Echange 2010 Hybrid to 2019 Hybrid

[Planehazza]

So without going into details, our 2010 Mbx server is dead and irrecoverable. CAS is OK.

 

We wanted to go to 2019 on a single server anyway so now is as good a time as any. Due to the reasons for why Mbx is dead, we'd rather just keep our 2010 CAS off the network and configure a 2019 server to serve as the new on prem hybrid box from scratch.

 

We have the necessary schema and functional level, so whilst it probably isn't the best way to do it, can I safely just create a new Exchange 2019 setup and reconfigure the hybrid config from scratch, all with the existing exchange set up offline? Obviously I'll need to adjust internal DNS to point to the new box, and thankfully all users are in the cloud now anyway so losing the mbx server was not a disaster.

 

How does licensing work for 2019 with hybrid? We pay for Exchange Enterprise yearly; is this still valid for 2019 hybrid?

 

We do not use Azure to host our AD; instead we used AADC on a DC to sync on prem AD to 365. Given this, I assume that a hybrid setup is in fact still the best method? We're not looking to move to cloud based AD any time soon.

 

Thanks!

 

EDIT: nope, our domain and forest functional levels are 2008 R2, which, in fried brain hindsight, makes sense as we have 2008 R2 servers in places. Time to rebuild them and get our functional level forward two decades...

Edited May 5, 2020 by Planehazza

[Passat1983ICTech]

ware looking to do this but mailbox are on site not in the cloud need jump to server 2016 or go to 2019

[chaplic]

Why do you need hybrid at all if no mailboxes on prem?

 

If you want the comfort of having an on prem exchange server to do the microsoft approved user attribute changes, it doesn't have to be in hybrid. Or you could live a little, do without exchange on prem completely, and just modify on prem Ad directly.

 

to answer your question directly, my lab has a similar setup with no issues.

[Planehazza]

Why do you need hybrid at all if no mailboxes on prem?

 

If you want the comfort of having an on prem exchange server to do the microsoft approved user attribute changes, it doesn't have to be in hybrid. Or you could live a little, do without exchange on prem completely, and just modify on prem Ad directly.

 

to answer your question directly, my lab has a similar setup with no issues.

 

It's all still a little over my head, but essentially we still have a lot of devices/local servers that require mail flow such as copiers, firewall etc.

 

Short version, the comfort level I'm at is that I'd prefer to keep a single, lightweight 2016/9 exchange server onprem do handle the AD syncing to 365 for mailboxes etc. The problem I've got is that our 2010 CAS server is fine, but the separate MBX server is dead. It's not recoverable; without going in to too much details, a ransomware attack has rendered this server useless, as well as its backup.

 

My current thought process is around two options. Install MBX role on the 2010 CAS server, and in place upgrade it to 2013. Then, install exchange 2019 on a 2019 server, reconfigure hybrid via HCW and update all the DNS settings etc. Or do I just spin up a 2016 server and install exchange 2016 which can coexist with 2010. Then, run HCW again and decommission the 2010 server. Right now, I don't know what the repercussions of losing just the 2010 mbx server are yet.

Edited May 6, 2020 by Planehazza

[chaplic]

Having an Exchange server as a outgoing SMTP relay, and to be a admin webpage for email stuff is not a bad thing, still doesn't need hybrid. You need hybrid if you ever plan or want the ability to have mailboxes on premise with good interoperability with O365

 

To your question, apart from the databases and certs, the config for Exchange is held in AD, so if you want you can install a new server with the same name and EXACT same config (drive letters, install paths) POW you have your 2010MBX server back (no databases obviously). Equally to nuke your mailbox from existence you'll have to remove stuff from AD.

 

However, I'm still struggling to understand what you are missing from the dead server? a mailbox server with no mailboxes? or does the mailbox server do hub transport duties too?

[Planehazza]

Having an Exchange server as a outgoing SMTP relay, and to be a admin webpage for email stuff is not a bad thing, still doesn't need hybrid. You need hybrid if you ever plan or want the ability to have mailboxes on premise with good interoperability with O365

 

To your question, apart from the databases and certs, the config for Exchange is held in AD, so if you want you can install a new server with the same name and EXACT same config (drive letters, install paths) POW you have your 2010MBX server back (no databases obviously). Equally to nuke your mailbox from existence you'll have to remove stuff from AD.

 

However, I'm still struggling to understand what you are missing from the dead server? a mailbox server with no mailboxes? or does the mailbox server do hub transport duties too?

 

In bold, that's it right there. We will need a handful of on prem mailboxes, albeit very few.

 

Regarding your second paragraph, that's precisely what I did last night. New (ha!) 2008R2 SP1 Ent server deployed, and exchange 2010 installed via setup /m:recoverserver. Worked flawlessly once I'd installed the few KB updates that I'd missed. Of course, this obviously cannot and will not restore broken or lost databases, but thankfully the <100 on premises mailboxes were either inconsequential or destined for deletion (both in most cases) anyway.

 

I don't need hybrid for this, rather the opposite, in that because we're using hybrid I need to keep an OnPrem server for the creation of new mailboxes prior to migrating them online.

 

Like you say, we could do away with hybrid and rely on send connectors alone but that's for another time. The priority currently is restoring all lost services and at least getting the existing onprem exchange working again for now.

 

Nothing missing from the dead server really. I probably could have just installed the mailbox role into the CAS server and been done with it, but I was more comfortable quickly knocking up a new server to replicate the old setup. The plan now is to get those in place upgraded to 2013 so I can deploy a replacement 2019 server.

 

If I'm getting this wrong, I'm not trying to sound stupid; I don't need any help with that ha. Exchange is something I inherited and so am a little thin in experience and technical know how. I'm finding my feet with more than just managing it as I go.

Edited May 7, 2020 by Planehazza

[PyROm]

If you have no on premises mailboxes you can use exchange server 2016 for free without licensing (it auto licenses itself when setting up hybrid). Exchange 2019 is not free though.

[PyROm]

I think you are creating local mailboxes first, then moving them to the cloud because they dont properly link with your AD accounts if you dont? The way around this is to set the remote routing address in AD, this way your create the AD user, set the remote routing address to your tenants mail address e.g. [email protected] (we use powershell) and assign licenses. When the user logs into exchange online it creates their mailbox for them and it is properly tied to their ad account.

[mdrabble]

Spec for 2019 are quite high - as I was going to move from a Hybrid Exch 2013 to Exch 2019 but due to specs moved to Exch 2016 instead.

 

Memory Varies by Exchange server role:

• Mailbox: 128 GB minimum recommended

• Edge Transport: 64 GB minimum recommended.

 

https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/system-requirements?view=exchserver-2019

[Planehazza]

I think you are creating local mailboxes first, then moving them to the cloud because they dont properly link with your AD accounts if you dont? The way around this is to set the remote routing address in AD, this way your create the AD user, set the remote routing address to your tenants mail address e.g. [email protected] (we use powershell) and assign licenses. When the user logs into exchange online it creates their mailbox for them and it is properly tied to their ad account.

 

Yeah I've thought about this in the past, but I was still under the impression an on prem server exchange was required to manage AD attributes, such as aliases etc?

 

Our rerouting address is already configured: [email protected], and this is configured on Exchange via a Email Address policy automatically for staff/student based on an attribute set on their AD object. So, yeah I guess this could be done in AD without exchange, surely there's a lot more to the need of an onprem server than just this?

 

Spec for 2019 are quite high - as I was going to move from a Hybrid Exch 2013 to Exch 2019 but due to specs moved to Exch 2016 instead.

 

Memory Varies by Exchange server role:

• Mailbox: 128 GB minimum recommended

• Edge Transport: 64 GB minimum recommended.

 

https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/system-requirements?view=exchserver-2019

Yeah we were quite shocked at that too, but I assume those high memory requirements assume the server is running as a full on onprem exchange server with hundreds of mailboxes, which isn't the case with 365.

Edited May 7, 2020 by Planehazza

[chaplic]

I think you are creating local mailboxes first, then moving them to the cloud because they dont properly link with your AD accounts if you dont? The way around this is to set the remote routing address in AD, this way your create the AD user, set the remote routing address to your tenants mail address e.g. [email protected] (we use powershell) and assign licenses. When the user logs into exchange online it creates their mailbox for them and it is properly tied to their ad account.

 

 

That'll work, but if you do have people on prem they won't see that user having a mailbox. You want enable-remotemailbox -remoteroutingaddess [email protected] .This creates all the necessary attributes on the account and creates a mailbox in O365, assuming licensed.

 

It's worthwhile before you do it, get the full properties of an AD account get-aduser blah -properties * then do it afterwards. Youll see the enable-remotemailbox just adds a pile of values into things like MsExchRemoteRecipientType