[This is pre-release documentation and subject to change in future releases. This topic's current status is: Milestone-Ready]

Topic Last Modified: 2010-07-17

Validating connectivity for external users requires ensuring connectivity from users to the server and port for the Access Edge service.

Test Remote User Connectivity

You can test remote user connectivity by using the Office Communications Server Remote Connectivity Analyzer. This Web-based application helps IT Administrators to validate and diagnose end-to-end Communications Server scenarios by facilitating testing of the connectivity of a remote user to Communications Server. The site simulates multiple Communications Server client access scenarios from outside the customer's infrastructure and reports whether the test was successful. You access and run the application directly from the Office Communications Server Remote Connectivity Analyzer Web site at https://www.testocsconnectivity.com.

To use the tool, you first specify the test method:

  • Test remote client connectivity to Office Communications Server by specifying the FQDN of the Access Edge Server and the port.

  • Test remote client connectivity to Office Communications Server by using auto-discovery to find the Access Edge Server and port to which to connect.

Security Note:
You should create a test user account for this test, instead of using an account of a user in your organization. As a best practice, change the user password or delete the account after the test.

After you select which of the two test methods is to be used for the test, you specify the required information, including the user account to be used in the test, and then the application attempts to connect to the Access Edge Server and complete the following test steps:

  • Resolve the host name in DNS.

  • Test the TCP port to ensure that it is open.

  • Test the certificate for validity.

  • Remotely sign in the remote user to Communications Server through the Access Edge service on the appropriate port, and then start or join an A/V session with an internal user or a Web conference with multiple users.

  • Indicate where the test was successful, provide details about the results of each test step, and, if any test step failed, identify which step failed and provide information about how to resolve the issue.

The tool can identify DNS name resolution issues for both the manual TLS and automatic client sign-in, including DNS configurations issues, TLS connectivity issues, and NTLM domain credential issues for remote user sign-in.

Because the test results identify exactly what failed and provide detailed information about the problem, this tool can help streamline testing and troubleshooting processes.

Test Connectivity of Other External Users

After confirming remote user connectivity as previously described, you should ask other types of external users to try signing in using their account credentials (where applicable). Tests should include each type of external user that your organization supports, including any or all of the following:

  • Users from at least one federated domain, and test IM, presence, A/V and desktop sharing.

  • Users of each public IM service provider that your organization supports (and for which provisioning has been completed).

  • Anonymous users.