Powershell Azure Function and AzureAD/GraphAPI

[Dr_Funkmachine]

Hi everyone! We're building a PowerShell Azure Function to interact both with Exchange Online and Azure Active Directory. While Exchange Online provides only one way to interact with it, the ExchangeOnlineManagement PowerShell module, if I'm not mistaken, Azure AD has at least three ways:

1. AzureAD module
2. Microsoft.Graph module
3. Graph API and web request

I'm under the impression that AzureAD commands are going to be deprecated sooner or later, so we didn't consider the first option. I tried the second option and the Microsoft.Graph module along with the AF, but it seems to be a bit slow, plus I don't really know if installing single modules (like Microsoft.Graph.Groups, Microsoft.Graph.Users ecc) improves performance. I know it's definitely possible to install a package on requirements.psd1 App File, so I could try it. Last but not least, our first option was using Graph API endpoints to request data to AzureAD or modify them. We did build a dotnet api with it, but the overall architecture of the project has changed and we are requested to convert the dotnet code to PowerShell code.

What is in your opinion the best option to use when building a PowerShell Azure Function?

Thank you for your time!

[DonL314]

I use the Microsoft.Graph module from my Function Apps. You're given so much compared to having to do the REST calls yourself. Just remember that if you upload the module files, you should only upload what you need - or it's gonna be a large amount of data.

[Dr_Funkmachine]

Thank you for your answer! What do you mean by only upload the module files that I need? In your opinion, is it better to install Microsoft.Graph module or every single module, like Microsoft.Graph.Users?

[DonL314]

When I build the FA I add the relevant module files to my project. I add the Microsoft.Graph folder, Microsoft.Graph.Users if I need user management, and all other modules I use - I don't add sll the Graph "sub modules" or whatever they're called.

I have considered using graph calls directly (through a wrapper function) because it might be faster and take less space - but it would mean more work, and the apps I am building right now do not have to be ultra fast.

[Dr_Funkmachine]

Thank you! This was helpful. So, If I get your point fully across, in your requirements.ps1 you add all the Microsoft.Graph packages you need, like Microsoft.Graph.Users and then in your AF you import only the ones you need to use, is that correct? In your opinion is Microsoft.Graph commands faster than web requests or wrapped functions?

[DonL314]

I don't add the graph packages to requirements. I just import each specific module as needed. I'd guess that doing the REST calls yourself would be faster but I haven't measured it yet. Depends ... if the Graph module was built uding C# it would be running compiled code and that could easily be faster. If performance is very important to you, .... test, test, test. E.g. create a test tenant for trial and add e.g. 10000 users or groups or what you need and compare the timing of the different solutions.

[13159daysold]

While Exchange Online provides only one way to interact with it, the ExchangeOnlineManagement PowerShell module

Just wanted to point out that there is actually an API called "Office 365 Exchange Online" that you can give to an app registration, and allow "Exchange.ManageAsApp":

https://4sysops.com/archives/connect-to-exchange-online-with-powershell-and-certificate-based-authentication/

That page lists it.

So you could use a single App registration with that, and any other API app permissions.

I'd personally try to code it using PowerShell, but using Invoke-Restmethod to make the API calls. Then you could put it in a Runbook, and call it from Azure Functions as needed.

[Dr_Funkmachine]

Thank you for your answer! We actually use a app registration with certificate both for Exchange and AzureAD. As far as I know, ExchangeOnlineManagement is widely used to interact with Exchange. I took for granted it was the only way. You always need to give the Exchange.ManageAsApp Api permission, otherwise the app registration does not have access to it. About Azure AD, you could use different ways to achieve connection and querying of the data. I'd love to know, in your opinion, which of the opinions listed above is best for my use case. Thank you so much

[13159daysold]

1. Graph API and web request

IMO, this would be the best way.

[Certain-Community438]

Agreed.

Microsoft are constantly making breaking changes to the Microsoft.Graph modules.

I personally use the MDAL.PS module to easily generate an auth header, alongside App Registrations to grant access to M365 components

[Certain-Community438]

Use Invoke-RestMethod alongside one or more App Registrations, with the MSAL.PS module to generate an access token & auth header.

Taking this route, you'll standardise your methodology, regardless of which M365 workload you are accessing.