0x800700A1 when running command line task in SCCM 2012 OSD

Today in my SCCM 2012 lab I was troubleshooting a task sequence error in regards to source being unavailable. It is a very simple task sequence deploying Windows 7, the only custom step I placed in it was a vbscript I wrote to programatically determine or prompt for the computer name. The error was immediately presenting as soon as my “Run Command Line” task came up. Upon hitting F8 and running CMtrace (thank you Microsoft for putting that in the boot images natively!) I navigated to the SMSTS log found at X:\Windows\TEMP\SMSTS\smsts.log (while in the PE)

task sequence failed to resolve the source for SMS PKGID= 0x800700a1

Here’s what I looked at:

  1. Made sure that I had configured the network access account for the site
  2. Made sure my package had been distributed to the distribution point
  3. Made sure I could access it from the distribution point with the NAA account..wait a second, where is it anyway in 2012?

Here is where some reading may be required. Here is an article that regards the differences between the content library in 2012 and how packages were distributed in 2007. http://blogs.technet.com/b/hhoy/archive/2012/05/31/an-adventure-in-the-sccmcontentlib-single-instance-store.aspx

In the end, I had to ensure all packages referenced by the task sequence were in fact being copied to shares on the distribution point.  For this specific example I chose a specific share, but you shouldn’t have to do that.

Once I made that change, the task sequence deployment option could be set to “Access content directly from a distribution point when needed by the running task sequence”.  I needed to this because when running a task that needs to access package content before the local disk is partitioned there is nowhere to download the data to, so it must be run directly from the distribution point.

SCCM PXE Boot Media Certificate Expiration

Recently I came upon a default self-signed PXE certificate expiration on a ConfigMgr PXE service point site system. The warning message is:

Warning: The certificate associated with this media will expire in hour(s) and minute(s). A valid certificate is required for the duration of a boot media based deployment. Do you wish to continue?

To re-up the self signed certificate is quite simple, but a few extra things need to be done as well once the certificate has a new expiration date. First we navigate in the console to the server which clients are PXE booting from under site systems and look at the properties of the ConfigMgr PXE service point role.

Click on the database tab then set the expiration date out. Now we have to go to the Boot Images node in the SCCM console and update the distribution points (follow the wizard) for each of the boot images that contain the expiring certificate. Then restart the WDS service on the server and you’re all set.

Change a Computer’s OU during an OSD Task Sequence

I came across a situation when testing pushing re-images out with SCCM where I needed to ensure that the old computer object had been moved to the new OU that I specified. This is because even though I specified what OU I wanted the computer to be moved to during the “Apply Network Settings” task, the computer object wasn’t moved because the object already existed. I downloaded and modified Jakob’s vb script MoveOU.vbs which accepts the target OU as an argument.

The caveat with this script is that that since it needs to be run with an AD account that has rights to move the computer object, it cannot be run while the PC is in the PE, so it has to be run after the computer has been sysprepped and has booted from the OS that was dropped to the disk. Not a big deal, since we want the script to be successful even on new images where there isn’t an existing computer record. Here is an example command line usage:

MoveOU.vbs “OU=Marketing Department,OU=Workstations,DC=CONTOSO,DC=COM”

Change SATA operation to AHCI during OSD

So I ran into an interesting situation when we started deploying Windows 7 out via OSD to Windows XP boxes recently. There were some PCs that would take FOREVER to download the image, which would actually end up failing the task sequence. What I ended up finding out was that these computers (Dell Optiplex 960’s) were set to use IDE in the BIOS, which set me out on the task of finding the fastest way to add a step to my task sequence to modify the BIOS during an OSD pushed OS upgrade. I looked into modifying the PE so that the change could be done from the BIOS, but in the time constraint I was working under I ended up simply installing the Dell Open Manage Client Instrumentation 8 (available here) on the Windows XP workstation and changing it before it was shut down as a part of the task sequence.

First, I created a task folder that checked if it was a 960 using a WMI model query:

Select * From Win32_ComputerSystem WHERE Model LIKE “%optiplex 960%”

Then I installed the open manage client, then set the bios. My command lines for my 2 tasks were:

OM_APP_WIN_R300391.EXE /s


cscript.exe OMCI_SATA_Operation.vbs 4

The referenced OMCI_SATA_Operation.vbs script is actually a modified script file (Original name is OMCI_BIOS_ACHI.vbs) available in the package files of the open manage client. When running this script, the option 4 was used to set it to AHCI.

And presto! Since I had to gather information from the OS that was about to be reimaged anyway, this was an option for me. However, for other options like USB deployment and situations where the pre-existing OS might not be available, this will not be the best option. This was a quick and dirty method, but worked during the rollout.

Here is the modified script text:

‘*** Name: OMCI_BIOS_AHCI.vbs
‘*** Purpose: To clear the chassis intrusion status on a Dell OMCI client.
‘*** Usage: cscript.exe //nologo OMCI_BIOS_AHCI.vbs <systemname>
‘*** This sample script is provided as an example only, and has not been
‘*** tested, nor is warranted in any way by Dell; Dell disclaims any
‘*** liability in connection therewith. Dell provides no technical
‘*** support with regard to such scripting. For more information on WMI
‘*** scripting, refer to applicable Microsoft documentation.

‘*** NOTE: Replace <Password> in line 57 (inside the quotes)
‘*** with the desired values if there is any password set in the system.
‘*** If both passwords(Admin and Boot) are set please replace it with Admin Password.
‘*** If there is no password set in the system please leave it as empty.

Option Explicit

‘*** Declare variables
Dim strNameSpace
Dim strComputerName
Dim strClassName
Dim strKeyValue
Dim objInstance
Dim strPropName
Dim strPropValue
Dim oInParams
Dim objWMIService
Dim returnValue
Dim ColSystem
Dim strAttributeName(2)
Dim strAttributeValue(2)

‘*** Check that the right executable was used to run the script
‘*** and that all parameters were passed
If (LCase(Right(WScript.FullName, 11)) = “wscript.exe” ) Or _
(Wscript.Arguments.Count < 1) Then
Call Usage()
End If
‘*** Initialize variables
strNameSpace = “root/dcim/sysman”
strComputerName = “.”
strClassName = “DCIM_BIOSService”
strAttributeName(0) = “Embedded SATA Controller”
strAttributeValue(0) = WScript.Arguments(0)

‘*** All possible values for Embedded SATA Controller are as follows:
‘*** Possible values are:
‘*** 1 – Off
‘*** 3 – ATA
‘*** 4 – AHCI
‘*** 5 – RAID

returnValue = 0
‘*** Retrieve the instance of DCIM_BIOSService class
Set objWMIService = GetObject(“winmgmts:{impersonationLevel=impersonate,” &_
“AuthenticationLevel=pktprivacy}\\” & strComputerName & “\” &_
Set ColSystem=objWMIService.execquery (“Select * from ” & strClassName)

For each objInstance in ColSystem
Set oInParams= objInstance.Methods_(“SetBIOSAttributes”).InParameters.SpawnInstance_
oInParams.AttributeName = strAttributeName
oInParams.AttributeValue = strAttributeValue
Set returnValue = objInstance.ExecMethod_(“SetBIOSAttributes”, oInParams)

‘*** If any errors occurred, let the user know
If Err.Number <> 0 Then
WScript.Echo “Changing BIOS SATA operation failed.”
End If
‘*** Sub used to display the correct usage of the script
Sub Usage()
Dim strMessage
strMessage = “incorrect syntax. You should run: ” & vbCRLF & _
“cscript.exe /nologo OMCI_SATA_Operation.vbs <Possible Sata Value>. All possible values for Embedded SATA Controller in OMCI 8 are as follows: 1 – Off,3 – ATA, 4 – AHCI, 5 – RAID”
WScript.Echo strMessage
End Sub

What the HAL is going on with these E6510 and E6410s?

At my place of employment, we recently ran into some issues integrating Dell’s newer model of laptops, the E6510 and the E6410, into our imaging process for the deployment of Windows XP SP3.

We experienced 3 varied issues that are described as follows:

  • ·         The first occurs on both the E6410 and 6510 XP SP3 is related to the ST Micro Accelerometer driver (Version 1/4/2010) that is included with the E6510 and E6410 XP SP3 x86 driver cab file downloads. If at any point this driver is installed, regardless of installation method, the system will lock up at shut down and sporadically during startup. Simply disabling this driver in SCCM fixed the issue. I also downloaded this driver individually and ripped it apart. I found that it is the same version and modify date as the one included in the CAB files. I can only tell you what I know, which is I have never seen this driver installed without the side effect of random lock ups. I am assuming this is a problem with the driver. As of now, the workaround is to avoid this driver entirely.
  • ·         The second issue we are experiencing is related only to the E6510 model. When utilizing only the drivers provided in the CAB file, ours locks up during the sysprep process. Reviewing the setupapi.log reveals that it is indeed locking up during the installation of the “Intel(R) Active Management Technology – SOL” (Version 9/17/2009) driver. Disabling this driver in SCCM was a workaround this issue for us and presented a new problem. Now it will finish sysprepping and run the image, however the mouse and keyboard will not work due to an IRQ conflict. We are still troubleshooting this issue with Microsoft, as we are trying to get this driver to install properly.
  • ·         The third issue we are experiencing is related only to the E6410 model. When utilizing only the drivers provided in the CAB file, we experience a lockup when resuming from standby. We are utilizing Intel(R) 82567LM-3 Gigabit Network Connection (Version 12/10/2009). We were able to develop a workaround by downloading a later version from the Intel website (Version 9/29/2010) and creating a software package for installation, as the driver would not natively plug-n-play for this device. This is a temporary workaround, but we are watching for the latest version to be approved on the Dell website. We found this article to be very useful. http://communities.intel.com/thread/15350?start=0&tstart=0

The root cause ended up being the version of the HAL that was in our base image. You can read up on the different versions here. In short, we were building our gold standard image on Microsoft Virtual PC, which is an addition to Windows 7 and the successor to Virtual PC 2007. When we built our image on the Microsoft Virtual PC, the HAL type chosen by Windows when installing XP SP3 was “Advanced Configuration and Power Interface (ACPI) PC”. Based on some recommendations on the Dell Techcenter site, (Thanks Warren!) and the evidence that others were having success with a HAL switching script, we decided to rebuild our gold standard image on a VMware based machine, which will choose “ACPI Uniprocessor PC”. After we made this change we no longer had the issues listed above. To check what version of the HAL is installed on your installation, you can simply go to device manager, and look under the computer node.