Haiku #50
Hope springs eternal.
Let's hope this is all working.
Health monitoring.
The optimist proclaims that we live in the best of all possible worlds, and the pessimist fears this is true.
-- James Branch Cabell
By and large, system administrators tend to be pessimists. Is the glass half empty or is the glass half full? System administrators don't really care; all they want to know is how the heck that glass got in here in the first place. If things are going bad, well, then things are going bad. (Which isn't good.) And if things are going good? That's not much consolation; after all, system administrators fully expect that things will start going bad soon enough.
Note. Our favorite system administration-related quote? It's probably this one: "Computers don't make errors. What they do they do on purpose."
Or maybe this one: "Failure is not an option. It's included in the software."
On the other hand, and now that we've given this a little thought, we're beginning to think that system administrators aren't pessimists after all.
Note. Shouldn't we have thought about that before writing an opening paragraph that said that system administrators are pessimists? Hey, we're technical writers; thinking is not our strong suit.
Instead, we're beginning to think that maybe system administrators are just a little insecure. Yes, right now everything seems to be working just fine, but how do they know that things are working just fine? Is everything truly OK, or is it just that no one has called to complain yet? System administrators aren't necessarily pessimists, but they do need a little reassurance from time-to-time.
So how can you help an insecure system administrator, particularly an insecure Microsoft Lync Server 2010 administrator? Well, while searching the Internet we found a number of organizations that will call you every day and reassure you that everything is OK. That seemed like a pretty good idea, except we weren't convinced that system administrators would take the word of some stranger who called and tried to convince them that everything was OK. (Did we mention that system administrators are skeptics, too?) Therefore, we came up with an even better idea: synthetic transactions.
A synthetic transaction is just a way to test some feature of Lync Server and get some reassurance that the feature in question is working as expected. For example, you can use the Test-CsIm cmdlet to verify that instant messaging is working; likewise, the Test-CsRegistration cmdlet lets you know that users are able to log on to Lync Server. These tests are known as synthetic transactions because (with one or two exceptions) they aren't real transactions; that is, you don't have a real user send a real instant message to another real user. Instead, the cmdlets simulate the process in order to make sure that all the underlying plumbing is working as expected.
Note. What's that? You say you'd be interested in knowing what synthetic transactions are available in Lync Server 2010? That's cool. For a list of the synthetic transaction cmdlets, and a brief description of what each of those cmdlets does, just run this command:
Get-Help "Test-Cs*" | Select Name, Synopsis | Format-List
In general, a synthetic transaction can be run in one of two ways. For one, you can run the test using a real user account (or, depending on the cmdlet, two real user accounts). There's nothing wrong with that: it works just fine, and it doesn't interference with anything that the real real user might be doing. For example, you can run a test using Ken Myer's account even if Ken is currently logged on to the system and involved in a conference or instant messaging session. Ken will never even know that his account has been used to conduct this test.
That works great, and is especially useful if Ken Myer happens to call and say that he can't log on to the system: in that case, you could use the Test-CsRegistration cmdlet to see if you can figure out why he can't log on to the system. However, if you use a real user account in a synthetic transaction you have to supply both the user name and the password for that account. If you don’t know Ken Myer's password then you can't use his account with one of the Test-Cs cmdlets.
Which, as you might expect, brings us to option 2: health monitoring accounts. The CsHealthMonitoringConfiguration cmdlets (Get-CsHealthMonitoringConfiguration, New-CsHealthMonitoringConfiguration, Remove-CsHealthMonitoringConfiguration, and Set-CsHealthMonitoringConfiguration) allow you to configure a pair of test accounts for a Registrar pool or a Director pool. Once you've done that, you can run your tests using those preconfigured accounts, without having to supply any user names or any passwords. Here's an example that employs two real user accounts in order to test instant messaging:
$cred1 = Get-Credential "litwareinc\pilar"
$cred2 = Get-Credential "litwareinc\kenmyer"
Test-CsIm -TargetFqdn atl-cs-001.litwareinc.com -SenderSipAddress "sip:pilar@litwareinc.com" -SenderCredential $cred1 -ReceiverSipAddress "sip:kenmyer@litwareinc.com" -ReceiverCredential $cred2
And here's an example that uses a pair of users accounts that were preconfigured for the pool atl-cs-001.litwareinc.com:
Test-CsIm -TargetFqdn atl-cs-001.litwareinc.com
You can decide for yourself which one is easier.
So how hard is it to set up test accounts for a pool? Believe it or not, it's easy, way easier than setting up real user accounts. All you have to do is call New-CsHealthMonitoringConfiguration and provide your two test users with SIP addresses:
New-CsHealthMonitoringConfiguration -Identity atl-cs-001.litwareinc.com -FirstTestUserSipUri "sip:kenmyer@litwareinc.com" -SecondTestUserSipUri "sip:pilar@litwareinc.com"
And yes, we know you're cynical. (We forgot to mention that, too: system administrators have been known to be cynical from time-to-time.) But that's really all you have to do. You'll now have a pair of test accounts that can be used by the pool atl-cs-001.litwareinc.com. (And can only be used in synthetic transactions; you can't do something like, say, fire up Microsoft Lync and try to log on as one of these test users.) The next time you run Test-CsIm you won't have to include any user account information. Instead, all you have to do is include the TargetFqdn parameter and the fully qualified domain name of the pool being tested. The Test-CsIm cmdlet will then check the health monitoring settings for that pool and, if test users exist, will conduct its test using those test users. And if there aren't any such test users? That's fine; Test-CsIm will then prompt you to enter user account information.
If that doesn't reassure you, well, we don't know what will.
Incidentally, we should mention that there are a few Test-Cs cmdlets that can't employ these test users. For example, Test-CsClientAuth is designed to see if a real user, using a real client certificate, is able to log on to Lync Server. Because test accounts aren't real users and don't have real client certificates, they can't be used with Test-CsClientAuth. The best way to know whether you can use test accounts with a given cmdlet? Take a quick peek at the help topic for that cmdlet:
Get-Help Test-CsClientAuth –full | More
That's all we have time for today; in fact, seeing a show it's Friday, that's all we have time for this week. So do we really think that system administrators are pessimistic, insecure, skeptical, and cynical? No, not really. But if we didn't say that we were, well, we wouldn't have much of an article for today, would we?
And yes, we know what you're thinking. Very funny.
Note. Just in case system administrators really are pessimists, here's some advice paraphrased from an old joke. "If you need to borrow money, borrow it from a system administrator. He or she won't expect to ever get it back."