We already use https for our intranet so guess that is not an option. Most servers is on the DMZ is not member of a domain/forest only in workgroup mode, does these need to be joined to new domain or can you dictate MP/SUP preference on these? Are SUP preference just not a GPO, why do you need an alternate domain?
Regards Mattias Benninge http://myitforum.com/myitforumwp/author/matbe/ On Wed, Nov 19, 2014 at 11:46 PM, Eric Morrison <[email protected]> wrote: > Gotcha… We’ll see how it goes. J > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Jason Sandys > *Sent:* Saturday, November 15, 2014 2:28 PM > *To:* [email protected]; [email protected] > *Subject:* RE: [mssms] Managing Servers in a DMZ > > > > “Preference” is the key word. It’s not a hard or guaranteed affinity. What > exactly that equates to in technical terms is anyone’s guess though as all > the technical folks in the product team will tell us is that it’s a > “preference”. It should fail over “gracefully” though. > > > > J > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Eric Morrison > *Sent:* Saturday, November 15, 2014 7:42 AM > *To:* [email protected] > *Subject:* RE: [mssms] Managing Servers in a DMZ > > > > Separate domain, no trust. > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Jason Wallace > *Sent:* Saturday, November 15, 2014 1:25 AM > *To:* [email protected]; [email protected] > *Subject:* Re: [mssms] Managing Servers in a DMZ > > > > Same domain? > > > On 15 Nov 2014, at 05:15, Eric Morrison <[email protected]> wrote: > > Something I’ve noticed is that clients from my internal network will > attempt the DMZ MP, and vice versa… > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Jason Sandys > *Sent:* Friday, November 14, 2014 9:09 PM > *To:* [email protected]; [email protected] > *Subject:* RE: [mssms] Managing Servers in a DMZ > > > > No. This already falls into the scenario of my last paragraph as the best > way to do it at present. > > > > J > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Eric Morrison > *Sent:* Friday, November 14, 2014 7:02 PM > *To:* [email protected] > *Subject:* RE: [mssms] Managing Servers in a DMZ > > > > Hey Jason, > > > > Interesting response… > > > > My current environment has a separate forest/domain that is untrusted for > our DMZ. I have a site system server in that domain running SUP, MP, and DP > to manage the DMZ systems. > > > > Are you recommending to use a secondary site server in this scenario > instead? > > > > Thanks, > > > > Eric Morrison > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Jason Sandys > *Sent:* Friday, November 14, 2014 3:57 PM > *To:* [email protected]; [email protected] > *Subject:* RE: [mssms] Managing Servers in a DMZ > > > > Not really. This value is only for MPs, not SUPs. Thus, you’re still > stuck. The best you can do is put a secondary site in the DMZ which has a > DP, SUP, and DP on the secondary site server and additionally put an MP > from the primary into the DMZ as well. Then using the registry value, > configure all of the DMZ clients to use the MP in the DMZ. You should at > this point also use the registry value to configure all of your internal > clients to use only the internal MP(s). > > > > Alternatively, you could use some other method to patch systems in the DMZ > or maybe you could rely on the SUP failover to assign the proper SUP to > the systems in the DMZ (but I wouldn’t really architect a solution counting > on this behavior necessarily although it should and does work to my > knowledge). > > > > I am not a fan of this registry value as its more or less and poor man’s > hack. > > > > At this time, the best solution IMO is to use either HTTPS in the DMZ > (although there are few quirks with this as well) or deploy an alternate > domain/forest to the DMZ which will in turn dictate MP and SUP preference. > > > > J > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Mattias Benninge > *Sent:* Thursday, November 13, 2014 4:46 AM > *To:* [email protected] > *Subject:* [mssms] Managing Servers in a DMZ > > > > I know that this have been discussed before but I want to raise the > question if the possibilities have been change with CU3 for 2012 R2. > > > > With CU3 we get the option to limit a client to one or more specific(s) MP. > > > > > > *This cumulative update introduces a new registry entry for clients. This > entry will restrict which management point (MP) a client can communicate > with. This can be useful in environments that have multiple MPs in > different forests, and the clients can only communicate with a subset of > them. Setting the registry value to only those MPs that can be reached by > the client can improve overall efficiency. The new registry value is > AllowedMPs, a REG_MULTI_SZ (multi-string) type that is under the following > subkey: * > > *HKEY_LOCAL_MACHINE\Software\Microsoft\CCM* > > > > Does this mean that we now have a viable option for setting up an > MP/DP/SUP in DMZ? > > > > If this is not an option what is the recommended/supported way for > managing server/clients in a DMZ? What we want to do is basically patch and > inventory servers (workgroup) in DMZ. We have PKI and certificates on all > server already. > > > > > Regards > > Mattias Benninge > > http://myitforum.com/myitforumwp/author/matbe/ > > > > > > > > > > > > > > > > > > > >
