locked
Set bits to foreground windows server 2012 r2 RRS feed

  • Question

  • I recently migrated my wsus 3.0 sp2 server to windows server 2012 r2 from windows server 2003 r2.

    This included migrating the remote database from sql 2005 to sql 2008 r2.

    All seemed to go well, I updated group policy to set the new intranet site server.

    The systems connected and registered successfully.

    After approving updates, the servers started to error with download failures from the wsus server.

    I ended up running wsusutil /reset before realizing there may have been permissions issue on the content directory after the migration.

    It is taking forever to rebuild the content directory.

    How can I set bits to the foreground on windows server 2012 r2 with the susdb on a remote server running sql 2008 r2?

    I am not sure if this will correct my issue, but most updates are reporting they have not been downloaded.

    Thanks for the input.

    Jeff

    Sunday, November 23, 2014 1:07 PM

Answers

  • How can I set bits to the foreground on windows server 2012 r2 with the susdb on a remote server running sql 2008 r2?

    The location of the database is irrelevant. The command is identical on WSUS v3.2 and WSUS v6.3. But the command is also irrelevant if the download jobs have already been queued for execution.

    But before you go changing BITS configurations, it would be useful to see if you actually NEED any downloads, and whether any downloads have actually been queued.

    If you were getting download failures, then changing BITS isn't going to make any difference. You need to inspect the Application Event Log for the EventID 364s and determine what is causing the download failures.

    Not sure what methodology you used to 'migrate' the server, but if you installed WSUS from Server Manager on WS2012R2 and did not change anything, then the access permissions should be correct. The more likely cause is external to the server. Was the old server configured to use a proxy? If so, is the new server configured with the same proxy settings?

    It's taking forever to rebuild the content directory because that's how long it takes to run a complete wsusutil reset on a server with years of legacy content. There's *nothing* you can do until that 'reset' task completes, and until that task completes, you should NOT do anything at all.


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


    • Edited by Lawrence Garvin Sunday, November 23, 2014 11:57 PM
    • Marked as answer by Jeff120 Tuesday, November 25, 2014 6:01 PM
    Sunday, November 23, 2014 11:54 PM
  • Instead of using smig, I removed the content drive from the 2003 r2 vm and assigned to the 2012 R2 vm.

    While a creative solution, it introduces a critical issue. Access to ~\WSUSContent is achieved through the WSUS Administrators group... a LOCAL group. By reassigning the v-disk from VM1 to VM2, the folder now has invalid ACLs, because, almost certainly, the GID(SID) of "WSUS Administrators" on VM1 is not the same as the GID(SID) of "WSUS Administrators" on VM2. This is why allowing the install to create the folder and then copying the subfolders is critical. It's the only way to ensure the correct ACLs are inherited on the entire ~\WSUSContent\* folder tree and files.

    Of course, it also has another practical reality. You would need to reassign the v-disk BEFORE installing the role, and then instruct the role installer to use an existing content store. If you did this, but gave the role installer a folder location different from the original location, it would create a NEW folder tree and ignore the old one. And, to your benefit, the actual folder tree would have the correct ACLs.

    The only difference I noticed on the content drive after running wsusutil /reset was the content folders were moved from d:\wsus to d:\.

    WSUSUTIL RESET did not do this. Either the content folders were originally in that location on the WSUS v3 instance, or something else caused them to be relocated. The Good News is that this actually helped you recover fairly quickly because the ACLs on the actual content store were ostensibly created during role installation.


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



    Tuesday, November 25, 2014 7:27 PM

All replies

  • How can I set bits to the foreground on windows server 2012 r2 with the susdb on a remote server running sql 2008 r2?

    The location of the database is irrelevant. The command is identical on WSUS v3.2 and WSUS v6.3. But the command is also irrelevant if the download jobs have already been queued for execution.

    But before you go changing BITS configurations, it would be useful to see if you actually NEED any downloads, and whether any downloads have actually been queued.

    If you were getting download failures, then changing BITS isn't going to make any difference. You need to inspect the Application Event Log for the EventID 364s and determine what is causing the download failures.

    Not sure what methodology you used to 'migrate' the server, but if you installed WSUS from Server Manager on WS2012R2 and did not change anything, then the access permissions should be correct. The more likely cause is external to the server. Was the old server configured to use a proxy? If so, is the new server configured with the same proxy settings?

    It's taking forever to rebuild the content directory because that's how long it takes to run a complete wsusutil reset on a server with years of legacy content. There's *nothing* you can do until that 'reset' task completes, and until that task completes, you should NOT do anything at all.


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


    • Edited by Lawrence Garvin Sunday, November 23, 2014 11:57 PM
    • Marked as answer by Jeff120 Tuesday, November 25, 2014 6:01 PM
    Sunday, November 23, 2014 11:54 PM
  • Thanks for explanation.

    I followed the recommendations on TechNet, http://technet.microsoft.com/en-us/library/hh852339.aspx

    I could not find a migration guide specifically for 2012 R2.

    The only deviation from the guide, both systems are virtual.

    Instead of using smig, I removed the content drive from the 2003 r2 vm and assigned to the 2012 R2 vm.

    The rest of the installation and post migration tasks were successful.

    The only difference I noticed on the content drive after running wsusutil /reset was the content folders were moved from d:\wsus to d:\.

    That's why I was thinking I may have had a permissions issue to begin with, the original path was different.

    I am pretty sure that I specified the original path during the initial installation on 2012.

    We did not use any proxies.

    The rebuild did complete successfully, it just took a long time to complete.

    All of the servers have downloaded updates and are reporting in as usual.

    Thanks for your help.

    Jeff

    Tuesday, November 25, 2014 6:01 PM
  • Instead of using smig, I removed the content drive from the 2003 r2 vm and assigned to the 2012 R2 vm.

    While a creative solution, it introduces a critical issue. Access to ~\WSUSContent is achieved through the WSUS Administrators group... a LOCAL group. By reassigning the v-disk from VM1 to VM2, the folder now has invalid ACLs, because, almost certainly, the GID(SID) of "WSUS Administrators" on VM1 is not the same as the GID(SID) of "WSUS Administrators" on VM2. This is why allowing the install to create the folder and then copying the subfolders is critical. It's the only way to ensure the correct ACLs are inherited on the entire ~\WSUSContent\* folder tree and files.

    Of course, it also has another practical reality. You would need to reassign the v-disk BEFORE installing the role, and then instruct the role installer to use an existing content store. If you did this, but gave the role installer a folder location different from the original location, it would create a NEW folder tree and ignore the old one. And, to your benefit, the actual folder tree would have the correct ACLs.

    The only difference I noticed on the content drive after running wsusutil /reset was the content folders were moved from d:\wsus to d:\.

    WSUSUTIL RESET did not do this. Either the content folders were originally in that location on the WSUS v3 instance, or something else caused them to be relocated. The Good News is that this actually helped you recover fairly quickly because the ACLs on the actual content store were ostensibly created during role installation.


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



    Tuesday, November 25, 2014 7:27 PM
  • Lawrence,

    I know I assigned the vmdk file to the new server prior to starting the installation.

    I new the installation would assign the correct rights.

    Based on all of the information you have provided, I think I missed entering the correct location of the original content drive during the install.

    Thanks again for all the info and your assistance with figuring this out.

    Jeff

    Tuesday, November 25, 2014 8:17 PM
  • I new the installation would assign the correct rights.

    But this is an incorrect assumption. The installation WILL NOT assign rights to an EXISTING folder.

    However, to your benefit, it would seem that the folder defined in the role installation was NOT the actual folder containing the content, so the legit folder did get assigned the correct ACLs.

    While it may be true that you misentered the actual location of the content directory during role installation, ironically, that error saved you a nominal amount of repair work. :-)


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

    Wednesday, November 26, 2014 3:52 AM