My post with lots of Lync 2010 error messages is my highest-rating page, and I’ve been meaning to start an equivalent collection of Lync 2013 messages. And so it begins.

 

Jump to the relevant section headings or just ^F to search for your specific error:

Signing-In
Contact Management
Instant Messages
Voice / Phone Calls
Skype

 

Signing-In

“Can’t sign in to Lync”

“There was a problem verifying the certificate from the server.”

1) This will show on a “workgroup” machine connected on the corporate network. The machine doesn’t have the enterprise root certificate, so it doesn’t trust the certificate being presented by the Front-End. Log in to the Certificate Authority (or any domain-attached machine), export the Root cert and import it to your machine.

“Lync couldn’t find a Lync server for <your domain>. There might be an issue with the Domain Name System (DNS) configuration for your domain. Please contact your support team.”

1) There’s a problem with the Reverse Proxy at <your domain>. Autodiscover has completed successfully – the DNS records are there – but your RP is down or misconfigured. Work around this by specifying a manual server name in the client under Tools / Options / Personal tab & the Advanced button.

“We’re having trouble connecting to the server. If this continues, please contact your support team.”

1) There’s a problem communicating with the Edge server. It might be a firewall problem or bad networking settings on the Edge. Check out UC Ken’s “Lync Edge Server Static Routes” post for a couple of tips here.

2) Click “Delete my sign-in info” and try again. That’s been known to get me past this one!

 

Contact Management

“Cannot add, remove or move contacts or groups at this time. Please try again later.”

1) This is a problem with the Unified Contact Store. Diagnose this using “Test-CsUnifiedContactStore”, “Test-CsExStorageConnectivity”, “Get-CsPartnerApplication” & “Debug-CsUnifiedContactStore”. If this is a major issue, roll the users back to Lync for their contacts as a band-aid until you can fix it. Either Grant a different “user services policy”, or change the existing one to set UcsAllowed to $false. Once you’ve done this you’ll need to “Invoke-CsUcsRollback –Identity <username>”, as changing the policy doesn’t automatically roll back the contacts that are already in Exchange.< p>

 

Instant Messages

“We couldn’t send this message because we couldn’t find <User>.”

1) This is an interesting Federation bug. In this scenario, the published Federation SRV record for *my* domain was wrong – so the error message is a red herring: “Jessica’s” Lync deployment is working fine. (Tracing on the remote Edge server confirmed it was looking up the Federation record for my SIP domain prior to starting the conversation, and I was returning an incorrect hostname and IP).

2) This is as a result of the remote Lync’s Edge server returning a 404 NOT FOUND – but that confirms we’re talking OK to the far end. It’s going to be one of the following: the user doesn’t exist; the user *does* exist and is not enabled for Federation; or the remote Lync deployment has closed Federation (or it’s Open and you’re on their Blocked list).

“This message wasn’t sent because <user> doesn’t have permissions on your organization’s network, or because the address is incorrect.”

1) The other end’s Lync has a bad DNS record. The “_sipfederationtls._tcp.<theirSipDomain>” SRV record is pointing to a host name in a different domain. This is borne out by a trace of the Edge, but can be diagnosed quickly and easily just using nslookup:

 

Phone / Voice Calls

The below are all failed outgoing PSTN calls

“Call was not completed or has ended”

“When contacting your support team, reference error ID 10053 (source ID 7).”

1) I do this one to myself quite a lot – it’s caused by me jumping up on a customer’s VPN and then absent-mindedly making a call via Lync. The fix is to sign out and back in again. You might also encounter other errors establishing media in this same scenario. Any time you change your networking environment (like by connecting to or disconnecting from a remote VPN) you should always sign out and back in to Lync.

“When contacting your support team, reference error ID 10001 (source ID 243).”

1) I think I’d go so far as to say this one is going to ALWAYS be caused by a problem in your voice config, or a dead/defunct PSTN Gateway. In this example I’d dialled a number that was correctly handled by my configured routing, and it was pointing to a PSTN Gateway that is no longer in service. Run a quick check of the number with “Test Voice Routing” in the Lync Control Panel, make sure there’s a Gateway assigned to the Route, and then ping the Gateway to see if anyone’s home…

“When contacting your support team, reference error ID 405 (source ID 239).”

1) The call made it to the PSTN Gateway (a Sonus SBC 2000), which responded with SIP 405 (“Method Not Allowed”). In this case I had an error in the SIP “Message Manipulation” table assigned to Lync’s SIP Signaling Group in the UX/SBC.

 

“When contacting your support team, reference error ID 485 (source ID 241)”

485 is the giveaway here – it’s SIP-speak for “ambiguous”. There are likely one of two issues here:

1) You’ve called an internal user, however their Line URI is either mis-configured in Lync or someone else has. e.g. User 1 is set with a line URI of “tel:+61270001234” whilst User 2  is “tel:+61270001234;ext=nnnn”. Lync doesn’t know which one to send the call to, so it decides on no-one.

2) You may be fortunate enough to have two users configured in the Lync user database with the same number. It’s not meant to happen but it can. A trace of this call on the Front-End will report “ms-diagnostics: 4199;reason=”Multiple users associated with the target phone number”;

 

“When contacting your support team, reference error ID 500 (source ID 239).”

The call made it to the PSTN Gateway (a Sonus SBC 2000), which responded with SIP 500 (“Internal Server Error”).

1) Tracing in the Gateway revealed an error in the SBC’s “Action Set Table”.

2) Mis-configuration of the Gateway was set to return an invalid Cause Code.

3) The call was correctly forwarded to the Exchange/CO, which returned Q.850/ISDN Cause code 6 (“Channel Unacceptable”). The fault was proven to be locked-up or misconfigured (?) ISDN channels. The carrier was eventually able to fix this.

“When contacting your support team, reference error ID 502 (source ID 239).”

1) The call made it to the Gateway and was correctly forwarded to the Exchange/CO. It returned Q.850/ISDN Cause code 27 (“Destination Out of Order”), which was sent to Lync as “SIP/2.0 502 Bad Gateway”. The cause could be bad RegEx in your PSTN Gateway config, or a problem with the called number. It’s not that uncommon here in a deregulated Australia to encounter issues where a destination number isn’t loaded in the Exchange/CO or routed correctly between carriers, so re-testing this number by dialling it from your mobile phone or another device isn’t necessarily a good test.

“<number> is in another call.”

OK, perhaps stating the bleeding obvious here, but as this is a list of error messages, I’ve let it through.

1) The called party is a valid PSTN number, and they’re on the phone! The PSTN Gateway reported Q.850/ISDN Cause code 17, which was sent to Lync as SIP 486 “Busy Here”.

“<number> … is not in service. Please check the number and try again.”

1) In this example it was a RegEx error in the Gateway that resulted in a genuine number being reported as invalid. The Gateway (in this case an SBC 2000) reported “SIP/2.0 404 Not Found”.

2) My SIP trunk wasn’t registering correctly with the carrier, so all call attempts were being rejected (with “SIP/2.0 404 Not Found”).

“<number> is unavailable or may be offline.”

1) The call made it to the Gateway and was correctly forwarded to the Exchange/CO. It returned Q.850/ISDN Cause code 34 (“No circuit/channel available”), which was sent to Lync as “SIP/2.0 480 Temporarily Not Available”.

2) The call made it to the Gateway and was correctly forwarded to the Exchange/CO. It returned Q.850/ISDN Cause code 41 (“Temporary Failure”), which was sent to Lync as “SIP/2.0 480 Temporarily Not Available”.

“<number> did not answer.”

Perhaps another one for the “bleeding obvious” category.

1) The Exchange/CO is only going to ring a number for so long without answer. It will eventually force disconnect the call attempt, reporting Q.850/ISDN Cause code 18 (“No User Responding”), which was sent to Lync as  “SIP/2.0 408 Request Timeout”.

“Cannot complete the call”

“There is more than one contact with your phone number. If you cannot resolve this problem, contact your support team with this information”.

1. As per the message, due to a config anomaly both you and another user have managed to have the same Tel URI allocated to you. On the Front-End your failed call was logged in the trace as “ms-diagnostics: 4002;reason=”Multiple users associated with the source phone number”;source=”<FE-FQDN>”. If the Lync Control Panel can’t identify the clash you might need to pull the info out of AD with LDIFDE and use Excel or your favourite text editor.

Skype

“This message was not delivered to <SIP address> because the service is not available.”

Your message didn’t get through because the person you’re trying to contact has their privacy settings ramped up, and as you’re not in their Contact list you can’t call them. Strangely though, your attempt to contact them has actually been received as an invitation – but until they add you to their Contacts you’re not going to have any luck reaching them. Their privacy settings probably look like this:

BTW, there are several things to note in the Lync image above: you’re not seeing the other party’s name, only their SIP address (“<blur>@outlook.com”), and they’re showing as offline with no photo. This indicates the other end isn’t trusting you with their details or status just yet.

NB: from my experience it might take one or two more failed calls or IM attempts before Lync and Skype sync up here, so don’t be too impatient. After the remote party has added you maybe wait a minute, or attempt a couple more times….

“Call was not completed or has ended”

“When contacting your support team, reference error ID 403 (source ID 239).”

This one is another symptom of your security-conscious ‘friend’. You’ve placed a call to a Skype user but you’re not in their Contacts list – and they only accept calls from Contacts. The call went unanswered and this was the resulting failure message you received.

“<Username> is unavailable or may be offline.”

This is what an unanswered call to a Skype user looks like if you *are* in their Contacts and you *are* allowed to call them. But they didn’t answer.

Note in contrast to the earlier screen-grabs you’re now seeing their user name instead of “<blurred>@outlook.com”, and you see their presence as well.

“<Username> did not answer.”

Yes, well I guess it *is* accurate to report that the user at the far end did not answer – but they actually rejected your call (clicking the red handset button on the offered call).

 

 

– G.