Location B, which is the secondary AD server (I'm trying to configure but...) is on subnet 192.168.1

I understand this may be a DNS issue. The only DNS server I have assigned to that subnet via DHCP on a Sonicwall is the AD server in Location A. I got positive results from DNS tests in ping and nslookup.

I have joined, unjoined, rejoined the domain.

All Event Viewer is telling me that the login is taking too long, it took 931 second, it's taking to long to log off, and there's a csc resource cannot be loaded...

Is it simply that the profile is too large in size for the T1? I've enabled Folder Redirection - still taking forever, stuck at "waiting for user profile service".

Note that this happens on both Win2k8R2 and regular Windows 7 in Location B.

Now happening at Location A as well... [Possibly fixed - it may just be raw profile size, even with folder redirection on]

Ok, after setting up Folder Redirection and don't automatically cache offline, logon times are down to 30 seconds and logoff takes about a minute. Does that seem about right over a T1?
–
EarlsJun 23 '11 at 3:56

1 Answer
1

I wouldn't make any assumptions about the cause until you get more details about what's actually happening. If you're seeing slow logons in both locations then it's hard to pin blame totally on the WAN infrastructure (though I'm sure it bears some blame... T1's used to feel so fast... now they're just painful to me).

Anybody who knows me will be able to sing along here: Grab a sniffer and watch what's being sent on the wire. Seeing how much traffic is moving during these slow logon scenarios (never mind what the traffic composition is-- just the gross quantity) is going to tell you loads about the problem. If you see a trickle of traffic then you can start investigating why you're only seeing a trickle. If you see a flood then you can start figuring out how to size-down the data being sent. Until you know what's going on behind-the-scenes, though, you're just taking stabs in the dark. The event logs on the client and server aren't particularly useful in this scenario, in my opinion.

It's not clear to me if your server hosting the roaming profiles share is running W2K8 (or newer) or not. If it is your Windows 7 / W2K8R2 clients should be using SMB2 and doing a decent job pipelining operations for better utilization of the T1. Having said that, roaming profiles of any size (particularly if the AppData directory is filled with the kind garbage that the Flash Player and Java Runtime Environment love to pile in there) are going to be painful to sync over a T1. You can redirect things out of the profile and get it fairly small, but it can still be painful.

Grab a copy of Wireshark, port-mirror the switch port where a test client is attached, and get to sniffing. You should be able to get some details straight away about the gross quantity of traffic. Then you can start drilling-down into the specifics.