0XC00D1455: Fix NS_E_INVALID_PUBLISHING_POINT_NAME Fast

You try to start a publishing point on Windows Media Services and it throws 0XC00D1455 — NS_E_INVALID_PUBLISHING_POINT_NAME — with the flat message that the name is invalid. Windows isn't lying. One of the characters or the structure of the name is off. It's almost never a permissions or a service crash. It's the name.

I've hit this on Server 2008 R2 boxes running WMS 9.5, usually right after someone pasted a name from a ticket or a URL bar. What's actually happening is that WMS parses the publishing point name against a strict grammar, and if a single character breaks it, the API returns 0xC00D1455 before anything else gets validated.

Cause 1: Reserved characters snuck into the publishing point name

This is the big one. WMS publishing point names don't allow the same set of characters a file path does. Things you'd consider normal — a space, a slash, a backslash, a question mark, a colon — will trip the validator. The classic real-world trigger: an admin copies a folder path like C:\WMS\Live Stream and pastes Live Stream into the publishing point name field. The space alone is enough. Another common one is naming a point Channel 1 or News:East.

Here's the rule set WMS enforces. Allowed characters in a publishing point name:

• Letters A–Z and a–z
• Digits 0–9
• Hyphen -
• Underscore _
• Dot . (but not leading or trailing, and not two in a row)

Everything else is rejected. No spaces. No slashes. No umlauts. No percent signs. If you want the display name to read Live Stream, that goes in the description field, not the publishing point name. The internal name should be LiveStream or Live_Stream.

Fix it from the WMS MMC snap-in:

1. Open Server Manager → Roles → Streaming Media Services.
2. Right-click the publishing point, choose Properties.
3. Rename it using only the allowed characters above.
4. Restart the publishing point.

If you're scripting it, the same rule applies. This fails:

# Bad – spaces and a colon
wmsscript MyServer Create PublishingPoint "Live: East"

This works:

# Good
wmsscript MyServer Create PublishingPoint LiveEast

The reason step 3 works is that WMS re-validates the name against the grammar every time you save, so the moment the characters are clean, the error stops. You don't need to reboot WMS, restart the service, or reinstall anything.

Cause 2: The name is hitting a reserved word or a duplicate

Even a clean-looking name can fail. WMS reserves a handful of tokens that collide with internal routes or URL path segments. I've personally seen these blow up with 0XC00D1455:

• WMSPublishingPoint
• WMSAdmin
• WMS
• Admin
• Public
• Default

Two of these — Default and Public — are especially sneaky because they look completely normal. If someone spun up a "Default" point and it errored, you'd assume something deeper is broken. It isn't. WMS uses those names internally for its own endpoints and won't let you shadow them.

The second half of this cause is a duplicate name collision. WMS namespace is flat within a server, so you can't have two publishing points both called Live on the same machine, even if they sit under different sites. Create-time collisions return this same error code. When you check, remember to look at the actual publishing point name, not just the friendly description — admins rename the description and think they've renamed the point.

Check what's already registered:

wmsscript MyServer List PublishingPoints

Or in the MMC, expand Publishing Points and scan the Name column. If your intended name is there or on the reserved list, pick something else. LiveEast instead of Live. ChannelOne instead of Public. The fix is remembering that the publishing point name is an identifier, not a label.

Cause 3: A leftover or ghost publishing point holding the name

You've checked the MMC, the name isn't there, and you still get 0XC00D1455 on create. What's actually happening is that a previous publishing point is still registered in the WMS configuration store even though it doesn't render in the console. This happens after an unclean shutdown, a failed import, or an aborted script that created the point then crashed before it could commit the removal.

The give-away is that the error fires on create even though the console shows a clean list. The WMS exported config file (usually %SystemRoot%\System32\inetsrv\config\applicationHost.config for older IIS-hosted setups, or the WMS XML under %SystemDrive%\Windows\System32\Windows Media\Server) still has the node.

Stop WMS first, then look:

net stop wmserver
findstr /i "MyPointName" "%SystemDrive%\Windows\System32\Windows Media\Server\*.xml"

If it shows a hit, back up the file, remove the offending <publishingPoint> block manually, save, and start the service:

net start wmserver

A safer route when scripts are in play is to export the full config, delete the whole WMS config, and re-import. That wipes the ghost and any other stale entries in one shot. Do not just delete the XML — WMS will regenerate a default one and you'll lose your other points.

If the ghost is coming from a script that runs on a schedule, this will keep happening. Add a cleanup step that calls wmsscript Remove PublishingPoint before the create. The error is the symptom; the missing cleanup is the disease.

Quick-reference summary

If you've checked all three and it still fails, the name isn't the problem — something upstream is mangling it before WMS sees it. That usually means a script is passing a URL-encoded string or a variable that still contains quotes. Log the exact string the script sends and compare it character by character to what you typed in the console. The error code is reliable; the input usually isn't.