Here is a step-by-step guide on how to create offline deployment media for SmartDeploy Enterprise. Following these steps will quickly get you a basic offline deployment CD/DVD.
1. Open the Media Wizard by selecting Start – All Programs – SmartDeploy – SmartDeploy Enterprise – Media Wizard.
2. Select Next to proceed to the Select Task page
3. Select Create offline deployment media. This option allows you to create offline deployment media containing all components required to boot and deploy target computers.
4. Select Next to proceed to the Select Image page
5. Select Browse to browse for the WIM you have created.
6. Select Next to proceed to the Platform Pack page
7. Select Browse to browse to a platform pack that you have created. Don’t have one? Get a Platform Pack here.
8. Select Next to proceed to the Optional Components page. For now let’s keep the defaults.
9. Let's select CD / DVD disc as the type of media we would like. SmartDeploy Enterprise supports spanned media, so really you can pick any option. It just depends on how big your image is and what media you select!
10. Select Next to proceed to the Save Options page.
12. Select Browse to select a location where you want to save the SmartDeploy ISO. If you would like to burn the .iso to media now, click the Burn now checkbox, otherwise just click Next and burn the media later.
13. Select Finish to start the media creation process.
You have now successfully created offline deployment media with SmartDeploy Enterprise! You can now boot from this CD and/or DVD to start SmartPE and begin the deployment process.
If you have any questions, feel free to ask, and we will be glad to help.
For years people have struggled with the best way to capture and share dialog boxes or other objects they see on their computer screen.
The old tried and true method: PrtScn & Alt+PrtScn
The PrtScn button by default captures the entire desktop, and using Alt+PrtScn captures only the active window on the desktop. This is a good start to get what you want captured. You can then open the Microsoft Paint application (mspaint) and paste in what you have captured. The trick here is to make the area in Paint that you’re about to paste into smaller than what you are pasting, this way the resulting image will be exactly what you captured and not have any white space. This works fine, but what if you want more than one window, but not the whole desktop? You have to capture the whole desktop, paste it into Paint, then select just the area you want, copy that, create a new instance of Paint and paste it in. So, it can be done… but it’s tedious. The obscurity of this process and the desire to have more functionality has led many people to purchase 3rd party software like Snagit. While these 3rd party tools aren't that expensive and provide a lot of functionality, I think many people end up purchasing them just for basic functionality.
Microsoft steps in: The Windows Snipping Tool
With Windows Vista and Windows 7, Microsoft includes a handy utility for screen capture called the Snipping Tool. It's installed by default in almost all versions of Vista and 7, other than the basic and lower editions. Its part of the “Tablet PC Components” so if you can’t find it, be sure those components are installed under Windows Features. The easiest way to launch the Snipping Tool is to use Windows Vista and Windows 7’s built in search. Click the Start Button, type in “snip” and it should be at or near the top of the list. Or, if you really just want to go to it, it sits under All Programs, Accessories.
By default the Snipping Tool opens to a rectangular snip, in which you can draw a rectangle around anything you want and it will capture it. There are other options…
The Windows Snip option is much like Alt+PrtScn, but can capture any window you hover over and highlight. There are also configurable options…
With Windows Vista, probably the first thing I like to change is that by default all captures have a red ink boarder. So if you uncheck the "Show selection ink after snips are captured”, that won’t happen anymore. In Windows 7, this is unchecked by default. Also, here lies another neat feature. By default the Snipping Tool is set to “Always copy snips to the Clipboard”. With this, if you really just want to paste what you’ve captured into another program, you don’t have to save the capture first because it’s already in the Clipboard. For example, you can snip something and then just paste it into an IM conversation or email to share it with someone.
Editing tools after capture are fairly limited. You can highlight, use a pen to draw, or directly email the capture. Beyond this is where you would really need a more fully functional 3rd party application if you wanted to resize, add text, or other graphics.
In Windows Vista both Paint and the Snipping Tool default to saving their files as JPEG’s. However, in Windows 7 they have switched both to default to PNG’s. Microsoft has always bounced back and forth on this, but I prefer PNG’s, so I like that they have gone that direction with Windows 7.
In a follow-on to my previous “Windows 7, BitLocker and Recovery” blog, I was wondering what would happen if you installed Windows 7 to an existing partition so that you ended up with a single partition instead of two, and then ran the BitLocker wizard. Or, if you made a 300MB active partition in the beginning of the disk and then told Windows setup to install to the free space.
In the “Hardware requirements for BitLocker Drive Encryption” section of the Windows 7 Help and Support, it states that the system partition must be at least 200MB. Then in the “Set up your hard disk for BitLocker Drive Encryption” section it states… “If your computer does not have a system partition, the BitLocker wizard will create one for you using 200 MB of available disk space.”
Yet the BitLocker wizard follows the Windows PE User’s Guide recommendation of 300 MB. Plus, it moves and reconfigures the Windows Recovery Environment from the boot drive to the newly created system drive.
Let’s summarize what you end up with the 3 scenarios:
Perform a clean install from the Windows 7 product DVD, enable BitLocker after installation.
Install from the Windows 7 product DVD to an existing single partition, enable BitLocker after installation.
Pre-create a 300MB active partition, have Windows setup install to the free space, enable BitLocker after installation.
These are significantly different outcomes. It really makes me think that it was a mistake not having Windows setup create a 300MB system partition and locate the Windows Recovery Environment there from the beginning. Or, maybe Windows setup shouldn’t even bother pre-creating the 100MB system partition. What is funny is that all SKU’s of Windows 7 create it, yet only Enterprise and Ultimate contain BitLocker. BitLocker is the one product feature that really requires two partitions. I could see if the Windows Recovery Environment was located in the 100MB partition by default, but it isn’t.
Having the 300MB active/system partition at the beginning or end of the drive could really be personal preference. If you ever wanted to have a recovery image stored locally on the machine, much like the OEM’s do, then having the 300MB at the beginning makes some sense. This allows you to then have a third partition at the end of the drive large enough to hold your image. I’m going to go with a 300MB system partition at the beginning, and then the BitLocker Wizard doesn’t have to shrink an existing partition later.
Windows 7 has greatly improved and simplified the process of setting up BitLocker and the Windows Recovery Environment. In fact both the separate partition structure required for BitLocker, and the automatic failover to the Windows Recovery Environment are setup by default in Windows 7. With Windows Vista neither of these were setup up by default. With Windows Vista the guidance from Microsoft was to create a 1.5GB system partition for BitLocker, and this is exactly what the BitLocker Drive Preparation Tool did. 1.5GB was plenty big to hold the system files plus a Windows Recovery Environment. But, it oddly still fell short of being able to hold a recovery image of any kind since the base install.wim for Vista Enterprise 32-bit is over 2GB in size. Now with Windows 7, the automatically created “System Reserved” partition is just 100MB. This is an interestingly small size, because the Windows Recovery Environment is too big to fit on this partition. The included Windows Recovery Environment, Winre.wim, in Windows 7 is 138MB. The Winre.wim is located on the boot partition in a Recovery folder, and is set as the default recovery sequence in the Boot Configuration Database for the boot partition.
This all works great, but things start to get interesting when you enable BitLocker. Enabling BitLocker on Windows 7 causes the Windows Recovery Environment to be removed. The Winre.wim and boot.sdi are removed from the Recovery folder and the BCD entries are deleted. This actually causes errors with integrated features of Windows 7. If you go to Recovery in the Control Panel, and click on “Advanced recovery methods”, you will receive the following error.
One interesting aspect of automatic failover with the Windows Recovery Environment is that once you enable BitLocker it will no longer be a seamless process. Meaning that when the system went into failover mode and booted to the Windows Recovery Environment it would prompt for the BitLocker recovery password to first unlock the drive, instead of automatically running the recovery agent. This makes automatic failover not as useful once BitLocker is turned on. Maybe this is one of the reasons that led to the removal of the Windows Recovery Environment when you enable BitLocker.
Having the Windows Recovery Environment located in the boot partition has some drawbacks, because you have to read the Winre.wim file from the Windows partition that might need fixing. Thus, if the MBR or partition table becomes corrupt, you can’t boot to the environment that could fix those issues.
In the Windows PE User's Guide for Windows 7, it suggests having the Windows Recovery Environment on the first partition on the disk, which would be the active/system partition, but makes it 300MB. So, the roughly 30MB of system files along with the Windows Recovery Environment fits no problem. This seems to make a lot of sense, and I don’t see why Windows 7 wasn’t setup this way by default. I also don’t see why the Windows Recovery Environment is automatically removed when you enable BitLocker.
For years, IT departments have been searching for a method to maintain a perfected Operating System image which can be quickly and easily deployed to the majority of the computer models supported throughout the organization. This 'golden image' should contain all the necessary OEM drivers for the hardware to work without any secondary steps to manipulate the device manager or otherwise update drivers after the initial image deployment. I have personally experienced high levels of frustration from hours of development time trying to design the correct scripts to conduct INF file injection PRE or even POST SYSPREP for an elusive 'golden image' because the payoff would be well worth it.
Finally, there is a product on the market which achieves the perfect image end game. By leveraging the scripting and single-instance storage available in SmartDeploy Enterprise (SDE) I now have the 'golden image' at my proverbial deployment fingertips. In the past, my methods were tiresome. I would get a new model computer and visit the vendor site only to download, extract, and install each individual driver for the hardware components then move on to other add-ons. The alternative is to use the vendor baked-on image, but in IT circles that is blasphemy to most professionals due to the unnecessary add-ons, trial software, and general sluggishness of vendor supplied images.
There are several advantages to adopting the SmartDeploy Enterprise software to serve as a new model for your Operating System image management. First, you are able to use the Platform Manager component within the SDE software to create single-instance storage files of all the drivers you need for a specific computer platform or model. These are known as Platform Packs. Secondly, Prowess the makers of SDE host a freely accessible database of Platform Packs that can be quickly queried to deliver a fully functional driver pack for each of your computer models. Each contains the collection of needed drivers and INF files needed for your model and conveniently organized by Windows version.
The process is simple. Download the Platform Packs from the website for the supported models in your organization. When you open the pack with the SDE Platform Manager component you can quickly make additional customizations to the driver sets if desired. For example, I downloaded a pack for an Optiplex 745. Then opened it with Platform Manager. The drivers are organized logically by OS and then by hardware device as you can see.
In this example, I needed to add an additional high-end audio driver for a specialized sound card that we use. To make the changes to a platform pack: I start by extracting the driver files for the manufacturer and model that I need to modify to a new folder on my computer. Then I delete the operating system that I just extracted and subsequent driver files (from the Platform Manager console). Next, I make audio driver file additions to my new local folder. Finally, I re-import the folder containing the updates into my modified platform pack file and re-save it. For exact steps on how to do this follow the Smart Deploy Enterprise User's Guide below.
Add or remove drivers in a platform pack
1. Go to Start > All Programs > Prowess > SmartDeploy Enterprise > Platform Manager.
2. Click File, and then click Open. Browse to the platform pack (.ppk) that you want to modify, and then click Open.
3. Expand the tree to the manufacturer and model you want to modify.
4. Right-click the operating system you want to modify. Then click Extract.
5. Browse to an empty folder or create a new folder for the extracted drivers. Then click OK. The device drivers are extracted to the folder.
Caution The next step deletes the entire operating system tree under the selected manufacturer and model. This includes all custom filters, tasks, and settings for the device drivers and supporting software. Make sure you are working from a copy of the original platform pack, and take a few minutes to note this information so that it can be easily re-entered when needed at the end of this section.
6. In the Platform Manager, right-click the operating system you just extracted, and then click Delete. Click OK.
7. Open Windows Explorer to the folder where the drivers were extracted. Do one of the following:
To add drivers, add the desired files and/or folders.
To remove drivers, delete the desired files and/or folders.
8. In the Platform Manager, expand the tree to the manufacturer and model you want to modify.
9. Right-click the computer model, then click Add. The Add new software dialog will appear.
10. In the Target operating system list, select the same operating system you just deleted.
11. Click Browse, and then select the platform folder that contains your device drivers. Click OK.
12. Browse the device driver tree and confirm your device drivers have been added.
13. Go through the device driver tree, and re-create the custom filters, tasks, and settings.
14. When you have finished your changes to the platform pack, click File, and then click Save.
As I mentioned, this process is simple. You can even import one Platform Pack into another if you need a single pack to contain drivers across multiple chipsets if desired. Below are the instructions from the Smart Deploy Enterprise User's Guide.
To combine platform packs into a single file:
1. Go to Start > All Programs > Prowess > SmartDeploy Enterprise > Platform Manager.
2. Click File, and then click New. Browse to where you want to save your combined platform pack. Type a name for the combined platform pack; for example, Default.ppk, and then click Save. An empty platform pack will be created.
Note If the platform pack is named Default.ppk, and it is located in the same folder containing your images, it will automatically be processed by the Deploy Wizard at deployment time.
3. Click File, and then click Import.
4. Browse to the place where you downloaded the platform packs. Select a platform pack. Then click Open.
For each platform pack you want to include in the file, repeat steps 3 and 4. When you are done importing platform packs, close the Platform Manager.
Our 'golden image' attainment is closer than ever before. Next, we will choose to deploy our Operating System with the desired Platform Pack to our destination computer. I plan on discussing how easily image deployment occurs in V2V or P2V environments in my next post.
In almost ten years of Windows Operation System image deployment experience, I have been chasing an easier way to manage the OS image development process or OS image life cycle. Most of us in the industry have grown tired of the antiquated process of building a reference Operating System image on driver specific hardware only to have the dreaded Blue Screen of Death (BSOD) appear when the manufacturer changes chipsets or other components on common corporate-class models. Many organizations have been tied to a specific make and model of computer for all of their employees. This over-standardization is hampered by long and often delayed computer refreshes which are driven by keeping the computers 'the same' to simplify OS image administration. IT Professionals can agree on the varying level of negative outcomes that they have experienced when trying to make their newly 'minted' standard corporate OS image work on different hardware that just arrived from the vendor who conveniently changed chipsets unannounced. IT offices everywhere have been forced to maintain dozens of copies of the same basic corporate image because of hardware component differences, device driver inconsistencies, and the beloved out-of-warranty computer models that are still supported within every organization.
Then....along came virtualization. Several years ago, I started experimenting with VMWare Workstation to test scripted application installs with Windows XP. The beauty of a virtual machine (VM) resides in the ability to take a snapshot of the any current 'state' of the VM before you apply changes to the OS image such as an application install. For the first time, I could easily test and re-test changes to the OS image without having to re-image my computer or delete the Windows user profile in order to un-do system modifications. My initial excitement around virtualization was placed in the time that I would save, no longer needing to re-image computers for testing. Instead, utilizing a virtual environment for testing scripted applications and undoing OS image changes by easily reverting to a clean ‘snapshot’ of my VM reference computer.
My thinking easily expanded to comprehend the advantages of using desktop virtualization for the entire OS image life cycle from beginning to end. For example, Microsoft's SYSPREP process is notorious for requiring a rigorous testing of the logic in an unattended file. By using virtualization technology to develop the reference computer image, IT Professionals can easily capture a 'snapshot' of the pre SYSPREP state of a VM for rapid testing while avoiding time consuming physical machine re-images and image re-captures that would normally be required during the SYSPREP testing phase. Now my only roadblock was finding a product that supported Virtual Machine OS image capture and coordinated OS image deployment to physical machines.
First, I tested Norton Ghost to capture the VM of my sypreped reference computer image by booting the machine into a Ghost PXE environment, capturing the image, and storing it on the network. However, when I tried to apply the image to a physical disk it failed at boot with the dreaded Blue Screen of Death (BSOD). I realized my folly: my images would always fail to transcend the virtual to physical deployment process unless I could manipulate the device drivers for specific hardware. Fortunately, I had been following the development of an upcoming trial release of SmartDeploy Enterprise which heralded a new driver injection process that could avoid BSODs by managing device drivers as a package called a platform pack (collection of drivers). So, I captured an image of my reference computer image by booting the machine into a SmartDeploy PXE environment, capturing the image, and storing it on the network. Then I booted my Dell Latitude with the SmartDeploy PXE media, launched the deployment wizard, selected the captured image file, selected the platform pack for my Dell Latitude, and deployed the image.
For the first time ever, I had successfully captured a virtual machine of a reference computer image and deployed that image to a physical computer which booted correctly with no Blue Screen of Death (BSOD). Furthermore, the Windows device manager looks clean with plug-n-play detection working seamlessly with the pre-compiled drivers from the SmartDeploy Platform Pack were injected correctly during the imaging process.