Search the Community

Showing results for tags 'imaging'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Windows Deployment
    • SmartDeploy Enterprise
    • General Deployment Discussion
  • Deployment Components & Tools
    • SmartDeploy Imaging Component (SmartWIM)
    • SmartDeploy Virtual Disk Component (SmartVDK)
  • Knowledge Base
    • SmartDeploy Enterprise


  • Community Calendar


  • Smart Image Deployment
  • Devon's Blog
  • Allen's Blog
  • Erik's Blog

Found 7 results

  1. While imaging less than 10 computers at a time (sometimes less than 5 computers), we are getting reports from our network infrastructure team that network bandwidth is maxed out and saturated to the point that all users on campus cannot utilize any network assets. We have a 1GB backbone/switches throughout campus and all imaging communication resides on premise inside our DMZ. We usually image via unicast to our WDS server and expect to be able to image up to ~25 without speed issues before going with multicast transmissions, but are still having network speed issues with less than 10 at one time. We have been able to image successfully in the past without speed issues, but we are trying to pinpoint what has changed since then causing our bottle-neck. Our image size has actually decreased in size to 10.4GB. Any input is appreciated.
  2. Hello, We are looking to use SmartDeploy in a manufacturing venue, where we deploy systems with different applications. We would like to use Differentials for app packages. Example: Laptop 1 needs Windows 10 with Applications A and B. Laptop 2 needs Windows 10 with Applications B and D. Laptop 3 needs Windows 10 with Applications A and C. Can we have a differential for each Application, and select multiple DWM files during deployment?
  3. 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
  4. Hi, When we try to capture the image of the VDI, it throws error 90200 stating that the WIM Image Name already exists... but it doesnt.... Any ideas? Thanks Adam
  5. Hi Everyone, I am a new user to SmartDeploy. I'm trying to wrap my head around differencing images so I have a few questions. -Would I use differencing images if I have a base image with the general apps all my users have, then expand upon them to add the additional software needed for different images? So for example, most of my users need all of the Windows Updates, Office, and Adobe Products. So that's my base "generic" image. Now I have users that need CADD software. How would I go about making a differencing image based on that? -If differencing isn't what I need in this cenario, could someone explain what is best? I have about 10 different software scenarios for different images and I'd like to keep the footprint as small as possible. Thank You in advance for your help
  6. 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
  7. 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