Part 3.b: Configuring WSUS and target computers to use Local Update Publisher
“I’m Winston Wolfe. I solve problems.”
Work in progress.
UPDATED January 2nd, 2012:I’ve created an MSI using WIWW, following a how to on OCS’s site.
In Part 3.a, I covered installing and configured WSUS to target Windows hosts with updates.
In part 2.c, I originally had diverted the configuration of OSSIM until the package deployment mechanisms were completed, since we will be leveraging Local Update Publisher to build then WSUS to deploy the OCS-ng client.
A walk through of Local Update Publisher is covered thoroughly in the Local Update Publisher wiki, and I strongly suggest you look there. For the sake of continuity, I will attempt to streamline the docs and offload some decision making to myself, documenting my procedure here.
Download and install Local Update Publisher:
- Download and install the latest version of Local Update Publisher on a machine with the WSUS admin console.
- You must install a hotfix for WSUS 3.0 SP2 that will solve a problem when using .NET Framework 4.0 and writing custom updates and an error that metadata only updates cannot be expired or revised.
- Run Local Update Publisher, and enter the connection info:
Servers: SERVERNAME Name: SERVERNAME Port: 8530
Manage the certificate used to sign packages:
- Start Local Update Publisher
- You will be prompted to generate or import a certificate to be used for package signing. Click Yes
- From here either you can choose to create a self-signed certificate or import a existing key pair that’s been issued to your from a CA. (I prefer calling it a “key pair” so that it raises understanding that the “certificate” is actually a public key and a private key…)
Using a self-signed certificate:
I had posted a (sort of babbling) question to the security stackexchange, and received an informative answer. It seems that using self-signed certificates is a generally acceptable security practice. This is something I always thought was wrong, and is actually a sort of revolutionary concept.
To use a self-signed certificate:
You must distribute this public key to your targeted clients to be stored in their Trusted Root Certification Authorities. Microsoft covers this in detail, but I will also cover it here.
- Click Create Certificate to generate a self-signed, 2048 bit long RSA key.
- In the Certificate Information window, click Export Certificate> enter a location for the file, and Local Update Publisher will export the public key of the key pair to a DER encoded binary X509 certificate contained in the specified file.
- Start>run> gpmc.msc
- Navigate to the “WSUS and BITS” policy you created in Part 3.a> right click> Edit
- In the GPO tree navigate to: Computer…\[policies]\Administrative Templates\Windows Components\Windows Update\ and make sure the Allow signed content from intranet Microsoft update service location is enabled.
- In the GPO tree navigate to: Computer…\[policies]\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certificate Authorities, then go to Action menu> Import, select the public key .CER file exported earlier, and Next it.
- In the GPO tree navigate to: Computer…\[policies]\Windows Settings\Security Settings\Public Key Policies\Trusted Publishers, then go to Action menu> Import, select the public key .CER file exported earlier, and Next it.
If you’d like to use a CA issued certificate:
You may have a CA in your organization and may be able to submit a certificate request. Within the request note the OID for code signing, 188.8.131.52.184.108.40.206.3, as this is the key function required for WSUS update signing. I suggest requesting a key with at least a 3072 bit key length.
Local Update Publisher is documented to look at the Local Computer\WSUS certificate store to find a usable certificate, but I didn’t have luck with it finding any existing key pair in that path, so I suggest you use the Local Update Publisher UI to import the key pair issued by the CA.
Deleting stored key pairs:
If you wish to delete the key pair generated by Local Update Publisher, you can do so through the use of mmc.exe’s Certificate “snap-in”:
- start> run> mmc
- File> Add/Remove Snap-in> Click Add
- Select the “Certificates” snap-in, and click Add.
- Bullet “Computer account”> Next> bullet Local Computer> Finish.
- Close> OK
- Navigate: Certificates (Local Computer)\WSUS
- Any existing certificates will be included below in a container called Certificates.
- Delete the key.
Install the public key on the Local Update Publisher workstation:
Before continuing, you must add the public key generated in the Manage the certificate used to sign packages section above to the Computer\Trusted Root Certificate Authorities and the Computer\Trusted Publisher stores on the machine where you will be publishing any updates to WSUS through Local Update Publisher (also make sure the latest WSUS KB is installed as noted in “Download and install Local Update Publisher”, and that the key pair/certificate used is at least 2048 bits). IF you do not do these things, you will get an error when attempting to publish updates in %programfiles%\Update Services\LogFiles\SoftwareDistribution.log:
Invalid Operation Exception: The package could not be published. Verification of file signature failed for file: \\SERVER\UpdateServicesPackages\[PackageID]\[InstallableItem ID].cab
Create a new package for deployment:
This is not really a simple task, and is covered in detail on the LUP wiki.
For this example, we actually won’t be deploying an update, but instead a new package, the OCS-ng Windows client, in reference to part 2.c. There is a walkthrough of generating an MSI for OCS-ng’s agent within the project’s wiki; however, I will summarize here the process here.
- Go to the OCS-ng agent download page and download the latest Windows Agent installer (as of December 31, 2012 v.2.0.5 is available).