NS_E_INVALID_PUSH_PUBLISHING_POINT (0XC00D151B) Fix

1. Mismatched or Missing Publishing Point Name

This is the one I see most often. You're trying to push a stream to a publishing point that doesn't exist on the destination server, or the name doesn't match exactly. Windows Media Services is picky about case and spelling here.

Check the push source URL. It should look like this:

http://destination-server:4223/publishing-point-name

That :4223 port is the default for Windows Media Services HTTP push. If you're using HTTPS, it's :443, but that's less common in this context.

Make sure the publishing point on the destination server is set to Push (not Pull) and is already created. If you create it after starting the push, you'll get this error. Create it first, then start the source stream.

Quick test: open a browser on the source server and hit http://destination-server:4223/publishing-point-name. If you get a 404 or 400, the point doesn't exist or is misnamed. If you get a blank page or XML response, it's alive.

2. Authentication Credentials Are Wrong or Missing

Windows Media Services push publishing points require authentication by default. If you're running the source service under a local system account or a domain account that doesn't have permissions on the destination server, you'll hit this error.

Fix it by opening the Windows Media Services console on the destination server. Right-click your publishing point, go to Properties, then the Authorization tab. Make sure WMS HTTP Authorization is enabled and configured to allow the source server's account.

If both servers are on the same domain, use a domain account that's a member of the WMS Anonymous User group or the local Administrators group on the destination server. If they're not on a domain, switch to Anonymous authentication on the destination publishing point. That's under the same Authorization tab—just enable the anonymous option and disable the others. This is less secure but works for internal lab environments.

One more thing: on the source server, go to the push publishing point's properties, Source tab. Under Connection credentials, specify the same authenticated account. Don't leave it blank or as local system.

3. Firewall or Port Blocking the Push Connection

Even if the publishing point and authentication are correct, a firewall (local or network) can silently kill the push. Windows Media Services uses TCP port 4223 for HTTP push by default. If that's blocked, you get 0XC00D151B.

Run this on the destination server to open the port in Windows Firewall:

netsh advfirewall firewall add rule name="WMS Push HTTP" dir=in protocol=tcp localport=4223 action=allow

If you're using a third-party firewall, you'll need to add that rule manually. Also check if the source server can reach the destination server's IP and port using telnet or Test-NetConnection:

Test-NetConnection destination-server -Port 4223

If the connection fails, the problem is between the servers—not in your publishing point config.

I've seen cases where the push worked fine for months then broke after a Windows Update changed the firewall profile from Private to Public. Double-check your firewall profile status on both servers.

Quick-Reference Summary Table

That covers the three main reasons you're seeing 0XC00D151B. Start with the publishing point name—it's the fastest check and the most common culprit. If that's fine, move to authentication, then firewall. You'll likely have it fixed within ten minutes.