Quite a while ago, helpdesk came to use with this unusual problem
When some users logon to their workstation, they receive the error “Logon Failure: The target account name is incorrect”. This happens when they are trying to map to any shares in our DFS root, e.g. \\mycom\dfsroot. As such, non of their network drives were mapped.
For some workstations, they could still map to the network drives after logon manually, but for some they received the same errors when trying to map manually. For some workstations, a secure channel reset to another DC and a reboot seems to work. And users have no problems with mapping to another root, e.g \\mycom\dfsroot2, though. This isolates the problem to the dfsroot share.
The event logs on the clients contains the following:
Event ID: 3034
The redirector was unable to initialize security context or query context attributes.
0000: 00080000 00560002 00000000 80000bda
0010: 00000000 80090322 00000000 00000000
0020: 00000000 00000000 0000046c 80090322
We ran a check on MSKB and came across this:
Connecting with Incorrect Computer Name Results in 3034 Warning
This is confirmed via netmon on the client, in the netmon capture we saw:
- Client as for DFS referral and got a reply from SERVER1
- However, SERVER1 address somehow resolves to SERVER2 and when the client actually requests for a DFS referral, they ask from SERVER2.
- SERVER2 then rejected the request, as the referral was for SERVER1
How did this happened?
Well, it seems like one of my team mates was pre-building SERVER1 here, which was meant to be shipped to another location. SERVER1 is a DFS root replica for \\mycom\dfsroot. This was then shutdown and the SAME IP address was during to pre-build SERVER2 and install DFS also. This is also going to be a replica in the same \\mycom\dfsroot. SERVER1’s was still listed as a DFS replica.
Unfortunately within that short time, SERVER1’s WINS entry is still alive.
As a result, client who happened to get SERVER1 as a DFS referral talked to SERVER2 instead, which reject the request as the client principal name was incorrect, ie. not SERVER2, but SERVER1.
Turning of SERVER2 resolved this issue.
- Never reuse an IP address to build 2 servers successively, esp. not DFS root replicas.
- When turning off infrastructure server, ensure that their WINS & DNS entries are released in a timely manner.