locked
Configure WSUS with Configuration Manager 2012 R2 RRS feed

  • Question

  • We configured WSUS to be integrated with SCCM 2012 R2.

    WSUS is on a different server than SCCM 2012 R2, and we have the site server role SUP installed on this server.

    Both servers are Server 2012 R2.

    We are doing Software updates, and I have some basic questions.

    I can see from the logs that it downloaded all the updates, but where are they stored in SCCM, and how do I know they are there.

    Thanks

    Friday, February 14, 2014 1:47 AM

Answers

  • Update files are stored on your WSUS (SUP) server, ConfigMgr only synchronizes the metadata of your WSUS server. When doing actual update deployments, you'll be asked where the content (\\yoursupserver\WsusContent) is and after that ConfigMgr will create the update package that copies the files from WSUS and after that can be used to deployment for the clients.

    You can see the updates from your ConfigMgr console Software Library -> Software Updates. You can do a manual synchronization to ConfigMgr by right clicking the Software Updates node. After this you can check the synchronization status of updates into ConfigMgr by checking the wsyncmgr.log from your site server.

    Here's some references:

    http://technet.microsoft.com/en-us/library/gg712312.aspx

    http://msincic.wordpress.com/2012/08/24/using-the-software-update-point-in-system-center-configuration-manager-2012/

    http://blogs.msdn.com/b/scstr/archive/2012/05/31/configuring_2d00_software_2d00_updates_2d00_in_2d00_configuration_2d00_manager_2d00_2012.aspx


    • Proposed as answer by Narcoticoo Friday, February 14, 2014 4:05 AM
    • Edited by Narcoticoo Friday, February 14, 2014 4:07 AM
    • Marked as answer by Joyce L Monday, February 24, 2014 10:15 AM
    Friday, February 14, 2014 4:05 AM
  • One additional key item: do not go into the WSUS console and perform any administrative tasks. The SUP does this for you and thus all software update related administration is done using ConfigMgr. Also, if you are familiar with WSUS, forget everything you know about using it as the process in ConfigMgr is different and you will only cause yourself pain if you try to do things in ConfigMgr the way you did them in WSUS -- don't misinterpret this though, the core concepts and tenants are still the same (like Update applicability, the Windows Update Agent installing updates, the WSUS catalog), but the administrative workflow and the moving parts involved are very different.

    Jason | http://blog.configmgrftw.com

    • Marked as answer by Joyce L Monday, February 24, 2014 10:15 AM
    Friday, February 14, 2014 1:19 PM
  • Well, that's a tough one to put in words correctly and completely.

    Basically, it doesn't affect the built-in processes and they are still fully enabled. A few key points:

    - The ConfigMgr agent does set a local group policy pointing each client's WUA at the WSUS instance underlying the SUP.

    - The WSUS instance, once integrated into ConfigMgr is only responsible for the update catalog (and update EULAs) including downloading it from Microsoft and making it available to clients. Technically, that WSUS instance could still be used to approve and deploy updates directly, but its not supported to do so and could cause side effects; thus the warning above in my post not to do this.

    - Updates are downloaded by ConfigMgr and clients retrieve them using standard ConfigMgr content handling.

    - The WUA, which is still alive and kicking, performs actions like scanning for applicable updates and installing updates at the direction of the ConfigMgr client. If not disabled (see blog posts below), the WUA will carry on its merry way and similar to the WSUS situation above, could technically do things on its own but because nothing has been approved in the WSUS instance its pointing to, it doesn't do much except what the ConfigMgr client tells it to do -- there actually is reason to disable it though (see blog posts listed blew for more info on that).

    These two blog posts I did a while back should help fill in some blanks: http://blog.configmgrftw.com/?p=88 , http://blog.configmgrftw.com/?p=89


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Joyce L Monday, February 24, 2014 10:15 AM
    Saturday, February 15, 2014 4:20 AM

All replies

  • Update files are stored on your WSUS (SUP) server, ConfigMgr only synchronizes the metadata of your WSUS server. When doing actual update deployments, you'll be asked where the content (\\yoursupserver\WsusContent) is and after that ConfigMgr will create the update package that copies the files from WSUS and after that can be used to deployment for the clients.

    You can see the updates from your ConfigMgr console Software Library -> Software Updates. You can do a manual synchronization to ConfigMgr by right clicking the Software Updates node. After this you can check the synchronization status of updates into ConfigMgr by checking the wsyncmgr.log from your site server.

    Here's some references:

    http://technet.microsoft.com/en-us/library/gg712312.aspx

    http://msincic.wordpress.com/2012/08/24/using-the-software-update-point-in-system-center-configuration-manager-2012/

    http://blogs.msdn.com/b/scstr/archive/2012/05/31/configuring_2d00_software_2d00_updates_2d00_in_2d00_configuration_2d00_manager_2d00_2012.aspx


    • Proposed as answer by Narcoticoo Friday, February 14, 2014 4:05 AM
    • Edited by Narcoticoo Friday, February 14, 2014 4:07 AM
    • Marked as answer by Joyce L Monday, February 24, 2014 10:15 AM
    Friday, February 14, 2014 4:05 AM
  • One additional key item: do not go into the WSUS console and perform any administrative tasks. The SUP does this for you and thus all software update related administration is done using ConfigMgr. Also, if you are familiar with WSUS, forget everything you know about using it as the process in ConfigMgr is different and you will only cause yourself pain if you try to do things in ConfigMgr the way you did them in WSUS -- don't misinterpret this though, the core concepts and tenants are still the same (like Update applicability, the Windows Update Agent installing updates, the WSUS catalog), but the administrative workflow and the moving parts involved are very different.

    Jason | http://blog.configmgrftw.com

    • Marked as answer by Joyce L Monday, February 24, 2014 10:15 AM
    Friday, February 14, 2014 1:19 PM
  • Thanks for the reply one other question.

    When you go into Control Panel > Windows Updates

    How does SCCM 2012 r2 affect [Windows Updates], since we are now deploying all updates via SCCM 2012 R2.

    Windows Updates in Control panel is not greyed out ,etc..

    thanks

    Saturday, February 15, 2014 3:16 AM
  • Well, that's a tough one to put in words correctly and completely.

    Basically, it doesn't affect the built-in processes and they are still fully enabled. A few key points:

    - The ConfigMgr agent does set a local group policy pointing each client's WUA at the WSUS instance underlying the SUP.

    - The WSUS instance, once integrated into ConfigMgr is only responsible for the update catalog (and update EULAs) including downloading it from Microsoft and making it available to clients. Technically, that WSUS instance could still be used to approve and deploy updates directly, but its not supported to do so and could cause side effects; thus the warning above in my post not to do this.

    - Updates are downloaded by ConfigMgr and clients retrieve them using standard ConfigMgr content handling.

    - The WUA, which is still alive and kicking, performs actions like scanning for applicable updates and installing updates at the direction of the ConfigMgr client. If not disabled (see blog posts below), the WUA will carry on its merry way and similar to the WSUS situation above, could technically do things on its own but because nothing has been approved in the WSUS instance its pointing to, it doesn't do much except what the ConfigMgr client tells it to do -- there actually is reason to disable it though (see blog posts listed blew for more info on that).

    These two blog posts I did a while back should help fill in some blanks: http://blog.configmgrftw.com/?p=88 , http://blog.configmgrftw.com/?p=89


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Joyce L Monday, February 24, 2014 10:15 AM
    Saturday, February 15, 2014 4:20 AM