SharePoint Ports, Proxies and Protocols ....

Why is this important to understand?

So the first question is "why do we care about farm communications"? .... There are three reasons why every SharePoint architect, consultant should know about this stuff and they are as follows:

• 1. Secured or ‘locked down' farms may have servers on different network segments and you may have to configure firewalls to only let the minimum traffic through. Without know what traffic needs to go where, this is a very difficult process.
• 2. Understanding network activities is very useful when trying to troubleshoot strange problems since SharePoint does not do a great job of reporting when there are network issues preventing something from working.
• 3. Windows Server 2008 and SQL 2008 are both ‘locked down' by default. Meaning that a fresh install of Windows Server 2008 will have everything disabled in Windows Firewall. Clearly you could simply enable all inbound / outbound communications (and I've done that once or twice myself in the past! J) but that kind of defeats the point. It is much better to understand what traffic is coming in and out of the server and open ports as necessary.

SharePoint Transport Protocols

All traffic within SharePoint occurs over one of three transport protocols, they are:

• SQL Server Tabular Data Stream (TDS). This is the protocol that handles all traffic in and out of SQL. By default this occurs on port TCP:1443 but named instances of SQL will have a random port assigned.
• Server Message Block (SMB). Rather surprisingly, this ancient file-sharing protocol is used extensively for search and query operations with SharePoint. This occurs on port TCP:445 or TCP:137,138,139 (over NetBIOS).
• Hyper Text Transfer Protocol (HTTP). No big surprise here, HTTP handles all incoming traffic and inter-farm web service calls. This normally incoming traffic occurs over ports TCP:80 or TCP:443 (SSL) but this depends on how your Web Applications have been configured. Shared Service Provider web service calls occur on ports 56737 and 56738 (SSL).

In addition to the above, SharePoint obviously has to communicate with other servers such as Active Directory, DNS etc which require other ports, they are as follows:

• AD Authentication: Occurs on TCP:445 or TCP:88 (Kerberos)
• LDAP: Occurs on LDAP:389 and LDAPS:636
• DNS: occurs on TCP:53
• SMTP: Occurs on TCP:25

Inter-Server Communication

The term ‘Inter-Server' is used to describe traffic which occurs between servers inside the SharePoint farm. This includes the SQL server. The vast majority of traffic in this area is traffic to and from SQL server, which is why people always say that the SQL is the most important server in the SharePoint farm. This diagram describes the inter-server traffic. A large version of this image can be found here.

Extra-Server Communication

The term ‘Extra-Server' is used to describe traffic that occurs between the SharePoint farm and other servers. This would typically include AD, DNSD etc but you must also consider any external Indexing and BDC connections. This diagram describes the extra-server traffic, a larger version can be found here.

Client-Server Communication

Client server communication refers to all traffic between the SharePoint farm and clients which may include Office, Browsers, and SharePoint Designer etc. All of this traffic occurs over HTTP and only ever interfaces with the Web Front End server. None of the other servers in the SharePoint farm handle client-server traffic. This diagram describes Client-Server communications, a larger version can be found here.

SharePoint Protocols

The actual communications that occur within SharePoint happen using a wide range of SharePoint-specific protocols. These protocols are documented in great detail here; additionally there are similar documents for Office protocols here.

The documents contained in the above links include a massive amount of detail on how specific operations within SharePoint occur. For example, if you want to know which servers, stored procedures and other protocols are involved when you interact with the recycle bin, check out ‘[MS-WSSCADM]: Windows SharePoint Services Content Database Administrative Communications Protocol Specification‘.

These documents are a great resource for really understanding the low-level details of what your SharePoint servers are doing.

Search Specifics

One of the main type of Inter-Server communication is based around Search and Indexing. Interestingly, the communications channels used are primarily SMB which means that SMB must be allowed through firewalls if different servers are on different network segments.

Search & Index has 3 main types of activity, they are as follows:

• Search Administration. This is simple HTTP traffic to the Office SharePoint Server Web Services which occurs on ports TCP:56737 and TCP:56738 (SSL). This is used to administer the Search service.
• Search Crawling: This is the process of eth Index server crawling SharePoint and external content. During a crawl there is heavy traffic both between eth Index server and the content and the Index Server and SQL
• Search Index Propagation: During an crawl, the Index Server will propagate the indexes to the Query server. This occurs throughout the indexing process (it does not wait until indexing has complete to propagate). This communication occurs over SMB which means that an SMB channel must be open between eth Index and Query servers.
• Search Query Execution: This is the process of a user executing a query on eth Web Front End Server and it being passed to the Query server for execution. This also occurs over SMB which means that an SMB channel must be open between you Web Front End and Query Servers.

Tools

In terms of troubleshooting, there are three tools that are invaluable in terms of understanding network communications, they are:

• SQL profiler. This is a tool that has been package with SQL for many years now. Profiler essentially allows you to view exactly what is happening inside SQL. If you use this in conjunction with teh SharePoint protocol documents you will be able to see specific stored procedures being executed when certain activities happen.
• WireShark. This is a physical packet sniffer that can be used to examine all network packets. You can download WireShark here.
• Fiddler. This is a HTTP debugging application that can be used to examine HTTP traffic. This is simpler than WireShark but will not cover TDS or SMB (which WireShark will). You can download Fiddler here.