The nasty Sysprep Rearm 3-step limit and working around it.

If you haven’t heard of Rearm (or SkipRearm before) then this is a tricky little thing that Microsoft has introduced into Windows Vista and Windows 7, as part of the more complex activation thingys. And it is an annoying thing. Any one image can only be sysprepped three times before you get this thing kicking in and telling you that Sysprep had a fatal error with the Rearm component. I got this today when I took what was supposed to be my do-all, good-for-everything 64 bit 7 Enterprise image. Last week I copied it to a laptop, installed the laptop-specific stuff on it, then put it back onto the VM, and today I tried to sysprep it, and got this error.

The simple answer: don’t sysprep more than you have to. Keep a master image that hasn’t been sysprepped, and make all the changes you need to it. Then make a copy of it, and sysprep that copy. Whenever you need to make changes, go back to your master that hasn’t been sysprepped, make the changes on that, copy it, sysprep it, deploy it. It just means extra work copying files around.

I suspect this is the reason that MDT Sysprep stopped working the last time I tried to use it. The imager VM had the same image on it that it always had, and it had been sysprepped a few times. Enough to hit that limit. Even though I haven’t been able to find out what error was thrown, it would have been the same count as the sysprep I tried to do today, and so it failed.

As you may recall, one of the criticisms I had of MDT and AIK was the need to keep a 32 bit VM running to allow 32 bit installations to be serviced using these tools. Well, that won’t be an issue for much longer. I think we’re about to bite the bullet and go to 64 bit Windows on everything. And then the AIK and MDT can be installed on a 64 bit server and there won’t be any issue for them. What in fact I will do is install those on my server now and set up new 64-bit-only MDT/AIK shares that they service.

But for right now, for getting those laptops out, what I am going to do? Well after some thought I decided to start building my image again from scratch, this time making the necessary copies of the VHD so that it can be done properly this time. Another thing I did today is to run the Office 2010 OCT to make an installation that automatically puts the activation key in, so we don’t have to bother about the KMS to get things installed. So pretty soon I am going to be building a new image for our computer suite that is 64 bit and then they will all be changed over to 64 bit the next time they need reimaging.

Don’t use 32 bit Windows with more than 3 GB of memory

Well the subject of this post is that everyone should be getting used to 64 bit operating systems and migrating to them. Today I saw a laptop that had 4 GB of RAM, the very latest HP that we can lease for a school in the TELA scheme. With the 32 bit edition of Windows 7 it reports it has 2.92 GB of RAM available. Now I thought this was a bit low as I knew more memory is reported for the 64 bit edition of Windows 7. I was quite shocked to discover that the latter figure is 3.8 GB. In other words a difference of around 900 MB. This is quite a significant difference.

Since as far as I know these TELA scheme HP Laptops are only available with the 32 bit edition that has been built up for the Tela scheme, we will definitely be continuing to customise our laptops with the 64 bit edition of Windows 7. We are currently looking at the best way to deploy these. As previously described in this blog I spent a lot of time learning to use MDT and while it is a very sound method it is technically complex and requires a significant amount of specialised resources to maintain. Therefore I am having a look at Native VHD deployment as a means to achieve what we want, which will be along with the use of WSIM and DISM as described in a recent series of articles. At the moment I am as a first stage loading a VHD to one of the actual laptops in order to customise it with hardware-locked applications that are normally installed by a MDT task sequence. After that it will go back onto the imaging VM for tweaking and then the sysprep for deployment. The way of doing backups with VHDs (instead of MDT based capture) is to use Microsoft’s Disk2VHD tool to capture a hard disk into a VHD file. So we could almost dispense with MDT altogether.

After the first week back at school our nVHD deployment of 30 computers in our suite has been generally successful. The main issue to date is getting Windows and Office activated; as we put in a key for Windows it still has to be manually activated, while Office should be activating against a KMS server but isn’t. I can switch Windows in future back to KMS but we still have to work out why the Office KMS server (which is a different server from the one that handles Windows 7 activations) isn’t receiving activation requests. As it happens Office will not stop working but it will just keep on warning it needs to activate so we have a bit of time to sort out that problem.

Another big task is creating 300 accounts for all our students who have individual logon accounts. We used our previous SMS to export a CSV that was hacked in Excel and then fed into a VBscript to use ADSI to set up the accounts. This year with Musac I have created a separate Access database to handle this task and that of creating the output CSV file to feed into the script. Naturally I have decided some enhancements are possible. For example with Outlook Live having a Powershell interface it should be possible to create email accounts at the same time. Further capability will be added later. The main change is that the creation of the accounts will be automated with the names of students being used and, to get around the 20 character length limit for the sAMAccountName field, the UPN name field will be set with a 3 character UPN suffix, thus each logon will be xxx.yyyyyy@zzz which is standardised for all logons. This will be the first time we have set up and distributed accounts with the expectation for using a UPN name.

It is important to note when using UPN names for accounts that Windows still sets the %USERNAME% environment variable for the user to the value of sAMAccountName. When you create home folders for your users you need to allow that the sAMAccountName is the one that is relevant to Group Policy Folder Redirection for %username% and that this still needs to be unique even if it is truncated to 20 characters for users with longer names stored in the UPN. Log in, look at the environment variables and see how many uses there are made of that sAMAccountName value. Also all our new users are getting their home drive changed to O: because a lot of computers have extra drive letters with the additional partitions for Windows 7 and nVHD as well as card readers and the like.

Deploying Native Boot VHDs [6]

We have successfully completed our first ever mass deployment of computers using the Native Boot VHD technology of Windows 7. This article carries additional detail of the deployment phase of this project.

The average transfer rate for the 15 GB VHD over the network was around 45-55 MB per minute equating to around 4-5 hours to complete the copying. The machines then had to have several more scripts run to complete the initial setup. In future updating the machines will only require the VHD file to be replaced. After rebooting the Windows Setup Wizard will appear and ask you to provide some settings such as the computer name and a username. It automatically restarts the computer again and brings up first time login. After this the only remaining step is to join the domain, this may be automated in future.

Both of the main activation tasks, the Windows 7 and Office 2010 activations can be handled by setting up a KMS server. This has not yet been done but it is one of the next tasks, being quite straightforward, and relieves you of the need to manually activate, and in Office’s case enter the product key as well.

Although the copying stage of the VHD may seem slow it is roughly equivalent to Ghost without the network congestion that multicasting produces. My experience of simultaneously ghosting multiple machines is that it rarely meets expectations, in that it is typical to require several hours or more and thus produce no real time saving at all.

D-Day

D-Day is Deployment Deadline Day. D-Day is also the day where I have had a record amount of trouble with my work computer, which has had to be restarted twice so far, firstly when Explorer crashed and wouldn’t restart, and then the second time Windows Live Writer wouldn’t load.

The process of getting from a reference image to deploying it to target machines is somewhat multi faceted. The process we use goes something like this:

• The VM is shut down
• A pre-sysprep backup of the VHD is made
• The VM is booted
• The VM is sysprepped (which can only be done live). At the end it shuts down again automatically.
• A post-sysprep backup of the VHD is made.
• The VHD is copied to another VM for offline servicing.
• DISM is used to inject the drivers in offline servicing.
• The VHD is copied to a network share to be deployed.

Bare metal deployment requires numerous steps and I have been in the process of creating and testing command or Diskpart scripts to automate as much as possible. A spare SD Card with Windows PE, scripts and tools loaded on it is set up to boot. Press the right key and the hardware boot menu comes up, then select the SD Card to boot from it. First task was a simple Diskpart script to create the three partitions needed on the HDD. So what was done on Wednesday afternoon was to boot every new PC to this card and run this script against Diskpart to initialise and format the disk. Then we had two days off for our annual staff retreat and I came in to work again today, Saturday.

Looking at the rest of what was needed I got started with a script that mapped a network driver letter to the share on the file server to allow the VHD to be copied over the network instead of an external HDD. This is all fine but the problem that showed up is that network drivers for this particular hardware platform are not included in Windows PE. Some time ago I wrote about learning how to inject drivers into Windows PE 2.0. As this is PE 3.0 the process is slightly different and is basically the same as injecting them into a Windows boot image: using DISM, first step is to use DISM to mount the boot.wim file (you don’t need to use ImageX to do this anymore). But as we don’t need or want the 1.4 GB of images that the VHD got, I just gave it the path to the network drivers folder and it injected two drivers only taking about 4 MB. After all changes are completed use DISM to commit changes to the WIM. Then this was copied over the existing boot.wim folder on the SD card and away we went. The Net Use command can be scripted to specify both username and password in the command line so that has been handled OK.

My next act was to attempt to fully script the process of running BCDBoot to copy the boot files and set up the BCD in the system partitition. This has run into snags because as soon as I tried to get Diskpart to set up the partition it threw various errors. In the script I got it to attach the VHD and assign it a drive letter. It objected to the select vol that it was given and apparently therefore could not assign the drive letter or do any of the other commands except detach the VDisk at the end. But when I ran diskpart with the script that attaches and assigns, the volume was there as expected at the end so I don’t see why all the other errors occurred. At this point I decided it was just easier to put all the scripts and tools onto Y drive (the network install share I had set up earlier) than mucking around with the SD card all the time, and this lets me make some boot CDs as well to speed things up for deployment.

Also in the deployment tools documentation for Windows 7 AIK is detailed instructions on how to install RE and customise it to specific requirements. A future project is to add the RE to the system partition so that a boot media isn’t needed to boot up the machines for reinstallation in future. I’ll look into it sometime when I get some free time.

Basically at this point all the machines are copying the image all at once and network performance seems to be extremely slow. This means the machines will probably take half the night to complete copying the 15 GB file. I’ll come back in the morning to finish working on them.

File and registry virtualisation in Windows 7 and Vista

File and registry virtualisation in Windows 7 and Vista is a new technology that deals with the requirement of some applications to be able to write data in locations where the user does not have access permissions, as well as the user inadvertently choosing these locations. The latter functionality in particular can trip you or your users up and perhaps it is better to educate your users about the limitations of saving their data into “system reserved” locations.

For example C:\Program Files (or the equivalent for different boot drive letters) is such a location and you may find (as I did this week) that attempting to save data files from an application into this directory will result in the file “disappearing” or “appearing”. In this case I found I could see a view of the file only in the Save dialog of the exact application that created it. Explorer wouldn’t display the file at all.

After looking into this I found a resource on MSDN that details this process. In this case the file is being written into a subdirectory of C:\Users\<username>\AppData\Local\VirtualStore and actually did exist in that location when I checked. The point of what was in its original location is that it looked like a file, not a shortcut to a file that was stored somewhere else.

These technologies appear to be targeted at legacy applications in that they only apply to 32 bit apps, not 64 bit for example. As such they fit in with applications that wouldn’t meet the current Windows Logo cert requirements.