The answer is yes! My first clue for solving this came from deployvista.com, “Using the $OEM$ folder with SCCM 2007 OS Deployments“. To summarize you need to place your $OEM$ files into C:\_SMSTaskSequence\OSD\$OEM$ in order for Windows Setup to use the files. Here is what I did:
- Added my $OEM$ Files to my MDT Settings Package. (The one with unattend.txt, sysprep.inf and customsettings.ini)
- Add Z-CONFIG-CopyOEM.wsf to your MDT Source Files package. I’ve provided it below. (Remember to update DP)
- In your Task Sequence right before “Setup Windows and ConfigMgr” add a new “Run Command Line” task.
- Set the Name to “Copy OEM Files”.
- Set the Command Line to “cscript.exe “%deployroot%\scripts\Z-CONFIG-CopyOEM.wsf”.
- Click the “Package” checkbox and select your MDT Settings Package.
- All Done!
The guts of the script is pretty simple stuff and it works because when you set a Package in a Run Command Line Task the current directory is the path to whatever package you’ve select. In this case the current directory is the MDT Settings package containing our $OEM$ files.
sDest = OEnvironment.GetOSDV4(
"$OEM$ Files will be copied to "
& sDest, LogTypeInfo
sSource = oShell.CurrentDirectory &
"$OEM$ Files will be copied from "
& sSource, LogTypeInfo
oFSO.CopyFolder sSource, sDest
Download the script here.
If you’ve ever had anything to do with maintaining or migrating a fileserver you will probably have experienced issues with MAX_PATH. In Windows the maximum length for a path is MAX_PATH, which is defined as 260 characters. One of the most common errors for MAX_PATH is “Can’t access this folder. Path is too long.” This usually happens when users (those pesky users!) map a drive half way down a directory structure and started creating new files and folders.
You can find more information about MAX_PATH at the following locations:
I’ve seen a number of different ways of finding paths that are too long but my favourite at the moment is using the Microsoft Log Parser. Details:
Once you’ve downloaded LogParser you can run the following command to output a CSV file of paths greater than 250 characters:
LogParser “SELECT Path, Size FROM C:\*.* WHERE STRLEN(Path) > 250″ -i:FS -preserveLastAccTime:ON -o:CSV > Results.csv
Just change the “C:\*.*” to the location you want to check for long paths and Bob’s your uncle.
I booted an SCCM Task Sequence boot image this morning in VMWare Workstation and received the following error: “This application has failed to start because wdi.dll was not found. Re-installing the application may fix this problem“.
Oh of course that makes perfect sense……arhhh actually no. After a bit of searching it appears as thought this is an issue with the VMWare Workstation Drivers. Earlier I’d added the entire drivers directory from the VMWare Tools directory to SCCM. Bad move! All you need is the the vmxnet and scsi directories. Remove all the others, re-generate the Boot Image and you’re away!
Today I was attempting to create a sysprep.xml file for Windows 2008. After opening my WIM file in Windows SIM I got the prompt to generate a Catalog file, clicked Yes and then……Error!! What?? Lets try that again….Error!! Whatever, lets try again, Error!! Ok this time I read the error. “System.Reflection.TargetParameterCountException: Parameter count mismatch.” Ummm, what??
After wasting almost 2 hours chasing this error I found this post on the TechNet Forums: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=3066853&SiteID=17.
The key information is:
Because of the changes in the servicing stack in Windows Vista with Service Pack 1 (SP1) and Windows Server 2008, Windows System Image Manager (Windows SIM) cannot create catalog files for some Windows images of different architecture types. The following list describes the Image Manager architecture types and catalogs that can be created for each one.
x86 Windows SIM:
Can create catalogs for x86, x64, and Itanium-based Windows images.
x64 Windows SIM:
Can create catalogs only for x64 Windows images.
Itanium-based Windows SIM:
Can create catalogs only for Itanium-based Windows images.
Please confirm if what version of Windows SIM you are using. I recommend installing x86 Windows SIM.
Hope it helps.
Tim Quan – MSFT
Update: Michael Niehaus pointed out that this information is available in the updated version of the WAIK 1.1 release notes available at http://www.microsoft.com/downloads/details.aspx?FamilyID=051091e8-51ea-4d2c-96b3-dc9863edebd9&displaylang=en.
I use VMWare Workstation on almost a daily basis. It is without a doubt my favourite piece of software. There is one thing, however, that I find very annoying and that is trying to hit ESC on the startup screen. It is at that point when you need to either hit ESC to get a boot menu or DEL to get into the bios. The VMWare bios splash screen displays for all of about half a second and then gone! So you reboot and try again and again and again…grrrrrr!
Well happily there is a simply solution. Open your .vmx file for the virtual machine you are using and add the following line to the file:
bios.bootDelay = “5000″
I’m not sure how I missed this one or how long it has been available but you can download the source code for MDT 2008 from Microsoft Download. You can learn a lot about how MDT 2008 works and also a lot about managed MMC snap-ins from the MDT 2008 source code. Click here to download.
I spotted an article on Micheal Niehaus’ blog the other day about moving to a single partition when doing OS deployments. You can read the article here.
This very issue arose in the project I am currently involved in and after trying reading and implementing Micheal’s post I found a couple of nuances:
- If there is an OEM partition (like WinRE) then you risk deleting you’re OS partition. OEM partitions are often a hidden partition (Type 0×27) at the start of the disk that allow OEM’s to offer a recovery environment for their customers.
- If there is more than a one extra partition on the disk then ExtendOemPartition=1 won’t really work.
I thought the problem deserved some more attention so I’ve written a script to be included in the “Refresh only” section of “Preinstall” in the Task Sequence that you use to deploy you’re image. The script queries WMI to find how many partition are on the disk that contains C:. If there are any partitions after the C: partition they are removed using diskpart “delete partition”.
Any comments or suggestions please let me know!
I laughed myself silly yesterday when I received an email from Microsoft Support with the following:
“I am sorry for the late reply. Unfortunately our Microsoft network is down since last week. All the domain controllers had to rebuild again. The email system is down, internet is down. So we are unable to communicate with our existing customers.
I will contact you as soon our infrastructure is ready.
Sorry for inconvenient.”
Best excuse for poor service from Microsoft yet!
I’ve been playing with automating MDT 2008 using Powershell and thought I’d start to share some of the info over the next few weeks.
The very first thing you need to do in MDT is create a Distribution Share. It turns out this is exceptionally easy in Powershell. The Microsoft.BDD.ConfigManager.Manager namespace has a method called UpgradeDistributionShare(string location, bool update). Just pass in the location you’d like to create the distribution share at and you’re done! You can set update to true if you are upgrading an existing Distribution Share to MDT 2008.
Here is the code:
"You must specify a Location"
"C:\Program Files\Microsoft Deployment Toolkit\Bin\Microsoft.BDD.ConfigManager.dll"
Quite frequently I underestimate how much space my Virtual Machines need, particularly when doing work with MDT 2008 and SMS 2003. This is exactly what happened today and my SMS virtual wasn’t happy that it had less than 100Mb space on C:. Fortunately it is really easy to resize a vmdk file. I resized my SMS OS partition using the following command:
vmware-vdiskmanager.exe -x 15Gb D:\Virtuals\LABSRV02\Labsrv02.vmdk
This only gets us part way there though. If you were to start the virtual machine after doing the resize with vmware-vdiskmanager.exe windows would indeed see the new space but the partition would be the same size. I’ve noticed that a lot of people use GParted but there is an alternative, WinPE.
Attach a WinPE 2 iso to your VM and boot into WinPE. Then run the following:
select disk 0
select partition 1
The commands above assume that you are resizing the first partition on the first disk. Using extend will only work if the partition you are trying to extend is the last partition on the disk. You can get more information about diskpart here and more information about using the extend command here.