Haiku #75

Need a Lync Server

Reset button? Try CS

Configuration.

Before we do anything else, we'd like to offer everyone an apology for yesterday's haiku. Apparently some unscrupulous hackers managed to breach security and leave weird, incomprehensible notes like this one, notes that suggest that the author of yesterday's haiku (who is also the author of today's haiku) not only doesn't know what he's talking about, but that he's easily duped as well:

Note from Jean. The actual conversation was more along the lines of "New-CsVoiceRegex is an interesting cmdlet, you should write a haiku about that one." But if the author of today’s haiku, a.k.a. Greg Stemp, wants to take that as a challenge, that’s okay. We got the haiku didn’t we?

Easily duped?!? Easily duped?!? The author of today's haiku plans to write a blistering rebuttal to that insult … just as soon as he finishes whitewashing the fence.

At any rate, we do apologize for these unwanted and unwarranted intrusions into the daily haiku. We hope this does not cause any problems for either one of our devoted readers.

Note. And yes, now that you mention it, hacking the daily haiku is sort of like someone scrawling comments into the margins of a Gutenberg Bible, isn't it?

Sort of.

It's actually a bit ironic that we got hacked, because we thought we had the ideal security system: by writing a daily haiku about Lync Server PowerShell, we figured no one would even read the thing, let alone hack into it. Unfortunately, we were wrong. But don't worry: we'll get to the bottom of this. In fact, we've assigned our best people to the task of tracking down the hacker and bringing him (or her) to justice.

Or at least that's what we would do if we actually had any best people.

As you might expect, the past couple days have been a bit traumatic for those of us here at the Lync Server PowerShell blog. But that's OK; we can handle that. After all, when we're feeling a little stressed out and a little overwhelmed, we do what most people do when they're feeling a little stressed out and a little overwhelmed: we console ourselves by running the Export-CsConfiguration and the Import-CsConfiguration cmdlets.

Note. And then we down a couple bottles of vodka. But it's always cmdlets first, vodka second.

So what's so interesting, and so comforting, about the Export-CsConfiguration and Import-CsConfiguration cmdlets? Well, for one thing, these cmdlets enable you to backup and restore a your Lync Server deployment: when you run Export-CsConfiguration, the cmdlet creates a .ZIP file containing backup data for your Lync Server topology, configuration settings, and policy data. Why do you need that backup data? Well, suppose the computer running your Central Management store blows up. (Or perhaps gets hacked into. Hey, if it can happen to us it can happen to anyone!) In that case, the best (and really the only) way to restore the system, and to get the Central Management store up and running on a new computer, is to use the Move-CsManagementServer cmdlet and the .ZIP file that was created by running Export-CsConfiguration.

Note. If you're trying to plan ahead for potential problems like the Central Management store blowing up (and it's really a good idea to plan ahead for things like that, just in case) you might want to routinely backup your system using Export-CsConfiguration. If you're using Enhanced 9-1-1 (E9-1-1) then you might want to also routinely back up that system by using the Export-CsLisConfiguration cmdlet. Export-CsConfiguration does not back up your E9-1-1 location and configuration data; Export-CsLisConfiguration does.

Of course, by now you're probably wondering how you actually use Export-CsConfiguration. (Well, unless you're still wondering how, and why, someone could hack the daily Lync Server PowerShell haiku.) As it turns out, that's one of the easier cmdlets you could ever choose to run:

Export-CsConfiguration -FileName "C:\Config.zip"

That's it: you just call Export-CsConfiguration and include the FileName parameter followed by the full path to the .ZIP file being created.

Note. Hmmm, maybe we could drink the vodka first after all ….

Now, what about the Import-CsConfiguration cmdlet? Well, Import-CsConfiguration actually has two uses. First, the cmdlet can be used to restore an exported version of the Central Management store. For example, suppose you export the configuration settings, you make a bunch of changes to Lync Server, and then you decide you don't like the changes that you made after all. If you wanted to, you could try to manually undo everything you just did. Alternatively, you could use a command like this to restore a previously-exported copy of your Lync Server settings:

Import-CsConfiguration -FileName "C:\Config.zip"

Note. We should probably point out that this is an all-or-nothing process: you can't restore just the settings for this particular component or just the external access policies that you created. Your entire Lync Server topology and all your Lync Server configuration settings and policy data are backed up, and all of those items are restored.

And no, there isn't an official way to backup and restore individual policies or settings. But we do have an unofficial way to do that.

Import-CsConfiguration is also useful when you're setting up an Edge server, a computer located outside your perimeter network. To help get your Lync Server settings copied to the Edge server, and to help get that computer integrated into the replication system, use Export-CsConfiguration to export your settings to a .ZIP file. Copy that .ZIP file to the Edge server, then use Import-CsConfiguration to import all those settings to the local store on that Edge server. (The local store is the locally-stored copy of the Lync Server settings.) After that's done, the Edge server will automatically begin replicating data with the rest of your servers. To import Lync Server settings to the local store (as opposed to the Central Management store), just tack the LocalStore parameter onto your command, like so:

Import-CsConfiguration -FileName "C:\Config.zip" -LocalStore

Incidentally, one way to test the use of these cmdlets is to do this (which is actually how we tested the use of these cmdlets):

1. Export the data to a .ZIP file using Export-CsConfiguration.

2. Create a new something. We created a new external access policy named TestPolicy.

3. Immediately import that .ZIP file using Import-CsConfiguration.

4. Check to see if the external access policy TestPolicy still exists; it shouldn't. Why not? Because TestPolicy wasn't included in the exported and imported data.

Something to think about anyway.

That's all we have time for today. But guess what? We've spent a few minutes with Export-CsConfiguration and Import-CsConfiguration and we're already feeling much, much better.

Although we suppose that the two bottles of vodka didn't hurt, either.

See you on Monday.