1 2 3 4 5?

That's not an acceptable

Pin. Please try again.

 

We don't wish to alarm anyone, but we felt a duty to call your attention to this. As you may have heard, the Mayan calendar runs out on December 21, 2012. And the minute that calendar runs out, the world is destined to come to an end!

 

That's what we said: Eep.

 

Note. Why will the world come to an end just because the Mayan calendar doesn't go beyond December 21, 2012? Well, we're not really sure, although we have read that this might have something to do with the fact that 12/21/12 is the day that the mysterious Planet Nibiru is supposed to crash into the Earth. Now, admittedly, Nibiru was originally supposed to crash into the Earth back in 2003 and maybe it did: we don't always keep up with current events as well as we should. But when Nibiru crashes into the Earth in 2012 it's going to be bad, really bad.

 

Although, considering the rate at which our 401Ks continue to lose money, maybe it won't be all that bad after all.

 

If you know what we mean.

 

Of course, right now you're probably thinking, "Gosh, how can the authors of the Lync Server PowerShell blog save the Earth?" Well, to be perfectly honest, we can't: we're all doomed. What we can do, however, is help to make everyone's last few months on Earth as pleasant as possible. Suppose we had only a year or so left to live, we thought to ourselves. (Which, if the prophecy is correct, is all we do have left.) How would we like to spend that time? The answer, of course, was easy: we wanted to be with our families, relaxing on a tropical beach, and using the CsPinPolicy cmdlets (Get-CsPinPolicy, Grant-CsPinPolicy, New-CsPinPolicy, Remove-CsPinPolicy, and Set-CsPinPolicy) to manage dial-in PIN settings for Lync Server users. Needless to say, we figured you'd want to do the same.

 

Thus the reason for today's haiku. If you aren't sure what dial-in PIN policies are, or why you'd want to manage them, let's take one of our few remaining moments on Earth to explain. As you probably know, Lync Server provides a way for users to connect to the system and/or dial into audio conferences using any old telephone. As you also know, when you connect to Lync Server you typically need to provide a user name and password. Is that a problem? Well, not if you have a name like 546 82341. But suppose you have a name like Ken Myer (that is, a name that contains letters as opposed to numbers). In that case, that is a problem: entering alphabetic characters using a standard telephone keypad isn't all that easy. (You should see the author of today's haiku trying to send text messages to his son. It's not a pretty sight.) Therefore, Lync Server gives dial-in users the option of authenticating by using a PIN number; instead of entering a user name and password, dial-in users can type in a PIN number like this: 121989. That's a tad bit easier, to say the least.

 

So what do you need PIN policies for? Well, PIN policies enable you to place some restrictions on the PIN numbers that users can and cannot use. You know how you use password policies to prevent all your users from using a password like this one: password. Well, that's one reason to use PIN policies: it prevents all your users from using 12345 as their PIN number.

 

So what kind of restrictions can you impose using PIN policies? Well, for one thing, you can specify the minimum number of digits that must be used in a PIN.  By default, the global PIN policy requires you to have at least 5 digits in a PIN; a user who tries to use the PIN 9827 will have that PIN rejected. (Why? Because it only contains 4 digits.) The minimum number of digits can be set to any integer value between 5 and 24, inclusive. For example:

 

Set-CsPinPolicy –Identity global –MinPasswordLength 8

 

And then there's the AllowCommonPatterns parameter. When set to False, this setting prevents users from creating PINs that consist solely of repeating digits or consecutive digits. For example, a PIN like this will be rejected:

 

123456

 

So will a PIN like this one:

 

654321

 

However, you can use consecutive digits as long as you break the pattern in some way. In other words, this PIN will be allowed:

 

1234568

 

Why? Because while there are consecutive digits, the entire PIN does not consist of consecutive digits. The same thing  is true for repeating digits. This PIN will be rejected:

 

333333

 

This one will not:

 

333336

 

It's not super-duper password protection by any means, but it does help.

 

Oh, and here's how you allow/disallow common patterns:

 

Set-CsPinPolicy –Identity global –AllowCommonPatterns $False

 

You can also set an expiration date on PINs, meaning that users will have to periodically get a new PIN number (just like they periodically have to get a new password). To do that, you need to do two things:

 

·         Set the PinLifetime parameter to the number of days a PIN is valid before it expires. For example, setting PinLifetime to 90 means that the PIN will expire 90 days after it's issued.

·         Set the PinHistoryCount parameter to a value greater than 0. PinHistoryCount specifies how often a user can use the same PIN. For example, suppose PinHistoryCount is set to 2 and the user has the PIN 071267. When the user needs to refresh his or her PIN, they cannot reuse PIN 071267; they have to pick a different PIN. What happens the next time they need to refresh their PIN? Because this is the second time they've had to pick a new PIN they, again, cannot use 071267. However, the third time they have to select a new PIN they can reuse 071267. That's because the PinHistoryCount is set to 2. If that value was set to 10 they would have to wait until the 11th try before they could reuse a PIN.

If you set a value for the PinLifetime parameter then you must set PinHistoryCount to a value greater than 0.

 

Here's how all that might look:

 

Set-CsPinPolicy –Identity global –PinLifetime 30 –PinHistoryCount 5

 

Interesting Note. The PIN history applies to a PIN that a user chooses for himself (or herself) by going to the Dial-In Conferencing Web page. However, the PIN history count is not enforced if an administrator assigns the user a PIN. Suppose a user desperately wants to reuse PIN 071267. The Dial-In Conferencing Web page won't allow them to reuse the same PIN. (Assuming that PinHistoryCount is greater than 0.) However, an administrator can assign them that PIN, even if the PIN history count would seem to prohibit that:

 

Set-CsClientPin "Ken Myer" –Pin 071267

 

Note that administrators do have to abide by the minimum PIN length and the allow common patterns settings.

 

In case you're wondering, PIN policies can be assigned to the global, site, or the per-user scope. Use New-CsPinPolicy to create new policies and use Set-CsPinPolicy to modify existing policies. You can probably figure out for yourself what Get-CsPinPolicy, Grant-CsPinPolicy, and Remove-CsPinPolicy do.

 

Note. Just in case, Get-CsPinPolicy retrieves information about all your existing PIN policies; Grant-CsPinPolicy assigns a per-user PIN policy to one or more users; and Remove-CsPinPolicy deletes an existing PIN policy.

 

By the way, administrators cannot retrieve the actual PIN that has been assigned to a user; all you can do is determine whether or not a user currently has a PIN. Here's a command that returns the Identity of all the users currently assigned a PIN number:

 

Get-CsUser | Get-CsClientPinInfo | Where-Object {$_.IsPinSet –eq $True}

 

That's all we have for today. Again, we didn't mean to alarm anyone by revealing that the world is going to come to an end on December 21, 2012; we just felt that most people would prefer to hear that kind of news from the authors of the Lync PowerShell blog. And for those of you who remain skeptical, consider this: today's haiku is haiku number 72. What do you get if add the digits in 72 together? You get this:

 

7 + 2 = 9

 

What do you get if you add the digits in 12/21/12 together? See for yourself:

 

1 + 2 + 2 +1 + 1 + 2 = 9

 

Now, guess how many letters there are in PinPolicy? Coincidence? If it makes you feel better then, sure, it's all just a coincidence ….

 

But if you have a dentist appointment for December 22, 2012, well, you might consider rescheduling, if you know what we mean.