Adding an Employee ID Number to Active Directory

Filed in Active Directory, PowerShell

The Active Directory database contains two fields that can be used to store an employee ID number:

  • EmployeeID
  • EmployeeNumber

Neither field is used for anything currently, and neither one shows up in Active Directory Users & Computers or Active Directory Administrative Center by default. ADUC can be modified to display one or both of the two available fields (See here for example), but I don’t think ADAC can.

I created a simple PowerShell Script for the help desk to use to update this field. It accepts two parameters: 1) a username and 2) an employee ID number. If either is omitted, it will prompt the user to enter it.

# Param specifies the command-line parameters. The first
# parameter is the username. The second is the employee ID.
# The HelpMessage property contains text to be displayed 
# if the user types !? at the prompt.
# The ValidateLength attribute specifies a minimum and max
# length for the EID parameter.
        HelpMessage="Enter a complete Username."
        HelpMessage="Enter a 7-digit employee ID number."

# Loads the AD PowerShell module.
if (-not(Get-Module ActiveDirectory)) `
    {Import-Module ActiveDirectory}

# Set the EmployeeID property if the user object exists.
If(Get-ADUser -Identity $Identity) {
    Set-ADUser -Identity $Identity -Server DC05 `
        -EmployeeID $EID
    Get-ADUser -Identity $Identity -Server DC05 `
        -Properties EmployeeID | Format-List `
        UserPrincipalName, EmployeeID

Be careful with the employeeID and employeeNumber properties. They aren’t displayed anywhere by default, but they’re not hidden either. Anyone with access via LDAP, ADUC, etc., can see these values. Don’t use them to store social security numbers or other sensitive information.

Click to view/hide

Assign the value of ObjectGUID to a string variable in Powershell

Filed in Active Directory, PowerShell

The ObjectGUID property of an AD object is weird. I tried using -Expand and foreach{$_.ObjectGUID} to extract the value, but neither did quite what I expected. Here’s how I was able to get the value of that property into a string variable that I could then use for something useful.

$uGuid = (Get-ADUser <username> | Select -Expand ObjectGUID).toString()

The value of $uGuid will be the string value of ObjectGUID and not the System.Object Guid or System.Object objectguid.

Click to view/hide

Get a List of Mailbox Folders Sorted by Size

Filed in Microsoft Exchange 2010, Microsoft Exchange 2013, PowerShell

It doesn’t matter if an end user gets so much email that it’s impossible to manage, gets a lot of really important email that can’t be deleted, or is just really bad at managing their stuff, many end users will always complain about not having enough storage space for their mailbox. We all know the standard instructions: Configure auto-archiving or online archiving, save attachments separately and remove them from the original messages, etc. But generally it usually comes down to one real solution: delete large and unneeded emails.

“But how do I find the large emails?”

Outlook has some great built-in search features that let you find all emails over a certain size, and that’s a great answer for some users. Other users are on a Mac. In my opinion, there are no good answers for them except to run Outlook 2013 in Parallels. Outlook 2011 and Mac Mail are far too error prone and unstable to be a reliable Exchange client. Here’s one thing that can really help those Mac users–and even PC users–focus their mailbox cleanup efforts.

You can run this script from the Exchange Management Shell and tell them exactly which folder contains the lion’s share of email. Save it as “Get_Folders.ps1″ (or whatever you want to call it) under C:\Windows\system32\WindowsPowerShell\v1.0> and enter it with a mailbox name as a command line switch. If you enter it without a mailbox name, it will remind you and give you some instructions.

if (($Username -eq $Null) -or ($Username -eq "")) {
     [console]::ForegroundColor = "yellow"
     write-host " "
     write-host "Syntax: Get_Folders <username>"
     write-host " "
     write-host "Username can be an alias, primary SMTP, UPN, etc."
     write-host " "
     [console]::ForegroundColor = "white"

Get-MailboxFolderStatistics $Username | sort-object `
     foldersize -descending | ft folderpath, foldersize, `
     itemsinfolder -autosize

The output will look something like this:

FolderPath             FolderSize                   ItemsInFolder
----------             ----------                   -------------
/Inbox/Stupid stuff    1.115 GB (1,196,735,329 bytes)       14471
/Inbox                 196.2 MB (205,723,806 bytes)          4491
/Deleted Items         133.8 MB (140,254,956 bytes)          2095
/Sent Items            111.8 MB (117,249,782 bytes)          1929
/Deletions             62.59 MB (65,627,090 bytes)           1640
/Conversation History  42.14 MB (44,182,985 bytes)            977
/Calendar              9.079 MB (9,520,300 bytes)             417

From this you can tell the user that either they should probably take a look at that “Stupid Stuff” subfolder under the Inbox. There might be a few items there that they could stand to delete.

Click to view/hide
Click to view/hide