Category Archives: Error Codes

Error returned while installing OcsMcu.msi, code 1603

19 Saturday Nov 2016

Posted by in Error Codes, Uncategorized

≈ 9 Comments

Tags

Just recently we have started seeing the Skype for Business installer option to “Connect to internet to check for update” actually find updates. Yay!

Hold on now, as this is where the issue begins..

On a new install (Enterprise Edition Pool) this week I though I might give it a bash and see how we go.

Seems we have found some updates, unfortunately there is no indication at this point as to which updates these are.

downloading-updates

Next I ran through STEP 1 and 2

Step 2 Fails.

ocsmcu-msi-error-1603

OK, so the log file alludes to the Apply Patch and it mentions OcsMcu.msi. I am beginning to suspect pre-install update wizard already.

Checking the log file we find the following errors:

Error 1

Product: Skype for Business Server 2015, Conferencing Server – Update ‘Skype for Business Server 2015, Conferencing Server (KB3149233)’ could not be installed. Error code 1603.

Error 2

Windows Installer installed an update. Product Name: Skype for Business Server 2015, Conferencing Server. Product Version: 6.0.9319.259. Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: Skype for Business Server 2015, Conferencing Server (KB3149233).

Installation success or error status: 1603.

So from these errors we can see that the Conferencing Server (OcsMcu.msi) Installed Version is expected to be from KB3149233. The second error calls out the version of OcsMcu.msi as 6.0.9319.259

Lets do a quick check to see what is actually installed. There are a few ways to do this. Great post by Tim Harrington at http://howdouc.blogspot.co.nz/2012/04/three-ways-to-determine-what-version-of.html on how to do this.

Since (at the time of writing) the latest KB (November 2016) is out and is newer than whats being reported here, I will use SkypeServerUpdateInstaller.exe as it seems I will need to run updates.

Here’s what’s been found:

skypeserverupdateinstaller

From this quick view it appears that some components have been updated BUT as you can see, the conferencing server update (OcsMcu) is on a much older version. The error log was expecting to find 6.0.9319.259 (July 2016)  but what we have is even older than that. That’s actually the original version on the ISO so it is safe to say that the Conferencing Server was not patched at all.

As a quick fix, thought I might try a sneaky update and hope that the aged OcsMcu would get patched.

Unfortunately the expected version is now mismatched and so the update attempt also throws an error:

ERROR 1603: OCSMCU.msp had errors installing.

Solution

In this case, since we are in the install process, we opted for uninstall and re-install. This time however we did NOT select the option to “Check for Updates” before running the install.

Note

 

No Presence for Fedrated partners – Event ID 11

08 Wednesday Jun 2016

Posted by in Error Codes, Event ID, Federation Issue, Lync DNS Records overview, Lync Edge, O365, Office 365, SRV, SRV Record, Uncategorized, Unified Messaging, voicemail

≈ 2 Comments

Tags

, ,

Problem

Came across a deployment with the following 2 issues:-

  1. federated partners were showing up as presence unknown
  2. unable to call voicemail (hosted in O365)

When trying to send messages to these “unknown” federated partners I got “This message wasn’t sent due to company policy”.

So why did I try to message a contact with a presence status of “unknown? Simply because the federated contact could see my users presence and send me IM’s, I was even able to respond to these IM’s although the presence was still “unknown”.

Presence Unknown

Troubleshooting

A quick look at the client side logs revealed an error in the presence Subscribe message

CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 172.11.12.13:24164;ms-received-port=24164;ms-received-cid=FC9300
ms-diagnostics: 1008;reason=”Unable to resolve DNS SRV record“;domain=”ucsorted.com”;dns-srv-result=”NegativeResult”;dns-source=”InternalCache”;source=”access.ucsorted.com”
Server: RTC/6.0
Content-Length: 0

Taking a look at the users (client side) local event log I found the same error.

Event Log

Event ID 11
A SIP request made by Lync failed in an unexpected manner (status code 80ef01f8).

Response Data
504  Server time-out
ms-diagnostics:  1008;reason=”Unable to resolve DNS SRV record“;domain=”ucsorted.com”;dns-srv-result=”NegativeResult”;dns-source=”InternalCache”;source=”access.ucsorted.com”;OriginalPresenceState=”0″;CurrentPresenceState=”0″;MeInsideUser=”No”;ConversationInitiatedBy=”6″;SourceNetwork=”5″;RemotePartyCanDoIM=”Yes”

Clearly there is some issue with either the federation SRV record or resolving the federation SRV record.

Checking the SRV record from the Edge server I can see that this record is not found. Checking the DNS for the Edge server I noticed that the interfaces are pointing to the internal DNS servers.

Solution

We have 2 options here:-

  1. Configure the Edge Server to point to a public (external) DNS server where the SRV record for _sipfederationtls._tcp.domain.com is valid (frowned upon by some security folks)
  2. Add the SRV record for _sipfederationtls._tcp.domain.com to the internal DNS, making sure that the target FQDN is the Public Access FQDN of the Edge Server.

NOTE

Here is a little reason why you may want to avoid using the common sip.domain.com DNS name for your Edge Servers Access FQDN (only..). Internally the sip.domain.com record was generally configured to resolve to the front end pools, if we now need an internal SRV record for _sipfederationtls._tcp.domain.com then targeting this to sip.domain.com will simply get to the Front End Pool and not to the Federation point at the Access Edge FQDN.

 

 

ms-client-diagnostics: 25; reason=”A federated call failed to establish due to a media connectivity failure where both endpoints are internal

07 Monday Sep 2015

Posted by in Candidate, Edge Server, Error Codes, Federation Issues

≈ 5 Comments

Tags

Huh you say..that’s what I said too.

The Problem

Audio and Video failing between federated partners. This only happens when the B-Party user was internal. I also found that when the B-Party called the A-Party the media worked.

The Monitoring server reveals as follows:-

ms-client-diagnostics: 25; reason=”A federated call failed to establish due to a media connectivity failure where both endpoints are internal” Diagnostic ID: 25 states:- “A federated call failed to connect because a media path could not be established between the two internal endpoints. This failure can be caused by network performance issues affecting the endpoints or an endpoint being unable to use the A/V Edge Server. Correlation of such failures with individual networks, endpoints or A/V Edge Server can indicate potential deployment issues.”

The Diagnostic Header 25; reason=”A federated call failed to establish due to a media connectivity failure where both endpoints are internal”; UserType=”Callee”; MediaType=”audio”; ICEWarn=”0x40003a0″; LocalSite=”192.168.99.33:20008″;LocalMR=”60.234.48.202:54594″; RemoteSite=”10.57.210.11:20003″;RemoteMR=”122.56.25.147:54376″; PortRange=”20000:20039″; LocalMRTCPPort=”55223″; RemoteMRTCPPort=”54376″; LocalLocation=”2″; RemoteLocation=”2″; FederationType=”1″; NetworkName=”ucsorted.com”; Interfaces=”0x6″; BaseInterface=”0x2″; BaseAddress=”192.168.99.33:20018; MrDnsU=”lyncedge01.ucsorted.com”; MrResU=”0″

Finding the underlying issue

The federated environment is as follows:-

Skype Edge Architecture

Logical view

Following the call setup using Snooper I can see the initial INVITE from the A-Party with 8 possible candidates.

SIP INVITE

Caller Candidates

Next we see the response from the B-Party in a 183 Session Progress message. The B-Party offers 5 possible candidates.

183 Session Progress

Caller Candidates

We should now see a message containing “a=remote-candidates” to identify the selected and tested candidate pairs.

In my trace, this is missing! Instead I find a BYE message with the following ms-client-diagnostics:-

The Diagnostic Header 25; reason=”A federated call failed to establish due to a media connectivity failure where both endpoints are internal”

I did notice the reference to LocalLocation=”2″; RemoteLocation=”2″; Having compared this to a successful federated audio call I cant say that this has any relevance since the same location ID’s were present.

Generally when the candidate negotiation fails we are facing a path issue. Be that blocked ports or routing.

I have come across this issue before see https://ucsorted.com/2014/01/12/media-connectivity-failure-when-both-endpoints-are-internal/

This time, however, the underlying cause of failed candidate negotiation was something I hadn’t encountered (yet).

My edge server was configured with external facing IP’s in the DMZ with NATted Public IP’s for each. Checking the NAT using whatsmyIP I discovered that the result was not what I expected. Cycling through all 3 IP’s on the Edge server I found that the routing was not symmetric!

Arrghh! Such a simple issue!

Asymmetric verses Symmetric simply refers to the paths that data takes on a round trip.
Symmetric routing – Send and receive traffic via the same Public IP.
Asymetric Routing will send on one IP BUT return traffic arrives from a different IP (this is no good for Audio and Video in Lync\Skype for Business)

Solution

Once the routing was corrected to symmetric the audio was successful.

This time the nominated candidate pair for Audio and video was present. Looking into the final INVITE from the Callee (B-Party) to the Caller (A-Party).

Candidate Negotiation

Caller Candidate Selection

The Callee is stating that it will use candidate pair 3 to get to the Caller and that it plans to do so via the remote-candidate.

In response (OK Message), the caller states its intention to use the following candidate pair:-

Candidate Selection

Callee Candidate Selection

Now the Caller states that it will use candidate pair 6 to get to the caller and that this will be done via its remote-candidate.

Summary

It seems to me that when the candidate negotiation fails the default assumption is that the endpoints must be internal. I can understand that reasoning since you would only expect to negotiate candidates so that you are able to traverse the Edge infrastructure.

However, it can lead you down the wrong path.

Phew!..and now that’s sorted