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

Delegate365-Read audit logs

Friday, February 21, 2020

Whenever a user or the synchronization makes a change in Delegate365, this is logged. Logging is a collection of changed properties of an object. Since many different things can happen, logging depends on the action. See more here.

Delegate365 protocols the changed object properties or assignments to an object. Through the service-oriented architecture, it can take up to 5 minutes till actions are visible in the audit logs. Logs are available for users who have permission to the corresponding Logs modules. For scope admins, usually the Quick Audit OU´s menu is available to see changes of their own objects as follows.


In that module, the log goes back 7 days. For older logs, Delegate365 provides the Log Access module to directly connect to the log storage, see below.

I think, the best way to explain the changes is to look at a sample. Here, an admin has changed the user object biancap. The latest changes are on top, the oldest at the bottom of the list. You can filter the list for the UPN or other text parts on top of the list. So, here are 3 actions concerning biancap.


We start the reading from the bottom up.

  • action 1: First, biancap has been changed. We see, there were no changes in the user fields (the user properties). But the licenses are empty - there are 0 items shown in the Array [0] entry. This means, previously assigned licenses have been removed.
  • action 2: The second action shows that 5 fields of biancap have been changed: fields Array [5]. fieldName: "Department" has an "oldValueIfAny" property set to "Sales". The "currentValue" shows "Sales Seattle". This is the new and current value of that user property. We also see that fieldName: "StateOrProvince" has been changed from "WA" to "". The fieldName: "UserPrincipalName" is protocolled, but has not been changed, there´s the same value in both properties. Such entries can be existent. In that case, the value has not been changed, but is essential for the operation and is protocolled. This depends on the action and the response of Office 365. No other properties or assignments have been changed in action 2.
  • action 3: The last action on top shows that the licenses have been changed: licenses: Array [1], 0: Object, name: "OFFICE 365 ENTERPRISE E5". This log entry indicates that this license has been assigned to that user. If plans are enabled or disabled within the plan, their values are protocolled in the sub-fields. No other actions happened in that operation.

If possible, Delegate365 protocols the old values, how it works with user properties. If the action was an assignment, as licenses, the old license array is not protocolled, but the new license assignments are logged.

Group operations are logged in the group log, not per user. If a user was added or removed from a group, the membersAdded and membersRemoved keys are containing the users. Here, the admin added biancap as member to the Office 365 group Retail.


The same happens vice versa if a user is removed from a group. Here, the admin removed biancap as member from the Office 365 group Retail.


The logging protocols actions as JSON entry with that key/value schema that can be used from Power BI or other systems for further processing. The action above is stored as here.

{ "fields": [],  
{ "distributionGroupAdded": "",   
"distributionGroupRemoved": "",   
"securityGroupsAdded": [],   
"securityGroupsRemoved": [],   
"sharedMailboxAdded": "",   
"sharedMailboxRemoved": ""
"licenses": [], 
"membersAdded": [], 
"membersRemoved": [ "" ]

This format allows a flexible storing of actions. You can connect to the storage with the credentials in the "Log Access" module and use tools as Microsoft Storage Explorer as in the the following screenshot.


For older logs, you need to export the logs or use Power BI connected to the storage. Please see Delegate365-Working with Audit Logs and Delegate365-Working with Audit Logs and Power-BI.

All actions executed in Delegate365 are logged, whether it's a manual action or an automated process. Portal Administrators get access to all the audit data of Delegate365. Scope Admins usually have the Quick Audit OU´s module for checking their latest actions. There are several ways to get all audit data easily for further usage in other tools. We hope these features help to understand actions in your Delegat365 environment. See more about getting data from Microsoft 365 and Delegate365 at Delegate365 Reports.

Delegate365 - Methods of getting license statistics

Saturday, February 1, 2020

There are several ways to get the number of assigned Microsoft 365 licenses in Delegate365, depending on the administrator´s permissions policy and the OU assignments. See all methods listed here.

  1. Licenses / License report: This module shows den current status of licenses per OU as shown here. First, the Delegate365 licenses are shown. Below, every OU is listed in a box with it´s numbers per object type (such as Users, Groups, Shared Mailboxes, etc.) and the numbers of Microsoft 365 licenses that are assigned to users in that OU. If there are license quotas set, the quota is shown as well.
    This module is aimed at administrators, the Delegate365 licenses and number of managed objects are shown as well.
  2. Licenses / License statistics: This module is aimed for Scope Admins and shows the numbers of used Microsoft 365 licenses as follows.
  3. Licenses / License aggregation: For customers, it is often important to know later, on which day in which unit how many licenses are assigned. To enabled such a reporting, Delegate365 stores the assigned Microsoft 365 licenses on a daily basis. In the License aggregation module, administrators can filter for their OU´s and a date range. In the result list, all assigned Microsoft 365 licenses are shown for the OU and per day. This list can be easily exported using the CSV and Excel symbols in the top right of the list as shown in the screenshot below.
    This list shows a very detailed historical use of the licenses and quotas.
    Note: In this chronicle you can go back to the beginning where you started working with Delegate365, not only 30 or 90 days as Microsoft 365 stores data!
  4. Reports / Delegate365: The report License statistics in the Delegate365 section at the end of the report´s list shows the numbers of assigned Microsoft 365 licenses as well.
    License statistics: This reports is an exported list including the current numbers of assigned licenses and quotas per OU as shown in the Excel export here.
    Note: If you are interested, what objects are assigned to an OU, check out the OU overview report. This export includes all objects in a line per OU: users, groups, etc.
    The report Active user detail in the Office 365 section shows assigned licenses per service for a simple analysis:
    Note: To see a list of available reports with samples, see Delegate365 on GitHub
  5. Reports / Delegate365 / notifications: Note that every admin can choose when to receive a report in the Schedule dropdown. Available options are Run now, Run weekly (each Monday) and Run monthly (each 1st). This allows to automate the report generation on a individual user basis.
    Note: The Portal admins controls how the notification is sent to the users: Send notification with link to the Delegate365 reports page, Send notification with the report as attachment, and Send a notification with a direct download link to the report, which is valid for 24 hours. Our recommend method is to use the last option with the 24-hours link. See more at Delegate365 changelog version 8.4 - New Report notification settings.
  6. User properties / Notifications: Another option is to set the Daily Notifications to Yes in the user properties. Click on your user name in the top right corner and select Properties. Turn on the daily notifications and enter the email address to send the report to (usually that would be your work account address you use to manage Delegate365). Then, click Save.
    The daily notification function generates a report every night that is sent to the provided mailbox. The admin gets an overview of the assigned users of his assigned OU´s. The email is sent with the subject "D365 daily notification" and looks similar as here.
    This notification includes a section for every OU showing the current numbers of assigned Microsoft 365 licenses and managed objects on a daily basis automatically. Every admin can select this option if needed.

So, Delegate365 provides several methods to get and to export license statistics, even historical data.

Beside these statistics, Delegate365 provides more license features: Admins can manage license quotas, friendly license names and they can select the usage locations within their Delegate365 environment. Scope admins can take advantage of the internal license order module to get more licenses for their OU´s. License assignments can be done per user, with the bulk license module, or automatically based on Sync rules. See more about the latest Delegate365 features here.

Delegate365 - Sync rules and license quota example

Wednesday, January 15, 2020

Delegate365 allows to split a Microsoft 365 tenant and to delegate management of assigned objects. With synchronization rules, licenses can be added or removed automatically. This works together with license quotas. In this article we show an example.

  • Scenario: Here, we have a demo tenant and two administrators in Delegate365: Admin and AdeleV. The Admin can manage the OU´s "Seattle" and "New York" and has the role "Portal Admin". AdeleV has the role "Scope Administrator" assigned and she can manage OU "New York" as we see in the Delegate365 Administration / Administrators menu.
  • Scope Admin AdeleV: User "AdeleV" sees currently 7 users in her assigned OU "New York". 3 users have an Office 365 license (E5) assigned: Allan, Isiah and Lee. The other 4 users don´t have any Office 365 license assigned as we see in the following screenshot.
  • Define a license quota for "New York": The Admin now creates a new license quota for "New York" and license "Office 365 Enterprise E5" - we use the short form "E5" in this article - for 4 licenses in total. This can be done by entitled admins in the Licenses / Quotas menu.
    This means that members of OU "New York" cannot be assigned more than 4 Office 365 E5 licenses in Delegate365.
  • Create a security group with members for automatic license assignments: The Admin creates a new security group with the name "E5". 4 members are added as members: Allen, Cameron, and Delia from OU "New York" and Diego from OU "Seattle". AdeleV only sees "her" 3 users (these are the first 3 users in her users list).
  • Define a license sync rule: The goal is to automatically add the "E5" license to all members of the security group "E5" (I chose the same name to show what this group does), so to all 4 members. In the users list shown to AdeleV above, we see that 2 users in OU "New York" currently do not have the "E5" license assigned, these are Cameron and Delia. The users Allen and Diego already have the "E5" license assigned. To accomplish this task, the Admin adds a sync rule in Delegate365 as here:
    Step 1 is to add the condition: If Security Group contains the expression "E5" then…
    Note: The condition is using the contains filter to apply the rule to every security group that has "E5" in it´s name. So, this rule would also assign the licenses set to security groups "E5", "Office 365 E5", "E5 licenses", "licenses e5 for standard users" or "Office5". This is especially useful if you have many groups and want to simplify the assignment of licenses. So, keep this in mind to get the desired license assignments.
    …we click in the license icon and add the license "E5" as step 2.
    Then, in step 3, we save the sync rules settings at the page bottom.
  • Sync to test: Now we have defined a sync rule to automatically assign license "E5" to all members of security group "E5". Wait, we have defined a license quota for "New York" with 4 times "E5" licenses. So, what will happen? To see the result, let´s start the sync manually as Admin in Administration / Sync operations.
    After clicking the Start AAD sync button, we confirm the start. This process will take a minute or up to some hours, depending on the tenant size and the sync rules.
  • Check the result: As a result (after the sync has completed, we can check in the Sync history box and click Refresh…), AdeleV should see one more user having the "E5" license assigned. In this sample, this is user Delia. We also see that Cameron does not have an "E5" license due to the total license quota of 4 "New York" licenses.
    The process worked. 4 users in OU "New York" have the "E5" licenses assigned (only and automatically).
    Note: Sync rules cannot be configured which users get the licenses. They run through the user objects and (un)assign licenses in the order they are delivered from the Microsoft API.
  • Notifications: The Portal Admins will see a corresponding message in their notification center in the Delegate365 menu bar, at the message icon. The message says: "Manage License: No more licenses available for OU: New York and License: OFFICE 365 ENTERPRISE E5". The license quota would have been exceeded by the sync operation and therefore no more licenses are assigned automatically. Also, a Scope Admin as AdeleV cannot use more than 4 "E5" licenses in the Delegate365 interface.
    Note: Currently, Scope admins do not get this notification.
  • No more licenses? What happens, if there are no more pool licenses available in the tenant? In that case, Delegate365 will inform the Portal Admins in the notification center as well.
    The message will say: "UserLicenseSyncJob(378) Code: Request_BadRequest Message: Subscription with SKU [someid] does not have any available licenses. Inner error". This is the message delivered from the Microsoft API combined with the user information. Delegate365 cannot assign the desired license since there is no license left in the pool. In this case, the organization needs to add more Office 365 licenses if needed or to reorganize their assigned licenses. Delegate365 supports internal license orders in the Licenses / license order menu.
  • Quota exceeded? Can the Delegate365 license quota be exceeded? Yes, this can happen.
    If licenses are set outside of Delegate365 (for example, in the Office Admin portal or with PowerShell), they remain assigned to the users and Delegate365 does not remove any licenses if a defined license quota is exceeded. In that case, the licenses and the quota will show a larger number in the user license menu, such as "E5 (10/4)": 10 users have the "E5" license assigned, but the quota is set to 4 licenses. The Scope Admin then can only reduce licenses by un-assigning licenses from users until there are less then 4 licenses assigned and reuse them afterwards. So, AdeleV could remove licenses from 7 users, then 1 license is available (the quota is 4 licenses( and can be assigned to another user.


This scenario shows the behavior of Delegate365 when working with license quotas and license sync rules. License quotas can be set per OU and for each Office 365 license. They help to set the available number of license per OU. This functionality is also helpful for billing OU´s (cost centers) for the usage of their Office 365 licenses, many customers of Delegate365 use this function.

We hope this article helps to use the (automatic and manual) license assignments correctly.

Delegate365 version timeline

Friday, December 27, 2019

Delegate365 has continued to evolve over the past few years. See the timeline of the Delegate365 versions in this graphic.

atwork started the development of Delegate365 ( in early 2013 as an Add-On for Office 365. Many functions have been added since then. Here you can see the graphic of the Delegate365 versions timeline as of today (click to enlarge).


On average, a new Delegate365 version is deployed every 3 months. Delegate365 is operated as SaaS, so updates usually happen automatically. For versions that require additional permissions, a Delegate365 administrator must run a setup once on request. You can find the Delegate365 version details in the corresponding articles here. The current version is Delegate365 v8.5. The next update will be Delegate365 version 9.1, planned for February 2020.

Happy delegating with Delegate365!

Delegate365 changelog 8.5

Thursday, October 31, 2019

Delegate365 version 8.5 is an update to the extensive Delegate365 version 8.4. This update includes a new sync operation "Sync with security group" and some sync fixes. See a description here.

  • New "Sync with security group" mechanism: In Administration / Sync rules, this option allows to synchronize all members of a Security Group with assigned members of an OU. After a sync, only the members of a security group are assigned to an OU. Removed members will be removed from an OU, new members are added. See a full description of this sync feature at Sync with Security Group.
  • Reports overview: The reports list has been extended. A list of all reports with samples is available at the Delegate365 GitHub reports repository.
  • Small sync fixes: During the sync a lot of situations can happen due to Office 365 restrictions such as available licenses or updated objects, temporary issues or because of parallel executions in Delegate365 to speed things up. We went through the latest errors in various sync logs to intercept possible errors that could happen if object properties were missing or not updated in time. So, this update fixes such operations that caused smaller errors in the past. If errors still occur, the sync usually continues its work with the next object and often the sync repairs data in Delegate365 with the next run.

Delegate365 version 8.5 is currently in test phase and will be available starting mid of November. Productive tenants will be updated end of November to beginning of December.

Delegate365 changelog 8.5-Sync with Security Group

Wednesday, October 30, 2019

Delegate365 version 8.5 comes with an updated sync operation for the option "Sync with security group". This option allows to achieve a match between (specific) Office 365 security groups and Delegate365 OU´s. In short, this means that the members of a Security Group control the assigned members of an OU, and after a sync, they are identical. See a description of this sync feature here.

Sample scenario

To describe the "Sync with Security Group" functionality, here´s a demo. In our organization, there are branches in 3 locations: Seattle, New York, and London. We want to have users in some locations automatically assigned to OU´s in Delegate365. For that purpose, we are using Security Groups in Office 365 and add the users as members to these groups. So here´s the detailed scenario.

Sync with security group

In Administration / Sync rules menu, we turn on Sync with security group as shown below. This switch set to Yes hides the other settings below and enables the synchronization with Security Groups as the only method. When the switch is set to No, Admins can define alternative properties for the sync, but members stay in OU´s and get added, but not removed. So, for a full synchronization with security groups, the switch must be set to Yes.


Note: "Sync with security group" is the recommended sync option for working with Delegate365. It´s much faster than a sync with user properties and automatically removes users from OU´s.

These are the rules for the Sync with security group setting set to Yes:

  1. At the sync, Delegate365 compares the name of every Security Group with the name of an OU. If there´s a match, the members of that Security Group will become the members of the OU (see below). The comparison method checks if Security Group Display name "New York" = OU name "New York", but upper and lowercase are not be considered, so "New York" = "new york".
  2. Users that are not members of the Security Group, will be removed from the corresponding OU automatically. After the sync, Security Group members = OU members (see below).
  3. If there´s no match for a Security Group = OU, no automatic OU assignment happens.
  4. If a user is member of multiple Security Groups (and there exist corresponding OU´s), the alphabetically sorted last Security Group will be used for the OU assignment (see below).
  5. If the switch Create OU if not existing is set to Yes, all Security Groups will be created as OU´s in Delegate365. So, be aware that this might not be the desired result for using Sync with security groups, every Security Group will be existing as OU in Delegate365.

So, here´s the demo scenario in a test tenant.

OU´s in Delegate365

In Delegate365, there exist 3 OU´s: Seattle, New York and London. We will not use London here, but the first two OU´s, just to keep it simple but to illustrate that, of course, Admins can manage multiple OU´s with different aspects.


There are currently no users assigned to any of these OU´s. It´s important that the OU´s have the same name as the security groups we want to sync. In our sample, it´s Seattle and New York only.

Security Groups in Office 365

In Office 365, there might exist several other security groups, but we don´t want to use all of them in Delegate365 for any OU assignments. The Office Portal shows theses security groups:


We are interested in 2 security groups that shall be used for the OU assignment in Delegate365: Seattle and New York.

  • In security group Seattle, there are 2 members: AlexW and DebrahB
  • In security group New York, there are 2 members: IrvinS and PattiF

So, the members of these two groups shall be synced to Delegate365 OU´s.

Admins often use the Office 365 admin portal or tools like PowerShell or AAD Connect to modify users and groups outside of Delegate365, so I use the admin portal, too. Of course, these operations can happen within Delegate635 as well.

Assign the OU´s to the Admin

Ensure that the current Admin can manage the OU´s and domains, as here. In this sample, the Admin can manage Seattle, New York and London and the domain of the demo tenant. If you do not see users, pls. have a look at Troubleshooting Delegate365.


Currently, there are no users in these OU´s, the users list is empty.

Run a sync

Let´s run the synchronization with that setup in menu Administration / Sync operations.


Check the result

After the sync is completed, check the Users list. We should see the automatically new assigned users: 2 in Seattle, and 2 in New York, as here.


AlexW and DebraB are in OU Seattle, IrvinS and Patti are in OU New York.

Test the sync with changed group members

After the initial sync worked properly, we test again with different members in security group Seattle: DebraW is removed and HenriettaM is added as here:


So, Seattle now has AlexW and HenriettaM as members. Let´s run the sync again in menu Administration / Sync operations.

After the sync, the users list shows the new OU members. We see the new members in OU Seattle: AlexW and HenriettaM, while DebraB was removed.


So, the sync did update the OU memberships as expected.

Test the sync with multiple group members

What, if a user is member of multiple security groups and the Sync with groups function runs?

So, here IrvinS is assigned as member of New York AND Seattle (and some other groups) in the Office portal.


In Delegate365, IrvinS is currently assigned to OU New York. We run the next sync in Delegate365.

After the sync, IrvinS has changed from OU New York to OU Seattle.


This is because the Delegate365 sync sorts all groups by name and the last group wins.

As the rules at the beginning state, Sync with Security Group ensures that all current members of a Security Group are equal to the OU assignments in Delegate365, if there´s a matching OU name.

If the Delegate365 license quota is exceeded through automatic OU assignments

To clarify the Delegate365 licensing with automatic OU assignments: Delegate365 must be licensed for all users that are managed within the solution. Relevant are the users that are visible in the Users list. See Delegate365 license information for details. If more users shall be assigned to an OU, Delegate365 stops doing the OU assignment if the Delegate365 license quota is exceeded.

To demonstrate that, we have set the Delegate365 licenses to 5 while there are already 4 users added. The licenses can be checked anytime with the warning icon in the menu bar as here.


To simulate the behavior, I added 1 more member to security group Seattle (DiegoS) and 2 more members to New York (DiegoS and EmilyB) as here.


So, in total there are now 6 uniqe users to sync (AlexW, IrvinS and DiegoS are in both groups). The next sync is started.

After the sync has completed, the result looks as here: EmilyB has been added to OU New York. DiegoS has not been assigned to any OU since the Delegate365 license quota did not allow the operation.


To complete that sample, I remove EmilyB from security group New York and run the sync again.

After the sync, EmilyB is removed from Delegate365, but DiegoS came in in OU Seattle (the last group).


This sample illustrates the behavior when working with the "Sync with security group" option. We recommend to use that sync option in future.

Delegate365 - Secure and setup your tenant

Friday, October 11, 2019

Delegate365 is using the Microsoft 365 and Azure standards to sign-in and to communicate with the Microsoft APIs. Here´s the best practice how to secure your environment for using Delegate365.

1. Secure your Microsoft 365 tenant

Microsoft 365 provides a bunch of features to harden a tenant and to raise the Secure Score. Every administrator should start improving the security with setting Conditional Access, MFA, and policies.


You can learn more about Microsoft Secure Score here. This demo tenant screenshot above is not properly configured and should definitely be secured. If your need support, we got you covered, see our Enterprise Security & Compliance Workshop offering.

2. Create a Service User for Delegate365

We recommend to create service users for specific purposes, such as for scheduled tasks, other apps and for Delegate365. Open the Azure portal and login as Global Admin. Navigate to Azure Active Directory - Users. Click on the New user link and create a service users, such as, similar as here.


Note the username and the password. We need these credentials for the sign-in process and to generate an app password later.

3. Assign the administrative role to the service account

Open the newly created user from the Users list and assign the "Global Administrator" role to the service.delegate365 account. That user must be able to access the Azure Active Directory and to create the Delegate365 app. Click on the "Assigned roles" menu, then click on the "Add assignment" link. Search the "Global Administrator" role and click the Add button on the bottom. When done, the screen should look as here.


4. Ensure that MFA is not set for the service account (temporarily)

For the Delegate365 setup, we need a temporary Multi Factor Authentication (MFA) exception: MFA must be disabled for the service.delegate365 account. You can check that as Global Admin in the multi-factor authentication portal. Users themselves can use the link to configure their second factor as needed anytime.


Note: After the Delegate365 setup, MFA should be activated again, see below. To setup MFA, see Set up multi-factor authentication.

5. Run the Delegate365 setup

Now you need the data from your Delegate365 setup email: the setup URL and the Delegate365 configuration password. The subject title starts with "Welcome to Delegate365", the email looks as here:


Open a browser in private mode, and open the setup URL. That´s the Delegate365 portal URL with /setup added. Enter the configuration password, the service.delegate365 account and the password.


The setup process will runs for one to two minutes. When completed, click on the Login button.


Sign-in with the service.delegate365 account. You will now see the Delegate365 dashboard.


You can start configuring Delegate365 now, or do that later. A box in the dashboard with links to the modules informs about the first steps such as creating OU´s and define Administrators. Also, check out the Delegate365 videos.

Leave that browser windows open, we will return in a minute.

6. (Re)Activate MFA for the service account

Open the multi-factor authentication portal as Global Admin and enable MFA for the service.delegate365 account as here.


See more about MFA at Set up multi-factor authentication.

7. Enable App Passwords in your tenant

For client applications such as older versions of Outlook that cannot work with modern authentication methods, and for automation where there´s no second factor available such as in a scheduled unattended task, Microsoft provides "App passwords". These are automatically generated passwords that are harder for an attacker to guess and are more secure than a user password that is sent. Since Delegate365 is running as service, it requires to execute some Exchange operations without user interaction and without a second factor. This is, where the app password comes in for performing tasks automatically.

Open Multifactor settings portal as Global Admin. Open the "service settings" page and enable "Allow users to create app passwords to sign in to non-browser apps". Then, click the "Save" button at the bottom as here.


This enables app passwords in your tenant. Any user must then create his own app passwords if required. You can close that page then.

7. Setup MFA for the service account

Switch to the other browser where Delegate365 is still open and where you are signed-in as service.delegate365. Open another tab with the address of the multi-factor authentication portal. You should now be asked for the other factors for that account.


Configure the method you want use for the sign-in…


In most cases, the "Mobile App" is a good choice.


At the end, you will see a generated app password. We need that in Delegate365. Note that app password.


Here the app password is starting with "jzr…". Click "Done".

8. Get a new app password for accounts with MFA

If you need to create an app password for an existing account with MFA enabled, login with that account and open the My Account website and follow the steps described at Create an app password for Office 365.


The link opens Here, a user can manage his app passwords.


Microsoft recommends not to exceed 40 passwords and to use them per device, not only per app. Every user is responsible for his app passwords in the same way as for his user password.

9. Use the service account and the app password in Delegate365

Now, when we have the app password created for the service.delegate365 account, we need to add the new credentials in Delegate365. Click on Administration / Office 365 account and enter the credentials of the service.delegate365 user and the app password (here it´s "jzr…"). Do not use the user password. Click on "Save".


Then, click on the "Test credentials" button to see if the communication to Exchange Online works with the new credentials.


The message should inform that the Exchange account is valid. If the process fails, pls. check the service.delegate365 user credentials and create a new app password and use that for the service account.


We definitely recommend to use Secure Score and security settings such as Conditional Access and MFA to secure your Microsoft 365 environment. Delegate365 is using the same mechanism for user authentication as every other modern Microsoft services. For running specific Exchange operations, follow the steps above to create a service account and to use an app password to automate processes and to improve security.

Delegate365 changelog version 8.4 update-Speeding up License assignments

Friday, September 13, 2019

Delegate365 version 8.4 came up with a lot of improvements and updates. This version recently got another update to speed up the license assignment synchronization operation. See the details here.

Delegate365 allows to add sync rules to the sync operation to automate specific operations. In large tenants, the sync can run for a long time since all objects must be queried for changes. To accelerate the sync operation when using license assignment sync rules, we optimized this process as follows:

  • Old User license assignment: In the previous versions of Delegate365, license assignment rules could be defined for members of security groups and for user properties as shown here.
    So, the idea here is to write an information such as "Sales and Marketing" to one of the user properties, such as "CustomAttribute1", and to define that all users with that user property get the "Office 365 E5" license assigned automatically. Unfortunately, this causes Delegate365 to run through all user properties of the tenant which can cause long sync op runtimes.
  • New User license assignment: Assigning licenses based on security group membership is a more convenient and elegant way. So, we decided to remove the user property options to speed up the whole license assignment process. The new form includes only the option "Security group". Every member of the defined security group gets or loses the license(s) defined in the rules.
    So a rule allows flexible license assignments, such as: If a "Security group" contains "sg-Sales and Marketing" in the display name, all members of that group get a license for "Office 365 E5", etc.
  • Speed up the sync: As result, the sync op will run much faster when sync rules are used.

All Delegate365 tenants will be updated with the speed-up feature in the next weeks within Delegate365 version 8.4. To see a list of all updates of Delegate365 version 8.4, pls see Delegate365 changelog version 8.4-Teamify with policy support, Room Lists, Mailbox licenses management, Report download and more.

Delegate365 changelog version 8.4-Teamify with policy support, Room Lists, Mailbox licenses management, Report download and more

Monday, July 29, 2019

Delegate365 v8.4 brings a bunch of new features and improvements. Office 365 Groups management allows to teamify existing groups and to control all Teams settings including policy settings. The Sync Job can send warnings if many objects are deleted, Shared Mailboxes and Resource Mailboxes licenses can be removed, Reports can be directly downloaded, Room Lists are available, License Orders can be exported and much more. See a description of the new features here.

  • Create a new Team: When creating a new team in Groups / Office 365 groups, the administrator can set the new Team switch to Yes. This provisions a new Office 365 Group and creates a Team on top of the Office 365 group. After the new Team was created, don´t forget to set additional owners if required and members for the new team, see below.
  • Support for Group Naming Policy: If a Naming Policy is set (which can be controlled in Delegate365 as well, see below), the Group Name will be updated to comply with the naming policy. In this sample, "Project Apple" will be renamed to "GRP Project Apple Contoso" because the policy demands that naming.
    This affects also the Primary SMTP Address which now is email-ready formatted "GRPproject-appleContoso" plus the primary or selected domain.
  • Team-ify an existing Office 365 Group: The Office 365 groups list now shows the group "Type" in an extra column. Possible values are: Unified Group, Team and Yammer. An existing group of type Unified Group can be converted to a Team with the menu on the right as in the following screenshot.
    Confirm the message box with Yes. Then, the group type changes and the new team will be available, usually within some seconds.
  • New Office 365 Group and Team properties: The Office 365 Group properties have been extended to support all Team settings as shown in the screenshots below (there are 3 screens appended). Again, if a Group Naming Policy is in place, the policy will be shown and new group name will be modified automatically. E.g., if the group name is changed to "Project Charlie", with that policy, the new name will be "GRP Project Charlie Contoso". If no Group Naming Policy is set, the Group Name stays as entered. No worries, if the "New name" field stays empty and another option in that box is modified, the group name stays untouched as well.
  • Group Owner: Pls. note that the owner of a new Office 365 Group (or Team) is automatically set to the Administrator who created the group. In this sample, the group owner is the "admin@…" user. If a Group Naming  Policy is set, requiring e.g. the [Department] of the user, the data is looked up from the current creator user.
    Info: There are no members set automatically when a new group is created. Administrators must add their desired members that after the group creation.
  • New Office 365 Groups settings: There exists a new module in Administration / Unified group settings to define group policies if required. The following screenshot shows the sections that can be controlled for Office 365 Groups in the tenant: Classification, Blocked Words, Enable Group creation, Prefix suffix naming requirement, Guest settings und Guidelines.
    To access the new module in Administration / Unified group settings, the permission policy set has been extended with a permission for "Unified group settings" in the  Administration box. When Delegate365 was upgraded from a previous version, this setting is set to Yes if the Enable Administration switch is set to Yes by default.
  • Office 365 Groups Classifications list: Here, the tenant-wide settings can be defined for the Office 365 Group classification.
    Usually, it is recommended to use only 3 to 4 classifications to make it easy for the users to select the classification. Click the Save button at the page bottom after any changes. If set, a new Office 365 Group will automatically get the Default group classification until another defined classification is set. Existing Office 365 Groups stay untouched. If required, the classification can be set to existing groups afterwards.
  • Office 365 Groups Blocked words: In here, blocked words can be saved. These words cannot be used as Office 365 Group Name. In this sample, a group cannot start or contain the word "boss" or "ceo" in the group name. The switch enables or disables that feature. This setting has no effect on existing group names.
    Click the Save button at the page bottom after any changes.
  • Office 365 Group creation: Administrators can define a tenant-wide policy here to allow users to create Office 365 groups or not. If Enable groups creation is set to No, no user can create a new group. As exception the ID of ONE Security Group can be set so that only members of that group are allowed to create a new Office 365 group.
    To use this configuration, Global Admins can lookup the Security Group ID in the Azure Portal in AAD / Groups.
    You can also get the Group ID from the URL when opening the group in the Azure Portal. Use this Group ID in the "Group creation allowed groupId" field in Delegate365. Click the Save button at the page bottom after any changes.
  • Office 365 Group Prefix suffix naming requirement: Define a Group Policy Name in Delegate365. Every new Office 365 Group name will be adapted as defined in the template, e.g. "GRP [Groupname] [Department]". [Groupname] is the name of the Office 365 group an Administrator puts in in Delegate365. During the creation process, the group name will be modified by the template. If an empty string is provided here, no group naming policy is existing and new Office 365 group names will stay as entered.
    The template field can contain placeholders. Supported Azure AD attributes are [Department], [Company], [Office], [StateOrProvince], [CountryOrRegion], [Title]. Unsupported user attributes are treated as fixed strings, for example [postalCode] or similar. This setting has no effect on existing group names and is active from the moment on.
  • Office 365 Group Guest settings: This section allows to define guest settings for Office 365 Groups. There are switches for Allow to add guests, Allow guests to be group owner and Allow guests to access groups. Guests are so called external users, that are not users in the own Office 365 tenant. These switches define the behavior of groups tenant-wide.
  • Office 365 Group Guideline URL: Allows to use a custom webpage for delivering additional information to users when creating a new Office 365 group in the Office 365 portal. This can be set in Delegate365 as well if required.
    Pleas note that the Save button for ALL sections is at the page bottom here. Every change has to be saved in order to be active.
  • New Sync Rules including "Domain" for all mailboxes: In the "User" section, an automatic sync rule by "Domain" was already existing. This means, that users can be automatically assigned to an OU if the domain name equals an OU name, e.g. If username "" = OU name "" that user gets assigned to that OU, etc. The Domain rule has been added to Distribution Groups, Office 365 Groups (Teams), Resources and Shared Mailboxes as well. This simplifies the automatic assignment of mailboxes by their domain name.
    By activating the "Domain" option, all mailbox objects in Office 365 can be assigned to an OU with the same name by their Primary email Address.
  • New Sync feature Block user assignment: In Administration / Delegate365 settings, an automatic OU assignment (through the Sync Rules) can be stopped, if an enforced license quota is exceeded. The switch "Prevent the user from being assigned to an OU when an enforced license quota is exceeded" controls that behavior. By default this switch is set to No.
    When set to Yes and and any license quota for the OU would be exceeded, the user will not be assigned to that OU.
  • New Sync warning for deleted objects: When the Microsoft API delivers at least 20% fewer objects in a synchronization process than Delegate365 knows, a SyncJob warning is generated. The warning informs about the percentage of deleted objects per object type, as in this example: "The sync job has deleted n percent of the Unified groups. If this action was an error, the objects will be added again at the next sync."
    This warning informs Portal Admins and Notification Admins that a large number of objects have been deleted. That can happen through bulk operations with PowerShell or other deletions. Delegate365 gets the information from the Microsoft API and generates that warning.
    The warning is also sent to all Delegate365 users who have the permission "Is Notification Administrator" set to Yes in their assigned permission policy.
    Additionally, the users must have set a notification email address. This can be done by the Portal Admins in the administrators list, or individually by each Admin in the account properties as shown here.
    If these two conditions are fulfilled, the Notification Administrators receive the SyncJob warning message as well. The email hast the subject "D365: SyncJob warning" and looks as here.
    With that notification, the administrators can check if the deletion of the objects was intentional and react. If the cause was that the Microsoft API did not delivered all objects for whatever reason, the next sync will add missing objects if a corresponding sync rule is set.
  • New Report notification settings: When submitting a report request, the user can select to get a notification email when the report is ready as here.
    The report engine will generate the reports from the Scheduled reports and will move the reports to the Finished reports section.
    In Administration / Delegate365 settings, there is a new Report notification settings section that allows to define how report notifications are sent. Now, there are three options available that can be set for the Delegate365 tenant:
    1. Send notification with link to the Delegate365 reports page
    2. Send notification with the report as attachment
    3. Send a notification with a direct download link to the report, which is valid for 24 hours
    Option 1 is the default setting that sends an email to the user with a link to the Delegate365 portal report page. Option 2 and 3 are new and allow to send the notification email with the report included as attachment (2) or (3) - which is the recommended option - with a direct link to download.
    If the report email is generated with option 3, the email includes direct links to get the report by clicking on the link. This link includes a SAS* key that is valid for 24 hours.
    * A shared access signature (SAS) is a URI that grants restricted access rights to the Delegate365 storage resources. With the report links, a user can download the report as CSV or Excel file for further usage. The link expires after 24 hours for security reasons. Vice versa, in the Delegate365 reports page, generated reports are available for 7 days for the signed-in user before they are deleted automatically.
    So, Portal Admins can define the desired notification format and the report delivery in Administration / Delegate365 settings.
  • New Room Lists: Distribution Groups can now be created as "Roomlist". Set the Roomlist switch to Yes and Save the room list.
    The Type Details column informs about the Distribution Group type.
    Pls. note that only resource mailboxes and other roomlists can be added as member to a roomlist. In this sample, the Administrator can manage a user mailbox "Adele", but when searching for "ad", user mailboxes do NOT show up, only rooms, as "Conf Room Adams". This is intentional, only these two mailbox types are allowed as members.
  • Show UPN and OU in people picker: As shown in the screenshot above and below, the people picker now shows the UPN (or the Primary Email Address, here: Adams@…) and the OU name (here: Seattle) besides the name to identify objects straightforward.
  • Remove Office 365 licenses for Shared Mailboxes and Resource Mailboxes: When a user mailbox is converted to a Shared Mailbox (SM) or to a Resource Mailbox (RM), Delegate365 allows to block the sign-in for that user mailbox if desired. The following screenshot shows that process with a selected user mailbox in the Users list.
    Note the Block sign-in switch and the license information in that panel. This behavior can be defined in the Administration / Delegate365 settings as follows:
    In the Converting users box, Admins can set that converted mailboxes lose their Office 365 license at that conversion process – or not.
  • New Shared Mailboxes parameters: So that the mails sent from a shared mailbox also appear in the mailbox's "Sent" folder, the parameters "MessageCopySendAs" and "MessageCopyforSendOnBehalf" must be set. In Mailboxes / Shared Mailboxes, the settings MessageCopySendAs, MessageCopyforSendOnBehalf and MessageRecallProcessing have been added in the General section of a Shared Mailbox.
    Admins can now control this behavior in Delegate365 for each Shared Mailbox, see also here.
  • New Export License Orders: Users can export their license orders list as CSV or Excel file directly with the icons on top of the list.
    The export delivers one row per order. In the following screenshot one order has been transposed to show all fields below the generated order table.
    CreateDate is the order date, UpdateDate the date when the order was approved or cancelled. The export allows to process the license orders in other systems.
  • Export OU´s with date and user information: The OU list can be exported including additional metadata.
    The export file also shows when an OU has been created or updated and by what user, as shown here:
  • Export has been added to the following lists: Users, Shared Mailboxes, Resources, Contacts, Security Groups, Office365 Groups, Distribution Groups, Dynamic Groups, and OU´s .
  • User names with special characters: Delegate365 now allows special characters like "ěščřžýáíé etc." in the user name and other user properties. So, Delegate365 does allow to save the user name, including hooks and commas. In Czech this would be translated as follows: "Delegate365 umožňuje uložit uživatelské jméno, včetně háčků a čárek.". All these characters and many more are now supported as well as special characters in English names as "O’Maley" are valid.
  • New User password policy switch: Disable strong password: This setting can be modified for one or multiple users in the Users list, in menu Password policy as shown here. Disable strong password can be set to Yes or No.
    The Password never expires switch allows to set that for individual users if required.
  • License Sync Rules fix: Under certain circumstances, multiple license assignments of the same group did not work properly if licenses have been activated and some plans out of that SKU have been removed in another rule afterwards. This issue has been fixed in v8.3 and v8.4.
  • New Exchange Reports about Litigation hold: In Reports and Category Exchange, three new reports have been added: Litigation hold user mailboxes, Litigation hold shared mailboxes, and Litigation hold resource mailboxes.
    These reports show mailboxes with the information if Litigation Hold is set and if the mailboxes have an Office 365 license assigned.
    So, Administrators can simply identify mailboxes that require an Office 365 license.
  • Small fixes and re-labeling: Some labels have been slightly changed to make them clearer and description text has been updated.

We've added many of the features described to our customers´ direct feedback, and we think they're useful. The Delegate365 update v8.4 is planned during August for productive customers. New Delegate365 trials will get this version starting mid of August.

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!

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