PowerShell Core and setting a working directory via profile script

PowerShell Core continues to irritate me, almost every time I decide to give it another chance it manages to get on my nerves in some new and ingenious way. Today’s rant is the story of me trying to bring the Profile customizations I’ve made to its beloved older brother, Windows PowerShell, to the current 6.1 release of Core. One of these customizations includes setting the working directory to something more useful than the default “Home” directory.

So I proceeded to add a simple Set-Location cmdlet to my profile script, yet after relaunching PowerShell, it still opened in my home directory. Failing to spot any obvious errors in the simple cmdlet I’ve used, I proceeded to refresh my memory on how PowerShell Core handled profiles, and just in case put the same line in the “system” (All Users, All Hosts) profile. No luck.

Being the experienced debugger that I am, next I did what I know best – wrapped a bunch of Write-Host cmdlets around the Set-Location one. Just to make sure the profile is actually being executed (although I did already know this is happening, due to the other customizations). Even the almighty echo-s didn’t help, and the working directory was clearly being set on some other level, overriding any changes I made to profile.

The first suspect to examine then was the settings on the shortcut I used to launch PowerShell, and I expected to see the “Start in” property populated there, as in fact it is for the Windows PowerShell shortcuts. Although in the case of Windows PowerShell it does not overriding the profile customizations. Anyway, I was wrong on that part and the “Start in” value was empty. However the “Target” value caught my eye, and lo and behold – PowerShell was being invoked with a new -WorkingDirectory switch:

Nasty little bugger! Removing it fixed my issue, and the universe made sense again. And since I wasted half an hour on this, I decided to waste some more time and bitch about it on GitHub. Turns out there is already an issue raised on this, and the fix is merged in the 6.2 Preview release, so I didn’t get to express my frustration as someone beat me to it. But nothing stops me from doing so here on my blog 🙂

Hopefully others will not have to suffer the same, once the 6.2 version has GAd. Until then, if you run into this annoyance, simply remove the -WorkingDirectory parameter from your shortcut(s).

Posted in PowerShell | 1 Comment

New properties added to Get-MailboxStatistics output

It looks like the good folks at Microsoft have updated the output of the Get-MailboxStatistics cmdlet with few additional properties. Here’s the full list:

LastEmailTime                                 : 01/02/2019 15:17:05
LastContactsTime                               : 13/09/2018 18:55:35
LastCalendarTime                               : 25/01/2019 18:48:09
LastTasksTime                                 : 21/01/2019 17:13:13
LastFileTime                                   : 01/02/2019 21:55:48
LastProfileTime                               :
LastInteractionTime                           : 01/02/2019 15:17:05
LastUserAccessTime                             :
LastUserActionTime                             : 01/02/2019 15:17:05
LastUserActionUpdateTime                       : 02/02/2019 01:52:04

Since there is no mention in the documentation for any of there, we can make some educated guesses as to what each property represents. For example, the LastTasksTime seems to correspond to the date/time at which I last updated a task item in my mailbox, and in fact seems to be correct. On the other hand, properties such LastEmailTime or LastActionTime don’t seem to correspond to the actual time such operations were performed. And since they all have a similar value, we can guess that all of them are being updated by some background process on a regular schedule, which seems to introduce few days delay.

And that’s pretty much all I know about them at this time. I’ve probed Microsoft for more details, and should they share them or publish an article on the changes, I will make sure to circle back to this. It’s also worth noting that none of these properties seem to be available on-premises, at least not on Exchange 2019 RTM.

Posted in Exchange Online, Office 365, PowerShell | Leave a comment

Exchange Online now supports the -like operator for PrimarySMTPAddress filtering, sort of

In today’s useless bit of information, I present you the news that we can now use the -like operator when filtering against the PrimarySmtpAddress attribute in Exchange Online.

Filters are certainly one of the most useful features and any Exchange (and Office 365) administrator should be taking advantage of them whenever possible. They help you configure your Dynamic groups or address book policies, and they enable you to return just the objects you need, greatly minimizing the time it takes to run reports or perform bulk changes. In the Office 365 world however they come with certain limitations, such as not being able to use leading wildcards or certain type of operators.

For example, if you tried to use a filter based on the PrimarySmtpAddress attribute few years ago and used the -like operator, you would have run into the following error message:

Get-Mailbox -Filter {PrimarySmtpAddress -like "*@michev.info"} 
Property PrimarySmtpAddress does not support Microsoft.Exchange.Data.TextFilter. Only Microsoft.Exchange.Data.ComparisonFilter is supported.
+ CategoryInfo          : NotSpecified: (0:Int32) [Get-Mailbox], ADFilterException
+ FullyQualifiedErrorId : F201E363,Microsoft.Exchange.Management.RecipientTasks.GetMailbox
+ PSComputerName        : amxprd0310psh.outlook.com

whereas nowadays you can run the same code without any errors. Sadly, without any output either, as the fact that the -like operator is now supported for PrimarySmtpAddress queries, doesn’t mean it actually works 🙂 No matter which variation I try, the end result is zero returned entries, while at the same time filters based on other attributes work just fine:

C:\> Get-Mailbox -Filter {PrimarySmtpAddress -like "*@michev.info"}
C:\> Get-Mailbox -Filter {PrimarySmtpAddress -like "@michev.info"}
C:\> Get-Mailbox -Filter {PrimarySmtpAddress -like "michev.info"}
C:\> Get-Mailbox -Filter {EmailAddresses -like "*@michev.info"}

Name                      Alias           Database                       ProhibitSendQuota    ExternalDirectoryObjectId
----                      -----           --------                       -----------------    -------------------------
bathroom                  bathroom        EURPR03DG246-db075             9.5 GB (10,200,54... 6a9994eb-0449-4f1d-a305-7cf228a06f66
dimo                      dimo            EURPR03DG135-db037             9.5 GB (10,200,54... 34ea864d-8765-45da-8b15-df67cf2fc547

The only type of query that appears to be working is one excluding the domain part, which renders the filter almost useless. For example, I can filter all mailboxes that have primary SMTP addresses in the form vasil*@*, but that’s pretty much the same as filtering on the Name or Alias attribute, and for that we don’t even need filters:

C:\> Get-Mailbox -Filter {PrimarySmtpAddress -like "vasil*"}

Name                      Alias           Database
----                      -----           --------
vasil                     vasil           EURPR03DG245-db082
vasilUS                   vasilUS         EURPR03DG267-db103

C:\> Get-Mailbox vasil*

Name                      Alias           Database
----                      -----           --------
vasil                     vasil           EURPR03DG245-db082
vasilUS                   vasilUS         EURPR03DG267-db103

And what’s even more annoying is that the same type of filters do not work properly on-premises either, even though the example you can find on the -Filter documentation seems to indicate the opposite.

So what does work then? You can certainly do a filter on the EmailAddresses attribute instead. Problem with it is that you cannot use it to match against only the Primary SMTP address, if you include the “SMTP” prefix you end up in a similar situation as with the PrimarySmtpAddress filter. Instead, what you can do, at least in the service, is to use a filter based on the WindowsEmailAddress attribute:

Get-Mailbox -Filter {WindowsEmailAddress -like "*@michev.onmicrosoft.com"} | select Name,PrimarySmtpAddress,WindowsEmailAddress

Name                    PrimarySmtpAddress                             WindowsEmailAddress
----                    ------------------                             -------------------
HuKu                    HuKu@michev.onmicrosoft.com                    HuKu@michev.onmicrosoft.com
NewDiscoveryMailbox     NewDiscoveryMailbox@michev.onmicrosoft.com     NewDiscoveryMailbox@michev.onmicrosoft.com
sharedtest              sharedtest@michev.onmicrosoft.com              sharedtest@michev.onmicrosoft.com

The same trick should work with on-premises Exchange as well, but technically those are two different attributes, so remember to always check whether the PrimarySmtpAddress does match the value of WindowsEmailAddress.

Posted in Exchange Online, Office 365, PowerShell | Leave a comment

MigratedMessages folder for Office 365 Group mailboxes

Here’s something interesting I spotted a while back – all Office 365 Group mailboxes in my tenant seem to have an additional (sub)folder under the RecoverableItems subtree, named “MigratedMessages”. And only Office 365 Group mailboxes, none of the other types seem to have it. You can run the following cmdlet to check the presence of this folder for your Group mailboxes:

Get-UnifiedGroup | % { Get-MailboxFolderStatistics $_.PrimarySmtpAddress -FolderScope RecoverableItems | ? {$_.Name -eq "MigratedMessages"} | select Name,Identity,FolderSize }

Name             Identity                                           FolderSize
----             --------                                           ----------
MigratedMessages Unified@michev.info\MigratedMessages               0 B (0 bytes)
MigratedMessages firstgroup@michev.onmicrosoft.com\MigratedMessages 0 B (0 bytes)
MigratedMessages chinese@michev.info\MigratedMessages               0 B (0 bytes)

In my case, every single Group mailbox has this folder, and in every single Group mailbox this folder is empty. Zero messages, zero size. Zero results online as to what it might be used for. And the best part – the folder has been around since at 2014 at the very least, according to entries from my PowerShell transcripts. My initial guess, based on the name of the folder and the fact that it has existed for years is that it might have something to do with the initial release of the Unified Groups feature, and maybe even some plans Microsoft had to offer (shared) mailbox “conversion” into Groups. Which doesn’t explain why this folder is present for newly created Groups as well.

While looking at this folder, I discovered yet another new entry under the RecoverableItems subtree. Namely, a folder named “SubstrateHolds” seems to be present in some of the Group mailboxes. Some, as in not all of them have it. No “regular” mailbox has it either. Here’s how to check for it:

Get-UnifiedGroup | % { Get-MailboxFolderStatistics $_.PrimarySmtpAddress -FolderScope RecoverableItems | ? {$_.Name -eq "SubstrateHolds"} | select Name,Identity,FolderSize }

Name           Identity                                         FolderSize
----           --------                                         ----------
SubstrateHolds firstgroup@michev.onmicrosoft.com\SubstrateHolds 0 B (0 bytes)
SubstrateHolds chinese@michev.info\SubstrateHolds               0 B (0 bytes)
SubstrateHolds OutlookGroup@michev.info\SubstrateHolds          0 B (0 bytes)

As with the “MigratedMessages” folder, there is absolutely no information available what the folder is used for. Its name and the fact that it’s located under the RecoverableItems subtree suggests that it has something to do with the hold functionality, but what exactly is beyond me. If I ever manage to get additional info, I’ll make sure to update the post 🙂

Posted in Exchange Online, Office 365, PowerShell | Leave a comment

Microsoft removes the Team’s and Manager’s Calendar Groups from Outlook

In their never-ending quest to dumb down Outlook’s interface, the folks at Microsoft has decided to get rid of yet another feature. This time around, the impacted functionalities are the Team’s and Manager’s Calendar Groups in Outlook, or in other words the ability to quickly access all your direct reports’ or peers’ Calendars. While the semi-annual channel builds still feature these two functionalities, anyone using a current channel build will no longer have access to them.

For those of you that aren’t familiar with this functionality, here’s the two sentence breakdown. To access said Calendar Groups, one would navigate to the Calendar pane in Outlook (Ctrl+2), select Home on the Ribbon, look for the Manage Calendars group in the middle and press the Calendar Groups button. From the dropdown menu, you can manage your Calendar groups, or toggle the built-in options to Show Manager’s Team Calendars and/or Show Team Calendars. Here’s how it looks like:

Once you toggle the settings, a new “group” will appear on the left pane, prefixed with “Team:” and featuring the name of the manager (or your name in case of direct reports). Under the calendar group, the individual calendars of each member of the team will be listed, up to a number of 100, allowing you to quickly select each on all of them, when needed. The feature itself doesn’t perform any changes (or checks) on the permissions on those calendars.

In all fairness, we haven’t lost the functionality to actually open the Calendars of any of our peers or direct reports, provided the corresponding permissions allow it. What we’ve lost is access to these two toggles, which made the process that much easier. Then again, in larger teams they could contribute to creating a “calendar bloat”, or create confusion in situations where the permissions didn’t match the intended use case for this feature. Still, people have been using these settings and were caught off guard by their removal, as evident for example from this thread on the MTC.

In addition, the feature relied on having the Manager attribute properly configured in AD/Exchange Online, which isn’t always the case. For example, two years back when Microsoft decided to shove the “Auto creation of Direct reports Office 365 Groups” down our throats, Tony Redmond was quick to point out that roughly half of the Exchange Online users covered by Cogmotive/Radar reports do not have this property configured.

In any case, Microsoft has already confirmed that removal of these two settings is by design, so they will not be returning in future builds, although they haven’t bothered to actually mention this on any official channel. Which is the reason for writing this blog post. Enjoy! 🙂

Posted in Exchange Online, Office 365, Outlook | Leave a comment