none
Exchange 2010 Unable to Assign Full Access Permissions using a Security Group RRS feed

  • Question

  • I've been running into this issue lately.  I cannot seem to use groups to allow full access to mailboxes.  When I add them from the EMC, it will show up when you go to "Manage Full Access Permission...".  After waiting a day and even restarting the Information Store service, the permissions do not take effect.  When I view the msExchDelegateListLink attribute of the mailbox account, the group is not listed.

    When I grant a user full permission, it works and updates the attribute.  However, on occasion when I revoke the full access permission for a user is doesn't always remove that user from the msExchDelegateListLink attribute.  So the mailbox will still appear in Outlook, but the user isn't able to see new emails.

    Any ideas on what may be going wrong?

    Environment:
    Exchange Server 2010 SP1 Standard
    Windows Server 2008 R2 Standard
    Outlook 2010 SP1 (tried without SP1 as well)

    I was looking over Add-MailboxPermission on Technet (http://technet.microsoft.com/en-us/library/bb124097.aspx) and I noticed that it doesn't mention adding groups.  Is this not possible?

    Wednesday, July 6, 2011 12:42 PM

All replies

  • This is just a guess, try mail-enabling the security group.
    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Wednesday, July 6, 2011 3:49 PM
    Moderator
  • Just tried that.  I tried switching it to a universal group first which didn't work.  This hasn't worked yet either.  The group shows up when I run Get-MailboxPermission -identity "mailboxname" as it did before.

    Wednesday, July 6, 2011 7:32 PM
  • That didn't appear to work even after a restart of the Information Store service.  I even tried removing the group and adding it back.  Still no luck.  It does show up when running Get-MailboxPermission -identity "mailboxname".  It just doesn't show up in Outlook.

    I've also tred deleting and recreating the Outlook profile.

    Any other ideas?


    • Proposed as answer by ggh sd Thursday, April 11, 2013 11:23 PM
    Thursday, July 7, 2011 11:29 AM
  • Hi wchar_t,

     

    I test in my lab (Exchange 2010 SP1), get the same result as you.

     

    If you only want members (in this security group) to have full access permission on the mailbox, you can use this command to achieve the goal:

     

    Get-DistributionGroupMember “Test Group” | foreach-Object { Add-MailboxPermission “Usermailbox” –AccessRights FullAccess –user $_.Name}

     

    Note: “Test Group” is a mail-enabled security group

     

    Thanks,

     

    Evan Liu

     

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com  

    Thursday, July 7, 2011 11:41 AM
    Moderator
  • I appreciate the PS script to get this done.

    Is there any reaason groups shouldn't work?  I had this issue prior to SP1 as well.  I just didn't have a strong need like I do now.  I really don't want to assign permissions by user as that isn't best practice.

    Thanks.

    Thursday, July 7, 2011 11:44 AM
  • Since we have SA, I have opened a case with MS.  But I'm still open to ideas from the forums. :)
    Thursday, July 7, 2011 11:53 AM
  • Hi, I have experienced exactely same issue at a client place.

    Exchange 2010 SP1 within a DAG

    Windows Server 2008 R2 SP1

    Outlook 2010

    If i apply full access permission to an user, it works.

    If i apply full access permission to a security group, it never applies.

    Thanks to keep us updated about your case.

    Samir

    Thursday, July 7, 2011 2:57 PM
  • I will definitely update this thread when I hear back from them.  ~1 business day or so.
    Thursday, July 7, 2011 2:59 PM
  • Hope MS will give you an answer :)

    Thanks!

    Thursday, July 7, 2011 3:19 PM
  • Hi! Any update concerning the issue?
    Monday, July 11, 2011 10:12 AM
  • Heard back from MS, but nothing new to report.  Made them aware of this thread and what has been tried already.  I'll post back when I hear something from them
    Monday, July 11, 2011 11:37 AM
  • Any news?
    Thursday, July 14, 2011 7:04 AM
  • Hi wchar_t,

     

    Do you get any information now?

     

    I got a same issue, I can apply full access permission to a user, but cannot to a security group.

     

    Could you share us your solution?

     

    Thanks,

     

    smart

    Tuesday, July 19, 2011 1:21 AM
  • No news yet.  The last suggestion was to add the mailbox to the "additional mailboxes" section in the mail profile.  This failed as well with the error "Cannot expand the folder".

    Still waiting on a reply.

    Tuesday, July 19, 2011 12:56 PM
  • Add-AdPermission -Identity "User Mailbox login account Name" -User "Universal security group" -AccessRights readproperty, writeproperty _properties "Personal Information"

    Get-Mailbox -Identity "User Mailbox Name" | Add-MailboxPermission -User "Universal security group" -AccessRights fullaccess

    Can you try this

    Tuesday, July 19, 2011 2:08 PM
  • This thread points clearly a bug...
    Thursday, July 21, 2011 11:51 AM
  • The MS rep I'm working with is finally able to reproduce the issue in his test environment.  He has asked me to install Exchange 2010 RU4 for SP1.  http://www.microsoft.com/download/en/details.aspx?id=26910

    I haven't done this yet, so I'm not sure that it will fix anything.  I didn't see this specific bug listed.

    Thursday, July 28, 2011 11:17 AM
  • Hi

    Read this before you go for update SP1 RU4

    http://blogs.technet.com/b/exchange/archive/2011/07/13/exchange-2010-sp1-ru4-removed-from-download-center.aspx

    Dont do the availble version now, update version will release by Aug and try to install that


    Thursday, July 28, 2011 11:31 AM
  • Per MS support:

    I would like to explain that Exchange 2010 SP1 RU4 was re-released on 7/27. This updated release of Exchange 2010 SP1 Rollup 4 can be download safely.

    Friday, July 29, 2011 11:47 AM
  • Yes. New rerelease happened yesterday for RU4, I get the information today from my friend :) you can proceed as MS tech informed
    Friday, July 29, 2011 12:20 PM
  • Installed RU4 v2 without any issues.  The problem still exists as I suspected it would.

     

    Little frustrating playing email tag with MSFT support.


    Friday, August 5, 2011 1:30 PM
  • Thanks for the updates wchar_t! I have been experiencing the same issue and it’s been driving me nuts. I’m surprised that there isn’t more of an uproar over this problem, unless it only happens in very specific EX2010 setups?

    Personally we migrated from Exchange 2003 to 2010 in this manner:

    ·         All Servers are VMware ESX 3.5 Virtual Machines

    ·         Upgraded all VMware ESX 3.5 hosts to VMware ESXi 4.1 update 1

    ·         Created 2 new virtual W2K8R2 DC’s, decommissioned our 2 virtual W2K3 DC’s

    ·         Created 1 new virtual EX2010 STD Server with CAS, HT, and MB roles.

    ·         Migrated accounts from virtual EX2003 ENT to virtual EX2010 STD

    ·         Virtual EX2003 is still running strictly for SMTP delivery as our developer updates his code for the new virtual EX2010 STD server

    For anyone experiencing the problem are there any similarities in how you deployed EX2010?


    Friday, August 12, 2011 7:09 PM
  • Thanks for the updates wchar_t! I have been experiencing the same issue and it’s been driving me nuts. I’m surprised that there isn’t more of an uproar over this problem, unless it only happens in very specific EX2010 setups?


    Our site is a fresh install.  No migration at all.  VMware 4.0/4.1.  Not sure why more people aren't complaining unless they are just dealing with it.

    Last communication from MS wanted me to try:

    Add-ADPermission –Identity "Mailbox" -user "Security Group Name" –ExtendedRights Receive-As

    I haven't done it yet.

    Friday, August 12, 2011 7:19 PM
  • So I brought this issue up at my local Exchange Users group and no one else (out of 8 people) has the same problem, they also all run Exchange on a physical server. So I wonder if it's related to a something as dumb as a virtual driver?

    Tuesday, August 16, 2011 11:55 PM
  • I tried the last command MS sent me.  It didn't work either.  It also broke OWA for the test account I was using.

    Not really sure why it would matter (physical vs virtual).  But who knows at this point.  It's definitely annoying.

    Wednesday, August 17, 2011 12:27 PM
  • I've had this EXACT same issue since we migrated from Exchange 2003 to 2010.  I can grant users full mailbox access to a mailbox but when I try to add a security group the member of the group is unable to open the mailbox as an additional mailbox in their Outlook profile. 

    I did discover, that if I had a member of the security group create a new mail profile and connect to the vanity mailbox, they could open it.  Out of curiosity I had the member go to their default Outlook profile and add the vanity mailbox as an additional mailbox, VOILA!  they were able to open it. 

    Not what I'd call a viable workaround, especially if you have a multitude of members in that security group. 

    I'll be monitoring this board anxiously waiting for a solution.

    Thursday, August 25, 2011 8:28 PM
  • @Bugeater Fan,  that actually worked for my account. Before I wiped my Local Outlook profile I had this issue, after troubleshooting a another issue and wiping/rebuilding my profile I can now use access mailboxes that I couldn’t before via a security group. A few things I noticed:

    1.       If I was already part of a security group that had access to an email box, that ability stayed after the upgrade to EX2010

    2.       If I created a new security group for a new mail box after our upgrade to EX2010 I had the issue.

    I plan to test the following with a user still having the issue

    1.       Before rebuilding outlook profile

    a.       Add this user to a security group that has access to a mail box where both were created BEFORE our EX2010 upgrade (created in EX200). Does this issue still occur?

    b.      Add this user to a security group that has access to a mail box where both were created AFTER our EX2010 upgrade (created in EX200). Does the issue still occur?

    2.       Wipe and rebuild local outlook profile and then test again.

    I’m wondering if there is something in the local profile that is missing if it isn’t rebuilt after an EX2003 to EX2010 upgrade…

     

    @wchar_t, any news on your end?

    Tuesday, September 6, 2011 6:37 PM
  • @wchar_t, any news on your end?


    Nothing on my end.  Just sent off another email asking for a status update.  I normally don't hear back until ~3am the next day.  I'll let you know what I hear.
    Tuesday, September 6, 2011 6:40 PM
  • wchar_t,

    Can you comment the case id you have open with Microsoft? As I am seeing the identical issue I'll see what leverage I can use to escalate the issue.

    Helps if I can give them the existing case id for them to review.

    Friday, September 9, 2011 6:20 PM
  • It was implied that the issue may be with virtual servers.  It is not..

    Currently all of my exchange servers are physical.  I'm also having an issue with giving groups full access permissions on mailboxes.

    Monday, September 12, 2011 4:28 PM
  • As an update here is what is happening in my environment through testing:

    • If a new group created in ECM (which makes Universal groups) and that group is used to give full access permissions to mailbox (created pre or post upgrade) the users in the group will eventually get access to the mail box but it might take a few days (Created the group on Thursday and it didn’t work immediately or on Friday, when I tried on Monday it did work)
    • Mailboxes that worked before the upgrade from 2003 to 2010 still work with the original groups. These groups are Global and not Universal groups so they do not show up in the ECM under Recipient Configuration ->Distribution Group but do show up when you use the ECM to Added full mailbox permissions. New members added to these groups do not have immediate access, but after 30 minutes they do.

    So, I'm wondering if this is an issue with how universal groups are handled in EX2010? Maybe we all have a setting in our Global Catalog servers that only Exchange 2010 is sensitive too? I currently have a single domain with two DC's., they both are Global Catalog servers but one DC holds all of the FSMO roles. And when I run

    Get-ADServerSettings | FL

    I see that my EX2010 server is pointing to my secondary DC. I'm going to try changing that to my primary and see if that helps it process Universal group memberships quicker.



    • Edited by Vox Medica Monday, September 12, 2011 6:43 PM
    Monday, September 12, 2011 5:26 PM
  • I'm also quite interested in this. However, my situation would take it even a step further:

    User is a member of a RoleGroup

    RoleGroup is a member of MailboxPermissionGroup

    The MailboxPermissionGroup is what I'd like to give:
    -ExtendedRight 'Send-As','Receive-As'
    -AccessRights FullAccess
    ...and also have the group given full access end up in the msExchDelegateListLink attribute of the mailbox... which should happen when given fullaccess.

    Nothing I do other than granting that permission to an account (not at all prefered) works.

     

     


    Ian
    Saturday, September 24, 2011 4:41 PM
    1. this may be a bug.  Even with the latetst rollup.
    2. Similar to, if you try to give the send-as permission to a DL via EMS on another Exch server than to the one you created to the DL on, it will fail, because the local exchange server in the owner and not the Exchnage Servers groups.
    3. Similar if you create a DL in ADUC, it will fail because the domain admins are the owners and not the Exchange server groups.
    4. Workaround for these is to give the exch servers group modify permission
    5. I will find out about this next week.

    Sukh
    • Proposed as answer by loserface15 Tuesday, July 3, 2012 5:47 PM
    Saturday, September 24, 2011 10:02 PM
  • hello

    same issue here, migrating from ex2003, domain 2008, ex2010 sp1 giving a AD security group Full Access to a mailbox will not give user the access..

    Monday, September 26, 2011 7:33 AM
  • Just wanted to post a quick status update.  I'm working with Exchange support (a different tier) now to find the cause of the issue.  So far he hasn't been able to reproduce it.  I just sent off more data to him last week.  I should hear back fairly soon.

    I'll post back with what I find.

    Monday, September 26, 2011 12:13 PM
  • I am also having this problem;

    Im using a Native 2008 R2 SP1 Domain, Exchange 2010 SP1 RU3, and Office 2010 (both SP1 and non SP).

    The domain originally had Exchange 2003, which was upgraded to Exchange 2007, and then Exchange 2010 8 months ago.


    Tuesday, September 27, 2011 10:56 AM
  • Finally got around to testing some more on my end and here what I found

    ·     Granting full access permissions to universal groups (created through the EMC in 2010) on a mailbox works but only after 12- 24 hours

    ·     Even after a group has access any new members will need 12-24 hours to be recognized

    So I'm guessing that in my Active Directory that for some reason Universal Groups are painfully slow to update individual accounts as group members. Now I know Universal groups usually only replicate groups as members and not users, but since my AD is flat (1 one domain, 2 DC's) I’m not sure why I’m having such a hard time pulling user accounts as group members.

    I did try switching the domain controller my Exchange server pointed to but that didn’t help with the issue. Can anyone else confirm if the issue is due to slow Universal group replication in their environment?

    Wednesday, October 5, 2011 6:34 PM
  • Vox Medica,

    You can expedite the process by restarting the Information Store service.

    Wednesday, October 5, 2011 6:48 PM
  • Won't that disconnect everyone from their mailbox? We run in our Outlook clients in cached mode I assume our users would just see a message stating that connection to the mail server has been lost.

    Wednesday, October 5, 2011 7:01 PM
  • Won't that disconnect everyone from their mailbox? We run in our Outlook clients in cached mode I assume our users would just see a message stating that connection to the mail server has been lost.


    Yes it will.  So I'd advise not doing that during working hours.  ;)
    Wednesday, October 5, 2011 7:10 PM
  • I can say for my organization that applying full permission to a group gives members of that group full permission right away. What doesn’t work for me is the members of that group being added to the autoopen list for the mailbox.

     

    I've taken to setting the group I want to give full permission on custom attribute 5:

    Set-Mailbox $samaccountname -CustomAttribute5 (Get-QADGroup $permissiongroup).dn
    


    Then this function runs every 10 minutes as a scheduled task to set the members of that group in the auto-open field:

    function Set-SharedMailboxAutoOpen
        {
        $SharedMailboxes=Get-Mailbox -RecipientTypeDetails SharedMailbox
        foreach ($SharedMailbox in $SharedMailboxes)
            {
            $PermissionGroupMemberDNs=(Get-QADGroupMember -Indirect -Type user -Identity $($SharedMailbox.customattribute5)|%{$_.dn})
            Set-QADUser $SharedMailbox.samaccountname  -ObjectAttributes @{msExchDelegateListLink=$PermissionGroupMemberDNs}
            }
        }
    Set-SharedMailboxAutoOpen
    

    This works 100% of the time, but it's silly that it's necessary. This should just work.


    Ian
    • Proposed as answer by Ian Bruckner Wednesday, October 5, 2011 7:12 PM
    • Unproposed as answer by wchar_t Wednesday, October 5, 2011 7:13 PM
    Wednesday, October 5, 2011 7:11 PM
  • Hi,
    I use security groups a lot when assigning permissions to Shared Mailboxes and I have never had any problemes with that.

    I must ask, After you added the users to the group, did they log off/on before they tried to add the Shared Mailbox as an additional one? (just restarting Outlook will not work)
    If not that would really explain why it takes time before the new permissions takes affect (TGT not updated = Ticket Granted Ticket).


    Martina Miskovic - http://www.nic2012.com/
    Wednesday, October 5, 2011 7:21 PM
  • Hi,
    I use security groups a lot when assigning permissions to Shared Mailboxes and I have never had any problemes with that.

    I must ask, After you added the users to the group, did they log off/on before they tried to add the Shared Mailbox as an additional one? (just restarting Outlook will not work)
    If not that would really explain why it takes time before the new permissions takes affect (TGT not updated = Ticket Granted Ticket).


    Martina Miskovic - http://www.nic2012.com/

    Yes I have.  I've also tried accessing the other mailbox via OWA without any luck.
    Wednesday, October 5, 2011 7:23 PM
  • Ok Good (cause I see this alot when users is not informed to log Off and then back On again on their computers and not just close and open Outlook)
    I hope you find a solution to your problem!
    Martina Miskovic - http://www.nic2012.com/
    Wednesday, October 5, 2011 7:26 PM
  • Martina_Miskovic, to confirm with wchar_t, I’ve tried restarting Outlook, restarting the the PC, rebuilding the Outlook profile, and trying to access from Outlook 2011 (which uses EWS).  All with no luck.

    In the meantime whenever the need arises I give the group and it's individual members full mailbox access and then remove the individual accounts 24 hours later. On a side note I always wondered why when the groups do finally kick in they never auto add the mailbox to the users Outlook file tree. I'll have to look into what imbruck2 posted if once this issues is resolved they still don’t auto add.

    Wednesday, October 5, 2011 7:34 PM
  • Hi Vox Medica,
    Auto-Mapping only works when giving fullmailboxaccess to users and not when security groups is used, so that is expected.

    Martina Miskovic - http://www.nic2012.com/
    Wednesday, October 5, 2011 7:39 PM
  • Hi Vox Medica,
    Auto-Mapping only works when giving fullmailboxaccess to users and not when security groups is used, so that is expected.

    Martina Miskovic - http://www.nic2012.com/

    From what MS support has said so far, that's not correct.  Autodiscovery should work when using groups as well.
    Wednesday, October 5, 2011 7:41 PM
  • Did MS Support really say that Auto-Mapping would work when giving groups fullmailboxpermission?
    In my experience, that is not true.


    Martina Miskovic - http://www.nic2012.com/
    Wednesday, October 5, 2011 7:46 PM
  • Hi Guys

     

    I'm also seeing the same problems.

     

    I created an Ad Security group called "test" and this is a security/Universal group. I added my normal user account to this grop

    I created a shared mailbox on my Exchange 2010 SP1 UR5 Org (all Exchange servers on 2010 SP1 UR5) using the New-Mailbox cmdlet with "-shared" and then gave the security group Full Access permission through the Exchange Console Gui (not via PS)

    24 hours later, on a Windows 7 Enterprise x64 SP1 Machine with Office 2010 SP1 x86 installed, I'm not getting the additional mailbox self populating at all. the msExchDeletageList is also empty.

    If I add myself directly to a mailbox with Full Access Permissions, the mailbox suddenly appears in my outlook (no restart of outlook required)

    something not quite right with reading the groups.

    Maybe enable Universal caching on the GCs?

    Thanks

     

    Andy

    Thursday, October 6, 2011 1:05 PM
  • Andy, thats what I was thinking of trying next even though that option is meant to address replication issues across slow links between Active Directory Sites. Which makes me belive there is either something odd flaw in how Universal Groups are handled in EX2010 or some misconfiguration issue with our all our Gobal Catalong servers.
    Thursday, October 6, 2011 4:35 PM
  • On Thu, 6 Oct 2011 16:35:03 +0000, Vox Medica wrote:
     
    >Andy, thats what I was thinking of trying next even though that option is meant to address replication issues across slow links between Active Directory Sites. Which makes me belive there is either something odd flaw in how Universal Groups are handled in EX2010 or some misconfiguration issue with our all our Gobal Catalong servers.
     
    Exchange (any release after 5.5) has nothing to do with groups other
    than to update properties. The AD is responsible for replication.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Thursday, October 6, 2011 9:50 PM
  • Exchange (any release after 5.5) has nothing to do with groups other
    than to update properties. The AD is responsible for replication.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP

     

    The only reason I mention EX2010 is that previous versions of Exchange didnt require Universal groups and we didnt have the issue until we moved to from EX2003 to EX2010. Granted we moved our AD from 2003 to 2008 R2 first but we were still able to assign permissions to mailboxs via Global groups in EX2003 fairly quickly.  

    Thursday, October 6, 2011 9:58 PM
  • On Thu, 6 Oct 2011 21:58:16 +0000, Vox Medica wrote:
     
    [ snip ]
     
    >The only reason I mention EX2010 is that previous versions of Exchange didnt require Universal groups and we didnt have the issue until we moved to from EX2003 to EX2010.
     
    Although it wasn't _required_ in releases earlier than 2007 (not 2010)
    the use of groups with global or local scopes casued problems.
     
    >Granted we moved our AD from 2003 to 2008 R2 first but we were still able to assign permissions to mailboxs via Global groups in EX2003 fairly quickly.
     
    For group membership to work as people expect, the membership of a
    group must appear in the GCs of all domains in the forest. The only
    group scope that works that way is "universal". Other scopes replicate
    the group membership only in the DCs in the same domain. That AD
    behavior results inconsistent behavior across domains.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Friday, October 7, 2011 1:26 AM
  • For group membership to work as people expect, the membership of a
    group must appear in the GCs of all domains in the forest. The only
    group scope that works that way is "universal". Other scopes replicate
    the group membership only in the DCs in the same domain. That AD
    behavior results inconsistent behavior across domains.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Thats whats bugging me, I have one domain with 2 DC's. Shouldn't universal groups be replicated already, espcially when Exchange 2010 is ponting to the DC holding all my FSMO roles?
    Friday, October 7, 2011 11:38 AM
  • What Domain and Function Level is everyone running at? Specifically I wonder if those working have AD set to 2008 or 2008 R2 vs 2003 Native?


    edit added:

    It is possible to alter how Universal Groups cache on the DCs however given that restarting the InfoStore seems to have an effect I wonder at its polling time against changes on the GC. Anyone know if there is a attribute to effect this?

    Friday, October 7, 2011 4:44 PM
  • I'm still at 2003 native due to some internally developed software still using our Exchange 2003 server and one of our SQL 2000 servers. Once those applications are updated and working I plan to raise our AD to 2008 R2 native.

    Friday, October 7, 2011 5:04 PM
  • I should have mentioned I'm on 2003 Native as well, planning on flipping the flags in 2-3 weeks to 2008R2 Native.
    Friday, October 7, 2011 5:06 PM
  • On Fri, 7 Oct 2011 11:38:48 +0000, Vox Medica wrote:
     
    <>For group membership to work as people expect, the membership of a
    group must appear in the GCs of all domains in the forest. The only
    group scope that works that way is "universal". Other scopes replicate
    the group membership only in the DCs in the same domain. That AD
    behavior results inconsistent behavior across domains. --- Rich
    Matheisen MCSE+I, Exchange MVP
    >>--- Rich Matheisen MCSE+I, Exchange MVP
     
     
    >Thats whats bugging me, I have one domain with 2 DC's.
     
    And both of those DCs are in the same AD forest?
     
    >Shouldn't universal groups be replicated already,
     
    That's easy enough to verify. Use ADUC and onnect to each DC in turn.
    Do you see the same results when you look at the properties of the
    group?
     
    Next, use LDP.exe and connect to each of the GCs (port 3268). Do you
    see the same results?
     
    If you don't see the same thing in both DCs and GCs then you have a
    problem with AD replication, not with Exchange.
     
    >espcially when Exchange 2010 is ponting to the DC holding all my FSMO roles?
     
    FSMO roles mean nothing in this context.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Friday, October 7, 2011 9:42 PM
  • Ok Guys, lets bring this back into context of the real issue here.

    So this is what I did on Friday (7th October 2011) before I went home

    In ADUC I created a new group. This was a Security Universal Group called "Test1". I stuck myself in this

    In ADUC I created another group. This was a Distribution Universal Group called "Test2". I stuck myself in this.

    I created 2 "Shared" mailboxes from EMS with the "-shared" parameter. They created fine.

    SharedMBX1

    SharedMBX2

    In SharedMBX1 I granted my Security Universal Group "Test1" Full Mailbox access using the EMC Gui. I did not add Send As rights to the same group

    In SharedMBX2 I granted my Distribution Universal Group "Test2" Full Mailbox access using the EMC Gui. I did not add Send As Rights to the same group

    I left for the weekend

    On coming back I rebooted my machine (Windows 7 Enterprise X64 SP1 with Office 2010 x86 SP1) and opened Outlook. NEITHER Mailbox was auto listed.. even after a few hours

    I checked the following attributes of both the Shared Mailboxes I created

    msExchDeletegateListBL

    msExchDelegateListLink

     

    Both were still empty. I verified no AD replication issues.

    Again, running Exchange 2010 SP1 with UR5 across all our Exchange 2010 servers.

     

    I'm 99.9% sure this is a bug. I saw this in Exchange 2007 too.

    Cheers

     

    Andy

     

     p.s. Found this link: http://ibenna.wordpress.com/2011/09/12/automapping-to-a-group/

     

    While it states that Automapping doesnt work (as we are experiencing) it says you should be able to add the mailbox as an "Additional Mailbox" and it should work. For me, that doesnt work either. I get "Cannot expand the folder"

    A.

     

     


    • Edited by Andyhud Tuesday, October 11, 2011 11:22 AM
    Tuesday, October 11, 2011 10:31 AM
  • You've found exactly what I have. Customers can manually open a mailbox the old way after being given full permission, but it won't auto-open. I too think this should automatically work, but the fact remains that it won't.

    *I'll note that I use Quest Active Directory (QAD) commandlets in my examples. If you run these, you'll need to make sure you have them installed and in memory.

    You have a mailbox with a samaccountname of: "mailbox_xyz"
    You have a security with a samaccountname of: "mailbox_xyz"_fullpermission", which is not mail-enabled.
    Customers (or their nested role groups) are a member of: "mailbox_xyz"_fullpermission"

    I've taken to setting the group I want to give full permission  on custom attribute 5 so that I can reference it later when adding it's members to the auto-open list (customers won't need to log off/on for this to work since it's not AD based): 

    $samaccountname="mailbox_xyz"
    $permissiongroup="mailbox_xyz_fullpermission"

    Set-Mailbox $samaccountname -CustomAttribute5 (Get-QADGroup $permissiongroup).dn

    If you want the accounts in the permission group to "send as" the mailbox, you also run this line (customers will need to log off/on after this permission is given since it's AD based):

     

    Add-QADPermission -Identity $samaccountname -Account $permissiongroup -ExtendedRight 'Send-As','Receive-As' -ApplyTo 'ThisObjectOnly'
    

    I run this this function runs every 10 minutes as a scheduled task on a server to set the members of that group in the auto-open field. If you remove anyone from the group, it will remove them from the auto-open list. This becomes effective the next time a given customer opens MS Outlook (customers won't need to log off/on for this to work since it's not AD based): : 

     

    function Set-SharedMailboxAutoOpen
        {
        $SharedMailboxes=Get-Mailbox -RecipientTypeDetails SharedMailbox
        foreach ($SharedMailbox in $SharedMailboxes)
            {
            $PermissionGroupMemberDNs=(Get-QADGroupMember -Indirect -Type user -Identity $($SharedMailbox.customattribute5)|%{$_.dn})
            Set-QADUser $SharedMailbox.samaccountname  -ObjectAttributes @{msExchDelegateListLink=$PermissionGroupMemberDNs}
            }
        }
    Set-SharedMailboxAutoOpen
    


    This works 100% of the time, but it's silly that it's necessary. This should just work.


    Ian
    • Proposed as answer by Ian Bruckner Tuesday, October 11, 2011 1:57 PM
    • Edited by Ian Bruckner Tuesday, October 11, 2011 2:02 PM
    • Unproposed as answer by wchar_t Tuesday, October 11, 2011 2:15 PM
    Tuesday, October 11, 2011 1:57 PM
  • I'm 99.9% sure this is a bug. I saw this in Exchange 2007 too.

    ...

     p.s. Found this link: http://ibenna.wordpress.com/2011/09/12/automapping-to-a-group/

     

    While it states that Automapping doesnt work (as we are experiencing) it says you should be able to add the mailbox as an "Additional Mailbox" and it should work. For me, that doesnt work either. I get "Cannot expand the folder" 

     



    I didn't have 2007 prior so I wasn't sure if this existed there or not.  And you are correct on the additional mailbox option.  I get the same error.  Happens in OWA as well.

    imbruck2,
    I only unmarked the solution you proposed because it doesn't actually fix the issue.  It is a good workaround and will be helpful until MS decides to really look into this.  I just sent off another email to tech support.


    • Edited by wchar_t Tuesday, October 11, 2011 2:17 PM
    Tuesday, October 11, 2011 2:15 PM
  • I am agree with you, previously I was able to assign a Security Group to have a full access to an exchange mailbox.

    It was before I was migrating all mailbox from SBS2008 (which is Exchange 2007) to Exchange 2010 SP1.

     

    Today I was creating similar proxy mailbox and want to assign a Security Group but it cannot be done through EMC.

     

     

    Thursday, October 13, 2011 8:56 AM
  • @Rich Matheisen

    Universal Groups and group members show up on both DC’s immediately after creation, and both DC’s are in the same forest and domain. I tried using LDP but wasn’t sure what to look for but the initial query gave similar results when used against both DC’s

    @Everyone else

    To further isolate the issue to EX2010 I created 3 test groups:

    01 – Universal group with my account as a member
    02 – Global group with my account as a member
    03 – Universal group containing a Global Group I belong to

    For all three groups I verified that they appeared on both of my DC’s after creation, I created group 01 on my first DC and the other two on my 2<sup>nd</sup> DC. All groups appeared instantaneously on both DC’s after creation.

    I then, one by one, assigned each group access permissions to a share on one of my file servers. Both Universal groups (01 and 03) required a log off/log on before I could access the share on the PC I tested on. Once they worked any other PC I was logged into still couldn’t access it unless I logged off. I read somewhere in my research that Universal groups membership is only once at login by the PC and this appears to be the case

    The Global group worked within a few minutes of being created

    I then tried assigning the two Universal groups full access to a mailbox I did not have prior access and then tried to open the mailbox through Outlook 2007. Each time I encountered the same error we have all been dealing with, just for kicks I gave each a 2<sup>nd</sup> try after logging in and out but the result was the same.

    So I think we can rule out issues with everyone’s Global catalog servers seeing that in my testing our file servers handled Universal group membership just fine. So I wonder if Exchange is exhibiting the same behavior as my desktops, that is not processing the group membership until a login event or 24 hours later. I’m going to keep my one PC logged in to see if the Universal group is recognized by it 12-24 hours later.

     

    Thursday, October 13, 2011 8:56 PM
  • did you manage to get this one sorted?

     

    I am having the same issues (though not relly intrested in the auto mapping feature). All i am trying to do is nest a few security groups with another security group and apply that group with full mailbox access to the Mailbox. Any users that are members of the nested security groups (All Universal) cannot access the mailbox when added into Outlook as an additional mailbox. Giving a user exclusive full access to the mailbox works with no problems! 

     

    We are running Exchange 2010SP1 RU5 and coexistance with Exchange 2003


    Thursday, November 17, 2011 4:30 PM
  • same problem here. able to view the mailbox using the security group membership but not send-as

    we are on SP1 RU6. surely there is a solution to this by now

     

     

    Friday, December 2, 2011 10:45 AM
  • Apparently RU5 was supposed to resolve this issue. This is a major booboo from Microsoft, and there is no mention of it in SP2 :(
    Friday, December 2, 2011 11:55 AM
  • we have noticed that legacy permissions seem to work - mailboxes that had the permissions set before environment was upgraded from 2007 to 2010 are fully functional. new ones however only allow view, not send-as

     

     

    Friday, December 2, 2011 2:37 PM
  • Hi all, and update in regards to our problems with nested groups.

    After applying RU6 on to all MB\CAS\Hub servers, our nested groups now seem to be working OK. We have done extensive testing over the last few days and all seems to be OK (Though still not removing the DelegateListLink ADSI Attribute!). Although the fix is not listed in the RU6 issues list, i suspect MS have sneaked it in as the RU5 update was supposed to fix this and never did!

     

    Hope this info helps you all out

    • Proposed as answer by DaveHoward79 Thursday, January 5, 2012 10:15 AM
    Wednesday, December 7, 2011 10:54 AM
  • Hi all, and update in regards to our problems with nested groups.

    After applying RU6 on to all MB\CAS\Hub servers, our nested groups now seem to be working OK. We have done extensive testing over the last few days and all seems to be OK (Though still not removing the DelegateListLink ADSI Attribute!). Although the fix is not listed in the RU6 issues list, i suspect MS have sneaked it in as the RU5 update was supposed to fix this and never did!

     

    Hope this info helps you all out


    I have RU6 waiting to deploy.  Hopefully it fixes it.  From what the Exchange engineer I talked to said, they don't publish all fixes in RU or SP.  So it could very well be in there and just not made public.
    Thursday, January 5, 2012 1:32 PM
  • We recently applied EX2010 SP2 over the weekend and in our enviroment the issue still remains.
    Friday, January 6, 2012 7:35 PM
  • I too continue to have this issue... has anyone heard anything further from MS?

     


    -DEMPC
    Monday, January 30, 2012 9:43 PM
  • I have RU6 waiting to deploy.  Hopefully it fixes it.  From what the Exchange engineer I talked to said, they don't publish all fixes in RU or SP.  So it could very well be in there and just not made public.

    Did this fix the issue for you in the end? We are having the same issue with nested groups and are currently on SP1. thanks

    Friday, February 24, 2012 4:39 PM
  • I have SP2 installed and it is still not working for me... FYI

    -DEMPC

    Friday, February 24, 2012 4:48 PM
  • Looking over the KB for SP2 RU1, it doesn't look like the issue was addressed

    http://support.microsoft.com/kb/2645995

    Friday, February 24, 2012 4:56 PM
  • I have RU6 waiting to deploy.  Hopefully it fixes it.  From what the Exchange engineer I talked to said, they don't publish all fixes in RU or SP.  So it could very well be in there and just not made public.

    Did this fix the issue for you in the end? We are having the same issue with nested groups and are currently on SP1. thanks

    Actually, it has so far.  I haven't had issues adding them to an Outlook profile or opening via OWA.  I will say that permissions take a bit to take effect sometimes.

    Just a quick note.  Outlook will not automatically add mailboxes unless you assign permissions with the user account.  Outlook does not attempt to expand groups looking for users.  That said, I wonder if nested groups are supported at all?  I haven't tried them out yet.

    Friday, February 24, 2012 5:25 PM
  • Just a quick note.  Outlook will not automatically add mailboxes unless you assign permissions with the user account.  Outlook does not attempt to expand groups looking for users.  That said, I wonder if nested groups are supported at all?  I haven't tried them out yet.

    That's precisely the functionality that i am looking for. I want to be able to grant a group full access permission the mailbox rather than assigning each user full access permissions


    -DEMPC

    Friday, February 24, 2012 5:40 PM
  • @ DEMPC, you can pull that off with some powershell scripting. imbruck2 has posted a way to do so earlier in the thread, i tested it and it works as advertised but it is a little cumbersome to resort to such a method.

    @ wchat_t, so it is working for you? I still have to wait around 24 hours in my environment. Are you seeing a much quicker turn around time now?

    Friday, February 24, 2012 5:47 PM
  • @ wchat_t, so it is working for you? I still have to wait around 24 hours in my environment. Are you seeing a much quicker turn around time now?

    Hate to say it, but it depends.  Sometimes its quick.  Other times I have to wait a day.  Same with removing permissions.

    Not to muddy the waters any, but I found another bug.  If you add a user and a group with full access to a mailbox and that use happens to be in the group as well, Outlook doesn't like it.  It caused rule issues, "cannot expand folder" errors.  Granted, it was my fault for having both there, but you'd think it wouldn't matter.

    Friday, February 24, 2012 5:55 PM
  • @ DEMPC, you can pull that off with some powershell scripting. imbruck2 has posted a way to do so earlier in the thread, i tested it and it works as advertised but it is a little cumbersome to resort to such a method.

    @ wchat_t, so it is working for you? I still have to wait around 24 hours in my environment. Are you seeing a much quicker turn around time now?

    Agreed, cumbersome indeed. Do you think this functionality will ever exists in future updates?


    -DEMPC

    Wednesday, February 29, 2012 3:53 PM
  • Looking at the timing of the issue, perhaps it is related to OAB generation and updates on the Outlook client.

    Are the folks having the issue using Cached mode on Outlook, what happens if you disable cached mode?

    Friday, March 23, 2012 12:30 AM
  • We have noticed the issue with both cached and unchaced outlook 2007/2010 clients. I think the issue is due to the replication of universal groups memberships as opposed to Off line address book generations. Good thinking though!
    Friday, March 23, 2012 5:13 PM
  • I'm having the same issue, did you every get a resolution from Microsoft?

    george

    Friday, April 27, 2012 3:14 PM
  • Hi,

    I had similar issues and found the solution here:

    http://blogs.msdn.com/b/pepeedu/archive/2010/08/26/how-to-upgrade-a-universal-distribution-group-to-a-universal-security-group.aspx

    Solution without explanation:

    1) try:  set-distributiongroup -identity <alias of your group>
    If "nothing" happens (command accepted without feedback) or you get some yellow lines that nothing has been changed, you are finished.

    This can run in an error: Members can’t remove themselves from security groups. Please set the group to Closed for requests to leave.

    2) Do so:  set-distributiongroup -identity <alias of your group> -memberdepartrestriction closed

    3) try 1) again

    You should be able to add the group to calender permissions now, give full access or use it in a similar way. Also the "red deny" symbol in address lists should be gone. All group with this symbol may have the same problem.

    Good luck

    Frank



    • Edited by Henti Monday, May 21, 2012 1:56 PM
    Monday, May 21, 2012 11:50 AM
  • EDIT!!!!

    I found out that I was inheriting a deny for the user account I was testing.  This caused the group to be overridden; but applying the individual user full mailbox permission directly overrode the deny. 

    I had to run

    "Get-MailboxPermission "<shared mailbox>" -user | FL User, AccessRights, IsInherited, Deny" to see what was happening.  

    I had to remove the deny permission for it to work using this command:

    Remove-MailboxPermission -Identity '<shared mailbox>' -User '<user>' -Deny -InheritanceType 'All' -AccessRights 'FullAccess'

    Hope this helps someone that may have a similar problem. 

    JD


    Wednesday, June 27, 2012 6:02 PM
    1. this may be a bug.  Even with the latetst rollup.
    2. Similar to, if you try to give the send-as permission to a DL via EMS on another Exch server than to the one you created to the DL on, it will fail, because the local exchange server in the owner and not the Exchnage Servers groups.
    3. Similar if you create a DL in ADUC, it will fail because the domain admins are the owners and not the Exchange server groups.
    4. Workaround for these is to give the exch servers group modify permission
    5. I will find out about this next week.

    Sukh

    This worked like a charm for me.  Seems to be related to the security relationship between Exchange and the AD objects. 

    To clarify:

    1. I was running in to this issue when trying to grant full access to resources via a security group.
    2. I access a/the resource in AD, brought up the security tab, granted Exchange Servers full control to the AD object.
    3. Viola!  almost instantaneously members of the security group can now access those resources. 
    • Proposed as answer by Guyver-1 Thursday, March 6, 2014 9:23 PM
    Tuesday, July 3, 2012 5:54 PM
  • Please see Sukh282's post from Sept 24, 2011 10:02 pm.  It worked for me, even though it's more of a workaround than a fix.  Shame on you MS for yet another stupid bug that we have to figure out for you. 
    Tuesday, July 3, 2012 5:56 PM
    1. this may be a bug.  Even with the latetst rollup.
    2. Similar to, if you try to give the send-as permission to a DL via EMS on another Exch server than to the one you created to the DL on, it will fail, because the local exchange server in the owner and not the Exchnage Servers groups.
    3. Similar if you create a DL in ADUC, it will fail because the domain admins are the owners and not the Exchange server groups.
    4. Workaround for these is to give the exch servers group modify permission
    5. I will find out about this next week.

    Sukh

    This worked like a charm for me.  Seems to be related to the security relationship between Exchange and the AD objects. 

    To clarify:

    1. I was running in to this issue when trying to grant full access to resources via a security group.
    2. I access a/the resource in AD, brought up the security tab, granted Exchange Servers full control to the AD object.
    3. Viola!  almost instantaneously members of the security group can now access those resources. 
    This worked wonderfully, Thank you!!!
    Thursday, July 5, 2012 1:51 PM
  • Hi ,

    With exchange servers do you mean the Exchange domain servers or the Exchange Enterprise servers ?

    Thank you all for this workaround..

    Tuesday, July 10, 2012 10:23 AM
  • Hi ,

    With exchange servers do you mean the Exchange domain servers or the Exchange Enterprise servers ?

    Thank you all for this workaround..


    Exchange servers will do.

    Sukh

    Tuesday, July 10, 2012 11:46 AM
  • Hi all,

    i still have the issue with granting access to a shared mailbox via a security group, the attribute msExchDelegateListLink of the Shared mailbox does not get filled so users who are member of that group still does not get the sharedmailbox automatically in their outlook 2010, but users are able to manually add the mailbox. offcourse adding the user separately  will add the mailbox automatically but I wont believe Microsoft intended it to have it work this way.   I have tried the sollution mention above with setting the permissions for the exchange group to the AD object, but that didn't do the trick for me.  if there something i missed or someone has a workaround .. please let me know..  in advance thanks all for your help.

    Wednesday, July 11, 2012 9:23 AM
  • Hi,
    I can understand that you think it's an issue, but as I wrote earlier in this thread that is expected.

    Auto-Mapping will only work when given fullmailboxaccess to mailboxes and that is By Design (a linked attribute is used)

    Martina Miskovic

    Wednesday, July 11, 2012 9:29 AM
  • Hi martina,

    Thank you for your reply, it looks like i have to live with this.. Hope that this "Design" will be reviewed/changed with the next RU/Exchange version  :).

    Wednesday, July 11, 2012 9:47 AM
  • Hi martina,

    Thank you for your reply, it looks like i have to live with this.. Hope that this "Design" will be reviewed/changed with the next RU/Exchange version  :).


    Hi GreenGolfer,
    I hope so too, cause I really like Automapping.

    Martina Miskovic

    Wednesday, July 11, 2012 9:52 AM
  • We had exact same problem with groups not working with shared mailboxes.  Sukh828's number 4 item resolved it, as with others.  It's an issue with migrating from older Exchange where new permissions for Exchange Servers group are added into AD, but it may not get the right permissions it needs.  If you give the group Full Control in AD, it can then read and set the group permissions.

    • Edited by Daedorion Thursday, August 30, 2012 3:46 AM spelling
    Thursday, August 30, 2012 3:35 AM
  • We had exact same problem with groups not working with shared mailboxes.  Sukh828's number 4 item resolved it, as with others.  It's an issue with migrating from older Exchange where new permissions for Exchange Servers group are added into AD, but it may not get the right permissions it needs.  If you give the group Full Control in AD, it can then read and set the group permissions.

    Can you explain this to me?? Sukh828's number 4 doesn't mean a lot to me..


    I'm in the same situation. I have migrated from Exchange 2003 to Exchange 2010 and when I add Full Access to a Group, no access is granted. I'm having to grant Full Access to each user one by one and it's a major pain.

    Friday, September 14, 2012 5:18 AM
  • I have the same issue as described here too... what are the steps I need to do with Exchange Server group?

    DURP

    • Proposed as answer by abarker81 Thursday, September 18, 2014 7:54 PM
    • Unproposed as answer by abarker81 Thursday, September 18, 2014 7:54 PM
    Tuesday, September 18, 2012 2:05 PM
  • I know this thread is a bit old but I really liked this solution and wanted to post a reply. I found I needed to tweak the Set-MailboxSharedAutoOpen function some since I'm not using the Quest commandlets. Here's what's working for me;

    function Set-SharedMailboxAutoOpen
     {
     $SharedMailboxes=Get-Mailbox -RecipientTypeDetails SharedMailbox
     foreach ($SharedMailbox in $SharedMailboxes)
      {
      $PermissionGroupMemberDNs=(Get-ADGroupMember -Identity $($SharedMailbox.CustomAttribute5) | %{$_.distinguishedname})
      Set-ADObject $SharedMailbox.distinguishedname -Replace @{msExchDelegateListLink=$PermissionGroupMemberDNs}
      }
     }
    Set-SharedMailboxAutoOpen

    Friday, September 21, 2012 6:22 PM
  • Even though it's 2013 it seems like we have the same problem with SP2 + RU3. Did anyone got this case solved/confirmed by Microsoft in the end or are we still using workarounds to give a Universal Group Full Mailbox Access?
    Friday, January 4, 2013 1:40 PM
  • I never got a proper fix.

    I worked around it by creating a script which gets the members of an AD Mail Enabled security group, and updates the full access based on the groups members.

    Here's a script I'm running every hour which updates permissions. It's probably not the most efficient script ever, but it works. It has several benefits

    1. Managers of the distribution group can add/remove mailbox members using OWA or through the address list
    2. New members of groups are added to FULL Access Permissions
    3. Members removed from the groups are removed from FULL access permissions
    4. Automapping works :)
    5. Maintains a log of access added / removed / time taken etc.

    Obviously I have had to remove domain related information, replace with whatever your domain requirements are, and PLEASE debug it properly in your environent first, don't complain to me if it wipes out a load of access for you or something like that!

    It takes about 5 minutes to run in my environement. Some formatting seems to have got messed up on here, sorry. I hope it is of use!

    #---------------------------------------------------------------------------------------------#
    # Mailbox Permissions Setter for Exchange                                                     #
    # v1.1                                                                                        #
    # This script will loop through all mailboxes in Exchange and find any where                  #
    # the type is 'SHARED'. These should be determined to be a GROUP/SHARED mailbox               #
    # and access to these mailboxes are controlled by a single ACL, e.g. 'ACL_Shared_Mailbox'.    #
    # This script will add any members of these ACLs directly to the Full Access Permissions      #
    # of the mailbox and also remove them if they no longer need the access.     			      #
    #---------------------------------------------------------------------------------------------#
    #
    # Script created by Jon Read, Technical Administration
    #
    # Recent Changes
    # -----------------------------------
    # 
    # 15/11/2012
    # 1.1 Added exclusions for ACLs that we don't want automapping to happen for
    # 
    # 12/11/2012
    # 1.0 Initial script 
    #
    #
    #
    #Do not change these values
    #----------------------------
    Add-PSSnapin *Ex*
    $starttime = Get-Date
    $logfile = "C:\accesslog.txt"
    $logfile2 = "C:\accesslog2.txt"
    $totaladditionstomailboxes = 0
    $totalremovalsfrommailboxes = 0
    $totalmailboxesprocessed = 0
    $totalmailboxesskipped = 0
    #----------------------------
    
    # Exclude any ACLs that shouldn't be processed here if they are used for a non-standard purpose and
    # we don't want FULL access mapping to happen. Seperate array values with commas
    #----------------------------
    $ExcludedACLArray = "DOMAIN\ACL_ExcludedExample"
    #----------------------------
    
    Write-Output " " >> $logfile
    Write-Output " " >> $logfile
    Write-Output "#----------------------------------------------------------------#" >> $logfile
    Write-Output "# Mailbox Permissions Setter for Exchange                        #" >> $logfile
    Write-Output "# v1.1                                                           #" >> $logfile
    Write-Output "#----------------------------------------------------------------#" >> $logfile
    Write-Output " " >> $logfile
    Write-Output " " >> $logfile
    Write-output "Start time  $starttime ">> $logfile
    Write-Output " " >> $logfile
    Write-Output " " >> $logfile
    
    
    # Set preferred DCs and GCs 
    $preferredDC = "preferredDC.domain"
    $preferredGC = "preferredGC.domain"
    Write-Output " PreferredDC = $preferredDC ">> $logfile
    Write-Output " PreferredGC = $preferredGC " >> $logfile
    Set-ADServerSettings -PreferredGlobalCatalog $preferredGC -SetPreferredDomainControllers $preferredDC
    
    
    # The first part of this will ADD permissions to the mailbox, reading from an associated ACL.
    #---------------------------------------------------------------------------------------------
    
    # Check for all mailboxes where the type is SHARED. These are the only ones we would
    # want to apply group mailbox permissions to.
    foreach ($mailbox in get-mailbox -resultsize "unlimited" | where-object {$_.RecipientTypeDetails -eq "SharedMailbox"})
    {
    	$totalmailboxesprocessed = $totalmailboxesprocessed + 1
    	Write-Output " " >> $logfile
    	Write-Output " " >> $logfile
    	Write-Output "|-------------------------------------------------------" >> $logfile
    	Write-Output "|  MAILBOX ADDITIONS: $mailbox " >> $logfile
    	Write-Output "|-------------------------------------------------------" >> $logfile
    	$mailbox=$mailbox.ExchangeGuid.ToString()
    	
    	# For each of them, get the distribution list applied to the mailbox (Starting DOMAIN\ACL_)
    	# We then need it to be turned into a string to use later.
    	
    	#Declared $changes as 0. if this is set to 0 at the end of the mailbox job, we know no changes were made.
    	$changes = 0
    	
    	foreach ($distributiongroup in get-mailbox $mailbox | Get-MailboxPermission | Where-Object {$_.User -like "DOMAIN\ACL_*" })
    	{
    	$skipACL = 0
    	
    	#Get the distribution group and put the name in a useable format
    	$distributiongroup=$distributiongroup.user.tostring()
    	Write-Output "Found ACL $distributiongroup" >> $logfile
    		
    	# Check if this distribution group needs to be excluded and if it shouldn't be processed
    	# then move onto the next ACL. This will stop FULL access being granted if the mailbox is
    	# used for a non-standard purpose. See the start of this script
    	# for where these are excluded (ExcludedACLArray)
    	
    	foreach ($ACL in $ExcludedACLArray )
    		{
    		if ($distributiongroup -eq $ACL)
    			{
    			$skipACL = 1
    			Write-Output "ACL $distributiongroup is excluded so skipping mailbox " >> $logfile
    			$totalmailboxesskipped = $totalmailboxesskipped + 1
    			}
    		}	
    		
    	if ($skipACL -eq 0)
    		{
    		# Get each user in this group and for each of them, add try to add them to full access permissions.
    			foreach ($user in Get-DistributionGroupMember -identity $distributiongroup)
    			{
    				# Get the user to try, convert to DOMAIN\USER to use shortly
    				$user="DOMAIN\" + $user.alias.ToString()
    				
    				# Check to see if the user we have chosen from the ACL group already exists in the full access
    				# permissions. If they do, set $userexists to 1, if they do not, leave $userexists set to 0.
    				
    				# Set $userexists to 0 as the default
    				$userexists = 0
    							
    					foreach ($fullaccessuser in get-mailbox $mailbox | Get-MailboxPermission) 
    					{
    									
    						# See if the user exists in the mailbox access list.
    						# Change $fullaccessuser to a useable string (matching $user)
    						$fullaccessuser=$fullaccessuser.user.tostring()
    										
    						if ($fullaccessuser -eq $user)
    						{
    							$userexists=1
    							
    							# Break out of foreach if the user exists so we don't unnecessarily loop 
    							break
    						}
    					}			
    					
    				# Now we know if the user needs to be added or not, so run code (if needed) to add
    				# the user to full access permissions
    					
    				if ($userexists -eq 0)
    				{
    					Add-MailboxPermission $mailbox –user $user –accessrights "FullAccess"
    					Write-Output "Added $user " >> $logfile
    					$changes = 1
    					$totaladditionstomailboxes = $totaladditionstomailboxes + 1
    				}
    			#Now repeat for other users in the ACL
    			}
    		}
    	}
    	
    	#if changes were 0, then log that no changes were made
    	if ($changes -eq 0)
    	{ 
    	Write-Output "No changes were made." >> $logfile
    	} 
    	
    }
    
    
    	Write-Output " " >> $logfile
    	Write-Output " " >> $logfile
    	Write-Output "---------------------------------------------------------------------------------" >> $logfile
    	Write-Output "                        FINISHED ADDING PERMISSIONS" >> $logfile
    	Write-Output "---------------------------------------------------------------------------------" >> $logfile
    	Write-Output " " >> $logfile
    
    
    
    
    # The second part of this will REMOVE permissions from the mailbox, reading from an associated ACL.
    #--------------------------------------------------------------------------------------------------
    #
    #
    ## Check for all mailboxes where the type is SHARED. These are the only ones we would
    ## want to apply group mailbox permissions to.
    #
    foreach ($mailbox in get-mailbox -resultsize "unlimited" | where-object {$_.RecipientTypeDetails -eq "SharedMailbox"})
    {
    	Write-Output " " >> $logfile
    	Write-Output " " >> $logfile
    	Write-Output "|-------------------------------------------------------" >> $logfile
    	Write-Output "|  MAILBOX REMOVALS : $mailbox " >> $logfile
    	Write-Output "|-------------------------------------------------------" >> $logfile
    	$mailbox=$mailbox.ExchangeGuid.ToString()
    
    	#Declared $changes as 0. if this is set to 0 at the end of the mailbox job, we know no changes were made.
    	$changes = 0
    		
    	
    	# For the current mailbox, get a list of all users with FULLACCESS, and then for each of them
    	# check if they exist in the ACL
    	foreach ($fullaccessuser in get-mailbox $mailbox | Get-MailboxPermission | Where-Object {$_.Accessrights -like "FullAccess" }) 
    	{
    		# Get the security identifier (SSID) of the FULLACCESS user to store for later.
    		$fullaccessuserSSID=$fullaccessuser.user.SecurityIdentifier.ToString()
    		$fullaccessuser=$fullaccessuser.User.ToString()
    
    		
    		#If user needs to be excluded then skip this bit
    		#Users added or removed will only start with 07 (07$, 07T, so only run if the user starts with this.
    		#This stops it trying to remove NT AUTHORITY\SELF and other System entries
    		
    		if ($fullaccessuser -like "DOMAIN\07*")
    		{
    			# Set $userexists to be 0. if we find the use user needs to remain, then change it to 1.
    			$userexists=0
    			
    			# Check if this user exists in the ACL, if not, remove.
    						
    			foreach ($distributiongroup in get-mailbox $mailbox | Get-MailboxPermission | Where-Object {$_.User -like "DOMAIN\ACL_*" })
    			{		
    				$distributiongroup=$distributiongroup.user.tostring()
    				#Write-Output "Found associated distribution group $distributiongroup" >> $logfile
    				
    				# Get each user in this group and for each of them, See if it matches the user in the mailbox.
    				foreach ($user in Get-DistributionGroupMember -identity $distributiongroup)
    				{
    									
    					# Get the user to try, convert to DOMAIN\USER to use shortly
    					$userguid = $user.Guid.ToString()
    					$user="DOMAIN\" + $user.alias.ToString()
    					
    					if ($fullaccessuser -eq $user) 
    					{
    						$userexists=1
    						#we have found the user exists so no need to continue
    						break
    					}
    				}
    			}
    		# If userexists = 0, then they are NOT in the ACL, and should be removed from
    		# the full access permissions. Run the code to remove them from full access.
    		
    		#CONVERT FULLACCESSUSER TO GUID AND REMOVE $FULLACCESSUSERGUID NOT $USERGUID
    		
    		
    		if ($userexists -eq 0)
    			{
    			Remove-MailboxPermission -Identity $mailbox –user $fullaccessuserSSID –accessrights "FullAccess" -Confirm:$false
    			Write-Output "Removed $fullaccessuser " >> $logfile
    			$changes = 1
    			$totalremovalsfrommailboxes = $totalremovalsfrommailboxes + 1
    			}
    		}
    	}
    			# if changes = 0, no changes were made to this mailbox, so log this fact.
    		if ($changes -eq 0)
    			{ 
    			Write-Output "No changes were made." >> $logfile
    			}
    }
    
    #Put the time in a displayable format
    $endtime = Get-Date
    $runtime = $endtime - $starttime
    $runtime = $runtime.ToString()
    $runtime1 = $runtime.split(".")
    $totaltime = $runtime1[0]
     
    	Write-Output " " >> $logfile
    	Write-Output " " >> $logfile
    	Write-Output "|-------------------------------------------------------------------------------------- " >> $logfile
    	Write-Output "|  SCRIPT COMPLETE : STATS " >> $logfile   
    	Write-Output "|-------------------------------------------------------------------------------------- " >> $logfile
    	Write-Output "| Total Mailboxes Processed                  : $totalmailboxesprocessed " >> $logfile
    	Write-Output "| Total Additions                            : $totaladditionstomailboxes " >> $logfile
    	Write-Output "| Total Removals                             : $totalremovalsfrommailboxes " >> $logfile
    	Write-Output "| Total Mailboxes Skipped due to ACL         : $totalmailboxesskipped " >> $logfile
    	Write-output "| Start time                                 : $starttime ">> $logfile
    	Write-output "| End time                                   : $endtime ">> $logfile
    	Write-Output "| **END OF RUN** - Elapsed time              : $totaltime " >> $logfile
    	Write-Output "|---------------------------------------------------------------------------------------" >> $logfile
    	Write-Output " " >> $logfile
    	
    	
    	
    	
    
    	
    	




    • Edited by Jon __R Friday, January 4, 2013 2:05 PM
    • Proposed as answer by MikaelJones Wednesday, January 16, 2013 1:07 PM
    Friday, January 4, 2013 2:00 PM
  • GREAT script - thanks a lot!

    I will also go ahead and maybe post this at Microsoft's managed newgroups for partners and see if they can confirm if this still a bug or whatever the problem might be.

    • Proposed as answer by WickedWolfie Thursday, January 10, 2013 3:44 PM
    • Unproposed as answer by WickedWolfie Thursday, January 10, 2013 3:44 PM
    Friday, January 4, 2013 2:22 PM
  • Hi all,

    Here's the fix that worked for us;

    In AD users and computers check the properties of the group that you have granted full access to the mailbox in exchange.

    On the security tab, go into the advanced settings. Find an entry for "Exchange Servers" and tick the "Read Members" box to grant permission. This allows all the exchange servers to see who's in the security group.

     

    We just found this today but from reading through this thread it makes sense. We have a fairly simple set up which elimited a lot of the trouble shooting options. Users don't have their own mail boxes, just the shared one. All users use owa with a shortcut to the mailbox.

    Today we had two test users in the group, one could access the mailbox, one couldn't. Not sure of the exact cause but it appears to be that owa hosted on the first exchange server (of 4) group worked, but on the second server new group members couldn't access the mailbox. It also appeared that older user accounts had a better change of getting in to the mailbox.

    Hope this helps...

    • Proposed as answer by Zilvak Tuesday, February 12, 2013 2:24 PM
    Thursday, January 10, 2013 3:44 PM

  • Thanks,  WickedWolfie,
    I tried this - it works.

    Our infrastructure:
    - Exchange 2010
    - Outlook 2013
    - Security groups nesting: users -> Global group -> Domain local group -> Mailbox permissions (full access, send as permissions)
    I changed permissions for Domain local group only.

    Tuesday, February 12, 2013 2:33 PM
  • Hi all,

    Here's the fix that worked for us;

    In AD users and computers check the properties of the group that you have granted full access to the mailbox in exchange.

    On the security tab, go into the advanced settings. Find an entry for "Exchange Servers" and tick the "Read Members" box to grant permission. This allows all the exchange servers to see who's in the security group.

     

    We just found this today but from reading through this thread it makes sense. We have a fairly simple set up which elimited a lot of the trouble shooting options. Users don't have their own mail boxes, just the shared one. All users use owa with a shortcut to the mailbox.

    Today we had two test users in the group, one could access the mailbox, one couldn't. Not sure of the exact cause but it appears to be that owa hosted on the first exchange server (of 4) group worked, but on the second server new group members couldn't access the mailbox. It also appeared that older user accounts had a better change of getting in to the mailbox.

    Hope this helps...

    Does the group have to be mail enabled to work???

    Thursday, March 14, 2013 3:22 PM
  • I had the same problem

    I added a mailbox to user account, granded that user group a full permision, then cheked in outlook and there are no access to data

    a solution that worked for me is:

    I defined a local profile in outlook containing only the user mailbox which I granded permition to, and loged on to it using the credentials of the usere I gave a permition to, then loged of and on using the standart profile, then it worked for me

    • Proposed as answer by sami97 Wednesday, June 12, 2013 9:01 AM
    Wednesday, June 12, 2013 9:00 AM
  • Our company has had the same issue. We Migrated from 2007 to 2010, any existing global/security group works fine. any new groups created that is a global/security group doesnt work. Once making it a Universal/security group it would work.

    I wonder if 2010 only works with universal security groups and not global groups

    Thursday, August 15, 2013 4:04 PM
  • You are right. Exchange 2010 and later version support only the Universal Distribution Group

    This link will help you to understand it better

    http://www.expta.com/2009/10/how-to-convert-local-and-global-groups.html

    Thursday, August 15, 2013 4:56 PM
  • I am unable to find the "Read Members" permissions located on the Universal Security Group to assign it to the "Exchange Servers" group, though even if I did, it would be a work around. 

    A few months ago (Nov 2013) I opened a ticket with premier support (113110510920596) and after submitting a bunch of data and performing a fair amount of up-front troubleshooting, we never could come to a resolution.  They seemed to think the problem was with Active Directory and not Exchange.  I've re-opened the case but I'm wondering if anyone else has specific cases we can have the engineer reference to find the root cause of the problem.  This is nuts that this problem has been going on this long without a specific identified solution and nothing more than a few work arounds.

    Friday, February 7, 2014 9:20 PM
  • To find the "Read Members" permission

    If you just want this for one group open that Security group, if you want it to inherit for all objects go to Microsoft Exchange Security Groups and open Exchange Servers.

    Click the Security Tab | Click Advanced | Sort by Name and find Exchange Servers

    The first Exchange Servers in the list only applies to Descendant User objects DO NOT Click this one. Click the next one that says Read Exchange Personal Information and click edit. Scroll down and you will see "Read Members" check Allow and it should work.

    DISCLAIMER: I do not have a test lab, so I only did this for the one group I needed to work. In theory this should work for you, but test it out first. This alone does not make it auto populate in Outlook I still had to open them through the Email settings | Advanced Tab for each user.

    • Proposed as answer by abarker81 Thursday, September 18, 2014 7:54 PM
    Thursday, September 18, 2014 7:49 PM
  • As of late, we've not had the group permissions issues.  The process that has been working for us so far is:

    1. Create shared mailbox
    2. Create universal security group
    3. Add users to the group
    4. Assign the group the required permissions
    5. Log into mailbox with account assigned to the mailbox
    6. Disable the mailbox account

    This seems to work every time.  Currently running Exchange 2010 SP2 RU8.  Most clients are on Outlook 2010 with a few 2013 clients out there.


    • Edited by wchar_t Friday, September 19, 2014 10:40 AM
    Friday, September 19, 2014 10:39 AM
  • "Disable the mailbox account"??? really?

    This will delete the mailbox.. then you will not have issues in deed, but no mailbox to share too...

    Friday, November 14, 2014 1:06 PM
  • We had the same issue here (EX 2010, 2008R2 DCs).

    This is my solution:

    I found out that after putting the user into the group that gets full access for the mailbox, I have to log off and log on the user from his/her workstation, then resart the exchange information store and voila -> access granted !

    Logging off and back on the user seems logical, because group membership will only change after the next log on.

    Restarting the Information Store seems logical, if , as I guess, Exchange only does group expansion on a periodically basis (I didn't had the time to check and wait..)

    But if you restart the Information Store before the user has logged off (even with outlook closed) and then log off/on he user, access will not be granted. I really don't understand this behavior.

    Maybe there is someone out there with deeper knowledge of Exchange/AD that can explain this.

    The solution with "Read Members" didn't work. I think the Exchange Servers already get the "Read Members"-Right through their membership in "Exchange Trusted Subsystem". That group has the right in question.

    Hope this helps.


    EDIT: Now I found out that it has to do with the Kerberos tickets for that user in question. As long as there is a ticket with the old group memberships, the restart of the Information Store doesn't update the access rights. klist purge (on all clients the user is looged on to) before restarting the information store does the job too. Maybe this is about Exchange SID caching.



    • Proposed as answer by DevOn99 Friday, November 28, 2014 12:06 PM
    • Edited by DevOn99 Friday, November 28, 2014 12:18 PM
    Thursday, November 27, 2014 10:04 PM
  • Wow, this has been an issue since 2011.. and its still not fixed 4 years later?

    Noticed today we're running into the same problem.

    Assign single user to full access permissions, works like a charm, automatically shows up in user's Outlook.

    Assign a security group full access permissions... nothing happens. 130,000 employees and not one of them can fix this?

    Thursday, February 12, 2015 6:55 PM
  • same boat here..

    cmon Microsoft!

    Monday, February 23, 2015 2:33 AM
  • And same problem here, some groups works and som don´t.

    Some groups works with some of the users, but not all users..

    cmon... 2015?? -> 1995??


    Wednesday, February 25, 2015 9:02 AM
  • Same problem here, i am in a hybrid situation with exchange 2007 and exchange 2013 (CU5)

    We have a lot of security groups that have mailbox permissions, when i migrate a mailbox from 2007 to 2013 the user gets a access denied (also in OWA)

    Now going to test Sukh workaround to see if i can get this working.


    Wednesday, February 25, 2015 3:14 PM
  • It's hard to believe that an issue likes this dates back as far as it does and has not been yet fully addressed. Am I missing something?

    M.

    Wednesday, February 25, 2015 8:42 PM
  • FYI, just tested this again. We're on latest release Exchange 2010 SP3 RU8.2. Same problem. Added myself to a universal security group that had full mailbox access permissions to another mailbox. 2 days later it still doesn't show up in my Outlook 2010.

    Of course I can add it manually via Accounts Settings -> More Settings -> Additional Mailboxes. But that defeats the purpose, since instructing users to open additional mailboxes is cumbersome and causes many issues down the line if that additional mailbox no longer exists, yet is still in the user's mail profile.

    Anyone know if this issue is resolved in other combinations of Exchange/Outlook, e.g. Exchange 2013, or Exchange 2010/Outlook 2013?

    Wednesday, February 25, 2015 8:54 PM
  • I can confirm it still does not work, on Exchange 2010 SP3 RU9/Outlook 2013 and exactly the same.

    Would say to be honest they have no intention of actually fixing it.


    • Edited by Carbyfed Thursday, May 28, 2015 1:03 AM added wording
    Thursday, May 28, 2015 1:03 AM
  • Anyone know the logic / how long it takes for mailbox access to be granted to a user once they've been added to a Security Group that has Full Access Permissions to said mailbox?

    E.g. Group1 has Full Mailbox Permissions to Mailbox1. I add User1 to Group1. User1 then goes into Outlook and adds Mailbox1 as an additional mailbox to their account settings. User1 then shuts down Outlook and logs off. They log back in and when they click Mailbox1 in their Outlook it gives them permission denied. This stays the same for X amount of time (hours? days?) then all of a sudden it works.

    I'd like to know what determines this delay and/or what action can be done to speed this up (e.g. restart information store?)

    Monday, July 13, 2015 5:45 PM
  • I am having the original issue too. Exchange 2010 SP3.

    granting permission to a mailbox with a universal security group does not appear to work.

    Wednesday, July 15, 2015 5:16 PM
  • I am STILL having a problem with this issue
    Tuesday, March 15, 2016 5:59 PM
  • We recently encountered same problem.

    Situation we have is some people are having access in reasonable time, whilst someone need to wait like over 1 week t oget permissions when these are granted over an AD group.

    Yesterday I tried to move mailbox to a different database - and user got access straight away after that, so there is something with Exchange and applying permissions definately - anyone knows why it takes so much time to work?

    Kind regards,

    PaweL Jarosz

    Thursday, June 23, 2016 7:00 AM
    1. this may be a bug.  Even with the latetst rollup.
    2. Similar to, if you try to give the send-as permission to a DL via EMS on another Exch server than to the one you created to the DL on, it will fail, because the local exchange server in the owner and not the Exchnage Servers groups.
    3. Similar if you create a DL in ADUC, it will fail because the domain admins are the owners and not the Exchange server groups.
    4. Workaround for these is to give the exch servers group modify permission
    5. I will find out about this next week.

    Sukh

    This works. I've had this problem for years!
    Thursday, October 13, 2016 8:35 PM
  • End of 2016, five years after the first post in this topic and we still have this issue.

    We are using Exchange 2013 here, I tried the solution that gives "read members" permission for the Exchange Servers in the security group who I would like to grant access and this worked for 2 days.

    Now, the permission has returned to it's original state, and everytime I try to change it, when I hit Apply, it gets unmarked again.

    Tried this another solution above, granting full permission to exchange servers group within the security group (that contains the users I want to have full access in the mailbox) but it seems to not work too.

    Does anyone have any other thoughts?

    Wednesday, November 30, 2016 4:37 PM
  • We are running exchange 2010 sp3 ru15 and have been assigning group with full access to mailboxes with no problems. It just takes overnight for the changes to sync once the user adds the mailbox to outlook.

    I first create a universal group in AD, add the users, then I create a DL in exchange, then I open the shared mailbox and add the permission to all folders. I also add the group to the send as option for that mailbox. This has been working for a few years now and I have over 50 shared mailboxes set this way.

    Thursday, January 26, 2017 10:34 PM
  • Since going to Exchange 2010 SP3 RU16 my experience with this has been worse.

    Sometimes it can take a few days to work, or requires a remove and re-add of the security group.

    This really isn't a workable solution with such delays - can anyone advise what's going on? There's a lot of conflicting info in this thread.

    Thursday, March 30, 2017 1:45 AM
  • This has started happening to me too now. I have tried a few things in this thread and none worked. What DID just work though was to move the mailbox to another database and now it works instantly.
    Thursday, December 28, 2017 4:45 PM