Ran into a problem this weekend and was wondering of any Windows savvy 'dopers could give me some thoughts on it. Basically, it seems that the Windows 7 workstation machines on one of my customers Windows 2003 domains is not getting their home drive mappings from their profile in Active Directory Users and Computers. They are getting all the drive mappings from the VBScript login script they are using, but not from the Windows 2003 Domain, interestingly enough.
I did some research, and it seems this is a known bug that can be fixed (in theory) by upgrading the domain to 2008. I say ‘in theory’ because based on some of the responses to people trying this, it seems to be definitely mixed results.
My question though, is maybe there is another way as a stop gap until the customer upgrades to 2008 sometime later this year (assuming that if the Windows 7 boxes were on a 2008 domain they would be getting their home drive mappings correctly…no idea). Would a ‘better’ way be to simply modify the VBScript log in script to map a home drive directly from there, instead of using ADU&C to map it in the profile? And if so, what would the code look like to map a drive to the users home share? I presume there is a variable for the user name in VBScript, correct?
Or is this the wrong way to look at fixing this issue? What’s the ‘best’ way to solve this (with the caveat being that the customer does not want to upgrade to 2008 until late later this year or early next year)?
Do you have any more information on this ‘bug’ (MS KB Article, for example)? We have a Windows 2003 domain, and have migrated a fair number of our IT staff to Windows 7 and haven’t had any problem with drive mappings.
My first guess is that it might have something to do with Group Policy changes in Win 7, but I’m not sure by any means.
I didn’t see any MS KB articles on it…just some threads discussing the problem when I googled it. Basically what’s happening is that the Windows 7 boxes (and ONLY the Windows 7 boxes) don’t get their home drive mappings on log in. They get all their other drive mappings from the VBScript they are running at log in, but not the drive mapping from their profile.
You can map the drive manually using \server\share$<username>, and, of course, you can make the drive re-map that way on log in, but that only works if the same user uses the same machine every time. I’ll see if I can dig up some of the threads I was looking at yesterday on this if I have a chance tomorrow.
Out of curiosity, are you mapping a home drive using the profile in your Windows 2003 domain? Have you upgraded your AD to 2008?
Take a look here for a very basic home drive mapping in a logon script. I would check the mapping first (if NOT exist "<homedrive>:" then …) to ensure that it had not been auto-mapped, but that is about it.
Take a look here for a very basic home drive mapping in a logon script. I would check the mapping first (if NOT exist "<homedrive>:" then …) to ensure that it had not been auto-mapped, but that is about it.
It’s not a group policy issue, so I don’t see how GPUPDATE would do anything, to be honest. To answer your question, nope…haven’t tried that, nor was it anything that was suggested in any of the threads I was looking over. The basic solution they were talking about seemed to be to do a forest and AD upgrade to 2008, but it seemed to me that about half of the folks who said they had tried that were still having the same issue.
I’ll definitely check it out. I’m leaning towards this more brute force type solution in the interim, since I’d rather not mess with an AD update given the delicate state of the users network (plus the fact that they will be deploying an all new 2008 domain later in the year or early next year, so no point upgrading their 2003 domain to 2008).