Exchange has always been few steps ahead compared to other Microsoft products when it comes to PowerShell support and the JEA model in general (yes, we call it RBAC, but it’s the same idea). You can get very granular with the RBAC and luckily, the team has also made sure that all the relevant controls in the EAC (or OWA options) are dynamically adjusted based on the actions the user has access to. This goes not only for the different tabs, but even for individual buttons.
Still, there is some ‘behind the scenes’ logic we need to comply with whenever we play with the roles. I run into one such example last week while creating a restricted “MyDistributionGroups” role, with the idea to block user from creating or removing DGs without admin approval. Once you’ve familiarized yourself with the core RBAC concepts, achieving this is a simple task (those of you that want detailed instructions might refer to this blog article). I decided to go a step further and remove few other ‘unnecessary’ cmdlets, such as the Set-Group one. So I created the new role, configured it as desired, run some tests and as all went well I assigned it to the default policy. The next day however users started complaining about no longer being able to manage the ownership of their DGs. Now, I quickly inspected the new role and confirmed that everything should be there, both the Set-DistributionGroup cmdlet and the ManagedBy parameters were present. Opening the group properties in OWA however revealed the issue – while the users were able to see the ownership information and manage any other settings, the Add and Remove buttons were missing from the Ownership tab.
As another set of validations, I logged in to PowerShell as a restricted user and tried to set the ownership of a DG I own. No surprises there – as the Set-DistributionGroup cmdlet was indeed assigned to the role, I was able to add/remove owners as I please. In effect, while technically I hadn’t removed the ability to change ownership, OWA seems to either use the Set-Group cmdlet instead of Set-DistributionGroup, or it simply expects both cmdlets to be available in order to show the Add and Remove buttons. And because of that fact, users were not happy. So lesson learned – when you try to play smart, always double-check all endpoints/interfaces your changes will affect. And make sure to not remove any of the generic cmdlets (Set-User, Set-Group, etc.) just because the relevant parameters are already covered by other cmdlets. Unless you plan to teach the end users on how to use PowerShell that is 🙂