CustomAddADUser v1.0

I uploaded a new project on Github today, named CustomAddADUser.

If you have a lot of Active Directories and/or employee account records to maintain, or even if you don't but you're just obsessive compulsive like me, you might require a certain level of completeness, accuracy, and use of custom attributes that the old Active Directory Users and Computers doesn't really give you.  For instance, let's say that your HR system requires that you populate the "Employee ID" attribute on your user accounts.  The ADUC GUI doesn't provide that as part of the "new user" dialog. You have to create the user first, then enable "Advanced Features," then go and click on them again, open their properties sheet, go to the "Attribute Editor" tab, and type it in there.  And even then it's still prone to typos, which will make your identity management a struggle and your HR system won't be able to accurately track the user accounts.  You can't just mark the "employeeID" attribute as mandatory unless you want to modify the AD schema. And even if you did that, you still can't ensure that the employee ID matches a very particular ID format that your company uses.

Well CustomAddADUser aims to make all that possible.

Almost everything is customizable via a configuration file, including which attributes are mandatory, the application's icon, the window title, the company logo that appears on the "About" tab, the help text that appears on the About tab, and the regular expressions that are used to validate the input. Furthermore, you'll notice as you enter the user's account details that names are automatically capitalized and trimmed for you, etc., to encourage a clean and consistent user database.

(Gah people that don't capitalize the first letters of names drives me up the wall!)

So let's say that you need all your employees to have their employee ID attributes filled out, and your company uses employee IDs that look like F4348277 for full-time employees, and P4348277 for part time employees.  No problem, just edit the config file to use this regex pattern:

<add key="employeeIDRegex" value="\b[fp]\d{7}\b" />

Now the application will not allow the user to be created until the employee ID matches that regex pattern.  It will politely remind the administrator that the attribute needs to match that pattern.

All the other attributes have their own regex patterns too. If you don't care about the format of the attribute, just leave the regex pattern as (.+) to match anything.

Additionally, since it's very rare that AD users are created and aren't assigned to any security groups, you can easily copy the security group members from another existing user during creation.  When you change the "Create in" drop-down list, the list of available users from which to copy group memberships changes accordingly to show only users who are also in that branch of the directory.

The app is about 36 hours old so I will likely continue adding new features pretty quickly.  And of course, I wouldn't have put it on Github if I wasn't welcoming to anyone who wanted to submit bugs, feature requests, etc.  One of my missions with this application is to make it significantly better than the standard ADUC Users and Computers interface that people might actually want to use it... so I will be adding more features to it.

Writing and Distributing a Powershell Module via GPO

I recently wrote a bunch of Powershell Cmdlets that were related to each other, so I decided to package them all up together as a Powershell module.  These particular Cmdlets were tightly integrated with Active Directory, so it made sense that they would often be run on a domain controller, or against a domain controller, usually by a domain administrator.

First, to create a Powershell script module, you create a folder, and then place your *.psm1 and *.psd1 files in that folder and they must have exactly the same name as that folder. (You can also compile your Powershell module into a DLL, but let's just talk about script modules today.)  So for instance, if you name your module "CloudModule," you would create a directory such as:

C:\Program Files\PSModules\CloudModule\

And then you'd place your files of the same name in that folder:

C:\Program Files\PSModules\CloudModule\CloudModule.psm1
C:\Program Files\PSModules\CloudModule\CloudModule.psd1

I think that a subdirectory of Program Files works well, because the Program Files directory is protected from modification by non-administrators and low-integrity processes.

The psd1 file is the manifest for the PS module. You can easily create a new manifest template with the New-ModuleManifest cmdlet, and customize the template to suit your needs. The module's manifest is simply the "metadata" for the Powershell module, such as what version of Powershell it requires, other prerequisite modules it requires, the module's author, etc. The cool thing is that with current versions of Powershell, just by saying:

RequiredModules = @('ActiveDirectory')

in your manifest file, Powershell will automatically load the ActiveDirectory module for you the first time any cmdlet from your module is run. So you really don't need to put an Import-Module or a #Requires -Module anywhere.

The psm1 file is the collection of Powershell Advanced Functions (cmdlets) that make up your module. I would recommend naming all of your cmdlets with a common theme, using supported verbs (Get-Verb) and a common prefix. You know how the Active Directory module does Get-ADUser, Remove-ADObject, Set-ADGroup, etc.? You should do that too. For example, if you work for McDonald's, do Show-McSalary, Deny-McWorkersComp, Stop-McStrike, etc.

Now that you've got your module directory and files laid out, you need to add that path to your PSModulePath environment variable so that Powershell knows where to look for it every time it starts. Do not try to cheat and put your custom module in the same System32 directory where Microsoft puts their standard PS modules.

I decided that I wanted all my domain controllers to automatically load this custom module. And I don't want to go install and maintain this this thing on 50 separate machines.  So for a centrally-managed solution, let's utilize Group Policy and SYSVOL.

First, let's put something like this in the Default Domain Controllers (or equivalent) GPO:

(*Click to enlarge*)

And secondly, let's put our Powershell module in:


Of course, since this directory is replicated amongst all domain controllers, we only need to do this on one domain controller for the files to become available on all domain controllers.  Likewise, any time you update the module, you only need to update it on one DC, and all DCs will get the update.

Lastly, since this Powershell module is only for Domain Administrators, and SYSVOL by design is a very public place, let's protect our module's directory from prying eyes:

Careful that you only modify the permissions of that one specific module directory... you don't want to modify the permissions of anything else in Sysvol.