I decided a while back that when I finally set about to publically document the pathway to enable a new type of Replica Management Point in ConfigMgr, that I wouldn’t go into much detail explaining what a Replica Management Point is, or pitch their usefulness and all that, as we’d get bogged down in details that are already out there.
The likes of Brian Mason and Kent Agerlund have for many years been fleshing out their justification and use-cases, and produced some great guides to getting them up and running, even our Paul Winstanley at WMUG has put together a guide, so instead I thought I’d visualise a particular problem where a default Pull-based Replica Management Point falls short, and show how implementing a Push-based Replica Management Point solves that problem.
In the below shot, I’ve mocked up a visual showing how SQL is used by a Management Point in the three scenarios that it currently covers:
- Management Point in close proximity to the Site Database (in terms of network location)
- Management Point using remote Site Database to service Clients
- Replica Management Point using a replica of the Site Database to service Clients
Image may be NSFW.
Clik here to view.
Now this works just fine as long as you’ve got communications pathways back to the Site servers Database, but when operating in restrictive environments and those pathways are blocked, it means taking Replica Management Points off the design board as a design element.
To get things underway, I’ll focus more on the reason for the drawback in using Replica Management Points in those environments, and show how to put them back on the design board.
So here we are, a very basic network and services diagram, showing on the left a trusted network, and on the right two untrusted networks.
Image may be NSFW.
Clik here to view.
The untrusted networks are not allowed to communicate back to the trusted network, for obvious reasons, and the communications back in that direction are blocked, as is shown using the red crosses above.
The Microsoft documentation for setting up a Replica Management Point guides the administrator into creating a subscription on the Replica SQL Database, which makes it a Pull-based method for replication. So by default, a Replica Management Point is a pull-based mechanism.
I would only recommend using a Push-based Replica Management Point sparingly, and if you need a standard Replica Management Point for high-availability, perhaps look at SQL Always-On as an alternative to hosting Replica SQL Databases.
With the firewall blocking communications back to the Site servers Database, it means that a Pull-based Replica Management Point will fail to function at all, as the underlying SQL replication mechanisms communication pathway back to the Site servers Database is blocked by the firewall.
The solution is pretty simple, nothing complicated about it, but comes with a few considerations, such as incurring a slight performance impact on the SQL database hosting the Subscription, and the supportability of the change to a standard Replica Management Points design. We’ll cover those both more in a moment.
To solve the problem then, all we need to do is rotate this pull-model around to become a push-model, and to achieve that we simply create the subscription on the Site server if it’s hosting the Site Database, or on a remote SQL, or remote SQL Cluster.
Changing the SQL Replication model to Push instead of Pull, means Replica Management Points can function in those environments that restrict access back to the trusted network.
Image may be NSFW.
Clik here to view.
Changing the Replica Management Points SQL replication mechanism to push-based completes part of the solution, but to finish up the Site system also needs to be considered, as by default the Site system will attempt to connect to the Site server, and fail in the problem scenario due to being blocked by the firewall.
The Management Point will essentially drop inventory reports and other material coming in from clients, such as Status and State Messages, into its own Inboxes, and the contents in the Inboxes, on its Site system, need to be replicated to the Site server, so that they can be processed into the Site database.
To solve this problem in a restrictive environment is easy, a feature that has been built into the ConfigMgr product for some time is to configure a Site system so that the Site server connects to it, rather than it connecting to the Site server, labelled up as Require the site server to initiate connections to this site system but more breezily titled Inter-site whizzy bang Inbox Pull Mode contraption thingy.
Here’s Site server to Site system replication visualised showing both modes of operation:
Image may be NSFW.
Clik here to view.
Now all of that is out of the way, and you clearly understand that this new type of Replica Management Point, push-based, is only for heavily restrictive environments, where Regulation\Compliance rules exist that do not tolerate connections being established from untrusted networks to trusted networks.
And you know already from reading this post, or are becoming more aware of the fact that for most people, implementing a Push-based Replica Management Point in their environment is probably a pointless exercise.
However, some of you have probably already figuring out that a Push-based Replica Management Point could actually help you to manage more devices in the more restrictive parts of your environment, possibly replacing ConfigMgr Hierarchies specifically setup just to manage those devices, or bringing them fully into the companies System Management solution, ConfigMgr, rather than letting them continue being managed by stand-alone WSUS for patching and AD Group Policy or “by hand” software delivery.
But here is the catch, since we’ve changed how the Replica Management Point is implemented it is unsupported, not because it doesn’t work, just that it was never put on the test list, if it had, it would be one of our current design elements.
Another point to be made here is that a performance penalty will be incurred by the host of the Subscription, so if it is hosted on the Site server which has local SQL, there will be a slight performance impact, how big depends on the scale of your environment. The more Subscriptions you have, the more of a performance penalty is felt.
Base-lining and monitoring of SQL performance would help view performance before and after the change, and keep on top of performance nose-diving, but to be honest this won’t represent a problem for most customers that are not at large scale, only those that are running their SQL at a far gallop (under-specification, over-used) already.
To solve the supportability issue, if you’re a Microsoft Premier customer you can get reasonable commercial support while this is implemented, but are open to Microsoft during a support engagement asking you to revert the Replica Management Point back to its default configuration (Pull-based SQL Replication) for reproduction of the problem you’re logging with them. Make sure you have a procedure for switching back and forth between Push and Pull in place in case you need to do it.
If you’re the type of environment that pays at least a token nod at not tolerating unsupported scenarios, and do not have a Microsoft Premier agreement in place so as to get a supportability statement sorted out, then you’re out of options, and implementing and dealing with any consequences is entirely your own choice.
For obvious reasons I only recommend readers of this post to implement while getting the nod from Microsoft Premier Support. I am not responsible if you decide to implement and your technical world for some reason ends because of it, even though it is entirely unlikely to happen.
Strap in, get ready, finally we’re going to finish up the post by showing how the replication is switched from pull to push mode.
The Microsoft Documentation for implementing a Replica Management Point is here:
Image may be NSFW.
Clik here to view.
To implement a Push-based Replica Management Point, we’ll follow the Microsoft documented instructions up to the To configure the database replica server section:
Image may be NSFW.
Clik here to view.
We’ll carry out step 1,but modify the step 2 procedure slightly, so as to produce the Push-based SQL Replication mechanism, then complete the rest of the overall Microsoft documented procedure.
Image may be NSFW.
Clik here to view.
2. On the site database server, use SQL Server Management Studio to connect to the local server, browse to the Replication folder, expand Local Publications, select the Publication and right click and select New Subscriptions…
Image may be NSFW.
Clik here to view.
a. Select the Publication and select Next
Image may be NSFW.
Clik here to view.
b. Select Run all agents at the Distributor.
As can be noted in the screenshots text, this changes the replication mechanism from pull to push, it is as easy as that.
Image may be NSFW.
Clik here to view.
c. Select Next
Image may be NSFW.
Clik here to view.
d. Select Add Subscriber and select Add SQL Server Subscriber… then connect to the SQL Replica database. Returning back to the New Subscription wizard, the Subscription database drop-down for the newly added subscriber needs some attention. If you’ve already pre-created the database, this is where you’d select it, otherwise create a new database.
Image may be NSFW.
Clik here to view.
e. Once you’ve taken care of the small matter of pointing at the Replica Database, select Next
Now go back to Step 2 in the To configure the database replica server section, and carry out steps f, g, h and i, and then complete the entire remaining procedure as documented by Microsoft. You can also enable the Notification Channel as instructed in the Microsoft documentation.
A quick check of the Publication see’s the Subscription has been added to it:
Image may be NSFW.
Clik here to view.
Having a nose around the actual Publication shows us what is being replicated (Articles):
Image may be NSFW.
Clik here to view.
And viewing the properties of the Subscription shows us it is in Push mode:
Image may be NSFW.
Clik here to view.
Your SQL Replication mechanism will now be push-based, and along with a Site system that is serviced by the Site server connecting to it, you have a Management Point role that, along with its underlying Site system, is for the first time compliant with the needs of some of the most complex untrusted, but accessible, network environments out there.
Drop in a Distribution Point and you’ve now got Policy, Lookups and Content covered in the restrictive environment, Client Registrations too. OSD is but a mere click away. Nice.
While this is a great solution for on-premise devices, there are other ways coming about to service the same difficult to reach devices such as those in untrusted networks, as long as they have access to the internet . An up-and-coming feature called the Cloud Proxy Point, which is trialling in Build 1606 of the Technical Preview will open all of them up to management using a solution lashed together with Azure and on-premiseConfigMgr. I’ll be covering this technology in my next blog, as it is a killer way to handle devices on the internet or with on-premise but with internet access, without needing to place your Site Roles in a public facing DMZ. One of the most exciting features I’ve seen in a while as an architect, along with Intune, but quite a fiddly affair in comparison to Intune to get up and running.
Update (05/09/2016):
Confirmed that with a Push-based Replica Management Point, the Client Notification Channel works fine. Nothing special needed to configure it beyond the documented steps.