Changelog

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

Delegate365-Working with guest users

Friday, June 26, 2020

Delegate365 supports working with guest users. Guest users or external users are users that are invited to the company tenant by email. Once they accept the invitation, they get access to corporate resources. For example, a guest user can be a member of a Microsoft team or collaborate in Planner or in a SharePoint site or similar. See some samples here.

Invite a guest user

In Delegate365, admins can invite a guest user by clicking on the "Invite guest user" icon next to the "+" icon (new user). If you don´t see this icon, ask your Delegate365 Portal Admin to enable that feature in the permission policies.

Fill out the invite guest user form and click the Invite button.

You will find the invited user in the users list instantly as here. You can manage that user in the same way as the other users.

What´s the user´s UPN?

Azure AD stores that user internally with the default domain of the tenant. In this sample, we see that user

doris.doe@gmail.com became doris.doe_gmail.com#EXT#@M365x193702.onmicrosoft.com.

Note: When inviting external users, the default domain of the tenant is used. So, this can be a custom domain as well. The Azure AD portal and the Microsoft 365 admin center show the original username doris.doe@gmail.com. Anyway, internally the extended username is used.

We can change the username to a more friendly name or to a different domain later in Delegate365, see below.

How does the guest user complete the invitation?

The invited user gets an email. Here, the user accepts the invitation to that Microsoft 365 tenant.

Then, the user follows the process and signs-in with a custom password. Also, the user has to accept that the Microsoft 365 tenant can sign him or her in and to read the user´s (Azure AD) profile. Now the guest user has his email address and a password for the organization´s Microsoft 365 tenant. If the organization enforces MFA, the user must follow that process as well to get access.

Note: In Azure AD, the guest user is added as "Microsoft Account" and the status is "Invitation accepted". Other invited users that have not accepted the invitation get the status "Invited user".

In Delegate365, the guest users show up after the sync in the users list as Type "User" and Status "Cloud".

Assign guest users to OU´s

The same happens to users that have been invited outside of Delegate365, e.g. in the Azure AD portal. The Azure AD UPN is ending with #EXT#@M365x193702.onmicrosoft.com. Here, users anne.doe@gmail.com and John@doe.com are shown in the list of OU / Assign.

So, we can assign these users to an OU, in our sample, we assign the two selected users to OU New York at the page bottom.

Manage guest users UPNs

As we see, now there are 3 guest users which we can manipulate in the same way as the internal users we can manage.

Important: A administrator must be assigned to an OU AND to the DOMAIN of the users he or she can manage. In our sample, the current admin has the OU New York assigned AND the domain M365x193702.onmicrosoft.com! See also Troubleshooting Delegate365.

Wait! What if you don´t want to assign the default domain to your admins in Delegate365?

Well, then you can modify the UPN domain of the guest user as follows.

Modify the guest users UPN

In Delegate365, you can change the UPN. The UPN is the internal name of the guest user in your tenant.

Note: You can´t change the guest users UPN in the Azure AD portal, so that´s a feature of Delegate365.

), as in the sample here when we remove the #EXT# and change the domain:

So, now the UPN is <name>_gmail.com@atwork.fun.

How does the guest user sign-in to Microsoft 365?

Even if you change the guest user´s UPN in your Microsoft 365 tenant, the user continues to use his or her own email address to sign-in. So, the login process is unchanged as we see here. When the guest user signs-in to e.g. portal.office.com…

..after the successful login, the Office portal follows.

Benefits of managing guest users in Delegate365

Guest users can be managed in Delegate365. Notice the domain of the UPN of the guest user, and check if the domain is assigned to the admins in Delegate365. Benefits are:

Changing the UPN of guest users in Delegate365 helps to get a friendly UPN.
Changing the UPN and the domain allows to delegate guest user management to admins that are now allowed to manage the default domain of the Microsoft 365 tenant. In our sample, admins who are only allowed to manage users with the domain "atwork.fun" (but not the tenant´s default domain M365x193702.onmicrosoft.com), will see that guest user and are able to manage that user.
Also, the user can get an Office 365 license from your organization if needed.
Guest users that are assigned to the own OU´s (or Guest OU´s) can be added to groups as well.
Note: There´s a change in Delegate365 v9.2: If a admin is assigned to a Group OU, the domain assignments will no longer be used as filter in that case. The people picker (e.g. in group membership assignments) will show ALL users in the Group OU, regardless of the domain. This allows admins to add users to their groups, regardless of the user´s UPN domain. This is only valid for Group OU´s. Users in assigned OU´s still filter for the domain of the current admin.

We have seen, that administration of guest users can be delegated with Delegate365. Portal Admins can control, what users can be managed by whom and what guest users can be managed.

Delegate365 changelog 9.2-SPO site auto-assign

Monday, June 15, 2020

Delegate365 v9.2 brings a new feature for auto-assigning existing SharePoint site to an OU. This follows the same principle as auto-assigning groups. See it here.

Note: To use the SharePoint Online management feature, ensure you have configured the SPO access for Delegate365 as described at Delegate365 changelog 9.1-SharePoint Online.

The following scenario describes how to use the new SPO site auto assign.

A scenario

In this demo tenant, there are some SharePoint Online sites with a prefix in their site name: There are two sites starting with "New York", one site with "Paris" and three sites starting with "Seattle". All site names are separated with an underscore between OU name and the following site name, as here in screenshot of the SharePoint admin center (open it with your tenant-name and a Admin at https://<yourtenant>-admin.sharepoint.com/).

In Delegate365 v9.2, there´s a new section SharePoint in the Administration / Sync rules. Here, Admins can define that SPO sites with an OU as prefix are automatically assigned to that OU, as here.

Define the desired separator option and click Save at the page bottom.

As with the other (group) rules, the name must match, and upper / lower case is ignored. So, "new york" = "New York" = "NEW YORK".

The SPO sync

The SPO site sync is currently not part of the Delegate365 sync and runs every 3 hours. If you have just created new sites outside of Delegate365, it can take up to three hours until the new SPO sites show up in Delegate365. As of today, you cannot start the SPO sync job manually, pls. simply wait and check from time to time. Once the SPO sites are showing up, the sites can be assigned manually or automatically.

What we expect

We want to have the new SPO sites automatically assigned to our OU´s. In our sample, we have only two OU´s defined, New York and Seattle.

Check the result after the SPO sync

After the SPO sync is completed, let´s see the result. The SPO sites with the prefix New York and Seattle should have been automatically assigned to the corresponding OU´s.

This worked well and as expected. A change of the site name would - with the settings above - cause that a site will be assigned to another OU. If the site name would be changed and there´s no corresponding OU, the site OU assignment would stay untouched and the site remains in the existing OU.

Since there is no OU with the name Paris, this SPO site has not been automatically assigned. This site Paris_site3 show up in the OU´s / Assign module in the SharePoint section and can be manually assigned to an OU (as before).

Summary

If you have a large and growing number of new Teams and SPO sites, this feature reduces the effort to manually assign sites to an OU in Delegate365. If the OU name is used as prefix in the SPO site name, let the SPO site auto assignment to the work. The assignment definition works in the same way as with groups.

Delegate365 changelog 9.2-Group OUs

Friday, June 5, 2020

Delegate365 allows the separation of a single Microsoft 365 tenant with the OU concept. Every admin only sees and manages his own objects. Group OU´s allow administrators to add users from other organizational units to their managed groups without having access to manage those users. Until now, when using Group OUs, the domains had to be added to the administrators. That has now been changed with this version.

Note: Article Delegate365 changelog version 8.0-Group OU's also describes the basic concept of Group OU´s in Delegate365. This article describes the modification that the user´s domain must no longer be assigned to an administrator.

A typical scenario

To demonstrate that, let´s have a look a the following scenario:

A M365 tenant has two domains: atwork.fun and M365x193702.onmicrosoft.com.
User Admin manages OU´s Seattle and New York, and has both domains assigned.
User Adele manages OU New York only, and has domain M365x193702.onmicrosoft.com assigned.

So, Adele can manage only her users and groups assigned to New York.

Group OU´s

The goal is that Adele can add or remove users from another OU - from Seattle - to her groups. For this purpose there is the concept of the Group OUs. We can assign Seattle as Group OU to Adele as here.

In the panel, we select Seattle and click Save.

New in this version: Note that Adele has only the M365x193702.onmicrosoft.com assigned.

Test users and their OU´s and domains

The admin sees Seattle and New York. In Seattle, we see two users with two different domains assigned:

ringo.starr@atwork.fun
paul.mccartney@M365x193702.onmicrosoft.com

Test the Group OU´s

User Adele can manage New York… in her users list, she sees the three users AlexW, BiancaP and NestorW with the domain M365x193702.onmicrosoft.com (but not Ringo or Paul…).

With the assigned Group OU Seattle, she should now be able to add users from Seattle to her groups! So, let´s check it by going to a group…

…and edit the group to add more members like here. The people picker shows corresponding names from all entitled OU´s.

As we see, the Group OU allows Adele to add users from Seattle to her own groups!

The important (new) part here is, that Adele sees ALL users of the assigned Group OU´s regardless of the user´s domain.

It is worth mentioning here - in contrast to above - that Adele only sees users from her assigned OU´s if the user´s domain name is in the list of her assigned domains as before. Adele is able to add only "her" three users she sees in her users list above. If there are users assigned to New York, but with a different domain name (@atwork.fun in our sample), she would not see them in the people picker.

As result, we see that Adele ha successfully added AlexW, Ringo and Paul to her group Project Apple. To identify objects easily, Delegate365 shows the OU of the users in brackets.

When clicking the Save button and confirming the message, these users are added as members to that group.

Visibility rules

As we have seen, Group OU´s allow to see users from other OU´s to be able to add them to your own groups, regardless of the user´s domain. Before, the domain also had to be assigned to the administrators. Now, no domain assignment is required any longer.

We think, this makes sense, because admins shall not be able to manage users with domains they shall not be able to use for their own objects. This sample shows the new behavior available with Delegate365 v9.2 (along with many other new features). Stay tuned!

Delegate365 changelog 9.1-more updates

Monday, March 30, 2020

With the many new functions in the latest version, Delegate365 has received even more updates in version 9.1. See more new features such as the new user sync property StateOrProvince, the notification license names lookups and logs and guest user modifications here.

See an overview of all updates at Delegate365 changelog 9.1-many new features. The following features have been added to Delegate365 v9.1 including all existing versions:

New user sync property StateOrProvince: In Administration / Sync rules, in the User section, there is a new property StateOrProvince available. This new property allows that all users with an OU name in that user property can be automatically assigned to the OU, in the same way as with the other user properties.

Note: In general, it is recommended to use the Sync with security group feature from an organizational perspective if possible. See more at Sync with Security Group.
New: Notifications include Licenses names: When licenses are assigned (manually or automatically), license errors can occur. Delegate365 informs about such errors and logs them. For example, if there are no more licenses in the pool or if the quota is exceeded, a warning is created in the Delegate365 notification center. Unfortunately, the Office 365 API only delivers a message with the ID of the SKU, but no licenses name, such as:
```
UserLicenseSyncJob(349) ChristieC@M365x836814.onmicrosoft.com: 
Code: Request_BadRequest Message: 
Subscription with SKU c7df2760-2c81-4ef7-b578-5b5392b571df does not have any available licenses.
Inner error: AdditionalData: request-id: 07c100b3-9e70-409e-8a38-66b1517573c1 
date: 2020-03-30T07:31:00 ClientRequestId: 07c100b3-9e70-409e-8a38-66b1517573c1
```
To make more sense, Delegate365 now completes such messages and adds the Office 365 licenses name, and if used, the Delegate365 friendly license name after the SKU ID.
```
UserLicenseSyncJob(349) ChristieC@M365x836814.onmicrosoft.com: 
Code: Request_BadRequest Message: 
Subscription with SKU c7df2760-2c81-4ef7-b578-5b5392b571df (OFFICE 365 ENTERPRISE E5) (Enterprise E5) does not have any available licenses.
Inner error: AdditionalData: request-id: 07c100b3-9e70-409e-8a38-66b1517573c1 
date: 2020-03-30T07:31:00 ClientRequestId: 07c100b3-9e70-409e-8a38-66b1517573c1
```
In the sample above, the "Office 365 Enterprise E5" license (with the friendly name "Enterprise E5") could not be assigned to user "ChristieC" because there are no licenses left in the Office 365 tenant. The same completion happens for other license-related messages containing an Office 365 license ID. Another example with excluding license assignments, when a license shall be set, but another license is already assigned:
```
License assignment failed because service plans afc06cb0-b4f4-4473-8286-d644f70d8faf (Skype for Business Online (Plan 1)),0feaeb32-d00e-4d66-bd5a-43b5b83db82c (Skype for Business Online (Plan 2)) are mutually exclusive, service plans 4a82b400-a79f-41a4-b4e2-e94f5787b113 (Exchange Online Kiosk),efb87545-963c-4e0d-99df-69c6916d9eb0 (Exchange Online (Plan 2)) are mutually exclusive.
```
Here, the Skype for Business Online (Plan 1) cannot be assigned if Skype for Business Online (Plan 2) is already assigned to a user or vice versa. To handle thousands of such possible messages in large tenants, the license name completion happens automatically in the background within some minutes. It can take up to five minutes till the completed messages show up in the notification center in the top menu bar as shown here.

We think this update makes a lot of sense to make such errors more readable for administrators.

New notifications log: The notifications that are shown in the Delegate365 notification center are now logged extra to the Delegate365 log storage. Here Delegate365 works on the same principle: The prefix of the tables is named "notification", followed with the year, month and day. Messages are saved daily for the last 7 days (notification20200330), in a monthly log (notification202003), per year (notification2020) and overall (notificationLog). The messages are the same as in the notification center shown above. The Microsoft Storage Explorer helps to access the data directly.

This allows admins to work with the notification log data in other systems easily. See more at Working with Audit Logs.
Guest UPN: New behavior when editing guest users: In Azure AD, guest users are stored with a "special" UPN. "some.user@somedomain.org" is stored as "some.user_somedomain.org#EXT#". For such users, Delegate365 now allows to leave the UPN unchanged when setting the first name, last name and the display name. The UPN remains and is not generated automatically from the name fields for guest users. Alternatively, administrators can set a new UPN without #EXT# if desired. "@domain.ext" is controlled by the Domain dropdown below and is added automatically.

Note: The login for guest users works as before, with their email address they used when registering. The UPN is just the Azure AD "internal" name that can be set to a more user friendly name in Delegate365. This is a feature of Delegate365 only. Changing the UPN to another name is not available in the Office 365 Admin portal or in the Azure portal.
In this sample, the UPN of that guest is set to tonipohl43_gmail@M365x836814.onmicrosoft.com (without the ".com#EXT#" text). "@domain.ext" is added automatically.
Note: Don´t add a "@" in the UPN because that would result in 2 times "@" in the UPN, such as tonipohl43@gmail@M365x836814.onmicrosoft.com and that would not be valid.

This Delegate365 feature allows to leave the UPN of guest users unchanged (…#EXT#), or to change the UPN without this format if desired.

This update was carried out automatically in all existing Delegate365 versions 9.1 and is included in all new versions as well. We hope to support many administrators with the new features.

Delegate365 changelog 9.1-Intune

Friday, March 6, 2020

Delegate365 v9.1 provides basic device management of devices for Scope admins with Microsoft Intune. See a description of the new features here.

Setup Intune

To connect devices to Microsoft Intune, see an overview at Enroll devices in Microsoft Intune.
For Android devices: Connect your Intune account to your Managed Google Play account.
For Apple devices: Tutorial: Use Apple's Corporate Device Enrollment features in Apple Business Manager (ABM) to enroll iOS/iPadOS devices in Intune.
For Windows 10 devices: Intune enrollment methods for Windows devices.
For Windows 10 and Autopilot: Tutorial: Use Autopilot to enroll Windows devices in Intune.
The easiest way to register a mobile device is to install the Intune Company Portal app from the Google Playstore and from the Apple App store. Every user can do this independently with their device and their organizational identity.

Manage devices with Delegate365

When devices are enrolled, they will be visible in Delegate365 in the users module. The Delegate365 sync updates the devices with the users automatically in the background. Any modifications to device settings and operations in Delegate365 are done directly in Azure AD in the same way as all other objects.

Devices are assigned to a user and are shown in the Users module. Select a user and click on the Devices menu in the right side.
Managed devices: The Managed devices list shows all devices that are registered for that identity. Depending on the status, Delegate365 provides the following functions: Manage owners, Manage users, Wipe device, Retire device, Sync device, Update device, Remote lock, Remove device. The list of devices can also be exported.
Manage owners: You can assign multiple owners for a selected device. Search for a user with the people picker and click Set owner.
Manage users: The same works for assigning users to a device. Search for a user with the people picker and click Set user.
Wipe device: The Wipe action restores a device to its factory default settings. The user data is kept if you choose the Retain enrollment state and user account checkbox. Otherwise, all data, apps, and settings will be removed. Click on Wipe and confirm the action.
Retire device: The Retire action removes managed app data (where applicable), settings, and email profiles that were assigned by using Intune. The device is removed from Intune management. This happens the next time the device checks in and receives the remote Retire action. Click on Retire and confirm the action.
Sync device: The Sync device action forces the selected device to immediately check in with Intune. When a device checks in, it immediately receives any pending actions or policies that have been assigned to it. Click on Sync and confirm the action.
Update device: This feature updates the owner type and the managed device name of the device in Azure AD. This works for all managed devices and has no influence on the device itself. As type, select Company, Personal or Unknown. Modify the device name if needed and click Update.
Remote lock: Causes the device lock and to ask for the PIN code or for the unlocking action. The device must run iOS or Android and the user has to unlock the device. Click on Lock and confirm the action.
Remove device: To remove a device, click the Remove device menu. The next time the device checks in, any company data on it will be removed.
Reports: To see all managed devices from your entitled OU´s admins can generate a report as follows.

The report includes one line per device. For better readability, here´s the provided data as picture for a sample device.
(Update) Unassigned devices: In Administration / Devices, Delegate365 shows a list of device objects that are registered in the organization but not assigned to any user in an OU. In real world, this mostly are old devices that have been registered but no longer are used by tenant users. Admins can select devices, see assigned owners and users. Devices can be deleted here as well.

In this environment, there are no unassigned devices in the Microsoft 365 tenant.

By managing devices in Delegate365, scope administrators can respond to scenarios to reset company data or the device, for example if users have lost their device or it has been stolen. The managed devices report allows to export devices for users of entitled OU´s. This functionality enables Delegate365 to be used as a simple tool for managing devices.

Delegate365 changelog 9.1-many new features

Thursday, March 5, 2020

Delegate365 v9.1 comes with many new features. This version immediately follows version 8.5 and this is a major version with many large and small updates. It includes new functions such as Teams improvements, SharePoint sites management, basic device management with Intune, Invite guests, notifications, the new smart sync option, license quotas, new reports and much more. See a description of the new features here.

Run a setup: Since new permissions are required for the Delegate365 app, an administrator needs to run the Delegate365 setup after the upgrade process. We will propose an update date to every customer. After the update, an administrator needs to run the Delegate365 setup once. See the How-To at Delegate365-(Re)run the setup.
Small design changes: You will notice that Delegate365 looks looks a bit tidier. Boxes were reduced.

All frames of the boxes are now reduced to a single line under the title. That gives more clarity.
Why v9.1? This is a major release of Delegate365. The last version of Delegate365 has been v8.5 in last fall. We added more features and updated and optimized the technology behind Delegate365 to the modern Microsoft .NET Standard and .NET Core framework internally. From an end-user perspective, that means more performance. To represent that, we updated the next Delegate365 version from v8.5 to v9.0 since this is a major release. Since the .NET Core 3.1 LTR framework is now available on the Microsoft Azure platform, it makes sense to use the latest framework. So, we skipped the switch to .NET core 3.0 (and Delegate365 v9.0 was an internal test version only) and decided to go to .NET core 3.1 directly with this update. To make it short: Delegate365 v9.1 is the latest version, directly following v8.5.
Invite users: To collaborate with external users, they can be invited to the company tenant. Now, Admins can do this in Delegate365 (if permitted, see below). In the Users module, there´s a new icon "invite guest user" on the right of the "create user" icon on top of the list. Click on that icon to do so.

Fill out the fields and click Invite.

The user gets an invitation per email to join the organization as a guest. Once the user accepts the invitation, he will be added as guest user to the Azure AD. Delegate365 already adds that user to the selected OU and will show that user in the users list.

BTW, admins can assign a license to a guest user as well. Note that the user (dependent on the account type) must sign-in to your tenant with the full UserPrincipalName to be identified as a guest in an Azure AD. In this sample this looks as here.
Invite guest role: The permission policies now include the permission to invite a guest in the Users section. By default, this is set to No. Change it as needed.
Teams channels management: With this version, Delegate365 allows the management of channels in a team. Select a team and see the features in the menu on the right. Click Channels to manage them.

In the channels list, you can modify the channels of the selected team. The list shows also the web URL to directly get access to the channel.

When clicking the Create "+" icon or Edit, you can modify the channel.

Note: To modify a channel description, you have to change the display name as well. Otherwise you get a message informing that you have to change the display name as well. For a new description, you currently need to change both fields and click Save.
Teams channels and Tabs: In the Tabs menu, admins can see the defined Tabs with a direct web URL link to access that tab in Teams.

You can use the link to navigate to the page in the Teams client.
Teams channels and Apps: The Apps menu shows a list of apps with their current version that are installed in the selected team. Return with the back icons on top and at the end of the list.
SharePoint sites requirements: To use SPO functionality, Delegate365 requires an app. The SPO app must be created once and added to the configuration of Delegate365. Please see the steps at Delegate365 changelog 9.1-SharePoint Online.
SharePoint sites assignments: Once the SPO app is configured in Delegate365, this version brings management of SharePoint (SPO) sites. Admins can assign SPO sites in the OU´s / Assign menu. There´s an additional section for SharePoint.

The sync gets all SPO sites if the tenant and allows to assign them to an OU here - as usual. The list shows all sites with their site type that are unassigned. Select the sites and assign them to the corresponding OU. Click the Assign button and confirm the popup message to do so.

You can use the OU´s / Unassign menu to remove SPO sites from OU´s.
Note: SPO sites don´t have a group membership and no properties in Azure AD. So, you can only assign sites manually to an OU as shown here. There´s no sync rule for automatic assignments available. Please see details at Delegate365 changelog 9.1-SharePoint Online.
SharePoint site and permission management: The new module SharePoint allows a basic management of the assigned SPO sites. The permission to see the menu SharePoint is controlled in the permission policies. The list shows the site name, the URL, the site type and the OU as follows.

When you select a site and click Edit, you can modify specific site settings. The settings depend on the site type and show the most relevant site features.

Also, admins can manage the site permissions as here.

Please see details at Delegate365 changelog 9.1-SharePoint Online.
SharePoint Provisioning: Admins can create a new SPO site with Delegate365 within an OU. To create a new Team, follow the link saying "To provision a new Team or a new Microsoft 365 group, click here." below the panel title. Otherwise, use this panel to create a new Communication site as here.

Please see details at Delegate365 changelog 9.1-SharePoint Online.
Intune features: Admins can now benefit from the basic management of devices of their users. This includes a a new menu Devices in the users list and includes actions such as Wipe Device, Retire Device, Sync Device, and Delete Device. This will be covered in an extra article in the next days here.
Smart sync: This is a new feature for improving the sync mechanism in Delegate365 if the Microsoft interface does not deliver complete data from the tenant. In short: Unless 80% of the data is sent from the Microsoft API, Delegate365 will not delete the existing data until the same data has been provided three times. Admins can configure and overwrite that behavior if needed.
This incomplete data scenario did occur in the past some times. So, Smart Sync prevents unwanted changes. Smart sync makes it possible to run a full synchronization only if the Microsoft 365 interface supplies complete data. Administrators can define a threshold from which data is considered complete. If less data is supplied by the Microsoft 365 interface, Smart Sync blocks the deletion of large amounts of data. In this case, no deletions are made in Delegate365 and the following two sync operations are observed. The actual deletion in Delegate365 takes place only when the data is supplied in the same way for the third sync operation. This mechanism enables incomplete data to be automatically repaired in Delegate365. By default, starting with this Delegate365 version, Smart sync is enabled and it is recommended that you leave this setting enabled.

If Smart sync is set to Yes, the other switches in the section become active. The switches allow to override the sync behavior if needed. If set to Yes, the next sync will synchronize objects of that type, even if Smart Sync is activated. This also resets the counter for the next smart sync operations. The small "i" icons inform about the switches. Also, warnings are generated to the admins if if the threshold is exceeded. The Smart sync behavior is new, but the warnings exist since previous versions of Delegate365. See notification samples at Delegate365 v8.4-New Sync warning for deleted objects.
Notifications: Admins can control if they want to receive notification emails from Delegate365. Again, the small "i" icons inform about the switches. This can be done on behalf of an admin in Administration / Administrators as here…

…or every admin can do this on his own in the Properties in the top right corner menu.
Revoke sign in sessions: This new feature allows to sign-out users instantly, for example if the user has a lost or stolen device. Revoke sign in session prevents access to the organization's data through applications on the device by requiring the user to sign in again to all applications that they have previously consented to, independent of device. Select the user and click on the Revoke sign in session menu on the right side.

The admin has to confirm the operation by clicking on the Revoke button.

A toast notification informs that the Revoke sign in session was executed. The user needs to login again on his or /her machines to use the Microsoft 365 services. This is a security feature that allows admins to react quickly if a user identity becomes compromised.
New license quotas features: When working with a lot of licenses and license quotas, there are now some helpful features available: In menu OU´s / Manage OU´s, one or more OU can be selected and default license quotas can be added with the new Create default license quotas menu as shown here. Confirm the message to create quotas for the selected OU´s.

In menu Licenses / license quotas, you can now filter for OU and for licenses to find your quota to find it faster, as follows. The list also shows the used licenses within the OU.

The default quotas set the quota to 0 licenses and Enforce is set to No. If quotas are already existing for the OU and for the license, they do not get overwritten by default quotas - they remain as configured. Missing licenses will be a added then. So, this is a convenient method to create license quotas and then start configuring them as needed.
License order notification: In the Licenses / license orders, admins can start a request for more licenses. In the following sample, Adele requested 10 E5 licenses for her OU New York.

She gets a notification email, as well as the license admins. This email will be sent to the requester as confirmation with the subject "Delegate365: License order" as follows.

If this request turned out to be wrong, Adele can delete the request herself, before it has been processed by a license admin.

If Adele deletes the request, the license orders list is cleared. The same happens for the license admins. To track that deletion process, Delegate365 now informs the licenses admin about the delete-operation, also with subject "Delegate365: License order". This looks as here.

This this completes the information chain so that admins get informed about a cancelled request.
Sync messages for Scope Admins in the notification center: All operations are logged in Delegate365. If errors occur, these are logged in the storage and in the notification center. In the past, Portal admins saw all error messages, and scope admins saw errors they produced in the UI. With this version, admins now see error messages from from all objects of their OU´s. So, if for example there are license quotas defined for an OU, and there is a sync rule in place that assigns licenses to users and there´s a conflict during the sync, the OU admins will now see the corresponding messages. Here, we see such a scenario in the screenshot. Licenses could not automatically be assigned because a license quota prevents that.

So, OU admins now see messages concerning their managed objects.
Notification emails: If the notification warnings are enabled for an admin, he or she will receive emails for warnings, such as here. The admin here got a notification that the sync could not assign a license because the license quota was exceeded. The email subject in this particular case is "D365: License quota reached".
Notification center automatic messages cleanup: Messages that popup in the notification center will now automatically be deleted if they are older than 30 days. This prevents the notification center to slow down if there are (ten)thousands of messages in the list. It deletes messages that are no longer relevant automatically from now on. The messages remain in the Delegate365 Audit log in the error table.
Reports: New reports have been added, such as Directory role users, Managed devices, and List Directory audits. The Directory roles users report generates a list of the users that are assigned to an directory role. Managed devices generate a list of properties and relationships of the managed device objects. The List directory audits report shows the audit logs generated by Azure Active Directory. See the current list and samples of all reports at Delegate365 Manual for Reports.
OU invoice data: In OU´s / Manage OU´s, now additional data for the address can be added, e.g. for billing purposes. Select an OU and click on Invoice data.

Then, fill out the fields as needed and click Save.

Note: Currently this data is not used in reports, but it can be used for future features.
Sync Rules extended attributes removed: In previous versions, automatic user OU-assignment was available for extended user attributes in Azure AD. No customers used that and this has been removed since it used an old Microsoft API that was deprecated. So, the Administration / Sync rules and the User section now looks as here: It allows to sync with security group (see more here) or to select the predefined user properties to automatically assign users to an OU in Delegate365.
Sync history: The history table now shows the number of total users, assigned users, total groups, and assigned groups. This gives an overview at a glance about changes in the Office 365 tenant.

Also, the details contains more detailed information about the sync operation, showing numbers of synced objects before and after the sync.
Fixes: We added more description, and updated labels and added info symbols here and there to make features more accessible. Also, the sync has been optimized and minor fixes have been made.

We have added many new features from our customers´ feedback and we hope you like the new and improved features of Delegate365!

Delegate365 version 9.1 will be available starting this March. atwork will propose an update date to every productive tenant. New versions get the latest Delegate365 version automatically.

Delegate365 changelog 9.1-SharePoint Online

Wednesday, March 4, 2020

Delegate365 v9.1 provides basic management of SharePoint Online (SPO) sites that are assigned to an OU. See the prerequisites (part 1) and the features (part 2) here.

Part one - Create the SPO app once

Important: Do the SPO app setup FIRST: To allow communication between Delegate365 and the SPO system, an app is required. Follow the steps described at Register SharePoint Add-ins to create the app or follow the step-by-step instructions here.
AppRegNew: In a browser, as Global Admin, open the SPO Admin page and change your tenant name in the URL: https://<tenantname>-admin.sharepoint.com/_layouts/15/appregnew.aspx
In the appregnew form, click Generate for the Client Id and click Generate for the Client Secret. Add an app title like "Delegate365SPOApp", your app domain like www.mycompany.org and a Redirect URI such as "https://www.mycompany.org /delegate365" as here. Click Create then.
The form will now show the data. Copy that data to a safe place - we need it later.

Click OK. You will be redirected to the settings page.
AppInv: Use that browser page and change the page from settings.aspx to appinv.aspx - like here: https://<tenantname>-admin.sharepoint.com/_layouts/15/appinv.aspx
In the appinv form, paste the Client ID into the App Id field and click Lookup. The app fields are now filled with your app data from the previous step. Add the permission XML from here:
<AppPermissionRequests AllowAppOnlyPolicy="true"> <AppPermissionRequest Scope="http://sharepoint/content/tenant" Right="FullControl" /> </AppPermissionRequests>
The, click Create.
Trust the app: You will be redirected to the Trust page. Click Trust It.

You get redirected to the SPO Admin center. You can now close this page.
Back in Delegate365: Use that SPO app data and add it to Delegate365 in the Administration / Delegate365 settings. Go to the SharePoint configuration section and add the generated ClientId, the ClientSecret, and add the Tenant URL. Again, the tenant URL includes the name of your tenant in the admin-URL as here: https://<tenantname>-admin.sharepoint.com as here.

Click Save to proceed. This SPO app allows Delegate365 to access SharePoint Online. If this app registration is done, the following features are available.
Note that it can take some minutes, until the new SPO app is functional and can be used from Delegate365.

Part two - Manage SPO sites

After the configuration is completed, admins can use the features in Delegate365.

SharePoint sites assignments: To manage SPO sites, admins can assign SPO sites in the OU´s / Assign menu. There´s an additional section for SharePoint. Toggle the section by clicking on the title.

The sync gets all SPO sites if the tenant and allows to assign them to an OU here - as usual. The list shows all sites with their site type that are unassigned in Delegate365. Select the sites and assign them to the corresponding OU. Click the Assign button and confirm the popup message to do so.

You can use the OU´s / Unassign menu to remove SPO sites from OU´s.
Note: SPO sites don´t have a group membership and no properties in Azure AD. So, you can only assign sites manually to an OU as shown here. There´s no sync rule for automatic assignments available.
SharePoint site and permission management: The new module SharePoint allows a basic management of the assigned SPO sites. The permission to see the menu SharePoint is controlled in the permission policies. The list shows the site name, the URL, the site type and the OU as follows.
Select a site to work with it: When you select a site and click Edit, you can modify specific site settings. The settings depend on the site type and show the most relevant site features.

For example, the Sharing capability allows to control if and how sharing of content can be made in that site.

A Team site allows more settings.

Here, sharing can be specified.
Site features: The availability of features depend on the site type. If you change a site name, the URL remains. You cannot change the type of a site. To accomplish that, you would need to create a new site with the new site type. Delegate365 currently supports the new site types Communication site and Team only.
Admins: To manage the Administrator of a site, open the Admins link. Select additional owners in the people picker and click Add. You can remove existing admins with the Remove "x" icon next to the name.
Permissions of users: To modify permissions to a site, select the site in the list and open the permission menu on the right.

In the permissions list, select the user or group. Again, there´s a permissions menu on the right to change the site permissions for the selected object. The default permissions are: Full Control, Design, Edit, Contribute, and Read. If configured, custom permissions can show up as well.
Permissions of SharePoint groups: The same system works for groups with permissions, only additional members can be edited here. Manage members allows to do so.

Here, members can be removed…

…and added.

Return to the permissions page with the left arrow symbol on top and at the end of the list.
SharePoint Provisioning: Admins can create a new SPO site with Delegate365. As usual, this operation automatically assigns the new site to the selected OU. To create a new Team, follow the link saying "To provision a new Team or a new Microsoft 365 group, click here." below the panel title. Otherwise, use this panel to create a new Communication site as here.

After filling out the site properties, click Save. This process can normally take between one and three minutes.

Note: Please do not close that panel and don´t navigate away (but you can open Delegate365 in another tab and continue to work there with other operations). In this case, the newly created site is not displayed. The new site will only show up after the next sync and after an admin has manually assigned the new site to an OU. So, it´s worth waiting until the process is completed. Once the site is provisioned it will be visible in the site list, and you can start configuring it.
Default site permissions: a new SPO Communication site by default has the following permissions.

You can start to modify them as needed or add members to the predefined SPO groups.

Note: You can add users and security groups to a SPO site. In this sample, we add a security group sg-Finance.

When creating, the permissions to that site can be set below.

Click Create to add the user or the group with the defined permissions to that site. Modify the permissions as needed.

Return to the sites with the back icon on top and at the end of the page.
Delete a site: To delete a site, select it and click the Delete option in the right menu. It will be deleted and is no longer accessible.
Note: Deleted SPO sites are "soft deleted" and can be restored within 30 days by a SPO Admin in the SPO Admin center at https://<tenantname>-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/recycleBin. Also, a site can be "hard deleted" in the SPO admin center.

If a site is restored, Delegate365 will see that site after the next sync operation. To make the site visible, it must be assigned to an OU again as described above.

Managing assigned SPO sites in Delegate365 allows scope admins to provision and to manage specific sites within the management solution and within their environment. We think this is a useful addition for Delegate365. Portal admins can control if their scope admins shall be entitled to use this feature in the permission policies.

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": [],  
 "userMembershipChanges": 
 { "distributionGroupAdded": "",    
   "distributionGroupRemoved": "",    
   "securityGroupsAdded": [],    
   "securityGroupsRemoved": [],    
   "sharedMailboxAdded": "",    
   "sharedMailboxRemoved": ""
  },  
  "licenses": [],  
  "membersAdded": [],  
  "membersRemoved": [ "BiancaP@M365x836814.onmicrosoft.com" ]
}

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.

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.
Licenses / License statistics: This module is aimed for Scope Admins and shows the numbers of used Microsoft 365 licenses as follows.
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!
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
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.
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) DeliaD@M365x423383.OnMicrosoft.com: 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.

Summary

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.

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