I just sent you an
Instant message. Are you there?
The first time the author of today's haiku ever used email was 20 years ago, when he entered graduate school at the University of Washington.
Note. Actually, we agree with you: it is hard to believe that someone who writes daily Lync Server PowerShell haikus for a living was able to get into graduate school at the University of Washington, isn't it? On the other hand, that was a long time ago; apparently the UW's standards weren't all that high way back then.
Email was quite new in those days, so new that students didn't automatically get assigned email addresses: you had to officially request an email address, and your adviser had to approve that request.
Note. Your adviser also was in charge of assigning you your email address. For some reason, the author's adviser thought that using your name, or some variation on your name, would be too hard for people to remember. Therefore, he assigned each of his students an email address based on his or her student number. As a result, for many years afterward the author was officially known as email@example.com.
Which was obviously much easier for him to remember than his own name.
As a very new and very revolutionary technology, email wasn't always trusted back then. For example, it was far from unusual for the author's phone to ring and, upon answering it, hearing something like this: "I just sent you an email it. Did you get it yet?" At that point, the caller would often go ahead and read the email over the phone, just in case the email had been received but was unreadable. When he worked for the UW School of Dentistry (and no, not as a dentist!) it was routine for anyone who received an email to print it out and store a copy of that message in their files; no one really believed that an email received today would still be available tomorrow. In fact, the author can recall one professor who would read email but not send email. If she received an email she would read it, print it out, type up a reply (yes, on a typewriter), put the original email and her reply in an envelope, and then mail her response back using regular "snail mail."
Ah, yes: the good old days.
It's been awhile since the author has gotten a phone call asking him if he received an email or not; nowadays, everyone just attaches a return receipt to their messages. However, he has gotten phone calls from people asking if he received their instant message. As it turns out, the author has the annoying habit of (gasp!) occasionally leaving his desk, and without taking his computer with him. (And at Microsoft, that qualifies as very suspicious behavior. On many occasions the author has seen, or at least heard, people in the bathroom typing away on their laptops.) In this day and age, people take the term instant message literally: if you don't respond instantly to a message, they assume you've been taken hostage by anti-technology guerillas or perhaps have had a heart attack and can't quite summon the strength to reply to their message. Either way, they immediately call to check up on you.
With Microsoft Lync Server 2010, however, you no longer have to worry about whether or not your instant messages are getting through: you can use the Test-CsIM cmdlet to verify that instant messaging is working the way it's supposed to.
Note. The Test-CsIM cmdlet is one of many "synthetic transaction" cmdlets included in Lync Server 2010. The term "synthetic transaction" refers to the fact that the cmdlet is running a pretend (synthetic) transaction: it's not sending a real instant message from user A to user B, but is, instead, verifying that all the steps required to send an instant message from user A to user B are working.
Like many of Lync Server's synthetic transaction cmdlets, Test-CsIM can be used in two different ways. If you just want to verify that the instant messaging subsystem is up and running, you can set up a pair of health monitoring test accounts for a pool (see New-CsHealthMonitoringConfiguration for more details) and use a command as simple as this:
Test-CsIm -TargetFqdn atl-cs-001.litwareinc.com
That command simply verifies that your two test users (who do not need to represent actual people) can exchange instant messages on the pool atl-cs-001.litwareinc.com.
Alternatively, you can use Test-CsIM to verify whether or not two actual users are able to exchange instant messages with one another. To do that, you need to create PowerShell credential objects (something you do using the Get-Credential cmdlet) for each user, which means you're going to have to know the logon name and the password for each user account. (With test users, you don't have to worry about passwords: all you have to do is make up SIP addresses for your two test accounts.) Assuming that you have credential information for each user, you can then use a set of commands similar to this to verify that, for example, Ken Myer and Pilar Ackerman can send instant messages to one another:
$cred1 = Get-Credential "litwareinc\pilar"
$cred2 = Get-Credential "litwareinc\kenmyer"
Test-CsIm -TargetFqdn atl-cs-001.litwareinc.com -SenderSipAddress "sip:firstname.lastname@example.org" -SenderCredential $cred1 -ReceiverSipAddress "sip:email@example.com" -ReceiverCredential $cred2
Or, we suppose, you could simply call Ken Myer and ask him to send an instant message to Pilar Ackerman, then call Pilar and ask her to send a message back to Ken Myer, then set up a conference call with both of them to verify that the messages were all dutifully sent and received. For some reason, however, we think that the Test-CsIM cmdlet offers a better way of doing things.
But, then again, is there anything in life that isn't best done using Lync Server PowerShell? We couldn't think of anything, either.