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]] On Behalf Of Edward Woo Sent: Thursday, November 6, 2014 5:57 PM To: [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 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.
