One of my customers has now had two occasions where they deemed it necessary to purchase a Custom Support Agreement (CSA) from Microsoft to keep a specific version of Windows patched for a short time. As I’ve been able to find NO information about the process of deploying these special patches via SCCM or WSUS I decided to document the experience here.
Note: I legally cannot and thus will not share any of the bits/files.
Step 1: Acquire the files
The first trick is to actually acquire the custom catalog/metadata file and the actual patches. In my case these are delivered by the Microsoft Technical Account Manager (TAM) associated with the legal entity that actually has the agreement. My customer is global and another region owns the CSA, thus I get the patches after they’ve gone through several hands inside the company. This is what the files look like.
Nothing really special on the surface, just a bunch of CAB files.
Step 2: Import the Metadata
If this is the first time dealing with CSA patches, you’ll need to get the TAM to send you the import/insert tool (it goes by a few different names in the documentation including WSUS CSA Insert Tool, WSUS 3.0 SP2 CSA Insert Tool, and WSUS Import Tool). This is what reads the metadata CAB and injects it into the WSUS database.
Once you have the utility, run it with proper command line parameters as shown in the screen shot.
Here is the command line [cc lang=’dos’ line_numbers=’false’]WSUSImportTool.exe “x:\FolderWithMetadata\metadata.cab” “x:\FolderWithPayloadFiles”[/cc]
Notice that I didn’t have the payload files (patch CABs) in the directory I specified on the command line. That’s because the TAM sent me MSU files instead of CABs the first time around. WSUSImportTool.exe can’t handle MSU files, only CABs.
Step 3: Update SCCM SUP Products
If you are running SCCM 2012, you must update the Products in your Software Update Point. For whatever reason, this is not necessary in SCCM 2007 even though the Product is listed. I’m hoping Microsoft will give an explanation for this seeming impossibility.
Step 4: Synchronize SCCM with WSUS
After the metadata is added to the WSUS database, SCCM needs to synchronize just like it does every Patch Tuesday or whatever your schedule is. Here is the before and after.
The WSYNCMGR.log looks pretty normal.
Notice that CSA patches have a title that clearly differentiates them from normal patches.
Step 5: Download the Patches
Now that SCCM knows about the patches it is time to add the binaries to a Software Update Package (SCCM 2007 in this case). There isn’t anything special here except that you can’t download them from the Internet; you’ll have to point them to a local/network path.
All done!
Now the CSA patches can be deployed just like all the others and you can feel safe and secure that the truckload of cash you paid to avoid Service Pack 1 for Windows 7 is worth it! 😉