Set the following in Group Policy above the WORKSTATION OU:
Computer Configuration\Admin Templates\System\Logon
Always Wait For Network=Disabled
Then this above the USER OU:
User Config\Admin Templates\System\User Profile
Connect Home Directory To Root Of Share=Disabled
As for the problem of not mapping to the %username%, that sounds like a deep share issue and the above might help. By deep share I mean Microsoft just allowed this late in NT4 days as Novell had it for years prior. Have you tried using the following syntax:
\\eblas-dc1.domain.local\users$\%username%, subsituting .domain.local with your root, of course?
What could this will essentially take NetBIOS out of the question. For instance if you have a non-DC server that is multi-homed, such as 2 NICs pointing to different subnets, it senses that on the subnet that is not associated with the DCs subnet does not have a master browser so it becomes master browser. Once a node is a master browser, it is a master for ALL subnets it is tied to. Therefor it will try to be a master on the subnet that the DC is on. The DC however knows that it should take precidence, so it doesn't reliquish master either. You end up having what we call NetBIOS browsing wars where all of a sudden all nodes can only see themselves, believe it or not. Well, fully qualifying it will make it so that the workstations uses DNS instead of NetBIOS so it will force the proper resolution of the server IP where the share is located. Example: some people multi-home Exchange servers for obvious reasons.
NOTE: The previous can also happen if a user brings a Unix or Linux box on the subnet and has SAMBA (SMB=server message block) enabled.
Check your DC for Kerberos errors. This may be caused by Vista or XP firewalll rules blocking the route. You can remediate this by turing the GP off at the offending workstaions and diagnosing it, OR setting Group Policy to turn off Firewalls completely over your OU.
Computer Configuration\Admin Templates\Network\Network Connections\Windows Firewall\Domain AND Standard Profile
Protect All Network Connections=Disabled
(You can obviously change this back after diagnosis, but do not do this on laptop OU as if you are still diagnosing when a user leaves, they will be exposed on external networks)
If you do have Kerberos or Authentication errors please list them out for me, also look on the workstations themselves.
Are any of the workstations going through a firewall appliance to get to the DCs? If so, this may be your problem also. Set GP to do a TCP/IP handshake on authentication instead of running it over UDP. With certain firewalls even firewalls that are third party ON the workstations or servers themselves like Norton, etc, will sense UDP kerberos authentication as an SPI firewall exploit.
Needless to say make sure that ALL firewalls, software or hardware on your internal LAN are disabled while diagnosing. To set the registry for this change, run a REG file that you create with the following KB article then reboot:
How to force Kerberos to use TCP instead of UDP in Windows
Next, lets check out your DNS. How is it's integrity? I am assuming you are running Microsoft's DNS instead of a third party, so check your event log on your DCs. Of course ignore DNS errors while a server is starting up because the caveat is that Kerberos Authentication of the DNS service cannot autheticate BECAUSE it has no DNS serrvice running at the time. It's a chicken before the egg symtpom. Once it is started, DNS can finally allow for Kerberos and the error will stop occuring. I know, it's dumb, but it only happens on startup for that reason. Once started, and all DCs are started do a issue a net stop netbios and then a net start netbios. This will make sure that all proper Active Directory DNS records are completely registered. Go into DNS managment itself and make sure there are no wrong server DNS records. Confirm that you have a reverse DNS zone properly configured. If you dont make sure you create a reverse on every DNS server you have, as Kerberos does a reverse lookup to authenticate. If you don't the workstation may not be able to establish it's own secure channel to the DCs or other servers. This will prohibit the User themselves from authenticating correctly as well. By default, you authenticate by Kerberos, then NetBIOS if Kerberos fails. UNLESS you have GP locked down to only allow for Kerberos.
As you have Exchange on your network, you more than likely still have the Support Tools instealled on your DCs as DCDiag is a prescribed step in setting up Exchange. Run dcdiag > c:\dcdiag.txt. Then post it here if there are errors and I will tell you how to remediate them.
Once you issue new GP settings above, make sure you reboot a couple times, OR issue a gpupdate prior to rebooting the first time. If you still have a problem after that, I want you to confirm that the GPs are active by running rsop.msc. Check for the active settings.
I'm sure you probably did, but sometimes, even when issued through ADUC, the original mapped drive will not give up it's mount for a new mapped destination. So essentially, if a user is already mapped to the root of the share instead of the deep share, even though ADUC has a user profile mapped to it's deep share it will not map it because the workstation itself is hanging on to the old mapping. To remediate this temporarily as it will only take one time to fix, is to issue a "net use u: /delete" (assuming "U: is their %homedrive%. They will just need to log off, then back on two times.
Now we move on to permissions. Make sure that the users you are talking about do indeed have NTFS permissions and correct share permissions. IF your original admin knew what he was doing he would normally lock out users from the root so they cant browse the root directory. For this however, the default of "Bypass Traverse Checking". What this does is, it essnetially makes it so that NTFS bypasses all root folder permission checking and only checks the final destination folder to see if te user has access. If this setting is DISABLED, you will NOT map correctly in this situation.
Let me know what you come up with.
.gif "IP Gear")
