An HTTP 503 from SharePoint Central Administration means IIS could not serve that request. A stopped application pool or invalid service-account credentials are common causes, but they are not the only causes. Check the failing server, pool state and event logs before changing any identity.
This is for SharePoint Server, not the SharePoint admin centre in Microsoft 365.
1. Establish the blast radius
Check:
- Central Administration on each SharePoint server that hosts it
- a normal SharePoint web application
- IIS Manager on the affected server
- Windows System and Application event logs
- recent password, policy, certificate, patch or account-lockout changes
If only one server fails, compare it with a healthy node. If Central Administration and content web applications fail together, the incident is wider than one site.
Record timestamps, HTTP substatus where available, event IDs and ULS correlation information before recycling anything.
2. Inspect the application pool
In IIS Manager, identify the application pool used by Central Administration. Check whether it is stopped.
Start it once and immediately retest. If it stops again, do not keep restarting it. Read the related Windows Process Activation Service, IIS and security events. A repeated rapid-fail event is evidence of an underlying failure, not a request for more recycling.
Also verify that the server has disk space and that dependent SharePoint and Windows services are in their expected state.
3. Check the account without exposing it
Microsoft's SharePoint Server account planning guidance separates farm, application-pool and service identities. It also explains that SharePoint services do not generally support Active Directory managed service accounts or group managed service accounts, although SQL Server has different support.
Check whether the application-pool identity is:
- locked or disabled
- expired
- denied logon by policy
- using a password that changed outside SharePoint's managed-account process
- missing required local rights because of a policy change
Do not paste the password into scripts, logs or a ticket.
4. Update credentials through SharePoint
If the cause is a changed managed-account password, use SharePoint's supported managed-account controls or SharePoint Management Shell procedure for your server version. Do not fix only the IIS application-pool identity and leave SharePoint's stored credentials disagreeing with it.
Plan the change because one managed account may run more than Central Administration. Identify every dependent service and application pool first.
If you cannot open Central Administration, use the documented PowerShell route for the installed SharePoint version from an elevated SharePoint Management Shell.
5. Treat an account redesign as a separate change
Using one identity for unrelated farm services increases the impact of a lockout or password error. Microsoft documents distinct administrative and service-account purposes.
However, an outage is the wrong moment to improvise a farm-wide identity redesign. Restore the supported configuration, prove service, then plan account separation with backups, change control and rollback.
6. When credentials are not the cause
Continue with evidence:
- IIS binding or certificate failure
- failed patch or configuration-wizard state
- missing file or assembly
- application-pool rapid-fail protection
- resource exhaustion
- server policy or endpoint-security changes
- database or network connectivity errors
Use the event details and ULS logs to narrow the next step. A generic 503 page alone cannot distinguish these causes.
Prove recovery
After the repair:
- open Central Administration from the intended admin network
- test a representative content web application
- confirm the pool remains started after repeated requests
- check that related Windows and ULS errors have stopped
- test scheduled tasks or services using the same managed account
- monitor through at least the next relevant service cycle
One successful page load proves that one request completed. It does not prove the account is healthy across every dependent service.
Sources
- Plan for administrative and service accounts in SharePoint Server
- Initial deployment administrative and service accounts
- SharePoint Server PowerShell overview
For practical SharePoint Server diagnostics and operating patterns, join the SharePoint & Teams Admins Space.