Trapper Posted October 10, 2014 Posted October 10, 2014 Can't find this using search (probably my fault) Since going to Windows 7 everyone's Home Directory has that annoying desktop.ini which changes the folder name to "Documents". Hard when staff are trying to find a users drive. I've set a GP option to disable it (does sod all), I've emptied the file and turned all the security off so it's totally inaccessible, but it still happens. Help!
Ant Posted October 10, 2014 Posted October 10, 2014 You could add a column for "filename" and sort by that instead. Not ideal, but far easier than trying to mess with disabling desktop.ini etc. I appreciate this is probably easier for you to do for yourself rather getting staff to it.
siuko Posted October 10, 2014 Posted October 10, 2014 Use File Server Resource Manager > File Screening Management - Ban saving of desktop.ini to their areas Works a treat - but does spam the event logs a bit every time desktop.ini is being saved lol
DevilsAdvocate Posted October 10, 2014 Posted October 10, 2014 (edited) Just in relation to the above, we had massive logon slow downs when blocking the desktop.ini We were redirecting to the users home drive root and I changed it to create a folder called 'Documents' within the root instead to negate the name change and need to block desktop.ini Edited October 10, 2014 by DevilsAdvocate 2
siuko Posted October 10, 2014 Posted October 10, 2014 Just in relation to the above, we had massive logon slow downs when blocking the desktop.ini We were redirecting to the users home drive root and I changed it to create a folder called 'Documents' within the root instead to negate the name change and need to block desktop.ini I haven't noticed logon slow downs... but I am interested in what you do instead. Where exactly is it that you create the Documents folder? And what do you use to create it? Sounds like a better idea than mine
FN-GM Posted October 10, 2014 Posted October 10, 2014 I haven't noticed logon slow downs... but I am interested in what you do instead. Where exactly is it that you create the Documents folder? And what do you use to create it? Sounds like a better idea than mine It does actually slow it down. I tested it
DevilsAdvocate Posted October 10, 2014 Posted October 10, 2014 (edited) I didn't notice it at first until I watched one of our students logging in with mandatory profile and it took over 2 minutes, most of which was 'preparing desktop'. I changed the group policy setting for Document redirection to create the folder and then added in the appropriate share path. Edited October 10, 2014 by DevilsAdvocate 1
Joanne Posted October 10, 2014 Posted October 10, 2014 you can run a batch file to delete them: @echo off del /s /q /f /a "h:\desktop.ini" del /s /q /f /a "h:\$Recycle.Bin\*.*" replace the h:\ with whichever drive the folders are on on the server. THEN - my personal recommendation, set document redirection so that the documents folder goes into the username folder.
localzuk Posted October 10, 2014 Posted October 10, 2014 We fixed this by following Microsoft's guidance - move everyone's documents to a sub-folder within their named folder, so it ends up with \\server\share\username\documents. All our accounts are set up in that way.
smithson83 Posted October 10, 2014 Posted October 10, 2014 I had most of these same issues first the "Documents" then the slowdown when attempting the block the creation / read etc through FSRM. My solution was to create a folder under \%username% called Documents and map H:\ to that so the kids don't see any difference and the staff get \\DFS\Pupils\YearGroup\JoeBloggs\Documents The gotya is that when creating users you have to first create \\DFS\Pupils\YearGroup\%username% which creates the user folder, then go back and set them all to \\DFS\Pupils\YearGroup\%username%\Documents which cretes the documents subfolder. bit of a faff as existing users need their documents moving over but a careful robocopy did that in minutes.
Satvir Posted October 10, 2014 Posted October 10, 2014 We have fixedthis by running a batch script, every 15 minutes, for both staff and studentshome drives (a separate script for staff and students). This desktopinifile is created every time the user logs onto the network and so it needs to bere-ran every 10 minutes. It takes less than a minute and is not CPU hungry atall. Our batch file is: REM ***********remove student troublesome desktop.ini files*************** REM this mustbe placed in C:\support\scripts run as system user every 1 day @00:15 REM and repeated every 15 mins for 23 hours mdD:\deletearea_Students RoboCopy D:\users\pupils D:\deletearea_Students desktop.ini /MOV /E /LEV:3 /Z/R:1 /W:1 /TS /FP rmdir D:\deletearea_Students /S /Q exit Basically, the script makes a temporary folder on our D:drive on the server. scans each of the user areas searching for the desktop.inifile. If it finds it. it then moves that file into the temporary folder. Onceall the user areas have been scanned, it then deletes the temporary folder whichcontains all of the desktopini files. Works very well and does not cause us any issue. We havebeen using this for over 12 months now. 1
smithson83 Posted October 10, 2014 Posted October 10, 2014 (edited) If you move the My Documents folder to %username%\Documents, you don't need to keep deleting it, or prevent it from being made, or read... @localzuk you beat me to it whilst I was typing Edited October 10, 2014 by smithson83
localzuk Posted October 10, 2014 Posted October 10, 2014 Can I ask those of you who are deleting desktop.ini files, why are you continuing to do this? The Microsoft advice on it is here - http://support.microsoft.com/kb/947222
smithson83 Posted October 10, 2014 Posted October 10, 2014 (edited) Can I ask those of you who are deleting desktop.ini files, why are you continuing to do this? The Microsoft advice on it is here - http://support.microsoft.com/kb/947222 +1 Seems overboard when a little work sets you up the way it was designed. Extra step on user creation, plus robocopy script for existing users, job done. Edited October 10, 2014 by smithson83
SovietRussia Posted October 10, 2014 Posted October 10, 2014 I usually add a the 'owner' column, it displays the username then.
Trapper Posted October 11, 2014 Author Posted October 11, 2014 If I change the Documents location from H:\ to H:\Documents, how will that effect laptops with offline sync. I assume it will need the offline cache formatting and then resyncing. otherwise there will be two copies of the same data in the offline cache (the original location, now not needed and the new location which will be forced to sync from scratch after the change). I've only got 120GB SSDs in the staff laptops, they can't handle two copies of some folks home directories!
TechSupp Posted October 11, 2014 Posted October 11, 2014 +1 Seems overboard when a little work sets you up the way it was designed. Extra step on user creation, plus robocopy script for existing users, job done. Can you post the robocopy script that creates the new folders and moves the existing data to the new folders? Presume All I have to do then is do a mass change on the user account property that sets the path to the users home folder? Our home folders are currently set as \\server\staff$\Smiths on each home folder path in AD, could I use a %username% or something similar i.e.\\server\staff$\%username%\documents in the path so they are all the same and not have to do each one?
Trapper Posted October 12, 2014 Author Posted October 12, 2014 Just as an aside - why did M$ decide to change this behaviour for Win Vista ++?
Chuckster Posted October 13, 2014 Posted October 13, 2014 Run this REG at startup in your GPO, as this'll cure the problem. Windows Registry Editor Version 5.00 ; Prevents User folders being renamed to Documents after logging on [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{FDD39AD0-238F-46AF-ADB4-6C85480369C7}] "LocalizedName"=hex(2):00,00 1
truebluesteve Posted October 13, 2014 Posted October 13, 2014 Do you actually need to move any existing data if you create a Documents folder? This Microsoft workaround doesn't actually say that as such
free780 Posted October 13, 2014 Posted October 13, 2014 I didn't notice it at first until I watched one of our students logging in with mandatory profile and it took over 2 minutes, most of which was 'preparing desktop'. I changed the group policy setting for Document redirection to create the folder and then added in the appropriate share path. [ATTACH=CONFIG]26965[/ATTACH] Did this speed up login?
stitch Posted October 14, 2014 Posted October 14, 2014 Use File Server Resource Manager > File Screening Management - Ban saving of desktop.ini to their areas Works a treat - but does spam the event logs a bit every time desktop.ini is being saved lol This is the way I do it here as well. Works Great.
smithson83 Posted October 14, 2014 Posted October 14, 2014 (edited) Can you post the robocopy script that creates the new folders and moves the existing data to the new folders? Presume All I have to do then is do a mass change on the user account property that sets the path to the users home folder? Our home folders are currently set as \\server\staff$\Smiths on each home folder path in AD, could I use a %username% or something similar i.e.\\server\staff$\%username%\documents in the path so they are all the same and not have to do each one? I think I did it something like this Goto the Home folder right click open command promt here and enter DIR /B > C:\Data\Stafflist.txt This will get you a list of the users, open this in excel In cell b1 type =CONCATENATE("robocopy ", CHAR(34), A1, CHAR(34)," ",CHAR(34), A1,"\Documents",CHAR(34), " /MOVE /E /ZB /COPYALL /XD Documents Recycler Sysvol appdata /XF desktop.ini /R:5 ") Replicate this down the column, hightlight the column and copy Run CMD as admin (needed for /COPYALL) change directory to the home folder then simply hit paste Obviously test it first, make sure you have a good backup to hand. Then go to the staff OU in AD, select all, and change the Home Folder to \\server\staff$\%username%\Documents, hit ok, and cross your fingers Edited October 14, 2014 by smithson83 Terrible Spelling 1
TechSupp Posted October 14, 2014 Posted October 14, 2014 Thanks, may give that a try when I get a 'brave' moment. At the moment I use the fike management to block the ini file, no slow downs as farvas I can see (or hear) so far. Will monitor and if problems try to make time for a 'brave' moment. Trouble with supporting only in spare time, dont get big amounts if time to try things out.
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