Tag Archives: troubleshooting

Target account name is incorrect… when trying to map DFS shares

This was one of the problems I worked on 1 years ago…


When some users logon to their workstation, they receive the error “Logon Failure: The target account name is incorrect” when trying to map to any shares in \\<domain>\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.

The eventlogs on the clients contains the following:

Event ID: 3034
Type: Warning
Source: MRxSmb
The redirector was unable to initialize security context or query context attributes.

Error code
0000: 00080000 00560002 00000000 80000bda
0010: 00000000 80090322 00000000 00000000
0020: 00000000 00000000 0000046c 80090322

The KB seems to point to the reason for it:;en-us;263208

Diagnosis and Resolution:

From a network monitor capture, it seems like the clients were referring to Server1 for DFS referral, but the IP address resolved to Server2 which is not a DFS replica, which rejected their request. Turning off Server2, seems to have resolved the issue, as client referred to an alternative DFS working replica instead.

The problem started when one of our team member built Server1 and added it as a DFS replica in our dfsroot. It was then turned off as its not in use yet. The SAME IP address was then used to build Server2. Server2 is not a DFS replica.

When client does a dfs referral for dfsroot, some of them got referred to Server1. Also the WINS entry of Server1 was still alive and not expired nor tomestoned. Thus, Server1 name was resolved to the IP address that was held by Server2 and hence the clients tried to make dfs referrals with Server2, which rejected the rejected the request. As a result, users could not map drives via our dfsroot.


Posted by on October 10, 2006 in Windows


Tags: ,

Slow file select on Windows Explorer

Recently a user came to me with a problem with his Windows explorer. Whenever he tries to select some files in Windows explorer in 2 particular folders, the explorer window would freeze for a moment, sometimes this can be quite a while (like up to 1 minute) before it unfreeze and the file shows as selected. The files are all MS Excel (XLS) files.

Of course, the first few things I would do is to list down all possible reasons for this to happen:
– Too many XLS files were opened
– Other huge XLS files were opened
– Anti-virus is slowing this down
– C: drive is getting full
– Too many Explorer windows are opened
– Too many applications are opened
– Performance issue with my file server
– User is too impatient (now this is something you cannot dismiss, sometimes)

The user was even asked to reboot the workstation just do nothing but open Windows explorer to that particular location… and its still slow.

I decided to check it out myself. Indeed, the particular folder he was talking about, when I selected a 5 MB XLS file, the explorer froze for about 1-2 mins before coming back alive showing the select 5 MB file. One thing I noticed is that there are between 500 to 1,000 odd XLS files within the folder and I wonder if this could have caused the problem, since other 5 or even 10 MB files in other folders don’t suffer from such performance when selected.

Now my first clue came from the MSKB titled, Slow network performance occurs when you select a file on a share that uses NTFS.

Basically it says:
This issue occurs because Microsoft Windows Explorer tries to open NTFS streams on the volume to get extended information about the file, for example, title, subject, comments, and source author. All of this information for the file is stored on the volume

It believable, but all our workstations are already on Windows 2000 SP4, whereas this KB is meant for those below SP4. So I should believe that this should be fixed. Actually, when I reread it, it meant to say that the hotfix does not fix the problem, rather we still need to change some setting to improve performance. Hence, this really does look like the culprit and so I tried the workaround suggested in the KB.

2. On the Tools menu in Windows Explorer, click Folder Options.
3. In the Folder Options window, click the View tab, and then make sure that the Show pop-up description for folder and desktop items check box is not selected.
4. Click the General tab, and then click the Use Windows Classic Folders check box.
5. Click OK to close the Folder Options window.

Immediately the Windows explorer came to live and the issue was resolved!

However, I still don’t think that I actually knew what happened, as in why the performance would actually be so slow and why a large number of files in the same folder would cause this degradation, where as a small number of files may not. Does it have to be all XLS files? What if I have a mix of different types of files like text, jpg and office documents of different sizes? Will the same issue occur?

Now being an adminstrator in the Windows server team, I find that the quality of helpdesk personals is not as good as when I used to be in helpdesk some 10 years ago. I could resolve more of the issues at the desktop level (and this is a desktop issue, really) by myself. I got this issue escalated to me from my helpdesk simply because they felt that this issue must be caused by either network performance or our file server. But they forgot that our file server are impartial to any particular folders, that is, it will not say: “I don’t like this folder, so I will slow it down”. If there is a performance issues, other folders or users would have seen this also!

I find that helpdesk and 1st level staff tend to give up too easily on problems nowsadays, simply because they can always escalate their issues to the 2nd line people.


Posted by on August 2, 2006 in Windows


Tags: ,

Weird problem with Windows environment variables at startup

Strange problem occured today with one of my Windows 2000 server, its a citrix server and had some issues with the database, so I tried to start and stop the IMA service and rebooted the server.

Upon reboot, it threw up one of the dreaded errors:

Application popup: ImaSrv.exe – Unable To Locate DLL : The dynamic link library BRAPI.dll could not be found in the specified path

Having an long path doesn’t help neither, but then the path is only 582 chars long… only half way to 1023 chars.

Its a strange error as all I did was to start stop a service and reboot the server, so there is no reasons why some of the dlls will go missing after that.

The problem was that Windows could not find the dlls located in C:\Program Files\Citrix\System32 when it starts up. Also the path variable contains environment variable %pf% which substitutes for c:\program files. That is, the string in the path variable is actaully %pf%\citrix\Sytem32. Now if we execute an echo on %pf% and %path%, all works fine. Somehow and suddenly, during the service startup time, Windows was not able to recognize or resolve the %pf% variable and hence, the dlls was not found.

Obviously, replacing the %pf% string with a literal string C:\program files seems to solve this probem upon next reboot. I have seen this problem before in NT but I am surprised to see this also in 2000. Also why Citrix is still depending on the path variable to start services is a mystery to me.


Leave a comment

Posted by on July 16, 2006 in Windows


Tags: ,

How do you know if a machine is running Windows?

Okay, this may sound like a dumb question, especially if you are looking at the machine! However, this is one of the few questions that interviewees for Windows position are stumped by, going by my experience.The question goes:

You are only given a Windows command prompt and an IP address, what tools can you use to confirm whether this is a Windows host and not a UNIX host?

Most of the time candidates would tell you that you can use ping. Some even say nslookup.

Ping only returns an FQDN as defined by the DNS service and nslookup only queries DNS servers. In no way can you confirm with definite certain that a IP address belongs to a Window machine using these 2 tools.

The correct tool to use is Nbtstat. This tool queries the Nbt stats in a host. In general, only a Windows host will reply when you us it, a Unix/Linux host will not. However, this may not be definitive as Samba clients running on Unix could also return the Nbt stats.

To confirm, you could dir the c$\winnt directory of the host. That is “DIR \\machine\c$\WINNT”. You don’t need admin access for this. If you receive access denied or a list of files, you can be sure its a Windows client.

Alternatively to check if its a Unix client, try telnetting to the host. If telnet works, in general it means its not a Windows server. Of course, this is provide that Telnet service is not running on Windows.

Leave a comment

Posted by on July 6, 2006 in Operations, Windows



Looking at active ports in Windows

Windows OS provides netstats which provides you some information on who is connected to your TCP or UDP ports and which port is active. However, very often when a service could not start because of port conflicts, that is, some other service is using the same port, netstats does not help you in your troubleshooting.

2 freeware available in the net allows you to view active port connections and which exe are running them.


Leave a comment

Posted by on July 4, 2006 in Windows


Tags: ,

Troubleshooting hardware: Blind Spots

One thing that I always remind myself of is to be opened to all possibilities, especially when troubleshooting technical issues. This usually works well, but sometimes, when we have already decided on the result or the reason for a problem, it can blind you from thinking otherwise.

The other day at the data center in Japan, one of the HP Proliant servers had a problem and we kept getting the message “hardware error”. So my immediate assumption was that something must be wrong with one of the hardware parts of the server. So in comes the HP engineer to look at the problem. My initial suspect is either the system board or the SCSI board. So I thought that this would be a quick and easy job, 1 hour, everything replaced and we go home.

But NO!! The engineer replaced the system board; it did not work. The SCSI board; did not work. Then we waiting for another 3 more hours for some CPU and memory parts to come in. Replaced the CPU; did not work. Replaced the memory, still did not work! Argghhhhh… it already 8 pm! The good news is that the server was not in production, so we took a break after like 6 hours working on it. Went home and rested.

The next day, a new engineer came in and I expected them to bring in more parts. So I was a little pissed when he did not carry anything with him and I said to myself: “Oh no, what can he do without parts, not another late night!?”

So already I’ve made a decision that this is stupid engineer and was a little bit on the edge (only internally), just waiting to see what miracle he could perform. He ask for a Windows 2003 CD, which we did not have. So I showed him where I got the error and using the exact same hard disks, I inserted it into another machine of the same specs and showed him that it booted up fine. Then I keep repeating (in broken Japanese) that we did this sooooooo many times with all other servers and they worked and only THAT machine did not work. I was trying to impress onto him that he need to CHANGE the whole bloody machine and save my time.

Then he did some that caught me off guard and suddenly and immediately I knew what was most likely the problem!

He took out the PCI network card and the 2 HBA (fiber channel) cards and place them on the floor. Almost immediatly, I knew that the problem must be due to one of the HBA cards and the symptoms makes sense all of a sudden. True enough, it was one of the HBA cards… and it has nothing to do with server, its our own stuff.

I could almost kill myself with stupidity because this is one of the worst sins one can commit in troubleshooting: “Not breaking down and identifying all the variables and eliminate them one by one!” My assumption that the server had to be faulty was so strong that I forgot that other variables, like the cards or even cables could be a source of problem.

Boy did I do a lot of “domo arigato gazaimasu” with him as he was leaving.

Leave a comment

Posted by on June 26, 2006 in Operations, Peopleware


Tags: ,