We’ve Moved!

Hi all,

I wanted to provide an update on where we’ve been. Back in February of 2014 Jesse and I, along with William Bracken & an additional partner, started a new consulting company. We focus on client and datacenter automation, primarily through System Center.  You can find our new blog posts here. Here’s a bit of information on the company.


The Model Way

Henry Ford’s creation of the Ford Model T car in 1908 was undoubtedly brilliant, but it was not what made him a pioneer. Ford’s true vision was brought to life when he fine-tuned the assembly line mode of production and enacted a method of keeping the best workers loyal to his company.

You see, he didn’t invent the product. He perfected the process. And he honored the people who worked hard to make it possible. In that, he revolutionized an industry.

At Model, we are inspired by the advancements we’ve seen in businesses through Microsoft automation technology.

Automation fascinates us, and helping businesses achieve their objectives through automation is our professional reason for being. Our team has invested years of our lives studying and perfecting the art of automation, and we are excited to share our expertise to help you see the breakthroughs for your business.

Just as equally, Model is passionate about cultivating a strong IT community. We know that our brand is a reflection of our people, and therefore we are committed to cultivating an empowered, champion technologist culture. And, beyond the Model team, we are invested in contributing to the growth of Microsoft technologies and the world of innovators who support it.




Troubleshooting APM SCOM 2012

Recently I had the opportunity to troubleshoot SCOM at a client, here’s my recent experience with APM.

My client had two web servers, not joined to the domain. Both of these servers hosted an application that we wanted to instrument with APM. 01 wasn’t working with APM but was working with other OpsMgr alerts and rules. 02 was working for APM and for other alerts and rules.

  • These servers are not domain joined (verified the runas account, cert thumbprint, communication port, etc…)
  • The two servers are exact clones of one another ( same serialnumber listed in SCOM, not ideal but unsure if this is causing the issue or not)
  • OpsMgr agent installs on both 02 – gets the instrumentation 01 – does not
  • Both servers show the same discovery information from the IIS MP
  • Once I setup the .NET template, here’s a list of high-level troubleshooting steps
    • Created a custom group containing only web01 and scoped a new .NET monitor to the group
    • On the .net template, I removed the group and flushed the health services
    • Tried putting Web01 in maintenance mode for 10 min
    • Verified discovered inventory on the health service
    • Viewed the failed / applied rules & monitors (no failures)
    • setup a new .NET template from scratch
    • Notta

The entire time, I’m closely watching the event logs on Web01 for any signs. Come to find out there was a bug in 2012 SP1 where, if the discovery of the server name shows up in lowercase and in uppercase throughout the OpsMgr Console it may cause APM some heartburn. So I upgraded to 2012 SP1 UR 4, which contains the fix – Read this here’s the link to UR4

Unfortunately, the issue wasn’t resolved, so I went through the steps once again with no positive result. Next I enabled Verbose tracing and created the issue again, stopped verbose tracing, and went through the logs.  Decided to reapply the UR4 server update, ran LODCTR /R on Web01, waited 5 minutes, and all was fixed.

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.