Tuesday, December 7, 2010

Microsoft Office Communications Server Remote Connectivity Test fails with: “Subscription for provisioning data did not return a valid MRAS URI.”

Lately, I’ve been receiving feedback about my posts that the solution to the issues are not always correct. It’s partly my fault for not including an additional note that the problems I write about along with their solutions are only one of the many scenarios that may exists and if they don’t necessarily work for all situations. I would like to thank the people who have provided me with this feedback and I’ll make sure I make this note in my future posts.

As with many errors or warnings that you may experience with Microsoft Office Communications Server 2007 R2, note that following solution is one of the many that may cause such an error so it may or may not apply to other situations were this error is thrown.


You’ve deployed a new OCS 2007 R2 Edge server and have begun testing with Microsoft Office Communications Server Remote Connectivity Test tool at Since the public DNS SRV records have not been created yet, you have opted to use the tool without the AutoDiscover option but once you’ve completed entering all the information, you get the following result:


Connectivity Test Failed

Test Details

Copy to Clipboard



Testing the Remote Connectivity to Microsoft Office Communications Server Access Edge Server running on port number 5061 to see if user can connect remotely.

Specified Remote Connectivity test(s) failed. Please examine below details of specific reason for failure.


Test Steps


Attempting to Resolve the host name in DNS.

Host successfully Resolved


Additional Details

IP(s) returned:


Testing TCP Port 5061 on host to ensure it is listening/open.

The port was opened successfully.


Testing SSLCertificate for validity.

The certificate passed all validation requirements.validation checks.


Additional Details

Subject:, OU=Domain Control Validated,, Issuer SERIALNUMBER=9999, CN=Go Daddy Secure Certification Authority, OU=, O=", Inc.", L=Scottsdale, S=Arizona, C=US


Testing Microsoft Office Communications Server remote sign in through Access Edge Server: Port Number (, for SignInAddress (

Specified Remote Connectivity test(s) failed. Please examine below details of specific reason for failure.


Tell me more about this issue and how to resolve it


Additional Details

Subscription for provisioning data did not return a valid MRAS URI.


Analyzing the Problem

The first place I checked because the server I was working with Windows Server 2008 R2 was the local security settings:


Since this was set properly, I proceeded to move on to doing SIPStack traces on the Edge server to see if I was able to capture additional information to help with the troubleshooting:


While the SIPStack trace only provided 2 entries, it turned out to be more than enough to indicate what was causing the error:


TL_INFO(TF_CONNECTION) [0]0688.0960::12/02/2010-23:17:57.673.0000000d (SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(161))$$begin_record

LogType: connection

Severity: information

Text: TLS negotiation started



Connection-ID: 0x4100

Transport: TLS

Note: Sorry but I lost the screenshot for the snooper trace and only have the text

TL_ERROR(TF_CONNECTION) [0]0688.041C::12/02/2010-23:17:57.705.00000010 (SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(157))$$begin_record

LogType: connection

Severity: error

Text: The connection from a remote user client is refused because remote user access is not enabled on this port


Transport: TLS


Data: listening-port="5061"




What immediately (and finally) caught my eye was that port 5061 was being used and our public SRV record is supposed to direct traffic to port 443 when users are connecting to the Edge with their MOC clients.

All that was required to be changed to receive an error free test was the OCS Access Edge Server Port which in this case should be 443 and not 5061.



Anonymous said...

This also fixed our problem. Now that we can test we will be continuing! Thank you

Mohammed Hamada said...

How do you change that on Lync? I'm receiving the same error.