Not all SharePoint modules are currently generated.

I have tons of use cases for running Powershell scripts in Azure Functions. What I do at the moment is obtain my Managed Identity bearer token (which I have previously granted permissions to) and the use the Invoke-WebRequest commandlet against the raw Graph API.
It would be great if as part of the Connect commandlet I was able to either pass in my already obtained bearer token, or even maybe ask the Connect commandlet to go get it for me.
AB#5613

Consider adding a cmdlet to list the current scopes and/or the token. Will be useful for troubleshooting purposes and avoiding 401 errors.

Hi!
First off great job on this new PS "sdk", I think it looks super promising!
Now the question: I'm trying to upload the user's picture, which I think will be a common scenarios for IT pros around the world.
I'm now sure how I should pass the photo binaries however, I've tried something like that and a few variations but it doesn't seem to be working.

update-userphoto -UserId ef1c916a-3135-4417-ba27-8eb7bd084193 -BodyParameter ([System.IO.File]::ReadAllBytes("C:\Users\vince\Desktop\00003IMG_00003_BURST20170402115324.jpg"))

At this point I'm not sure whether I missed something (hence the question) or whether this feature is currently missing in the SDK.
I'm running the beta SDK, updated/installed today.
Thanks for the help!

Currently AutoREST configuration is done at the global project level. This is not going to scale. We would like to create config files for each module so that individual teams can control the generation of the cmdlets for their service.

With Microsoft Graph v1.0, $ prefix is only optional for a subset of the API. We should therefore ALWAYS include the $ prefix in all OData query parameters.

Ref: https://docs.microsoft.com/en-us/graph/query-parameters

This repo is missing a License. Please license it using Microsoft Open Source Standard Licensing 😊

So this one is on me, but can we have proper error messages and some validation on the Scopes parameter? Here's what happens if I mistype the scope level (Mail.Read.All instead of Mail.Read):

Of course if I remove it or fix the typo it works fine.

Better error handling throughout the module is needed IMO...

Due to the multiple module constraint we will have duplicate cmdlets for shared types.

Any particular reason why you are storing the tokens in unencrypted form on the hard drive? Hardly the best security practice.

I understand that you might be using this for ensuring session longevity and such, but at least store them as secure string, or use the cred man or something. On a related note, why arent you leveraging the ADAL/MSAL token cache?

AB#4594

AutoREST will not be able to generate a single module for all of the Graph API and therefore we will need to create smaller modules and then aggregate.

Hi,
when running Connect-Graph I am getting an error:

Connect-Graph : AADSTS50196: The server terminated an operation because it encountered a loop while processing a request

I am using proxy

[system.net.webrequest]::defaultwebproxy = new-object system.net.webproxy('http://proxy.fqdn.com:8080')
[system.net.webrequest]::defaultwebproxy.credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials
[system.net.webrequest]::defaultwebproxy.BypassProxyOnLocal = $true

Suggestion to add DefaultDisplayPropertySet for objects returned from Microsoft Graph. Currently tested commands have all properties displayed in table format, many of which are not populated with any information. This requires use of "| select-object -property propA, propB, etc." (or "| format-list ...") to display the information desired.

Example commands tested: Get-Group, Get-User.

For reference implementation:
PowerShell - Defining Default Member Sets for Objects

PowerShell - Extending properties for obejcts - Property Sets

AB#4595

Currently, some generated cmdlets in *.Actions & *.Functions modules have duplicate names with cmdlets from other modules. This results in a cmdlet name conflict when generating the roll-up module.
e.g.
Get-Site in Sites.Site module and Get-Site in Sites.Functions module.

Related to Azure/autorest.powershell#517

Steps to repro:

Call Connect-Graph and sign in.
Call Disconnect-Graph
Call Connect-Graph again.

Observed behavior

You will automatically get logged in and the old token cache will be recreated on disk.

Expected behavior

You will be asked to log in again.

If you close the PowerShell terminal after doing Disconnect-Graph then next time you open the PowerShell window Connect-Graph will work as normal. I think we just need to re-create the Application upon doing Disconnect-Graph.

Just FYI, if there are actually plans to make a Graph SDK / module for PowerShell, I am super stoked. :D 👍

If the device code flow fails for some reason, it leaves the powershell window in a hung state that there seems to be no way of recovering from.

Related to Azure/autorest.powershell#517

Add support for generation beta modules by specifying graphVersion query option to Graph Slice service. The generated Graph beta module names should be in the form of Microsoft.Graph.Beta.*.

Currently, all cmdlets return all properties of their response object as part of their response. This forces most customers to pipe cmdlet with | select prop1, prop2, just to get common properties like ids, names e.t.c. It would be nice to have the cmdlets return a bare minimum number of useful properties from their response object.

Are there any plans to rename all the commandlets to something more specific to the Graph?

For example instead of Get-User will this commandlet be renamed to something like Get-GraphUser

Apologies if this has been detailed on elsewhere.

As discussed briefly the other day on the call, you should consider adding an unique prefix to all the cmdlets. This will not only make them easier to identify with the module, but avoid clashes with existing cmdlets. Prime examples being Get-User and Get-Group - both of these are heavily used in Exchange/Exchange Online PowerShell. And since support for Exchange management tasks in the Graph is still non-existent, it's very likely that people will use both the ExO cmdlets and the Graph module in the same PS session.

Considering the sheer number of cmdlets in the module, you're bound to have other duplicates as well.

This makes it difficult to log into a new tenant. It is necessary to delete the token cache to get login prompt again.

Hi, I was testing the steps mentioned here. I was getting several errors and was able to fix them. Reporting them here in case documentation needs to be updated.

Issue 1:
Connect-Graph -ClientId 'ID' -Scopes 'user.read, Calendars.Read, Files.Read'. Based on my tests, I think the TenantID is also needed otherwise, I receive an error.

With TenantID, it succeeded.

Issue 2:
Get-MeMessage -Top 10 -Skip 10 -Select 'Id, Subject, CreatedDateTime' | Format-Table CreatedDateTime, Subject, Id. This example returns your messages, but for this to work, we need to add 'Mail.Read' to the scopes in the previous step. Otherwise, you will get an 'Access Denied' error.

So, to sum up, I needed to run this:
Connect-Graph -ClientId 'ID' -Scopes 'user.read, Calendars.Read, Files.Read, Mail.Read' -TenantID 'tenantID' instead of Connect-Graph -ClientId 'ID' -Scopes 'user.read, Calendars.Read, Files.Read'

Related to #369
AB#7428

ref:

• https://swagger.io/specification/#discriminatorObject
• https://swagger.io/specification/#schemaObject

AB#4988

1. Define infrastructure to add custom cmdlets to generated modules.
2. Add a custom New-GroupMember cmdlet to Groups.DirectoryObject module.

Autorest generator doesn't support anyof keyword. OpenAPI doc corresponding to Graph OData metadata contains usage of anyof keyword to represent nullable fields. This task is to remove anyof keyword from openapi doc to facilitate code generation using Autorest.

The preview modules we release to PowerShell Gallery will be identified using the 0.x.y version number. Unfortunately, PowerShell Gallery doesn't currently support dependencies between modules with the -preview version identifier, so we can't use that.

In which parameter do i define the query parameters?

PS C:\WINDOWS\system32> $calendar = Get-UserCalendar -UserId $Me
PS C:\WINDOWS\system32> Get-UserCalendarView -UserId $Me -CalendarId $calendar.Id
Get-UserCalendarView : This request requires a time window specified by the query string parameters StartDateTime and EndDateTime.
At line:1 char:1
+ Get-UserCalendarView -UserId $Me -CalendarId $calendar.Id
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: ({ UserId = 9ad1...= , Select =  }:<>f__AnonymousType20`8) [Get-UserCalendarView_List], Exception
    + FullyQualifiedErrorId : ErrorInvalidParameter,Microsoft.Graph.PowerShell.Cmdlets.GetUserCalendarView_List

For this request, the query parameters are not part of a filter, so logic tells me not to use the -Filter parameter (?).

Docs for CalendarView

PS C:\WINDOWS\system32> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.18362.145
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.18362.145
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Need to understand and lock on authentication story for powershell modules. There are open questions on application IDs and usage story .

The openapi-getusers.yml file contains these operations but AutoREST processes them fine. When I generate other documents e.g. https://graphslice.azurewebsites.net/$openapi?tags=users.user&style=Powershell it fails.

Suggestion to support specifying the thumbprint of certificate to be used for certificate based authentication. This would be in addition to (or replacing) the option for certificate name. If I'm not mistaken the certificate name could be the same across many different certificates (like a display name) vs. the thumbprint which uniquely identifies the certificate (like an identifier).

Ex. Connect-Graph -ClientId "[clientId]" -TenantId "[tenantId]" -CertificateThumbprint "[certThumbprint]"

Currently $GraphAuthConfigID populates with only the most recently requested scopes during "Connect-Graph" connection. Recommend that during "Connect-Graph" execution to update the $GraphAuthConfigID variable with the cumulative set of scopes returned from the response.

Powershell module generated by autorest has preconfigured httpclient. Plan is to investigate and understand the integration point and integrate dotnet SDK's core module and leverage httpclient with middleware capabilities in powershell modules.

Hi
I'm testing out the msgraph-sdk-powershell and have installed the module. Using powershell 5.1.
I have Registered an App in my Azure and added a certificate that was created based on .\Create-SelfSignedCertificate.ps1 (https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azuread)

When trying to connect I get the following error:

Connect-Graph -ClientId $clientId -TenantId $TenantId -CertificateName "CN=MyCompanyName"

Connect-Graph : Value cannot be null.
Parameter name: certificate
At line:2 char:1
+ Connect-Graph -ClientId $clientId -TenantId $TenantId -CertificateNam ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Connect-Graph], ArgumentNullException
    + FullyQualifiedErrorId : System.ArgumentNullException,Microsoft.Graph.PowerShell.Authentication.Cmdlets.ConnectGraph

I'm doing something wrong:s, but what?

Im able to get information via the app-registration using the
Invoke-RestMethod -Headers $Headers -Uri "https://graph.microsoft.com/v1.0/users/$UserPrincipalName/photo" -Method Get
Which means that the app registration and permissions are ok, perhaps I need to create a certificate another way?

Any tips are welcome!

brgs

Bjørn

e.g.
Get-Group -expand "owners"
Get-Group -expand "members"

These commands fail. The expand parameter is not appearing in the OpenAPI document.

Ideally we should remove all navigation properties that cannot be expanded. They are just cluttering up the model. This should actually be done in the OpenAPI generation step.
AB#6083

Goal is to generate functional powershell module using openapi doc representation of graph apis. We need to document issues which fall in autorest domain vs apislice domain and fix issues which can be fixed by changes in apislice code.

By plugging in a piece of middleware we can intercept the request prior to sending and emit the result to the host. This would be useful for debugging cmdlets.
AB#6242

If you installed the module when it was first released, like I did, you can use this PowerShell to get the latest version of the modules:

Set-PSRepository -Name GraphPowerShell -InstallationPolicy Trusted
Get-InstalledModule -Name "*graph*" | foreach { $b = (find-module $_.name).version ; if ($b -ne $_.version) { Write-host "Updating $($_.name) from $($_.version) to $b" } ; Update-Module -Name $_.name }

tk

Add option to pass a module version and an optional preview number for preview modules during generation process.