Hello howdy readers,
Not too long passed since my last post on Azure Monitor; I couldn’t leave you alone 
.
In this post, I would like to explore something about gaining and keeping observability over guest users. Guest users in Azure Active Directory are external users to which you can grant permission on resources in your tenant, thanks to the B2B collaboration.
Adding an external user to your tenant is remarkably simple: sending an invitation to the user’s email address is more than enough. Once the invitation is accepted, the user can sign-in and access the resources in your subscriptions(s) according to the permissions given to his/her guest account.
For more information on how to send invitations or about the B2B collaboration, the following articles are available:
After having all the necessary invitations been sent, is there any way to know something about their status?
Unfortunately, there is nothing natively integrated with Azure Monitor for this scope, but together with my colleague @elenacazzagon, we found out that we have all the ingredients to prepare a satisfying meal 
.
We can start by getting the necessary information about guest users from Azure AD using the Microsoft.Graph.Users PowerShell module.
Second, do not forget that we can ingest data into Azure Monitor from anywhere (check my Azure Monitor: Logs Ingestion API Tips & Tricks post) using the Log Ingestion API.
Third, we can automate this ingestion using an automation runbook, feature of Azure Automation.
Last but not least we can use Azure Workbooks to visualize the data. Remember that observability, which is the main target of this post, goes hand in hand with monitoring (see Monitoring and observability)
Putting all this in the same pan, gave @elenacazzagon and me the idea to provide you with a sort of “tool” that allows you to gain observability over your guest users and invitations.
We built up a sample, but working, script that takes care of:
- Authenticating to Azure Active Directory using a System Assigned Managed Identity
- Authenticating to Azure using the same System Assigned Managed Identity as above
- Retrieving only the guest users
- For each guest user, getting the necessary properties like User Id, UPN, Email, DisplayName and some others.
- Sending the data to Azure Monitor
Considering the amount of information that an Azure AD Tenant can contain and the time the script would take to run and upload data, we decided to not retrieve the permissions assigned to each user or group to which the user belongs to, but only if App Roles or group membership have been configured for the given guest.
Attached to this post, you will find all the necessary pieces to begin your guest user’s observability journey sample. As journeys require preparation also this one requires some prerequisites to be put in place:
- Automation Account
- PowerShell modules imported as Automation Modules
- Log Analytics Workspace
- Custom table created in the Log Analytics Workspace
- Data Collection Endpoint (or DCE)
- Data Collection Rule (or DCR)
- Permission to be granted to the Automation Account Managed Identity
- Configuration of Automation Variables
Let us explore them one by one:
Automation Account
Any existing automation account can be used. Should you have none, create a new one following the instructions at Quickstart: Create an Automation account using the Azure portal.
PowerShell modules
The following PowerShell modules must be imported in the Automation Account prior to executing the script:
For information about how to import modules, refer to Import Az modules.
Log Analytics Workspace
Any previously created workspace can be used. Should you have none, you can create a new one following the instructions available at Create a Log Analytics workspace
Custom table
Since data into a Log Analytics Workspace is organized into tables with records and fields, we need to define a custom table prior to ingesting data. A custom table can be defined in different mode but for the sake of this post, we will refer to Create new table in Log Analytics workspace using ARM templates.
Data Collection Endpoint (or DCE)
Data collection Endpoint can be created using the Azure Portal, the Rest API or through ARM templates. In this post we will use the ARM template approach. More info in DCE creation using templates can be found at Create data collection endpoint.
Data Collection Rule (or DCR)
We will follow the same approach to DCR creation. More info available on the Create data collection rule page.
NOTE: The configuration of Custom table, DCR and DCE can be done in one go using the sample script and the template attached to this post. Make sure to enter the values corresponding to your subscription, resource group, Log Analytics Workspace before executing the script.
Permission to be given to the Automation Account Managed Identity
As far as permissions go, we need to assign two sets of permissions to the Automation Account Managed Identity:
- Permission to the DCR to allow data ingestion. The managed Identity can be assigned to the Monitoring Metric Publisher role using the Azure Portal as documented at Assign permissions to a DCR
- Permission on the Azure AD Tenant to read user information. A simple approach is to assign this Managed Identity the Directory Reader role
Configuration of Automation Variables
Once we have completed all the above, we can move on with the Automation Variables:
The script code makes use of three automation variables holding the coordinates to where and how data will be sent. They must be created according to the info below:
- gumDcrImmutableId:
- Name: gumDcrImmutableId
- Type: string
- Value: <ImmutableID of the DCR created above>
- gumDce
- Name: gumDce
- Type: string
- Value: <URL of Log Ingestion endpoint of the DCE>
- gumTableName
- Name: gumTableName
- Type: string
- Value: <Name of the custom table>
NOTE: To make your life easier, a ZIP file, with the content listed below, has been attached to this post. Remember to adapt the script for table, DCE and DCR, inserting the coordinates of your resources. Finally: TEST, TEST, TEST !
- the sample runbook PowerShell code,
- the PowerShell script to create the custom table, the DCE and the DCR
- the sample workbook code
Once all the prerequisites are in place, import the sample runbook PowerShell code making sure to import it as PowerShell runbook type and to select Runtime version 5.1.
Create a schedule for the runbook execution setting the recurrence to an interval of your convenience.
Import the corresponding workbook, wait for the first runbook execution (or execute it manually) and play with the data.
Have fun with your Guest User Management 
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.