This article describes the reasons why you cannot use the ImageX.exe tool as a backup tool on a Windows Vista-based computer. The ImageX.exe tool ships as part of the Windows Automated Installation Kit (WAIK).
You can use the ImageX.exe tool to capture an operating system installation image on which you have run Sysprep (Sysprep.exe) from the Windows Preinstallation Environment (Windows PE). You can then deploy the operating system installation image on another computer.
Although the ImageX.exe tool may appear to be a mechanism to create an image of a computer for backup, there are several issues that prevent using the ImageX.exe tool as a supported backup mechanism.
The following are the issues when you use the ImageX.exe tool as a backup mechanism:
- Extended attributes are lost.
- The ImageX.exe tool only applies reparse points that are symbolic links or junctions.
- Sparse files on the system are captured and applied. However, the sparse files are no longer sparse after they have been applied.
- Object IDs on files are lost in the capture process or in the apply process.
- Windows Vista Ultimate
- Windows Vista Enterprise
- Windows Vista Business
- Windows Vista Home Premium
- Windows Vista Home Basic
- Windows Vista Starter
Improving Your Image: Sector-Based, File-Based, and Sysprep – What Makes the Most Sense? Part 3: Deploy-time Build Automation and Recommendations
Jeremy Chapman has created the third blog in a series on the benefits of using package based imaging tools.
Read the third post here.
“This is the third and final blog in the series . In the last blog, The Pros and Cons, I covered the main benefits and underlying drawbacks of file-based and sector-based core images. I intentionally stuck to core image files (the .WIM, .V2I, .GHO, .TIB, .VHD, etc. files themselves) and purposely left out the automation needed to tailor installations at install-time using automation. The automation will actually play a role into the overall recommendations of what type of image to use – file or sector-based. I would argue that thin, file-based images would make a lot less sense if the automation wasn’t there to support the additional functions.”
Integrating Microsoft Deployment Toolkit 2010 Update 1 With System Center Configuration Manager 2007 SP2/R2 – Part 2 “Boot Images”
This will be a
quick-start guide for integrating MDT 2010 Update 1 with ConfigMgr
SP2/R2. This information is provided as-is.
This will be a
three part series covering the Setup, Boot Images and Task Sequences.
If you want
specific information on UDI (User Drive Installation) setup and components,
then I would point you to one of my previous posts on UDI.
Creating a Microsoft Deployment Toolkit based Boot Image
When MDT is integrated with ConfigMgr, a new option is available in the ConfigMgr console when creating a new Boot Image:
If we select this option, we are presented with a wizard to create a new MDT based boot image for ConfigMgr.
The first screen requires us to provide a source directory for the boot image:
I will typically recommend a path similar to below, putting all boot images in a subfolder called “boot”, and naming the folder with something descriptive.
Once you have entered in the path, you can click “Next” to proceed to the next screen.
Next, we need to provide the name of the Boot Image we are creating, and the version and any other comments if desired.
Click on “Next”:
The “Image Options” page has several selections that we can choose from.
First we can select the architecture of the boot image we want to create:
Next we can select to include ADO components (necessary for access to SQL databases) and optional fonts:
We can also select to add a pre-execution hook/media hook to enable the Deployment Wizard for the boot media. By default this will give us a Computer Name prompt for any unknown device, however this can be expanded to launch a custom front-end or other custom options.
We can also opt to include a custom background image into our boot image:
Lastly, we can choose an Extra directory to add if we want to automatically include additional files to our boot image, for example putting Trace32 into our image for easier reading of log files.
I’m going to add the Media Hook and include an Extra Files in this example:
My extra files directory simply contains Trace32:
The next screen presents you with a summary of the options you selected:
Click on “Next”:
The final screen, will show a confirmation of successful boot image creation:
Click “Finish” to exit:
Once completed, you will now have a new boot image under the Boot Images node in the ConfigMgr console:
Lets open the properties of the boot image:
Under the Data Source tab, you will see that the source points to the directory we had specifies previously:
On the “Windows PE” tab we have a few options we’ll want to set:
You will want to enable command prompt support for testing, so you can open up Trace32 and view log files. This isn’t recommended for your production boot image, however many people will leave it enabled to be able to quick troubleshoot. However, there is a security risk in having this left enabled.
You can also add drivers to your boot image in this tab, however if you have to add multiple drivers, it’s much easier to do this from the drivers node rather than selecting the drivers from here. Please keep in mind that the boot image is based upon Windows 7 and thus you will need Windows 7 drivers for the boot image, and for the appropriate architecture.
Adding from the Drivers node can be easier if you have multiple drivers, as you can select them all and then select “Add or Remove Drivers to Boot Images”
You would also see your custom background set here if you had previously set that in the wizard. Or you can change it here if ever needed.
Once you have made the appropriate changes, you will be prompted to update the boot images if required. I typically say “No” here and finish adding my drivers and any other changes I need, then add the boot image to the Distribution Points manually. Otherwise you can end up updating the boot image several times as you are making changes.
I will not cover adding the boot image to the Distribution Points in this guide as I assume you already have that knowledge. Keep in mind whenever drivers are added/removed you will have to recreate the boot image and update the DP’s.
In order to assign the boot image to a Task Sequence, we will need to go into the Task Sequence properties box.
Go to the “Advanced” tab:
Pick our custom boot image we created:
Select “Ok” again:
Manually modifying the boot image to add/remove/replace files
If you want to later add additional files to the boot image, this can be done using Imagex and the Deployment Tools Command Prompt (part of the Windows Automated Installation Toolkit aka WAIK).
Open up the command prompt:
Make a local directory to mount the image to, I generally use “C:\Mount”:
Next we will want to mount our image to that directory so we can add files to it. (DO NOT mount the WinPE.PackageID.WIM file)
You want to mount the “WinPE.Wim” using the command line:
Imagex /mountrw [path]\winpe.wim 1 [destination]
The “1” is the image index, if you need to use a different index, be sure to change that to the appropriate index.
If you just want to verify files in the image, you can use /mount instead (read-only) access.
Successfully mounted image:
Through explorer, we can see the files contained in the image now:
If we browse to windows\system32 we can see that our Trace32.exe is there now that we had included in our Extrafiles directory when we created the boot image:
Using explorer, you can add/remove any files you need to the c:\mount directory. Once completed, close explorer and return to your Deployment Tools command prompt.
To just unmount an image and discard any changes, use:
imagex /unmount [mountdir]
Example: imagex /unmount c:\mount
To save your changes, you need to commit the changes to the image and unmount the image. This can be done together using the following command:
imagex /commit /unmount [path]
Example: imagex /commit /unmount c:\mount
Once you have successfully unmounted the image, then be sure to update your Distribution Points to reflect the new changes you have made.
Improving Your Image: Sector-Based, File-Based, and Sysprep – What Makes the Most Sense? Part 2: The Pros and Cons.
Jeremy Chapman has created the second blog in a series on the benefits of using package based imaging tools.
Read the second post here.
“Welcome to blog number two in the series where we’ll look at file-based images versus sector-based images. We’ve already done the tools primer and defined the terms again in the last blog post. Now we actually get some real work done by comparing the “tried-and-true approach” of sector-based images that most of us (including me) have grown up with and the relatively newer approach of composing installations with “builds” at deploy time using file-based “core images” (I defined the terms in quotes in the first blog of the series in case you are wondering why I used quotes). Beware, this blog doesn’t have any pictures or pretty screenshots.”
Great TechNet article on building your image.
Improving Your Image: Sector-Based, File-Based, and Sysprep – What Makes the Most Sense? Part 1: Terms and Windows Tools Primer
Jeremy Chapman has created the first blog in a series on the benefits of using package based imaging tools.
Read the first post here.
“Welcome to blog number one in the series of imaging and image composition. Last week, Stephen kicked off the series in the Springboard Series Insider Newsletter and I’ll try to get through this in three or four blog posts, but the nature of this discussion can almost be constituted as a religion. In that sense, there is never a perfectly correct answer. Like any good IT pro, when someone asks a question like what is the best way to do imaging, manage drivers, etc. – you’ll typically want to respond with “it depends.””
Here is a video showing you how to build a bootable Windows 7 VHD from the Windows 7 install.wim using diskpart.exe and imagex.exe. Very cool stuff!
About this Video
This command line demonstration explains how to build a bootable Windows 7 VHD image from a Windows 7 "install.wim" file using diskpart.exe and imagex.exe. The demonstration continues with an explanation of how to configure the boot entry using bcdedit.exe and explains the limitations of VHD Boot. See the Windows 7 VHD Overview page for more information about this technology.
The below information is provided as is, please test and realize you are using this information at your own risk.
This process sadly won’t work with SMS 2003, so until i have it ready to go in my SCCM test environment I cannot verify that this works 100%. However, I did run it by “Microsoft” and my source said it should work just fine in Configuration Manager. Once again, i believe i owe my source a lot of beer. 🙂
Really, it’s pretty simple. We need to set the TS variable called “OSDImageIndex”.
So we need to create a new Task Sequence step to set a TS variable.
I’m going to call this step “Set Image Index” seems.. clear enough.
The value will be the value of the image index you want to use, 1,2,3 whatever is the index of the image you want to select. Now you can parse this variable a number of ways. You could use a model query, or anything else you can think of. You also will want multiple steps so that can set the various indexes depending on how many images you have in your .wim file.
So for the sake of example, lets keep it simple.
I have a image.wim file i’m going to use that has 3 images in it.
Index 1 – ACPI Windows XP SP3
Index 2 – Advanced ACPI Windows XP SP3
Index 3 – Windows XP SP3 Tablet
Lets create a model query for a HP NC6000 notebook, which i know is a Advanced ACPI hardware device. I need to set my TS variable value to “2”, so that i select my Advanced ACPI image from my .wim file. If i’m not deploying to a HP NC6000, then the default “1” is just fine and dandy.
Now I need to create a model query so that this step will only run for my HP NC6000.
Here is my WMI Query for the NC6000, i use the %…% so i don’t have to worry about the various HP Part #’s, if you have any HP devices, you know what i’m talking about.
Now i have my query, so when my TS runs, it will detect that i have a HP NC6000 laptop based on my query, and set my image index to the appropriate image. If i don’t have a HP NC6000 laptop, then it will use the first index and i’m still good to go.
I haven’t thought a clever way to identify the tablet models quite yet, i could use a model query, but i think i can come up with something more clever, so once i do, i will add that to this post. I was thinking about using something along the lines of the %istablet% custom query that you can do in customsettings.ini but i need to think on it for awhile.
Hope that helps, let me know if you have any questions.
This information is provided as is, this can be a complicated process, so you do so at your own risk. I am also unsure of what level of “supported-ness” (i think i made that word up) this has by Microsoft, so again, you do so at your own risk. 🙂
Now that we’ve stated the usual stuff, lets begin….
Here are the steps I used to combine my multiple images into a single .wim. In my case this is an XP ACPI image, XP Advanced ACPI image, and a XP Tablet image.
Before i ran sysprep and any of my virtual machines to capture them, i always stop the SMS client service and clean the SMS certificate first:
This is the sysprep command we want to run on our reference machine(s) (a virtual machine in my case):
Once the machine has been shutdown, then boot from your WinPE CD, I’m using the generic OSD cd created by MDT 2008 workbench that i’ve added imagex support to:
Imagex capturing the 1st image, i mapped a Z: drive to my laptop to upload the images to:
Making progress, we’ve got our first capture completed:
So now I need to revert to a snapshot so i can switch my HAL and create my Advanced APCI Image. I’ll skip the first few screenshots on this, since i’m basically do the same thing until i get to the winpe environment again.
Original HAL type:
My new HAL type, yet another reason that building your reference image in a virtual machine is the way to go, try this on a physical machine 🙂
After i sysprep’d the machine and booted my generic OSD disk with imagex support, I ran the append command to add the 2nd image contents to the original .wim we captured:
And now we have our appended image results:
Now here is a screenshot to show the differences. So what i did prior to the append capture is i created a stand-alone capture of our 2nd image (Advanced APCI) to show the size differences. So my original xpimage_1.wim before the append was the same size as you see for xpimage2.wim, so now i’ve combined xpimage_1.wim with the data in xpimage2.wim and you see it has only grown a few megs. Very cool!
Here is the information on the new xpimage_1.wim file provided by the /info command, you can see there are 2 images in the .wim file:
You can see the names of the individual images and that we do in fact have 2 images within the single .wim file. Again, very cool!
So now i’m going to go one step further and add my Tablet image as well:
Here is my tablet VM loaded up, just need to login and run sysprep:
Again, sysprep doing it’s thing on the machine:
Again, i’m going to do a stand-alone capture first, so i can show the size difference (real world). Here is the size of my tablet reference image:
Now we’ll append the xpimage_1.wim with the tablet image which will now be our 3rd image in that .wim file
Here we can see the new xpimage_1.wim has grown again now that we have the tablet image integrated as well:
Here again we can see the results of our /info command and see that we do in fact have all 3 images in the single .wim file:
So there we go, we have successfully integrated 3 separate images into a single .wim file.
In “Part 2” i will cover modifying the Task Sequence.
Please let me know if you have any questions.
Here are the direct links for the 2 larger /info screen shots.
All 3 images: