none
WSUS not working after movecontent

    Question

  • I've just run "wsusutil movecontent F:\ F:\move.log" and my update files have moved to the root of the F drive but now the WSUS console won't connect.  It opens normally but the summary page just times out loading before showing a Connection Error and logs the following in the Event Log:

    EventID 7032

    The WSUS administration console was unable to connect to the WSUS Server via the remote API. 

    Verify that the Update Services service, IIS and SQL are running on the server. If the problem persists, try restarting IIS, SQL, and the Update Services Service.

    System.Net.WebException -- The operation has timed out

    Source
    System.Web.Services

    Stack Trace:
       at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
       at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
       at Microsoft.UpdateServices.Internal.DatabaseAccess.ApiRemotingCompressionProxy.GetWebResponse(WebRequest webRequest)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
       at Microsoft.UpdateServices.Internal.ApiRemoting.ExecuteSPGetUpdateServerStatus(Int32 updateSources, Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String preferredCulture, Int32 publicationState, Int32 propertiesToGet)
       at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPGetUpdateServerStatus(UpdateSources updateSources, Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String preferredCulture, ExtendedPublicationState publicationState, UpdateServerStatusPropertiesToGet propertiesToGet)
       at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetStatus(UpdateSources updateSources, Boolean includeDownstreamComputers, UpdateScope updatesToInclude, ComputerTargetScope computersToInclude, UpdateServerStatusPropertiesToGet propertiesToGet)
       at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetReplicaStatus(UpdateSources updateSources)
       at Microsoft.UpdateServices.UI.SnapIn.Common.CachedUpdateServerStatus.GetFreshObjectForCache()
       at Microsoft.UpdateServices.UI.AdminApiAccess.CachedObject.GetFromCache()
       at Microsoft.UpdateServices.UI.SnapIn.Pages.ServerSummaryPage.backgroundWorker_DoWork(Object sender, DoWorkEventArgs e)

    It's then followed up by another error EventID 7053:

    The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console. If this error persists, 

    Try removing the persisted preferences for the console by deleting the wsus file under %appdata%\Microsoft\MMC\.


    System.NullReferenceException -- Object reference not set to an instance of an object.

    Source
    Microsoft.UpdateServices.UI.SnapIn

    Stack Trace:
       at Microsoft.UpdateServices.UI.SnapIn.Pages.ServerSummaryPage.backgroundWorker_RunWorkerCompleted(Object sender, RunWorkerCompletedEventArgs e)

    I have tried restarting my WSUS server and the SQL server (not using the local internal DB) but no joy.

    Any ideas how I can resolve this please?

    Chris


    • Edited by Tippers Thursday, November 8, 2012 9:21 AM
    Thursday, November 8, 2012 9:20 AM

Answers

  • So its not possible to move the content folders to the root of a drive?

    Actually, it is; but you may be encountering another known issue that dates all the way back to the original release of WSUS v2.

    There's a 'bug' in the .NET2 installer that fails to properly initialize the ACLs on the ROOT of non-SYSVOL drives. As a result, WSUS and BITS are unable to read/write to a WSUS content store contained on a non-SYSVOL drive. The fix for this is to add *READ* rights for the NT AUTHORITY\Network Service account to the ROOT of the non-SYSVOL drive(s) - in this case drive F: - and that should resolve the issue.

    Here's a link to a thread from a few years ago where this was previously discussed:

    http://social.technet.microsoft.com/Forums/sv/winserverwsus/thread/c2e6b642-4372-46b4-b129-1a88521e32b8

    You can find other references by searching on "WSUSContent non-SYSVOL".


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    • Marked as answer by Tippers Monday, November 12, 2012 11:14 AM
    Friday, November 9, 2012 11:13 PM
    Moderator

All replies

  • Hi,

    Pls try to set the location like F:\WSUS  F:\move.log.After the movecontent,check the ACL and size of all the transferred folder to whether it equals to the original.

    You must create the new path for local WSUS update storage prior to using WSUSutil.exe. 

    To change the location of local WSUS update storage

    1.Click Start, and then click Run.

    2.In the Open box, type cmd, and then click OK.

    3.At the command prompt, navigate to the directory that contains WSUSutil.exe.

    4.Type the following, and then press ENTER:

    wsusutil.exe movecontent contentpath logfile 

    For example, type:wsusutil.exe movecontent D:\WSUS1\ D:\move.log where D:\WSUS1 is the new path for local WSUS update storage, and D:\move.log is the path to the log file.

    When you run this command, WSUSutil.exe Copies the update files from the old location into the new location.Updates the WSUS database to refer to the new location of the update files.The destination folder where update files are moved to must be on an NTFS partition. The content move tool will not try to copy update files if they already exist in the destination folder. WSUSutil.exe sets the same permissions on the destination folder that were set on the original folder.

    Managing WSUS from the Command Line: http://technet.microsoft.com/en-us/library/cc720466(v=ws.10).aspx


    Regards,

    Clarence

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.



    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    Friday, November 9, 2012 5:54 AM
    Moderator
  • Hi Clarence,

    Thanks for your reply.  So its not possible to move the content folders to the root of a drive?  I didn't see that in any of the documentation for wsusutil.

    Anyway, I found further errors in the SoftwareDistribution log file (in C:\Program Files\Update Services\LogFiles) of SqlException and Sql Timeout errors.  When I tried to edit any of the options in the WSUS console there was a message saying that settings could not be saved due to processing a previous config change.  I guess the initial movecontent command must have left the SQL database in an inoperable state and as I didn't have a backup I have re-installed WSUS with a new database.

    Regards

    Chris

    Friday, November 9, 2012 8:48 AM
  • So its not possible to move the content folders to the root of a drive?

    Actually, it is; but you may be encountering another known issue that dates all the way back to the original release of WSUS v2.

    There's a 'bug' in the .NET2 installer that fails to properly initialize the ACLs on the ROOT of non-SYSVOL drives. As a result, WSUS and BITS are unable to read/write to a WSUS content store contained on a non-SYSVOL drive. The fix for this is to add *READ* rights for the NT AUTHORITY\Network Service account to the ROOT of the non-SYSVOL drive(s) - in this case drive F: - and that should resolve the issue.

    Here's a link to a thread from a few years ago where this was previously discussed:

    http://social.technet.microsoft.com/Forums/sv/winserverwsus/thread/c2e6b642-4372-46b4-b129-1a88521e32b8

    You can find other references by searching on "WSUSContent non-SYSVOL".


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    • Marked as answer by Tippers Monday, November 12, 2012 11:14 AM
    Friday, November 9, 2012 11:13 PM
    Moderator
  • I think Lawrence has explained the reason clearly.If there is anything that I can do for you, please do not hesitate to let me know, and I will be happy to help.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, November 12, 2012 7:05 AM
    Moderator
  • Hi Lawrence,

    Thanks for your reply, much appreciated.  I mistakenly entered the root of the F: drive instead of creating a subfolder which would have prevented this problem in the first place but thanks for your solution.

    Regards

    Chris

    Monday, November 12, 2012 11:15 AM
  • Lawrence, I'm hoping you can provide some insight for me too.

    I used the 'WSUSUtil movecontent E:\WSUS E:\move.log' command as instructed.  After it says it completed successfully, my SQLserver.exe process takes up 99% of the CPU.  I have added the Network Service account with Read rights to the root of my E:, rebooted the server and SQL still hogs the CPU.  This was done on 2 of our 8+ downstream servers.  Is there anything else I can look at or change to correct this?  I'd rather not uninstall and reinstall it all, but will if I have to.

    Thanks,

    Ray

    Thursday, July 25, 2013 2:01 PM
  • Lawrence, I'm hoping you can provide some insight for me too.

    I used the 'WSUSUtil movecontent E:\WSUS E:\move.log' command as instructed.  After it says it completed successfully, my SQLserver.exe process takes up 99% of the CPU.  I have added the Network Service account with Read rights to the root of my E:, rebooted the server and SQL still hogs the CPU.  This was done on 2 of our 8+ downstream servers.  Is there anything else I can look at or change to correct this?  I'd rather not uninstall and reinstall it all, but will if I have to.

    Thanks,

    Ray

    Greetings Ray

    It's not unusual for the sqlservr.exe process to consume a fair amount of CPU after a 'movecontent' execution, as there are likely database records that need to be updated with the new content store location.

    The relevant question would be (10 hours since you've posted) whether that sqlservr.exe process is still consuming that much CPU. Also relevant to that would be:

    • How many updates are synchronized to the WSUS Server?
    • How many updates have active approvals?
    • What are the system specifications of your WSUS server? (number of course, clock speed, installed RAM, disk configuration -- which may be relevant to paging activity if RAM is starved)

    We do know that a related task 'wsusutil reset' can take several hours (nay, in some cases several *days*) to complete execution, depending on system resources and the number of updates or number of approved updates.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, July 26, 2013 12:07 AM
    Moderator