Exchange Online and Remotely Terminated Employees

So as you know my company recently (Feb) migrated to Exchange Online and one thing we did not think to ask about during that really hurried and busy time period was how to immediately sever email communications with remote employees when they are terminated.

What I've been hearing today is that our practice of firing people without having either them come into an office or an employee (likely HR) travelling to them.  Do things like collect hardware, deal with exit interviews, company property, outstanding expense reports, etc.

We actually fire people via phone calls, and hope they want their last check bad enough to ship in all the company property AND to not do anything stupid.  Well it happened yesterday.
We apparently fired a person who 8 hours later sent out some emails under his company account.


Many folks blew a virtual gasket.. then of course flooded IT with questions: How did he do that? Why was his access not cut off?, etc, etc..

Well to answer that we have a procedure that worked perfectly pre-migration that consisted of
running a powershell script that I developed two years ago that performed the following

1. Changed the domain user password
2. Disabled the domain account
3. Changed the description field to term the exact time/date of termination
4. Hid the user from the GAL
5. And moved the user object into a Disabled Users OU

All of that took care of the issue because once the domain account was disabled any VPN session were terminated. Disabled user account and changed password meant no OWA access either.

Now, however, once all of that is done if the user keeps outlook open their session lives on for up to 10 hours.  That's how this latest guy was able to send email.

So it turns out that we have protections in place for mobile devices, however the way our local domain info syncs to the parent company which in turn syncs to Microsoft is rather convoluted IMO.

We use PCNS to sync AD credentials.. which is good except password changes are synced in almost real time.  Account changes though can take anywhere up to 6 hours. So while we can change their password, if they keep Outlook open their current session will keep working for 10 hours or so before checking to see that the password has changed in order to prompt the user to input the new password.  Or before it determine the account is disabled which then makes Outlook cough and sputter.

So how to fix this?

I/We played with settings such as disabling MAPI, OWA, Activesync via ECP but those seem to need Outlook (or the device) to be restarted before the change takes affect.. or 10 hours passes in the case of Outlook.

What we eventually determined was that changing the MaxSendSize to 0 takes roughly 10 minutes. You could change the RecieveSize too just to be safe.

This is our fix until the company decides to either bring the term into an office or send a representative to them.

Win?

Upgrading forest functional level, and DFS mode

So today I ran into a small issue.. I noticed that it seems that computer tombstoning is not happening as I have multiple computer objects with lastLogonTimestamps of 2012...

In pursuing further I discovered that I don't have the AD Recycle Bin because we're still running at a Forest Functional Level of 2003.  Gotta fix that!  Except WHOA.. we use DFS and it's stuck at a 2000 mode.
I go looking and Microsoft graciously did not craft an upgrade for DFS, so it looks like the only way to upgrade my forest level and keep a functioning DFS is to upgrade them both.

Raising the forest functional level is easy and fast.

Open the Active Directory Administrative Center
Right-Click on your domain
Choose raise your Forest functional level

Easy peasey.

Now 'upgrading' your DFS mode take a little more work.


First you're going to want to backup your existing DFS configuration, run the following from one of your domain controllers:

dfsutil root export \\<domain.fqdn>\<Namespace> %temp%\namespace_backup.xml

Next you are going to remove your old namespace..  open your DFS Management snap-in and remove your namespace servers. That's it.

Now in this step you will be creating a 'new' namespace however you will keep the original names.  If your original namespace was "consoso.com\Public" then create the new one using that name.  Except during the creation make sure the box for 2008-mode is checked. Also it hurts nothing to leave the DFS Share from the default "C:\%systemroot%\DFSRoots"

Make sure you add all the same namespace servers you had before as well..

Lastly you will import your old config via:

dfsutil root import merge %temp%\namespace_backup.xml \\<domain.fqdn>\<Namespace>