1

On our network we give each user a network share at \\fileserver\users\username. These are intentionally NOT set up as their home directory, and are instead mapped by a login script every time the user logs on. For new users, this drive mapping fails, since the folder does not exist yet.

Is there a way that when we create a new user in Active Directory, it can automatically create the folder at \\fileserver\users\username? Or alternatively, that the folder can be created the first time it is accessed?

Failing that, can somebody show me how to manually create a folder with vbscript?

edit

So it appears that the logon script solution is not going to work for me, because the user doesn't have permission to create folders in \\fileserver\users. (and the script runs with the user's privileges) Any other ideas?

Improve this question
2
  • Brent, how do you map to the user folder when login? I am aware I can create a script to map to a directory but how to a specific directory for each user? Commented May 14, 2009 at 20:36
  • strUserName = gobjWshNetwork.UserName Commented May 14, 2009 at 21:08

3 Answers 3

Reset to default
3

Set the permissions of \\fileserver\users as described in the Microsoft TechNet article entitled "Security Considerations when Configuring Folder Redirection" http://technet.microsoft.com/en-us/library/cc775853(WS.10).aspx. The situation you are describing is exactly the situation in which folder redirection operates. The permissions described will allow regular user accounts to create their own folders and then to access them, but they will not allow users to access folders belonging to others. Thus, a logon script will operate as you desire once these permissions are set.

For what it's worth, your next step along the road to best practices is to actually use folder redirection and get rid of drive mapping altogether. Windows surfaces redirected folders throughout the user interface, and so it is easier for users to find a redirected folder than a mapped drive. Also, folder redirection requires no scripting, and folder creation is automatic, which is what you want.

Improve this answer
1
  • +1 Many of MS's Group Policy changes are providing features that encourage you to discontinue login scripts, and years of experience indicate that is a Good Thing! Commented May 29, 2009 at 6:13
1 
On Error Resume Next set objFSO = CreateObject("Scripting.FileSystem") If Not objFSO.FolderExists("\\fileserver\users\username") Then result = objFSO.CreateFolder("\\fileserver\users\username" If result = 0 AND Err.number = 0 Then Wscript.Echo Chr(34) & "\\fileserver\users\username" & Chr(34) " -created" End If
Improve this answer
4
  • To do it upon first login set a login script on the user account in AD and call the above from the login script. Commented May 14, 2009 at 20:27
  • A user will not have permissions to create a directory at that level. How can I work around that? Commented May 14, 2009 at 20:40
  • This script is is intended for an Admin to run after creating the account. If you'd like I can easily edit the code so that it would prompt the admin for the path/username, and then as part of your regular procedures you could just run this after creating the user account, or better yet you could incorporate the code to create the user account and then create the folder. Commented May 14, 2009 at 21:34
  • Not exactly what I'm looking for. I want to address the (common) problem that the admin forgets to create the \\fileserver\user\username directory. Commented May 14, 2009 at 22:01
0

You could do things in a bit of a different fashion and use a script to create everything, including the user account. This way you could also include the home share as part of the new user script. There are a ton of examples out there on how to modify AD via script.

Improve this answer
2
  • I'm still hoping for a more automatic solution. When we had our fileserver on Linux, it would auto-create a missing directory the first time a user logged in. That was nice. Commented May 15, 2009 at 16:10
  • Granted, but you can't get much more automated than a catch-all script (outside of having to develop said script...) Commented May 15, 2009 at 16:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.