KNOWN ISSUE: Application metering Reports don't work. Replication isn't replicating necessary data

book

Article ID: 181200

calendar_today

Updated On:

Products

Management Platform (Formerly known as Notification Server)

Issue/Introduction

 

Resolution

There are a couple of replication rules that must run in order for reporting to work correctly on the parent. These are the “Metered File Properties Data Class Data” and “Metering Summary Data Class Data”. The first replicates Inv_Windows_File data and the second Inv_Monthly_Summary data.

The “Metered File Properties Data Class Data” rule requires that the data exist in the Inv_Monthly_Summary or the Inv_Software_Execution tables. It also must exist in the Inv_Windows_File data which is populated by the File Details inventory component.

The “Metered File Properties Data Class Data” rule updates the forwardinghistorysummary table and inserts into the evt_ns_object_replication_status table. The “Metering Summary Data Class Data” rule  inserts into the evt_ns_object_replication_status table. It also updates the forwardinghistorysummary table for the specific computer resource and Monthly Summary dataclass.

The “Metered File Properties Data Class Data” creates a file resource in the RM_ResourceFile table but the “Metering Summary Data Class Data” does not. It creates an entry in  Inv_Monthly_Summary and collectionmembership. Because it doesn’t create a resource, it is able to coexist OK with the other rules that do create a resource.

The “Metered File Properties Data Class Data” is a “relocate up” rule which sets the ownernsguid and the itemnssource data to that of the parent for each replicated file on the child.

When both of these two rules run successfully the data is inserted into the RM_ResourceFile, Inv_Windows_File and Inv_Monthly_Summary and the reports on the parent should return accurate results.

The “Metering Summary Data Class Data” replicates the data in the Inv_Monthly_Summary table. It compares the forwarddate in the forwardinghistorysummary with the modifieddate in the resourceupdatesummary for each computer resource that has Inv_Monthly_Summary data. If the modifieddate is newer than the forwarddate, the data is replicated.

These replication processes show up as a ‘Replication” Category and a “ProcessJob” Sub-Category in an Altiris profiler trace.

There is another replication rule that performs a “relocate up” of file data. This is the "Software key Executable" rule. It also creates the file resource and inserts into the Inv_Software_Key_Executable” table.  The existence of this rule and the “Metering Summary Data Class Data” generates a conflict that causes two issues with replication.

1) If the "Software key Executable" runs first it sets the ownernsguid and itemnssource data to that of the parent. Any other replication processes for the file will fail because the child doesn't think it owns it. By resetting these values back to the child, the data will rereplicate.

 

2)If the "Software key Executable" runs first it creates the file resource on the parent. When the "Metered file properties data class data" runs, the data is ignored because the resource already exists.

 

The relocate up process is a onetime process and must replicate all data classes that perform a relocate up process at the same time.

Solution: A modified filter was provided by Development called “Metered Files”which allows both the "Metered file properties data class data" and "Software key Executable"replication rules to coexist without causing these two issues. Both of these rules MUST be configured to run on the standard schedule. Neither can run on a custom schedule in order for this to work.

 

Import the “Metered Files” filter at Manage – Filters – Software Filters – Agent and Plug-In  Filters on each of the child NSs. This XML has the attribute of “Non-replicable” and so must be imported on each child.

 

This will replace the existing sql in the filter from this:

 

SELECT DISTINCT FileResourceGuid FROM Inv_Monthly_summary

      UNION

SELECT DISTINCT FileResourceGuid FROM dbo.Evt_Application_Start

               

To this:

 

SELECT DISTINCT FileResourceGuid FROM Inv_Monthly_summary

      UNION

SELECT DISTINCT FileResourceGuid FROM dbo.Evt_Application_Start

                UNION

SELECT DISTINCT _ResourceGuid FROM Inv_Software_Key_Executable

A second issue exists when the same file data is replicated up to the parent from a second, third, forth, etc. child NS. The file data is NOT getting merged.

 

Solution:  Once the files have been relocated up, the replication rule “File Resources for key executable files” on the parent is supposed to replicate these files back down to ALL child NSs whether they have the files or not. The file merge will occur at the Child NS if the file already exists.

 

This process preventing this from working is that the target for the “File Resources for key executable files” is built wrong. It does not include files belonging to the inv_monthly_summary data class.

 

Import the Inventoried Files (Down).xml at Manage – Filters – Software Filters – Agent and Plug-In  Filters on the parent NS  .

 

The filter’s sql will change from:

 

SELECT DISTINCT _ResourceGuid FROM dbo.Inv_Software_Execution WHERE IsMetered = 1

               

To this:

 

SELECT DISTINCT _ResourceGuid FROM dbo.Inv_Software_Execution WHERE IsMetered = 1

                UNION

SELECT DISTINCT FileResourceGuid FROM Inv_Monthly_summary

      UNION

SELECT DISTINCT FileResourceGuid FROM dbo.Evt_Application_Start

                UNION

SELECT DISTINCT _ResourceGuid FROM Inv_Software_Key_Executable

 

Below are the complete steps to get Application Metering data to replicate correctly.

 

1.       On each child NS: Import the modified “Metered Files” filter at Manage – Filters – Software Filters – Agent and Plug-In  Filters on each of the child NSs. This XML has the attribute of “Non-replicable” and so must be imported on each child.

 

        Click “Update membership” on the filter to refresh the membership.

 

2.       Both the “Metered Files and Properties Data Class Data” and the “Software Key Executable” replication rules MUST be scheduled to run under the default “Differential” schedule. These are “relocate up” rules and so will run on the child NSs. This can be configured at the parent and replicated down to all child NSs.

 

3.       On each child NS: The ownernsguids for files will have changed to that of the parent NS from previous “relocate up” replication jobs but may not have merged properly leaving the files in a state that they won’t be replicated again along with their respective data classes. These ownernsguids need to be reset so that the process will work with the new filters in place.

 

Run the following SQL query on all Child NSs.

 

update RM_ResourceFile set OwnerNSGuid = (select * from vThisNS)

 

4.       On each child NS: The ItemNSSource table must also be set back to the ID associated with the local server. Run the following query on all Child NSs.

 

update ItemNSSource set OriginNSSourceNSId = 1 where ItemGuid in (select guid from RM_ResourceFile)

 

5.       On each child NS: Clear the ForwardingHistorySummary table for all files so that the replication process will resend the file associated with the Inv_Windows_File and Inv_Software_Key_Executable data classes. Run the following query on all Child NSs.

 

delete from ForwardingHistorySummary where ResourceGuid in (select guid from RM_ResourceFile)

 

6.       On the parent NS: Import the Inventoried Files (Down).xml at Manage – Filters – Software Filters – Agent and Plug-In  Filters on the parent NS. See above for details on this modified filter.

 

        Click “Update membership” on the newly imported modified Inventoried Files (Down).filter to refresh the membership.

 

7.       On all NS servers: Verify that the tr_inv_app_meter_policy trigger is current on all SMP servers. An update to this trigger was applied with Inventory Solution 7.1 Sp2 HF1. You can run sp_helptext tr_inv_app_meter_policy and compare the output with the provided trigger.

 

The change is in the bottom of the trigger. The following two lines are added:

 

DELETE TOP (1) FROM @temp_insert WHERE _ResourceGuid = @FileResourceGuid         

DELETE TOP (1) FROM @temp_delete WHERE _ResourceGuid = @FileResourceGuid  

 

Take note that there are two instances of these queries at the bottom. Without these changes file merging will timeout.


EXEC sp_Inv_Adding_Metering @FileResourceGuid1, @FileResourceGuid     

DELETE TOP (1) FROM @temp_insert WHERE _ResourceGuid = @FileResourceGuid OR _ResourceGuid = @FileResourceGuid1        

DELETE TOP (1) FROM @temp_delete WHERE _ResourceGuid = @FileResourceGuid     

END  

    ELSE

    BEGIN

                DELETE TOP (1) FROM @temp_insert WHERE _ResourceGuid = @FileResourceGuid        

                DELETE TOP (1) FROM @temp_delete WHERE _ResourceGuid = @FileResourceGuid     

    END  

END           

ELSE         

BEGIN         

DELETE TOP (1) FROM @temp_insert WHERE _ResourceGuid = @FileResourceGuid         

DELETE TOP (1) FROM @temp_delete WHERE _ResourceGuid = @FileResourceGuid         

END                             

END                  

END

 

8.    On all NS servers: There is an issue when upgrading from SP1 to SP2 where a foreignkey should have been removed.  See Etrack(2726555) Inventory Solution fails to merge file resources (like during replication) if solution was upgraded from 7.1 sp1 to 7.1 sp2.

 

Run the following query:

 

Select * from item where guid = 'E0C7CB1D-C586-41C0-8A8F-A65275E82BAC'

 

If this returns results run the following two queries.

 

update Item set Attributes = 0 where Guid = 'E0C7CB1D-C586-41C0-8A8F-A65275E82BAC'

insert into ItemToDelete values('E0C7CB1D-C586-41C0-8A8F-A65275E82BAC', GETDATE())

 

        Run the “quarterly” schedule in Windows task scheduler to allow the deletion to complete.

 

9.    Perform a differential replication up from the child NSs.

 

10.    Once this upward differential replication job completes from the child NS(s), run a differential from the parent to each child NS.

 

Etrack  2747178

 

 

 

A permanent fix has been provided in 7.1 SP2 MP1 V6. (See HOWTO81832)

Attachments

files.zip get_app
AM Replication Fix process.doc get_app