A few years ago, a cell phone company began running a series of TV commercials that featured a technician who traveled all across the United States. Each time this technician arrived in a new spot, he would phone his home office and utter the by now ubiquitous phrase, "Can you hear me now?"
Why did the cell phone company run these commercials? To hammer home the point that, no matter where users of this service might find themselves, they would not only be able to get a connection, but they would be able to get a good, high-quality connection. How could users be assured that they really would be able to get such a connection? Because the cell phone company was testing and verifying connectivity from any place you could think of. You knew your cell phone would work because the cell phone company had already been there and made sure that it would work.
This same idea—proactively monitoring and validating connectivity—is the reason for the Deployment Validation Tool, which is included with the Office Communications Server 2007 R2 Resource Kit. The Deployment Validation Tool simulates an audio call between two endpoints, enabling administrators (or, depending on the configuration, end users) to not only determine whether a connection can be made between these two endpoints, but to also to determine the quality of that connection.
Note
Don’t let the name of the tool throw you. The Deployment Validation Tool can, and should, be used after an Office Communications Server deployment to help verify that installation succeeded and that your audio/voice connections are working as expected. However, the Deployment Validation Tool shouldn’t be run just that one time immediately after deployment. Instead, it should be used on a regular basis.
Administrators can use the Deployment Validation Tool in two different ways. To begin with, administrators can set up answering agents. Answering agents (found in the single .msi file that makes up the Deployment Validation Tool) provide an easy way for anyone in an organization (not just administrators) to test the audio quality of a connection. For example, suppose a user is on the road and needs to call in from a hotel room to join an online conference. Prior to joining the conference, the user can call an answering agent, using the same process they use to call a real person. When the call goes through, the answering agent (which operates along the lines of a standard answering machine) prompts to user to record a message. After this message has been recorded, the answering agent then plays it back, allowing the user to judge the quality of the audio connection.
Answering agents should be set up on specific computers, based on your needs. (Depending on those needs, you can set up multiple agents on multiple computers.) For example, to test audio connections across the Internet, you might want to install an answering agent on a computer that lies outside your organization’s firewall. In addition, if users are going to be dialing in using standard telephone lines, you might want to install an agent on a computer equipped with a dial-up modem and a valid phone number.
To install an agent, log on to the computer where the agent will reside and start the batch file SetupAgent.cmd (a file found on the Resource Kit CD). Follow the prompts, being sure to specify the following:
When asked to enter a Session Initiation Protocol (SIP) URI, enter a URI for a valid domain user account, which is an account that has been enabled for Office Communications Server. This account should not be tied to an actual user; instead, it should be limited to use as an answering agent. In addition, each agent should be associated with a unique user account. Having more than one agent with the same SIP URI will cause problems.
When asked to select an agent type, choose Answering Agent and enter the phone number associated with that agent. Phone numbers should be entered using the E.164 format.
By default, agent files are stored in the folder C:Program FilesMicrosoftDVTAgent.
Note
When installing an agent, you might see a message box telling you that an unexpected error occurred while running Netsh.exe. This error occurs if the Windows Firewall Internet Connection Sharing Service is not running and can be safely ignored. Simply click OK and the setup program will continue.
After you install an agent, you must then log on to Office Communicator by using the agent account. If an agent is not logged on to Office Communicator, users will not be able to contact the agent and perform the audio check. (This effectively limits you to one agent per computer.)
You can change the properties of an agent at any time by starting the Agent Configurator application (click Start, click All Programs, point to Deployment Validation Tool, and then click Agent Configurator). In the SIP URI box, type the URI for the agent in question (for example, [email protected]), make your changes to the agent configuration, and then click OK.
Note that after making a change to an agent, you must restart the Office Communications Server Deployment Validation Tool Agent Service before those changes will take effect.
To make a call to an answering agent, select the desired agent from your list of Office Communicator contacts (or type in the appropriate SIP URI). Once that’s done, call the agent the same way you would call any other contact. When prompted, use the Office Communicator Dialpad to press the pound key (#), record your message, and then use the Dialpad to press # a second time. At that point, the agent will replay the recorded message.
In addition to the ad hoc, one-off testing that answering agents provide, administrators can conduct more formal (and fully automated) testing by using the complete Deployment Validation Tool. The Deployment Validation Tool consists of two components: an Organizer and a collection of agents (as many as 16 per Organizer). The Organizer’s job is to run a set of tests with each of these agents. By default, each agent will call every other agent in both a peer-to-peer conversation and in a conference session mediated by Office Communications Server. For example, suppose you have three agents: A, B, and C. In that case, the default test suite would consist of the following peer-to-peer tests:
Agent A calls agent B
Agent A calls agent C
Agent B calls agent A
Agent B calls agent C
Agent C calls agent B
Agent C calls agent A
A similar set of tests would then be carried out for conference sessions. Each call is evaluated on multiple QoE criteria and then given a pass/fail score.
To install the Deployment Validation Tool, you must first select a computer where the Organizer will run. (A complete set of tests has the potential to use a considerable amount of system resources and network bandwidth. Therefore, it’s recommended that the Organizer be installed on a dedicated computer whenever possible.) The computer that hosts the Organizer must also run the following software:
Microsoft Visual C++ 2005 Service Pack 1 (SP1) Development System Redistributable
.NET Framework 2.0
Microsoft SQL Server 2005, Express Edition
If any of these applications are not currently installed, setup will install them for you. Note that you must install SQL Server Express even if SQL Server is already installed on the computer.
Note
Unlike the Organizer, agents do not have to be installed on a dedicated computer. You can safely install agents on computers that perform other tasks because the agent service is relatively lightweight and has little impact on system resources.
Incidentally, when you use the complete Deployment Validation Tool, you have three different agent types at your disposal:
Answering Agent. This is the same type of agent that can function in standalone mode. This agent simulates an answering system any time it gets called.
Unified Communication. This type of agent simulates an Office Communicator 2007 client.
PSTN. This type of agent simulates a Public Switched Telephone Network (PSTN) phone.
After you have installed the Organizer and created all your agents, you must then add these agents to the Organizer. To do this, bring up the Admin Console (click Start, click All Programs, point to Deployment Validation Tool, and then click Admin Console). On the Roster tab, click Add Agent and then, in the URI dialog box, type in the SIP URI of the agent, a nickname to make it easy to identify the agent, and, if you wish, a description of that agent. Click OK, and the agent will be added to the roster. Remember, you can have as many as 16 agents in a single Organizer.
By default, the Organizer automatically runs a complete set of tests every 60 minutes. That is, each agent calls every other agent in both a peer-to-peer call and a conference call. The 60-minute interval can be modified within the Admin Console by clicking the Test Suite tab and entering a new value. You can also disable auto-checking by clearing the Auto Run check box. If you clear that check box, the test suite will no longer run at the specified interval. However, you can manually run the complete set of tests at any time by clicking the Run Suite button.
Of course, sometimes you might want to do some testing, but you don’t want to run every possible test. (For example, you might only be concerned with connectivity through the Edge Servers and not with connectivity on the internal network.) In such a case, you have at least two options available to you.
First, you can test the connectivity between any two agents by right-clicking the appropriate test in the test suite matrix and then clicking Run Testcase. The Organizer will immediately run a test verifying the connectivity between those two endpoints. If you want to run tests between multiple agents but not all the agents, you can remove specified tests from the test suite by right-clicking each of those tests and then clicking Disable Testcase. Disabled test cases will not be run the next time the test suite executes. To restore a case to the test matrix, right-click the case and then click Enable Testcase. Alternatively, click Restore Default to re-enable all the test cases.
Each time a test is conducted, the appropriate cell in the test matrix is updated to reflect the results of that test. Green means that the test case passed, and red means that the test case failed. This provides a simple visual indicator not only of how the tests are turning out, but also of how the test suite itself is proceeding. (Tests that have not yet run will be colored white, and tests currently in process will be colored grey.)
You are not limited to this pass/fail type of reporting. For more detailed information, click the Reports tab. On this tab, you can see the following information for the tests you have conducted:
Alert status
Date/time
Test type
Connectivity results
Quality results
Initiator agent
Receive agent
Test description
If you want even more detailed information, click Send Reports To File. This will generate a text file report (named Reports.txt) that will automatically be saved to your Documents folder. If a file named Reports.txt already exists in that folder, it will be overwritten.