Event ID 41025 - Conferencing Edge Server -

I was wondering about an elusive and very intermittent desktop sharing issue via the Edge Server. The only evidence of wrong doing was the Event Log on the Front End Server. The log was looping through Event ID 41025 and 41026 every 2 to 3 seconds!!!

Surely that's not normal...

The BPA showed no evidence either. Used a simple telnet test from the FE to the CE over ports 8057 and 5062. All working.

Searching for Event ID 41025 on TechNet I found a post quoted below

"For the 41024, 41025, 41026 loop of errors, the issue was tracked down to a strange certificate issue.

On the Edge External Nic I had used one vendor's for the UCC certificates (GoDaddy), as well I used that same vendor for the certificates on Exchange, TMG, and on the FE server Nic BUT for the internal facing edge NIC I had used a different vendor (RapidSSL) as I already had it.

I replaced the certificate from the one vendor with essentially the same thing but issued from the same vendor as all the other certificates in the deployment (GoDaddy)"


Ok, probably a good idea to check the cert assignments on the Edge Server. Turns out that I was using the same GoDaddy cert on the internal and external interfaces. Mmm...

Started to wonder if the FE was happy with that as the internal servers all used an internal CA. Two choices, either replace the Edge internal cert with one from the internal CA or export the Edge GoDaddy cert and import to the FE Personal Store. 

I went with option 2 and voila, Event ID 41025 gone!!!

EWS not working externally

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

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 “LyncLab\KerberosUserAccount” –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 “LyncLab\KerberosUserAccount” –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 “LyncLab\KerberosUserAccount”

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:\Temp\Kerberos test.htm” –Verbose