I have been reading quite a bit about possible implementations regarding WORKGROUP systems in an SCCM environment. My company's current implementation exists of a site server and a sql server. Theylive in our internal domain. We eventually would like to configure WSUS via SCCM and have laid the foundation but are still using a WSUS standalone server. The primary site is in mixed mode and we could eventually move to native mode but have not had a need yet. I need to get the SCCM client installed onto our DMZ systems and have concerns regarding the most secure way to do this given our current SCCM implementation.From what I have been reading, manually installing the client on each system and opening ports 80, 445, 443, 135 UDP, 1025-5000 will allow me to add these DMZ systems directly to my internal SCCM site server. This seems like we would be opening a large hole from our DMZ systems into our internal network. Another option, if I have been reading correctly, would be to stand up another site system in the DMZ and have it communicate with my SCCM server.The DMZ clients would then communicate with the DMZ site system and back to the primary site.I have a few questions about this, probably from my lack of understanding on the SCCM product.1)Can i stand up a secondary site in my DMZ, or does it need to be a Primary site? 2)Do i require a domain in my DMZ, which we currently do not have. What would be seemingly ideal is a server I could place in the DMZ that runs some site systems, is trusted by the site server, and is the proxy for all the DMZ clients to communicate to my primary site server. Something like a gateway server in the SCOM environment. Mostly, I require some advice regarding my company's current needs. Given our SCCM implementation as is, what would an SCCM expert do to get the client working on SCCM systems (require hardware/software inventory, software distribution, and eventually Windows Updates via SCCM.) Thanks!-Scott

To answer both questions at once:You can create a secondary site in the DMZ butall site system servers must be in a domain and it would be up to you to protect the server-to-server communication betweeen the sites and open ports for this. Some site systems can only be installed in primary sites, so you might still need to open some ports for the clients.If you could achieve your business requirements (client installation, hardware/software inventory, software distribution, software updates) by not having to install a domain/forest in the DMZ or install additional site systems,or configure additional site boundaries, and require only HTTPS to be open on a firewall from the DMZ into the intranet -would this be a sufficient reason to migrate the site to native mode? If so, have a look at this post: http://social.technet.microsoft.com/Forums/en-US/configmgrsetup/thread/d78cf16e-4360-43eb-97bf-874ae1200d0b- CarolThis posting is provided AS IS with no warranties and confers no rights

Thank you for your reply Carol. I was considering the same thing this past week however we might soon implement AD in the DMZ. We dont really have any internet clients and our majority of mobile phone users carry blackberry's.I suppose there isnt much of a downfall to migrating to Native mode other than the additional administration required to set it up and it does seem like the better way to achieve what the company is requesting.

Alright I have finally implemented Native mode successfully and am ready to move forward with this. From the above link regarding DMZ systems and native mode, I have a few questions. This was the steps described by Carol in the link:If security is important to you, here's what I would do:1. Run your existing site in the intranet in native mode (assuming the PKI dependency can be met)2. Configure the site system running the default management point with an Internet FQDN that matches its intranet FQDN3. Configure the default management point to accept client connections from the intranet and the Internet4. Create a CD with all the client source files and a script to install the client as Internet-only With this configuration you can manage your DMZ servers for compliance, easily extend it so that they also install software updates and applications if needed, all communication between them and site systems in the intranet uses mutual PKI authentication and all traffic is over SSL, and because the server locator point is not needed for site assignment you don't need to open HTTP on the firewall - just HTTPS.I have steps 1 and 2 ready to go. I am curious about a few things. The company is requesting future implementation allow for internet based clients (non DMZ systems.) If I follow the above steps to connect my dmz systems, what is the best approach regarding 'real' internet clients? Can i have my dmz systems attached as outlined above, and still stand up the appropriate infrastructure in the DMZ to connect internet clients? In regards to name resolution, given these are all workgroup PCs and have no name resolution to the MP, what is the best way to connect them? Can i just specify the MP in the client install and be done with it? I would prefer not to rely on WINS or changing the host file manually to provide name resolution. Lastly, the above posts states that the configuration can be easily extended for software updates and applications. What more is required to provide for that extension?Thanks again!-Scott

I too am having a few problems with DMZ clients. 1: My clients are configured as Intranet clients. 2: Servers in the DMZ are in workgroups 3: Ports 80\443 are open on the DMZ firewall to the internal primary site which at the moment hosts roles for MP\DP. 4: SCCM Clients were installed as part of OSD whilst on the domain, so have sitecodes assigned by AD. I have managed, after much messing about managed to get an advertisement down to the client in the DMZ (basically by using an entry for the SLP in LMHOSTS and set up a new boundary for my Primary Site pointing to my DMZ subnet) The advert and program have been configured to show in RAP and download content locally to the cache. Now I can see the advert popup in RAP, but the content is NOT downloaded. In the CCM\Cache dir there is a directory that has been created with "ProgramID.SourceVersion.System", but there is no content there. I took a look at the DataTransferService.log file on the DMZ client, which states that the DTSJob {GUID} successfully completed download to c:\windows\syswow64\ccm\temp. however there are no files in this directory. I then took a look at the CAS.log on the DMZ client, and found the following: Successfully created location request {GUID} for package <ID>.<Source> Location update from LS for content <ID>.<Source> and location request <GUID> No matching DP Location Found Releasing content request {GUID} Cancelling LS Job {GUID} for content <ID>.<Source> So my question is now, how do I get the distribution point to become available to the client for download? Any help is gratefully received :)

This sounds like it's a boundary configuration issue to me (eg overlapping boundaries or the advertisement needs to be configured for slow and unreliable boundaries). Try walking through the process by using this troublehooting blog post: http://blogs.technet.com/configmgrteam/archive/2010/01/14/troubleshooting-client-content-download-in-configuration-manager-2007.aspx

Scott, I'm sorry that I missed your additional post on January 13th to this thread and you didn't get a response. If you still need help with this, open a new thread in the Configuration Manager Internet Clients and Native Mode forum with a reference back to this one, and I'll be sure to see it and reply there.

Hi Carol, This isn't a boundary issue, as the DMZ subnet is included in the AD Site, and is on a FAST LAN. I am going through the troubleshooting guides that you posted up, and will see if I get any further.. I think the problem is that I need a reverse proxy in the DMZ, so am working on getting that setup and running. Will let you all know how I get on.. Thanks.

Ok I am answering my own post, but hopefully it will help others who have found similar issues, this is not intended to teach anyone to suck eggs, rather the process that I went through to get SCCM\DMZ software deployments to work. Basically the problem that I had was that I didn't have any SAN (subject alternative Name) in my site server certificate, when clients are configured for Internet based management, I needed to have the internet and intranet FQDN's in the SAN. I recreated the Webserver Cert with 2 additional SAN's. The full process to get SCCM clients to work in a DMZ with only internal site servers is quite simple when you find the correct areas of documentation. Install DP ensuring that Communication Settings are configured to allow BITS, HTTP and HTTPS and "Allow both intranet and Internet client connections" is set. Have the Webserver Certificate configured with FQDN in the subject Configure SAN in the Webserver certificate to Intranet FQDN, Intranet NetBIOS name, Internet FQDN Import the Webserver Certificate into IIS Open ports 80\443 bi-directional (or which ever ports are configured on the Site Server) on any firewalls Create PFX file with exported key for the DMZ client, ensuring Intranet FQDN is supplied (even if in a workgroup) Copy and install PFX file in SCCM DMZ Client Copy full SCCM Client install files to DMZ Client Install Client ensuring that the following switches are used: /native:[fallback parameter] SMSSITECODE=XXX SMSSLP=SLP.FQDN FSP=FSP.FQDN SMSMP=MP.FQDN CCMHOSTNAME=SRV.FQDN CCMHTTPSTATE=1 CCMHTTPPORT=80 CCMHTTPSPORT=443 Once client is installed, you should now be able to pull policy and deploy software without any external infrastructure. Top client logs to follow (in no particular order): ClientLocation.log - To identify that the management point is correctly picked up FSPStateMessage.log - To confirm client can communicate with the FSP CAS.log - To identify the download locations for packages ClientAuth.log - To identify certificate retrieval status DataTransferService.log - To identify Cert Retrieval Status and Internet based DP download URL ContentTransferManager.log - To monitor the download InternetProxy.log - Should you use one (I didn't) You may also want to check out the IIS logs as this will indicate any issues with WebDav configuration (remember RequestFiltering in ApplicationHost.config file!)