The case of the unexplained – ConfigMgr 1606: Office365 inventory data doesn’t replicate to CAS.


Hi Folks,

I happen to document this enough working on an issue and hence posting this out to revive my unexplained series that was dormant for quite a while. 🙂

Issue:

We introduced this new class in ConfigMgr 1606, I believe Office365PROPlusConfigurations as shown below.

officeblog

 

 

Now the issue is we have the data being collected in the respective table Office365ProPlusConfigurations_DATA on the primaries but the data doesn’t go to CAS.

 

Assessment:

The very first thing that comes to mind in such cases was to check if the table is being replicated at all first. Just to clear, any table that is replicated has to be a part of the ArticleData table. So ran,

select * from ArticleData where articlename like ‘Office365ProPlusConfigurations_DATA’

 

DANG! No rows returned. Thought of checking if this was by design, In the lab, I do get the data and the table is a part of replication group.

 

So there is something happening here where the Table is not even considered to be part of the replication group.

Frankly, I was at loss as to how to drill this down, The groups definitely need to be created by dataldr for sure that’s what I knew.

Checked the Dataldr.log on the CAS and saw these lines repeating.

//

There are 4 pending remote adds, 0 pending remote drops.      SMS_INVENTORY_DATA_LOADER     10/26/2016 11:15:35 PM  5784 (0x1698)

Looking for inventory schema changes…   SMS_INVENTORY_DATA_LOADER      10/26/2016 11:15:35 PM  5784 (0x1698)

…no inventory schema changes found.     SMS_INVENTORY_DATA_LOADER      10/26/2016 11:15:35 PM  5784 (0x1698)

//

Frankly, I couldn’t make much out of this, so digged thru the source as to what this entails.

Upon digging, it became clear that before setting up the replication group for an inventory table the CAS waits for the primaries to extend the schema.

So until the primaries have extended the schema the CAS wont setup the replication for the coming groups.

Now, CAS tracks the same from a table called RemoteInvSchema. This is a site data table so when the schema is extended on the primaries, they reach the CAS and that’s how CAS knows the schema is extended at primary.

So ran this at CAS:

select sitenumber, count(*) from RemoteInvSchema

group by(sitenumber)

 

Output:

              

SiteNumber Count
1 2309
2 2311
3 2309

     

 

Dang! So site number 1 and 3 are off by two records each. That makes it 4 for what the CAS is shouting for.

I ran the queries on the primary itself and it was 2311. So it was just that the data somehow never replicated up for these two sites.

The data records that was OFF was

MICROSOFT|MBAM_POLICY|1.0  UserExemptionDate

MICROSOFT|MDM_RemoteFind|1.0           Latitude

 

The table RemoteInvSchema is a part of Operational_Data so reiniting them from the CAS should have helped. But for two records reiniting a big group was something Cx was not willing.

Anyways even updating the records on Primary should do the trick via DRS. We ran the below on all primaries

//

UPDATE remoteinvschema SET AttributeName=AttributeName WHERE GroupClass IN (‘MICROSOFT|MBAM_POLICY|1.0′,’MICROSOFT|MDM_RemoteFind|1.0’)

//

* Make sure we have a backup of the DB before we run any delete query. Also, do not delete anything without the recommendation from the Microsoft Premier support. 

Sure enuf now the records from the query was 2311 for all sites and the dataldr kicked for creating the replication groups for the inventory tables.

Summary:

The table RemoteInvSchema is used in CAS to coordinate/wait for all primary sites to finish extending schema before the CAS extends schema.

The extension data for Office365 does not show up because CAS is ‘waiting’ for the primaries to finish schema extension.

While the primaries already finished schema extension, due to replication on this table not correct, the CAS still assumes the primaries are not finished yet.

So the fix is actually to fix replication for this table – after which inventory will work.

For fixing replication we used a dummy query that updates the missing records on the Primaries. The update forces resending missing data from Primaries to the CAS and therefore hopefully fixes replication.

Hope this helps !!

~UK

Support Escalation Engineer | Microsoft System Center Configuration Manager

Disclaimer: This posting is provided “AS IS” with no warranties and confers no rights.

Comments (0)

Skip to main content