Exchange migration requires a service restart on SEG server?

[btrabue]

Hello -

We are currently at the first stages of migrating over mailboxes from Exchange 2010 to 2016.  During our testing we are finding out that if we start off with a test mailbox in 2010 on an iPhone and migrate it over to 2016 that generally email will not sync with the iPhone till the following morning.  If we test with an account created in Exchange 2016 then it will sync immediately on the iPhone.  Just found out this evening that if I restart the World Wide Web Publishing service on the SEG server that it will get the iPhone to sync email immediately.  Why is it doing this?  Is there any other way to get the email to sync after the migration other than needing to restart the service?  We will be migrating users each night for several weeks and the need to restart the service on the SEG server seems crazy.  Has anyone else experienced this and were able to resolve it?  Thanks for your help!

[LukeDC · Accepted solution]

Probably had to do with sessions. Sounds like the devices have open sessions on the old server. By restarting IIS you are closing all sessions and they reconnect.

[btrabue]

Thanks Luke!  Looks like we will be busy restarting the service for a while until the Exchange team completes the migration. 

[SteveMorganStev]

We are just about to do this very same thing. Exc 2010 to 2016. How exactly did you go about it with the SEG's? We currently have 2 SEG v2's in each region clustered. Is it possible to break the cluster and have 1 pointing to 2010 and the other to 2016 using the same single external dns of SEG or do you need a brand new one?

[ChrisHuhnChrisH]

>> using the same single external dns of SEG or do you need a brand new one?
We have 2010 SEG and 2016 SEG with separate external names, made Smartgroup for each.
When we start as people are being migrated, the LAN group membership changes - the Smartgroup follows, and the Mail profile is ripped and replaced.
User impact is this; enter Exchange Mail password for new profile on device.
... unless someone has a better idea.

[SteveMorganStev]

Hmmm was really hoping to avoid having to get new public IP's with a new external address.
At the moment I'm getting conflicting info from VmWare regarding this topic and I can't find any KB on the subject.
We use KCD so I am hoping this will make it fairly seamless when migrating the users.

[LukeDC]

Since you'll need a new MEM config and a SEG can only run on one config at a time, you're kind of stuck having to use separate SEG's.

[LukeDC]

Yes, cert auth will make it really easy, they will still get ripped and replaced, but it should auto populate everything back for them in your case.

[ChrisHuhnChrisH]

Sadly we came to that conclusion during AirWatch build in November 2017.

[LukeDC]

Also, not sure if it is really doable, but you might be able to get away with using a different port other than 443 and let your load balancer forward to the SEG based on port number at the same hostname etc. Never tried it, but theoretically sounds like it could work.

[ChrisHuhnChrisH]

While that solution is technically usable, our Network Team would not find it so cool. Port Mapping a few years resulted in a severe outage on another system.

[SteveMorganStev]

OK thanks. We already have 2 SEG's in each DTC so not a massive issue to break the cluster and point one to Ex2010 and the other to Ex2016.
Yep aware the mailbox will be refreshed same as re-pushing the MEM profile but as you say will just pre-populate again without any user interaction.
Not sure about that personally. May be safer just to go through the pain of another public IP and external DNS. In which case we might as well create 2 brand new SEG's and start afresh.

[ChrisHuhnChrisH]

A thought, if the original SEG is set for Exchange 2010, and an Exchange 2016 ActiveSync server answers - will email delivery continue?
Or does Exchange 2016 REQUIRE a SEG configured for 2016?
Another way to ask, will a SEG Exchange 2010 profile work on a 2016 Exchange server?

[btrabue]

Chris H - We were told by AirWatch that the SEG should stay at pointing to 2010 until all of the accounts are migrated over to the new Exchange server.  We have not done the migration yet but this is what we plan on doing when the time comes.

[Jon_754]

Interesting Brian T/Chris H.
We're going to be going into 2010/2016 co-existence this week. We're leaving mailboxes on the Ex2010 MB servers until a later date. We were told by support to proxy all connections through the new 2016 servers, in other words, rerun the SEG setup and point the SEGs at 2016.

Another thought, if we can host file our SEGs, in effect pinning the SEGs to the 2010 CAS array.  Once swing the internal namespace/DNS to point mail.ourorg.com from the 2010 CAS array to the 2016 MBX servers, the SEGs should never know the changes were made on an Exchange org level.  Does that sound right?

[ChrisHuhnChrisH]

Thanks Bryan T.  I am already following that path as our Exchange Admin does testing.

[Jon_754]

FWIW, We moved forward with host filing our 2010 SEGs to point to our 2010 CAS array successfully.  We stood up an additional LB set of 2016 SEGs and let those use internal DNS to reach the 2016 FE services on the 2016 Exchange servers.

This has worked beautifully.  Once we change the user's Assignment Group, to trigger them to receive the ' 2016'  profile containing the new MEM config, the user sees mail disappear, is prompted for credentials, then mailflow is resumed to their device.

[mkoss]

We are currently in the process of migrating from Exchange 2010 to 2016. Right now we have SEG configured for Exchange 2010. Support is telling me that I will need to build out a new SEG server and run the SEG installer configured for Exchange 2016? Does this sound right, or is there a simpler approach to make this work to allow 2010 and 2016 mailboxes to coexist until we can get all mailboxes moved to 2016?

[SteveMorganStev]

Yes they are right...You have to build all new SEG servers that specifically point to Exchange 2016. Then of course you'll need new Public IP's, certificates etc.
I am just doing the same thing now. I'm also having to build new ENS v2 servers as ENS v1 does not support Exchange 2016. That's 12 new servers for our environment just for Exchange 2016. Fun!

[mikemeiter]

We are wrapping up our migration from 2010 to 2016.  Prior to migration set the SEGS to work with 21016.  Then ensure the SEGS are configured to point to the 2016 active sync front end.  Should be that simple.  Moves from 2010 to 2016 should be  imperceptible to the user with regards active sync.  This of course assumes your 2016 / 2010 environment is configured properly so that 2016 proxy’s the active sync traffic to 2010 exchange.