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.

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

 

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).

scenario

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.

DNS

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

NOTE

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.

TIP

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 _sipfederationtls._tcp.ucsorted.com 5061 access.ucsorted.com
SRV _sip._tls.ucsorted.com 443 access.ucsorted.com
A access.ucsorted.com Onprem Access Edge Public IP
A\CNAME lyncdiscover.ucsorted.com Onprem Reverse Proxy Public IP
A meet.ucsorted.com Onprem Reverse Proxy Public IP
A dialin.ucsorted.com Onprem Reverse Proxy Public IP
A sfbweb.ucsorted.com Onprem Reverse Proxy Public IP
Cloud SRV _sipfederationtls._tcp.uc-heroes.co.nz 5061 Sipfed.online.lync.com
SRV _sip._tls.uc-heroes.co.nz 443 sipdir.online.lync.com
CNAME sip.uc-heroes.co.nz sipdir.online.lync.com
CNAME lyncdiscover.uc-heroes.co.nz Webdir.online.lync.com

 

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.

error

Step 3

Certificates

You will need to add a sip.domain.com 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 sip.uc-heroes.co.nz 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.

 

Limitation

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.

Note

This is not an officially supported configuration.

Posted in Uncategorized | Leave a comment

No Presence for Fedrated partners – Event ID 11

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.

 

 

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