Haiku #90
Raw oyster? Broiled dog?
Maybe we should just run a
Cmdlet instead.
In the move Blade Runner, the bad guys were the replicants, incredibly powerful and intelligent robots that were virtually indistinguishable from human beings. In fact, in the movie the only way to determine who was a replicant and who wasn't was to administer a lengthy examination, sort of like a lie detector, in which the examiner asked a bunch of weird questions ("How do you feel about eating raw oyster and broiled dog?") and then measured things like heart rate, respiration rate, and eye movements. That kind of test worked, because replicants don't have normal human emotions.
Note. Of course, that was 20-some years ago. Today you can identify replicants by using a single question: what's 3 times 4? If you can answer that question without having to whip out your iPhone, then you're probably a robot.
So what do replicants have to do with Microsoft Lync Server 2010? As far as we know, nothing whatsoever. We were just reminded of the movie Blade Runner, and of replicants, when we sat down to write today's haiku.
Trivia Note. In the book Do Androids Dream of Electric Sheep? (on which the movie Blade Runner was based), replicants weren't called replicants; instead, they were called, well, androids. However, thanks to the movie Star Wars, people had begun to picture androids as being cute and cuddly little things, and the moviemakers decided no one would want to see a movie involving mutinous, murderous androids; it'd be like watching The Texas Chainsaw Massacre remade using the Care Bears. Because of that, they coined the word "replicant" as a way to describe their mutinous, murderous androids.
Like we said, there are no replicants in Microsoft Lync Server.
Note. Yes, it's true that, due to his lack of normal human emotions, the author of today's haiku has often been accused of being a replicant. However, replicants also have superior strength and superior intelligence. Needless to say, accusations withdrawn.
Anyway, there are no replicants in Lync Server, but there are replicas: basically a replica is any computer that runs a Lync Server server role and participates in the Lync Server replication cycle. So how do you know who all your replicas are, and whether replication is up-to-date? Well, one way is to query each computer and ask how it feels about eating raw oyster and broiled dog. Perhaps a better way, however, is to run the Get-CsManagementStoreReplicationStatus cmdlet. How hard is it to run the Get-CsManagementStoreReplicationStatus cmdlet? Not all that hard, even if you don't have your smartphone with you:
Get-CsManagementStoreReplicationStatus
That's pretty much all you have to do; in turn, Get-CsManagementStoreReplicationStatus will bring back information like this about each of your Lync Server replicas:
UpToDate : True
ReplicaFqdn : atl-cs-001.litwareinc.com
LastStatusReport : 4/14/2011 8:28:46 AM
LastUpdateCreation : 4/4/2011 8:28:43 AM
ProductVersion : 4.0.7629.0
More often than not the property you'll really be interested in is the UpToDate property; that simply tells you whether or not replication is up-to-date on the computer (replica) in question. In case you're wondering, replication on Lync Server works something like this: Any time you make a change to the system (for example, you create a new policy or you delete the meeting configuration settings for a site) that change gets recorded in the Central Management store. For Lync Server to actually work (and, trust us, it's much better for Lync Server to work than for it not to work), that change must be replicated to all the computers running Lync Server services or server roles.
In other words, to all the Lync Server replicas.
So how exactly does that data get replicated? Well, to begin with the Master Replicator (a service running on the Central Management Server, and a job title that the author of today's haiku would love to have for himself) creates a snapshot of the modified configuration data. (As a general rule, only the actual changes are replicated. If you create a new policy, replicas will be notified about the new policy, they won't get a brand-new copy of the entire Lync Server deployment.) A copy of this snapshot is then sent to each Lync Server replica. On those replicas, a replication agent receives the snapshot and uploads the modified data; the agent then sends the Master Replicator a message reporting the latest replication status.
Note. Which, now that you mention it, probably would make for a great sequel to Blade Runner, wouldn't it: Blade Runner II: Return of the Master Replicator.
At any rate, if you just want to double-check the replication status of a single computer, well, you can do that; all you have to do is include the ReplicaFqdn parameter:
Get-CsManagementStoreReplicationStatus –ReplicaFqdn atl-cs-001.litwareinc.com
Or if you'd like to see a list of computers where replication is not up to date you can do something like this:
Get-CsManagementStoreReplicationStatus | Where-Object {$_.UpToDate -eq $False}
You can also add on the –CentralManagementStoreStatus parameter, like so:
Get-CsManagementStoreReplicationStatus -CebntralManagementStore
Why would you want to do that? Well, that's going to bring back some additional information about the Central Management Store; it's also going to bring back a list of active replicas and deleted replicas. What's a deleted replica? Well, that's a replica that's been removed from your Lync Server topology (using Topology Builder) but where Lync Server itself hasn't been uninstalled yet.
Or at least that's the way we think it works.
That's all we have for this week. Incidentally, if you really, really enjoyed today's haiku we have just one question for you: how do you feel about people eating oyster and broiled dog?
Just wondering ….