locked
Architecture Sanity Check RRS feed

  • Question

  • I'm building out an architecture for a customer and it's odd enough that it doesn't fit the normal rules, I'd appreciate a sanity check.  The environment consists of:

    • Forest A - this is the main area for workstations and servers, but it has two zones that are separated by firewalls, the firewalls can be opened but preference is not to open them up.
    • --- Primary Site Server with a secondary site server to serve the second zone.  This allows the computers in the second zone to connect to MP, DP, WSUS and other roles without crossing the firewall.  Client installation will have to specify the MP.
    • Forest B - this is a remote area that has a trust relationship to Forest A but is separated by a firewall.  Clients from A may roam to B, but B will not roam to A
    • --- Secondary site server to manage the machines in the zone, again with MP, DP, WSUS to eliminate the cross forest boundary issues.  Again agent installs with MP specified.
    • Forest C - this is a DMZ, it has a DR site as well and where we will need to put the Internet facing equipment and have servers to manage, all servers are members of forest C.  No trust between this forest and the others.
    • --- Two secondary sites, one for the main site, the other for the DR site.  I chose a secondary so that they could manage all of the servers in the zone.  Main reason for using it rather than the Internet facing server is the need for a local MP and I have two zones.
    • --- An Internet facing server that has the MP, DP, WSUS, SLP and App Catalog roles, I'm going to try and get this to be a member of Forest A, if I can then user software requests via the catalog are possible.  If not the App Catalog won't be isntalled since user authentication can't happen.  I would like to setup one of these in the main and DR sites, but as near as I can tell I can have only one Internet facing MP, having more would confuse the agents.  Solution to that is to put it on a VM with a replica sitting at the DR site or convince them that a failover of that magnitude SCCM functioning over the Internet would probably be their least concern.
    All cross zone/boundary connections will be IPSEC.  My alternative to this is to setup a Primary in each forest, but I'm not sure the primary in the DMZ would be able to service the Internet clients.

    Bob

    Monday, December 17, 2012 9:09 PM

Answers

  • Primary site server with a secondary site servers won't work for your different zones:

    - You can't specify a "proxy" MP when installing a client. They aren't referred to officially as "proxy" MPs anymore, but the fact remains, clients use MPs in a secondary site based upon content boundaries and not assignment.

    - Clients in secondary sites must be able to contact the MP in the primary site. This is mainly only true during initial client installation, but there could be other times when this is required. Secondary sites are not "gateways" and are not intended for use across a network barrier like a firewall.

    Also note, you mentioned that you "chose a secondary so that they could manage all of the servers in the zone". Secondary sites do not manage clients in any way. Secondary sites merely provide a network conduit for some client traffic back to the primary or the ability to offload some client traffic to local roles like a DP or SUP.

    I don't see much of an option besides using primary sites for each of your different "zones".


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Bob Panick Tuesday, December 18, 2012 2:01 AM
    Monday, December 17, 2012 10:40 PM
  • Primary site server with a secondary site servers won't work for your different zones:

    - You can't specify a "proxy" MP when installing a client. They aren't referred to officially as "proxy" MPs anymore, but the fact remains, clients use MPs in a secondary site based upon content boundaries and not assignment.

    - Clients in secondary sites must be able to contact the MP in the primary site. This is mainly only true during initial client installation, but there could be other times when this is required. Secondary sites are not "gateways" and are not intended for use across a network barrier like a firewall.

    Also note, you mentioned that you "chose a secondary so that they could manage all of the servers in the zone". Secondary sites do not manage clients in any way. Secondary sites merely provide a network conduit for some client traffic back to the primary or the ability to offload some client traffic to local roles like a DP or SUP.

    I don't see much of an option besides using primary sites for each of your different "zones".


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Bob Panick Tuesday, December 18, 2012 2:01 AM
    Monday, December 17, 2012 10:40 PM

All replies

  • Primary site server with a secondary site servers won't work for your different zones:

    - You can't specify a "proxy" MP when installing a client. They aren't referred to officially as "proxy" MPs anymore, but the fact remains, clients use MPs in a secondary site based upon content boundaries and not assignment.

    - Clients in secondary sites must be able to contact the MP in the primary site. This is mainly only true during initial client installation, but there could be other times when this is required. Secondary sites are not "gateways" and are not intended for use across a network barrier like a firewall.

    Also note, you mentioned that you "chose a secondary so that they could manage all of the servers in the zone". Secondary sites do not manage clients in any way. Secondary sites merely provide a network conduit for some client traffic back to the primary or the ability to offload some client traffic to local roles like a DP or SUP.

    I don't see much of an option besides using primary sites for each of your different "zones".


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Bob Panick Tuesday, December 18, 2012 2:01 AM
    Monday, December 17, 2012 10:40 PM
  • Primary site server with a secondary site servers won't work for your different zones:

    - You can't specify a "proxy" MP when installing a client. They aren't referred to officially as "proxy" MPs anymore, but the fact remains, clients use MPs in a secondary site based upon content boundaries and not assignment.

    - Clients in secondary sites must be able to contact the MP in the primary site. This is mainly only true during initial client installation, but there could be other times when this is required. Secondary sites are not "gateways" and are not intended for use across a network barrier like a firewall.

    Also note, you mentioned that you "chose a secondary so that they could manage all of the servers in the zone". Secondary sites do not manage clients in any way. Secondary sites merely provide a network conduit for some client traffic back to the primary or the ability to offload some client traffic to local roles like a DP or SUP.

    I don't see much of an option besides using primary sites for each of your different "zones".


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Bob Panick Tuesday, December 18, 2012 2:01 AM
    Monday, December 17, 2012 10:40 PM
  • Thanks Jason, that was one of the things I was worried about.  I knew it wouldn't work in 2007 but I never came across a good description of how the MP functions in 2012.

    Question though, any thoughts about how to deal with the Internet facing clients?  The primary in the DMZ won't be the site for the clients actually connecting to it, and I thought I saw something that suggested clients won't access MPs from different sites.  The only thing I can think of here would be to put the member server in to handle the MP functions on the Internet; however I might be able to use the DP, WSUS, etc on the primary in the DMZ zone.

    I do wish someone from Microsoft would put a good best practices suggestion for how to implement all this stuff, the stuff that's on TechNet and even the blogs is basic at best.


    Bob

    Tuesday, December 18, 2012 2:07 AM
  • As I dig back through the documentation it appears that I could simply setup MPs on servers in the DMZ and other zones and make them members of that forest.  As I understand it when the agent is installed the MP can be specified, from that point the agent will get the MP list and will try each one until it finds one that meets its needs.  So it sounds like I would be better off doing that rather than using multiple primary sites.

    I'll probably need to stand up one of them to be Internet facing that is part of the intranet forest to get user application catalog requests to work.


    Bob

    Tuesday, December 18, 2012 2:52 PM
  • Yes, that's feasible, but not until SP1 when you can have multiple active SUPs in a single Primary Site.


    Jason | http://blog.configmgrftw.com

    Tuesday, December 18, 2012 8:29 PM
  • Yep, I spotted that one, we were planning on going with SP1, particularly if we can get the SP1 bits in January. 

    Have you seen anything yet that controls how the agents fnd the SUP/WSUS in those cases.  I have the beta installed and I haven't found anything yet that suggests how they manage that.  The only thing I can think of would be something like the MPs where they get a list of them, first one to answer type thing.


    Bob

    Tuesday, December 18, 2012 10:04 PM
  • Yes, it is exactly like the MP. Essentially a GC lookup that returns a list of MPs (or SUPs) with HTTPS capable MPs returned first (if the client is HTTPS capable) and all other MPs (or SUPs) returned last and no guaranteed or specific ordering within those two categories.

    Jason | http://blog.configmgrftw.com

    Tuesday, December 18, 2012 10:14 PM
  • Thanks Jason.

    Going back to the MP on the secondary, I haven't found anything that calls out the MP on the secondary as being different from another MP.  I'm wondering is dropping the Proxy MP designation because it's an MP that is found like any other MP, with the exception it can't be Internet facing.  I think I like using the servers directly better anyway for this solution, but I'd like to know if MPs on secondaries are different than normal MPs.


    Bob

    Wednesday, December 19, 2012 2:43 PM
  • A MP installed on a secondary in CM07 was called "proxy MP". It has been "renamed" to MP in CM12. No difference in functionality though.

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

    Wednesday, December 19, 2012 3:17 PM
  • To the client, they are no different than they were in 2007. They are found differently from primary MPs though -- based on content download boundary groups and not the normal site assignment procedures and lookup in AD: http://blog.configmgrftw.com/?p=453

    Clients are never assigned to a secondary and thus an MP at a secondary is never assigned to a client. Clients will use an MP at a secondary if they fall within the content location boundary group associated that the secondary site has been associated with.

    I think they dropped the "proxy" designation because secondaries no longer "cache" policy lookups but instead have a replica of the policy information from the primary's SQL Server DB stored in their own local SQL Server DB that they can directly hand-out to clients.


    Jason | http://blog.configmgrftw.com

    Wednesday, December 19, 2012 3:22 PM
  • Interesting discussion, thank you both. 


    Bob

    Thursday, December 20, 2012 1:04 PM