SUP Sync Fail in SCCM 2012 SP1 (or Higher)

I recently had to reinstall WSUS and the SUP role on my Primary Site server (stop asking me why…I’m not telling). It had been so long since I’ve done this that I TOTALLY forgot about a fun little “gotcha”.

After installing the WSUS server role and adding the SUP role to my SCCM server, I went to the typical logs (WCM.log, WSYNCMGR.log, WSUSCtr.log) with the idea that I would sit back, relax and enjoy all of the fruit that my left-clicking had to bare.

“Sync failed: WSUS update source not found on site”


So, a little detail that I forgot is the fact that

WSUS 3.0 SP2 in conjunction with SCCM 2012 SP1 requires a patch (with an optional patch as well):

Applying KB2720211 will alleviate the errors you see when WSUS attempts to sync with the interwebs by implementing a new certificate management process. KB2734608 actually includes KB2720211, so you can simply apply that hotfix if you so desire. This KB also modifies the SUP DB schema to support SHA256 hashes, which is necessary for patching Windows 8 and Server 2012 machines.

Happy updating!

Remotely Activate Microsoft Office

Oh, man! I have a bunch of Office 2010 installations that are showing as “not activated” and my help desk queue is building exponentially. This is going to be a horrible d…WAIT! I am SMART and use SCCM for all comprehensive distributions!

I am going to do something different, here. I am going to give you the scripts and switches to run and leave it up to you to determine the best way to deploy this to end-user workstations that are showing this problem. Bonus points if you can figure out a way to determine who has a copy of Office 2010 that is not activated.

In order to input the Office 2010 key, run (starting in “c:\program files\microsoft office\office14” [or “program files (x86)” for 32-bit installs on a 64-bit OS]):

cscript ospp.vbs /inpkey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

Then, to activate:

cscript ospp.vbs /act

Change Incident Auto-Increment Value in SCSM 2012 SP1

You would never want to change the auto-incrementing value range in SCSM 2012…would you? Well, I came across an instance where I needed to (which I will explain in detail in future blog posts).

Essentially, I was migrating from a previous SCSM 2012 SP1 environment (that was originally migrated from 2010) to a new SCSM 2012 SP1 environment. However, I needed the Incident Request (IR) reporting to be available from the old environment. Therefore, I wanted to ensure that our IR values did not duplicate those in the past.

In the ServiceManager database, a table called AutoIncrementAvailableRange stores the next available number for the classes. This is the table that we need to alter in order to choose a defined range.

First, we need to join some tables by running the following query:







from ManagedType as MT, ManagedTypeProperty as MTP, AutoIncrementAvailableRange as AIAR

where MT.ManagedTypeId = AIAR.ManagedTypeId and MTP.ManagedTypePropertyId = AIAR.ManagedTypePropertyId

You will now have a list that looks like this:


Now (the scary part), we are ready to change the WorkItem ID. Do NOT run this unless you are ready!

For example, if we want to change the first available value to 40000, note the ManagedTypeId and the ManagedTypePropertyID for System.WorkItem and run the following:

update AutoIncrementAvailableRange

set FirstAvailableValue = 40000

where ManagedTypeId = ‘F59821E2-0364-ED2C-19E3-752EFBB1ECE9’ and ManagedTypePropertyId = ‘28B1C58F-AEFA-A449-7496-4805186BD94F’

Now, your next IR number should be IR40001.


I thought this was confusing, so I figured if it helps one person it is worth posting!

In order to do a WMI query for items that are NOT of a certain definition (for example, machines models that do not begin with “M”), you may think that you would include “NOT LIKE” in your query. The truth is, your query should look like this:

SELECT * FROM Win32_ComputerSystemProduct WHERE NOT Version LIKE “%M%”