NS_E_SERVER_ACCESSDENIED (0XC00D2EFB) Fix for Windows Media Server

1. Authentication settings are blocking you

I know this error is infuriating. It pops up when you try to stream from a Windows Media server on Windows Server 2008 R2 or 2012 R2, and it just says "access denied." The most common reason? The server's authentication method doesn't match what your client is sending.

Windows Media Services (WMS) uses either anonymous access or Windows Integrated authentication. If you're connecting from a Windows 10/11 machine with a domain account, but the server expects anonymous, you get this error. Or the reverse—you try anonymous when the server demands credentials.

Here's the fix:

1. Open the Windows Media Services console on the server (Start > Administrative Tools > Windows Media Services).
2. Right-click your publishing point (e.g., Sample_Broadcast) and choose Properties.
3. Go to the Authorization tab.
4. You'll see two options: WMS NTFS ACL Authorization and WMS IP Authorization. The first one controls who can connect based on their user account.
5. If it's enabled, you need to add the user or group. Click Edit, then Add. Type the domain\username or use Everyone for testing (but don't leave that in production).
6. Also check the Properties tab of the publishing point, under Authentication. Set it to either Anonymous (if you want no login) or Integrated Windows authentication.

Real-world trigger: I've seen this happen when a sysadmin migrates from Windows Server 2003 to 2008 R2 and forgets to re-enable anonymous access. The new server defaults to Integrated, but the clients (like old Windows Media Player 11) try anonymous and get kicked.

2. Firewall blocking the streaming port

If authentication looks good, next suspect is the firewall. Windows Media Services uses port 1755 by default for RTSP, but it can also use 554. If the firewall on the server or a network firewall is closed, the server sees the connection attempt but can't respond properly, so it throws the access denied error.

How to check:

1. On the server, open Windows Firewall with Advanced Security.
2. Look for inbound rules related to Windows Media Services. If they're disabled, enable them.
3. If missing, create a new inbound rule for port 1755 (TCP and UDP) and port 554 if you use RTSP.
4. Don't forget the WMS HTTP Streaming port (usually 8080) if you're using HTTP. That's a separate rule.

Real-world trigger: One client ran a third-party antivirus that killed the Windows Media Services firewall rules during an update. The service was running, but no traffic could reach it. Re-adding the rules fixed it instantly.

3. IP address restrictions are blocking you

This one sneaks up on people. The WMS IP Authorization plugin can limit access to specific IP ranges. If your client's IP isn't in the allowed list, you get the access denied error—even with correct authentication.

Fix it here:

1. In the same Authorization tab mentioned earlier, look for WMS IP Authorization.
2. Click Properties. You'll see a list of allowed and denied IP addresses.
3. If your client's IP is in the Denied list, remove it. If it's not in the Allowed list, add it.
4. You can use ranges like 192.168.1.0/24 or single IPs.

Pro tip: I almost always disable IP authorization entirely during troubleshooting. If the error goes away, you know it's an IP restriction. Then you can narrow it down. Just right-click the plugin and choose Disable.

Quick reference table

If none of these work, check the Windows Media Services logs at %WINDIR%\System32\LogFiles\WMS. They'll tell you exactly why the connection was rejected. The error code 0XC00D2EFB is a catch-all for "no," but the logs get specific.