Category: Infrastructure

SharePoint Infrastructure Workshop Topics

On By Tom ZhangIn Infrastructure, SharePointLeave a comment

I’ve run Infrastructure Workshops for many SharePoint implementation projects over the years. The objective of the workshop is to figure our how the farm(s) will be implemented in the customer’s environment. A few important decisions are made based on the outcome of the workshop:

  • Server and storage sizing
  • Network placement
  • Service account management
  • DR strategy
  • Farm configuration
  • etc.

I am sharing the checklist here in case it helps. 🙂 Feel free to leave your questions or feedback in the comment.

Infra Workshop Topics

Advertisement

SharePoint Three-Tier Network Zoning Architecture

On By Tom ZhangIn Infrastructure, Network, SharePoint6 Comments

This topic came when there were policies in some organizations that require SharePoint to comply with the “three-tier architecture” requirement, meaning WFE, APP and DB should be in three network zones, and WFEs CANNOT connect to the DBs directly! It is common to see SharePoint farms servers placed in three zones, but most of the time WFEs are allowed to connect to the DB Server. However, this is not acceptable to the organizations that has the “three-tier” policy in place.

I saw in some projects a proxy server is implemented in the APP zone to bridge WFE and DB. It works. However, that proxy can easily become a bottleneck in larger implementations. So far the most common way of implementation is to place one or multiple reverse proxies in the Web zone as the web layer, shifting the SharePoint WFEs to the App zone together with the App servers.

{update April 2018} What I propose in this post is an alternative using technologies on SharePoint. However, based on practical experiences, this approach is more theoretical than practical. So far, there is no production implementation yet. {/update April 2018}

This alternative approach leverages the Request Management of SharePoint. With that you may say SharePoint actually supports the 3-tier requirement. How Request Manager works is elaborated on TechNet. The design here is to:

  • Put the WFEs in the APP Zone so they can connect to the databases directly.
  • Put a dedicated request management farm in the Web Zone in between the Load Balancer and the WFEs, with databases in the same zone.

Good 3-thier Architecture

This way, the Request Management layer serves as the web layer interacting with user requests. The WFEs in the APP Zone become the content serving components that retrieve data from the databases at the back end, while they are in the secure internal APP network zone.

Q: is it OK to place a database server of the Request Management farm in the web zone?

A: Yes, there is no user data stored in the database, only farm service configuration data. And the firewall rules should be restricting network traffic to the DB server to come only from the Request Management Farm servers.

Q: When the actual WFEs in the APP zone servers content back to the users, do they transfer it directly to the users?

A: No, it responds back to the users through the Request Management farm. This is actually the key part that makes the architecture above possible as users are not able to reach the App Zone.

Q: Should Office Web Apps Server be placed in the Web Zone or the same zone as the actual WFEs?

A: It must be reachable by the end users directly, so it should be more suitable to be in the Web Zone.

PS: The diagram below shows a bad design example that uses a proxy:

Bad 3-tier Architecture

Real Zero-Downtime Patching in SharePoint 2016

On By Tom ZhangIn Infrastructure, Patching, SharePointLeave a comment

It is exciting to have Zero-Downtime Patching (ZDP) capability in SharePoint 2016. However, it requires more effort than most of us might have initially thought. While it is straightforward for other components, it requires a bit more care on Distributed Cache.

Distributed Cache doesn’t support High Availability the way that other services do. While multiple Distributed Cache servers in your SharePoint farm can help distribute the load, the data cached on each Distributed Cache server is NOT replicated to the other Distributed Cache servers. If a Distributed Cache server unexpectedly goes down, the data cached on that server will be lost. That means if you install patches and upgrades a Distributed Cache server without gracefully shutting it down, you will cause data lost!

One may argue that if there are three Distributed Cache hosts on the farm, there will be high availability for the Distributed Cache as AppFabric has as cluster quorum model. That is not true as SharePoint is not using that model!

Therefore, if you have workloads that heavily depends on Distributed Cache and have high availability requirements, add Gracefull Shutdown of the Distributed Cache Service into the patching process to have true Zero-Downtime.

Gracefully shutdown DCS: https://technet.microsoft.com/en-us/library/jj219613.aspx#graceful

One Single IP:port for Multiple SSL Enabled Sites, each with a Different SSL Certificate

On By Tom ZhangIn Infrastructure, NetworkLeave a comment

In a real-world production environments, there can be multiple web applications in the same farm that use different host headers but the same port, which is often 80/443. This is not an issue when SSL is not implemented. When the request reach the web server, IIS will direct the request to specific sites based on the host header. However, if SSL is to be implemented and all the sites will be using the same port, there will be a problem with the certificate as network end-point can only be identified with IP:Port binding. In the old days, two possible solutions are:

  • Use two IPs on the same server, so that each IIS site can use a different certificate. This is should not be too difficult when the WFEs are virtualized.
  • Use a wildcard certificate so all the web applications can use the same certificate as long as they share the same domain.  If not, you may want to choose a Unified Communications Certificate if that really is a preferred solutions in your situation.

With Windows Server 2012 or above, you have the third option that comes with the Server Name Indication feature of IIS 8. This feature makes it possible that the host name in the IIS binding be used to identify the network endpoint. In this case, different IIS sites can use the same IP address and port while using different certificates. However, it requires the client browsers to support SNI. If not, you need to create a default SSL site. Check this blog post for more information: http://blogs.msdn.com/b/kaushal/archive/2012/09/04/server-name-indication-sni-in-iis-8-windows-server-2012.aspx