Gaz Posted November 22, 2012 Posted November 22, 2012 For some reason today a computer (Win7 Pro 64bit) has decided it wont map the home drive for any user that logs on, however it does map a drive thats mapped via a script and another that is mapped via "map network drive" in my computer All other parts of the network appear to be working fine. The Event log says: Folder redirection policy application has been delayed until the next logon because the group policy logon optimization is in effect. Also for My Docs redirect Failed to apply policy and redirect folder "Music" to "\\LTC\Students\testacc\My Music". Redirection options=0x9001. The following error occurred: "Can not create folder "\\LTC\Students\testacc\My Music"". Error details: "Access is denied.
adrian_costea Posted November 23, 2012 Posted November 23, 2012 Make sure you haver read access to that share. Try connecting using a different account.
Michael Posted November 23, 2012 Posted November 23, 2012 Does the computer have a memory card reader using up drive letters? Check in Computer Management.
Gaz Posted November 27, 2012 Author Posted November 27, 2012 Sorry for the late reply I just assumed no one had replied because I didn't get an email notification. Only student accounts seem to be effected. Teacher accounts arent even though they are both limited accounts. Yes its in the correct OU. No other drive letters taking over the drive letter. They have read access to the share. This is a real noggin scratcher. I've tried everything I can think of but the student home drive still isn't mapping and its only this computer. :/ I've tried taking it out of the domain and adding it back in and still no joy.
Gaz Posted November 28, 2012 Author Posted November 28, 2012 OK I think this may be related. I've no idea how this has happened or even how its possible. If you look at the attached image you can see there are loads of "My Documents" folders but they are shared with the students username. This may be related to the problem. I think My Documents folder redirection has gone horribly wrong somewhere. I tested with two accounts: student1 (a temp student account) and testacc (my student testing account) student1 wasn't renamed to "My Documents" but testacc was, however they were both still effected.
Davit2005 Posted November 28, 2012 Posted November 28, 2012 Is this only happening to the student on one machine, I ask because I had this issue with a Staff member once. With the following symtoms 1. The staff member could logon to a different machine and got their home drive ok. 2. Anyone else logging onto the machine got their home drive including newly created test users. 3. Did not use roaming profiles, tried multiple profile removes on the local machine. 4. Tried recreating the users home area from scratch, recreated the users account as well I think. In the end almost at last resort after a few hours mucking around I re-imaged the machine and all was ok again for that user?????? Hope this helps David
Gaz Posted November 28, 2012 Author Posted November 28, 2012 It only seems to be student accounts that are effected and its only this machine. I just created another student account and it didn't map. I also don't use roaming profiles so I may try deleting the local profile of my test accounts. The symptoms are similar but I'd like to know the cause. If more computers were effected then I'd probably go the imaging route. Imaging is a last resort.
Davit2005 Posted November 28, 2012 Posted November 28, 2012 The issue I had only was effecting one machine so it may be worth just re-imaging. If it a student machine it shouldn't take that much to get back up and running? Alternatively swap out with another machine in a completely different area to see if their is some sort of networking/hardware issue, see if the problem moves with the machine.
Gaz Posted December 7, 2012 Author Posted December 7, 2012 This may or may not be related to DNS. I've just tried mapping it via an IP address. net use /delete h: net use h: \\192.168.10.1\students\%username% <---works net use /delete h: net use h: \\ltc.ltc.local\students\%username% <---works net use /delete h: net use h: \\ltc\students\%username% <---does not work The DNS records look fine. This guy is having similar problems. http://community.spiceworks.com/topic/164782-weird-shared-drive-behavior-location-is-not-available
Davit2005 Posted December 8, 2012 Posted December 8, 2012 (edited) This may or may not be related to DNS. I've just tried mapping it via an IP address. net use /delete h: net use h: \\192.168.10.1\students\%username% <---works net use /delete h: net use h: \\ltc.ltc.local\students\%username% <---works net use /delete h: net use h: \\ltc\students\%username% <---does not work The DNS records look fine. This guy is having similar problems. Weird Shared Drive Behavior - Location is not available - Spiceworks 2008 R2 prefers FQDN paths????? Do the redirects point to a 2008 R2? Another route would be to scrap the net use for the h drive in the batch file and use the home path variable in profile tab on the users AD object. This could be tested with that one user by just pointing them to a different batch file. Copy the batch file, rename and REMout the home drive i.e: REM net use h: \\ltc\students\%username% I would seriously consider re-imaging machine if it's only effecting one machine, you may not know what a user has done on that workstation which may of effected/corrupted a particular file???? As mentioned I only had an issue similar once in 14 months. Edited December 8, 2012 by Davit2005
SYNACK Posted December 8, 2012 Posted December 8, 2012 DNS, specifically suffixes when dealing with dfs can take a while to get sorted after boot on some stations, full paths or even additional A records for dfs can help. Why not just use the full dns path for everyone if it works? You can also push dns suffixes through GPO however full paths are probably better.
sted Posted December 8, 2012 Posted December 8, 2012 Is sync centre turned off. May be worth clearing out offline files cache seen that cause similar problems when it gets it knickers in a twist
Gaz Posted December 8, 2012 Author Posted December 8, 2012 Another route would be to scrap the net use for the h drive in the batch file and use the home path variable in profile tab on the users AD object. This could be tested with that one user by just pointing them to a different batch file. Copy the batch file, rename and REMout the home drive i.e: REM net use h: \\ltc\students\%username% Sorry for the confusion, the drives are mapped via the home path variable in the profile tab. The net use stuff was while testing to see if the map still worked and the commands were executed using the test accounts. I've just tried mapping it via the home profle using the FQDN and it works. Its just I've been using it the other way without any problems for years. Then suddenly a few weeks ago it starts acting up. Where might I find sync centre? Or how can I clear out the cache?
adamf Posted March 13, 2013 Posted March 13, 2013 We normally get a couple of these issues every week, deleting the local profile has been a quick fix in the past. In the last couple of days the number of reported instances of this issues has exploded. It seems to be a very sporadic issue affecting some students on some machines. We've gone as far as to move the affected user and computer to an OU with no group policy being applied to it and even after multiple runs of gpudpate /force we are seeing the same behaviour - it's like something is getting hung up on the machine, even deleting this users local profile isn't fixing it. We've tried a couple of hotfixes from Microsoft (KB2610379 and KBKB2775511) both of which haven't helped. We've proved that re-imaging the machine does fix it but giving the number we are seeing this isn't really practical and ideally I would like a fix to stop it happening in the future. Just wondering if anybody ever managed to solve it?
Gaz Posted March 13, 2013 Author Posted March 13, 2013 Well I did manage to solve it by changing the home folder map from \\domain to \\domain.domain.local Its like it was a DNS issue even though everything appeared to be hunky dory.
adamf Posted March 13, 2013 Posted March 13, 2013 Did you change that against the AD account on the profile tab or in the GPO where you have the folder redirection settings?
Gaz Posted March 13, 2013 Author Posted March 13, 2013 In the AD account on the profile tab. I'm not sure if you can do the lot in bulk without 3rd party tools. I've got a program called AD Infinitum that allows bulk changes with an easy to use GUI. I Just changed it to "\\abc.domain.local\group\%username%"
broc Posted March 14, 2013 Posted March 14, 2013 I had a similar problem with a staff machine recently & had to clear the offline files cache to resolve. I found this for Windows 7 using Google: In registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CSC Create new DWORD (32-bit) called FormatDatabase, set data value 1 save & reboot. No need to remove, the registry value gets deleted automatically.
ALR Posted March 14, 2013 Posted March 14, 2013 OK I think this may be related. I've no idea how this has happened or even how its possible. If you look at the attached image you can see there are loads of "My Documents" folders but they are shared with the students username. This may be related to the problem. I think My Documents folder redirection has gone horribly wrong somewhere. I tested with two accounts: student1 (a temp student account) and testacc (my student testing account) student1 wasn't renamed to "My Documents" but testacc was, however they were both still effected. [ATTACH=CONFIG]16079[/ATTACH] There is a fix for the home folders being renamed to "My Documents". We had this problem and fixed it by stopping users from saving the desktop.ini files in their home area. This might be totally unrelated but I saw the image attached to your post and thought it may help. If you want directions on applying the file screen, let me know and I'll post it... Cheers, Al
penfold Posted March 14, 2013 Posted March 14, 2013 You can search for numerous threads about files being renamed "My Documents" which provide feedback on how to deal with that 1 of which can be found here.
Gaz Posted March 14, 2013 Author Posted March 14, 2013 There is a fix for the home folders being renamed to "My Documents". We had this problem and fixed it by stopping users from saving the desktop.ini files in their home area. This might be totally unrelated but I saw the image attached to your post and thought it may help. If you want directions on applying the file screen, let me know and I'll post it... Cheers, Al Yeah and the solution is to delete the desktop.ini file and it will restore it to its former state.
penfold Posted March 14, 2013 Posted March 14, 2013 The folder isn't actually renamed though, if you search the forum it is a know issue and a solution to view the actual filename was posted here.
Gaz Posted March 14, 2013 Author Posted March 14, 2013 Yes but doing that the file will still be called "My Documents" all that "solution" does is add another column with the filename, if you want to get rid of the "My Documents name you can delete the "Desktop.ini" file and it will restore the original filename. What I found is that my users couldnt connect to their homefolder when it had been renamed to "My Documents" but I may have a different setup to others.
ALR Posted March 14, 2013 Posted March 14, 2013 (edited) Yes you have to delete the Desktop.ini to return the home folder name to the username, but using the File Screen prevents the user from saving another desktop.ini the next time they log off. The solution to get rid of the "MY Documents" folder name is delete the desktop.ini then apply the file screen to stop it coming back... The physical folder name in the NTFS file structure will stay the same (if you navigate to the folder in Command prompt the name will still be the username), the dekstop.ini masks it to call it "My Documents", but your home folder shares should still work if set up properly. If the share stops working it is more likely something in the GPO, the share or permissions than the desktop.ini oddity. Cheers, Al Edited March 14, 2013 by ALR
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now