Mark Minasi's Reader Forum
Mark Minasi's Reader Forum
Home | Profile | Register | Active Topics | Active Polls | Members | Search | FAQ | Minasi Forum RSS Feed
 All Forums
 HALP! Questions on Windows and Windows Server
 Windows Vista
 Strange renamed folder phenomenon - Vista related?

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

 
Note: please do not cross-post.
Cross-postings will be deleted and ignored.
Thanks for helping to keep this forum junk-free!
Check here to subscribe to this topic.
   

T O P I C    R E V I E W
aval Posted - 10/22/2008 : 3:20:56 PM
I THINK this is due to Vista file synchronization although I'm not 100% sure. Maybe you can tell me.

Until now, user personal folders, located in one parent folder, were designated by their name:

jsmith
tjones
wchurchill

etc. etc.

Now, the users with Vista (3 cases) and users who may have logged on to a Vista machine have folders designated by the name "Documents":

jsmith
tjones
Documents
Documents
wchurchill

And no, Windows does not seem to mind that there are several (sub)folders with the same name.

If I open the folder, I can see the file path and the user name in the address bar. Otherwise, there's no telling these folders apart without opening them.

Has anyone else noticed this? Files are accessible and folder redirection seems to be working all the same.

----------------------

EDIT - I'm also adding links to images posted online - see post below.
29   L A T E S T    R E P L I E S    (Newest First)
DanielRussell Posted - 12/11/2010 : 2:48:41 PM
What I did to fix the issue was to install FSRM and make a file screen for the share where their home directory is mapped disallowing any ini files. That did the trick for me.
geekzinc Posted - 10/04/2010 : 12:03:34 PM
This is also happening to anyone connecting to a w2003 server via our new W2008 terminal server - is there a way to turn this off???????
timbiotic Posted - 09/10/2010 : 1:32:14 PM
Is there a way to powershell script this where it only goes 1 level deep instead of all the way through?
scottpowers82 Posted - 01/22/2010 : 09:59:03 AM
I'm having the same thing happen to me on my network as well. Thankfully, all we have is a few users using Windows 7, but we plan to fully deploy it this Summer and would love to have this fixed in an easy to deploy method. Can anyone perhaps post a simple script that can fix the issue? Or are there any known methods to resolve the issue via a simple Group Policy update?

Thanks in advance
Zadoc Posted - 12/20/2009 : 05:44:18 AM
Hi,

still the same behavior in W2k8/Win7.
"Deny" Read access to "Desktop.ini" worked after a new logon to the fileserver.
Other work around is not to use "Explorer" but "Total Commander" or any file manager tool.

This is really anoying. Thank you MS!
aval Posted - 12/17/2009 : 08:30:32 AM
quote:
If you need the batch file e-mail me and I can send it your way.


Or post it here?

-----------------------

Has anyone tried this with a W2K8 file server / Vista-W7 combination.

I THOUGHT this was not a problem when I tested as mentioned above.
Endaar Posted - 12/15/2009 : 3:43:00 PM
Please let us know what PSS says.
erickson777 Posted - 12/15/2009 : 11:45:41 AM
We are seeing the same issues in Windows7. We just today added four Windows7 workstations to a client environment (Server 2003, all systems previously were XP) and when users logged in from those Windows7 machines their user folder on the server (we had always redirected U to \\servername\users\%username% via group policy) became "My Documents". The fix of deleting/renaming the desktop.ini file DOES fix the issue, however it is painful to go system by system.

So instead what we did was to use a little batch file we put on the NETLOGON share that would rename the desktop.ini to desktop.old. By incorporating this into the login script and having the batch file only be called if the OS type matched Windows7, the problem is resolved and doesn't spread. If you need the batch file e-mail me and I can send it your way.

We opened an e-mail case with Microsoft Support to see if they have any plans to resolve this issue .. no word yet. IMHO: Despite it being "by design" and workarounds like our batch file being available, it really is a silly problem for Microsoft to have. The workarounds in kb947222 are pretty weak.. none of them fit well for environments where you have hundreds or thousands or user shares. This was not a huge issue with Vista because so few companies converted.. but this will become a large issue with Windows7.
Douggg Posted - 12/11/2009 : 12:21:19 PM
There are issuing using Vista with a SNAP (now overland storage) NAS server. I can copy files to/from the server fine. But if I create a folder it loops and continues creating folder.
New Folder 1
New Folder 2
New Folder 3

I have to pull the NIC cable of re-boot to get it to stop.

Called Overland Tech Support, they said Microsoft did something (I guess in SMB) that's causing the problem and there is NO fix for the Snap servers.

Douggg

gazzarp Posted - 12/11/2009 : 11:40:54 AM
This is still a problem with Windows 7. I have deployed 20 Win 7 boxes and all of the redirected folders have changed to "Documents".
Douggg Posted - 11/18/2009 : 11:04:04 AM
Anyone know if this chnaged with Windows 7?
Douggg Posted - 11/18/2009 : 11:03:29 AM
I think the person who posted this reply on TechNet sums up our feelings best.

This has got to be the most RETARDED feature I have ever seen. So basicly anyone who has their system setup like this is SCREWED! - I have over 3000 users all with their documents fodlers directly in a share! And the really wierd thing is for some reason one name is slowly replicating to ALL our user folders... obviously the actual foldername is never touched, but the visiable folder name is - IS there ANY way to turn this off?
Endaar Posted - 11/18/2009 : 09:14:51 AM
Hmmn, I might have spoken too soon. This seems to have turned up again.
Endaar Posted - 11/18/2009 : 08:30:28 AM
Hi aval,

I use a GPO to actually redirect My Documents, etc. I still need a drive letter mapping though for some of the old software we deal with. The script is below. Bear in mind the majority of it is actually writing out to the PCs event log for troubleshooting purposes.


Dim objShell, objNetwork, objFSO
Dim ProfileDir

On Error Resume Next

Set objShell = WScript.CreateObject("WScript.Shell")
Set objNetwork = CreateObject("WScript.Network")
Set WshSysEnv = objShell.Environment("USER")

EventText = "Home folder mapping script processing started at: " & Time
objShell.LogEvent 4, EventText

ProfileDir = objShell.specialfolders("mydocuments")
EventText = "My Documents folder detected as: " & ProfileDir
objShell.LogEvent 4, EventText
WshSysEnv("NetworkDocs") = ProfileDir

EventText = "About to attempt to map user's home folder <" & ProfileDir & "> to drive H:\"
objShell.LogEvent 4, EventText

objNetwork.MapNetworkDrive "H:",ProfileDir
If Err.Number <> 0 Then
   EventText = "Error: " & Err.Number & "     Source: " &  Err.Source & "Description: " &  Err.Description
   objShell.LogEvent 1, EventText
   Err.Clear
Else
    EventText = "Successfully mapped user's home folder <" & ProfileDir & "> to drive H:\"
    objShell.LogEvent 4, EventText
End If

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colOperatingSystems = objWMIService.ExecQuery _
        ("Select * from Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
 OSVer = objOperatingSystem.Version
Next

Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.DeleteFile("H:\desktop.ini")

EventText = "Home folder mapping script finished at: " & Time
objShell.LogEvent 4, EventText

WScript.Quit


James
aval Posted - 11/18/2009 : 08:24:18 AM
So do you use the script to map the drive (rather than the setting in user properties | profile) and THEN in the same script delete the desktop.ini?

Otherwise, would you mind posting the script?

Lastly, I wonder if this "feature" has been corrected in Windows 7?

It seems like it is NOT a problem with the Vista - W2K8 server combination (tested just once, so perhaps not conclusive).
Endaar Posted - 11/10/2009 : 2:41:45 PM
Hate to bump an old thread, but this has been a thorn in my side for a bit, and I think I just came up with a reasonably simple workaround.

I have a login script which maps a drive letter to the user's redirected home folder. All I did was change that script to delete desktop.ini after mapping the home folder. This appears to be effective in preventing the folder name from changing.

As always, YMMV.

James
aed Posted - 03/16/2009 : 11:01:28 AM
Desktop.ini tells windows explorer how to display the folder so the display name of the folder is determined in the desktop.ini file. Have you checked the desktop.ini file on what it has?

Behaivor is because you are logged in and viewing the folders as Administrator. Deny access to it and then Administrator won't have the problem. That's my take on it.
Xenophane Posted - 03/11/2009 : 2:08:27 PM
That is correct... Then it will traverse all subfolders from there...

As a test you could do something like


$file = "C:\users\<username full path to INI>"
#Where the above is something like $file = "C:\users\<username>\desktop.ini

$colRights = [System.Security.AccessControl.FileSystemRights]"Read" 

$InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::None 
$PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None 

$objType =[System.Security.AccessControl.AccessControlType]::DENY 

$objUser = New-Object System.Security.Principal.NTAccount("Administrators") 

$objACE = New-Object System.Security.AccessControl.FileSystemAccessRule `
    ($objUser, $colRights, $InheritanceFlag, $PropagationFlag, $objType) 

$objACL = Get-ACL $File
$objACL.AddAccessRule($objACE) 

Set-ACL $file $objACL


aval Posted - 03/11/2009 : 08:26:07 AM
I don't have Powershell on these servers - they are running W2K3.

I think Powershell can be installed on W2K3 though.

I don't see why denying the admin access to the desktop.ini folder would solve the problem. Of course, if it does, it does, and that's that.

But what does the admin have to do with it? I would think that it's the SYSTEM account that is managing all this in the background, and not the admin who may not even be logged on.

Otherwise, concerning the script, and using my example in images, I would replace this:

quote:
$InitialFolder = "c:\scripts\test\"


with this:

quote:
$InitialFolder = "c:\staff\"


RIGHT?
Xenophane Posted - 03/10/2009 : 3:16:27 PM
Did not put this through extensive testing, just created a few desktop.ini files in a test folder, and added the Deny setting on the administrators group.


Just be aware this will recurse through all subfolders from the folder you supply and looks for files named desktop.ini


$InitialFolder = "c:\scripts\test\"

$Files = Get-ChildItem $InitialFolder -include desktop.ini -recurse -force

Foreach ($File in $Files) {
$colRights = [System.Security.AccessControl.FileSystemRights]"Read" 

$InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::None 
$PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None 

$objType =[System.Security.AccessControl.AccessControlType]::DENY 

$objUser = New-Object System.Security.Principal.NTAccount("Administrators") 

$objACE = New-Object System.Security.AccessControl.FileSystemAccessRule `
    ($objUser, $colRights, $InheritanceFlag, $PropagationFlag, $objType) 

$objACL = Get-ACL $File
$objACL.AddAccessRule($objACE) 

Set-ACL $file $objACL
}


This could probably have been done much easier with CACLS.
aed Posted - 03/10/2009 : 1:59:11 PM
I'm sure it's scriptable. It will depend on what version of server and if you are using powershell. I'm sure Claus could whip one up in no time in powershell :) I'm away from the office this week but can look at it next week.
aval Posted - 03/10/2009 : 09:25:32 AM
Jerrod,

Thanks for the link. Method 2 seems problematic, since granting users exclusive rights to their folder can make folder redirection fail altogether in some cases (in W2K and XP, if the user was not owner of their home folder which could be the case depending on how it was created).

Method 3 would mean a lot of repetitive work if you have hundreds of s (like I do) not to mention thousands (which some of you do).

There's probably a way to script this? One might do well to test it first (of course).

Otherwise, I tried to solve this by disabling the Offline Files service - with no success: yet another folder was renamed.
aed Posted - 03/08/2009 : 11:47:53 PM
Here's what MS has to say about it.

http://support.microsoft.com/kb/947222

Be sure you catch the note on the methods:
quote:
Note Method 2 works only for new users. To update the names of the existing folders on the server, we recommend that you use Method 3.

Looks like it all points back to the desktop.ini file in each folder.
MrEclipseguy Posted - 03/08/2009 : 7:24:18 PM
Not sure if its relavent, but I have been experiencing an issue at home where multiple "local settings\app data" folders are created within each users profile. Within each of the folders is the exact same subfolders all empty. ???
aval Posted - 03/08/2009 : 4:04:32 PM
Having been able to reproduce the above behavior, and film it in VMWare, I can confirm that Windows Vista renames the home folder of users to "Documents" under certain conditions:

Compostition of test network

- Domain Controller running W2K3. It is also the file server hosting the home folders.
- Client running XP SP2
- Client running Vista SP1

What I did

I created three users and configured them to have folders in this location (in their user profile settings in Active Directory):

C:\Staff

Which was accessible as:

\\DC1\Staff\%username%

I then configured folder redirection so "My Documents" is redirected to this folder.

I configured it as "Redirect to the following location": \\DC1\Staff\%username%

I logged on the XP machines as each of the three users.

The folders remained named as they were originally:



I then logged on as each of the users on the Vista machine.

One by one (as I logged on successively as each user) the folders were automatically renamed to Documents:



And then:





I did not make an image of the screen after the folder "mleblanc" changed. In the video, you can see the name of a fourth user (that I added later to verify) change to "Documents" at second 27-28


NOTES:

It seems that the renaming of the Home Folders only takes place when Folder Redirection applies to the user.

The folder of a test user not belonging to the OU affected by the Folder Redirection GPO was not renamed.

So the simple mapping of a network drive in the user profile (properties) does not appear to cause this behavior.
aval Posted - 02/02/2009 : 1:33:59 PM
First, sorry to keep you waiting, Mark. I gave up on this, seeing that MS considers it "by design" and probably won't patch it anytime soon (why patch a problem that isn't?).

quote:
Or is this just a single Vista machine shared by many people?


Yes, that's it.

There are no roaming profiles involved.

The machines were Vista from the start (SP1).

If you want screen shots, etc. I can provide them.
Mark Minasi Posted - 01/09/2009 : 12:56:59 PM
Hi David--

I'm not understanding what leads to this, can I ask for more info?

Are you saying that these users use roaming profiles? Or is this a system that was once XP and was upgraded? Or is this just a single Vista machine shared by many people?

Apologies, I must be dumb today... I read the forum post you pointed to and I'm afraid I still don't understand what's happening. Thanks!
Douggg Posted - 01/05/2009 : 11:58:49 AM
From MSFT

This behavior is by design. Because there is a desktop.ini file inside of the folder, and the display name of the folder is determined in the desktop.ini file.

Workaround:
========

Create a subfolder named as username and redirect to that subfolder. This will eliminate the confusion by allowing you to see folders and their respective users clearly. For example:
original redirected path is: \\server\share\username
current redirected path should be: \\server\share\username\username
In that folder, rename desktop.ini to desktop.old.

But as follow up users have pointed out this is a labor intensive solution since you have to "touch" every workstation.

MSFT didn't respond. Hopefully this will be a feature fix in Windows 7?
aval Posted - 01/05/2009 : 09:04:46 AM
This is what's happening (nice to know I wasn't hallucinating):

http://social.technet.microsoft.com/Forums/en-US/itprovistanetworking/thread/3f933312-8096-448d-b5ff-8664c659fc5b/

Mark Minasi's Reader Forum © 2002-2011 Mark Minasi Go To Top Of Page
This page was generated in 0.13 seconds. Snitz Forums 2000