Let’s face it… SQL replication is a must for many Ivanti Environment Manager customers that have geographically dispersed offices. It’s a best practice to have your personalization servers and databases as close to the endpoints to reduce latency.
This type of design would also reduce logon times and application launch times. This setup requires that the customer build multiple personalization servers and databases in different datacenters to solve the issue of latency. In the past we have used SQL “push/merge” replication to synchronize these databases ensuring the users always have quick access to their settings wherever they go.
SQL “push/merge” replication comes with its own set of challenges. First of which; a snapshot of the publishing database must be taken and delivered to the subscribers. This snapshot takes up quite a bit of room on the publishing SQL server. Next the entire “ApplicationData” table is replicated to all of the subscribers. This requires that all of the remote locations need to have almost the same amount of storage as the publishing SQL server.
Another issue exists if replication fails for any reason, and replication remains broken for fourteen days then the databases become orphaned and stop replicating altogether. Getting the databases back into sync is almost impossible after this occurs. Many smaller companies don’t know much about SQL replication and rely on mirroring or transactional replication for database replication. This makes implementing ,maintaining, and monitoring SQL replication even more difficult… Many times the SQL admins push back and refuse to implement it.
Enter “GeoSync”, a new feature released in Environment Manager 10.1 FR2. This feature completely replaces SQL “push/merge” replication with a built-in solution to synchronize user data across your personalization server databases. Instead of the SQL agent on your SQL servers initiating and handling the replication, the Background Service on the personalization server handles the replication much like it does for archiving. J
ust like archiving, if you have two or more personalization servers connected to a database the first server that starts the replication handles the replication. This means there are no single points of failure for the initialization of the replication.
“Push/merge” replication simply compares two tables in a database and copies missing records over or updates existing records based on a timestamp on the record. “GeoSync” is “intelligent” replication meaning its aware of how the database is structured and handles the user’s settings on a per-application basis.
This method of handling replication is far superior to “push/merge” replication as less work is being performed to compare the two databases. Imagine doing a personalization analysis for a user (see image below). All the items you see under the users account are “Application Profiles” and all the data associated with each entry is finally being properly handled as a group of settings as opposed to individual files.
“GeoSync’s” intelligence also allows it to replicate only a subset of the user’s data. This reduces the amount of storage needed at remote locations as well as the amount of bandwidth used on the WAN.
BTW, it works with all versions of SQL including SQL express!
So how do you set this up? Simply run this PowerShell script as admin on your personalization server and follow the prompts:
After you have run the script you would have made one site the “publisher” and the other the “subscriber”. Next we need to logon to the publisher and configure a personalization group for replication. You should have a new “GeoSync” tab where we can add our subscriber. Make sure to click “Save Changes”.
This is also where we can add conditions for user groups as well.
After you have enabled “GeoSync” for your personalization group you’ll need to find the “GeoSync” section at the top of the Manage tab.
On this tab we will define a schedule for replication by clicking the ellipsis on the far right.
Unfortunately, at this time you cannot get very granular with the replication schedule. In fact, I almost see this as an issue. Previously SQL “push/merge” replication would, based on the default replication configuration (personalization group settings, application groups, applications, etc), replicate every 5 minutes and the user’s data would replicate every 24 hours. This means if you make a change to personalization it gets rolled out almost immediately.
With “GeoSync” that would change, in that personalization wouldn’t take effect until the next day. Historically, it was also common to change the data synchronization from 24 hours to something more like 4 hours to ensure the data gets to another location before the user does by plane for example.
The workaround for the lack of scheduling options is to use PowerShell commands to initiate a “manual” sync. This can be automated via scheduled task but now you’ve just introduced a single point of failure.
Once you have your schedule set you can initialize the replication by choosing “Synchronize”.
After “GeoSync” is enabled and replicated if we logon to our subscriber you’ll notice the personalization group and my “IE” group are now highlighted in purple (see below). This indicates that this personalization group is syncing and we are connected to a subscriber.
This being the case, the settings for the personalization group or IE group on this server are read-only. Moving forward any changes will need to be configured on the publisher.
So is “GeoSync” ready for prime time?
Maybe… If you struggled with “push/merge” replication or need to filter what is being replicated, it might be for you. Any customer that has custom settings in their configuration may want to avoid adopting this feature as a replacement for “push/merge” replication.
As I was writing this article I found a bug. If you have a “Windows Setting Group” that has multiple custom settings and you have another “Windows Setting Group” that contains the same custom settings, then the “Windows Setting Group(s)” completely fail to replicate.
If the “Windows Setting Group” issue and the scheduling was improved with a separate configuration replication schedule and more options, other than once a day, then “GeoSync” would definitely be the way to go.
I was really hoping FR3 would have shown some progress with this feature, but that doesn’t seem to be the case. Hopefully FR4 will soon improve this feature up a bit in the near future!
Critical Design Associates