When working through problems in the topology or on specific servers, a good way to minimize the scope or to quickly identify errors is to use the Validation Wizard, which is available as a tool in the Office Communications Server 2007 R2 Administration MMC snap-in. This tool checks configuration against connectivity and does basic validation checks to point out and avoid misconfigurations in Office Communications Server 2007 R2 settings or in network and certificate configurations that relate to the server. The next Direct from the Source sidebar provides a usage example for using the Validation Wizard.
Direct from the Source: Using the Validation Wizard
Senior Program Manager, Office Communications Server Customer Experience
I have an Office Communications Server 2007 R2 Standard Edition Server and an Office Communications Server 2007 R2 Edge Server deployed. Most often, I log on internally by using the Office Communicator 2007 R2 client. If this does not work, I check the error message to see whether I can quickly resolve the problem because DNS and certificate issues are the easiest errors to identify. If I still can’t identify the problem, I use the Validation Wizard.
After one client has successfully logged on, I know that my Standard Edition Server is running and accounts are able to log on. I then move to the Edge Server; open Computer Management, Services and Applications; and then right-click Microsoft Office Communications Server 2007 R2 to launch Validation for the Access Edge Server role as shown in Figure 20-2.
I select the Validate Local Server Configuration, Validate Connectivity, and Validate SIP Logon (1-Party) And IM (2-Party) check boxes as shown in Figure 20-3.
Because I am giving an introduction to the Validation Wizard here in this sidebar, I will not explain all the tests; I will not include a federation test in this chapter.
First, I run the Validation Wizard on the Access Edge Server and receive errors. I select the View Logs option because logs are created by default in the user’s temporary directory. The resulting log page looks like Figure 20-4 when opened in Internet Explorer.
The errors point out problems, such as TLS connect failed: 192.168.100.5:5061 Error Code: 0x274c. No connection can be made because the target server actively refused it. Note that the log contains other errors. Experience has taught me to go through all the errors to find the biggest problem, which in this case is that I cannot connect to the Standard Edition Server.
The next step is to run the Validation Wizard on the Office Communications Server 2007 Standard Edition Server. I select only the Validate Local Server Configuration and Validate Connectivity check boxes (as shown in Figure 20-5) because the errors indicate a server problem and not a logon problem.
I receive the following error: Error: Service isn’t installed, enabled, or started. Please check service installation and configuration, as shown in Figure 20-6.
Sure enough, the RTCService service account password has expired and needs to be reset. I started my validation from the Edge Server and made the assumption that everything internally was working properly. Because it was not, I took actions to resolve problems for the internal server. So now, I will begin the Validation Wizard testing at the internal server and work my way back to the Access Edge Server to minimize the number of possible problems.
I have configured my deployment so that I will select all the options on the Validation Steps page (as shown in Figure 20-7).
I also have another failure to investigate. Now is the time to select Expand All at the top right of the log file page and scroll through the list. Remember that the first red text is not always the error but is typically a rolling up of the error from the steps contained within it. You will almost always scroll all the way to the bottom of the file.
I have two problems on which to focus, as shown in Figure 20-8: federation settings are failing, which also includes a DNS error for the name I put into the configuration. I can see here that no records exist. I either failed to enter the correct DNS A record, or I do not have the next hop server of edgeserver.litware.com. The second problem is that I was not able to log on one of the two users for whom I provided credentials.
Notice the information contained in the wizard about user logons, as shown in Figure 20-9. Credentials for Jeremy were passed using both Kerberos and NT LAN Manager (NTLM) and failed, whereas credentials for Vadim passed with Kerberos. The failure for both Kerberos and NTLM is a strong indicator that the password was mistyped (which I did on purpose to create this dialog), but the success of Vadim with Kerberos confirms that there is no authentication problem and, more specifically, no problem with Kerberos.
I corrected the next hop server fully qualified domain name (FQDN) to be edgesrv.litwareinc.com and verified my user credentials.