locked
CM 2012 design question RRS feed

  • Question

  • Hey ,

    We are in process of designing POC for CM 2012. Just before I would go into details here is what we got:

    - 4 DCs across globe connected to one primary DC(data centre ;) ) in Europe

    - Over 120 branch offices connected with mixed network bandwidth (from ADSL to MPLS)

    - Branches have from 25 up to 600 ppl (this varies a lot and is really dynamic )

    - Each of the branches has a local server

    - It happens that in one city we have more than one branch office

    - Its business requirement to support OSD and App deployment in each of the offices

    - Each of the offices has its own subnet assigned and has AD site

    So considering all available information we have we have stablished that one single primary site in central data centre will be sufficient to support dynamically growing infrastructure.

    We will be using DPs to support App and PXE

    Now the questions I'm bit unclear till now:

    - If im correct withing single site MP is choosen randomly ?! So is there a point of having more than one in this globally dispersed infrastructure ? Primary site is hosted on dedicated HV cluster with fibre to storage ;)

    - How to correctly set up boundaries to use simplicity of CM 2012 ? I have an idea of having one called BG - Site Assignment - PS1 to have all boundaries included and to be used only for site assignment. Then I would have for offices in cities BG - Content Location - City Name all DPs from that area and primary site DP.

    I would appreciate any input if this set up is correct or you guys would suggest something else ;)


    Blog at http://www.rpieniaz.wordpress.com

    Sunday, May 13, 2012 8:34 PM

Answers

  • Yes, MPs are chosen randomly within a single AD forest. The main reason to have mutliple is simple availability so I yes I would definitely have two maybe three. Having the primary site on a fault tolerant cluster is good, but not a technically supported method of availability for ConfigMgr so if you have the resources, having multiple dedicated MPs is the best way to go (remember that MPs don't have to be on the primary site server as these are two distinct things).

    Boundaries really depend on a lot of things, for a single site as laid out here, I would defintiely have one all encompassing boundary for site assignment (0.0.0.0 - 255.255.255.255) and one for each location/DP for content location so that the DPs can be protected to those boundaries and preclude the possiblity of clients traversing the WAN for content. Also, never use anything except IP Address range boundaries.


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

    • Marked as answer by Rpieniazek Monday, May 14, 2012 8:10 AM
    Sunday, May 13, 2012 9:51 PM

All replies

  • Yes, MPs are chosen randomly within a single AD forest. The main reason to have mutliple is simple availability so I yes I would definitely have two maybe three. Having the primary site on a fault tolerant cluster is good, but not a technically supported method of availability for ConfigMgr so if you have the resources, having multiple dedicated MPs is the best way to go (remember that MPs don't have to be on the primary site server as these are two distinct things).

    Boundaries really depend on a lot of things, for a single site as laid out here, I would defintiely have one all encompassing boundary for site assignment (0.0.0.0 - 255.255.255.255) and one for each location/DP for content location so that the DPs can be protected to those boundaries and preclude the possiblity of clients traversing the WAN for content. Also, never use anything except IP Address range boundaries.


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

    • Marked as answer by Rpieniazek Monday, May 14, 2012 8:10 AM
    Sunday, May 13, 2012 9:51 PM
  • Hey ,

    Thanks for the info - Now it will be just finishing up POC ;)


    Blog at http://www.rpieniaz.wordpress.com

    Monday, May 14, 2012 8:11 AM
  • Just to clarify, ConfigMgr is not cluster aware at all and it is not supported to deploy to a cluster. The only aspect that can be clustered is the SQL database which can be deployed to a clustred SQL instance.

    Jason

    Monday, May 14, 2012 1:27 PM
  • Just to clarify, ConfigMgr is not cluster aware at all and it is not supported to deploy to a cluster. The only aspect that can be clustered is the SQL database which can be deployed to a clustred SQL instance.

    Yes, good clarifying point. Rpieniazek said "HV Cluster" which I assumed was a Hyper-V cluster. If that's accurate, then he's not actually installing ConfigMgr as a clustered application (which is not possible of course), but instead hosting it on a clustered VM, which isn't technically supported to my knowledge -- not that it doesn't work though, it's just not a fully tested solution.

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

    Monday, May 14, 2012 2:39 PM