Problem

After participating in a number of Office 365 projects it gets cumbersome to manage lots of Office 365 accounts. Furthermore some people still seem to have the habit of using shared admin accounts which, in combination with password expiry, is annoying to deal with. Fortunately there is solution for that: the “Delegated Administration” feature. This feature basically allows a consultant to use his account in the Office 365 tenant of his employer for administering customer’s tenants.

I never got this particular feature to work in the previous wave of Office 365 so I was eager to use this functionality in the first couple of “wave fifteen” O365 projects.

Solution

Prerequisites

First of all you need to have the (Global) admin of your own company assign your account with permissions for delegated administration of customer tenants. They can do this in the properties of your account if you’re a Microsoft Cloud Partner.

Note: the screenshot below is in Dutch but it basically shows that I have no permissions on the tenant of my employer (first pair of radio buttons) and full admin permissions to request our customers for delegated permissions (last pair of radio buttons).

Web interface

Now, after logging in to Xylos’ Office 365 tenant, you can see (besides that I don’t have any user license assigned for the moment) that there a partner tab appears:

This tab provides an option to send, in addition to trial and purchase offers, requests for delegated administration

You need to copy the content of the “popup” to a mail yourselves. This way your customer will receive a “personal” mail rather than auto generated one which might get neglected.

The customer that receives the e-mail obviously needs to click the link and approve the request

Your customer can find delegated admins in a separate page of the “users and groups” section in his portal.

After finalizing the project he might want to “break” the delegated permissions. This can be done by checking the box besides the appropriate entry to activate a card with the well-known dumpster icon.

You’re all set to start administering your customer, you can use the “find and assist” option on the partner tab to do so

Next you need to search for the tenant or domain name of the customer in question

If they do not exist or the customer did not (yet) accept your request for delegated admin rights you will get a “user name or domain not found” notification.

If you’re lucky the result will resemble the screenshot below:

As you can see there are three options available to you

Let’s try some right to left reading

First of al there is “Show all administrators”

In the middle we can “Create Service Request” for our customer

Last but not least “Administer on behalf of” takes us straight to the dashboard of your customers O365 tenant. From there we have a access to all the other aspect of the O365 tenant administration

How nice ;-)

Note the difference in the presence of a “partner” tab when administering your client. Hitting is takes you back to your own tenant.

PowerShell

Managing thousands of users in a web interface, e.g. to assign licenses, does not fit my definition of “fun”. PowerShell is much more up to the job. And yes we can also use our delegated admin to do so.

As usual; import the msonline powershell module

Connect to the online services using your own O365 account. (The “get” of the credentials was done using some function I wrote myselves)

Now if you execute cmdlets you will run them in your own tenant. To administer a customer you need a unique identifier; the “TenantID”. You can find it using the get-msolpartnercontract cmdlet (there are most probably additional ways to do so).

Then you can pass the GUID you obtained as a parameter to most (if not all) “MSOL” cmdlets:

Without that parameter the result looks slightly different. However, there’s no way you can see what tenant the result is for. A couple hours of decent sleep seems advisable ;-)