Haiku #154
I now pronounce you
The brand new CMS store.
Congratulations!
Well, it's Monday, the day after yet another absolutely thrilling weekend here in the greater Seattle area. How thrilling was this past weekend? Well, on Sunday, the temperature topped out at a scorching 62 degrees Fahrenheit! How hot is that? Well, at one point, the author of today's haiku got so warm that he had to remove his mittens and his wool scarf. In July, mind you!
And if that wasn't enough excitement for a single weekend, on Saturday the author of today's haiku got to go to a wedding, his single favorite thing to do in the entire world (with the possible exception of getting to sit through a high school graduation). Or at least he thinks he went to a wedding on Saturday. The service drug on and on and on, and then all of a sudden the bride and groom walked out, without even a "Ladies and gentlemen may I present to you Mr. and Mrs. Ken Myer." (Which, of course, might be due in part to the fact that this wasn't the wedding of Mr. and Mrs. Ken Myer.) To be honest, it appeared as though the priest officiating at the ceremony decided to zip through most of that boring I-now-pronounce-you-man-and-wife stuff, the better to focus on his sermon on the joys and responsibilities of holy matrimony.
Either that or the bride and groom got bored, too, and decided to duck out and go get married at a Justice of the Peace.
Regardless, Saturday's wedding was every bit as exciting as you would expect a wedding to be, so exciting that the author of today's haiku go to thinking that maybe he should get married, too.
Which, surprisingly enough, turned out to be something his wife was strongly in favor of.
Note. Between home and work, it seems like the author of today's haiku is always being encouraged to explore other options. It's nice to know that people care, isn't it?
In all fairness, we should point out that there was one really good thing about this last wedding: for the first time in his life, the author of today's haiku had the perfect wedding gift. That's right, no waffle iron or Wal-Mart gift card, not this time around. Instead, he gave the happy new couple a gift that will keep on giving: The CsManagementServer cmdlets (Move-CsManagementServer and Set-CsManagementServer).
Now, we know what you're thinking: you call two Lync Server PowerShell cmdlets a good gift, especially when one of those cmdlets (Set-CsManagementServer) can only be used to change the replication port used by the Central Management store? How can you call that the perfect wedding gift?
Well, look at it this way: you're a newly-married couple, fresh out of college, looking for work, and hoping to someday start a family. In a situation like that, what's the last thing in the world you want to worry about? That's right: the last thing in the world you want to worry about is how in the world you could move your Central Management store to a new pool. The author of today's haiku didn't just give the happy couple a Lync Server PowerShell cmdlet; he gave them peace of mind.
How so? Well, suppose you have the Central Management service running on one of your Lync Server pools and now, for some reason, you need to transfer that service to a different pool. (For example, perhaps you need to decommission the pool where the service is currently running.) Can you move the Central Management service using a waffle iron or a Wal-Mart gift card? Not as far as we know. However, you can move that service by following these simple steps:
· Verify that you have created the new Central Management store in the alternate pool. This is done by running the Install-CsDatabase cmdlet and using the CentralManagementDatabase parameter. If you are moving the Central Management store to a Standard Edition server, you also need to use local setup to run the Prepare Standard Edition server option. That configures firewall rules that will allow Windows PowerShell to remotely access the new Central Management store.
· Verify that there is enough free disk space on the computer where Move-CsManagementServer is being run to accommodate the Central Management Server. Kind of a no-brainer, but it's a good thing to double-check, just to be on the safe side.
· Make sure you are logged on to a Front End server in the pool where the Central Management store will be moved to. You have to run Move-CsManagementServer locally, and on a Front End Server. No exceptions.
· Verify that you can successfully run the Enable-CsTopology cmdlet. If you can't, then the move will fail and you will no longer have a functioning Central Management store of any kind.
And yes, then you have real problems.
After you've completed those initial steps, you can then move the Central Management service by running this command:
Move-CsManagementServer
Believe it or not, that's all you have to do. Good luck finding a waffle iron that's as simple to use as that.
That's what you do when you have a fully functioning Central Management store that you simply want to transfer to a different pool. Now, suppose a meteor has hit your server room and destroyed your Central Management server. How can you "move" the Central Management service when that service no longer exists? Why, like this, of course:
Move-CsManagementServer -ConfigurationFileName "C:\CsConfiguration.xml" -LisConfigurationFileName "C:\CsLisConfiguration.xml" -Force
What's going on with this command? Well, in this command we're calling Move-CsManagementServer along with three parameters. The ConfigurationFileName parameter represents a backup copy of our Lync Server topology and configuration settings; this is a file you create by periodically running the Export-CsConfiguration cmdlet. In order to move the Central Management store you need to have this backup file, which means that you should get in the habit of periodically running Export-CsConfiguration in order to always have an up-to-date backup of your Lync Server settings. Likewise, the LisConfigurationFileName parameter is used to restore your Enhanced 9-1-1 settings. And where does that file come from? It comes from periodically running the Export-CsLisConfiguration cmdlet.
Note. And what if you're not using the E9-1-1 service? In that case, you don't have to include the LisConfigurationFileName parameter after all.
Last, but definitely not least, you also need to include the Force parameter. Why? Well, when you call Move-CsManagementServer, the cmdlet temporarily sets the Central Management store to read-only before the move takes place; that helps guard against data loss. In a disaster recovery scenario, however, the Central Management store cannot be marked as read-only; as you might recall, our Central Management store was obliterated by a meteor and no longer exists. The Force parameter instructs the cmdlet to move the Central Management store even though it has not been configured as read-only.
And that's why the CsManagementServer cmdlets are the perfect wedding gift. Granted, you can make waffles with any of these cmdlets but, then again, some things in life are more important than waffles.
Note. OK, maybe not Belgian waffles with strawberries and whipped cream. But some things in life are more important than plain waffles.
Incidentally, if you're wondering why the author of today's haiku didn’t also give the happy couple a copy of the Get-CsManagementServer cmdlet, well, it's not because he's a cheapskate (although he is). Instead, it's because there's no such thing as the Get-CsManagementServer cmdlet. If you want information about your Central Management server and your Central Management store, use these two commands instead:
Get-CsService –CentralManagement
Get-CsService –CentralManagementDatabase
That should do it for now. For more gift ideas, please contact the good folks here at the Lync Server PowerShell blog. And be sure to check out our back-to-school specials: buy one copy of the CsClientVersionPolicyRule cmdlets, get a second copy absolutely free! (You pay only shipping and handling.) Needless to say, you'll be hard-pressed to find a better price than that anywhere.
OK, maybe on Amazon. But other than that ….