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'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 0x27) 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!

So once you've created a Distribution share with MDT at some point you're going to need a LAB Deployment point. Creating and updating Deployment Points is managed via [Microsoft.BDD.ConfigManager.Manager] in Microsoft.BDD.ConfigManager.dll.

To get stared you need need a DeployManager:
[System.Reflection.Assembly]::LoadFile("C:\Program Files\Microsoft Deployment Toolkit\Bin\Microsoft.BDD.ConfigManager.dll") | Out-Null
$manager = [Microsoft.BDD.ConfigManager.Manager]
$deployManager = $manager::DeployManager

Once you've got a DeployManager you can create a new deployment point using CreateNew(). This returns a generic deployment point which you can then specify what type and settings you need for the deployment point. Specifying the type and settings (ie. all the options on the General, Rules, WinPE tabs) is done by setting some properties on the deployment point object like so:

$deploymentPoint = $deployManager.CreateNew()
$deploymentPoint["Name"] = "LAB"
$deploymentPoint["Type"] = "LAB"
$deploymentPoint["NetworkShare"] = $NetworkShare
$deploymentPoint["LocalSharePath"] = $LocalSharePath
$deploymentPoint["GenerateLiteTouchISO"] = $true
$deploymentPoint["GenerateLiteTouchFlatISO"] = $false
$deploymentPoint["GenerateGenericISO"] = $false
$deploymentPoint["GenerateGenericFlatISO"] = $false

This is not a complete list of properties but it gives you the right idea. Once you have a deployment point you also need to specify which Applications, Task Sequences and Driver Groups you wish to include. For a LAB deployment point this is all of them:

There seems to be a bit of confusion around the place about installing the .NET Framework 3.5 and it's prerequisites. Firstly I'll say that the .NET Framework 3.5 standalone redistributable package available from the Microsoft Download Center contains all the prerequisites for .NET 3.5 except the Windows Installer 3.1 Redistributable. Yes it's true, everything you need is in the one file: dotnetfx35.exe.

Secondly there is some great information on deploying the .NET Framework 3.5 on MSDN at http://msdn2.microsoft.com/en-us/library/cc160717.aspx.

You will see from the article above you can silently install the .NET Framework 3.5 but running the following command:

• dotnetfx35.exe /q /norestart

Wow! Couldn't be easier! However what if you're in an environment where everything is installed via MSIs and undergoes a certain degree of package standardization before deployment??? I found myself in this situation and as it turns out there is a lot of information available on this as well. Aaron Stebner has a wealth of information on installing the .NET Framework. In particular:

• Creating an administrative install point for the .NET Framework 2.0 SP1
• Creating an administrative install point for the .NET Framework 3.0 SP1

There is also a batch script at the bottom of http://msdn2.microsoft.com/en-us/library/cc160717.aspx for creating the Administrator installation points. I had a few problems with the script on MSDN so I used my own version which is included below. Download dotnetfx35.exe from Microsoft Downloads and place it in a temp folder somewhere under a directory called 3.5. I used C:\netFramework\3.5 as my location. Then copy the batch file below into a file called Create35AdminInstall.cmd under C:\netFramework. Double-Click the Batch file and you're away!! When the script is finished you will end up with admin install points for:

• MSXML Parser 6 - msiexec /i netfx35_deploy\AdminInstallPoint\MSXML6_x86\msxml6.msi /qb-
• RGB Rasterizer - msiexec /i netfx35_deploy\AdminInstallPoint\RGBRAST_x86\RGB9RAST_x86.msi /qb-
• .NET Framework 2.0 SP1 - msiexec /i netfx35_deploy\AdminInstallPoint\NETFX20_x86\netfx20a_x86.msi /qb VSEXTUI=1
• .NET Framework 3.0 SP1 - msiexec /i netfx35_deploy\AdminInstallPoint\NETFX30_x86\netfx30a_x86.msi /qb VSEXTUI=1
• .NET Framework 3.5 - msiexec /i netfx35_deploy\AdminInstallPoint\netfx35_x86\vs_setup.msi  /qb VSEXTUI=1

Enjoy!

Create35AdminInstall.cmd

@Echo Off
set WORKFOLDER=%~dp0netfx35_deploy
set dotNetFX35build=%WORKFOLDER%\dotnetfx35.exe
echo Creating Admin Install points for NETFX3 %PROCESSOR_ARCHITECTURE%

REM Create folders where work will be done
md "%WORKFOLDER%\extracted"
md "%WORKFOLDER%\AdminInstallPoint"
md "%WORKFOLDER%\logs"
pushd %WORKFOLDER%

REM Extract the files from the NETFX35 redist SFX
Echo Extract the files from the NETFX35 redist SFX
call "%~dp03.5\dotnetfx35.exe" /q /x:"%WORKFOLDER%\extracted"

REM ------------------------------------------------------------
REM create the MSXML6 x86 admin install point
Echo Create the MSXML6 x86 admin install point
md "%WORKFOLDER%\AdminInstallPoint\MSXML6_x86"
call msiexec /a "%WORKFOLDER%\extracted\wcu\dotNetFramework\dotNetFX30\x86\msxml6.msi" /qb /l*v "%WORKFOLDER%\logs\MSXML6_x86.log" Targetdir="%WORKFOLDER%\AdminInstallPoint\MSXML6_x86"

REM ------------------------------------------------------------
REM create the RGBRAST x86 admin install point
Echo Create the RGBRAST x86 admin install point
md "%WORKFOLDER%\AdminInstallPoint\RGBRAST_x86"
call msiexec /a "%WORKFOLDER%\extracted\wcu\dotNetFramework\dotNetFX30\RGB9RAST_x86.msi" /qb /l*v "%WORKFOLDER%\logs\RGBRAST_x86.log" REBOOT=ReallySuppress Targetdir="%WORKFOLDER%\AdminInstallPoint\RGBRAST_x86"

REM ------------------------------------------------------------
REM Extract NETFX 35 x86 components
Echo Extract NETFX 35 x86 components
md "%WORKFOLDER%\extracted\netfx35_x86"
call "%WORKFOLDER%\extracted\wcu\dotNetFramework\dotNetFX35\x86\netfx35_x86.exe" /q /x: "%WORKFOLDER%\extracted\netfx35_x86"

REM ------------------------------------------------------------
REM create the NETFX35 x86 admin install point
Echo Create the NETFX35 x86 admin install point
md "%WORKFOLDER%\AdminInstallPoint\netfx35_x86"
call msiexec /qb /a "%WORKFOLDER%\extracted\netfx35_x86\vs_setup.msi" USING_EXUIH=1 REBOOT=ReallySuppress /l*v "%WORKFOLDER%\logs\netfx35_x86.log" TARGETDIR="%WORKFOLDER%\AdminInstallPoint\netfx35_x86"

REM ------------------------------------------------------------
REM create the NETFX20 x86 SP1 admin install point
Echo Create the NETFX20 x86 SP1 admin install point

REM 2.0 SP1 files location
Set fx20=%WORKFOLDER%\extracted\wcu\dotNetFramework\dotNetFX20\
md "%WORKFOLDER%\AdminInstallPoint\NETFX20_x86"
call msiexec /a "%fx20%netfx20a_x86.msi" TARGETDIR="%WORKFOLDER%\AdminInstallPoint\NETFX20_x86"
call msiexec /a "%WORKFOLDER%\AdminInstallPoint\NETFX20_x86\netfx20a_x86.msi" PATCH="%fx20%ASPNET.msp;%fx20%CLR.msp;%fx20%CRT.msp;%fx20%NetFX_CA.msp;%fx20%NetFX_Core.msp;%fx20%NetFX_Other.msp;%fx20%PreXP.msp;%fx20%WinForms.msp;%fx20%DW.msp" USING_EXUIH=1 REBOOT=ReallySuppress /l*v "%WORKFOLDER%\logs\netfx20_x86.log"


REM msiexec.exe /i c:\netfx20sp1\x86\AIP\netfx20a_x86.msi /l*v %temp%\netfx20sp1x86log.txt /qb VSEXTUI=1

REM ------------------------------------------------------------
REM create the NETFX30 SP1 x86 admin install point
Echo Create the NETFX30 x86 SP1 admin install point

REM 3.0 SP1 files location
Set fx30=%WORKFOLDER%\extracted\wcu\dotNetFramework\dotNetFX30\
md "%WORKFOLDER%\AdminInstallPoint\NETFX30_x86"
call msiexec /a "%fx30%netfx30a_x86.msi" TARGETDIR="%WORKFOLDER%\AdminInstallPoint\NETFX30_x86"
call msiexec /a "%WORKFOLDER%\AdminInstallPoint\NETFX30_x86\netfx30a_x86.msi" PATCH="%fx30%WCF.msp;%fx30%WCS.msp;%fx30%WF.msp;%fx30%WPF1.msp;%fx30%WPF2.msp;%fx30%WPF_Other.msp;%fx30%XPS.msp;%fx30%WF_32.msp;%fx30%WPF2_32.msp;%fx30%WPF_Other_32.msp" USING_EXUIH=1 REBOOT=ReallySuppress /l*v "%WORKFOLDER%\logs\netfx30_x86.log"

pause

You may remember a post I did a little while ago about sorting applications in the Applications.xml file within BDD 2007. Well it seems that the Microsoft Deployment Toolkit suffers from the same problem as BDD 2007 so I've added a version to support MDT as well. You can get the new version from the original post here.

The Automated Installation Kit (AIK) for Windows Vista SP1 and Windows Server 2008 has been released head over here to get it.

Head on over to Richard Smith's blog to get GImageX. GImageX is a GUI for imageX. The original verison was written in AutoIT but this version has been completely rewritten in C++. The new version v2.0.1 BETA feature list on Richard's site:

• Native x86 and x64 versions entirely written in C++.  Tiny ~100KB executable.
• Doesn’t use the imagex.exe utility at all – instead it uses the WIMGAPI interface (the wimgapi.dll file from the imagex directory)
• Progress bars, time elapsed, time remaining, file counts have been added
• Clean “abort” option
• Ability to mount, change and get info on WIM images

So what are you waiting for, click here to get it.

Microsoft Deployment is the next version of BDD and the final version can be download here.

The brief from MS Dowloads:
Microsoft Deployment is the next version of Business Desktop Deployment (BDD) 2007. It is the recommended process and toolset to automate desktop and server deployment. Microsoft Deployment provides detailed guidance and job aids for every organizational role involved with large-scale deployment projects.

You may have read an article by Ben Hunter on sorting the applications in BDD so they are easier to find when adding them to the Task Sequencer of Database Role. The article can be found here.

An issue arose the other day that necessitated the re-ordering of application in BDD. The current build process that I am working on uses Windows Powershell to do a lot of post build customizations. In testing we found that Powershell was being installed before the .Net Framework. This seemed odd to me as we are using a role to installed our Tier 1 application.

After looking into the issue a bit more it seems that BDD does not honour the order of application defined in the role but installs them in the order they are listed in Applications.xml. This was a problem for us so I set about extending the bddsort application so I could specify any order I wanted. Hence BDD Application Sorter was born.

The program is simple to use, all you need to do is open the Applications.xml file, re-order the application and save the file again. I make a back of Applications.xml just in case but I have never had an issue with the program to date.

Anyway, BDD Application Sorter is attached below. Enjoy!

BBDAppsSort.zip (13.74 KB)

Update: New Version to support Microsoft Deployment Toolkit

The version below will work for the Microsoft Deployment Toolkit
MDTAppSort.zip (23.44 KB)

I've been using BDD 2007 a lot lately and I thought it would be nice to get live logging details from BDD rather than using the many .log files that are created. After searching around for possible solution I settled on using a combination of a C# application using HttpListener and a vbscript using MSXML2.ServerXMLHTTP. The logging application is shown below.

To setup the remote logger is fairly simple and the files needed are included below. To use the remote logger do the following:

1. Download BDD Remote Logger.zip
2. Copy ZTIGather.xml and ZTIUtility.vbs into your Distribution$\Scripts directory. Do a file compare if you are interested in the changes. There is an addition properity added to ZTIGather.xml called RemoteLogURL and a few lines added to the Logging Class in ZTIUtility.vbs.
3. Add RemoteLogURL=http://yourmachine:8081/
4. Start BDDRemoteLogger.exe and ensure that the url prefix is the name of your machine. The URL Prefix in BDDRemoteLogger must match what you have in your RemoteLogURL value.
5. Click start on BDDRemoteLogger and Run BDD as normal.

If you run BDD with RemoteLogURL present and you BDDRemoteLogger is not listening for requests then it will considerably slow down the BDD logging (approximately 1sec per entry). So if RemoteLogURL is present in Bootstrap.ini then make sure you have the logger running. If RemoteLogURL is not present BDD will run as norma.

If you've got any questions or comments please comment to this post.

Last week I needed to add a large number of hotfixes to the Task Sequencer for an XP BDD 2007 build. After adding the first few by hand I quickly sought after an easier method. As I result I came up with the code below. Althougth it may not be that useful to anyone else I thought I'd post it anyway so people can start to see what is possible using Powershell with BDD.

To use this function as is you need to have a Security Updates group in the task sequencer already. Then create a directory called Hotfixes under Applications in your Distribution point. Download the hotfix into the hotfixes directory and then run Add-Hotfix "hotfixname" "Path to TS.xml". So for a hotfix called WindowsXP-KB923191-x86-ENU.exe you would type something like: Add-Hotfix "WindowsXP-KB923191-x86-ENU" "C:\Data\TS.xml"

function Add-Hotfix ([string] $hotfix, [string]$TSFile) {
   $ts = [xml](Get-Content -read -1 $TSFile)
   $updates = $ts.psbase.SelectSingleNode("//group[@name='Security Updates']")

   $step = $ts.CreateElement("step")

   $name = $ts.CreateAttribute("name")
   $name.psbase.Value = "Microsoft Update - " + $hotfix
   $step.SetAttributeNode($name)

   $disable = $ts.CreateAttribute("disable")
   $disable.psbase.Value = "false"
   $step.SetAttributeNode($disable)

   $continueOnError = $ts.CreateAttribute("continueOnError")
   $continueOnError.psbase.Value = "false"
   $step.SetAttributeNode($continueOnError)

   $successCodeList = $ts.CreateAttribute("successCodeList")
   $successCodeList.psbase.Value = "0 3010"
   $step.SetAttributeNode($successCodeList)

   $description = $ts.CreateAttribute("description")
   $description.psbase.Value = ""
   $step.SetAttributeNode($description)
   
   $startIn = $ts.CreateAttribute("startIn")
   $startIn.psbase.Value = "%DEPLOYROOT%\Applications\Hotfixes"$step.SetAttributeNode($startIn)

   $action = $ts.CreateElement("action")
   $action.psbase.InnerText = $hotfix + ".exe /quiet /passive /norestart"
   $step.AppendChild($action)

   $updates.AppendChild($step)
   
   $ts.Save($TSFile)
}

The virtual machine that I have been using to do some Desktop Deployment work ran out of space today. I notice the directories taking up all the space where the RemoteInstall and Distribution directories that belong to BDD and WDS. So I decided to add another virtual disk and move those two directories.

WDS
Moving WDS was easy, stop the WDS service then do the following:

1. Cut and Past the RemoteInstall Directory to where you'd like it.
2. Reshare the RemoteInstall directory as REMINST
3. Open regedit and change HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\TFTPD\Parameters\Directory to the new location of RemoteInstall.
4. Start WDS and you're away.

BDD 2007
BDD 2007 was fairly striaght forward was well. Make sure you've closed the workbench and do the following:

1. Move the Distribution directory to where you'd like it.
2. Open regedit and change HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BDD 2007\Distribution_Dir to the new location of the Distrubution directory.

You can also rename these directories as well.

There, that was fairly painless.

I've been working with Windows System Image Manager today and found myself searching around for the right input locale to use for Australia.

Microsoft have a list of the right locales to use at http://msdn2.microsoft.com/en-us/library/ms776260.aspx

For us aussies,
Locale identifier:0x0c09
Locale: English (Australia)
Locale name: en-AU
Script tag: Latn
ANSI code page: 1252

I noticed today that WinPE 2, like all the WinPEs before it, does not have a built in network card driver for VMWare. Now you could add a driver to WinPE 2 by using the peimg /inf command but I just wanted to test something really quickly and didn't want the hastle of making a new WinPE 2 disk.

So I discovered you can tell VMWare to use emulate an Intel e1000 network card which works great with WinPE 2. Just add ethernet0.VirtualDev = "e1000" to your .vmx file!!

Most antivirus products these days have a unique ID stored in the registry so that management consoles can distinguish the clients. In you are using some form of cloning in your organisation this can cause problems with clients not updating or reporting back to the management console.

This week I ran into this very issue with eTrustITM v8. Fortunately all you need to do is delete a couple of ID values from the registry before running sysprep.

For eTrustITM delete the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\eTrustITM\CurrentVersion\ID

For eTrust Antivirus delete the following:
HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\eTrustAntivirus\CurrentVersion\ID

Remember to do this immediately before running sysprep otherwise the clients will register again, particularly if you do a reboot before running sysprep. In my builds I usually have a sysprep.cmd that deletes keys like this and then runs sysprep.exe.

The final version of BDD 2007 has been released. Get it here.

Microsoft have just released BDD 2007 RC1. BDD 2007 give best practice guidance on how to deploy Windows Vista and Office 2007.

Information about the technologies used in BDD 2007 are at http://www.microsoft.com/technet/windowsvista/deploy/depenhnc.mspx.

Go to https://connect.microsoft.com to download.

I've been doing some work with Zero Touch Installation lately and have certainly come across my fair share of problems. Fortunately you can get a lot of debugging information out of ZTI. THere is a great article OSD and ZTI Troubleshooting Tips that has some excellent tips on debugging.

One thing that I found that caused me grief for at least a few hours was the 80004005 error. According to the article mention above the causes are commonly:
-Wrong PackageID in customsettings.ini
-Failure to resolve MP or DP using FQDN
-Missing NIC drivers in Winpe

I found that I got this error because osd.debug existed on the machine I was testing on. If you're testing your deployment CD's make sure you do a diskpart first or at least remove osd.debug.

To mount an SDI file so that you can work with it you usually use the utility called sdiloader.exe that comes with the Windows XP Embedded Tools. Where's the fun in that I say!!

Create on of these guys:

Set oSDIMount = CreateObject("SDIAUT.SDIMountedDisks")

And then you can use:
oSDIMount.Add sTempImage
and
oSDIMount.Remove index-1

I've provided an example script so you don't have to do any real coding: MountSDI.vbs (2.22 KB)

Continuing on from my first post Creating SDI Images using VBScript I am going to look at a more complete example here. I've also attached a working script.MakeSDI.vbs (4.76 KB)

Previously we saw that you can create a new SDI image doing the following:
Set oSDIFile = oSDI.CreateImage(sImage, SDICREATENEW)
Now this isn't really all that useful because without a disk blob inside the SDI file you cannot partition and format the SDI file.

Now I'll leave it to someone more knowledgable than myself to explain exactly what a DISK blog is but you create one by using oSDIFile.Blobs.Allocate DISK, nLo, nHi. The signature for Allocate is:

Sub Allocate(ByVal ldwType As Long, ByVal ldwSizeLowPart As Long, [ByVal ldwSizeHighPart As Long])

Confused?? I was but if you take a look in SDIMgr.swf from the Windows XP Embedded Tools you'll be able to extract just the bits you need. I've provided them below and don't forget the example script that is attached.

Enjoy!

When you create an SDI image with the view of using it to create a bootable Windows PE or Bart PE disk one of the steps is to use diskpart or Device Manager to partition and format the image. Recently I tried to automate this process to my own demise. In the diskpart script that I used I had the line select disk 1, which was a terrible idea because when I ran it on another machine it formatted the HDD. Oops!

To get around this I thought I'd ask WMI what the index of my SDI Disk is before running diskpart, the result:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
   "SELECT * FROM Win32_DiskDrive WHERE Caption = 'SDIDisk'",,48)

For Each objItem In colItems 
   WScript.Echo "-----------------------------------"
   WScript.Echo "Win32_DiskDrive instance"
   WScript.Echo "-----------------------------------"
   WScript.Echo "Index: " & objItem.Index
   WScript.Echo "Name: " & objItem.Name
   WScript.Echo "Partitions: " & objItem.Partitions
   WScript.Echo "Size: " & objItem.Size
Next

Index is the Property that matches up with the Disk# you see in Device Manager. Keep in mind that if you have a couple of SDI images loaded you'll get them all back. In my script I've used the Partition Property to distinguish between an SDI I have just created and one that I left mounted previously.

I have been using SDI Images to make fast-loading Windows PE and BartPE boot disk using a technique I found over here: http://www.myitforum.com/articles/8/view.asp?id=8832

Typically you need to use SDIMgr.wsf and SDILoader.exe that come with Windows XP Embedded to create SDI file and mount them. This however is not the only way. All you need is a file called sdiaut.dll and of course the SDI driver. If you've installed the Windows XP Embedded tools as per the article above you'll have both of these.

sdiaut.dll is the SDI Automation dll and can be instantiated by like so:

Dim oSDI : Set oSDI = CreateObject("SDIAUT.SDI")

To Create an SDI Image it is as simple as:

Const SDICREATENEW = 1
Dim oSDI : Set oSDI = CreateObject("SDIAUT.SDI")
Dim fs : Set