WINLOAD.EXE Error After deployment of WIM Image - OSIM

After the creation of my 'golden image' I deployed the WIM to a VM and two physical systems. These did not deploy correctly and I faced an error:

Missing or Corrupt winload.exe (0xc000000e)

I know that the script to prepare the C: drive and deploy the WIM had ran so I looked a bit closer at the specific script. The script to deploy the WIM is located in managedpc\camenu\ the particular file we are looking at depends on the image name. %IMAGE%.cmd. I shouldn't replicate the script (as I wouldn't want to break any confidentiality agreements) but the structure is what you would normally expect.

- Connect to a server share
- Format the C drive using format c: /FS:NTFS /X /Q /V:OS /Y
- Use imageX to apply WIM
- Post install tasks etc.

After a bit of digging around on the Internet forums I noticed some people were seeing a similar issue. It looks like the C: drive hasn't been marked set in the BCD Store. A method around this is to use the bcdedit tool which is built into WinPE.

More on the bcdedit.exe located hither:

http://technet.microsoft.com/en-us/library/cc709667(WS.10).aspx

http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202(v=vs.85).aspx


In order to incorporate this into the script we just need to add the following lines of code to the end of %IMAGE%.cmd (before the :END and GOTO END)

x:\windows\system32\bcdedit /set {default} device partition=c:
x:\windows\system32\bcdedit /set {default} osdevice partition=c:
x:\windows\system32\bcdedit /set {bootmgr} device partition=c:

Where X: is the WinPE drive.

Reasons behind this are still a little clouded, I'm not wholly sure if this was something relating to my previous blog on the BDEDrive (Bitlocker System Drive) or due to the UEFI as described hither. http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

ITCM - DSM Explorer Error Message

During an attempt to update a package source with a service pack I had to kill the DSM explorer mid copy... bad idea. Any further edits of the package including deleting/sealing etc. gave me the following error:

The software is currently locked. Please retry the operation, if possible [SDM000103]

The lock cannot be removed from the client end (rebooting PC) so the method to resolve this is to do a CAF restart on the DM (Domain Manager).

caf stop
caf start

CA ITCM - Roaming Users

Interesting situation was discovered today:



Scenario:

Roaming user ‘Fred’ is assigned to SS ‘A’ in England
Roaming user ‘Fred’ likes to roam and spends a lot of time in Ukraine at SS ‘B’
‘Fred’ likes to receive new software/patches and raises tickets to have these installed.
IT initiates SW deployment/install via CA which starts to download from SS ‘A’ when Fred is located at SS ‘B’ where the software has already been staged. The install occurs over the WAN and will take a lot longer eating up bandwidth over WAN.



Back in the days of SMS 2003 and I'm sure in SCCM you can configure boandaries for roaming clients. IP Subnets/Sites are configured and allocated and they could use the secondary SMS server that was closest. So I got hold of CA and asked the question if there is any configuration that you can do DM or client side that would set this automatically. This can be done manually using the command



caf setserveraddress <servername>



I was looking for an answer that was a bit more intelegent than having a user manually register to the nearest SS.

CA replied that there was a script 'location awareness script' that could be used. Unfortunately this came with all kinds of support implications and it was a 'high risk' script... basically - don't use it.

CA ITCM OSIM - getimage Windows 7

Yesterday I went through the process of capturing a Win7 SP1 image using the OSIM built in wizards to see if they were as straight forward as advertised.
 I have a VM guest built with MDT all ready and waiting to be captured. Here is a CA diagram that shows the process.

Steps to create an OSIM 

Step 1 - Use 'New OS Image' Wizard and use 'GETIMAGE-WIN7' (this needs to be created on the boot server)
Step 2 - Use 'Register OS Image' Wizard to get the Image on the domain manager.
Step 3 - I created a SW job to deploy the OS to the boot server using the default procedure 'Add to boot server' the job failed with:

Exit code 1 indicates possible error [SDM228001]

Delivery Trace:
[10/5/2011 4:35:50 AM] INIT  1484 - 1485
[10/5/2011 4:35:54 AM] READ_FILTERING  
[10/5/2011 4:35:54 AM] CONNECTING  
[10/5/2011 4:35:55 AM] IN_PROGRESS 0%
[10/5/2011 4:36:03 AM] WRITE_FILTERING  
[10/5/2011 4:36:03 AM] COMPLETE  

Job Output:
ImageProduct: 'STWIN7-2':'12.1.0/00'
DSM base directory: C:\Program Files (x86)\CA\DSM
Boot server directory: C:\Program Files (x86)\CA\DSM\Server\\SDBS
ManagedPC directory: D:\CA\managedpc
ManagedPC logon user: canonprv
Image folder: STWIN7-2
Camenu files: STWIN7-2.cmd;STWIN7-2.wp1; 
Share name:   STWIN7-2-11
ManagedPC is configured to use Windows/Samba shares
Directory D:\CA\managedpc\images\STWIN7-2 already in use
Failed to install the OS imageClean-up:
Set status to 1

I guessed that due to the new OS being created on that boot server there was no need to complete this step. Folder structure was present with files.

Step 4 - As part of the capture process there is an option to create a backup of the OS before using the Sysprep and capture. I left this option out for this testing process as my OS is just a standard install with limited customisations.
The system has already been registered in the OS Installations and I managed the system and added the following parameters. I left the SysprepVersion parameter empty as Win7 as this builtin at the location c:\windows\system32\sysprep... not sure if I should specify the path ... will find out soon.

Once booted up into WinPe the following script initiated. We can see from the output that the file transfer was a success but there was an issue with the sysprep file.

Some troubleshooting steps that we went through to try to resolve the issue:

1. Checked that sysprep was in the path c:\windows\system32\sysprep - Passed
2. Checked that the OS partition was being used. I did this by removing the BDEDrive from the system.

After re-running the OS Sysprep after the removal of the BDEDrive the process worked and I could sysprep the C: drive. Looks like the BDEDrive was assigned as C: by OSIM... This troubleshooting with CA also proved worthwile as a patch is available for the IPS. The patch is called RO15097 and adds support to the IPS for Windows7 SP1 and does fix the issue with the bitlocker partition.

MDT 2010 - BDEDrive

After deploying a DVD installation of Windows 7 SP1 via MDT 2010 I noticed an NTFS partition of 300MB called BDEDrive:

BDEDrive

This is the Bitlocker partition that is allocated during a 'New Deployment' scenario. In our environment we are using an alternative disk encryption tool so in order to disable the creation of the partition we need to add the following to the CustomSettings.ini

DoNotCreateExtraPartition=YES

CustomSettings.ini

The location of the CustomSettings.ini can be found in \DeploymentShare\Control\CustomSettings.ini or can be editted using the MDT 2010 tool by:
Right click on the deployment share -> Properties -> Rules

Whilst this will not affect the capture process using our selected deployment tool CA's ITCM it's good to know we can get rid and keep things neat.