The synchronization with the upstream server or Microsoft Update was cancelled – WSUS Error

When initially setting up WSUS, you may get the following error when trying to synchronize with Microsoft for the first time:

“The synchronization with the upstream server or Microsoft Update was canceled”:

It took a while, but I finally fixed the problem!

Quick Answer

For those of you that just want to fix the issue, add ‘Full control’ permissions for the ‘Network Service’ user on the ‘C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp’ folder.

Long Answer

These were the steps I followed to find out the issue.

I suspected this was probably due to incorrect permissions – as always – somewhere in the system, so I found the correct permissions here:

http://technet.microsoft.com/en-us/library/dd939816(WS.10).aspx

I also downloaded the Microsoft Windows Server Update Services 3.0 SP2 Step By Step Guide which said this:

Permissions
The following permissions are required for the specified users and directories:
1. The NT Authority\Network Service account must have Full Control permission for the
following folders so that the WSUS Administration snap-in displays correctly:
 %windir%\Microsoft .NET\Framework\v2.0.50727\Temporary ASP.NET Files
%windir%\Temp
2. Confirm that the account that you plan to use to install WSUS 3.0 SP2 is a member of the
Local Administrators group.

WSUS still didn’t sync when I added the correct permissions to these folders:

  • %windir%\Temp
  • C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
  • C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

I checked the WSUS Application Pool was using the correct version (which it was):

Locating the default install directory (C:\Program Files\Update Services), I decided to hunt for log files, as there was nothing useful in the System Event Logs, eg:

Warning for Web Server Role:
A process serving application pool ‘WsusPool’ terminated unexpectedly. The process id was ‘3628’. The process exit code was ‘0xfffffffe’.

Finally, I found something actionable in ‘C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log’. I had looked in this before, but the file was huge as the log is appended to on each successive installation/sync attempt. Simply deleting the SoftwareDistribution.log file, prior to a sync attempt, will create a new SoftwareDistribution.log file.

Errors in SoftwareDistribution.log:

2012-03-14 12:20:54.532 UTC Error WsusService.22 ReportingDatabaseAccess.AddReportingEventBatchToDatabase Error occurred while writing events to the database. Exception: System.UnauthorizedAccessException: Access to the temp directory is denied.  Identity ‘NT AUTHORITY\NETWORK SERVICE’ under which XmlSerializer is running does not have sufficient permission to access the temp directory.  CodeDom will use the user account the process is using to do the compilation, so if the user doesnt have access to system temp directory, you will not be able to compile.  Use Path.GetTempPath() API to find out the temp directory location.

2012-03-14 12:20:54.546 UTC Error WsusService.22 AuthorizationManager.LoadAuthorizationPlugIns Failed to initialize authorization plugin Microsoft.UpdateServices.Internal.Authorization.DownstreamServerAuthorizationPlugInAccess to the temp directory is denied.  Identity ‘NT AUTHORITY\NETWORK SERVICE’ under which XmlSerializer is running does not have sufficient permission to access the temp directory.  CodeDom will use the user account the process is using to do the compilation, so if the user doesnt have access to system temp directory, you will not be able to compile.  Use Path.GetTempPath() API to find out the temp directory location.

2012-03-14 12:20:54.547 UTC Error WsusService.22 CatalogSyncAgentCore.ExecuteSyncProtocol System.UnauthorizedAccessException: Access to the temp directory is denied.  Identity ‘NT AUTHORITY\NETWORK SERVICE’ under which XmlSerializer is running does not have sufficient permission to access the temp directory.  CodeDom will use the user account the process is using to do the compilation, so if the user doesnt have access to system temp directory, you will not be able to compile.  Use Path.GetTempPath() API to find out the temp directory location.

Unfortunately, there was no path to the referenced temp directory, so I fired up Process Monitor whilst trying to sync WSUS for a final time.

After filtering only ACCESS DENIED results for File Operations, I got this:

So, it seems Microsoft isn’t aware you might need to add Full Control permissions for NETWORK SERVICE on ‘C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp’.

Once the permission were added to ‘C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp’, WSUS worked fine. Another win for Sysinternals Utilities!

Other steps I took which didn’t help

I ran wsusutil from C:\Program Files\Update Services\Tools: http://technet.microsoft.com/en-us/library/cc708604(v=ws.10).aspx

wsusutil checkhealth

Results will appear in the Application Event log.

I installed the Microsoft Report Viewer 2008 SP1 Redistributable Package: http://www.microsoft.com/download/en/details.aspx?id=3841

Comments

  1. Thanks. I have been struggling with this for sometime. Thank you so much.

    • Ah yes, this was a swine of a problem that stumped me for days! I was glad to see the back of it. Glad it helped you J-dog!

  2. rajeshdavid says:

    You are the man. Thanks Adam.
    Perfect solution

  3. Ι could not refrain from commenting. Exceptionally ԝell written!