locked
Patching in SCCM CAS & Primary Site Hierarchy RRS feed

  • Question

  • Hi all,

    I have a doubt with the update deployment process want to clear it out with the experts -

    We are currently in the process of installation & configuration of a site were we are having a CAS & 4 Primary sites. We were in the process of installing WSUS/SUP on CAS as well as on all primary sites, so that CAS syncs with MS update server fro update download & the Primary sites sync with CAS.

    But what if we download all the updates on the CAS & create a deployment package for the updates - Once these things are created they will be replicated to other primary sites & then we can deploy the packages to the collection just like software deployment.

    Can we do this please suggest ??

    Thanks,

    Pranay.

    Saturday, April 11, 2015 4:51 AM

Answers

  • Yes, you can use it like that. Actually, that's exactly how it's designed to be used. CAS is short for Central Administration Site, so in the ideal world you should be doing all your administrative tasks from the CAS. That includes the software update deployment.

    Note: This doesn't mean that you shouldn't install a software update point on the primary sites, as that's used by the clients to scan for compliance.


    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Saturday, April 11, 2015 5:51 AM
  • You *can* use it like that.
    Assuming that is consistent with the reasons you chose CAS in the first place?

    If you will do Software Updates Management in this hierarchy, then you *must* install SUP on the CAS (you have no choice about that) - because the CAS is the top-level SUP in the hierarchy, and only the CAS will sync to MSFT. (or to your other WSUS as USS if that is how you choose)
    Your primary sites in the hierarchy cannot sync to MSFT, they can only sync to your CAS. (essentially, primary site SUPs become DSS in relation to your CAS/USS).

    Assuming that you are implementing CAS+4PRI and need/wish to perform SUM at all 4 sites (remember CAS can not have clients), and you need/wish all objects/data (not necessarily packages) to replicate downwards to all PRI sites, and you need/wish to perform the SUM tasks in a centrally-managed fashion, then doing so at CAS is exactly what you should do.

    Really, it comes down to the reasons you chose to implement CAS at all (presumably for the benefits of central admin/management).

    e.g. if you have a PRI site for a datacentre, and, say that datacentre only has WindowsServers, then why push all the WindowsClient and Office stuff to that PRI site ?

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

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

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


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)


    Saturday, April 11, 2015 6:21 AM
  •  then we can deploy the packages to the collection just like software deployment.

    No, you do *not* deploy update packages. You deploy update groups. These are two distinct objects that are unrelated. Update groups allow you to organize updates and deploy, i.e. assign, updates to collections while update packages simply contain the update binaries that the client download when they need the binary for an update assigned and applicable to them.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Saturday, April 11, 2015 6:34 PM

All replies

  • Yes, you can use it like that. Actually, that's exactly how it's designed to be used. CAS is short for Central Administration Site, so in the ideal world you should be doing all your administrative tasks from the CAS. That includes the software update deployment.

    Note: This doesn't mean that you shouldn't install a software update point on the primary sites, as that's used by the clients to scan for compliance.


    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Saturday, April 11, 2015 5:51 AM
  • You *can* use it like that.
    Assuming that is consistent with the reasons you chose CAS in the first place?

    If you will do Software Updates Management in this hierarchy, then you *must* install SUP on the CAS (you have no choice about that) - because the CAS is the top-level SUP in the hierarchy, and only the CAS will sync to MSFT. (or to your other WSUS as USS if that is how you choose)
    Your primary sites in the hierarchy cannot sync to MSFT, they can only sync to your CAS. (essentially, primary site SUPs become DSS in relation to your CAS/USS).

    Assuming that you are implementing CAS+4PRI and need/wish to perform SUM at all 4 sites (remember CAS can not have clients), and you need/wish all objects/data (not necessarily packages) to replicate downwards to all PRI sites, and you need/wish to perform the SUM tasks in a centrally-managed fashion, then doing so at CAS is exactly what you should do.

    Really, it comes down to the reasons you chose to implement CAS at all (presumably for the benefits of central admin/management).

    e.g. if you have a PRI site for a datacentre, and, say that datacentre only has WindowsServers, then why push all the WindowsClient and Office stuff to that PRI site ?

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

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

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


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)


    Saturday, April 11, 2015 6:21 AM
  •  then we can deploy the packages to the collection just like software deployment.

    No, you do *not* deploy update packages. You deploy update groups. These are two distinct objects that are unrelated. Update groups allow you to organize updates and deploy, i.e. assign, updates to collections while update packages simply contain the update binaries that the client download when they need the binary for an update assigned and applicable to them.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Saturday, April 11, 2015 6:34 PM