You try it. I'm not

Gonna try it. Let's get Test

Device to try it.

 

One of the best television commercials of all time is Hey, Mikey, an ad for Life cereal. (Yes, there have been a number of great television commercials, like, say Hey, Mikey and … the other ones ….) In the ad, three boys are sitting at a table, staring at a new breakfast food: Life cereal. (Cue the ominous music.) The two older boys go back and forth:

 

"What's this stuff?"

 

"Some new cereal. It's supposed to be good for you."

 

"Did you try it?"

 

"No, I'm not gonna try it. You try it."

 

They finally decided to make little Mikey try it, which they assume will be a waste of time; after all, Mikey hates everything. As it turns out, though, Mikey likes it! Mikey eats the cereal, and everyone lives happily ever after.

 

Note. Well, unless you believe the urban legend that says that, several years later, Little Mikey died from eating Pop Rocks and then drinking a coke. (We were wondering the same thing: why do so many child actors engage in such wild and reckless behavior?)  We are happy to report, however, that this is just an urban legend: nobody, including Little Mikey, has ever died from eating Pop Rocks and drinking a coke.

 

Which is good, because that's what we had for breakfast this morning.

 

We don't know if the Microsoft Lync Server 2010 product team drew its inspiration from the Hey, Mikey ad (although we like to think they did), but it turns out that Lync Server has a built-in Little Mikey all its own: test devices. Suppose you and all your colleagues have the same Lync Phone Edition cell phone, and a new update has just been released for that phone. You like your cell phone, you need you cell phone, and your cell phone has been working just fine. As a result, things are likely to play out like this:

 

"What's that?"

 

"Some new cell phone update. It's supposed to be good for you."

 

"Did you try it?"

 

"No, I'm not gonna try it. You try it."

 

On TV, you could solve this problem by getting Mikey to try the update. In Lync Server, you do the same sort of thing: you have your test devices try the update.

 

Test devices are actually hardware devices (like cell phones) that Lync admins have specifically marked as test devices. By default, whenever you download new device updates for Lync Server, those updates are marked as "pending." What does that mean? That means that those updates will not automatically be installed on, say, everyone's cell phone. Instead, updates will be installed on only the appropriate test device. For example, suppose everyone in your organization has the new Litwareinc 597G cell phone. You take one or more of those 597G cell phones and mark them each as a test device. When you download the new update, it gets installed only on those test devices. That gives you a chance to use the phone and make sure that the update hasn't introduced any problems. Once you've given the update the thumbs-up, you can then mark that update as approved. In turn, the update can then be downloaded and installed in all your Litwareinc 597G cell phones.

 

And if the update does introduce problems? Then you don't mark it as approved. Instead, you use the Reset-CsDeviceUpdateRule cmdlet to reject the update as a whole, and to rollback the installation of that update on your test devices.

 

But device update rules will have to wait for another haiku on another day. Today we're only interested in the test devices themselves, which means that we're only interested in the CsTestDevice cmdlets: Get-CsTestDevice, New-CsTestDevice, Remove-CsTestDevice, and Set-CsTestDevice.

 

As it turns out, these cmdlets are pretty easy to use. For example, to mark a phone (or other hardware device) as a test device you don't have to do much more than run a command like this one:

 

New-CsTestDevice -Identity site:Redmond/Litwareinc597G -IdentifierType SerialNumber -Identifier "07823-A345"

 

What are we doing here? Well, obviously, we're using the New-CsTestDevice cmdlet to create a new test device. The Identity we use is a combination of the scope for the test device and a name for that device. Test devices can live at the global scope or the site scope; a device with the Identity site:Redmond/Litwareinc597G is simply a device with the name Litwareinc597G (we can give our test devices any name we want) that will be used in the Redmond site. Pretty straightforward.

 

We then have to use an identifier to uniquely specify that phone as a test device. In this case, we've used the serial number as the identifier:

 

-IdentifierType SerialNumber -Identifier "07823-A345"

 

Alternatively, we could also use the MAC address as an identifier. In that case, our command might look something like this:

 

New-CsTestDevice -Identity site:Redmond/Litwareinc597G -IdentifierType MacAddress -Identifier "01:02:03:04:05:06"

 

And what if we decide later on that we don't want to use this particular phone as a test device? That's fine; we just use the Remove-CsTestDevice cmdlet to remove the phone from the list of test devices:

 

Remove-CsTestDevice -Identity site:Redmond/Litwareinc597G

 

Note that this doesn't "hurt" the cell phone in anyway: the phone still works and it still runs the Lync Phone Edition software. It just no longer functions as a test device.

 

In other words, you can now safely download and test device updates in your organization, without worrying that a given update could cause mass chaos throughout the organization. Now the only thing that could cause mass chaos is if one of your users eats Pop Rocks, drinks a coke, and really does explode.

Note. Here's another candy-related urban legend for you. Allegedly, candy corn is the one candy that has never been advertised. Why not? Because all the candy corn in the world was made in 1911, and they don't want to draw attention to that fact.

 

So is that rumor true or false? To be honest, we suspect that it's false. On the other hand, having actually eaten candy corn before, well ….