Exchange Admin Improvements Announced at Microsoft Ignite 2019

Published Nov 05 2019 06:00 AM 40.8K Views

Today at Microsoft Ignite in Orlando we announced several changes that we hope will help Exchange Online Administrators get their admin tasks completed more efficiently and effectively. We’re bringing joy into Admin, one command or click at a time.

A New Exchange Admin Center for Exchange Online

Exchange Admin Center (EAC) is the web-based management console for managing Exchange. The current EAC provides has an ‘well-worn look and feel’ (some might say retro). Some of the other admin portals (SharePoint, Security and Compliance are just two examples) have moved to our latest technology already with admin experiences that are more aligned with the overall M365 admin experience.

It’s now time for EAC to join the party. We’ve built the beginnings of a new modern experience in line with those newer M365 admin portals and though it’s not at all fully functional you can try it now just by browsing to and logging in which your Exchange/Tenant admin credentials.

We think the new portal provides lots of advantages. Aside from simply being more intuitive and coherent with other M365 admin portals, the modern look and feel of the portal make the administration experience simple and fast. Here are some benefits of the new EAC. 

Simple mailbox management: The new EAC provides a simple mailbox management experience. The user and shared mailbox management experiences are now merged and the mailbox list and properties are available on the same page.


Personalized dashboard and reports for Exchange admin: Exchange admins now have a personalized home page where they can drag and drop reports they use often and see the reports directly on their home page. They can select date ranges and various pivots to make them more relevant.


Improved Migration:  The Exchange and G Suite migration capabilities are now simple wizard-based experiences.


Staying on the subject of G Suite migrations for a moment, our G Suite migration experience is now even better! The newest update to our G Suite migration toolset switches migration of Mail (this is new), Calendar and Contact data to use Google’s REST APIs.

This means the 2GB per user per day restriction we previously had when using IMAP for Mail data migration will no longer apply!

This has been the #1 customer ask since we released the v1 of our REST-based migration tools; as we all know that 2GB per user per day just doesn’t cut it for customers with large mailboxes to move! The velocity of your migration (per day) now depends upon the quota units available for the Google REST APIs in your Google tenant.

There are no changes to the existing UI or PowerShell Cmdlets to take advantage of these changes. If you do have migrations in progress, don’t worry. Batches created or started after this change has been activated use the REST APIs. Those that were in progress before the changes will continue to finish migrating using IMAP, Google Calendar API and Google Contacts API unless they are stopped/removed and recreated.

So if you are an Exchange Admin, go try out this new experience today at and share your feedback with EAC product team by clicking the “Give Feedback” button within the portal. We really want to hear your feedback and plan to continue evolving the new portal based on that feedback.

Please note that the existing EAC and the new EAC will run side by side throughout this development cycle.

Faster and More Reliable Exchange Online PowerShell Cmdlets

We know how painful it can be to use Exchange Online PowerShell to read and make changes to large number of Exchange objects. Today we announced some improvements that we hope will change your day to day Exchange management experience for the better. We think you should spend less of your valuable time writing complex scripts to handle error cases and spend more time getting actual work done, making configuration changes, analyzing results and making decisions.

The New Exchange Online Management Cmdlets (we’re referring to these as V2 Cmdlets) are considerably more reliable and much faster than those you use today. They recover and retry from failure on their own and provide much better overall performance.

How much faster? Managing our own Microsoft tenant, which contains some 300k+ mailboxes – we saw results an average of 4-8X faster, with vastly improved reliability. Your mileage will vary, but we think you’re really going to notice the difference and be very happy with the results.

So, what changed? And what was announced today at Microsoft Ignite?

The EXO V2 Cmdlets were changed to use the REST API. And the big news is they are available today. We intend for these new Cmdlets to replace their older, less efficient equivalents, as time goes along. We do still have the original Cmdlets available in the EXO V2 module for backwards compatibility, and have no plans to remove them at this time.

The new Cmdlets in the EXO V2 module are listed in the following table, alongside their existing counterparts. The most obvious change is simply the addition of ‘EXO’ to the Cmdlet name. But there’s a lot more going on that that.

New cmdlet in the EXO V2 module

Older related cmdlet


Connect-EXOPSSession   or   New-PSSession



















The V2 Cmdlets have also been designed to provide the same core functionality of their V1 equivalents, but they behave a bit differently. Some of the key differences are;  

  • V2 Cmdlets don’t return all properties by default. Instead, they return a minimum set of properties by default. If you want to get additional properties, you need to pass it as input parameter. Read more here.
  • The Identity parameter doesn’t accept name or alias. It only accepts UserPrincipalName or AAD ObjectID.

What are Some of the Benefits of new V2 Cmdlets?

We solve the reliability problems with PowerShell because we made the Cmdlets stateless with no affinity to the connected server. We also added pagination support to enable retry and resume from the point of last failure. We improve performance by defaulting to a min-set of objects returned, rather than the entire set we return today. We do, of course, support adding more properties during Cmdlet call.

This new module is backwards compatible. It contains 10 new EXO Cmdlets as well as all 700 or so older Remote PowerShell Cmdlets and another great thing is there is a single connect function to access all Cmdlets.

We believe this module is more suitable for automation scenarios, you can install, update & maintain via standard PowerShell Gallery Cmdlets. We also want to call out that this module supports Modern Auth (i.e. OAuth) only, it doesn’t support Basic Auth.

And one final big change is that it invokes multi-threading automatically to provide better performance. Iteration in PowerShell can be achieved using either for-each looping or Piping.  We recommend piping as the module invokes multiple threads when certain Cmdlets are piped. See the example below.

So How Do You Try Out These New Cmdlets?

Install the new EXO PowerShell module from here. See additional instructions here.


Simply use Connect-ExchangeOnline to use all the available Cmdlets.





$Credential = Get-Credential
Connect-ExchangeOnline -Credential $Credential -ShowProgress $true





Usage Example

Remote PowerShell (V1 Cmdlet) – A For Each loop. 





$mailbox = Get-Mailbox -ResultSize 1000
foreach ($user in $mailbox) {
	Get-MailboxStatistics $





The EXO PowerShell V2 version of above scenario using piping.





Get-EXOMailbox -ResultSize 1000 -PropertySets StatisticsSeed  | Get-EXOMailboxStatistics





The example above retrieves a specific set of properties specified under bucket “StatisticsSeed” which when piped to Get-EXOMailboxStatistics provides the best performance when retrieving mailbox statistics.


We’re very happy to be announcing these improvements today and we really hope you enjoy trying out these new capabilities. Please do share your feedback either in EAC directly, here on the post or in the Exchange Tech Community.

The Exchange Admin and Migration Teams

Senior Member
The link ( for the additional properties of the V2 does not work. Gives "We are sorry, the page is forbidden."
Occasional Contributor

There should exist a Disconnect-ExchangeOnline cmdlet?

Or is not a best practice to disconnect from the session?

Is there a limit?

@bobsys  - thanks for the catch - fixed.


Hi everyone


Sorry for the issue in above link. The same has been updated. 


Here is the correct link, FYI -

For the SSO experience:

Connect-ExchangeOnline -UserPrincipalName



New Contributor



No news about AADConnect in hybrid without any Exchange Server for management ? 

Regular Contributor

It finally happened. Praise the law.


@null nullWhat do you mean?

New Contributor

@Daniel Niccoli After Exchange hybrid deployment, if an organization plan to keep AADConnect synchronization, all Exchange Online modifications cannot be perform throught Office 365 admin portal but from the source authority (based on-prem). So, recommandation is to keep on last Exchange server on-prem for management purpose.

At the last Ignite, there were rumors about a new way that allow to keep AADConnect and be able to manage Exchange attribute online but no announcement was made... I was hooping a good news for this year on this topic :)

Regular Contributor

@null null 

Oh, I see. Personally, I don't have high hopes for it. The keynote made it pretty clear that unless you go Azure Arc, the focus is on cloud-only.


Anyway, there aren't actually that many Active Directory attributes necessary to manage that stuff. The mailNickname attribute is the Exchange Alias and proxyAddresses manage the smtp addresses. I'm not sure if you actually need any other attribute.

Occasional Visitor

Keen to try the new PowerShell Cmdlets, how does it work with MFA?


New-ExoPSSession : AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '0000000XXX...'.

PS I'm still getting "page is forbidden" for the explainer

Senior Member

We need the ability to run PowerShell scripts automatically in the backend, not by signing in manually. Is there a way to use Graph token auth as is available for managing CSP?


Hi guys!


I'm trying to test the new cmdlet agains a large group of users where commonly the classic query runs out of memory


Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Get-MailboxFolderStatistics -FolderScope RecoverableItems | where{$_.Identity -like "*\Recoverable Items" -and $_.FolderAndSubfolderSize -ge 90GB}| Export-CSV -path XXXX


Trying the same but using the Get-EXO* version I'm getting a conversion error.


Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Get-EXOMailboxFolderStatistics -FolderScope RecoverableItems | where{$_.Identity -like "*\Recoverable Items" -and $_.FolderAndSubfolderSize -ge 90GB}| Export-CSV -path XXXX


"Could not compare "682 KB (698,404 bytes)" to "96636764160". Error: "Cannot convert value "96636764160" to type "Microsoft.Exchange.Management.RestApiClient.Unlimited`1[Microsoft.Exchange.Management.RestApiClient.ByteQuantifiedSize]". Error: "Operation is not valid due to the current state of the object."" At line:1 char:155 + ... ems | where{$_.Identity -like "*\Recoverable Items" -and $_.FolderAnd ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : ComparisonFailure "


The classic query works but the new one doesn't. Any recommendation?







Occasional Contributor

@Chris_AguileraYou were supposed to use the new cmdlet on the first command too, right?


Get-EXOMailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Get-EXOMailboxFolderStatistics -FolderScope RecoverableItems | where{$_.Identity -like "*\Recoverable Items" -and $_.FolderAndSubfolderSize -ge 90GB} | Export-CSV -path XXXX


And the error that you are receiving is about that comparison you are doing "-ge 90GB".

Occasional Contributor

Is there no way to return all the mailbox properties anymore?

If I use Get-Mailbox -Identity | fl *, it returned all properties of that mailbox.

I have tried to do it using Get-EXOMailbox and no joy...


Also, again with the same question as before. Since there is no Disconnect-ExchangeOnline cmdlet, the best way to close the connection is closing PowerShell? There are no limit of active sessions for the organization?


@Vandrey Trindade You can get all the properties by Using PropertySets parameter. Here is the syntax - 


Get-EXOMailbox -PropetySets All 


Please read more about this here -


@Vandrey Trindade 


Connect-ExchangeOnline creates a new PowerShell session for RPS cmdlets as well as setting up authentication for new EXO Cmdlets.

You can use below cmdlet to disconnect the session - 


Get-PSSession | Remove-PSSession


@Peter Vogl  - Enabling support for automation using the new EXO PowerShell V2 module is a work in progress and not a supported feature yet.

Occasional Contributor


Thanks for replying.

The link doesn't have the "-PropetySets All" example, I've read the entire article.

As for the "Get-PSSession | Remove-PSSession", I've ran it too. And I'm still able to get the mailbox properties running the Get-EXOMailbox cmdlet...

So I don't think that it's really disconnecting from the session....

Regular Contributor

@navgupta"Work in Progress" is good enough for now :)


@Vandrey Trindade - The page I shared explains the concept of PropertySets and also redirects to the list of PropertySets available for each cmdlet which is this page -


I take your feedback and we will add an example of PropertySets All.


However, I discourage you to use it as it will make the cmdlet slow and you should always use either default (Minimum set) or any other PropertySets or Properties parameter.


@Chris S  - Thank you for trying out the new cmdlets and sharing feedback. We are looking at this and we might need more info from you on this


Can you send the error details on email to ?

Occasional Contributor


Thanks once again.

I only use the full properties when I'm creating scripts. To check what I need.


What about the Remove-PSSession not disconnecting the session... It is correct?

Established Member

Very helpful improvements.

works well.

Some feedback:

1) When i saw that there is no positional parameter set, i was like "Again!", because it was see in AzureAD cmdlets.

Get-EXOMailbox - fails, error: A positional parameter cannot be found that accepts argument ''.

Please correct this, at least for Identity parameter, have the positional parameter feature.


2) -PropertySets All also works.

3) Get-EXOMailbox -PropertySet : * wild card is not working - document says: You can specify multiple values separated by commas. Wildcards ( * ) are supported.



Occasional Contributor

Is the Rest API that these new cmdlets use public or documented somewhere? And if not, will they be in the future?


@rfoust The REST API that these cmdlets use are not public. As of now, we don't have any plans to make to APIs publicly available.


@techiesahal  Thanks for your feedback. Support for positional parameters will be available in the coming version releases of the EXO PS V2 Module.

Senior Member

I am seeing some oddities with how sign in events from the exo v2 library are reported in Azure AD sign in logs. They are reported as client="Unknown". And while CA policies do appear to be correctly evaluated to block or present MFA challenges, these evaluations and outcomes are not reported in the sign in logs.

Regular Visitor

Is there a plan to add "Groups" to the new admin center?

New Contributor

The v2 Cmdlets are working great for me from Windows PowerShell... Much quicker. :cool:


However, I cannot get it to work in PowerShell 7, Preview 5.  There error I get is:

Line 366

"Could not load type 'System.Security.Cryptography.SHA256Cng' from assembly 'System.Core,
| Version=, Culture=neutral, PublicKeyToken=...."
This happens when using either of the authentication options (-Credential or -UserPrincipalName).
Is there a prerequisite I'm missing, or is this not working in the new PowerShell yet?


Hi @Ryan Van Cleave  


There is no extra requirement. Support for PS6 and PS7 is still a work in progress for EXO PowerShell V2 Module.

Occasional Visitor

With reference also to  , seeing strange behaviour when using get-exomailbox -inactivemailboxonly ; this is only returning a small number of our inactive mailboxes. get-mailbox command returns significantly higher numbers. 

I can confirm that behavior @warrenstark . 

P.S.  I miss the positional parameter.... :( 

Regular Contributor

@The_Exchange_Team Are there any features that will never come to the new EAC? For example, Retention Policies, will you rather redirect to use the Securit & Compliance portal for this? Just so I tell my customers the right thing since they tend to stick configuring some things like they’ve always done :)


@Satguru_Sharma  Yes. Very soon we'll be adding Groups and Contacts as a part of the Recipients experience in the new Admin Center.


@Jonas Back We are in the process of closing the scope of what all features will totally light up in S&C and not in EAC. Once the scope is closed we will intimate the same to all customers accordingly.

Regular Contributor

Yesterday a colleague tried to use the new Exchange Online module on macOS. It turned out, that it is not supported. Any plans to make the module it available to PowerShell on macOS in the future? PowerShell can already be used on Windows, macOS and Linux. But when the modules Microsoft is developing are not cross-platform, than it isn't of much help when you're an Office 365 / Microsoft 365 or Azure admin.

Regular Contributor

@Daniel Niccoli I know this doesn't help the way you want but I recommend checking out the Azure Cloud Shell. Makes it easy and remove the dependency of these PS modules.

Occasional Contributor

I am having problems with the Get-EXOMobileDeviceStatistics

Getting this error when trying to pull data for a user with multiple devices


Get-EXOMobileDeviceStatistics : Error while querying REST service. HttpStatusCode=500 ErrorMessage={"error":{"code":"InternalServerError","message":"The operation couldn't be
performed because '' couldn't be found.","innererror":{"message":"The operation couldn't be performed because '' couldn't
be found.","type":"Microsoft.Exchange.Configuration.Authorization.CmdletAccessDeniedException"}}} is the account I use to create PowerShell session, it does exist :smile:


The same operation works with fine with Get-MobileDeviceStatistics


@Grzegorz Wierzbicki  We are currently looking into this issue. It looks like it is happening for a select few users in a tenant. 


Can you please send an email to and we can discuss further as we might need some logs ? 

Occasional Contributor


I sent the email :smile:

Frequent Contributor

@Grzegorz Wierzbicki @navgupta 


I had this same issue with the Get-EXOMailboxFolderStatistics cmdlet.  What I found was that using the mailbox's Guid for the -Identity parameter would produce this problem.  When I instead used the mailbox's ExternalDirectoryObjectId value for the -Identity parameter, the problem went away.


This tells the issue here has to do with the new Identity parameter.  I hope this information can be helpful in resolving not only Get-EXOMailboxFolderStatistics, but also Get-EXOMobileDeviceStatistics.  I'm sure it's slightly different though seeing as the -Identity parameter on the latter would (I assume) be expecting the mobile device's ID, not a user's, so my solution doesn't quite seem to transfer over in this case.

Frequent Contributor

I don't know if anyone still watches these comments, and I've emailed the feedback address about this as well.  I've noticed that the new cmdlets:


  • Don't return any nested properties (i.e. for GrantSendOnBehalfTo from Get-EXOMailbox, or User from Get-EXOMailboxPermission, and so on).
  • Can't be used with Invoke-Command.

The 2nd point is pretty obvious, EXO servers wouldn't use the REST service to query themselves.  However I mention it because Invoke-Command is by far superior until these commands start to offer the nest properties in their outputs.  If returning nested properties won't be allowed, then the value returned for the flattened object properties where the value needs to be unique, should be unique values.


A perfect example is the GrantSendOnBehalfTo property.  Exchange Online will return the display names of users in that property, which is not a guaranteed-unique property, and is therefore useless in factual reporting.  This is a no-brainer to me, and I'm not sure why or how it was missed.


I originally found it difficult when I realized PowerShell remoting was such a downgrade compared to using the Exchange Management Shell (in this specific regard), but then I got used to Invoke-Command.  I now fear the new cmdlets are going to be another downgrade for admins.  My favorite thing to work on is Exchange, but it is getting harder and harder to not get caught up on these kinds of misses which seem like design choices or something.  I understand there is internet connectivity and server performance to deal with here, but stripping the product of valuable functionality seems like the wrong direction to be taking it.

Frequent Contributor

Here I am, back again with yet more complaints (so sorry, but I just can't get past these issues).  This one is to do with the new Exchange Admin Center, under Recipients > Resources > with a resource mailbox selected > Resource Delegates.


Resource Delegates need Send on Behalf, so they can respond with accept/tentative/decline on forwarded meeting requests (when forwarding to delegates is set to True).  What they DON'T need is FullAccess and Send-As.  At best, they would need the Editor permission on JUST the Calendar.


The new interface shows us that now even the Exchange developers are confusing this, and now we have "Resource Delegates" being confused with FullAccess and Send-As permissions.  What this will do, is tell Admins and therefore users, that "Resource Delegates" should have FullAccess and Send-As, but in reality we still know here and now that this is wrong and bad.  It's a big huge error that needs to be corrected.  What you will end up doing is setting the path to bad resource mailbox practices world-wide.  Meetings will get created from the Resource mailboxes themselves, and the resources will end up being the Organizer of meetings (which is very bad, just look at the "Important" note here - Create and manage room mailboxes).


Last thing - where the heck are the GUI options for AllBookInPolicy, BookInPolicy, AllRequestInPolicy, RequestInPolicy ?  These have been missing since (and including) Exchange 2013.  It tells me that you forgot about these, or are just boycotting them in favor of FullAccess and Send-As, thinking they accomplish the same things.  They don't, this is just bad bad bad.  Can't state it enough, it's bad.  It's a real problem that will spread all around the world and filthy up Exchange Online deployments everywhere (on-premises deployments too).


The other issue with FullAccess on resources is that now the users with FullAccess will by default have AutoMapping enabled, and their precious cycles in Outlook will be used up.  Not only in Outlook though, also their quota against their assigned throttling policy will be needlessly used up.  And not only that, just a huge waste of time and resource for these users accessing/synchronizing the other folders in the resource mailboxes, when all these "Resource Delegates" need is, like I said - at best, Editor access to the Calendar.


This one is just as bad (actually way worse) as the issues I mentioned in my earlier reply.  You are teeing admins and users up for very bad practices, against even your own recommendations.  This is not good.

Regular Contributor

@Jeremy BradshawI haven't had a look at the new UI yet, but ... Wow! That is extremely careless on Microsoft's part. But also something that I see more and more, looking at their produts. Developers "improving" functionality they have no idea how it works or why it's working in a certain way.


You are 100 % correct with every of your statements and that is exactly how we run our 700 people company, too. If that makes it to production and microsoft slashes the current admin interfaces, we'd be extremely unhappy!


I am having a problem with the Get-EXOMailboxStatistics command.  It is working intermittently.  I run

Get-EXOMailboxStatistics -Identity $MB.ExchangeGuid -Archive

and get output. If I run the same command again I get: 

Get-EXOMailboxStatistics -identity $MB.ExchangeGuid -Archive

Get-EXOMailboxStatistics : An error occurred while processing this request..
At line:1 char:1
+ Get-EXOMailboxStatistics -identity $MB.ExchangeGuid -Archive
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ProtocolError: (:) [Get-EXOMailboxStatistics], Exception
    + FullyQualifiedErrorId : One or more errors occurred.,Microsoft.Exchange.Management.RestApiClient.GetExoMailboxStatistics





Senior Member

@maryh2020Have you tried @Jeremy Bradshaw's comment above regarding the use of the ExternalDirectoryObjectId as the Identity for Get-EXOMailboxStatistics to see if that fixes the issue? I'm having the exact issue as yours as I'm querying around 35000 mailboxes and just read Jeremy's comment. I'm going to try using that in my script now and see if it fixes anything. Jeremy, let us know if you have additional comments on this. Thanks.

Frequent Contributor

@maryh2020 @Kevin Mychal Ong I do have something to add.  It is this page:


Note that -Identity takes either UserPrincipalName or ExternalDirectoryObjectID.


There is a new parameter (I'm not sure exactly which version introduced it) -ExchangeGuid which takes the ExchangeGuid.  So you can either change what you're supplying for Identity, or use -ExchangeGuid instead of -Identity.


Make sure to keep updating the new EXO module, it gets a new version quite often, and the changes/fixes will be plentiful.

Senior Member

Yes, I checked that link yesterday and noticed the new ExchangeGuid parameter. Have you confirmed using that parameter fixes the issue though? When I encountered the issue, I was piping the results of Get-EXOMailbox to Get-EXOMailboxStatistics.

Frequent Contributor

@Kevin Mychal Ong I was only thinking of @maryh2020 when I mentioned about the -ExchangeGuid parameter.


I just tested with Get-EXOMailbox | Get-EXOMailboxStatistics and it works for me, I'm using the latest version - 0.4578.0.


On the Get-EXOMailboxStatistics docs page, it shows "True (ByPropertyName)" for pipeline input for -Identity, -DatabaseGuid, -ExchangeGuid, and -UserPrincipalName, so any objects being piped in that have any of these properties on them (and with valid values of course) should work.  However, check this out:


>$ExchGuids = Get-EXOMailbox -Properties ExchangeGuid | select ExchangeGuid
>$ExchGuids | Get-EXOMailboxStatistics

Notice how I've made sure to get the ExchangeGuid property in my output from Get-EXOMailbox (using -Properties ExchangeGuid)?  That is a must in order to successfully execute the second command, because ExchangeGuid isn't a default property in the output of Get-EXOMailbox.


In case it's of any help, feel free to look at my script Get-EXOMailboxTrustee.ps1 (  I am not piping into any of the new cmdlets in that script but I'm using Get-EXOMailbox, Get-EXOMailboxPermission, Get-EXOMailboxFolderPermission, and Get-EXORecipientPermission.  Since all the new cmdlets are going to be changing for a while it's likely that script will change too.  But anyway, just wanted to share that.


So we have working pipeline for several properties and we can also go no-pipe and use the same properties manually instead, and in a foreach loop if needed.

Senior Member

@Jeremy Bradshaw, yes that's exactly what I'm doing. I can use either of the Guid parameters to pipe into Get-EXOMailboxStatistics. I know that Get-EXOMailboxStatistics shows "True (ByPropertyName)" for pipeline input for -Identity but if you do a Trace-Command against Get-EXOMailbox -PropertySets MinimumSeed | Select ExternalDirectoryObjectId | Get-EXOMailboxStatistics, it's weird that the ExternalDirectoryObjectId gets converted from Guid to String and bound to the Identity parameter. That means that the Identity parameter accepts pipeline input by PropertyName AND Value. I'm not sure if this is just a Get-Help documentation error for the Identity parameter or something.

Version history
Last update:
‎Nov 05 2019 09:46 AM
Updated by: