Disclaimer: This post was made possible by Steve Marcolla, Application Support Engineer at VMware AirWatch. His insight and suggestion into this migration are very much appreciated!
I recently finished migrating my SEG classic to V2, and of course, I documented the steps via the post below for the benefit of the AirWatch community.
Steps to migrate Secure Email Gateway (SEG) from Classic Platform to the V2 Platform
If you have Kerberos Constrained Delegation (KCD) implemented with your SEG, the steps should be more or less the same with a few key differences to remember.
While chapter 5 of the Kerberos Constrained Delegation Authentication for SEG V2 guide describes the steps needed to upgrade from classic to V2, in my opinion, it’s far from complete. VMware technical support (not Steve Marcolla) even advised me to acquire professional services to ensure this upgrade is successful.
Technical support (again not Steve Marcolla) also refers me to the link below, but I am quite certain this won’t work for SEG configured with KCD as the later has a different set of requirements.
Best Practices When Migrating from SEG Classic to SEG v2
You may also want to review the link below as well to fully understand the changes with SEG V2.
Changes to KCD Deployments for SEG V2
Here’s a better screenshot of the Advanced Configuration.
Now come the comments and suggestions from Steve Marcolla:
“Same steps. Thankfully the SEG config handles the setup for KCD, so no need to look for IIS settings to configure. You would need to make sure though that you have KCD enabled in the SEG MEM Config and advanced settings as appropriate before you download the installer so that it downloads the KCD package with the installer!”
“And yeah KCD can be daunting. Thankfully SEG V2 makes it a little easier.
Pretty much a good heuristic for the account(s) requirements are:
- If you have multiple CAS servers, you need to use an ASA account to represent the CAS array (even if exchange version is 2016 where there’s no longer the idea of a CAS array).
- If SEG is not on the same domain as the Domain Controller (and Exchange), then you need a service account on the domain controller’s domain to use to reach out to the domain controller to grab the Kerberos tokens.
The other most-handy tests are the connections from SEG to DC and back over port 88, and from SEG to CA and back over port 80 (and SEG to CRL over 80), and SEG to Exchange and back over 443.
Then all the fun with making sure the service accounts and SPNs are set up properly, the authentication settings in IIS on Exchange, etc.
Certainly lots of fun… really more of a test in patience than anything else haha.”