aaron.lines@gmail.com

The SmartDeploy Media Wizard enables you to quickly build boot media that includes a custom answer file. When you create boot media with an answer file it is stored at the root of your SmartPE media (CD or USB) as SmartDeploy.xml. This answer file has several important items that you may want to modify on the fly including: .WIM file being deployed Platform Pack (.ppk) being selected Windows Deployment Services (WDS) compatible image files are a good companion for a custom answer file because of the number of questions involved in the setup process. One method I have found that works well is using a free virtual CD daemon to modify the SmartDeploy.xml file on my SmartPE ISO images. You can have separate SmartPE media for each image path or platform pack variation. However, most would probably agree that it is more desirable to have different answer files (SmartDeploy.xml) and quickly swap them out as needed. Download your virtual CD daemon of choice. I like PowerISO. The unregistered version will allow you to create or edit image files less than 300MB which works effectively for WinPE ~204MB. This program allows me to quickly mount my SmartPE media and view the SmartDeploy.xml file. If you want to edit the answer file. Simply copy the file to your desktop. Edit the parameters to match the path to the platform pack and image file you need. Then copy the file back to the screen replacing the original file. You will have your new SmartPE ISO file with an updated SmartDeploy.xml as soon as you click save. Another useful idea is to use your mounted ISO to create a new deployment USB drive. Optionally, you can use the Media Wizard to perform this task. First, open SmartDeploy Enterprise Command Prompt. Then run the following commands: diskpart select disk 1 clean create partition primary select partition 1 active format quick fs=fat32 assign exit xcopy V:\SmartPEiso\*.* /e f:\ Note: where F:\ is the drive of your USB drive and V:\ is your virtual CD daemon drive. Remember, you can edit the SmartDeploy.xml file on your USB boot media that you have created quickly without needing to mount an ISO image. You may want to keep copies of various answer files that reference different paths to image files or platform packs on your network or WDS folders. If you name them logically (XP_answers, Win7_answers.xml) you will be able to swap out answer files on the fly in either the ISO or USB SmartPE media you are using. Enjoy IT, Aaron Lines IT Consultant

SmartDeploy now fully supports OS image capture for deployment using Microsoft's Windows Deployment Services (WDS). Devon's blog does an excellent job of over-viewing the process to capture a WDS compatible SmatDeploy image file. The process is wizard-driven and truly extends the capability of the product. In a large computer lab settings, it is very desirable for you to be able to automate the deployment wizard using an answer file. For example, some of the large labs I support include upwards of 40 systems of a single hardware type requiring the same platform pack. I will discuss how to integrate an answer file into your SmartPE media to create a fully automated method of deploying a specific SmartDeploy Windows image file to a large number of computers that require the same image with the same platform pack. Below is a screen shot from the Summary page of the Deployment Wizard. This is step 16 on part 7 of Devon's How To Integrate SmartDeploy With WDS blog. Now go ahead an export your answer file using the 'Export' button. Then create a new SmartPE image file using the Media Wizard that incorporates your WDS answer file. This is the screen shot from step 7 of Part 2: How To Integrate SmartDeploy With WDS. Click the 'Browse' button to import your WDS answer file. Then complete the wizard creating your new SmartPE media. Now you will have be able to re-import your new SmartPE media containing the answer file into your WDS to further automate image deployment in a lab environment. Similarly, image deployments that require the same Deployment Wizard answers (including the image file and platform pack) could merit their own SmartPE boot image that contains each unique answer file. I recommend naming the PXE boot image a specific file name to make it obvious it contains an answer file and for which configuration (e.g. image file + platform pack + Lab_Name). You should be able to judge how many SmartPE boot images containing various answer files based on the frequency you use an image file and platform pack for deployment. The more frequent you use an image set, the more likely you will want a boot image that answers the wizard questions for you. Things to keep in mind: You can use the Platform Manager to combine multiple platform packs which could further limit the number of SmartPE boot images required for your scenario. If anything needs to change (path to the image file, platform pack, etc.) then you may want to edit the answer file and create a new SmartPE boot image for that different imaging task. Finally, if you don't specify a platform pack it will automatically integrate one named DEFAULT during the deployment process. By storing platform packs for specific models in the root image directory on your WDS then naming it DEFAULT, you could avoid changing the answer file except in cases of image path differences. Final thoughts. Integration of WDS is a leap forward for SmartDeploy and image deployment professionals. I welcome more time saving tips and walk-throughs to reach further development our community's best practices with SmartDeploy Enterprise. Aaron Lines IT Consultant

One feature that I have started to utilize in SmartDeploy Enterprise is differencing images. This technology is currently available for you to reduce your image development time, decrease the amount of space required for OS image storage, and improve the change management process of 'certifying' OS images in your IT organization. A simple way to think about differencing images is that they represent only the changes (delta) between image ‘A’ and image ‘B.’ Most IT shops have at least a dozen different images they are supporting and maintaining which hogs valuable network space and more importantly takes up unnecessary time in capturing or deploying large image files during development. For example, if I want a Windows 7 image for each of my departments (HR, Finance, and IT) then I need 3 different images right? Yes and no. No, we do not need 3 huge 10GB images containing all the Windows base OS files and customized software for each of our three departments. First, we can capture a standard base image containing our basic applications (anti-virus software, web plug-ins, and Office). Then we can capture separate ‘differencing’ or delta (the changes) images between our base image and our customized software and settings for each of our three departments. Follow along: I captured a base image, aka a standard .WIM file of Windows 7 which ended up being about 5.8GB. Now I want to customize my image file to be specific for IT Professionals. So, I booted my VMware Workstation file of Windows 7 which I had recently captured. Then I installed two programs that all of my IT Professionals need, the Windows Automated Installation Kit (WAIK) and VMware Workstation 7. Next, I shut down the virtual machine and run the Capture Wizard again. This time I point to my original .WIM file (from my first capture run of the base image file) and create a new .DWM file with a similar name. Now I have two image files: Win7x86_GI_2-1-10.wim and Win7x86_GI_IT_diff_2-1-10.dwm that are saved in the same folder/directory. This aspect is important because when you deploy a .DWM image file you need to have the master image file residing in the same directory for the image deployment to complete successfully. My new .DWM or differencing file is only 3GB which saves about two-thirds of the space required to store the entire IT Department image. My base image was almost 6GB. If I had created a new traditional WIM, I would have had a new 9GB image for my IT Department. In total, the traditional method would require 15GB, with differencing images it only requires 9GB. This process can be continued to create .DWM files for each variation of your base image. To do this easily, you could have 3 separate virtual machines of the same base Windows 7 OS. Then customize each virtual machine with the different applications and settings for your 3 departments. Typically, I save these virtual machines to revisit at a later date to re-capture after more recent patches and security updates have been released for various applications. From a change management perspective, differencing images allow you to control the image certification process. You can distribute a 'certified' master image that gets a rubber stamp of approval every couple of months. Then encourage IT support staff to focus on developing differencing images while they await the quarterly or semi-annual master image. Overall, I like using differencing images with SmartDeploy Enterprise and I think you will as well. Please see me next post for a detailed screen shot based approach on how to 'difference' image step-by-step and for some .DWM file deployment best practices. Aaron Lines IT Consultant

We all need some time saving tips. I want to share a couple of time saving tips that I have developed while working with Smart Deployment Enterprise. The tips alone are not revolutionary, but they are valuable and will help new SDE adopters get even more out of an already valuable imaging suite. Part of being super efficient in image development is to use a virtual reference computer for gathering your base image (see my earlier post and Devon's post on creating a reference VM). I have a simple shortcut to share with you. I use a specific technique to capture and deploy .WIM files from my host computer while developing my OS images using Smart Deployment Enterprise in combination with VMware Workstation 7. In this scenario, I have just captured a newly minted Windows 7 SYSPREPED image from a VM using the SDE Capture Wizard. Next, I want to test deploying the image to a VM to verify SYSPREP works as desired. After creating a blank (image-less) 40 GB VM file to test my Windows 7 image, I use the following steps: I boot my blank (imageless) 40 GB VM with my SmartDeploy Enterprise PXE Media ISO At the SDE Splash screen I enter Shift + F10 for command prompt (per on-screen instructions) Using the net use command I map a Z: drive to my local machine using the computer name Net use Z: \\ocoitpc224c\B$ Enter the user name for ‘ocoitpc224c’ : Workgroup\Administrator Enter the password for ‘ocoitpc224c: **Also, the command line netuse functionality is available using a GUI from the Deploy Wizard. Click on the 'Advanced' button. Then click the 'Browse' button located on the 'General' tab. On the 'Open' window you will see the 'Network' button in the bottom right. Click the button to bring up a standard windows Map Network Drive windows. Then map a network drive to your local system using your local computer name. Note: I have to use the local admin account instead of my current user session for the drive mapping to complete successfully. Since I am not copying images back and forth to a network server and just using my local resources this useful shortcut saves me valuable development time with faster copy speeds. I have a 1.5 TB ‘B’ drive on my local computer which offers plenty of space for testing capture and deployments of my OS images. After my image testing is complete, I will copy my image to my network file server for added redundancy. My second tip suggestion is to use solid naming conventions so you can easily identify your .WIM files completely from the file name. I enjoy using the image description field to help describe my images, but you need to use the SDE Deploy wizard to view that info. Of course, you could use the IMAGEX /INFO command to view the architecture type (x86 or x64) of the image file which is an additional step. My naming convention is as follows: Windows Version + Architecture + Image Acronym + Date. For example: Win7_x64_GI_2-1-10.wim or XPSP3_x86_BI_1-1-10.wim The image acronym GI and BI stand for Generic or Base Image. I can quickly and easily identify if it is the base vanilla Windows image with no add-ons or my 'generic' image that has all of my company specific applications installed. Furthermore, I can read the Windows version, processor architecture type, and the date I created the image file all from my file name. I used to add the computer model to the file name, but SDE enables me to have hardware agnostic image files which I can blow on a variety of platforms as previously discussed in an earlier post. Overall, I think you will find that using the net use command for capturing .WIM image files locally and applying a solid naming convention will help you be more efficient in rapid Windows XP-7 image development with SmartDeployment Enterprise for your IT organization. Stay tuned for how to use differencing images for even more efficiency gains in my next post. Aaron Lines IT Consultant

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. Aaron Lines IT Consultant

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. Aaron Lines Email me IT Consultant