Set user thumbnail photo and get Office 365 domain references via the Azure AD Preview module

New version of the AzureADPreview module is available, you can get the module and full changelog from the PowerShell Gallery. I thought few additions are worth mentioning:

  • We now have full control over the ThumbnailPhoto attribute. I first noticed the existence of said attribute back in July, when I first blogged about the Azure AD module on Enow’s blog. At the time being, there was no way to configure the attribute, but now we can do so via the Get-/Set-AzureADUserThumbnailPhoto cmdlets. While the usual remark about using ObjectId applies, this time the team has made the cmdlet use much easier by introducing the FilePath parameter, allowing you to simply point to an image located on your PC:
 Set-AzureADUserThumbnailPhoto -ObjectId b96b3cae-888c-4b85-8871-c9766cb4791b -FilePath 'C:\blabla.jpg'

Get-AzureADUserThumbnailPhoto -ObjectId b96b3cae-888c-4b85-8871-c9766cb4791b

Tag :
PhysicalDimension : {Width=300, Height=300}
Size : {Width=300, Height=300}
Width : 300
Height : 300
HorizontalResolution : 300
VerticalResolution : 300
Flags : 77840
RawFormat : [ImageFormat: b96b3cae-0728-11d3-9d7b-0000f81ef32e]
PixelFormat : Format24bppRgb
Palette : System.Drawing.Imaging.ColorPalette
FrameDimensionsList : {7462dc86-6180-4c7e-8e3f-ee7333a7a483}
PropertyIdList : {20625, 20624}
PropertyItems : {20625, 20624}

You can also use a File stream or ByteArray to provide the image data if more appropriate. The size of the image you select must be appropriate for thumbnail, 100 KB or so. Exceeding this limit will result in the following error message:

Set-AzureADUserThumbnailPhoto -ObjectId b96b3cae-888c-4b85-8871-c9766cb4791b -FilePath 'C:\blabla2.jpg'

Set-AzureADUserThumbnailPhoto : Error occurred while executing SetAzureADUserThumbnailPhoto
StatusCode: BadRequest
ErrorCode: Request_BadRequest
Message: The stream write request would result in an excessive number of bytes being written.
At line:1 char:1

+ Set-AzureADUserThumbnailPhoto -ObjectId b96b3cae-888c-4b85-8871-c9766 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Set-AzureADUserThumbnailPhoto], ApiException
+ FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.Graph.PowerShell.Custom.Cmdlet.SetAzureADUserThumbnailPhotoCustom

The ThumbnailPhoto itself doesn’t seem to be currently used by any of the Office 365 services, but I guess that’s about to change soon.

  • Another convenient improvement is the Get-AzureADDomainNameReference cmdlet. You can use it to quickly list all objects which have attributes associated with a particular domain in your tenant. For example:
Get-AzureADDomainNameReference -Name tenant.onmicrosoft.com

The cmdlet works very similar to what we previously had available in the MSOL module:

Get-MsolUser -DomainName michev.onmicrosoft.com

However, unlike the MSOL cmdlet which only returns matching user objects, Get-AzureADDomainNameReference will also return group objects (both Office 365 Groups and “regular” ones). Some formatting issues are noticeable in the output due to the “mixed” object types however, here’s an example:

Get-AzureADDomainNameReference -Name michev.onmicrosoft.com

ObjectId DisplayName UserPrincipalName UserType
-------- ----------- ----------------- --------
fedf6ef0-235f-43cf-ae0c-e82f833c3e91 blabla xxx@michev.onmicrosoft.com Member

DeletionTimeStamp :
ObjectId : c12c1b90-0464-4ffc-a953-681b98ffcba4
ObjectType : Group
DisplayName : First group

DeletionTimeStamp :
ObjectId : 16ca4613-1ae7-45f0-94a7-a060f41f63fb
ObjectType : Group
DisplayName : Unified2
Posted in Azure AD, Office 365, PowerShell | Leave a comment

New features and settings for OWA (Accessibility settings, Undo send, Quick actions)

It has been a while since I wrote about OWA and a lot has changed in the meantime. So, here’s a quick look at all the new settings/features available as well as some reorganized options:

  • Under the General section, we have the new Accessibility settings menu, which seems to be a new feature intended to let anyone sending messages to you to make them accessible:

When the option is toggled on, people trying to send messages to you will be notified with a MailTip as shown below:

The feature can be controlled via the Set-MailboxMessageConfiguration and the -PreferAccessibleContent switch, and should not be confused with the Accessibility mode of OWA (which switches it to Light mode with improved accessibility features).

  • Under the Mail section, Automatic processing, we have the new Undo send options. It’s another example of a feature “borrowed” from Gmail, and it works by delaying your messages by up to 30 seconds. The options you can configure for said feature are shown below:

Once you toggle the feature, any new messages you compose in OWA will be kept into the Drafts folder for the specified number of seconds after you press the Send button. A visual indicator for the remaining time will be shown on the top right corner, along with an Undo button:

There doesn’t seem to be way to control this feature via PowerShell yet.

  • Under the Mail section, Layout, we can now customize the Quick Actions that appear in the top right corner of messages in the message list. You can choose up to four of the six available actions and rearrange them accordingly:

  • Lastly, the Calendar section has been reorganized and the options there are now grouped in Categories as follows:

We also have the Archive button and folder I covered in a previous article, a global Undo feature, the Report as phishing option, improved Move to menu. Focused Inbox should also start appearing, however the rollout seems to be a bit unpredictable lately.

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

“Archive” folder in Outlook

Some of you might have noticed that a new folder appeared in your Office 365 mailbox: Archive. Here’s what we know about it so far:

  • It’s a Default folder, with a FolderType Archive:
C:\ Get-MailboxFolderStatistics vasil | ? {$_.FolderType -eq "Archive"} | select Name,Folder*,Movable

Name : Archive
FolderPath : /Archive
FolderType : Archive
Movable : False
  • Being a Default folder, you cannot delete it (note the value of the Movable property above).
  • Neither Outlook nor OWA actually recognize it as Default folder yet and will happily allow you to delete or move it. And it will get restored later on, increasing your annoyance level. In case you want to actually delete or hide it, you will have to use MFCMAPI or another low-level method. Which is unsupported. But in case you are interested, details are for example here: https://www.howto-outlook.com/howto/hidemovedeletemfcmapi.htm
  • No other cmdlet recognizes the new folder type, for example you cannot create a retention tag for Type Archive:
C:\ New-RetentionPolicyTag -Name Archive -RetentionAction MoveToArchive -Type Archive -AgeLimitForRetention 720

Cannot process argument transformation on parameter 'Type'. Cannot convert value "Archive" to type "Microsoft.Exchange.Data.Directory.SystemConfiguration.ElcFolderType". Error:
"Unable to match the identifier name Archive to a valid enumerator name. Specify one of the following enumerator names and try again: Calendar, Contacts, DeletedItems, Drafts, Inbox, JunkEmail, Journal, Notes, Outbox, SentItems, Tasks, All, ManagedCustomFolder, RssSubscriptions, SyncIssues, ConversationHistory, Personal, RecoverableItems, NonIpmRoot, LegacyArchiveJournals, Clutter"
	+ CategoryInfo : InvalidData: (:) [New-RetentionPolicyTag], ParameterBindin...mationException
	+ FullyQualifiedErrorId : ParameterArgumentTransformationError,New-RetentionPolicyTag
  • Related to the above, no administrative controls exist to manage this new “feature” in Enterprise setting.
  • It’s not related to anything involving actual archiving of messages, as in the process of moving messages out of your primary mailbox. Instead, it’s the destination for “archive” actions via the recently introduced “archive” button in Outlook and the swipe actions on mobiles. The quotes are there for a reason. All these do is to move the message from one folder of your mailbox to another. As if we don’t have another 10 ways of doing the same already…
  • In case you need more info about that “archive” (note the quotes!) “feature”, read here: https://support.office.com/en-us/article/Archive-in-Outlook-2016-for-Windows-25f75777-3cdc-4c77-9783-5929c7b47028?ui=en-US&rs=en-US&ad=US

What’s even worse in the whole story is the fact that yet again Microsoft pushed a new functionality, and a one that’s easily noticeable by every user, without notifying us. And without providing proper administrative controls. It’s like the whole Clutter story never happened and no lessons were learned from it (mind you, Clutter was far more useful feature).

So here’s to a great new year and the hope that Microsoft will finally start doing things the right way! 🙂

Posted in Exchange Online, Office 365, Outlook, OWA | 2 Comments

Folder permissions for Groups and getting them recursively

Another example of interesting, but useless functionality – you can now check the folder permissions for Group mailboxes in Office 365. The Get-MailboxFolderPermission cmdlet has been updated to work against Group mailbox objects, via the -GroupMailbox parameter. Here’s an example:

[13:05:35][O365]# Get-MailboxFolderPermission -GroupMailbox default

FolderName User AccessRights
---------- ---- ------------
Top of Informatio... Default {None}
Top of Informatio... Anonymous {None}
Top of Informatio... Owner@local {ReadItems, CreateItems, EditOwnedItems, DeleteOwnedItems, DeleteAllItems, FolderVisible}
Top of Informatio... Member@local {Author}

The Add- and Set-MailboxFolderPermission cmdlets don’t yet recognize groups, so you cannot anything but look at the data. As Group permissions are governed by the membership of the Owners and Members group respectively, it’s expected to have both the Default and Anonymous levels set to None. Note that there aren’t any specific permissions for External users – similar to what we have with the Group files, external users get the same access as any other “regular” member of the Group (in this case Author permissions).

You can of course get the (sub)folder permissions too, but since there are no ways to actually grant permissions the result of this task will hardly be surprising. Still, I guess it’s a good exercise as some people might be unaware that Group mailbox folders are visible via the Get-MailboxFolderStatistics cmdlet. Here’s how to get the permissions for a particular (sub)folder:

[13:21:39][O365]# Get-MailboxFolderPermission -GroupMailbox external:\Inbox

FolderName User AccessRights
---------- ---- ------------
Inbox Default {None}
Inbox Anonymous {None}
Inbox Owner@local {ReadItems, CreateItems, EditOwnedItems, DeleteOwnedItems, DeleteAllItems, FolderVisible}
Inbox Member@local {Author}

And here’s how to do this recursively for all folders of the Group (there are quite many more than you might suspect!):

$mailbox = "external"

$folders = Get-MailboxFolderStatistics $mailbox | ? {$_.FolderType -notlike “RecoverableItems*” -and $_.FolderType -ne “Audits” -and $_.FolderType -ne “CalendarLogging”}

$arrPermissions = @()

foreach ($folder in $folders) {

	if ($folder.Name -eq "Top of Information Store") { $MailboxFolder = $mailbox }
	else {
		$FolderPath = $folder.FolderPath.Replace("/","\").Replace([char]63743,"/") #with PowerShell v3 'fix'
		$MailboxFolder = "$mailbox`:$FolderPath"
	}

	#replace with -Identity for User mailboxes
	$MBrights = Get-MailboxFolderPermission -GroupMailbox $MailboxFolder # | ? {$_.User.DisplayName -ne "Default" -and $_.User.DisplayName -ne "Anonymous"}

	if (!$MBrights) { continue }

	foreach ($entry in $MBrights) {

		$objPermissions = New-Object PSObject
		$i++;Add-Member -InputObject $objPermissions -MemberType NoteProperty -Name "Number" -Value $i
		Add-Member -InputObject $objPermissions -MemberType NoteProperty -Name "User" -Value $entry.user
		Add-Member -InputObject $objPermissions -MemberType NoteProperty -Name "Folder" -Value $folder.Name
		Add-Member -InputObject $objPermissions -MemberType NoteProperty -Name "Access Rights" -Value $entry.AccessRights
		$arrPermissions += $objPermissions

	}
}

$arrPermissions | select Folder,User,'Access Rights'

The result will be a long list of useless data, don’t say I didn’t warn you! But you also easily adapt this to run against User mailboxes or export the result to CSV file, which makes a bit more sense 🙂

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

Keep a copy of sent emails for delegates of user mailboxes!

The ability to send messages on behalf of somebody else has been around for a long time, but it has it quirks. One of the major issues with it was the fact that any messages send on behalf of say a shared mailbox weren’t copied to the mailbox, thus other people working with it were unaware of the action. Over the course of the last few years and Exchange versions, Microsoft offered us different workarounds for this issue, the latest one being the use of the MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled parameters. For a brief overview on the different methods and details on said parameters you can refer to the EHLO blog post here: https://blogs.technet.microsoft.com/exchange/2015/03/03/want-more-control-over-sent-items-when-using-shared-mailboxes/

As you can see from the article above, while the new method proved very useful and easy to control, it was only available for shared mailboxes. If you tried to configure the setting for any user mailbox, you were greeted by the following error message:

PS C:\> Set-Mailbox huku -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

MessageCopyForSentAsEnabled can only be set on shared mailboxes

+ CategoryInfo : NotSpecified: (huku:MailboxIdParameter) [Set-Mailbox], TaskArgumentException

+ FullyQualifiedErrorId : [Server=HE1PR03MB1340,RequestId=e7ba59bb-a4a4-4de8-b751-1904ac73185c,TimeStamp=11/11/2015 8:34:59 PM] [FailureCategory=Cmdlet-TaskArgumentException] 36931497,Microsoft.Exchange.Management.RecipientTasks.SetMailbox

This in turn meant that we still had to address issues with delegates for user mailboxes, say a secretary sending mail on behalf of a VP. Well, no more! The parameters can now be used for both shared and user mailboxes. For example, to turn this on for a single user mailbox you can use:

Set-Mailbox HuKu -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

To turn the settings on for all user mailboxes, use:

Get-Mailbox -RecipientTypeDetails UserMailbox | Set-Mailbox -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

To turn the settings on for all user and shared mailboxes:

Get-Mailbox -RecipientTypeDetails UserMailbox,SharedMailbox | Set-Mailbox -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

If you try to turn it on for any other type of mailbox, you will still run into the familiar error message:

MessageCopyForSentAsEnabled can only be set on shared mailboxes or user mailboxes.

+ CategoryInfo : NotSpecified: (WC:MailboxIdParameter) [Set-Mailbox], TaskArgumentException

+ FullyQualifiedErrorId : [Server=DB6PR0302MB2614,RequestId=602ce875-59c1-4353-8fd5-d37bc8565572,TimeStamp=12/23/2016 8:36:24 AM] [FailureCategory=Cmdlet-TaskArgumentException] 10E0541D,Microsoft.Exchange.Management.RecipientTasks.SetMailbox

One last remark: at the time of this writing, the functionality is not yet rolled out fully, so while you can configure the settings, the actual copies of the send message don’t get copied to the mailbox. Which I guess is why Microsoft hasn’t yet announced this officially 🙂

Posted in Exchange Online, Office 365, PowerShell | 2 Comments