Add a User as a Member from a different Azure AD Tenant

Azure Active Directory (Azure AD) can have two types of users: Member and Guest.

Microsoft states the following in their documentation:

The UserType has no relation to how the user signs in, the directory role of the user, and so on. This property simply indicates the user's relationship to the host organization and allows the organization to enforce policies that depend on this property.

The same documentation goes on to state:

There may be cases where you want to give your guest users higher privileges. You can add a guest user to any role and even remove the default guest user restrictions in the directory to give a user the same privileges as members.

It's possible to turn off the default limitations so that a guest user in the company directory has the same permissions as a member user.

So they actually are different…  What if you do not want to turn off the default limitations for all guest users, but one or more external user(s) need elevated access to manage your entire Azure Directory?  For example, you are working with a consulting firm like NetCorp, and you need their team to have administrative access into your Azure AD Tenant.

How about adding the External User as a Member instead of a Guest?

This is accomplished through PowerShell using the New-AzureADMSInvitation function.  This used to be possible to do through the Portal, though it appears the feature was taken away.

The following is an example of what the call would look like:

New-AzureADMSInvitation -InvitedUserEmailAddress "" -InviteRedirectUrl "" -SendInvitationMessage $false -InvitedUserType "Member"

It’s important to address some of the parameters used in the above example.

First, the InvitedUserType parameter is set to “Member” to override the default value of Guest.

Second, a user will have to accept the invitation by accessing a redemption URL while logged in as the invited user.  By default, this invitation will arrive via email.  An edge case caveat here would be if the invited user does not have a mailbox associated with the given Azure AD User’s login.  The SendInvitationMessage parameter controls whether an email invitation is sent.  In our example above, we are turning off this functionality.

Third, the InviteRedirectUrl parameter is required, but can be a ‘bum’ URL – so long as the invited user knows this.  Otherwise, it is best to redirect the user to your organization’s website homepage, or maybe the Azure Portal (e.g.

The resulting output is as follows.  Please note, if you set SendInvitationMessage to $false, you must take note of the value in the InviteRedeemUrl and provide it to the invited user.  Preferably, with instructions on how to access it (while logged in as themselves).

Id                      : ********-****-****-****-************
InvitedUserDisplayName  : John Doe
InvitedUserEmailAddress :
SendInvitationMessage   : False

InviteRedeemUrl         :********-****-****-****-************&user=**********-****-****-***********&ticket=Omgm11231YaPSYkw5Yz21jj1010mnzsd0wP25%2f23aqSQ9u%2bZfTRM%3d&ver=2.0

InviteRedirectUrl       :
InvitedUser             : class User {
                            Id: *********-****-****-****-**********
InvitedUserType         : Member
Status                  : PendingAcceptance

I hope this was as helpful to you as it was for the customer I was serving today.

Office 365, DKIM, and a naughty domain name

While helping a customer setup their Office 365 tenant, we ran into an edge case scenario…

An Internet domain name with a hyphen (minus symbol) in it.  Let’s call is

When you setup DKIM for Office 365, the DKIM ‘selector’ entries you have to create within your domain’s DNS zone are of type CNAME, and they refer to custom entries, hosted by Microsoft for your Office 365 tenant.

An example of this is as follows, per Microsoft:

Host name: selector1._domainkey
Points to address or value: selector1-<domainGUID>._domainkey.<initialDomain> 
TTL: 3600

Host name: selector2._domainkey
Points to address or value: selector2-<domainGUID>._domainkey.<initialDomain> 
TTL: 3600


  • For Office 365, the selectors will always be “selector1” or “selector2”.
  • domainGUID is the same as the domainGUID in the customized MX record for your custom domain that appears before For example, in the following MX record for the domain, the domainGUID is contoso-com: 3600 IN MX 5
  • initialDomain is the domain that you used when you signed up for Office 365. Initial domains always end in For information about determining your initial domain, see Domains FAQ.

Note: The domain name portion (<domainGUID>) of the Fully Qualified Domain Name (FQDN) of which is contoso and its Top Level Domain (TLD), .com are not separated as expected with a period in the ‘target’ value of the CNAME records.

Instead, they are separated with a hyphen (minus symbol) as in: contoso-com

So if the delimiter between your domain name and TLD is a hyphen, what happens if your domain itself contains a hyphen (e.g.

This is where the trouble comes, but how do you resolve it?

Once you have added your domain name within the Office 365 Admin Portal, under Setup > Domains, and you click on the domain name, take a look at the expected DNS record entries.  Under the proposed MX (mail exchange) record for your domain name, you may be surprised to see extra characters after your domain name, such as “0c” and the original hyphen from your domain name ( completely removed: 3600 IN MX 5

This subtle change is key to a successful DKIM setup for a domain with a hyphen in its name.

So then we know your DKIM selector CNAME entry target values should read as follows:

There you have it!

If this was helpful to you, please share it by Tweeting about your newfound discovery!

Where oh where did my DKIM go?

While helping a customer setup their Microsoft Office 365 tenant past this week, we ran into an issue with enabling DKIM within Exchange Online.

Within the Exchange Admin Center (EAC), under protection > dkim, for each domain, the Enable option was completely missing.

It was a long shot, but I tried enabling it using PowerShell for Exchange Online with the New-DkimSigningConfig command for each domain as follows:

New-DkimSigningConfig -DomainName -Enabled $true

ref: Microsoft Docs

Here is what the output looks like upon successfully calling New-DkimSigningConfig:

PS C:\Users\contosoadmin> New-DkimSigningConfig -DomainName -Enabled $true
WARNING: The config was created but can't be enabled because the CNAME records
aren't published. Publish the following two CNAME records, and then enable the
config by using Set-DkimSigningConfig.

Domain        Enabled
------        -------  False

Then, back within the Exchange Admin Center (EAC), under protection > dkim, I can now select the domain I just created a new DKIM Signing Config for, and click to Enable it as seen in the following screen shot.

Before you can Enable it though, you have to add the expected CNAME records to DNS.  I have a separate post covering the required DNS additions.

Thankfully, this worked, and now next to each domain within EAC, DKIM shows as enabled, and presents the expected options “Disable” and “Rotate” (to rotate the DKIM key):

If this post was helpful to you, please Tweet and share it with others.