locked
SCCM 2012 SP1 WSUS Scenerio RRS feed

  • Question

  • We have an existing WSUS server that work fine. In the past before SCCM 2012 SP1 I tried to install WSUS on the same box as SCCM but it seemed like the Windows update process became a lot more complicated than it used to be. You had to use deployment packages, target groups, add rules and go through a lot of hoops just to get out updates that WSUS handles just fine all by itself. Maybe we are the exception but our method has always been to deploy all updates to all computers all the time. With WSUS this is simple, with SCCM it is not that simple.

    So now that I have SCCM 2012 with SP1 installed is the process any easier? What I would like to do is to use our existing WSUS server for all updates but use SCCM Sp1 to deploy the ForeFront client. Can I install WSUS on the SCCM box and have it sync to our main WSUS server? Sync just Forefront stuff? We have GPO pointing to our main WSUS box and that works just fine.

    What I would like to do is install WSUS on SCCM, configure it to use 8530 and 8531 ports to advertise itself to SCCM and ahve the SCCM wSUS get updates from our main internal WSUS server.

    I would aprreciate all advice given for this scenerio.

    Friday, January 18, 2013 3:29 PM

Answers

  • ConfigMgr never pulls/downloads updates themselves from anywhere except directly from the link specified in the WU/MU catalog which is directly from Microsoft. Once downloaded, the updates get put into Update Deployment Packages which in turn are placed on your DPs so that the clients can get to them -- this is no different than any other content in ConfigMgr. Updates must also be referenced in a Software Update Group which in turn is deployed to your clients so that the client know which updates are assigned to them. As John mentioned, both these steps can simply be automated by ADRs in 2012 (and 2012 SP1 of course).

    Yes, you must have a SUP; the SUP provides a thin layer of communication between ConfigMgr and a dedicated instance of WSUS. This WSUS instance provides access to the WU/MU catalog and nothing more. Prior to SP1, this dedicated WSUS instance must get its copy of the WU/MU catalog directly from Microsoft. Added in SP1 is the ability to use another upstream WSUS server to retrieve the WU/MU catalog. As noted, this is only the WU/MU catalog and not the updates themselves, these are still downloaded directly from Microsoft (it is possible to actually get the updates from somewhere else, but this is not anything direct or automated in the box).

    Honestly, most folks over-complicate the software update process in ConfigMgr and confuse themselves over what is happening. There are a few moving parts, but once you sit down and learn them, it is no more complicated than a stand-alone WSUS instance with a lot more power and flexibility. If you are trying to directly translate how you did things in WSUS to ConfigMgr, you will have issues just like you will going between any two products. You need to step back and learn the new system first and then apply your requirements to it and not the steps you used in the old system.

    Additionally, here's an awesome post from Jorgen on why using a stand-alone instance of WSUS when you have ConfigMgr is place is anti-intelligent: http://ccmexec.com/2012/08/top-11-reasons-why-you-should-use-configmgr-2012-for-managing-software-updates/

    Also note that the process of deploying SCEP (it's no longer forefront) and SCEP definitions is completely different in 2012 as SCEP is now a formal part of the product. SCEP agent installation is automatic and is simply a switch you flip in the console -- there is no direct deployment via WSUS -- and SCEP definition updates can be deployed in multiple ways all directly configured in the ConfigMgr console.


    Jason | http://blog.configmgrftw.com

    • Proposed as answer by Garth JonesMVP Saturday, February 7, 2015 2:29 PM
    • Marked as answer by Garth JonesMVP Friday, January 22, 2016 7:20 PM
    Friday, January 18, 2013 4:17 PM
  • Not exactly sure what you're looking for, but here's the TechNet docs on this: http://technet.microsoft.com/en-us/library/gg712696.aspx#BKMK_WSUSSyncSource

    Jason | http://blog.configmgrftw.com

    • Proposed as answer by Garth JonesMVP Saturday, February 7, 2015 2:29 PM
    • Marked as answer by Garth JonesMVP Friday, January 22, 2016 7:20 PM
    Sunday, February 24, 2013 8:42 PM

All replies

  • CM12 simplified the software updates process above and beyond what was available in CM07. You can setup auto deployment rules and forget about it just like plain ole WSUS.

    You can't have CM WSUS pull from another internal WSUS though, it's one or the other.


    John Marcum | http://myitforum.com/myitforumwp/author/johnmarcum/

    Friday, January 18, 2013 3:48 PM
  • Ok so I can have SCCM pull updates from our main internal WSUS server, sounds great. Do I need to to install the SUP role at all on the SCCM box?
    Friday, January 18, 2013 3:58 PM
  • ConfigMgr never pulls/downloads updates themselves from anywhere except directly from the link specified in the WU/MU catalog which is directly from Microsoft. Once downloaded, the updates get put into Update Deployment Packages which in turn are placed on your DPs so that the clients can get to them -- this is no different than any other content in ConfigMgr. Updates must also be referenced in a Software Update Group which in turn is deployed to your clients so that the client know which updates are assigned to them. As John mentioned, both these steps can simply be automated by ADRs in 2012 (and 2012 SP1 of course).

    Yes, you must have a SUP; the SUP provides a thin layer of communication between ConfigMgr and a dedicated instance of WSUS. This WSUS instance provides access to the WU/MU catalog and nothing more. Prior to SP1, this dedicated WSUS instance must get its copy of the WU/MU catalog directly from Microsoft. Added in SP1 is the ability to use another upstream WSUS server to retrieve the WU/MU catalog. As noted, this is only the WU/MU catalog and not the updates themselves, these are still downloaded directly from Microsoft (it is possible to actually get the updates from somewhere else, but this is not anything direct or automated in the box).

    Honestly, most folks over-complicate the software update process in ConfigMgr and confuse themselves over what is happening. There are a few moving parts, but once you sit down and learn them, it is no more complicated than a stand-alone WSUS instance with a lot more power and flexibility. If you are trying to directly translate how you did things in WSUS to ConfigMgr, you will have issues just like you will going between any two products. You need to step back and learn the new system first and then apply your requirements to it and not the steps you used in the old system.

    Additionally, here's an awesome post from Jorgen on why using a stand-alone instance of WSUS when you have ConfigMgr is place is anti-intelligent: http://ccmexec.com/2012/08/top-11-reasons-why-you-should-use-configmgr-2012-for-managing-software-updates/

    Also note that the process of deploying SCEP (it's no longer forefront) and SCEP definitions is completely different in 2012 as SCEP is now a formal part of the product. SCEP agent installation is automatic and is simply a switch you flip in the console -- there is no direct deployment via WSUS -- and SCEP definition updates can be deployed in multiple ways all directly configured in the ConfigMgr console.


    Jason | http://blog.configmgrftw.com

    • Proposed as answer by Garth JonesMVP Saturday, February 7, 2015 2:29 PM
    • Marked as answer by Garth JonesMVP Friday, January 22, 2016 7:20 PM
    Friday, January 18, 2013 4:17 PM
  • ConfigMgr never pulls/downloads updates themselves from anywhere except directly from the link specified in the WU/MU catalog which is directly from Microsoft.

    So what you are telling me, is that Microsoft have written another backwards component to this product (just look at the DB requirements) that forces you to download the content from Microsoft again, which if you have a slow connection to the internet and download limits, is just stupid and can be costly.

    What happens when you attempt to use this product on a disconnected network? Can you export the content from an Internet connected system so that it can imported onto the disconnected network?

    I find this really frustrating in the way that they have designed this component. So going forward, we are still stuck with having our Microsoft updates seperate from our OS/Software deployment/management point.

    Byron

    Thursday, January 24, 2013 9:15 PM
  • Not sure why you're jumping directly to Microsoft bashing particularly since none of your conclusions above are accurate.

    No one is forcing you to download content from Microsoft again. You can actually use an alternate location when creating/populating your update packages -- it's just a rather time consuming process because there is no way for it to know where to look for the updates so you have to manually specify the location to grab the update from for each and every update -- it can't magically detect this. I have seen this scripted before though.

    For a disconnected network, the TechNet documentation lists exactly how to export the meta-data from an online WSUS server and import into the WSUS instance used by the SUP. Then using the manual import process, which is the scenario for which I've seen the script created/used, you can import the updates also.

    Incidentally, what's wrong with the DB requirements?

     

    Jason | http://blog.configmgrftw.com

    Friday, January 25, 2013 2:09 AM
  • The issue with the DB requirements is the database collation: SQL_Latin1_General_CP1_CI_AS. This of course requires you to stand up separate DB instances, separate from other DB instances, just to service this one application. Our SQL DB expert was not impressed.

    As for the whole export of meta-data process, see my thread here: http://social.technet.microsoft.com/Forums/zh/winserverwsus/thread/4a7176b2-051f-4bd0-bb8f-17731d43dcaf

    If SCCM is capable of pulling the meta-data from a WSUS server, it should be capable of pulling the updates. It sounds like the person who created that component of SCCM was being lazy at the time and decided to leave out that portion of the code. I will go looking for this script and see what it can do, unless you have a link for it.

    I think in the end I will end up taking this issue up with our TAM.

    Friday, January 25, 2013 2:31 AM
  • Added in SP1 is the ability to use another upstream WSUS server to retrieve the WU/MU catalog. As noted, this is only the WU/MU catalog and not the updates themselves, these are still downloaded directly from Microsoft (it is possible to actually get the updates from somewhere else, but this is not anything direct or automated in the box).

    Jason, do You have a link for a Technet artikel that describes this? I trust You but my managers want to hear it from MS.

    Regards

    Anders

    Monday, February 18, 2013 1:52 PM
  • Here's the option, but there really isn't that much to tell you about it over what Jason already said.  It simply tells your Software Update Point to sync from a local WSUS server rather than Microsoft Update. fin.


    My Personal Blog: http://madluka.wordpress.com

    Monday, February 18, 2013 5:35 PM
  • But that option only downloads the WU catalogue from the upstream server.

    What I want is a MS article describing this "feature"

    Tuesday, February 19, 2013 7:04 AM
  • Not exactly sure what you're looking for, but here's the TechNet docs on this: http://technet.microsoft.com/en-us/library/gg712696.aspx#BKMK_WSUSSyncSource

    Jason | http://blog.configmgrftw.com

    • Proposed as answer by Garth JonesMVP Saturday, February 7, 2015 2:29 PM
    • Marked as answer by Garth JonesMVP Friday, January 22, 2016 7:20 PM
    Sunday, February 24, 2013 8:42 PM