In part 1 I talked about architecture for a SharePoint external environment. Lets see how to implement such an environment.
Network/Data Flow
It is important to understand network flow for a SharePoint environment to be able to implement it without hitches.
A nicely compiled list of required network ports.: Click Here
 |
| source: http://blogs.msdn.com/b/uksharepoint/archive/2013/01/21/sharepoint-2013-ports-proxies-and-protocols-an-overview-of-farm-communications.aspx |
All the mentioned ports are default as used by applications. Change them as per your organizational requirements. If you don't have more than 10,000 users; don't bother setting up separate Distributed Cache servers. You can run Distributed Cache on your WFEs.
If you have decided to host all Farm servers in single network subnet then it shouldn't be much of a problem to allow ports except for non-Farm servers such as SMTP host, external content servers etc...
In case you are hosting WFE and application servers in separate network segments, you will have to make sure all required network ports are open among them.
Some organizations take network security very seriously. They like to keep their DMZ alienated from other corporate networks. I came across a similar situation where WFEs were in DMZ but application servers were to be hosted in HTZ so that app servers can connect to data warehouse in GNZ. Most importantly, a blanket connectivity on specific ports between DMZ and HTZ was not allowed. The only way to connect WFE with application servers was to configure communication through a web service security appliance. This poses unique challenges because SharePoint farm servers communicate directly on specified ports. All internal communication happens using NetBIOS names.
In order to configure Web Service Security Appliance, we must know exact web service endpoints that initiate connection from WFE to App servers. Each of the SharePoint service application have its own set of web services. All these web services are SOAP, but Microsoft uses custom SOAP format. In order to find out exact web service end points for the service application, check application server IIS Manager on server where that service is installed.
Lets take an example of SSRS (SharePoint integrated mode).
Open IIS Manager on SSRS application server. Under "SharePoint Web Services" expand web application for SSRS. In case there are multiple web applications, best way to identify correct web application is to check its application pool. It is a good practice to keep separate service accounts for different services. The application pool configured with SSRS service account is correct app pool; and the web application using that app pool is the web app used for SSRS. Click on web app and check Content View.
These WCF Web services ending with .svc. You will have to configure following web services for SSRS.
- AlertingWebService.svc
- ReportExecution.svc
- ReportingWebService.svc
- ReportServiceBackgroundProcessing.svc
- ReportStreaming.svc
Because all network communication from WFE to App servers should pass through Web Service Security Appliance, hosts file on WFE should reflect changes for IP - App Server name. Make following changes in hosts file on WFE.
<web service security appliance IP> <App server NetBIOS name>
If your web service security appliance requires app server name to forward traffic, always use app server NetBIOS name; NO FQDN. In case your web service security appliance validates soap service, its going to stop all traffic as SharePoint web services don't follow standard soap format. Best way to avoid this problem is to configure web service security appliance with REST.
