locked
Disaster recovery heirarchy design question RRS feed

  • Question

  • Hi  there

    I'm working on a SCCM 2012 design, and so far the design looks like this:

    Site1: Main site - CAS & Child Primary

    Site2: 2500+ clients therefore a Child Primary instead of a secondary (due to the client limit on secondaries).  There are network constraints that remove the possibility of allowing these clients to report directly to the main site.

    Site3: 1000 workstations and also a hot DR site.

    Site4: Cold DR Site (live on the network)

    Sites 5 - 29: Secondary site servers hanging off Site1

    Sites 30 - 100: Remote distribution points hanging off the secondaries

    What I'm trying to define is the best server type / strategy for sites 3 and 4. 

    Could I for example make them both primaries and then cut the applicable one loose from the CAS in a DR situation?  Is it possible to manage child primary servers directly in a 2012 infrastructure, so that some critical DR packages be defined on these servers directly as opposed to only on the CAS?  

    Or would it be advisable to rather run a secondary on Site 3, and then a separate SCCM 2012 DR heirarchy running side by side the production SCCM 2012 system?

    Thanks

    Kevin

    Wednesday, June 27, 2012 10:16 AM

Answers

  • Some quick thoughts based on your info:
    - On Site1 I would not go for a CAS, instead implement a primary on your main site
    - On Site2 implement a secondary to manage your network constraints (it can support up to 5000 clients)
    - On the other sites implement either a secondary or a DP, depending on your requirements

    Specifically for DR maybe consider the following strategy:
    - Ensure specific roles are made redundant (Mainly MP, DP ...) in case the primary site server goes down
    - Have some infrastructure in place to quickly recover the primary site server (eg standby server with OS, SQL installed)

    Similar approaches have been discussed in other threads (eg here and here). Might be good to have a look at those as well.



    • Edited by TimDKMVP Wednesday, June 27, 2012 10:37 AM
    • Marked as answer by Kevin de Wet Thursday, June 28, 2012 10:44 AM
    Wednesday, June 27, 2012 10:36 AM
  • In general don't think too much 2007 ... think 2012. ;-)

    The 5000 clients for a secondary is documented as a supported configuration by the vendor (here). No need to doubt that.

    When your environment scales out over a large number of sites keep in mind that a single secondary supports up to 250 DP's. You may need multiple secondary sites in your case.

    For managing the environment you can connect to the CAS or a Primary. When you connect to the CAS, you can view and configure data for all sites in the hierarchy. If you have a CAS but connect the Configuration Manager console directly to a primary site, you can view and manage Configuration Manager data from this connection, but you cannot see data from other primary sites or from the secondary sites of other primary sites.

    • Marked as answer by Kevin de Wet Thursday, June 28, 2012 10:44 AM
    Wednesday, June 27, 2012 11:27 AM
  • If you have a CAS but connect the Configuration Manager console directly to a primary site, you can view and manage Configuration Manager data from this connection, but you cannot see data from other primary sites or from the secondary sites of other primary sites.

    Not true. Global data will be visible on ALL sites (example: packages are part of global data). A package created on the CAS will be replicated to all primaries. A package created on a primary will be replicated to the CAS and the CAS will replicate it to all primaries.

    Torsten Meringer | http://www.mssccmfaq.de

    • Marked as answer by Kevin de Wet Thursday, June 28, 2012 10:44 AM
    Wednesday, June 27, 2012 11:39 AM
  • OK so lets say you had an active Primary at a DR site, and the site running the CAS gets wiped out in a disaster.   Would it then be possible for that primary to cut ties with the CAS and service clients at the DR site even if the packages, collections, configuration items etc. were all defined on the CAS?
    No. As discussed by Tim and Torsten, primary sites cannot and do not have knowledge or visibility of clients not assigned to them thus in a DR scenario you would be faced with reassigning all of you clients from one site to another -- not fun or easy. Thus using multiple primaries is not suitable for a DR scenario.

    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    • Proposed as answer by TorstenMMVP Monday, July 2, 2012 7:35 AM
    • Marked as answer by Kevin de Wet Wednesday, July 11, 2012 1:20 PM
    Monday, July 2, 2012 3:19 AM
  • For a secondary site, you can use an existing instance of SQL Server or allow Setup to install and use an instance of SQL Server 2008 Express.

    Personally I would opt for a SQL Server Standard Edition if possible, mainly from a manageability perspective.

    Note that regardless of the version, the SQL Server must be located on the secondary site server.

    I don't agree with this. For manageability, SQL Express is fully manageable from SQL Management Studio, it just doesn't come with it but you can easily connect the instance of Management Studio on your primary to it.

    Also, sing SQL Standard will cost you a boatload of money.


    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    • Proposed as answer by TorstenMMVP Monday, July 2, 2012 7:35 AM
    • Marked as answer by Kevin de Wet Wednesday, July 11, 2012 1:20 PM
    Monday, July 2, 2012 3:22 AM

All replies

  • Some quick thoughts based on your info:
    - On Site1 I would not go for a CAS, instead implement a primary on your main site
    - On Site2 implement a secondary to manage your network constraints (it can support up to 5000 clients)
    - On the other sites implement either a secondary or a DP, depending on your requirements

    Specifically for DR maybe consider the following strategy:
    - Ensure specific roles are made redundant (Mainly MP, DP ...) in case the primary site server goes down
    - Have some infrastructure in place to quickly recover the primary site server (eg standby server with OS, SQL installed)

    Similar approaches have been discussed in other threads (eg here and here). Might be good to have a look at those as well.



    • Edited by TimDKMVP Wednesday, June 27, 2012 10:37 AM
    • Marked as answer by Kevin de Wet Thursday, June 28, 2012 10:44 AM
    Wednesday, June 27, 2012 10:36 AM
  • Hi Tim

    Thanks for the reply.

    I see I had the wrong information on the supported client number for secondaries.  Would you feel comfortable in a production environment to have as many as 5000 clients reporting in to a secondary?  To me even at 2500 it feels like a primary would be needed, but perhaps I'm thinking more Configmgr 2007.

    So to elaborate further, these 2500 clients are spread across +- 600 sites on slow and unreliable networks.  For now we would enable branchcache on those sites, but in future there may be the requirement to put down a distribution point on each site.  I'm not sure I'd be ok with configuring 600 DP's below a secondary.  In larger implementations like these we have typically tried to flare out for large site numbers e.g. Primary on site2 with 2 or 3 secondaries below this and then spread the DP's across those secondaries.  I see a lot of the forums are punting no CAS unless you have a huge site, but it seems to me that scenarios like this one there may also be a case for it?

    Incidently do you know if it is possible to manage child primary sites directly (i.e. for package, collection creation etc.) or do you have to manage the environment from the CAS?

    Thanks

    Kevin

    Wednesday, June 27, 2012 11:12 AM
  • In general don't think too much 2007 ... think 2012. ;-)

    The 5000 clients for a secondary is documented as a supported configuration by the vendor (here). No need to doubt that.

    When your environment scales out over a large number of sites keep in mind that a single secondary supports up to 250 DP's. You may need multiple secondary sites in your case.

    For managing the environment you can connect to the CAS or a Primary. When you connect to the CAS, you can view and configure data for all sites in the hierarchy. If you have a CAS but connect the Configuration Manager console directly to a primary site, you can view and manage Configuration Manager data from this connection, but you cannot see data from other primary sites or from the secondary sites of other primary sites.

    • Marked as answer by Kevin de Wet Thursday, June 28, 2012 10:44 AM
    Wednesday, June 27, 2012 11:27 AM
  • If you have a CAS but connect the Configuration Manager console directly to a primary site, you can view and manage Configuration Manager data from this connection, but you cannot see data from other primary sites or from the secondary sites of other primary sites.

    Not true. Global data will be visible on ALL sites (example: packages are part of global data). A package created on the CAS will be replicated to all primaries. A package created on a primary will be replicated to the CAS and the CAS will replicate it to all primaries.

    Torsten Meringer | http://www.mssccmfaq.de

    • Marked as answer by Kevin de Wet Thursday, June 28, 2012 10:44 AM
    Wednesday, June 27, 2012 11:39 AM
  • OK so lets say you had an active Primary at a DR site, and the site running the CAS gets wiped out in a disaster.   Would it then be possible for that primary to cut ties with the CAS and service clients at the DR site even if the packages, collections, configuration items etc. were all defined on the CAS?
    Wednesday, June 27, 2012 11:52 AM
  • Correct Torsten - the statement is too general and should have explicitly mentioned the type of data (global vs site).
    Wednesday, June 27, 2012 11:59 AM
  • One more question:

    So up to 5000 clients are supported on a SCCM 2012 secondary.  When would it be advisable (i.e. client numbers) to rather use a full SQL install over SQL express at a secondary?  Would it be fine for example, to use SQL Express on a secondary with 5000 clients?

    • Proposed as answer by TimDKMVP Thursday, June 28, 2012 11:15 AM
    • Unproposed as answer by TimDKMVP Thursday, June 28, 2012 11:15 AM
    Thursday, June 28, 2012 11:00 AM
  • For a secondary site, you can use an existing instance of SQL Server or allow Setup to install and use an instance of SQL Server 2008 Express.

    Personally I would opt for a SQL Server Standard Edition if possible, mainly from a manageability perspective.

    Note that regardless of the version, the SQL Server must be located on the secondary site server.

    Thursday, June 28, 2012 11:19 AM
  • OK so lets say you had an active Primary at a DR site, and the site running the CAS gets wiped out in a disaster.   Would it then be possible for that primary to cut ties with the CAS and service clients at the DR site even if the packages, collections, configuration items etc. were all defined on the CAS?
    No. As discussed by Tim and Torsten, primary sites cannot and do not have knowledge or visibility of clients not assigned to them thus in a DR scenario you would be faced with reassigning all of you clients from one site to another -- not fun or easy. Thus using multiple primaries is not suitable for a DR scenario.

    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    • Proposed as answer by TorstenMMVP Monday, July 2, 2012 7:35 AM
    • Marked as answer by Kevin de Wet Wednesday, July 11, 2012 1:20 PM
    Monday, July 2, 2012 3:19 AM
  • For a secondary site, you can use an existing instance of SQL Server or allow Setup to install and use an instance of SQL Server 2008 Express.

    Personally I would opt for a SQL Server Standard Edition if possible, mainly from a manageability perspective.

    Note that regardless of the version, the SQL Server must be located on the secondary site server.

    I don't agree with this. For manageability, SQL Express is fully manageable from SQL Management Studio, it just doesn't come with it but you can easily connect the instance of Management Studio on your primary to it.

    Also, sing SQL Standard will cost you a boatload of money.


    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    • Proposed as answer by TorstenMMVP Monday, July 2, 2012 7:35 AM
    • Marked as answer by Kevin de Wet Wednesday, July 11, 2012 1:20 PM
    Monday, July 2, 2012 3:22 AM