So you want to add the $OEM$ folder to your SCCM 2007 OS Deployments?

Well, if you just add the $OEM$ folder to the package (any location) it will be skipped… The reason is because the “Setup Windows and ConfigMgr” action adds (or overwrites) the OemFilesPath=C:\_SMSTaskSequence\OSD\$OEM$ value in unattend.txt before starting Winnt32.exe

The workaround is simple. Just copy your $OEM$ folder to C:\_SMSTaskSequence\OSD as a Custom Action before the “Setup Windows and ConfigMgr” (You will have to create the OSD subfolder in C:\_SMSTaskSequence first)

If you add a well formatted cmdlines.txt file to C:\_SMSTaskSequence\OSD\$OEM$ it is smart enough to merge your cmdlines settings with its own settings (the OSDSETUPHOOK.)

If you need a sample script for copying the $OEM$ directory, check out this nice entry

Can you use $OEM$ Files with SCCM 2007 OS Deployments?
http://blog.project84.net/2008/10/16/CanYouUseOEMFilesWithSCCM2007OSDeployments.aspx

The default “Setup Windows and ConfigMgr” SCCM action will effectively replace all variables in sysprep.inf

And since that action is run under WinPE, the %WINDIR% variable will be replaced with X:\Windows.

So never, ever use that variable in sysprep.inf… (unless you really deploy Windows to X: which I highly doubt  🙂  )

This is by design….

Tired of using the ConfigMgr console just because you need a new SCCM Task Sequence boot media (WinPE)? … Well, you don’t have to…

In the ConfigMgr SDK there is a API (tsmediaapi) that can be used together with a vbscript….

Step-by-step

1. Download the ConfigMgr SDK, and install to the default location  (http://www.microsoft.com/downloads/thankyou.aspx?familyId=064a995f-ef13-4200-81ad-e3af6218edcc&displayLang=en)
    
2. Register the tsmediaapi.dll
    
   regsvr32 “C:\Program Files\Microsoft System Center Configuration Manager 2007 SDK\Samples\OperatingSystemDeployment\CreateTSMediaAPI\tsmediaapi.dll”
    
3. Download the below script and, edit the necessary variables (see header of the script). 
   http://www.deployvista.com/Repository/tabid/71/ctl/EntryDetails/mid/396/EntryId/42/language/en-US/Default.aspx

The HAL Replacement script for MDT 2008 (LiteTouch and ZeroTouch) has been updated with support for XP SP3 and SCCM 2007.

Note: 2008-12-23, added standalone version for users running third party deployment solution like Intel LANDesk or Altiris,

Download link:
http://www.deployvista.com/Repository/tabid/71/EntryId/53/DMXModule/396/ctl/EntryDetails/mid/396/language/sv-SE/Default.aspx

 

This is a step-by-step guide to boot DOS 7.10 images from Windows Deployment Services (WDS).

Booting DOS 7.10 images from Windows Deployment Services (WDS)

1. Create a DOS 7.10 image file (.ima) using winimage 8.10 (http://www.winimage.com). You can also download a DOS boot image from http://www.bootdisk.com/ and use winimage to convert it from .exe to .ima. 
    
2. Download and extract syslinux from http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-3.71.zip (it contains pxelinux)
    
3. Copy the syslinux-3.71\com32\menu\vesamenu.c32 file to your WDS Server, D:\RemoteInstall\Boot\x86 
    
4. Copy the syslinux-3.71\memdisk\memdisk file to your WDS Server, D:\RemoteInstall\Boot\x86
    
5. Copy the syslinux-3.71\core\pxelinux.o to your WDS Server, D:\RemoteInstall\Boot\x86, rename it to pxelinux.com
    
6. Download a nice background image (http://www.deployvista.com/Portals/0/DeploymentBackground.png), and save it in D:\RemoteInstall\Boot\x86 
    
7. In the D:\RemoteInstall\Boot\x86 folders, make a copy of pxeboot.n12 and rename it to pxeboot.0
    
8. Configure WDS to use the pxelinux.com boot file (Server properties, Boot tab)
    
9. In the D:\RemoteInstall\Boot\x64 or D:\RemoteInstall\Boot\x86 folders, create a subfolder called pxelinux.cfg
    
10. In the D:\RemoteInstall\Boot\x64\pxelinux.cfg or D:\RemoteInstall\Boot\x86\pxelinux.cfg folders, create a file named default with the following settings

    DEFAULT      vesamenu.c32
    PROMPT       0
    NOESCAPE     0
    ALLOWOPTIONS 0
    # Timeout in units of 1/10 s
    TIMEOUT 300
    MENU WIDTH 40
    MENU MARGIN 0
    MENU ROWS 12
    MENU TIMEOUTROW 14
    MENU HSHIFT 5
    MENU VSHIFT 2
    MENU COLOR BORDER 30;44       #00000000 #00000000 none
    MENU COLOR TABMSG 1;36;44     #00000000 #00000000 none
    MENU COLOR TITLE 1;36;44     #00000000 #00000000 none
    MENU COLOR SEL   30;47       #40000000 #20ffffff
    MENU BACKGROUND DeploymentBackground.png

    MENU TITLE PXE Boot menu
    MENU WIDTH 80
    MENU MARGIN 18
    MENU ROWS 4
     
    LABEL wds
     MENU       DEFAULT
     MENU       LABEL Windows Deployment Services
     KERNEL     pxeboot.0
     
    LABEL local
     MENU LABEL Boot from Harddisk
     LOCALBOOT 0
     
    LABEL dos710
     MENU LABEL DOS 7.10
     KERNEL memdisk keeppxe
     append initrd=dos710.ima

It turns out that the well-known security patch for DNS last summer breaks WDS, but only if DNS and WDS are running on the same box. This is also valid for Windows Server 2008 and Windows Server 2008 R2 which has the patch built-in.

In brief, the issue with DNS and WDS on the same machine is that DNS will bind to 2500 ports in the ephemeral port range (49152-65535). Since the 2500 ports are randomly chosen, there’s a chance that those 2500 ports will completely cover WDS’s port range (which is 6400 to 65000 by default). Since the DNS ports are randomly chosen each time the DNS service starts, it’s possible that changing the WDS port range will fix the problem now, but next time the machine restarts they will conflict again.

For this reason, the proper fix is to make the WDS port range larger than the DNS port range. There’s also an option in Windows Server 2008 R2 to have WinSock dynamically allocate ports to WDS that aren’t in use, which is controlled by a registry key as indicated below. However, this fix may not work if you are using a third party firewall that requires a rule for WDS since the ports chosen will be random.

 

Workaround #1: 
Don’t install DNS on the same server as WDS  🙂

Workaround #2: 
If you are running Windows Server 2003 or Windows Server 2008, on the WDS Server properties, in the network settings tab, change the range from say 50000 to 65000 (assuming you don’t have any other apps using these ports). You can also set this from the command line using WDSUTIL:

wdsutil /set-Server /Transport /StartPort:50000 /EndPort:65000

If you are running Windows Server 2008 R2 you can also configure WDS to dynamically query WinSock for available ports instead of using a port range. This is done by setting the UdpPortPolicy value in the registry to 0. You will find it in the HKLM\System\CurrentControlSet\Services\WDSServer\Parameters key. You need to restart WDS after changing the value.

For more info, see: http://support.microsoft.com/kb/977512 

 

As you probably know, WDS doesn’t provide any security for it’s native boot images (Windows PE 2.x). However, by adding pxelinux and vesamenu.c32 to WDS, you can add that feature. Here is how…

 

1. Download and extract syslinux from http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-3.71.zip (it contains pxelinux) 
    
2. Copy the syslinux-3.71\com32\menu\vesamenu.c32 to your WDS Server, D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86 
    
3. Copy the syslinux-3.71\core\pxelinux.o to your WDS Server, D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86, rename it to pxelinux.com 
    
4. Download a nice background image (http://www.deployvista.com/Portals/0/DeploymentBackground.png), and save it in D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86  
    
5. In the D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86 folders, make a copy of pxeboot.n12 and rename it to pxeboot.0 
    
6. Configure WDS to use the pxelinux.com boot file (Server properties, Boot tab) 
    
7. In the D:\RemoteInstall\Boot\x64 and D:\RemoteInstall\Boot\x86 folders, create a subfolder called pxelinux.cfg 
    
8. In the D:\RemoteInstall\Boot\x64\pxelinux.cfg and D:\RemoteInstall\Boot\x86\pxelinux.cfg folders, create a file named default with the following settings
    
   DEFAULT      vesamenu.c32
   PROMPT       0
   NOESCAPE     0
   ALLOWOPTIONS 0
   # Timeout in units of 1/10 s
   TIMEOUT 300
   MENU WIDTH 40
   MENU MARGIN 0
   MENU ROWS 12
   MENU TIMEOUTROW 14
   MENU HSHIFT 5
   MENU VSHIFT 2
   MENU COLOR BORDER 30;44       #00000000 #00000000 none
   MENU COLOR TABMSG 1;36;44     #00000000 #00000000 none
   MENU COLOR TITLE 1;36;44     #00000000 #00000000 none
   MENU COLOR SEL   30;47       #40000000 #20ffffff
   MENU BACKGROUND DeploymentBackground.png

   MENU TITLE PXE Boot menu
   MENU WIDTH 80
   MENU MARGIN 18
   MENU ROWS 4

   LABEL wds
    MENU       DEFAULT
    MENU PASSWD P@ssw0rd
    MENU       LABEL Windows Deployment Services
    KERNEL     pxeboot.0

   LABEL local
    MENU LABEL Boot from Harddisk
    LOCALBOOT 0 

 

Here is a step-by-step (how-to) guide for deploying Ubuntu 8.04.1 LTS 32-bit (Hardy Heron) from a Windows Server running WDS (Windows Deployment Services)

Part 1 – Stage the Ubuntu Setup files on your Server

Note: If you really wan’t to do Ubuntu deployments with style, you should of course skip downloading the alternate ISO’s and instead create a local mirror of the real Ubuntu dist mirrors. You’ll find optional instructions on how to do this further down in the guide (Part 3 to be exact), but for now we simply use the Ubuntu Alternate CD (32-bit) to speed up the process.

1. Download the 32-bit Alternate Install CD’s from http://releases.ubuntu.com/hardy/ubuntu-8.04.1-alternate-i386.iso
    
2. Install IIS (web server) on your server and create a virtual directory named Ubuntu (in this example from the D:\Ubuntu folder): Configure the MIME Settings for the virtual Ubuntu directory by adding a .* wildcard extensions for the “text/plain” mime type (In the HTTP Headers Tab of the Virtual Directory Properties). This is for supporting wget downloading files (which the Ubuntu install engine is using).
    
3. Copy the contents of the iso image to D:\Ubuntu. Be warned though, The Ubuntu CD Image team (in their infinite wisdom) choosed to use the Rock Ridge extensions to ISO 9660 which supports filenames up to 255 characters. Problem is most Windows software (including vmware) doesn’t support this when running Windows as a guest OS. However, MagicISO does, so download and install MagicISO from http://www.magiciso.com/download.htm and use it to extract the iso to theD:\Ubuntu folder.
    
4. Create another virtual directory, this time named Kickstart (in this example from the D:\Kickstart folder). Configure the MIME Settings for the virtual Ubuntu directory by adding a .cfg extensions for the “text/plain” mime type (In the HTTP Headers Tab of the Virtual Directory Properties).
    
5. Download and extract the sample kickstart file (Ubuntu version of unattend.txt) found at this link http://www.deployvista.com/Portals/0/kickstartscript.zip and save it in the D:\Kickstart folder. The encrypted password in thekickstart script is ubuntu

Part 2 – Configure WDS to support Ubuntu

1. From the D:\Ubuntu\install\netboot\ubuntu-installer\i386 folder, copy the initrd.gz and linux files to D:\RemoteInstall\Boot\x86\Hardy\32
    
2. Download and extract syslinux from http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-3.71.zip (it contains pxelinux)
    
3. Copy the syslinux-3.71\com32\menu\vesamenu.c32 to your WDS Server, D:\RemoteInstall\Boot\x86
    
4. Copy the syslinux-3.71\core\pxelinux.o to your WDS Server, D:\RemoteInstall\Boot\x86, rename it to pxelinux.com
    
5. Download a nice background image (http://www.deployvista.com/Portals/0/DeploymentBackground.png), and save it in D:\RemoteInstall\Boot\x86 
    
6. In the D:\RemoteInstall\Boot\x86 folders, make a copy of pxeboot.n12 and rename it to pxeboot.0
    
7. Configure WDS to use the pxelinux.com boot file (Server properties, Boot tab)
    
8. In the D:\RemoteInstall\Boot\x64 or D:\RemoteInstall\Boot\x86 folders, create a subfolder called pxelinux.cfg
    
9. In the D:\RemoteInstall\Boot\x64\pxelinux.cfg or D:\RemoteInstall\Boot\x86\pxelinux.cfg folders, create a file named default with the following settings

   DEFAULT      vesamenu.c32
   PROMPT       0
   NOESCAPE     0
   ALLOWOPTIONS 0
   # Timeout in units of 1/10 s
   TIMEOUT 300
   MENU WIDTH 40
   MENU MARGIN 0
   MENU ROWS 12
   MENU TIMEOUTROW 14
   MENU HSHIFT 5
   MENU VSHIFT 2
   MENU COLOR BORDER 30;44       #00000000 #00000000 none
   MENU COLOR TABMSG 1;36;44     #00000000 #00000000 none
   MENU COLOR TITLE 1;36;44     #00000000 #00000000 none
   MENU COLOR SEL   30;47       #40000000 #20ffffff
   MENU BACKGROUND DeploymentBackground.png

   MENU TITLE PXE Boot menu
   MENU WIDTH 80
   MENU MARGIN 18
   MENU ROWS 4
    
   LABEL wds
    MENU       DEFAULT
    MENU PASSWD P@ssw0rd
    MENU       LABEL Windows Deployment Services
    KERNEL     pxeboot.0
    
   LABEL local
    MENU LABEL Boot from Harddisk
    LOCALBOOT 0
    
   LABEL hardyubuntudesktop32
    MENU PASSWD P@ssw0rd
    MENU LABEL Deploy Ubuntu Desktop 8.04.1 32 bit
    KERNEL /hardy/32/linux
    append vga=769 initrd=/hardy/32/initrd.gz ksdevice=eth0 ks=http://demosrv001/kickstart/Ubuntu_Desktop_32.cfg

Part 3 – What next…

if you really wan’t to do Ubuntu deployments with style, you should of course skip downloading the alternate ISO’s and instead create a local mirror of the real Ubuntu dist mirrors, giving you access to the latest security updates, drivers, support for multiple architectures etc… However, they are really big… Even a single dist like Hardy is about 36 GB (i386 and amd64)

To create a local mirror of the hardy dist I recommend using apt-mirror which will run just fine in Windows, as long as you run it in Cygwin.

Download cygwin from http://cygwin.com/ and run setup, make sure to select the wget package in addition to the default packages.

Then download apt-mirror from http://apt-mirror.sourceforge.net/ and then, in cygwin, create a file named /etc/apt/mirror.list with the following content

# begin mirror.list
# apt-mirror configuration file

##
## The default configuration options (uncomment and change to override)
##
# Store data on the d:\staging
# Note: Create the following folders
# d:\staging
# d:\staging\skel
# d:\staging\skel\var
# d:\staging\mirror
set base_path    /cygdrive/d/tmp
#set mirror_path  $base_path/mirror
#set skel_path    $base_path/skel
#set var_path     $base_path/var
#
# set defaultarch 
set nthreads     2
#

##
## Example sources
##

# Ubuntu

# Ubuntu 8.04 “Hardy” i386
deb-i386 http://ftp.acc.umu.se/ubuntu hardy main restricted universe multiverse
deb-i386 http://ftp.acc.umu.se/ubuntu hardy-updates main restricted universe multiverse
deb-i386 http://ftp.acc.umu.se/ubuntu hardy-security main restricted universe multiverse

# Ubuntu 8.04 “Hardy” amd64
deb-amd64 http://ftp.acc.umu.se/ubuntu hardy main restricted universe multiverse
deb-amd64 http://ftp.acc.umu.se/ubuntu hardy-updates main restricted universe multiverse
deb-amd64 http://ftp.acc.umu.se/ubuntu hardy-security main restricted universe multiverse

# Support for network based installations i386
deb-i386 http://ftp.acc.umu.se/ubuntu hardy main main/debian-installer
deb-i386 http://ftp.acc.umu.se/ubuntu hardy restricted restricted/debian-installer
deb-i386 http://ftp.acc.umu.se/ubuntu hardy universe universe/debian-installer
deb-i386 http://ftp.acc.umu.se/ubuntu hardy multiverse multiverse/debian-installer

# Support for network based installations amd64
deb-amd64 http://ftp.acc.umu.se/ubuntu hardy main main/debian-installer
deb-amd64 http://ftp.acc.umu.se/ubuntu hardy restricted restricted/debian-installer
deb-amd64 http://ftp.acc.umu.se/ubuntu hardy universe universe/debian-installer
deb-amd64 http://ftp.acc.umu.se/ubuntu hardy multiverse multiverse/debian-installer

##
## Cleaner configuration example
##
#
# set cleanscript $var_path/clean.sh
#

# Cleaning section
clean http://ftp.acc.umu.se/ubuntu
# begin mirror.list

In cygwin run: perl apt-mirror (it will now create a local mirror of the selected dists and packages)

Then copy the content of the d:\staging\ftp.acc.umu.se\ubuntu folder to D:\Ubuntu. Another option is of course to create the /ubuntu virtual directory from d:\staging\ftp.acc.umu.se\ubuntu directly.

Why Microsoft choosed to release MDT 2008 Update 1 with a known superbug in it I don’t understand… but  I don’t work for Microsoft so I guess I shouldn’t…

Anyway, the MDT 2008 update 1 will wipe your deployment point(s) settings completely… make sure to backup the deploy.xml file before applying the update, by default it’s in the C:\Program Files\Microsoft Deployment Toolkit\Control folder…

What to do if I don’t have backup, and my settings are gone?
Well, don’t panic just yet, as long as the deployment point folder is still intact, you can have MDT generate a new one for you by creating a new deployment point and set the path to the original folder.

 

A common error when deploying a MDT 2008 generated Task Sequence for SCCM 2007 is the following error:

Task Sequence: has failed with the error code (0x80091007). The full error is “the hash value is not correct”.

Workaround:
One common solution is to change the advertisment to access content directly from a distribution point when needed by the running task sequence, but that’s really not needed…

Instead, most times it’s the Settings Package that is failing and you only need to Update the Distribution Point for that package and then everyhing works just fine…