How replicating computers works within an Hierarchy?
search cancel

How replicating computers works within an Hierarchy?

book

Article ID: 180295

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

How replicating computers works within an Hierarchy?

Environment

ITMS 7.x, 8.x

Resolution

Replicating Computers


Computers and associated data are replicated using the standard web service container model.
Computer replication rules can either be created based on a resource type selection of ‘Computer’ and ‘Virtual Machine’ , or a  Resource target can be selected, which would contain a selected group of computers or virtual machines to be replicated.
 
To check if a computer resource has been successfully replicated via the database you can query the below tables:
·          Computer Resource Type - ‘RM_ResourceComputer’
·          Virtual machine Type – ‘RM_ResourceVirtual_Computer’
·          Both Computer and Virtual machines - ‘vResourceItem’
·          For verifying the data associated with the resource has been sent successfully, you should query the data class tables selected in the resource replication rule e.g. The default NS Core computer rule sends the ‘Inv_AeX_AC_Indentification’ data class. Query this table at the destination NS for the _ResourceGuid of the replicated resource.
 
All replicated computers and virtual machines, whether they are managed or unmanaged will appear in the default Organisational Groups at the destination NS.
Replicated computers and virtual machines will only appear inside relative Filters at the destination NS if the resource is managed by the source NS, i.e If the altiris agent is installed.
 
How to know when data for a resource should be resent, and when it should not be resent:
 
Query the dataclass table to obtain the GUID of the dataclass you wish to investigate. This GUID matches up with that of the ClassGuid column in the ForwardingHistorySummary table on the source server.
Include in the query the GUID of the resource you wish to search on.
See below for an example query where I am trying to find out the last time data class AeX_AC_Machine_Usagewas sent for a specifc resource.
 
select * from ForwardingHistorySummary
where ClassGuid = '7FEA91B2-41EA-4CCB-ADAF-185F3957E739'
and ResourceGuid = 'B930288D-8F59-4C93-91A2-512B7FB66BA1'
 
In the results there is a column called ‘ForwardDate’. This is the last time the source server replicated this dataclass for the specified resource.
You then want to compare this forward date against the last time the data class changed for the resource.
To find this out, query the ResourceUpdateSummay table with the appropriate resource GUID and dataclass GUID.
The column ‘DataLastChangedDate’ will show the time the data class was last updated for a particular resource.
If the date inside the ‘DataLastChangedDate’ column is greater than the ‘ForwardDate’ within the ForwardingHistorySummary table, then the data should be sent at the next replication, if not, than the data should not be sent when the resource replication rule next runs.
If the ‘DataLastChangedDate’ is set to NULL, this means the resource has never changed and the created date applies instead.
 
Dataclass Summary Information -
When creating a computer resource replication rule there is a new dataclass available for selection called ‘AeX AC Client Agent Summary
This data class contains summary information for the standard basic inventory dataclass ‘AeX AC Client Agent’.
The associated database table ‘Inv_AeX_AC_Client_Agent_Summary’ is populated when the NS Daily Shared schedule fires.
The purpose of sending the summary data is to provide the user at the destination NS with a consolidated report of the count of Altiris Agents reporting to each NS within the hierarchy. The user can drilldown on a selected computers which will launch a remote drilldown to the ‘Altiris Agent Summary Details’ report which exists on the NS that the selected computer reports to.