“The Thread is not in Background Processing Mode” when trying to download updates from SCCM console and patchdowner.log prints “HTTP_STATUS_FORBIDDEN or HTTP_STATUS_DENIED” and 0x80070193
ISSUE
“The Thread is not in Background Processing Mode” when trying to download updates from SCCM console
This can happen when you try to manually download updates from Configuration Manager console. In the patchdownloader.log you may see the following error:
HTTP_STATUS_FORBIDDEN or HTTP_STATUS_DENIEDError: DownloadUpdateContent() failed with hr=0x80070193
Error Code: 0x80070193 (403) Error Name: ERROR_PROCESS_MODE_NOT_BACKGROUND Error Source: Windows Error Message: The process is not in background processing mode.
Here I adapted what Scott Breen explained in the tech forum for reference which can put this issue through, I think:
Configuration Manager needs to internet access to download source files for Software Updates. This process goes by the following way: – Way 1: The Configuration Manager server during the execution of an Automated Deployment Rules (ADR); – Way 2: The Configuration Manager console (in the user context on the computer where the console is running) during creation of a Software Update package.
Note that the download process requires the computer or user account where the download originates to have access direct to the internet or through a proxy server.
The proxy server configured within Configuration Manager settings is for the server initiated downloads only (Way 1 above) – NOT the console initiated downloads.
If you are downloading via Configuration Manager console, you need to ensure that the account you are using has proxy settings configured in Internet Options (or Internet Explorer options) – https://support.microsoft.com/en-us/kb/2777643. Note that if you logged on with a different account, but are running the console as another user you will need to option Internet Options as that user (which you can do by running Internet Explorer as that account).
Client computers show up in Unknown tab in Deployment status after updates deployment
One of the most common issues you ever come across is that client computers stay in Unknown tab in Deployment status in SCCM console. There are several reasons for this:
The client computer is turned off
The client computer is considered inactive by SCCM, though it is running actually as you observed
The client computer has an issue with updates scanning
The last probability is most seen. Recently I ran into such an issue caused by problematic updates scanning.
ScanAgent.log shows the following messages.
03-21-2022 16:43:40.123 ScanAgent 2928 (0xb70) ScanJob({383C1CD8-0555-44E4-A96A-551EA38718F6}): CScanJob::OnScanComplete -Scan Failed with Error=0x80240437
03-21-2022 16:43:40.139 ScanAgent 2928 (0xb70) ScanJob({383C1CD8-0555-44E4-A96A-551EA38718F6}): CScanJobManager::OnScanComplete- failed at CScanJob::OnScanComplete with error=0x80240437
0x80240437 means –
Error Code: 0x80240437 (2149844023)
Error Name: WU_E_PT_SECURITY_VERIFICATION_FAILURE
Error Source: Windows Update Agent
Error Message: There was a problem authorizing with the service.
This error code points out that the client has a communication security issue with the software update point. Looks like the client was rejected by the software update point server.
LocationServices.log reveals the wsus server it was trying to connecting to.
03-21-2022 16:43:35.295 LocationServices 2928 (0xb70) Calling back with the following WSUS locations
03-21-2022 16:43:35.295 LocationServices 2928 (0xb70) WSUS Path='https://contososup.test.lab:8531', Server='contososup.test.lab', Version='4241', LocalityEx='BOUNDARYGROUP', SUPFallbackIn='0'
As you can see, the client was connecting to contososup.test.lab at port 8531. Testing the communication between the client and the software update point with TNC contososup.test.lab -Port 8531. All was good.
Then I captured two network trace files while triggering a Software Update Scan cycle from Configuration Manager client UI. The two network traces show the following interesting behaviour.
Client –
Server –
The client and server could establish TCP 3 handshake but failed with TLS 1.2 connection. At that moment, I suspected the server might not support TLS 1.2. However, SoftwareDistribution.log from the software update point server proved me wrong. The logs says TLS 1.2 is indeed enabled.
Remoting into the software update point server, I verified TLS 1.2 with IIS Crypto, a good free tool to check TLS settings.
What else to check? I launched WSUS console on the software update point server and caught sight of the following!
WSUS server was actually using port 8530 instead of 8531. Why the client was trying to connect at 8531? I went back to the client computer and check its wsus settings in the registry, which has the same information found in LocationServices.log.
As you know, SCCM sets local group policy to define WSUS settings. Is there something wrong about software update point role? With that thought, I went back to SCCM console and examined the software update point role settings. Voila, there is the answer: Require SSL communication to the WSUS server option is checked.
SOLUTION
Go to SCCM console
Navigate to the Software Update Point
Right click on it and then on Properties
Select General tab
Uncheck Require SSL communication to the WSUS server
Sometimes, you may need to retrieve updates deployment status from the site database. Here are some example queries that can helpful to you in some scenarios.
Get deployment status of updates in a deployment
-- Replace {873BFE1F-C688-4E61-9447-1E943ECFEF05} with the actual deployment ID
declare @DEPLOYMENTID nvarchar(max) = '{873BFE1F-C688-4E61-9447-1E943ECFEF05}'
select
vRS.name0 as ComputerName,
vUPI.Title as UpdateTitle,
vUPI.ArticleID,
vUPI.CI_UniqueID as UpdateID,
vCIA.CollectionID,
vCIA.AssignmentName as DeploymentName,
@DEPLOYMENTID as DeploymentID,
vCIA.AssignmentID,
vCIA.AssignmentName,
vCIA.CollectionName,
vSN.StateName as LastEnforcementState,
vASC.StateTime
from v_CIAssignment vCIA
join v_CIAssignmentToCI vCIA2CI ON vCIA2CI.AssignmentID = vCIA.AssignmentID
join v_UpdateInfo vUPI ON vUPI.CI_ID = vCIA2CI.CI_ID
join v_AssignmentState_Combined vASC on vCIA.AssignmentID=vASC.AssignmentID
join v_StateNames vSN on vASC.StateType = vSN.TopicType and vSN.StateID=isnull(vASC.StateID,0)
join v_R_System vrs on vRS.ResourceID=vASC.ResourceID
where vCIA.Assignment_UniqueID = @DEPLOYMENTID
order by ComputerName
Get deployment status of a specific update in a deployment
-- Replace 16777217 with an UserID from v_users that has full administrator rights
declare @UserSIDs nvarchar(max) = 16777217
-- Replace {873BFE1F-C688-4E61-9447-1E943ECFEF05} with the actual deployment ID
declare @DEPLOYMENTID nvarchar(max) = '{873BFE1F-C688-4E61-9447-1E943ECFEF05}'
-- Replace b3fb7000-1397-452f-81d3-4e9515450bfc with the actual deployment ID
declare @UPDATEID nvarchar(max) = 'b3fb7000-1397-452f-81d3-4e9515450bfc'
declare @UPDATETITLE nvarchar(max) select @UPDATETITLE=TITLE from v_UpdateInfo where CI_UniqueID = @UPDATEID
declare @ASSIGNID int = (select AssignmentID from fn_rbac_CIAssignment(@UserSIDs) where Assignment_UniqueID = @DEPLOYMENTID)
declare @LOCALUPDATEID int = (select CI_ID from fn_rbac_UpdateCIs(@UserSIDs) where CI_UniqueID=@UPDATEID)
select
uc.ResourceID,
m.Name0 as ComputerName0,
m.User_Domain0+'\'+m.User_Name0 as LastLoggedOnUser,
asite.SMS_Assigned_Sites0 as AssignedSite,
m.Client_Version0 as ClientVersion,
sn.StateName as Status,
isnull(uc.EnforcementSource, 0) as EnforcementState,
nullif(uc.LastEnforcementStatusMsgID&0x0000FFFF, 0) as ErrorStatusID,
nullif(uc.LastErrorCode, 0) as LastErrorCode,
@UPDATETITLE as UpdateTitle,
@UPDATEID as UniqueUpdateID,
uc.StateType*10000+uc.StateID as StateID,
statusinfo.MessageName as ErrorStatusName
from v_UpdateState_Combined uc
join v_CIAssignmentTargetedMachines ast on ast.ResourceID=uc.ResourceID and ast.AssignmentID=@ASSIGNID
join fn_rbac_CIAssignmentToCI(@UserSIDs) aci on aci.CI_ID = uc.CI_ID and aci.AssignmentID = @ASSIGNID
left join fn_rbac_StateNames(@UserSIDs) sn on sn.TopicType = uc.StateType and sn.StateID = uc.StateID
join fn_rbac_R_System(@UserSIDs) m on m.ResourceID=uc.ResourceID and isnull(m.Obsolete0,0)=0
left join v_RA_System_SMSAssignedSites asite on m.ResourceID = asite.ResourceID
left join fn_rbac_AdvertisementStatusInformation(@UserSIDs) statusinfo on statusinfo.MessageID=nullif(uc.LastEnforcementStatusMsgID&0x0000FFFF, 0)
where uc.CI_ID=@LOCALUPDATEID
order by m.Name0
Alternatively, use the following one. Pick the latest entry order by StateTime column in descending order.
-- Replace 16836015 with the actual CI_ID value
select * from v_UpdateState_Combined as vUPC join SR_StateNames as SRS
on vUPC.StateType = SRS.TopicType and vUPC.StateID = SRS.StateID
where CI_ID = 16836015;
CI_ID can be retrieved by running the following in CM PowerShell (Connect via Windows PowerShell from sccm console)-
Get-CMSoftwareUpdate -Name "2020-01 Update for Windows 10 Version 1909 for x64-based Systems (KB4497165)"| Select-Object -Property CI_ID
Microsoft 365 Apps Update – Semi-Annual Enterprise Channel Quality Update for x64 based Edition Version 2102 (Build 13801.21004) (KB3104046) fails to get installed on a client where both English and German Microsoft 365 Apps are installed
When only the English version of this M365 update is deployed to the client it can get installed successfully.
Error Code: 0x5B4 (1460) - 0x800705b4 Error Name: ERROR_TIMEOUT Error Source: Windows Error Message: This operation returned because the timeout period expired.
DTS log says it successfully downloaded ONE file. Just one file only and no more! However, the update with English and German version contain many other files and is over 3G in size.
10-26-2021 11:18:36.838 DataTransferService 12280 (0x2ff8) DTSJob {9B87386D-110C-4726-8A24-3CE821E071C6} created to download from 'https://contoso.lab.com:443/SMS_DP_SMSPKG$/162734f6-b630-4373-b5d2-f22b051a80be' to 'C:\WINDOWS\ccmcache\1a'.
10-26-2021 11:18:36.838 DataTransferService 4156 (0x103c) DTSJob {9B87386D-110C-4726-8A24-3CE821E071C6} in state 'PendingDownload'.
10-26-2021 11:23:48.526 DataTransferService 16608 (0x40e0) Updating ccmcache with the downloaded file data
10-26-2021 11:23:48.530 DataTransferService 16608 (0x40e0) Adding full file Office\Data\16.0.13801.21004\i640.cab to cache
10-26-2021 11:23:48.552 DataTransferService 16608 (0x40e0) Download completed for file sccm?/Office/Data/16.0.13801.21004/i640.cab
10-26-2021 11:23:48.578 DataTransferService 8084 (0x1f94) DTSJob {9B87386D-110C-4726-8A24-3CE821E071C6} in state 'NotifiedComplete'.
10-26-2021 11:23:48.579 DataTransferService 8084 (0x1f94) DTS job {9B87386D-110C-4726-8A24-3CE821E071C6} has completed:
Status : SUCCESS,
Start time : 10/26/2021 11:18:36,
Completion time : 10/26/2021 11:23:48,
Elapsed time : 311 seconds
Another interesting point is that UpdatesHandle.log prints the following information.
10-26-2021 11:17:59.144 UpdatesHandler 15148 (0x3b2c) CUpdate::CheckLocations - Checking locations on action (INSTALL) for Update (162734f6-b630-4373-b5d2-f22b051a80be)
10-26-2021 11:18:02.459 UpdatesHandler 15148 (0x3b2c) Starting download on action (INSTALL) for Alternate Update (162734f6-b630-4373-b5d2-f22b051a80be)
10-26-2021 11:18:02.553 UpdatesHandler 15148 (0x3b2c) CAtomicUpdate::ScheduleDownloadTimer - Timer started, download will timeout in 120 seconds
10-26-2021 11:20:02.570 UpdatesHandler 14608 (0x3910) ContentAvailable notification received from CAS.
10-26-2021 11:20:02.583 UpdatesHandler 14608 (0x3910) CAS failed to download update (162734f6-b630-4373-b5d2-f22b051a80be). Error = 0x800705b4. Releasing content request.
I had a hunch that it could be either related to missing content or to some antivirus.
With the help of ContentLibraryExplorer.exe tool on the primary site, I found that the update files of German version are missing. What was annoying was that Update distribution points could not refresh the target distributions as expected. In the end, I had to create a new package at a new location and distributed the package to the target distribution points. I deployed the update again to the client computer and voila, it worked!
Sometimes you may need to deployment via SCCM through Packages using the command WUSA. You may put in Command line in Program something like below: wusa.exe …..
After deployment, the client shows the update gets installed successfully but the SCCM console shows Error with the code 1641.
Strictly speaking, 1641 cannot even be considered as an error because all it asks is a reboot:
Error Code: 0x669 (1641)
Error Name: ERROR_SUCCESS_REBOOT_INITIATED
Error Source: Msi.h
Error Message: The requested operation completed successfully. The system will be restarted so the changes can take effect.
If you look at the execmgr.log, you can find similar information as below. You follow the instructions to restart the client computer, but the error messages in the SCCM console stays forever.
07-15-2021 16:18:03.644 execmgr 10342 (0x27a4) Program exit code 1641
07-15-2021 16:18:03.645 execmgr 10342 (0x27a4) Looking for MIF file to get program status
07-15-2021 16:18:03.647 execmgr 10342 (0x27a4) Script for Package:testpkg, Program: Install failed with exit code 1641
07-15-2021 16:18:03.660 execmgr 10342 (0x27a4) Raising event:
[SMS_CodePage(874), SMS_LocaleID(1054)]
instance of SoftDistProgramErrorEvent
{
AdvertisementId = "APRCONTOSO";
ClientID = "GUID:ed123456-e3e9-2345-9f26-3ff8b875f376";
DateTime = "20210715091803.654000+000";
ExitCode = "1641";
MachineName = "cntcontoso";
PackageName = "testpkg";
ProcessID = 4788;
ProgramName = "Install";
SiteCode = "CNT";
ThreadID = 10342;
UserContext = "NT AUTHORITY\SYSTEM";
};
07-15-2021 16:18:03.663 execmgr 10342 (0x27a4) Raised Program Error Event for Ad:APRCONTOSO, Package:testpkg, Program: Install
07-15-2021 16:18:03.685 execmgr 8256 (0x2040) Execution is complete for program Install. The exit code is 1641, the execution status is FailureNonRetry
A simple way to resolve is to wrap the command wusa.exe in a bat file, eg. installupdate.bat and add exit 0 at the end. Something like this:
wusa.exe ..... exit 0
That way the package will always return 0, which will be considered as a Success.
Looking at LocationServices.log, we found the following messages –
05-24-2021 22:59:00.664 LocationServices 5924 (0x1724) 1 proxy MP errors in the last 10 minutes, threshold is 5.
05-24-2021 22:59:49.974 LocationServices 13528 (0x34d8) 2 proxy MP errors in the last 10 minutes, threshold is 5.
05-24-2021 23:00:01.747 LocationServices 9620 (0x2594) 3 proxy MP errors in the last 10 minutes, threshold is 5.
05-24-2021 23:00:31.063 LocationServices 13528 (0x34d8) 4 proxy MP errors in the last 10 minutes, threshold is 5.
05-24-2021 23:00:46.937 LocationServices 15764 (0x3d94) Proxy MP error threshold reached, moving to next MP.
DataTransferService.log –
05-24-2021 23:04:44.994 DataTransferService 15764 (0x3d94) BITS compatible path: http://secondarysite.contoso.com:80/SMS_MP/.sms_pol?%7BF4CA6035-61A2-4146-89C0-50DB591157A0%7D.SHA256:36A294B138C353F4487562349357BE61D23B9C631D8707BC79B712A5D836DC0F
05-24-2021 23:04:44.994 DataTransferService 15764 (0x3d94) BITSHelper: Full source path to be transferred = http://secondarysite.contoso.com:80/SMS_MP/.sms_pol?%7BF4CA6035-61A2-4146-89C0-50DB591157A0%7D.SHA256:36A294B138C353F4487562349357BE61D23B9C631D8707BC79B712A5D836DC0F
05-24-2021 23:04:44.994 DataTransferService 15764 (0x3d94) BITSHelper, remote name = http://secondarysite.contoso.com:80/SMS_MP/.sms_pol?%7BF4CA6035-61A2-4146-89C0-50DB591157A0%7D.SHA256:36A294B138C353F4487562349357BE61D23B9C631D8707BC79B712A5D836DC0F, local name = C:\WINDOWS\CCM\Staging{F4CA6035-61A2-4146-89C0-50DB591157A0}.1.00.tmp
Visiting the highlighted link in the browser on the client computer returns 500 Server Internal Error.
Bits job, retrieved by running “bitsadmin /list /allusers /verbose“, has the following information. Obviously, something goes wrong with the management point on the secondary site. More likely relevant to IIS.
UID: {A5A891C5-4EB7-4EB2-BE44-19BB40F66CCA} DISPLAY: 'CCMDTS Job'
TYPE: DOWNLOAD STATE: TRANSIENT_ERROR OWNER: NT AUTHORITY\SYSTEM
PRIORITY: HIGH FILES: 0 / 2 BYTES: 0 / UNKNOWN
CREATION TIME: 5/24/2021 11:04:44 PM MODIFICATION TIME: 5/24/2021 11:17:58 PM
COMPLETION TIME: UNKNOWN ACL FLAGS:
NOTIFY INTERFACE: REGISTERED NOTIFICATION FLAGS: 11
RETRY DELAY: 60 NO PROGRESS TIMEOUT: 28800 ERROR COUNT: 14
PROXY USAGE: NO_PROXY PROXY LIST: NULL PROXY BYPASS LIST: NULL
ERROR FILE: http://secondarysite.contoso.com:80/SMS_MP/.sms_pol?%7BF4CA6035-61A2-4146-89C0-50DB591157A0%7D.SHA256:36A294B138C353F4487562349357BE61D23B9C631D8707BC79B712A5D836DC0F -> C:\WINDOWS\CCM\Staging{F4CA6035-61A2-4146-89C0-50DB591157A0}.1.00.tmp
ERROR CODE: 0x801901f4 - HTTP status 500: An unexpected condition prevented the server from fulfilling the request.
ERROR CONTEXT: 0x00000005 - The error occurred while the remote file was being processed.
We enabled the failed request tracing for IIS on the secondary site, then reproduced the issue by visiting the highlighted URL in red. No surprise, still 500 error. At the same time, failed request tracing logs are generated. Here is what we got –
It points to the getpolicy.dll, which is a file from SCCM itself. Okay, now we know that it is not the IIS that brings the issue but the management point itself.
In MP_Framework.log, we found this information –
MPDB ERROR - CONNECTION PARAMETERS
SQL Server Name : secondarysite.contoso.com\CONFIGMGRSEC
SQL Database Name : CM_SS1
Integrated Auth : True
MPDB ERROR - EXTENDED INFORMATION
MPDB Method : ExecuteSP()
MPDB Method HRESULT : 0x80004005
Error Description : Login failed for user 'lnsvr_admin'.
OLEDB IID : {0C733A63-2A1C-11CE-ADE5-00AA0044773D}
ProgID : Microsoft SQL Server Native Client 11.0
MPDB ERROR - INFORMATION FROM DRIVER
SQL Server Name : SCCMSiteDBSQL02
Native Error no. : 18456
Error State : 1
Class (Severity) : 14
Line number in SP : 1
But what is this ” lnsvr_admin ” user? We tried to find login failure information from the secondary site database CM_SS1 but got nothing (In fact, ” SQL Server Name : SCCMSiteDBSQL02 ” pointed out already the right target sql server but we neglected that information). What is going on? It dawned on us that there could be a linked server object in this secondary site database which is using ” lnsvr_admin ” as the connection account. We were right –
Right click on the linked server object and select Test Connection. It failed.
On the linked server’s events log, we could find similar messages –
The customer told us that that account’s password has been changed by their sql server administrator but they never did any change to the linked server object. All is clear now – the account ” lnsvr_admin ” has the wrong password in the linked server object and thus failed to connect to the linked server.
Solution
After we updated the password for ” lnsvr_admin ” to the correct one, all the errors in MP_Framework.log went away and the ” proxy MP errors …” also disappeared from LocationServices.log and Software Center finally shows applications and updates.
Office 365 updates sync failed with “Failed to download or process the O365 file manifest. Caught exception: System.IO.FileNotFoundException: Failed to download file manifest for O365 from http://officecdn.microsoft.com/pr/wsus/ofl.cab, with error 12029~~”
Issue: Software Update synchronization failed with the following exceptions in wsyncmgr.log.
SMS_WSUS_SYNC_MANAGER 8032 (0x1f60) Failed to download file- "http://officecdn.microsoft.com/pr/wsus/ofl.cab" from internet. Using proxyserver - 0. Error = 12029
SMS_WSUS_SYNC_MANAGER 8032 (0x1f60) Failed to download or process the O365 file manifest. Caught exception: System.IO.FileNotFoundException: Failed to download file manifest for O365 from http://officecdn.microsoft.com/pr/wsus/ofl.cab, with error 12029 at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.DownloadAndExtractCabFile(String cabFileUrl, String fileNameInCab) SMS_WSUS_SYNC_MANAGER 8032 (0x1f60) Failed to download or process the O365 file manifest. Caught exception: System.IO.FileNotFoundException: Failed to download file manifest for O365 from http://officecdn.microsoft.com/pr/wsus/ofl.cab, with error 12029
at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.DownloadAndExtractCabFile(String cabFileUrl, String fileNameInCab)~~
at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.DownloadO365FileManifest(String fileManifestCabURL, String o365FileManifestXml)
SMS_WSUS_SYNC_MANAGER 8032 (0x1f60) Failed to synchronize O365 update bcaa6153-dd4b-4f69-bc39-e546554312c7 - Office 365 Client Update - Deferred Channel (1602-17) 64-bit Edition
Solution:
The hierarchy’s top level WSUS server and the top level Configuration Manager site server must have access to the following URLs:
In the previous post “Office 365 update failed to download with error 0x8007362e“, I described how to fix the issue by playing with the database. However, my customer asked me to fix all the remaining Office 365 updates seeing the same behaviour. I thought it would be enough to do a full synchronization. To my surprise, the synchronization failed.
wsyncmgr.log –
01-26-2021 15:09:19.835 SMS_WSUS_SYNC_MANAGER 8860 (0x229c) Failed to download file- "http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be/office/data/16.0.13628.20274/s320.cab" from internet. Using proxyserver - 0. Error = 80
01-26-2021 15:09:19.867 SMS_WSUS_SYNC_MANAGER 8860 (0x229c) Failed to download or process the O365 file manifest. Caught exception: System.IO.FileNotFoundException: Failed to download file manifest for O365 from http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be/office/data/16.0.13628.20274/s320.cab, with error 80 at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.DownloadAndExtractCabFile(String cabFileUrl, String fileNameInCab) 01-26-2021 15:09:19.867 SMS_WSUS_SYNC_MANAGER 8860 (0x229c) GetOfficeFileHash_O365Service() failed to get file hash for O365 file. Caught exception: System.IO.FileNotFoundException: Failed to download file manifest for O365 from http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be/office/data/16.0.13628.20274/s320.cab, with error 80
at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.DownloadAndExtractCabFile(String cabFileUrl, String fileNameInCab) at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.GetOfficeFileHash_O365Service(O365FileList o365FileList, String fileContainingHash, String updateId) 01-26-2021 15:09:19.867 SMS_WSUS_SYNC_MANAGER 8860 (0x229c) ProcessOfficeFile() failed to get file properties from file manifest. Caught exception: System.IO.FileNotFoundException: Failed to download file manifest for O365 from http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be/office/data/16.0.13628.20274/s320.cab, with error 80
at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.DownloadAndExtractCabFile(String cabFileUrl, String fileNameInCab) at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.GetOfficeFileHash_O365Service(O365FileList o365FileList, String fileContainingHash, String updateId)
at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.ProcessOfficeFile_O365Service(O365FileList o365FileList, Int32 iFile, XmlWriter xml, String updateId)
01-26-2021 15:09:19.867 SMS_WSUS_SYNC_MANAGER 8860 (0x229c) ProcessFileManifest() failed to process O365 file manifest. Caught exception: System.IO.FileNotFoundException: Failed to download file manifest for O365 from http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be/office/data/16.0.13628.20274/s320.cab, with error 80 at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.DownloadAndExtractCabFile(String cabFileUrl, String fileNameInCab)
at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.GetOfficeFileHash_O365Service(O365FileList o365FileList, String fileContainingHash, String updateId) at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.ProcessOfficeFile_O365Service(O365FileList o365FileList, Int32 iFile, XmlWriter xml, String updateId)
at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.ProcessFileManifest_O365Service(String sO365ServiceUrl, XmlWriter xml, String updateId)
01-26-2021 15:09:19.867 SMS_WSUS_SYNC_MANAGER 8860 (0x229c) Failed to synchronize O365 update 5f3e8945-7806-4ec2-b723-ca7fd7e40edc - Microsoft 365 Apps Update - Current Channel (Preview) Version 2101 for x86 based Edition (Build 13628.20274)
Error 80 refers to file existing. I scratched my head struggling to figure out what that means. I looked into the database trying to find relevant information but in vain. Then it dawned on me that downloading had something to do with patchdownloader! Here is what I found from PatchDownloader.log –
01-26-2021 15:09:09.819 Software Updates Patch Downloader 3948 (0xf6c) Failed to create temp file with GetTempFileName() at temp location C:\Windows\TEMP\, error 80
01-26-2021 15:09:19.835 Software Updates Patch Downloader 8860 (0x229c) ERROR: DownloadContentFiles() failed with hr=0x80070050
The synchronization failed due to existing files in C:\Windows\TEMP on the software update point server. Thus the solution –
Delete all the content in C:\Windows\TEMP directory from the Software Update point server
Synchronize all updates:
Resynchronize updates – Create an empty file named full.syn in, eg. \inboxes\wsyncmgr.box on top-level site server and wait for the synchronization to complete.
Wait for its completion. To monitor the sync status: Monitoring>Overview>Software Update Point Synchronization Status
Some computers install software updates successfully while some don’t.
This was the issue reported by one of my clients. Initially I found they set a deadline which is a future date for the deployment. So I asked them to go with As soon as possible if they want to install updates immediately.
However, they came back telling that it does not work either. That sounds weird. I asked for the client CCM logs, where I could see that the deployment policy was well applied as indicated in PolicyAgent.log.
But when I was checking the UpdatesDeployment.log a strange message caught my eye.
12-07-2020 21:57:19.206 UpdatesDeploymentAgent 5876 (0x16f4) Message received: '
{F17D64D8-77D3-4247-BAF0-5EB81BAF95E7}
'
12-07-2020 21:57:19.206 UpdatesDeploymentAgent 5876 (0x16f4) Message ignored as component is disabled.
12-07-2020 22:00:00.013 UpdatesDeploymentAgent 1232 (0x4d0) CUpdateAssignmentsManager received a SERVICEWINDOWEVENT START Event
12-07-2020 22:00:00.018 UpdatesDeploymentAgent 1232 (0x4d0) Suspend activity in presentation mode is selected
12-07-2020 22:00:00.018 UpdatesDeploymentAgent 1232 (0x4d0) At least one user has elected to suspend non-business hours activity when in presentation mode. Checking for presentation mode.
12-07-2020 22:00:00.018 UpdatesDeploymentAgent 1232 (0x4d0) Proceeding to non-business hours activites as presentation mode is off.
12-07-2020 22:00:00.021 UpdatesDeploymentAgent 1232 (0x4d0) Auto install during non-business hours is disabled or never set, selecting only scheduled updates.
12-07-2020 22:00:00.021 UpdatesDeploymentAgent 1232 (0x4d0) A user-defined service window(non-business hours) is available. We will attempt to install any scheduled updates.
12-07-2020 22:00:00.021 UpdatesDeploymentAgent 1232 (0x4d0) Attempting to install 0 updates
That led me to thinking that Software Update Agent on those clients may not be enabled as they should.
Due to the customer could not remote onto any of those clients, I asked to run remotely this command to verify the setting.
Get-WmiObject -Namespace "ROOT\ccm\Policy\Machine\ActualConfig" -Query "SELECT * FROM CCM_SoftwareUpdatesClientConfig"
The command returned the following result (I just pasted piece of the key information. The actual result is really quite long.) –
Third-party updates download failed with 0x80073633
Days ago one of my customers reached out to telling me that he had a problem with third-party updates download, which always failed with 0x80073633 meaning
The background of the issue was that the was trying to download third-party (Intel) updates from within SCCM console.
Checking the PatchDownloader.log in %temp% directory on the computer where SCCM console is installed, I found the following information corresponding exactly to what he saw from SCCM.
11/6/2020 09:40:03 Software Updates Patch Downloader Download http://aaa.bbb.ccc:8530/Content/D8/63B1ED2921E30447184094523CA4A1C005F9D5D8.cab to C:\Users\smsadmin\AppData\Local\Temp\2\CABB8AA.tmp returns 0 11408 (0x2C90) 11/6/2020 09:40:03 Software Updates Patch Downloader Using machine settings for CRL checking. 11408 (0x2C90) 11/6/2020 09:40:03 Software Updates Patch Downloader Cert revocation check is disabled so cert revocation list will not be checked. 11408 (0x2C90) 11/6/2020 09:40:03 Software Updates Patch Downloader To enable cert revocation check use: UpdDwnldCfg.exe /checkrevocation 11408 (0x2C90) 11/6/2020 09:40:03 Software Updates Patch Downloader Verifying file trust C:\Users\smsadmin\AppData\Local\Temp\2\CABB8AA.tmp 11408 (0x2C90) 11-06-2020 09:40:03.332 Software Updates Patch Downloader 11408 (0x2c90) Authentication of file C:\Users\smsadmin\AppData\Local\Temp\2\CABB8AA.tmp failed, error 0x800b0004 11-06-2020 09:40:03.345 Software Updates Patch Downloader 20792 (0x5138) ERROR: DownloadUpdateContent() failed with hr=0x80073633
It failed because the client computer running SCCM console did not trust the root certificate of the CAB file. To resolve it, we need to import the root certificate into the trusted root store.
Right click on it and review the Certificate Path, and review if there are any trust errors. Figure 1
If the certificate shows any errors, you will need to export and import that root certificate into the machine’s trusted root store running the ConfigMgr console. Click on View Certificate (Figure 1) and import it into the trusted root store (Figure 2).
After that third-party updates downloading succeeded. Figure 3.
SCCM Monde 