Wednesday 12 October 2011

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

Tuesday 11 October 2011

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.

Thursday 6 October 2011

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 image
Clean-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.


Wednesday 5 October 2011

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.