Slow Logons on Folder Redirection

[blu4]

Hello all,

 

Right- we have the most bizzare situation at work now.. We have got 3x DC's on SRV 2012 R2. Two weeks ago there was a power cut and all of them had a dirty shutdown. My collegue comes in the following monday and SOME (<-- important) users have slow log on times, on laptops only. Desktops work fine. So we try to locate the issue, nothing in the logs. All of a sudden the issue fixed itself for the users that had the problem and "moved on" to the next batch of users that could log on fine. @mrbios on Discord kindly suggested to enable verbose logging, we did and we found out that the logon gets stuck on "applying folder redirection policy". We disabled that policy but issue still persists. Thigs that we did and sort of work:

 

-If you disable the Wifi you logon instantly, turn back on, log off and issue is still there.

-Wait for about 35-45 minutes. No thanks.

-Re-image the machine, that works right away.

-Run in safe mode with networking.

 

So it's definately some sort of policy that's slowing down the logon but we can't figure out which on it is. I did a little research and this is what I found, http://www.edugeek.net/forums/windows-server-2008-r2/86860-slow-logons-applying-folder-redirection.html

 

We actually had that disabled on FSRM, we disabled that policy with hope it would work but no. The issue seems to rectify itself and it moves on between users. I tried explaining this as well as I can but it's like trying to describe a colour to a blind person. It's less persistent than last week but still causing issues for us- I am buried in laptops, so is my collegue. I'd appreciate any help, please ask away for more information.

 

Cheers

[Dom_]

Are you only seeing the issues over wifi? Do they always behave patched in? What do you use for your wireless? I've had a ruckus director in the past wipe half it's config after a dirty shutdown - so most of the AP's were assigned the same channel and we had similar issues to what you're describing here...

[blu4]

Are you only seeing the issues over wifi? Do they always behave patched in? What do you use for your wireless? I've had a ruckus director in the past wipe half it's config after a dirty shutdown - so most of the AP's were assigned the same channel and we had similar issues to what you're describing here...

 

Well, we got a laptop this morning with this issue. We hooked it up with a cable and that didn't seem to work. We have already rebooted and AP controller and checked all the settings and all seems good. We have an MSM765ZL module as our Wi-Fi controller. Other laptops did behave when plugged in. That's the bizzare thing about it- we cannot seem to replicate the issue.

[Dom_]

I found I could only replicate it when logging in 16+ at the same time (in the same area - the load balancing kicked in and fired the laptops off to different AP's but they didn't have a clue where they were connecting to!). Do you have access to the AP configs - can you see which channels they're running on? Most controllers have a monitoring section.

 

Hooking up with a cable is no good if it's already started the login process (or so I found!)

[blu4]

I found I could only replicate it when logging in 16+ at the same time (in the same area - the load balancing kicked in and fired the laptops off to different AP's but they didn't have a clue where they were connecting to!). Do you have access to the AP configs - can you see which channels they're running on? Most controllers have a monitoring section.

 

Hooking up with a cable is no good if it's already started the login process (or so I found!)

 

I'll try the cable trick you mentioned. With the Wi-Fi, we tried logging on on one channel XYZ, I then go to another part of the school, different AP but still same channel XYZ- Issue still occurs. Chaning a channel doesnt do anything.

[roc1479]

Have you noticed any change in transfer rate over wifi since the glitch?

[FN-GM]

You can get this issue when you block desktop.ini files. Might be worth checking that out