First published on MSDN on Apr 13, 2015
I’d like to discuss something that has saved (and ruined) the day for many; something that is little documented and less understood: the joiner tool. When we open up our sync service, we see it as the last tab.
Clicking opens up the joiner tool screen:
By selecting the drop-down menu next to “Management Agent:” we are given a list of all available management agents. Really, what we are seeing here is the connector space of, not the management agent itself.
Likewise, by selecting the drop-down menu next to “Disconnector Type:”, we can filter by the various types of disconnector.
If, for example, we select the Blue AD management agent and “All Dicsonnector Types” and click “Search”, we get the below results. Notice, in this example, that one looks different from the rest.
This is because this user object (Aaron Burr, third Vice President of the US) is actually an explicit disconnector .
So, with that in mind, let’s change our filter for “Explicit Disconnectors” only.
Here we see Mr. Burr, sans connections.
Since this user is explicitly disconnected, it does not matter if they reappear in another connected data system. As an explicit disconnector they will remain (from this day until the end of days) a disconnector. In fact, let’s add Mr. Burr back to our Vice Presidential data source, do a round of syncs and see what happens.
Following a full import, here’s the view of a full synchronization on our source data directory:
And a full synchronization of Active Directory. Notice that no joins have occurred. This is, of course, a direct result of the explicit disconnection state.
How, then, can this ever be resolved? If we return to our joiner tool, on the right-hand side under “Actions” there is an option to “Change Disconnector Type”. Here, we can change the type to (a regular) “Disconnector”.
Now, a synchronization of Active Directory shows (as expected) a join.
This is, in my opinion, the most likely scenario under which you would use the joiner tool. However, it is worth noting that advanced join scenarios do exist. For example, the situation may arise (most likely during disaster recovery) where a manual join must be accomplished between two objects, as shown below.
Here, we have configured a search filter to find all objects lacking a valid connector. Please note, the top half of the screen shows the object in a given connector space (in this instance, the Blue AD connector space), while the bottom half shows the actual metaverse object. Once we are certain these two objects are the same, simply clicking “Join” will effect a manual join.
This is where things can get dangerous. It is possible, in theory, to join any disconnected object to any other object…period. A user to a contact; a contact to a group; a group to a network attached multifunction printer. Granted, those are extreme examples, but valid nonetheless. Fortunately, the joiner tool effects change only on a single object (two, at most) at any given time. On the upside, there is no worry here about accidentally breaking 10,000 users. The downside is that the single user we do break very well could be the CEO. I point this out not in jest, but to urge you to be exceptionally careful here, as even a minor incident could have major repercussions. In the fire-fighting world of IT in which most of us live, we’re always so occupied trying to keep our heads above water that’s it’s easy to fall into the mindset of “breaking one user out of 100,000 is no big deal”. However, I assure you, when that 1 user is the CEO, it can be a very big deal.
So, now that we have established what the joiner tool is and what, exactly, it does, let’s discuss why you would use it. In all reality, I have actually seen very few valid use cases for the joiner tool. Granted, I’ve seen it used many times, but most of them weren’t valid. Most of these “bad use cases” were a direct result of improperly configured join logic. “displayName equals displayName” is not good join logic; at best, this will result in a connector space full of disconnectors. At worst, it could result in a metaverse full of duplicates. In many cases where I’ve seen this, the FIM admin thought, “well, I’ll just jump into the handy-dandy joiner tool and manually join these objects up”. That is, in fact, a terrible thought process. It makes sense, but it’s a bad idea. What I generally tell customers is, “If you have the thought of ‘I’ll just hop into the joiner tool, no big deal’, stop, back away from your computer and take a break as you’re probably about to do something bad”. The joiner tool is not, in my opinion, something that is to be used lightly and without regard.
That being said, what, then, are valid use cases? The most valid, I think, is to rejoin an object that has been purposefully explicitly disconnected. I see a common practice in academia of explicitly disconnecting long-tenured (and often
department head) professors when they retire. It is desired that they retain a mailbox (and, by proxy, an AD account), but that they be removed from HR and elsewhere. They retire, become explicitly disconnected and everything is right
with the world. Six months later, however, they decide retirement is killing them and wish to return to teach one class per semester. Even though they have been recreated in HR (and all attributes match up exactly) a join does not
occur. Here, we could most likely get away with using the joiner tool to change their disconnector type to (regular) “disconnector” and firing off a synchronization (to effect a join). Worst case scenario, we can use a search filter and manually join.
The second most likely (valid) use case is under a disaster recovery scenario. Perhaps bad backups (or worse still, no backups) of one data source have caused issues for some users as we cannot determine proper join logic. The desired outcome would be good join logic, but if that is not available, we can (through a painfully tedious process) go through and manually rejoin all affected users.
Questions? Comments? Love FIM so much you can't even stand it?
EMAIL US>WE WANT TO HEAR FROM YOU!<