EWS not working externally

11 Sunday Nov 2012

Posted by Paul Bloem in call history, Communicator, Credentials are required, EWS, Login issue, voice mail, voicemail

The Problem
Lync password prompts when connecting over Edge server : “Lync needs your user name and password to connect for retrieving calendar data from Outlook”

No matter what credentials you type it wont accept. The effect is that your call history and voice mail is un-populated.

Testing this from internally works, looking at the configuration information you see that the EWS connection data is missing as below:

Why is this happening?

When the Lync client signs in, it also attempts to retrieve availability data via Exchange Web Services. It does so via the Autodiscover functionality built into Exchange.

Lync Communicator will issue SOAP requests (over HTTPS) to the published Autodiscover server, who returns the URLs for the Microsoft Exchange Client Access Server(s) that will feed the availability data back to Lync Communicator.

The additional prompt for authentication comes from Communicator being hard-wired to authenticate using NTLM. When IIS (on the Exchange CAS machines) returns it’s WWW-Authenticate headers, it does so in the form of:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

When Communicator attempts to negotiate authentication using your cached credentials (over the Internet), it will fail with a “401.2 Unauthorized”, and subsequently prompt you for authentication as above.

If we force NTLM from either the client side or the server side, we eliminate these additional prompts for credentials.

How do we do that?

Client side

From Internet Explorer – Tools, Internet Options, Advanced, scroll down to the “Security” section, un-check “Enable Integrated Windows Authentication”, you should no longer receive the additional authentication prompt from Lync

Server Side

I prefer the server side fix as it solves the problem for everyone in a single swoop
In this fix we are instructing IIS on the Exchange CAS server(s) to offer NTLM as the first authentication provider (with Negotiate as the fallback provider) in the WWW-Authenticate header.

On the CAS Server do the following:

Open the IISmanager
expand the Default Web site
Select EWS and Autodicover and click on authentication
Select Windows Authentication
on the right hand pane select ” providers”
Move the “NTLM” to the top
Click ok
Close IIS manager
open command prompt
type “iisreset /noforce”
make sure IIS admin service and WWW services are started.

That sorted it for me.

Just a side note about the TMG rules. I have changed the TMG rule for EWS from Basic authentication to “No authentication, but client can authenticate directly” and added “All users” to the users allowed to authenticate.

I did have one final prompt for credentials, probably cause the cache had been altered by my endless testing, but this time adding my credentials was successful.

Lync login issue

02 Friday Nov 2012

Posted by Paul Bloem in Client certificate, Communicator, Control Panel, Credentials are required, CSCP, GAL, kerberos, Login issue

≈ Leave a comment

The Problem
I was having trouble connecting to the Control Panel (The URL worked fine) as well as getting the “Credentials are Required” box on many users.
Id get 4 consecutive “Credentials are Required” boxes as below.

Manually typing the creds didnt work and cancelling or closing the boxes resulted in the client logging in anyway. BUT as you would imaging there is no access to any of the services as reported on in the warnings.
The most obvious was that the GAL wasn’t being downloaded or updated anymore

The Culprit
Finally found that an over zelous Administrator had deleted my Lync Kerberos Account.

The fix (4 Steps)

1. Create a Kerberos account
Pre-req: member of Domain Admins and computer running Lync Management Shell (LMS)

New-CsKerberosAccount –UserAccount “LyncLabKerberosUserAccount” –ContainerDN “CN=Users,DC=LyncLab,DC=local”

Note
The –UserAccount parameter is used even though we are creating a computer account with this command.

2. Assign the Kerberos account to a site
Pre-req: member of RTCUniversalServerAdmins and computer running Lync Management Shell (LMS)
To use the Kerberos account, you must assign it to a site. While you can create multiple Kerberos accounts for your environment, you can only assign one account per Lync site.

New-CsKerberosAccountAssignment –UserAccount “LyncLabKerberosUserAccount” –Identity “site:MyLyncSiteName”

Enable-CsTopology

3. Set Kerberos account password and Synchronize to IIS
Pre-req: member of RTCUniversalServerAdmins and computer running Lync Management Shell (LMS)
Set-CsKerberosAccountPassword –UserAccount “LyncLabKerberosUserAccount”

If any servers are added to the topology in the site (like Front-ends and Directors) you will need to synchronize the Kerberos account password to IIS of the new server.

Set-CsKerberosAccountPassword –FromComputer SourceComputerFQDN –ToComputer DestinationComputerFQDN

4) Testing to make sure Kerberos is working properly
To test for full functional readiness of Kerberos within a site, the following command can be run to create a report:

Test-CsKerberosAccountAssignment –Identity “site:MyLyncSiteName” –Report “C:TempKerberos test.htm” –Verbose

Troubleshooting Address Book Service issues

17 Wednesday Oct 2012

Posted by Paul Bloem in ABS, AddressBook Service, Communicator, GAL

≈ Leave a comment

The culprit.

Generally speaking the ABS can be problematic from a client or server perspective. I usually start with the client, working my way up from there.

Ask yourself, self…
Is the Cannot Syncronize the Address Book error experienced by all or just onefew individualy?

If its just a few it may be a local issue

Simply to delete the local GalContacts.db and GalContacts.db.idx files. You could then wait and after a raondom time from 1 – 30 minutes (default 30 minutes) you should get a new GAL.
If not check to see if the client can navigate to the ABS URL’s (Seen from configuration information)- often been the problem

What if its Server Related?
The client side GAL files are downloded from the Lync FE IIS. The URL is visible from the Communicator Configuration information (SHIFT + Rightclick icon).

There will be an internal and external URL depending on where the client is connecting from. The URLS look similar to this:-

URL Internal From Server https://FE.lynclab.local:443/abs/handler
URL External From Server https://FE.lynclab.co.nz:443/abs/handler

Firstly you can test to see if you can reach these. URL needs to be valid and reachable (proxy issues?etc)
Both sites should present you with an authentication Required box asking for username and password, if you see this the URL is working.

The data located in the backend of the url is situated on the Lync Share that was created during the install process. Ensure that the share is still valid by navigating to it from one of the clients (clients should have read access).

If for some reason the file share is no longer shared or the rights to the share and even the file structure in the share has changed…
You can remedy this by re-publishing the Topology followed by running the Deployment Wizard.

The Lync share needs to have the following 3 files:-

The time and date stamp on these indicates when they were initially created.
The file structure ia as below.

The second level 00000000-0000-0000-0000-000000000000 folder should be time stamped with the last time the AddressBookService was updated (with approximatly 5 minutes added to it).

You could run a Update-CsAddressbook PS command and after about 5 minutes the folder should be updated.

An error I can across recently, the client reported that the “Corporate Address book file appears to be damaged”

Deleting the second level 00000000-0000-0000-0000-000000000000 folder removes the corrupt file. Simply running another Update-CsAddressbook PS command will recreate the folder and its contents.

If the IIS bits are misbehaving its probably best not to fiddle with tnem as the rights, paermissions and accounts required are configured by the installer. What you could try is uninstall lync web component module (control pannel > uninstall …), delete web component directory (C:Program FilesMicrosoft Lync Server 2010Web Components) then reinstall web component through lync deployment wizard.

Smarter Together

~ by I.M.H.O.

Category Archives: Communicator

Troubleshooting Address Book Service issues

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: