Fix ERROR_DS_INVALID_SCRIPT (0X00002198) on Windows Server

What's Actually Happening Here

ERROR_DS_INVALID_SCRIPT (0X00002198) hits when a domain controller tries to run a logon script assigned to a user or computer, but the directory service says the script's invalid. What that usually means: the script file doesn't exist at the path stored in AD, or the path itself is malformed. I've seen this most often after a domain migration, when someone copies user objects but forgets the scripts, or when SYSVOL replication hasn't caught up after a new DC.

The error appears in the Directory Service event log, event ID 1001 or similar, and users see a blank login screen or a slowdown at sign-in. Let's fix it step by step. Start simple, escalate only if needed.

Quick Fix (30 Seconds) — Check the User's Script Path

The most common cause is a typo or a path that points to a script that was deleted. Don't waste time rebuilding anything yet — just check what's assigned.

1. Open Active Directory Users and Computers (dsa.msc) on any domain controller.
2. Find the affected user or computer account. Right-click, select Properties.
3. Go to the Profile tab. Look at the Logon script field. It's a relative path, like scripts\login.bat or scripts\user.vbs.
4. Now navigate to the SYSVOL share on your DC: \\\SYSVOL\\scripts\. See if the file listed actually exists there.

If the file is missing, that's your problem. Either restore it from backup or remove the script path from the user's properties. If the file exists but the error persists, move to the moderate fix below.

A real-world example: I had a client whose admin deleted the logon.cmd script during a disk cleanup on the primary DC, but the path was still set in AD for 200 users. The error flooded the event log every 5 minutes.

Moderate Fix (5 Minutes) — Check Script Path Format and Permissions

If the file exists, the error might be a syntax issue in the path, or the file is corrupt. Also check that the script is readable by the authenticated users group.

1. On the domain controller, open File Explorer and go to C:\Windows\SYSVOL\sysvol\\scripts\. This is the local path that maps to the shared scripts folder.
2. Right-click the script file → Properties → Security. Ensure Authenticated Users has Read & execute permission. Without this, the directory service can't process it during logon.
3. If permissions look fine, open the script in Notepad. Check for unusual characters — a stray UTF-8 BOM or a corrupted line break can trip up the parser. For .bat files, keep it simple: no fancy Unicode characters. For .vbs or .ps1, ensure the first line is valid and there's no garbage at the start.
4. Test the script manually: on a client machine, run \\\SYSVOL\\scripts\. If it fails to run, the file is corrupted. Replace it with a clean copy.

I've seen cases where a .vbs script had a phantom null byte at position 0 from a bad copy-paste. The file looked fine in Explorer but the AD parser choked. Use a hex editor to check if you're stuck.

Note: If the script path uses environment variables like %LOGONSERVER%, that's fine — it's resolved at runtime. But relative paths like ..\scripts\user.bat are not allowed. The path must be a simple filename or scripts\filename.extension.

Advanced Fix (15+ Minutes) — SYSVOL Replication Problems

If you have multiple domain controllers, the script might exist on one DC but not another. AD reads the script path from the directory service, but the actual file comes from the local SYSVOL. If replication is broken, the script won't be available on the DC that authenticates the user.

1. Open Active Directory Sites and Services (dssite.msc). Expand Sites → Inter-Site Transports → IP. Check if all domain controllers show recent replication.
2. On each DC, run dcdiag /test:replications /v from an elevated command prompt. Look for errors like ERROR_DS_INVALID_SCRIPT or replication failures.
3. If you find replication issues, run repadmin /syncall /AdeP to force sync. Wait 5 minutes, then re-check the script file on the problematic DC's SYSVOL.
4. If the script still isn't there after sync, copy it manually from a working DC to C:\Windows\SYSVOL\sysvol\\scripts\ on the broken DC. Then run gpupdate /force on that DC.
5. After that, test the user logon again. The error should clear if replication was the root cause.

The reason step 3 works: SYSVOL uses DFS-R by default (on Server 2012+). If a script file is missing on one DC, that DC can't serve it. Forcing sync pulls the correct file from the authoritative source. But if the file was never added to the originating DC, you'll need to restore it from backup.

One more edge case: If the script path in AD has a trailing space or double backslash, AD still stores it but the filesystem can't match it. Use PowerShell to scan for bad paths:

Get-ADUser -Filter {ScriptPath -like "*"} -Properties ScriptPath | Where-Object { $_.ScriptPath -match "\\\\| \\s$" }

That regex finds double backslashes or trailing spaces. Fix any matches by clearing the path or correcting it.

If none of these fix it, you're looking at a deeper AD issue — maybe a corrupt database. That's rare, though. In my experience, 9 times out of 10 it's a missing file or a typo. Start with the 30-second check and you'll save yourself a lot of headache.