Driving Through The Clouds

Client Experience: Free Busy not working

Ivan Franjić — Sun, 19 Jun 2016 09:08:15 GMT

Worked on the Free / Busy issue recently and thought to share troubleshooting steps. Free / Busy usually is "black box" for a lot of Exchange folks I was talking with, but essentially it is really easy and straight forward service to troubleshoot. I'm planning to write article about it and most common troubleshooting scenarios in future. Now, back to the case. FB access was working for entire org, just several users were suffering FB issues. UserA couldn't see FB of UserB and UserC... And vice versa. Other users could see FB for UserA, UserB... All users were part of the same Exchange organization. With above, conclusion was that probably permission level issues were in place. Fiddler trace confirmed suspicious:

Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException: The caller does not have access to free/busy data.
. Name of the server where exception originated: SERVER01. LID: 44348ErrorNoFreeBusyAccess0//schemas.microsoft.com/exchange/services/2006/errors">NoFreeBusyAccessException

Fired PowerShell session to check permission and to my surprise, permissions seemed OK:

Get-MailboxFolderPermission userA:\calendar
 
FolderName           User                 AccessRights
----------           ----                 ------------
Calendar             Default              {AvailabilityOnly}
Calendar             UserB                {Reviewer}
Calendar             UserC                {Reviewer}
Calendar             UserD                {Reviewer}
Calendar             UserF                {Reviewer}

For all users that was working, ACL wasn't present which means they are going to fail to "Default" scope and get "AvailabilityOnly". Other users that have permissions shouldn't get "NoFreeBusyAccessException" as ACL allows them "FullDetails" with "Reviewer" permissions. Only one strange thing I found here is that default "Anonymous" permission of "None" is missing, but that shouldn't matter at all since all users within same Exchange organization should have authenticated session. Going forward I wanted to compare raw store level permission with what Get-MailboxFolderPermission cmdlet was showing. In order to do that, Get-StoreQuery should be used and steps as outlined below: 1. Find MailboxNumber within store:

$userMbx = Get-Mailbox user@domain.com
Get-StoreQuery -Database $userMbx.Database -Query "Select MailboxNumber from Mailbox Where MailboxGuid='$($userMbx.ExchangeGuid)'"

MailboxNumber
-------------
          194

2. Find Calendar folder in the store:

$userMbxFolder = Get-StoreQuery -Database $userMbx.Database -Query "Select * From Folder Where MailboxNumber=194 and DisplayName='Calendar'"

3. Parse Folder ACL blob:

$userMbxPerms = Get-StoreQuery -Database $userMbx.Database -Query "Select * From ParseAclTableAndSD($($userMbxFolder.AclTableAndSecurityDescriptor))"

$userMbxPerms.Value

ACL table:
Name(0):
SID(0): S-1-1-0
IsGroup(0): False
Rights(0): FreeBusyAll
EntryId(0):
Name(1): UserA
SID(1): S-1-5-21-1234567890-1234567890-123456789-1681589
IsGroup(1): False
Rights(1): EditAny, DeleteAny, Author, FreeBusyAll
EntryId(1): 00000000 12345678 12345678 12345678 12345678 12345678 00000000 12345678 4D532F6F 753D4578 6368616E 67652041 646D696E 69737472 61746976 65204772 6F757020 28465944 49424F48 46323353 50444C54 292F636E 3D526563 69706965 6E74732F 636E3D4D 41594552 45303000
EntryId(1).Eidt: UserA
EntryId(1).EmailAddress: /o=G/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA
Name(2): UserB
SID(2): S-1-5-21-1234567890-1234567890-123456789-1724373
IsGroup(2): False
Rights(2): ReadOnly, Visible
EntryId(2): 00000000 12345678 12345678 12345678 12345678 12345678 12345678 12345678 
EntryId(2).Eidt: UserB
EntryId(2).EmailAddress: /o=G/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB
...
...
...

SID to Type map:
SID:S-1-1-0, Type:User
SID:S-1-5-21-1234567890-1234567890-123456789-1681589, Type:User
SID:S-1-5-21-1234567890-1234567890-123456789-1724373, Type:User
SID:S-1-5-21-1234567890-1234567890-123456789-1366337, Type:User
...
...
...

SD:
O:SYG:SYD:(A;CI;0x1208ab;;;S-1-5-21-1234567890-1234567890-123456789-1681589)(D;CI;0xd4114;;;S-1-5-21-1234567890-1234567890-123456789-1681589)(A;OIIO;0x1f0fbf;;;S-1-5-21-1234567890-1234567890-123456789-1681589)(A;CI;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1724373)(D;CI;0xd4116;;;S-1-5-21-1234567890-1234567890-123456789-1724373)(A;OIIO;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1724373)(D;OIIO;0xd0716;;;S-1-5-21-1234567890-1234567890-123456789-1724373)(A;CI;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1366337)(D;CI;0xd4116;;;S-1-5-21-1234567890-1234567890-123456789-1366337)(A;OIIO;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1366337)(D;OIIO;0xd0716;;;S-1-5-21-1234567890-1234567890-123456789-1366337)(A;CI;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1664815)(D;CI;0xd4116;;;S-1-5-21-1234567890-1234567890-123456789-1664815)(A;OIIO;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1664815) ... ... ...

FreeBusy SD:
O:SYG:SYD:(A;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1681589)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1724373)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1366337)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1664815)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1549750)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-2149643)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1679850)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-2181067)... ... ...

After observing raw FreeBusy SD, I noticed that all SIDs from the subject had "D" in front of ACE string which stands for "Deny":

(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1724373)
(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1366337)

ACL string structure can be found here. Raw ACL showed that FB permissions were incorrectly set on 'Calendar' folder, while Get-MailboxFolderPermission displayed folder level permission which were bit misleading. In order to correct this issue, user must set FB level permissions on 'Calendar' folder through Outlook and give the appropriate permission to the people that were experiencing the issue.

Client Experience - Category color disappearing from item after Outlook restarts

Ivan Franjić — Wed, 18 May 2016 06:10:43 GMT

Just recently I was working on interesting case where colors were disappearing from custom categories in Archive Calendar items after Outlook restarts. Following are steps user done to reproduce the issue: 1. Opened calendar item from Archive mailbox, 2. Created new category and assigned custom color to it, 3. Assigned newly created color to opened calendar item, 4. Saved item, 5. Upon restarting Outlook, custom color disappeared. First thing I wanted to check if there is actual category property set on server on the item itself. That would show if Outlook ROP (Remote OPeration) reached and updated item on the server and that we are not seeing "Test Category" string definition from local .ost file. Fired up PowerShell session and loaded Get-StoreQuery function. From information above I knew following: 1. Items are in Calendar folder, 2. Calendar folder is in Archive mailbox. First thing to do is find user's archive mailbox number in the store as it will be used for retrieving folders and items:

$mbx = Get-Mailbox userMailbox -Archive
$mbxNumberInStore = Get-StoreQuery -Database $mbx.ArchiveDatabase -Query "Select MailboxNumber From [$($mbx.ArchiveDatabase)].Mailbox Where MailboxGuid='$($mbx.ArchiveGuid)'"
$mbxNumberInStore

MailboxNumber
-------------
          123

Then we need actual id of the calendar folder within archive since it will be used as parameter while retrieving messages:

$calendarFolderInArchive = Get-StoreQuery -Database $mbx.ArchiveDatabase -Query "Select FolderId, DisplayName From [$($mbx.ArchiveDatabase)].Folder Where MailboxNumber=$($mbxNumberInStore.MailboxNumber) and DisplayName='Calendar'"

$calendarFolderInArchive

FolderId                                               DisplayName
--------                                               -----------
0x52D13AF2E8970F408FC28B30EAB9CD4B0000145ED07200000100 Calendar

At this point I needed only category stamp and subject of test calendar item (MAPI properties are documented on MSDN - MAPI Properties). Below are hex representation of MAPI properties and first 4 chars are property identifier and last for are type of data stored within property:

$keywordsProperty = p8002101F
$subjectProperty = p0037001F

Get-StoreQuery -Database $mbx.ArchiveDatabase -Query "Select $keywordsProperty, $subjectProperty From [$($mbx.ArchiveDatabase)].Message Where MailboxNumber=$($mbxNumberInStore.MailboxNumber) and FolderId=$($calendarFolderInArchive.FolderId)" | Where-Object { $_.p0037001F "Test Meeting"}

p8002101F                      p0037001F
---------                      ---------
Test Category		         Test Meeting

String representation of category is stamped on item. Great, ROP is not failing and item is updated which means that client is able to talk to server and submit ROPs without any issues. Next logical question would be - Where category color definition is stored? It is within Calendar FAI (Folder Associated Item) on IPM.Configuration.CategoryList message class item which is not visible through Outlook. Since it's not visible through Outlook I wanted to check if it's visible using Get-StoreQuery: Note // Category definition for all items within single mailbox are store in Calendar folder of that mailbox, no matter if item flagged with category is in Inbox or any other folder.

Get-StoreQuery -Database $mbx.ArchiveDatabase -Query "Select * From [$($mbx.ArchiveDatabase)].Message Where MailboxNumber=$($mbxNumberInStore.MailboxNumber) and FolderId=$($calendarFolderInArchive.FolderId) and MessageClass='IPM.Configuration.CategoryList'"

Nothing returned! First thought was either Get-StoreQuery cannot access to the item or Archive mailbox is missing IPM.Configuration.CategoryList item. To rule out first scenario I executed Get-StoreQuery against primary mailbox and suprisingly I got result:

Get-StoreQuery -Database $mbx.Database -Query "Select * From [$($mbx.Database)].Message Where MailboxNumber=$($Numb
erInStore.MailboxNumber) and FolderId=$($calendarFolder.FolderId) and MessageClass='IPM.Configuration.CategoryList'"

MailboxNumber              : 122
LastModificationTime       : 30.4.2016. 16:32:52
Size                       : 4850
MessageClass               : IPM.Configuration.CategoryList

At this point it was clear that category item (Keyword typeOf string) was successfully stamped on Calendar item (meeting item), but Outlook client wasn't able to store color definition for it in configuration store IPM.Configuration.CategoryList as this was missing from Archive mailbox configuration. How to recreate missing IPM item and remediate issue? Outlook have custom switch which can be used when starting - outlook.exe /remigratecategories. However in this case that didn't helped. Ews to the rescue! Since Ews supports access to FAI, I created cmdlet in Ews module which will recreate missing IPM.Configuration.CategoryList item: Following cmdlet generates empty IPM.Configuration.CategoryList under specified folder:

$calendarArchiveFolder = Get-EwsFolder -RootFolder (Get-EwsWellKnownFolderId ArchiveRoot) -FolderName "Calendar"
Get-EwsMasterCategoryConfiguration -CalendarFolder $calendarArchiveFolder
WARNING: CategoryList item not found in specified calendar folder.
WARNING: The specified object was not found in the store., The configuration object was not found. Name = CategoryList.
 
New-EwsMasterCategoryConfiguration -CalendarFolder $calendarArchiveFolder
Get-EwsMasterCategoryConfiguration -CalendarFolder $calendarArchiveFolder
 
Name           : CategoryList
ParentFolderId : AAMkAGM1NmE5NTA4LWI5Y2YtNGI0NC1hNGM2LTc3NmZmOTNjMWY0NgAuAAAAAADDlsVc+qFNQ7GQklHk1YUeAQBS0Try6JcPQI/CizDquc1LAAAAAAENAAA=
ItemId         : AAMkAGM1NmE5NTA4LWI5Y2YtNGI0NC1hNGM2LTc3NmZmOTNjMWY0NgBGAAAAAADDlsVc+qFNQ7GQklHk1YUeBwBS0Try6JcPQI/CizDquc1LAAAAAAENAABS0Try6JcPQI/CizDquc1L
	         AAAhukKOAAA=
Dictionary     : {}
XmlData        :
BinaryData     :
IsDirty        : False

Creating new category within Archive mailbox initialized IPM.Configuration.CategoryList FAI which resolved issue completely:

$categoryPayload = Get-EwsMasterCategoryConfiguration -CalendarFolder $calendarArchiveFolder
[System.Text.Encoding]::UTF8.GetString($categoryPayload.XmlData)


        {3C9CA7C2-64DD-4942-AB47-6CE29FF23624}"/>

PowerShell - Get-GuidFromHex

Ivan Franjić — Wed, 18 May 2016 05:53:32 GMT

Lot of time I need to deal with conversion between different data structures. One most often I deal with is conversion from hex data to guid representation of it. I wrote simple function that handles that kind of conversion. Since lot of guid representation stored in hex format uses little endian ordering, function has special switch -LittleEndian which will convert hex to guid using little endian byte ordering.

function Get-GuidFromHex
{
    param
    (
        [string]
        $HexString,

        [switch]
        $LittleEndian
    )
    
    #region Perform hex string validation

    # if string provided is in raw hex format, remove heading '0x'
    if ($HexString.StartsWith('0x'))
    {
        $HexString = $HexString.Substring(2);
    }

    # guid expects 32 bits, if provided string is not 32 bits length,
    # we shouldn't bother with trying to convert it.
    if ($HexString.Length -ne 32)
    {
        throw "Hex string is not valid length. Current length is '$($HexString.Length)', expected length is 32 characters.";
    }

    # validate if all characters from provided string is expected
    # hex character.
    [regex]$hexAllowedCharacters = '[0-9a-fA-F]';

    foreach ($hexChar in $HexString.ToCharArray())
    {
        if (-not ($hexAllowedCharacters.Match($hexChar).Success))
        {
            throw "Unexpected character encountered '$hexChar'. Provided hex string is not in valid format";
        }
    }

    #endregion

    # if we are not using little endian ordering, just convert hex
    # to expected data type for guid
    if ( -not $LittleEndian.IsPresent)
    {
        $a = [uint32]('0x' + $HexString.Substring(0, 8));
        $b = [uint16]('0x' + $HexString.Substring(8, 4));
        $c = [uint16]('0x' + $HexString.Substring(12, 4));
    }
    # in case we selected little endian ordering, let's swap bits and reorder
    # them to match little endian structure
    else
    {
        $aArray = ($HexString.Substring(0, 8) -replace '.{2}(?=.)','$0,').Split(',');
        $a = [uint32](
                [string]::Format('0x{3}{2}{1}{0}',
                $aArray[0],
                $aArray[1],
                $aArray[2],
                $aArray[3]                
            )
        );

        $bArray = ($HexString.Substring(8,4) -replace '.{2}(?=.)','$0,').Split(',');
        $b = [uint16](
            [string]::Format('0x{1}{0}',
                $bArray[0],
                $bArray[1]
            )
        );

        $cArray = ($HexString.Substring(12,4) -replace '.{2}(?=.)','$0,').Split(',');
        $c = [uint16](
            [string]::Format('0x{1}{0}',
                $cArray[0],
                $cArray[1]
            )
        );
    }

    # instantiate guid - https://msdn.microsoft.com/en-us/library/system.guid%28v=vs.110%29.aspx
    return New-Object System.Guid($a, $b, $c,
            [byte]::Parse($HexString.Substring(16,2), 'HexNumber'),
            [byte]::Parse($HexString.Substring(18,2), 'HexNumber'),
            [byte]::Parse($HexString.Substring(20,2), 'HexNumber'),
            [byte]::Parse($HexString.Substring(22,2), 'HexNumber'),
            [byte]::Parse($HexString.Substring(24,2), 'HexNumber'),
            [byte]::Parse($HexString.Substring(26,2), 'HexNumber'),
            [byte]::Parse($HexString.Substring(28,2), 'HexNumber'),
            [byte]::Parse($HexString.Substring(30,2), 'HexNumber')
        )

}

I usually store all functions in my PowerShell profile which automatically loads them in memory every time I start PowerShell session and can use them straight away. Here is simple scenario. If you use DirSync or AAD Connect to sync your on-premise identities to cloud, every object will use ImmutableId property to store mapping relation between cloud and on-premise user. By default, on-premise objectGuid property becomes cloud ImmutableId stored as Base64 string:

Get-MsolUser -UserPrincipalName user@domain.com | Select-Object ImmutableId

ImmutableId
-----------
etyLZDkvKUKZzTogkajbig==

Now we need to convert Base64 string to hex:

([Convert]::FromBase64String("etyLZDkvKUKZzTogkajbig==") | ForEach-Object { "{0:x}" -f $_ }) -join ""
7adc8b64392f294299cd3a2091a8db8a

And finally we can use Get-GuidFromHex to get actual guid ( hex has little endian ordering ):

Get-GuidFromHex -HexString "7adc8b64392f294299cd3a2091a8db8a" -LittleEndian

Guid
----
648bdc7a-2f39-4229-99cd-3a2091a8db8a

Retention: Which Retention Policy Tag is applied to message - EWS way

Ivan Franjić — Wed, 18 May 2016 05:35:31 GMT

In my last post I showed how to check which Retention Policy Tag is applied to the item within user's mailbox. In this post I'm going to show how same information can be checked using EWS. Compared to Get-StoreQuery way, using EWS is more convenient if you are using Office 365 mailboxes since you won't have access to Get-StoreQuery command . In this demonstration I'll use EWS PowerShell module I wrote while back. Module is still under developement. Please note, using commands and modules from this post are at your own risk. Download and install module:

Invoke-Expression -Command (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/IvanFranjic/XEws/master/InstallXEwsModule.ps1")

Create Ews session:

Import-EwsSession -EmailAddress "user@domain.com" -Password (ConvertTo-SecureString -AsPlainText -Force -String "pass") -EwsEndpoint "https://mail.domain.com/ews/exchange.asmx"

( If you omit parameter -EwsEndpoint, autodiscover will be used for locating correct endpoint ) Retreive message from desired folder and get retention tag:

$folder = Get-EwsFolder -FolderName "MyStuff"
Get-EwsItem -FolderRoot $folder.Id | select ConversationTopic, *Archive*, *Retention*
	
ConversationTopic ArchiveTag                           RetentionDate
----------------- ----------                           -------------
Important report  3afbf723-8f69-4a3d-8fdf-7254278dd560 3.5.2016. 12:43:20
Retention tag     3afbf723-8f69-4a3d-8fdf-7254278dd560 1.5.2016. 14:22:50
	
	
Get-RetentionPolicyTag 3afbf723-8f69-4a3d-8fdf-7254278dd560
	
Name                      Type                      Description
----                      ----                      -----------
Personal 60 Day Archive   Personal                  Managed Content Settings

Ews call returns .Net guid representation of the tag so result can be feeded directly in Get-RetentionPolicyTag Exchange cmdlet.

Retention: Which Retention Policy Tag is applied to message - Get-StoreQuery way

Ivan Franjić — Fri, 26 Feb 2016 15:26:58 GMT

In this post I'll explain how can you query store and check which Retention Policy Tag is applied to message. This is extremly useful if you don't have access to users mailbox / Outlook etc... Next posts ( when I get some time ) will address this using EWS. Problem statement: Check which retention policy tag is applied to messages in "MyStuff" folder for mailbox "adias". First you should load ManagedStoreDiagnosticFunctions.ps1 into memory. That script contains Get-StoreQuery function that will be use through this post.

[PS] C:\>cd $exscripts
[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>. .\ManagedStoreDiagnosticFunctions.ps1
[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>

Since first parameter of Get-StoreQuery is name of the database we are querying, we need to find out where mailbox is located:

[PS] C:\>Get-Mailbox adias | ft database, name -AutoSize

Database Name
-------- ----
DB01     Dias Ana

Next thing we need to find out is MailboxNumber within database since this will help us get to "MyStuff" folder:

[PS] C:\>Get-StoreQuery -Database DB01 -Query "select MailboxNumber from [DB01].Mailbox where DisplayName='Dias Ana'" | ft -AutoSize

MailboxNumber
-------------
          134

Now that we know MailboxNumber within database we need to find folder where messages of interest are located:

[PS] C:\>Get-StoreQuery -Database DB01 -Query "select FolderId, DisplayName from Folder where MailboxPartitionNumber=134"

FolderId                                                    DisplayName
--------                                                    -----------
0xE06990A3341D4C44B472B05AAFD8E81C00000000010800000100      Top of Information Store
0xE06990A3341D4C44B472B05AAFD8E81C00000000010900000100      Sent Items
0xE06990A3341D4C44B472B05AAFD8E81C00000000010A00000100      Deleted Items
0xE06990A3341D4C44B472B05AAFD8E81C00000000010B00000100      Outbox
0xE06990A3341D4C44B472B05AAFD8E81C00000000010C00000100      Inbox
0xE06990A3341D4C44B472B05AAFD8E81C00000000010D00000100      Calendar
0xE06990A3341D4C44B472B05AAFD8E81C00000000010E00000100      Contacts
0xE06990A3341D4C44B472B05AAFD8E81C00000000010F00000100      Drafts
0xE06990A3341D4C44B472B05AAFD8E81C00000000011000000100      Journal
0xE06990A3341D4C44B472B05AAFD8E81C00000000011100000100      Notes
0xE06990A3341D4C44B472B05AAFD8E81C00000000011200000100      Tasks
0xE06990A3341D4C44B472B05AAFD8E81C00000000011300000100      Recoverable Items
0xE06990A3341D4C44B472B05AAFD8E81C00000000011400000100      Deletions
0xE06990A3341D4C44B472B05AAFD8E81C00002987902E00000100      MyStuff

Finally get to the message:

[PS] C:\>$message = Get-StoreQuery -Database DB01 -Query "select * from Message where MailboxPartitionNumber=134 and FolderId=0xE06990A3341D4C44B472B05AAFD8E81C00002987902E00000100"

Message contains "PropertyBlob" property which is stored in Hex format and contains all message properties:

[PS] C:\>$message.PropertyBlob
0x50726F5000033600080823000000000050504100B80100004848420050020000505043005F02000048484400F6020000080857000100000008085
8000000000048486400000300004848650004030000484870007F0300005050190C8E03000048481A0C2604000048481E0C3504000048481F0C3904
00004848020EB40400004848030EB504000048481D0EB604000050504D0EC504000050504E0EE30400005050580E01050000484835101F050000505
00B304605000050501430580500005050183066050000505019307805000050501B308A05000038381C309805000018181D300000000018181E3041
00000038381F30A10500000808403A010000001818DE3FAF6F00001818F13F090400004848F83FAA0500005050F93FB90500004848FA3F510600005
050FB3F5B060000181819403D02000018181A403D02000018181C401100000048482340F2060000484825406D07000048483040E707000048483140
F607000048483840050800004848394014080000181859403D02000018185A407D0600004848015D1E0800004848025D3D0800004848E55F5C08000
01818C6650200000008081880010000000808298000000000519600000000DCA740C8C042101AB4B908002B2FE18201000000000000002F6F3D494E
542F6F753D45786368616E67652041646D696E6973747261746976652047726F7570202846594449424F484632335350444C54292F636E3D5265636
97069656E74732F636E3D64393036373263323134636334306434396437616136656665353361393134302D41646D696E6973747261746F72004D0D
41646D696E6973747261746F72519500000000DCA740C8C042101AB4B908002B2FE18201000000000000002F4F3D494E542F4F553D45584348414E4
7452041444D494E4953545241544956452047524F5550202846594449424F484632335350444C54292F434E3D524543495049454E54532F434E3D36
303936453838354132303534444433394343443034444135423539353730372D4D532E204449415320414E41004D084469617320416E614D0245584
D792F4F3D494E542F4F553D45584348414E47452041444D494E4953545241544956452047524F5550202846594449424F484632335350444C54292F
434E3D524543495049454E54532F434E3D44393036373243323134434334304434394437414136454645353341393134302D41444D494E495354524
1544F524D0D526574656E74696F6E20746167519600000000DCA740C8C042101AB4B908002B2FE18201000000000000002F6F3D494E542F6F753D45
786368616E67652041646D696E6973747261746976652047726F7570202846594449424F484632335350444C54292F636E3D526563697069656E747
32F636E3D64393036373263323134636334306434396437616136656665353361393134302D41646D696E6973747261746F72004D0D41646D696E69
73747261746F724D0245584D792F4F3D494E542F4F553D45584348414E47452041444D494E4953545241544956452047524F5550202846594449424
F484632335350444C54292F434E3D524543495049454E54532F434E3D44393036373243323134434334304434394437414136454645353341393134
302D41444D494E4953545241544F5248484D0D526574656E74696F6E20746167511C01050000000000051500000096D60630CB490B714D4AA0AEF40
10000511C01050000000000051500000096D60630CB490B714D4AA0AEF4010000511C01050000000000051500000096D60630CB490B714D4AA0AEF4
0100004D253C313435363439323933313834372E32303738374069742D656E67696E6565722E6F72673E511071AB2CD588B69D47AB665CEEBF0C71C
0510C03000000578DDE05FC4E2B9E511023F7FB3A698F3D4A8FDF7254278DD560511023F7FB3A698F3D4A8FDF7254278DD560510C01000000802D67
C89870D10138DB823D8FACA3D1013880ED408DACA3D1014D0D41646D696E6973747261746F72519600000000DCA740C8C042101AB4B908002B2FE18
201000000000000002F6F3D494E542F6F753D45786368616E67652041646D696E6973747261746976652047726F7570202846594449424F48463233
5350444C54292F636E3D526563697069656E74732F636E3D64393036373263323134636334306434396437616136656665353361393134302D41646
D696E6973747261746F72004D084469617320416E61519500000000DCA740C8C042101AB4B908002B2FE18201000000000000002F4F3D494E542F4F
553D45584348414E47452041444D494E4953545241544956452047524F5550202846594449424F484632335350444C54292F434E3D5245434950494
54E54532F434E3D36303936453838354132303534444433394343443034444135423539353730372D4D532E204449415320414E41004D792F4F3D49
4E542F4F553D45584348414E47452041444D494E4953545241544956452047524F5550202846594449424F484632335350444C54292F434E3D52454
3495049454E54532F434E3D44393036373243323134434334304434394437414136454645353341393134302D41444D494E4953545241544F524D78
2F4F3D494E542F4F553D45584348414E47452041444D494E4953545241544956452047524F5550202846594449424F484632335350444C54292F434
E3D524543495049454E54532F434E3D36303936453838354132303534444433394343443034444135423539353730372D4D532E204449415320414E
414D0D41646D696E6973747261746F724D0D41646D696E6973747261746F724D0D41646D696E6973747261746F724D084469617320416E614D1D416
46D696E6973747261746F724069742D656E67696E6565722E6F72674D1D41646D696E6973747261746F724069742D656E67696E6565722E6F72674D
0120

Not much of help, but there is function (ParsePropertyBlob) within database itself which takes PropertyBlob attribute and gives you human readeable property definition. Imagine as a stored procedure for SQL:

[PS] C:\>Get-StoreQuery -Database DB01 -Query "select * from ParsePropertyBlob($($message.PropertyBlob))" | ft -AutoSize

PropertyTag  PropertyName                                      PropertyType PropertyValue
-----------  ------------                                      ------------ -------------
0023:Boolean 00020328-0000-0000-c000-000000000046:N:0x00000023 Boolean      False
0041:Binary  00020328-0000-0000-c000-000000000046:N:0x00000041 Binary       0x00000000DCA740C8C042101AB4B908002B2FE1...
0042:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000042 Unicode      Administrator
0043:Binary  00020328-0000-0000-c000-000000000046:N:0x00000043 Binary       0x00000000DCA740C8C042101AB4B908002B2FE1...
0044:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000044 Unicode      Dias Ana
0057:Boolean 00020328-0000-0000-c000-000000000046:N:0x00000057 Boolean      True
0058:Boolean 00020328-0000-0000-c000-000000000046:N:0x00000058 Boolean      False
0064:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000064 Unicode      EX
0065:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000065 Unicode      /O=INT/OU=EXCHANGE ADMINISTRATIVE GROUP ...
0070:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000070 Unicode      Retention tag
0C19:Binary  00020328-0000-0000-c000-000000000046:N:0x00000C19 Binary       0x00000000DCA740C8C042101AB4B908002B2FE1...
0C1A:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000C1A Unicode      Administrator
0C1E:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000C1E Unicode      EX
0C1F:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000C1F Unicode      /O=INT/OU=EXCHANGE ADMINISTRATIVE GROUP ...
0E02:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000E02 Unicode
0E03:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000E03 Unicode
0E1D:Unicode 00020328-0000-0000-c000-000000000046:N:0x00000E1D Unicode      Retention tag
0E4D:Binary  00020328-0000-0000-c000-000000000046:N:0x00000E4D Binary       0x01050000000000051500000096D60630CB490B...
0E4E:Binary  00020328-0000-0000-c000-000000000046:N:0x00000E4E Binary       0x01050000000000051500000096D60630CB490B...
0E58:Binary  00020328-0000-0000-c000-000000000046:N:0x00000E58 Binary       0x01050000000000051500000096D60630CB490B...
1035:Unicode 00020328-0000-0000-c000-000000000046:N:0x00001035 Unicode      <1456492931847.20787@domain.org>
300B:Binary  00020328-0000-0000-c000-000000000046:N:0x0000300B Binary       0x71AB2CD588B69D47AB665CEEBF0C71C0
3014:Binary  00020328-0000-0000-c000-000000000046:N:0x00003014 Binary       0x03000000578DDE05FC4E2B9E
3018:Binary  00020328-0000-0000-c000-000000000046:N:0x00003018 Binary       0x23F7FB3A698F3D4A8FDF7254278DD560
3019:Binary  00020328-0000-0000-c000-000000000046:N:0x00003019 Binary       0x23F7FB3A698F3D4A8FDF7254278DD560
301B:Binary  00020328-0000-0000-c000-000000000046:N:0x0000301B Binary       0x01000000802D67C89870D101
301C:SysTime 00020328-0000-0000-c000-000000000046:N:0x0000301C SysTime      2016-05-01 13:22:50.3330523
301D:Int32   00020328-0000-0000-c000-000000000046:N:0x0000301D Int32        0
301E:Int32   00020328-0000-0000-c000-000000000046:N:0x0000301E Int32        65
301F:SysTime 00020328-0000-0000-c000-000000000046:N:0x0000301F SysTime      2016-05-01 13:22:47.0000000
3A40:Boolean 00020328-0000-0000-c000-000000000046:N:0x00003A40 Boolean      True
3FDE:Int32   00020328-0000-0000-c000-000000000046:N:0x00003FDE Int32        28591
3FF1:Int32   00020328-0000-0000-c000-000000000046:N:0x00003FF1 Int32        1033
3FF8:Unicode 00020328-0000-0000-c000-000000000046:N:0x00003FF8 Unicode      Administrator
3FF9:Binary  00020328-0000-0000-c000-000000000046:N:0x00003FF9 Binary       0x00000000DCA740C8C042101AB4B908002B2FE1...
3FFA:Unicode 00020328-0000-0000-c000-000000000046:N:0x00003FFA Unicode      Dias Ana
3FFB:Binary  00020328-0000-0000-c000-000000000046:N:0x00003FFB Binary       0x00000000DCA740C8C042101AB4B908002B2FE1...
4019:Int32   00020328-0000-0000-c000-000000000046:N:0x00004019 Int32        573
401A:Int32   00020328-0000-0000-c000-000000000046:N:0x0000401A Int32        573
401C:Int32   00020328-0000-0000-c000-000000000046:N:0x0000401C Int32        17
4023:Unicode 00020328-0000-0000-c000-000000000046:N:0x00004023 Unicode      /O=INT/OU=EXCHANGE ADMINISTRATIVE GROUP ...
4025:Unicode 00020328-0000-0000-c000-000000000046:N:0x00004025 Unicode      /O=INT/OU=EXCHANGE ADMINISTRATIVE GROUP ...
4030:Unicode 00020328-0000-0000-c000-000000000046:N:0x00004030 Unicode      Administrator
4031:Unicode 00020328-0000-0000-c000-000000000046:N:0x00004031 Unicode      Administrator
4038:Unicode 00020328-0000-0000-c000-000000000046:N:0x00004038 Unicode      Administrator
4039:Unicode 00020328-0000-0000-c000-000000000046:N:0x00004039 Unicode      Dias Ana
4059:Int32   00020328-0000-0000-c000-000000000046:N:0x00004059 Int32        573
405A:Int32   00020328-0000-0000-c000-000000000046:N:0x0000405A Int32        1661
5D01:Unicode 00020328-0000-0000-c000-000000000046:N:0x00005D01 Unicode      Administrator@domain.com
5D02:Unicode 00020328-0000-0000-c000-000000000046:N:0x00005D02 Unicode      Administrator@domain.com
5FE5:Unicode 00020328-0000-0000-c000-000000000046:N:0x00005FE5 Unicode
65C6:Int32   00020328-0000-0000-c000-000000000046:N:0x000065C6 Int32        2
8018:Boolean 00000000-0000-0000-0000-000000000000:N:0xFFFFFFFF Boolean      True
8029:Boolean 00000000-0000-0000-0000-000000000000:N:0xFFFFFFFF Boolean      False

There is lot of properties on message, but we are interested in this case only on 0x3019 (PidTagPolicyTag ) and that property contains following value:

3019:Binary  00020328-0000-0000-c000-000000000046:N:0x00003019 Binary       0x23F7FB3A698F3D4A8FDF7254278DD560

That hex string is GUID representation of policy tag that is stamped on message. So convert that hex value to guid and get policy tag:

Get-GuidFromHex -HexString '23F7FB3A698F3D4A8FDF7254278DD560' -LittleEndian
3AFBF723-8F69-4A3D-8FDF-7254278DD560

[PS] C:\>Get-RetentionPolicyTag 3AFBF723-8F69-4A3D-8FDF-7254278DD560

Name Type Description
---- ---- -----------
Personal 60 Day Archive Personal Managed Content Settings

Get-GuidFromHex function can be found on following link.

Authentication: Enabling Modern Auth (OAuth2)

Ivan Franjić — Sun, 07 Feb 2016 20:29:25 GMT

How many times you wanted to have Outlook seamless authentication on domain joined computers while connecting to Office 365 like it would do with on premise Exchange? I don't know about you, but I always liked Outlook profile creation without prompting user for entering credentials. This is great feature while Exchange is on-premise since it using either Kerb or NTLM. With moving user mailbox to Office 365, basic authentication for Outlook was only way for authenticating user. Users needed to enter their username / password combination and click "Save credentials" and everything was fine until user was changed password and prompt would pop up again. With introduction Modern Authentication for Office suite and Exchange 2016, Outlook seamless authentication experience is possible with Office 365 as well. Note // This is only tested with Exchange Hybrid environment. This post will be divided in three parts: 1. Enable modern authentication on Outlook client, 2. Set up intranet sites for STS, 3. Enable Oauth profiles feature in Office 365. Enable modern authentication on Outlook client Modern authentication (ADAL) in Outlook 2016 is enabled by default and it will be first mechanism that Outlook will try to use against Office 365. On the other hand, Outlook 2013 has it turned off by default and registry key should be used for enabling it . Navigate to HKCU:\Software\Microsoft\Office\15.0\Common\Identity and create new dword value "EnableADAL" and set it to value "1": Set up intranet sites for STS In order to get seamless experience while authenticating to STS, STS should be placed in "Local Intranet" zone and that zone should have option "Automatically login with current username and password" option set: Enable Oauth profiles feature in Office 365 Final step in this process is to enable OAuth2 Client Profile. Open PowerShell session to Office365 tenant and execute following command: Set-OrganizationConfig -OAuth2ClientProfileEnabled $true After that wait few minutes and you are all set. Create new Outlook profile (or wait until profile is automatically switch over to OAuth2) for user that have mailbox hosted in Office 365: You can check in connection status that Outlook is consuming "Bearer" (fancy name for Oauth) authentication: How it works? Lets go fiddling... I won't cover each step Outlook performs while connecting to service (you should know it already!?), just one's that matters. Fire up Fiddler! 1. Client make HTTP POST to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml

POST https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: text/xml
Authorization: Bearer
Cookie: OutlookSession="{1CF266D3-11FB-47D7-B0CD-CA3999D8D62D}"
User-Agent: Microsoft Office/16.0 (Windows NT 10.0; MAPI 16.0.4266; Pro)
X-MS-CookieUri-Requested: t
X-FeatureVersion: 1
Client-Request-Id: {57328DA9-DBD7-4D83-80F7-38778E9B8EB3}
X-MapiHttpCapability: 1
Depth: 0
X-AnchorMailbox: AGomes@itor.mail.onmicrosoft.com
X-User-Identity: Alice.Gomes@domain.com
Content-Length: 365
Host: autodiscover-s.outlook.com

AGomes@itor.mail.onmicrosoft.comhttp://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a

Response: 401 Unauthorized with authorization link https://login.windows.net/common/oauth2/authorize

HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/8.0
request-id: 41e440d8-c358-4bbe-9a94-664cfee0fc26
X-CalculatedBETarget: vi1pr08mb0832.eurprd08.prod.outlook.com
X-DiagInfo: VI1PR08MB0832
X-BEServer: VI1PR08MB0832
X-AspNet-Version: 4.0.30319
Set-Cookie: X-BackEndCookie2=AGomes@itor.mail.onmicrosoft.com=u56Lnp2ejJqBzcybyp2dxs3SzczMm9LLx8vK0p7NmZnSz8idz5ybzsrLxsqbgZaLkI3Rkp6Wk9GQkZKWnI2QjJCZi9GckJKBzc/OydLPzdLNyKvOyMXMysXPyYGaio2PjZvPx9GPjZCb0ZCKi5OQkJTRnJCSgc8=; expires=Sat, 27-Feb-2016 17:35:06 GMT; path=/autodiscover; secure; HttpOnly
Set-Cookie: X-BackEndCookie=AGomes@itor.mail.onmicrosoft.com=u56Lnp2ejJqBzcybyp2dxs3SzczMm9LLx8vK0p7NmZnSz8idz5ybzsrLxsqbgZaLkI3Rkp6Wk9GQkZKWnI2QjJCZi9GckJKBzc/OydLPzdLNyKvOyMXMysXPyYGaio2PjZvPx9GPjZCb0ZCKi5OQkJTRnJCSgc8=; expires=Sat, 27-Feb-2016 17:35:06 GMT; path=/autodiscover; secure; HttpOnly
X-Powered-By: ASP.NET
X-FEServer: AM4PR01CA0024
WWW-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@*", token_types="app_asserted_user_v1 service_asserted_app_v1", authorization_uri="https://login.windows.net/common/oauth2/authorize",Basic Realm="",Basic Realm=""
Date: Thu, 28 Jan 2016 17:35:06 GMT
Content-Length: 58

You do not have permission to view this directory or page.

2. Client submits HTTP GET against login.microsoft.com and request contains user email address: Request:

GET https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c&redirect_uri=urn%3aietf%3awg%3aoauth%3a2.0%3aoob&resource=https%3a%2f%2fautodiscover-s.outlook.com%2f&nux=1&login_hint=AGomes%40domain.com HTTP/1.1
Accept: */*
client-request-id: 75FE0558-9C26-46D5-AED6-E831CC28E4F8
return-client-request-id: false
x-client-BSSO: on
x-ms-PKeyAuth: 1.0
x-client-SKU: Win32
x-client-Ver: v1.0.2016.0
x-client-OS: 10.0.10586
Accept-Language: hr-HR
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; Trident/7.0; .NET4.0C; .NET4.0E)
Host: login.microsoftonline.com
Connection: Keep-Alive

Response (redirect to OnPrem STS):

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Expires: -1
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
x-ms-request-id: c3a5cbf0-2a91-48bd-aa16-8f3da5ddc34a
client-request-id: 75fe0558-9c26-46d5-aed6-e831cc28e4f8
x-ms-gateway-service-instanceid: ESTSFE_IN_152
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: flight-uxoptin=true; path=/; secure; HttpOnly
Set-Cookie: x-ms-gateway-slice=productionb; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/; secure; HttpOnly
X-Powered-By: ASP.NET
Date: Thu, 28 Jan 2016 17:35:08 GMT
Content-Length: 5503

setTimeout(function () { window.location.replace('https://sts.domain.com:443/adfs/ls/?login_hint=AGomes%40domain.com\u0026username=AGomes%40domain.com\u0026wa=wsignin1.0\u0026wtrealm=urn%3afederation%3aMicrosoftOnline\u0026wctx=estsredirect%3d2%26estsrequest%3drQIIAXWPP0vDQByGuaQK1qHiIDhbRIS73J-kMTfZRUdX18vlkgZNfpJcKvgxOvsJOnRwkn4GhyyKOIpDP0InMXUVl-eFB94X3v7ulBFKOGUjQk9dRpgcJiKIqElGOOCxwD6jHCuTpliphPOIq5gyXe339663vpvjx9eLxduKvZx8refosKlKmRubyvtMgmrsRHJCJUD8jFCL0AqhmXMwvoTC1Oe5xabM8tKYikCVtQ76cAZX467EN4AqfzCff8zMHfwOc7KhhsTM3aOJtXe19LxOQZLXGqamwjWBxt4C3BANhffkbndRQLl0hzGlZzTWPk5EqLGvUoEjxRj2Q6G50iII_ejdRW0PrXtoufP_qx81'); }, 0);

3. STS authenticate client and return it back to login.microsoft.com:

HTTP/1.1 200 OK
Cache-Control: no-cache,no-store
Pragma: no-cache
Content-Length: 6244
Content-Type: text/html; charset=utf-8
Expires: -1
Server: Microsoft-HTTPAPI/2.0
X-XSS-Protection: 0
Set-Cookie: MSISAuth=AAEAACaKnyhiKMDsU02wKcnNYfD7tWo1KRGJ/fD7i4WRP18D+TF1YT5vIn7pkaqDR5ehab8dRaFQXCwo5/A6PWthIczezmUYedt7p0367VF7tMercBr3fJlN36lMUcuDRSCdxeFdXRvwLJCfg2zlfg+TRZ6LAfW0s4zEGToviA79Mm0FfLi7AKCcY0nKwKDYh2FCcywEThmcX1910GzPSb4Pof3wscCDEV5D4EjR/oN4qKGylX0mBKz8DQY/nPQqwyt4HqPY6mKvh9prY70gZHkz42bY4h3UKtxpQXfKiFYMU/3lnv06CMr9PvXKqRwZj+EFe4/L0Men3LPvF6/sl8zO0n2Klxvk4THVNMzJR6xO67E5sir2ljdWjrjDgkb6VZ/YmgABAAAu/gCwAMgev4k2w/CmwaBO6vLb/RgrZvrDMWfmoVd7WMdyFJqczkhg4iSAFCzDMTLvwfdqeuHlUObcPby1RHOHVDaksSEAiPQMZwWe8cs0qZwRvwr283X4qsXofArV09L26HdHTE72jgu+zNA57mgU9VXxFKyg1V+PkK31qGgRKupqtaXVT3OlKyZCwBMKAFDa9jOSMFUn8nzFyEnZVRXI/V6SE36V0ienkFaVjzdj5VYZlqls7cYAFo/1AJYh6m9Z9jQu1FzCGeeb5I9zgshR+QbcqxpkG+5h1ZysUqZzz+3BlzBiku5fZfEHIDeqmadGfdZEuzZsquwv0Vyq5KeukAIAACEFAAJ3Fz4gsVzt4MV5Z16vGPD0Dfizus1wJ/f0QGMfvHTL65imWk15I8VjyfmnrBM07y+ndm1GT2IXOX7htJbRShmdfN3ep9BocEisluqTuIBD5j0JgAqGPtlNeaX9vzjVjcaIq8aOhxGCb7XdTR5HsccQOcBo9VrWpspShxGsI1wj/AhxcrYckOdz9grDz3fXUGnsCdx8kXk2eCKP88Ol8JrprDGt2Fbrtp371uC4Y/gVOInIjiDQDHy2WUGMtkomHQ054WbIF2qevoARdb8oEFRA4cZIazgNz0pTd6zESGxsdVsk2lsVmuLI6qWbAyef5vKfkheo+M64UtKXQbh1RaiAqmuxN8drxQhPgs85mFopM2pg14v5/gcJhkKBqS3JscUOOAwejj5AbevVw8xVQpHpBh6XY448C/CBpJFKdo/LEcp+o8pf9ku3pAoELya9gnESBhZVSnsLPrmrUIGjULRvaR73UhP/Yjp6VI6xU4AIbfEo0avGhEU2H+ABPIm4nBpxQMlB9wZXadgPI/L0mckljPxQAnde3Bx7mZ1ypukFPbUd6TE32TBuq5PuXkpIAhoaAAY2P04vVuN56NqJpZzb1/Fvw4ZlVplswqwurcTAXkk7nwX36DWZhCmbmu/5nWETJ2ZlGQJVl/i9EsR7jRzfDxjRRGX6gerJ6zqXLBjfTRRE1izw0Xk7FroPAOrW29tbCjecSW54SjUiMbHfwSfMB+nUXoMGYJDPgFQXKwHVmOjzlYkVkzbOf/Q7HRyZSbkCADqkR7WHv2Kew4WVXYsPzMb4sF4OCsszrumdHqpWXQvmjwiv8AHMI8KcPbLkBrUQOlK/PUDHXpi1OhTg99Yjk33GcCJYA9BSAi0f; path=/adfs; HttpOnly; Secure
Set-Cookie: MSISSignOut=c2lnbm91dENsZWFudXA7dXJuJTNhZmVkZXJhdGlvbiUzYU1pY3Jvc29mdE9ubGluZSZNaWNyb3NvZnQrT2ZmaWNlKzM2NStJZGVudGl0eStQbGF0Zm9ybSZodHRwcyUzYSUyZiUyZmxvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20lMmZsb2dpbi5zcmYmaHR0cHMlM2ElMmYlMmZsb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tJTJmbG9naW4uc3JmXA==; path=/adfs; HttpOnly; Secure
Set-Cookie: MSISAuthenticated=MjguMS4yMDE2LiAxNzozNTowNQ==; path=/adfs; HttpOnly; Secure
Set-Cookie: MSISLoopDetectionCookie=MjAxNi0wMS0yODoxNzozNTowNVpcMQ==; path=/adfs; HttpOnly; Secure
WWW-Authenticate: oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARu03ZIshvo2zaqdk/XmgkDMwqT3eyknJWhyB2OkCyulZ52eQEz5c3tLa0Fzf5eY9DO16MBvkV5e008JdyJU9PMy2NfHKlqr0ri1OLAZauuJWNsSFdF4Eh91IzPBH5kyU/eRrQrJC4O5d4HY27vTcY=
Date: Thu, 28 Jan 2016 17:35:04 GMT

AB: Address List is not updating

Ivan Franjić — Sun, 07 Feb 2016 12:34:06 GMT

Every time working with Exchange issues is completely new adventure. So it was with this one as well. Custom address book wasn't updating members. Address book was configured to update member based on specific string in CustomAttribute5. First thing to check was actual address list and filter that list is using:

Get-AddressList "Test Address List" | fl *

Container                    : \
Path                         : \Test Address List
DisplayName                  : Test Address List
Name                         : Test Address List
RecipientFilter              : ((CustomAttribute5 -eq 'Test String') -and (Alias -ne $null))
LdapRecipientFilter          : (&(extensionAttribute5=Test String)(mailNickname=*))
LastUpdatedRecipientFilter   : ((CustomAttribute5 -eq 'Test String') -and (Alias -ne $null))
RecipientFilterApplied       : True
IncludedRecipients           :
ConditionalDepartment        : {}
ConditionalCompany           : {}
ConditionalStateOrProvince   : {}
ConditionalCustomAttribute1  : {}
ConditionalCustomAttribute2  : {}
ConditionalCustomAttribute3  : {}
ConditionalCustomAttribute4  : {}
ConditionalCustomAttribute5  : {}
ConditionalCustomAttribute6  : {}
ConditionalCustomAttribute7  : {}
ConditionalCustomAttribute8  : {}
ConditionalCustomAttribute9  : {}
ConditionalCustomAttribute10 : {}
ConditionalCustomAttribute11 : {}
ConditionalCustomAttribute12 : {}
ConditionalCustomAttribute13 : {}
ConditionalCustomAttribute14 : {}
ConditionalCustomAttribute15 : {}
RecipientContainer           :
RecipientFilterType          : Custom
Identity                     : \Test Address List
IsValid                      : True
ExchangeVersion              : 0.1 (8.0.535.0)
Id                           : \Test Address List

After that we wanted to make sure that we are getting recipients while querying that RecipientFilter:

Get-Recipient -RecipientPreviewFilter { ((CustomAttribute5 -eq 'Test String') -and (Alias -ne $null)) }

Name     RecipientType
----     -------------
John Doe MailContact

Filter is returning object. So far so good. Checking recipient address list membership showed only membership to defaults, without custom address book:

$mailContact = Get-MailContact "John Doe"
$mailContact.AddressListMembership
\All Contacts(VLV)
\All Recipients(VLV)
\Default Global Address List
\All Contacts

Running Update-AddressList manually was updated address list membership:

Get-AddressList "Test Address List"  | Update-AddressList
$mailContact = Get-MailContact "John Doe"
$mailContact.AddressListMembership
\Test Address List
\All Contacts(VLV)
\All Recipients(VLV)
\Default Global Address List
\All Contacts

Searched eventlogs but nothing strange was reported for address list activities. Looking more deeply what Update-AddressList is doing you can notice calls to "Rus Agent" (Recipient Update Service Agent):

Get-AddressList "Test Address List"  | Update-AddressList -Verbose
VERBOSE: [11:03:51.097 GMT] Update-AddressList : Runspace context: Executing user: domain.com/Users/Administrator, Executing user organization: , Current organization: , RBAC-enabled: Enabled.
VERBOSE: [11:03:51.425 GMT] Update-AddressList : Active Directory session settings for 'Update-AddressList' are: View Entire Forest: 'False', Default Scope: 'domain.com', Configuration Domain Controller:
'DC.domain.com', Preferred Global Catalog: 'DC.domain.com', Preferred Domain Controllers: '{ DC.domain.com }'
VERBOSE: [11:03:51.441 GMT] Update-AddressList : Beginning processing Update-AddressList
VERBOSE: [11:03:51.456 GMT] Update-AddressList : Instantiating handler with index 0 for cmdlet extension agent "Rus Agent".
VERBOSE: [11:03:51.456 GMT] Update-AddressList : Instantiating handler with index 1 for cmdlet extension agent "Admin Audit Log Agent".
VERBOSE: [11:03:51.472 GMT] Update-AddressList : Current ScopeSet is: { Recipient Read Scope: {{, }}, Recipient Write Scopes: {{, }}, Configuration Read Scope: {{, }}, Configuration Write Scope(s): {{, }, }, Exclusive Recipient
Scope(s): {}, Exclusive Configuration Scope(s): {} }
VERBOSE: [11:03:51.487 GMT] Update-AddressList : Searching objects "\Test Address List" of type "AddressBookBase" under the root "$null".
VERBOSE: [11:03:51.487 GMT] Update-AddressList : Previous operation run on domain controller 'DC.domain.com'.
VERBOSE: [11:03:51.487 GMT] Update-AddressList : The current object has been processed by the cmdlet extension agent with index 0.
VERBOSE: [11:03:51.487 GMT] Update-AddressList : The current object has been processed by the cmdlet extension agent with index 1.
VERBOSE: [11:03:51.487 GMT] Update-AddressList : Processing object "\Test Address List".
VERBOSE: [11:03:51.487 GMT] Update-AddressList : [Microsoft Cmdlet Extension Agent] Validating object "\Test Address List" of type "AddressBookBase".
VERBOSE: [11:03:51.487 GMT] Update-AddressList : Admin Audit Log: Entered Handler:Validate.
VERBOSE: [11:03:51.487 GMT] Update-AddressList : Admin Audit Log: Exited Handler:Validate.
VERBOSE: Updating all recipients matching the filter of address list "\Test Address List".
VERBOSE: [11:03:51.487 GMT] Update-AddressList : Resolved current organization: .
VERBOSE: [11:03:51.878 GMT] Update-AddressList : Saving object "\Test Address List" of type "AddressBookBase" and state "Unchanged".
VERBOSE: [11:03:51.878 GMT] Update-AddressList : Previous operation run on domain controller 'DC.domain.com'.
VERBOSE: [11:03:51.878 GMT] Update-AddressList : Admin Audit Log: Entered Handler:OnComplete.
VERBOSE: [11:03:52.206 GMT] Update-AddressList : Admin Audit Log: Exited Handler:OnComplete.
VERBOSE: [11:03:52.222 GMT] Update-AddressList : Ending processing Update-AddressList

"Rus Agent" is executed every time recipient related cmdlet is called, which means that every time Set-Recipient (Set-MailContact, Set-Mailbox, etc...) is executed. Why "Rus Agent" didn't run when Set-MailContact was used (Set-MailContact -CustomAttribute5 'Test String'). Searched admin audit log to see when command was executed to get something to work with:

Search-AdminAuditLog -Cmdlets Set-MailContact

Returns nothing? Ran Search-AdminAuditLog without any parameters just to see if anything will be returned:

Search-AdminAuditLog

RunspaceId         : 7f9ae249-1393-4af6-9705-839faddfd148
ObjectModified     : \Test Address List
CmdletName         : Update-AddressList
CmdletParameters   : {Verbose, Identity}
ModifiedProperties : {}
Caller             : domain.com/Users/User
ExternalAccess     : False
Succeeded          : True
Error              :
RunDate            : 
OriginatingServer  : EXCHANGE (15.00.1130.005)
Identity           : AAMkADNkOWZkMDFkLThiOTQtNDc0My05ZmVlLWViOTdmODkzYWYzOABGAAAAAAAsKgfCgkDVTbCL/MvE2gSABwCf9J8M2CH1SoFNuEBYOhBbAAAAAAEYAACf9J8M2CH1SoFNuEB
                     YOhBbAAAi9M0qAAA=
IsValid            : True
ObjectState        : New

How command Set-MailContact was executed if it's not in audit logs? Explanation is actually very simple - Set-ADObject. Recipient CustomAttribute5 was updated through Active Directory PowerShell module and because update wasn't done through Exchange console, "Rus Agent" is never called, hence showInAddressBook AD attribute was never updated which caused recipient not showing in custom address list. Every time you want to make custom address list, make sure you either set filtering attribute values through Active Directory (PowerShell or ADUC) prior creation address list, or update those attributes through Exchange management shell afterwards.

RBAC: Remote Scripts

Ivan Franjić — Mon, 01 Feb 2016 11:16:28 GMT

Ever wanted to execute commands on Exchange server other than built-in Exchange cmdlet in remote powershell session? Exchange 2013 onwards RBAC model introduced "Unscoped Role Management" management role which allows creating management role without specifying parent role. Beside putting only cmdlets (management entries) inside management role, unscoped role allows assigning scripts as a management entry. This topic will address following scenario:

Administrator have access only to Exchange remote PowerShell over Internet,
Administrator needs to have ability to execute Get-Service cmdlet only on Exchange servers.

I have already prepared Get-Service.ps1 script and it is available for download. Note: Details how to create proxy script Will be covered in one of the upcoming posts. Copy script Get-Service.ps1 in { Exchange Install Path }\RemoteScripts (usually "C:\Program Files\Microsoft\Exchange Server\V15\RemoteScripts") Now it's time to create unscoped management role and assign coresponding management entry.

New-ManagementRole -Name "HelpDesk Scripts" -UnScopedTopLevel -Description "Role will contain HelpDesk scripts"
Add-ManagementRoleEntry "HelpDesk Scripts\Get-Service.ps1" -UnScopedTopLevel -Parameters Name, ComputerName, ShowOnlyExchangeServices

Management role must be linked to role group which leads you to two options:

Create new role group,
Link management role to existing role group.

In this example I'll link management role to the existing "Organization Management" role group:

New-ManagementRoleAssignment -Name "HelpDesk Scripts - Organization Management" -SecurityGroup "Organization Management" -Role "HelpDesk Scripts"

After all steps are done, create new session to the remote Exchange shell and you should see Get-Service.ps1 script included in remote commands:

Get-Command Get-Service.ps1 | Select-Object Name, Source

Name            Source
----            ------
Get-Service.ps1 tmp_smlv3kdj.nfc

Get-Service.ps1 -ShowOnlyExchangeServices

Status   Name               DisplayName
------   ----               -----------
Running  MSExchangeADTop... Microsoft Exchange Active Directory...
Running  MSExchangeAntis... Microsoft Exchange Anti-spam Update
Running  MSExchangeDagMgmt  Microsoft Exchange DAG Management
Running  MSExchangeDelivery Microsoft Exchange Mailbox Transpor...
Running  MSExchangeDiagn... Microsoft Exchange Diagnostics
Running  MSExchangeEdgeSync Microsoft Exchange EdgeSync
Running  MSExchangeFastS... Microsoft Exchange Search
Running  MSExchangeFront... Microsoft Exchange Frontend Transport
Running  MSExchangeHM       Microsoft Exchange Health Manager
Stopped  MSExchangeImap4    Microsoft Exchange IMAP4
Stopped  MSExchangeIMAP4BE  Microsoft Exchange IMAP4 Backend
Running  MSExchangeIS       Microsoft Exchange Information Store
Running  MSExchangeMailb... Microsoft Exchange Mailbox Assistants
Running  MSExchangeMailb... Microsoft Exchange Mailbox Replication
Stopped  MSExchangePop3     Microsoft Exchange POP3
Stopped  MSExchangePOP3BE   Microsoft Exchange POP3 Backend
Running  MSExchangeRepl     Microsoft Exchange Replication
Running  MSExchangeRPC      Microsoft Exchange RPC Client Access
Running  MSExchangeServi... Microsoft Exchange Service Host
Running  MSExchangeSubmi... Microsoft Exchange Mailbox Transpor...
Running  MSExchangeThrot... Microsoft Exchange Throttling
Running  MSExchangeTrans... Microsoft Exchange Transport
Running  MSExchangeTrans... Microsoft Exchange Transport Log Se...
Running  MSExchangeUM       Microsoft Exchange Unified Messaging
Running  MSExchangeUMCR     Microsoft Exchange Unified Messagin...

This feature is available only for on-premise Exchange 2013 onwards. Get-Service

Managed Availability: Outbound Authentication failed with TargetUnknown

Ivan Franjić — Sat, 30 Jan 2016 18:40:13 GMT

Recently I was working with Managed Availability that fired up the alert "Outbound Authentication failed with TargetUnknown" on the server SERVER01. Looking in the "ProbeResults" of Managed Availability crimson channel "Microsoft-Exchange-ActiveMonitoring/ProbeResult", probe was failing very often, but probe results didn't gave me much of information. Testing server health didn't showed anything as "Unhealthy":

Get-ServerHealth $env:COMPUTERNAME | Where-Object {$_.AlertValue -eq "Unhealhty"}

Probe results were still failing and SCOM fired alerts over and over again. Since all SMTP sessions are stored in connectivity logs, checking it was next decision. Performed search of the latest connectivity log with pattern "Failed" and that gave me answer to my question, why probes are failing:

[PS] C:\Windows\system32>Get-Content "C:\{ Exchange Install Path }\TransportRoles\Logs\Hub\Connectivity\CONNECTLOG20151219-1.LOG" | Select-String -Pattern "Failed"
	
2015-12-19T04:29:04.035Z,08D2F893AD59193C,SMTP,Failed connection to 192.168.100.2:717 (TimedOut:0000274C)[TargetHost:SERVER02.domain.com:717|MarkedUnhealthy|FailureCount:1|NextRetryTime:2015-12-19T04:30:04.035Z][TargetIPAddress:192.168.100.2:717|MarkedUnhealthy|FailureCount:1|NextRetryTime:2015-12-19T04:30:04.035Z]

Basically, probes were failing while SERVER01 tried to execute SMTP transaction to another server in same site - SERVER02. Tried telnet to SERVER02 on port 717 (Outbound Proxy Connector port), but connection was failing:

[PS] C:\Windows\system32>telnet SERVER02 717
Connecting To SERVER02...Could not open connection to the host, on port 717: Connect failed

Checked transport service on SERVER02, and it was stopped:

[PS] C:\Windows\system32>get-service *transport* -ComputerName SERVER02

Status   Name               DisplayName
------   ----               -----------
Stopped MSExchangeFront... Microsoft Exchange Frontend Transport

Started service on remote server and probe stopped firing alerts. Why Frontend Transport was stopped and why probe was not failing for that component on SERVER02 is part of another story.

AD: LDAP search - OctetString

Ivan Franjić — Fri, 29 Jan 2016 14:24:31 GMT

Ever needed to search Active Directory objects by attribute value which is storing guids? On the first, process seems fair easy, but soon after executing command like Get-ADObject -LDAPFilter "(objectGuid=b0ae470c-16bc-4019-b455-8c96ec515f55)" and you get nothing, big question mark pops up above your head. I won't explain exact scenario because it's tied to environment I'm working with, but let's just say that attribute was storing guid value. objectGuid attribute will be used for demonstration together with Get-ADObject cmdlet, even though you can implement your own DirectorySearcher if you like. So, this is how it started. Run search with Ldap filter "(objectGuid=b0ae470c-16bc-4019-b455-8c96ec515f55)" and got nothing. First thing I done was looking on the attribute through AdsiEdit and at first glance everything seemed just fine: But while I double clicked on the property, it was actually showing me that attribute value is in some other format than just plain string (Octet String): I run simple query agains attribute in schema to confirm what exactly DirectorySearcher will expect (Syntax):

([DirectoryServices.ActiveDirectory.ActiveDirectorySchema]::GetCurrentSchema()).FindProperty("objectGuid")


Name                   : objectGuid
CommonName             : Object-Guid
Oid                    : 1.2.840.113556.1.4.2
Syntax                 : OctetString
Description            : 
IsSingleValued         : True
IsIndexed              : True
IsIndexedOverContainer : False
IsInAnr                : False
IsOnTombstonedObject   : True
IsTupleIndexed         : False
IsInGlobalCatalog      : True
RangeLower             : 16
RangeUpper             : 16
IsDefunct              : False
Link                   : 
LinkId                 : 
SchemaGuid             : bf9679e7-0de6-11d0-a285-00aa003049e2

From what we are able to see, DirectorySearcher was expecting typeOf OctetString. So I dig little bit further on MSDN (https://msdn.microsoft.com/en-us/library/windows/desktop/ms180873%28v=vs.80%29.aspx) which showed example for a SID, but I ended up writing something similar for guids:

function Get-OctetStringFromGuid
{
    [CmdletBinding()]
    param
    (
        [System.Guid]
        $GuidToConvert
    )
    
    return ("\" + ([System.String]::Join('\', ($GuidToConvert.ToByteArray() | ForEach-Object { $_.ToString('x2') }))));   
}

Feed function with a guid and returned result pass to DirectorySearcher:

Get-OctetStringFromGuid -GuidToConvert b0ae470c-16bc-4019-b455-8c96ec515f55 
\2c\47\ae\b0\bc\16\19\40\b4\55\8c\96\ec\51\5f\55

Get-ADObject -LDAPFilter "(objectGuid=\2c\47\ae\b0\bc\16\19\40\b4\55\8c\96\ec\51\5f\55)" | fl

DistinguishedName : CN=Administrator,CN=Users,DC=int,DC=domain,DC=com
Name              : Administrator
ObjectClass       : user
ObjectGUID        : b0ae470c-16bc-4019-b455-8c96ec515f55