Although SharePoint Online has changed how organisations look at providing the SharePoint platform, we continue to build SharePoint Server 2016 and SharePoint Server 2019 environments for our customers. Provisioned in their Datacentres or in Azure IaaS where they have requirements beyond what Office 365 can offer.
If you’re thinking on-premises, here are 6 things to consider before you start:
1) Planning your server farm
Each server requires a separate build and you will need to repeat that for each environment. For production and possibly UAT you will have at least 2 servers performing each role for a High Availability (HA) environment. High traffic sites may have more servers in the farm.
Typical Production HA Environment- 2x SharePoint Front-end with Distributed Cache Server
- 2x SharePoint Application with Search Server
- 2x Office Online Server
- 2x SQL Servers – With either Always On Availability Groups or Failover Clustering
- Production / Live (HA)
- UAT
- Development
- Training
- Sandbox
- Disaster Recovery
2) Right drive for the right job
We’ve undertaken a significant amount of remediation work: time and time again we’ve seen that SharePoint application files and logs point to the C: drive and this always leads to issues: we look to use different drives for the OS (C:), SharePoint Application and Logs.
3) Service accounts are key
Your goal is “least privileged administration”, to do this well approximately 10 accounts are required with appropriate permissions for each account. How not to do it is to use the Farm Account for everything, which is a highly privileged account.
4) It takes time
A single environment takes around 3 days to build depending on your environment and the level of documentation required.
5) Every environment ends up slightly different
"Configuration Drift" isn't uncommon: us humans aren’t good at doing the same task constantly and accurately - this introduces minor changes in each environment - that in turn leads to the integrity of your platform being compromised.
6) Rebuilding can be painful
Knowing the time it takes to build an environment, and making sure you have the right person available to do it, often means we don’t refresh non-production environments as much as we should, again leading to gaps between your environments.
So, what is our approach?
SharePoint Consultancy is a significant part of our business, and we deliver SharePoint infrastructure on a frequent basis, so we've developed a package of scripts and environment - specific configuration files to allow consistent builds every time, leveraging the PowerShell Desired State Configuration (DSC).
Our starting checklist is:- Servers are provisioned
- Source files are copied on to those servers
- Service accounts are set up
- Environment specific configuration files are created
We then execute our scripts to complete the build.
But then by running our scripts our customers benefit from:- Identical environments
- Hands off deployment
- Secure configurations (configurations are encrypted meaning things like service account passwords are secure)
- Environment governance: DSC ensures that environments remain in their desired state eliminating configuration drift between environments
- Easy to reuse for temporary environments e.g. training or development, or to decommission and recommission in Azure to save consumption costs
- Azure friendly - create a truly elastic environment and use Azure as a central repository for configurations and reporting
What you can do
If you're looking to get started on this - explore the Microsoft Documentation on DSC for engineers, and for decision makers.
https://docs.microsoft.com/en-us/powershell/dsc/overview/dscforengineers
https://docs.microsoft.com/en-us/powershell/dsc/overview/decisionmaker