NS_E_WRONG_PUBLISHING_POINT_TYPE (0XC00D1452) Fix

You're staring at NS_E_WRONG_PUBLISHING_POINT_TYPE (0XC00D1452) and your streaming media server just died. I get it—this one's annoying because it doesn't tell you what's actually wrong. Let's fix it.

The Quick Fix

Open Windows Media Services (WMS) Manager. Go to your server, expand it, and look at the Publishing Points section. Find the broken point—it'll likely show as cache or proxy type, but the error says that type doesn't support the property you're calling. The real fix is to delete that publishing point and recreate it as a broadcast or on-demand type.

1. Right-click the broken publishing point → Delete.
2. Right-click Publishing Points → Add Publishing Point.
3. Choose Broadcast or On-Demand (not Cache or Proxy).
4. Follow the wizard, point it to your source file or stream.
5. Start the point and test.

I had a client last month whose entire corporate training video system went down because someone migrated a cache point from an old server and the registry got corrupted. Deleting and recreating took ten minutes. They'd been fighting it for two days.

Why This Works

The error code 0XC00D1452 maps to NS_E_WRONG_PUBLISHING_POINT_TYPE. It fires when your code—or WMS Manager—tries to call a method or property that only works on broadcast or on-demand points, but the point was created as cache or proxy. Those types are read-only after creation; they don't support things like setting a source URL or changing the stream format dynamically. Deleting and recreating clears the internal state and lets you pick the right type.

WMS stores publishing point configuration in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media\WMServer\PublishingPoints. If that key gets corrupted—like from a bad server migration or a failed update—you'll see this error even if the point looks fine in the GUI. Recreating rebuilds that registry entry properly.

Less Common Variations

Script or API calls failing

If you're using PowerShell, C#, or a web service to manage WMS, you might hit this error when calling Start or SetProperty on a cache point. The fix is the same: check your script—it's probably referencing the wrong point object. I've seen people grab the first point in the collection thinking it's a broadcast, but it's actually a cache point from a default install. Add a test in your code:

$point = Get-WMSPublishingPoint -Name "YourPoint"
if ($point.Type -ne "Broadcast") {
    Write-Host "Wrong type — recreate as broadcast"
}

Cache-to-proxy migration gone wrong

Windows Media Services used to support cache and proxy points for load balancing streams. Microsoft deprecated those in later versions (Server 2012 R2 and beyond). If you're running a modern server and importing an old config, the migration tool might create a cache point that doesn't work with new APIs. You'll see 0XC00D1452. Delete the imported point and create a fresh broadcast point.

Third-party software conflict

Some IPTV or video surveillance software expects a broadcast point but creates a proxy point during install. I dealt with a security camera system that threw this error every reboot. The vendor's installer was buggy—it set the wrong point type. After I deleted and recreated it manually, the cameras worked fine. Check your software's logs to see what point it's trying to access.

Prevention

Don't migrate publishing points between servers using export/import tools. They carry over bad registry data. Instead, note your settings and recreate from scratch on the new server.

If you're automating with scripts, always validate the point type before calling methods on it. A simple check like if ($point.Type -ne "Broadcast") { throw } will catch this error before it hits your users.

Also, keep WMS Manager updated. The version that ships with Server 2008 R2 had a bug where the GUI would show a point as on-demand but the registry said cache. Server 2012 and later fixed that, but you still need to watch for manual edits.

Bottom line: this error is always a type mismatch. Recreate the point and move on. Don't waste time digging through logs—I've been there, and the fix is always the same.