One of the biggest changes that occurred in the design of ConfigMgr about SCCM / SMS was the conception of a new way of data management and replication between sites, both central to the primary, and primary with secondary adding SQL Service Broker, and not only replication files.
This meant that, previously to SP1, in ConfigMgr you had to define in the design phase if you wanted a single site, or may needed more, so creating a Central Site (CAS) was needed, and this role could not be added at a later point unless the entire site is rebuilt.
This resulted in the creation of Central Sites for the sole purpose of having them if were needed in the future, which is not desired in the design of any solution.
This change in SP1 and design allow to add this central site subsequently, giving flexibility to the design.
But why this limitation? What had changed?
SMS/SCCM replication was based on files, the Management Point sent the file to the Primary, this processing the file, if it depended on another site, these same files were sent sequentially until reach the highest level of the hierarchy, as is visible the level of performance on this design does not scale well and generates that the same file is processed several times in the structure generating redundancies that are not helping performance.
On ConfigMgr this was changed so that the file processed in the Primary Site is added to the database, and the information is replicated to the other sites via SQL-based replication, so is only processed one time, but this is not based on the native SQL replication, it is a service designed and created by the group ConfigMgr product.
And then, what is this replication?
Let’s start by defining what type of data is replicated, these are:
Global Data. Is the data of the database that are replicated between the CAS and all sites, applying to all sites, for example, boundaries, setting site, update Ids, … generally the data we see in the console and are common to all sites.
An offshoot of this is the Global Proxy Data, which are the primary replicates data to its side.
Site data. Is the data only apply to the local site, such as inventory, … are data that are not common among the sites only replicated between the primary site and the CAS.
This is the basis for understanding replication, since these data are replicated in groups according to whether global or site, forming replication groups.
When you install a new site this replication need to follow a few steps to initialize, would be:
a. Replication begins with a file BulkCopy actually tables that form replication groups from the parent server to the database server child by a bcp copy of the database is copied.
b. After this copy file replication can start, and using SQL elements, the changes that occur in the database, for this port 4022 is used by default (it is now configurable)
After this mounted replication, exchange controls now in the databases will feed data to replicate.
What if replication fails?
They have several automatic actions on the site, if none of these works need to act to repair it.
We cannot leave much time this component unattended because it has a limit lifetime of the data, if it passes this time (5 days by default), the entire process will restart with a new BulkCopy, moving a large volume of data In the net.
But this part and to another post.
configmgryyo 