Fix Printer Error 0X00000A6C (DFS Multiple Servers)

You're printing a document, and instead of the usual whir of the printer, you get an error popup: 0X00000A6C – "The operation is ambiguous because the link has multiple servers." This isn't a printer driver issue or a paper jam. It's a network path problem, and it's been tripping up admins since Windows 2003 era.

The trigger is almost always a printer shared through a DFS (Distributed File System) path like \\domain\shared\printer. When that DFS link points to more than one file server, Windows can't decide which one to use. It's like asking for directions but the signpost lists two different towns. The spooler (the service that sends print jobs) throws up its hands and gives you this error.

Root Cause in Plain English

DFS links let you create a single logical path that maps to multiple physical servers for redundancy. That's great for file shares. But printers aren't files. A printer lives on one server, with one queue, one set of drivers, and one physical device behind it. When a DFS path points to multiple servers, Windows doesn't know which server hosts the printer. The error code NERR_DfsVolumeHasMultipleServers is the system telling you: "I'm not guessing which one."

The fix is simple in principle: make the printer's path point directly to a single server, or narrow the DFS link to one target. But the tricky part is finding where that ambiguous path is coming from. It's usually hiding in a shared printer shortcut, a legacy logon script, or a group policy that maps printers by DFS.

What You'll Need

Administrator access to the print server and the DFS namespace
The actual server name where the printer is installed
A remote PowerShell session or access to the DFS Management console

The Fix: Step-by-Step

Step 1: Identify the Ambiguous Printer Path

First, check what path your users are pointing to. Open Command Prompt on an affected computer and run:

net use

Look for any mapped drives or connections that include \domain\ or a DFS namespace. You can also check the printer properties on the user's machine:

Go to Settings > Bluetooth & devices > Printers & scanners.
Click on the printer, then Manage > Printer properties.
Check the Ports tab. If the port shows something like \\domain\share\printer, that's your culprit.

Step 2: Find the DFS Link's Targets

Open DFS Management (dfsmgmt.msc) on your domain controller or file server. Navigate to your namespace, then find the link that matches the share used in the printer path. Right-click the link and select Properties. Under the Targets tab, you'll see a list of servers. If there's more than one, that's the problem.

If you prefer PowerShell, here's a one-liner to list all targets for a given link:

Get-DfsnFolderTarget -Path "\\domain\share" | Format-List

Step 3: Choose the Correct Target

Decide which server actually hosts the printer. That's the one where the printer is shared (you can check by browsing to \\servername\share and seeing the printer listed). Once you know, remove the other targets from the DFS link. In DFS Management, right-click the link, go to Targets, select the incorrect server, and click Remove. Confirm the warning.

In PowerShell, you can remove a target like this:

Remove-DfsnFolderTarget -Path "\\domain\share" -TargetPath "\\servername\share"

But wait—if that DFS link is used for other file shares too, removing targets might break redundancy. In that case, you're better off not using DFS for the printer at all. Go to Step 4.

Step 4: Point the Printer Directly to the Server

The real fix is to stop using DFS for printers. It's not designed for that. Instead, share the printer directly on the print server and create a standard TCP/IP port or use the UNC path \\printserver\printer. Here's how to update the printer's driver on each user's machine:

On the affected computer, open Devices and Printers.
Right-click the printer and select Printer properties.
Go to the Ports tab, click Add Port, choose Local Port, then New Port.
Type \\printserver\printer (replace with your actual server and share name).
Click OK, then close the dialog. The printer should now use the direct path.

If you manage many computers, deploy this via Group Policy. Create a preference that sets the printer port to the direct UNC path, and remove the DFS-based connection.

Step 5: Reset the Spooler (Just in Case)

Sometimes the spooler caches the old path. Restart it after making changes:

net stop spooler
net start spooler

What to Check If It Still Fails

If you've removed extra DFS targets or switched to a direct path and the error persists, don't pull your hair out yet. Here are three things I've seen trip up even seasoned admins:

Driver mismatch. The printer on the server might have a different driver than what the client is loading. Update the driver on the print server, then reinstall the printer on the client.
DNS or NetBIOS aliases. If the server name you're using is an alias (like a CNAME), the spooler might still resolve it to multiple IPs. Use the actual computer name in the UNC path.
Stale printer connections in user profiles. Even after you fix the path, some systems remember the old connection. Delete the printer from the user's computer, then add it again using the direct path.

One more thing: if you're in a mixed environment with older Windows 7 or 2008 R2 clients, they sometimes cache DFS referrals aggressively. A quick dfsutil /pktflush on the client can clear that cache:

dfsutil /pktflush

That's the whole fix. It's not glamorous, but it's solid. DFS is for files, not for printers. Once you point directly at the server, this error goes away and stays away.