Discussion Locked

Home Folder mapping

0 helpful
15 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I'm having trouble with users home folder mapings

users profile tab is configured like this

home folder: h: to \\servercluster\share\username
it seems as some users are not able to map it correctly, they
map it as \\servercluster\share

If I run gpupdate \force and log off the user and log it back on it maps
correctly until the next reboot.
I found out that those settings are stored in this registry key:
HK_Users\S-1-5-21-...\Volatile Enviroment

Users that map the home folder right have those settings
Homedrive: h:
Homepath: \
Homeshare: \\servercluster\share\username

But those that don't map the folder right hafe those settings
Homedrive: h:
Homepath: \username
Homeshare: \\servercluster\share\

If I change the registry settings the user maps the home
folder until next boot
This is only happening to our windows xp clients and not windows 2000 pro clients.

Has anyone had similar issues?

15 replies

by djameson

if you are using a windows 2000 ad environment, there was a common bug that is addressed in 2k3. Occasionally you will have to add a "\" at the end of the path, there is a path assembly problem that incorrectly builds the path, also make sure that the user has "full Control" of the path listed in the box, or the mount will fail to the next higher directory that they do. Also, you have to watch your folder ownership make sure they are owned by "computername\administrators" group or you could have some issues.;

by travis.duffy

When I try to put a "\" at the end of the path, i get the message:

The specified path is not valid. Enter a valid network server path using the form \\server\share\folder

by djameson

Then you are running on either a 2k3 ad structure or a 2k3 tool.

Can the users browse to that path and access all the documents?

by djameson

Option Explicit
dim dom
dim OU
dim usr
dim concat
dim obj
dim thing
dim grp
dim username
dim profilepath
dim homepath
dim homedir

Function FindNBind()
dim myObj
set myObj=GetObject ("LDAP://rootDSE")
FindNBind=myObj.get ("defaultNamingContext")
'FindNBind="dc=mydomainname,dc=com"
end Function

'calling the function
FindNBind
dom = FindNBind

'building a DN for the Class Object
concat="LDAP://OU=users, OU=test environment, "& dom
wscript.echo "The concatenated DN is " & concat

'binding to the Users object
set obj=GetObject (concat)
wscript.echo "Its class is " & obj.class & "." & vbcrlf & "This will change the profile path: "

'changing profile for each user
for each thing in obj
Wscript.echo thing.name
homepath = "\\server2\user$\" & thing.sAMAccountName &"\home"
profilepath = "\\server2\user$\" & thing.sAMAccountName & "\" & thing.SAMAccountName
'wscript.echo homepath
'wscript.echo profilepath
thing.Put "homeDirectory", homepath
thing.Put "homeDrive", "h:"
thing.Put "profilePath", profilepath
thing.SetInfo
next

by davidja02

Hi Did you find a fix for this, loads of people have posted this error over differnet forums.

We now have this issue and are pulling our hair out.
Can anybody help. We do not want to have just fix this with a login script, we need to know why it is happening.

Regards
Dave

by mdanihy

Nobody on the net seems to have a good answer for this. We have been battling this ever since SP2 came out. We thought it might have something to do with the TCP/IP stack that Microsoft changed in SP2. We applied a patch we found on the net and it didn't help. It seems using the NET USE H: \\Server\Home\%username% /persistant:YES will work fine (at least for the most part). That would actually entail us finding all the logon.bat files we use for everyone (not everyone has the same) and making the changes. We also point everyone's "My Documents" to the H: drive, so that would have to be changed in AD as well to point to H:. We are still searching for the reason, just as everyone else on the net who is having the same problems. We have narrowed it down to an OS problem on the client side, not the server.

by frantisek.kos

We have the same trouble. The trouble manifested on Win based server and on NAS EMC (CIFS) too. The Win 2000 Pro clients haven?t this trouble. It seems to an OS problem on the client side, not the server (approve to MDanihy).

by jmedpc

We had a similar problem using a batch file and a gpo to map drives. We switched to a vb script and the problem went away. We also disabled XP (through a GPO) fast boot.

Hope this helps!

Jim

by gadman

We don't have that problem because we map our home drives differently. When we create a user and their home folder we share out that folder as username$. That hides the folder from being browsed to directly. We don't share out the 'Users' folder. So users don't see everyone else's home folders. The path to their home folder becomes \\servername\username$.

by hagstrom

I got the same problem. It's very random. Hoping somebody will figure out what the problem is. Maybe somebody has gone directly to Microsoft and asked for help?
Seems to me it has to be a MS bug...

by mmccabe

It's been over two years since the original post. Has ANYONE figured this out yet? We've had this issue ever since we deployed XP to our desktops, and nobody seems to have a clue.

by gpavey

Found this on another post.Somebody suggested to enable this GPO; Computer Config-Administrative
Templates-System-Logon-Always wait for network at computer startup and logon.

It seems that You need to disable quick login for the win xp clients. Cached credentials allow you to login even if the network isnt ready or available and that can cause the home folders to not map correctly. It will take 2 full reboots on your XP clients though. There is a KB on it somwhere at microsofts site. It never happes on win2k machines because they are forced to wait for the network to be ready. This policy forces the xp clients to do the same thing.

by p_hofland

Same problem here.
We opened a Microsoft support call and they came up with the following solution.
Disable the FastLogon option, but FastLogon enabled is the standard setting for XP?
So, this is a workaround and not a solution as I see it.
Microsoft should start working and find a proper solution instead of changing the standard XP settings to get things working again.

I do see alot of MSGINA errors in eventviewers on the servers (dating back years) where the homedrives are located. Does anyone else have these errors? Filter the eventviewers ApplicationLog to search for MSGINA errors.

Event Type: Error
Event Source: MsGina
Event Category: None
Event ID: 1010
Date: 20-03-2009
Time: 10:50:33
User: N/A
Computer: server
Description:
Failed to set the user's home directory (Drive F: connected to Share \\Servername\users$).

Notice the homedrive path in the error above and the errors are just as random as the homemapping Errors.

Question: Does anyone use Smartcard access software such as IdentiPHI?

Thanks,
Peter

This discussion is closed to new replies.