Advice on Exchange 2016 - Hybrid on Server 2012 R2

[Gobstopper]

Hi all,

 

I am looking for a bit of advice, I recently inherited a school network that is currently using Exchange 2016 on Server 2012 R2 in a hybrid configuration.

 

I can do the day to day stuff in Exchange and am comfortable with the powershell side of it but admittedly I am a tad inexperienced with Exchange, all of my previous schools have had their mail solution completely cloud driven, most moved from RM Easymail straight to Google Workspace or Office 365. This is the first school I have worked in that has Exchange on-prem in hybrid.

 

With Server 2012 R2 reaching EoL on the 10/10/23 I need to look at my options, I wondered if anyone has been in this situation or something similar that could offer a bit of advice?

 

My options, as I see it are:

 

 

1. Turn off exchange and manage everything with Powershell, I am told this is now doable but am unsure on the process.
   
2. Install a newer version of Exchange on a newer version of Win Server, not entirely sure how I do this as I assume it is not straight forward.
   

 

Any advice massively appreciated!

[FN-GM]

I do option 1. (Making sure I use the offical script from Microsoft to clean up AD after getting rid of exchange.)

 

 

You have a third option as well! You can install the Exchange 2019 management tools without Exchange server. This will allow you to manage the synced environment without actually having the actual full flown exchange installed.

 

I guess it comes down to the what you’re actually managing? What would you actually need to do on premise? I found it’s very few and a rarity.

[chaplic]

There's no magic in Exchange and 365, all attributes you set in Exch2016 are just writing to AD then being synced to Azure AD (then to exo directory). Hybrid doesnt even need to be setup either. For years I've seen clients simply turning exchange off and forgetting about it, simply modifying AD attributes directly. This is frowned upon by Microsoft but till recently there wasn't a supported solution.

 

Also, whatever you do, DO NOT uninstall the last exchange server

 

As FN-GM says, IF you have access to Exchange 2019 (it's no longer just a public download), download that and just install the tools only on a newish server (which you can then get rid of). It'll upgrade some AD attributes then the powershell modules will work. If you wanted the comfort of the /ECP an install of Exchange 2019 just to have that is pretty much setup.exe next-next-next

[Gobstopper]

This is exactly the kind of advice I was after, thank you to you both - I can now plan with a bit more confidence!

[chaplic]

Good luck and let us know how you get on.

[FN-GM]

This is exactly the kind of advice I was after, thank you to you both - I can now plan with a bit more confidence!

 

I am curious to know what direction you're going?

[Gobstopper]

Well I have managed to get access to our volume licensing agreement and I do have access to Exchange 2019, which I have downloaded ready to use in the October break.

 

So on balance, given that 2016 is rather old I thought it would probably be sensible to install the tools from from Exchange 2019 onto something like a Server 2019/2022 VM and let it update the AD attributes and then kill that vm. The plan is then to turn off the Exchange 2016 Server 2012R2 vm whilst in no way uninstalling it.

 

From what you guys have said, this seems OK and relatively straight forward to do? Feedback welcome!

[chaplic]

Sounds like a plan. If you have O365<>Exchange federation setup and email routing I’d tear that down first, maybe do some message tracking from powershell to see if there’s anything floating round on prem email other than message health tyep stuff. Also, if you have O365>Exchange stuff remove firewall rules, revoke certs etc

[free780]

If you do retire the server / migrate to server 2022 and exchange 2019 (or newer) just check the server 2012 isn’t being used as a mail relay. You’ll need to point any services to the new server or see if they can authenticate to 365 directly.

[Gobstopper]

Thanks guys, this is massively helping me - I appreciate the time your taking to help!

 

Following on from the advice above I have managed to gather the following:

 

1. All mailboxes are in Office 365

2. We have no Federation in place, just AD Connect

3. Mailflow appears to be Sender > Barracuda > Office 365 > Reciepient, MX Records on DNS Host point to Barracuda - I can't see any references to our internal Exchange server - Is there any way I can double check this? I did consider turning off the VM to see what stopped working!!

4. Exchange online has our domain set to Authoritative and not Internal Relay

 

Thanks again guys!

Edited September 25, 2023 by Gobstopper

[chaplic]

Sounds good, would any internal systems like scan-to-email printer use your internal exchange server as an SMTP email?

 

Turning them all off for a while and passing the screen test is not a bad idea, but Id do get-messagetrackinglog on your on prem. There WILL be emails but should all be background noise. If you see a to/from/subject you recognise youv’e got a problem

[Gobstopper]

Thanks for the tips Chaplic, they have been incredibly useful, however COVID slowed down my progress on this, back now though!

 

So using the messagetackinglog I can see the background noise from Exchange that you mentioned above, the only email addresses I see after that are from our on-prem Smoothwall, which seems to be for reporting purposes. We also have Salamander but I am in the process of planning a migration with them.

 

As for Scan to Email/Notifications it would appear Papercut is pointing to .mail.protection.outlook.com so I am guessing that means Papercut is sending straight to 365.

 

Other than the above, I see no specific users which is presumably a good thing!

[chaplic]

Nice you spotted smoothwall using it a relay and kinda validates that once sorted shouldn't be any other dramas. I suspect you'd know if you had any funky EWS integrations, so the only other things would be if autodiscover (via service connection point or CNAME) pointing t your on prem. likely woudnt make a different to new office clients but might slow things a little.

[Gobstopper]

Thanks for the pointer again Chaplic

 

It does all seem to be going the correct way so far and I imagine it could've been much worse!

 

I had a look at the Autodiscover CNAME record on our web domain and it does appear to be pointing to our on-prem exchange server, not autodiscover.outlook.com

 

Also, looking through ADSI it would also appear that the Autodiscover is set to our on-prem exchange which I found under the property of ServiceBindingInformation, this makes sense to me.

 

So my logic is telling me that I can simply flip it and change both to autodiscover.outlook.com which would then (presumably!) stop Outlook clients trying to connect to the on-prem exchange server and go directly to 365. With MX records pointing to Barracuda (as we currently buy into their email defence module) I can't see any major problems? I appreciate that I am still incredibly green with on-prem Exchange so I don't want to assume too much!

[chaplic]

Outlook autodiscover is pretty resilient and will try about a dozen different things and new outlook versions connect to O365 first anyway but yeah it would be good practise to change the autodiscover entry to a CNAME pointing at O365 and either nuke the SCP or point that at O365 too.

 

Sounds like you’re on your way to be the best kind of decommissioning/ migration - where no-one actually notices!