The following sections cover the two primary methods of site-to-site replication in ConfigMgr: database replication (handled by DRS) and content replication (or file replication). These replication methods have been the cornerstone of ConfigMgr since the 2012 release.
About Configuration Manager Database Replication
Database replication replaces the file-based replication methods previously used. It removes the need to reprocess these files at each site in the hierarchy.
These files contained client data (status and state messages along with inventory and discovery) and server data (status messages and discovery data). These were processed at each site, which had an impact on the scalability of the site as the messages had to be processed at each site they traversed to ensure that each site’s database contained the correct information. This lack of scalability led to bloated hierarchies with additional sites just to distribute (scale out) processing load.
This method was inefficient because information was processed at least twice in a hierarchy—once at the primary site and again at the central site. In complex and large hierarchies with multiple tiers of primary sites (which was possible with ConfigMgr 2007 and earlier versions), this could cause the same file to be processed numerous times. Each processing incurred write costs into the site database for each site, along with inbox processing by ConfigMgr components. The event of a flood of data to process at any one site resulted in a flood of data to every site above that flooded site.
ConfigMgr 2012 removed this issue by introducing database replication. Database replication is a slightly confusing term as transactional database replication is one of the most common methods of database replication used by SQL Server database administrators. This term was also used in early beta versions of ConfigMgr 2012. For this reason, this book refers to it as DRS from here on, as DRS has nothing to do with transactional database replication in SQL Server.
DRS uses SQL Server change tracking to monitor for table changes and store them. With each activation of DRS by SMSExec’s Replication Control Manager (RCM), changes since the last activation are reviewed and bundled into compressed XML messages and passed to the SSB. The SSB provides a guaranteed transmission method between SQL Server database engine instances for an SQL Server-based application, in this case ConfigMgr. The term guaranteed is used from a developer point of view to refer to a transmission method that the developer is not responsible for maintaining; rather, the SSB provides a resilient transmission method for atomic messages where the developer can fire messages and assume that they were delivered.
As part of creating a ConfigMgr site in a hierarchy, asymmetric keys are exchanged for authentication of each SQL Server database engine instance for use with the SSB. Setup also initializes the database on each end of the replication. The initialization extracts from the database information that is authoritative for that type of data. The CAS is authoritative for global data, which includes all console objects. Primary sites are authoritative for site data, which includes client data (inventory, state/status, and discovery) along with site-specific information (state and status messages). In addition, some types of data could be conceptually viewed as being shared—in the sense that the CAS and its child primary sites both write different information to the same table. For the purposes of DRS, authority is defined at the table layer and not within a table. This is an important distinction, as DRS is used to recover a site outside its change-tracking interval.
For these reasons, if you implement a hierarchy, it is important to monitor DRS replication between your ConfigMgr sites to ensure that any outage is resolved as quickly as possible. Furthermore, while it is possible to increase the data retention value to 14 days, doing so has an impact on the performance of the site database and SQL Server because almost three times the amount of data for the changes must be stored in the site database.
About Content Replication
To enable content replication, ConfigMgr uses SMB to copy files from one site server to another site server. This is generally from the CAS to its child primary sites. You could create content directly on a child primary site and have it replicate up, although using this method causes additional replication lag and is less efficient due to replication up to the CAS and back down again to the other child primary sites in the hierarchy. Chapter 5, “Network Design,” and Chapter 14 cover content replication in more detail.