Install-WindowsFeatures Fail Server 2012R2

So after attempting to use Pat Richards Lync install script (http://www.ehloworld.com/1697) I was seeing errors on the Lync FE server that Lync prerequisites were failing during the install.

After some trail and error of individual features I was able to narrow it down to two (2) features that were failing;

• web-asp-net
• web-asp-ext

So off to Google to find an answer, first post was from Greig Sheridan (https://greiginsydney.com/add-windowsfeature-fails-on-server-2012/), the patch that Greig and co. had identified wasn't install on my 2012R2 server.

After a few discussions with colleges around what could be causing the issue it was found to be another windows patch that was stopping the install.

http://support.microsoft.com/kb/2966828

So after we removed the patch from the server, the install worked with no further issues..

SIP_E_AUTH_NTLMMISMATCH

Have come across this error again today whilst deploying an 2013 Edge server and users wont able to log in.

In the SIP traces from the Edge server after the usual 3 attempts or registration, the client wont login and one of the last message in snooper is:

ms-diagnostics: 1000;reason="Final handshake failed";HRESULT="0xC3E93EE4 (SIP_E_AUTH_NTLMMISMATCH)";source="FE Server"

The fix is to change the local security policy for the Lync servers to allow for no minimum for NTLM SSP session security.

From the local security policies on the Lync servers remove the tick from the "Require 128-bit encryption"

 

Lync Server Install Fails on SQL Express Install

Have run across this issue a few times now and it always take me a while to find to find the registry key that needs to be updated so thought I would port about it.

The issue is that the SQLExpress install fails as the systems thinks there are pending file deletes to happen during a reboot, but even after the reboot you get the same error.

The below is the error that is seen.

The registry key that needs to be updated is under:

HKLM > SYSTEM > ControlSet001 > Control > Session Manager > PendingFileRenameOperations

Just open the entry and delete the contents, close the Lync Deployment Wizard and re-run the Lync Bootstrapper.  All should be good.

Call failed due to network issue

The error message "Call failed due to network issue" can be caused from a number of different reason, the following post outlines some of the issue that I have so far found.

Monitoring Server
The first thing to check is to check the monitoring server reports for an error message.  Usually the error is some thing like "Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote"

Candidate information
Checking the  candidate information from the SIP packets during the call.  What we are looking for is that both the Edge AV Service IP address and the NAT IP address (of your home router etc) is being sent and received by the two clients.

DNS
If the candidate information is not being sent first thing to check is that the internal client can resolve the DNS host name of the Edge Server to the INTERNAL interface.  

If the DNS results returned don't match the IP address of the internal check DNS to make sure that a error hasn't been made with a static entry and check that the Internet facing NIC's in the edge server.  If there are dynamic entries in the DNS check that the "Register this connection's address in DNS" 

From the NIC properties select "Internet protocol Version 4 (TCP/IP)

Select Advanced

Select the DNS tab, then un-tick the "Register this connection's address in DNS"

Firewall:

The Media Relay Authentication Service (MRAS) is responsible for notifying the Lync client of the STUN and TURN IP address for ICE.  This service run on UDP port 3478.

To check that the UDP port is open on the firewall between the Internal Lync clients and the Edge server running this service you can use the Microsoft tool PortQry

PortQryUI: http://www.microsoft.com/en-us/download/details.aspx?id=24009

PortQry: http://www.microsoft.com/en-au/download/details.aspx?id=17148

Lync Client Policy

There is a Lync client policy setting called "DisableICE", from Technet the DisableICE value is described as "When set to True, Lync 2010 will not use the Interactive Connectivity Establishment (ICE) protocol to traverse firewalls and network address translation (NAT) devices; this effectively prevents users from making Lync 2010 calls across the Internet. When set to False, Lync 2010 will use the ICE protocol to enable Lync 2010 calls to traverse firewalls and (NAT) devices."  If this has been set to TRUE then the Lync Client wont communicate with the MRAS service.

STRACE and HTTPRelay

Whilst watching a Lync training video the other day, the instructor was using a very nice tool from Microsoft called STRACE.  It provided the ability to log all the HTTP/HTTPS requests that a particular application would make whist it was running.

I have used this program along with HTTPReplay a few times since to troubleshoot EWS errors in the Lync client.

So though I would try and put together some notes on how to use it.

First the programs can be downloaded from:
STRACE:       http://www.microsoft.com/en-us/download/details.aspx?id=7643
HTTPReplay:  http://www.microsoft.com/en-us/download/details.aspx?id=3121


Once installed, the process is traceing/troubleshooting/logging is done in two (2) parts.

1. Launch the required program to trace (in this case the Lync client) using the strace DLL.
2. View the output of the STRACE using HTTPReplay

STRACE

From a command prompt change to the directory that the STRACE program was installed.

cd "c:\Program Files (x86)\STRACE"

Launch the required application with the following command

withdll /d:STRACE.DLL MYAPPLICATION.EXE

The actual command to launch with communicator will be something like

withdll /d:STRACE.DLL "c:\Program Files (x86)\Microsoft Lync\communicator.exe"

The STRACE program will continue to log details of HTTP and HTTPS requests until you exit the program that was launched. So exit Lync and the STRACE program will complete.

This will create a file on your desktop called:

STRACE_COMMUNICATOR_PID_<PID Value>_<DATE>_<GMT Time>.LOG

HTTPReplay
Copy this file to the install directory of the HTTPReplay program

c:\program files (x86)\httpreplay\

From a command prompt change to the HTTPRelay directory.

cd "c:\program files (x86)\httpreplay"

Launch the HTTPReplay application with the STRACE log file that was created earlier.

httpreplay.cmd STRACE_COMMUNICATOR_PID_<PID Value>_<DATE>_<GMT Time>.LOG

The will again be a file created on the desktop, this time a .html file called HTTPREPLAY.HTML.  This file will automatically open in your default web browser.

From the image above you can see the URL, and the HTML status code from the request.  In the example you can see that there are a few status codes with "500" as the value. A HTML status code of "500" is "Internal Server Error"

Clicking on the status code value will give more details of the actual error that was generated.

From the generated "500 - Internal Server Error" message we can see that the error occurred due to an account being locked out.

In this case once the account was "un-locked" in AD the users problem was resolved.

So to cover off the commands again, just because I'm lazy and don't want to have to copy and paste from a few spots in this post.

cd "c:\Program Files (x86)\STRACE"

withdll /d:STRACE.DLL "c:\Program Files (x86)\Microsoft Lync\communicator.exe"

copy the STRACE log file to "c:\program files (x86)\httpreplay\"

cd "c:\program files (x86)\httpreplay"

httpreplay.cmd STRACE_COMMUNICATOR_PID_<PID Value>_<DATE>_<GMT Time>.LOG

TLS Outgoing Connection Failures

Whilst checking a event viewer on a Lync Front End today I noticed.

The above message has the right host name but WRONG IP address, after checking DNS I found four (4) entries for the Edge server.  three (3) entries with IP address for the external NIC of the edge.


So I figured that the external NIC was trying to register with DNS.


From the NIC properties select "Internet protocol Version 4 (TCP/IP)

Select Advanced

Select the DNS tab, then un-tick the "Register this connection's address in DNS"

You may see the initial error message appear in the event view one (1) more time before it stops reporting.

Exchange connection down

So when this error occurs to check the status of Exchange Web Services (EWS) launch outlook and try to schedule a meeting, if you can see the calendar availability of people you are trying to schedule a meeting with the EWS is ok

So this will tell you if you have a try Exchange connection error, if you are able to see other peoples schedule through outlook, I would suggest you run a trace using STRACE and HTTPReplay to see if any error are being presented via the EWS.

I have a blog post about using STRACE and HTTPReplay here: http://myucthoughts.blogspot.com.au/2012/06/strace-and-httprelay.html