hitting a snag when looking at removing hybrid exchange

[KK20]

We migrated our mailboxes from onsite exchange to office 365 some time ago along with our MX, our mailflow is internet > office365 > (if necessary fro mailbox) onsite exchange. There were some diehard applications and hardware that wouldnt communicate with office 365 properly and so we still had our onsite exchange server running with a few service accounts and connector to offsite - we do not run centralized email. After running through the weekend rigmarole of installing the hotfix patch, it has been decided to shelf those apps and hardware so we can finally look at retiring our exchange onsite completely.

 

However, we still have onsite AD and are running federated - azure AD connect synchronisation. This means that in the past we have created a new user in AD onsite, added email account in onsite exchange then migrated the mailbox, this ensured that the onsite AD was populated with email addresses, the GAL updated nicely and the exchange online mailbox functioned fine with outlook online etc. Im struggling to see how I would do this with no exchange server.

 

If I (now) create a new user and leave things alone (i.e. I do not create a mailbox in local exchange), I do still get the offsite exchange online mailbox when azure AD connect syncs, it is the correct federated domain, UPN is the same form as everyone else. Licences are correct just as they would be for anyone else - except my onsite AD in not populated with email address, GAL is not updated with the user email either.

 

What am I missing or more correctly what have I probably not done? Im better fixing these issues before I remove exchange completely....

[psydii]

https://docs.microsoft.com/en-us/exchange/decommission-on-premises-exchange

 

(basically if hybrid, hybrid forever, or until you turn off hybrid and decomission your local AD)

 

I'm planning to install a minimal Exchage 2019 server this summer, locked down and restricted to office 365 + local MFDs only and then decomission the shell of the huge 2013 server. It will be *just another little server* much like AADConnect or Azure App Proxy.

[HPlum78]

Maybe we will see the promised hybrid replacement so that we can get shot of on prem exchange installs... This may help focus some minds.

[Tefters]

Pysdii nailed it on the head, Hybrid has to have an on-prem exchange server just for management and support.

With mine it's the most basic of installs with as many Exchange services disabled as possible wmbefore breaking the management GUI.

 

Technically you can get rid of it and just manipulate the values via scripting or ADSI edit but this is not supported or recommended by Microsoft.

[chaplic]

MS official requirement is you keep an exchange server but IMHO thats complete and utter bunkum (and some of the MS smart-arses saying 'why do you have exchange on prem this week have really annoyed me because of this!).

 

There is no connection between Exchange and O365 (let's ignore mail flow), all information is held in the directory(AD->AAD->EXO). So you can quite happily turn on things like archive mailbox or shared mailboxes by knowing which attributes to set - in AD

 

So to answer your first question, if you are 100% online and don't need an on-prem GAL to work then controlling which AD user gets a mailbox by licensing is fine. I know an org that has two exchange servers but has them permanently turned off!

[KK20]

Looks like I will simply keep our exchange server. "migration" wont be an issue as there will be no mailboxes on it, external input will be locked down to o365 so that should cut the attack vector down a little (firewall wont pass OWA as there wont be a need to).

 

We have no intention of moving our AD totally offsite yet and I dont fancy ADSI editing every account we create!

[KK20]

as an addition, how do people-who-hybrid go about creating new users? Do you still create and assign mailboxes onsite THEN migrate? I assumed that the sync was "one way", I didnt want to have two mailboxes created for new users as I suspected that if I created a new user (which would be synced online), if they were exchange licensed (as our OUs are) this would automatically provision an exchange online mailbox. Im guessing this exchange online GUID is not synced backwards?

[RobD]

I create AD user as standard then use Enable-RemoteMailbox

 

i.e.

Enable-RemoteMailbox -Identity %USERNAME% -remoteroutingaddress %USERNAME%@YOUR_SITE.mail.onmicrosoft.com

 

https://docs.microsoft.com/en-us/powershell/module/exchange/enable-remotemailbox?view=exchange-ps

[KK20]

OK so I just tested it. The following happens for me:

1) create user onsite in an appropriate OU

2) at this point I would normally create an exchange mailbox - I actually have a script on scheduled task that has a combination of Get-ADUser -searchBase on my OUs and Enable-Mailbox (plus some set-mailbox with differences if necessary). I did not manually kick off this script therefore an onsite mailbox was NOT created

3) waited about 10 minutes so that AD azure connect synced to azure AD

4) licence was added in azureAD, user shows synced. Online mailbox with correct school.co.uk domain created.

5) tested mailflow - onsite and offsite email went happily to and from the user.

6) GAL does not list this user in the usual groups. ADUC does not think this user has an email address - mail property not populated.

 

so I set about thinking - what if I create an onsite mailbox? So i ran my script with did create an onsite mailbox. However, the onsite and remote mailbox had different GUIDs so whilst it was a kludgy fix for GAL and ADUC, (mail still flowed to the remote mailbox), it wasnt neat. The solution was to edit my script slightly-

 

after creating the mailbox onsite for the user, do a bit of decision making - if there is an offsite GUID for this user, then disable the onsite mailbox, create a remote mailbox using the tenant name, copy the offsite GUID onto this record. If there isnt an offsite GUID then create a batch remote migration with auto completion.

 

This worked fine for my test user - ADSI shows the correct proxy addresses, correct mail and exchange local is happy with the correct offsite GUID (and no hint of local). Local ECP shows the user as having an office 365 mailbox.

 

This means I will simply carry of as normal letting ADUC add a new user, wait for my scheduled task to create the onsite mailbox and re-forge the o365 mailbox GUID. Why do I do it this way? If I was creating a single user then I could probably get away with create in ADUC and add remote-mailbox BEFORE azure syncs. However since I auto assign licences this is a run the gauntlet. so I could stop the auto assign exchange license or do the script. At least this way the accounts work as soon as sync is up and running, it is simply ADUC and GAL that will take time to update.

Edited March 10, 2021 by KK20

[chaplic]

Why do you need to create the on-prem mail attributes for new users if you will never have a user mailbox there?

[KK20]

ADUC does not have a mail attribute attached to it, this is used by other applications querying ADUC. Are you saying your sync writes back remote mailbox details to ADUC? If so then I have a configuration issue as mine definitely does not.

[Tefters]

As per RobD.

 

Create local AD user and then run the create remote mailbox command, this populates AD with all the info which then gets synced to O365 via (AD Sync or whatever its called nowadays) and creates the mailbox there. You must remember to also assign the user an Exchange license in O365 also, simply creating the mailbox via the remote mailbox command is not enough.

 

Alternatively go speak with Salamandersoft and have them automate everything

I've thrown some great curveballs at them for automation requests and everytime they nail it. Best £1k per year you could ever spend!

Edited March 11, 2021 by Tefters

[Max_Power]

Looking for answers to this myself after the latest Exchange issues to plague the world. Appears I have to maintain Exchange 2016 for the mailbox management aspect as its the only "supported" method at the moment even though we've been in a hybrid for a year and have no mailboxes onsite.

 

However I have come across this https://www.granikos.eu/en/justcantgetenough/PostId/1858/remove-the-last-exchange-server?fbclid=IwAR2bIuSo8JVB-CEL-O1abHUEyfcRCdW4Q2VJdYU3TZ3mBzdJIFPLe5BWgPQ which details how to manage Exchange Online after migrating. Sounds like you simply update the AD schema to include Exchange and enable Exchange Remote Features and you can manage everything without an Exchange Server? Has anyone done that? Or know if its legit?

[MartinT]

My concern is that, having shut down our Exchange server for over a year now, the last thing I want to do is power it up for fear of what it might do to existing accounts, notwithstanding that it'll be a lot of updates behind and therefore vulnerable.

 

We tend to use Powershell for managing existing and new accounts.