Haiku #128

Who said you can’t teach an old dog new tricks? Well, whoever said it, they were absolutely right: you can’t teach an old dog new tricks. Go up to an old dog and try to teach him a new trick. The old dog will just arch an eyebrow, shake his head, and then go back to sleep. It can’t be done.

As it turns out, however, one thing that you can do is teach an old guy (such as the author of today’s haiku) a new word. And the new word for today is this: deduplication.

Deduplication – which we really wish was disduplication, so that we could say things like “You have disrespected my disduplication” – is the ” … process of examining a data set or byte stream at the sub-file level and storing and/or sending only unique data.” The idea is that you have several copies of something lying around, and deduplication helps you get rid of the duplicate copies. How exactly does that happen? Well, to tell you the truth, we don’t know. We only learned about deduplication because we got an invitation to sit in on an online seminar on the topic.

So did we sit in on that online seminar? Well, we thought about it, but then we realized that the whole idea of deduplication is that you have a bunch of people doing the same exact thing. Based on the sorts of things we do here at the Lync Server PowerShell blog, well, we don’t really have to worry too much about anyone duplicating our efforts.

For which Microsoft (and everyone else in the world) is grateful.

Note. As it turns out, however, there are a couple of other Web sites that bring you a haiku of the day, although we couldn’t find too many who bring you a Lync Server PowerShell haiku of the day. Here’s one of the haikus we discovered while searching for other haikus of the day:

in the deep of the woods a snake changes clothes

Admittedly, that could be about the Import-CsLegacyConferenceDirectory cmdlet, but we aren’t sure.

So what exactly are the CsPublicProvider cmdlets (and why are they so much more interesting than deduplication)? To answer that, let’s first explain what a public provider is. A public provider is simply an organization that provides instant messaging, presence, and related services to the general public. Lync Server 2010 ships with three public providers preconfigured but not enabled:

·MSN

·Yahoo!

·AOL

Note. Yes, these organizations were known as PIC (Public Internet Connectivity) providers back in the Office Communications Server 2007 R2 days. For Lync Server 2010, however, we’ve changed the name to public providers.

And now that you mention it, deplublic deproviders would have been a way cooler name, wouldn’t it? Maybe in the next version of Lync Server ….

Ah, good question: how do we know that Lync Server ships with these three public providers preconfigured but not enabled? Because we ran this command, and that’s what it told us:

Get-CsPublicProvider

If you’re wondering why these providers are preconfigured but not enabled, well, there’s actually a good reason for that: simply enabling these providers will not allow your users to start exchanging instant messages with people on Yahoo! or AOL. Instead, there’s a provisioning and licensing process that you must complete. How do you complete that process? We have no idea. But this document should explain things.

Assuming that you have completed the provisioning and licensing process, how do you then enable one of these public providers? Well, for some reason, there are two ways to do this. (Obviously a candidate for a little deduplication, eh?) For one, you can enable a public provider by using the Enable-CsPublicProvider cmdlet:

Enable-CsPublicProvider –Identity AOL

Alternatively, you can do the same exact thing by using the Set-CsPublicProvider cmdlet:

Set-CsPublicProvider –Identity AOL –Enabled $True

Does it make any difference? Not as far as we can tell, other than the fact that Enable-CsPublicProvider doesn’t require quite as many keystrokes.

If you later change your mind (or let your license expire or whatever), you can then use either of these commands to disable a public provider:

Disable-CsPublicProvider –Identity AOL

Set-CsPublicProvider –Identity AOL –Enabled $False

Again, it doesn’t matter which command you choose; they’ll both do the trick. We might point out, however, that, as a general rule, it’s probably better to disable a provider than to actually remove that provider. Why? Well, if you disable a provider then you can always re-enable that provider using a single command:

Enable-CsPublicProvider –Identity AOL

But suppose you delete a provider, using a command like this one:

Remove-CsPublicProvider –Identity AOL

If you do that, AOL will disappear completely from the list of public providers and the only way to get it back is to recreate that provider. If you’re positive you’ll never need that provider again, well, go ahead and delete it. If you aren’t sure, then simply disable the provider.

Note. Incidentally, Remove-CsPublicProvider is a bit different from most of the other Remove-Cs cmdlets. With Remove-CsPublicProvider you can actually delete all the default public providers; this command will remove all your public providers, including MSN, Yahoo!, and AOL:

Get-CsPublicProvider | Remove-CsPublicProvider

The only way to get those default providers back is to re-create them.

Speaking of creating new providers, can you create a new public provider? Of course you can:

The key here is the ProxyFqdn parameter: this is the fully qualified domain name of the proxy server used by the public provider. Proxy FQDNs must be unique: you can’t have two public providers (or even one public provider and one hosting provider) that share an FQDN. In addition, you can’t change the ProxyFqdn for a provider. Suppose Fabrikam switches to a different proxy server: proxyserver2.fabrikam.com. Although the Set-CsPublicProvider cmdlet enables you to modify an existing provider, that cmdlet won’t let you change the ProxyFqdn. Instead, you’ll have to create a brand-new provider using the new FQDN.

That’s just the way things work.

We might also mention the VerificationLevel property. This property determines how messages purportedly sent from this public provider are verified. You have three choices when it comes to the verification level:

·AlwaysVerifiable. All messages purportedly sent from this provider will be accepted. If a verification header is not found in the message it will be added by Lync Server 2010. This is the default value.

·AlwaysUnverifiable. All messages purportedly sent from a public provider are considered unverified. They will be delivered only if they were sent from a person who is on the recipient’s Contacts list. For example, if Ken Myer is on your Contacts list you will be able to receive messages from him. If Pilar Ackerman is not on your Contacts list then you will not be able to receive messages from her.

·UseSourceVerification. Uses the verification header added to the message by the public provider. If the verification information is missing the message will be rejected.

This property can be changed using the Set-CsPublicProvider cmdlet. For example:

That’s pretty much all there is to public providers. If you were thinking about writing your own haiku about public providers, well, we strongly encourage you to use our haiku instead. No point in duplicating efforts, and then having to deduplicate those efforts, right?

Note. Oh, OK, you talked us into it: if you want to write your own haiku about public providers go right ahead. Trust us, we understand why you’d by so anxious to do that yourself.