The Content Central login page won't open

Match what your browser shows — server not found, connection refused, an HTTP error, or failing links — to the fix, and know exactly what to send support if you're still stuck.

AdministratorsContent Central 7.x15-30 minutesVerified 2026-08-30

Before you begin

The Content Central address your organization uses (usually `http(s)://<server>/ContentCentral`)
Administrator access to the Content Central server for the IIS and event-log checks

By the end of this guide you'll know which layer is failing — name lookup, network, IIS, or the address itself — and either have the login page back or have a compact evidence packet ready for support.

Match your symptom first

What the browser shows tells you where the problem is. Find your row, then jump to that section.

What you see	Where the problem is	Section
"Server not found" / "site can't be reached"	The name doesn't resolve (DNS)	1
Connection refused or timed out	Network, firewall, or IIS is stopped	2
An HTTP error page (500, 503, etc.)	IIS reached, but the application failed	3
Login page loads, but sign-in fails	Credentials/session — different guide	4
You can sign in, but emailed/exported links fail	Two different addresses in use	5

Note

The address is usually http(s)://<server>/ContentCentral, but the folder name can differ per install. Confirm the exact address a working user has bookmarked before changing anything.

1. "Server not found" — the name doesn't resolve

The browser never reached the server. This is common after a server move: the old hostname no longer points anywhere.

1
On the affected workstation, open a Command Prompt and look up the server name from your Content Central address:
```
nslookup yourserver
```
What you should see: an IP address. Non-existent domain (NXDOMAIN) means DNS has no record for that name — Content Central itself was never involved.

If the lookup fails, ask whoever manages DNS to point the name at the current server, or confirm the correct current address with your IT team.

Important

Changing a workstation's IP address never changes the server address. If the page stopped loading after a network change, the server name or the server's own address changed — start with DNS, not the browser.

2. Connection refused or timed out

The name resolved, but nothing answered. Check the path from workstation to web server.

1
From the workstation, test the port (use 443 if your address starts with https://):
```
Test-NetConnection yourserver -Port 80
```
What you should see: TcpTestSucceeded : True. False means a firewall is blocking the port or nothing is listening.

If the test fails, sign in to the Content Central server and check that World Wide Web Publishing Service is Running in services.msc. Start it if stopped.

Still failing? Ask IT to check firewalls between the workstation and server for the web port. A page that works on the server itself but not from workstations is almost always a firewall.

3. An HTTP error page appears

IIS answered but the application couldn't. Do these checks on the Content Central server.

Open IIS Manager > Application Pools and confirm ContentCentralApplicationPool shows Started. Start it if stopped, then reload the page.

Open Event Viewer > Applications and Services Logs > ContentCentral and read the newest errors from source AdmCCWebsite. The message here is almost always more specific than the browser page.

Figure

Event Viewer showing the ContentCentral log with an AdmCCWebsite error selected

If the server was recently moved or restored: a frequent cause is the IIS worker process being unable to write its ASP.NET temporary compilation folder on the new machine. Have IT confirm the app pool identity (NETWORK SERVICE by default) can write to the Temporary ASP.NET Files folder for .NET Framework 4.x, then stop the app pool, clear that folder's contents (it's a rebuildable compile cache, not data), and start the pool again.

If the error started right after an upgrade: Content Central deliberately refuses to start when the database version doesn't match the installed program version. Don't work around it — contact support with the event-log message.

What you should see when it's fixed: the login page with Username, Password, and Domain fields and a Login button. That's your success check for sections 1–3.

That's not a "page won't open" problem — the web application is healthy. Credentials, domain selection, and sessions are covered in How signing in works.

5. Signed in, but links Content Central sent you fail

A user is signed in and working, but a link from a notification email or an exported form is denied or asks them to sign in again.

Sign-in is tracked by a browser cookie tied to the exact host name in the address bar. Someone signed in at http://192.168.1.10/ContentCentral has no session at http://yourserver/ContentCentral — the browser treats them as two different sites, even though they're the same server.

Pick one canonical address — the proper name, not an IP — and have everyone bookmark and use only that.

In Admin > System Settings, under Notification Settings, check Override server URL in outgoing notifications and set Server URL to that canonical address (e.g. http://yourserver/ContentCentral/).

In the same settings, under Workflow Settings, set Server URL for workflow to the same address — this is the one used for exported capture forms and document sharing.

Warning

Don't "fix" this by telling users to browse by IP address. That multiplies the number of addresses in use and the number of broken links. One address everywhere is the fix.

Still stuck?

The exact address you're browsing to, copied from the address bar
Which symptom row from the table above matches, and a screenshot of what the browser shows
Output of nslookup yourserver and Test-NetConnection yourserver -Port 80 (or 443) from an affected workstation
Whether ContentCentralApplicationPool shows Started in IIS Manager
The newest error text from Event Viewer > ContentCentral log, source AdmCCWebsite
Whether the server was recently moved, restored, or upgraded — and when the page last worked

Send that packet to support and they can usually pinpoint the layer on the first reply.