Error returned while installing OcsMcu.msi, code 1603

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.


Next I ran through STEP 1 and 2

Step 2 Fails.


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 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:


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.


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.



Posted in Error Codes, Uncategorized | Tagged | 6 Comments

How to federate Onprem with sub-domain\other domain hosted online

Office 365 Tenants with multiple Domains have become fairly common place. Be it the international organization with a primary domain and a number of child domains, or the university with a faculty and student domain. Perhaps it’s the merger of two or more organizations, where some domains are Hybrid and others will remain in the cloud (for now).


This is easily addressed with a Hybrid deployment; I hear you say. True BUT..

In some cases, the requirement is to have some of these domains as cloud ONLY.

What reasons might an organization have to keep one domain on premises and another in the cloud only?

Two I have come across are: –

User Accounts

In one instance I saw an environment where university students (60 0000 +) were on line only, while faculty were Onprem. The university was not keen to add 60 0000 + users account to Active Directory so that we could enable hybrid mode (especially since the students were never going to be moved to Onprem)

In a Hybrid scenario, all the users (regardless of whether they will be homed in the Cloud or Onprem) need to exist in Active Directory. When you have two organizations merging then this can be a big limiting factor. Sure you can setup trusts and use resource accounts etc., limiting and intensive non the less.


When enabling Hybrid mode its required to point the DNS records to the On premise infrastructure. Consider a deployment where the Tennant is in the USA and the On premise deployment is in New Zealand. Potentially the on Premise deployment may be expanded to other continents, BUT I find it rather challenging to explain to a customer that I need to point the DNS records to an NZ deployment that’s probably not considered “Enterprise” in terms of High Availability.


For the sake of understanding let’s talk about SIP Domains.

We will consider three SIP Domain configurations: –

Onprem SIP Domain – All users homed on premise, domain does NOT exist in the O365 Tenant

Hybrid SIP Domain – All user accounts in on premise AD, Skype users homed to either On premise or online

Online SIP Domain – Users DO NOT exist in On premise AD. SIP Domain is created in O365 Tenant and there is no requirement to have these users on premise

So to be clear, what we will be looking at is “Federation” between an Onprem or Hybrid domain with an Online Domain.

Here’s what you need to do:-

Step 1

Configure Hybrid mode for the On premise SIP Domain (if it’s not already done). Details of configuring Hybrid can be found HERE


You do not need to add the child\additional domains to the on premise topology (there is no harm in doing so either)

Step 2

Configure the DNS

A rule of thumb is to point the On premise\Hybrid SIP domain DNS records to the On premise deployment, and the Cloud SIP Domain DNS records to the O365 cloud.


Be sure to add the “Cloud SIP Domain” to the internal DNS Zones as any users considered internal will need to resolve the SRV records to the Online servers.

SIP Domain Record Type DNS Record Port Target
Onprem\Hybrid SRV 5061
SRV 443
A Onprem Access Edge Public IP
A\CNAME Onprem Reverse Proxy Public IP
A Onprem Reverse Proxy Public IP
A Onprem Reverse Proxy Public IP
A Onprem Reverse Proxy Public IP
Cloud SRV 5061
SRV 443


If you have the DNS for the Online domain pointing to Onprem you will get a user not found error when trying to message an Online user.

Conversely, if you have the DNS for the Onprem domain pointing to Online you will get a user not found error when trying to message an Onprem user.


Step 3


You will need to add a SAN to the Edge server certificate for each online SIP domain that needs to be included in the “federation”.

In my case I had to add as a SAN to the existing UC SAN Certificate already deployed.


Under the hood

O365 will actually handle the on premise SIP domain as if it’s in a fully deployed hybrid deployment.

The on premise deployment will handle the Online SIP domain as if it’s a federated partner. Thus the usual behavior for federation will be followed.



The primary limitation is with regard to Federation behavior between these On premise\Hybrid SIP Domains and the Online SIP Domains.

Typically, you won’t see rich presence, Presence Notes, detailed contact card etc for Federated contacts. These same limitations will apply in this setup.

The inverse in not true though, the Online SIP Domain users will see the Onprem\Hybrid users as if they were fully Hybrid.

Also, if you are “federating” between Onprem\Hybrid and Online as I have just described, then the Onprem deployment is authoritive for the Onprem\hybrid users and the online deployment is authoritive for the online users.


This is not an officially supported configuration.

Posted in Uncategorized | Leave a comment

No Presence for Fedrated partners – Event ID 11


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


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

Via: SIP/2.0/TLS;ms-received-port=24164;ms-received-cid=FC9300
ms-diagnostics: 1008;reason=”Unable to resolve DNS SRV record“;domain=””;dns-srv-result=”NegativeResult”;dns-source=”InternalCache”;source=””
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=””;dns-srv-result=”NegativeResult”;dns-source=”InternalCache”;source=””;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.


We have 2 options here:-

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


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



Posted in Error Codes, Event ID, Federation Issue, Lync DNS Records overview, Lync Edge, O365, Office 365, SRV, SRV Record, Uncategorized, Unified Messaging, voicemail | Tagged , , | Leave a comment