You're running a scheduled task or a batch script that references a server by its name—maybe \\SQLPROD01\backup—and suddenly you get 0X0000092F: "This computer name is invalid." The task fails, the script throws an error, and you're staring at Event Viewer wondering what broke. This happens most often on Windows Server 2016 or 2019 when a service account tries to access a network share using a computer name that no longer matches the actual hostname. It also pops up when you've renamed a server but forgot to update a dependent job.
Why You're Seeing This Error
The root cause is simple: Windows can't match the computer name you gave it to any name in the network's resolution system—DNS, WINS, or the local hosts file. It's not a permissions issue, not a firewall issue, not a hardware failure. The name you're using is either mistyped, outdated, or doesn't exist on the network.
I've seen this trip up admins who rename a server, update most references, but miss one scheduled task buried in Task Scheduler. The task still points to the old hostname, and boom—0X0000092F. Another common trigger: you're using the fully qualified domain name (FQDN) in a script, but the DNS record for that FQDN was deleted or never created.
How to Fix It
The fix is straightforward: figure out what name that task or command is trying to use, then correct it. Here's the step-by-step.
Step 1: Find the Exact Name Being Used
Check the scheduled task, script, or command that threw the error. In Task Scheduler, right-click the task and choose Properties. Look at the "General" and "Actions" tabs for any \computer\share paths. Note the computer name exactly as it appears—including any typos or old names.
Step 2: Verify the Correct Computer Name
Log into the target server and run hostname in a command prompt. That gives you the current name. Also check the DNS record:
nslookup your-server-name.yourdomain.comIf the DNS lookup fails or returns a different IP than expected, you've found the problem.
Step 3: Update the Reference
Edit the task, script, or connection string to use the correct hostname. If you're dealing with a SQL Server connection, it might be in a connection string like Server=OLDSERVER\INSTANCE;Database=mydb. Change that to the current server name.
Step 4: Test the Path Manually
Before you rerun the task, open a command prompt and try to access the share directly:
net use \\SERVERNAME\shareIf that works, your fix is good. If it still fails, check the next section.
Still Not Working? Check These
If the name is correct and the manual test still throws 0X0000092F, you've got a deeper name resolution issue. First, flush your DNS cache:
ipconfig /flushdnsThen make sure the target server's firewall allows ICMP and SMB traffic (port 445) from the client. If you're using a hosts file for testing, check C:\Windows\System32\drivers\etc\hosts for any old entries that might be overriding DNS.
Also—and this is the one that gets me every time—check if the computer name has a trailing space or a non-printing character. Copy-pasting from an email or a config file can sneak in a hidden space. I've spent an hour on a single hidden character before, so I always retype the name manually when testing.
If you're on a domain, run gpupdate /force on the client to refresh policy, then nbtstat -R to reload the NetBIOS name cache. That clears out stale entries that could be pointing to an old IP.
The last resort: reboot both machines. I know it sounds cliché, but name resolution caches can get stuck, and a reboot clears them cleanly. I've seen 0X0000092F vanish after a reboot with no other change.
This error is frustrating because it's so vague, but once you understand it's a name resolution problem, the fix is usually a quick edit. Keep your hostnames consistent across DNS, tasks, and scripts, and you'll rarely see it again.