Abracadabra:

You can now find your contact.

AB Web query.

This past week, a British journalist and self-proclaimed friend of Harry Potter author J. K. Rowling (or "Jo," as he calls her) reported on an alternate ending to the series that Rowling allegedly considered and then rejected. It's an … interesting … ending to say the least, one that involves everything from some weird time-reversal spell that turns Voldemort back into a little kid to Harry's wife, Ginny Weasley, turning herself into a bird of paradise rather than face the prospect of growing old.

At any rate, our first thought was to take this British journalist at face value and accept his story as the true alternate ending to the Harry Potter. (And who could blame us? After all, in this day and age, who has more creditability than a British journalist?) However, in doing a little investigative work on our own, we soon discovered that J. K. Rowling had also considered other possible endings for the series. Take this one for example:

In one potential ending, Harry and Voldemort are battling in the parapets high atop Hogwarts Castle. "I will avenge my father's death!" Harry cries. "Harry!" responds Voldemort. "I am your father!" And then Hermione blows up the Death Star.

In another scenario that Rowling pondered, the battle against the Dark Forces has gone badly: Hogwarts is in ruins, and several minor, but lovable, characters are dead. Despondent, Harry is contemplating suicide: "I wish I had never been born!" he sobs. At that very moment, Dumbledore comes down from heaven and shows Harry that things would actually have been much worse if he'd had never been born. Reinvigorated, Harry defeats Voldemort and then rushes home to his family. The Wizard Building and Loan is saved, Dumbledore gets his wings, and everyone lives happily ever after.

Here’s another one. The battle appears lost when Voldemort waves his wand and Harry bursts into flames. Ron grabs a bucket of water and throws it on Harry. That puts out the fire, but some of the water splashes on Voldemort and causes him to melt. Voldemort's hold on the Dark Forces is broken, evil is banished from the world, and everyone sings a catchy little song. And then, just to make sure this sort of thing never happens again, Hermione blows up the Death Star.

Now, admittedly, any one of those would make for a pretty good ending. However, our favorite alternate ending is this one: Harry and Voldemort are locked in mortal combat. Harry knows that the only way he can win this battle is to get help: he needs to get hold of Ron and Hermione. But how can he do that? After all, he doesn't know Ron and Hermione's SIP addresses. And yes, that information is kept in the Address Book server, but how does Harry know if he can even contact the Address Book server, let alone retrieve information from it? Just when things look their bleakest, Harry calls upon the Test-CsAddressBookWebQuery cmdlet to verify that he can contact the Address Book server. When the test succeeds, he uses the Address Book server to locate Ron and Hermione and sends them an instant message. Ron and Hermione arrive on the scene, blow up the Death Star, and everyone lives happily ever after.

The End

Now, we know what you're thinking. You're thinking, "That's way too unbelievable. He's in the middle of a fight to the death, and we're supposed to believe that Harry Potter can run the Test-CsAddressBookWebQuery cmdlet? No way!"

Believe it or not, however, this isn't just your typical Hollywood smoke-and-mirrors. For example, let's assume that Harry has set up some health monitoring test accounts for his Lync Server Registrar pool. (As best we can recall, this was something he did do back in Harry Potter and the Prisoner of Azkaban.) Assuming he did set up these test accounts then he can verify his ability to connect to the Address Book server Web service by using a command as simple as this:

Test-CsAddressBookWebQuery –TargetFqdn "atl-cs-001.litwareinc.com"

Obviously anyone could find time to do something as simple as that regardless of whether or not you were in the middle of a fight to the death. And what if you wanted to know if the Address Book contained an entry for a particular user? That's also easy: all you need to do is tack on the TargetSipAddress parameter followed by the SIP address of the user you're looking for. For example, this command queries the Address Book server for the user sip:kenmyer@litwareinc.com:

Test-CsAddressBookWebQuery –TargetFqdn "atl-cs-001.litwareinc.com" –TargetSipAddress "sip:kenmyer@litwareinc.com"

If Ken Myer is in the Address Book you'll get back output similar to this:

TargetUri  : https://atl-cs-001.litwareinc.com/groupexpansion/service.svc

TargetFqdn : atl-cs-001.litwareinc.com

Result     : Success

Latency    : 00:00:00.0605769

Error      :

Diagnosis  :

And if Ken Myer isn't in the Address Book then you'll get back something similar to this:

TargetUri  : https://atl-cs-001.litwareinc.com/groupexpansion/service.svc

TargetFqdn : atl-cs-001.litwareinc.com

Result     : Failure

Latency    : 00:00:00

Error      : Address Book Web service request has failed with response code

             NoEntryFound.

Diagnosis  :

OK, but suppose Harry didn't set up test accounts for his pool. (Or, more likely, suppose Neville accidentally deleted those test accounts.) That's fine. As long as you have a user name and password, you can run Test-CsAddressBookWebQuery under alternate credentials, like so:

$cred1 = Get-Credential "litwareinc\kenmyer"

Test-CsAddressBookWebQuery -TargetFqdn atl-cs-001.litwareinc.com -UserCredential $cred1 -UserSipAddress "sip:kenmyer@litwareinc.com"

As you can see, we start off by using the Get-Credential cmdlet to create a PowerShell Credentials object for the user litwareinc\kenmyer. (That has to be a valid user name, and you must know – and supply – Ken Myer's password when creating this object.) We then need to pass that Credentials object as the parameter value for the UserCredential parameter, and pass Ken's SIP address as the parameter value for the UserSipAddress parameter.

And what if we wanted to look for a specific user? That's fine; simply include the TargetSipAddress parameter, just like we did before:

Test-CsAddressBookWebQuery -TargetFqdn atl-cs-001.litwareinc.com -UserCredential $cred1 -UserSipAddress "sip:kenmyer@litwareinc.com" –TargetSipAddress "sip:packerman@litwareinc.com"

It's so easy, even a Muggle could do it!

Some of you seem a little confused; after all, didn't we just do a haiku about testing the Address Book service a week or so ago? As a matter of fact, we did. However, in that case we used the Test-CsAddressBookService cmdlet, which tests the ability of a user to connect to an Address Book server and locate copies of the Address Book files which can be downloaded to the local computer. Test-CsAddressBookWebQuery, by comparison, tests the ability of a user to connect to the Address Book Web service. The difference? With the downloaded files approach, users search for contacts using a copy of the Address Book that has been copied to their local computer. With the Web service, users search for contacts by using the Web service to search the Address Book itself. There are two different ways to search the Address Book, which means we need two different cmdlets to test the Address Book service.

At any rate, that should do it for today, and for this week: after all, it is Friday. If you haven't already done so, we'd encourage you to take some time this weekend and go see Harry Potter and the Deathly Hallows: Part II. It's not a bad movie, and the way it ends – with Harry, Thelma, and Louise driving off a cliff – well, trust us: we did not see that coming. Not at all.

See you Monday.

Shall I compare thee

To almost one summer's day?

Test federation.

Well, it's July 21^st, it's 57 degrees outside, and it's raining – again. But we have good news for everyone: despite all that, the author of today's haiku is not going to waste your time complaining about the weather and whining about the lack of summer here in the Seattle area. Is that because he finally realized that people would rather read about Lync Server PowerShell than listen to his bellyaching? Well, to be honest, that reason never occurred to him, although it is a pretty good reason. No, the reason he's not going to waste your time complaining about the weather is this: it turns out that, for the first time in his life, he was wrong about something.

At any rate, after complaining – repeatedly – that there has been no summer here in Seattle, it turns out that the author of today's haiku was wrong: there has been a summer here after all. A local meteorologist recently went through the minute-by-minute weather statistics for the entire year, looking for "summer moments;" by his definition, a summer moment was any time of the day when the temperature was at or above 80 degrees. By that reckoning, it turns out that the Seattle area has had a summer: 78 minutes worth, to be exact.

And yes, that is almost an hour and a half.

And what if you lower your standards a bit? (Interesting note: the author of today's haiku remembers hearing his wife use that phrase earlier today as well.) Well, if you look for moments when the temperature has been 75 degrees or warmer, the numbers climb dramatically: by that definition, the Seattle area has experienced nearly 16 hours of summer! 16 hours; two-thirds of a day. No wonder it feels so good to have cooler temperatures and a little rain this morning.

Of course, the big question is really this: other than being wrong about Seattle not having a summer, what other mistake could the author of today's haiku have ever made? And here's your answer: it took him forever to finally get around to talking about the Test-CsFederatedPartner cmdlet. But he's making up for that right now.

As you might have guessed, the Test-CsFederatedPartner cmdlet provides a way for you to verify connectivity with a federated domain. (A federated domain, of course, is simply a domain that your users can communicate with, and exchange presence information with, in pretty much the exact same way your users can communicate with, and exchange presence information with, other people in your own domain.)

That's good; even better is the fact that Test-CsFederatedPartner is remarkably easy to use. For example, suppose you reside in the litwareinc.com domain, and you have set up federation with the fabrikam.com domain. How can you verify that this federation connection is still up and running? Like this:

Test-CsFederatedPartner -TargetFqdn accessproxy.litwareinc.com -Domain fabrikam.com

Like we said, remarkably easy. All we have to do is include the TargetFqdn parameter followed by the fully qualified domain name of our Edge server, as well as the Domain parameter followed by the FQDN of the federated domain. (And yes, you can only run this command against federated domains. If you try running it against a random domain, a domain you are not federated with, the command will fail.)

That's all you have to do and, to be honest, that's pretty much all you can do with the Test-CsFederatedPartner cmdlet. But here's a bonus command for you anyway, just for the heck of it. This one retrieves all the domains included on your Allowed Domains list (that is, the domains you are federating with) and runs Test-CsFederatedPartner against each one of those domains:

Get-CsAllowedDomain | ForEach-Object {Test-CsFederatedPartner –TargetFqdn accessproxy.litwareinc.com –Domain $_.Identity}

As you can see, we called Get-CsAllowedDomain to return a collection of allowed domains, and then piped that collection to the ForEach-Object cmdlet; in turn, ForEach-Object then ran the Test-CsFederatedPartner cmdlet against each domain in the collection. Why didn't we just pipe the allowed domains directly to Test-CsFederatedPartner, something like this:

Get-CsAllowedDomain | {Test-CsFederatedPartner –TargetFqdn accessproxy.litwareinc.com –Domain $_.Identity

Well, believe it or not, we actually had a good reason not to use a command like that one: it won't work. That's because the Test-CsFederatedPartner cmdlet can't accept pipelined input:

Test-CsFederatedPartner : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input.

Because of that, we use the good old-fashioned ForEach-Object workaround instead.

And that's pretty much all she wrote (or at least all we wrote) when it comes to the Test-CsFederatedPartner cmdlet. Not only that, but the temperature has climbed all the way to 61 degrees, and the rain has devolved into a sort of misty drizzle kind of thing. Obviously we have nothing to complain about here!

Mom says that we have

To tell everyone about

Policy profiles.

We thought we'd try something a little different today: today we're going to randomly select one of the many emails sent in by our devoted readers and see if we can answer the reader's question by writing a haiku; this is our way of trying to give everyone what they really want. Let's see what we have here:

"The Lync Server PowerShell blog is a travesty. This is by far the worst example of – "

Um, never mind. As it turns out, that mail was sent by a family member, and it wouldn't seem sporting (or ethical) to use something sent by a family member.

Let's try another one:

"I cannot believe that this is what Microsoft pays you to do. As far as I'm concerned – "

Hmmm …. Apparently Steve Ballmer isn't the soft-spoken guy we always assumed he was. OK, let's try a – whoa. Never mind about that one.

OK, by now it should be pretty obvious what everyone really wants: everyone really wants us to address the CsNetworkBandwidthPolicyProfile cmdlets!

So what exactly is a network bandwidth policy profile, and why do we need cmdlets to manage these policy profiles? Good question. As you probably know by now, in Lync Server 2010 Microsoft introduced Call Admission Control, the ability to place bandwidth usage restrictions on all (or some) of your network connections. We won't go into all the whys and wherefores of Call Admission Control today; if you need that sort of background information, take a look at the article Call Admission Control in Lync Server.

What we will tell you is that bandwidth policies are used to determine the amount of bandwidth that can be used for audio and/or video transmissions. These policies let you place two different kinds of restrictions on bandwidth use: you can limit the total bandwidth allocated for all audio/video sessions, and you can limit the amount of bandwidth allocated for a single session. For example, you might decide that an individual audio session will be allowed 100 kilobits per seconds (kbps) of bandwidth use, while a grand total of 1000 kbps will be allocated for all the current audio sessions. What does that mean? Well, suppose you have 10 audio sessions going on right now, each using the allotted 100 kbps. 10 audio sessions times 100 kbps equals 1000 kbps, the total amount of bandwidth allocated for audio. Suppose that user no. 11 now tries to make an audio call. Is that call going to go through? Nope; there's no bandwidth available for audio sessions. User no. 11 is going to have to wait for an existing session to end before he or she can place the call.

Make sense? We thought it would.

Bandwidth policies are assigned to your network sites; for example, this command assigns the policy LowBWLimits to the Vancouver site:

Set-CsNetworkSite -Identity Vancouver - BWPolicyProfileID LowBWLimits

And how did we create that bandwidth policy in the first place? Like this:

New-CsNetworkBandwidthPolicyProfile -Identity LowBWLimits -AudioBWLimit 2000 -AudioBWSessionLimit 200 -VideoBWLimit 1400 -VideoBWSessionLimit 500

As you can see, we simply called the New-CsNetworkBandwidthPolicyProfile cmdlet, gave our new policy an identity (LowBWLimits), and then assigned values to the individual session and total session parameters for both audio and video. If we now run the command Get-CsNetworkBandwidthPolicyProfile, we should see the following:

Identity          : LowBWLimits

BWPolicy          : {BWLimit=2000;BWSessionLimit=200;BWPolicyModality=Audio,

                    BWLimit=1400;BWSessionLimit=500;BWPolicyModality=Video}

BWPolicyProfileID : LowBWLimits

Description       :

Actually, that is kind of hard to read, isn't it? OK, try this command instead:

Get-CsNetworkBandwidthPolicyProfile | Select-Object –ExpandProperty BWPolicy

That will give you output that looks like this:

BWLimit          : 2000

BWSessionLimit   : 200

BWPolicyModality : Audio

BWLimit          : 1400

BWSessionLimit   : 500

BWPolicyModality : Video

Much better. Right, Mom?

That's actually pretty straightforward. Unfortunately, it now starts to get a little bit tricky. Why? Well, suppose you want to change the audio bandwidth to 2200, but want to leave everything else exactly as-is. Logically enough, you'd probably run this command:

Set-CsNetworkBandwidthPolicyProfile -Identity LowBWLimits -AudioBWLimit 2200

Is that going to work? Well, it depends on your definition of "work." Here's what your bandwidth policy profile will look like now:

Identity          : LowBWLimits

BWPolicy          : {BWLimit=2200;BWSessionLimit=175;BWPolicyModality=Audio}

BWPolicyProfileID : LowBWLimits

Description       :

Uh-oh. As you can see, the audio bandwidth limit got bumped up to 2200, just like we wanted. However, the audio session limit got switched to 175, and the video settings disappeared altogether. What's the deal here?

Well, the deal here is that the Set-CsNetworkBandwidthPolicyProfile cmdlet always replaces the entire policy with whatever parameters you gave it. We gave Set-CsNetworkBandwidthPolicyProfile just one parameter: AudioBWLimit. Therefore, it essentially created a brand-new policy, one with a limit of 2200 (as we asked) and a session limit of 175 (the default value, which is used because we didn't specify a session limit). And what happened to the video settings? Well, we didn't include any video settings, so Set-CsNetworkBandwidthPolicyProfile … helpfully … removed all those settings from the policy.

Thanks, Set-CsNetworkBandwidthPolicyProfile.

So is there a way to work around that? To the best of our knowledge, no, there isn't. If you want to make one little change to an existing policy you have to be sure to also include all the settings and values that you don't want changed:

Set-CsNetworkBandwidthPolicyProfile -Identity LowBWLimits -AudioBWLimit 2200 -AudioBWSessionLimit 200 -VideoBWLimit 1400 -VideoBWSessionLimit 500

Is that a hassle? Yes. But, then again, you probably won't be changing your bandwidth policy profiles very often, so ….

If you decide you don't need a bandwidth policy profile after all, you can simply delete that profile by using Remove-CsNetworkBandwidthPolicyProfile:

Remove-CsNetworkBandwidthPolicyProfile -Identity LowBWLimits

And if you have a desire to do something really weird, try these commands:

$x = Get-CsNetworkBandwidthPolicyProfile -Identity LowBWLimits

$x.BWPolicy.RemoveAt(1)

$x.BWPolicy.RemoveAt(0)

Set-CsNetworkBandwidthPolicyProfile –Instance $x

What do those commands do? Well, after creating an object reference ($x) to the policy profile LowBWLimits, they then use the RemoveAt method to remove the second policy in the profile (the video settings) and then the first policy in the profile (the audio settings).

That will give you an "empty" policy profile:

Identity          : LowBWLimits

BWPolicy          : {}

BWPolicyProfileID : LowBWLimits

Description       :

Why would you ever want to do that? We have no idea; we just wanted to show off for Mom. Mom, did you see what we did? Mom? Mom, are you watching?

Dang.

Oh, one other note: we also recommend that you use the CsNetworkBandwidthPolicyProfile cmdlets instead of the New-CsNetworkBWPolicy cmdlet. You can pretty much do the same thing with either the CsNetworkBandwidthPolicyProfile cmdlets or the New-CsNetworkBWPolicy cmdlet. But, for the most part, the CsNetworkBandwidthPolicyProfile cmdlets are much easier to work with. (And, besides, the New-CsNetworkBWPolicy cmdlet is really intended for future use, when additional types of bandwidth policies might be available to you.)

That's pretty much all we have for today. A special thanks to Mom, Steve Ballmer, and everyone else for your words of … encouragement …. Keep those cards and letters coming in!

We'll have fun, fun, fun,

Till daddy takes our Hosting

Provider away.

In case you were wondering (and we assume that you were wondering) yesterday something different happened to the author of today's haiku: he actually had some fun!

OK, good point: seeing as how he works at Microsoft and gets to deal with the Microsoft bureaucracy day-in and day-out, well, obviously he has fun every day. But yesterday he managed to have even more fun than usual.

Yesterday the author of today's haiku went for a bike ride after work. His intrepid party started down one bike trail, only to discover that the trail is closed for maintenance and upgrading. For those of you keeping score, that's now the third major bike trail the author of today's haiku has tried to go down, only to discover that the trail is closed for the summer.

At any rate, having been turned away from yet another bike trail, the author and his wife next set their sights on riding up Mt. Rainier, elevation 14,411 feet. Admittedly, it's possible that it wasn't really Mt. Rainier they were riding up; it just seemed that way as they continued to slog – slowly – up a long, reasonably steep hill that never seemed to end. And hey, if that isn't fun, we'd like to know what is!

Oh, wait: now that we think about it, going up wasn't the fun part: coming down that hill was the fun part. Fortunately for everyone involved, there was essentially no traffic on the trail at that time, which meant that the author and his wife were free to just let 'er rip and go zipping down the mountain. That was fun.

At any rate, after all the fun and excitement he had yesterday, you might think coming in to work this morning would be a letdown. Ha! Barreling down a mountainside on a bike is fun, but that's nothing compared to writing a haiku about the CsHostingProvider cmdlets (Disable-CsHostingProvider, Enable-CsHostingProvider, Get-CsHostingProvider, New-CsHostingProvider, Remove-CsHostingProvider, and Set-CsHostingProvider).

So what exactly are the CsHostingProvider cmdlets used for and, while we're on the subject, what exactly is a hosting provider? Well, a hosting provider is simply an organization that provides SIP communication services for other organizations; for example, Fabrikam Hosters might host users from Contoso, Northwind Traders, and Wingtip Toys. That's nice, but the cool thing about hosting providers is this: when you establish a federation relationship with a hosting provider you establish federation with all the organizations hosted by that provider. For example, if you federate with Fabrikam your users will be able to exchange instant messages and presence information with users from Contoso, Northwind Traders, and Wingtip Toys.

You can see why we find the CsHostingProvider cmdlets to be so much more fun than bike riding.

Hosting providers are also used in split domain scenarios. What's a split domain scenario? Well, for our purposes, a split domain scenario is simply one in which some of your Lync Server 2010 users have accounts hosted on-premises (that is, hosted on your local implementation of Lync Server) while other users have their accounts maintained off-premises by the third-party hosting provider. Federating with the hosting provider enables on-premises and off-premises users to communicate with one another. The primary example of that? You got it: Office 365.

Now, admittedly, the whole idea of hosting providers and split domain scenarios and all those other good things are still somewhat in their infancy; it's going to take a while before the industry begins to take advantages of these new capabilities built into Microsoft Lync Server 2010. In the meantime, though, you can definitely use the New-CsHostingProvider cmdlet to set up federation with Office 365. How? Well, after enabling federation, period (see Haiku #83 for more information), you can connect to Office 365 by running the following PowerShell command:

New-CsHostingProvider –Identity LyncOnline –ProxyFqdn sipfed.online.lync.com –Enabled $True

Yep, that's it: you call New-CsHostingProvider, you specify an identity and a proxy FQDN (the fully qualified domain name of the proxy server used by the hosting provider), and set the Enabled property to True. It's as easy as riding a bike down a hill.

Except you don't have to slam on your brakes at the bottom when you realize there's a cross street filled with speeding cars down there.

Ah, good question: what are the other 16 million CsHostingProvider cmdlets for? Well, the Set-CsHostingProvider cmdlet lets you modify the property values of an existing provider. However, there's one very important caveat here: you can't modify the ProxyFqdn for a provider. Suppose LyncOnline decides to change its proxy FQDN to newsipfed.online.lync.com. How do you change the proxy FQDN for LyncOnline? You don't. Instead, you'll have to remove the old provider and create a new one, like so:

Remove-CsHostingProvider –Identity LyncOnline

New-CsHostingProvider –Identity LyncOnline –ProxyFqdn newsipfed.online.lync.com –Enabled $True

Why do you have to do it that way? Beats us; you just do. But, on the bright side, now you know what the Remove-CsHostingProvider cmdlet is for.

You probably also know what the Get-CsHostingProvider cmdlet is for, too: it lets you retrieve information about the hosting providers configured for use in your organization. For example, this command returns information about all your hosting providers:

Get-CsHostingProvider

Not impressed? Then how about this command, which lets you know which hosting providers have been created, but are not currently enabled:

Get-CsHostingProvider | Where-Object {$_.Enabled -eq $False}

We thought you'd like that one. And this command shows you which hosting providers (if any) are used to host Microsoft Lync users:

Get-CsHostingProvider | Where-Object {$_.HostsOCSUsers -eq $True}

OK. Then what are Disable-CsHostingProvider and Enable-CsHostingProvider used for? Well, obviously you can use these cmdlets to disable/enable a hosting provider. For example:

Disable-CsHostingProvider –Identity LyncOnline

Enable-CsHostingProvider –Identity LyncOnline

What's wrong with that? Nothing. However, we should point out that you can do the same exact thing by using the Set-CsHostingProvider cmdlet instead:

Set-CsHostingProvider –Identity LyncOnline –Enabled $True

Set-CsHostingProvider –Identity LyncOnline –Enabled $False

So does that mean we have two different ways to enable/disable a hosting provider, yet no way to change the proxy FQDN of a hosting provider? Yes, that's exactly what this means. But take heart: there's a bright side to having things set up this way.

We just don't have any idea what that bright side might be.

But that's a very minor quibble, and nothing to worry about. The important thing is that you've got your CsHostingProvider cmdlets, you’ve got the wind in your hair, and you're having the most fun you've ever had in your life.

See you tomorrow.

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.

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.

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.

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 ….