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]] > 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]] > 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]] > 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]] > 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/ > > > > > >
