Ours is expected behavior too, except for one piece. Once it tries to hit the DMZ MPs and failed, it should rollover to the HTTP MPs internally, but it’s not.
Daniel Ratliff From: [email protected] [mailto:[email protected]] On Behalf Of Krueger, Jeff Sent: Tuesday, August 05, 2014 9:44 AM To: [email protected] Subject: RE: [mssms] RE: Cross domain ConfigMgr Support We had a case open with Microsoft for the same issue, was told that it was expected behavior. So we’re using static boot images, which ultimately is not a huge issue for us (only a single primary) but still annoying. From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Ratliff Sent: Tuesday, August 5, 2014 9:30 AM To: [email protected] Subject: RE: [mssms] RE: Cross domain ConfigMgr Support We have a case open with Microsoft for this exact issue. Having separate boot disks for all of our primaries is not an option. I think we may end up just making all our MPs HTTPS. Daniel Ratliff From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of CE5AR.ABREG0 Sent: Tuesday, August 05, 2014 9:26 AM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] RE: Cross domain ConfigMgr Support Sorry for highjacking the thread a little bit. If you do bare metal OSD with dynamic boot disk, make sure you do additional testing. Behavior we have seen. When there is only one HTTPS MP, during WINPE client will try contacting it first because it will be at the top of the list due to preference and the client will not be able to download policies and display any TSs. We are currently dealing with this issue. Unless we are missing something, the only way to get around this issue, it is not to make the boot disk dynamic but when you have a CAS and multiple primaries/domains you need to have one per primary. Fun stuff, I hope it helps or get input from others. Cesar A. Meaning is NOT in words, but inside people! Dr. Myles Munroe My iPad takes half the blame for misspells. On Aug 5, 2014, at 4:21 AM, David O'Brien <[email protected]<mailto:[email protected]>> wrote: Just to add, never cut your clients in a secondary site off from the primary site. Even if you have a management point in your secondary, upon registration, the client will always talk to a primary site's management point. No matter what command line parameters you're using to point it somewhere else. I had to learn that recently, you can't completely separate networks. Cheers David Sent from my Windows Phone ________________________________ From: Robert Marshall<mailto:[email protected]> Sent: 5/08/2014 8:29 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Cross domain ConfigMgr Support 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]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: 05 August 2014 01:27 To: [email protected]<mailto:[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<https://urldefense.proofpoint.com/v1/url?u=http://blogs.technet.com/b/neilp/archive/2012/08/20/cross-forest-support-in-system-center-2012-configuration-manager-part-1.aspx&k=DRaZFQufJSh%2Bz2CJu01vGA%3D%3D%0A&r=G7Rp%2FyVEkz9AB1xRQWzmh1E0dbzzZxlFIY6QTWSRqzc%3D%0A&m=1IBGGsJ6a6wvr4dwkzTRbk499Xg7A0HAAg2WKwyQWlI%3D%0A&s=06f3472e1d7aaf8c200ba6baf1b807ed8e82b53c55e8fc7ddbbeb86b04acb007> 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. The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. ________________________________ CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy & Security page on www.henryford.com for more detailed information as well as information concerning MyChart, our new patient portal. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us. The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
