Just to add further . the MP and SUP roles are not location aware, so once you've got a site system with an MP and\or SUP into the DMZ you need to pay some thought to controlling DMZ devices attempts to access CORP roles, and the reverse from CORP to DMZ.
The ConfigMgr agent could treat all those MP's equal when performing selection, you say you've got the forest split up into multiple domains, well the ConfigMgr agent will select an MP based on Forest\Domain\Security Realm (HTTP\HTTPS), so you may have a form of location 'bounding' in place for the MP roles already. If you didn't have that bounding taking place due to your Active Directory design then you'd traditionally go with a Secondary Site server in the DMZ, so as to 'bound' the MP and SUP usage, but this scenario has a drawback in that your DMZ based devices will have to have a relationship with your Primary Site servers Management Point(s), as well as the Proxy Management Point, and that you can only put one of each role onto a Secondary so there is no high availability options, either role fails and you fall back to a (most likely) randomly selected role from the Primary. You may be able to block all traffic going to and coming from the DMZ on ports 80 and 8530\8531 at the DMZ's bridgehead just to make sure device traffic doesn't hop out of the DMZ, or stuff comes into the DMZ, or, introduce a ConfigMgr product extension called LocationAware that provides full location awareness to these roles, and lock your ConfigMgr Agents into specific MP's and SUP's. Think Boundary Groups for Management Points and Software Update Points. I have to declare self-interest here as I wrote LocationAware, but I'm certainly not herding you towards it, I'm also an ECM MVP and ConfigMgr architect so I like to answer these questions where I can, and go over what I can quickly recall around the area in question. I would certainly look at how best to do this and fit my needs with existing product or infrastructure design elements before venturing off to look at exotic and advanced forms of control. To me it sounds like you are part way there. Robert From: [email protected] [mailto:[email protected]] On Behalf Of Jason Sandys Sent: 05 August 2014 01:27 To: [email protected] Subject: [mssms] RE: Cross domain ConfigMgr Support First note that there's no reason to set up a site server at all for a DMZ or an alternate domain. This can easily be handled by a site system - note the difference between a site server and site system. Also, a site system can happily exist in an untrusted domain so it's really moot whether or not you have a trust in place. To directly answer one of your questions though, yes, two domains within a forest automatically have two-way trusts - this is simply part of them being part of the same forest. But as mentioned, is irrelevant for this scenario. And finally, yes you could also treat the systems in the DMZ as Internet based clients. J From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Beardsley, James Sent: Monday, August 4, 2014 6:28 PM To: [email protected] <mailto:[email protected]> Subject: [mssms] Cross domain ConfigMgr Support We're looking at setting up a domain in our DMZ where some IIS servers (10-20 at most) would reside and up until now, I've only ever managed one domain so one of the items I'm researching is how we'd manage resources in a separate domain with CM. One of the questions I had were about trusts. Would something like the simplest scenario #1 in this blog post below require a trust between the DMZ domain and our main domain where the CM primary site resides? http://blogs.technet.com/b/neilp/archive/2012/08/20/cross-forest-support-in- system-center-2012-configuration-manager-part-1.aspx Theres a statement where it says "In order to install and configure a child site (primary or secondary), the child site server must be located in the same forest as the parent site or reside in a forest that contains a two way trust with the forest of the parent (CAS or primary)". Am I reading that correctly where as long as the two domains are in the same forest, we wouldn't need a two-way trust? How about a one-way trust? I don't think we're going to put a child site in the DMZ domain unless we have to. I'd like to see those servers be managed directly from the primary site but I'm not at all familiar with cross-domain authentication. Understandably, certificate management is a factor but just from an SCCM communication standpoint, would something like this require a one-way, two-way, or no trust at all? Another idea I had was just manage the servers like they are laptops on the internet. Is there any reason that wouldn't work? Then they could just communicate with CM through our external facing URL and no trust would be needed at all. That would just require a lot of manual work to manage the certificates and install the client so if it's easier to do the method described in the blog post, we'll do that. Thanks in advance for your input. Thanks, James _____ Confidentiality Notice: This e-mail is intended only for the addressee named above. It contains information that is privileged, confidential or otherwise protected from use and disclosure. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, or dissemination of this transmission, or taking of any action in reliance on its contents, or other use is strictly prohibited. If you have received this transmission in error, please reply to the sender listed above immediately and permanently delete this message from your inbox. Thank you for your cooperation.
