Deploying Windows 7 Part 2

This is the second instalment documenting my adventures with deploying a Windows 7 SOE.

In this post I’m going to lay out how I’ve built my development environment and get our source image machine booted. I built this environment from scratch in VMware Workstation so that it remains clean, portable and independent of any other infrastructure in my other labs.

Each time you see a mention of a file in this post it should be a hyperlink to the file. I should mention that some of my config is locale centric and may make some other assumptions that are not relevant to your environment.

If anything in this post isn’t clear, or is wrong please let me know in the comments!

Note: I take no responsibility for this stuff destroying your kit, your data or your life. I run this all in a separate virtual lab and so should you. You really should read all the files before you run them.

My Hardware

I run this entire lab on my Dell Latitude E6500. I store all the VMs on an external 500GB powered E-SATA hard drive.

I have a USB network interface so that I can have two wired connections to my laptop, one for this lab and one for the laptop’s own OS to use.

Install VMware Workstation 7.1

The only significant thing you need to do with the VMware is to open the VMware Virtual Network Editor remove the lab LAN physical NIC from the default bridge and bridge it to VMnet3. Remove TCP/IP protocols from the physical NIC in the lab host so that it can’t see the lab LAN.

Build the Server

This is a VM running Windows Server 2008R2.

Its virtual hardware should be configured as such-

1. Two network interfaces

2. 2GB of RAM

3. 50GB C: and 150GB E:

4. The virtual CD-ROM is D:

5. Name the machine “buildsvr”.

One interface connected to the NAT network (VMnet8) and configures to use DHCP and the other interface bridged to the host NIC that connects to your lab LAN (VMnet3) with a fixed IP.

I used 192.168.14.1/24 as my build LAN.

Set the administrator password to “BuildAdmin01”. Set the password to never expire.

Then install the following additional services and settings-

a. Active Directory (buildlab.local)

b. DNS

c. DHCP Server (use a private subnet that you don’t use elsewhere and make the build server the gateway and DNS server). Bind it to the build LAN.

d. Create an account “deploy” with the password “Deploy1234”. Set the password to never expire

e. Install RRAS and configure it to NAT connections from the LAB LAN to the interface that connects to the host NAT network. This will allow machines in the LAB to get to the internet to install Windows Updates.

f. Configure DNS on buildsvr so that it will resolve queries for internet names.

g. Install the Windows 7 AIK

h. Create a ‘deploy’ on E: (the 150GB disk) and share it as ‘deploy’. Edit the permissions so that Users have Modify access to the folder and R/W on the share.

Note: the ‘e:\deploy’ folder and share is the home for everything else we’re going to do. All the files provided should be put in there. At the end of this series I’ll put up a Zip file of the basic structure so that you can just extract it into Deploy and get a good framework to start with. I’m not doing this now as some of these files are currently specialised for my employer and I’m editing and posting them as I go at this stage.

Prepare the Images

1. Insert the Windows 7 Enterprise x86 source media into D:, either by mounting an ISO or patching the physical drive through to the VM.

2. Open the “Deployment Tools Command Prompt” (this is part of the AIK)

Note: The next few scripts call DISM which will mount some files and make some changes. This will fail if any files are open in the mounts. Explorer has a tendency to index the folders if you have any folders open so you should close any Explorer windows before you run these scripts from the Deployment Tools Command Prompt.

i. Run “01 copy ms wims and inject pe drivers.bat” – there is no error handling, check the output thoroughly. Read the batch file for details.

ii. This copies the Boot and Install WIMs from the DVD and injects the Dell PE driver bundle into them. Note the the Boot.wim has two partitions.

iii. We will use these WIMs to deploy our initial copy of Windows using WDS.

iv. Run “02 make WDS PE image.cmd” – there is no error handling, check the output thoroughly. Read the batch file for details.

v. This calls copype.cmd (which is part of the AIK) to copy the WinPE image from the AIK folders into a working folder and then mounts the resulting WIM and injects the drivers and some extra PE packages. We will use this PE to capture and deploy our image.

Note: The only reason to inject the drivers at this stage is to do source installations to newer Dell hardware directly. The virtual machine boots using the drivers that Microsoft ships with Windows 7. The Dell PE drivers have also been sufficient for any HP models I’ve seen so far.

Install WDS

1. Set the Remote Install folder to E:\RemoteInstall

2. Use the Windows 7 DVD images for the initial images

3. Open the WDS console

4. Add a boot image “E:\deploy\Win7 x86 Ent DVD\boot.wim” with the name and description “Microsoft Windows Setup (x86) w. Dell Drivers”

5. Add a boot image “E:\wds_winpe_x86\winpe.wim” with the name and description “Microsoft Windows PE (x86) w. Dell Drivers”

6. Add an Install image “E:\deploy\Win7 x86 Ent DVD\install.wim” with the name and description “Windows 7 ENTERPRISE w. Dell Drivers”

7. Select Properties on “Windows 7 ENTERPRISE w. Dell Drivers” and set the unattended install file to “e:\deploy\ImageUnattend.xml” and close the dialog

8. Copy “E:\deploy\WDSUnattend.xml” to “E:\RemoteInstall\WDSUnattend.xml”

9. Select the properties of the WDS server, click on the Client tab and tick “Enable unattended installation” click brows and select “E:\RemoteInstall\WDSUnattend.xml”

10. Tick the “Do not join domain” box and close the dialog

11. Close the WDS console

Wait up, what’s in those XMLs?

The two XML files mentioned above are pretty basic and it should be fairly obvious what they do.

To edit the files you should use the Windows System Image Manager that’s part of the AIK rather than just opening them in notepad. To get a better understanding of what the various sections of the XML mean you can just have a bit of a Bingle around the internet- but the Microsoft documentation I’ve already linked to above is quite good.

WDSUnattend.xml only configures the initial Windows PE environment and the execution of Setup.exe within that environment.

ImageUnattend.xml configures the deployment itself. Other than setting the locale and other options required for a hands-free installation it configured the machine to pull down any .Inf drivers from a share and boot into Audit Mode. Once in audit mode it runs auditbatch.bat. auditbatch.bat maps Z: back to the deployment folder ready for you to run any other scripts you need to customise your source machine.

Reminder: Please edit the files to suit your environment, or at least be familiar with the assumptions my files are making for the installation.

Create the Source machine and boot it into it

1. Create a new VM (2GB/40GB) and connect it to the lab LAN (VMnet3).

2. Power on, hit F12 and boot from the network adaptor. Select “Microsoft Windows Setup (x86) w. Dell Drivers”

3. The image is installed to the VM without user interaction

4. The unattend files configure Windows Setup to perform the following actions –

• Pull down all the drivers from “\\bcebuildsvr\deploy\image drivers”
• Boot into Audit Mode
• Execute \\buildsvr\deploy\audit.bat which maps Z: to \\buildsvr\deploy

5. Once setup is complete you will be automatically logged into Audit Mode as the Administrator using the default profile. Any changes you make in Audit mode will affect the profile of all new users created on the machine after it is deployed.

What's next?

In the next post I’ll be showing you how to install apps into the source machine, capture it, inject additional drivers into the image and finally how to deploy that image so that Windows RE can make the deployment resilient.

Deploying Windows 7 Part 1

This is the first in a series of posts relating to my recent adventures with deploying Windows 7.

With this first post I will introduce the overall environment I'm building with and building for.

There are a few things that are a bit special about this deployment. It’s not your typical corporate domain-joined limited user deal -

• The machines are not domain joined
• There is no 'back-door' management
• The users own the machine. Both fiscally and administratively

The machine owners get much the same experience as they would have buying a laptop at a retail store. They get prompted for all the same options - machine name, enable updates - everything. It's their machine.

All I'm doing is making the installation consistent regardless of the hardware platform (i.e. no crapware) and pre-installing the applications that are required for the owners work.

That said not much of the remaining technical details are affected by this change in Operating System ownership. The same scripts and bits are equally applicable to managed, domain-joined deployments.

The only difference is that I need to make the deployment more resilient. Many of the target machines don't have optical media and it’s still a work tool. It needs to be resilient to any of the bad, bad things that its owner may do to it and get them working again quickly.

To this end I've deployed the image with Windows RE included. WinRE is a recovery environment that is included in Windows Vista and Windows 7. It’s the same environment you boot into when you choose recovery on a Windows Vista or Windows 7 installation DVD. The difference here is that I've baked WinRE and a backup copy of the Windows installation image into the hard drive within a hidden partition.

With Windows RE suitably configured the user can totally mangle the installation of Windows in C:\WINDOWS. They can easily boot into Windows RE and then re-install a clean copy of Windows and all of their applications as they were when they first received their machine.

Before Windows RE does this reinstallation it moved all of the user data in C: into C:\WINDOWS.OLD\ so the user won’t lose any of their documents. Additionally in this particular deployment the user’s data will also be backed up to Live@EDU.

The next few posts in this series will cover off three broad topics-

1. My lab environment including VMware workstation, Windows Deployment Server and the Windows Automated Installation Toolkit
2. Building and capturing an image
3. Deploying an image that includes WindowsRE from Windows PE booted either from USB or WDS.

Stay tuned!

Dell Laptop diagnostic special key sequence

Interesting little tid-bit. I've had a lot of drama with my Dell Latitude E6500 throttling when it gets warm. This has largely been resolved by installing BIOS A19 and keeping the heat-sink clean.

A recent discovery I found on Dell's forums is the diagnostic key sequence -

Hold shift and fn whilst typing 1-5-3-2-4, release then press fn + R

This diagnostics screen will give you readouts and let you change some thermal settings.

When the mode is enabled your keyboard lights will do some funky things. To reset back to defaults you need to shutdown and restart.

Pretty neat, eh?

Playing with the Option GTM380 HSDPA card

Following on from my last post we now move to the other HSDPA card I bought. This is an Option GTM380. As I can tell its not OEM'd by anyone else like the HS2300/MC 8775 was. Option's web page was recently re-vamped and the IEMI for my card will now let me download the latest driver from Option.

You can also get the driver and software bundle from the Option AT&T support page here.

The interface is a fair bit more basic than the Sierra Watcher, but there is still all the things you need to get it working.

One thing that didn't work as I expected is that the "Autoconnect" option in the software doesnt seem to leave the card in the "Always On" state. You can go into the cards driver properties and change the Autoconnect and Auto re-connect variables to 1 which does the trick however the software client still tries to tear down the connection if you exit it. Luckily the auto-reconnect function in the driver brings the link back up.

This card has two antenna connections that are needed to support 7.2MBps, and if the weather is right you can get about 60% of that. Two antennas doesn't seem to buy much extra connectivity reliability over the MC 8775 card, however.

The one significant gripe I have with this card is its lack of compatibility with Windows, and specifically Windows 7. The card drivers fail to re-initialise after sleeping, which I would do regularly given that I commute with my laptop. The issue is covered and patched for Vista however I'm not running Vista anymore. I do hope that its fixed in later builds of 7 - I'm currently on 7077 x64.

Buying cheap MC 8775 HSPA/HSDPA/HSUPA cards on eBay

I recently bought a couple of cheap (~$120AUD, shipped) 3G cards on eBay. Both work fine however I thought that I'd post about my experiences and mention some tips for young players. I'll cover the first card, a Sierra Wireless MC8775, in this post. I've been running it for a couple of weeks now, when I have more experience with the new card I shall post about it.

I bought them to use in my new Dell E6500 laptop running Vista x64.

The first was a Sierra Wireless MC8775, however the device I received was a HP branded HS2300 unit. After trying lots of drivers, I ended up getting the slightly older HP drivers working. Searching on HP's site for HS2300 found suitable drivers, however the later ones didn't install properly for me, its possible that they are locked to HP hardware.

There are some drivers included with the Generic Watcher, too, but these only cover Sierra's own brand products.

You can download HP the driver that worked for me from here.

You then can get the Sierra Generic Watcher app from here.

If so inclined you can get later firmware using the link in this post. Ignore the Watcher and driver link, though.

The MC8775 is a HSDPA single antenna device so it only supports 3.6Mb/sec but it does get quite a good signal using either of the two antennas in the E6500, better than my iPhone on the train, for example.

You can configure the Watcher profile type to Autoconnect and to not turn off the radio on exit. This way the Internet connection is "always on". You would want to keep an eye on your ISP quota, though.

Overall I'm quite happy with Optus' coverage on my commute and based on my iPhone experience (which is also with Optus) the coverage should be pretty good out on the road as well.