NS_E_TCP_DISABLED 0xC00D00D2 Fix for WMS

Picture this: you're running Windows Media Services on a Server 2008 R2 box (or someone's still leaning on it in a lab), trying to publish a live stream, and the client gets nothing. Event Viewer spits out NS_E_TCP_DISABLED (0xC00D00D2). Or you're mucking with the WMS admin console, you click "Enable" on a new publishing point, and the MMC snap-in throws this error at you before anything even starts. Either way, the message is blunt: the TCP protocol on that server isn't turned on, so WMS has no transport to hand the stream to.

I've seen this pop up most often after someone restores a server from backup, or after a Windows update resets protocol bindings. Last month a small insurance office had their training video server go dark overnight. Same error. A GPO push had uninstalled a leftover WMS component and killed the TCP protocol registration.

What 0xC00D00D2 Actually Means

Windows Media Services can push streams over UDP, TCP, or HTTP. UDP is fast and lossy, great for LANs. TCP is the reliable one and the one most clients fall back to when UDP gets blocked by a firewall or NAT. NS_E_TCP_DISABLED literally means "the TCP protocol object in the server config is disabled or not registered." No TCP, no fallback, no stream.

Two things can cause it:

The TCP protocol was never enabled on the publishing point or the server itself.
Something disabled it — a script, a GPO, an update, or a botched restore — and WMS still tries to negotiate with it.

This isn't a firewall problem. It's not a port problem. It's the protocol toggle inside WMS, and until you flip it, nothing else matters.

The Fix — Step by Step

Open the Windows Media Services console. On the server, hit Start, run wmssnap.msc if the snap-in isn't already in your admin tools. If it errors out, the WMS role itself is broken and you'll need to reinstall it via Server Manager before anything else.
Find the publishing point. Expand the server node, then Publishing Points. Pick the one throwing the error. If you don't know which one, the event log entry usually names it in the source field.
Check the protocol list. Right-click the publishing point and hit Properties. Go to the General tab. You'll see the enabled protocols listed. If TCP isn't there, that's your smoking gun.
Enable WMS TCP at the server level first. Some setups require the protocol registered globally. Right-click the server node (top of the tree), Properties, then the Protocols tab. Check WMS TCP and click Apply. This is the step most walkthroughs skip and it's why people keep hitting 0xC00D00D2 after "fixing" the publishing point.
Enable it on the publishing point. Back at the publishing point properties, under General, click Add next to protocols. Select WMS TCP. Accept the default port (usually 1755, though HTTP fallback on 80 or 8080 is worth adding too).
Restart the service. Open an elevated command prompt and run:

net stop wmserver && net start wmserver

Don't just restart from the services GUI — the WMS service sometimes holds the old protocol table in memory and won't pick up the change cleanly. The command line stop/start forces a full reload.

If That Didn't Do It

Sometimes the toggle is already on and the error persists. That usually means the TCP protocol registration itself is corrupted. Here's what I check next:

Registry check. Crack open regedit and look at HKLM\SOFTWARE\Microsoft\Windows Media\Server\Protocols\WMS TCP. If the key is missing or the Enabled DWORD is 0, set it to 1 and restart the service.
Firewall on the server. Even with TCP enabled, if Windows Firewall is blocking inbound 1755 or 80, you'll get the same symptom on the client side. Add an inbound rule for wmserver.exe rather than the port — the service likes to switch ports when HTTP fallback kicks in.
Reinstall the WMS role. If registry keys are missing wholesale, the role install is hosed. Server Manager → Remove Roles → reboot → add the Streaming Media Services role back. Yes, it's heavy-handed. It's also faster than chasing a corrupted protocol table through five different logs.
Check for a GPO. Run gpresult /h gpo.html and search for anything referencing media services or firewall. I've twice caught a domain policy that disabled WMS TCP after hours, because some security baseline template treats it as a legacy risk.

Once TCP is enabled and the service restarts clean, clients should negotiate without complaint. Test with a unicast pull from a known-good client before you tell anyone it's fixed — the WMS admin console will happily let you configure a protocol the network still blocks.

And if you're supporting this in 2024, seriously look at migrating to IIS Smooth Streaming or a modern CDN. WMS is EOL and you're only going to keep patching a wound that won't close.