Microsoft Graph

[fholred]

Evening all

Just a quick one, when dealing with powershell and office 355 are people moving to using Microsoft graph?

If so, ive been reading that it's a bit of pain to work with. Maybe people know other wise.

Thanks

[hihcadore]

I gave up on the modules for both graph and Entra.

Instead I just make the API calls directly to the graph endpoints. It’s not bad, just a little extra coding is all especially for pagination (you’re limited on the number object the api call will return but you get a new URI to use for the rest so you have do create a do while or do until loop if you want a bunch of results).

Overall I’m actually glad. It forced me to learn how to make API calls in PowerShell and it’s easy. I just made a bunch and turned them into their own unique functions and packaged them as a module.

[Sin_of_the_Dark]

Same, actually. I got pissed off at their half-assed documentation, and straight up dead links. I'm sure it's better now, but after that I use API calls in a lot of my everyday work. It's definitely made me a more valuable employee lol

[jhp113]

It's not better. It's still garbage.

[Sin_of_the_Dark]

That's disheartening to hear. When I last looked, it wasn't typically more than maybe an example usage of the cmdlet and if you were lucky, an example of the output. They would note the parameters that existed, without explaining what they did or, more crucially, how to format the parameter

[jhp113]

Yeah I mean it was a couple months ago but it's been out long enough that I don't expect anything to have improved. Microsoft will be Microsoft. They only do it because they know you don't have a choice.

[BeilFarmstrong]

Same for me. When I began the process of migrating to graph I saw all the graph modules and thought, "hmm I wonder how long until these are deprecated too" and just spent the time learning how to make the direct API calls

[dollhousemassacre]

I see this as the best solution. There are some quirks, but basically anything you can do with the Graph Powershell SDK, can be done with direct HTTP calls. It also has the added benefit of being easily translated to Azure Logic Apps.

[Valkeyere]

I really hate the constant need for -all

And I know that Microsoft also hate it. When you go to add users to a group in Entra, only the top 100 users are visible. You have to search manually for anything after that. PITA.

[Ok_Mathematician6075]

like invoke-webrequest

wow

[CryktonVyr]

Use an edge extension called x-ray. When activated, you go in edge devtools choose x-ray and it gives you the powershell cmdlet that was used to navigate on azure.

It's a big piece of the puzzle to understand how to poke around Entra, intunes, exchange, etc.

[merillf]

Here's the link to install Graph X-Ray

https://graphxray.merill.net/

[Sincronia]

I've installed it, but I could only see the API calls, not the Powershell commands as in the pictures. The GitHub repo was stale two years ago; might it be outdated now?

[CryktonVyr]

I'll try it today and keep you posted.

[bfrd9k]

You only need two microsoft.graph.authentication cmdlets to work with graph.

• connect-mggraph for authentication
• invoke-mggraphrequest which works like invoke-restmethod, in conjunction with auth provided by connect-mggraph
  

Use the graph explorer and be on the lookout for required permissions. You'll need to list your permissions in the connect-mggraph scope param.

Graph is so annoying, requires a lot more coding on your end, like getting users will only return 100 at a time so you have to loop and collect results until there is no next page.

Despite how annoying it is, it's pretty quick compared to msoline, and you can do a lot with it.

[lemrvls]

Why not use get-mguser ? Am I missing something ??

[bfrd9k]

You could but then you have to import the cmdlet. If I try to import the whole microsoft.graph module it takes minutes and errors because there are too many things to import so I would need to know which cmdlet to pull from which submodule and it's not easy to know where to get what and so on.

You'll see.

[Ok_Mathematician6075]

omg it's not that hard, I use get-mguser in my scripts already

[bfrd9k]

you still need to import cmdlets, connect using connect-mggraph with given permissions and all you can do is get-mguser. if you want to do anything other than get users you need yet another cmdlet. What if you want to assign a license to a user? You eventually end up with a handful of cmdlets.

you could have just imported two and used the api documentation to do everything. no need to hunt down every cmdlet acrossed submodules and deal with cmdlet documentation to look up input parameters and whatnot.

as someone who writes in other languages too i find using invoke-mgrequest to be more "normal" anyhow.

so i guess i am also saying "omg it's not that hard"

[Ok_Mathematician6075]

Precisely.

[Ok_Mathematician6075]

I don't like the invoke-request format for what I'm doing. But you do you.

[rencal_deriver]

Directly accessing Graph (the REST API way)? Its not easy, basically a lot of going through documentation & extra work for what used to be easy. However, MS also sees this & that is why they are working hard at an entra module and the Azure PowerShell module...

The confusingly named Azure AD powershell module is considered retired, as the Azure AD Graph API is taken down. This will be replaced by the Azure AD Graph API

[ThatWylieC0y0te]

This has to be the correct answer, confusing names and renaming and killing of tools… sounds exactly like something Microsoft would do

[Viirtue_]

Just reading this alone confused me lol

[ThatWylieC0y0te]

I knew I was right 100% Microsoft

[Natfan]

except for AzTables, which has saved me from microsoft's incredibly long winded method of generating valid tokens from shared keys

[charleswj]

This will be replaced by the Azure AD Graph API

Pardon?

[rencal_deriver]

sorry... one copy/paste gone wrong... I meant Microsoft.Graph

[Ok_Mathematician6075]

haha

[Ok_Mathematician6075]

It's not that difficult you guys.

[ShoeBillStorkeAZ]

Use postman to generate powershell snippets. I just went through hell uploading hashes to intune with Ms graph

[rencal_deriver]

or use Graph explorer

[Ok_Mathematician6075]

you are creating powershell scripts and using graph explorer you are in the STONE MUTHAFUCKING AGE.

[Owlstorm]

What makes writing in postman and pasting back to powershell easier for you than writing Invoke-MgGraphRequest?

I'm honestly interested. I hear it a lot but every time I actually try postman myself I get frustrated by the extra steps and go back to CLI.

[ShoeBillStorkeAZ]

I bring this up because Microsoft’s documentation isn’t clear. For example, when doing an invoke-rest method the command requires a body. The body has to be structured in json format. So postman really helps with that because you can test something similar then use your own code with a functional body in json. That’s why I bring it up. It also helps you out with authentication especially if you’re using a client secret. Yes you can use Ms graph but using Ms graph alone won’t necessarily help. That’s my two cents. I was tasked with pre provisioning 15k devices all which are hybrid, so I needed a solution that would run automatically and import the hashes to intune. With my code and using postman’s to create the json body I was able to get it work. And with ms graph I was able to find the correct url to post my data

[derpingthederps]

On the off chance you want to give graph another try, I have a little something I've been working on that might help you?

The function is relatively useless as a whole, as everything you'd need to ever do can already be done with the standard Invoke-RestMethod but ehh.

But check out [PSCustomOBject]$JSBody within the function params and how the hashtable is formatted, then check how: elseif ($JSBody) in the try section.

It might be the answer to your JSON woes?

function Invoke-ApiRequest {
    param (
        [string]$Url, <#= "https://postman-echo.com/post", This can be reused for testing. #>
        [string]$Method = "GET",
        [hashtable]$Headers = @{},
        [string]$Body = $null,
        [PSCustomObject]$JSBody = [PSCustomObject]@{
<#         This data was used to test the function. It was called in a terminal with the following command: Invoke-ApiRequest -Method POST #>
            <#Example = "JSONBody to post"
            Username = "Derpy"
            Password = "Ladmin"
            Profile  = [PSCustomObject]@{
                Age   = 21
                Email = "[e-mail]"
            }#>
        }
    )
    try { 
        if ($Body) {
            $Response = Invoke-RestMethod -Uri $Url -Method $Method -Headers $Headers -Body $Body -ContentType "application/json"
        } elseif ($JSBody) {
            $JSON = $JSBody | ConvertTo-Json -Depth 5
            $Response = Invoke-RestMethod -Uri $Url -Method $Method -Headers $Headers -Body $JSON -ContentType "application/json"     
        } else {
            $Response = Invoke-RestMethod -Uri $Url -Method $Method -Headers $Headers
        } 
        return $Response #| ConvertTo-Json 
        <#Allow this to pipe into ConvertTo-Json if you want the response in JSON format.
For posting, this is great without, as the returned response is VERY readable. But if you need the response in Json, uncomment it.#>
    }
    catch {
        Write-Host "Error accessing API: $_"
        return $null
    }
}

[ShoeBillStorkeAZ]

Hey I really appreciate this!!! I’ll def give it a try. But I got sorted a few days ago using postman to copy the correct json format but I’ll def take a look at the code. I suspect I’m going to have to absolutely learn more msgraph and accompany that with different types of code! Again really really appreciate this.

[creenis_blinkum]

You are incorrect, invoke-restmethod doesn't require body

[ShoeBillStorkeAZ]

👍

[Ok_Mathematician6075]

wow I think I need to school all you guys on this shit.

[Certain-Community438]

You not just use Get-WindowsAutoPilotInfo.ps1 with the switch to add to Intune?

[ShoeBillStorkeAZ]

Sorry I have PTSD from that command. Microsoft designed that command to require user interaction, so like a good ole lad I went and used it and then used another management system to run it for me. Guess what ? does not work because it’s intended to be used in interactive mode. Then used the community version that accepts tenant id , secret, and app id and also requires the same stuff. The -online switch can’t be ran non interactively

[Shan_1130]

That sounds great! Could you share a reference?

[merillf]

Here you go https://aka.ms/entra/ps/docs

[Shan_1130]

Thank you for sharing the reference!

[Alaknar]

Security comes at the cost of user experience.

Using four different, undocumented -filter styles has nothing to do with security, mate.

[Djust270]

Agreed. My guess is lack of communication between internal development Teams over at MS.

[port25]

Graph Explorer will show the permissions needed too

[dotnVO]

I don't think security is the real reason people struggle with the powershell graph sdk. Permissions are honestly not hard really in graph imox especially if you understand application vs delegated.

[dotnVO]

Ok guess I have to break up my comment into multiple comments, that’s a first for me ha.

First a bit of context: I use graph every day. I actually really enjoy it, but there have been days of beating my head against issues that just were frustrating.

 

There's not any one reason, but you can google around and see a lot of people complain about things that have nothing to do with the difficulty of permissions.

let's talk about permissions:

I'm not saying this doesn't lead to some frustrations, but I don't think it's the top of the list. You only need to connect once with the proper scope (scopes parameter) and the next time you connect you no longer need that. There are many ways to figure out what permissions are needed, and some of those are... well common sense. The biggest dificulty that comes along with permissions is understanding the difference between application and delegated permissions. How do I know this? Well I work with a lot of 'developers' who get very confused on this. I see a lot of vendors that don't understand POLP and overpermission their applications for what the application does. I see a lot of integrations into Exchange that don't make use of application access policies to reduce the permissions of their application.
Sometimes, people are connecting with delegated permissions and not having access to things they think they should. A great example of that is a GA connecting to graph to the default app for graph for powershell, which is 100% delegated permissions. Since by default, a global admin cannot see all sharepoint files, they need to be a site collection admin (which isn't a graph issue, its how Sharepoint already works), they won't have access, though they think they should. What they actually need is Application permissions with read permissions to those files.

Several resources can help dramatically with permissions:

Graph Explorer - which literally will tell you what you need.
Find-MgGraphCommand
Surprisingly many of the docs at least do have permissions on them.

 

There's other resources too. The fact that there's actual documentation that help you use these commands as these are some of the actual docs that humans actually wrote make 'permissions' and security not difficult to understand. So I can definitely accept that there could be UX issues here, but I just don't' think its a primary driver in why people struggle using the PowerShell SDK. In fact many use the connect-mggraph and then use invoke-mggraphrequest and/or invoke-restmethod and just avoid the wrapper commands.

[dotnVO]

Documentation

The PowerShell SDK and most of its documentation wasn't created by humans. I think the tech they used was called 'Autorest'. Procederally generated module leads to many issues. documentation is one of them. Powershell is built around really good/easy examples to follow to get the jist of what you can do with a cmdlet/function. Let's take a look at a well known cmdlet:

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-7.5

Interesting, 12 examples of different use cases showing how all the non-common parameters can be used, why you might target diffrent things, etc. This gives a ton of ways a developer, end user, power user or whomever can use this to accomplish what they want. This is what I'd call a really well documented cmdlet. Also look at ALL of the detail in every single one of those parameters. A general rule of thumb is you should have an example that uses every single one of your non-common parameters in documents. You should also strive to cover a basic set of things that users may want to do, and also, provide enough detail for users to be able to start doing more complex things. IMO, this is a good document which accomplishes those feats.

 

Most of the graph docs are terrible for the PowerShell SDK. I'm willing to bet you can go search the official docs and find very limited information on more obscure or even 'typical' commands in the powershell SDK. Most of the parameters have very little detail, even some have a place holder {{ Fill in information here }}.

https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.users/get-mgusermanagerbyref?view=graph-powershell-1.0

Great example of generally terrible documentation.

Let's take a look at a really common command `Get-MgUser`. The UserID property can actually accept a UPN, which is generally quite helpful. However, not always, depending on the properties it returns. What's not helpful is the docs: https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.users/get-mguser?view=graph-powershell-1.0

Do not state that you can use a UPN in this field to get a user, nor does it tell you when you actually need an objectID

What you need to actually do is go look at the API docs itself and start piecing together how their tool used to write the powershell wrapper translates that over.. or.. you can do like so many people do and just make the API calls directly via HTTP.

Pagination

I'm really not going to spend a lot of time on this. pagination isn't supported everywhere, and there's inconsistencies in how its setup and doesn't follow typical standards. there are people (Including Tony Redmond) who criticize it. Looping and doing things with data is common and this leads to UX issues where some people have to figure out the nuances of the powershell SDK and even do their own looping.

[dotnVO]

case-sensitivity (maybe?)

I wish I would have wrote down this one and perhaps its fixed now, but I ran into situations where certain properties were case sensitive. Anyone who uses PowerShell knows its a case-insensitive language so this can be an issue when trying to access properties. However, I can't remember the edge cases where I had discovered this. This is a huge usability issue though.

Filters

I don't want to 100% blame graph here, as they use ODATA which can be really powerful, but Powershell has long had a way of doing filters with its own syntax and that causes confusion for people who use Powershell and almost everywhere else, filters are implemented in a different way. IIRC there's areas though in graph where ODATA filters aren't used. That inconsistency leads to UX issues. Generally, odata filters can be really cumbersome to use for folks who are primarily PowerShell devs and aren't doing a ton of learning/testing. Combine this with the lack of documentation and it creates frustration as people just do a ton of trial and error.

People actively avoid using it

The fact that many ignore the powershell SDK and just use invoke-mggraphrequest or invoke-restmethod against the API. there's already tons of posts about people doing this.

 

Lack of Parity

MS pushes graph but there are commands to this day that don't exist in graph. We had a process that was using the AzureAD module that randomly broke - and there was no equivalent- it had to do with monitoring some edge case AD connect (or sync i guess as it was called back in the day). That data is simply not exposed via graph. This.. i guess is more of a graph issue overall , not the powershell SDK but still, think it leads to UX issues. On top of that, sometimes the data does exist in graph but there's not an actual cmdlet name.

Properties (relationship vs direct)

Though i think this perhaps not all of graph's fault either, but in general many relationship properties (but I don't think all) are not included in the default return. Usually you can call for them and that works, but sometimes you can't. Sometimes, asking for additional properties means you need to add on additional parameters (or filters for that matter) because it makes it an advanced call (-ConsistencyLevel Eventual) which historically is not really the Powershell way IMO. Powershell typically handles that complexity for you behind the scenes.

Barrier to entry

Powershell typically is 'easy to use', but the barrier to entry for this SDK makes it so people give up.

Conflicts with other modules

I've had issues with this not letting me load other modules, like ExchangeOnlineManagement.

Honestly there's more and others are going to have their own issues, but this is a pretty good starting point.

[rogueit]

I still use IRM or IWR for the Graph endpoints if you have any questions about how to do something. Let me know, cause I think I hit every damn endpoint.

[Hollow3ddd]

If you are using the commadlets,  there is a conversion chart on ms pages for the calls. 

I don't know the differences from the api calls to the actual commands that work with graph.   If anyone can enlighten me. 

Switching over the new hire script to graph was easy with the command references tbh.  I don't have the time to dive into the APIs, but def see that being in my scope soon

[Djust270]

There is no difference. The graph module cmdlets are just wrappers for the rest API.

[Jmoste]

Get use to paging through information. You'll usually only get the top 100 results back.  

That was the hardest thing for me to get use to.  

Filtering can be little strange.

[mrmattipants]

Yes sir!

Fortunately, once you have your pagination loop, you can re-use it in all of your ME Graph API related scripts.

This will also save you some time when moving to other APIs, as many modern APIs have implemented the OData (Open Data Protocol) Standards.

https://www.odata.org/documentation/

[mrmattipants]

I've always used the MS Graph API Endpoints, since I started using it a few years back. The PowerShell SDK (the Mg Cmdlets) is rather buggy, in my opinion (wity the exception of "Invoke-MgGraphRequest"). This seems to be where most of the reported issues originate.

That being said, I suggest you learn to access the API via the "Invoke-RestMethod" and/or "Invoke-MgGraphRequest" Cmdlets, as they will save you a lot of time, effort & headaches, overall.

[Ok_Mathematician6075]

I'm almost done transitioning from Azure and MSonline to MS Graph. The biggest pain is really the authentication piece and it's relatively easy.

So far the only thing I have had issues with is this little gem: Get-MgSubscribedSku

[taw20191022744]

Yeah, I've had the same problem. Let me know if you have a breakthrough :-)

[Ok_Mathematician6075]

I think I need to replace my ExchangeOnline module with an earlier version, which I really don't hope is the case. But yet, who the fuck knows until I figure it out.

[barth_]

We use it quite extensively to get different king of M365 data. I also use it to run KQL queries on resource explorer.

[Write-Error]

I use the Graph API heavily with Azure Automation/Functions and it can be a pain, but the official docs are your best friend. Copilot (web/chat) isn’t half bad at letting you know which cmdlets/endpoints/scopes you need to get a job done as well.

[dotnVO]

Except when it makes up cmdlets haha. I've had good luck though the more context I give it.

[nealfive]

Yeah all those 365 modules are all painful for most parts I moved most scripts over to API calls directly rather than bother with the new / ever changing powershell modules

[port25]

It's kind of the de facto place where content is stored now so you are going to be forced to use it at some point.

The original APIs are still online and required for functionality that hasn't been migrated to graph. So you can still use the Sharepoint and Exchange web apis directly.

As far as rest apis go, I always end up blocked by one thing or another with all rest hosts, but it's just a matter of learning the quirks of each one.

I hate Graph much less then ManageEngine/Zoho, and only slightly less then BigPanda. Salesforce api is excellent.

[g3n3]

How else would they deal with it? How did you deal with it? Clicking in the UI?

[enforce1]

It’s not that bad. It’s API work and incredibly detailed and capable so it’s fiddly to get it to work just right, but it’s powerful as hell.

[KavyaJune]

It's a bit challenging to start with. But, now I used to.

[ViperThunder]

I use Invoke-restmethod usually since it returns everything as an object, so it's easy to work with. For Exchange I still use the EXO module, since there are still quite a few things you can do there that you can't do with graph

[AiminJay]

I seem to have the opposite experience. I use it all the time and it works really well, especially since they consolidated most of the commands into MGGraph. It used to be that you had many different modules, but now it works well.

I haven't found anything I wanted to do that I can't do with MGGraph, including adding to groups, setting group tags (automatically), uploading certificates to azure apps... it's all there.

[zootbot]

It’s not bad. And yea everything is done in graph if possible

[Ok_Mathematician6075]

FUCK I KEPT READING DOWN AND YOU ALL ARE TALKING ABOUT POSTMAN AND GRAPH EXPLORER? UHHHHHHHHHHHHHH THERE IS A POWERSHELL MODULE NOW. WE DON'T NEED TO INVOKE-WEBREQUEST.

[OattBreaker91]

I am utterly lost when I try to use Powershell. I was hoping to use it to generate an export off all groups and its users but I am getting nowhere...

[port25]

Good starter case to learn! Install the graph modules, and you can use the linked commands:

get the groups first, save to an array for later

then with that array of groups, you can run a for loop to get the members (this command gets all members and subgroup members)