If it is performance as designed then you'll likely get the same response. You might get some way by raising a DCR but if use of HTTPS is the answer then that sounds like a reasonably easy fix
> On 5 Aug 2014, at 16:31, "Daniel Ratliff" <[email protected]> wrote: > > Hopefully we get a better answer. Will let you know. > > Daniel Ratliff > > From: [email protected] [mailto:[email protected]] > On Behalf Of Krueger, Jeff > Sent: Tuesday, August 05, 2014 10:19 AM > To: [email protected] > Subject: RE: [mssms] RE: Cross domain ConfigMgr Support > > Yep exact same thing we saw, it tries first to talk to the HTTPS MP and would > not fail over, and PE would error out because it couldn’t download policy. > MS support told us that was by design and we’d have to use a static boot > image or put a cert in our boot images. > > From: [email protected] [mailto:[email protected]] > On Behalf Of Daniel Ratliff > Sent: Tuesday, August 5, 2014 9:59 AM > To: [email protected] > Subject: RE: [mssms] RE: Cross domain ConfigMgr Support > > 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]] > On Behalf Of CE5AR.ABREG0 > Sent: Tuesday, August 05, 2014 9:26 AM > To: [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]> 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 > Sent: 5/08/2014 8:29 PM > To: [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]] > 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]] > On Behalf Of Beardsley, James > Sent: Monday, August 4, 2014 6:28 PM > To: [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. > > > > > > > > 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. > > > > 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. >
