- Windows PE before HDD format: x:\windows\temp\smstslog\smsts.log
- Windows PE after HDD format: x:\smstslog\smsts.log and copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
- Full version Windows before SCCM agent installed: c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
- Full version Windows after SCCM agent installed: c:\windows\ccm\logs\Smstslog\smsts.log
- Full version Windows (x64) after SCCM agent installed: c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
- After Task Sequence has finished running: c:\windows\ccm\logs\smsts.log
- After Task Sequence has finished running (x64): c:\windows\sysWOW64\ccm\logs\smsts.log
After our SCCM upgrade from 2012 R2 SP1 to SCCM 1511 applications, OSs etc would not deploy. The client would sit at 0% downloading.
If you clicked “update content” on the installer within the SCCM console it would then install on the client. Investigating further I found the following error in the DataTransferService.log on the client
<![LOG[[CCMHTTP] ERROR: URL=http://<DP SERVER NAME>:80/SMS_DP_SMSPKG$/Content_53b51003-972a-41a7-bc75-0a22b18ceaef.1, Port=80, Options=480, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE]LOG]!><time=”09:13:45.837+00″ date=”02-10-2016″ component=”DataTransferService” context=”” type=”1″ thread=”5284″ file=”ccmhttperror.cpp:291″>
This highlighted that the file could not be found on the web server. I checked the file location in IIS on the DP, it was pointing to E:\SMSPKGSIG – as expected the file it was trying to download did not exist.
To find the application that went with this Content ID I sued the following PowerShell script on the DP/Site server (I cannot remember what website I found this script on so apologies to the author)
$SiteCode = ‘Site Code’
$ContentID = ‘Content_53b51003-972a-41a7-bc75-0a22b18ceaef.1’
#Get-WmiObject -Namespace root\sms\site_$SiteCode -ComputerName $Server -Class SMS_Deploymenttype
Get-WmiObject -Namespace root\sms\site_$SiteCode -Class SMS_Deploymenttype -Filter “ContentID = ‘$($ContentID.Split(“.”))'” | Select LocalizedDisplayName -Unique
I validated the application on this DP and it failed and suggested redistributing. This did not resolve the problem but in the distmgr.log file on the site server hosting the DP role I found this error
RDC:Failed to copy package content signature file \\?\C:\SMSPKGSIG\Content_53b51003-972a-41a7-bc75-0a22b18ceaef.1.tar to \\<SERVER NAME>\SMSSIG$\Content_53b51003-972a-41a7-bc75-0a22b18ceaef.1.tar. Error 2
The strange thing was, the SMSPKGSIG directory should be on the E drive for our server(as set in IIS). When I check the c:\SMSPKGSIG directory I found the Content_53b51003-972a-41a7-bc75-0a22b18ceaef.1.tar file.
It would appear after upgrading the DP has changed its location for the SMSPKGSIG & SCCMContentLib directories and is now looking for them on the C drive & E Drive.
I used the ContentLibraryTransfer.exe tool from the ConfigMgr 2012 Toolkit R2 with the following command to transfer the library back to the E drive.
ContentLibraryTransfer.exe -SourceDrive C -TargetDrive E
I then revalidated the content of the failing package on the DP and it passed.
I scheduled a validation on all content – this should have already been on as it is on our other DPs
All Applications and OSs are now deploying again.
Hope this helps someone else as this caused massive head scratching!
If you get “The Operations Manager web console was not configured successfully on this computer. Some views in the web console will not function correctly. Unable to import code signing certificate. System Error -2147024891 (0x80070005): Access is Denied” Check your group policy settings.
The users need to be able to mage there own Trusted Publishers. As screenshot below
This GPO Setting is under Computer Configeration\Policies\Windows Settings\Security Settings\Public Key Policies\Certificate Path Validation Settings
This same setting caused the following error in Configuration Manager 2012 (and 2012 R2) when trying to install software from the users application catalogue
Hope this helps someone else
“This setting cannot be configured because of a network communication or configuration problem.”
Add the following registry key to the SCCM Distribution Point and restart the WDS service:
TYPE: REG_DWORD Value: 16384
For us this made a massive difference from over 5 mins to under 15 seconds!