Deprovisioning and Litigation Hold

Question

We're working on migrating to Office 365, and have a few questions.

We use Ad Sync to sync our users and groups to Office 365. Part of our Deprovisioning needs to include putting the mail box on Litigation hold for 60/90 days first before removing the user.

Deprovising the user will just move the user to an OU that isn't part of the Sync to Office 365, then at the next sync interval, Office 365 will remove that user from the cloud.

So I read that: •The Litigation Hold setting may take up to 60 minutes to take effect.

And my Ad Sync happens every 30 minutes.

So my questions are, If I deprovision a user, will there be a timing issue here? Will the user be moved and mailbox cleaned up before Litigation Hold ever takes affect?

Comments

I guess the same question goes for Created users.

I did a test to see what happens with a New User if I decided to License them right away in the Business Rule after creation. It creates the use in Office 365 so the user is (in the cloud) vs AD Sync.

So I guess if I want to license them, then I'll need to wait until AD Sync then it'll be done the way I want. So definately a timing issue here.

---

Okay, a few clarifiations for this also.

We use AAD Connect from On-Prem AD to Office 365

We have no On-prem exchange, ALL in Office 365.

Answer 1

Hello,

Deprovisioned Users
That's a question more to Microsoft Support than to us, because it is not quite clear as to what the setting may take up to 60 minutes to take effect wording means. On Adaxes part, as soon as you enable Litigation Hold for a mailbox, Adaxes sets the LitigationHoldEnabled attribute of the mailbox to TRUE via PowerShell. Everything else is done by Exchange. We didn't test such a scenario, but from our point of view, a safer approach would be to leave the users within the AAD Scope, but block their access to Office 365 services.

New Users

if I decided to License them right away in the Business Rule after creation. It creates the use in Office 365 so the user is (in the cloud) vs AD Sync.So I guess if I want to license them, then I'll need to wait until AD Sync then it'll be done the way I want.

No, there is no need to wait, you cn license them right away. The users will indeed be created as cloud-only accounts, but during the 1st sync after the account creation, AAD Sync will link the cloud and on-premises accounts. After that, the account status will change to Synced with Active Directory.

Comments

Ok, the new user portion works as you said, I just needed to wait a little, makes sense.

But with the Litigation hold, I wasn't able to get that to work. I made a new Deprovision custom command for this with the basics. Am I missing something?

and the result was: {The recipient doesn't have neither a mailbox nor an e-mail address}

The user does have a Office 365 Enterprise E3 License with Exchange Online (2) enabled. And I went in and checked that it had a mailbox in Exhange with proper email addresses assigned.

---

Hello,

We tested your Custom Command in our environment, and everything worked perfectly.

The user does have a Office 365 Enterprise E3 License with Exchange Online (2) enabled. And I went in and checked that it had a mailbox in Exhange with proper email addresses assigned.

What about the user's Office 365 and Exchange Properties in Adaxes? Can you view them?

---

Hello,

We tested your Custom Command in our environment, and everything worked perfectly.

The user does have a Office 365 Enterprise E3 License with Exchange Online (2) enabled. And I went in and checked that it had a mailbox in Exhange with proper email addresses assigned.

What about the user's Office 365 and Exchange Properties in Adaxes? Can you view them?

Yes, I can! Didn't even think about checking the web interface. And through the interface, I was able to enable litigation hold. Also, I confirmed it through Powershell.

However, now clicking through trying some things out, now I get an error in the web interface:

Connecting to remote server failed with the following error message : The SSL connection cannot be established. Verify that the service on the remote host is properly configured to listen for HTTPS requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig -transport:https". For more information, see the about_Remote_Troubleshooting Help topic.

However, just checked for outages on exchange, maybe that error is due to this?

---

However, just checked for outages on exchange, maybe that error is due to this?

Yes, that's possible. Try re-checking the things after the ticket is closed by Microsoft or using a different Office 365 administrator account in your tenant settings.

---

Okay, an update on this.

NOT THE ISSUE: Microsoft's issue listed here previously was not the issue unfortuanately.

I believe I had found the issue though! Fingers crossed, will be sure tomorow if not..

Back Story:

The Adaxes server lives on our network behind a proxy server. When first setting up Adaxes to use with Office 365 and trying to attach the Tenant, I had issues because the user could not get out. Why? Becauces the service user I was using did not have the proxy settings group policy setting (IE Proxy). So once I added that, I was able to connect to the tenant. From there on, adding users to Office 365 worked great as well. BUT not the Exchange settings, it only worked sometimes.

So once I remembered that connecting the Tenant was a Proxy issue, I started digging in that direction. One thing that was weird was that I would open up Powershell and try to connect to Exchange Online, and it was failing too. So It's just not a Adaxes thing, but something else. So, why do some non powershell to Office 365 work, and others (Exchange Online) don't?

Well, my theory here is that some use the IE Proxy settings, others (Exchange Online) use WINHTTP proxy settings.

My Adaxes server had WINHTTP settings of "Direct Access" in other words, Direct to the firewall, skip the proxy server. The firewall trusts any traffic through the proxy server, so it will let that traffic through. So by going directly to the firewall it would be blocked, unless that firewall has a specific rule to allow that traffic. Which it my case I think it would work sometimes based on what DNS returned for Outlool.Office365.com. I believe our Skype rule was letting it through, if we got lucky and it returned an IP that was in that rule.

WHAT Fixed this: Setting the WINTTP settings for the Adaxes server to point to the Proxy. Just incase others run into this and want to verify or set the WINHTTP proxy, it's done like this:

Show me the settings: netsh winhttp show proxy

Set the proxy: netsh winhttp set proxy {proxy address}

---

IE Proxy settings, or (Exchange Online) WINHTTP address in the last step you mentioned.