Channel: blog.atwork.at
Viewing all articles
Browse latest Browse all 1118

Delegate365 changelog version 8.1-New permission policies


When we started with Delegate365 five years ago, basic permissions were sufficient to control what features can be used by Scope Admins. Since Delegate365 evolved with more functionality and we received requests from our customers, it was time to renew the permission control to a more granular level. So, the existing permissions have been replaced with permission policies. With Delegate365 version 8.1, each Administrator gets a permission policy assigned that controls on a very granular level, what modules and features can be managed. The new menu structuring is part of that functionality. See how the permission policies work and how existing permissions are converted here.

To make it short and comprehensible, see the old and the new Delegate365 permissions at a glance here.

Old permission set (Delegate365 v8.0)

To Delegate365 version 8.0, in Administration / manage administrators, each admin had a set of basic permissions. The switches controlled, what modules are visible for that admin, as Is Portal Admin, Manage Distribution Groups, Can manage Manage Security Groups, Manage Mailbox settings, etc.


The benefit here was that setting permissions was done very quickly and easy to manage for Admins. We had Portal Admins and "Non-Portal Admins", we called them Scope-Admins. The switches showed a menu and allowed read and write-access. On the other hand, some of our customers requested to have custom roles, as e.g. persons who should be able to control only the license quotas and should not be able to manage users or groups, etc. Another characteristics of that system was, that if you had many administrators, you would need to modify each administrators permissions. So, it was time to make the permissions more better customizable.

New permission policies – do it once for multiple Admins (Delegate365 v8.1)

With Delegate365 version 8.1, there come permission policies. Each administrator requires to have one permission policy assigned in Administration / Administrators / Edit admin.  The assigned permission policy defines the set of permissions that administrator gets.


To keep it as simple as possible, only one permission policy can be set per admin. A huge benefit here is, that permissions can be defined in a central place once (as follows) and affect every single admin who has that permission assigned. This reduces the work for Admins and allows to modify the underlying permission policy anytime easily.

How does it work when Delegate365 is upgraded?

When Delegate365 has been  upgraded to version 8.1, the existing permissions are converted automatically to a policy for each administrator. This ensures that existing permissions are 1:1 converted into the new permission policies. The converted permissions get the name of the administrator account (UPN) as here.


When converted, a permission policy is created for administrator AdeleV with the same name.

Of course, to benefit from the "Define-once-apply-to-multiple-admins" feature, we recommend to check the permissions and to reunite permissions as much as possible. So, it would make sense to create a permission policy for a region, OU's or for various admin-roles. See here, how to modify a permission policy.

Define or modify a permission policy

Permission policies allow to granularly define what features the admins can use within Delegate365. The Permission policies list shows the existing policies and how many admins are assigned to each policy, as in column Assigned. Admins see at a glance, what policies are active and what policies are not used. To define a permission policy, open the Policies / Permission Policies menu as here. Create a new policy or edit an existing one as usual in Delegate365 with the Plus icon or by selecting a row and clicking Edit policy.


By default, there are two permission policies available: Portal Administrator and Scope Administrator. Plus, there will be a policy for each admin, if Delegate365 has been updated from a previous version.

The permissions panel opens on the right side. Each policy requires a policy name. The policy name can be modified anytime as needed and does not affect any existing assignment. To make it quick and easy to define the multitude of permissions, there are three predefined roles available with the buttons: Portal Admin, Scope Admin and Read Only. Best practice is, to click on one of these buttons to set the basic permissions for such a role and adapt it from here on.


Then, you can start modifying the permission set as needed. Each module is shown in a box, as Administration, Policies, Users, Mailboxes, etc., in the same order as they appear in the menu on the left side. Quick info tips help to understand what behavior this permission controls. The following graphics shows all current permissions in Delegate365 in a big picture, click to enlarge.


As shown, some modules as e.g. Distribution Groups, distinguish between No permission, Read and Write permissions. To clarify, Write indicates permissions to Read and Write, so that's the highest privilege. For some other permissions, only a Yes or No permission makes sense. The permission switches depend on the module or the feature. After the permissions have been set, click the Save button at the bottom of the permission policy panel.

Setting granular permissions – example

Noteworthy, that there are permissions available for each "feature-box". So, here can be defined that e.g. Admins with a specific permission set only have allowance to create and to delete Shared Mailboxes and that they only see the forwarding box and the setting out-of-office notifications box for their Shared mailboxes- Here, a Portal Admin defines that specific set of policies to the permission policy of AdeleV.


As a result, AdeleV - who has assigned that permission policy - can only see (and manage) these two features in the mailbox feature page.


So, custom permission sets can be defined easily for various roles in each organization.

Modifying permissions on the fly – Admins need to logout and login to see changes

Please note, that when an underlying permission policy is changed, the assigned admins have to logout and login again in Delegate365 to see any changes. The permission roles are cached after the login for performance optimization. Of course, this is only necessary if an admin is currently signed-in in Delegate365.

The quickest method for login-logout is to click on the username in the top right corner, wait for the "you are signed out message", and click on the Delegate365 name in the following page to login again.


The user needs to re-authenticate and will see the current permissions available, as AdeleV sees now one more feature, the mailbox delegation, in her Shared Mailbox page.


Permissions scope

Permission policies act as additional restriction for Admins to OU and domain-assignments. With the new permission policies, Admins can granularly control what modules and features other Delegate365 Admins can see an use. Permissions are also valid for the Delegate365 API and PowerShell module as well as the OU-restrictions.

We recommend to create the required permission policies in an organization and to delete personal and unused permission policies. Now, there's one central module to restrict or extend permissions with a mouse click for all assigned administrators. We think the new permission policies make a lot of sense in Delegate365 and we hope, you like them, too!

Viewing all articles
Browse latest Browse all 1118

Latest Images

Trending Articles