1

I have created a SCOM inbound connector based on the example code from How to Create Inbound Connectors. I run the code and my objects appear in operations manager as expected.

I cannot find any guidance as to how to get my discovery executable to get automatically called - ideally it would be run just like a "Discovery" snippet in the management pack. Another option I thought of would be a Agent Task but I'm not sure that can be scheduled. A third option would just be to install the code as a service completely outside of the management pack.

Is there a best practices on how to execute / schedule the execution of a custom inbound connector?

Reza Aghaei
  • 120,393
  • 18
  • 203
  • 398
bpkbpk
  • 11
  • 1

2 Answers2

0

Inbound connector lifecycle and frequency needs to be managed by the developer.

What I follow is:

  1. Create a connector GUID during product install, persist it
  2. When you product (being monitored) is launched, create the connector, create a Timer that is called every X mins. If its a long running server then the code can tag along the server code. Otherwise, you will need to create a windows service to host the timer+connector code in it. On product launch, just start this service.
  3. When product is uninstalled, unregister and cleanup the connector.

This allows much more relaxed reporting say 30mins or 1hr or even dynamic frequency during peak hour monitoring requirements.

Monitors/Alerts in management pack can then be a bit more aggressive in terms of frequencies.

Rohan
  • 428
  • 5
  • 10
0

If you would like to coupe your discovery/connector push workflow with SCOM, just wrap it as a SCOM rule.

Advantages would be:

  1. It's scheduled on a regular basis.
  2. You can return a property bag with discovery process state -- so if there is an exception in your process, then SCOM raises an alert.
  3. It's stored in SCOM as an MP, so won't get lost, like if it is a Windows Service on another server.

So, you need to write an Probe Action in C#. The best way to do that is to use an MS example. Then compile it to a class library, link to an MP, wrap as Probe Action and make a rule inside the MP.

NB:

  • Use only .NET 3.5 and below as target platform

  • Use special compiler options to improve SDK call performance.

    // To make SCOM SDK calls fast [assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)] [assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)] [assembly: CompilationRelaxations(CompilationRelaxations.NoStringInterning)] [assembly: SecurityPermission(SecurityAction.RequestMinimum, SkipVerification = true)] [assembly: PermissionSet(SecurityAction.RequestMinimum, Name = "Execution")] [assembly: PermissionSet(SecurityAction.RequestRefuse, Unrestricted = false)] [module: UnverifiableCode] [assembly: CLSCompliant(false)]

Max
  • 751
  • 6
  • 10