May 2009 - Posts
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.
-Chris
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):
Sysprep running:
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.
-Chris
Here are the direct links for the 2 larger /info screen shots.
All 3 images:
http://myitforum.com/cs2/blogs/cnackers/ximage_info_1.jpg
2 images:
http://myitforum.com/cs2/blogs/cnackers/ximage_info_2.jpg
The below post is a combination of information i have learned as well as information i have found on the internet. I posted some "credits" at the bottom to some sources i pulled a few things from.
Also please note that is method is not supported by Microsoft as detailed here http://support.microsoft.com/kb/288344/, as per usual, use at your own risk, although this is a fairly common method.
Additionally, keep in mind that MDT 2008 will integrated mass storage drivers for you when you are only using the workbench, if you are using the integration with SMS 2003, then MDT 2008 will not integrated mass storage drivers for you and a solution like below is needed.
When integrating Mass Storage drivers like the Intel driver into either WinPE or your image I’ve always known the steps i needed to take, but i never really understood where that information was coming from. When i first started with ICH5 (i think), I already had the modifications, so as new versions of the intel driver came out, i simple added the new strings to my existing information to cover the PCI ID’s. So if i ever had a new driver that i needed to start from scratch with, how would i get the information i needed to modify txtsetup.sif?
I would generally recommend that you try using the winpeoem.sif method first, since it a much easier method. If that does not work, then you most likely will need to use this method that involves modifying the txtsetup.sif file.
I will use the Intel driver to demonstrate
Gathering the needed information from the txtsetup.oem file
1) The PCI ID String
Example: 
2) The INF file name
Example: 
3) The SYS file name
Example:
4) The Device driver description quoted (although you can change this to whatever you want, i would recommend you use something descriptive)
Example: 
Copying the necessary files to correct locations
1) Copy INF files to “WinPE Source”\i386\inf
2) Copy SYS file and remaining files to “WinPE Source”\i386\system32\drivers
Modifying the txtsetup.sif
1) Open the file “WinPE Source”\i386\txtsetup.sif
2) Locate the section named [HardwareIdsDatabase]
3) Add each PCI ID like this...
[PCI ID String] = [SYS File name (Without .sys)]
Example: 
4) Locate the section named [SCSI.Load] in the txtsetup.sif
5) Add each INF File name without .inf like this...
[SYS File name (Without .sys)] = [SYS File name],4
“The "4" means that the file is in “WinPE Source”\i386\system32\drivers“
Example: 
6) Locate the section named [SCSI] in the txtsetup.sif
7) Add each INF File name without .inf like this...
[SYS File name (Without .sys)] = [Device driver description quoted]
“The description can be anything you want”
Example: 
Now the documentation I have for the Intel driver also shows the following section needs to be added to [SourceDisksFiles] section in txtsetup.sif
This is the section i have always struggled with the most as far as figuring out where the heck all the commas and numbers come from. I will post what i have been able to find for information below.
First a nice picture that details the information, followed by a much more in depth explanation.
The following line shows the syntax of each line in the [SourceDisksFiles] section:
filename_on_source=diskid,subdir,upgradecode,newinstallcode,spare,spare,newfilename
Extra fields specified by commas (,) are Windows NT—specific.
diskid is used when a floppy disk installation is used. (Or multiple CDs?)
subdir is the directory to which files are copied.
Codes defined in the [WinntDirectories] section of the TXTSETUP.SIF file are used to identify the destination directory.
Sample screenshot:
upgradecode is a single digit that is used if this is an upgrade from an earlier version. It specifies whether the file is copied during the text-mode portion.
Codes in the [Files] Section of TXTSETUP.SIF for File Copy
Status Code - Copy Action
0 - Always copies the file
1 - Copies the file only if it exists in the installation directory
2 - Does not copy the file if it exists in the installation directory
3 - Does not copy the file
newinstallcode is a single digit that is used if this is a fresh installation. It specifies whether the file is copied during the text-mode portion. The same codes are used as for upgrading Windows 2000 and are described in Table 4.3. The newinstallcode is optional; if it is not included, the file is not copied (code = 3).
newfilename is the name to which the file is renamed if it is copied. As an example, consider this line from the [SourceDisksFiles] section.
CODE
autochk.e XE = 1,,,,,,_x,2,0,0
The file AUTOCHK.EXE in this line is on the CD or the disk with diskid d2 defined in the [Media] section. The file also is on Setup Disk 2 (_2), also defined in the [Media] section. The file is installed in directory 2, which is defined in the [WinntDirectories] section. If you look up the [WinntDirectories] section, directory 2 is the System32 subdirectory in the Windows 2000 root directory. The upgrade code and new installation codes are 0, which means that this file always must be copied to the installation directory, whether this is an upgrade from an earlier version of Windows 2000 or a fresh installation.
Taken from:
http://www.msfn.org/board/index.php?showtopic=14852
and
Windows® 2000 Server Professional Reference
By Karanjit S. Siyan Ph.D.
Publisher : New Riders Publishing
Pub Date : July 10, 2000
ISBN : 0-7357-0952-1
Pages : 1848
Although MDT will integrate both network and mass storage drivers for your Lab environment, it does not automatically integrated mass storage drivers for your SMS 2003 OSD Deployment Point/WinPE Boot Source. So when you import that boot source into SMS 2003 OSD, you will not have mass storage support, unless you add it prior to the import.
So looking at your Lab deployment point, you can see it will nicely integrate mass storage drivers for you:
However, if you look at your SMS 2003 deployment point in the workbench, you will not see that option available to you:
So how do we address that? You could manually integrate mass storage support into your PE source, using the method described here. However, the downside is that every time you do an “update” to the deployment point, it will rebuild that boot source and you will lose your mass storage integration that you manually added. Which is fine as long as you remember that before you import the new updated WinPE source into SMS 2003.
Taking advantaged of the “Extrafiles” feature in MDT, we can do a few customizations to ensure that when we build or update our deployment point in the workbench, that our boot source always contains the mass storage support we want.
First, we will want to create a folder to house the files, i typically just name it “Extrafiles” and put it in the Distribution folder.
You will want to build out the structure i have pictured below:
For the sake of it, i would recommend you throw trace32.exe in the \system32 folder so that you can view log files in a friendly view from within WinPE, you can also add anything else you might want to access from within WinPE.
I will use the Intel mass storage driver as an example below since that is what we use and it’s very common for many vendors to require this driver.
So in the \INF folder we will want to put the following files:
In the \DRIVERS folder you will want to put the other files from the driver package:
in \I386 you will want to put your modified txtsetup.sif that contains the necessary information for the Intel mass storage controllers, or whatever controller you are adding support for. If you are using the Intel one, make sure you have add the appropriate lines as per the document linked again here.
Now what we have our necessary folder structure, we will want to make sure we add the extrafiles directory to our SMS 2003 deployment point in the workbench:
Now when you use “update” on the deployment point, the necessary files required for mass storage support will be copied into your WinPE boot source every time.
One less thing to take care of manually :)
I hope this helps, please let me know if you have any questions.
-Chris
Posting this info, so i can remember where i put it :) and so that others can find it helpful.
This info is from a response on the myITforum email list, i asked what people had seen when having both SMS 2003 and SCCM in the same environment. Below is info received from Dale Nemec.
Chris,
As I migrated my SMS 2003 clients to SCCM, I had both SMS 2003 and SCCM 2007 serving the same domain.
The issues I had to watch for included:
- IP Address boundaries - make sure that only SCCM 2007 or SMS 2003 has the IP address(es) in the Site Boundary, otherwise the new SCCM 2007 clients won't know to contact the SCCM Management Point and will try to continue using the SMS 2003 Management Point. The ClientLocation.log file is very helpful in seeing this issue.
- AD Schema Extensions - Both SMS 2003 and SCCM 2007 can co-exist with the SCCM 2007 AD Schema Extensions in place. Wally confirmed this at MMS 2008 last year. Be sure to remote the older SMS 2003 objects out of the Systems Management container when you decommission the SMS 2003 servers.
- SMS 2003 Advanced Clients upgrading to SCCM 2007 Advanced Clients - for some reason my SMS 2003 Advanced Clients would not cleanly upgrade to SCCM 2007 Advanced Clients. I've had to uninstall the SMS 2003 Advanced Client from my client machines and then install the SCCM 2007 Advanced Client onto them. Most issue I'm seeing seem to be related to old/corrupted WMI Repository data.
Good luck!
Dale Nemec
I wrote this report a long time ago, however i saw it pop up in a distribution list today so figured I’d post it. I’m not a SQL guru, but this should work.
Main Query:
SELECT DISTINCT SYS.Name0,SYS.AD_Site_Name0,
SYS.User_Domain0,SYS.User_Name0,
SYS.Operating_System_Name_and0
FROM v_R_System SYS
WHERE SYS.AD_Site_Name0 LIKE @variable
ORDER BY SYS.Name0
Prompt:
begin
if (@__filterwildcard = '')
SELECT DISTINCT SYS.AD_Site_Name0 FROM v_R_System SYS ORDER BY SYS.AD_Site_Name0
else
SELECT DISTINCT SYS.AD_Site_Name0 FROM v_R_System SYS
WHERE SYS.AD_Site_Name0 like @__filterwildcard
ORDER BY SYS.AD_Site_Name0
End
Sometimes it is useful to create a command prompt under the NT Authority/System context to test things. Most often this is a great way to test if an application can install under system context.
One way to do do this is to create a service that allows you to create a system command prompt whenever you start the service.
First you need to create the service:
sc create ntauthcmd binpath= "cmd /K start" type= own type= interact
Then you can use this command to start the service:
sc start ntauthcmd
Now, whenever you start that service, you will have a command prompt under the system context.
