ConfigMgr and Windows To Go – Lessons Learned

ConfigMgr and Windows To Go – Lessons Learned

(Originally posted 3/4/2014. Reposted for reference)

 

For Microsoft customers with Enterprise Agreements, the Windows To Go option is becoming an increasingly useful approach to the Bring Your Own Device (BYOD) paradigm.  All you need is a certified USB stick and a host machine that meets the Win7/8 specs and you can take your workspace virtually anywhere.

It’s reasonable to assume that most IT organizations will want at least some measure of control over and customization of the Windows 8.x instance being placed on the Windows To Go device, and while it’s certainly possible to script out a relatively static Windows 8.x build for mass production on a USB duplicator, most customers that already use ConfigMgr 2012 to deploy and maintain Windows 8.x on the standard platform will want to use the same processes to manage the Windows To Go devices.  Fortunately, Microsoft provides a fully supported means of provisioning Windows To Go devices with ConfigMgr 2012.  The basic premise is to create a prestaged media image of the OSD Task Sequence and apply that media image to the USB key using the Windows To Go Creator utility (wtgcreator.exe). 

Having implemented this solution in a production environment, I wanted to share a few lessons learned during the development of this process:

Content – A prestaged media image is not the same as stand alone media; it still requires connectivity to the ConfigMgr environment during imaging, even if you prestage every referenced package in the Task Sequence.  You need to be able to talk to the Management Point, and you presumably will want to be on the network to join the domain.

Prestaged Media Image – Building the prestaged media image, applying that image to the USB key using the wtgcreator.exe utility, and booting to the USB key to run the Task Sequence and build out the OS.  Building the prestaged media image only needs to be done if you make changes to your core image, assigned boot image, or to any referenced content that you want to have prestaged in the cache when the Task Sequence runs.  A bigger prestaged media image takes longer to apply to the USB key but reduces the time the Task Sequence takes to run (at the cost of flexibility).  The same considerations you apply to the build and capture of your core image apply to your prestaged media image.

Note – It’s highly recommended you disable realtime protection for any antivirus client while creating the prestaged media image.  Antivirus clients have a nasty habit of locking files in the staging directory while the image file is being generated, and the result is a failure of the wizard to complete the image file.

Task Sequence – There is really no reason you can’t use the same Task Sequence to deploy Windows 8.1 for both Windows To Go and standard workstations.  The _SMSTSWTG Task Sequence variable provides a simple boolean value to use as a condition for tasks.

Windows 8.x – One major issue encountered early in the development process had to do with Windows 8.1 setup.  Specifically, if an available wireless network is detected, by default Windows setup will prompt to connect to a wireless network to complete setup online.  This functionality actually goes back to Windows 7, but this is the first time I’ve actually seen it during OSD in quite some time so I figured I’d include it.


Sample image from http://seanelvidge.com/2012/10/my-first-hour-with-windows-8-part-1/

This is obviously an impediment to any notion of an automated imaging process, so you’ll want to create/modify the unattend.xml file and set the HideWirelessSetupInOOBE value to true in the oobeSystem pass.

Driver Management – This is perhaps the biggest challenge for end user experience.  By design, these devices can be plugged into nearly any business or consumer hardware out there, and while Windows 8.1 has a fairly robust driver store for general network and display adapters there are bound to be situations requiring additional driver support.  Suffice it to say, standard ConfigMgr driver management only applies to the hardware upon which the WTG device is provisioned; it doesn’t do anything for subsequent host hardware.  I will detail an approach to this in a follow-up post.

Security – Because of its mobile nature, Windows To Go is designed to use BitLocker without leveraging the TPM.  A special utility (osdbitlocker_wtg.exe) is provided to provision the drive for BitLocker encryption.  As part of the command line, an initial passphrase is required. This passphrase is set using the OSDBitLockerPIN Task Sequence variable. You can set the Task Sequence variable to whatever you want…but the requirement is for a numeric PIN.  Put an alphanumeric value in for that variable and you’re going to get a failure when osdbitlocker_wtg.exe runs.

ConfigMgr Database – One major concern any experienced ConfigMgr admin would immediately have is how ConfigMgr can tell the a WTG device from the record for the host machine (assuming obviously that the host machine is itself a managed device).  As far as ConfigMgr goes, it turns out they have anticipated this issue and accounted for it.  I did a quick test using a Windows 7 host machine (“PM10002”) and a Windows To Go device built on the same hardware (“WTG-TEST”).  The result was recognition of a different AD SID and a different ConfigMgr Unique ID (GUID) despite having the same MAC address:

An additional key property of the record helps ConfigMgr keep things straight: the Portable Operating System property.

This further marks the device out as a Windows To Go device, allowing it to be treated accordingly.  The result is that despite showing some duplication of core items such as MAC address, ConfigMgr is able to maintain distinct records for both the WTG and host hardware without mistakenly marking records as obsolete or disrupting normal functionality. 

Once caveat however is PXE.  Because PXE functionality is tied specifically to MAC address, there is no way to distinguish between the two records in the database.  The result can be inconsistent behavior for PXE booting, depending on the scenario.

There were plenty of other minor issues encountered along the way, but the above list should hopefully help save you some time and headaches should you head down this path.

 

Chrysanth WebStory WebStory: Get a super Twitter client!

Leave a Reply

Your email address will not be published. Required fields are marked *