We use Azure B2B extensively. However where B2B users have been into our directory and the user has left the third party organisation and thus had their account removed does not clean up the guest account records in our directory.

Over time this leaves thousands of 'orphaned' guest accounts in our directory, with no ability for our administrators to identify which accounts are orphaned. and thus numbers of guest users in our our directory expands over time infinity

Azure AD should automatically in the in the event of a user object being removed from the third party directory remove the guest pointer record from any directories where the object has been invited as a guest.

We invite quite a lot of external guests into our SPOnline tenant. Originally via the (old Azure portal) bulk add (CSV) B2B process, but more recently via the (new Azure portal) invite guest user B2B/B2C process.

We're getting more and more B2B users that fit into one or more of the following:

1. Don't know their organisation has O365
2. Don't know their O365 login (it's not always their email address)
3. Their organisation/domain is registered for O365, but they don't have a license.
4. Have O365, but aren't syncing their AD with AzureAD.
5. Aren't able to get their IT to give them O365 access (quite frequent when their domain has been registered for O365 by the offshore parent company).

This leads to very unsatisfied users, as we have to try a number of mechanisms to give them access, usually ending with them registering a personal MS account and we revert to B2C - which is not good practice for Extranet/B2B situations.

It would be useful if we (the invitors) had some mechanism for determining what a users O365 status is, so we can adjust our process accordingly.
It would be useful if the invitees were able to retrieve/reset their AzureAD passwords, without the intervention of their (often not local) O365/Azure admins.
It would be useful if the ability to be invited to a third party O365/SPOnline tenant, wasn't influenced by your own O365 licensing status.

While the whole invite process is much better than it was, it's still by far the least smooth aspect of working with external parties.

We need to create many users for our testing environments. Normally, the way we do this is to use 'plus-addressing'. This is a convention by which you can add a '+' sign and then anything afterwards to an email address, and it gets delivered to the recipient as if the + and everything after did not exist i.e. the following two email addresses are different but get delivered to the same place:

me@gmail.com
me+foo@gmail.com

This is a standard called 'sub-addressing' which is supported by quite a few mail providers, including Google Gmail, Google Apps, Yahoo! Mail, Outlook.com, and quite a few others. See https://en.wikipedia.org/wiki/Email_address#Subaddressing.

This is extremely useful for testing, because we can create multiple accounts in AAD which all map back to the same physical address. These multiple accounts are necessary to test things when developing an application that uses AAD, like accessing the system as different users that have different permissions, client associations, and so forth. Without this, we have to create fake addresses at our email provider, and alias these to real addresses manually, which is error-prone and time consuming.

Currently when I try to create a plus-address via the Microsoft Graph create user API (POST https://graph.microsoft.com/v1.0/users) OR invite API, I get this error message:

com.microsoft.graph.http.GraphServiceException: Error code: Request_BadRequest
Error message: Property userPrincipalName is invalid.

Please support plus-addressing, which is a very common way to deal with this kind of situation. If you like, make it an application option that is off by default, but that can be enabled by admins for specific applications.

Consider the following scenario. You have a sister company or other company with their own AzureAD tenant, for which you want your users to be able to collaborate. You invite those users to your AzureAD tenant. Depending on how you do so, those external users may be Users or may be Mail Enabled Users.

These External Users may now collaborate with your users using SharePoint or other AzureAD connected business apps, but if you're users are regularly collaborating with these external users, wouldn't it be great if you could make it easy for your users to find them in the Exchange Global Address List?

In the past you would need to also create Contacts in Exchange Online in order for your users to find these objects in and Exchange Address Book.

By default Mail Enabled Users are hidden from the Exchange Global Address List but you can change the attribute ShowInAddressList to True and now your External User has both the functionality of a User AND a Contact.

Now, consider these External Users are actually payrolled staff who happen to use another AzureAD Tenant for any number of reasons. Maybe they are part of the same company but have a tenant registered in a different geography. Maybe they are a sister company or users from a company you acquired. ...or maybe they are just users of a very close business partner who you want to have full access to your tenant. In this case you want to provision them as UserType Member instead of UserType Guest.

Invitations for External Guests are provisioned as "Mail Enabled Guests" but invitations for External Members are provisioned only as "Users". Using Set-ADUser you can change the UserType to Guest, which will automatically Mail Enable the user, and then you can change it back to UserType Member and it will forever remain a Mail Enabled user.

Why not give the inviter explicit control of this behaviour on invite?

This is powerful stuff here. This makes it very easy for a company to manage users in multiple tenants as if they are one. From a user perspective they can easily find these external users in Exchange/Outlook/SharePoint, etc.

Microsoft should enable portal.azure.com and Azure AD PowerShell to explicitly set Mail Enabled to True or False for both Member and Guest invitations, and also set the ShowInAddressList attribute to True or False during invitation rather than having to invite all as Guest and change them to Member and set the ShowInAddressList attribute after invitation.