Replication FAQ

Article:HOWTO36974  |  Created: 2010-12-21  |  Updated: 2013-07-29  |  Article URL
Article Type
How To


Replication FAQ 

Creating a hierarchy adds a tremendous amount of complexity to the process. There are also a lot of misconceptions regarding what hierarchy is and what it can do.  A hierarchy allows for scaling with a central management structure from the top down.

The decision to move to hierarchy should be based upon the number of nodes reporting to a single NS and whether performance is acceptable. Maintaining a single NS, if possible, is a better solution than moving to hierarchy due to the complexity and increased administrative overhead.

For other articles regarding Hierarchy/Replication, see HOWTO42291 "Hierarchy and Replication"

 •       Can you enable Hierarchy at any time?  

Basically if you already have a system in place can you break out into Hierarchy and start adding Child Ns’s?For a hierarchy to be created, each node in the hierarchy must have an off box site server with package services enabled in the same site as a the SMP. If this is configured, then you can add child and/or parent nodes.


•       Would it be better to split off two separate Hierarchies and of a master that isn't used except for Global policies?  Is it possible to make our current NS server a Child NS and would that be best practice?  This way we would have one Clean master with Two child NS’s. 


Normally, you want client facing SMPs to be your child SMPs with the parent SMP being the source for management, reporting and Asset. If you currently have an SMP that is child facing, I would definitely make it a child to another non-client facing SMP. 


Clients will need to be configured between the child SMPs. Whether you decide to organize these based upon organizational groups or some other way is up to you. 


•       Can you use the same SQL instance on the Database server for multiple NS’s or child NS’s?

With 32-bit SQL we required that each database be in its own instance. Even with the performance benefit of 64 bit I would still recommend creating different instances for each database. The SMP utilizes the TEMP database heavily and if you have all databases using the same instances then all of the databases will be competing for use of the TEMP database.

If your SQL box is beefy and running 64-bit, I would use the same server but make sure each database is configured in its own instance. Each instance will therefore have its own TEMP db. 


•       What global policies can you push from the master NS server?   For instance can you set patch policies globally from the master NS and replicate down. 

Items replicated down and resources replicate up by default. Policies are considered at item and they replicate down along with any dependencies.  So yes, you can create the policies on the parent and they will replicate down to each of the child SMPs.  

As an FYI, replicated items are by flagged as read-only. Once an item has replicated, changes need to be made at the parent.  

Patch policies do replicate down. Their implementation is rather complex in my opinion. The child SMPS must replicate their languages up. The parent replicates the policy configurations down based upon the languages. PMImport is triggered on each child SMP. There is a lot of synchronization that has to occur but it seems to work well.


•       Do Software packages replicate down to the Child  NS’s? 

The XML for the packages replicate down to the child SMPs. The actual files do NOT. Ownership of these replicated packages is maintained by the parent. Package Servers on the child make a packageinfo request to their NS and are redirected to the parent. The parent will then hand off codebases to its offsite package server where the package should be ready. The offsite package server on the child then downloads the files from the offsite package server on the parent.


 •       How long does Replication take on average? 

That varies on the size of the database, the amount of the data and the hardware capabilities. A complete replication can take hours (4-8). A differential may take a couple of hours.  

We recommend NOT using “complete” replication because of the burden it is on the network and servers. A differential will only replicate those items that are necessary and does so in a much more efficient way. 


•       What can’t you replicate down to the Child NS?

The general rule is that resources replicate up and items replicate down. Each solution determines its replication process. Some solutions are not replicable. Asset is one of them. Items (policies, packages, filters, targets, etc.) will replicate down. Computers, Subnets, Files, replicate up.

 You can configure replication rules to replicate resources down but to have resources replicate in both directions is unsupported.  

There are a couple of other scenarios where resources are “relocated up” to the parent and then replicated back down. An example is subnet replication. Subnets are created by basic inventory when agents check into their client facing SMPs via Inv_Aex_AC_TCP_IP data. This data is “relocated up” meaning that each subnet resource will only replicate up once and once it does, the ownership for the subnet is changed to the parent. Subnet assignments to sites are then made on the parent. Subnet and Site data are then replicated back down to all child SMPs.  

Organizations views and groups, security roles, permissions and privileges also replicate down.   

If AD import is used at the parent, the organizational structure replicates down but the scope membership does not because it is based upon resource data (resources should only replicate up). Connector rules must be used to import the dataclass data for the computers down to the child SMPs without also replicating the resources down.  

Organizational views and groups created manually on the parent replicates down as well as its scope membership since scope membership for this process is maintain in the scopemembership table. However, if organization structure is managed from the parent, it must always be managed from the parent because changes made directly to the child SMPs will be overwritten by what exists on the parent when replication occurs.


 •       Do all the servers need to be at the same patch level as far as CMS goes? 

Yes.   The process for upgrading servers is to disable replication on all servers, upgrade the child SMPs and then the upgrade the parent. Once the upgrade has completed, reenable replication.


 •       What are the top caveats or Gotcha’s Hierarchy? 

Hierarchy is not a synchronization process between servers. We do not track the deletion of resources between the child and the parent but only with certain resource types. This list will increase with 7.5.  

Security has its own way of replicating. 

Security is NOT included in the hash calculation of an item so there isn’t any way to know whether the security of an item on the parent matches that of the child. If the permission replication process fails, there isn’t any way for the NS to verify and report on this.  This has much improved in 7.1 however since roles are now considered items and permissions are included in the XML of an item. So if the item changes, its permissions are also replicated.  

Scopemembership is confusing. There is a process that must be followed if creating the organization structure manually or via AD import. There is a KB for this.  

Application metering reporting currently doesn’t work correctly. A process must be followed to replicate certain dataclass data up to the parent in order for metering reporting to work. There is a KB for this. 

Replication is administratively intense. It will require a basic knowledge of how replication works. Replication jobs can and do fail for numerous reasons which may require manual intervention to clean up these hung jobs and orphaned data. 

Tasks execution from the parent down to targets on the child SMPs are unidirectional.  Tasks will replicate down to the child SMPs but schedules created on the parent execute on the parent. The parent will send down replication jobs down to the child SMPs for those clients that are in the task’s target. The tasks will run on the agents in the target but there isn’t any reporting back up to the parent to indicate if the task ran successfully. Nothing will be reported back to the child SMP either. Tasks can be created on the parent but should be scheduled and executed on the child SMPs for accurate reporting. 


•       Can you report on everything from the Master NS? 

No. Not everything. The example above with tasks is an example where the task execution is not reported back up. Built in reporting is not very robust when it comes to reporting across the hierarchy. The reason is that in order to report on data across all servers, either all of the data for all servers must exists in one location OR linkedservers must be used to allow for the pulling of data from each database. Since we don't know what each customer’s hierarchy looks like it’s impossible to have canned reports to accomplish this. IT Analytics may help bridge this as it creates linked servers and pulls the data into a central location.

There is also a KB for creating reporting for package servers across all SMPs. This process could be used as an example for creating other reports. The KB is HOWTO83775. 

The Patch data isn’t replicated up. Instead the reports on the parent open up on each of the child SMPS. 

With 7.x you can replicate event data up though we don’t recommend it.


 •       Can you replicate Tasks or image jobs? 

As mentioned above, you can replicate tasks, however; schedules should be configured and ran on the child SMP for accurate reporting. Policies and their schedules replicate down and run on the child SMPs.   

Each solution is responsible for their own replication implementation. I do know that the DS team recommends NOT using hierarchy for pushing images. The recommendation is to configure and use imaging specifically from the child SMPs


 •       Does the deploy anywhere driver database replicate out?

I believe so.


 •        Why does it take up to 3 days for some items to replicate down the Hierarchy?

Some items have many pieces that need to be replicated, if any portion is not fully ready when the first replication runs it will not be fully functional on the child servers until the next replication schedule has completed. 

One of the most common items are packages, if they have not downloaded to the site server in the same site as the SMP server and returned the codebases when the first replication runs this situation will occur.


 •      Why does the Hierarchy topology page show High alert status for recent replications? 

The data used to show the latest alert status includes failures that occurred for items that are not replicable and items that did not exist for valid reasons.  This can skew the count in a large way.  Run other reports to verify replication status rather than relying on the one on the Hierarchy topology page.

 •      Why do my Hierarchy jobs show multiple runs and can I clear them up?

Follow the KB for replication cleanup.  KB: TECH141847

 •      What is the default timeout for a replication job?

48 hours.

 •      How many replication jobs can run at any given time on a server? 



 •       Is it recommended to run a complete replication periodically? 

Only schedule a complete replication job as needed, such as when a network failure has occurred during a differential, or some other replication failure occurs, or as guided by support. The differential replication is much more efficient without the performance hit to the servers.

 •      Can I set a Standalone Replication rule to do a complete replication?

No. Standalone Replication rules always run in differential mode.

 •      When I right-click a folder and select Hierarchy/Replicate Now, will the replication run as Complete or Differential?


 •      When I right-click a Node in the Hierarchy Topology and select Replicate To, will the replication run as Complete or Differential?


 •      What are the concerns about setting the Configuration and Management Items to "Custom"?

We do not recommend that the Configuration and Management Items "Custom" setting be used due to hidden items that can't be selected and the volume of items that would need to be selected to make a custom process work. Customers may find that items they expect to replicate don't because of the "custom" setting.

The recommended setting is "All". Selecting "All" will replicate only those items that need to be replicated during a differential.


Article URL

Terms of use for this information are found in Legal Notices