Migrating to Windows 7 from XP with OS Specific Desktop Policy

This article is mainly focused on the issues which come with the migration for the user experience, as opposed to the task of getting new hardware or upgrading older hardware and installing the operating system on it. There are challenges which come with differences in the operating systems and the configuration settings that apply to them. This is especially true if you are using Group Policy or Registry settings to lock down desktops for certain classes of users, as would be quite common in a school environment with students for example.

Whilst it is tempting to think some of the differences can be dealt with by using loopback policy to apply OS specific settings only to machines which have a specific OS, this brings other complications, mainly when a user with administrative rights logs on to a computer and finds that the same lockdowns are applied to their account. I would highly recommend from experience that loopback policy for desktop experience settings is only used as a stopgap measure, until such a time as all of your computers, or as much of them as possible, can be transitioned to as much commonality in these settings as possible, so that the majority of them can be taken out of loopback policies and put back into the per-user section of the policy tree where they don’t affect all your users the same.

For example, we used to redirect the Start menu in Windows XP so that it displayed a pre configured set of icons. In fact, it was redirected to the All Users Start Menu, which in turn was configured with exactly the set of icons we wanted the user to have access to. This immediately causes problems in Windows 7 because the equivalent is stored in a physically different path. I decided ultimately to stop using this redirection completely in Windows 7. This means at least for the moment that I have to find a way of differentiating between Windows 7 and Windows XP computers. In the short term I can immediately do this using a loopback policy. However that will also limit me if I log on to one of these computers as an administrative user because that policy ends up being applied to every user the same. In the longer term therefore I must be able to take as many as possible of the policy settings out of loopback and into a user specific policy.

If I have a browse through my Windows 7 policy file then there aren’t that many settings that are Windows 7 specific. So it wouldn’t really take long to weed out the ones that only apply to 7 and loopback only these specific settings, with everything else into a user specific policy, and then make life simpler for people administering these computers. I wouldn’t say it will totally fix the problems and it is possible we would look at other means of making these computers administrable. One option is to set up local administrative accounts as these are not subjected to the limitations of group policy.

MDT & Intel Arrrrrgggghhhh!

Last year I spent a great deal of time learning how to use MDT. And it seemed like a good system. It worked well and there were only a few hiccups with it.

Suddenly this year it is proving to be a great deal of trouble and I’m wondering why I bothered with it.

Firstly, I made an effort to get a capture done from a VM image. There were no problems getting that capture done before. But now, for no apparent reason, MDT starts refusing the capture, and when it’s MDT, the reasons won’t be that obvious; the error messages you get will be meaningless like “CloneTag” or something, and you won’t be able to work out just what is going on without a lot more work.

The second instance is this year when I have started to work on laptops, and for good measure I loaded the carefully crafted and fully tested laptop image onto three new laptops. These types of laptops never gave us any trouble before loading this MDT image. But now, all three of them have inexplicably crashed during the MDT deployment process, leaving me with a pile of work to get them completed because half the task sequence hasn’t been completed.

At the moment I am not in a place where I have got time to poke around trying to find out why MDT has failed. I expected this deployment to go smoothly. It hasn’t. It is very time sensitive and it will have to be completed manually with a lot of extra work involved.

With all the amount of trouble that it can be with MDT at times like this I am really seriously considering just going over to native VHD deployment for all of our Windows 7 computers. Then we will only need MDT to simplify some of the management and I won’t be doing captures or deployments with it.

The second MDT (and AIK for that matter) annoyance is the design limitations that means a 64 bit installation (which is made on a 64 bit platform i.e. Windows 7 or Windows Server 64 bit edition) can only service installations that are for 64 bit target platforms. To be able to service both 64 bit and 32 bit installations, the 32 bit version of MDT (which can only be installed on a 32 bit edition of Windows) has to be installed. So this means that the computer that MDT and AIK is installed on has to be running a 32 bit edition of Windows. And since 2008R2 came out it is 64 bit only. Now the importance of this is that I wanted to have my Setup share a local drive letter on the MDT/AIK VM. This means it can only be running a Desktop edition of Windows and thus there is the infamous 10 connection limit. So in reality this would limit access to that share to 10 connections. Sometimes when you see these limitations you wonder if MS really has a clue what people use these packages for or they just must think people are made of money so they can fork out for another license for a machine that runs that specific edition of Windows (and another hardware box if that is what is needed). For me I have a Enterprise server license that will let me run this VM as part of the license but it still ends up with that 10 connection license to run a desktop edition of Windows.

The other annoyance is the server rail kit for Intel 5295 chassis. We ordered a rack that is 700 mm deep, thinking this would be plenty, after all the chassis is about 500 mm deep. But this very poorly designed Intel product will not fit in a chassis that is less than that size, even though it allows a huge gap at the back of the server, the rails require minimum of 700 mm depth in the chassis to fit in, and even at that you should really be looking at 800 mm chassis depth because the front door of your cabinet will not close. But of course in the minimum size 12RU chassis that we purchased, it is not available in more than 700 mm depth. Not until you go to 22RU and that is much too big and expensive.

So while the rack manufacturer’s product is good, Intel has really let us down with this silly very poor design. I went all over Intel’s website and looking at other websites to see what information is there about this design limitation (the product is called APP3RACKIT) and there is NO information. Absolutely NONE at all. If we can’t get the kit returned we are going to end up having to try to resell it, and we’ll end up losing money on it.

Deploying Native Boot VHDs [5]

The steps for deploying a native VHD boot are the same as if you are using a third party imaging solution, such as Ghost. Effectively, copying a VHD is a kind of third party imaging solution, in that it is not a directly supported deployment scenario for the Microsoft Deployment Toolkit, its predecessor Business Desktop Deployment, Windows Deployment Services, or System Center Config Manager. Ideally at least MDT would have task sequences added to automate the required steps, namely Sysprep and DISM.

Hence having used a third party imaging  scheme before, it took me little effort to get going with Native VHD deployment as we originally developed a Vista image using Ghost along with WSIM and Sysprep. The stage I didn’t get around to at that time was DISM, or possibly it was different under Vista. This time I have to use it because the network card driver for our particular target platform is one of those which is not included with Windows 7, and thus, out of the box, Windows 7 will not be able to search for drivers for the other hardware.

When we developed our first Vista image I had a buck both ways and also ImageX’d the PC so that I had this image available in case Ghost didn’t work out. As it happens, Native VHD deployment is like ImageX except that the stage of physically imaging the hard disk and reloading that image to target PCs is replaced by copying the VHD file to target PCs. ImageX has the advantage over Ghost of being file-based rather than disk-based, and various other things it can do like having multiple images stored efficiently in one WIM file due to single instanced storage. Native VHD on the other hand is like a partition, due to the fact that a VHD file is a virtual hard disk. When you deploy it, multiple VHDs can represent multiple partitions on the target system. Its strength lies in the fact that you don’t have to physically define and maintain partitions on the target computer’s hard disk, especially if you have more than one. Re imaging the target is as easy as booting up to a Windows PE command prompt and copying the new VHD file over the old.

Once you have sysprepped your VM with your deployment VHD attached to it (as this is an online step), the final step before deployment to target platforms is to perform offline servicing. This is what DISM does. Its name stands for Deployment Image Servicing and Management, and like other tools that you use in a Windows PE command prompt, such as Diskpart, it has been extended for Windows 7 to work with native boot VHD files as well as WIMs. Supposedly you can pass Dism an unattend.xml file that you set up with WSIM that has a driver path specified in the [2 offlineServicing] section. I wasn’t able to make this work, so I just copied the drivers to the local HDD and used the Add-Driver option instead. The use of DISM is pretty straightforward, although since it cannot work over network paths, you may need to copy your image file somewhere locally first (I recommend you also copy your unattend.xml file to the same directory):

• Start the Deployment Tools Command Prompt by right clicking it and choosing “Run as administrator”.
• Browse to the directory which contains the image you are performing offline servicing on.
• You will need to use Diskpart first in order to map the  VHD to a drive letter.
  • Start Diskpart
  • At the Diskpart prompt, enter select vdisk file=<path_to_vhd>
  • Enter attach vdisk
  • Enter list vol to see if diskpart has assigned a drive letter to the file. If not, use the assign command to assign a drive letter. In this case drive letter F has been assigned. Typically you will find two extra drive letters automatically assigned: one for the boot drive partition, and one for the system partition.
  • Enter exit to quit Diskpart
• Type in a command which starts with dism /image:<drive_path> followed by a servicing command.
  • For example: dism /image:F:\ /get-drivers will list the drivers already present.
  • To add drivers off a local path such as C:\dism, enter a command like dism /image:F:\ /Add-Driver /Driver:C:\dism\Intel /recurse (Intel is where I have copied the driver files to).
  • After doing this you can use something like dism /image:F:\ /get-drivers to see what was installed.
  • The first time I tried this 198 driver packages were added to the image. YMMV – You may wish to trim down your driver folders (These were only four devices in total). This number of drivers added 1.2 gigabytes (!) to the image size.
• After using DISM, detach your VHD using more Diskpart commands before you copy it to the target platform.
  • Start Diskpart
  • Enter select vdisk file=<path_to_vhd> (or press the up and down arrows to recall the command that you entered when you used Diskpart earlier in the session)
  • Enter detach vdisk
  • Enter exit to quit Diskpart
• Deploy and test. (I copied the VHD straight over the network from C:\Dism on my MDT VM)

Eventually AIK is going to get installed on my tech server VM where all the setup files are local so that I don’t have to copy the files around each time I’m using DISM.

We have more or less finalised the process of imaging for our computers now. There is just a bit more tweaking and customising the image to get it all working properly before we deploy soon.

Deploying Native Boot VHDs [4]

The first time startup with the sysprepped VHD went reasonably well until an error message was displayed:

After that the system was stuck in an endless loop of displaying messages which basically said “Windows could not complete the installation. To install Windows on this computer, restart the installation”. Then the system would restart and, you guessed it, the same message was displayed again.

Now our first thought might be that that isn’t where we originally put our unattend.xml file and that is probably true, however it does get copied here. So we need to get the log files that are created by the installation which will tell us what problems have caused this error. To do this I need to boot my target system into Windows PE again and examine the VHD that way. We can do this by using Diskpart to attach the VHD and assign a drive letter to it. Then I can browse it directly to find the log files, which in this case are in c:\windows\panther\unattendgc. It is recommended to detach the VHD before quitting, using Diskpart commands again. After I checked the log files I found a couple of issues which have resulted in corrections being made to the listed settings in Part 3 of this article series. Part 3 has been updated with these corrections. I fixed up the answer file using WSIM again.

I’ve also decided I will set up a custom folder for DISM for OOB drivers for this image because it’s pretty easy to do and will simplify the process of injection by limiting the number of drivers that are injected to those which are needed for this image. So that stage will require the drivers being copied to a custom folder in the AIK share and then the path in the answer file will be changed. With the changes to the answer file that also needs to be recopied to the VM before reprepping it.

There is one software package I have not been able to install onto the VM because it is the software for the DVD writer and it won’t install if the drive is not present. This means that final customisation of the VHD will require it being deployed to the target platform so this will be done before it gets sysprepped. This of course means a target platform has to be available at some stage of the image development process. I will have to see how I can make this work out in practice. It was something I had hoped to avoid because obviously the primary benefit of using a VM to build up images is that you don’t need access to a target platform until deployment. However in practice this should be OK, just a little inconvenient. After this convoluted process of getting the VHD onto the target and then back again, the software installation was completed. The reprep was then started. This went more or less as expected. I am currently testing and finalising settings and preparing to DISM the image.

Deploying Native Boot VHDs [3]

OK so we start up Windows System Image Manager (WSIM) and create a deployment share, which is in my Setup share (where all the other setup files and images are stored). AIK uses something similar to MDT; as far as I can tell, MDT adds a few folders to a basic AIK deployment share. I’ve started up a new one rather than trying to use one of my MDT shares. Next, select an image – I went into MDT shares and selected the Windows 7 Ent x86 image. Then create an answer file and do stuff to it.

I think we need stuff in the answer file for the following passes:

• offlineServicing – DSIM uses this to inject the drivers. We “insert the driver path” to this pass and then later on we run DSIM and pass the answer file to it. This step should inject our custom platform drivers. Since MDT doesn’t actually create physical subfolders when you tell it to “create a folder” under “Drivers” we are just going to give it the OOBD folder and see what happens. That will give it a lot of drivers.
• specialize – this is where many of the useful custom settings are applied when the platform is rebooted after a sysprep with the /generalize switch. Essentially this is where some of the settings are put for an unattended installation.
• generalize – this specifies settings for a sysprep which is using this switch.
• oobeSystem – other settings for unattended installation.

Inserting the driver path is done from the menus in WISM. The other components are inserted by browsing the list of components under the image that I selected, and right clicking gives you the option to insert the component to the appropriate pass of the answer file.

Once the answer file is complete it would be copied into C:\Windows\System32\sysprep on the target platform. Sysprep.exe is there already. Then run sysprep and give it the answer file and tell it to shut down the VM. Then copy the VHD to somewhere convenient. Run DISM and pass it the answer file and it will go get the drivers and copy them into the image. Then deploy, hopefully.

After this point specifying those components is the tricky part, like which ones do you need? These are the ones I’m trying out first:

• Microsoft-Windows-International-Core [4 specialize]: this enables us to specify our specific regional settings. That’s the stuff that Windows Setup would normally ask us for, so it makes sense to put it into an answer file.
  • InputLocale: en-US
  • SystemLocale: en-US
  • UILanguage: en-US (en-NZ is not the correct value for this field)
  • UILanguageFallback: en-US
  • UserLocale: en-NZ
• Microsoft-Windows-Shell-Setup [7 oobeSystem]: various settings for first time setup. N.B. Some of these settings are only available for [7 oobeSystem] pass and some are only available for [4 specialize] pass.
  • Autologon
    • Username: Administrator (this enables the default Administrator account)
    • Enabled: True (this doesn’t get set by default and will cause an error if left blank. Needs to be True to ensure the account is enabled.)
    • LogonCount: 1 (a workaround to make sure the administrator account gets enabled)
  • OOBE
    • NetworkLocation: Work
    • ProtectYourPC: 1
    • HideEULAPage: True (hide the page asking the user to accept license)
    • HideWirelessSetupInOOBE: True (set this one to make sure it doesn’t pop up)
  • ProductKey: Your Windows 7 MAK (this setting can only be entered for the 4 specialize pass)
  • RegisteredOrganization: Name of organisation
  • RegisteredUser: Name of user
  • ShowWindowsLive: False
  • TimeZone: New Zealand Standard Time
  • UserAccounts
    • AdministratorPassword: whatever (the account must be enabled with Autologon\Username as above)
• Microsoft-Windows-UnattendedJoin [4 specialize]: Enables an unattended domain join. This is useful even if you let the system choose a random name. At the moment we’ll leave this off and join manually after we’ve customised the computer name manually.

There are several corrections in the above which are underlined, these were found necessary to fix issues.

And that’s about it. Because the VHD already contains the OS we don’t need to bother about Windows PE pass settings. Save the answer file and then do the sysprep. I use the following command line in a command script file to automate sysprep:

• sysprep.exe /shutdown /generalize /oobe /unattend:c:\windows\system32\sysprep\unattend.xml

To do this put sysprep.cmd (the command script containing this line) and unattend.xml in the sysprep folder shown in the above command, start up the virtual machine then browse to that folder in Explorer and double click sysprep.cmd. You will then see a dialog box that shows a moving progress bar as Sysprep does its thing. Eventually if you’re still watching, you will see a “Sysprep_succeeded.tag” file generated in the directory and then your VM will automatically shut down.

The next step is to run DISM to inject the drivers. DISM works offline whereas Sysprep works online. This means that my next step is to make another copy of my VHD (the post sysprepped one) and then call up DISM to inject drivers into that particular VHD instance. However right now I’m going to skip that and instead deploy the sysprepped but not yet DISMed VHD to my target platform in order to test out the unattend settings.

Before doing a sysprep stage I recommend you shut down your VM and make a backup copy of your VHD. I keep copies of the VHD both pre and post sysprep. After making the pre copy, start the VM up again before sysprepping it live. When the VM shuts itself down, make the post copy VHD for DISMing before it goes to deployment. Restore your pre copy to the VM before you do any more work with it.

Deploying Native Boot VHDs [2]

My first test was to set up the target computer with its hard disk and boot environment and copy the VHD directly from the VM to the target and then boot. This was successful; the main issues being the missing Sysprep and driver injection stages. Since then, thinking about it overnight, I have decided I will have to learn how to use WSIM, Windows 7 Sysprep and DISM, all of which MDT nicely isolates you from. This is because MDT doesn’t have a deployment scenario for the situation we are using. Using the three tools mentioned above is what MDT encapsulates, but in a different way. The normal basic steps of deployment which I learned with Vista are:

1. Make a Unattend file using WSIM
2. Sysprep your reference system passing it the Unattend file
3. Image it by using ImageX to perform the capture.

And now, with VHDs, we can replace the third step with DISM to inject the drivers. Then we copy the VHD for deployment. Deploy it to the target platform and when that platform is booted it will automatically set itself up with the Unattended settings. The advantage of this overall is that we don’t need to have a separate imaging stage to copy what is on the VHD into a wim file, and we don’t have to have a separate stage of loading the image onto the target platform. All we have to do is simple copying of the VHD file to the target platform, so it saves a lot of time. In my test run yesterday it took about seven minutes to copy a 13 GB VHD off an external hard disk to the computer. Basically this is what MDT leverages, but in a different way. MDT splits up the setup passes so that some of them happen at the time of doing Sysprep and Capture, and some of them happen at the time of applying the Deployment task sequence. But if you do it so that you specified your unattend file and everything before you deploy the VHD, then it all gets done automatically when the VHD is booted up for the first time.

Let’s have a look in depth then at the old system like Ghost of copying a whole hard disk and that being the image of the machine. The main advantage of this is that it is very easy to set up and deploy. However since you still need to Sysprep before capture, you will still need to learn how to use the WSIM and Sysprep tools. Therefore you haven’t saved much. The main issue is that once you have captured with Ghost into its own format, servicing those images becomes the issue. The usual story is to deploy to a reference platform, service, sysprep, capture, and you have to have a reference platform to do it. The other big Ghost limitation is that it is tied to a single HAL and that means images are locked to that platform pretty much.

On the other hand we will be starting with a VHD that is attached to a VM. We build and maintain it on that VM. We then take a simple copy of that VHD, run Sysprep over it with our unattend.xml file that we have already built. We then use DISM to inject the drivers to it. It is then ready to deploy. We can still service the VHD offline at that point before it’s deployed, no matter how much is needed to it. Or we can go back to our VHD attached to the VM and service it live there then do the Sysprep and DISM stages again. At no stage is it necessary to recapture and at no stage is it necessary to deploy the captured image by special software. It is just a matter of copying the VHD to the target platform. This is an advantage even over WIMs which is why the native boot VHD capability is such an underrated feature of Windows 7.

Facebook food for thought

Here’s some hard thoughts about FB.

I’ve been on FB for over four months and I have chosen to have only 20 friends. These friends are real life friends. People that I meet and talk with regularly for the most part. I don’t post much on FB. I reserve it for serious stuff. I like to think through what FB is really useful for and not waste more time on it than I really need to. I’ve changed the privacy settings to very restrictive ones that hide as much personal information as possible. My FB profile won’t tell you too much about me. Not like some of my friends who tell you who they are married to and their birthdate and the names of their kids.

So here are a couple of articles on the Net to have a serious read and think about if you are a serious FB fan:

• http://www.nzherald.co.nz/lifestyle/news/article.cfm?c_id=6&objectid=10665586
• http://www.nzherald.co.nz/relationships/news/article.cfm?c_id=41&objectid=10700662

For me, I think FB is mostly about an email replacement. That’s about it for the moment. Maybe sometime later I’ll think of other ways that FB could be useful to me.

Deploying Native Boot VHDs [1]

Having discussed this lengthily in a previous series of posts it’s time to start working on a real world implementation – and by the way, happy new year!

The following steps should be those needed to set up a Native Boot VHD from scratch:

1. Develop the image
   1. Create a new VHD and attach it to a virtual machine
   2. Deploy the OS and all required applications
   3. Sysprep the VHD by running a custom sysprep-only task from MDT
   4. After the VM is shutdown, use DISM to service the VHD by injecting the drivers to it
   5. Copy the VHD to a portable hard disk or similar means of distribution media
2. Configure the target machine
   1. Boot the target machine in Windows PE using bootable media.
      1. Find out if the recovery option is installable in the standard boot partition so that F8 can be pressed to boot off the HDD instead of needing a boot disk in subsequent Windows PE tasks.
   2. Run a few Windows PE commands to create a boot partition and create the required entries in the BCD
3. Deploy the VHD
   1. Copy the VHD file to the target hard disk
   2. Reboot the machine
   3. Enter any initialisation data needed when Windows 7 boots off the VHD
4. Update the VHD
   1. If the VHD needs to be updated follow the sequence again but it should just be a case of replacing the existing VHD file with a new one once the machine has been booted into Windows PE. To replace an existing VHD a command may be needed to dismount the existing VHD.

There are a few special considerations. One is that we want a second VHD that is used by the user as scratch space shared by all users (video editing for example). A special command can be used to create this the first time the system is set up. Another consideration is whether to convert the boot VHD from dynamic to fixed size after it is copied. Keeping it dynamic up until copying reduces the size massively. Fixed is recommended for best performance in a native boot VHD deployment. If it is dynamic it gets automatically expanded to its maximum size at boot anyway but this will lengthen the boot time.

Right now I am working on some of the steps in each group but not through all of them. I am about to get my target test platform set up so that I can be ready to check out some of the configuration work before I get onto finishing preparing the image for it.

The overall aim is to have a deployment system that is simpler to use than MDT for deployment. MDT is a good deployment system provided that you have the necessary training and means to resolve issues with it. If your deployment is just to a few machines and your staff are not specifically MDT savvy but they know how to do stuff in Windows PE then it’s easier that way and you eliminate the extra steps of doing a capture each time your deployment image is changed.

In the next part I will look in more detail at the nitty gritty of these steps above and hopefully I will have deployed to my target test system.

Previous series:

• http://nzschooltech.blogspot.com/2010/11/native-boot-vhds-and-mdt.html
• http://nzschooltech.blogspot.com/2010/11/native-boot-vhds-and-mdt-2.html
• http://nzschooltech.blogspot.com/2010/11/native-boot-vhds-and-mdt-3.html
• http://nzschooltech.blogspot.com/2010/11/native-boot-vhds-and-mdt-4.html