Haiku #157
Shall I compare thee
To almost one summer's day?
Test federation.
Well, it's July 21st, 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.
Note. So is this really the first time in his life that he was wrong about something? Well, it depends on who you ask. The author of today's haiku is almost positive that he was wrong about something else a long time ago; however, his wife insists that he has never been wrong about anything. If she's correct, that would mean he comes from an all-but mistake-free family: he's never made any mistakes, and his wife says she's only made one mistake in her life (although she adds, "But it was a doozy"). And no, the author of today's haiku has no idea what that one huge mistake could be.
No idea at all.
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.
Note. Which also puts us back on more-familiar ground. According to the National Weather Service, thus far in June and July the Seattle area has had 29 days where the temperature failed to reach 70 degrees, and two days when it failed to reach 60 degrees. But are we complaining? No sir, not us.
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!