• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 182
  • Last Modified:

Help with Mail-Enabled Security Groups in Office 365 and On-Prem Active Directory

We just moved from an on-prem Exchange 2013 server to a Office 365 with hosted Exchange.  We have a handful of shared mailboxes that we use, such as info and orders.  

With our on-prem Exchange server, I had a access based security groups set up for each of of the shared mailboxes, such as "shmb_info_fullaccess" and "shmb_orders_fullaccess".  I also had role based security groups setup, such as "shared mailbox - info" and "shared mailbox - orders."  Users would then be assigned to the role based security group.  The role based security group would then be assigned to an access based security group.  The access based security group would then be given permissions on the Exchange shared mailbox.

With Office 365 and hosted Exchange, it appears that the security group must be a Universal security group and also be mail-enabled in order to apply the security group to a shared mailbox.  I have tested this and it seems to work as intended.  

With that said, the following is my dilemma.  In order to make the security group mail-enabled one must run the enable-distribution cmdlet from the Exchange Management Shell.  Withut an on-prem Exchange server, one cannot run this command as the command is not supported with Office 365 hosted Exchange.  Therefore, it does not seem that I can create a mail-enabled security group from within my on-prem AD.  It seems that I must created the security group from within the hosted Exchange Admin Center.  

When I create a security group within the hosted Exchange Admin Center, it shows the group within the Office 365 Admin Center that the group status is "In Cloud" and not "Synced with Active Directory."  I am not sure if it is possible or not to get the security groups created in the Office 365 hosted Exchange to sync with my on-prem Active Directory or not.  I like the idea of being able to manage all of my users, groups, etc. within my on-prem AD instead of bouncing between my on-prem AD and the Office 365 Admin Center.  

I'd love to hear your feeback on my current situation.  Maybe I am going about this all wrong.
0
csimmons1324
Asked:
csimmons1324
  • 4
  • 4
  • 2
  • +2
8 Solutions
 
MaheshArchitectCommented:
if you want to sync mail enabled groups from onpremise Ad to O365, you must need onpremise exchange server, else you cannot create mail enabled groups
If its standard security group, you can create it with on premise ad and then it will get synced to o365 as security group

one option is to fill up all required exchange specific attributes in group such as alias, ProxyAddresses and target addresses and so on but that is not supported way as Microsoft will not support if tomorrow you face any issues because of manual edition of attributes

U need to install hybrid edition of exchange 2013 / 2016 and from there manage groups and users
0
 
Vasil Michev (MVP)Commented:
You kinda are going about it all wrong. If you are using dirsync, you are required to have at least one Exchange box on-premises, for management purposes (such as the scenario you describe above). And that's valid for any configuration involving dirsync, regardless of whether you have mailboxes on-prem. Otherwise, you are in unsupported configuration, and while you can certainly work with other tools to manage the objects, the fact remains that the Exchange tools are the only ones Microsoft will support when it comes to recipients or properties related to Exchange.

The easier path would be to simply create them in O365 and be done with it.
0
 
Aaron GuilmetteTechnology Solutions ProfessionalCommented:
Depending on the size of your organization and if you are synchronizing an on-premises directory, you may still want an on-premises Exchange 2013/2016 server.  I recommend most of my customers keep one for things like:
  • Creating/managing synced distribution lists (your issue)
  • Running Enable-RemoteMailbox as part of an automated/scripted provisioning process
  • TLS-enabled relay to Office 365 for multifunction devices/printers
  • relay to outside the organization from on-premises application servers

We only support modifying Exchange attributes via the Exchange Management Shell or Exchange Admin Center (on-premises) for synchronized objects.

You can obtain a free hybrid key for Office 365 (http://aka.ms/hybridkey).
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
Peter HutchisonSenior Network Systems SpecialistCommented:
It is possible to create mail-enabled groups with AD by just setting the appropiate properties using Set-ADGroup groupname -ADD{attribute=value, ...}
The attributes you need to set are:
mailNickname = Alias or short group name.
displayName = Name shown in Address book
proxyAddresses = List of SMTP and smtp secondary addresses
mail = main email address

See https://docs.microsoft.com/en-us/powershell/module/addsadministration/set-adgroup?view=win10-ps for set-adgroup.

See http://www.selfadsi.org/attributes-e2k7.htm for list of attributes (attributes should be same for later ver of Exchange).
0
 
csimmons1324IT ManagerAuthor Commented:
Thanks for all of the input.  I was under the impression that once I moved to hosted exchange that I could decommission my on-prem Exchange server.  I will take a more in depth look at your responses and do some more reading over the next few days.

FYI...I am only dealing with about 30 users / mailboxes.
0
 
MaheshArchitectCommented:
IMHO, for 30 users manage everything in cloud, if required enable MFA service and disable ad sync functionality
OR
Use ad sync to sync users with out exchange attributes and enable mailbox in cloud directly to list in gal
0
 
Aaron GuilmetteTechnology Solutions ProfessionalCommented:
For 30 users, if you're going to use AAD Connect to maintain password hash sync or pass-through authentication (or ADFS), then you'll still want to maintain an Exchange installation on-prem, even if it's for just 30 users.  For attributes that are synced to cloud (such as proxyAddresses), you can *only* modify them on-premises.

While it's totally possible to manually set the synced attributes (such as proxyAddresses or msExchRecipientTypeDetails) via ADUC Attribute Editor or ADSI Edit, if something doesn't get properly formatted (such as an entry in proxyAddresses not prefixed with smtp:, multiple entries with capital SMTP: in proxyAddresses, a targetAddress set to a value that's not in proxyAddresses, etc) or you introduce a duplicate value (two accounts with overlapping SMTP or UPN values) and it requires a call to Premier, the first thing they'll ask you to do is to log into your Exchange environment and check it there.

We'll do the best we can to support you, but as an MSFT resource, I can't recommend something that's not in our best practices or supported by the Product Group.

If you're not using AAD Connect for password hash sync or pass-through authentication and don't want to support an Exchange system deployment (even if it's on the same server that runs AAD Connect), you may be better off switching to a cloud-only deployment.
0
 
csimmons1324IT ManagerAuthor Commented:
Maybe I am missing something here or maybe I am not.  My concern is that if I do not run ADD Connect then I have to add a new user to my on-prem domain / active directory AND then add the user again within the Office 365 portal.  If I remove a user from our on-prem active directory then I also need to go into Office 365 and remove the user there as well.  Same goes for adding / removing groups, users changing passwords, etc. etc.  This all seems very redundant and cumbersome.  

With that said, I am inclined to continue to use ADD Connect to keep our local domain / active directory in sync with Office 365 as I do not want to have to manage users / groups /etc. in multiple places.  I was not informed that I would need to keep an on-prem Exchange installation running to do this.  Correct me if I am wrong, but nothing on the on-prem Exchange server needs to be configured for sending / receiving email as it is only being used to manage the Exchange attributes & settings for users / groups.
0
 
Aaron GuilmetteTechnology Solutions ProfessionalCommented:
Correct.  If you want to sync users from on-prem to cloud, the source of authority is now your on-premises AD, so you need to modify all of the attributes that are synchronized through your on-premises AD.  

You don't need to configure Exchange to route, but I'd still suggest going through the Hybrid Configuration Wizard.  It gets your routing domain added to Exchange on-prem, so that when you run Enable-RemoteMailbox (or New-RemoteMailbox), there's a value for -RemoteRoutingAddress.  It also will guide you through setting autodiscover, so if you had existing on-premises Exchange, that controls how your Outlook client connects to Office 365.

You don't need to actually route mail with it.  It's just an added capability.  The other thing that I like about this method is that it makes you look like most other customers, so if you need to call support for something, the troubleshooting processes that support goes through will work more easily.
0
 
csimmons1324IT ManagerAuthor Commented:
Aaron,

I appreciate you help and suggestions with this.  Do you think that it would be best to decommission my existing Exchange 2013 server (running in a VM) and start with a fresh hybrid installation of Exchange 2016?  

I have had plans to move our on-prem Exchange to the hosted solution for some time but it recently got expedited due to some problems that were having with on on-prem Exchange server that I couldn't figure out.  Instead of spending the time to troubleshoot the on-prem Exchange server, I determined that my time was better spent just moving everything to the hosted solution as we planned on doing so anyway.  With all of that said, it would probably be better to just spin up a new VM and do a fresh install of Exchange 2016 for the hybrid environment unless you see a reason not too.
0
 
Aaron GuilmetteTechnology Solutions ProfessionalCommented:
Once mailboxes are moved, you can just install a new 2016 server and uninstall your 2013 server. It doesn't sound like you have a lot of management activity (since you don't have a ton of users), so I definitely wouldn't invest a lot of time in troubleshooting.  Moving the mailboxes if your environment is experiencing issues should probably be your first move, and something that you could easily accomplish over a weekend.  Then, you can deploy a new 2016 server and gracefully decommission your 2013 server.
0
 
csimmons1324IT ManagerAuthor Commented:
Thanks to everyone for the comments, tips and suggestions.  I have already moved all of our mailboxes to Office 365.  I will keep an on-prem Exchange server up and running for management purposes.  Once again, thank you.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Windows 7 Basic

This introductory course to Windows 7 environment will teach you about working with the Windows operating system. You will learn about basic functions including start menu; the desktop; managing files, folders, and libraries.

  • 4
  • 4
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now