RES Workspace Manager – Inject Java Security level for users

Today I encountered a challenge which I think needed to be shared with you all.

Currently I’m working with other colleagues on building a brand new Citrix XenApp 7.5 environment based on Server 2012 R2 x64 in combination with RES Workspace Manager 2014 SR1, together with mandatory profiles and RES Zero Profiling technology.

A user who works with several java applications encountered the following problem:

figure 1.1: Java Application Blocked by Security Settings

java selfsigned blocked

Since this error is generated by Java, I immediately went to the control panel to investigate the available options for configuring Java.

You can find the Java control panel applet, when you change the “Category” view in your control panel to “Large” or “Small” icons.

figure 1.2: Control Panel – Java (32-bit)

04

Click the “Java (32-bit)” shortcut in your control panel, and the following screen will appear:

figure 1.3: Java Control Panel

java05

Now for example, if we want to change the security level of Java, which prevents the current Java application from running, change the security level from “High”

figure 1.4: Java Control Panel – Security High

java10

To “medium”

figure 1.5: Java Control Panel – Security Medium

java11

And click “OK”.

This would do the trick, but how can this setting be passed on to users logging on to a Citrix environment with mandatory profiles?

Since we are using RES Workspace Manager, I did the following:

First of all I needed to capture the setting with some kind of tool. You’ve got two options here:

  1. Regshot, wich is an opensource and free tool to capture and compare system state registry and file system changes between two snapshots and show the result as to what has changed
  2. ProcMon, which is a great tool for checking realtime processes, registry behavior and much more.

I chose for ProcMon, (make sure it runs in admin mode!)

figure 1.6: ProcMon

procmon

Now, when ProcMon is started, make sure you stop capturing (leave ProcMon running for some time and you’ll know why ;) ) and make sure the list of captured events is made empty by clearing the screen:

 figure 1.7: ProcMon – Capture and Clear Screen

procmon arrows01

Now that’s out of the way, since we want to capture some Java activity, go to Filter in the menu, and add the following filter: “Path” contains “Java”

 figure 1.8: ProcMon – Add filter

path java09

Click “Add” and then “Apply”.

Now you have made a filter only showing event’s which concern the word “Java”.

Now repeat the configuration of the Java security level on the Java control panel menu. And you will see the following appearing in ProcMon:

 figure 1.9: ProcMon – Results

procmon12

As you can see here, Java writes the changes to the following path: “C:\Users\Administrator\Appdata\LocalLow\Sun\Java\Deployment\deployment.properties”

Examining this location reveals the following:

 figure 1.10: Windows Explorer – File location

java13

If you open this file with notepad, you will find several properties which indicate how Java is configured on your machine.

 figure 1.11: Deployment.Properties – Content

deployment.properties

So there you have it: the Java configuration file.

The same goes when adding certain trusted websites to the Java applet:

figure 1.12: Java Control Panel – Edit Site List

java10

If you click “Edit Site list” the following screen appears:

figure 1.13: Exception Site List

java14

By clicking “Add”, another screen appears:

figure 1.13: Exception Site List – Adding the website

java15

For example, by adding Google.com to the list of trusted sites to run Java-applets, you’ll receive security warning if you click “OK”

figure 1.13: Exception Site List – Just click OK…

java17

And by clicking “Continue”, the website will be added to the list of trusted sites to run Java-applets. Again a setting which will be written to a config file, this time on the following location:

“C:\Users\Administrator\Appdata\LocalLow\Sun\Java\Deployment\Security\exception.sites”

 figure 1.14: Windows Explorer – File location

java16

If you open this file with notepad, you will find the website we’ve just added:

 figure 1.15: Exception.Sites – Content

exception sites

Now, how can this be incorporated for every user signing into a Citrix environment with mandatory profiles you ask?

In the RES Workspace Manager console, go to “Administration > Custom Resources”, and add the deployment.properties and / or the exception.sites file as a custom resource:

 figure 1.16: RES Workspace Manager Console – Custom Resources

Custom Resources

Go to “Composition > Execute Command” and click “New Command”

In the properties pane, make sure the script is executed “At logon after other actions” as command specify the following: “%script%”, this makes sure you can use the “Script” pane which can hold far more complex  and even more important, multiple lined scripts.

 figure 1.16: RES Workspace Manager – Execute Command

command01

As you can see, I’ve pasted the following script in the “Script” pane:

 figure 1.17: Execute Command – Script

script

The exact content of the script is:

script 1.1: Copy Java security permission file to designated location

 figure 1.18: RES Workspace Manager – Execute Command

execute command

Now each time a user log’s into the Citrix environment the Java configuration file “deployment.properties” will be copied from the database used by RES, into the specified location. Setting the correct Java security level, trusted websites and other related settings for each user, during each session.

As you can see an entire different warning appears, which is just perfectly normal. It hopefully makes users aware of the potential risk opening the Java applet. But 90% of the users will happily make use of their trigger-finger twitch!

 figure 1.19: Java Security Warning

java do you want to run

Got anything to add, got a trick up your sleeve which can simplify this action, or am I just doing it all wrong? :) Please leave your comments in the comment section!

Cheers Rens!

MDT – Linked Deployment Shares, Litetouch.vbs and CustomSettings.ini properties and priority (User Question)

Last week Alexander reached out to me with the following question(s):

“Hello could I ask some questions?

  1. I am creating Linked Deployment Share, what difference between Merge and Replace, during creating?
  2. What properties do you recommend for using?
  3. Could you explain features of Extrafiles directory on MDT, how can I use It, and may be you know were I can find information about it. May be you know good examples?
  4. Is it important the order of positions priority in CustomSettings.ini
  5. Priority=DefaultGateway,Make,Default,SendMail
    Properties=OSDSendMailFrom,OSDSendMailTo,OSDSendMailSubject,OSDSendMailBody,
    OSDSendMailSMTPServer,OSDSendMailIncludeBDDLog,SavedJoinDomain and how could I understand what have to be first, second, third etc.
  6. What is Priority and Properties?
  7. What difference between LiteTouch.wsf and LiteTouch.vbs? And which script I have to start to implement replace scenario?

Thank you for your answers!”

Well Alexander, you didn’t hold back on asking questions, so let me ‘not’ hold back on giving answers :)

Linked Deployment Shares

Linked Deployment Shares is MDT’s mechanism to distribute and synchronize content which is originated with the MDT Deployment Share, to parent deployment shares or remote locations. Deployment Shares can be connected to other deployment shares, and this is called “Linked Deployment Shares”. Now how will MDT know what content to distribute and/or synchronize? This is determined by using selection profiles.

Selection profiles are profiles which can be created within MDT, under “Advanced Configuration” in the MDT workbench, and are no more or less then a list of items that are checked or unchecked by the person creating the profile. These profiles can be used for lot’s of things, such as driver profiles, package profiles, offline media profiles, and linked deployment share profiles.

Basically by checking and unchecking content from the MDT Deployment Share through the workbench console, you can decide which content needs to be distributed and synchronized from time to time.

Now you ask the purpose behind merge and replace. This can be best compared by doing a copy and paste action on a windows folder, which already holds content that you are going to copy/paste into the exact same folder. What happens is that the Windows Explorer File Manager will ask you what to do with the content: Replace, or do nothing. This action is similar to the replace or merge function. Merge means that content which is already present in the parenting deployment share will be maintained, while replace means that the entire content which is already present in the parenting deployment share will be replaced.

However, I would not recommend using linked deployment shares, since it is prone to error’s, and it lacks control, which you otherwise would have, when you using robocopy for instance. Even MDT guru Johan Arwidmark recommended me to use robocopy above using linked deployment shares, and I won’t argue with him on that point!

What properties do you recommend for using?

I’ve written a blog about my commonly used customsettings.ini properties, read it here

Could you explain features of Extra files directory on MDT…

The extra files directory is quite simple. But first, let us determine the extra files directory:

Go to your deployment share, right click on it, and click “Deployment Share Properties”

figure 1.1: Open Deployment Share Properties

DeploymentShareProperties

My approach has always been to embed extra files like this:

figure 1.2: Deployment Share – WinPE Properties

Extrafiles

As you can see I’ve specified the extra files directory within MDT as following: “%DEPLOYROOT%\Extra” and the same goes for the Custom MDT background which is also located in in my Extra directory, the benefit of this is, that I can create a folder named “Extra” within my deploymentshare, and place all the content I need into my boot image, in this location:

figure 1.4: Extra folder

Extrafolder

Next time when you will update or completely regenerate your boot images, the contents of the Extra folder will be present in your boot image, and it can be found by opening a command prompt and browse to the root of your drive: “X:\” there you will find trace64.exe for example, which is quite handy viewing logfiles, rather then using notepad.exe!

figure 1.5: Command Prompt in WinPE

Extracommandprompt

So there you have it, the Extra files directory in MDT

Is the order of  priority positions in CustomSettings.ini important?

Short answer: Yes, priority determines in which order subsections of the CustomSettings.ini is processed:

As you can see in this example, my priority order is as following: Priority=Model, Default. This means that first if the machine you are going to work with, matches the model description specified in the customsettings.ini this section will be processed first, before the default customsettings.ini rules will be processed.

This can be quite handy, if you want certain machines to join the domain, while others just need to be joined to a workgroup or the other way around. So yes priority matters, however the location of your subsection in Customsettings.ini does not. You can place the Model subsection beneath the Default section, and add in other subsections as well. This does not affect the priority.

What is Priority and Properties?

This question hooks onto the previous one:

  • Priority determines in which order Properties are processed
  • Properties represent objects which contain a value that MDT can work with since the scripts that are used within MDT rely on these properties.
  • The priority of properties is of no importance. It doesn’t matter if you place OSDSendMailFrom before OSDSendMailTo or OSDSendMailTo before OSDSendMailFrom, it just matters that the property is present.

So for example the Property “OSDComputerName” = HAL9000, this value will be collected during the Gather step in a task sequence, and then will be stored and used when the time is right to set the hostname of the machine, which happens during the setup phase of the operating system.

What’s the difference between LiteTouch.wsf and LiteTouch.vbs? And which script I have to start to implement replace scenario?

Good question, if you would have examined both script’s you will find the following:

Litetouch.vbs is used to start the deployment, and setup a connection with the deploymentshare. This process can either be initiated from within Windows, or from within WinPE, it doesn’t matter. Either way Litetouch.vbs is used. Litetouch.vbs can be started by double-clicking on it on a running Windows machine, but that’s just to easy since Windows recoqnizes VB script’s and know’s what to do with it.

The correct way to start Litetouch.vbs is to open an elevated command prompt and type: cscript.exe <path to litetouch.vbs\litetouch.vbs. This also provides some cool tricks to instantly specify certain values that litetouch.vbs can work with, for example: cscript.exe litetouch.vbs /tasksequenceid:<tsid> will initiate the mdt deployment which immediately calls the specified and desired task sequence!

figure 1.6: Litetouch.vbs

litetouch.vbs

And as you can see here: Litetouch.vbs paves the way, Litetouch.wsf finishes what has been started!

About your replace scenario, this is not decided by either Litetouch.vbs or Litetouch.wsf but determined by the value which given to the property: “DeploymentType

This properties knows three known values:

  1. NEWCOMPUTER
  2. REFRESH
  3. REPLACE

And depending on the value you specify, one of these three scenario’s will kick-in. Just open your task sequence and look at the groups Refresh, Replace and view the options, to find a Task Sequence Variable is set as condition. And if the condition is met, these steps are executed during the deployment of the machine!

That concludes this blog, and I hope you Alexander and many others will find this information usefull in your way of working with the Microsoft Deployment Toolkit!

Cheers!

MDT – Quick Post: How to install App-V 4.6 SP3 and 5.0 SP2 client

Some time ago I needed to install both App-V 4.6 and 5.0 with MDT for a Citrix XenApp 7.5 base installation image.

Figuring out which command lines run with different applications, can sometimes be a painful process. Of course opening up a command prompt, and entering the following command “executable.exe /?” will get you on the right track, but sometimes that’s just isn’t enough.

One of those applications I’ve encountered numerous times, which will always get to you is, is the installation of the App-V 4.6 client with SP1, SP2, SP3 and hotfixes.

This guide will help you install the App-V client to the latest available versions out there!

First of all, here’s a list of the most up to date version of the App-V 4.5 and 4.6 client:
Current list of App-V 4.5 and App-V 4.6 file versions

And the same goes for the App-V 5.0 client
Current list of App-V 5.0 file versions

Next to this you’ll need middleware components, App-V uses several Visual C++ components. I have the following installed prior to the installation of App-V:

figure 1.1: Installation of Visual C steps

app-v002

The install command lines for Visual C++ are as following:

  • vcredist_x64.exe /q
  • vcredist_x86.exe /q
  • vcredist_x64.exe /q
  • vcredist_x86.exe /q
  • vcredist_x64.exe /q
  • vcredist_x86.exe /q
  • vcredist_x64.exe /q
  • vcredist_x86.exe /q
  • vcredist_x64.exe /quiet /norestart
  • vcredist_x86.exe /quiet /norestart
  • vcredist_x64.exe /quiet /norestart
  • vcredist_x86.exe /quiet /norestart

At this moment my task sequence looks like this:App-V 4.6 SP3 especially needs Visual C++ 2008 SP1 x64 and x86

figure 1.2: Installation of App-V client

app-v001

And the command lines used are as following:

  • msiexec.exe /i SETUP.MSI SWIGLOBALDATA=”D:\App-V” SWIUSERDATA=”%APPDATA%” SWICACHESIZE=”30721″ SWIPUBSVRHOST=”SAPPV.CONTOSO.COM” /norestart /qb
  • cmd /c NET STOP SFTLIST
  • cmd /c NET STOP SFTVSA
  • setup_upgrade.exe /S /v”/qn REBOOT=ReallySuppress”
  • Restart Computer
  • msiexec /p AppV4.6SP3-RDS-KB2897394-x64.msp /qb-! /norestart
  • APPV_CLIENT_SETUP_RDS.EXE /q /norestart /ACCEPTEULA
  • AppV5.0SP2-RDS-KB2934349.exe /q /norestart /ACCEPTEULA
  • AppV5.0SP2-RDS-KB2956985.exe /q /norestart /ACCEPTEULA

Next, stopping the App-V services is necessary to perform the remainder of the installation of the App-V 4.6 SP3 update. This is because after the reboot the App-V services are already up and running. The line marked orange is to stress the need for a reboot at this point.

Update, since App-V 5.0 SP2 hotfix 5 has been released, the following command line can be added to the steps above:

  • AppV5.0SP2-RDS-KB2963211 /q /norestart /ACCEPTEULA

That’s all folks, hope this comes in handy when you are struggling yourself with the installation of any App-V client.

If you have any remarks, questions or comments, feel free to contribute in the comment section.

Cheers! :)

MDT – How I build my reference images (User Question)

Based on my last post: “MDT – Post me your MDT Questions” I’ve received a question from mr. “Jones” who reached out to me with the following comment:

Hi,

Great that Microsoft at last put an understandable Technet article on “Create a Windows 8.1 Reference Image”. Great comments by you aswell on clearing the event logs. I think Microsoft should put that as default in MDT.

Maybe there are some other small “tips” that you ALWAYS perform at every MDT installation you do that you can share with us?

So to put my words in action, this is how I build my reference images.

!Note: this post focusses on building a Windows 8.1 Enterprise image, but with some adjustments can well be used for a Windows 7 Enterprise deployment.

1. Use the ConfigureDeploymentShare script.

To get a headstart with configuring MDT, you can save a lot of time by using my powershell script. It will create and configure everything in your deploymentshare, based on a logical structure I’ve designed.

You can find the script and post about it, here: “MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

2. Create a build task sequence

Within MDT there are several templates available which set you up with a task sequence from where you should be able to do a deployment.

Now understand that there is no difference between a so called ‘build task sequence’ and a ‘deploy task sequence’, the differences are made by the person that’s responsible for the MDT environment.

To get started, I assume you have already imported the following sources:

  • Operating System source (like from a Microsoft ISO file)
  • Applications (like visual C++ redistributables, Office 2013 etc.)
  • Possible VMware drivers (if you are building your image on a VMware platform)
  • Packages containing Windows 8.1 update files
  • Language packs

Under the task sequences node, select the Build folder, which represents task sequences that are used for creating reference images:

figure 2.1: Task Sequence Node

build001

and on the right side pane, click “New Task Sequence”

figure 2.2: New Task Sequence

build002

From there a wizard will start, asking some basic information. This information is used to generate the unattended.xml which is used to deploy the operating system unattended with the information specified in the xml file.

figure 2.3: Task Sequence Wizard – General Settings

build003

In the general settings, I always like to specify a build task sequence with OSB (derived from Operating System Build) followed with a unique number. If this is the first task sequence, call it OSB001

figure 2.4: Task Sequence Wizard – Select Template

build004

 

Select the standard client task sequence if you want to deploy a client, select the standard server task sequence, if you want to deploy a server

figure 2.5: Task Sequence Wizard – Select OS

build005

Select the base operating system image source

figure 2.6: Task Sequence Wizard – Specify Product Key

build006

Normally for any deployment task sequence, you need to specify a product key. Since we are building an image here, this is not necessary. Presumably by the time you have reached the 180 day grace-period, your image must have been built ;)

figure 2.7: Task Sequence Wizard – OS Settings

build007

The same goes for the OS Settings, why specify the company name during the build already, when the company information is only relevant during deployment. Using generic information, does not cloud your image with irrelevant information, and enables you the use the images for more then one company for instance.

figure 2.8 : Task Sequence Wizard – Admin Password

build008

I always work with a specified admin password, nothing more to add here

figure 2.9: Task Sequence Wizard – Summary

build009

 

The summary displays the information we have provided before the task sequence is created.

figure 2.10: Task Sequence Wizard – Confirmation

build010

And lastly, the task sequence is created. And for the powershell fanatics among us, a script to perform these steps is provided:

Now that’s out of the way. Lets have a closer look at the Task Sequence properties.

3. Task Sequence Properties

Open up your task sequence, to modify the following settings:

!Note I will only describe the changes I’ve made to the default “standard client task sequence”

First: create the following Task Sequence Variables, stored in a group called Task Sequence Variables, prior to the “Initialize” step:

  • TSVAR: WindowsSource
  • VALUE: %DeployRoot%\Operating Systems\Windows_8.1_Enterprise_x64\sources\sxs
  • TSVAR: DoCapture
  • VALUE: YES
  • TSVAR: ComputerBackupLocation
  • VALUE: %DEPLOYROOT%\Captures
  • TSVAR: BackupFile
  • Value: W81ENTx64.wim
  • TSVAR: FinishAction
  • VALUE: SHUTDOWN

These Task Sequence Variables are set with the task sequence, and define the following actions:

WindowsSource, points to the sources\sxs folder which is needed in some cases when you want to install the .NET FX role with your Windows 8.1 installation
DoCapture, sets the flag to yes, so that at the end of your deployment the machine will be captured to a wim file
ComputerBackupLocation, determines the location where the wim file will be stored
BackupFile, specifies the name of the wim file, which sometimes may differ from what you normally want to call it, due to testing purposes
FinishAction, specifies that when the machine is finished capturing the wim file it will shutdown automatically.

By now you should have a task sequence which looks like this:

figure 3.1: Task Sequence Variables at the beginning of your task sequence

build011

this is also the moment to say: “I wish MDT Task Sequnces had a maximize button” – Which the MDT Team already came back to me explaining it’s a restriction of the current GUI / Console they are using :(

Next stop: Go to the Preinstall step, and select “Inject Drivers”. At this step, select the preconfigured selection profile: “Drivers_Virtual_VMware”

figure 3.2: Driver Selection Profile

build012

Selecting a driver profile for injecting drivers, makes sure incorrect drivers are not injected during this phase, which can cause a lot of trouble at later stages during the deployment

Next, under the “Inject Drivers” step, you will find the “Apply Patches” step. From the preconfigured selection profile, select: “Packages_Windows_8.1_x64″

figure 3.3: Packages Selection Profile

build013

Injecting packages upfront will shorten the time Windows Updates will run post-Operating System installation. This means that update files can be changed offline which is much faster then online update installation. Since there are no services running yet, no DLL’s registered, etc.

Next stop: “State Restore”, since the “Install” step only concerns applying the source wim file to the virtual machine and post install is setting up and configuring the machine for use. We can skip these steps and advance straightaway to the “State Restore” step.

Make sure to enable both “Windows Update” steps, if you want to service your image with the latest available updates! Besides this, remove the “Install Application step” and move the “Custom Tasks” step, inbetween the two Windows Update steps. Like this:

figure 3.4: State restore – Windows Updates and Custom Tasks

build014

Underneath the “Custom Tasks” step, I’ve created the following steps:

  • Install Roles and Services – Windows 8.1 – .NET Framework 3.5 and 4.5
  • Restart computer
  • Install application – Windows 8.1 Language Pack
  • New group, called: “Install Visual C++ Redistributables”
  • Install application – Visual C++ 2005 up to 2013
  • New group, called: “Install Office Suite”
  • Install application – Office 2013, incl. language packs
figure 3.5: Install Roles and Features

build015

figure 3.6: State Restore – Custom Tasks

build016

Of course these steps can be altered and can be focused on the requirements of your own organization. This is not a best practice, this is just my way of building a corporate ready reference image.

Next stop, is the end of the task sequence, right before the machine will be sysprepped and captured into a wim file, I perform a cleanup of several things:

  • Temp files and temp directories, such as logfiles that have been left over from the Visual C++ installation, the “Perflogs” and “temp” directory etc.
  • Clean up logfiles, this makes sure your logfiles are clean and empty before the machine is being captured. This makes sure that newly deployed machines don’t have a logfile full of entries back at the day the reference image was created.
figure 3.7: Cleanup phase

build017

The cleanup happens with a powershell script, which is located in the .\DeploymentShare\Scripts folder and called with a “PowerShell Script” step:

  • %ScriptRoot%\OSDCleanup.ps1

The contents of the script, are as following:

Log files can be easily cleaned by performing the following “Run Command Lines”:

  • - wevtutil cl application (for the application log)
  • - wevtutil cl security (for the security log)
  • - wevtutil cl system (for the system log)

And last but not least, before the sysprep and capture phase takes place, one final reboot of the machine to process system changes that otherwise may interfere with the sysprep process and may cause your entire task sequence to fail at this point.

figure 3.8: Reboot -just to be sure-

build018

And that is how I build my reference images mr. Jones :)

If there is any need to manually make changes before the machine is being captured, just insert the following “Run Command line” right after the Windows Updates (Post application installation) process: “cscript %ScriptRoot%\LTISuspend.wsf”

This will create a shortcut on the desktop, enabling you to make adjustments, restarting the computer and when finished making alterations, to continue the process of creating the reference image.

For more information about LTISuspend, please visit this great blog written by Michael Niehaus: “MDT 2010 New Feature #3: Suspend and resume a Lite Touch task sequence

This concludes my blog for this time. I felt I had to make it up to all of you, due to my absence the past couple of weeks :D

I’ll leave you with the content for and from this blog, which contains the screenshots used in this blog. The scripts, and installation command’s of the applications used in this blog, like visual c++, Office 2013, language packs, and many more…

zip
ReferenceImageBlogContent.zip

Untill next time my padawan automaters ;)

 

MDT – Post me your MDT Questions

Hi guys and girls, it’s been a while since I’ve written an post related to MDT or anything other useful to contribute.

At this moment my inspiration for writing blogs is on the back-burner. This is also due to the fact that writing about MDT is related to the things I encounter in my day to day activities, which are going pretty solid at this moment.  (I’m mostly relaxing, watching the World Cup Soccer, and doing other things not work related)

The’re no issues I’d encounter and had to resolve, and unfortunately no new stuff I haven’t done. So if there’s is anything you would like to know or would like to have explained. Don’t hesitate and leave your comment or remarks in the comment section.

Cheers! :)

MDT – Microsoft releases advanced how-to MDT technet articles and more…

Hi guys,

Long time since my previous post but I’m kinda in the middle of moving our stuff after we have sold our house, so I’ve been a little bit occupied at the moment. However there are some great things to report:

As you perhaps might know, TechEd North America has kicked off today, already with some fantastic new things and improvements to report.

One of them is regarding to Operating System Deployment with the Microsoft Deployment Toolkit.

As stated by other persons on the web busy with Operating System Deployment, Microsoft isn’t any longer showing how one can perform an Operating System Deployment with MDT, but it is exactly telling us what to do, and how it can be achieved.

Please see the following section on technet, and this link in particular: Create a Windows 8.1 Reference Image

Next thing is that deployment guru and MVP Johan Arwidmark known for his website: http://deploymentresearch.com now has released a weekly update for us “deployment geeks” called: “Deployment News”, you can check in on him every week on his youtube channel

I’ve taken the liberty to embed the first two episodes of Deployment News on this blog!

Deployment News – Episode 1

Deployment News – Episode 2

That I’ll be all for know, I’m working on a post regarding OS deployments with MDT on VMware, since I’ve noticed a big difference in performance between Intel E1000 and VMXNET3 NIC’s

Cheers and see you soon!

MDT – Automating IE Blocker for Windows

Today I was at a client which had a question among others about blocking the automatic installation of Internet Explorer 11.0 on clients which needed to run on Internet Explorer 8.0 only.

I was there integrating some new things in MDT when the question came from the person responsible for deploying the machines at their site. Since the company was not running WSUS and had not configured GPO’s to regulate Windows Updates. I needed to find another solution to prevent the automatic installation of any Internet Explorer version higher then 8.0.

While already made a regshot of a machine where I chose to hide the installation of Internet Explorer 9.0, 10.0 and 11.0, I struck a Microsoft link which referred to: Toolkit to Disable Automatic Delivery of Internet Explorer ##

It appears Microsoft has a toolkit, or set of scripts and files to do just that! :D

You can find the toolkits for each version here:

Internet Explorer 7.0
Internet Explorer 8.0
Internet Explorer 9.0
Internet Explorer 10.0
Internet Explorer 11.0

Basically each ‘Toolkit’, exists out of the following set of files:

  • IE##_Blocker.adm
    which holds the GPO template to regulate the exact same thing via GPO
  • IE##_Blocker.cmd
    which is an command line tool which writes specific values to the registry of the machine on which it is being executed
  • IE##_BlockerHelp.htm
    which is the help file where you may find usefull information on how to use this tool
figure 1.1: the containing files of the IE##_BlockerToolkit.exe

ie_toolkit1

Now to prevent the installation of any unwanted version of Internet Explorer during your deployment process (when your machine is already running Windows and is connected to the internet, the polling for new updates starts right away). Just incorporate the IE##_Blocker.cmd as an application with source files into MDT.

figure 1.2: General application properties of the Microsoft Internet Explorer Blocker ##

ie_toolkit2

figure 1.3: Detailed application properties of the Microsoft Internet Explorer Blocker ##

ie_toolkit3

Basically all that needs to be specified in the command line is the following: cmd /c IE##_Blocker.cmd %OSDComputerName% /B

cmd /c makes sure, that a command line is executed, IE##_Blocker.cmd speaks for itself, and since the variable %OSDComputerName% is known for the length of the deployment it can be used instead of the real hostname, and the /B switch tells the CMD to make a registry key into the registry to block the automatic installation of Internet Explorer.

When the machine is finished, a simple verification if the tool has been executed correctly will suffice:

figure 1.4: Registry key written that blocks the automatic installation of Internet Explorer

ie_toolkit4

As you can see for each version of Internet Explorer a DWORD “DoNotAllowIE##” will be written with a value of “1” under: HKLM:Software\Microsoft\Internet Explorer\Setup\##.#\

Alternatively you may choose to write this regkey yourself, automated via a script, command line etc. do it via GPO, or implement Windows Server Update Services.

Hope you find this blog usefull, and if there is anything that you would like to ask or contribute, as always don’t hesitate to leave something in the comment section. :)

Workshop – Migrating from Windows XP to Windows 7 or 8.1

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

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

netfx04

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
netfx01
figure 1.3: Using the command line
netfx03
figure 1.4: Using the “Install Roles and Feature” step

netfx02

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
netfx05
figure 1.6: Task Sequence Properties – “Install Roles and Feature” step

netfx06

Or use an application, like the script mentioned above:

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

netfx08

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 :)

 

Direct Access – Automatic GPO configuration set’s outdated and incorrect WMI filter

Just a quick post to inform you about the GPO’s that will be automatically configured when configuring Direct Access.

Today I’ve done a Server 2012 R2 Direct Access implementation, and part of this configuration is that the Direct Access Configuration Wizard will automatically create two Direct Access GPO’s in your Group Policy Management.

  • One for Servers
  • One for Clients
figure 1.1: Group Policy Management

gpo

However, the GPO for Clients is configured with a WMI filter, so that if the rules stated in the WMI filter apply, the policy will be set on the system.

figure 1.2: WMI Filters

gpo_wmi

The WMI filter containes two queries: The 1st query looks for the PCSystemType to match with the number 2, which represents an mobile device (either a laptop or tablet). The 2nd query verifies if the Operatingsystem ProductType, Version, and OperatingSystemSKU matches a number of possibilities:

as we can see here the second query, looks for machines which are: ProductType 3 (Server) which run: Version 6.2 (Windows 8) and have OperatingSystemSKU: 4 (Enterprise) or run Version 6.1 (Windows 7) and another set of SKU’s.

The odd thing here is that, although the Direct Access server runs on Windows Server 2012 R2, it configures WMI filters for Windows 8 and Windows 7, and not Windows 8.1. Also it configures in that same particular filter that the ProductType needs to match #3 which equals a server, and not a workstation (which represents the number 1)

Therefore I’ve modified this query into the following:

This way the WMI filter, filters accordingly to a Windows 8.1 Enterprise operatingsystem running on a Workstation.

Alternatively you can simplify, adapt er even completely remove the WMI query and just apply the GPO to a specific OU. However DirectAccess configures the GPO next to the default domain policy at the toplevel of the domain thus applying to all OU’s and Objects if it wasn’t for the WMI filter.

Hope this blog can be of use when configuring DirectAccess and prevent any delays when troubleshooting!

If there is anything you would like to share, please feel free to contribute in the comments

Thanks for reading! :)