Is a little more #PowerShell consistency across Microsoft teams such as @MicrosoftTeams, @microsoftgraph, and @MSFTExchange too much to ask?

Each has a Connect-* cmdlet.

Each supports CBA.

There is no consistency across parameter names or values among the three of them.

1/7
Connecting using CBA with @MicrosoftTeams:

Connect-MicrosoftTeams -CertificateThumbprint $thumbprint -ApplicationId $appId -TenantId $tenantId

(this is the best of the lot, and the example to follow IMHO)

2/7
Connecting using CBA with @microsoftgraph:

Connect-Graph -CertificateThumbprint $thumbprint -ClientId $appId -TenantId $tenantId

A close second, but -ApplicationId would be preferred as a parameter name over -ClientId, to align with how it is named in Azure.

3/7
You can use CBA with @MSFTExchange now as well:

Connect-ExchangeOnline -CertificateThumbprint @thumbprint -AppId $appId -Organization & #39;TenantNameNotId& #39;

Why only accept a tenant name and not an ID?

And can& #39;t we get consistency in the parameter names?

4/7
Prior to modern auth, #PowerShell auth using PSCredential was great, because it was consistent almost everywhere ( @MicrosoftTeams, you& #39;re not supporting -Credential $username properly). With modern auth, we need some cross-team effort, coordinated by @Steve_MSFT& #39;s team.

5/7
Also, some of these support CBA using a certificate file that is not loaded into a store (needed for serverless/shared infrastructure scenarios), but others do not (although support is coming for some). This also needs to be consistent (same file format, same parameters).

6/7
With basic authentication going away fast (and rightly so), and modern auth with certificate-based authentication stepping in quickly, a little effort up front to make sure that #PowerShell remains consistent in this area would go a long way for the community.

Thank you.

7/7
You can follow @Poshoholic.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: