If separate NIC drivers are offered by an OEM manufacturer for use in Windows PE vs. the full Windows OS, the Task Sequence may fail if the Windows OS being deployed is Windows Vista or newer (Vista, Windows 7, 2008, 2008 R2) and if it is being deployed from an "Operating System Install Packages" (Windows installation source files).
Usually the OEM manufacturer offers separate NIC drivers for use in WinPE vs. the full Windows OS because of special characteristics of the NIC, such as it being a multi-tiered device. WinPE does not support multi-tiered devices, so the OEM manufacturer offers a "monolithic" driver for use in WinPE. An example of such a NIC device is the Broadcom NetXtreme II (based on the 5706, 5708, 5709, and 5716 chipsets) commonly seen on server class hardware. Please see the below link for additional information regarding the Broadcom NetXtreme II NIC:
http://www.broadcom.com/support/ethernet_nic/netxtremeii.php
Note: The monolithic driver for the Broadcom NetXtreme II NIC does not need to be loaded into the WinPE Boot Images of SP2 of SCCM 2007. SCCM 2007 SP2 utilizes WinPE 3.0 which already contains the NetXtreme II NIC monolithic driver. However it does need to be loaded in the Boot Images of SP1 of SCCM 2007. SCCM 2007 SP1 utilizes WinPE 2.1 which does not contain this driver.
When the Task Sequence fails, the errors displayed both in the interface and in the SMSTS.log may be different depending on if the deployment was an SCCM 2007 SP1 vs. SCCM 2007 SP2 Task Sequence. It will also vary depending if the Advertisement for the Task Sequence is set to download and run locally ("Download content locally when needed by running task sequence") or run from DP ("Access content directly from a distribution point when needed by the running task sequence").
Below are example error messages for each scenario:
SCCM 2007 SP1 & SP2 Run From DP
SMSTS.log:
Executing command line: "\\<DP_SERVER>\<DPSHARE>$\<Windows_Installation_Package_ID>\SOURCES\SETUP.EXE" "/unattend:C:\_SMSTaskSequence\unattend.xml" /noreboot OSDSetupWindows
Process completed with exit code 3221225478 OSDSetupWindows
Windows Setup completed with exit code 3221225478 OSDSetupWindows
Entering ReleaseSource() for \\<DP_SERVER>\<DPSHARE>$\<Windows_Installation_Package_ID>\ OSDSetupWindows
reference count 1 for the source \\<DP_SERVER>\<DPSHARE>$\<Windows_Installation_Package_ID>\ before releasing OSDSetupWindows
Released the resolved source \\<DP_SERVER>\<DPSHARE>$\<Windows_Installation_Package_ID>\ OSDSetupWindows
exitCode == 0, HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\setupwindows\setupwindows.cpp,440) OSDSetupWindows
Windows setup failed, code 3221225478 OSDSetupWindows
setup.run(), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\setupwindows\setupwindows.cpp,1707) OSDSetupWindows
Exiting with code 0x80004005 OSDSetupWindows
Process completed with exit code 2147500037 TSManager
!--------------------------------------------------------------------------------------------! TSManager
Failed to run the action: Setup windows and ConfigMgr.
Unspecified error (Error: 80004005; Source: Windows) TSManager
The execution of the group (Setup Operating System) has failed and the execution has been aborted. An action failed.
Operation aborted (Error: 80004004; Source: Windows) TSManager
Failed to run the last action: Setup windows and ConfigMgr. Execution of task sequence failed.
Unspecified error (Error: 80004005; Source: Windows) TSManager
Setupact.log and Setuperr.log:
SP1:
<Date> <Time>, Info IBS SetImageXMLOnBB:Could not cache the WinPE image XML info [\\<DP_Server>\<DP_Share>$\<Windows_Installation_Package_ID>\SOURCES\Boot.wim]. Error code is [0x35]
<Date> <Time>, Info [0x060115] IBS Callback_Productkey_Validate_Unattend:Using ProductKey WillShowUI value of [OnError]; retrieving key from unattend file...
<Date> <TIME>, Error [0x060412] IBS IsValidTargetLanguage: Unable to get languages from the lang.ini file.[gle=0x00000035]
or
<Date> <TIME>, Error [0x060412] IBS IsValidTargetLanguage: Unable to get languages from the lang.ini file.[gle=0x00000040]
<Date> <TIME>, Error [0x060467] IBS Failed to retrieve compressed image size for '\\<DP_Server>\<DP_Share>$\<Windows_Installation_Package_ID>\SOURCES\Install.wim'[gle=0x00000035]
or
<Date> <TIME>, Error [0x060467] IBS Failed to retrieve compressed image size for '\\<DP_Server>\<DP_Share>$\<Windows_Installation_Package_ID>\SOURCES\Install.wim'[gle=0x00000040]
<Date> <TIME>, Info [SETUP.EXE] Called script [X:\windows\Setup\Scripts\ErrorHandler.cmd] to handle fatal error
<Date> <TIME>, Info [0x070042] DIAG CallBack_DiagnosticDataSend: Called with notification for Error published by ErrorHandler
<Date> <TIME>, Info [0x0601d7] IBS InstallWindows:Error Type = 3211266
SP2:
<Date> <Time>, Info [0x060115] IBS Callback_Productkey_Validate_Unattend:Using ProductKey WillShowUI value of [OnError]; retrieving key from unattend file...
<Date> <TIME>, FatalError [0x090001] PANTHR Unhandled exception (code 0xC0000006: IN_PAGE_ERROR) occurred at 0x735E87D4 in \\<DP_SERVER>\<DPSHARE>\<Windows_Installation_Package_ID>\SOURCES\win32ui.dll (+000287D4). Minidump attached (51636 bytes).
SCCM 2007 SP1 Download & Run Locally
SMSTS.log:
Executing command line: "C:\_SMSTaskSequence\Packages\<Package_ID>\SOURCES\SETUP.EXE" "/unattend:C:\_SMSTaskSequence\unattend.xml" /noreboot OSDSetupWindows
Process completed with exit code 0 OSDSetupWindows
Windows Setup completed with exit code 0 OSDSetupWindows
GetDirectoryListing() entered OSDSetupHook
Initializing HTTP transport. OSDSetupHook
Setting URL = http://<SCCM_MP_Server>/SMS_DP_SMSPKG<Drive_Letter>$/<Package_ID>/. OSDSetupHook
Address = <SCCM_MP_Server>, Object = /SMS_DP_SMSPKG<Drive_Letter>$/<Package_ID>/, Port = 80. OSDSetupHook
WinHttp credentials set OSDSetupHook
CLibSMSMessageWinHttpTransport::Send: URL: <SCCM_MP_SERVER>:80 PROPFIND /SMS_DP_SMSPKG<Drive_Letter>$/<Package_ID>/ OSDSetupHook
Error. Received 0x80072ee7 from WinHttpSendRequest. OSDSetupHook
unknown host (gethostbyname failed) OSDSetupHook
hr, HRESULT=80072ee7 (e:\nts_sms_fre\sms\framework\osdmessaging\libsmsmessaging.cpp,7714) OSDSetupHook
sending with winhttp failed; 80072ee7 OSDSetupHook
oHttpTransport.Send((char*)S_DAVQUERY, (sizeof(S_DAVQUERY)/sizeof(S_DAVQUERY[0]))-sizeof(char), pReply, nReplySize), HRESULT=80072ee7 (e:\nts_sms_fre\sms\framework\tscore\downloadcontent.cpp,585) OSDSetupHook
SendResourceRequest() failed with 0x80072ee7 OSDSetupHook
SendResourceRequest(), HRESULT=80072ee7 (e:\nts_sms_fre\sms\framework\tscore\downloadcontent.cpp,371) OSDSetupHook
oDavRequest.GetDirectoryListing(setDirs, setFiles), HRESULT=80072ee7 (e:\nts_sms_fre\sms\framework\tscore\resolvesource.cpp,2419) OSDSetupHook
Retrying download... OSDSetupHook
No errors in the Setupact.log or Setuperr.log
SCCM 2007 SP2 Download & Run Locally
Deployment runs successfully
Cause
The basic cause of the problem is that network connectivity is lost in WinPE when the NIC driver is installed. When running from DP, the Task Sequence will fail immediately after the NIC driver install takes place. When downloading and running locally, the Task Sequence will fail a few minutes after the the NIC driver install takes place and right after the initial Windows setup is complete. Loss of network connectivity is caused by how and when the NIC driver is installed by the SCCM OSD Task Sequence.
In Windows Vista or newer (Vista, Windows 7, 2008, 2008 R2), drivers can be installed during one of several different passes during an unattended Windows installation. These passes are described in the below TechNet article:
Add Device Drivers During Windows Setup
http://technet.microsoft.com/en-us/library/cc766485(WS.10).aspx
When either the "Apply Driver Package" task or "Auto Apply Driver" task is included as part of an SCCM 2007 OSD Task Sequence that is deploying an Operating System via an "Operating System Install Packages" (Windows installation source files), the Task Sequence will automatically generate and/or add to an unattend.xml file specifying for the drivers to be installed during the windowsPE phase. According to the above TechNet article, drivers installed during windowsPE phase are not only installed within WinPE, but also in the full Windows OS installation:
"If you need drivers for Windows PE to see the local hard disk drive or a network, this configuration pass must be used to add the necessary drivers to the Windows PE driver store. The windowsPE configuration pass also configures settings that apply to installation. This means that drivers in the Windows PE driver store are also reflected into the offline Windows image or copied to the Windows image driver store during offline servicing."
The problem with installing NIC drivers that are different for WinPE vs. the full Windows OS is that attempting to install such drivers during the windowsPE phase will cause network connectivity in WinPE to stop working and fail. This occurs because the incorrect drives are "reinstalled" while still in WinPE.
The exact failure is different depending if SCCM 2007 SP1 or SCCM 2007 SP2 is being used. SP1 utilizes WinPE 2.1 and SP2 utilizes WinPE 3.0. In SP1, when the driver is attempted to be installed while in WinPE 2.1, the network connectivity is lost permanently. In SP2, when the driver is attempted to be installed while in WinPE 3.0, network connectivity is also lost. However, WinPE 3.0 handles the issue better and after a few seconds recovers and network connectivity is regained.
If the Task Sequence is being run from the DP, in both SP1 and SP2, the Task Sequence will fail during the initial Windows Setup. When Windows Setup installs the NIC driver, the Task Sequence will fail immediately after the NIC driver has been installed. Specifically, when the failure happens, the Task Sequence is accessing the Windows installation source files directly on the DP. Since it cannot access these files anymore due to the loss of network connectivity, Windows Setup fails, which causes the Task Sequence to fail.
If the Task Sequence is downloading and running locally, the Task Sequence will not fail immediately upon the installation of the NIC driver. Since the Windows installation source files have already been downloaded and are located locally on the hard drive, the Task Sequence will continue with Windows Setup using the Windows installation source files located locally on the hard drive even if there is no network connectivity. The initial Windows Setup will then succeed but once it completes, since network connectivity is needed once again to continue the Task Sequence, in the case of SP1 and WinPE 2.1 where network connectivity never comes back, the Task Sequence fails when it cannot access the network to continue. However, in SP2 that utilizes WinPE 3.0, since network connectivity has been regained by the point that the initial Windows Setup completes and network connectivity is needed again by the Task Sequence, the Task Sequence continues and completes successfully. so the issue does not occur.
Resolution
There are several solutions to the problem:
1) Upgrade to SP2 of SCCM 2007, and then choose the option to download and run the Task Sequence locally ("Download content locally when needed by running task sequence") in the properties of the Advertisement of the Task Sequence.
2) Capture a reference image of the Windows OS on another model PC that does not utilize the affected NIC, and then deploy Windows OS via a Task Sequence that deploys from an Operating System Image instead of an Operating System Install Package. The way drivers are injected and installed in an Operating System Image is different than an Operating System Install Package (drivers are injected directly into the Operating System Image's Driver Store) so the process completes successfully.
3) Install an additional NIC card that does not require separate drivers for WinPE vs. the full Windows OS into the PC . Disconnect the NIC that requires separate drivers for WinPE vs. the full Windows OS, and then use the newly installed NIC exclusively during the Task Sequence.
4) The affected NIC drivers need to be somehow installed during the offlineServicing pass instead of the windowsPE pass. However there is no way to change the default behavior of the SCCM 2007 OSD Task Sequence tasks "Apply Driver Package" and "Auto Apply Drivers" to install drivers during a pass other than the windowsPE pass.Although by default the pass used by and automatically generated by an SCCM 2007 OSD Task Sequence in the unattend.xml file cannot be changed, some additional tasks can be added to the Task Sequence that manipulates both the unattend.xml file and where the drivers are installed from. This process is described below:
A) Open Notepad.
B) Below, choose the appropriate architecture of the Windows OS being deployed, copy the lines below the architecture, and paste them into the Notepad:
x86:
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="offlineServicing">
<component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<DriverPaths>
<PathAndCredentials wcm:action="add" wcm:keyValue="1">
<Path>C:\_SMSTaskSequence\Drivers2</Path>
</PathAndCredentials>
</DriverPaths>
</component>
</settings>
</unattend>
x64:
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="offlineServicing">
<component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<DriverPaths>
<PathAndCredentials wcm:action="add" wcm:keyValue="1">
<Path>C:\_SMSTaskSequence\Drivers2</Path>
</PathAndCredentials>
</DriverPaths>
</component>
</settings>
</unattend>
C) Save the Notepad file with the name unattend.xml
When saving the file, make sure that "All Files (*.*)" is selected next to "Save as type:" so that it does not append the .txt extension to the file.
D) In the SCCM 2007 Admin console, under the "Computer Management" -->"Software Distribution" --> "Packages" node, create a new package that contains the unattend.xml file created in Steps B & C. A Program does not need to be created for the Package. After creating the Package, make sure to copy the Package to the Distribution Points.
E) In the SCCM 2007 Admin Console, under the "Computer Management" -->"Operating System Deployment" --> "Task Sequences" node, right click on the affected Task Sequence and choose "Properties".
F) In the "Apply Operating System" task, check the option "Use an unattended or sysprep answer file for a custom installation". Next to the "Package:" field, click on the "Browse..." button and select the package created in Step D. Next to the field "Filename:", enter in unattend.xml
G) Create a Driver Package that ONLY contains the drivers of the affected NIC device. Make sure to add the Driver Package to the Distribution Points after creating it.
H) If applicable, create a second Driver Package that contains all of the other drivers that need to be installed on the PC during the Task Sequence. Do NOT include the affected NIC drivers in this second Driver Package. Make sure to add the Driver Package to Distribution Points after creating it.
I) Remove any "Auto Apply Driver" tasks from the Task Sequence.
J) Immediately after the "Apply Network Settings" task, add an "Apply Driver Package" task and point it to the Driver Package created in Step G that only contains the affected NIC driver.
K) Immediately after the "Apply Driver Package" task created in Step J, add a "Run Command Line" task. In the "Name:" box, type in:
Rename Drivers Directory
In the "Command line:" box, enter in
cmd /c move "%_SMSTSMDataPath%\Drivers" "%_SMSTSMDataPath%\Drivers2"
L) Immediately after the "Run Command Line" task created in Step K, add another "Run Command Line" task. In the "Name:" box, type in:
Recreate Drivers Directory
In the "Command line:" box, enter in
cmd /c md "%_SMSTSMDataPath%\Drivers"
M) If applicable, immediately after the "Run Command Line" task added in Step L, add an "Apply Driver Package" and point to the Driver Package created in Step H that contains all of the rest of the drivers for the PC.
It is possible to use solution #4 and the above steps using the "Auto Apply Drivers" task instead. Instead of creating two separate Driver Packages and two separate "Apply Driver Package" tasks, two "Auto Apply Drivers" tasks that utilize driver categories can be used instead. A special driver category would need to be created for the affected NIC driver, and a separate category would need to be created for all other drivers. For the first"Auto Apply Drivers" task , choose the option "Limit driver matching to only consider drivers in selected categories", and then select the special category created for the affected NIC driver. In the second "Auto Apply Drivers" task, also select the option "Limit driver matching to only consider drivers in selected categories", but this time select the category created for all other drivers. Make sure that the affected NIC driver is NOT included in the "all other drivers" category.
NOTE:
As a possible resolution, attempting to not install any driver for the NIC while in WinPE via the "Apply Driver Package" task and/or the "Auto Apply Drivers" task and instead trying to install the NIC driver later in the Task Sequence during the full Windows OS portion (after the "Setup windows and ConfigMgr" task), via an "Install Software" task, does not resolve the problem. Once the Task Sequence detects that it does not have network connectivity in the full Windows OS (due to the NIC driver not being installed), the Task Sequence will fail. It will never get to the "Install Software" task that installs the NIC driver. Additionally, even if the Task Sequence did get to the "Install Software" task that installs the NIC driver, there would be no way of reaching the DP and downloading the software package containing the NIC driver since there is no network connectivity.
Frank Rojas | System Center Support Escalation Engineer
I recently ran into this issue a couple days ago and didn't see a whole lot documented on it so I thought I would do a quick write up here. If you're trying to upgrade some of your site servers to SP2 and run into an issue, this should get you going again pretty easily.
Note: This article describes making changes to the primary site database. Before making changes in SQL Management Studio to the database, make sure to create a backup of your ConfigMgr 2007 Primary Site/Database. The process in this post has not been officially tested and is posted as is with no guarantee. This solution did work for me and it should also work for you, just make sure to back up your Primary site/database to be safe.
Issue
ConfigMgr2007 SP2 Setup on some Secondary sites failed due to insufficient disk space. Once we freed up enough disk space, we needed to get setup for SP2 restarted, preferably without having to copy the source files to the Secondary Site server and manually upgrading. Since the setup failed to even start due to disk space issues on the Secondary Site server, it got stuck in an Upgrade status and did not resume setup automatically even after freeing up the disk space on the server.
Resolution
We found that manually copying the ConfigMgr SP2 source files to the server and running setup worked to get the Secondary Site upgraded, but if there are a lot of servers with the issue this can become quite time consuming. Since we did not want to have to perform this manual process on each server where disk space was already an issue, we devised the following solution:
Using SQL Management Studio at the ConfigMgr 2007 Primary Site database, we opened the dbo.Sites table and modified the Secondary Sites Status column from 5 to 1.
The Sites table in the Primary Site database will have entries for each site including the Secondary sites. In the database there is a Status column where the current status will be defined as 1, 2, 3, 4, or 5 :
- SITE_STATUS_ACTIVE 1 Site is active & normal
- SITE_STATUS_PENDING 2 Being installed
- SITE_STATUS_FAILED 3 Failed install
- SITE_STATUS_DELETED 4 Delete has been initiated
- SITE_STATUS_UPGRADE 5 Upgrade in progress
Based on the above information, we changed the status back to 1 for the sites that failed , and then started another upgrade from the ConfigMgr 2007 Admin Console. This allowed us to re-trigger the SP2 upgrade without having to copy the files locally to each server and running setup manually.
Clifton Hughes | Senior System Center Support Engineer
When deploying Windows 7 via OSD in SCCM 2007 SP2, upon rebooting from the WinPE stage to Windows 7 Mini-Setup, Windows may not start and the following error occurs instead:
Status: 0xc0000001
Info: An unexpected error has occurred.
Examining the following logs may reveal the following errors:
SMSTS.log
Applying driver package "<Driver_Package_ID>". OSDDriverClient
...
Writing configuration information to C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml OSDDriverClient
Successfully saved configuration information to C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml OSDDriverClient
Setting temporary directory to 'C:\_SMSTaskSequence\PkgMgrTemp'. OSDDriverClient
Calling Package manager to add drivers to the offline driver store. OSDDriverClient
Command line for extension .exe is "%1" %* OSDDriverClient
Set command line: "X:\windows\Pkgmgr\pkgmgr.exe" /o:"C:;C:\Windows" /n:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /l:"C:\_SMSTaskSequence\PkgMgrTemp\PkgMgr" OSDDriverClient
Executing command line: "X:\windows\Pkgmgr\pkgmgr.exe" /o:"C:;C:\Windows" /n:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /l:"C:\_SMSTaskSequence\PkgMgrTemp\PkgMgr" OSDDriverClient
Process completed with exit code 2 OSDDriverClient
uExitCode == 0, HRESULT=80070002 (e:\nts_sms_fre\sms\client\osdeployment\osddriverclient\sysprepdriverinstaller.cpp,553) OSDDriverClient
Package manager failed with return code 2 OSDDriverClient
AddPnPDriverToStore( pszSource, sTargetSystemDrive, sTargetSystemRoot, wProcessorArchitecture), HRESULT=80070002 (e:\nts_sms_fre\sms\client\osdeployment\osddriverclient\sysprepdriverinstaller.cpp,663) OSDDriverClient
Failed to add driver to driver store. Code 0x80070002 OSDDriverClient
InstallDriver( iInstallParams->sContentId, iInstallParams->sSource, iInstallParams->pBootCriticalInfo ), HRESULT=80070002 (e:\nts_sms_fre\sms\client\osdeployment\osddriverclient\driverinstaller.cpp,557) OSDDriverClient
...
pDriverInstaller->InstallDriverPackage( sPackageId, pBootCriticalInfo ), HRESULT=80070002 (e:\nts_sms_fre\sms\client\osdeployment\osddriverclient\osddriverclient.cpp,409) OSDDriverClient
Failed to provision driver. Code 0x80070002 OSDDriverClient
Exiting with return code 0x80070002 OSDDriverClient
Process completed with exit code 2147942402 TSManager
!--------------------------------------------------------------------------------------------! TSManager
Failed to run the action: Apply Driver Package.
The system cannot find the file specified. (Error: 80070002; Source: Windows) TSManager
PkgMgr.log
<Date> <Time>, Info CBS Pkgmgr: called with: ""X:\windows\Pkgmgr\pkgmgr.exe" /o:"C:;C:\Windows" /n:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /l:"C:\_SMSTaskSequence\PkgMgrTemp\PkgMgr""
00000001 Shim considered [l:252{126}]"\??\C:\Windows\Servicing\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7600.16385_none_0935b76c289e0fd5\pkgmgr.exe" : got STATUS_OBJECT_PATH_NOT_FOUND
<Date> <Time>, Info CSI 00000001 Shim considered [l:252{126}]"\??\C:\Windows\Servicing\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7600.16385_none_0935b76c289e0fd5\pkgmgr.exe" : got STATUS_OBJECT_PATH_NOT_FOUND
00000002 Shim considered [l:246{123}]"\??\C:\Windows\WinSxS\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7600.16385_none_0935b76c289e0fd5\pkgmgr.exe" : got STATUS_SUCCESS
<Date> <Time>, Info CSI 00000002 Shim considered [l:246{123}]"\??\C:\Windows\WinSxS\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7600.16385_none_0935b76c289e0fd5\pkgmgr.exe" : got STATUS_SUCCESS
<Date> <Time>, Info CBS
<Date> <Time>, Info CBS pkgmgr called with: ""X:\windows\Pkgmgr\pkgmgr.exe" /o:"C:;C:\Windows" /n:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /l:"C:\_SMSTaskSequence\PkgMgrTemp\PkgMgr""
<Date> <Time>, Info CBS Executing DISM: "C:\Windows\WinSxS\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7600.16385_none_0935b76c289e0fd5\dism.exe" /image:"C:\\" /sysdrivedir:"C:\\" /norestart /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\PkgMgr.txt" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml"
<Date> <Time>, Info CBS Could not create process with command line ""C:\Windows\WinSxS\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7600.16385_none_0935b76c289e0fd5\dism.exe" /image:"C:\\" /sysdrivedir:"C:\\" /norestart /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\PkgMgr.txt" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml"" [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
<Date> <Time>, Info CBS Failed to start dism.exe. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
<Date> <Time>, Info CBS pkgmgr return code: 0x2
<Date> <Time>, Info CBS Pkgmgr: return code: 0x2
This issue can occur if you are attempting to use a WinPE 2.x based Boot Image created with the WAIK 1.x for a Windows 7 deployment. Windows 7 deployments require a WinPE 3.0 or newer based Boot Image created with the WAIK 2.x or newer.
Examining the logs reveals that the deployment is trying to use Pkgmgr.exe (Package Manager), which is a WinPE 2.x/WAIK 1.x tool, to try to inject drivers into Windows 7. PkgMgr.exe is not compatible with Windows 7 and it has been replaced with DISM.exe in WinPE 3.x/WAIK 2.x. DISM.exe is required to inject drivers properly into Windows 7.
Using the incorrect Boot Image causes the deployment to try to use a combination of PkgMgr.exe and DISM.exe, and ends up causing it to fail.
Resolution
Check to make sure that the Task Sequence deploying Windows 7 is using a WinPE 3.x based Boot Image.
To check the Boot Image that the Task Sequence deploying Windows 7 is using:
- In the ConfigMgr 2007 console under the "Operating System Deployment" --> "Task Sequences" node, right click on the affected Task Sequence and choose "Properties".
- Click on the "Advanced" tab
- Under the option "Use a boot image:", make sure that the Boot Image selected is a WinPE 3.x based Boot Image
To check the version of the Boot Image to verify that it is a WinPE 3.x Boot Image:
- In the ConfigMgr 2007 console under the "Operating System Deployment" --> "Boot Images" node, right click on the Boot Image as determine in the above steps and choose "Properties".
- Click on the "Images" tab.
- Click on the "Reload" button.
- Check the value of the field "OS version".
For WinPE 3.x based Boot Images, the version number should at least be at 6.1.7600.16385. If the version number is 6.0.6001.18000 or older, this is a WinPE 2.x based Boot Image which will not work with Windows 7 deployments.
Frank Rojas | Configuration Manager Support Escalation Engineer
IT administrators and IT support staff need easier access to key information about software and operating system deployments, client health, and compliance with regulations. They must ensure that their systems and software meet the configuration requirements established for the organization. And they need the ability to track this information without having access to a System Center Configuration Manager console.
The Solution: The System Center Configuration Manager 2007 Reporting Dashboard
The Microsoft System Center Configuration Manager 2007 Dashboard lets customers track application and operating system deployments, security updates, the health status of computers, and IT compliance with key regulations—with an easy to use, customizable Web interface. Because the Dashboard is built on Windows® SharePoint® Services, IT staff can access information without using the Configuration Manager console. The Dashboard is a free Solution Accelerator, and fully supported by Microsoft.
Key features of the Dashboard include:
- Easy access to key information without using the Configuration Manager console
- Centralized view of Configuration Manager data sets
- Data can be viewed in graph, table, or Dundas gauge formats
- You can create custom dashboards for different departments, based on site user’s group membership.
For all the details and to join the beta see http://technet.microsoft.com/en-us/library/ff369719.aspx
J.C. Hornbeck | System Center Knowledge Engineer
Consider the following scenario:
- You install the System Center Configuration Manager 2007 Service Pack 1 (SP1) client or the System Center Configuration Manager 2007 Service Pack 2 (SP2) client.
- You install security update 974571 on this computer.
- A SCCM task sequence runs on this client. This task sequence includes the Capture User State task sequence step and the Restore User State task sequence step.
In this scenario, user state migration fails. At the same time, the following error message is logged in the Ccmexec.log file:
Failed to import the client certificate store (0x80092024) OSDSMPClient
This issue occurs because an embedded NULL character is in the Friendly name property of a certificate. The security update 974571 prevents the action that imports the certificate when its Friendly name property has an embedded NULL character. Therefore, the certificate cannot be imported.
For all the details including a download link to the hotfix see the following new Knowledge Base article:
KB977203 - User state migration fails on a SCCM 2007 SP1 client or on a SCCM 2007 SP2 client after you install security update 974571
J.C. Hornbeck | System Center Knowledge Engineer
Looks like the folks on the Configuration Manager documentation team announced all their updates last Friday. It includes things such as:
Configuration Manager 2007 SP2 Supported Configurations
- Removal of the statement that in-band provisioning is not supported on Windows 7. This topic also has an updated section about BranchCache, to clarify its integration with Configuration Manager 2007 SP2.
Certificate Requirements for Native Mode
- Updated for the client authentication certificate that might be used with an operating system deployment in native mode. This certificate must have a unique value for the Subject Name and unlike the client authentication certificate that is used by native mode clients, it does not support a certificate SAN value.
Troubleshooting Management Point Communication
- Updated for clarity and with a warning that before running the MPCERT and MPLIST tests in a native mode site, a certificate must be imported into the browser.
And much much more. For all the details see http://blogs.technet.com/configmgrteam/archive/2010/01/29/announcement-configuration-manager-documentation-library-update-for-january-2010.aspx
J.C. Hornbeck | System Center Knowledge Engineer
We recognize that Windows 7 is an opportunity for organizations to reduce their costs, improve security, and improve productivity. Windows 7 helps achieve these goals. However, organizations do not maximize the return on investment of Windows 7 without modern infrastructure to support it.
We want organizations to benefit from the latest platform's features. To achieve these goals, we want to help organizations migrate to our latest management platform. To do this, we have released a compatibility pack that adds Windows 7 and Windows Server 2008 R2 as supported clients in Microsoft Systems Management Server (SMS) 2003 Service Pack 3 (SP3). This compatibility pack helps SMS 2003 SP3 users migrate their software to Configuration Manager 2007 while realizing immediate benefits from their Windows 7 investment.
For all the details and to download the Compatibility Pack see the following new Knowledge Base article:
KB974014 - Compatibility Pack for SMS 2003 SP3 that adds Windows 7 and Windows Server 2008 R2 as supported clients
J.C. Hornbeck | System Center Knowledge Engineer
The Application Compatibility Toolkit Connector (ACT Connector) assists administrators with collecting the necessary computer and application compatibility information to help plan for a Windows deployment.
The ACT Connector provides the following functionality:
- Inventories installed software applications and creates reports that will assist with determining which applications are Windows compatible.
- Retrieves device driver compatibility for installed devices and creates reports that will assist with determining which device drivers will need to be upgraded to support the Windows operating system.
You can read all the details and download the connector at http://www.microsoft.com/downloads/details.aspx?FamilyID=567be755-1d64-471d-8376-6b463491654b&displaylang=en
J.C. Hornbeck | System Center Knowledge Engineer
With the R2 release of System Center Configuration Manager 2007, the product now supports the use of SQL Reporting Services as a reporting solution. This is the direction for reporting going forward and it offers a good number of exciting possibilities for building great custom reports. In the January edition of TechNet magazine, our very own Steve Rachui published an article discussing this feature and showing a sample method for building custom reports:
Reporting is a crucial ability for most organizations—and the ability to provide robust reporting of various Microsoft System Center Configuration Manager (SCCM) functions is no exception. Reporting is a feature that hasn’t changed much over several versions of Systems Management Server and SCCM. With the release of SCCM R2, reporting has undergone one significant change—the ability to interface and take advantage of SQL Server Reporting Services (SSRS). This one change brings with it the ability to make use of the many robust features SSRS provides. Like any new technology, there is a learning curve associated with SSRS—but the benefits are well worth it. This article will discuss the integration between SCCM and SSRS and walk through a very simple example of building a report in SSRS and publishing for use in SCCM.
To continue reading see http://technet.microsoft.com/en-us/magazine/ee914611.aspx
J.C. Hornbeck | System Center Knowledge Engineer
I was having trouble finding this post on the old SMSandMOM blog without a direct link, and saw this question asked on an alias so I thought it would be worth posting again on the new blog site for ConfigMgr 2007. This post describes how to move the Site Database for Configuration Manager 2007 to another drive, or another computer running SQL 2005.
INTRODUCTION
This article describes how to move the Site Database in Microsoft System Center Configuration Manager 2007 from a computer that is running Microsoft SQL Server 2005 to another drive on the same computer, or to another computer that is running SQL Server 2005.
MORE INFORMATION
In certain situations, you may have to move the Site Database from a computer that is running SQL Server 2005 to another drive, or to another computer that is running SQL Server 2005. For example, the following situations may require that you move the Site Database:
- You experience hardware issues on the server that you currently use. Additionally, you do not consider the server to be reliable.
- You have to move the Site Database and the log file to a different volume because the database requires more space, or because you want to improve performance.
- The server that you currently use is leased. The lease on the server is scheduled to expire soon.
- New hardware standards have been developed and approved. You must upgrade the computer that is running SQL Server 2005 to the new hardware specifications.
SQL Server 2005 supports the following:
- You can move files and log files from one computer to another computer if both computers are running SQL Server 2005.
- You can move data files and log files from one instance of SQL Server 2005 to another instance of SQL Server 2005 if both instances are on the same computer.
- You can move data files and log files from one volume to another volume on a computer that is running SQL Server 2005.
For more information about these functionalities in SQL Server 2005, visit the following Microsoft Web site: http://technet.microsoft.com/en-us/library/ms203721.aspx
PREREQUISITES
Before you move the Site Database from a computer that is running SQL Server 2005 to another drive or another computer that is running SQL Server 2005, follow these steps:
- Back up all the databases from their current locations. This includes the master database.
- Verify that you have system administrator permissions on both the computers that are running SQL Server 2005.
- Verify that you have configured the computer where you want to move the Site Database exactly like the computer that currently hosts the Site Database.
- Verify that you know the name and the current location of the Site Database.
- Stop the following Configuration Manager services on the Microsoft System Center Configuration Manager 2007 site server:
• SMS_EXECUTIVE Service
• SMS_SITE_COMPONENT_MANAGER Service
• SMS_SITE_SQL_BACKUP Service
• SMS_SITE_VSS_WRITER
Note: You can stop all of these services using the Preinst.exe utility by running the following command without the quotes:
"Preinst.exe /STOPSITE"
Preinst.exe is included with Microsoft System Center Configuration Manager 2007 Server and is located in the following path:
Drive:\Program Files\Microsoft Configuration Manager\bin\i386\00000409 (the last folder is dependent upon the language of the product, 00000409 is for the English version).
Note: If you are running the SMS Provider and the Site Database on the same SQL 2005 Server, and you are moving the Site Database to a new server, you will also need to modify the SMS Provider Configuration in order to move it as well, For more information about moving the SMS Provider in Microsoft System Center Configuration Manager 2007, visit the following Microsoft Web site: http://technet.microsoft.com/en-us/library/bb693923.aspx.
MOVING THE DATABASE
To move the Site Database from a computer that is running SQL Server 2005 to another drive or another computer that is running SQL Server 2005, follow these steps:
Step 1: Detach the database
1. On the computer that currently hosts the Site Database, click Start, point to Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio.
2. Click the appropriate values in the Server type list, in the Server name list, and in the Authentication list. Then, click Connect.
3. Expand the Databases folder, right-click the SMS_<DatabaseName> folder, point to Tasks, and then click Detach. Note that the Detach command is visible only if the following conditions are true:
• You are a member of the sysadmin fixed server role.
• The server to which you are connected is running SQL Server 2005.
4. Verify the status of the Site Database. Note that to successfully detach the Site Database, the status in the Databases to detach box in the Status column must read: "The database is ready to be detached." Optionally, you can update statistics before the detach operation. To do this, select the check box under the Update Statistics column in the Databases to detach box.
5. To close any existing connections in the Site Database, select the check box under the Drop Connections column in the Databases to detach box.
6. Click OK. The database node of the detached Site Database disappears from the Databases folder.
7. After the Site Database is detached, copy the SMS_<DatabaseName>.mdf file and the SMS_<DatabaseName>.ldf file to the drive and path you want to move it to, or to a folder on the computer to which you want to move the Site Database.
Note: The following path is the default path of the SMS_<DatabaseName>.mdf file:
Drive :\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data
The following path is the default path of the SMS_<DatabaseName>.ldf file:
Drive :\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data
Step 2: Attach the database
1. Click Start, point to Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio.
2. Click the appropriate values in the Server type list, in the Server name list, and in the Authentication list. Then, click Connect.
3. Right-click the Databases folder, and then click Attach. Note The Attach command is visible only if the following conditions are true:
- You are a member of the sysadmin fixed server role.
- The server to which you are connected is running SQL Server 2005.
4. In the Attach Databases dialog box, click Add to specify the database that you want to attach.
5. Locate and then click the SMS_<DatabaseName>.mdf file. Then, click OK.
Note The following path is the default path of the SMS_<DatabaseName>.mdf file: Drive :\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data
6. On the View menu, click Refresh to view the database node of the attached Site Database.
Note: If you moved the Site Database files to another drive on the same computer, then your move is complete, and you can start the following services:
- SMS_EXECUTIVE Service
- SMS_SITE_COMPONENT_MANAGER Service
- SMS_SITE_SQL_BACKUP Service
- SMS_SITE_VSS_WRITER
Step 3: Update the database server name
If you moved the Site Database to another server, you need to run the Microsoft System Center Configuration Manager Setup Wizard on the Microsoft System Center Configuration Manager 2007 Server to modify the SQL Server configuration to specify the new SQL Server name.
1. Ensure the primary site server computer account has administrative privileges over the new site database server computer.
2. Close any open Configuration Manager console connections to the site server.
3. On the primary site server computer, use the hierarchy maintenance tool (Preinst.exe) to stop all site services with the following command: Preinst /stopsite.
4. On the primary site server computer, click Start, click All Programs, click Microsoft System Center, click Configuration Manager 2007, and click ConfigMgr Setup, or navigate to the .\bin\i386 directory of the Configuration Manager 2007 installation media and double-click Setup.exe.
5. Click Next on the Configuration Manager Setup Wizard Welcome page.
6. Click Perform site maintenance or reset this site on the Configuration Manager Setup Wizard Setup Options page.
7. Select Modify SQL Server configuration on the Configuration Manager Setup Wizard Site Maintenance page.
8. Enter the appropriate SQL Server name and instance (if applicable) for the new site database server as well as the site database name on the Configuration Manager Setup Wizard SQL Server Configuration page.
9. Configuration Manager Setup performs the SQL Server configuration process.
10. Restart the primary site server computer, and verify the site is functioning normally.
Note: If you also need to move the Software Update Services Database (SUSDB) you will need to stop IIS Admin Service, and Update Services Service and follow Steps 1 and 2 above to detach, then move the SUSDB.MDF and SUSDB.LDF files, then attach the SUSDB.MDF, in the new drive location or on the new SQL Server 2005.
Enjoy!
Clifton Hughes | Senior Support Engineer – System Center
Consider the following scenario:
- You install the distribution point role on a Microsoft System Center Configuration Manager 2007 Service Pack 1 (SP1) site server.
- You customize the retry settings on the Distribution Point tab for the distribution point. Or, you use the default value for the retry settings.
- A retry is required after a package distribution fails.
In this scenario, the Distribution Manager does not honor the retry settings on the Distribution Point tab when the Distribution Manager retries the distribution.
Note Before each retry, there is a 10-second delay.
For information on the hotfix and associated settings needed to resolve this see the following new Knowledge Base article:
KB978875 - The Distribution Manager does not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings on SCCM 2007 SP1 site servers
J.C. Hornbeck | System Center Knowledge Engineer
Jeff Wettlaufer posted a cool video demonstrating the new "Prestaged Media" deployment option included in the upcoming ConfigMgr 2007 R3 over on the System Center Team blog. It's only about 4 to 5 minutes long so if you have a few spare cycles today and you haven't already seen it you should stop by and check it out:
http://blogs.technet.com/systemcenter/archive/2010/01/20/os-deployment-enhancements-in-configuration-manager-2007-r3.aspx
J.C. Hornbeck | System Center Knowledge Engineer
International Client Packs (ICPs) contain international-language clients to use with System Center Configuration Manager (SC Config Mgr) 2007 SP2. ICP downloads contain only the Config Mgr client files, not the English-language SC Config Mgr 2007 SP2, which is required.
ICP1 contains the following languages:
- English
- French
- German
- Japanese
- Spanish
ICP2 contains all languages from ICP1 plus the following:
- Chinese (Simplified)
- Chinese (Traditional)
- Czech
- Danish
- Dutch
- Finnish
- Greek
- Hungarian
- Italian
- Korean
- Norwegian
- Polish
- Portuguese
- Portuguese (Brazil)
- Russian
- Swedish
- Turkish
For all the details and to download the ICPs see http://www.microsoft.com/downloads/details.aspx?familyid=4C8FA7D6-1671-4D76-860B-195B16C214A8&displaylang=en
J.C. Hornbeck | System Center Knowledge Engineer
I know this isn't necessarily Configuration Manager specific but I figured that some of you may still have some old Windows 2000 or Windows XP SP2 systems running out there and would appreciate the heads up.
As the title says, Windows XP SP2, Windows 2000 Server and Windows 2000 Professional are reaching End of Support (EOS) on July 13, 2010 (and Windows Vista RTM End of Support is on April 13, 2010). This means that regular Microsoft support and free access to security updates will come to an end for those products on those dates.
To help with planning your migration strategy to Windows 7, Windows Server 2003, Windows Server 2008 or Windows Server 2008 R2, we have the Windows 2000 End-of-Support Solution Center which is a fantastic place to start. It has information on planning your move, migrating clients and server roles, Small Business Server, Application Compatibility and much much more. It's a definite must-see site and you can check out all the details at http://support.microsoft.com/win2000.
For more information see the Microsoft Support Lifecycle Policy.
J.C. Hornbeck | System Center Knowledge Engineer
Purpose:
This post is intended to explain how client approval works when a Mixed Mode Configuration Manager 2007 site is configured to automatically approve clients in trusted domains and to offer insight into how to troubleshoot scenarios where this is not working as expected. The configuration is shown below:
The short version:
- The new client performs a CCM_POST to CCM_System_WindowsAuth on the MP.
- The MP responds with a 401 as the request is anonymous and contains no security data.
- The client requests a Kerberos ticket for http://MP_FQDN from Active Directory (e.g. http://SCCMMP.Contoso.com).
- On obtaining the Kerberos ticket, the client performs another CCM_POST including the security data.
- If the MP accepts the ticket then the client is authenticated and is considered to be trusted.
- Whether the client is trusted or not, the MP executes the spUpdateClientRegistration stored procedure to update the database. If the client has authenticated properly, both the @ApprovalMethod and @IsIntegratedAuth parameters will be set to 1. If not, they are both set to 0.
Technical details:
The following is from data obtained in my lab during a successful test where a client in a child domain (Child.A2003.VM.local) was automatically approved by the MP in Child’s parent domain (A2003.VM.local). Relevant details:
- Client is WK02-020-51W.Child.A2003.VM.local with IP address 192.168.20.102
- The DC for the Child domain is DC03-020-52S with IP address 192.168.20.10
- The MP is SMS4-120-52S.A2003.VM.local with IP address 192.168.120.20
- The DC for the A2003 domain is DC02-110-61E with IP address 192.168.110.10
The IIS log shows:
2009-05-20 19:35:11 W3SVC1 192.168.120.20 CCM_POST /ccm_system_windowsauth/request - 80 - 192.168.20.102 ccmhttp 401 2 2148074254
2009-05-20 19:35:13 W3SVC1 192.168.120.20 CCM_POST /ccm_system_windowsauth/request - 80 CHILD\WK02-020-51W$ 192.168.20.102 ccmhttp 200 0 0
Code 2148074254 or 0x8009030E means SEC_E_NO_CREDENTIALS
MP_RegistrationManager.log shows:
MP Reg: DDR file written to E:\SMS\inboxes\auth\ddm.box\regreq\A8Z82CVO.RDR
Network Monitor shows:
Client issues the CCM_POST with no security information, starting in frame 4:
The MP responds with the HTTP 401 in frame 10:
The client requests a Kerberos ticket for the HTTP SPN of the MP from the Child domain DC in frame 13:
The Child DC refers the client to the A2003 domain DC in frame 14:
The client then makes the same Kerberos request to the A2003 DC in frame 15:
The A2003 DC responds with a Kerberos ticket in frame 16:
The client reissues the CCM_POST, with security information, in frame 17:
The MP responds with an HTTP 200 in frame 25:
SQL Profiler shows the MP executing spUpdateClientRegistration with values of 1 (True) for the relevant parameters so the client is set to Approved in the database (with parameters inlaid):
exec spUpdateClientRegistration (@SiteCode) "2P4", (@SMSID) "GUID:EEAF9390-94EB-43AE-A0DE-F374E3E7E03B", (@CSMSID) NULL, (@Identity) NULL, (@DeviceID) NULL, (@Certificate) 0x308201E03082014DA0030201020210C25D7C383E3CB6AE466BE10C22ACF3AE300906052B0E03021D05003025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D533020170D3039303531393139333434375A180F32313039303432363139333434375A3025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D5330819F300D06092A864886F70D010101050003818D0030818902818100BAEB59B8B0ECB451AB82FECF42791740BB3704BD00705126D3DA0FB7618B53955CFF142534B09ACDB97B6B8E42D10663453EA6C35A0BC30A3A83F3381B507A4D051C884E9789DC827223C1C92D0C4712458DAF96A8F15CABE2AB14ED9755A89034657CCB96A7086DFB92E928C35626F08F6A3FA451206850CEC0FC8EC671E09F0203010001A317301530130603551D25040C300A06082B06010401823765300906052B0E03021D050003818100A7A603A7E7AFB19E7518F62F5D4153FA3926AA8348D9EFCB9EC4C03AB991202CB2496B48489C6E6AB48E673ECA6DBED3A4EC7FBE1D3BB70682338FC5E4A86BCEBC4702EDBB41F060AD54117707AFCD0A2FC8AF17DF9E71F1206FBCE9295237322029956D2AA652B41F1258D617BBC4D07410F01CC40042D33BA97511F2B2DDCA, (@Thumbprint) 0xE824658E489FDBB6481ED7788E74877FB9DBCF0B, (@EncKey) 0x308201E13082014EA00302010202106866F6C06283B38644D10B448CFAE966300906052B0E03021D05003025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D533020170D3039303531393139333434385A180F32313039303432363139333434385A3025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D5330819F300D06092A864886F70D010101050003818D0030818902818100BC71E0923FBF50300A40C479CBCE5F49D20597C00873C5F6ED16538A41FF5FA54B402905DB424D95B1D67FFFD6245204E4B5FD6A751087BAFD6846FA1272E6F0405EEB647020BB8DFD2E78516C263ECE8831E17CD230C5637AA83AE222B900530977A57F390AD6542C344AB6DD6F8D7ED8CAED76A3F700ED0250ED64481C9D550203010001A318301630140603551D25040D300B06092B0601040182376502300906052B0E03021D0500038181008D63DEC508A14404372B3BEE2AD35D8B44C7C6E2AA8B81A9FA8280D416FFAB67DDDA1F37B981523DA6EEBF66CDE9F7C501412D1438E0FC490C022BC4CA854EFAA975D49182A3300C76577B4BE15B5FCB0014C36E0C418EE98F13AF6264E69C0DCFFFADD1D0800400A15630FA6C023B989D341F33E197885001601CFFC015AA0B,(@EncThumbprint) 0x6B186E7BC2B86B059FAE5E431C6C6CE40A943F3C,(@KeyType) 1, (@PublicKey) 0x06020000002400005253413100040000010001009FE071C68EFCC0CE50682051A43F6A8FF02656C328E992FB6D08A796CB7C653490A85597ED14ABE2AB5CF1A896AF8D4512470C2DC9C1237282DC89974E881C054D7A501B38F3833A0AC30B5AC3A63E456306D1428E6B7BB9CD9AB0342514FF5C95538B61B70FDAD326517000BD0437BB40177942CFFE82AB51B4ECB0B859EBBA, (@ValidFrom) "2009-05-19 19:34:47.000", (@ValidTo) "2109-04-26 19:34:47.000", (@AgentType) 0, (@SMBIOSID) NULL , (@MACAddress) NULL , (@HardwareID1) "2:D4D8AD1963DA464FC3EE60E5212310036AB9EDEC", (@ISVProxyID) NULL , (@AlwaysInternet) 0, (@InternetEnabled) 0, (@Force) 0, (@ApprovalMethod) 1, (@ResolutionMethod) 0, (@IsIntegratedAuth) 1, (@Version) "4.00.6221.1000", (@NetbiosName) "WK02-020-51W", (@FQDName) "WK02-020-51W.Child.A2003.VM.local", (@ManualConflictResolution) 0
Troubleshooting:
Standard troubleshooting of these issues should include:
- Checking the duplicate GUID report to see if the problem client’s GUID is present. If so, run CCMDelCert on the problem client to force a new GUID to be generated and see if that resolves the issue.
- If duplicate GUIDs do not apply then step through the following:
- Delete the problem client from the central site console and let the delete cascade to child sites, as appropriate.
- Set the SMS Agent Host service to manual on the client and reboot it.
- Start a network capture on the client (NetCap, NetMon 3.x, Ethereal, etc).
- Set the SMS Agent Host service back to Automatic and start it.
- Initiate a Discovery Data Collection Cycle via the Control Panel applet.
- If the client is re-inserted into the database as not approved then collect the network capture (and all relevant IP details) with the IIS log and MP_RegistrationManager.log from the MP to which the client reports directly for review.
- If the network capture shows the client does get a Kerberos ticket then the IIS log should contain a Win32 error code indicating why the MP rejected it.
- If the client does not get a ticket then the response from the DC in the capture should detail why. Kerberos logging on the client, per KB262177, may add some useful information to the System Log in Event Viewer as well. Since Directory Services supports Kerberos, they may be engaged for assistance in determining why no ticket was acquired.
Note: The MP_RegistrationManager.log does not contain much detail by default. Enabling Verbose and Debug CCM logging will add some extra entries which may be helpful.
Known reasons why this will fail:
Duplicate GUIDs: Duplicate GUIDs can cause a myriad of client data integrity problems including client approval issues. If only a subset of the clients are impacted by the client approval failure then duplicate GUIDs should be investigated.
The HTTP SPN is registered under a user account: Normally, there is no HTTP SPN for a server so the HOST SPN, which should always be on the computer object, is used in obtaining the Kerberos ticket. If web based services, such as SQL Reporting Services, are running under user context on the MP, and the HTTP SPN is linked to that user account, the Kerberos ticket obtained by the client will be for the same user. When presented to the MP, which runs as Local Service (System), it is rejected because it is linked to the wrong user.
The solution for this is to delete the HTTP SPN from the user object, move the web service running as the user to a different web site using a different port and create a new HTTP SPN to refer to the new port. For example, for a new web site using TCP port 81, the new HTTP SPN, created under the user object in AD, would be similar to:
HTTP://SCCMMP.Contoso.com:81
Reference http://msdn.microsoft.com/en-us/library/aa480609.aspx which states:
SPNs are only created for the HOST service and all built-in services use the HOST SPN. However, this implementation is transparent because built-in names act as an alias to the HOST service unless they have been specifically mapped to a Windows account.
And also:
When you use Windows Integrated Security, both Internet Explorer and IIS use the HTTP SPN to request service tickets and to process a request. As a result, when you use a domain user account in IIS 6.0 as the process identity, you must map the host-based HTTP SPN to the domain account that is used by the service.
Client and MP in different domains only share an external trust:
As is noted above, Kerberos is required for the client to authenticate to the MP. While Kerberos *may* work across an external domain trust, it is not supported. It is only supported across a forest trust between two Windows Server 2003 mode (or higher) forests.
Reference http://technet.microsoft.com/en-us/library/cc773178(WS.10).aspx which states:
When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests.
Anything else that causes Kerberos to fail:
Kerberos can fail for many reasons including time skews in the environment; DNS name resolution failures, etc. Generally, network capture data will show why it is failing though Kerberos logging per KB262177 can also be helpful.
More Information:
General information on Client Approval can be found at http://technet.microsoft.com/en-us/library/bb694193.aspx.
Keith Thornley | Senior Support Escalation Engineer
