Showing posts with label MDT 2012. Show all posts
Showing posts with label MDT 2012. Show all posts

8 Jan 2013

Adventures when upgrading SCCM 2012 to SP1

I recently upgraded our newly installed SCCM 2012 RTM infrastructure to SP1 after it's release in late December and after doing so I encountered a number of issues, below are the issues that I experienced and the associated fixes.


Broken MDT Database Connectivity

We have MDT 2012 U1 integrated with our SCCM infrastructure and use the MDAC based database functionality to lookup various details but after the SP1 upgrade,  the following errors could be found in the BDD.log;
Unable to create ADODB.Connection object, impossible to query SQL Server: ActiveX component can't create object (429)
After some research and forum posts I managed to confirm that the upgrade process had removed MDAC from the MDT Boot Image and therefore crippling database connectivity when inside WinPE. To resolve this, I found it necessary to recreate the the MDT Boot Image from within the SCCM Admin Console.


Misassignment of drive letters during OSD of Windows 7

Another side effect of the SP1 upgrade was that previously working Windows 7 images were installing but assigning drive letters D: or E: instead of the normal C: drive assignment. This appears to be a result of the introduction of the new Task Sequence variable OSDPreserveDriveLetter. When investigating my existing Task Sequences I found that a new step had been added to named 'Set Variable for Drive Letter' which declares the value of this variable as False. By changing this value to True, this ensures that the intended drive letter assignment is honoured and therefore future OS drives are assigned C:.

21 Nov 2012

Offline USMT excluding Local Accounts in SCCM 2012 & MDT 2012

Local Machine accounts can be excluded from the USMT process by specifying an additional Task Sequence variable and then either explicitely excluding the local account(s) or explicity including the domain accounts. An issue with the offline USMT method is that the machine is unable to determine the domain by it's name and therefore it's necessary to use the Domain's SID based on the fact that each user account within a given domain will have a similar SID apart from the RID which forms the last section of the SID string.

See the Wikipedia explanation

  1. First of all create the necessary TS variable in a new step before the Scanstate operation named OSDMigrateAdditionalCaptureOptions
  2. Give it a value of /ue:* /ui:<Domain SID>*
Multiple instances of /ui can be used to specify additional domains if required.

A domain's SID can be retrieved by using PSGetSID.exe from SysInternals and using the following syntax; psgetsid.exe <Domain Name>