Mail Enabled Security Group, Migrated, Office 365 mailboxes. Hybrid Enviornment.

[Robert Bollinger]

Hey Guys,

Strange issue (at least for me). We have a mail universal security group, that is being used to grant access to a series of conference room mailboxes as such:

get-MailboxFolderPermission -Identity <conference room name:\Calendar>

FolderName           User                 AccessRights   
Calendar             Default                      {None}
Calendar             Anonymous              {None}
Calendar             UserManager            {Editor}
Calendar             GroupName              {LimitedDetails}

The group named "Groupname" (not actual name) has about 100 users in it, and those 100 users were able to see the availability for the conference room and are also the only ones allowed to submit an InPolicyRequest to book the conference room. (when the group was on-prem, prior to migration).

Everything was working as expected. and then we decided to migrate the group the cloud so that the user who is the group manager could add and remove members to her hearts content without having to open a ticket every time.

Problem:

Now that the group has been migrated to the cloud, a newly added member (me) is unable to see the above availability. I am assuming that other members will also have the same problem.

Any ideas? Can a Cloud Group, not be used to grant access to a group of mailboxes that are hosted on office 365?

Thanks,

Robert

[#2]

Cross-premises permissions are tricky. What's supported currently is Full Access and send on behalf of, support for folder-level permissions is coming in the next months. The details are here: https://technet.microsoft.com/en-us/library/58b46b2c-a6b2-424a-8fc2-0f1fe1ad8e18(v=exchg.150)#Delega...

[#3]

But this isn't necessarily cross-premise, the users and the group are all in the cloud.

Robert

[#4]

Replying here because Robert PM'ed me.

Robert, not sure what "migrate the group the cloud" means... stopped syncing it from on-prem AD perhaps? Anyway, what you're looking at is a situation where you should set up a test case and compare results. I don't know an answer off the top of my head.

Create a shared mailbox or conference room in the cloud, create a security group in the cloud, add a single user to the group, configure the permissions the way you want them, and see if it works.

If the test case works, something has broken in that one particular scenario. Maybe removing and re-applying the permissions would fix it.

If the test case has the same problem, maybe you've encountered something that just doesn't work. Open a support ticket and see what MS says about it.

If you have luck (or no luck), share the results here so we can all see what happened.

In the meantime, maybe someone who knows for sure will answer.

[#5]

Sorry Paul i missed your response. It turns out that our "script" we used to migrate the group to the cloud was actually deleting the old group and creating a new group with that same name. 

Then i had to remove the old entry on the mailboxes in question and simply re-add them. Quick 10 minute fix. 

Robert 

[#6]

Your script is correct in that it deletes the group on premises and recreates the group in the cloud.  I don't know of another way of doing this.  The problem with that method is that I can tell where the group has been used to grant permissions in the cloud previously.  When I delete it and it disappears from the cloud, there is no way for me to tell where to use the new one I create to match the old permissions.  I wish I could tell where my on premises groups that replicate to 365 are being used to give access to 365 objects.  This would make the recreation process much easier and less impactful to users