I was working on something today where I wanted to use the AzureAD PowerShell module, you know as one does. In order to use any of the commands in the module it has this weird dependency where you have to FIRST run the `Connect-AzureAD` command. Which makes sense, you want to make sure you're connected to something before you try and do it. What doesn't make sense though, is the kind of weird implementation of the command especially if you try to call it from another function. # The Problem Every time you call `Connect-AzureAD` it assumes you want to generate a new connection to AzureAD. Which, honestly kinda makes sense. However, the implementation of this puts you in a position where if you are not connected it yells at you. If you run it and your already connected, it assumes you want to connect again and destroys your session. I don't want to destroy my session, and I want to build the connection without tons of angry red text, and only if I need to. ## The solution - ish. There is another command in the AzureAD module called `Get-AzureADTenantDetail` it does exactly what's on the tin. Get's details about your Azure AD Tenant. >[!Tip] Never Underestimate Get-Command > I previously wrote an article: [[PowerShell - Get-Help]] in this article I covered how to use things like "get-help" and Get-Command. I found the Get-AzureADTenantDetail command by using Get-command and limiting it to the AzureAD module. I say this is a solution - ish because if you attempt to run `Get-AzureADTenantDetail` and you haven't run `Connect-AzureAD` you'll still get an error message. But the error message, is specific, and the outcome of running the command is some generic tenant data. ## Getting a specific Exception Understanding Exceptions is an entirely different topic, but for now let's just all agree that exceptions are stored in the `$error` variable. We can use this to figure out the name of the exception that occurs when `Connect-AzureAD` hasn't been run yet! Step one is to generate the error! ![[generateException.png]] Once we've generated the error we can then take a look at it by selecting the error and looking at it's type information. ```powershell #Get the most recent error, get the exception get it's type, get its full name. $error[0].exception.Gettype().Fullname ``` This will then reveal to us the exception we are looking for is called: `Microsoft.Open.Azure.AD.CommonLibrary.AadNeedAuthenticationException` Great we can use this! ## Try, Catch and Finally One of the best kept secrets in PowerShell when it comes to Try & Catch statements is their ability to catch on a specific exception. Since we have the specific exception here we can now write a little try catch to prompt us to connect on our custom functions. We'll only be prompted when we need to connect, and we won't destroy our existing connection every time we run our command. ```PowerShell try { $validateConnection = Get-AzureADtenantdetail } catch [Microsoft.Open.Azure.AD.CommonLibrary.AadNeedAuthenticationException] { Write-Verbose -Message "Not connected to Azure AD - Will Prompt for connection" try { $connection = Connect-AzureAD -ErrorAction Stop } Catch{ Write-Error -Message "Failed to connect to Azure AD - $_" -ErrorAction Stop } } ``` This will let us test to see if we have a connection and help us fix it if we don't. For bonus points, we would want to use this in "begin" block if this function we were creating accepted input from the pipeline. This way we wouldn't test the connection on every single iteration! # Conclusion Sometimes people do weird things in PowerShell. Sometimes it's easier to just write lots of little helper functions to work around said problem! There are a lot of little places where things like this are helpful in Configuration Manager and various other platforms. As always I hope this was helpful and you can find new and interesting ways to use it!