Microsoft SCCM 2012 R2 - Dual SUPs, Same Site

Had to cobble together some information to get this working. As usual, I try to center my posts around information that I had to spend some time researching...to hopefully save someone else the trouble.

I wanted to setup two SCCM 2012 R2 SUPs within the same Site. One is for Intranet clients, the other for Internet clients (IBCM). To mitigate the "change WSUS server sync penalty" Microsoft recommends setting the two SUPs up with the same SQL and same content directory per this article. Well, they don't truly explain how to do that clearly, especially on Windows Server 2012 R2. Here are the collection of technet articles I pooled together to get this right:

TechNet Blog - Describes this exact thing! (without much detail!)
Configure WSUS for NLB - Ignore the NLB parts, no need for NLB with SCCM, gives some better detail on several of the steps

Here is a quick and dirty step outline on how I got this working:

1) Create a domain service account for IIS to reach the contentdir network share - ill use wsususer for the remainder of this blog entry.

2) Create a folder for the WSUS content and share it (you can do DFS if you want, I just did standard share) Any server can host it, I chose my "first" WSUS server. This may not be precise, but it worked for me...set the permissions as follows:

• NETWORK SERVICE - Full Control
• wsususer - Read
• WSUSCOMPUTERACCOUNT-1 - Full Control
• WSUSCOMPUTERACCOUNT-2 - Full Control

3) Server #1 - Install WSUS on the first server: (powershell makes it easy)

Install-WindowsFeature -Name UpdateServices-Services,UpdateServices-DB -IncludeManagementTools

 4) Server #1 - Run postinstall on the first server, specifying the remote SQL DB but leaving content directory at default (we'll move it after the install, an important point)

.\wsusutil.exe postinstall SQL_INSTANCE_NAME="DBSERVER\INSTANCE"

5) Server #1 - Run the wsustuil movecontent to the newly created share. Its located in C:\Program Files\Update Services\Tools

  .\wsusutil.exe movecontent \\networkshare.fq.dn\sharename C:\movecontent.log

6) Server #1 - Open IIS and navigate to the WSUS Administration Site and the Content Directory. Edit the "basic settings" to point to the network share (if not already done) and edit the "connect as" account to the wsususer account. Run a test to make sure permissions are correct.

7) Server #1 is now "done". I recommend restarting WSUS services and watch the event log for any automatic health alarms that pop up.

8) Repeat steps 3-4 on server #2. The WSUSutil on Windows 2012 R2 will auto detect the exsting database and use it. It appears older versions of WSUS needed an extra flag set (see TechNet article I linked above)

9) On Server #2, we will not run the movecontent utility, we will simply edit the ContenDir registry key to tell WSUS to store updates on the network share. This key is located here:

HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup

10) On Server #2, repeat steps 6-7

11) Install SUP role on server #1, watch the WCM.log for any errors in configuring it. If all good, install SUP role on server #2. Now SYNC!!!

AIA-Enabled Certificate Chains

UPDATE: Cisco has written a very similar, more spelled out version of this blog entry, check it out!
http://blogs.cisco.com/security/where-is-my-intermediate-tls-certificate

Have you ever wondered why your nice publicly-signed certificate displays just fine on your workstation but your mobile device shows a certificate error?

First, in review, all of your browsers trust an authority such as Verisign, so they have the Verisign Root in their trusted store. In the case of www.cisco.com's certificate, its authority chain looks like so:



In order to fully trust the www.cisco.com certificate, your browser must not only trust its built-in root (Baltimore CyberTrust Root), but the Intermediate certificate in-between. Your server should be configured to send all certificates in the chain to every HTTPS client.

If not presented by the server, most desktop browsers use AIA to dynamically download the Intermediate certificate, using the www.cisco.com certificate's AIA field seen here:




If AIA works, no certificate error appears, because your desktop browser was able to complete the chain dynamically.

Mobile browsers, however, do not use the AIA extension. This is due to bandwidth/overhead of querying other websites to find the upstream Intermediate CAs. Desktops can handle this query process seamlessly, mobile browsers simply do not.

My recommendation is to send the full chain to everyone. This ensures no errors for mobile devices, and theoretically quicker load times because this AIA parsing does not need to be processed by any browsers. Inserting the Intermediate certificate in your webserver's CA configuration is the way to include this. Review your apache/IIS/other documentation on how to do this.

You can test your certificate chain with OpenSSL using the following command:
openssl s_client -showcerts -connect host.domain.tld:443

Everything is 100% right if you see the following at the bottom:
Verify return code: 0 (ok)