Forum Widgets
Latest Discussions
What is the Office Graph?
Office Graph - the intelligent fabric to Office 365 data The Office Graph represents a collection of content and activity, and the relationships between them that happen across the entire Office suite. From email, social conversations, and meetings, to documents in SharePoint and OneDrive, the Office Graph maps the relationships among people and information, and acts as the foundation for Office experiences that are more relevant and personalized to each individual. The Office Graph uses sophisticated machine learning techniques to connect people to the relevant content, conversations and people around them. Office Graph has mapped over billions actions and interactions within Office 365, making it clear that organizations have been sitting on an untapped gold mine of business value. As it continues to analyze relationships and deliver insights from across the tools people use at work every day, it will enable experiences that go above and beyond search and discovery. Going forward, the Office Graph will continue to evolve and deliver increasingly rich insights in Office 365, and incorporate support for extensibility to reach beyond Office 365.
Get Accesstoken from Connect-MgGraph
Hello there I am using the PowerShell Graph SDK and connecting using the connect-mggraph cmdlet to authenticate to Azure (manual Login). I am assuming, this cmdlet somehow creates something like a temporary app registration and uses this for every further action. Now my question is, if I can somehow get to the access token that the SDK is using on behalf of my User. I then want to make calls to the Graph API with the invoke-restMethod cmdlet
SDK command error - "The input is not a valid Base-64 string..."
Whenever I perform ANY SDK command (i.e. get-Mguser, invoke-MgGraphrequest), I receive the following error. Example 1: Get-MgUser : The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters. At line:2 char:1 + Get-MgUser -Filter "userPrincipalName eq '$UPN'" + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Get-MgUser_List1], FormatException + FullyQualifiedErrorId : Microsoft.Graph.PowerShell.Cmdlets.GetMgUser_List1 Example2: Invoke-MgGraphRequest : The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters. At line:4 char:14 + ... response = (Invoke-MgGraphRequest -Uri $uri -Headers $headers -Method ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [Invoke-MgGraphRequest], FormatException + FullyQualifiedErrorId : NotSpecified,Microsoft.Graph.PowerShell.Authentication.Cmdlets.InvokeMgGraphRequest I am able to perform connect-mggraph and obtain the -scopes needed. I have done the following (and searched for the past few days): Executed VSCode/Poweshell ISE/pwsh.exe with Administrator privs Removed microsoft.graph modules and reinstalled version 1.10 I do not recall when this error began, but it's probably within the past week. I'm using Graph Explorer without error of course. I've had 2 Windows 10 updates on 6/20/2022. KB5014699 and Servicing Stack 10.0.19401.1737. I realize "It works on my machine. What did you do to yours" is the most common answer. 🙂 Any guidance, workaround, solutions to try would be most welcome.
Could not load file or assembly 'Microsoft.Graph.Authentication, Version=1.3.1.0
Hi All, not able to run Graph powershell cmdlet post updating. getting below error: New-MgUserAuthenticationPhoneMethod : Could not load file or assembly 'Microsoft.Graph.Authentication, Version=1.3.1.0, Culture=neutral, PublicKeyToken=ASFFFSSFFF' or one of its dependencies. The system cannot find the file specified. At line:1 char:1 + New-MgUserAuthenticationPhoneMethod + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [New-MgUserAuthe..._CreateExpanded], FileNotFoundException + FullyQualifiedErrorId : Microsoft.Graph.PowerShell.Cmdlets.NewMgUserAuthenticationPhoneMethod_CreateExpandedAuthenticate to Connect-MSGraph with PowerShell
Let me preface this question by stating I may be misunderstanding how this is supposed to work. I'm writing a PowerShell script and need to be able to connect to MS Graph to use Intune Graph. I'm running the following: $authparams = @{ ClientId = 'appID' TenantId = 'tenantID' ClientSecret = ('appSecret' | ConvertTo-SecureString -AsPlainText -Force) } $token = Get-MsalToken @authparams $authorizationHeader = @{ Authorization = $token.CreateAuthorizationHeader() } $requestURL = "https://graph.microsoft.com/beta/deviceManagement/managedDevices" Invoke-RestMethod -Uri $requestURL -Headers $authorizationHeader Which comes back successful, but when I run a cmd, for example Get-IntuneMangedDevice , it returns Get-IntuneManagedDevice : Not authenticated. Please use the "Connect-MSGraph" command to authenticate. At line:1 char:1 + Get-IntuneManagedDevice + ~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : AuthenticationError: (:) [Get-DeviceManagement_ManagedDevices], InvalidOperationException + FullyQualifiedErrorId : PowerShellGraphSDK_NotAuthenticated,Microsoft.Intune.PowerShellGraphSDK.PowerShellCmdlets.Get_DeviceManagement_ManagedDevices I thought the first bit of code was authenticating? Am I misunderstanding how this works?Microsoft Graph - Don't Get Throttled!
The Microsoft Graph endpoint is normally highly performant. The infrastructure behind Microsoft 365 will allocate computing resources based on demand to ensure that periods of high traffic levels do not result in degraded performance. In addition to dynamic scaling of resources, another mechanism that Microsoft uses is throttling. If you make too many requests then you will start to get HTTP 429 (too many requests) response codes returned. Not all resources are metered and while this initially applied just to the Outlook APIs but we can assume that more resources will be metered over time. How many requests is "too many"? So the obvious question is: what is the definition of "too many requests?". The answer to this is that you will get throttled if you make a number of requests that would be detrimental to the service as a whole, which isn't actually that helpful. A figure that has been stated publicly is 10,000 requests in a 10-minute period. This applies on a per user and per application ID basis. So you could make 10,000 requests on behalf of each user or group in your tenant in a 10-minute period before triggering the throttle, and if you exceed the threshold for a particular user then it is only that user that gets throttled. If you are using app-only permissions then that counts as a single user. This is all well and good, but for practical purposes you have to accept that these rules could change at any time, and in addition you could well find that a lower threshold kicks in if the service is becoming overloaded for whatever reason. You might also find you get throttled if you make a large number of requests across your tenant, the 'rules' above notwithstanding. The reality is that unless you are making a small number of requests, you should design your application on the assumption that you could get a 429 response at any time and build in logic to deal gracefully with that situation when it arises. If your application is throttled you will get a Retry-After response header in addition to the 429 response code, telling you the number of seconds your application needs to wait before making more requests. You also get a descriptive Rate-Limit-Reason header (I hesitate to call it an error message) which you probably will want to log rather than show to a user. Obviously you will want your app to wait for the Retry-After period before making another request, otherwise you will just get more 429s and probably extend the throttling period even further. Avoiding Throttling Clearly it is preferable not to be throttled in order to keep your application performant. There are a number of strategies you can use: Don't do automatic retries as these will accumulate requests against any throttling limit. Retrieve multiple items in one request, e.g. get a page of list items rather than retrieving individually, and use $select to avoid getting properties you don't need to keep the payload down. Increase the value of $top to get larger pages (default is 10 but maximum is 1000) Cache data locally where needed to avoid re-fetching data, while being careful not to breach data privacy, retention policies and terms of use of the Microsoft Graph Use webhook notifications rather than polling requests to detect changes (you can also use delta queries to reduce the response payload). Use JSON batching to combine multiple requests into a single batch request. You should think of the Retry-After period as a recommendation. If you re-try the request after the Retry-After time has elapsed it is still possible that you will get a 429 response. This means that throttling is still in effect. In this case you should again wait for the (possibly updated) Retry-After period and try again, repeating this process until the request succeeds. It is worth noting that not all of the Microsoft Graph APIs provide a Retry-After header. It is possible for an API to have throttling implemented but not yet support the Retry-After header. In this case a strategy would be to have an initial wait period and keep increasing it exponentially with each 429 response. More guidance is provided in the Microsoft Graph documentation. Microsoft Graph Data Connect The Microsoft Graph API is designed for transactional access to Microsoft 365 data on a user-by-user basis. Some applications really require bulk access to data, for example aggregation of data across a tenant, fraud detection, analysing resource utilization and efficiency or building organizational directories, to name a few use cases. Typically these types of processing occur on a scheduled basis, for example every night. In this case the Microsoft Graph API endpoint is a very inefficient way of doing this and the application is likely to encounter throttling limits. A better solution in this case is to use a new feature (currently in preview at the time of writing) called Microsoft Graph Data Connect. It allows you to get at the same data that's available through Microsoft Graph APIs (currently only a limited subset is available), but in a scalable way. It also allows you to build sophisticated analysis pipelines using tools like Azure Data Factory. All this processing occurs within the Azure data centre for better data protection. For more information see the Microsoft Graph Data Connect documentation. More articles on my blog.Get-MgProfile : The term 'Get-MgProfile' is not recognized as the name of a cmdlet, function, script
Hi everyone, The cmdlet Get-MgProfile is no longer available after updating to v2.1.0 Even the link is no longer available: https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.people/get-mguserprofile What is the replacement Graph SDK cmdlet to get the existing Microsoft Graph PowerShell SDK connection profile name? Thanks in advance.
