Anyone in IT wanna take a stab at this one?

[cubbies]

OK, first of all, I work in IT and have for a number of years now. I am no expert, but certainly no slouch either. However, this problem has everyone in our department stumped.

We first noticed the problem when we got a new computer for one of our VP's. He works in the design department. We have a network drive (M: drive) that is our file storage. Each department has their own folder and there is a public folder. Whenever he would open his My Computer and go to the M: drive and click on the Design folder, it lags for a long time...45 seconds or more. What makes this even more weird is that it also re-maps the drive two more times. So, when he goes to his M: drive and clicks on it and it lags, then you go back to My Computer, you now have the M: drive, the Z: drive and the Y: drive...all mapped to the same place. And the Z and Y were not there before.

At first, I thought it was a problem with HP. I got the VP's laptop back from him and tested it...sure enough it didn't work. Then on my Lenovo desktop I tested it and it works fine. I go to the M: drive, click on the Design Folder and it opens right up. However, I am running Vista Business and he is running XP Pro, so I figured it was not a very good test. So I told my boss about the problem and on his Dell Desktop with XP Pro, he tested it and everything worked fine. So I called HP hoping that maybe they had seen the problem and that they had a fix. No such luck, they sent me to the research department and they are "looking into it". However, it turns out that it is not just an HP problem. I just got a Dell laptop back from a jobsite and it is having the same issue. And after doing some more research, we found the problem on two other desktops...both HP.

Here is what I have tried:

I have formatted the machine back to just a bare XP Pro SP1 machine with only basic drivers. Installed the Ethernet driver, joined the domain, added a user and logged in...doesn't work. I tried creating a dummy user in Active Directory who was a member of nothing, just a domain user who had no startup scripts or anything, just a dummy user. Logged in as him and same problem, didn't work. I tried installing an external NIC from a different manufacturer and disabling the onboard one...same problem. I am having a real hard time linking it to any of the client hardware or software.

So, I have to assume that it is a network issue. We just recently, in the last month or so, virtualized our entire network. I don't know enough about this process to know if there could be any issues stemming from this or not, and I certainly wouldn't know how to go about fixing it. The weird problem is is that even though there are a good number of machines that this happens to, there is an equal number that it does not happen to. It doesn't appear to be an user issue because if I log onto a working machine with a user that it was not working for, it works.

Actually, as I was tying this my boss came over and through some processes of elimination we have decided that this issue definitely popped up BEFORE the fileserver was virtualized.

Sorry for the long post, but I wanted to give as many details as possible.

I am open to any solutions. Anyone care to take a stab at this one?

 

[david_42]

Does the problem move with the network drop? Which is to say, if you unplug a system that isn't having a problem & plug in one that has a problem & vis versa, do the results change?

 

[CyclingCraig]

It is possible a network routing problem? Paths not configured optimally?

each time you connect to the network drive it takes a different path and thinks it's a different drive so it maps it to a new drive letter? something like that?

 

[MikeFlynn74]

Id check his account settings just to make sure they are exactly how they should be.

Is the drive mapped via scripting? Check his script specifically

 

[JVD_X]

I would check with VMWare or whomever you virtualization provider is - to see if this is a known defect.

BTW - great move going virtual but I usually ask our clients to start small by virtualizing their test environments first.

If you are talking about VLAN and not virtualization that I would agree with CyclingCraig - you have network configuration issues... probably one of your routers is not properly configured.

 

[cubbies]

Does the problem move with the network drop? Which is to say, if you unplug a system that isn't having a problem & plug in one that has a problem & vis versa, do the results change?

Yes the problem does move. My boss' computer (dell desktop, XPP) works, if I connect a system that doesnt work to it, it doesnt work.

 

[rdwj]

 

[cubbies]

Id check his account settings just to make sure they are exactly how they should be.

Is the drive mapped via scripting? Check his script specifically

For our users, the maps are scripted; however, I created a dummy user and manually mapped the drive and the problem still occurred.

 

[cubbies]

It is possible a network routing problem? Paths not configured optimally?

each time you connect to the network drive it takes a different path and thinks it's a different drive so it maps it to a new drive letter? something like that?

Not exactly. The original drive (M: ) is always there. However, when you try to open one of the folders (and it is not all the folders ont he drive, just a couple) it lags and creates two new drives (Z and Y), but they are mapped to the same place as M:.

 

[MA_Brewer]

Does the OU that the computer is in have any funky group policies applied?

You say you logged on using a dummy AD user account, but how did you get to the network location? Tools>Map Network drive from explorer? Or did you manually kick off a script?

What if you don't join the machine to the domain, and just type the UNC into explorer ie \\server\share$ - what happens then?

Are you using the FQDN for the mapping, IE server.domain.com or just the machine name?

 

[Chriso]

I agree that the symptoms seem to indicate a problem specific to virtualization. Unfortunately, while I have lots of experience with shared drives and login scripts, I have not had a chance to work with a virtualized server environment in my career.

FWIW the combination between 45sec lag and multiple new drive mappings leads me to believe it could also be a DFS problem - is the Design folder actually located within the parent Shared directory? Or is it mapped as a DFS link underneath a DFS tree?

 

[MikeFlynn74]

Hey Windows has imbraced Vware. This is a good thing. Hopefully they will get away from "features" and become more utilitarian. I love Win64. Its fast/powerful/stable.

But not used enough

 

[MA_Brewer]

I love Win64. Its fast/powerful/stable.

But not used enough

Need to use it for Exchange 2007

 

[r2eng]

Do you have networked HP printers? When this delay happens, have your task manager/processes showing and see if your "hptoolboxFX" is pegging your processor.

HP Toolbox FX makes windows explorer CHOKE on out network. Disable/uninstall it.

Just a guess... we have had this problem before, and HP's Laserjet division here in Boise is aware of it.

Hope this helps!

Eric

 

[MikeFlynn74]

Need to use it for Exchange 2007

You have no Idea- National Guard wont let us upgrade from Win2k/Exch 5.5

Dude I am in such pain dealing with that.

 

[EvilTOJ]

I'd have to agree that it's some kind of network issue. If a user that was working fine on one machine logs onto one reporting the mapping lag, and the same thing happens, it's gotta be network. I wish I knew more about our own virtualization project, but graveyard is treated like mushrooms

Let us know if you find a fix!

 

[MA_Brewer]

I'd have to agree that it's some kind of network issue. If a user that was working fine on one machine logs onto one reporting the mapping lag, and the same thing happens, it's gotta be network.

I don't know that I agree with this -- to me, the "network" is routers and switches and their supporting core services (DHCP, DNS, WINS, AD, etc.) This could be a workstation issue, which I wouldn't consider a network issue per se...but that could be just me being protective of networks as they often unfairly get the blame for things not working .

 

[MA_Brewer]

You have no Idea- National Guard wont let us upgrade from Win2k/Exch 5.5

Dude I am in such pain dealing with that.

If you want to continue the pain, upgrade to 2007 - there is LOTS of pain there. Unless you are a fan of using a command line tool to get info that USED to be easily accessible in the GUI tool.

At least you wouldn't have gotten used to having one tool to do basic AD & Exch tasks (as in ADUC for AD & Exchange 2003) only to have it taken away and moved back to two serparate tools in Exch 2007. WTF??? M$, make up your mind!!!

 

[EvilTOJ]

That's the thing though, is that he said the issue doesn't follow the user login, it stays at particular workstations. So it *could* be workstation related, but then why so many workstations? And is it truely random? Are all the workstations the same build/physical setup, or are some older than others? And are only the older/newer PCs showing the problem? Or is it happening in only certain sections of the building?


You know what's sad? Is that this is the most work I've done all night. Soooooo bored.

 

[cubbies]

Does the OU that the computer is in have any funky group policies applied?

You say you logged on using a dummy AD user account, but how did you get to the network location? Tools>Map Network drive from explorer? Or did you manually kick off a script?

What if you don't join the machine to the domain, and just type the UNC into explorer ie \\server\share$ - what happens then?

Are you using the FQDN for the mapping, IE server.domain.com or just the machine name?

There is no group policy associated with the users OU. Unfortunately. Personally I think out system is a little lax, but it is not my place to change it.

Most users get their drives mapped by a script, however, the dummy user did not. I went the tools>map network drive route.

I havent tried not joining the domain; I will try that here in a second.

Unfortunately, I am not familar with FQDN, so I cant answer that question.

 

[cubbies]

I don't know that I agree with this -- to me, the "network" is routers and switches and their supporting core services (DHCP, DNS, WINS, AD, etc.) This could be a workstation issue, which I wouldn't consider a network issue per se...but that could be just me being protective of networks as they often unfairly get the blame for things not working .

It's weird. I want to say it is the client that has the problem, but I cant say that for sure. It is only on a handful of machines, and if I take the ethernet cable from a working computer and plug it into one that is not working, it still doesnt work. However, on that same token, I have taken one of the computers down to just a bare system. Formatted with Windows XP SP1, installed the NIC driver, joined the domain, added a user, logged in and attempted to open the folder...no dice. Then on the same computer (still just a bare system), I disabled the network card and installed a PCMCIA network card by a completely different manufacturer and it still didnt work.

There is no link that I can find between the clients and the problem. They are all different models, with different NIC cards. The only thing that is the same is the OS (XPP), but there are hundreds of XPP machines here and only a couple of problems.

I dunno.

 

[MA_Brewer]

There is no link that I can find between the clients and the problem. They are all different models, with different NIC cards. The only thing that is the same is the OS (XPP), but there are hundreds of XPP machines here and only a couple of problems.

I dunno.

FQDN is just short for Fully Qualified Domain Name, IE machinename.domainname.com as opposed to just listing the "machinename".

Anyway, tells us about your VLANs - are you segmented (using VLANS and/or different subnets?) Do you have ACL's inbetween segments?

How does virtualization play into this? Do you have a cluster with a bunch of virutalized servers playing the role of DC's and "service" servers (DNS, DHCP, etc.)

 

[MA_Brewer]

It is only on a handful of machines, and if I take the ethernet cable from a working computer and plug it into one that is not working, it still doesnt work.

This right here tells me it is not the basic network transport itself. Without knowing about your virtualization or segmentation, the next step I'd try would be to use one of the "bad" machines that is NOT joined to the domain.

 

[JVD_X]

It's weird. I want to say it is the client that has the problem, but I cant say that for sure. It is only on a handful of machines, and if I take the ethernet cable from a working computer and plug it into one that is not working, it still doesnt work. However, on that same token, I have taken one of the computers down to just a bare system. Formatted with Windows XP SP1, installed the NIC driver, joined the domain, added a user, logged in and attempted to open the folder...no dice. Then on the same computer (still just a bare system), I disabled the network card and installed a PCMCIA network card by a completely different manufacturer and it still didnt work.

There is no link that I can find between the clients and the problem. They are all different models, with different NIC cards. The only thing that is the same is the OS (XPP), but there are hundreds of XPP machines here and only a couple of problems.

I dunno.

The commonality is the router.

 

[MikeFlynn74]

At least you wouldn't have gotten used to having one tool to do basic AD & Exch tasks (as in ADUC for AD & Exchange 2003) only to have it taken away and moved back to two serparate tools in Exch 2007. WTF??? M$, make up your mind!!!

Did not know that

 

[user 574]

To rule in/out probable network and routing. Take a DHCP user address that doesn't show the problem and reserve the DHCP address for the user that does have the issue. If it goes away it probably is a routing issue. Don't know how segmented you have your vlans etc but it seems to be a good thing to try to identify net/workstation based.

I saw this same prob on our end users randomly as well (only w/ user maps and performance not adding more maps). Try this; unmap all drives with the offending user and hit the server direct through UNC \\servername\shareName. If the perforamnce is normal you got the same problem we had.

 

[user 574]

Another thing and you probably don't use it but I'll ask. Do you use roaming profiles?

 

[cubbies]

FQDN is just short for Fully Qualified Domain Name, IE machinename.domainname.com as opposed to just listing the "machinename".

Anyway, tells us about your VLANs - are you segmented (using VLANS and/or different subnets?) Do you have ACL's inbetween segments?

How does virtualization play into this? Do you have a cluster with a bunch of virutalized servers playing the role of DC's and "service" servers (DNS, DHCP, etc.)

Well, I am no expert on the VLANS. I was not a major part of that project. Honestly, no one in our department was a major part of it, we had consultants doing most of the work. My boss (the network administrator) was the main person though.

Basically we have a internet connection that comes in, goes to our firewall, that then goes to our Cisco Catalyst and then off to users/servers. There are three servers housing all of our servers...there are 23 of them including the fileserver. Unfortunately, that is all I know as far as the VLAN.

 

[ohiobrewtus]

It is very unlikely that the recent server virtualization has anything to do with this issue. This sounds like a client issue to me but there are some infrastructure possibilities as well.

Some questions that I have:

Are there any common software packages on the 'problem' clients that are not installed on the 'non problem' clients?

Have you taken a 'non-problem' laptop and connected it to the same port as a 'problem' client? If so, what were the results?

Are all of the 'problem' clients on the same switch or is there a mixture of both 'problem' and 'non-problem' clients across all switches?

Are you using Cisco switches? If so, are you using the monitor session command to SPAN/RSPAN ports for any reason? If not configured properly, this can significantly impact the performance of the source ports and if one of these 'problem' clients is in one of these ports it could explain the performance delay.

Many people have asked about the user account in AD, but what about the machine accounts for the 'problem' clients? Are they all in the same OU or scattered amongst multiple OU's? Do they have any GPO's over them? You can blow out a machine, even give it a different name, move the user to an OU that doesn't have any GPO's applied to it and still have issues if the default location for machine accounts still has a GPO over it. You've checked the AD user accounts, check the machine accounts as well.

How many GC's (Global Catalog servers) do you have in your domain? Do you have either the PDC Emulator, Schema Master or Infrastructure Master roles assigned to a DC that's also a GC? If you go into AD Sites and Services are you able to successfully force replication between GC's? I have seen instances of the password that GC's use to replicate becoming corrupt - causing all kinds of weird issues. I haven't seen it cause random drive mappings, but theoretically it could if those drive mappings were once part of a GPO that has not received the most recent changes because of a broken replication bond and a client hits the GC with the old GPO settings during bootup.

 

[ohiobrewtus]

Hey Windows has imbraced Vware. This is a good thing. Hopefully they will get away from "features" and become more utilitarian. I love Win64. Its fast/powerful/stable.

But not used enough

Actually they haven't. Windows Server 2008 introduces Microsoft's virtual server platform that is in direct competition with VMWare.

If you call Microsoft for professional support and you tell them that you have their OS running on VMWare, they make sure to let you know that it not a Microsoft supported environment. They'll still assist you, but they'll get to a certain point, them blame it on VMWare and wash their hands of it.

 

[cubbies]

Some questions that I have:

Are there any common software packages on the 'problem' clients that are not installed on the 'non problem' clients?

Have you taken a 'non-problem' laptop and connected it to the same port as a 'problem' client? If so, what were the results?

Are all of the 'problem' clients on the same switch or is there a mixture of both 'problem' and 'non-problem' clients across all switches?

Are you using Cisco switches? If so, are you using the monitor session command to SPAN/RSPAN ports for any reason? If not configured properly, this can significantly impact the performance of the source ports and if one of these 'problem' clients is in one of these ports it could explain the performance delay.

Many people have asked about the user account in AD, but what about the machine accounts for the 'problem' clients? Are they all in the same OU or scattered amongst multiple OU's? Do they have any GPO's over them? You can blow out a machine, even give it a different name, move the user to an OU that doesn't have any GPO's applied to it and still have issues if the default location for machine accounts still has a GPO over it. You've checked the AD user accounts, check the machine accounts as well.

How many GC's (Global Catalog servers) do you have in your domain? Do you have either the PDC Emulator, Schema Master or Infrastructure Master roles assigned to a DC that's also a GC? If you go into AD Sites and Services are you able to successfully force replication between GC's? I have seen instances of the password that GC's use to replicate becoming corrupt - causing all kinds of weird issues. I haven't seen it cause random drive mappings, but theoretically it could if those drive mappings were once part of a GPO that has not received the most recent changes because of a broken replication bond and a client hits the GC with the old GPO settings during bootup.

Only XPP. To test this I used a generic XP CD with SP1. It was not a proprietary disk that came with HP or anything like that and had extra software...nothing but XPP with SP1. From that point I installed only the NIC driver, joined the domain, added the user, logged on and tried it. I did this on both a Dell and a HP...same thing

Yes, we have done that. Actually that was done sort of immediately. The VP who got the new computer who first noticed it. used to have a Toshiba Tablet. When he got his new computer, it had this problem, so we took it back and gave him his tablet back. The new HP wouldnt work in his office, but his old Tablet does. Plus we have tested that further up here.

Well, to be honest, we dont know how many people are having the problem. Like I said, it is only a couple of folders that have the problem, so unless you click on one of these folders, you wouldnt notice it. We havent gone around testing people machines because we dont want to alert them to a problem they dont know they have. So, of the ones we know about, they are all in our area, so one our switch...however, they did not all start out on the same switch.

We are using Cisco routers and switches, but I have had no part in the configuration. We have an outside consultant who manages those. Nobody in our department knows how they are configured.

All of the users are in the same OU and there are no group policies assigned. I wish it was a little more organized than this, but it is not my call.

The last question is over my head...sorry.

 

[cubbies]

Just to add this,

My boss' computer just started doing it. His worked for the last couple days as we have been troubleshooting this, but just now it started doing it...very weird.

 

[malkore]

Why are you still using Mapped drive letters? They are antiquated pieces of crap that are prone to failure for no reason.

setup a shortcut using a valid UNC path instead.

may not fix it, but at least you'll get away from something that's quirky to start with. :fro:

 

[MikeFlynn74]

HAve you read the memo about the TPS reports?

 

[MA_Brewer]

This was asked before, but, are you using roaming profiles? Can you log onto someone else's workstation and get the same *desktop* that you would at your own workstation?

Is DFS involved?

This sounds to me like a problem with a higher level service that you might have running, but might not be too sure about.

DC's, GC's, PDC Emulators (and all FSMO's) are probably all handeled by your ouside contractor. They are certain roles that Windows Domain Controllers have.

Where are you again? I smell some consulting $$ :cross: (j/k, of course)

 

[MikeFlynn74]

Do you have an old priest and a young priest?

 

[LakeGrove]

You have no Idea- National Guard wont let us upgrade from Win2k/Exch 5.5

Dude I am in such pain dealing with that.

You'd be in greater pain trying to use Vista. The program securities do not support the system securities established by DoD/DA/NGB. Trust me I feel your pain. Our system is slower than my old Commador 64.

On the original question my first observation is you never should have gotten HP's. Hook a chain to 'em and toss them over the bow. :rockin: Sounds like a user profiles issue. HP has some problems related to user profiles as does Compaq. Crappy BIOS. Have your bos log on to a Dell or something that you know works and see what happens.

There is one thing I like that the National Guard does. We use CAC access so I can log onto any computer and it knows who I am. Plus a lot of our Internet/Intranet sites use CAC acces so I don't have manage a bunch of passwords. And no HP's!

 

[MikeFlynn74]

LakeGrove- You in WA Guard? Email me if you ar please

 

[LakeGrove]

LakeGrove- You in WA Guard? Email me if you ar please

I AM the WA Guard:rockin: JFHQ

 

[cubbies]

This was asked before, but, are you using roaming profiles? Can you log onto someone else's workstation and get the same *desktop* that you would at your own workstation?

Is DFS involved?

This sounds to me like a problem with a higher level service that you might have running, but might not be too sure about.

DC's, GC's, PDC Emulators (and all FSMO's) are probably all handeled by your ouside contractor. They are certain roles that Windows Domain Controllers have.

Where are you again? I smell some consulting $$ :cross: (j/k, of course)

Must have missed the roaming profiles question, no we are not using them.

One things that is worth mentioning, and I don't even know if I will be able to explain it, but I will give it a shot. My boss installed a program that monitors what the computer is doing when you navigate around. When he goes to the network drive and click on a folder that is working, say the IT folder, it shows the computer looking at the M: drive, and then looking at m:\IT. However, when he clicks on a folder that does not work, like the design folder, the computer looks at the M: drive, then at the m:\design folder and THEN at every single subfolder, M:\design\subfolder1, M:\subfolder2 and so on...and these folders are pretty big. So, that is what causes the lag. We still don't know why, and we don't know why it autocreates the drives, but that is definitely the cause of the lag.