Do I need an Exchange Server?

Copper Contributor

Before anyone bites my head off or says "Yes!  Of course you do!" hear me out.  I have some scenarios I'm working through and I'm simply not sure...

 

1) Company is spinning off of Parent company.  Parent company is in O365, Company will be doing a Tenant to Tenant migration and won't even have an on-prem active directory to start with.  They will eventually have an on-prem Active Directory, but it will obviously have never had Exchange.  Since the AD Schema will not have been extended to include Exchange Attributes, I know for a fact that I can edit email addresses and all other Exchange Attributes in O365 even after I start syncing with on-prem AD.  Do I need an Exchange Server?

 

2) Company is considering moving from G-Suite to O365 and has obviously never had on-prem Exchange.  They do, however, sync some of their distro groups from AD to G-Suite, which means they will either need to sync those to O365 or delete from AD and recreate them in O365 and manage in cloud.  Again, since the AD Schema was never extended, will I need an Exchange Server?

 

EDIT TO ADD:  In both cases, I have already told the customer(s) that we will need an exchange server on prem, but I'm just curious at this point if I really do.

8 Replies
Are you talking about an on premises exchange server? Well no! Can’t find a reason why you would need an on site server for these scenarios, but I might have misunderstood? Please elaborate why you think you need one.

Adam

@adam deltinger

Well, the only supported method of managing Exchange attributes is Exchange admin center or Exchange Management Shell.  And really, the more I think about it, the more I think I'm going to need one.

If I have to change an email address, I would have to use ProxyAddresses in ADUC - which is technically an unsupported method.  And I'm pretty sure that Hide from address list, even with the schema not extended, is still somehow in AD.

Darn.  I think I'm going to need the server to be in a supported configuration.

Proxyaddress has been working well for me many times, and you can extend the schema without installing exchange server

@adam deltinger

Yes.  Yes, you can do those things and you can use ADSIEdit and it will work.  But the key here is "supported".  Microsoft only SUPPORTS using EAC/EMS.  As a consultant, I cannot in good conscious put my customers in an unsupported configuration, especially since they are using enterprise O365 licensing, which gets them a Hybrid Exchange License Key.

You don't *need* one, technically you can manage all the related attributes just fine via the AD tools. However, the only *supported* method to manage Exchange-related objects and attributes are the Exchange tools, thus Microsoft's recommendation to spin up an Exchange box if you want to stay in *supported* configuration. I've worked with many organizations that simply ignore this recommendation, and they are doing just fine. But in general, using the Exchange tools is better, as they protect you from stamping invalid or duplicate attributes, etc.

 

As for extending the schema, this is pretty much a requirement if you are going to use AAD Connect - without it you will not be able to manage any of the Exchange attributes as they will be locked in O365 and not "known" at all in AD.

Proxyaddress has been working well for me many times, and you can extend the schema without installing exchange server

Having a running server on premises just for the sake of attributes defeats the purpose of exchange online!
I do agree with Vasil, and I think it’s fairly dumb in the it works! I’ve also seen and set up a lot of ad syncs with no exchange server on premises and they all works fine with and with the help of PowerShell, makes it easy to handle!
So, no you don’t need one but I won’t tell against it! If you feel it’s better going supported with MIcrosoft, there is nothing wrong with that

@Rachael Moermond 

 

As suggested by Vasil, Technically you do not need an Exchange Server On Prem to manage the configuration you mentioned. However it is better to stay on the safe side and be in a supported configuration.

 

Thanks

 

Robin Nishad

-----------------

Technical Consultant