Blog

Dec 23
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 :)

Dec 23
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 :)

Dec 15
New Calendar sharing experience in Office 365

Without any big announcements, Microsoft has started rolling out the new Calendar sharing experience we first saw earlier this year at Ignite. The improvements are long overdue for sure, as the process of sharing your Calendar or getting access to other people's availability data has been confusing and unreliable for many users. On top of this, we also face issues with the limited availability of sharing functionality on mobile devices.

There are few major sets of improvements coming. First, we will get a simpler, streamlined UI experience for both sharing and accepting invitations. The new experience is already available in OWA for First Release tenants, so you might want to give it a go. Outlook for desktop and mobiles will follow suit in the coming weeks. Next, reliability and speed improvements are coming thanks to the use of modern protocols and APIs. Instead of the old "linked" Calendar model, now a local copy of the shared Calendar will be created and the service will take care of updating it with both yours and the owner's changes. Yes, this means mobile clients will also display shared Calendars! Lastly, a set of new features is coming, such as reminders for events in shared calendars or notifications for changed items! You will also be able to configure or check for Delegate permissions, that pesky "delegate can see my Private items" setting and the equally troublesome meeting delivery options:

At this time, only a subset of the above is rolled out to the service, and most of it requires you to use OWA. Which I guess is the reason why Microsoft has chosen to keep this quiet. Rest assured though, the new experience is coming to all Outlook modalities soon! For timeframes and additional details on the new experience (including some other great features not directly related to Calendar sharing), make sure to watch the video recording from Ignite: 

 

 

Dec 05
Immediately revoke access to Office 365 applications

Being able to immediately revoke user's access to applications is one of the most requested security related features for Office 365. Because of the different caching mechanisms employed in the service and/or the apps you use, accomplishing this can be a tricky task. As an example, you can refer to this article detailing the different factors that affect this in Exchange (Online). Modern authentication made things even messier, with the very long validity of the refresh tokens and the lack of proper methods to revoke them.

Almost a year ago, the SharePoint Online team gave us the opportunity to revoke access via the Revoke-SPOUserSession cmdlet. I blogged about this here. Now, at long last, we finally have global control over this via the AzureAD PowerShell module and Revoke-AzureADUserAllRefreshToken cmdlet. Here are few examples on how to use the cmdlet:

  • The only parameter the cmdlet accepts is -ObjectId, which isn't really convenient (if only the folks at Microsoft listened to feedback):


    C:\> Revoke-AzureADUserAllRefreshToken -ObjectId 582b2b38-888c-4b85-8471-c9716cb4791b

    No output will be returned unless an error occurs.

  • An easier way is to get the objectId via the Get-AzureADUser cmdlet and pipe it to Revoke-AzureADUserAllRefreshToken:


    C:\> Get-AzureADUser -SearchString huku | Revoke-AzureADUserAllRefreshToken

  • Similarly, you can do something like this:


    C:\> Revoke-AzureADUserAllRefreshToken -ObjectId (Get-AzureADUser -SearchString huku).objectId

  • Our you can get more creative like for example revoking access for all members of a particular group:


    C:\> Get-AzureADGroup -SearchString CloudSecGrp | Get-AzureADGroupMember | Revoke-AzureADUserAllRefreshToken

Another similar cmdlet exists, namely Revoke-AzureADSignedInUserAllRefreshToken. It's used to revoke tokens for the currently signed in user, i.e. the one issuing the cmdlet. It doesn't accept any parameters and can be used to for testing/development purposes.

Lastly, a word of caution. Although the cmdlet does revoke the refresh token, the access token remains valid and the user will be able to continue to access data until the browser is closed (or the app restarted). In other words, the user is not immediately forced to reauthenticate, but with the refresh token purged he will have to do so as soon as the access token has expired (max 1 hour). Or the app/browser is closed.

Nov 29
Using filters against objects containing special characters

Another one in the series "blog this so I don't forget it later"‚Äč. Here's the issue: when using server-side filtering (the -Filter parameter, or -RecipientFilter, etc), you have to use the OPATH format and mind some special characters. For example, having an apostrophe in the name of the object.

I run into this when preparing a report on DG membership for some users in specific country. Now, you are probably aware of the quick and easy way to get the "MemberOf" equivalent in EO:

Get-Recipient -Filter {Members -eq 'CN=user,OU=tenant.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR03A001,DC=prod,DC=outlook,DC=com'}

This lovely one-liner will save you the trouble of having to enumerate all groups and cycle over them! So it greatly reduces the complexity and time of execution for the script. Note the DN handling however - it needs to be enclosed in single quotation marks. Which coincidentally, are used interchangeably with apostrophes. So in effect, every DN that contains an apostrophe (which is totally legit btw), will cause the nice one-liner above to break. The solution - 'escape' the apostrophe in the DN by replacing it with... four (yes, that's f-o-u-r, 4!) other apostrophes. Or in script form:

$dn =  (Get-Mailbox user).DistinguishedName
$dnnew = "'" + "$($dn.Replace("'","''''"))" + "'"
$cmd = "Get-Recipient -Filter 'Members -eq '$dnnew''"
$list = Invoke-Expression $cmd

Now, the filter should work just fine!

1 - 5Next