Delegate365 is a user-friendly tool to enable delegated management of users, licenses, and groups. This means that only objects assigned to a scope administrator are displayed in Delegate365. So, sometimes, we get questions as "I can't see my users/shared mailbox or similar". Here's why and how to solve such issues.
Why does Delegate365 not show users?
Well, that's the idea of the tool. Delegate365 shows only objects to which I am entitled to see and to manage.
Portal administrators (users who can configure Delegate365) define Organizational Units (OU's) and assign objects as users and groups to them. In Delegate365, an OU is a container for managing objects. Then, they define scope administrators and what OU's they can manage. So, the scope admins see only objects they can manage in Delegate365. For example, a scope admins sees an Office 365 Group, but in that group he sees only the members he can manage (and not other members that might be in that group as well). That's the basic rule and the concept. That being said, there are two conditions that must apply for administrators and users as follows.
Administrator assignments
Scope administrators must be assigned to the OU AND the user DOMAIN in the Administration / Administrators menu.
For example, to see user "DebraB@M365x036690.onmicrosoft.com" who is assigned to OU "Seattle", the administrator must be able to manage OU "Seattle" and he must be able to manage the domain "M365x036690.onmicrosoft.com". So, an OU and the user's UPN domain must be assigned to a Scope Administrator. See this screenshot when a new administrator is added. At the end, the panel asks for the domain and the OU assignment.
Of course, this can be done for existing admins anytime in the menu as well by selecting an administrator and assigning the domain(s) and OU(s) in the corresponding menus on the right.
Note: Only users that are in the administrators list are able to login to Delegate365 and to use the management capabilities of Delegate365. Just to mention, there are some modules that can be used by end users, see How to manage self service password reset for users in Delegate365.
Users
So, these two assignment, OU and domain, are required that an administrator sees "his" assigned users as the following screenshot shows. Both conditions must be fulfilled, as marked with red boxes below.
Additionally to the OU, the domain restriction allow to filter just for specific domains within one OU. E.g. if there's a country OU "Germany" and in that country, there are multiple custom domains for sub companies or departments or brands as mycompany.org, mycompany.de, mybrand.com, etc, the domains can be assigned to different administrators. Again, scope admins must have the user's UPN domain assigned to be able to see these users.
Mailboxes and groups
The domain assignment will not be considered for other objects than users. So, shared mailboxes, resource mailboxes and groups show all objects that are assigned to an OU, regardless of the domain.
As mentioned above, administrators see only members of their own entitled OU's. This is not a bug, it's a feature to ensure that administrators cannot modify new or existing members they shall not see. An exception to break that system is the concept of Group OU's. This allows to add users as members to own groups even if you cannot manage them. See more at see Delegate365 changelog version 8.0-Group OU's.
Assign objects
Still don't see users, mailboxes or groups?
Ensure that the objects (users and groups) are properly assigned to an OU in Delegate365. This can be done manually and automated. Anyway, Portal Admins can check that anytime in the menu OU / Assign and in OU / Unassign.
This OU / Assign module shows all UNASSIGNED objects and allows to select objects and assign them manually to an OU. This must be done per object type. You find the users in the User box, Shared Mailboxes in that box, etc.
Note: The OU assignment can be automated based on user properties or group membership in module Administration / Sync rules. If such rules are enabled, assigned objects can change an OU automatically.
Objects that are assigned to an OU can be exported in the Reports menu with report OU overview.
Unassign objects
To check, if objects are already ASSIGNED to an OU in Delegate, open the OU / Unassign menu.
Here, all objects that are currently assigned to an OU in Delegate365 are shown, as user "AdeleV" is assigned to OU "Seattle". You can select objects and un-assign them. Then, they are no longer visible in Delegate365 and they will show up in the OU / Assign menu again.
Shared Mailboxes (SM) and Resource Mailboxes (RM)
Looking for shared mailboxes or resource mailboxes and don't see them?
In Office 365, every mailbox is of RecipientType 'UserMailbox' and the RecipientTypeDetails property makes the difference. Check that in your tenant in your Office 365 portal - or by connecting to Exchange Online and running the following Remote Exchange PowerShell command:
Get-Mailbox -ResultSize:Unlimited `
| Select PrimarySmtpAddress,RecipientType,RecipientTypeDetails | ft
The output shows all mailboxes with three different RecipientTypeDetails: UserMailbox, RoomMailbox and SharedMailbox.
PrimarySmtpAddress RecipientType RecipientTypeDetails
------------------ ------------- --------------------
AdeleV@M365x036690.OnMicrosoft.com UserMailbox UserMailbox
Adams@M365x036690.onmicrosoft.com UserMailbox RoomMailbox
shared1@M365x036690.onmicrosoft.com UserMailbox SharedMailbox
Delegate365 queries objects by the RecipientTypeDetails. So, the objects (if assigned to an OU, see "Assign objects" above) are shown in the Users, Shared mailboxes and Resources modules, analogous to the RecipientTypeDetails.
If you are unclear why objects do not show up, pls. check the RecipientTypeDetails of objects and if they are assigned to an OU in Delegate365. Then, they will show up in the corresponding module.
When using Sync Rules with CustomAttributes, you can check if the required attributes are set for Delegate365 by querying them as in the following sample using CustomAttribute10.
Get-Mailbox -ResultSize:Unlimited | Where {$_.CustomAttribute10} `
| Select PrimarySmtpAddress,RecipientType,RecipientTypeDetails,CustomAttribute10
Here, only two mailboxes have a value stored in CustomAttribute10.
PrimarySmtpAddress RecipientType RecipientTypeDetails CustomAttribute10
------------------ ------------- -------------------- -----------------
Adams@M365x036690.onmicrosoft.com UserMailbox RoomMailbox Berlin
DiegoS@M365x036690.OnMicrosoft.com UserMailbox UserMailbox Vienna
Note: If Sync Rules are configured using CustomAttributes1 to 15, be aware that only users with an existing Exchange mailbox (a license) do have these attributes. So, a user without Exchange license, does not have CustomAttributes as long as the user property schema is not extended through the Exchange server. This happens automatically by assigning an Exchange license to a user (or if a new mailbox as a SM or RM is created). So querying data is good to ensure the values are set correctly. If possible, we recommend to use Security Group membership since this is more performant and usually easier to manage.
Sync: Ensure Delegate365 is up to date
In the background, Delegate365 synchronizes changes (the delta) between Office 365 and Delegate365. So, if a user or a group is created, modified or deleted or Office 365 licenses are assigned, Delegate365 knows about the changes and updates it's cache. If a change has just been made in Office 365 through any other system (bulk assignments, PowerShell scripts, etc.), it might take some time until Delegate365 sees the latest changes. This usually happens within less than four hours. Anyway, administrators can force a manual sync anytime in the Administration / Sync operations menu.
Note: If you just know that any changes happened in Office 365, start the AAD sync in Delegate365 manually to ensure that Delegate365 is working with the latest changes of objects. Otherwise, just wait. The Sync history box informs about the latest sync processes. The Sync Rules in Delegate365 are attached to that sync process. So, they run, after any Delegate365 objects have been updated.
Summary: Step-by-step troubleshooting
If objects are not shown in Delegate365:
- Check if the objects are visible in the cloud (in hybrid scenarios). Check in the Office 365 portal.
- Check the last sync operation (that Delegate365 is up to date) or run the sync manually in Administration / Sync operations.
- Ensure that the objects are assigned to an OU. Check OU / Assign (for unassigned objects) or OU / Unassign (for assigned objects). Assign objects to an OU.
- Check if the administrators have the OU AND the DOMAIN of the users assigned in Administration / Administrators.
If sync rules are active and objects are not shown, check additionally:
- When working with CustomAttributes or names: Do the objects really have the values assigned that are defined in the sync rules? Check the data.
- When working with group membership: Is the object in fact a member of that group?
- Is the sync rule correct and active?
- Might there be contradictory sync rules?
As IT-Administrator, with these simple steps, you should be able to discover, why objects are not visible in Delegate365 and you should be able to fix that accordingly.
We hope, this article helps to configure your Delegate365 so that delegation works for your organization and relieves IT tasks.