Friday, August 7, 2015

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?







No comments:

Post a Comment