When running a full hybrid with Exchange on-premise and Exchange online, what options are there for maintaining Airwatch enrollment and protecting access to corporate email?
We currently have SEG servers in place with Exchange on-premise only.
If we move to a full hybrid scenario I mentioned above, how do you utilize the same protection the SEG server offers after a users mailbox is migrated to Exchange online?
I would prefer to avoid having all ActiveSync traffic continue to depend on the Exchange on-premise servers for mailboxes that have been moved to Exchange online.
Is there a way to configure Airwatch to maybe use the SEG servers for mailboxes that still live on-premise but deploy a different profile that maybe uses the newer Powershell method and have the people whose mailboxes were moved access them directly via Exchange online and still be protected?
I'm trying to understand my options here.
Have you opened a support ticket with VMware? We are in the same boat migrating all on-premises mailboxes to the cloud by year end.
I'm not an Exchange expert by any mean, but I do have a few ideas in mind:
Did you guys get this resolved? I'm in the same boat, trying to get this sorted.
We have yet to finalize our setup and begin our migration. What stage are you in at the moment?
We have an on-prem 2016 server providing hybrid services to O365. We created a new SEG v2 server and have it pointed at the new on-prem server, but activesync is giving us credential issues for an O365 account synced to that server. I'm planning to pull activesync logs tomorrow, but I figured if someone else had already done it, I wouldn't be reinventing the wheel.
Gotcha. In my case, we still leverage SEG for the native mail client with on-premises mailboxes. We also rolled out the Outlook mobile app which first authenticates through Azure before it redirects to WS1 Access for further authentication. Our goal is to move all on-premises mailboxes to O365 and get rid of the SEG altogether.
Folks, just wanted to follow up on this. Our issue was directly related to TLS version mismatches on our servers. I ended up pointing SegV2 at our Exchange2010 environment versus the 2016 server. I also had to force TLS 1.1, as 1.2 would not work no matter what I did. Once I did that, everything worked exactly as expected. We've been up for about a month with no issues.
If you run into similar issues, I recommend trying to enable TLS 1.0 first to see if it resolves it. If it does, you're also having a TLS mismatch and can focus on that. Below is from support on how to enable or disable different TLS versions.
---
It is not necessary to enable it explicitly. I would like to test enable TLS 1.0 on SEGv2, as seems Exchange has it enable as well. Please save a copy of this file: segServiceWrapper.conf previous to edit it:
Property 1:
wrapper.java.additional.9=-Djdk.tls.disabledAlgorithms=MD5\, RC4\, TLSv1\, SSLv2Hello\, SSLv3\, DSA\, DESede\, DES\, 3DES\, DES40_CBC\, RC4_40\, MD5withRSA\, DH\, 3DES_EDE_CBC\, DHE\, DH keySize < 1024\, EC keySize < 224
set this property as: (Removing TLSv1 from the disabled list)
wrapper.java.additional.9=-Djdk.tls.disabledAlgorithms=MD5\, RC4\, SSLv2Hello\, SSLv3\, DSA\, DESede\, DES\, 3DES\, DES40_CBC\, RC4_40\, MD5withRSA\, DH\, 3DES_EDE_CBC\, DHE\, DH keySize < 1024\, EC keySize < 224
Property 2:
wrapper.java.additional.12=-Dhttps.protocols=TLSv1.1\,TLSv1.2
set this property as:
wrapper.java.additional.12=-Dhttps.protocols= TLSv1\,TLSv1.1\,TLSv1.2