Redirecting 'My Documents'

[Yzöwl]

Just another method for reusing /redirecting to an existing My Documents

The task:

Search all Local hard and Network drives except for the System drive

Find the 'My Documents' folder attributed to the current User name

Redirect the My Documents, My Music and My Pictures to the found location

The problems:

The folder does not always get named My Documents or *Documents in fact

People for some unknown reason do not always use the User name within the path

How to attribute the folder contents to the current user only

The thinking:

Use something common to all 'My Documents' folders (desktop.ini)

Search for all files named desktop.ini on all local and network drives

Read each desktop.ini file looking for the name of the current user

If found look for something in that file unique to the 'My Documents' ini

If a match is found, add the new locations to the appropriate registry keys

The result:

In order to read all those files, a batch file took far too long.

(you wouldn't believe how many desktop.ini files can exist on your system)

The vbscript may still take a while, especially searching networks

What therefore follows is my attempt at a vbscript to do the job.

redirect.vbs

sComputerName="."
Set oWMI=GetObject("winmgmts:{impersonationLevel=impersonate}//" _
  &sComputerName &"\root\cimv2")
Set oDriveSet=oWMI.ExecQuery _
  ("Select Name From Win32_LogicalDisk WHERE DriveType=3 OR DriveType=4")
Set oOSSet=oWMI.ExecQuery("Select * From Win32_OperatingSystem",,48)
Set oCompuSet=oWMI.ExecQuery("Select * From Win32_ComputerSystem",,48)
For Each sOS In oOSSet
  sSys=sOS.SystemDrive
Next
For Each sCompu In oCompuSet
  sUser=Split(sCompu.UserName,"\")
  sUser(1)=Trim(sUser(1))
Next
For Each sDrive In oDriveSet
  If sDrive.Name=sSys Then
  Else FindFile sDrive.Name
  End If
Next
Sub FindFile(sDLetter)
  sDrive=sDLetter
  sName="desktop"
  sExtension="ini"
  sWQL="Select Name From CIM_DataFile WHERE Drive='" _
    &sDrive &"' AND Filename='" &sName &"' AND Extension='" _
      &sExtension &"'"
  Set oResult=oWMI.ExecQuery(sWQL,,48)
  For Each oFile In oResult
    ReadFile oFile.Name
  Next
End Sub
Sub ReadFile(sFName)
  sIni=sFName
  sMyDocs=Left(sIni,InStrRev(sIni,"\"))
  sMyDocs=Left(sMyDocs,Len(sMyDocs)-1)
  sExpLoc=Replace(sMyDocs,sUser(1),"%UserName%")
  Set oFS=CreateObject("Scripting.FileSystemObject")
  Set oIn=oFS.OpenTextFile(sIni,1)
  bFound=False
  Do Until oIn.AtEndOfStream
    sLine=oIn.Readline
    If InStr(sLine,"Owner=" &sUser(1))>0 Then
      bFound=True
      Exit Do
    End If
  Loop
  If bFound=True Then
    Do Until oIn.AtEndOfStream
      sLine=oIn.Readline
      If InStr(sLine,"InfoTip=@Shell32.dll,-22914")>0 Then
        Set wShell=CreateObject("Wscript.shell")
        sKey="HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\"
        wShell.RegWrite sKey &"User Shell Folders\Personal",sExpLoc,"REG_EXPAND_SZ"
        wShell.RegWrite sKey &"Shell Folders\Personal",sMyDocs,"REG_SZ"
        wShell.RegWrite sKey &"User Shell Folders\My Music",sExpLoc &"\My Music","REG_EXPAND_SZ"
        wShell.RegWrite sKey &"Shell Folders\My Music",sMyDocs &"\My Music","REG_SZ"
        wShell.RegWrite sKey &"User Shell Folders\My Pictures",sExpLoc &"\My Pictures","REG_EXPAND_SZ"
        wShell.RegWrite sKey &"Shell Folders\My Pictures",sMyDocs &"\My Pictures","REG_SZ"
        Exit Do
      End If
    Loop
  End If
End Sub

I would suggest this is run as a logon script.

For unattended use your initial logged in user name, usually Administrator, would need to be the name you wish to redirect to an existing location.

Note

It only maps existing 'My Documents' folders to users of the same name as before.

Dont expect username Rosemary to take over Rose's old documents folder

Disclaimer

I am more proficient at coding Windows NT Command Scripts.

There may therefore be better or faster ways of achieving the goal with VBScript.

If any damage occurs as a direct result of this script, even if you knew me, I would take no responsibility for it.

[Djé]

2 questions and 2 possible (related) suggestions:

1- When you say ' logon script', do you mean runOnceEx or are talking about something else that I will want to know about.

If it is runOnceEx, you may have it run for every user by using the runOnceEx key not in the HKLM hive, but in the HKCU one at T12.

This way, the running command will be copied to the Default User hive and then to every users hives to be executed when they first login.

It you're not talkin about RunOnceEx, what is it then?

2- Are the keys changed before or after the creation of the standard Shell Folders by windows? If it's after, wouldn't it be interesting to also delete those standard Shell Folders with a few more lines in the script, since they aren't needed anymore?

[Yzöwl]

@ Djé

1. I would suggest using the default users runonce key

@ECHO OFF
PUSHD %ALLUSERSPROFILE%\..\DEFAULT USER
REG LOAD HKU\TEMPHIV NTUSER.DAT >NUL 2>&1
REG ADD HKU\TEMPHIV\Software\Microsoft\Windows\CurrentVersion\RunOnce /V NewMyDoc /D "cscript /B /nologo \"%%ALLUSERSPROFILE%%\redirect.vbs\"" /F >NUL
REG UNLOAD HKU\TEMPHIV>NUL 2>&1
POPD
GOTO :EOF

This example would of course mean that you woud need to locate the redirect.vbs in %AllUsersProfile%.

2. I understand what you mean, and it is something I thought about, originally and am still considering.

With my lack of confidence in my vbscripting techniques, I just didn't want all my eggs in one basket!

Edited April 6, 2006 by Yzöwl

[Djé]

1- Yep. That's the clean way to do it. HKCU at T12 is not very clean.

So I guess the sequence would be:

a- schedule redirect.vbs in HKLM RunOnceEx (from T12, T13 or whatever for the first login).

b- schedule the above batch (including a moving of redirect.vbs to the proper location) to be run also by HKLM RunOnceEx so it will set-up the things for subsequent users.

Now, if redirect.vbs has to remain on the computer for any potential user (re-!) showing up. Maybe it would be ideally located in %SystemRoot%

2- I have no vbscripting techniques, so my suggestion remains theoretical.

[Yzöwl]

1. It sounds to me like you've got a little script coming on

2. Scripting that in shouldn't prove a problem, it's more the fact that I tend to think with a similar logical progression to batch scripting, and for the sake of some unused folders, I didn't want to go through the rethink. As I said, I am still considering it, I'm just not ready to do it yet!

[MHz]

1- Yep. That's the clean way to do it. HKCU at T12 is not very clean.

So I guess the sequence would be:

a- schedule redirect.vbs in HKLM RunOnceEx (from T12, T13 or whatever for the first login).

b- schedule the above batch (including a moving of redirect.vbs to the proper location) to be run also by HKLM RunOnceEx so it will set-up the things for subsequent users.

Now, if redirect.vbs has to remain on the computer for any potential user (re-!) showing up. Maybe it would be ideally located in %SystemRoot%

2- I have no vbscripting techniques, so my suggestion remains theoretical.

I disagree. The Default User Profile is loaded instead of the current user at T-12. A perfect time. I add to the registry entry and copy the file to the HDD in one go.

The registry entry will execute a RunOnce script that is super hidden in the Windows Dir. You just need to add the entry at T-12 to HKCU\...\RunOnce and it will be executed with any new account that is logged on to. My script is old and proven to work for each new logon.

Clean as I did not have to load a profile...think about it.

[Djé]

I disagree. The Default User Profile is loaded instead of the current user at T-12. A perfect time. I add to the registry entry and copy the file to the HDD in one go.

The registry entry will execute a RunOnce script that is super hidden in the Windows Dir. You just need to add the entry at T-12 to HKCU\...\RunOnce and it will be executed with any new account that is logged on to. My script is old and proven to work for each new logon.

Clean as I did not have to load a profile...think about it.

MHz, I think you did not get it exactly. I'll try to explain it better below, and also why it still works the way you do.

AFAIK, at T12, HKCU (meaning the loaded user hive, or profile as you call it) does not map to the hive in the Default User Profile, which does not exist yet.

Rather, it maps to HKU/.DEFAULT, which is NOT the same.

HKU/.DEFAULT is the registry hive for No User (before someone logs in). It is stored in '%SystemRoot%\System32\config' along with all the system hives. Its file name is simply 'default'.

In there you can also find a folder called 'systemprofile' which stores the 'No User Profile' files.

I don't know yet when, but after T12, the Default User Profile is made out of (copied from) this 'No user Profile', and the 'default' hive is copied to the NTUSER.DAT (user's hive) of that Default User Profile (meaning in '%ALLUSERSPROFILE%\..\Default User' ).

That is why you don't have to load the Default User hive and it still works (you already know that, later, when a new user logs in for the first time, his profile is made from that Default User Profile).

Why I'm saying it's not clean and why Yzöwl made this hive loading batch is that using HKCU at T12 leaves some stuff in HKU/.DEFAULT which has no reason to be there, since No User does not need any shell folder.

Now, I must agree, it's not that a big issue. But if you do that for all your reg tweaks, well... yes it works, but I maintain: it is not very clean. We can do better.

And loading a hive, tweaking it no more than necessary and then unloading it IS clean. It may be some more work, but it does not leave any mark behind.

@Yzöwl: no I don't have any little script coming on. And I would not, except if you ask me to do it. I was just commenting (that's always easier ).

Edited April 7, 2006 by Djé

[Noise]

Yzöwl,

That is one of the coolest scripts I've seen in awhile. Very nice. But I'm curious about one thing, what is the NUL 2>&1 is the pushd and popd lines? I cant figure out what it does...

[Yzöwl]

I'll try to explain with an example:

I entered the commands at the commandline to show you the resulting output

Microsoft Windows XP [Version 5.1.2600]
© Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Yzöwl>PUSHD %ALLUSERSPROFILE%\..\DEFAULT USER

C:\Documents and Settings\Default User>REG LOAD HKU\TEMPHIV NTUSER.DAT

The operation completed successfully

C:\Documents and Settings\Default User>REG UNLOAD HKU\TEMPHIV

The operation completed successfully

C:\Documents and Settings\Default User>POPD

C:\Documents and Settings\Yzöwl>

Now adding the >NUL prevents the 'standard output' message of The operation completed successfully being shown by redirecting it to nul, (nothing or nowhere), whereas 2>&1 would prevent any subsequent 'standard error' message by redirecting it to the same place as the 'standard output'. You will also notice the >NUL at the end of the reg command which also prevents the 'successfully' message.

From the PUSHD message you can see that it basically puts you at another location, the clever bit is that it stores the location you were at when you moved. When you need to go back, use POPD and it will return you to the previous location as stored.

[Noise]

I've been using >NUL and PushD and PopD for a long time, I'm very familiar with them. I had no idea you could use pushd and popd on the local system, I thought it only worked on network drives, very handy. I would have used the subst command, but yours is way better.

The >NUL statement alone blocks the status message programs the programs issue. Are you saying the 2>&1

will block any secondary messages that >NUL would miss? Would the command 2>NUL be the same as 2>&1 in this instance?

Thanks for trying to explain this, I'm just trying to understand better. The 2>&1 is very intreguing to me because I've never seen it used before.