When is a Boolean Not a Boolean?

[NextHop_Team]

First published on TECHNET on Dec 08, 2010

If you've ever read Alice in Wonderland , you might recall the famous riddle posed by the Mad Hatter: "Why is a raven like a writing desk?" And that -- hmmm, that is an interesting question, isn't it? Why is a raven like a writing desk?

Of course, one reason why the riddle has become so famous is that in the book, the Mad Hatter never bothers to answer the riddle. Many years later Carroll himself explained why the Mad Hatter never bothered the answer the riddle: there was no answer to the riddle. According to Carroll "Enquiries have been so often addressed to me, as to whether any answer to the Hatter's Riddle can be imagined, that I may as well put on record here what seems to me to be a fairly appropriate answer, viz: 'Because it can produce a few notes, tho they are very flat; and it is never put with the wrong end in front!' This, however, is merely an afterthought; the Riddle, as originally invented, had no answer at all."

Well, here at the Lync Server PowerShell blog we like to consider ourselves the Lewis Carroll of the Microsoft Lync Server 2010 world. (Or at least the Windows PowerShell part of that world.) And that means that if Lewis Carroll can pose a riddle, well, by golly, we can pose a riddle, too. And here goes: When is a Boolean value not a Boolean value?

OK, maybe that's not quite as catchy as "Why is a raven like a writing desk?" On top of that, it's nowhere near as mysterious and challenging. After all, our riddle seems to have a pretty straightforward answer: there is no answer, because a Boolean value is always a Boolean value. In fact, if you do a quick search for the word Boolean you'll invariably find definitions similar to this:

"In computer science, the Boolean or logical data type is the most primitive data type, having one of two values (true or false), intended to represent the truth values of logic and Boolean algebra."

There you have it: a Boolean value is a data type that has two possible values: a Boolean value is either True or a Boolean value is False. As the immortal Ken Kesey used to say, you're either on the bus or you're off the bus.

Note . We should probably point out that Ken Kesey isn't truly immortal; he died back in the year 2001. Before he died, however, Kesey did write the novel One Flew Over the Cuckoo's Nest . The protagonist of that novel was a red-headed Irishman named Randle Patrick McMurphy. When the novel was made into an Academy Award-winning movie, McMurphy was played by, uh, Jack Nicholson.

Incidentally, as good as One Flew Over the Cuckoo's Nest was, the novel Sometimes a Great Notion was even better. Don't listen to what anyone else has to say, take it from us: Sometimes a Great Notion is better. Hey, if you can't trust the Lewis Carroll of the Microsoft Lync Server 2010 world who can you trust?

In other words, Boolean values are pretty straightforward: they're either True or they're False. So then when is a Boolean value not a Boolean value? Here's the answer to the riddle: When that Boolean value represents the Enabled attribute that gets added to Active Directory when you install Microsoft Lync Server.

Note . Or when it can produce a few notes, tho they are very flat; and it is never put with the wrong end in front! We'll accept either answer.

Let's see if we can explain what we mean when we say that the Boolean attribute Enabled is not a Boolean attribute. Up till now, we've been under the impression that the Enabled attribute, like all good Boolean attributes, can be either True or False: we've been assuming that the value is True if a user has been enabled for Lync Server and False if a user has not been enabled for Lync Server. And, the fact is, for most of the things you do with Lync Server PowerShell, you can act as though that really is the case. However, there's an exception to that general rule, an exception you should know about it.

As it turns out, the Enabled attribute actually has three possible values:

· If the user has been enabled for Microsoft Lync Server 2010 then his or her Enabled attribute is equal to True (or, in Windows PowerShell-speak, $True).

· If the user has had their Lync Server account temporarily disabled, then his or her Enabled attribute is equal to False ($False). What do we mean by "temporarily disabled?" Well, let's suppose we've enabled Ken Myer for Lync Server; that means his Enabled attribute is equal to True. We now run this command to temporarily disabled Ken's Lync Server account:

Set-CsUser -Identity "Ken Myer" -Enabled $False

At that point, Ken's Enabled attribute will be set to False. To restore his account, and set the Enabled attribute back to True, we need to run this command:

Set-CsUser -Identity "Ken Myer" -Enabled $True

· If the user is not enabled for Lync Server then his Enabled attribute is set to a null value ($Null). That's an important distinction. A null value means "no value at all." A False value is an actual value; it's just False rather than True. But because it is a real value, it's not a null value. And there's a difference.

That should clear everything up, eh?

Let's take a look at three users and then show you why this distinction is important:

User	Account Status	Enabled Attribute
Ken Myer	Enabled for Lync Server	$True
Pilar Ackerman	Lync Server account temporarily disabled	$False
April Reagan	Not enabled for Lync Server	$Null

Suppose we run the following command, which returns the value of the DisplayName and the Enabled attributes for all our Active Directory users:

Get-CsAdUser | Select-Object DisplayName, Enabled

In return we get back data that looks like this:

DisplayName Enabled

----------- -------

Ken Myer True

Pilar Ackerman False

April Reagan

OK, so far so good; all our users are there. Now we want to get back data just for users who have been enabled for Lync Server. That means we're going to run this command:

Get-CsAdUser –Filter {Enabled –eq $True} | Select-Object DisplayName, Enabled

In other words, this time we only want to get back information for users who have an Enabled attribute equal to $True: {Enabled –eq $True}. And if we run that command we should get back this:

DisplayName Enabled

----------- -------

Ken Myer True

The only information we get back this time is information about Ken Myer. Which is exactly what we should have gotten back. After all, Ken is the only user we have who's been enabled for Lync Server.

Now here's the part that could cause some confusion. Suppose we now want information about the users who have not been enabled for Lync Server. We know that the Enabled attribute is a Boolean value, and that Boolean values can either be True or False. Just a few seconds ago, to find all the users who have been enabled for Lync Server we used this command:

Get-CsAdUser –Filter {Enabled –eq $True} | Select-Object DisplayName, Enabled

Logically enough, we might then expect that the following command, which looks for user accounts where the Enabled attribute is equal to $False, will return all the users who have not been enabled for Lync Server:

Get-CsAdUser –Filter {Enabled –eq $False} | Select-Object DisplayName, Enabled

But guess what? It doesn't do that. Instead, this is what we get back:

DisplayName Enabled

----------- -------

Pilar Ackerman False

In this case, we get back just what we asked for: all the users where the Enabled attribute is False. What we didn't get back, however, is what we really wanted to get back: all the users who are not enabled for Lync Server. In our case, that would be April Reagan, the only user we have who hasn't been enabled for Lync Server. (Remember, Pilar Ackerman is enabled for Lync Server, but we've temporarily shut down her account.) We don't get back April Reagan because her Enabled attribute isn’t set to $False; instead, it's not set to anything at all (that is, it's equal to a null value). The returned data is a little deceiving, because we looked for users with an Enabled attribute equal to $False and we got back a collection of users who all have an Enabled attribute equal to $False. But we never should have looked for those users in the first place.

Instead, if you want to return all the Active Directory users who are not enabled for Lync Server, you need to use this command, which searches for accounts where the Enabled attribute is null:

Get-CsAdUser –Filter {Enabled –eq $Null} | Select-Object DisplayName, Enabled

That command returns April Reagan, and anyone else who hasn't been enabled for Lync Server:

DisplayName Enabled

----------- -------

April Reagan

See how that works and, equally important, why that works? If you've never been enabled for Lync Server, then your Enabled attribute is equal to a null value. That's also true if you were at one point enabled for Lync Server, but then had your account disabled by using the Disable-CsUser cmdlet:

Disable-CsUser "Pilar Ackerman"