Skype for Business Blog

4 MIN READ

Dealing with Information Overload, Part 1

Brass Contributor

May 20, 2019

First published on TECHNET on Jul 01, 2010

Displaying Select Microsoft Lync Server 2010 Property Values

Here’s a rhetorical question for you: although you hear the phrase “information overload” all the time, does anyone know what that term actually means ? Well, after doing a little research, we managed to come up with a pretty good example of information overload. In the late 1880s the US War Department decided to transcribe all its personnel records – dating back to the Revolutionary War – onto index cards. Within a few years, several hundred clerks were busily at work in Ford’s Theater in Washington DC, copying information onto index cards. Some 30 million index cards later, disaster struck: three floors of the theater collapsed, and 22 clerks were crushed to death.

And you think you have problems dealing with too much information.

Note . So did that really happen? Well, kind of. The War Department really did try transcribing all its personnel records onto index cards, and several floors in Ford’s Theater really did collapse and kill a number of clerks. As it turns out, however, it wasn’t so much the weight of the index cards that was responsible for the collapse; instead, it was the fact that construction workers who were renovating the basement removed portions of the foundation without providing adequate support.

In other words, the building was going to collapse anyway, index cards or no index cards. But telling you that would have ruined a perfectly good example of information overload.

Information overload can be a problem in Microsoft Lync Server 2010 as well. (Although, to the best of our knowledge, Lync Server’s information overload has never collapsed three floors of a theater.) For example, suppose you run this simple command to return information about the user Ken Myer:

Get-CsAdUser –Identity "Ken Myer"

Do that and you’ll get back something that looks like this:

SamAccountName : kenmyer

Sid : S-1-5-21-1573807623-1597889489-1765977225-1235

SidHistory : {}

PasswordLastSet : 6/14/2010 6:06:00 PM

UserAccountControl : NormalAccount, DoNotExpirePassword

UserPrincipalName : kenmyer@Litwareinc.com

PrimaryGroupId : 513

Id : CN=Ken Myer,CN=Users,DC=Litwareinc,DC=com

AltSecurityIdentities : {}

Assistant :

Company : LitwareInc

CountryOrRegionDisplayName :

Department : Finance

Fax :

FirstName : Ken

HomePhone :

Initials :

LastName : Myer

CountryAbbreviation : US

City : Redmond

CountryCode : 0

Description : {}

EmployeeId :

Info :

IPPhone :

MiddleName :

Manager :

MobilePhone :

Office :

OtherFax : {}

OtherHomePhone : {}

OtherMobile : {}

OtherIPPhone : {}

OtherPager : {}

OtherTelephone : {}

Pager :

PostalCode : 98052

PostOfficeBox : {}

PreferredLanguage :

StateOrProvince : WA

Street :

StreetAddress :

Title : Accountant

Url : {}

WindowsEmailAddress :

ObjectCategoryCN : person

DisplayName : Ken Myer

AddressListMembership : {}

Phone :

WebPage :

ProxyAddresses : {sip:kenmyer@litwareinc.com}

TenantId : 00000000-0000-0000-0000-000000000000

SipAddress : sip:kenmyer@litwareinc.com

CSEnabled : True

Name : Ken Myer

DistinguishedName : CN=Ken Myer,CN=Users,DC=Litwareinc,DC=com

Identity : CN=Ken Myer,CN=Users,DC=Litwareinc,DC=com

Guid : e715038a-3639-44be-aefb-690307289e1e

ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=Litwareinc,DC=com

ObjectClass : {top, person, organizationalPerson, user}

WhenChanged : 6/14/2010 2:44:14 PM

WhenCreated : 6/14/2010 11:06:00 AM

OriginatingServer : DC.Litwareinc.com

IsValid : True

ObjectState : Unchanged

That’s what we said: wow.

Needless to say, that’s a lot of information to wade through, especially if all you really wanted to know about Ken was:

· His Active Directory display name

· The department he works for

· His job title

· Whether or not his account has been enabled for Lync Server

Even worse, suppose you wanted to return these same four attribute values – display name; department; job title; and Lync Server account-enabled status – for all 987 of your users? That’s what we said: ouch. Trying to make sense of all that information probably wouldn’t collapse a theater and kill 22 clerks, but it wouldn’t be all that much fun, either.

The truth is, there are times when Lync Server presents us with a classic case of too much information. So is there any way to work around the fact that you sometimes get back way more information than you really need? Did you even have to ask? Of course there are some things you can do to limit the amount of information you get back when running a Lync Server cmdlet. And, with a tip of the hat to Dr. Seuss, here’s Thing One: Using Select-Object.

Using Select-Object

Now that we have you all excited about how to limit the information returned by a Lync Server cmdlet we’re going to switch gears and go off on a bit of a tangent: before we do anything else we’re going to talk about how Windows PowerShell decides which property values should be displayed any time you run a cmdlet.

Note . What if you don’t want to know how Windows PowerShell decides which property values should be displayed any time you run a cmdlet? Then just skip ahead to the section titled OK, This Time We Mean It: Using Select-Object .

If you don’t skip ahead, well, you have only yourself to blame, we told you that you could.

To explain what happens when Windows PowerShell displays property values, let’s take a closer look at the Get-Process cmdlet. If you want to play along at home, start Notepad, then type the following at the Windows PowerShell prompt and press ENTER:

Get-Process notepad

You should get back something that looks a little like this:

Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName

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

67 8 252 7360 77 0.12 3048 notepad