We’ve all been there – you’ve just added a new role to a server, installed a new component or got around to updating an expired licence, and now you’ve got to sit there and wait until the next discovery cycle occurs (potentially up to 24 hours in some cases).

However, Operations Manager 2012 includes a nice little Agent task you can run on a health service to manually trigger a discovery attempt! I haven’t found much documentation for the task or the module (it’s not composite, and I haven’t yet deconstructed it) but I’ve used it a couple of times now and it always works a treat!

Disclaimer: I don’t know exactly how this task interacts with discoveries that don’t feature Probe modules expecting a trigger item somewhere in their cooked down chain. If your Discovery is based on the presence of a Windows event, this may not function as expected. Discoveries based on schedules (normally via System.Discovery.Scheduler) should function fine.

The high level steps are:

Locate the “Trigger On Demand Discovery Task” for the health service you need to run the discovery from.

Find the DiscoveryId so that SCOM knows which discovery to run.

Find the TargetInstanceId so SCOM knows which specific object the discovery should run for.

Run the task, overriding with the appropriate IDs.

Run the Task against the appropriate Health Service

So, how do I run this task? Well you’ll find it targeted at health Services, so the Agent Health State or Management Servers State views under the Operations Manager folder will do the trick.

Select the Agent/Management server that you want the discovery to be triggered on (make sure you select the state view on the right and not the “from health service watcher” items) and you should see the task show up in the task pane on the far right.

Don’t run it yet though, because now comes the only tricky part – you MUST specify which discovery the agent should trigger, and which target instance that discovery should be run for. These have to be specified as the internal GUID that SCOM assigns to entities. What’s the best way to retrieve that you ask? Powershell of course!

DiscoveryId

In order to get your DiscoveryId you can use the Get-ScomDiscovery cmdlet with the -Displayname parameter, or if you know it the –Name parameter. The Displayname is what displays in the SCOM console in the “Object Discoveries” section of the Authoring pane. The Name is whatever name the MP Author gave the discovery when writing the management pack.

Either way, once you’ve run that cmdlet and found your discovery you want the guid displayed in the Id property. It will look something along the lines of: 94d82cfb-2644-97ab-b42c-f0438d77b90a

TargetInstanceId

Now to get your TargetInstanceId guid we need to find the unique ID that’s been assigned to the particular instance of the object that your discovery targets. Most times this is probably going to be a windows computer or server object. In order to find this we can use the Get-ScomClass and Get-ScomClassInstance cmdlets. If you are comfortable getting this, skip head to the next section (PROTip: The class id is available in the .Target.Id property of the discovery object you returned above).

First we need to get the Class that the discovery targets . In the authoring pane of the SCOM console where you got the discovery name from, note down the value in the “Target” column.

Next, load up the Discovered Inventory view in the Monitoring Pane, and change the Target Type (via the task pane on the right) to your class you got from the Discovery target column. Note down the displayname of the object that you want to run the discovery against (for example, a particular computer name). Finally, run the below command

This will display another guid, which is your TargetInstanceId. Almost there!

Override and Run the Task

Head back to the Agent/Management server view, select your health service that you want the discovery to run on, and click on the task. You’ll see the following screen:

Hit the Override button, and in the “New Value” column enter in your TargetInstanceId and DiscoveryId guids that you found in the previous steps. Hit Override, and then back on the run task screen click Run. The discovery request will launch and should complete fairly quickly (faster than your discovery will at any rate. Task completion doesn’t mean the discovery has finished, merely that the trigger request was sent successfully). If you see any errors listed in the task results pane, then it’s likely you’ve got the wrong guid somewhere.

And that’s it. Hopefully after a short amount of time your class objects should start to appear in SCOM. If your discovery finds the root of a hierarchy of objects, you don’t need to submit a trigger for each subsequent object – those will be discovered immediately as normal once your root object is discovered.

Hope that helps you having to wait around for your latest installed component to show up in SCOM, and get back to monitoring!