A solid SharePoint setup requires more than just running the installer. Poor infrastructure decisions often lead to instability, poor performance, and costly migrations later. This post covers common mistakes made during the initial setup phase, divided into SQL Server and SharePoint infrastructure concerns.
SQL Server Mistakes
No SQL Server alias
Relying on a direct SQL Server name ties your SharePoint farm to a specific machine name. Without an alias, future migrations or server replacements require a full rebuild or painful reconfiguration. A SQL alias provides flexibility and makes disaster recovery much easier.
SQL installed on the same machine as SharePoint
This is a classic performance bottleneck. Both SQL Server and SharePoint are resource-hungry applications. Hosting them together causes CPU, memory, and I/O contention, severely degrading performance and scalability.
No failover
SharePoint is only as resilient as its database layer. Without SQL clustering or Always On availability groups, any SQL Server failure will bring your entire farm down. Redundancy is essential for uptime and disaster recovery.
Inappropriate SQL Recovery Models
Choosing the wrong recovery model can have serious consequences for backup and restore strategies. Content databases should use the Full recovery model to enable point-in-time recovery and ensure data protection. On the other hand, service application databases can typically use the Simple recovery model, as their data is less critical and easier to rebuild. Mixing these up may lead to unnecessary transaction log growth or insufficient recovery options.
Improper Auto-Growth Settings
Leaving SQL Server’s auto-growth settings at their defaults is a common mistake. By default, growth is set to 1MB for data files and 10% for logs, which leads to frequent small growth events — each one causing a performance hit. For production environments, auto-growth should be configured with larger, fixed increments appropriate to the size and usage of each database. Better yet, regularly monitor and manually grow files in advance to avoid auto-growth during peak usage.
SharePoint Server Infrastructure Mistakes
All components hosted on one machine
Running the web front end, application services, and SQL Server all on a single machine violates best practices for role separation. It hinders performance tuning, security, and scalability.
Lack of Redundancy
Even in a production environment with fewer than a thousand users, it’s important to plan for high availability. I strongly recommend scaling out by setting up redundant servers for each major SharePoint role — web front ends, application servers, search components, etc. This ensures that services remain available during hardware failures, maintenance windows, or upgrades. Redundancy isn’t just for large enterprises — it’s essential for any environment where uptime matters.
No SLA definition
Without a Service Level Agreement (SLA), expectations between IT and business users are unclear. How fast should incidents be resolved? What uptime is acceptable? Not defining these metrics leads to dissatisfaction and unmanaged risk.
No disaster recovery plan
Backups alone are not enough. A disaster recovery plan defines who does what, when, and how — ensuring your SharePoint environment can be restored quickly and correctly in case of a failure.
All logs written to disk C
By default, SharePoint and IIS dump logs into the system drive. If left unchecked, this fills the OS disk, crashes the server, and causes outages. Logs should be redirected to a dedicated drive with monitoring in place.
Conclusion
Many of these mistakes stem from underestimating SharePoint’s infrastructure needs. Treat SharePoint like a mission-critical application from day one — plan for performance, redundancy, and growth. Avoiding these pitfalls early on can save your organization serious time and money later.