Tag Archives: 2014

2014 – My year in review…

Published / by Rens Hollanders / Leave a Comment

Lasts day of the year, always a good day to look back and to look forward, to what’s been and what comes 🙂

In addition to last years review: 2013 – My year in review, MDT, MCT, Music, Vinyl, Concerts and more… I’ll start with the top 5 best read posts of this year:

  1. MDT – Unattended.xml, CustomSettings.ini, Task Sequence Variable, which setting takes precedence over which setting?
  2. Windows 8.1 – Installation of NetFx3 by command line will fail if language pack is installed
  3. Office 365 – Automatic deployment of Office 365 with MDT
  4. MDT 2013 – Configuring your environment for Bitlocker deployments with TPM, Windows 8.1 and MDT 2013
  5. OSD – Live from the field my ‘Best Practices’ for Operating System Deployment

Now lets talk numbers:


As you can see here, over the entire year. I had nearly 60k sessions. 41k unique visitors which generated 152k pageviews. That’s a staggering number for me, as I never expected this many people would visit my blog. Taking into account, that most of you stayed nearly for 1:30 minutes per session on my blog is incredible and I would like to thank you for all this.

Also it’s funny to see when the weekend kicks in, and when the working days are. Somewhere between March 13 and March 18 I lost my Google Analytics tracker due to the change of my websites theme.

If we are talking geographics, the United States, United Kingdom and the Netherlands are in the top three of visits by country:


Browsers, Google Chrome on top:


So I’m really dazzled by all these numbers, and I would like to thank you all for visiting my blog over in 2014.

But 2014 meant more for me, then just writing some posts about IT related stuff. We’ve sold our apartment which due to the financial crisis wasn’t really easy. It took nearly three years before it got sold. Bringing a huge sacrifice at this point, enabled us to buy our dream house only 8 months later, and now we finally have a house with a rooftop to shout it from 🙂

But 2014 was also a year of music, and for my fellow music enthusiast, I wanted to share my list of music for the year 2014:

  1. The War On Drugs – Lost In The Dream
  2. Royal Blood – Royal Blood
  3. Wovenhand – Refractory Obdurate
  4. Interpol – El Pintor
  5. Lana Del Rey – Ultraviolence (Deluxe)
  6. Amatorski – From Clay To Figures
  7. Damien Rice – My Favourite Faded Fantasy
  8. PAUW – PAUW – EP

Above are some of my top listed albums and EP’s from 2014, which are definitely worth a try If you haven’t heard from any of these bands (although I doubt the War on Drugs is unknown, since it occupied the radio-waves home and abroad throughout the entire year)

Well this leaves me to say and wish you all the very best in 2015, with health luck and love and have a safe New Years Eve.

Cheers! Rens


MDT – Add deployment information with PowerShell and perform a REFRESH scenario

Published / by Rens Hollanders / 8 Comments on MDT – Add deployment information with PowerShell and perform a REFRESH scenario

Hi, just a quick post about an idea I wanted to share with you all:

A request from a colleague -since we are using MDT to deploy our corporate machines- was to create a mechanism that prevents the re-partitioning and formatting of hard drives that have already been deployed with MDT.

Now this can easily be done by creating the following steps in your deployment task sequence:

figure 1.1: Set Task Sequence Variable – DeploymentType


As you can see above, the Task Sequence Variable “DeploymentType” will be set, during the execution of the task sequence. But how can we achieve this only happens if for example the machine has already been installed with MDT a previous time?

figure 1.2: Task Sequence Variable Condition


By setting a condition on this Task Sequence Variable. For example by checking if a certain file exists. Naturally it is key, that this file will be created at the first initial deployment of the machine, or the file is created manually afterwards. The reason why I check both C: and D: drive, is that within Windows PE, it may occur that sometimes your C: drive is detected as D: drive due to the “System Reserved” or “System” partition.

This way I’m always right.

Now, to generate a file for identification, I’ve created a powershell script, which dumps certain Task Sequence Variables queried by the ZTIGather.wsf script in a text file, together with a couple of WMI queries:

The script is pretty straight forward:

First it sets the invocation path, which is the path from where the script is called. Then it sets the variables which are needed as input for the script. And the cool thing is, since ZTIGather.wsf queries the entire machine, we can use the MDT Task Sequence Variables as input for our script, which will be dumped into the text file.

To determine the computername, I wanted to use the OSDComputerName task sequence variable, but strangely enough, it outputted the AssetTag instead, for this reason I used the WMI query:

And the same thing goes for the Windows Operating Sytem version:

And bitlocker recovery key:

I then just needed to format these results in a readable usable manner, to get all my variables straight.

Now that’s out of the way, I needed a folder to store this information in, but I don’t want to bother end-users looking into it. So I create a folder called “MDTRollout” and placed it in the root of C:\ and give it the “Hidden” attribute, also I perform a check if the folder itself does not exist, in that case it will be created.

The same thing goes for the text file which is automatically created, if it does not exist. And if the file exists, it will add the content, for example when the machine is reïnstalled for the 2nd, 3rd, or 50th time.

And now to show you the result:

figure 1.3: No folder present at first


figure 1.4: running the script


figure 1.5: Task Sequence has finished


figure 1.7: Contents of the DeploymentInfo.txt004

There you have it, a little usefull file which can be used to quickly evaluate the computer’s identity and configuration. Which on it’s turn, forms the basis to perform a MDT REFRESH scenario, instead of a NEWCOMPUTER scenario.

The script can be placed in the .\DeploymentShare\Scripts folder, and executed with a “Run Powershell Script” step from within the Task Sequence properties pane. You can call the script as following: “%Scriptroot%\MDT_DeploymentInfo.ps1”, the great thing about doing it this way, is that MDT handles the execution policy of powershell which would otherwise prevent the execution of the script. Normally it is necessary to set the policy to “Bypass” or “Unrestricted”.

figure 1.8: Calling the script


figure 1.9: Testing it yourself


Now to test the script yourself, a custom task sequence with the following two steps should do the trick:

  1. “Gather”
  2. “Run PowerShell Script”

Hope this can be of use to anyone else.

Find attached the screenshots used, and the actual script, which can be downloaded


Cheers and have great 2014/2015! Merry Christmas and a Happy New Year!!!!


MDT – Versioning made easy (powershell = king)

Published / by Rens Hollanders / Leave a Comment

The great thing I like about doing projects with customers, is that each and every customer has it’s own challenges. And I think it is safe to say, that challenges brings out the best of all of us IT Pro’s.

In this particular post, I want to talk about the Microsoft Deployment Toolkit, versioning mechanism: ..MDT has no versioning mechanism 🙁

Wouldn’t it be nice to just have an option to duplicate a task sequence, like MDT’s big brother Microsoft System Center Configuration Manager?

Well that day has come my friends 🙂

Currently I’m working on reverse engineering a Citrix XenApp 6.5 environment which needs to be rebuild from the ground up with MDT. And after it has been built, it needs to be managed, improved, extended further when necessary.

Now it is perfectly possible to duplicate task sequences manually. Just create a new task sequence with the wizard within MDT, and copy the ts.xml and optionally the unattend.xml from your control\<tsid> folder to the new control\<newtsid> folder, and voilá your task sequence is duplicated. But wouldn’t it be nice to do this automatically?

Depending on the tools that are present in any particular organization, since MDT is free, and tools such as RES Automation Manager and System Center Config. Mgr. cost money (..and particularly Config. Mgr. costs lots of it too) I wanted to create a solution for having some kind of versioning system in MDT.

Since I’m getting more and more familiarized with PowerShell, I can kick in the open door by saying what we all know: PowerShell is truly King. Although I do not poses all the knowledge, luckily I have multiple colleagues who are willing to help me at any given time. This time I would like to thank Pascal Zeptner, for spending his free time with me 😀

Now before we are going to talk about the script, it is imperative that your Task Sequence ID is built up out of the following naming convention:

  • OSB001
  • OSD002

I maintain this convention at all of my MDT implementations. The abbreviation OSB stands for “Operating System Build“, while OSD stands for “Operating System Deployment“. The essential difference between the two is, that the first one is used for creating reference images for target machines. While the second is used for deploying the reference image that is created, to target machines.

And to have a complete MDT environment with an orderly created folder structure in less then 20 seconds, please visit this blog: MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

Behold the script:


First of all, the script checks for elevation, if you do not run this script elevated it will not execute:

Secondly, the script needs certain variables made clear to work with. In this case the following static variables:

After these variables are filled in. The script will import the MDT PowerShell module, located at the default location where MDT normally is installed. If you have installed MDT elsewhere, you will receive notice that the MDT module was not found and the script will terminate.

Next, a new PowerShell drive will be created, so we can browse the MDT virtual folder structure:

After this, the real stuff begins: In the following lines of code, the properties of a task sequence will be queried. This happens with the “Out-Gridview” cmdlet, since this presents a nice selection dialog, to select the desired task sequence which we want to duplicate.

From this selected task sequence, we query it’s ID, and increase the number on the ID with +1 to create the new Task Sequence ID.

The same thing goes for the Task Sequence Version, which is also queried, and increased with +1. As soon as the version of the task sequence hits .9, it will increase the master version from 1.0 to 2.0.

Lastly the name of the task sequence is queried, and assuming we use a specific naming convention for our task sequences, which uses “v1.0” at the end. The last three characters are removed and replaced with the $NewTSVersion variable. This causes our newly created task sequence, to receive a name with the increased version number too!

Now all the information we need to know to duplicate our task sequence is known, we can actually create a new task sequence and copy the contents from our reference task sequence to the new task sequence:

As you can see, there are some checks built-in that verify if the new to be created task sequence does not already exist on physical folder level.

Now to underline all this, screenshots:

figure 1.1: Select designated task sequence for duplication


figure 1.2: Task Sequence duplicated


figure 1.3: Press F5 to refresh and see the new task sequence


figure 1.4: Perform duplication at v .9


figure 1.5: Version 2.0 created


figure 1.6: Press F5 to refresh and see the new task sequences


figure 1.7: *.xml files are copied from destination task sequence to new task sequence


..and that my padawan automaters, is how the cookie crumbles.

Comments, questions, improvements? Please let me know in the comment section. It’s as always much appreciated.

The script and images used in this blog can be downloaded here:


Cheers! -Rens


Citrix – XenApp/Desktop integrate Internet Explorer 11 Enterprise Mode – Issue and workaround

Published / by Rens Hollanders / 6 Comments on Citrix – XenApp/Desktop integrate Internet Explorer 11 Enterprise Mode – Issue and workaround

Working in real life production environments beats concept and test environments each and every time when it comes to debugging and optimizing the environment for your care-free 😉 end-users.

No matter how much you have tested up front, If you think you’ve got it covered for 99,9 % there’s always that 0,01 % that comes knocking at your door. This time it’s Internet Explorer 11 Enterprise Mode, in combination with Citrix XenApp 7.5 / 7.6 that causes a malfunction of the so called EMIE feature.

First some more details about Internet Explorer Enterprise Mode or EMIE:

A lot has been written about EMIE and one of the founding father’s I believe is Microsoft Architect Chris Jackson, who was so kind to at least hear me out after I contacted him on twitter FTW!

EMIE operates as an alternative to Internet Explorer’s Compatibility View. It’s a feature that needs to be enabled trough Group Policy Objects to reveal itself to the user. The benefit of using EMIE above Compatibility View is that EMIE allows us to specify individual websites to run EMIE even when the parenting website should not run EMIE. Opposed to Compatibility View, which allows you to only run entire domains in compatibility view, not excluding or including sub-domains or sub-sites.

If EMIE would have been enabled on your machine, you would have found it here:

figure 1.1: Internet Explorer Tools


Since it’s not there we need to make it visible, start GPEDIT.MSC and go to: “Computer Configuration \ Administrative Templates \ Windows Components \ Internet Explorer” and enable “Let users turn on and use Enterprise Mode from the Tools menu“. Next, perform a GPUPDATE /FORCE to force the policy to become active.

figure 1.2: Group Policy Objects – Configure EMIE


This causes you to put websites in Enterprise Mode for the length of your current browser session. When you close your session, Enterprise Mode for this particular website isn’t active anymore when the website is revisited.

Since we configured the Group Policy Object, we can now see EMIE in Internet Explorer 11:

figure 1.3: Internet Explorer Tools – EMIE visible


Microsoft has come up with a solution to provide a list of websites that forces Internet Explorer 11 to always render those particular websites in Enterprise Mode. Therefore the following Group Policy Object is configured: “Computer Configuration \ Administrative Templates \ Windows Components \ Use the Enterprise Mode IE website list “. This allows you to generate a website list XML file, which contains which websites should run Enterprise Mode and which shouldn’t.

It looks like this, and is best managed and generated with the Enterprise Mode Site List Manager:

figure 1.4: EMIE Site List Manager


figure 1.5: EMIE Site List Manager – Add new website


If for example the website: www.google.com was to run in Enterprise Mode, it would look like this:

figure 1.6: Google running EMIE


EMIE can be easily identified, when looking at the address bar, in front of it you should see a blue square with a white office building logo. This represents EMIE is enabled for this particular website.

The problem:

In this particular case we have setup EMIE, to use the Sitelist.xml hosted on a file server. It’s also possible to host the file on either a webserver or local file path.

If we look at EMIE and it’s behavior in the registry, we can conclude the following information is necessary to configure EMIE for users.

In HKLM we encounter the following key and registry values: “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode” -Name “Enable” -value “blank” -type “REG_SZ”

And -Name “SiteList” -value “path to xml file” -type “REG_SZ”

figure 1.7: Regedit – HKLM


And in HKCU we encounter the following key and registry value: “HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\EnterpriseMode” -string “Currentversion” -value “1” -type “REG_SZ”

The currentversion value, checks if the Sitelist.xml has been updated between the previous and current session. If this is the case, EMIE will retrieve the new Sitelist.xml from the designated target location. This procedure also causes EMIE to malfunction in cases where the list has not been updated, but the list itself not being retrieved. The solution to this is to either delete the CurrentVersion value each time from the users registry, or to increase the version number within the Sitelist.xml. I choose another option: Use mandatory profiles! Since mandatory profiles is already in place within our environment, each time the user log’s out everything that is not preserved with RES Workspace Manager Zero Profile technology will be deleted. For more information about this particular ‘error’, please visit this social.technet thread.

What we encountered in our environment was that when logging in to a Citrix connected session the Enterprise Mode was not configured, opposed to when we logged in from an Remote Desktop Session. This has come forward during troubleshooting the issue. At first we looked with ProcMon to find if any other process was interfering with our Group Policy Object and RES Workspace Manager, which we use to configure HKCU Group Policy Objects and registry settings with, but we couldn’t find a direct lead to the problem.

The behavior prior to resolving the issue was, that when using a Citrix connected session. The “EnterpriseMode” key was not and could not be created in the user’s registry for the length of the session. Strangely enough we could create registry value’s under .\Internet Explorer\Main, but not key’s. Regedit threw an error stating:

figure 1.8: Regedit – Error


Unfortunately the screenshot is in Dutch, but it states: Cannot create key: an error has occurred when trying to write to the registry

The workaround:

While troubleshooting, I’ve submitted a ticket with Microsoft Support, but they were unable to find anything concerning either Server 2012 R2, Internet Explorer and EMIE in particular. Which pointed me to Citrix. I received a tip from a Citrix partner to create a registry placeholder through Group Policy Object, which is what I did:

figure 1.9: Group Policy Objects – User Configuration registry placeholder


figure 1.10: Group Policy Objects – User Configuration registry placeholderemie009
figure 1.11: Group Policy Objects – User Configuration registry placeholder

This finally ‘resolved’ my issue, and made it able to use EMIE within a Citrix XenApp 7.5 / 7.6 environment. However it’s still unclear what causes to hijack the “.\Internet Explorer\MAIN” key, due to the placeholder it’s now possible to create keys underneath MAIN which was necessary for EMIE to function properly.

Although this workaround works for now. I’m convinced the error lies within Citrix, and they should at least examine the root cause of this incident. Since Server 2012 R2 and Citrix XenApp is becoming common ground in Server Based Computing land, and I think it’s highly unlikely that no one else will encounter the same issue.

In the mean time, this should have to do the trick and I hope this can be useful for anyone encountering the same issue.

Don’t agree? Or got a better idea? -As always comments and contribution’s in the comment section are greatly appreciated.

Cheers! -Rens


RES Workspace Manager – Save IE and Windows Credentials

Published / by Rens Hollanders / 11 Comments on RES Workspace Manager – Save IE and Windows Credentials

Just a quick post to inform everyone who is interested where to find and preserve the Internet Explorer and Windows Credentials used to log in to SharePoint websites, web-portals and other websites.

Normally you would find these settings within Windows, at the following place: “Control Panel \ All Control Panel Items \ Credential Manager”

figure 1.1: Credential Manager

Credential Manager

The folder location where these files can be found on your own computer for these three folders and it’s place in the registry are:

  1. C:\Users\<username>\AppData\Local\Microsoft\Credentials
  2. C:\Users\<username>\AppData\Roaming\Microsoft\Credentials
  3. C:\Users\<username>\AppData\Local\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28
  4. HKCU\Software\Microsoft\Internet Explorer\IntelliForms\Storage2

If we take a look into the “Credentials” folders you will not see anything unless you uncheck: “Hide protected operating system files (Recommended)” in the folder options:

figure 1.2: Folder options


Once this has been done, have a look into your .\Credentials folders to find files like these:

figure 1.3: Credentials


Now if we want to preserve the information for this section with RES Workspace Manager, since you might have configured mandatory profiles with RES Zero Profile technology. Just add the following four paths to your “User Setting template” for Internet Explorer 11. (Alternatively you may want to create a dedicated User Setting for these credentials)

  1. Folder tree: %LOCALAPPDATA%\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28
  2. Folder tree: %LOCALAPPDATA%\Microsoft\Credentials
  3. Folder tree: %APPDATA%\Microsoft Credentials
  4. Registry tree: HKCU\Software\Microsoft\Internet Explorer\IntelliForms\Storage2

Remarkably, the first path needs to be added into RES Workspace Manager including the GUID folder: 4BF4C442-9B8A-41A0-B380-DD4A704DDB28

To learn more about the credentials Vault present in Windows, please visit this excellent blog written by “Derek Melber”: Saving Credentials on Windows Computers

figure 1.6: RES Workspace Manager – Edit User Setting

RES WM  - User Settings2

Click OK, and you are good to go! Now passwords entered on websites will be preserved in between user sessions.

Again any comments or contributions are valued!

Cheers! 🙂