Back to blog

Working with the new Exchange Cmdlets Webinar v2.0 – Q&A’s

May 28, 2020 by Vasil Michev

Exchange Cmdlets being discussed

Last week, myself, Vasil Michev, and my fellow MVP Paul Robichaux held the popular “Working with the new Exchange Cmdlets v2.0” webinar. If you missed the session, you can register anyway to receive an on-demand recording.

The session was well-received with record attendance and over 1000 sign-ups. This monumental response really demonstrated the need for more information amongst the Exchange communityon executing daily administrative tasks.

We always aim to produce the best possible content in our webinars, so we hope you found the information shared in the session useful. The recording, slides, and additional resources have been shared with everyone who signed up, however, if you haven’t received this please get in touch. In this post, we will try to answer some of the questions we couldn’t address online.

Exchange Cmdlets Webinar v2.0 Questions

We’ll start with a question from Barry Irving: “I know that when the cmdlets were released there were issues with paging large datasets and it didn’t return all the data over 1k objects. I’m not sure if that’s been resolved yet?”

Pagination support and bulk data retrieval are core concepts for the REST-based cmdlets, and they work well way beyond the 1k number of results. The default value for the –ResultSize parameter is indeed 1000, but you can run the cmdlet with –ResultSize Unlimited.

That said, early versions of the “V2” Exchange Online PowerShell module didn’t return objects with missing ExternalDirectoryObjectId value, which might be a reason as to why you are not getting the expected results. The module has received multiple bug fixes over the past few months, so make sure you are using a recent version. The latest version of V2 module returns all Exchange objects, even those which don’t have ExternalDirectoryObjectId attribute populated.

And in case you are still seeing such issues, email with additional details, or open a support case once the module goes GA (should be very soon now).

The next question is from Santosh Ramchandra: In the new version, I guess when you do a Get-Mailbox MailboxName, it errors out. Apparently, you have to type in Get-Mailbox -Identity MailboxName, was this done to incorporate the New V2 cmdlets?”

This was with the initial release of the module, the cmdlets did not support “positional parameters”. Things have since changed and this and many other “convenience” updates have been released over the past few months. So as I’ve previously mentioned, make sure you are using a recent version of the module. Many of the examples we did in our demos were using positional parameters, and they work just fine now.

Our next question from Manjit Bilkhu: “Invoke-RestMethod only returns 1000 by default, is there any improvement in new module?”

Technically, this has nothing to do with the Exchange Online PowerShell V2 module, the Invoke-RestMethod cmdlet is “core” PowerShell one and has been available for years now. I suppose you are referring to the fact that the REST-based ExO cmdlets return up to 1000 objects by default, in which case you can simply uscae the –ResultSize Unlimited parameter/value.

Another question we received, this time from Syed Faisal: “Hi, if we use get-mailbox | -expand emailaddresses |export-csv , it returns numeric value only, any way to handle this?”

This is again something not related to the V2 Exchange Online PowerShell module, but let’s address it. The reason you are getting such output is because when you are piping to Export-CSV, it expects you to provide an object. However, because you are using the –ExpandProperty switch, you are effectively transforming it into a string. Here’s how to properly export to CSV with the above in mind:

Get-Mailbox -ResultSize Unlimited | select EmailAddresses | Export-Csv -nti EmailAddresses.csv

Or, in case you want each address on a separate line:

Get-Mailbox -ResultSize Unlimited | select -ExpandProperty EmailAddresses | Out-File EmailAddresses2.csv

Better yet, you can use a full-blown script such as the one I’ve shared here (help file is located here and additional details can be found over at the Quadrotech blog).

Vin Latus asked the following: “When I connect with the Connect-ExchangeOnline commandlet I get a warning “WARNING: Using New-PSSession with Basic Authentication is going to be deprecated soon, checkout for using Exchange Online V2 Module which uses Modern Authentication.” Am I missing something?”

Now, I’m not sure what the exact question is here, but let me try to answer it regardless. Microsoft has been telling its customers that basic authentication is going to be depreciated across all services for a while now, and Exchange Online is no exception. Exchange Online PowerShell in particular has supported modern authentication for a while now, and the V2 module *only* supports connecting via modern authentication. So, if you are using the module already, you’re all set.

The confusion usually arises from the fact that authentication is “proxied” via the WinRM basic authentication endpoint, and the session properties actually show “basic”, as we’ve shown as part of the demo. This is sort of a workaround, similar to the workarounds implemented for other clients that don’t natively support modern authentication. If and when Microsoft will provide “native” support for modern authentication that will work independently of the WinRM settings, we cannot tell.

Similar questions were asked by a few other attendees, so hopefully the above addresses your concerns. If not, let us know in the comments section.

Next, we move to a question related to hybrid scenarios: “How does these new cmdlets affect a hybrid situation. Or does MS want all mailboxes in EXO going forward?”

The answer here is that all the new cmdlets and improvements only apply to Exchange Online. The message from Microsoft has been clear for years – yes, they want you to move everything to the cloud. They do realize this is not possible for all customers/scenarios, thus they are still providing support and (sometimes) new features for on-premises environments, but the focus is clearly on the cloud.

Of course, we cannot speak on behalf of Microsoft, so any such questions/concerns should be addressed to your TAM or local Microsoft representatives. Or you can ambush someone from the Exchange team over at the EHLO blog.

The next question is regarding more new cmdlets: “What about Set- CMDLets? Are they also planned for the future?”

Again, we can’t speak on behalf of Microsoft here, but we’ve already seen the first Set- cmdlet added to the V2 module, namely the Set-UserBriefingConfig cmdlet. We have also seen examples of “traditional”-style cmdlets getting the REST API treatment, such as the cmdlets introduced to manage the event from emails feature earlier this year. So, I’m sure we will get more of these.

When this will happen however, I cannot tell. Keep in mind that the number of cmdlets in Exchange Online is huge, and reworking all of them to use the new APIs will be a multi-year effort. It’s unlikely that we will be getting replacement for all of these, at least not in the next few years. Moreover, the focus for the new cmdlets is “bulk” operations and addressing the most common tasks. But as I said, we cannot really speak on behalf of Microsoft with regards to their plans.

We also received a question regarding SSO: “If we want to use connect-exchangeOnline -UserPrincipalName with SSO, does that mean that we need to be logged on to our Hybrid Joined computer with an AzureAD administrator account? This might violate MS best practices / recommendations”

There are different forms of (seamless) SSO, the one I showcased as part of the demos was indeed leveraging Azure AD joined device to which I’ve logged in with my Azure AD credentials. In this scenario, authentication is performed via the so-called PRT (primary-refresh token), therefore you don’t need to provide any password or perform additional verification. A similar experience was demonstrated when using the ADAL methods to connect programmatically outside of the V2 module, in our “manual” scenario.

Whether this violates best practices/recommendations is debatable. Yes, one recommendation is to always separate admin and user accounts, but this mostly applies to the Global admin role. On the other hand, we have features such as Azure AD PIM, which allow you to use a single account and elevate it when necessary, thus applying the principles of JIT/JEA. Configuring passwordless authentication for such accounts is also considered a best practice, and one that works great with the Azure AD joined device/PRT flow. When using a personal tenant, that’s an acceptable risk.

As expected, we received a lot of questions regarding the “automation” scenario. Here are some of them:

“Looking to automate new scripts/cmdlets using the new cmdlets – is this possible? How?”

“will there be a way to automate login to exchange, with the -credential parameter, on accounts that require MFA?”

“How to use the new module in automated scripts with Modern Authentication. How to handle modern authentication in Automated scripts without human intervene. Thanks”

“With basic authentication being deprecated in November (I believe) for the exchange online PowerShell V1 endpoint, do you know of a way of authenticating to the service using stored credentials using modern auth in the V2 module? This is specifically for those of us who use a lot of automation and currently use basic auth with stored passwords for the service accounts that do the work (so for example, a task+account that checks/sets mailbox baseline configurations which runs every night.). We do this with certificates and azure AD app registrations for the SharePoint APIs (spo/pnp), but no option appears to exist to authenticate to exchange online PowerShell with this method. Thanks!”

“how do you connect to exo using app ID and app secret”

Obviously, this is a topic of great interest, and I would’ve loved to have shared more details with you. Unfortunately, we are still bound by NDA on this front. All I can tell you for now is that Microsoft is indeed working on it, in fact there’s a private preview currently going on and it works more or less as one would expect. I did try to drop some hints during the “manual connectivity” part of the demo, and I’ll  gladly expand on all the additional details once this has been released to the general public.

Lastly, there was a question from someone who must’ve missed this section of the session: “where do I get all the new cmdlets for EXO v2.0”?

The answer is to get the module from the PSGallery, and refer to the official documentation for additional details.

That concludes our follow up. Thank you once again for attending the session and we’re looking forward to seeing you on our next webinar, where we will discuss everything about the “automation” scenarios!

If you missed the Working with the Exchange Cmdlets v2.0 session, don’t worry you can still register here to receive an on-demand recording.