Click here if you like to subscribe the ChangeLog as an RSS feed.
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.
Install-Module -Name Delegate365If 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 -ForceCheck the version:
Get-Module -ListAvailable -Name Delegate365The output could look like here.
Set-DAdministrator -Identity 'john.doe@delegate365.com' `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.
-OrganizationalUnits 'London', 'New York' `
-GroupOrganizationalUnits 'Kuala Lumpur', 'Paris'
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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!
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.
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.
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.
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".
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.
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.
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.
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.
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:
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.
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.
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 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.
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.
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).
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.
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.
To demonstrate that, let´s have a look a the following scenario:
So, Adele can manage only her users and groups assigned to New York.
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.
The admin sees Seattle and New York. In Seattle, we see two users with two different domains assigned:
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.
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!
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:
UserLicenseSyncJob(349) ChristieC@M365x836814.onmicrosoft.com: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.
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
UserLicenseSyncJob(349) ChristieC@M365x836814.onmicrosoft.com: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:
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
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.
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.
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.
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.
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.
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.
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.
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.
Register the SPO app and to add that data in Delegate365. This needs to be done once by a Global Admin of the tenant.
<AppPermissionRequests AllowAppOnlyPolicy="true">
<AppPermissionRequest Scope="http://sharepoint/content/tenant" Right="FullControl" />
</AppPermissionRequests>
After the configuration is completed, admins can use the features in Delegate365.
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.
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.
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.
If you want to see the full changelog, please visit our blog.