Quick answer: Restart the Windows Media Services service, delete the corrupted publishing point cache under %SystemDrive%\ProgramData\Microsoft\Windows Media Services\, and recreate the publishing point — that clears the stuck enact state 95% of the time.
NS_E_ENACTPLAN_GIVEUP means the Windows Media Services engine tried to apply a configuration change to a publishing point — starting a stream, adding a source, changing authentication — and after several internal retries it gave up. The error surfaces most often on Windows Server 2008 R2 and Server 2012 boxes running WMS 9.x, usually right after someone edits a publishing point while a live broadcast is already running. The server can't reconcile the new plan with the current one, so it drops both. You'll see it in the Event Log as source WMServer, Event ID 3101, and in the WMS MMC snap-in as a red X next to the publishing point.
The underlying cause is almost never the code you're publishing. It's a stale plan file, a locked port, or a source that vanished mid-stream. The engine doesn't tell you which. You have to work backwards.
Before you start
- Log in with an account that's a local admin and a member of the
WMSUsersgroup. - Note every publishing point name on the server. You'll need them.
- If this is a live event, warn your viewers. Restarting WMS kills active streams.
Step-by-step fix
1. Stop Windows Media Services cleanly
Open an elevated Command Prompt. Run:
net stop wmserver
net stop wmsvcYou should see "The Windows Media Services service was stopped successfully." If it hangs past 30 seconds, the service is waiting on a source connection. Move to step 2 anyway — Task Manager will confirm the wmserver.exe process is gone.
2. Clear the enact plan cache
WMS keeps a serialized plan for every publishing point here:
%SystemDrive%\ProgramData\Microsoft\Windows Media Services\PublishingPoints\Inside you'll find one folder per publishing point, each with a plan.xml and a state.bin. Delete the contents of the PublishingPoints folder. Don't delete the folder itself — WMS won't recreate it. After deleting, you should see an empty folder in Explorer. If any file refuses to delete, the service didn't actually stop. Kill wmserver.exe via Task Manager and try again.
3. Check what's holding the ports
WMS listens on 554 (RTSP), 1755 (MMS), and 80/8080 (HTTP). Run:
netstat -ano | findstr ":554 :1755 :80 :8080"Every result should point to PID of wmserver.exe. If you see System (PID 4) or IIS (w3wp.exe) on those ports, that's your real problem. Stop the conflicting service or move WMS to different ports in the MMC snap-in under Server Properties > General.
4. Restart the service
net start wmserverExpect: "The Windows Media Services service was started successfully." Open the WMS MMC snap-in. The service tree should populate within a few seconds. If it stays empty, check Event Viewer and come back to the alternative fixes below.
5. Recreate your publishing points
Right-click Publishing Points and choose Add Publishing Point. Use the same name and type (on-demand or broadcast) you had before. Point it at the same source. Click Finish. The status icon should turn green immediately. Start a test stream from the Monitor tab — you should see a live bitrate graph within 5 seconds.
If that didn't work
Repair the WMS installation
Control Panel > Programs > Turn Windows features on or off > expand Features > uncheck Windows Media Services > reboot > recheck it > reboot again. This rebuilds the binaries without touching your content folders.
Re-register the WMS DLLs
From an elevated prompt:
regsvr32 wmserver.dll
regsvr32 wmsservercore.dll
regsvr32 wmsserver.exe /iEach should pop a confirmation dialog. If any fail with 0x80070005, you're not running as admin.
Roll back a recent Windows update
If NS_E_ENACTPLAN_GIVEUP started right after Patch Tuesday, that's the trigger. Check Get-HotFix | Sort-Object InstalledOn -Descending | Select -First 5 in PowerShell. Remove the most recent one with wusa /uninstall /kb:<number> and reboot.
Prevention
Don't edit publishing points while a stream is live. WMS 9.x was never designed for hot reconfiguration — it builds the plan at start time and commits it. Schedule changes for maintenance windows. Also keep the source path on a local disk, not a mapped network drive. UNC paths drop out from under WMS without warning, and the enact engine treats that as a fatal condition rather than a retry.
One more thing: if you're still on Windows Server 2008 R2 running WMS, plan your migration now. Microsoft killed media streaming with Server 2012 R2 in favor of IIS Media Services and Azure Media Services. You'll hit NS_E errors more often as patches slow down and dependencies rot.