none
Permissions required to run server cleanup on WSUS 4.0 server that is also a DC

    Question

  • Hello all,

    In our environment we have a main office with various servers, one being a WSUS server that synchronises from MU and seven remote "branch offices" with a single DC server in each running WSUS as downstream servers from our main office.

    Previously as part of our server maintenance we had the WSUS server clean-up tasks run through the use of the following tool located here: http://wsus.codeplex.com/releases/view/17612. This tool also makes use of a SQL script used to re-index the SUSDB database: http://technet.microsoft.com/en-us/library/cc708594(v=ws.10).aspx.

    This has been working fine on all our servers running up to Windows Server 2008 R2 (WSUS 3.0 SP2) as a scheduled task as as a domain admin service account (ugh). 

    We recently replaced two of our branch servers with Windows Server 2012 servers; naturally this created problems. The referenced clean-up tool no longer works, seemingly because it tries to call procedures not present in WSUS 4.0 (.NET 2.0 vs .NET 4.0 from my research), so I have created a new script to perform the same actions in PowerShell since WSUS 4.0 supports this well. 

    My first question is, is it necessary for the account that runs the server clean-up tasks to be an administrator of the WSUS server? I would like to do away with needing to use a domain admin account simply because these servers are DCs and have no "local admin". I have tried placing the target service account into the domain WSUS Administrators group but this hasn't helped. I have also tried adding log on as batch and log on as service privileges through Group Policy but this didn't help at all.

    Secondly, is the referenced SQL script ( http://technet.microsoft.com/en-us/library/cc708594(v=ws.10).aspx ) compatible with the WSUS 4.0 SUSDB?

    Thanks in advance.

    Tuesday, September 24, 2013 10:48 PM

All replies

  • is it necessary for the account that runs the server clean-up tasks to be an administrator of the WSUS server?

    Strictly speaking, no. It only needs to be a member of the "WSUS Administrators" group so that it can authenticate with the WSUS API (via APIRemoting30). However, since these are domain controllers, take note that this will actually be a Domain Security Group "WSUS Administrators", and the script will have to run in the context of a domain account (but not a domain admin account).

    Secondly, is the referenced SQL script ( http://technet.microsoft.com/en-us/library/cc708594(v=ws.10).aspx ) compatible with the WSUS 4.0 SUSDB?

    Presumably so, but TESTING would be the recommended course of action.

    (Additional pedantic note: WSUS on WS2012 is properly referred to as WSUS v6.2; WSUS on WS2012R2 is referred to as WSUS v6.3. There is no such beast known as WSUS v4.)


    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.

    Wednesday, September 25, 2013 5:01 PM
  • Strictly speaking, no. It only needs to be a member of the "WSUS Administrators" group so that it can authenticate with the WSUS API (via APIRemoting30). However, since these are domain controllers, take note that this will actually be a Domain Security Group "WSUS Administrators", and the script will have to run in the context of a domain account (but not a domain admin account).

    I had added the account to the domain WSUS Administrators group but as stated in my original post, this didn't help :(

    Presumably so, but TESTING would be the recommended course of action.

    (Additional pedantic note: WSUS on WS2012 is properly referred to as WSUS v6.2; WSUS on WS2012R2 is referred to as WSUS v6.3. There is no such beast known as WSUS v4.)

    Ah thanks, so v4 through v6.1 don't exist then?

    Wednesday, September 25, 2013 11:38 PM
  • Ah thanks, so v4 through v6.1 don't exist then?

    Correct. The renumbering to v6.2 was done to be consistent with the internal Windows OS build number, now that WSUS is a fully-integrated component of the Server OS.

    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, September 27, 2013 8:52 PM
  • I had added the account to the domain WSUS Administrators group but as stated in my original post, this didn't help :(

    That should be all that is required. The tasks are actually executed by the service, via the API, so the only access rights required are for the script to access the API. Note, though, there is an authentication requirement to talk to the API. Make sure the scheduled task is properly configured to run in the context of the authorized user.

    There's also a possibility that a service restart may be required in order to implement the group membership change. If, like many other things in the WSUS/WUA world, stuff is initialized at service start, it's entirely possible that the service has cached that group membership, and isn't seeing your addition to the group.

    Also, because we're talking about domain group memberships, you must also take into consideration the replication time amongst domain controllers and global catalogs. Ideally the DCs at your branch offices are RODCs, which means there's a replication delay from where you created the group membership (corporate office) to the RODC (branch office) with the affected WSUS server.

    And, even if not an RODC, from whichever DC you did create the group memberhips, there's still a replication delay to the other six systems.


    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, September 27, 2013 9:00 PM
  • Hi,

    Just checking in to see if the suggestions were helpful. Please let us know if you would like further assistance.

    TechNet Subscriber Support

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


    Cataleya Li
    TechNet Community Support

    Monday, September 30, 2013 4:44 AM
  • Hi,

    Just checking in to see if the suggestions were helpful. Please let us know if you would like further assistance.

    Sorry, haven't had a chance to rule out cached group memberships. Have restarted the WsusService since making the domain group membership change. The change was made on the DC in question (which is also running WSUS) so replication should not be an issue, furthermore, change was made last week.

    I'm going to try and restart the server to see if any other services might need restarting. Failing that I don't know what else I can try.

    To recap, I have a Windows Server 2012 DC also running WSUS. Attempting to have a domain user account (DOMAIN\wsus.cleanup) to run a PowerShell script via Scheduled Tasks to perform WSUS clean-up utilities using PowerShell cmdlets available since WSUS 6.2.

    This domain account is a member of the WSUS Admins domain group (DOMAIN\WSUS Administrators) and has the "Log on as batch" policy enabled through Group Policy on the domain controller in question.

    When the scheduled task is run (manually or automatically) the PowerShell script runs. I can confirm this as the script outputs to file the user running it and the time it's run prior to running the WSUS clean-up cmdlets. However, no output from the cmdlet, as below:

    DOMAIN\wsus.cleanup
    
    
    Name : DC.DOMAIN.com
    
    Start time:
    30/09/2013 4:35:42 PM
    
    
    
    
    Finish time:
    30/09/2013 4:35:42 PM
    
    
    

    Running the script under a domain administrator yields the following output leading me to believe it may be a permissions issue:

    DOMAIN\administrator
    
    
    Name : DC.DOMAIN.com
    
    Start time:
    30/09/2013 4:26:34 PM
    
    
    Obsolete Updates Deleted:0
    Expired Updates Declined: 0
    Obsolete Updates Deleted:0
    Updates Compressed:0
    Obsolete Computers Deleted:0
    Diskspace Freed:0
    
    
    Finish time:
    30/09/2013 4:26:38 PM
    

    The PowerShell script exits with a return code of 0.

    For what it's worth, this is the content of the script:

    $WSUSServer = Get-WsusServer
    
    [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
    $WSUSServer
    Write-Output "Start time:"
    Get-Date -Format G
    Write-Output "`n"
    Invoke-WsusServerCleanup -CleanupObsoleteComputers -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates
    Write-Output "`n"
    Write-Output "Finish time:"
    Get-Date -Format G

    I will be trying to restart the server some time during this week when I can schedule an outage.

    Monday, September 30, 2013 6:36 AM
  • Hi,

    Any update?

    TechNet Subscriber Support

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


    Cataleya Li
    TechNet Community Support

    Wednesday, October 02, 2013 12:05 PM
  • Hi,

    Any update?

    Yes.

    It didn't work.

    So far it looks like the only way to go will be to use a domain administrator account...

    Thursday, October 31, 2013 5:25 AM
  • This domain account is a member of the WSUS Admins domain group (DOMAIN\WSUS Administrators) and has the "Log on as batch" policy enabled through Group Policy on the domain controller in question.

    Please grant this account "Log on interactive" rights and try one more time.

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

    Saturday, November 02, 2013 5:38 PM
  • Please grant this account "Log on interactive" rights and try one more time.

    Hi Lawrence,

    I have added it to the "Allow log on locally" policy and it hasn't made a difference.

    Monday, November 04, 2013 3:27 AM