The SharePoint farm came back, but the portal did not

The niche situation

A composite government-project portal runs on an older SharePoint farm that has been treated as “legacy but stable.” After a weekend certificate replacement, external users see a browser warning, internal users receive repeated credentials prompts, and the load balancer marks one web front end healthy and the other unhealthy. The certificate was replaced in one IIS site, but nobody can confirm where the private key came from or which service account may read it.

Central Administration working is misleading. It proves that some farm services, SQL connectivity and local authentication are alive. The public alternate access mapping, IIS binding, TLS chain, reverse proxy, claims provider and custom application path remain outside that result.

The business wants a rapid migration to SharePoint Online. That may be strategically correct, but it will not recover the records and behaviour needed to define the replacement. The immediate task is controlled read recovery so records, dependencies and behaviour can inform the transition.

Freeze the evidence surface

Before changing bindings or service accounts, capture the current state from every node: server roles, farm build, patch level, web applications, alternate access mappings, managed accounts, service applications, IIS sites and pools, certificate thumbprints, SNI/host headers, Windows event logs, ULS correlation IDs and load-balancer health checks.

Export configuration where supported and take infrastructure snapshots only through the organisation’s approved recovery process. Do not clone a production SharePoint VM and start it on the same network; duplicated machine identities, search components and timer services can cause a second incident.

Record time synchronisation, DNS results and the exact URL tested from each network zone. An endpoint test must follow the client path through its DNS answer, proxy or WAF and selected web front end.

Walk the request path in order

Start outside and move inward. Resolve the public and internal DNS names. Confirm the load balancer’s target, port, host header and health path. Inspect the TLS certificate presented to the client. MMC shows the local store and may not identify the certificate selected by the live binding or proxy. Verify subject alternative names, expiry, chain and whether each web front end presents the same certificate.

At IIS, compare bindings across nodes. Confirm that the application pool is started, its identity is valid and it can read the certificate private key when TLS termination occurs on the server. Then check the SharePoint web application, zone and public URL. A binding repaired to the wrong zone can create authentication loops even though the site responds.

Only after transport and routing are consistent should you trace claims authentication, People Picker, custom providers and application code. Use the request's correlation ID and UTC window to query the relevant ULS events.

Recover service identities without over-privileging them

List each managed account and match it to Windows services, application pools, scheduled tasks, SQL logins and custom integrations. A password reset may restore one pool while breaking another system that used the same undocumented account. That is why the dependency map precedes rotation.

Where credentials must be rotated, coordinate the change through SharePoint’s supported managed-account process and every non-SharePoint dependency. Grant certificate private-key read permission only to the identity terminating TLS. Do not add farm accounts to local Administrators as a permanent cure; doing so masks the missing right and materially expands compromise impact.

If an identity cannot be safely recovered, create a replacement through a documented change, update one dependency at a time and preserve the old mapping in the evidence record.

Stabilise only as long as required for evidence

The target state for a risky legacy farm may be controlled read-only access. Disable new transactions if their integrity cannot be guaranteed. Preserve authenticated access for authorised discovery staff, export critical lists and documents with metadata, and capture custom forms, workflows, timer jobs and integration behaviour.

Fix only what is necessary to establish a reliable evidence window. Large patch jumps, service-application rebuilds and content-database upgrades during discovery combine recovery and modernisation risk. If the farm must be patched for a known security exposure, treat that as a separate gated change with backup and rollback evidence.

Recovery requires authorised users to retrieve the required evidence consistently and the team to map enough dependencies for replacement design.

Verification matrix

Test each required URL from external, internal and administrative network positions using named personas. Verify TLS, authentication, navigation, document retrieval, search where required, custom forms and representative integrations. Repeat against each web front end by controlled routing and record the result per node.

Correlate the browser result with load-balancer logs, IIS logs, ULS and SQL access. Record what is deliberately unavailable. A truthful recovery report distinguishes restored capability, untested capability and capability that will remain retired.

Run an approved restart test only after configuration is documented. Recovery acceptance includes a planned reboot and repeated client-path test.

Turn the recovery into replacement evidence

The recovered farm now supplies a real service blueprint: user groups, transactions, records, integrations, exception paths and operational constraints. Classify each component as migrate, rebuild, retire, archive or temporarily rehost. Use representative content and the hardest custom behaviour for proof-of-capability spikes.

This is how legacy repair avoids becoming nostalgia. The old system is restored only far enough to make the next architecture honest. Platform selection—SharePoint Online, Power Platform, Power Pages, custom Azure or hybrid—then follows the verified requirements and proof results.

What not to do during farm recovery

Do not start with an in-place version upgrade, attach production content databases to an improvised farm, or restore virtual machines into the live network without checking identity and topology collisions. Do not replace every certificate and password at once: that removes the ability to connect a changed dependency to the observed result.

Central Administration, IIS Manager and SQL Management Studio each show only one layer. A green console indicator covers that component at that capture time. Repeat the business request through DNS, TLS, IIS, SharePoint and the dependency path. Avoid deleting alternate access mappings or authentication providers because they look obsolete until traffic, logs and business owners establish their purpose.

Finally, do not let “temporary legacy recovery” become an unowned permanent service. Record the allowed operating window, monitoring, accountable owner and explicit transition decision.