Discoveries, multihoming and cookdown


We have a few customers that are using multihoming for opsmgr agents. They all complains for slow discovery in the added MG. I’ve been asked about this delay online as well, so I’m going to wrap my answers and give my view of the issue.

The slow discovery in the added MG, from my internal tests, it’s due to cookdown. Cookdown applies to every workflow, discoveries included. So let’s take for example a discovery of your own for Component C, that targets component B and that in turns targets Windows.Computer. Important: you’re discovering the components in both MGs. When you add a new MG to an agent the install process does a very basic discovery and restarts the agent, when the agent is restarted all the non synced discoveries are run. After the restart Windows.Computer is discovered for MG2, this will cause a reload (event 21025) for the specific MG, this in turn forces a download of all the workflows targeted at Windows.Computer. What we expect now is that newly downloaded discoveries (in our example for component B) run. But , since the discovery workflow for component B is already there for MG1 and that it has been run at agent startup after the new MG has been added, cookdown will step in and say “this is the same workflow, with the same signature so I can safely wait for the next scheduled time”. If the scheduling is 24 hours you must wait 24 hours (actually a little less) for component B to appear in MG2. And then the same process applies for Component C and so on.

So what you can do to speed up the discovery process for newly added MGs? 

First, to check if this is really the issue you’re facing, restart the agent on one sample system and check if discovery data flows in, restarting the agent forces all non time synced discoveries to run. Between one restarts and another give the agent enough time (5’ to 10’ typically)  to complete the discovery cycle.

Second, if you’re the MP author you should use the System.Discovery.Scheduler instead of the System.Scheduler datasource. This has been adopted by the latest OS MPs, so

Third, install the latest OS MPs at least version 6.0.6667.0.

For the curious of you, the difference between System.Scheduler and System.Discovery.Scheduler is only in the signature, in the latter the target managed entity Id has been added so it won’t be cooked down (the signature will always be different)

     <DataSourceModuleType ID="System.Scheduler" Accessibility="Public" Batching="false">

        <Configuration>

          <IncludeSchemaTypes>

            <SchemaType>System.ExpressionEvaluatorSchema</SchemaType>

          </IncludeSchemaTypes>

          <xsd:element name="Scheduler" type="PublicSchedulerType" xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; />

        </Configuration>

        <ModuleImplementation Isolation="Any">

          <Native>

            <ClassID>C3339855-80B3-4c06-B7AB-5C5D97B59A0D</ClassID>

          </Native>

        </ModuleImplementation>

        <OutputType>System.TriggerData</OutputType>

      </DataSourceModuleType>

 

    <DataSourceModuleType ID="System.Discovery.Scheduler" Accessibility="Public" Batching="false">

        <Configuration>

          <IncludeSchemaTypes>

            <SchemaType>System.ExpressionEvaluatorSchema</SchemaType>

          </IncludeSchemaTypes>

          <xsd:element name="Scheduler" type="PublicSchedulerType" xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; />

        </Configuration>

        <ModuleImplementation Isolation="Any">

          <Composite>

            <MemberModules>

           

              <DataSource ID="DS1" TypeID="System.Discovery.Scheduler.Internal">

                <Scheduler>$Config/Scheduler$</Scheduler>

                <ManagedEntityId>$Target/Id$</ManagedEntityId>

                <RuleId>$MPElement$</RuleId>

              </DataSource>

             

            </MemberModules>

            <Composition>

              <Node ID="DS1" />

            </Composition>

          </Composite>

        </ModuleImplementation>

        <OutputType>System.TriggerData</OutputType>

      </DataSourceModuleType>

     

      <DataSourceModuleType ID="System.Discovery.Scheduler.Internal" Accessibility="Internal" Batching="false">

        <Configuration>

          <IncludeSchemaTypes>

            <SchemaType>System.ExpressionEvaluatorSchema</SchemaType>

          </IncludeSchemaTypes>

          <xsd:element name="Scheduler" type="PublicSchedulerType" xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; />

          <xsd:element name="ManagedEntityId" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; />

          <xsd:element name="RuleId" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; />

        </Configuration>

        <ModuleImplementation Isolation="Any">

          <Native>

            <ClassID>C3339855-80B3-4c06-B7AB-5C5D97B59A0D</ClassID>

          </Native>

        </ModuleImplementation>

        <OutputType>System.TriggerData</OutputType>

      </DataSourceModuleType>

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

About these ads
  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 348 other followers

%d bloggers like this: