Haiku #137
I sense a very
Real connection between us.
CS Management.
Yesterday the author of today's haiku was the lone member of the user assistance (UA) team to sit in on a meeting. As such, he was almost immediately peppered with questions about documentation:
"Do you know who's going to be working on the documentation for this?"
"No."
"Do you know if you guys have started planning the documentation set for this?"
"No."
"Do you know when your team expects to have the documentation done?"
"No."
"Do you know who holds the Major League record for most runs scored in a career?"
"Yes. Rickey Henderson."
OK, no one actually asked that last question, which is too bad: after all, Rickey Henderson does hold the Major League record for most runs scored in a career. But no one ever asks the author of today's haiku about important things, like baseball or college basketball. Instead, they always ask him things about work priorities and deadlines. Work priorities and deadlines? Why would you ever ask someone who writes haikus about Lync Server PowerShell questions about work priorities and deadlines?!?
Note. True story: several years ago the author of today's haiku was sitting in a meeting with someone who had lived in Seattle all her life. Somehow or another, Ken Griffey, Jr.'s name was mentioned, and this woman asked, "Who's that?" Despite living in Seattle her entire life, she had never even heard of Ken Griffey, Jr. That's life at Microsoft.
But wait, there's more. In reply to her question, someone said, "He's the Willie Mays of our generation." And she said, "Who's Willie Mays?"
At any rate, if you want to know who holds the Major League record for most doubles in a season (Earl Webb), ask the author of today's haiku. But that's pretty much the extent of his knowledge. If you want to know something besides the name of the player who holds the Major League record for most doubles in a season, well, you'll have to ask someone else.
No, wait! As it turns out, the author of today's haiku does know one other thing: he knows what the CsManagementConnection cmdlets (Get-CsManagementConnection, Remove-CsManagementConnection, and Set-CsManagementConnection) are used for.
So what are the CsManagementConnection cmdlets used for? We were afraid someone was going to ask that. Well, as you probably know, most of the configuration information used by Lync Server 2010 is stored in a SQL database known as the Central Management Store. Where exactly is that SQL database? To tell you the truth, we have no idea. But the Get-CsManagementConnection cmdlet will typically tell you:
Get-CsManagementConnection
Run that command, and you will typically get back something similar to this:
StoreProvider : Sql
Connection : DataSource=atl-sql-001.litwareinc.com\rtc;InitialCatalog=xds;IntegratedSecurity=True
ReadOnly : False
So why do we keep saying that things "typically" work like this? Well, typically, you configure your SQL Server database (and, by extension, your management connection) when you install Lync Server and, from that point on, you never have to worry about either the database or your management connection. However, suppose that something does go wrong?
Note. Yes, we know: nothing could ever go wrong with Lync Server. But just pretend, OK?
For example, suppose your database has crashed, and you need to point your management connection to a backup database. How do you do that? One way is to use the Set-CsManagementConnection cmdlet:
Set-CsManagementConnection -StoreProvider Sql -Connection "atl-sql-001.litwareinc.com\rtcbackup"
As you can see, that's not too terribly hard: you simply set the StoreProvider parameter to Sql and set the Connection parameter to the path to the backup database. Will you ever have to do that? Probably not. But it doesn't hurt to know that you can do that, if need be.
Here's something else that you'll probably never need to do, but can: you can actually set your management connection to the local file store. In that case, you'll do all your work locally and will not be connected to the Central Management Store:
Set-CsManagementConnection -StoreProvider FileSystem -Connection "C:\Test"
So why would you ever want to do that? Well, two reasons. One, it gives you a test environment where you can play around with doing things like creating and deleting policies, all without ever affecting the real Central Management Store. For example, if you create a new voice policy, that policy won't get stuffed into the Central Management Store where another administrator could inadvertently start assigning the policy to actual users. Instead, it just becomes an XML file on your local hard disk. A good, risk-free way to play around with Lync Server PowerShell.
Another possibility is this: you need to create a bunch of new policies and stuff, but your network is having problems and you can't connect to the Central Management Store. Well, if you wanted to, you could switch your management connection to the file system, create your policies, export them to a slightly-different XML format, and then later (after the connection has been restored) import them to the Central Management Store.
OK, good question: what does that mean? Well, it means that you could do something like this:
$x = New-CsExternalAccessPolicy –Identity "TestExternalAccessPolicy"
Export-Clixml –Path C:\Test\TestExternalPolicy.xml –InputObject $x
All we've done here is create a new external access policy and stored it in a variable named $x; we then use the Export-Clixml cmdlet to save that policy to an XML file named C:\Test\TestExternalPolicy.xml.
What's the point of that? Well, let's suppose the network is back up and running, and we've switched our management connection back to the Central Management Store. Is there an easy way to get this new external access policy into the Central Management Store? Of course there is:
$x = Import-Clixml –Path C:\Test\TestExternalPolicy.xml
Set-CsExternalAccessPolicy –Instance $x
As you can see, we've imported the policy, stored it in a variable named $x, then used the Set-CsExternalAccessPolicy cmdlet to save that policy to the Central Management Store. Again, this might not be something you'll ever find yourself doing, but, hey, stranger things have happened, right?
Note. No, we can't think of any either, at least not off the tops of our heads. Still ….
By the way, how do you switch back to using the Central Management Store as your management connection? By running this command:
Remove-CsManagementConnection
Yes, that looks dangerous, doesn't it? But it's not. If you don't specifically define a management connection then Lync Server PowerShell automatically looks in Active Directory to see if it can find a service control point that reports the path to the Central Management database. Assuming that this service control point can be found, then your management connection will automatically point towards that database.
Two quick notes about this. First, you can only change the management connection for your local computer; you cannot remotely connect to another machine and change its management connection.
Note. Yes, that would be a hilarious practical joke, wouldn’t it? But it can't be done.
Second, any change you make to your management connection lasts only as long as your current instance of Windows PowerShell. Suppose you switch your management connection to the file system and then exit the Lync Server Management Shell. The next time you start the Management Shell, your management connection will once again point to the Central Management Store. (Why? Because the Management Shell retrieves the service control point from Active Directory each time it starts up.)
And there you have it: now you know all about the CsManagementConnection cmdlets. Oh, and you also now know that Ty Cobb holds the Major League record for most triples hit in a career. Is there anything else that you need to know? Not that we can think of.
See you tomorrow.