Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem


1 Comment

Exchange: Network Ports and Flows References

Having recently dealt with MS Exchange vs. Firewall and flows issues, I thought it might be interesting to post a summary of useful links related to network ports and flows used by Exchange and various clients . Bottom line: Exchange and firewalls ain’t no good friends but you already knew that don’t you?

Clients and Mailflows

Unified Messaging

Hybrid Deployments

Other Resources

Advertisements


2 Comments

SharePoint: SNI vs. Windows WebDAV Client

Introduction

SNI stands for Server Name Indication, an improvement to the SSL/TLS protocol recently added to Windows (from Windows Server 2012/IIS 8). Its purpose is to allow using multiple SSL certificates on the same web server’s IP address and port. In a certain sense, you could say it is to HTTPS what host header is to HTTP. Similarly to host header, this feature must be implemented in both client and server sides because it relies in additional information’s passed as part of the SSL handshake process initiated by the client. As consequence, older browsers (as well as older client applications in general) are not compatible.

The Problem

Now SharePoint comes into the picture. One key client functionality is the Explorer View exposed by Windows WebDAV Client. Although Microsoft continuously updates its browser, the WebDAV client did not recently receive any update to support SNI. Therefore, if you configure SharePoint together with IIS to use HTTPS using SNI, Windows Explorer browsing SharePoint will simply stop functioning displaying an error such as “A device attached to the system is not functioning”. The problem will sadly occur with Windows 8 as well but is fixed from Windows 8.1.

Workarounds

There is currently no real solution and very few workarounds:

  • On IIS: Use unique combination of web application, certificate and IP address and/or port. Every time a new web application is created on SharePoint, you will have to reconfigure it on each server in the IIS configuration in order to use another IP address or another port.
  • On Windows/HTTP.sys driver: Use a fallback certificate. This blog post details the procedure to do so: How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2
  • On a hardware load balancer: identically to what can be done on IIS, a unique virtual IP address for each web application together with its own certificate can be used. On the SharePoint side, you can whether use no certificate at all or a used self-signed one.

More Information


Networking: Microsoft has Released Message Analyzer

Message Analyzer Logo

Yesterday, Microsoft has released the successor to Network Monitor: Message Analyzer.

Beyond the name change, Message Analyzer comes with a brand new way of capturing and analyzing network traffic: Instead of capturing at a very low level and filtering the flows to identify useful one, it allows to capture closer to the protocols or to the OSI-layer you are interested in. As the screenshot show hereunder: there are plenty of pre-configured layer or protocols (HTTP, Windows Firewall, File & Print Sharing, network adapter…). This greatly simplifies analysis and reduces the impact on system resources as well.

Message Analyzer Screen Capture

The capture’s details are also much easier to read, as depicts the screenshot hereunder.

Message Analyzer Screen Capture

Finally, the footprints is also reduced and the whole application is less intrusive since it does not requires to install a filtering driver. Instead, it leverages the Event Tracing for Windows (ETW) infrastructure. Unfortunately, this also means that the minimal OS requirement is Windows 7/Windows Server 2008.

More Information’s


Windows: An existing connection was forcibly closed by the remote host

Two different projects complaining about the same issue: nice troubleshooting challenge! One is SharePoint-based and the second is a, let’s say “entertaining” .Net-based application. They both make use of SQL Server as back-end data store and both complain about having “existing connection forcibly closed” reported in they stack trace when then attempt to connect to SQL.

This happens when a client application is trying to re-sued an existing TCP connection to a remote host while it closes it, making connection reuse impossible. There are actually multiple possible root causes which do no seem to be mutually exclusive:

Limit set on the number of connection allowed by SQL Server on a given instance

For a given SQL instance, you can set the maximum number of connections that can be used by applications. Depending on the way your application is written, multiple connection might be used for a single transaction… Raise the limit or set it to unlimited as necessary.

The (infamous) Scalable Networking Pack

The Scalable Networking Pack is a set of improvements brought to the Windows Networking stack. It is available as an add-on for Windows Server 2003 but is included from Service Pack 2 as well as from Windows Vista/2003.

This update greatly modifies the way Windows handles network connectivity at TCP-level and might therefore provoke the error. In short, the following settings should be modified on the SQL Server (or on any server acting as the server component):

In the registry, under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters

  • EnableTCPChimney (REG_DWORD) set to 0 (disabled)
  • EnableRSS (REG_DWORD) 0 (disabled)
  • EnableTCPA (REG_DWORD) 0 (disabled))

Applying the change requires a reboot.[UPDATE] Some MS sources report that a reboot is not necessary for some settings so I switch my statement to *might* require a reboot.

You’ll find a lot of trustworthy online resources recommending to disable the SMP…

On the other hand, recent NIC drivers may allow your system to work properly with these options set to enabled… Look at this page to get a list of SMP “partners”: http://technet.microsoft.com/en-us/network/cc984184.aspx.

Faulty NIC, NIC driver or driver settings 

Some NIC include a TCP Offload Engine (TOE). Incorrectly configured or running an out-dated, they will generate error at TCP-level.

In some cases, the TOE simply does not work, so you also might want to test with this function completely disabled. When editing you driver’s parameters, look for “Large Send Offload”, “Checksum offload”…

Import to note, you might also want to check the link speed and duplex at NIC level AND at switch port level, they might also cause the problem. Remember,: they must be identical on BOTH sides

Applying the change *might* requires a reboot.

Windows TCP/IP Stack Custom Configuration or Hardening

There are plenty of resources describing how to “harden” the Windows TCP/IP stack. Unfortunately most of them simply show the “how to”, not its consequences. Of of them being the performance decrease implied by hardening. You’ll also find those parameters under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters

In our case, the parameter “SynAttackProtect” set to 1 instead of 0 (disabled) will force Windows to be more restrictive regarding the incoming or TCP connection requests and well as more aggressive with the re)use of existing one. If the parameter is  enabled, the following additional parameters will also be taken into account:

  • TcpMaxPortsExhausted: Determines the maximum number of connections that can be opened before enabling protection against SYN attacks
  • TCPMaxHalfOpen: Determines the maximum number of connections that can be left “half-open” (waiting for re-use)
  • TCPMaxHalfOpenRetried: Same as above BUT applicable to connections that were effectively re-used by the original client

The parameters above are thresholds used by Windows to determine if a TCP-based (SYN) attack is in progress or not. They should only be used if the server is put in a high risk situation (DMZ or internet-facing) while there is not other security device put in place (Firewall…).

Note that, before Windows 2003 SP2, this SynAttackProtect is set to 0 while with SP2, it is set to 1 then with the latest versions of Windows, it returns to 0…

Automatic adjustment for the TCP window size (From Vista or 2008 only)

On the client side, Windows, starting from Vista, comes with a feature that allows to dynamically set the TCP windows size depending upon the network (remote host) conditions. See http://support.microsoft.com/kb/929868. But I frankly doubt it can be the root cause, I just documented it for comprehensiveness.

If your application is affected by those problem, I hope you’ll find the culprit amongst one of those.

Any network device catching the traffic at TCP-level

If there is any firewall in place, look at their logs, they might reveal that some connections are refused when the client attempts to re-use them.

More Information

Thanks to Tim B (MSFT) and Pascal B (MSFT) for the hints and guidance.

And cut!

The French Connection Poster