In this 2 part series I will show you how to build an automated and audit-friendly user termination process. In Part 1, I showed you how to get the users into a centralized location and execute basic user termination actions. For Part 2, we will fully automate the process of the user being deleted from the organization, while backing up their email, home directories, and providing email logs.

You can find Part 1 here.

Disclaimer: This script could have a very negative impact on your organization. As such, I am not responsible for any damage that may come from using this script. You should take great care when implementing anything that will be destroying/altering data without interaction.

Addons / Things to know

• purchase accutane !Important: You will need DotNetZip to use this script properly. You can find the dll that we’ll use here: Ionic.Zip.dll
• An Exchange account will need to be created for mailflow purposes.
• Create a second OU for termed users who have encountered an error. If errors occur, a person will need to correct them.

Scenario

HR has submitted the termination request for the user Test User. In Part 1 we:

• Removed the user from any groups
• Updated the description field with a note (for us, we will use TERMED: mm/dd/yyyy)
• Moved the user to a termed user OU
• Hid the user from the GAL

In Part 2, our script (not us!) will do the following:

• Move the Mailbox to a terminated user Mailbox Database
• Export the active Mailbox and Personal Archive PST
• Zip up and move the user’s Home Directory
• Check our work, and mark users who are ready for removal
• Remove the users from Active Directory
• Clean up previous processes

We will use the following functions:

• Zip
• ConvertToDate
• MoveMailbox
• ExportMailbox
• ArchiveHomeDirectory
• PendingRemoval
• RemoveObject
• LoadModules
• CleanUp

And we’re off.

Variables, Modules, and Parameters

Before we can get into the meat and potatoes, we need to define some variables and load some modules.

To begin, our only parameter is $function. This allows us to run the script and define a specific function. We then load our Ionic.Zip.dll (DotNetZip) and System.Web (we’re going to use it to generate a hashtag). The DLL that you downloaded earlier should be placed in C:\\scripts\\ScheduledTasks\\bin\\.

Variables

• Customiziable variables. Change these to reflect your organization.
  • $terminated_days – The amount of days that must pass since this user was terminated before we can being our process
  • $from_email – Who the email will come from
  • $to_email – Who the email will be sent to
  • $smtp_server – The relay server. You can DNS or IP
  • $zip_password – The password we’ll use to “secure” our zip files
  • $termed_ou – The OU where terminated users are placed
  • $domain – Your internal domain name
  • $termed_mailbox_db – Termed user mailbox database
  • $blockmailsender – This user will be used to stop mail flow to a specific user once their PST has been exported
  • $archivelocation – Share location where PST’s and homedirectories will be placed
• Static Variables. Do not change these variables.
  • $purge_date – Subtract the $terminated_date from today’s date
  • $date – Today’s date
  • $split – Split $domain into an array
  • $shortdom – The NetBIOS name of your domain (hopefully)
  • $shortdom2 – Top level domain (local)

Function: Zip [$Path, $OutputPath, $user]

This function will zip up our HomeDirectories.

First we empty out $hashinfo, then with a foreach loop we create a unique hash for this zip. We then add README.txt with the info $user archived on $date. This allows us to know when this user’s HomeDirectory was specifically archived. Add in hash.txt so that our zip is unique. I implore you to read more about DotNetZip for information about what else is happening within this function. DotNetZip is a good tool to have in your arsenal of powershell scripts.

Variables for this function

• $Path – Path to the file that will be zipped
• $OutputPath – Where our zip will be dumped once it has been processed
• $user – The username of the user who is being terminated

Function: ConvertToDate [$STR]

This function will convert the string date that we get from the user’s description field into something we can use. ** Note: I did not write this function, but I cannot find the source. If you did, or know who did create this, please contact me so I can provide proper credit! **

Please read this TechNet article for more information about regex.

Function: MoveMailbox

This function will find any users that are in the Termed Users OU and move them to the Termed users mailbox database.

First we need to get a list of users in the Termed Users OU. We do this by using -SearchBase. We will do this for nearly every function from here on out, so I will not cover it beyond this point. We need to set our $count variable to 0 in order to know if we should send an email (was anything done).

Within the foreach loop, we are generating the following info and executing the following commands.

• $sam – Get the user’s SamAccountName
  
• $database – Get the user’s mailbox
• if $database.Database does not equal “$termed_mailbox_db” (the one defined by you in the variables), then do the following
  • Execute New-MoveRequest for the user $sam with a Target Database of $termed_mailbox_db. Allow up to 50 items to be corrupted.
    • You certainly do not have to allow any bad items; however, in my experience this will only cause issues with your automation. It is acceptable within our organization to lose 1-2 emails for every 10,000 emails.
  • $count++ is saying make $count whatever it was, plus 1.
  • $move_mailboxes is for our logging purposes. If this is the first time the loop has run through, then $move_mailboxes is empty and only the $sam is captured.

Now that our loop is complete, we should send an email to the administrator(s) and let them know who has been moved.

We will reuse many of the same commands / variables (although we will redefine them) for future functions, but I will not continue to explain them.

Function: ExportMailbox

This function will export a user’s active mailbox and personal archive PST.

The $blockmail variable is collecting the CanonicalName for the user $blockmailuser. This is needed to change the -AcceptMessagesOnlyFromSendersOrMembers parameter within Set-Mailbox.

This foreach loop is completing the following tasks:

• $termed is executing the ConvertToDate function on the user’s Description field. We must do this so we can compare today’s date with the users “TERMED” date.
• If $termed is less than or equal to $purge_date
  • $sam – Collect the user’s SamAccountName
  • $database – Get $sam user’s mailbox
  • If $database.Database equals our $termed_mailbox_db
    • Prevent the user from receiving any new email
    • Create a New-MailboxExportRequest which will export the PST to $archivelocation\$sam.pst
    • If our mailbox has a personal archive
      • Create another New-MailboxExportRequest to export this user’s personal archive to $archivelocation\$sam.archive.pst. We use .archive.pst to differentiate their active mailbox and their archived mailbox. The -IsArchive switch tells PowerShell that we are interested in exporting this user’s Personal Archive.
      • $archive_mailboxes is used for our email logs

Once we’re done with our loop, we fire off the email.

Function: ArchiveHomeDirectory

This function will zip up and move the user’s HomeDirectory. The Home Directory is a property within Active Directory. Common Home Directories are U:\ or \\Share\Users\tuser.

The similarities between this function and ExportMailbox are very similar; however, here we are working with NTFS files and not mailboxes. Instead of using New-MailboxExportRequest, we’re going to use our own function Zip. We use Test-Path to test if the HomeDirectory listed actually exists, and Get-ACL to test for access. If the folder doesn’t exist, or we do not have permissions, we’ll create an error to send to the admin. The zip files are placed within the share you defined earlier.

Halfway there…

At this point we are halfway done. The script has moved the user’s mailboxes, exported their production mailbox and personal archive to PST, and zipped up and moved their home directory. The following functions will check all of our work and make sure a user is ready for removal, and if everything checks out, remove the AD object and HomeDirectory from our file share. Then all we need is a little cleanup and it’s rinse and repeat.

*Deep breath* Okay, continue when ready.

Function: PendingRemoval

This function is going to check all of our work.

While this function may appear quite long and may be daunting, it’s all very basic logic. Has a PST been created? Has the HomeDirectory been backed up? If those two things are true, then set the user as ready for deletion.

Function: RemoveObject

Alright… 213 lines of PowerShell just to get to this moment… The moment we delete the user!

What we’re checking for here is if the users (those in the All Termed Users OU) have “REMOVAL PENDING” as their description. If they do, we’re going to check the users again (functions!) and, if everything pans out, delete the user’s Active Directory account and HomeDirectory from the file share.

Function: LoadModules

This script imports the ActiveDirectory module and adds the Exchange Management Shell snap-in.

If you have read any of my other articles, you have noticed that I always use PowerShell sessions rather than loading modules directly. This is because I want my scripts to work anywhere on the network and have no dependencies on the local machine. However, because we are already having to use a local DLL for this script to function properly, it doesn’t make much since to use remote sessions. Now you’re probably wondering why I have this wrapped up in a function… The reason is that our production script performs basic file moving tasks that don’t require these modules. Because of this, I don’t want the script to waste time loading modules it doesn’t need for certain tasks.

Function: CleanUp

This function will run  San Andres Tuxtla before each of our functions to ensure we keep a nice and clean Exchange environment.

As you can see, we’re heavy on the Exchange commands here. All we’re really trying to do is report any failures that have happened previously. If there is an issue, the user is moved to our All Termed Users (errors) OU. Here an admin can manually audit these users and see if they are ready to be deleted.

Execute the proper function

Now we can tell the script which function to execute.

The $function variable is defined by the user when they execute the script (e.g. .\UserTermination.ps1 -function MoveMailbox). We’ve wrapped this within try {} catch {} finally {} so we can catch any errors. And that’s it for the script!

Now we need to set up some scheduled tasks so this truly requires no interaction.

The Scheduled Tasks

These are the scheduled tasks that you’ll need to set up to really benefit from this script.

Program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Mailbox-Export

• Runs at 7:00 AM every Saturday of every week
• Add Arguments: -noninteractive -nologo C:\scripts\ScheduledTasks\UserTermination.ps1 “ExportMailbox”

Mailbox-HomeDirectory

• Runs at 6:00 PM every Friday of every week
• Add Arguments: -noninteractive -nologo C:\scripts\ScheduledTasks\UserTermination.ps1 “ArchiveHomeDirectory”

Mailbox-Move

• Runs at 8:00 AM every Wednesday of every week
• Add Arguments: -noninteractive -nologo C:\scripts\ScheduledTasks\UserTermination.ps1 “MoveMailbox”

Mailbox-PendingRemoval

• Runs at 8:00 AM every Monday of every week
• Add Arguments: -noninteractive -nologo C:\scripts\ScheduledTasks\UserTermination.ps1 “PendingRemoval”

Mailbox-RemoveObject

• Runs at 5:00 PM every Tuesday of every week
• Add Arguments: -noninteractive -nologo C:\scripts\ScheduledTasks\UserTermination.ps1 “RemoveObject”

All of these must be set to run with the highest privileges, and set to run whether a user is logged on or not.

Structure

Here are some images of what your Active Directory and Scheduled Tasks should look like.

Active Directory

Scheduled Tasks

Conclusion

Assuming you made it all the way down here after reading that mess above, congratulations! If you’re curious about the viability of this script, it has been working in our production environment for just short of a year now. It has processed north of 600 accounts and we have not yet (knock on wood) had a piece of information we were unable to retrieve.

Since the introduction of this script, we have freed up a little over 1TB in Mailbox database space and file share disk space. Those may not be huge returns, but if you’re working with limited resources, every bit helps.

You will probably have some issues along the way. This script was specifically tailored for our environment, but it should work with minimal modification by you.

I hope this is useful to you, and thank you for reading.