Tag Archives: windows 8.1

Check Adobe Flash version Internet Explorer (Active-X) on Server 2012/2016 and Windows 8.1/10

Published / by Rens Hollanders / Leave a Comment

Hi there,

Just a very short post, because sometimes you’re search queries on Google don’t match the result you are looking for. I was looking for a way to detect which version of Adobe Flash is native installed on clients Windows Server (which happens to be Server 2012R2) and what it’s current patch level would be.

If you click this link (it point’s to Adobe’s website) and click on the button: “Check Now”, it will give you a result of which version of Adobe Flash is installed for Internet Explorer


After hitting “Check now” you will see the following result:


If you want to know which other versions of Adobe Flash player are installed for example for Google’s Chrome (PPAPI)  and Mozilla’s Firefox (NPAPI), then type in your start screen: appwiz.cpl which will bring you directly to the installed programs menu of the control panel.

Cheers! Rens

Workshop – Migrating from Windows XP to Windows 7 or 8.1

Published / by Rens Hollanders / Leave a Comment

We all know (as good technicians) that the technical support for Windows XP is coming to its end at April 8th 2014. For some time now I have been writing about topics related to Operating System Deployment, Microsoft Deployment Toolkit and Windows 8.1. And as of June last year I’ve followed a didactic course to become an Microsoft Certified Trainer, because I believe that sharing my knowledge, passion and enthusiasm for the work that I do, and the products I work with, could inspire others to do the same.

To put this into reality, my employer has enabled me to develop a two day workshop about migrating from Windows XP to another operating system platform, which can be either Windows 7 or Windows 8.1. The focus of this workshop lies on migrating from an existing operating system to a new one, -but that isn’t entirely necessary-. If you are interested in working with the Microsoft Deployment Toolkit this workshop also applies to you!

The topics that will be discussed within these two days are the following:

  • Concept of Operating System Deployment
  • Installing and configuring a Microsoft Deployment Toolkit environment
  • Migration scenarios
  • First steps in creating and building a reference image
  • Driver management
  • Userdata
  • Troubleshooting
  • Licenses

Requirements for this training:

  • A laptop capable of running Hyper-V and two virtual machines
  • Windows 8.1 Enterprise

Who may attend:

  • Basically everyone who wants to learn something about Operating System Deployment, but the focus lies mostly on IT Pro’s, System or Infrastructure Engineers

Where will this workshop be held:

  • On my employers head office, located in Wijnandsrade, the Netherlands.
  • Possible this workshop will be recorded and made publicly afterwards.

Unfortunately, international followers cannot attend this course at this moment. But in case you could not wait or you prefer to have more detailed information, please do not hesitate to contact me. 

More information:

If you are interested in participating in this two-day workshop, please visit the following link: http://t.co/2SAa2kx6PT

Thanks for reading! 🙂

Windows 8.1 – Installation of NetFx3 by command line will fail if language pack is installed

Published / by Rens Hollanders / 7 Comments on Windows 8.1 – Installation of NetFx3 by command line will fail if language pack is installed

Yes that’s right. Tested it the past week when creating an reference image for a project. It appeared to me that every time when I’ve wanted to install the .NET 2.0 and 3.0 feature on Windows 8.1 via command line or in MDT using the “Install Roles and Features” step and have ‘slipstreamed’ a language pack in Windows 8.1 with DISM upfront, the installation went wrong due to the fact that the Sources\SXS folder could not be found. This is something I’ve already seen as a question on social.technet which also lead to this investigation

figure 1.1: Error showing in bdd.log


For reasons unknown as we can see in the logfile the source path is changed from the value that I have specified to: C:\MININT\Sources\ while it should point to “%DEPLOYROOT%\Operating Systems\Windows 8.1 x64 Enterprise\Sources\SXS”

So I’ve started some testing and debugging, tried different scenarios such as: copying files locally, using an cmd installation file etc. Nothing seemed to work when the language pack was installed. Therefore I’ve performed a deployment without any additional language packs and it came to my attention NET FX 3.5 installs correctly without any issues.

Now how did I get around this?

Basically there are three options to install the .NET Framework 2.0 and 3.0 on Windows 8.1

  1. Manual by hand from the GUI
  2. By command line using DISM
  3. By using the “Install Roles and Feature” step in MDT
figure 1.2: Using the GUI
figure 1.3: Using the command line
figure 1.4: Using the “Install Roles and Feature” step


The way to get around this nasty ‘issue’ that DISM ‘sayes’ it can’t find the SXS source file location is to put the installation of NetFX before the installation of the language pack.

Currently I use the following scenario:

Added the Sources\SXS folder from the operating system I use (which is currently Windows 8.1 x64 Enterprise) as an application into the Microsoft Deployment Toolkit and within the application I’ve created the following cmd:

This will copy the Sources\SXS folder locally to the machine into C:\Temp and then executes the DISM command to enable the NetFx3 feature. At the end of my task sequence I perform a cleanup of some folders which deletes the content copied locally. I then call the cmd as command line for my application installation. Perhaps not the tidiest way to do it. But using cmd’s makes sure you can execute multiple commands just by starting one cmd. Instead of having to break things down in MDT with single command lines.

Another solution may be to put an Task Sequence Variable at the beginning of the task sequence called: WindowsSource which holds the following value (points to the following location) “%DEPLOYROOT%\Operating Systems\Windows 8.1 x64 Enterprise\Sources\SXS” and use the “Install Roles and Features” step.

Whatever you do, just make sure the installation of NetFx3 happens before the installation of a Windows language pack. And I’ve put a restart step after the installation of NetFx3 just to be sure. And since this is during the building of the reference image, time is not of the essence here. So having another reboot more or less doesn’t matter in this particular case.

figure 1.5: Task Sequence Variable – WindowsSource
figure 1.6: Task Sequence Properties – “Install Roles and Feature” step


Or use an application, like the script mentioned above:

figure 1.7: Application Properties
figure 1.8: Task Sequence Properties – Install Application


Hope this can be of help to anyone, if you have encountered something different. Have a different approach or just want ask something? Please feel free to contribute in the comments. Thanks for reading 🙂


Windows Intune – Automatic client installation on Windows 8 / 8.1

Published / by Rens Hollanders / 1 Comment on Windows Intune – Automatic client installation on Windows 8 / 8.1

When writing this blog, the initial purpose was to gather information and proof that the current Microsof Windows Intune client installation does not work on Windows 8.1. However before I went home today, I’ve deployed another Windows 8.1 machine with the Intune client with the intention to gather information, screenshots and logfiles to endorse this blog. However, 3 hours later, the results where entirely different.

This week I was busy with creating and testing a new deployment solution, which I’m building for one of our customers.

Since Microsoft Windows Intune was in play, and Intune provides Software Assurance, and this means we can use the latest available software. I created a Windows 8.1 and Office 2013 deployment task sequence, with the automatic installation of the Windows Intune Client (x64)

First of all the people new to Intune, need to know, that when you are going to deploy Windows Intune, firstly the client (which holds the Intune Agent) is being deployed, and when all goes well, the other Intune components are retrieved by the agent and automatically installed. Not only will this take some time, but this is also an indication, that Windows Intune will not appear directly on your new enrolled client in the start menu and or taskbar.

Based on Microsoft’s documentation about deploying Windows Intune on clients automatically, this can be done in 3 ways:

  1. Windows Intune Administrator Deployment
  2. User-initiated Enrollment for Computers in Windows Intune
  3. Installing the Windows Intune Client Software as Part of an Image

I chose another option, namely to deploy the client in my deployment task sequence. Separately from my image, so I’ve created the following step:

figure 1.1: task sequence properties


Which executes the installation of the application with the following command line: “msiexec.exe /qn REBOOT=ReallySuppress /i Windows_Intune_x64.msi

figure 1.2: Microsoft Windows Intune application properties


After the deployment was finished, I saw the client reported itself in the Intune management console, but I also saw that some errors where reported stating that the installation of the “Intune Client (x64)” could not be completed.

figure 1.3: Intune portal error


figure 1.4: Intune portal, detailed error pt. 1


figure 1.5: Intune portal, detailed error pt. 2


After checking my bdd.log (since I use MDT for deployment) and the MSI log’s that can be found in the %Windir%\%temp% directory, I saw all kinds of strange errors in the MSI logs which I could not interpret (The BDD.log was clean).

figure 1.6: bdd.log nothing to see here


figure 1.7: MSI{random_number}.log


After this I started to do some debugging, and try to take different approaches on installing the Intune client. First of all, I’ve started reading the “Troubleshooting Windows Intune Client Software Deployment and Enrollment” and “Validating Windows Intune Client Software Deployment

Next I performed a local copy action (from within the task sequence) of the client to the machine, and performed a local installation, instead of a network installation directly from the deployment share. I tried another installation switch. I extracted the .exe file and used the .msi instead. All did not lead to a solution. However I was able to install the client manually, without any problem. Which is very strange to my opinion since nothing has changed, the privileges used for installation where the same (administrator) and the only difference I could detect was using a task sequence versus manually installation.

Finally I tried a Windows 7 x64 deployment, with the Microsoft Windows Intune client incorporated in the deployment task sequence, which lead to the following result:

figure 1.8: Intune on Windows 7, everything green (except missing some updates)


So deploying Microsoft Windows Intune on a Windows 7 machine, works right away without any noticeable delays. Although Microsoft itself states that delays up to 30 minutes are ‘normal’:

After the Windows Intune client software is installed on client computers, the Windows Intune agents communicate with the Windows Intune service to provide the service with data about the clients. The frequencies with which the different agents communicate with the Windows Intune service depend on the workspace (for example, for the Updates workspace, the agent communicates with the Windows Intune service once a day; for the Software workspace, the agent communicates with the service once a week). In a few minutes to 30 minutes after the client software is installed, the names of the client computers appear in the Windows Intune administrator console. To locate the computers, in the Windows Intune administrator console, in the workspace shortcuts pane, click Devices, and then click All Devices. For more information, see Validating Windows Intune Client Software Deployment.”

source: http://technet.microsoft.com/en-us/library/jj676583.aspx

So it is very strange to see, that after 3 hours the Intune client finally did come through on the Windows 8.1 machine. There where no interruptions, no reboots and no loss of internet connectivity. Just by looking at the timestamp of the logs, it just showed that for the past 2 hours and 35 minutes, nothing had happened, untill I checked back on the machine again:

figure 1.9: timestamp of logfiles


Very strange right? And I have performed over 5 deployments with no effect, the Windows Intune Client remained in a state. So when I noticed this, I decided to do a new deployment again, and leave the machine unattended for longer then a day. When I checked it the next day, again the Intune client was installed correctly, however, again by looking at the timestamp of the logs. It again took longer then the projected 30 minutes. This time it took over an hour for the client to be succesfully installed.

figure 2.0: Intune on Windows 8.1



My conclusion thus far is that the Intune client is not entirely self-reliant at this moment to be automatically deployed on Windows 8.1. Yes it will install eventually, but it takes more time then I’m used to. Certainly, when we see that on Windows 7, the installation goes without a problem. So if time is not of the essence, you can go ahead and automatically enroll your Intune client, but if time is against you, you may want to enroll the Intune client manually at this moment, which goes without any errors, and it starts syncing the other components right away.

Just by looking at the log files, and the error’s that can be found in the log’s surely indicate that automatic deployment of the Intune client on Windows 8 /8.1 struggles to get installed correctly. However I can’t see anything specific in the log’s since the error’s don’t make sense to me (see figure 1.7).

Another thing that still needs to be resolved is the ‘remote desktop’ or ‘remote assistance’ functionality which appears to be disabled for Windows 8 / 8.1 machines on the Intune management console due to unsatisfying performance.

Hope this blog may be of some assistance for people that are trying to achieve the same, and -or perhaps you have managed to pull this one off without any problems. If so, feel free to contribute in the comments or to send me a message directly or via twitter

ps. forgive me for the Dutch screenshots, the Intune Portal belongs to a Dutch customer, and I have not find a way to set the interface to English.

Find attached the screenshots used in this blog, and the logfiles:

WinPE 5.0 will not boot on Hyper-V properly if start-up memory is less then 1024 Mb

Published / by Rens Hollanders / Leave a Comment

Since Windows 8.1 is here, and I’m a deployment enthusiast who likes to work with new things, I needed to upgrade my own system to Windows 8.1.

After this was complete I immediately installed the Hyper-V client role on my machine and created a Windows Server 2012R2 with MDT 2013 and Windows Assessment and Deployment Kit 8.1 for Windows 8.1 and Windows Server 2012R2.

During the installation of the Windows Server 2012R2 in Hyper-V I received the following error: “Error code: 0xE0000100

figure 1.1: Windows Server 2012R2 installation error


Later on it appeared to me that addressing less then 1024 Megabytes of memory, caused this error.

After my server and MDT 2013 where succesfully installed, I wanted to do some deployment testing using one of my VM’s which I have configured as following:

figure 1.2: Hyper-V Machine Configuration – Memory


Since I’m only using Hyper-V for my own lab/test environment and my client machine has 16 Gb of RAM memory, I always check the “Use Dynamic Memory for this virtual machine” checkbox, thinking that if my virtual machine needs more memory then 512 Mb, it will claim it by itself!

By increasing the memory configuration in Hyper-V for this particular virtual machine from 512 Mb to 1024 Mb the installation error of Windows Server 2012R2 was resolved, which got me thinking…

If Windows Server 2012R2, Windows 8.1 (which has been released at the same time with these two operating systems) and WinPE 5.0, all have the same kernel, increasing the memory from 512 Mb to 1024 Mb on a virtual machine which I’m going to to use for MDT deployments should solve my problem that WinPE 5.0 stalls during boot, and shows no MDT wizard screens within WinPE, and my assumption was correct

So, if you encounter this on your own lab environment, or using WinPE 5.0 on Hyper-V, then make sure the virtual machine you are using has at least 1024 Mb of startup memory available!

Almost weekend! Cheers! 😀