Fix NS_E_INCOMPATIBLE_SERVER (0XC00D2EE8) Streaming Error

Before You Start

I've seen this error hundreds of times in enterprise environments — Windows Media Player trying to stream from a server that isn't running Windows Media Services (WMS) or IIS with the right modules. The error message is dead-on: the server isn't a compatible streaming media server. Let's fix it.

This error almost always shows up when you're trying to open an mms:// or rtsp:// URL in Windows Media Player, and the server either doesn't have WMS installed or the firewall's blocking the right ports. Quick check: if you're on Windows 10 or 11, WMS isn't installed by default — you need Server OS for that.

Three levels of fix below. Start with step one, test, then move down if it's not working.

Simple Fix (30 seconds) — Check the Server Type

Before you dig into server config, verify the server you're connecting to actually runs WMS. I can't count the number of tickets where someone pointed Media Player at a generic IIS server or a Linux box running Apache — that won't work natively.

1. Ask the server admin or check the server OS. If it's Windows Server 2008/2012/2016/2019/2022, WMS might be installed as a role. If it's Linux, macOS, or a cloud storage URL, you're out of luck with native Media Player streaming.
2. Test with a known-good stream. Open Media Player, press Ctrl+U, and try this Microsoft test stream: mms://wm.microsoft.com/encoder/1.0.4. If that works but your internal URL doesn't, the issue is on your server, not the client.
3. If the server is a Windows desktop (Windows 10/11), WMS is not available. Full stop. You need a Server OS or a third-party streaming solution like Wowza or VLC's streaming feature.

If the test stream fails, skip to the moderate fix — it might be a client-side codec or network issue.

Moderate Fix (5 minutes) — Firewall and Port Check

If the server is running WMS but the error persists, the culprit is almost always a firewall blocking the streaming port. WMS uses port 1755 for MMS traffic by default, though it can use others.

On the Server

1. Open Windows Firewall with Advanced Security on the server.
2. Check for an inbound rule allowing TCP/UDP port 1755. If it's missing, create it:

   Open 'Inbound Rules' → New Rule → Port → TCP and UDP → Specific local ports: 1755 → Allow the connection → Apply to Domain, Private, Public → Name: WMS Streaming (1755)

3. If using a third-party firewall (like Cisco ASA or pfSense), confirm the rule is there and not being overridden by a deny-all rule.

On the Client

1. Check Windows Firewall on the client — ensure 'Windows Media Player Network Sharing Service' is allowed through. This is a common oversight.
2. Test using telnet from the client: telnet <server_ip> 1755. If it hangs or fails, the port is blocked somewhere. If it connects but the screen goes blank, the port is open — that's normal for telnet on a streaming port.

I've also seen this error when DNS is resolving to the wrong server. Run nslookup <stream_url_hostname> from the client to confirm you're hitting the right IP.

Advanced Fix (15+ minutes) — WMS Configuration and IIS Interop

If ports are open and the server has WMS installed, it's time to dig into the service itself. This is where I see two specific failures: the publishing point is misconfigured, or IIS is stealing the port.

Step 1: Verify WMS is Running

On the server, open Services.msc. Look for 'Windows Media Services'. It should be running. If it's stopped, start it and set it to Automatic. If it fails to start, check the event log for error IDs — often it's a dependency service (like Windows Media Network Sharing) that's missing.

Step 2: Check Publishing Points

1. Open the Windows Media Services management console (or use wmsmgr.msc).
2. Expand the server, click 'Publishing Points'.
3. Find the publishing point that matches your URL. For example, if you're hitting mms://server/myvideo.wmv, there should be a publishing point named myvideo or a default one like <default>.
4. Right-click it → Properties → Source tab. Ensure the source type is correct: 'Playlist' or 'Media files', and the path to the media file exists and is accessible by the Network Service account.
5. Test the publishing point: in the management console, right-click it → 'Allow New Connections' (if it's stopped), then try 'Test Stream'. If that fails, fix the source path.

Step 3: Port Conflict with IIS

This one's sneaky. If IIS is running on the same server and is configured to stream media via HTTP on port 80, it can conflict with WMS if WMS is also set to use HTTP streaming on port 80. Separate the ports:

1. In WMS management console, right-click the server → Properties → 'Control Protocol' tab.
2. Uncheck 'HTTP' if you don't need it, or change the HTTP port to something else (like 8080).
3. Restart WMS: net stop wmserver && net start wmserver.

Step 4: Reinstall WMS Role (Nuclear Option)

If nothing else works, remove and re-add the Streaming Media Services role via Server Manager. This clears up any corrupted config files. After reinstall, reconfigure your publishing points from scratch. Don't restore from backup — that just reintroduces the same bad config.

Pro tip: In 2024, I'd strongly consider moving away from WMS for new deployments. It's deprecated in Windows Server 2022 and has known security issues. Use a modern streaming solution like Wowza, Nimble Streamer, or even a cloud CDN. But for existing systems, these fixes will get you back online.

Still Not Working?

If you've gone through all three steps and the error persists, collect the following and open a case with Microsoft Support (or your vendor):

• Full error text (not just the code)
• WMS event logs from the server
• Network trace from the client (use netsh trace or Wireshark) showing the failed connection
• Windows Media Player version and OS build of the client

That's it. You've got the fixes that have worked for me in hundreds of Enterprise deployments. Go fix it.