SharePoint Server: Setup, Policies, and Admin Configuration Guide 2026

Microsoft Fix Advanced 18 min read Official Docs Grounded Updated April 20, 2026
What's in This Guide
  1. Why This Is Happening
  2. The Quick Fix , Try This First
  3. Step-by-Step Solution
  4. Advanced Troubleshooting
  5. Prevention & Best Practices
  6. FAQ

Why SharePoint Server Configuration Goes Wrong

If you're reading this, something is broken , or you're trying very hard to make sure it doesn't break. Either way, I've got you. I've spent years inside SharePoint Server farms ranging from a single-server sandbox to multi-datacenter Subscription Edition deployments, and I'll tell you the honest truth: SharePoint Server is one of the most powerful collaboration platforms Microsoft has ever built, and also one of the most unforgiving to configure incorrectly.

The platform spans four actively supported versions, SharePoint Server Subscription Edition, 2019, 2016, and 2013, each with its own hardware requirements, upgrade paths, and update packaging model. Most of the pain I see in enterprise environments comes from three root causes.

First, mismatched update states across farm servers. SharePoint farms are multi-server beasts. If one server gets the March 2026 cumulative update (KB 5002843, version 16.0.19725.20076) and another is still sitting at the October 2025 build, the Configuration Wizard will refuse to complete and Central Administration will throw cryptic database schema errors. The farm thinks it's in a broken state, because it is.

Second, the pre-March 2023 dual-update confusion. Before Microsoft changed its packaging model with the Version 23H1 release, you had to install two separate updates: the language-independent STS update and the language-dependent WSSLOC update. Admins who skipped the WSSLOC package ended up with farms that were partially updated, English UI worked fine, but language pack installations broke in subtle ways that only surfaced weeks later during a failover test.

Third, farm configuration steps done out of order. Running the SharePoint Products Configuration Wizard before all servers in the farm have the same patch level, or skipping the post-update timer job execution, produces errors that look like hardware failures but are really just sequencing problems.

Microsoft's error messages in these scenarios are legendarily unhelpful. You'll see things like "An exception of type Microsoft.SharePoint.Upgrade.SPUpgradeException was thrown" with a stack trace that points at internal framework code, not at the actual thing you did wrong. That's what this guide is for.

Browse all Microsoft fix guides →

The Quick Fix, Try This First

Before you go deep, run this PowerShell command on every server in your SharePoint farm. It will tell you the current patch level of each server and flag any version mismatches immediately. Open the SharePoint Management Shell as Administrator and run:

(Get-SPFarm).BuildVersion
Get-SPServer | Select-Object Name, NeedsUpgrade

If any server shows NeedsUpgrade : True, that's your smoking gun. The farm database schema is ahead of the binaries on that server, which means the Configuration Wizard needs to run there, or you haven't yet installed the latest cumulative update on that machine.

The fastest path to resolution for most SharePoint Server Subscription Edition farms in 2026 is to install the current cumulative update (KB 5002843, released March 10, 2026, build 16.0.19725.20076), run the SharePoint Products Configuration Wizard on all servers in the correct order (database server first, then application servers, then web front ends), and then force the upgrade timer job to complete:

$farm = Get-SPFarm
$farm.BuildVersion

# Kick off the upgrade job manually if it's stalled
$upgradeJob = Get-SPTimerJob "job-database-schema-update"
$upgradeJob.RunNow()

Wait five minutes, then check Central Administration > Upgrade and Migration > Review Database Status. Every content database should show a green status. If it does, you're done.

If you're on SharePoint Server 2019, 2016, or 2013, the same core logic applies, check your version, get to the latest cumulative update for your version, and run the Config Wizard in the right sequence. The specific KB numbers differ by version, but the process is identical.

Pro Tip
Always install SharePoint cumulative updates during a maintenance window, never mid-week on a live farm. The Configuration Wizard requires IIS application pools to restart on every web front end, which will drop active user sessions. Schedule it, communicate it, and give yourself 90 minutes minimum per server in the farm.
1
Verify Hardware and Software Requirements Before Anything Else

I've seen SharePoint Server installations fail at step one because someone skipped the hardware and software requirements check. Microsoft is very specific here, and those requirements differ by version. For SharePoint Server Subscription Edition, you need Windows Server 2019 or 2022, SQL Server 2019 or 2022, and specific .NET Framework versions installed before you even run Setup.exe.

Open a PowerShell window and check your OS build and .NET version first:

[System.Environment]::OSVersion.Version
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").Release

A release value of 533320 or higher means you have .NET Framework 4.8.1 installed, which Subscription Edition requires. Anything lower and the SharePoint prerequisite installer will fail, sometimes silently, sometimes with the misleading error "This product requires .NET Framework 3.5" even though the real issue is the 4.x version.

For SQL Server, verify that the SQL Server service account has the correct permissions. It needs dbcreator and securityadmin server roles in SQL Server to create and manage SharePoint configuration and content databases. Navigate to SQL Server Management Studio > Security > Logins, find your farm account, right-click > Properties > Server Roles, and confirm both are checked.

When the prerequisites are all satisfied, you'll get through the prerequisite installer without a single reboot loop, which is how you know you did it right.

2
Install the Correct Cumulative Update for Your SharePoint Version

This step trips up even experienced admins. SharePoint updates are cumulative, each monthly update contains every fix released before it, so you only ever need the most recent update to be fully patched. You do NOT need to install them in sequence.

For SharePoint Server Subscription Edition, the current update as of this writing is KB 5002843 (build 16.0.19725.20076, March 10, 2026). Microsoft changed its update packaging model in March 2023 with Version 23H1, there is now a single monthly update file instead of the old separate STS + WSSLOC pair. If you're patching a farm that's still on a build prior to 16.0.16130.20206 (March 2023), you need both the STS and the WSSLOC files. After that version, one file handles everything.

Download the update, then install it on every farm server using an elevated command prompt. Do not double-click the .exe, use the command line so you can capture the exit code:

ubersrv2016-kb5002843-fullfile-x64-glb.exe /passive /norestart
echo Exit code: %ERRORLEVEL%

Exit code 0 means success. Exit code 17022 means success but a reboot is required. Exit code 17025 means the update is already installed. Any other code means something went wrong, check %temp%\opatchinstall*.log for the full error detail.

Install the update on all servers before running the Configuration Wizard on any of them. This is the single most common sequencing mistake I see.

3
Run the SharePoint Products Configuration Wizard in the Right Order

After every update installation, you must run the Configuration Wizard (PSConfig) on every server in the farm. The order matters. Run it on the server hosting the Central Administration site first, then work through the remaining application servers, and finally the web front ends.

For automated, scripted deployments, or when you're managing a large farm and don't want to click through the GUI, PSConfig.exe is your friend:

PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

Run this in the SharePoint Management Shell (or a regular elevated cmd window where PSConfig is in the path, typically C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\BIN).

Watch the output carefully. A successful run ends with "Configuration of SharePoint Products has succeeded." If it ends with "Configuration of SharePoint Products has failed", don't panic. Check the PSCDiagnostics log at:

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\LOGS\

Sort by date modified and open the most recent PSCDiagnostics file. The failure reason is almost always on the last 20 lines. Common causes: SQL Server connectivity dropped, the farm account doesn't have enough SQL permissions, or a previous PSConfig run left a lock file behind at C:\Windows\System32\msiexec.exe (kill any lingering msiexec processes first).

4
Configure Farm-Level Policies and Service Accounts

A freshly built SharePoint Server farm needs its service accounts configured correctly before you enable any service applications. Using a single account for everything, the farm account, the application pool account, the search service account, is a security antipattern that Microsoft explicitly warns against, and I've personally watched it cause Kerberos authentication failures in three separate enterprise deployments.

The minimum you should define before going live:

  • Farm account (SPFarm): runs the SharePoint Timer Service and Central Administration app pool. Should NOT be an interactive logon account.
  • Web application app pool account: separate from the farm account, one per web application ideally.
  • Search service account: used by the Search Service Application. Needs read access to all content sources.
  • User Profile Synchronization account: if syncing with Active Directory, this account needs "Replicating Directory Changes" permission on the AD domain.

Register your managed accounts in Central Administration so SharePoint can automatically handle password rotation. Go to Central Administration > Security > Configure managed accounts, click Register Managed Account, and add each service account. Then in PowerShell:

Get-SPManagedAccount | Format-Table UserName, AutomaticChange, PasswordLastChanged

If AutomaticChange is False, SharePoint will not rotate the password, and the first time that AD password expires, every service running under that account will silently fail. Enable automatic change unless you have a specific reason not to.

5
Validate Central Administration and Content Database Health

Once the farm is patched and PSConfig has run successfully on all servers, do a full health check before you call the deployment done. Open Central Administration and navigate to Upgrade and Migration > Review Database Status. Every database should show status No action required. If any show Upgrade required, you have a server that didn't complete PSConfig, go back to that machine.

Next, run the built-in Health Analyzer. Go to Monitoring > Review problems and solutions. The analyzer will surface issues like app pools running under wrong accounts, missing timer job executions, and disk space warnings. Address anything marked Critical or Error before opening the farm to users.

For content database validation, use PowerShell to check each database's compatibility level and confirm no orphaned objects exist:

Get-SPContentDatabase | Select-Object Name, NeedsUpgrade, Status, DiskSizeRequired | Format-Table -AutoSize

Any database with NeedsUpgrade : True at this point means PSConfig didn't fully process it. You can target a specific database manually:

Upgrade-SPContentDatabase -Identity "WSS_Content_YourDB"

When every database returns NeedsUpgrade : False and the Health Analyzer shows no critical alerts, your farm is in a known-good state. Document the current build number and the date, this is your baseline for future troubleshooting.

Advanced Troubleshooting for SharePoint Server Admins

When the standard steps don't cut it, you need to go deeper. Here's what I reach for when a SharePoint Server farm is misbehaving and the obvious checks aren't showing anything.

Reading the ULS Logs the Right Way

SharePoint's Unified Logging Service (ULS) logs are verbose to the point of being overwhelming, but they're the single best diagnostic source on the platform. Every significant operation writes a correlation ID, a GUID you can use to filter the log to just the events from a specific failed request. When a user reports an error, ask them for the correlation ID shown on the error page (it's always displayed as a long hex string).

Then filter the ULS log on any farm server:

Merge-SPLogFile -Path "C:\Logs\filtered.log" -Correlation "your-correlation-id-here" -OverWrite

Open the resulting file in a text editor and search for entries with Unexpected or Exception in the Level column. That's where the real story is.

Windows Event Log IDs to Know

In Event Viewer, navigate to Windows Logs > Application and filter by Source = SharePoint Foundation. These are the event IDs that show up most often in broken farms:

  • Event ID 6398: Timer job execution failure. Usually means a service account password expired or a dependent service is down.
  • Event ID 5586: Unknown SQL Exception. Check SQL Server connectivity and disk space on the SQL data drives.
  • Event ID 7043: User Profile Synchronization connection failure. Check the MSOL or AD connector account permissions.
  • Event ID 8000: Application pool recycle. Frequent recycling usually points to memory pressure, check the IIS application pool memory limits in IIS Manager.

Group Policy Conflicts in Domain-Joined Farms

Enterprise environments often have Group Policy Objects that conflict with SharePoint's required configuration. The most common offenders are GPOs that enforce IE Enhanced Security Configuration (blocks Central Administration in browser), GPOs that restrict PowerShell execution policy (PSConfig relies on PowerShell), and GPOs that remove local administrator rights (needed during initial setup).

Run gpresult /h gpreport.html on the affected server, open the report, and look for policies applied under Computer Configuration > Windows Settings > Security Settings. Coordinate with your AD team to add the SharePoint service accounts and the SharePoint servers themselves to the appropriate exclusion groups before attempting another installation or upgrade.

SharePoint Server Upgrade Across Versions

If you're upgrading from SharePoint Server 2016 or 2019 to Subscription Edition, Microsoft's official guidance is a database-attach upgrade: you detach content databases from the old farm, mount them on the new farm, and run the upgrade. Do NOT attempt an in-place upgrade between major versions, that path was removed after 2013 and will leave your farm in a broken intermediate state.

Before any cross-version upgrade, run the pre-upgrade checker on the source farm:

stsadm -o preupgradecheck

This generates a report of all customizations, missing features, and compatibility issues you'll need to address before the databases can be successfully mounted on the new farm. Work through every warning in that report before you touch a single database file.

When to Call Microsoft Support
If you're seeing PSConfig failures that persist after re-running three times, if your farm's Central Administration won't load after an update, or if you're getting SQL schema errors during a database-attach upgrade from 2019 to Subscription Edition, stop and escalate. These scenarios can corrupt content databases if you keep attempting fixes without the right context. Open a support ticket at Microsoft Support and attach your PSCDiagnostics log and ULS logs from the affected time window. Microsoft Support Engineers can remote into your environment and use internal tooling that isn't available to the public.

Prevention & Best Practices for SharePoint Server Farms

The farms I've seen stay healthy year after year aren't the ones with the most expensive hardware. They're the ones with disciplined patching schedules and well-documented configurations. Here's what separates a well-run SharePoint Server environment from a chronic fire drill.

Patch on a schedule, not in a panic. Microsoft releases SharePoint Server Subscription Edition updates on Patch Tuesday, the second Tuesday of every month. Block time in your calendar the following week for a maintenance window. Monthly patching keeps your farm within one update of the latest security fixes, which means you're never scrambling to patch a critical CVE from six months ago while also trying to skip three intermediate builds.

Test in a staging farm first. I know, I know, not everyone has a separate staging farm. But even a single-server test environment running the same SharePoint version matters. Install the monthly update there, run the Config Wizard, smoke-test your critical site collections, and only then push to production. This catches breaking changes in monthly updates before your users do.

Document your farm topology and custom solutions. When you're troubleshooting at 2am during an outage, "I think we have three web front ends" is not good enough. Maintain a living document with your server names, roles, service account usernames (not passwords), installed solutions, and the current build number. Update it every time you patch. Keep it in a SharePoint document library, meta, yes, but extremely practical.

Monitor timer job execution proactively. Set up an alert on Event ID 6398 in Windows Event Log. A failed timer job is almost always the first sign of something deeper going wrong, a service account password about to expire, a SQL connection pool being exhausted, or a content database running out of space. Catching it at the timer job stage, before users experience symptoms, is a much easier fix.

Quick Wins

Frequently Asked Questions

What is SharePoint Server and how is it different from SharePoint Online?

SharePoint Server is an on-premises version of Microsoft's collaboration and content management platform, you install it on servers you own or control, typically in your datacenter or a private cloud. SharePoint Online, by contrast, is the cloud-hosted version included with Microsoft 365 subscriptions. With SharePoint Server, you control everything: patching, customization, hardware, and data residency. With SharePoint Online, Microsoft manages the infrastructure and releases updates continuously through the Microsoft 365 Roadmap. Most enterprises that run SharePoint Server do so because of data sovereignty requirements, deep customizations, or hybrid integration scenarios where on-premises data needs to connect with cloud services.

Which version of SharePoint Server should I install in 2026?

If you're starting fresh in 2026, install SharePoint Server Subscription Edition, full stop. It's Microsoft's current actively developed on-premises version with the longest supported lifecycle. SharePoint Server 2019 is still supported but is receiving security fixes only, not new features. SharePoint Server 2016 is in extended support, and 2013 has reached end of mainstream support. If you're already on 2019 or 2016 and need to stay on-premises, plan your upgrade to Subscription Edition sooner rather than later. The upgrade path from 2019 to Subscription Edition is well-documented and straightforward using the database-attach method.

Do I need to install SharePoint Server updates in order, or can I skip to the latest?

You can go straight to the latest cumulative update, no need to install every monthly update in sequence. SharePoint Server updates are fully cumulative, meaning each update package contains all previously released fixes. For SharePoint Server Subscription Edition, the March 2026 update (KB 5002843, build 16.0.19725.20076) includes every security fix and bug fix released before it. Just download and install the current update directly. For updates released before March 2023, remember you needed both the STS file and the WSSLOC language patch; from March 2023 onward, a single file is all you need.

The SharePoint Products Configuration Wizard keeps failing, what do I do?

First, check that the same update version is installed on every server in the farm before running the wizard on any of them, mixed patch levels are the number-one cause of Config Wizard failures. Second, open the PSCDiagnostics log at C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\LOGS\ and look at the last 30 lines for the actual exception text. Third, verify that no msiexec.exe processes are running in the background (kill them in Task Manager). Fourth, confirm your farm account still has dbcreator and securityadmin roles on SQL Server. If all of that checks out and it's still failing, run PSConfig via the command line with the full parameter string rather than the GUI, it gives you real-time output that makes the failure point obvious.

How do I find the current build version of my SharePoint Server farm?

Open the SharePoint Management Shell as Administrator and run (Get-SPFarm).BuildVersion. This returns the current build number, for example, 16.0.19725.20076 for the March 2026 Subscription Edition update. You can cross-reference that number against Microsoft's official update history table to confirm which monthly update you're running. To check the build on individual servers and see whether any need to run PSConfig, use Get-SPServer | Select-Object Name, NeedsUpgrade. Any server showing NeedsUpgrade : True needs the Configuration Wizard run on it immediately.

Can I upgrade directly from SharePoint Server 2016 to Subscription Edition?

Yes, but it requires an intermediate step. Microsoft's supported upgrade path goes: SharePoint 2016 → SharePoint 2019 → Subscription Edition. You cannot mount SharePoint 2016 content databases directly onto a Subscription Edition farm, the schema gap is too large and the mount will fail. You'll need to first attach the 2016 content databases to a SharePoint 2019 farm, run the upgrade there, verify the content, then detach from 2019 and mount onto Subscription Edition. It sounds like extra work, but the database-attach method is safe and reversible at each stage. Run the pre-upgrade checker (stsadm -o preupgradecheck) on the source farm before you begin, and address every warning it surfaces.

Related Microsoft Fix Guides

Microsoft Fix
How to Fix Windows Update Errors (Error 0x80070003 & More)
Microsoft Fix
Fix Microsoft 365 Sign-In Problems, Complete Guide
Microsoft Fix
Azure Active Directory Troubleshooting Guide
Browse All
5,000+ Microsoft Fix Guides →
H
Sai Kiran Pandrala
Our team includes certified Microsoft engineers, Azure architects, and system administrators with 10+ years of enterprise IT experience. Every guide is written from hands-on troubleshooting, not guesswork. We test every fix before publishing.