Installing SCCM site systems in a DMZ environment

  1. Determine what site systems should be placed in DMZ. In my case I chose to install MP, SUP and DP. I also wanted all these roles to only communicate via HTTPS for security reasons. This requires installing a certification authority server (ADCS), so do that first if there is none in your environment. After installing that create certificate templates and GPOs according to this guide. It’s VERY important to create the certificate templates with Windows XP/Server 2003 compatibility, otherwise client authentication will fail. Also very important to make sure the clients choose the right certificate when they are registering with their management point, more about that later.
  2. Install prerequisites for MP and DP with this script.
  3. Install WSUS. To limit traffic and needed firewall ports opened I went with a shared WSUS configuration according to this guide. If you don’t need/want this just install WSUS as usual with either a MS SQL installation or WID, and jump to step 4.
  • On the primary server, make sure the computer account of the DMZ server has dbo permissions to SUSDB in SQL. You need to add this computer account manually in SQL Server Management Studio by creating a new login. Map the account to SUSDB in “User Mapping”, click “db_owner” and then OK.

    sql_permissions

  • The DMZ server will also reuse the existing WSUS content from the primary server. On the primary server, add read/write permissions on that folder for the DMZ server’s computer account.
    ntfs_permissions
  • I also added NTFS read permissions for the DMZ computer account on the actual SUSDB.mdf file on the primary server. I’m not sure if this is needed.
  • On the DMZ server, install WSUS via Server Manager. Just choose WSUS Services and NOT any of the database options. For content location choose the WSUS content folder share from the primary server, i.e. \\primary\WSUS or the like.
  • Configure WSUS to use a shared database. On the DMZ server, first stop the IIS, WSUS and Windows Updates services. Run this command:
    net stop W3SVC && net stop WsusService && net stop wuauserv
  • On the DMZ server, start regedit as administrator. Go to HKLM\Software\Microsoft\Update Services\Server\Setup. Change the values for ContentDir and SqlServerName to the following:
    ContentDir: \\primary\WSUS
    SqlServerName: hostname of primary server
    registry_settings
  • On the DMZ server, start the IIS console. Expand Sites –> WSUS Administration. Right click Content –> Manage Virtual Directory –> Advanced Settings. Change Physical Path to:
    \\primary\WSUS\WsusContent\
    iis_wsus_content_path
  • On the DMZ server, check if the WSUS service is disabled in services.msc and enable it if so.
  • On the DMZ server, start the three services again:
    net start W3SVC && net start WsusService && net start wuauserv
  • On the DMZ server, start the WSUS console and connect to the primary server. If it’s working, the shared database configuration is ok!
  1. On the primary server, install a new site system server from Administration à Site Configuration –> Servers and Site System Roles –> Create Site System Server. Pick your DMZ server. Add the MP, SUP and DP roles. Click next until completion, we will change the HTTPS settings later. Installing the roles might take a while.
  2. Configure WSUS/SUP to use SSL (HTTPS). On the DMZ server, open the IIS console. Create a domain certificate according to this guide.
  • Expand Sites –> WSUS Administration. Click Bindings and then edit the HTTPS entry. Choose your WSUS certificate you just generated.
  • Select the APIRemoting30 virtual directory. Double click SSL Settings and enable the Require SSL option, then click Apply. Repeat this step for the ClientWebService, DSSAuthWebService, ServerSyncWebService, and SimpleAuthWebService virtual directories.
  • Start an elevated command prompt and run this command:
    C:\Program Files\Update Services\Tools\WSUSUtil.exe configuressl fqdn-of-dmz-server
  • WSUS configuration is now done!
  1. Configure DP and MP to use HTTPS and SUP to use SSL.
  • DP: On the primary server, start the SCCM console and go to Administration –> Site Configuration –> Servers and Site System Roles. Click your new DMZ server and then right click Distribution point and choose properties.
    rc_dp
  • Select HTTPS and click OK.
    dp_https
  • Right click Management point and change communication to HTTPS as well, then click OK.
  • Right click Software update point and put a checkmark in “Require SSL communication…”.
  1. Configure the primary site to use HTTPS when available.
  • Right click the site and choose properties.
    rc_site
  • Click the Client Computer Communication tab. Mark the checkboxes according to the screenshot. Click Set and import the Root CA certificate. You need to export this certificate from the CA server first, instructions here. Click Modify to set certificate selection to your satisfaction.
    client_comm

    client_cert_selection

  • This is where certificates can start to become confusing. The certificate templates that you created earlier are designed for client authentication. However, if there are other certificate templates (with other compatibility settings) published in your domain that are also used for client authentication, and those certificates are already enrolled by your clients, it can become a problem if the clients choose the wrong certificate when they register with their management point. I’ve found that the easiest solution to this is to make sure the SCCM client certificate templates have the longest validity period. If you do this the default behavior of SCCM is to automatically choose that certificate.
  1. Make sure the DMZ management point is published to DNS.

    dmz_mp_dns_publish

    dmz_mp_dns_publish2

  2. Add timeout error code to the WSUS scan retry error list. The default behavior in SCCM is that clients pick a SUP at random and try to scan for metadata against it. It if fails it will try 3 more times and then switch over to another SUP. However, it only fails over if it gets certain error codes. A timeout error (0x80072ee2) WILL NOT make the client fail over. You will most certainly get this error so it’s best to add this to the error code list. Do this on the primary site and use this excellent guide.
  3. Also very important is to ensure your clients choose the correct management point, otherwise they will never get the correct client policies. If you run a CM12 R2 SP1 site you can force clients to only use MPs according to their respective boundaries/boundary groups, which is great.

    rc_hierarchy_settings

    client_mp_affinity

If you run only a plain R2 (at least CU3) site you need to get more creative and hard code management points in the registry. Check out this guide and implement a GPO or something to add these registry settings to your DMZ clients.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s