Legacy SharePoint recovery runbook

Capture before change

• Farm build, topology, server roles and patch state.
• Web applications, zones, alternate access mappings and managed paths.
• IIS bindings, pools, host headers and certificate thumbprints on every node.
• Managed accounts, Windows services, tasks, SQL logins and custom integrations.
• DNS, load balancer, proxy/WAF and health-check behaviour by network zone.
• ULS correlation IDs, IIS/event logs and exact failing URL/time.

Request-path order

1. DNS and network route.
2. Presented TLS certificate and chain.
3. Load balancer target and health.
4. IIS binding, pool and private-key permission.
5. SharePoint web application, zone and public URL.
6. Claims/identity provider.
7. Custom application and integration behaviour.

Change boundary

Make one causal change at a time and record before/after evidence. Rotate identities through supported managed-account procedures. Do not grant permanent local administrator rights or combine major patching, service rebuild and migration with incident recovery.

Persona and node matrix

Test each required URL from external, internal and admin locations using approved personas. Pin requests to each web front end. Verify TLS, sign-in, navigation, retrieval, representative custom functions and restart persistence. Mark restored, untested and deliberately retired capability separately.

Recovery exit

Authorised discovery users can retrieve required evidence consistently; dependencies and unresolved risks are mapped; the farm has a controlled operating mode; and components can be classified migrate, rebuild, retire, archive or temporarily rehost.