Summary: Microsoft PowerShell MVP and Honorary Scripting Guy, Sean Kearney, begins a discussion about home drives and Windows PowerShell.
Microsoft Scripting Guy, Ed Wilson, is here. If you are a seasoned Hey, Scripting Guy! Blog reader, you know that the most frequent guest blogger is Sean Kearney. If you are new to the blog, I welcome you, and I encourage you to catch up with Sean’s previous blogs.
Sean is a Windows PowerShell MVP and an Honorary Scripting Guy. Sean has been selected to present sessions called Integrating with Microsoft System Center 2012 and Windows PowerShell at TechEd NA and TechEd Europe this year. In his free time, Sean has written several blog posts about Hyper-V and some other cool stuff. Sean will be the blogger all week, and today he is writing about passwords.
BTW, if you are in New Orleans for TechEd this week, be sure to come by the Scripting Guys booth and say hello. The Scripting Wife and I will be there in addition to Chris Duck and Brian Wilhite. We also invited www.powershell.org to share the booth with us, so come by say hello to Don Jones, Jason Helmick, and Mike Robbins. I am also sure Sean will be hanging out at the booth.
Here’s Sean…
In many companies, staff will have a private drive letter or “home drive” allocated for their use. I have seen quite a few ways the drives are set up, but the simplest structure I have seen that works well is a “root” user’s drive that is shared out as hidden with appropriate permissions. From that folder, users are mapped to private subfolders that only they or Administrative staff can access.
In our scenario, if we had a folder on the root of a file server called E:\Users shared out at \\CONTOSO-FPS\Users$, we could set up a standard of mapping each user’s home folder to drive Z:.
Normally within Active Directory, we might configure a home drive to \\CONTOSO-FPS\Users$\%USERNAME%. This would create the folder, set the Active Directory attributes for home drive to that location, and set the appropriate permissions.
We can replicate this process in Windows PowerShell with the following steps:
- Set the property in Active Directory with SET-QADUSER
- Create the folder under our root folder structure for the user
- Set the permissions with the magic of .NET
If you’re an IT professional and you just saw .NET, do not…I repeat, DO NOT PANIC. We’re going to show some of the how, but leave the important piece at the end so you can do it with Windows PowerShell by supplying what you need.
To set a drive letter and path for any user in Active Directory, we need only use the Set-ADUser cmdlet with three parameters: HomeDrive, HomeDirectory, and the Alias of the user in Active Directory.
HomeDrive is the drive letter you would like mapped for a home drive. HomeDirectory is the UNC path name on your network that is unique to that user.
If I’d like to assign drive Z: to the folder \\CONTOSO-FPS\Users$\JohnSmith, I would use the following command:
SET-ADUSER johnsmith –HomeDrive ‘Z:’ –HomeDirectory ‘\\CONTOSO-FPS\Users$\JohnSmith’
But to make this more automated, we should supply variables. If this were a new user script, we might already have at least the user alias defined. As such we can leverage the name of the folder structure:
$HomeDrive=’Z:’
$UserRoot=’\\CONTOSO-FPS\Users$\’
$HomeDirectory=$UserRoot+$AccountName
SET-ADUSER $AccountName –HomeDrive $HomeDrive –HomeDirectory $HomeDirectory
Our next task is to create that directory.
Remember, all we have done is edit a field in Active Directory. The file system on the foreign server has no clue about the information presented within Active Directory. When you edit those fields in the GUI, the user folder and permissions are provisioned as a function of the code within that GUI interface—they are not a function of Active Directory.
Creating a new folder on the file share simply requires that the account has the appropriate permissions. In the case of our Users$ share on CONTOSO-FPS, we have established the following configuration for the file share:
- Domain Admins – Full control
- Domain Users – Change
On the NTFS side, the following rights have been established for the root folder:
- Domain Admins- Full control
- Domain Users – “Special” – ReadOnly access on this folder only
Although users need to be able to edit content in their private folders, they do not need to make changes at the root level.
Now to create the private folder, we need only run a standard New-Item cmdlet as if we were creating a local folder. We already have a variable in the cmdlet that contains this information, so we can leverage it for the New-Item cmdlet:
NEW-ITEM –path $HomeDirectory -type directory -force
Now that the home drive has been created for the user, we need to establish proper NTFS permissions to allow the user to navigate and create content within this structure. In our scenario, we are going to also allow the Domain Admins group to navigate and change control on the folder.
~Sean
Thank you, Sean, for a great post. Join us tomorrow for Part 2.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy