Content Director won't connect
The server side of Edit failures: the WCF services Content Director calls, the Windows feature whose absence turns them into 404.3, the browser-address subtlety that breaks workstations, and which event log holds the truth.
At the end of this guide, Content Director's calls home reach the server again — because you've checked the three server-side failure points in order: the service endpoints, the Windows feature behind them, and the address the browser handed out.
Scope first: this is the server half. If the browser itself complains — "Content Director is not running, is not installed…" — that's the workstation half, covered in Edit documents in place with Content Director. This page is for when Content Director launches, then its tray reports "Error communicating with Content Central" ("Please restart Content Director if problems persist.") — meaning it's alive but can't reach the server's services.
1. Test the endpoints directly
Content Director talks to WCF services under the site. From a workstation's browser:
https://docs.example.com/ContentCentral/Services/2010/01/01/CCWebService.svcWhat you should see: a WCF service information page. What you might see instead:
| Response | Meaning |
|---|---|
| HTTP 404.3 ("the appropriate handler is not installed…") | IIS doesn't know .svc — cause #2 below |
| Connection/name errors | The address itself doesn't reach the server — cause #3 |
| The service page | Server side is fine; the problem is the workstation half |
2. The missing Windows feature (fresh-server classic)
A 404.3 on .svc means WCF HTTP Activation isn't enabled. The installer normally configures it, but the step can fail quietly — a server that seems fully installed except for Content Director editing is this exact signature. Enable, in Windows Features / Server Manager:
- WCF Services > HTTP Activation (under .NET Framework 4.x features)
- With ASP.NET 4.x under IIS's application-development features
Or from an elevated prompt:
dism /Online /Enable-Feature /All /FeatureName:WCF-HTTP-Activation45Then retest step 1 — the service page appearing is the fix confirmed.
3. The address subtlety that breaks workstations
Content Director doesn't have its own server setting — it builds its service URLs from the address in the user's browser. Whatever host and port the user browsed to is where Content Director will call.
The consequence: a Content Central address that only resolves on the server (a local hostname, an internal-only binding) produces workstations where the website works — via some other path — but every Edit fails. The site's public address must reach the server from the workstations, as itself. If step 1's test fails from workstations but succeeds on the server, this is your cause: fix DNS/bindings so one address works everywhere.
Where the evidence lives
Both halves log to the same custom log — Event Viewer > Applications and Services Logs > ContentCentral — under different sources: AdmCCContentDirector on the workstation (what Content Director experienced), AdmCCWebsite on the server (what the site saw, including the full exception behind any 500). A 404.3 leaves nothing server-side — IIS rejected the request before Content Central ran — which is itself diagnostic: workstation errors plus a silent server log points at steps 1–2.
Success check: the .svc test page loads from a workstation, and an Edit on a test document runs the full round trip — checked out, opened, checked in — with a new major version to show for it.