Outbound Synchronization Rule Type Application - Explained
Something I get asked about a lot are the different types of outbound synchronization rules. When creating a new outbound synchronization rule, the astute observer will notice there are two specific types here:
Those of you who remember the old days of FIM 2010 RTM will recall we only had the first type available to us. To get users from FIM out to AD or wherever, in addition to the sync rule you had to create a set, workflow and MPR. In those days, a criteria based set would define the users who we wished to sync out. A set transition MPR would detect the change and fire the workflow (which called the actual sync rule) against the members of the set. That process was OK and we didn’t know any better because that was the only option we had.
Then along came FIM 2010 R2 and with it came the concept of system scoping filters. These days, many people use them, with their lack of sets/workflows/MPRs and much prefer the simplicity, but not many understand the true differences between the two and why, if possible, you should use these – from a performance perspective if nothing else.
As such, with this post I’d like to dig deeper into what are, in my opinion, the two primary differences between what I will call “traditional” and “scoping filter” outbound sync rules.
The first thing I’d like to talk about are what we call Expected Rule Entries (or EREs for short). EREs do a couple of things, but their primary purpose is to create a relationship between an object and the sync rule that applies to it. While that piece is all fine and good, my problem with EREs is that they can cause a performance hit in larger environments. To understand why, let’s first talk about how they get applied/stored.
I like to describe EREs as sort of like barcodes applied to the objects by the sync rule managing them. When a large mega retailer stocks their warehouses, do they just back up the trucks and dump everything out? No, because then they’d have no way of efficiently sorting through everything or finding specific items. In much the same way, MIM cannot simply dump 350,000 users into a metaverse without any way of cataloguing, associating or locating them. This is where EREs come into play.
As an outbound sync rule applies to an object type, let’s say a user, and carries them out of the portal, through the MIMMA connector space and metaverse and drops them in the target connector space, it stamps each user with an ERE identifying that user as essentially belonging to that sync rule. While this may not on the surface sound like a big deal, consider that all these EREs must go somewhere. In this case, that somewhere is the MIMSynchronization database. And while it is also true that an ERE is nothing more than a bit of text (like a GUID), if you have enough of them it becomes significant. Think of is this way: while a grain of sand may be tiny, all of the vast deserts and endless beaches in the world are made of sand. A billion of anything, no matter how small, when piled up becomes significant.
“But I don’t have a billion users, so what’s the problem?” you may be asking. True, you probably don’t, but these EREs are created on specific objects by each sync rule that touches them. Let’s say you have 100k users, a single AD and a single sync rule – you have 100k EREs.
Now, let’s say you have 100k users and two Ads (prod and QA, for example). Now you have two sync rules and 200k EREs.
What if you’re a global corporation and, for whatever reason, you have 3 forests with the same 100k users in each?
I realize this may not be realistic (why have multiple forests with the same users?) but it illustrates my point. Still, that doesn’t change the fact that if you’re a very large organization with hundreds of thousands of users spread across multiple forests in different geographies, you’re probably going to have a lot of outbound sync rules. My point, then, is that in a real-world scenario, it’s entirely plausible that your very large organization may well have hundreds of thousands (if not millions) of EREs just sitting there in the sync database, taking up space and slowing things down.
In addition to EREs, a “traditional” outbound sync rule (OSR for short) relies on a set, a workflow and a management policy rule to function. Not so bad, right? Let me clarify: you need a set, workflow and MPR for each traditional OSR. Have 50 outbound sync rules? Guess what, you’ll get to create 50 sets, 50 workflows, and 50 management policy rules, too. More moving parts equals more complexity; more complexity equals higher probability things will break down.
By contrast, an outbound system scoping filter based sync rule doesn’t utilize a set, a workflow or an MPR; nor does it create EREs in your sync database. So, while those two aspects alone are reason enough to use this type over a traditional rule, they’re still not the reason I prefer them. Rather, I appreciate the speed boost I pick up during a sync job. To better understand the speed difference, allow me to explain with this example:
With a traditional rule (set/workflow/MPR), the Built-in Synchronization Account climbs up on a soap box with a megaphone and announces, “Everybody line up, single file”. He then proceeds to go to each person in line and individually asks them, “Do you have an update?”. Let’s say there are 100k users and only 5 have a change; he must still ask all 100k people individually. Once all 100k have been asked and the 5 changed identified, he tells them to get on the boat (sync rule) and leave the island (connector space).
With a system scoping filter based outbound sync rule, the Built-in Synchronization Account again climbs up on his soap box with a megaphone, only this time he says, “Raise your hand if you have an update”. Of the 100k users, the 5 changed people raise their hands and he tells them to leave. So, under the traditional method he may ask the same questions one hundred thousand times; with a scoping filter sync rule, he asks one question one time to one hundred thousand people.
Now, granted, for a single AD with 100k users, there might not be a huge difference in speed. If, however, you’re a giant organization with dozens of sync rules and hundreds of thousands of users, this can become significant.
“So”, you may be asking, “why wouldn’t I just use scoping filter syncs rules all the time? Why does the other option even still exist?”. Two reasons: The first being scoping filters are designed really with a single criterion in mind (i.e., “employeeType equals FTE”). If you need to use two or more they become and “and” as there is no concept of “or”. In certain circumstances this may be desirable, such as “employeeType equals FTE” and “location equals Kentucky”. But what do we do if the second scope needs to be “location equals Kentucky or Texas”? With a scoping filter sync rule there is no way to accomplish this. In this case, you’d have to use a traditional sync rule (and you can specify and/or on the criteria of a set).
Questions? Comments? Love FIM/MIM so much you can’t even stand it?
EMAIL US!
>WE WANT TO HEAR FROM YOU<