Haiku #155

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.

 

Note. What's that? You wonder if maybe they just put up the Trail Closed sign when they see him coming, then take it back down as soon as he turns around and heads off in another direction? Nah, they wouldn't – hmmm ….

 

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.

 

Note. Interestingly enough, it turns out that the author of today's haiku is incredibly good at coasting, at just sitting there doing nothing; he definitely has a knack for going downhill, straight downhill, until he reaches rock bottom.

 

Oh, and he can do that on a bike, too.

 

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

 

Note. That's true, by the way: barreling down a mountainside on a bike really can't be compared to sitting around writing a haiku about the CsHostingProvider cmdlets. Not even close.

 

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.

 

Note. Well, up till now anyway. But just wait until we talk about the New-CsWebTrustedCACertificate cmdlet; that is going to be one wild and crazy day. Guaranteed!

 

See you tomorrow.