Click here if you like to subscribe the ChangeLog as an RSS feed.

Delegate365 changelog version 8.3-GroupSync,Bulk operations and more improvements

Monday, May 6, 2019

The next version of Delegate365 v8.3 is here. This major version brings some new features as "Sync with security group", bulk assignments, list export, improved OU management, and many further features and fixes. See the details here.

  • Upgrading from Delegate365 version 8.2 does not require running a new setup. Upgrading from any other Delegate365 version, requires to (Re)run the setup.
  • New Sync Rule "Sync with security group": This new feature in Administration / Sync rules allows to remove users from an OU automatically based on their security group membership.  See how this works in detail at Sync with Group.
    We hope this new sync feature helps improving your users organization based on security group memberships in Delegate365.
  • Bulk assign licenses uses license policy: In module Licenses / Bulk assign licenses, administrators can un-assign and assign licenses for multiple users. That can be tricky, since multiple users can have different licenses assigned and not setting a license or plan will remove that license or plan from all selected users. So, Administrators should know what they are execute in this module. Anyway, this module now considers a license policy that can be set for an Administrator. See details and a sample at Bulk assign licenses.
  • Administrator bulk operations: Setting the administrators permission and license policy now is easier. In module Administration / Administrators, multiple users can be selected. Then, the new menu is shown on the right side.
    This allows to set the permission policy…
    …and the license policy for multiple administrators in one step.
    Multiple administrators can be deleted in one step as well.
  • Administrators Last Login: The Administration / Administrators list now shows the last login of each Admin to identify admins that have been inactive for a longer time period.
  • Export list data to a CSV and Excel file: The following modules now have an export function, for exporting data as CSV or Excel file for further processing: Administrators, Users, Shared Mailboxes, Resources, Contacts, Security Groups, Office365 Groups, Distribution Groups, Dynamic Groups.
    Simply click on the icon on to of the table to download and open the generated file. The function exports all list data (not just the current page) to the file.
  • Create an OU with Admin-assignment: When creating a new OU, one or more administrators can be selected directly in the creation process. This saves extra steps.
  • Edit an OU with remove Admins: Also, when clicking Edit, you can remove assigned administrators from an OU - and add new ones in one step.
  • OU assign and unassign show the UPNs and allow search: The modules OU´s / Assign and Unassign have been extended to show the User Principal Names in all corresponding boxes User, Distribution groups (Primary SMTP address), Office 365 groups (Primary SMTP address), Dynamic groups (Primary SMTP address), Contacts (Windows email address), Shared Mailboxes (Primary SMTP address), and Resources (Primary SMTP address).
    The same goes for the unassigment-list as here.
    The search box also looks in that field when searching, so, you can search for a part of the email address as well, as e.g. "ers@m365x005" finds all users with that expression.
    This helps to identify and find the user objects, especially in large environments.
  • License policy added to Sync Rules: Administrators can now use a defined License Policy to use in the User license assignment settings.
    When the Licenses icon is clicked, the panel opens and shows a dropdown with all existing license policies. This allows to select a predefined policy set and to user this as a template for individually select licenses and plans that shall be set for that rule.
    As you can see, a selected license plan sets exactly the checkboxes as defined in the policy.
    Remember that changing a license policy in the dropdown resets existing selected plans and overwrites them with the selected policy settings. Anyway, you need to confirm the settings with the OK button at the panel bottom to save them.
    Info: Be aware that changing a license policy does NOT modify any existing license assignment rules. The License policy dropdown is just for selecting the settings of the current policy to the license selection. This feature supports especially administrators who need to define many licenses assignment rules to be able to perform this operation with one click instead of setting each single license or plan. We hope this helps.
  • Members lists sorted: All members list are sorted now to quickly find a member, e.g. in Distribution List Members.
  • Report Groups governance outsourced: The report generation was moved from the sync to the daily statistics task. So, the data is available for the day before.
  • Added a new endpoint HealthCheck for internal monitoring of telemetry data.
  • Initial Sync status is now "running" after the job has been started. Aborted jobs will be marked as "canceled".
  • Sync shows short summary: The sync operation shows the number of added, updated and deleted objects in the Details panel as here.
    In this sample, existing users have been assigned as members of security groups and groups have been added to OU´s based on their Display Name, as defined in the Sync Rules.
  • Additional small fixes, as removed user edit validations so that user properties can contain special characters, e.g. department "R & D" etc.

We hope this new features support in organizing your management with Delegate365!

Delegate365 changelog version 8.3-Sync with Group

Tuesday, April 23, 2019

With Delegate365 v8.3 there comes a new feature in the Sync Rules: Sync with security group allows to automatically remove users from an OU. See how this works here.

This is a feature request brought to us by Delegate365 customers: When a user is removed from a security group, he or she should also automatically be removed from the corresponding OU, if the User sync rules are set to "Security group". So here´s a description of that feature with a sample (improved Delegate365 Admins can have a look at step1 and then continue with step 7)…

  1. In Delegate365, the User sync rules are activated, and there´s an active rule set to "Security group". With this version, there´s a new switch "Sync with security group" that needs to be set to Yes as shown here. This activated switch will remove users from an OU if they are no longer member of a security group.
  2. In our scenario, I want that all members of Security Groups sg-Legal and sg-Retail shall be assigned to the OU´s with the same name. So, I created these two OU´s manually, additional to the two existing OU´s New York and Seattle as in the following screenshot. (My user has these OU´s assigned to see all objects in Delegate365.)
  3. To test, I have added 4 persons as members to sg-Legal: Joni, Enrico, Irvin and Grady. I did this outside of Delegate365 in the Azure portal, to test the consequences like in an hybrid environment.
    The second group sg-Retail, has only 2 members: Joni and Cameron.

  4. Check before sync: Currently, as administrator, I don´t see these users in Delegate365 – or some of them assigned to another OU: Enrico, Grady and Cameron are not showing (they are not assigned to an OU), Joni is already assigned to New York, and Irvin is already assigned to Seattle. This is the start scenario, composed in one picture with the Users search.
  5. Let´s run the sync in Administration / Sync operations by clicking on the Start AAD sync button. Confirm the execution.
  6. When the sync is completed, let´s see the result in the Users list. When filtering for OU sg-Legal, we see the 4 group members (Joni, Enrico, Irvin and Grady) assigned to that OU.
    Oh, a word to our second group sg-Retail with the 2 members: Joni and Cameron. As we see, Joni is also member of group sg-Legal. In Delegate365, an object can be assigned to an OU only. So, the first group "grabs" Joni and assigns her to sg-Legal. When checking for OU sg-Retail, we see just Cameron (and no Joni, because she was assigned to sg-Legal).
    So, one object = one OU assignment in Delegate365. All clear?
  7. So far so good, there´s no news until here. Now, let´s remove members from the two security groups. The members of sg-Legal have been changed to Joni and Enrico only, Irvin and Grady have been removed.
    And do the same for sg-Retail: We removed Cameron, and now only Joni is in.
  8. Run the sync again (as in step 5).
  9. With the new sync settings, we get these assignments: sg-Legal now contains only Enrico and Joni. Irvin and Grady have been removed – the OU has the same members as the Security Group.
    The second OU sg-Retail is empty as expected: Only Joni is member of that Security Group. But Joni has been assigned to sg-Legal already, and Cameron has been removed from that group. So we see an empty OU as here.
  10. As we can see, with the switch "Sync with security group", the OU´s now run synchronously with the Security Groups. Just, as exaptation, users can be assigned in Delegate365 only once.

We hope this new sync feature helps improving your users organization based on security group memberships in Delegate365!

Delegate365 changelog version 8.3-Bulk assign licenses

Friday, April 12, 2019

Delegate365 allows to modify licenses in many ways, manually, automatically and with bulk-assignments. With version 8.3, the license policies will be considered for bulk assignments as well. See a description of that functionality here.

The Delegate365 permission and license policies control what modules and what licenses a scope administrator sees. An administrator can be assigned to one permission policy and to one license policy. While many organizations are using the Delegate365 sync rules, scope admins can manually assign entitled licenses and plans. The menu Licenses / Bulk assign licenses allows to accomplish such an operation for multiple users and takes the unauthorized licenses into account with this update.

Single user license assignments

A Scope Administrator, Adele, can manage her users and licenses. In this sample, there is a license policy in place for Adele, that allows to set specific licenses and plans while others are inactive and cannot be modified as in this screenshot. Licenses in the red box are inactive and the licenses above can be managed by Adele.


In here, Adele manages the licenses of user Pradeep. As we see, Pradeep already has a license of E3 and the plans Mobile Device Management, Skype, SharePoint and Exchange selected. Adele cannot modify these plans due to her assigned license policy. But, she can, for example, add the plans for Teams and Planner as shown above. So, the yellow highlighted plans are set within the E3 license.

Bulk assignments for multiple users

In module Licenses / Bulk assign licenses, administrators can un-assign and assign licenses for multiple users. First, the users can be filtered and selected in the user´s list.


Note that all licenses and plans in the Licenses box are always unselected, since multiple users are affected and each user can have a different set of assigned licenses. In here, Adele selected two users. Remember that Pradeep had he following licenses selected: Enterprise Mobility + Security E5 and some plans of Office 365 Enterprise E3.

Now, Adele modifies some plans of E3 for Pradeep: Teams and Planner are deselected and To-Do is added. The green box shows the plans that can be modified, the red box shows the inactive plans.


The Assign button at the page end executes this operation for all selected users. The action must be confirmed.


Important: Note that the Bulk assign licenses module REALLY SETS the defined licenses for the selected users. This means, that ALL UNCHECKED plans and licenses are REMOVED from the users and ONLY SELECTED licenses and plans are ASSIGNED. Please keep that in mind when using this function.

Check the result

So, in our sample Adele modified Pradeep´s licenses. Let´s see the result in the user´s list here.


The plans that Adele is not allowed to edit are set (Mobile Device Management, Skype, SharePoint and Exchange – the plans that have been set by the Portal Admins are not changed). On the other side, the new To-Do license is set, and Teams and Planner plans are removed, since they were not selected in the bulk update. Also, the Enterprise Mobility + Security E5 license has been removed since it was not selected.

Use bulk assignments wisely

The Bulk assign licenses module fulfills the desired operation and removes unselected licenses and plans. So, please, be careful with that!

With this update, the Delegate365 Bulk assign licenses reduces the risk of removing unauthorized licenses or plans. We think, the new behavior makes sense and is helping scope admins with their bulk update of Office 365 licenses.

Delegate365 changelog version 8.2

Sunday, March 10, 2019

After the major update that came with Delegate365 v8.1, v8.2 brings various improvements and fixes to optimize daily tasks in Delegate365. See the details here.

  • Run a setup: Admins need to run the Delegate365 setup after the upgrade process from v8.1 to v8.2. See the How-To at (Re)run the setup.
  • User license quick info: When hovering over a license checkbox in the user license panel, a new quick info informs about the license numbers that are available in the Office 365 tenant. This brings more transparency for admins to see if a license might be inactive because all licenses are assigned.
    In this sample above, there are 25 E5 licenses available, and only 3 licenses are left (which means that 22 licenses are already assigned to users). In that OU, there are 7 E5 licenses used, and there is no quota defined.
  • Distribution groups including other distribution group: Now, a distribution group can be member of another distribution group as shown here. This works for distribution groups only.
    Important: Due to the nature of Office 365 groups, only users can be added to an Office 365 group, no other groups.
  • Reports: The different boxes were summarized. When a report is submitted, now there's one box Scheduled reports that shows reports waiting for generation, and one single box showing all Completed reports, regardless when they are scheduled.
  • New report Groups Governance: This report in the Delegate365 category at the end of the report list creates an overview of the entitled Office 365 groups in the tenant with the number of for each group.
    The generated report delivers the following data: OU, GroupDisplayName, Classification, ObjectId, Mail, OwnerCount, GuestsCount, MembersCount, RenewedDate, Visibility, IsTeam, Owners, InternalMembers, ExternalMembers
    So, the Groups Governance report informs about the number of group owners (to comply with any organization policies), external guests, members and group properties as the visibility and classification (if set) and the renew date and the type of a group.
  • Message Trace: This has been extended, so that Distribution Groups, Shared Mailboxes, Resource Mailboxes and Contacts can be used.
  • User field validation: The validation method has been extended for modifying the user properties, so that more special character are allowed. (Before, a validation error occurred and did not allow to save that content when entering data as below.)
  • Copy a policy: An existing permission policy and a license policy can now be copied with the new menu to minimize the management effort. Confirm the message, and a copy with the name "Copy – [name]" policy is created, here it would be named "Copy - Scopeadministrator".
    If a policy is copied, multiple times, the name is always "Copy – [name]". It makes sense to rename the policy then anyways.
  • Administrator send API key per email: A link Send API key to Admin has been added to directly send an API key to the administrator. This is useful to hand over that key when the administrator shall be able to use the Delegate365 PowerShell module.
    A notification in the bottom right corner informs when the email has been sent. The recipient gets an email that looks as here:
    For more information about using the Delegate365 PowerShell module, see
  • PowerShell: The command Set-DAdmin now allows to overwrite existing OU`s, Domains, Policy and the Active flag, see Set-DAdministrator. There's a new command Delete-DAdmin that allows to delete Delegate365 administrators. Fixed: Get-DAADUser –All and Get-DAADUser -UnAssigned –All delivered the same result. This has been fixed and the command returns all assigned or all unassigned users (for PowerShell Admins) . If the user is not a Powershell Admin, this commands always returns an empty list.
  • Improvements and fixes: The internal webjobs have been reorganized for using LogicApps and small adaptions have been made.

We hope you like the improvements. New Delegate365 demos automatically get the latest version, productive tenants will be upgraded by appointment.

Troubleshooting Delegate365-Login

Thursday, February 21, 2019

Sometimes support cases are opened because users cannot login to Delegate365 with their Office 365 account. In most cases, the browser cache automatically signs-in a user with wrong credentials. Please follow these simple steps to see how to achieve a successful login to the Delegate365 portal in such scenarios.

1. Use a browser in Private mode

The most common stumbling block is that web browser log in users automatically. Also, often users are working with multiple accounts. Thus, there is a high probability that an incorrect sign-in will occur when opening the Delegate365 portal.

To avoid such a behavior, open a new browser window in "private mode". Every modern browser supports that mode to ensure that you start with a "fresh" browser without automatic login. You can do so as follows.

  • In Google Chrome, press Ctrl + Shift + N, or open the menu "New incognito window" as here.
  • In Mozilla Firefox, press Ctrl + Shift + P, or open the menu "New Private Window" as here.
  • In Microsoft Edge, press Ctrl + Shift + P, or open the menu "New InPrivate window" as here.
  • In Microsoft Internet Explorer, press Ctrl + Shift + P, or open the menu "Safety" and "InPrivate Browsing".

It works similarly in other browsers. In case of any login issues, please use the private mode!

2. Check your Office 365 account

Just to mention… check your Office 365 account. Open a browser in private mode and login to and see, if the login works. If yes, the predefined Office 365 page will follow.


A valid Office 365 account is required to sign-in to Delegate365. If the login worked, you can open a new tab and open the Delegate365 URL.

3. Check the Delegate365 URL: https://<customer>

Ensure that you have the correct Delegate365 URL, especially when using bookmarks! Type or paste the URL into the address field.


Usually, the portal URL looks as here: https://<company>

Sometimes, wrong bookmarks are stored which results in an issue when signing-in. Avoid that by typing or verifying the Delegate365 URL.

4. Ensure you are using the correct Office 365 account

If you sign-in with an Office 365 account that is not allowed to open the Delegate365 portal…


… you are automatically logged-out and this information follows: "You have successfully signed out."


This occurs, when the sign-in process was successful - with a valid Office 365 username and password - but this account is not a valid Delegate365 app user.

In that case, start over with the correct user account. Click on the white Delegate365 link in the blue menu bar to retry (or close the browser and start over with step 1). Then, if the same behavior follows, please continue as here.

5. Ask your Delegate365 Admin to check your access

Basically, every user of Delegate365 must be added as Administrator to be able to use the Delegate365 portal. (There are some exceptions for specific URLs that can be used by normal users as SSPR.)

So, if your login still does not work, please contact your Delegate365 Portal Admin to check if your account has been added to the Administrators list in Delegate365. A Portal Admin needs to open the Administration / Administrators menu and see if the desired account is in that list and active:


In this sample, only two accounts have access to the Delegate365 portal and are set to Active equals yes: and .

Any other account cannot open the Delegate365 portal. So, if signs-in successfully, she gets this message: "You do not have permission to view this directory or page."


This happens, because MeganB logged-in to the correct Office 365 tenant, but is not listed as Administrator in Delegate365 (see above).


Please follow the steps above if you encounter any issues with your login to the Delegate365 portal. Use a browser in private mode, check your Office 365 account and ask your Delegate365 Portal Admin to check your account in the list of the Delegate365 administrators. In most cases, any issue is a (browser) client topic that can be resolved as described.

If these requirements are fulfilled and your Office 365 account is valid, the login to the Delegate365 portal will work properly.

Troubleshooting Delegate365

Wednesday, February 13, 2019

Delegate365 is a user-friendly tool to enable delegated management of users, licenses, and groups. This means that only objects assigned to a scope administrator are displayed in Delegate365. So, sometimes, we get questions as "I can't see my users/shared mailbox or similar". Here's why and how to solve such issues.

Why does Delegate365 not show users?

Well, that's the idea of the tool. Delegate365 shows only objects to which I am entitled to see and to manage.

Portal administrators (users who can configure Delegate365) define Organizational Units (OU's) and assign objects as users and groups to them. In Delegate365, an OU is a container for managing objects. Then, they define scope administrators and what OU's they can manage. So, the scope admins see only objects they can manage in Delegate365. For example, a scope admins sees an Office 365 Group, but in that group he sees only the members he can manage (and not other members that might be in that group as well). That's the basic rule and the concept. That being said, there are two conditions that must apply for administrators and users as follows.

Administrator assignments

Scope administrators must be assigned to the OU AND the user DOMAIN in the Administration / Administrators menu.

For example, to see user "" who is assigned to OU "Seattle", the administrator must be able to manage OU "Seattle" and he must be able to manage the domain "". So, an OU and the user's UPN domain must be assigned to a Scope Administrator. See this screenshot when a new administrator is added. At the end, the panel asks for the domain and the OU assignment.


Of course, this can be done for existing admins anytime in the menu as well by selecting an administrator and assigning the domain(s) and OU(s) in the corresponding menus on the right.


Note: Only users that are in the administrators list are able to login to Delegate365 and to use the management capabilities of Delegate365. Just to mention, there are some modules that can be used by end users, see How to manage self service password reset for users in Delegate365.


So, these two assignment, OU and domain, are required that an administrator sees "his" assigned users as the following screenshot shows. Both conditions must be fulfilled, as marked with red boxes below.


Additionally to the OU, the domain restriction allow to filter just for specific domains within one OU. E.g. if there's a country OU "Germany" and in that country, there are multiple custom domains for sub companies or departments or brands as,,, etc, the domains can be assigned to different administrators. Again, scope admins must have the user's UPN domain assigned to be able to see these users.

Mailboxes and groups

The domain assignment will not be considered for other objects than users. So, shared mailboxes, resource mailboxes and groups show all objects that are assigned to an OU, regardless of the domain.


As mentioned above, administrators see only members of their own entitled OU's. This is not a bug, it's a feature to ensure that administrators cannot modify new or existing members they shall not see. An exception to break that system is the concept of Group OU's. This allows to add users as members to own groups even if you cannot manage them. See more at see Delegate365 changelog version 8.0-Group OU's.

Assign objects

Still don't see users, mailboxes or groups?

Ensure that the objects (users and groups) are properly assigned to an OU in Delegate365. This can be done manually and automated. Anyway, Portal Admins can check that anytime in the menu OU / Assign and in OU / Unassign.


This OU / Assign module shows all UNASSIGNED objects and allows to select objects and assign them manually to an OU. This must be done per object type. You find the users in the User box, Shared Mailboxes in that box, etc.

Note: The OU assignment can be automated based on user properties or group membership in module Administration / Sync rules. If such rules are enabled, assigned objects can change an OU automatically.

Objects that are assigned to an OU can be exported in the Reports menu with report OU overview.

Unassign objects

To check, if objects are already ASSIGNED to an OU in Delegate, open the OU / Unassign menu.


Here, all objects that are currently assigned to an OU in Delegate365 are shown, as user "AdeleV" is assigned to OU "Seattle". You can select objects and un-assign them. Then, they are no longer visible in Delegate365 and they will show up in the OU / Assign menu again.

Shared Mailboxes (SM) and Resource Mailboxes (RM)

Looking for shared mailboxes or resource mailboxes and don't see them?

In Office 365, every mailbox is of RecipientType 'UserMailbox' and the RecipientTypeDetails property makes the difference. Check that in your tenant in your Office 365 portal – or by connecting to Exchange Online and running the following Remote Exchange PowerShell command:

Get-Mailbox -ResultSize:Unlimited `
  | Select PrimarySmtpAddress,RecipientType,RecipientTypeDetails | ft

The output shows all mailboxes with three different RecipientTypeDetails: UserMailbox, RoomMailbox and SharedMailbox.

PrimarySmtpAddress                    RecipientType RecipientTypeDetails
------------------                     ------------- --------------------     UserMailbox   UserMailbox      UserMailbox   RoomMailbox    UserMailbox   SharedMailbox

Delegate365 queries objects by the RecipientTypeDetails. So, the objects (if assigned to an OU, see "Assign objects" above) are shown in the Users, Shared mailboxes and Resources modules, analogous to the RecipientTypeDetails.


If you are unclear why objects do not show up, pls. check the RecipientTypeDetails of objects and if they are assigned to an OU in Delegate365. Then, they will show up in the corresponding module.

When using Sync Rules with CustomAttributes, you can check if the required attributes are set for Delegate365 by querying them as in the following sample using CustomAttribute10.

Get-Mailbox -ResultSize:Unlimited | Where {$_.CustomAttribute10} `
   | Select PrimarySmtpAddress,RecipientType,RecipientTypeDetails,CustomAttribute10

Here, only two mailboxes have a value stored in CustomAttribute10.

PrimarySmtpAddress                 RecipientType RecipientTypeDetails CustomAttribute10
------------------                  ------------- -------------------- -----------------   UserMailbox   RoomMailbox          Berlin  UserMailbox   UserMailbox          Vienna

Note: If Sync Rules are configured using CustomAttributes1 to 15, be aware that only users with an existing Exchange mailbox (a license) do have these attributes. So, a user without Exchange license, does not have CustomAttributes as long as the user property schema is not extended through the Exchange server. This happens automatically by assigning an Exchange license to a user (or if a new mailbox as a SM or RM is created). So querying data is good to ensure the values are set correctly. If possible, we recommend to use Security Group membership since this is more performant and usually easier to manage.

Sync: Ensure Delegate365 is up to date

In the background, Delegate365 synchronizes changes (the delta) between Office 365 and Delegate365. So, if a user or a group is created, modified or deleted or Office 365 licenses are assigned, Delegate365 knows about the changes and updates it's cache. If a change has just been made in Office 365 through any other system (bulk assignments, PowerShell scripts, etc.), it might take some time until Delegate365 sees the latest changes. This usually happens within less than four hours. Anyway, administrators can force a manual sync anytime in the Administration / Sync operations menu.


Note: If you just know that any changes happened in Office 365, start the AAD sync in Delegate365 manually to ensure that Delegate365 is working with the latest changes of objects. Otherwise, just wait. The Sync history box informs about the latest sync processes. The Sync Rules in Delegate365 are attached to that sync process. So, they run, after any Delegate365 objects have been updated.

Summary: Step-by-step troubleshooting

If objects are not shown in Delegate365:

  1. Check if the objects are visible in the cloud (in hybrid scenarios). Check in the Office 365 portal.
  2. Check the last sync operation (that Delegate365 is up to date) or run the sync manually in Administration / Sync operations.
  3. Ensure that the objects are assigned to an OU. Check OU / Assign (for unassigned objects) or OU / Unassign (for assigned objects). Assign objects to an OU.
  4. Check if the administrators have the OU AND the DOMAIN of the users assigned in Administration / Administrators.

If sync rules are active and objects are not shown, check additionally:

  1. When working with CustomAttributes or names: Do the objects really have the values assigned that are defined in the sync rules? Check the data.
  2. When working with group membership: Is the object in fact a member of that group?
  3. Is the sync rule correct and active?
  4. Might there be contradictory sync rules?

As IT-Administrator, with these simple steps, you should be able to discover, why objects are not visible in Delegate365 and you should be able to fix that accordingly.

We hope, this article helps to configure your Delegate365 so that delegation works for your organization and relieves IT tasks.

Delegate365-Working with Audit Logs and Power-BI

Tuesday, January 8, 2019

Delegate365 protocols operations in it's audit logs. This log space can be accessed from entitled users and it's simple to create a custom Power BI dashboard for your Delegate365 data. See how this works here step-by-step.

Tip: The article Delegate365-Working with Audit Logs covers the methods for accessing the data and working with the audit logs as well. This article informs how to connect to your Delegate365 with Microsoft Power BI step-by-step and how create your custom dashboard. You need to have a Power BI license, see details at Power BI Pricing.

Follow these steps to work with Delegate365 audit data with Microsoft Power BI (click on the images to enlarge them).

  1. If not already installed on you computer, download the free Power BI Desktop client from
  2. When installed, start the Power BI Desktop app and select Get data.
  3. In the Get Data dialog, select Azure / Azure Table Storage and click Connect.
  4. Change to your Delegate365 tenant and open Logs / Log Access. Click the Get account button. This opens the access data to your audit logs.
  5. Copy the Account name (here: d365demotp7) and the Account key (here: lMP1ORItc9...), best to a notepad.
  6. Change back to Power BI Desktop. Paste the Account name to the dialog box and click OK.
  7. Do the same with the Account key.
  8. In the Navigator dialog, select the tables you want to use:
    AuditLogSearch is the "full log" over all times. Additionally, Delegate365 stores audit data in tables named log<year>, as log2018, log2019, etc. and per month, named log<month>, as log201811, log201812, log20191, etc. So, you should select AuditLogSearch and – if you want to speed up performance – the logs for years and or months. Click Load.
    Power BI now loads the data from the Table storage.
  9. Back in the editor mode, open the menu Edit Queries.
  10. In the Power Query Editor, you need to decompose the log data as here. Click on the grey Split icon right of the column header Content. This action discovers the data stored in that column and opens a menu, where all analyzed fields are already selected. Click OK.
  11. You should see that new columns (yellow column headers) have been added and in the Applied Steps list on the right side, the Expanded Content step has been added. This step splits the JSON formatted log content in single columns. This is required to access the details.
  12. Then, click the menu Close & Apply. The data modifications will be applied.
  13. Now you can start designing your dashboard. The AuditLogSearch table can now be expanded. In this sample, a new stacked column chart has been added to the content board and filled with data from Content.Ou and Content.Action. This visualization then shows the number of actions that happened in the OU's in the time frame (since the start of working with Delegate365).
  14. Design your dashboard(s) as needed with the data provided directly from the audit logs. You can customize the visualizations by selecting the object, switching to another visualization and by clicking on the Format icon as here.
  15. You can update the data anytime by clicking the Refresh icon in the menu bar. This loads all data directly from the Delegate audit logs – you always get the latest data.
  16. Save your dashboard to you local computer, e.g. as MyDelegate365.pbix
  17. To make the reports available online, click the Publish menu icon.
  18. If not already signed-in, you need to enter your Office 365 credentials.
  19. Select an Office 365 group (a workspace) as destination. You reports will be published to that group.
  20. You can open the report directly from here now. This opens the browser with your report URL that looks similar as
  21. Done. The reports are now available online and can be shared, subscribed, etc.

These easy steps allow to directly access the Delegate365 audit logs and to customize the visualization depending on your needs.

Delegate365 PowerShell

Wednesday, November 7, 2018

As announced in Delegate365 changelog version 8.1-Many new features, this version brings PowerShell support for administrators. All Delegate365 admins can use the PowerShell module if the access is granted by Portal Admins. See the How-To here.

Note that for using the Delegate365 PowerShell module, Delegate365 version 8.1 (or higher) is required. The version number can be found in the status line at the end of the page in the Delegate365 portal, see the screenshot below.

PowerShell description at GitHub

To see the available PowerShell commands and to get the description, open


Installation of the Delegate365 PowerShell module

The Delegate365 module must be downloaded and installed once on a client computer from the PowerShell Gallery. The Delegate365 module can be used on any platform supporting the .NET standard 2.0 library. To overwrite an existing Delegate365 PowerShell module with the latest version, add the -Force parameter.

Install-Module Delegate365 -Force

Once installed on a client machine, the Delegate365 command lets can be used. In case of any errors when installing, please see the Prerequisites.

Get the Administrator's key from Delegate365

Every Administrator can use the Delegate365 PowerShell commands if the Portal Admins hand over the personal access key to the admin. As Portal Admin, you get that key for an admin in the Administration / Administrators menu. Select the desired user and open Edit admin as shown here.


In the Admin panel, scroll down to the bottom. Here you find the WebAPIKey. That works like a password for that specific admin. Hand over that password to the admin who wants to use the Delegate365 PowerShell module (or the Delegate365 API). Ensure that the admin is set to Active = Yes and that there is a WebAPIKey existing.


You can re-generate an new API key anytime. If you want to disable PowerShell access for an admin who already has access, regenerate a new WebAPIKey (and don't hand it over to the admin…), that's it. If an admin left the organization, and you completely want to disable him or her, set the Active switch to No (or delete that admin). Click Save afterwards.

Again, you can generate a new WebAPIKey anytime. This key works as a password for a Delegate365 admin when working with the PowerShell module or the API.

Connect to Delegate365

After the Delegate365 PowerShell module is installed, it can be used as here. Hand over the WebAPIKey to the admin. An admin needs his WebAPIKey and the URL of the Delegate365 portal. Replace the values of $baseUrl and $apikey in the script below with your own data. Then, use the Connect-Delegate365 command to connect to your Delegate365 instance and use the cmdlets afterwards. The following script connects to an Delegate365 instance and reads all users of OU Seattle with Get-DUser. Then, the connection is closed with Disconnect-Delegate365.

# Ensure that the module is loaded
Import-Module Delegate365

# Connect to your Delegate365 instance
$baseUrl = "https://<your company name>"
$apiKey = "<your administrator's API key>"

Connect-Delegate365 -WebApiSasKey $apiKey -WebApiBaseUrl $baseUrl

# Run commands
Get-DUser -OU 'Seattle'

# Close the session

If you run a script like above, the output should look similar as here within Visual Studio Code (with installed PowerShell extension).


The Delegate365 commands can be combined with any other PowerShell commands. So, you could output all (entitled) users to a CSV file and then work with these users and other Office 365 commands as needed. New-DAdministrator-Sample.ps1 shows another sample how to work with the Delegate365 PowerShell.


It's important to understand that every Admin could use Delegate365 PowerShell with his WebAPIKey, but only within his scope (OU's). There exists a switch "Is PowerShell Administrator" in the Permission Policies that distinguishes, if an admin can see and use all data from Delegate365, or just "his own" data. The following screenshot shows that setting in the Policies / Permission Policies menu (see more about these policies at New permission policies).


If the switch "Is PowerShell Administrator" is set to Yes, all admins that are assigned to that permission policy see all data in Delegate365. If that switch is set to No, the OU scoping is active, and these admins see only data that is assigned to their OU's. So, the PowerShell commands check, what data may be delivered to that admin, in the same way as the Delegate365 web portal. Portal Admins define, if scope admins shall have full access or not by defining the underlying permission policy for their admins. Usually, the OU restrictions make sense for scope admins and the permission policy should be set to "Scope Admin" (click that button and adapt then if needed) which sets the "Is PowerShell Administrator" to No.


Another benefit of using Delegate365 PowerShell is, that the operations of admins made though PowerShell are protocolled in the Audit Logs as well. Again, this is consistent with the Delegate365 web portal and operations can be tracked.


Check out for the latest news and documentation regarding Delegate365 PowerShells. This is the place where all PS-documentation will be done and updated.

Within PowerShell, execute Get-Command -Module Delegate365 to see a list of available commands in this module. All Delegate365 commands have a "D"-character (or the word Delegate365) included after the method to be not confusable with other PowerShell commands, e.g. Get-DUser for Get-Delegate365User.


Get-Help command-name delivers for information about a specific command, as this example: Get-Help Get-DResource


Add the "-Examples" parameter as Get-Help command-name -examples for samples how to use a specific command as here.


More Delegate365 PowerShell

Advanced PowerShell users will find out the functionality quickly. The Delegate365 cmdlets work in the same way as other PowerShell modules. More samples of using Delegate365 PowerShell will follow in the next weeks. We also plan to extend that if needed in future. We hope you like this new functionality to automate with scripts.

Happy automating with Delegate365!

Delegate365 regions

Thursday, November 1, 2018

Delegate365 runs completely in Microsoft Azure, in a region of the customer's choice. So, for US-based companies, Delegate365 is hosted within the United States of America, for EU-based customers, Delegate365 is hosted within the European Union, etc. Since we sometimes get questions about the location of the Delegate365 solution, we want to inform about the hosting options here.

Delegate365 as a service

Delegate365 is developed and operated by atwork and runs as Software-as-a-Service (SaaS). Customers can test and use Delegate365 instantly without any installation out-of-the-box and updates to the Delegate365 tenant are done automatically. Delegate365 runs completely in Microsoft Azure without customers having to maintain the solution in any way. The customer's data never leave the desired region, except the customer exports his data intentionally. The hosting costs are included in the Delegate365 price. Thus, Delegate365 is delivered as a carefree package to be used instantly.

Availability of Delegate365 in Microsoft Azure

Currently, Microsoft offers Azure services in 54 regions worldwide, see Azure regions.


Out-of-the-box, Delegate365 works in all Microsoft regions that are not classified as "sovereign" or "national" cloud and that are currently available for customers, see regions and locations. The Azure datacenter within the region will be set as optimal as possible for the customer and the tenant. Delegate365 is currently available in the following regions:

  • America: East US, East US 2, Central US, North Central US, South Central US, West Central US, West US, West US 2, Canada East, Canada Central, Brazil South
  • Europe: North Europe, West Europe, France Central, France South, UK West, UK South
  • Asia Pacific: Southeast Asia, East Asia, Australia East, Australia Southeast, Central India, West India, South India, Japan East, Japan West, Korea Central, Korea South

Newly announced Azure data centers that can be used in the future:

  • Europe (starting 2019): Germany North, Germany West Central, Switzerland North, Switzerland West, Norway East, Norway West
  • Middle East and Africa (starting 2019): South Africa West, South Africa North, UAE Central, UAE North

The regions and availability of Delegate365 might change in future, depending on Microsoft's Azure availability, conditions and legislation.

National Azure Clouds

Besides the Microsoft operated datacenters, there exist national clouds, see Microsoft National Clouds. These are datacenters for the US Government, the Microsoft Cloud Germany and the Microsoft China Cloud as the Microsoft website informs:


The national clouds receive new Microsoft features and services at a later date, or not the full functionality. For example, see services that have recently been announced in national clouds as Announcing General Availability and Sovereign Cloud Support of Managed Service Identity for App Service and Azure Functions or at Power BI is now available in three separate national clouds.


Delegate365 is currently not available in national clouds. Based on customer's needs, that could be addressed in future.

End of life for Microsoft Cloud Germany – Hello, new datacenters in Germany

As Microsoft announced end of August in "Microsoft to deliver cloud services from new datacenters in Germany in 2019 to meet evolving customer needs", the existing Cloud Germany operated by T-Systems will no longer be available for new customers and will be replaced by two new datacenters in Germany located in Berlin and Frankfurt. These are planned to be available to customers in the fourth quarter of 2019 for Azure and in the first quarter of 2020 for Office, and Dynamics to follow later in 2020. Instead of reduced functionality (and different pricing), the new datacenters will offer "full connectivity to Microsoft’s global cloud network" and will be operated by Microsoft.

"Based on this evolution in customers’ needs, our cloud strategy for Germany will focus on delivery of the new cloud regions in Germany that are consistent with our global cloud offering. With this focus, we will no longer be accepting new customers or deploying any new services from the currently available Microsoft Cloud Germany. Existing customers can continue to use the current cloud services available today, which we’ll maintain with necessary security updates.
… Based on this evolution in customers’ needs, our cloud strategy for Germany will focus on delivery of the new cloud regions in Germany that are consistent with our global cloud offering."

Delegate365 is not available in the "existing" (old) Microsoft Cloud Germany. Of course, Delegate365 will be available in the new datacenters in Germany in future. Also, Delegate365 can be hosted in all new datacenters, as announced at Microsoft reveals plans for new datacenters in Europe and the Middle East, while expanding its cloud offerings.

Define the Delegate365 region

When customers are starting with Delegate365, they receive a form to define the desired Azure region for their Delegate365 instance. So, every customer decides where his Delegate365 solution shall be hosted worldwide. The region stays for the whole operating life of Delegate365.

We hope, this article clarifies the hosting options of Delegate365. We at atwork take security and privacy very seriously. In case of any questions about Delegate365, pls. contact us.

Delegate365 changelog version 8.1-Many new features

Monday, October 22, 2018

These days, the next major Delegate365 version 8.1 is released. In that new version, there are a lot of new and improved features available for all Delegate365 customers. The menu has been restructured, permission policies allow to define granular rights and license policies simplify the set of licenses for Scope Admins. Furthermore, there are a bunch of useful improvements and the Delegate365 PowerShell module is available. See the details here.

  • Run a setup: Admins need to run the Delegate365 setup after the upgrade process, see the How-To at (Re)run the setup.
  • New menu: The Delegate365 modules have been grouped by topic, so e.g. all modules related to "licenses" can now be found in the menu "licenses", makes sense, or? Pls. see the details at Menu restructuring.
  • New Permission policies: The existing permissions for Scope Admins have been replaced with permission policies. Portal Admins can define such policies and apply them to multiple Scope Admins on a very granular level, for each feature and each box, even for Read Only or Write access. Check out permission policies.
  • New license policies: See license policies.
  • Scheduled Reports: Reports can now be scheduled to run now, weekly, or on a monthly basis. Simply select the desired time:
  • Add Shared Mailboxes as member to a Distribution Group: Shared Mailboxes and Resource Mailboxes can now be added to Distribution Groups, as shown here.
  • Block user mailbox when converting: If a mailbox is converted from a user mailbox to a Shared Mailbox or to a Resource Mailbox (or vice versa), it can make sense to block the user login in that process. That feature has been added in the convert-process.
    So, if a user mailbox is converted, the Convert-panel allows to block the user login for that mailbox. By default, the Block sign-in switch is set to No. If required, set it to yes. This deactivates the user and noone can sign-in to that mailbox even if the password is known.
    The same works vice versa when a Shared Mailbox or a Resource Mailbox is converted to a user object. Then, it could make sense to active the sign-in option for that mailbox.
  • New: Sync rules support of domains: The User sync rules now can use the domain name for assigning to an OU with the same name, e.g. user could be assigned to OU without the need to add meta information to the user object or add users to a Security Group. This simplifies such automatic OU-assignments.
  • Restore deleted users AND Office 365 Groups: Now, Delegate365 can restore deleted Office 365 Groups as well. Select the group and undelete it if needed.
  • Set license quotas if not existing: To prevent that Scope Admins can assign Office 365 licenses when there is no quota defined, this can be done now for all OU's and licenses that already have no quota set. The function creates a quota for each OU and license with a value of 0. That can be modified as needed afterwards for each item as usual. This feature helps not to forget to set quotas and is just some clicks away.
  • External license order: There's a permission change here: Before, Administrators could only see their own order requests. Now, the order license order list shows order request of all entitled OU's. This makes sense, since Admins can now see orders for their OU's made by other Admins (for the OU). Also, for our CSP customers, the simple order workflow can now be used for ordering external Office 365 licenses as well. This will be covered in an extra article.
  • PowerShell support: This topic will be covered in an extra article. For the documentation of the existing Delegate365 PowerShell commands, pls. see PowerShell cmdlets for Delegate365 on GitHub.
  • Small fixes: Some user field validations have been extended, the sorting of the licenses policies list has been fixed and some other minor fixes and updated descriptions have been accomplished.

We think, the new features in Delegate365 v8.1 allow a lot of extended functionality and can simplify daily tasks of many IT-Administrators. Hope you like it!

If you want to see the full changelog, please visit our blog.