Changelog

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

Delegate365 changelog 9.2.3-Add users to groups

Monday, July 26, 2021

Delegate365 v9.2.3 brings a fix for the Message Trace function and offers a mechanism to add multiple users to one or more groups directly from the user list. See it here.

Bulk add users to groups: In the users list, select more than one user. The menu on the right then shows the new option "Add users to group". In this sample, 3 users are selected: Debra, Pradeep and Lee.

The panel "Add users to group" opens and allows to select multiple groups of all types: Security groups, Distribution Groups, and Microsoft 365 Groups. The admin can search for the groups and add them to the Groups picker. By clicking on the Save button, a confirmation popup appears. When clicking Ok, the selected users will be added as members to these groups.

A quick toast message shows the result in the bottom right corner.

If the user already was a member of a group, this is ignored.
Check group assignments: As before, admins can check existing group assignments anytime in the Users list as well by opening the "Member of" function.

A panel then shows all groups where Debrah is member of.
Trace Messages Shared/Resource Mailbox Fix: If a message trace was executed, and the traced mailbox was a Shared Mailbox, or a Resource Mailbox, in some scenarios the output did not show all results. Also, SM and RM OU assignments are now fully considered. Both issues that could happen in some scenarios have been fixed.

This version has already been updated in all Delegate365 tenants and is available as of today.

Message Trace in Delegate365

Friday, July 9, 2021

When you run a message trace operation to get status information about specific emails, the result can vary, depending on time zone settings. See a sample here.

Show messages in the mail client

In this sample, we work with an email sent from azure-noreply@microsoft.com. In Outlook we see the timestamp at Mon 7/5/2021 7:08 PM (2021-07-05 19:08).

Message Trace in Delegate365

In Delegate365, admins can run a message trace to get information about the delivery status. When we run the message trace with the filter Startdate 2021-07-05 to Enddate 2021-07-05 - just this one day - and that user as recipient…

…we do not get a result. The Message trace result shows an empty list.

Why is that? Let´s check.

Message Trace with PowerShell

When we check with Remote Exchange PowerShell (you can also preferably use the EXO V2 module) and the Get-MessageTrace cmdlet, and an extended time frame from one day before (2021-07-04) to to one day after (2021-07-06) as here…

$session = New-PSSession -ConfigurationName Microsoft.Exchange `
  -ConnectionUri https://outlook.office365.com/powershell-liveid/ `
  -Credential $cred -Authentication Basic -AllowRedirection
Import-PSSession $session -AllowClobber

Get-MessageTrace -StartDate '07/04/2021 0:00AM' -EndDate '07/06/2021 11:59PM' `
  -RecipientAddress 'admin@tenant.onmicrosoft.com'

…we get two results. The second result from azure-noreply@microsoft.com is the one message we are interested in.

Received            Sender Address                           Recipient Address                 Subject                                    Status
--------            --------------                           -----------------                 -------                                    ------
06.07.2021 20:33:18 ProjectAlpha@M365x398760.onmicrosoft.com admin@tenant.onmicrosoft.com You've joined the Project Alpha group      Delivered
06.07.2021 02:08:34 azure-noreply@microsoft.com              admin@tenant.onmicrosoft.com Azure AD Identity Protection Weekly Digest Delivered

We see, that the one message is not from 2021-07-05 19:08 as shown in Outlook, but from 2021-07-06 02:08. The time difference between the two dates is 7 hours. Let´s search for the reason.

Get the tenant information

As a Global Admin, we can check the location of the Exchange Online servers in the Microsoft 365 admin center - Org settings.

So, the Exchange Server is located in the European Union, which means Central European Time (CET) which is UTC/GMT+1.

Check the mailbox time zone

The Delegate365 message trace did not return the same result. When we check the user´s mailbox with Get-Mailboxregionalconfiguration, we see that the mailbox settings are in a different time zone (in Pacific Standard Time, which means UTC−08:00) than the Exchange server (in Central Europe Time):

Get-Mailboxregionalconfiguration -Identity 'admin@tenant.onmicrosoft.com'

Identity             Language        DateFormat TimeFormat TimeZone
--------             --------        ---------- ---------- --------
admin                en-US           M/d/yyyy   h:mm tt    Pacific Standard Time

# To get all available time zones, we can run
Get-TimeZone -ListAvailable

The mail was delivered at 06.07.2021 02:08:34 CET, but the mailbox shows one day earlier, 2021-07-05 19:08 PST, which results in a time difference of -7 hours on the previous another day.

This is the reason, why different dates are shown, and why the message trace with the filter for one full day (2021-07-05) did not deliver that email(s).

Solution: Extend the date range in Delegate365 Message Trace

So, we add one day to the message trace filter in Delegate365. The Startdate goes from 2021-07-05 to Enddate 2021-07-06. Delegate365 always is using the full day, so in this sample, this covers 2 days.

We now get the two messages, including our sample email.

The time here differs because of the time zones of the mailbox, the Exchange server and the client. Between the local client time (CET: UTC+1) and the mailbox time zone (PST: UTC-8), there are 9 hours difference. The email that was delivered for the user on 2021-07-05 19:08 plus 9 hours makes 2021-07-06 04:08. This is the result that is shown in Delegate365.

Summary

To ensure, to get all messages of a specific time range with message trace, add or substract one day, depending on varying time zones of the Exchange server location and the user´s mailbox, as in this sample. Check the configuration to know about such possible settings.

Also, admins can set the Exchange server time zone as described at Configure the time zone in Exchange Online, and modify the mailbox time zone with Set-MailboxRegionalConfiguration.

I hope this sample helps to clarify and to avoid unexpected results in the message trace functions.

Delegate365 changelog 9.2.2-Manage group owners

Wednesday, June 16, 2021

Delegate365 v9.2.2 allows to manage group owners. The permission policies have been extended and the current admin can add him- or herself or additional group owners for Security Groups and Microsoft 365 Groups. See a description of the latest features here.

Enable (or disable) the manage owner feature: To enable the "manage owner" feature, you have to set the corresponding permission policies in the Groups - Security Groups - Manage owner from No to Yes, as here. Then, click on the Save button at the page end of the permission panel.

By default, this new setting is disabled. So, don´t forget to switch it on, if your admins shall be able to set the group owner for security groups (in the same way as for Microsoft 365 Groups). Once the setting is set, it will be effective for all admins that have that permission policy assigned. To learn more about setting permission policies, see here.
Check the Manager owner permission: To modify owners of a group, the "Manage owner" and "Ownership" settings in the policy should look as here:
Test it with Logout and Login: Note that the policies are applied, when a users signs in. If you modified a policy, the users must sign-out and sign-on again that changes take effect. Close the browser and open Delegate365 again.
Alternatively, the user can click on the Log Out menu in the user account menu, as here.

The user will be signed-out. After that process, the Delegate365 portal shows an info page. The user can click on the Delegate365 name in the top left corner to sign-in again.

After the successful sign.in, any modified policies are effective.
Create a new Security Group and add users as owner: When creating a new security group with the "+" icon, the panel now shows the owner selection- The set owner section is only visible, if the permissions are set as above. The admin can add him- or herself with the "Add me as the owner of the security group" switch set to Yes. Additionally, the admin can select users from his or her OU´s as security group owner, as here.
Modify the owners of a Security Group: When a group is selected, the menu on the right shows the Manage owner feature.

This opens the owners list, where new group owners can be added, or existing users can be removed.

Use the people picker to select new users.

A toast message shows the success of the operation.

Please note that the people picker follows the Delegate365 concept and shows only users that are assigned to an OU the admin is allowed to see. Admins cannot assign a user as an owner, that they are not allowed to manage (OU) or to see (Group OU).
Microsoft 365 Groups: Microsoft renamed the "Office 365 Groups" to "Microsoft 365 Groups". We did the same in Delegate365. The menus and text now is named Microsoft 365 Groups.
Create a new Microsoft 365 Group and add users as owner: The behavior for adding the current admin or additional users as owners of a new Microsoft 365 Group or Microsoft Team is now the same as for the Security Group.
General note for adding owners: For Security groups and Microsoft 365 Groups, it is not required to set an owner. If you create a Microsoft Team (as in the screenshot), it is mandatory to assign at least one owner. As a result, Delegate 365 adds the current administrator as the team owner, even if the "Add me as the owner of Microsoft 365 Group" switch is set to No, but the "Team" switch is set to Yes. In addition, the owner must be assigned a Teams license, otherwise Microsoft 365 delivers an error that is also displayed in Delegate365.
To make it short, we recommend to add the current user as an owner of a group, or to add another owner in all cases.
Message Trace modifications: The Mailboxes / Message trace function got updated and now shows a StartDate and an EndDate dropdown instead of the Date range dropdown that showed Past 24 hours, Past 48 hours and Past 7 Days. The new StartDate and EndDate Pickers allow to select a date between today and the last 7 days (from midnight to 11:59 PM). The default setting is to go back from today and display the last 3 days. This should make it easier to use. Also, the admin can now select the operator OR (only that was available before) and AND (that is new) to specify, if both conditions (sender an recipient), or just one condition must be met by the messages to be shown.
Small fixes: This version also includes some minor improvements from the previous Delegate365 version 9.2.1, such as exporting users fix, improved performance for the users list and the latest PowerShell module update.

Delegate365 version 9.2.2 will be available for all tenants next Monday, June 21st. Happy Delegating!

Delegate365 changelog 9.2-PowerShell module update

Friday, June 11, 2021

The Delegate365 PowerShell module got a small update to expand a user´s assigned licenses, license plans and proxy addresses. See the following description.

See the description at https://github.com/delegate365/PowerShell how to use the Delegate365 PowerShell module-

Check the Delegate365 PowerShell module version

First, ensure you have the latest version of the Delegate365 PowerShell module installed. Check with Get-Module as here. The version must be 1.0.0.10 (or in future a higher version).

If you don´t have v1.0.0.10 installed, update your Delegate365 PowerShell module, as follows.

Update the Delegate365 PowerShell module

Run Install-Module Delegate365 (if not already installed), or Update-Module Delegate365 as here.

Afterwards, check the version as above.

Test the Get-DAADUser expandable feature

Connect to your Delegate365 tenant as described here. Then, to get the advanced user properties, run the Get-DAADUser cmdlet with a user as here.

Get-DAADUser -Identity AdeleV@<tenant>.OnMicrosoft.com

The output shows the AssignedPlans, AssignedLicenses and ProxyAddresses properties of that user as list objects.

We can now expand these properties as in the following code samples:

Get-DAADUser -Identity AdeleV@<tenant>.OnMicrosoft.com | Select-Object -ExpandProperty AssignedLicenses

As result, the SkuId and the DisabledPlans are shown.

To see the assigned plans, we can expand the AssignedPlans property.

Get-DAADUser -Identity AdeleV@<tenant>.OnMicrosoft.com | Select-Object -ExpandProperty AssignedPlans

This shows a list of the assigned plans.

Note: Unfortunately, the Microsoft Graph delivers just the ServicePlanId and in the best case an "internal" (not-pretty) license name and there is no "publicly official Microsoft table" with all possible license names. For example, the first ServicePlanId "efb0351d-3b08-4503-993d-383af8de41e3" is the license "Information Protection for Office 365 - Premium". You can check some of the license Ids in the list at Product names and service plan identifiers for licensing. Delegate365 has an internal list for showing "better" license names. We are planning to improve the output by using the Delegate365 license mapping list in near future.

The ProxyAddresses show all assigned email addresses, such as alias addresses) of the given user, as here.

Get-DAADUser -Identity AdeleV@<tenant>.OnMicrosoft.com | Select-Object -ExpandProperty ProxyAddresses

Happy administrating with Delegate365 PowerShell!

Work with the Delegate365 PowerShell in the Azure Cloud Shell

Friday, May 21, 2021

Delegate365 provides a PowerShell module to access data in Delegate365 in scripts. You can import the Delegate365 module locally, or use it in the Azure Cloud Shell as well. See here, how to use the module in Azure Cloud Shell.

Here, you can find a description of the Delegate365 PowerShell module. It is hosted in the PowerShell Gallery and can be easily installed. So, here´s a step-by-step guide how to use the Delegate365 PS module.

Use the Azure cloud shell

See more about the cloud shell at Overview of Azure Cloud Shell. Users who have access to _any_ Azure subscription can use the cloud shell. A user only needs a Reader permissions to a resource, but a write permission to one specific Azure Storage account for storing the user´s profile is required (see below). So, every user who has access to Azure can use the Azure Cloud Shell.

Open the Azure cloud shell here: https://shell.azure.com/

Setup your cloud shell environment (once)

At the very first call, the cloud shell opens a wizard as here. Select "PowerShell" as environment.

To store the user´s profile, an Azure storage is required. The wizard asks to create a new storage at the first time the user opens the cloud shell.

Done.

Import the Delegate365 PowerShell module

When the storage has been created, the cloud shell opens with the PowerShell environment. Now, we can import and install the Delegate365 module from the PowerShell Gallery.

Install-Module Delegate365

Import-Module Delegate365

The next step is to connect to the Delegate365 API. Just to mention, all operations a user is doing in Delegate365 PowerShell are protocolled.

Let´s connect to Delegate365 with your API key.

You need the Delegate365 URL and an API key. You get a user´s API key in Delegate365 as shown here. Use the Connect-Delegate365 cmdlet to connect with your data as here:

$baseUrl = https://<your-company>.delegate365.com
$apiKey = "<your-api-key>"

Connect-Delegate365 -WebApiSasKey $apiKey -WebApiBaseUrl $baseUrl

Use the Delegate365 cmdlets

Now we can use the Delegate365 cmdlets as here:

Get-DOU

Get-DUser -OU 'Seattle'

See the cmdlets at https://github.com/delegate365/PowerShell.

Use VS Code in Cloud Shell

To run scripts, use the integrated VS Code editor, as in this sample here.

Happy scripting with the Delegate365 PowerShell module in Azure Cloud Shell!

Delegate365 changelog 9.2-More improvements

Monday, March 8, 2021

Delegate365 v9.2 will be extended with some new features this March. See the latest features here.

See the latest features of Delegate365 v9.2 such as extended reports retention dates, new message tracing options, a new license order process, some fixes and more at Delegate365 changelog 9.2-improvements
Schema Extensions: Another new feature is described at Introducing user schema extensions in Delegate365. This allows to add custom user data to Azure AD. The custom data can be used with PowerShell for own business processes. See more at how to use Azure AD schema extensions in Graph PowerShell.
Invite guests: When inviting guest users to the M365 tenant, the admin has to fill out a form with the Display name and the email address of the external user. The panel was extended with First Name and Last Name.

The invited user will show up in Delegate365 in the Users list automatically and can be administrated in the same way as internal users. The new fields are stored in the user object, as shown in the Azure Portal.

By default, the guest user gets an invitation to join the M365 tenant. See a detailed description at Delegate365-Working with guest users

The update will be rolled out in March for all Delegate365 tenants. Also, we are working on the next version Delegate365 v9.3 that will come in spring with some more improvements. Stay tuned!

Working with Azure AD schema extensions in Graph PowerShell

Thursday, March 4, 2021

Schema extensions enable to store extended custom data directly to objects in Azure AD. This article describes how to access data we defined and added in Introducing user schema extensions in Delegate365 with the Microsoft Graph PowerShell module.

Prerequisites

To work with Microsoft Graph and PowerShell, we need to install the Microsoft.Graph module as described at Install the Microsoft Graph PowerShell SDK. You can install the module in PowerShell Core or Windows PowerShell using the following command.

# https://docs.microsoft.com/en-us/graph/powershell/installation
Install-Module Microsoft.Graph -Scope CurrentUser

If you already have the module installed, check the version (currently, the latest version is '1.3.1'):

Get-InstalledModule Microsoft.Graph

To update to the latest version, run:

Update-Module Microsoft.Graph -Force

If you want to completely uninstall the Microsoft.Graph module, run Uninstall-Module Microsoft.Graph.

Connect to Graph

Once installed, we can use the Connect-MgGraph to authenticate with a user and device login to access data in the M365 tenant. The scopes define the permissions we need in our script. In this sample, we want to access User data (and eventually) Group data.

Import-Module Microsoft.Graph
# Select-MgProfile -Name "beta"
Connect-MgGraph -TenantId '<tenantname>.onmicrosoft.com' `
    -Scopes "User.ReadWrite.All","Group.ReadWrite.All"
Get-MgContext

Sign-in and copy the device code into the browser page. When you close the browser, Connect should welcome you: Welcome To Microsoft Graph!

We can check the connection with Get-MgContext. The output should look as here.

Get-MgContext

ClientId              : <someid>
TenantId              : <tenantid>
CertificateThumbprint :
Scopes                : {User.ReadWrite.All, Group.ReadWrite.All…}
AuthType              : Delegated
CertificateName       :
Account               : admin@<tenantname>.onmicrosoft.com
AppName               : Microsoft Graph PowerShell
ContextScope          : CurrentUser
Certificate           :

Looks good. Now we are ready to access the schema properties.

Get all existing schema extensions

To see how to work and how to get Schema Extensions, check out the documentation at Get schemaExtension. To get all schema extensions in the tenant with PowerShell, we can use the Get-MgSchemaExtension cmdlet with the -All parameter.

Get-MgSchemaExtension -All

We get a long list. It seems, Microsoft is using schema extension extensively. To see the properties delivered, we analyze the first element:

$SchemaExtensionList[0] | fl

Description          : sample desccription
Id                   : adatumisv_exo2
Owner                : 617720dc-85fc-45d7-a187-cee75eaf239e
Properties           : {p1, p2}
Status               : Available
TargetTypes          : {Message}
Keys                 : {}
Values               : {}
AdditionalProperties : {}
Count                : 0

The relevant properties are, of course, the Id, the Owner, the Properties and the Status. The status can be "InDevelopment", or "Available". When set to "Available", the properties can no longer be extended. In Delegate365, we use the Status "InDevelopment" to be more flexible.

Get specific existing schema extensions

To get only our own schema extensions, we need the App Id that owns the custom schema extension OR the name of the extension. In Delegate365, we can open the Delegate365 settings and get the schema extension name in the Schema Extensions section as here.

The schema extension name always ends with "delegate365userextension". Azure AD creates a random prefix for the name. In this sample, the generated name is "extmersxab8_delegate365userextension".

Unfortunately, the Graph (still) does not have an OData function to search with contains or endswith. Also, the cmdlet Get-MgSchemaExtension has a -Filter option - but that does not work! However, we can get all the schema extensions and filter for our own extension ourselves. So, let´s use our object and filter for our extension - adapt the search as needed.

$myext = Get-MgSchemaExtension -All | ? id -like '*_delegate365userextension'
$myext

Id                                   Description              Properties                          TargetTypes Status        Owner
--                                   -----------              ----------                          ----------- ------        -----
extmersxab8_delegate365userextension delegate365userextension {jobtitle, costcenter, favcolor}    {User}      InDevelopment a3f620a2-8418-44b6-9847-aa3db8cd37db
ext7ztddysl_delegate365userextension delegate365userextension {jobtitle}                          {User}      InDevelopment a3f620a2-8418-44b6-9847-aa3db8cd37db
extvndtvtlr_delegate365userextension delegate365userextension {jobtitle}                          {User}      InDevelopment a3f620a2-8418-44b6-9847-aa3db8cd37db

We see that our Delegate365 schema extension "extmersxab8_delegate365userextension" with it´s properties. The command also shows us the "owner". Here the owner is the Delegate365 app with the App Id "a3f620a2-8418-44b6-9847-aa3db8cd37db". Only the owner is allowed to modify the schema extension.

Side story when working with Schema Extensions in Graph: Currently, one application (in our case, the Delegate365 app) can only own up to 5 schema extensions. As of today, the Microsoft Graph API seems to have an issue here: If a new schema extension is created, it internally creates 2 or 3 schema extensions with unique names, but with the same initial properties (as we see the 3 lines above). The multiple extensions are connected: All schema extensions deliver the same data. In Delegate365, we use only the first (and created) schema extension by name. The remaining 2 are unused and cannot be deleted - another (corresponding) bug in the Microsoft Graph API. This leaves (5 - 3 =) only 2 more possible schema extensions for an app. When the next new schema extension is created, it can happen that 2 extensions are created... To make it short: The Graph API has some reproducible issues and the Delegate365 schema extension should not be removed in any case to ensure the properties can be extended in Delegate365 if needed. Therefore, removing an existing user schema extension in Delegate365 is not available. Also, the Delegate365 setup has been renewed to ensure that the Delegate365 app is never deleted and all secrets and certificates are renewed properly, when a new Delegate365 setup is executed. However, user schema extensions in Delegate365 are useful and Delegate365 works around that Graph issue.

Get users with specific data

A typical use case is to get a list of all users with a specific value set in a schema extension. For example, we want to get all users who have the favcolor set to "red", or all users who have the cost center set to "1200" or similar.

Unfortunately, there is currently no ready-to-use cmdlet available for that. So, we need to accomplish this with a Graph REST call, with a query running Invoke-MgGraphRequest (using the authentication from before) as here:

$Url = 'https://graph.microsoft.com/v1.0/users?$filter=startswith(extmersxab8_delegate365userextension/favcolor, ''red'')&$select=id,displayname&$top=2'$result = Invoke-MgGraphRequest -Method GET -Uri $Url

The syntax for the property query is <schemaextensionname>/<propertyname> (it took some time to figure this out). The request above shows the syntax. This returns a result with all (well, the first two) users who have the property favcolor starting with "red". Note that Graph only delivers up to 100 items per page. So, we have to take care and process additional data ourselves if needed, see below.

Process the result

First, let´s check the result. This is … clumsy, as we see when we output the $result.value from the operation above.

$result.value

Name                           Value
----                           -----
id                             <userid>
displayName                    Adele Vance
@odata.id                      https://graph.microsoft.com/v2/<someid>/directoryObjects/<userid>/Microsoft.Dire...
id                             <userid>
displayName                    Bianca Pisani
@odata.id                      https://graph.microsoft.com/v2/<someid>/directoryObjects/<userid>/Microsoft.Dire...

We get a a hash table, including a hash table for each item (including the selected properties). Really? So, we need to split the data to work with the corresponding users… Also, what if we get more pages of users?

Filter and loop through all users

After we initially loaded the first page, we can follow the data in the odata.nextLink property. See more at Paging Microsoft Graph data in your app. To make it short, here´s the solution for getting all filtered users for the query to continue to work with the user id for additional steps.

# Define the first request:
$Url = 'https://graph.microsoft.com/v1.0/users?$filter=startswith(extmersxab8_delegate365userextension/favcolor, ''red'')&$select=id,displayname&$top=2'
do {
    $page = Invoke-MgGraphRequest -Method GET -Uri $Url
    # Returns a hash table, including a hash table for each item....! 
    # We are only interested in the "id" and displayname property    $page.value | ForEach-Object { Write-Host $_['id'] $_['displayname'] }  
    # Check if there are following pages
    if ($page.'@odata.nextLink') {
        Write-Host 'Loading next page…'
        $Url = $page.'@odata.nextLink'
    } else {
        Write-Host 'We got everything!'
        break
    }
} while ($true)

When we run this script, we loop through all filtered users with the page size of 2. When no more data is returned, we´re done and end the forever-loop. As output we should get all users with their id and their Displayname:

bef4b76a-289a-43bc-bad4-84ee0c5f1c12 Debra Berger
30ad21be-3f2c-4c39-87c4-fad4784cb22d Adele Vance
Loading next page…
d92c0583-4b8e-4979-abd3-be0fd7c6fa3b Bianca Pisani
We got everything!

We can now continue to work with that data and do something with the users in the ForEach-Object { <do-something> } block. Eventually, we would like to add these users to a group, send emails to these users or do similar actions.

Summary

This article demonstrates the current status of working with Azure AD schema extensions with Microsoft.Graph PowerShell. You can download the script shown above in the Delegate365 GitHub Samples here. A sample for running such a script in an Azure Automation Account and synchronizing filtered users to an email enabled security group will be added in this repository shortly. We hope this step-by-step instructions helps to automate user specific processes and to customize tasks based on custom user data.

Introducing user schema extensions in Delegate365

Thursday, February 25, 2021

The current version of Delegate365 adds a new feature: Schema extensions for users. Schema extensions allow to add custom data to Azure AD objects. In Delegate365, administrators can use the Delegate365 schema extension feature to add custom properties to a user. Find out, how you can use the user schema extension in Delegate365 here.

Possible areas of application are e.g. predefined job titles, cost center, employee type, other emails or managers, or other user specific data where there is no property in Azure AD existing. The Delegate365 user schema extension can be declared and used in Delegate365 and in the Azure AD. There can be multiple properties defined, as a text field, or with predefined values as a selection field.

So, Delegate365 supports a free customizable user defined schema extension. The custom user data can be used outside of Delegate365 as well.

Default setting: You can find the schema extension settings in the Administration / Delegate365 settings menu, at the end of the page, in the Schema extensions section. By default, the schema extensions are not activated.
Activate and create the schema extension: Turn on the switch "Use schema extensions in Delegate365".

The switch activates the usage of the user schema extension in the Users menu, as a new function in the right menu, as here.

In order to be able to use the schema extensions, we have to define the following properties. If you want to deactivate that functionality, set the "Use schema extensions in Delegate365" switch to No.
Create the schema extension properties: Then, we can create one or more properties below. In our sample, we first add a new property with the name "jobtitle". Delegate365 offers a text field for free input, or a selection field (a dropdown). We want that the jobtitle shall be picked from a predefined list. So, we set the Is selection to Yes.

Click the Values icon to the right of the switch. Now, we can add values for the selection in the panel on the right.

Add multiple values and the desired order (that is used for the output) here. In this sample. we added 5 values for the jobtitle field. Click OK to save the values. When done, we can click Create extension.
A toast message shows the successful creation of the new schema extension.

This process creates the schema extension in Azure AD for all users in the tenant.
Schema extension name "extxxxxxxx_delegate365userextension": The schema extension is automatically named with a random extension number by Azure AD, followed by the name "delegate365userextension". In this sample, the generated name is "extmersxab8_delegate365userextension". The name cannot be changed. In Azure AD, the extension stores string values. See the following post how to access it from outside of Delegate365.
Update the schema extension: You can add additional properties to the schema extension if needed. In real world, this should be just a handful of properties you really need for all users, such as cost center, employee type, other emails or additional managers or similar. Simple properties for simple data. If you need to store more extensive user information, such as a picture or similar, we recommend to store just a reference as a link to that data in the user object.

In this sample, we add another property with the name "costcenter". This is a free text field, and Is selection stays to No. The admin shall enter any string value. Now, we can click Update extension to update the schema extension in Azure AD. We shall get a short success-message.
Existing property names cannot be changed: Note, that existing properties cannot be renamed or deleted. But, you can add new properties. Here this means, you cannot modify the property name jobtitle to e.g. oldjobtitle. When you update the schema extension , Azure AD will deliver an error as here.

If you such an error is shown, simply open another menu on the left, and come back to the Delegate365 settings menu. It will show the (unchanged) properties as they exist in the Azure AD. Again, you can a) add more new properties and b) you can modify the selection values anytime if needed!
Existing properties cannot be deleted: According to the previous point, properties cannot be removed, once the schema extension has been created or updated. This schema extensions behavior is by design. You would get and error similar as here: SaveSchemaExtension: Code: BadRequest Message: Cannot delete an existing property. So, create the properties wisely.
Fill and use the user schema extension: Once defined (and activated), the Delegate365 admins will see the Schema extensions menu in the Users list, as here.

The schema extensions panel opens on the right side, showing the defined properties. In this sample, we see the jobtitle as a dropdown and the costcenter as a text field.

The jobtitle selection offers the values we defined before. The predefined order defines the order in the dropdown. Here, Adele Vance, gets the role "HR Manager" assigned.

So, the data for this user can be selected and entered in the panel. As cost center, we input "1200" as a text value.

Click Save to save the custom data in the user schema property and to close the panel.
Users with custom data: To see, remove or manage the custom property values, select the user and open the Schema extensions menu anytime.
Limits and behavior: One application (in our case, the Delegate365 app) can only own up to 5 schema extensions. The Delegate365 user schema extension cannot be deleted to ensure manageability and expandability for additional properties if needed. Therefore, the Delegate365 setup has been renewed to ensure that the Delegate365 app is never deleted and all secrets, certificates and permissions are renewed or prolonged properly, when a new Delegate365 setup is executed.

The article Working with Azure AD schema extensions in Graph PowerShell demonstrates how to use the Delegate365 schema extensions outside of Delegate365. You can access the schema extension by the name provided here.

The Delegate365 schema extension for users allows enables the management and storage of additional data for user objects. The selector is useful to only allow predefined values for some custom properties. This helps in standardizing certain values within an organization. See the following article how to access that data from outside of Delegate365.

The new feature will be available in Delegate365 v9.2 in March. Happy managing your M365 tenant with Delegate365!

Delegate365 changelog 9.2-improvements

Thursday, October 22, 2020

The next version of Delegate365 is here. Delegate365 v9.2 follows the last update v9.1. This update includes a bunch of helpful features and improvements such as SharePoint sites management, Group OU improvements, report improvements, a new message trace job and more. See a description of the new features here.

License bars on the dashboard, for users and quotas: The license information is now visually improved for Portal Administrators. A license bar per license (SKU) shows how many licenses are in use and how many are available in total.

The same applies to a user's licenses…

…and license quotas.

The new display enables a quick view of the licenses.
SPO site auto-assign: This new feature allows to automatically assign SharePoint Online sites to an OU by site name in the Administration / sync rules module. Please see the details at Delegate365 changelog 9.2-SPO site auto-assign. and ensure you have configured the SPO access for Delegate365 as described at Delegate365 changelog 9.1-SharePoint Online.
Group OUs no longer require domains: When working with Group OU´s (see here), administrators required to have the domain of the users in the Group OU´s assigned to see them. That turned out to be cumbersome. Now, this is no longer required. Administrators now see ALL users of the assigned Group OU´s regardless of the user´s domain. The people picker now shows all users of entitled Group OU´s. Please see Delegate365 changelog 9.2-Group OUs for a sample and more information.
Named report files: The Reports module allows to generate reports for the entitled OU´s. The generated report files used be just named with a current number, such as 287.csv and 287.xlsx, etc. With this version, the new file names identify the group and the report purpose, such as "report-AzureAD-directoryroleusers-287.csv" etc.

The new file names support for later, automatic analysis, for example with Power BI, an article about this will follow. Admins see the new file names in the Delegate365 storage, as here.
Reports retention date: When talking about reports, there´s another new feature regarding the retention date of generated reports. Previously reports were only kept for 7 days. There is a new setting in the Administration / Delegate365 settings, in the Report settings.

Now admins can control the retention date of the report files with a time frame from 7 days up to 365 days before these reports are automatically deleted.

Amongst other things, this can be helpful for saving weekly or monthly reports for a longer time directly in the Delegate365 storage.
Message Tracing two options: Menu Mailboxes / Message trace now comes with two options. In the first section, the date range (up to 7 days) and sender or recipients can be filled in.

Below, the administrator can now run the query by clicking "Run now" (as before), or run the query as a job by clicking "Run as job". Run now is the default, when not many results are expected. The result is shown below as here.

The new option Run as job schedules a job as background task to avoid any time-outs if the query is running too long. Use this query if a large result set is expected, or if Run now does not deliver a result.

The Run as job notifies the user when the report is completed.
Date format harmonization: The web now is using the international date format (ISO 8601) for all audiences world-wide. There are not many date fields, so we hope the the harmonization works for everyone. The ISO 8601 format is YYYY-MM-DD (2020-07-12) to ensure accuracy in all situations.
PowerShell module update: The Delegate365 PowerShell module has been updated to v1.0.0.9 in the PowerShell Gallery. This version is fully compatible with the previous version 1.0.0.7 and works with Delegate365 v9.2. The Set-Admin command now supports Group OU's. See the https://github.com/delegate365/PowerShell ReadMe and the description of Set-DAdministrator command and below.
To install the Delegate365 module from the PowerShell gallery, run:
```
Install-Module -Name Delegate365
```
If you have already installed a previous version, we recommend to update your installed version to the latest version. Check your version (see below) and run the update:
```
Update-Module -Name Delegate365 -Force
```
Check the version:
```
Get-Module -ListAvailable -Name Delegate365
```
The output could look like here.
PowerShell update for Group OU's: The Set-DAdmin command now allows to set the Group OU as well. See the sample here and more at Set-DAdministrator.
```
Set-DAdministrator -Identity 'john.doe@delegate365.com' `
-OrganizationalUnits 'London', 'New York' `
-GroupOrganizationalUnits 'Kuala Lumpur', 'Paris'
```
Overwrites the OU assignment and the Group OU assignments of an administrator. The -GroupOrganizationalUnits parameter can be used starting with version Delegate365 v9.2 only. Pls. note that any OU or GroupOU assignments always overwrite existing assignments for the administrator. An OU can not be assigned as OU AND as GroupOU at the same time (as in the web portal). The administrator has to decide to which role the OU shall be assigned. If the same OU name is used as OU AND as GroupOU, the OU assignment always wins.You can check the result in the output as here.
New License order process (internal and external): With this update, the license order process can be changed in the Administration / Delegate365 settings. The default behavior "Internal order with approval (default)" (before this update) remains. License orders must be approved by a license admin in Delegate365, in the Licenses / license orders menu.
Now there are four options. Internal orders mean that license orders (as before) are fulfilled from the pool of existing (bought) Microsoft 365 licenses, while external orders licenses are bought new (they are added to the licenses in the M365 license pool) and made available via the Microsoft partner. For external orders, atwork must be your CSP partner and the customer ID for the atwork shop system needs to be filled out. Both order processes can take place with or without approval by a license administrator. In addition, licenses for Delegate365 itself can now also be ordered by license administrators if the setting "Allow Delegate365 orders for license administrators" is switched on. This increases licenses for Delegate365 and creates an invoice to the customer address by default. If billing of license orders shall happen to an OU instead of a single billing address, the invoice data must be filled out in the OU management.

A detailed article will follow shortly. Without changes here, the order behavior is as before.
Sync and little things: Some performance improvements in sync were made, now using more delta-queries, and small adjustments, such as labels and descriptions, have been made.
Update Oct., 24th, Update user fix: The Microsoft update user API service has been changed, causing update user operations and user license operations to fail in Delegate365. We have fixed this problem and all Delegate365 tenants have been updated to the latest version Delegate365 v9.2. With that update, these operations are now working properly again.

We hope you like the new and improved features of Delegate365. Delegate365 version 9.2 is available by end of October, and existing versions will be upgraded automatically. There is no interaction and no setup required. New versions get the latest Delegate365 version automatically.

Delegate365-Goodbye, Basic Authentication

Wednesday, October 21, 2020

Delegate365 provides a toolbox for easy management of a Microsoft 365 tenant. Management ranges from Exchange Online to Azure AD, SharePoint Online, Reporting and Intune. Delegate365 communicates with the Microsoft 365 services via apps and Modern Authentication, wherever possible. However, a service account had to be used for some Exchange features and the multi-factor authentication management. This will change with the next versions.

Some M365 background information

So far, some Microsoft services such as Exchange Online (EXO) could only be reached with Basic Authentication, while other (new) services such as Microsoft Graph can be used with an app. Basic Authentication relies on sending usernames and passwords with every request increasing risk of attackers capturing users´ credentials. Therefore, Microsoft recommends that you stop using Basic Authentication. Basic Authentication is superseded by Modern Authentication based on OAuth 2.0 that is supported for the new Microsoft 365 services.

Microsoft has announced that it will disable authorization with Basic Authentication for Exchange Online. The only problem for third party tools like Delegate365 is, that Microsoft (still) does not offer an API with modern authentication for EXO administration. They just deliver a new (and faster) Exchange Online PowerShell v2 module - instead of the Remote Exchange PowerShell module - that, at least, supports Modern Authentication with an app and a certificate. So let's take that.

To make it short: Delegate365 takes this into account and will therefore access Exchange Online differently. Basic Authentication will no longer be required in near future.

How Delegate365 communicates with an M365 tenant

When the Delegate365 setup is executed, the setup creates two Delegate365 apps in the Microsoft 365 tenant and automatically removes eventually existing older apps. Delegate365 is using these apps to transfer data to the tenant. Around 90% of all operations are performed through these apps. This also applies to access SharePoint Online. For the rest of the operations, Delegate365 currently requires a service account since Microsoft does not provide an API to access EXO and MFA services with an app. This will change as described below.

Delegate365 versions using a service account

Currently (up to Delegate365 v9.2), Delegate365 is using - next to the apps - a service account for accessing a small number of services. This applies to some operations in Exchange Online and for Multi-Factor Authentication (MFA) operations. The service account can be changed anytime in the Administration / Microsoft 365 account menu. MFA cannot be enabled for this service account, but it can use a password of up to 150 characters or an app password. Customers using MFA, need to make an exceptions for such service accounts for Delegate365 and other background tasks (cron-jobs, etc.) if they are using Conditional Access policies in their tenant.

The service account can then be used by Delegate365 to connect to the Microsoft legacy interfaces.

Note: If Basic Authentication is deactivated in an M365 tenant (see here) or no valid service account is saved, some Exchange functions and MFA will not work in Delegate365. But the rest in Delegate365 still does.

How to use a service account with MFA

As of today, there is a workaround available: Create a service account without MFA, run the Delegate365 setup, activate MFA, enable app passwords, create an app password, and use the app password in Delegate365. See details about the process at the article Delegate365 - Secure and setup your tenant. This workaround will no longer be required with Delegate365 v9.3.

What will change in the Delegate365 setup

To move forward and comply with security policies, Delegate365 v9.3 will no longer require a service account. This means, the setup process for Delegate365 will change as well. The goal is that Basic Authentication can be turned off in the M365 tenant. All operations accessing Exchange Online will be using the latest (currently in preview) EXO v2 module and the Delegate365 app for sending emails. MFA functions are removed (see below).

The new Delegate365 setup tool

With MFA: Administrators can download a Delegate365 setup tool to run the setup task in the next versions. The tool will allow a Global Admin - with MFA enabled - to sign-in interactively and asks for the required Delegate365 parameters on the local computer. The tool then communicates with the Azure AD and creates the apps, and generates a certificate .pbx file and a .json setup configuration file. This information can be uploaded into the new Delegate365 app settings. Then, Delegate365 will use the generated certificate and the app data to access the M365 tenant and all the services.

Without MFA: Alternatively, a Delegate365 service account can be used in the web interface as before, but no MFA must be activated. The setup asks for the service account and for additional parameters (as requested by the new Delegate365 setup tool). As long as no MFA is used, there is no need to use the new setup tool (but it can be used).

The Administrator / Microsoft 365 service account menu will be changed into App settings and allow to upload the generated files or to paste the app data and to modify each setting as well. Existing configuration will be updated and missing entries must be added then. The module will also allow to download the Delegate365 configuration to store the files in a safe place or for documentation. The new setup process and the interface will be described in an extra article when ready.

What will change in the Delegate365: No more MFA functions

This is associated with low costs: Since there is no longer a service account existing, MFA operations will no longer be accessible in Delegate365, as Microsoft does not provide an API for this currently. So, the MFA function in the Users menu will be removed.

Furthermore, the MFA sync rule section will be removed. If this settings was active, after the update to Delegate365 v9.3, this section will no longer be visible and has no effect.

Instead of using these MFA functions, Microsoft recommends to configure Conditional Access, see more here. Just remember, Conditional Access requires an Azure AD Premium P1 license.

The rest of the Delegate365 functionality remains unchanged.

Vote for the MFA API

Microsoft is still in the process to deliver MFA management functionality with the Graph API. We are waiting for that feature. You can support this request at microsoftgraph.uservoice.com. Vote for it! As soon as this API is available, we are happy to reintegrate the MFA functions into Delegate365 again.

Next steps

With this article we would like to give you advance information about the next steps in Delegate365. At the end of October, we will announce the new features of Delegate365 v9.2. The v9.2 update is planned for mid-November. We plan to release Delegate365 v9.3 with the new setup as indicated here in December.

Happy Delegating!

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