Tag Archives: Virtual Box

Building an image of Windows 10 for mass-distribution

Posted on by

Hello,

This post is a follow-up or compliment to creating an image of Windows for mass-distribution (Windows 7). On that note as well, the folks over at Deployment Research have a great post on creating an updated Windows 7 master image with MDT, very helpful.

This summer, Windows 10 is upon us, and we have already begun slowly transitioning some areas to Microsoft’s ultimate operating system. Largely, the process of making an image for Windows 10 is the same that is was for Windows 7 with a few twists.

Tools…

I like to build my images in a virtual machine. This approach allows me to create an image that is truly hardware-neutral. Using actual hardware could work, but there still may be remnants of that hardware that sysprep does not generalize, and could potentially make it into production. The actual hardware approach worked for Ghost, but it is not necessary anymore with MDT. Choose whatever virtualization tool out there, they all work very well, some are even free. Here’s the best of what’s around:

  • VMware Workstation/Player – Not free, but feature-rich and integrates into vSphere.
  • Microsoft Hyper-V – Comes with x64 server versions of Windows (2008 and later), and x64 desktop versions of Windows 8 and later. Despite all of the “server” nomenclature, client operating systems will work just fine.
  • Oracle VirtualBox – Free, and available for Windows, macOS, and Linux as both the host OS and the client OS.

I am aware that there are virtualization products for macOS, and Linux, but we’re working with Windows. I think it is best to just stick with that for the whole process. I’m sure everything would be fine if Windows was not the host operating system.

Given that, you’re going to want to do this work on a moderately beefy PC. Not all of us have Dell Precision workstations, or even access to a server with Hyper-V or vSphere installed, but using an under powered PC will make building images, and just using virtualization a slow and miserable experience. The key is storage. Creating images, multiple images with snapshots, and testing uses up a great deal of space on the disk drive(s). I would not bother using a drive smaller than 1TB. It’ll work on something smaller, but in that case, you are limiting the whole process. Even 1TB SSDs are reasonably priced now. SSDs are king, but still not equal to spinning disks in price per gigabyte. A combination of something like a 256GB SSD for the host operating system and applications with a 4TB spinning HDD for storage would work well. RAM is also very important because, when using VMs, RAM is being used by both the host and guest operating systems, at the same time. Try to max-out what your PC will take. 32GB, 64GB of RAM is not unreasonable for this type of work.

Modern CPUs are plenty powerful for many tasks, virtualization too. Intel CPUs have extensions specifically for virtualization. Quad-core CPUs should be a pre-requisite for a host PC that will do virtualization. You could use a dual-core CPU, but recall the part from above about under powered PCs and virtualization. If you can get a CPU with more cores, 6, 8, great! Xeon CPUs are really nice. I wouldn’t bother with anything under a quad-core i7. Another thing to also consider, that is sometimes overlooked, is bus speed. You could have the fastest CPU with many cores, a ton of RAM, working off a sweet 2TB SSD, but if the bus that connects all of these devices together is small, all you are creating is a digital traffic jam. NVMe, and M.2 SSDs are slowly replacing SATA-based SSDs and spinning HDDs in consumer and business PCs. They offer a significant increase in throughput and speed for data storage. DDR4 memory is the latest and greatest in RAM technology, until 2020, when DDR5 is expected. It is not the cheapest, but DDR4 outperforms all of its predecessors. Obviously, you want to get the best set up you can, but I understand budgets have limits.

Virtual Machine Settings…

This can vary from place to place, but I would use at least 4GB of RAM, one vCPU with 2 cores, and a 128GB VHD. That has worked well for me with Windows 7 and 10. If you can give the VM 8GB of RAM, do it. The smallest disk drive we have out there is a 128GB SSD in some Dell OptiPlex 9020s we purchased in 2014. When finished, my image has a disk footprint of around 70GB (35GB compressed by dism). If the new image will be small, then a 64GB VHD is fine. That is as small as I would go. It is possible to squeeze an image of Windows 10 (plus updates), Office 2016, Adobe Reader, Chrome, VLC, and AV software onto a 32GB drive, it is a tight squeeze. Windows grows in size over time, and 32GB will be gone long before you even realize it. I’m starting to think 32GB is too small for an iPhone… The virtual NIC should be configured for NAT, and not bridged to the production network. We’ll have a fresh install of Windows, straight from the ISO, and temporarily unpatched. The image should not see the production LAN until it is ready for testing (patched), or ready for use.

OS Installation…

After the guest VM is created for the new image, connect its virtual CD/DVD-ROM drive to the ISO file for Windows 10. In VMware Workstation, new VMs, with no OS installed, automatically boot to the virtual CD/DVD-ROM by default.

Follow the on-screen prompts to install Windows into the VM, but STOP after the first reboot from install/file copy to OEM/Windows setup. Setup will stop at that point, and wait for user input. There, we’ll use audit mode to finish setting Windows up the way we would like it. I have more information about installing Windows 10 in a separate post.

Press control + shift + F3 to reboot into audit mode.

STOP at this screen!

To get into audit mode, press control + shift + F3 all at the same time, like the three-finger salute (control + alt + delete). Windows will reboot, and automatically log in as the built-in administrator account, and will continue to do so, no matter how many times you reboot, until sysprep is run. Here, we’ll customize Windows 10 as desired, then run sysprep with an unattend.xml file that copies our profile over to the default (CopyProfile).

From within your virtual machine software, take a snapshot of the VM, at this point.

Most corporate or “work” PCs have Microsoft Office installed along with Windows and other common programs. Microsoft/Windows Update is used to update both Office and Windows. At this point, I install Office (silently with a MSP file), and enable Windows to update other products in addition to itself. This is done from the new Settings application \ “Updates & Security” \ “Advanced options” \  “Give me updates for other Microsoft products when I update Windows.”

The above setting has to be enabled for Windows to update Office too.

Once that is set, run updates on the new VM until there are no more left. The later the build of Windows 10, the fewer updates will be required. Microsoft Office 2016 has been available for some time, and has a decent amount of available updates online. Once the updates are finished, shut down the VM, and take another snapshot.

Some basic applications, which are not included with a regular install of Windows, are utilities that other applications use. Applications like the various Visual C++ Redistributables (VCPP), Microsoft Silverlight, and Updated .NET Frameworks (4.5/4.6). These are easily found online, and can be installed silently. The Deployment Research site has a script that gathers all of the C++ Redistributables together, and installs them, silently, in one script.

Download the VCPPs from the Microsoft website (both x86 and x64), and move them to a folder structure named as follows: (#### = the date for the VCPP application, 2005-2015)

Source \ VC#### \ vcredist_x64.EXE

Download all of the VCPP apps for x86 and x64 versions 2005, 2008, 2010, 2012, 2013, and 2015 and arrange them like above.

The script to install all of these can be found here.

Silverlight is also freely available from Microsoft’s website.

Next, is to install all of the regular applications that people use every day. Web browsers like Google Chrome, or Mozilla Firefox, PDF readers like Adobe Reader, or SumatraPDF, communications application such as Skype or Zoom, and multimedia apps like VLC, or iTunes. I download, and store the applications I intend to use on a server share, then use silent install scripts to install them on Windows 10, which is still in audit mode.

Some basic silent install commands for common applications. If you’re in for more details, check out ITNinja.com. They have a compendium of unattended and deployment-related information for many applications.

  • Adobe Reader: msiexec /qb /i AcroRead.msi TRANSFORMS=AdobeReaderDC.mst
  • Google Chrome Enterprise: msiexec /qn /norestart /i “GoogleChromeStandaloneEnterprise.msi”
  • Mozilla Firefox: FirefoxSetup.exe -ms
  • VLC: vlc-2.2.1-win32.exe /L=1033 /S /NCRC
  • Java (if you must): jre-8u66-windows-x64.exe” /s JAVAUPDATE=0 AUTOUPDATECHECK=0
  • Notepad++: npp.6.8.7.Installer.exe /S
  • 7-Zip: msiexec /q /I 7z920-x64.msi

Ninite.com has a site that will create a wrapper as an executable that will download whatever freeware is chosen and install them. All in one go.

Keep in mind that the fewer applications that are placed into the image, the longer that image will stay relevant. MDT/SCCM can deploy applications in addition to the OS itself. Products like Adobe Flash Player, and Adobe AIR change so often that I just install them when the image is deployed.

Run each of the newly-installed applications and configure them as desired. Shut down, take a snapshot, then reboot and let Windows 10 continue in audit mode.

To save time and effort in configuring Windows the way I need it, I try to automate as much as possible. Scripting the basics and eliminating the redundant and repetitive tasks can save a lot of time and prevent unnecessary mistakes.

Creating user accounts – I typically make a local user account for administrative use and for general use in case the domain is somehow unavailable.

First, I create a local folder to contain log files and other goodies, then hide it. “C:\Stuff” in this example.

mkdir C:\Stuff

attrib +h C:\Stuff

echo Creating local user accounts

net user pcadmin * /add /comment:”Local admin account” /passwordchg:NO
wmic useraccount where “name=’pcadmin'” set passwordexpires=FALSE
net localgroup “Administrators” pcadmin /add

net user pcuser * /add /comment:”Local user account” /passwordchg:NO
wmic useraccount where “name=’pcuser'” set passwordexpires=FALSE
net localgroup “Guests” pcuser /add

echo Local user accounts created on %date% at %time%>>C:\Stuff\Windows-10-Config-Script.txt

The asterisk (*) after the username will prompt for the new user’s password instead of coding it into the script and leaving it for prying eyes. The last command (echo…) will create a text file and add the text between echo and the first >. The double >> will just add the text to an existing file should that be the case.

To keep from surprising users with new builds or versions of Windows 10 through Microsoft Windows Update, I set a registry key to disables Windows upgrades through updates.

reg add “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” /v DisableOSUpgrade /t REG_DWORD /d 1 /f

echo Windows 10 version upgrade disabled on %date% %time%>>C:\Stuff\Windows-10-Config-Script.txt

The next thing I want up and running right off of the bat is remote desktop.

echo Enabling RDP with SASC alternate port
reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server” /v fDenyTSConnections /t REG_DWORD /d 0 /f
reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v “PortNumber” /t REG_DWORD /d “0xdesired_port_number_in_hex” /f
netsh advfirewall firewall add rule name=”Alternate RDP Port” dir=in action=allow protocol=TCP localport=desiredportnumberinbase10

echo RDP enabled with SASC alternate port on %date% at %time%>>C:\Stuff\Windows-10-Config-Script.txt

A facet of Windows’ default configuration is to hide file extensions. I can guess the designers at Microsoft figured doing so might be helpful to end users, but in practice I have found it to be anything but for most people. I inject a quick registry change to show those pesky extensions .

reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced /v HideFileExt /t REG_DWORD /d 0 /f
echo Windows file extensions shown on %date% %time%>>C:\Stuff\Windows-10-Config-Script.txt

 

This next part of the script is entirely optional. I don’t recommend activating Windows or Office until it is ready for the end user. A caveat in configuring a default user profile, even using Windows in audit mode, is that Windows cannot be personalized until it is activated. That means you will not be able to configure a wallpaper, screensaver, desktop icons, or color theme. I don’t find that to be a big deal as most of those items can be configured through a post-deployment registry tweak or with Group Policy. However, if those items are to be included with a custom default user profile during sysprep, activate and make the necessary changes. Then, add this to the script.

 

REM Try KMS activation first. If that doesn’t work, try MAK activation.
cscript C:\Windows\System32\slmgr.vbs /skms kmsserver.company.com:port
cscript C:\Windows\System32\slmgr.vbs /ipk THEWI-NDOWS-10KMS-PRODU-CTKEY
cscript C:\Windows\System32\slmgr.vbs /ato
if %ERRORLEVEL% == 0 echo Windows activated by KMS on %date% %time%>C:\Stuff\Windows-10-KMS-Act.txt
EXIT
else
REM If KMS is not available, use an MAK to activate.
cscript C:\Windows\System32\slmgr.vbs /ipk THEWI-NDOWS-10MAK-PRODU-CTKEY
cscript C:\Windows\System32\slmgr.vbs /ato
echo Windows activated by MAK on %date% %time%>C:\Stuff\Windows-10-MAK-Act.txt
       EXIT

 

If Windows was just activated, shut down, take a snapshot, then reboot and let Windows 10 continue in audit mode.

 

Custom Default User Profile…

 

Prepare the default user profile, the built in Administrator account, in the way the end user should have it. I would be cautious when running applications under this account to answer any first run prompts. Windows 10 does more during a user’s first login process than it did with Windows 7. These changes lengthen the amount of time it takes a new user to log in for the first time. As applications are run and settings configured, the user profile grows in size, quickly, going from 2MB to 500MB without doing much. This default profile is copied over from C:\Users\default each time a new user is brought on to Windows. The larger the profile, the longer the copy process will take and lengthen an already long login process. More and more I have sought ways to provide default user settings through group policy and our endpoint management platform, BigFix.

 

If a VM snapshot hasn’t been taken in a while, take one now and certainly before sysprep is run in any fashion.

 

In order for sysprep to copy the customized user profile we have configured to the default, replacing what Windows provides, there can only be one profile on Windows at the time sysprep is run. If there’s more than one profile, sysprep won’t copy anything. Delete any profile from Windows, through the System applet, except for the customized profile. This also ensures that everyone who logs into a PC with this image of Windows installed will get the customized profile.

 

Next, create an unattend.xml file with the Copy Profile option set to true. Unattend file creation needs to be done on another, separate install of Windows 10 that is running the exact same version of Windows 10 for which the unattend.xml is being made. Copy the unattend.xml file over to the VM (C:\Windows\System32\sysprep) which is about to be sysprepped and run:

 

sysprep.exe /oobe /generalize /shutdown /unattend:C:\File\Path\To\unattend.xml

 

Sysprep will take its time and do its thing to generalize Windows and shut down. Take another VM snapshot at this time and power-on the VM again. Windows OOBE will run as if it were a new PC obtained from an OEM or a vendor. Create a bogus user account to complete the OOBE process and get to the Windows desktop. Log off of the new user account and log in as the BUILTIN Administrator (It should be listed at the bottom-left portion of the login screen). Delete the new user account, created through OOBE, and confirm that the resultant user profile being given is what the end user should have. Take yet another snapshot of the VM. Once it is, capture the image with the imaging tool of choice. We use the Microsoft Deployment Toolkit (MDT). To capture an installation of Windows into MDT, connect to the deployment share with the Run dialog from the installation of Windows that is to be captured. No need to reboot into an MDT Windows PE USB drive.

 

\\mdtserver.company.com\deploymentshare\Scripts\LightTouch.vbs

 

Select the Sysprep and Capture task that was made to create an image of Windows 10. The task will also sysprep Windows and reboot into Windows PE and perform a capture, creating a WIM file in the deployment share’s “Captures” folder. Leave the VM alone, and let things take their time. Depending on the size of the install on the VHD, it could take an hour or more. A behavior specific to the 1709 builds of Windows 10 is the tendency for Windows, after being sysprepped in an MDT capture task, will not reboot into Windows PE. It would just go back into Windows again, skipping the capture entirely. To fix this, I’ve had to make sure that the VM’s virtual CD/DVD drive, mapped to the MDT Windows PE ISO file, is the first item on the VM’s boot sequence. Hyper-V will remove the virtual CD/DVD drive from the top of the boot order, and replace it with the Windows Boot volume from the VHD. In VMware Workstation, I have to edit the VM’s VMX file to include a boot delay, which give me time to interrupt the boot sequence and redirect it as desired. Just add:

 
bios.bootdelay = 20000
 

to the VM’s VMX file and it will wait 20 seconds before completing the default order in the boot sequence, which is more than enough time to stop it, get into the virtual BIOS, and switch boot devices. Providing one is paying attention…

 

Enjoy and happy imaging!

How to Create a Windows Image for Mass Deployment

Posted on by

Requirements: Windows install media (7 or 10. 8.x?), desired apps for the image (Office, PDF viewer, web browsers, plugins), virtual machine software (VMware Workstation, Microsoft Hyper-V, or Oracle Virtual Box), and image creation and deployment software (ImageX.exe, MDT, SCCM).

Almost every place I have ever worked, IT had or needed a method to clone and deploy a specific Windows configuration and application set. From a few PCs, to hundreds, the requirements were the same, to deploy the same configuration with as little, repetitive work as possible. The ideal target being what Microsoft calls “zero-touch” deployments that require no interaction on the target computer whatsoever. This is offered by Microsoft System Center (SCCM) along with the Deployment Toolkit (MDT). Many shops do not operate that way, and have some level of interaction required during the imaging process. This piece will discuss creating a Windows install for distribution.

 

What you’ll need…

Windows and software install media (obviously)

Virtual machine software for the creation workspace. Why? Two reasons. First, virtual machines provide the option to create hardware-neutral images which can be applied anywhere, regardless of what is actually in the target computer. One image becomes possible for multiple hardware configurations. This also involves less work in mainatining the image as any work only needs to be done once and not x-times per different type of hardware. Second, most virtual machine software (I’m not sure about Virtual Box) have the ability to save a VM’s state, and revert back to that state, should it become necessary. VMware calls these “snapshots”, and Microsoft uses the term “checkpoint” in Hyper-V. Should a screw-up occur, it can be undone without loosing work or have to re-do everything. These are two facets that are simply not available with building images on real hardware. Test on real hardware, but build in a virtual environment.

  • VMware Workstation is pricey, but well worth the cost IMHO.
  • Hyper-V comes with Windows Server 2008 and later, Pro and Enterprise versions of Windows 8, 8.1, and 10 as “Client Hyper-V.”. The build computer’s CPU must support hardware assisted virtualization for Windows to install the Hyper-V role. Intel Core 2 Duo/Quad CPUs won’t muster.
  • Virtual Box, now owned by Oracle, is a freebie. I haven’t used Virtual Box very much outside of general curiosity.

The build workstation has to have some power to it. Nothing extravagant like an Alienware, or Falcon Northwest gaming rig, but above average. Try to avoid using a laptop as a VM build station. Laptops are great for testing, but a desktop PC is optimal. Don’t use a Mac. I love my MacBook Pro, but it isn’t meant for making Windows images. A quad-core CPU (Intel Core i5/i7, or AMD Phenom series) will work for starters. The more powerful, the better. RAM is the key. The more the better. I routinely work with 16GB of RAM on my workstation (the most it’ll take), and it can handle three running VMs and the host OS before going wacky. 32GB of RAM is not ridiculously expensive today, and well-worth the couple-hundred extra bucks. VMs take up storage space quickly. Working on several VMs, it is not difficult to fill a 2TB HDD (I’ve done it). Those are not that expensive either, and 2TB is the starting point I’d go with for a virtualization rig. Anything more, and you have to make sure your PC supports UEFI vs. BIOS, or else all of the drive’s space will not be recognized by the firmware, and Windows. Working from USB storage might fly, but the throughput won’t match that of internal storage, and you’ll have a bottleneck. My VM creation setup, however, is backed-up every night to my trusty 4TB WD USB HDD. If you can get large-capacity SSDs instead of traditional rotational drives, do it, but don’t sacrifice space for speed. An SSD for the boot volume with Windows and apps along with a large 2TB+ traditional HDD for VM storage is a nice setup, and not fiscally unrealistic.

Virtual Machine Setup…

Create a new VM that will become your Windows image. For Windows 7 and later, I recommend 4GB of RAM, 1 CPU with 2 virtual cores (if possible), and a virtual hard drive the size of the smallest drive that will ever receive the image. We have some 128GB SSDs out there, so 128GB is my vHDD size. That’ll assure the image will fit everywhere you intend to deploy it. Now, it is easy to see how fast space will go on your drives. Everything else is fine with the defaults. Bridged vs. NAT network adapter? It doesn’t really matter even for network-based capture/deployment. I’ve used both and have noticed no speed differential.

Install and Configure Windows…

Install Windows onto the VM with all of the default settings. If you’re lazy like me, you can use an unattend file to answer all of those pesky setup questions. This site, the Windows Answer File Generator, has a GREAT web UI for creating unattend.xml files that WORK. Place the unattend file at the root of your install media and let Windows install itself. The whole process for Windows 7-10 should be 20-30 minutes. Don’t bother with the product key and activation. Sysprep will just strip that out in the end. If your build process takes longer than a month, you might need the key and activation. I’ve never run into that problem. Don’t join any active directory domains. Sysprep will quit if it is run on a domain-joined PC.

Next, power-down (not sleep, hibernate, or pause) the VM and create a snapshot or checkpoint. This will save you 20-30 minutes of re-installing should a foul-up occur. Power back on and go into Programs and Features (Windows 7) and add/remove all of the stuff that is not needed. I get rid of the tablet components, XPS printer/viewer, Windows Media Center, Windows Fax and Scan. All of the stuff I know the end users will not touch.

Update Windows/Office…

Before getting into the nitty-gritty of configuration, completely update Windows through Microsoft Update. The older your version of Windows, the more updates it will need, and the longer the update process will take. A fresh install of Windows 7 Enterprise SP1 x64 from MS VLC ISO required 296 updates before no  more were required (as of February 2016). This will take about a day (8+ hours) to complete. One might think about adding MS Office into this process to allow it to join in the update process, but there is a reason not. Take this opportunity of having a clean install of Windows, updated, and use it as a template for other VMs. VMware Workstation allows VMs to be cloned and copied, so a patched copy of Windows can serve as a starting point for other virtual machine projects. A MAJOR time saver. Completely update Windows until it screams “no more” and shut down, then take a snapshot.

Clone or continue? That’s up to you, but whatever is chosen, the next part is installing MS Office (if needed. I can’t imagine it wouldn’t), and completely updating that through Microsoft Update. I do a custom install of Office to not include the programs users won’t need, like Infopath, and Lync, Skype for Business, and OneDrive for Business. YMMV. Microsoft Office 2013 Pro Plus needed 151 updates to be complete from a fresh install of the MS VLC ISO. Again, I wouldn’t bother with product keys or activation for Office. Shut down and take a snapshot when that part is done.

Application Installs…

Add all of the applications that need to be deployed with the image. Here is where the question of thin image vs. thick image is contemplated. A thin image contains just the bare essentials needed to get started with many other apps installed at distribution. Programs that change often, and would require updating/re-capturing the image are best left to installation at deployment. Candidates for this include Adobe Flash Player, Shockwave, AIR, and antivirus software. Software that has first-run settings which must be answered for the end user should be placed into the image, and not installed at deploy time. We install many apps with our image, so this process takes us about as long as it does to update Windows and Office. A good example set to start would be: Mozilla Firefox ESR, Google Chrome Enterprise, Adobe Acrobat Reader, Quicktime Player, VLC Media Player, Microsoft Silverlight, Visual C++ Redistributables 2005-2015, Skype and 7-zip. Run each and every newly-installed application to make sure they work as intended, and then delete the downloaded installers. The plugins, and antivirus (SEP) will be installed when the image is deployed. Power-down the VM and take another snapshot.

By this point, we have a basic working install of Windows which is moderately useful and could probably be distributed to end users. One question does arise which is substantial in nature, and determines how next to proceed. Does a custom default user profile need to be created and configured? If yes, we need to do that before capture.

Customizing a default user profile…

Windows, by itself, works pretty well out of the box, but comes with a myriad of first-run dialogs and prompts which can be confusing. My target audience is public computing, classrooms, kiosks and labs. For privacy reasons, user profiles are not kept on the computers. As soon as a user logs off from Windows, their profile is removed. Each time someone logs into one of the computers I am responsible for administering, they are logging in for the first time. Any and all first-run dialogs/prompts that can appear will. The option to spend 10-15 minutes of a 60 minute class, getting the software to work as desired, and out of the way is just not an option. To prevent this, I try to configure as much for the end user in advance as possible. Group policy is my hero in this effort. Almost anything can be set for the computer or a user through a GPO. The exceptions being non-Microsoft software like MATLAB, Maple, and Stata that all have first-run issues which often require administrative intervention. I don’t let users run as admins.

Sysprep is the utility Microsoft has made available for generalizing an installation of Windows since Windows 2000. Starting with Windows Vista, Microsoft changed to an image-based installation and mmaintenance process. Sysprep changed too, and became much more difficult to use (for me anyway). It is at this time that copying a customized user profile to the default required the use of an unattend.xml file. With Windows 2000 and XP, you could actually just copy it and everything would be fine. In the specialize pass (No. 4) of the unattend.xml file there is an option to add a pass called “CopyProfile” to the “Microsoft-Windows-Shell-Setup” setting that will copy the built-in administrator account’s profile to the default. The trick is when to apply this, during capture, or during deployment? That depends on how you’re capturing and deploying, but either way the built-in administrator account is what I use as a template for my custom default user profile.

Enable the built-in administrator account and give a password you’ll be comfortable with entering dozens of times. Log in as the admin, and immediately delete the profile for the other account setup asked you to make after installing Windows. The reason for this is that CopyProfile will not copy the admin’s profile if another profile exists on the file system at the time the copy takes place (experience speaking here). Delete the profile from the advanced system properties window, and not by just deleting the folder under C:\Users. Other accounts can remain, they just cannot have profiles.

As the built-in admin, configure the Windows environment they way you want the end users to have it. Again, most of these tasks can be accomplished with a domain-based GPO. Run each and every program the end users are likely to use and answer any first-run dialogs and prompts. DO NOT surf the web as the built-in administrator on a Windows PC without antivirus software for obvious reasons, but an important another is profile size. Surfing with Chrome or Firefox even on just a couple of sites and will add megabytes of data to the profile. You could probably get away with not even running any of the browsers at all with a good GPO in place. Google, Mozilla, and of course Microsoft make GPO settings available to completely configure each piece of software and eliminate any first-runs. Adobe recently made an admx template for configuring Acrobat Pro and Reader via GPO. GPO templates exist for Microsoft Office 2007-2016, with a dizzying array of possible configuration options. Those and the settings for Windows will get 95% of end user configuration done in a customized profile.

Things that are easily set include the desktop wallpaper and icons, the start menu, screensaver, power options, and remote desktop settings. Take your time and run through each usage scenario, if possible, without puffing up the profile’s size. Large user profiles take a while to create at log in, and lengthen the log in time required to get started. In my case, every is logging in for the first time, so their profile will be created when the need to use the PC. A 500MB profile will slow that entire process down. Once things are as desired, power the VM down and take a snapshot. This snapshot is a failsafe point for return after the image has been captured.

Capturing the Image…

There are several different ways to get an image of Windows. Traditionally, Norton (Symantec) Ghost was the standard for deploying Windows operating system images. After acquisition, Symantec let the product stagnate over a period of years as Microsoft developed successive versions Windows, and it became necessary for us to switch to a solution that would natively support later versions of Windows PE. We adopted MDT a couple of years ago for a few reasons, and that allowed us to change the way we made operating system images. Driver support in Ghost is not real versatile. The option to create one image for multiple hardware configurations required substantial tweaks and endless trial and error testing Ghost was designed to have one image per hardware type, with all of the drivers included in the image. This is not that big of a deal since many large IT outfits only support a few different types of hardware models and configurations. For us, that was six different images for a single type of Windows install (Windows 7 Pro x64). Needless to say the images did not get updated too often due to the amount of work involved.

Removing the hardware dependence and creating hardware-neutral images was a requirement for our new imaging software. An install in a virtual machine allows that type of neutrality.

Boot the VM to be captured an log on as the built-in administrator, the one that was pre-configured before. From the advanced system properties, delete every other user profile on Windows. The accounts can stay, but the profiles cannot. If there are any VM-dependent software like VMware Tools, or Hyper-V Integration services installed, uninstall them. If there are mapped drives between the host and guest OS, power-down the VM, remove them, and restart.

I like to clean Windows before capture by running a few command prompt executables.

Go to %TEMP% from the Run dialog and delete everything there that can be deleted.

Open an administrative command prompt and run the following commands.

Delete any and all shadow copies.

vssadmin delete shadows /All /Quiet

Get rid of any downloaded software updates.

del c:\Windows\SoftwareDistribution\Download\*.* /f /s /q

Delete any hidden Windows install files. Chances are there are none, but it cannot hurt to check.

del %windir%\$NT* /f /s /q /a:h

Delete the Windows prefetch files. There also probably none of those either.

del c:\Windows\Prefetch\*.* /f /s /q

Run disk cleanup.

c:\windows\system32\cleanmgr /sagerun:1

Defragment the C:\ drive (It shouldn’t be that fragmented).

defrag c: /U /V

Clear the Event Logs. Execute one command on each line.

wevtutil el 1>cleaneventlog.txt
for /f %%x in (cleaneventlog.txt) do wevtutil cl %%x
del cleaneventlog.txt

Flush the DNS cache.

ipconfig /flushdns

NOW! We’re ready to capture. The question is how?

We use MDT for imaging. MDT has a special type of task sequence called “Sysprep and Capture.” To kick this off, from the install of Windows to be captured, navigate to \\mdtserver.domain.com\DeploymentShare$\Scripts and run LightTouch.vbs. This will connect to the deployment share, and start the process. Enter any credentials required, select the appropriate task sequence, and give the image a name, then begin. Capturing from a VM to an actual MDT server, over the network, will take a while. Even for small images, it is best to just let the task run and not use the build computer for anything else until it is finished. I do this at the end of the day, when I’m not going to be needing to use the computer.

Once the image has been captured, the VM will restart and wait for further action. At that point, power-down the VM, and roll back to the last snapshot taken before the VM was captured. Back to not-so-square-one, and ready to re-capture, update, or whatever when necessary.

Outside of MDT, it is possible to capture with just a Windows PE boot disk with ImageX.exe. This process is not a clean and automatic as MDT, but it works. Going that way, the pre-capture setup process goes a little differently. In its most basic form, you need to only run sysprep from the VM about to be captured, and shut down, then restart to the WinPE boot disk and run ImageX.exe. To copy the default user profile this way, an unattend.xml file needs to be used with sysprep and the CopyProfile option must be set to “True.” The unattend file is only needed if there are any customizations that need to be applied when the image is applied to a computer. Large capacity USB flash drives are very affordable. I have a 128GB USB drive, that I purchased for $29.99, configured as a WinPE boot drive, and can be used to capture images directly to the drive instead of over the network, as it is usually done.

Enjoy!