The server must be joined to a domain, though it doesn't necessarily have to be the same domain as your primary. Of course it still has to be able to communicate with the primary and will need the relevant accounts setup and ports opened between the two. You can set up this site system server to accept only clients from the internet, or do both internet and intranet.
Remember each MP can handle 25,000 clients, so I don't see the 10 MP limit as a problem and would locate any additional MPs (besides the one dedicated to IBCM) in your data center with the Primary server. If you have slow WAN links for remote offices you can setup a Secondary Site for though that really depends on client count as they don't send much data, otherwise just have a local DP for content. From: [email protected] [mailto:[email protected]] On Behalf Of Edward Woo Sent: Friday, November 7, 2014 2:15 PM To: [email protected] Subject: [mssms] RE: CM 2012 Roles for DMZ Client Management Hi Jeff, Given that a primary site is limited to 10 MPs, would it be sufficient to run one site system with MP, DP and SUP roles on it to handle remote sites? Is it possible to run the site system on a workgroup server or does that server have to be a member of the domain? (Trying to see if I can somehow the crossover from DMZ into our internal network.) Thanks, Edward From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Krueger, Jeff Sent: Friday, November 07, 2014 5:38 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: CM 2012 Roles for DMZ Client Management Secondary sites do not support Internet Based Client Management. I would setup a site system located off your primary with the MP,DP and SUP roles on that. Configure that one for certificates and publish an Internet FQDN that is tied to a VIP pointing at that site system. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Edward Woo Sent: Thursday, November 6, 2014 5:57 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] CM 2012 Roles for DMZ Client Management Hi All, I tried going through my archive of e-mails regarding SCCM 2012 roles used to manage DMZ (Workgroup/external facing) systems, but I couldn't find all the answers I wanted and was hoping people here could help clear things up for me the best ways to achieve my goals. The DMZ systems we want to manage with SCCM are workgroup systems that have some level of external facing access. We're primarily interested in the HW/SW inventory scans and software updates and application deployment of these systems. We have DMZ systems located at some of our offices so they're not located at one site and the number of systems can vary in number from 1 to 20 at the different locations. Initially my plan was to configure the internal domain based systems to use HTTP for communications and DMZ systems will require HTTPS communications and eventually migrate the internal systems to HTTPS as well. Deployment of an internal PKI is not going to be an issue for us. I do want to keep our internal clients communicating with a different MP than the DMZ based systems as a means of separation. It was also my understanding that client communications with MPs weren't really location aware, except when deployed using primary/secondary sites, though one of the most recent SCCM updates supposedly addresses that issue with a registry fix. Would it make sense to deploy a single secondary site just to handle all DMZ communications from all sites or would one deploy a secondary site for DMZ clients at each of the location? Or would it be better to just deploy an MP, DP, and SUP just to manage the DMZ systems and apply the update that addresses location awareness? Is there any additional protections that I could put in place to further isolate our DMZ systems from reaching the internal network? 1. I believe you can restrict primary site communications so that it is only initiated by the primary site server down to the child sites, but does that include primary to secondary site communications? 2. Can either the secondary site or MP/DP/SUP roles be installed on a workgroup server sitting on a restricted VLAN so that only DMZ clients can contact this restricted VLAN for agent communications and only the parent primary site server can contact this restricted VLAN for SCCM communications? That way the only risk is limited to the SCCM server in that restricted VLAN and one can't attack the AD systems through that server. Or do you have some other suggestion that would work (without building a separate independent SCCM environment for DMZ systems). Many thanks in advance! Edward Woo ________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.henryford.com&d=AAMFAg&c=aLnS6P8Ng0zSNhCF04OWImQ_He2L69sNWG3PbxeyieE&r=pQGVi_ygWZb0EWR_EeMFzgKJCQ8AFTQI7Ck6iiIPItI&m=2DPlCqP0LkqG29Bn8HPtNIDfcieyVYW5cP-fxlA8oSo&s=wEmIs-fwnuTdSqmKCKRraWZb98vo711WPUMlLrGE20w&e=> 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.
