Securing information after someone is fired (in HR terms, let go with good reason) is often important, especially if the now-terminated employee is suspected of some form of misconduct. Exchange 2010 and Exchange 2013 offer a range of methods to secure and protect mailbox data but software features are useless unless they are executed properly in a timely manner following a well-documented and tested process. Companies differ in the legal framework within which they operate and the HR procedures that they follow, but here are some general ideas for a starting point for your “mailbox seize and protect” process. I covered some of these points in a post about what should be done when an employee dies. Depending on the kind of situation that forces the departure, the steps to secure information in the mailbox of a leaving employee can more urgent as the person is still capable of accessing their mailbox.
The code listed here works in an Exchange 2013 environment. You need to adjust the ActiveSync cmdlets for Exchange 2010 (the names changed in Exchange 2013) to use Get-ActiveSyncDeviceStatistics etc. Most of the Exchange cmdlets work with Exchange Online too. However, stay tuned for a future article covering how to handle this situation inside Office 365.
First, disable the Windows account. It seems obvious but you do want to stop the employee logging on and gaining access to their data. You can do this pretty quickly through AD Users and Computers, but if you’re scripting the process then the Disable-ADAccount cmdlet comes into its own.
Disable-ADAccount -Identity "CN=Bad Employee,OU=IT,OU=Users,DC=Contoso,DC=COM"
Next, place the mailbox on litigation hold to stop any attempt to remove or edit mailbox items. Exchange caches data to avoid the need to re-establish mailbox connections and you don’t want the employee to be able to use ActiveSync on their mobile device to “clean” their mailbox en route out of the building. Mailboxes can be put on hold using EMC or EAC, but Set-Mailbox is usually faster:
Set-Mailbox –Identity ‘Bad Employee’ –LitigationHoldEnabled $True -RetentionComment "Employee terminated on 1-April-2015"
Mailbox quotas can be reduced to prevent any new messages being sent or received. This stops an employee who is logged onto the mailbox being able to send themselves items that might contain confidential information.
Set-Mailbox –Identity ‘Bad Employee’ –ProhibitSendQuota 0 –ProhibitSendReceiveQuota 0
You can set an autoreply message on the mailbox so that other users know that the person no longer works for the company. The Set-MailboxAutoReplyConfiguration cmdlet allows you to set different text to be sent to internal and external correspondents. A MailTip is also useful in terms of immediately signaling to internal users that the recipient is no longer available.
Set-MailboxAutoReplyConfiguration –Identity ‘Bad Employee’ –InternalMessage ‘Mr. Bad no longer works for us. Talk to HR if you want to know why!” –ExternalMessage ‘Mr. Bad is no longer an employee of this company.” –AutoReplyState Enabled
Set-Mailbox -Identity 'Bad Employee' -MailTip 'Bad Employee has left the building. Don't bother sending email"
A slightly different solution is to add the mailbox to a special “Disabled and Retained Mailboxes” distribution group that is referenced by a transport rule which watches for any message sent to a member of the group and then bounces it with a special non-delivery notification.
New-TransportRule "Block Email to Disabled Mailboxes" -SentToMemberOf "Disabled and Retained Mailboxes" -RejectMessageEnhancedStatusCode "5.7.929" -RejectMessageReasonText "Regretfully the user that you attempted to contact is no longer with Contoso Corporation" -Enabled $True
It's a good idea to hide the mailbox from the GAL and remove them from any distribution group to which they might belong. This is simple good housekeeping and reduces the number of bounced messages that will be generated because the receive quota is set to zero. Remember that it will take a day or two before the update is reflected in the offline address books used by clients. Some like to also change the SMTP address of the mailbox to prevent it being used to address messages.
Set-Mailbox –Identity ‘Bad Employee’ –HiddenFromAddressListsEnabled $True
Moving the mailbox to another database is an effective way of breaking current logons to the mailbox and force clients to reconnect. However, it might take some time for the Mailbox Replication Service (MRS) to move the mailbox, which is why you want to put it on litigation hold first. Some organizations like to use a specific database to hold the mailboxes of ex-employees. This step only applies to on-premises deployments because you can't invoke a mailbox move within Office 365.
New-MoveRequest –Identity ‘Bad Employee’ -TargetDatabase DisabledMailboxesDB
You should enable mailbox auditing on the mailbox so that any and all activity will be tracked. As the Windows account is disabled, you should only need to audit delegate and admin access, but the choice is yours to configure auditing in an appropriate manner.
Set-Mailbox –Identity ‘Bad Employee’ –AuditEnabled $True
Use the Clear-MobileDevice cmdlet (Exchange 2013) or Clear-ActiveSyncDevice cmdlet (Exchange 2010 or Exchange 2013) to send a remote wipe command to all of the ActiveSync devices registered for the mailbox. That is, of course, unless you have seized all mobile devices that they have used to connect to Exchange.
Get-MobileDevice –Mailbox 'Bad Employee' | Clear-MobileDevice
Remove the partnerships for the ActiveSync (EAS) devices that are allowed to connect to the mailbox and remove the ability of devices to connect to the mailbox via EAS. If you have a mobile device access policy in place that quarantines new devices, this step will prevent any attempt to use a device to connect to the mailbox because the device will be forced to resynchronize. However, because EAS does not check the ActiveSyncEnabled setting for a user at each connect, to be sure that the user cannot get to their mailbox, we first have to discover the device identifier for each device that they might use and add those identifiers to the list of blocked devices. EAS checks device ids on an ongoing basis to validate that new devices are allowed to connect, so this approach provides a more immediate block. Note that the "Device1ID", "Device2ID", etc. used here are placeholders for the actual device identifiers.
Get-MobileDeviceStatistics -Mailbox 'Bad Employee' | Select DeviceType, DeviceID
Set-CASMailbox -Identity 'Bad Employee' -ActiveSyncBlockedDeviceIDs Device1ID, Device2ID, Device3ID –ActiveSyncAllowedDevices $Null –ActiveSyncEnabled $False
Get-MobileDevice –Mailbox 'Bad Employee' | Remove-MobileDevice
To complete the block, you might also want to use Set-CASMailbox to disable the other client access protocols. This command also blocks access via OWA for Devices. The Outlook apps are blocked through ActiveSync.
Set-CASMailbox –Identity ‘Bad Employee’ –EWSEnabled $False –IMAPEnabled $False –POPEnabled $False -MAPIEnabled $False –OWAEnabled $False -OWAForDevicesEnabled $False -EWSAllowMacOutlook $False -EWSAllowOutlook $False -EWSAllowEntourage $False -MAPIBlockOutlookRpcHttp $True -ECPEnabled $False
Remember that Exchange caches information to ensure best performance so some of these steps might not be immediately effective. As mentioned above, in an on-premises deployment, you can move the mailbox to another server to force any current sessions to disconnect. Alternatively, you can either perform an IIS RESET on the CAS servers to which suspect clients might connect or recycle a specific IIS application pools for a protocol (OWA, EAS, etc.) to flush any cached password tokens. Playing with IIS is likely to affect other users so it's not something to do without thinking. Unfortunately, unless you run a hybrid setup and can move a mailbox between on-premises and cloud or vice versa, you don't have the same levers to pull to control client connectivity if you are an Office 365 tenant.
Eventually, after everything settles down, you can decide to keep the mailbox for the long term or export it to a PST. I absolutely recommend avoiding using a PST whenever possible because once you export information from Exchange, you run the risk that it will be lost from view for eDiscovery searches if you subsequently decide to delete the mailbox.
There's a lot of things you can do to prevent a discharged employee removing data and the best idea is to figure out what approach works best for your organization and then create a script to automate the job using the suggestions provided above as guidelines.
The important thing is to have a plan that is thought through and tested before someone from HR or legal comes into your office to demand that a mailbox is secured. Some up-front work will solve the problem and make these kind of requests so much easier to handle.
Follow Tony @12Knocksinna
