In this video, Exchange experts and Microsoft MVPs Jeff Gulliet, Michael Van Horenbeeck (also known as “van-Hybrid”) and myself, Co-Chief Editor Sigi Jagott discuss the main reason why you need to keep an Exchange server, and also some ideas how to solve this dilemma in the future.
One of the biggest questions asked after completing an Exchange migration is “How to get rid of the last Exchange Server from your Active Directory?” Currently, you have to keep Exchange Server in your environment because Azure AD Connect (also called DirSync) locks the Source Of Authority (
Hello, Quadrotech. I have been searching the site, looking for an update on this subject. Is there any new news on Microsoft’s plans to simplify the requirements for on-premise requirements when managing an ExchOnline/Office365/Azure environment?
With the recent Exchange vulnerabilities allowing hackers into the LAN, Exchange is just giving them another entry point. So it becomes even more important to remove any unnecessary back doors.
If Microsoft would give us a way of managing the Exchange A.D attributes without needing to maintain an Exchange server on-premise, we could get rid of one more headache to patch. monitor and update.
I Love U!!
you stole the words from my mouth
The thing that you don’t speak to is the license cost for Windows Server itself. Sure, it’s easy to say, “Yea, it’s a great management server. It provides internal relay, EAC, Exchange Powershell, etc.” It’s great that Microsoft gives you a free hybrid license, but tell the customer it costs $1,000 for the Windows Server license and this 15 person company who wants to used AD Connect is going to tell you to pound sand. Now we are back to ADSI edit or AD attributes editing which are both unsupported methods.
Yes, $523 does seem like a lot for a Windows Server license. Isn’t it free to run the hybrid server on Windows Server on Hyper-V?
Hi,
This is an old thread, but I have a dilemma I can’t find the answer too. We have a customer that has had their e-mail on a hosted solution. Now, we have helped them migrate to O365 by creating a tenant, setting up AD-Sync etc. The last thing we did was to migrate their mailboxes from the hosted exchange solution to their O365.
Now some of the users have changed their names due to marriage and some asks to add/move e-mail alias to their mailboxes. So, attributes like mailnickname and proxy addresses and such does not match the users names.
As I try to edit all of this directly in O365, it says:
error
The operation on mailbox “Eugenio Povoa” failed because it’s out of the current user’s write scope. The action ‘Set-Mailbox’, ‘EmailAddresses’, can’t be performed on the object ‘Eugenio Povoa’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.
So, I know why this is, but I can’t find a good answer as how IT managers goes about their daily work editing these kinds of things with ease. Some blogs taking a single change as an example, says to expand the AD with the Exchange attributes and synk up the changes. But, this way I can only apply or edit some attributes in O365, I can never erase them.
What is the best practice to alter attributes on a O365 account when synked with an on-prem AD? Should I brake the synk each time and edit all the changes directly in O365 and then re-apply the synk? To expand the AD schema with Exchange attributes only allow me to add or in some cases alter the values, but will never allow me for example to move an “non personal “e-mail alias between 2 mailboxes, say suggestions@company.com“.
Hopes for a good answer,
Best regards, Karljohan
If my comment above doesn’t work, you can unbind objects completely without losing data:
1. Convert the user mailbox to a shared mailbox in Exch-Online.
2 . Move AD user account to OU not synced with Azure. Run sync.
– Note: 365 account will be in Deleted Users AND shared mailbox will disappear.
3. Restore the deleted user account, it will now be a CLOUD ONLY account. Shared mailbox will appear in Exch-Online. Change primary username of account to “@domain.onMicrosoft.com” and delete the alias for your primary domain.
5. On the shared mailbox, remove any mention of the “@domain.onMicrosoft.com” address and any other addresses matching the cloud user account.
6. Delete 365 user account. Confirm shared mailbox still in Exch-Online.
7. In AZURE AD:
Users > Deleted Users: permanently delete user account. You cannot do this 365 admin.
8. Edit shared mailbox and make changes to email addresses or aliases.
9. Match AD user’s ProxyAddress/Nickname to the shared mailbox. Move user account back to synced OU and run Delta sync.
10. Assign Exchange license to new synced user account in 365. This binds the user account to the shared mailbox using the SMTP primary address. Convert shared mailbox back to user mailbox.
You can now manage all the attributes from AD.
It means what is says – you have to make the changes on the Exchange server which was in the hosted solution (which is no longer there I guess) and let them synch to Azure/Office365.
I am looking for news on this too, as keeping old exchange servers alive is no fun but some people need on prem AD for other things.
Coming from SBS, it’s not even possible to keep your Exchange server alive as Server 2008R2 is not a supported platform. You need to either:
1. Install a supported Exchange release on another machine on your domain (ideally not your domain controller)
or
2. Manage your Exchange attributes directly in AD and let them sync via AAD Connect.
We tend to use option 2 as installing an Exchange server when you moved to Exchange online is ridiculous. One of the biggest selling points in moving to the cloud is no longer needing to run and secure an Exchange server on prem. So many updates and security patching that shouldn’t be necessary.
There are plenty of scenarios with AD as the Source of Authority being completely cromulent.
This is messy and ugly and stupid, Microsoft. Give us a lightweight mail attribute management tool that can be run with the synchronisation platform of our own choosing.
The attributes can be updated in ADSIEdit or you can keep 1 Exchange server onsite in hybrid mode (with a free hybrid license) to manage onsite users that are synchronized with o365.
This is a good dilema. I managed a O365 environment with this problem I took to using powershell to manage alias and name changes. It had a nice GUI and everything. I am now in a situation with what do I do. All mailboxes are in EXO and the exchange server is in a different AD domain from the Sync. Do I migrate the On-Prem to the AD that is managing the users? Do I just get rid of it and use PS to manage?
This reply is now a year old but if you haven’t found a solution, this is why that happens and how you address this.
1. Confirm your AD Sync configuration is syncing the Exchange Properties (this is a simple checkbox in the config menu).
2. Turn on Advanced Features in AD Users & Computers. This enables the Attribute Editor feature. You can only see the new tab in the properties menu by browsing to the object in the OU, you won’t see it using the “Find” function.
3. You’ll be able to edit the attributes for the Proxy Address and Mail Nickname. Capital “SMTP:” is used for the primary email and lowercase “smtp:” is used for aliases. You can also clean up any legacy exchange items here like “X400” and “X500”, but be aware this will impact end users as their individual Auto-complete addresses will still include the legacy addresses and will throw an NDR reply. They can delete the existing auto-complete object for that person and then choose it again once from the address book and it will use the updated proxy addresses which don’t include X400/X500.
We have Azure AD Sync enabled with Exchange Online, and have removed our last on premise Exchange server and get by fine. We use the “Attribute Editor” tab that’s built into the user’s AD object in on premise AD. If this tab and ADSI Edit are one in the same, then I am aware Microsoft states they don’t officially support this method, however it’s never failed me so far.
When are they releasing an Office 365 tool you can install on your on premise server that can be used to make these modifications to your Exchange Online mailboxes that were previously synced from on prem AD?
I can use dsa.msc to change the Proxy addresses, Is Support or I need to use Exchange tools?
Thank,
Nice video. It sums up the experience pretty well.
Do you have any guidance to offer with environments where somebody has made the decision, some time ago, to remove the last Exchange Server and resort to using ADSIEdit/Attribute editor, and now years later we would like to re-introduce an Exchange Server for Hybrid management?
Like the video, very informative.
What we have done is as follows:
1. after the migration of accounts to Office 365, and ensuring that no emails are still being forwarded from the legacy Exchange server, uninstall the legacy on-prem Exchange Server
2. extend AD schema by applying the latest schema updates from Exchange Server 2019
3. repopulate the proxyAddress manually or programmatically
see also https://jaapwesselius.com/2016/06/14/office-365-directory-synchronization-without-exchange-server-part-ii/
A great video and shows that even MVP’s themselves are unsure as to the best way to resolve this dilemma!
High level idea and just my view but Seeing as the issue centres around attributes needing to be updated at SOA, as AADConnect is syncing the data to O365 anyway, what if this can be “called” into an “online” Exchange Management Tools Experience” or a dedicated interface if you will that has writeback capability to the on premise source of authority. Any changes can be made via the hosted EMT as a staging area and be written back to AD for integrity. That effectively means everything is hosted but still maintains the on-premise SOA AD.
Thoughts/Comments?
Disappointing video. Instead of addressing the problem, they explain how it’s not a problem and promote the advantages of keeping your Exchange server (by calling it something else). Companies of less than 100 users, moving to Office 365 for the office suite and Exchange online but needing to keep some on-premises servers need a better solution that changing the name from “Exchange server” to “a management server”.
Completely agree with you.
I don’t care about keeping an on premise exchange for relaying. There are other solutions for relaying which are even documented at Microsoft.
Good morning, technical aside (we do have a number of clients with ADSync and 365 without a local exchange), what I am interested in regards the ‘supported aspect’ –
is there a current link, communication from MS that states it is not supported without local Exchange.
As mentioned, never good to hear “it is not supported…” and things often change at MS.
I am looking for current doc re MS and the support aspect only.
Thank you.
Hi all,
Nice video, thanks!
What I miss in this discussion is where Identity Management solutions fit in this picture. For what I heard (and (like Dan says) cannot find current documentation about) it is not supported to create Identities and mailboxes in the cloud while authentication is done through ADFS on prem. We come from Lotus Notes so we had no on prem exchange infra.
In my opinion Microsoft delivers Api’s and an identity management solution uses these api’s. The api is supported, so this kind of setup is supported. Or am I missing a piece of the puzzle?
Of course.
https://docs.microsoft.com/en-us/exchange/decommission-on-premises-exchange
Quote:
Can third-party management tools be used?
The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but THEY ARE NOT SUPPORTED. The Exchange Management Console, the Exchange admin center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects. If you decide to use third-party management tools, it would be at your own risk. Third-party management tools often work fine, but Microsoft does not validate these tools.
For SMB’s, especially with an old SBS server that is being retired, the requirement for an onprem server is a huge overkill. Unfortunately although there is the free Exchange licence, you still need a Windows licence for the server and you also need to keep patching and updating the version of Exchange – just to add an email alias?
I have a client that is currently using Hosted Exchange without Exchange On-Premise. They maintain two accounts for each user, one for AD and one for Exchange. They want to migrate all mailboxes to Office 365 but maintain only one accounts. Client has approximate 2000+ users. Is Exchange On-premise still required in this case?
Do you mean that their AD is local? In that case, no you do not need on prem Exchange. You just simply install Azure AD connect on your local AD and sync to the free version of Azure AD in the cloud. Exchange Online / O365 uses the users/groups stored in Azure AD. Don’t worry, you can still use your local AD, Azure AD is only used here to sync. Just make sure you have set the correct email adres in the local AD user. AAD connect uses the UPN and email adres to sync.
You only need on prem Exchange for setting advanced Exchange attributes like msExchRequireAuthToSendTo because that attribute doesn’t exist by default in local AD without Exchange.
Some firms will want to keep relays on premise due to security concerns so they are not sent unencrypted to office 365 if they can relay over tls.
But negative of leaving exchange on premise is you have to keep it within one version of current release so every six months you are upgrading exchange
I also have a few clients using dynamics distribution lists and you need azure ad licenses to do the same in the cloud. This needs to be included in any “fix” too.
But managing attributes via adsiedit is not a good support model. Please at least get some web management tool to make these edits without requiring exchange server Microsoft
Larry
Hi Larry,
I agree to your statements and also your examples! Microsoft must at least provide a management interface for a future solution.
Do you really think the management perspective of Exchange (CU-1 to be supported) is an issue? Especially if you do not host any mailboxes anymore, the impact of software updates is minimal.
You aspect about using dynamic distribution lists is interesting, so what’s your plan to get around the Azure AD premium license? Will you route all messages targeted to dynamic DLs to your on-premises enviroment?
Thanks for your insights…
Best,
Sigi
We’ve been using ‘hybrid’ exchange now for the last 5 years without any local exchange servers all while users are created by ADC. All of those attributes can be easily managed by AD users and computers without having to provide the Servicedesk with ADSI access!
So I’m not sure what your big deal is about keeping the exchange interface?
First of all, that’s not really hybrid if you have no on-prem mailboxes, but the main issue would probably be the “not supported” warning.
As already stated: If you’re using ADSI tools to manage your environment, you might run into some kind of weird issues if you change attributes that you could not change using Exchange Management Shell or PowerShell.
As far as I know, it works but I would never recommend it to a customer as Microsoft says: It’s not supported…
Thank you for your video. There’re a lot of SMB companies in my area where which I work for. They have generally small on-prem infrastructures, so they would like to get rid of stuff they don’t really need and save hardware resources. I think that it’s not worth taking an on-prem Exchange alive in my average case. I still can use Powershell through 365 and manage my Exchange OnLine via 365’s ECP as well. I can also create SMTP connectors for my public IP that allows me to manage scanners and applications. Why should I need to keep my Exchange on-prem? By the way you’re right, it’s an hot topic. Some of my colleagues think that an Exchange on-prem should be kept, so I mean we are discussing about it too.
Well, to get rid of the last Exchange server is quite simple if you can get rid of your local Active Directory: Just stop AAD Connect, and disable DirSync in your tenant.
Once all your IDs are converted to cloud IDs, you can use all Office 365 management tools to manage your users.
For SMB companies I would recommend to move everything to the cloud.
But if we need to sync the AD users for local files server and app access, can we just unclick the “hybrid Exchange” option in AAD sync?
Although i can see how last Exchange Server can serve as SMTP/EAC, you still have to have someone good at Exchange and manage it and update when old version is going EOL. Having an SMTP server and editing attributes (if schema is in place already) via AD is just easier and less time consuming.
Oleg, you have interesting arguments. So what SMTP server do you run? The one included in Windows Server?
Also, do you believe that managing an SMTP server is less effort than running an Exchange server? I think running an Exchange server for management purposes only, is pretty easy and straightforward. Also, I see an advantage for Exchange as you get the management interface and monitoring tools such as message tracking logs that are much easier to handle than running an SMTP server.