Haiku #98

[NextHop_Team]

First published on TECHNET on Apr 27, 2011

Elves are useless. Try

The UserReplicator

Cmdlets instead.

You'll have to forgive the author of today's haiku for being a bit excited and distracted this morning: after all, later on today he gets to attend his first ELF meeting!

Now, before you get too excited and distracted, the author of today's haiku should clarify that this meeting has nothing to do with those kind of elves, the kind who sneak into your house late at night and build shoes for you , or the kind that help Santa in his workshop. (Or at least he doesn't think those are the kind of elves we're talking about; he probably should pay more attention to the official emails that get sent out around here.)

And, sadly, these are definitely not the kind of elves that sneak into your office late at night and write daily Lync Server PowerShell haikus for you. (The author of today's haiku knows: he checks his desk every morning when he comes in and, so far anyway, nothing.) Instead, ELF is an acronym for Exchange, Lync, and Forefront, the three documentation teams that will be getting together this morning to do ... well, whatever it is that documentation teams do when they get together. Isn't Microsoft taking a huge risk by having all three of those teams gather in the same place at the same time; after all, what if extraterrestrials chose that very moment to aim their new Destructo-Ray at the conference center where they're meeting? For some reason, Microsoft seems willing to take that risk. Hmmm ....

Note . Did you know that real elves probably originated in Germany, although the Norse (you know, the Vikings?) were the ones who really promoted elves and elfdom? In fact, in Norse mythology it was possible for a human being to be promoted to elfdom; the only catch is that you had to die before you could become an elf. Which must have made for some interesting help wanted postings:

Wanted . Human being interested in becoming an elf. Hard worker, good organizational skills, non-smoker; must be willing to work occasional weekends. And be dead.

At any rate, it should be an interesting meeting, and the author of today's haiku is really looking forward to it.

Note . Because of all the important information he will learn at that meeting? Well, to be honest, he hadn’t even considered that : he was mostly excited about the free lunch. But learning important stuff would probably be good, too.

Of course, because these aren't the kind of elves who write daily haikus for you, that means the author of today's haiku actually has to author today's haiku. (And yes, at today's meeting he just might raise the issue of how unfair that is.) And so, with no further ado, here's the subject for today's haiku: the CsUserReplicatorConfiguration cmdlets.

Please hold your applause until the end.

As everyone knows, there are good elves and there are bad elves. The historian Snorri Snurluson summarized the difference between the two types by saying this:

"Sá er einn staðr þar, er kallaðr er Álfheimr. Þar byggvir fólk þat, er Ljósálfar heita, en Dökkálfar búa niðri í jörðu, ok eru þeir ólíkir þeim sýnum ok miklu ólíkari reyndum. Ljósálfar eru fegri en sól sýnum, en Dökkálfar eru svartari en bik."

Note . Remember, that's Snorri's opinion, not ours.

So does that mean that there are good CsUserReplicatorConfiguration cmdlets and bad CsUserReplicatorConfiguration cmdlets? Not exactly. However, there are CsUserReplicatorConfiguration cmdlets that will work with the on-premises version of Microsoft Lync Server, and CsUserReplicatorConfiguration cmdlets that will not work with the on-premises version of Microsoft Lync Server. And the difference between those cmdlets will be the focus of our discussion today.

Well, in a minute. First, we should probably explain what the CsUserReplicatorConfiguration cmdlets are even for. As you know, Lync Server 2010 depends on Active Directory as the ultimate source for user information. For example, when a new Active Directory user account is created, you must supply basic information about the user account (such as the Active Directory display name). However, when a user is enabled for Lync Server you do not need to specify a new display name for that user. Why not? Because Lync Server uses the display name already stored in Active Directory. You need to supply some Lync Server-specific information, but that's about it.

What's wrong with that? Nothing; you just have to make sure that Lync Server and Active Directory remain in synch. To do that, Lync Server must periodically check in with Active Directory, retrieve the latest user account updates, and then modify its user database accordingly. This synchronization between Active Directory and Lync Server is carried out by the User Replicator.

Note . Which, now that you mention it, would be a good name for an elf. But we're pretty sure that the User Replicator is not an elf.

When you install Lync Server, a global set of User Replicator configuration settings is created for you; these settings are used to manage the User Replicator on an organization-wide basis. Management of the User Replicator primarily consists of identifying the domains that Lync Server needs to synch with, as well as indicating how often the User Replicator checks Active Directory for user account updates. By default, the User Replicator discovers and synchs with all available domains. However, by using the ADDomainNamingContextList property you can restrict synchronization to a specific set of domains: the domains that appear in the ADDomainNamingContextList property.

Good point: that passage from Snorri Snurluson was easier to understand than the preceding paragraph, wasn't it? OK, let's put it this way. By default, you don't have to do anything to the User Replicator: it automatically seeks out and synchronizes with every domain it can find. Most of the time that's good. However, suppose you're working in a multiple domain organization and there are some domains that you'd prefer not be synched with the User Replicator. In that case, you can use a command like this one to specify that the User replicator should only synch with the fabrikam.com domain:

Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList @{Add="dc=fabrikam,dc=com"}

You say there are actually two domains you need to synch with? That's fine; just list both domains in your command, separating the two by using a comma:

Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList @{Add="dc=fabrikam,dc=com","dc=litwareinc,dc=com"}

And if you later decide that you don't need to synch with Fabrikam.com after all, well, then you can easily remove that domain from the list:

Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList @{Remove="dc=fabrikam,dc=com"}

As you can see, it's all pretty easy. And no elves required!

Oh, and if you decide to revert to the default behavior and synch with all the available domains, just set ADDomainNamingContextList to a null value. You know, like this:

Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList $Null

That's all for the Set-CsUserReplicatorConfiguration cmdlet. (There's also a Get-CsUserReplicatorConfiguration cmdlet that lets you review your current settings.) Now, what about the other two cmdlets in this cmdlet family, New-CsUserReplicatorConfiguration and Remove-CsUserReplicatorConfiguration ? Well, those two cmdlets are intended for use with Lync Online, and aren't something you need to concern yourself with right now. (In the future, yes. For now, no.) As you might expect, New-CsUserReplicatorConfiguration will allow you to create additional sets of user replicator settings, with these settings scoped at the service scope. In turn, Remove-CsUserReplicatorConfiguration will let you remove those custom settings. But that's how things will work in the future, as soon as our team of elves finalizes Lync Online.

And there you have it: the CsUserReplicatorConfiguration cmdlets. In closing, we'd like to leave you with one final comment about elves:

"In Denmark and Sweden, the elves appear as beings distinct from the vetter, even though the border between them is diffuse."

We couldn't have said it better ourselves.