I have been seeing this behaviour for a while and have never been able to answer it.

When a user logs into a computer one time it will be 20 seconds and 2 minutes later on the same computer with the same user it can take 5 minutes where it just sits at the welcome screen and does nothing. I know it is waiting for something but I can't figure out what. If you disconnect a computer from the network while it is stuck at the welcome screen by unplugging its network cord it will finish logging in almost immediately.

you could also check your switches and make sure they are matched speed wise to your connections, you might have port/duplex mis-matches. You can also enable verbose mode so you will see what you used to see with XP on boot-up -- open your Group Policy settings, and go to this location:

we found those settings, along with disabling IPv6 on network adapters helped a lot. the last setting is off by default and only on with Server 2008. make sure your Win 7 systems have a good DNS link to all your DC's, as it relies on DNS a lot.

I'm suspecting GPO/GPP as well. I had the same problem. The suggestions for turning on Verbose logging will help you pinpoint the issue as the whole log is time stamped by line. You can start to get a sense of where things are hanging up based on that time-stamp.

In our case, we had printers being installed by GPP that were set to "Replace". This meant that every time the user logged in, the system re-mapped their printers. It added 2-3 minutes to login. Once we changed it to "Update", login times were back to normal.

We would have never figured it out without the verbose logging turned on.

I don't know why they have verbose off by default in the first place, to be honest. it's incredibly useful and it actually tells you what it's doing instead of that dreaded "welcome" message for 10 minutes(if you're having issues).

Once I turned on the verbose logging, I could actually see it hanging on "applying folder redirection policies." Once I knew that, it really helped me narrow down the search.

I had tried everything I could think of before that, including Soluto and Microsoft's performance toolkit.

There seems to be a correlation to both our problems. I get the feeling that whatever causes the issue on folder redirection policies also affects the drive mapping policies. I would recommend running this hotfix on a test machine and see if it fixes it for you:

Afeitguy, this sounds exactly like my problem I even have the same settings set in group policy, however I installed the hot fix and still the same slow logon issue. It still wants to hang when applying the drive policies

I get it, I'm usually the one asking others the dumb questions :-) and then listening to an even dumber answer.

I did restart after applying the hotfix. that's how I know it didn't work. the logon was still slow after. I haven't run gpresults, I can and see what happens.

all of my mappings are to a DFS root namespace that has everyone allowed for permissions. the sub folders have different permissions underneath but I would assume the mapping would only check the first level?

all of my mappings are to a DFS root namespace that has everyone allowed for permissions. the sub folders have different permissions underneath but I would assume the mapping would only check the first level?

That's the great thing about mapped drives. You can map a drive to a folder that a user has permissions to and the parent folder directly above it, they do not have permissions to(not being inherited, obviously).

So, let's see what happens with the gpresult and go from there. I'm not sure if you've ever used it before, but the results can be exported to an html file. Very handy for troubleshooting purposes.

However, after glancing over it, I noticed a few things that you might want to play with.

First, I noticed two GPO's that look like they have been merely "deleted" instead of properly removed. You can tell, because the name of the GPO's are simply GUID's. The reason this jumps out at me is because of the reason the GPO's were denied were "Inaccessible." It may not have anything to do with the problem, but as a somewhat OCD person here, I'd want that off my report, regardless.

Next, I noticed your use of "calgary.cedarglenhomes.com" as all the link locations. Nothing necessarily "wrong" with that, and you may have your reasons for doing so, but let's try a few things on the mapped drives portions:

calgary.dedarglenhomes.local - There is a slight difference between the two. If I ping "americanfire.com", I get our externally facing IP address given to use by our ISP. If I ping "americanfire.local", I get the static internally facing IP address I assigned my Domain controller. If I had backup domain controllers and the main failed, I would get a different IP address. Or, if I had multiple domain controllers, I would get the first one(usually the "main" one), to respond. Anyway, try the .local just in case it's having to go through a weird route to get back to the domain controller.

ServerName - This is more for troubleshooting purposes, unless you only have one domain controller, in which it wouldn't matter anyway.

IP Adress - \\192.168.2.253\users\%username% (as an example) when mapping drives. This could possibly rule out DNS issues. Or, point them out. :p

Also, just for giggles, on the U:, I noticed you have: \\calgary.cedarglenhomes.com\systems\Cedarglen Users Folders\%username%

Try wrapping that in quotes because of the spaces between Cedarglen Users and Folders. Although, I would imagine it would fail to map if it required quotes, but it couldn't hurt to try it.

I've run into issues with DFS and mapped drives when using the domain namespace for DFS if not all servers that could be resolved to that DNS name were setup properly for DFS.

If this is the case, mapping to the DFS root does a DNS roundrobin and it sometimes resolves to a server that does not have the DFS share online.

To make sure this is not an issue:

Go into your DNS zone calgary.cedarglenhomes.com and verify all the IP addresses that will resolve to calgary.cedarglenhomes.com. They will the the A records with a Name value of '(same as parent folder)'

Make sure that each server that has one of those IP addresses has the DFS path you are trying to map to.

From there, you should be able to find it in SYSVOL or use AGPM to restore it with change control---recycle bin.

As for using IP, I suggested it as a troubleshooting step, not a permanent fix. If using an IP fixes the problem, you're looking for a DNS problem. The suggestions given by Daniel Eaton above me are a good start on the road to a fix.

Thanks for the help, my logon seems to be much faster now. the gpresults trick is a good one. I was able to pick out some errors in the gpo's from this. I noticed some references to a server I no longer have as well as some large sections that weren't really doing anything useful for me so I removed them.

The other change I made was with my drive mappings. I changed them all from replace to update and it seems to have sped up the drive mappings section

Yeah, gpresult really is a useful and very underutilized tool. It takes some time to go through it, especially if you have tons of policies, but I've actually added it to my quarterly maintenance routine.