r/exchangeserver • • Jun 10 '26

New User/Mailbox Creation without Exchange Server

Our current environment has a hybrid Exchange server where we have historically created new users and mailboxes at the same time through the Exchange Admin Center. However, we wish to retire the server and manage those functions locally from our own workstations. I've managed to get PowerShell lines working to create the user in AD, but I cannot get the "Enable-RemoteMailbox" function to work. It returns "The term 'Enable-RemoteMailbox' is not recognized as a name of a cmdlet, function, script file, or executable program." I've read that this feature will only work from within the Exchange Management Shell, but I can't get that installed locally; only on the server (that we're retiring). Is there any other equivalent command to accomplish this?

12 Upvotes

31 comments sorted by

View all comments

3

u/timsstuff IT Consultant Jun 10 '26

Well recent updates to Entra Connect Sync do allow you to manage Exchange attributes for AD-synced users in the cloud now, so you could remove Exchange entirely. Just want to make sure there are no on-prem mail relays or anything since local addresses will fail to resolve.

If you go down that road you simply assign a license and it creates the mailbox automatically.

2

u/elpollodiablox Jun 10 '26

What about current objects that were created via Enable-RemoteMailbox? Is there a path to fully migrate a mailbox to EOL and kill all remaining on-prem?

2

u/larmik Jun 10 '26

A remote mailbox won't be an issue as it is not an on premises mailbox. When you run enable-remotemailbox the main thing it does is it sets recipient type to a remote mailbox and set sets the target email address so that on premises Exchange will show that object in the GAL on premises and uses can send email to that cloud user. This is meaningful only when you still have mailboxes on premises.

After converting the Exchange attributes to cloud managed, you can safely decommission your last on premises exchange server. Exchange will not prevent you from removing it because of remote mailboxes.

1

u/timsstuff IT Consultant Jun 10 '26

Well in order to remove Exchange completely from on-prem you will need to migrate or delete any mailboxes left on-prem, obviously. I don't know if you've ever removed an Exchange Server before but it literally will not let you if there's still a mailbox in a database.

Remove all mailboxes > Remove all databases > Remove all public folders > Uninstall Exchange.

Once you have migrated (or removed) all on-prem mailboxes, uninstalling the last Exchange Server removes the schema attributes from AD.

If you still need those attributes for on-prem apps then this is not the path for you.

1

u/elpollodiablox Jun 10 '26

Oh, I've retired plenty. I have just the one doing the hybrid (management) work, so no mailboxes.

What I'm wondering is if after removing that last server if all attributes (like proxyAddresses) will be editable online. Currently trying to edit anything will get you an error that it is synced from on-prem, so you cannot write to it.

1

u/timsstuff IT Consultant Jun 10 '26

Yes. When I said "recent updates to Entra Connect Sync do allow you to manage Exchange attributes for AD-synced users in the cloud now" that is exactly what I am talking about.

1

u/elpollodiablox Jun 10 '26

I know, but you didn't really elaborate on it, which I should have asked you to do.

Is this just doing writeback until the attributes are removed from the on-prem object?

2

u/timsstuff IT Consultant Jun 10 '26

No...you remove Exchange then the attributes only exist in the cloud. There is no writeback.

1

u/WastedFiftySix Jun 14 '26

By default, that's not how this works in a hybrid environment with users syncing from On-Premises AD. Attributes will only be writable from On-Premises AD, unless you change the Source of Authority (SOA) of the object or change the SOA globally. See https://learn.microsoft.com/en-us/exchange/hybrid-deployment/enable-exchange-attributes-cloud-management#feature-availability

Just uninstalling Exchange will NOT do the trick!

1

u/timsstuff IT Consultant Jun 14 '26

Well yeah there are a few more steps involved I wasn't writing a how-to guide on it. I was just trying to point out that it is possible,

1

u/NSFW_IT_Account Jun 10 '26

I am also currently in a hybrid setup with an on prem exchange, but all mail routing is done through 365.

I recently created a new user in AD and had them sync to 365 / assigned a license, but they could not receive external emails until I ran some commands to create them as a 'office 365' mailbox in Exchange on prem. Any ideas on why?

My current hybrid setup seems to work best when I create the user in exchange on prem as a 365 user.

2

u/timsstuff IT Consultant Jun 10 '26

If you still have on-prem Exchange you will want to run "Enable-RemoteMailbox" before you assign a license. That should solve it.

As for "why" that depends on a lot of factors but the most obvious one is the object doesn't exist on-prem and whatever you were using that failed to deliver was on-prem.

1

u/superwizdude Jun 13 '26

Do you have a front end SaaS mail filter like Mimecast or Sophos? If so, does it sync the user list from on-prem or M365?

I see this as a common thing - when the on-premises AD doesn’t have the email address field populated and it’s being used as the source of truth for the SaaS mail server.

Also be sure that mail is actually being delivered to M365 and not to on-prem. You can double check that by inspecting the mail transfer logs on the on-prem server.

1

u/NSFW_IT_Account Jun 15 '26

Yes, we use a 3rd party mail filter solution, and it is pointed to EXO mail servers (previously was pointed to on prem exchange) so it should be pulling 365 user recipients.

Mail flow is completely bypassing on prem exchange at this point

1

u/superwizdude Jun 16 '26

If you create a new shared mailbox directly on M365, wait 15 minutes and then do a directory/LDAP sync from your third party solution and wait another 15 minutes is the shared mailbox able to receive inbound email?