Office 365 EWS-GetUserAvailability ID 为 null

Question

I am connecting to Exchange on 365 using EWS and using the GetUserAvailability method on the ExchangeService object to retrieve a collection of calendar items for a number of users (no more that 30).

My user that I am using to connect to EWS has impersonation rights and everything is working with the exception of one thing.

When I loop through the AttendeesAvailability collection, and then through each CalendarEvent within its CalendarEvents collection, I am able to see the Details object and access things like the Subject, Location, IsPrivate, etc...

The problem I have, is that the Details.StoreId is always null.

I have two 365 Exchange environments, our and a client's. When I try and access the StoreId on ours, it works absolutely fine and has the unique ID as expected. When I run the same come on the client's instance, it is null; but all the other properties are populated for the Details object.

This lead me to believe that it was a permissions issue for the service user within Exchange. So, I have slowly raised the permissions levels, hoping to hit the sweet spot, but nothing. The user is now an Exchange Admin (which I believe should have blanket access to anything and everything within the Exchange environment - including calendar items for each person's mailbox). Still not joy.

So, is it a configuration issue with the Exchange setup?

It is worth noting that all the other functionality that my application has, works perfect. It is just this ID that I am missing.

I am at a loss on this one. If it wasn't for the fact that I have shaved my head due to the lock down, I would be pulling my hair out right about now.

Any help or suggestions would be greatly appreciated.

Cheers

UPDATE 1

So, I have found that if I perform the same process on the service account that I am authenticating with, I get the StoreId back. This account was created after the migration from on-prem to O365 (which may mean nothing). I am in the process of getting access to another account that has been created since the migration to see if it works for that one as well. This will help me identify if the issue is likely to be with the migrated mailboxes only or with any mailbox apart from the account used to authenticate. I will update soon...

UPDATE 2

I have tested against a new account. I set the default permissions on the new account's calendar to Reviewer (even tried Owner and Anonymous just for a sanity check). When I authenticate using the service account, I don't get the StoreId. When I authenticate using the new test account, I do get the StoreId.

This leads me to believe that it is a permissions issue. It's now a case of finding out what that magic permissions is. It still eludes me as to why it is only the ID that I don't get back.

Still open to any suggestions.

UPDATE 3

It looks like it may be something different between build versions on EWS.

The version that works is reporting a server version of 15.20.3021.030. The version that does not work is version 15.20.3045.019.

Answer 1

So, it's been a while, but Microsoft have now fixed the issue and the existing code is now working fine.

I can also confirm that this work when using OAuth as well.

Answer 2

The problem is probably related to not having sufficient rights from the account you use for the Exchange Service authentication to the target account. Use the command below to give rights and try again.

Add-MailboxFolderPermission -Identity User@domain.com:\Calendar -User serviceceaccount@domain.com -AccessRights Reviewer

This is a very annoying issue, I have opened an incident with MS in the past, but got the disappointing answer that this won't change soon.

Below is the PS code to set rights to all users, rooms, resources, regardless of culture (language) and name of the calendar folder.

Param(
     [parameter(position=0,Mandatory=$true)][string] $serviceaccount,
     [parameter(position=1,Mandatory=$true)][string] $mailboxtype
)

$acl = "Reviewer"

if ($mailboxtype -eq "All") {
    $mailboxes = Get-Mailbox | Where {$_.RecipientTypeDetails -eq "UserMailbox" -or $_.RecipientTypeDetails -eq "RoomMailbox" -or $_.RecipientTypeDetails -eq "EquipmentMailbox"} | Select -expand PrimarySmtpAddress | Select -expand Address | Where {$_ -NotLike "Administrator@*"}
}
elseif ($mailboxtype -eq "Users") {
    $mailboxes = Get-Mailbox | Where {$_.RecipientTypeDetails -eq "UserMailbox"} | Select -expand PrimarySmtpAddress | Select -expand Address | Where {$_ -NotLike "Administrator@*"}
}
elseif ($mailboxtype -eq "Resources") {
    $mailboxes = Get-Mailbox | Where {$_.RecipientTypeDetails -eq "RoomMailbox" -or $_.RecipientTypeDetails -eq "EquipmentMailbox"} | Select -expand PrimarySmtpAddress | Select -expand Address
}
else {
"Error specifying target mailbox type. Choose one of: 'All', 'Users' or 'Resources'.`n
'All' - UserMailbox, RoomMailbox, EquipmentMailbox.`n
'Users' - UserMailbox.`n
'Resources' - RoomMailbox, EquipmentMailbox."
}

foreach ($mbx in $mailboxes)
{
    $calName = Get-MailboxFolderStatistics -Identity $mbx -FolderScope Calendar | Where-Object { $_.FolderType -eq 'Calendar'} | Select-Object Name, FolderId #-ErrorAction Stop
    #echo "${mbx}:\$($calName.Name)"
    Add-MailboxFolderPermission -Identity ${mbx}:\$($calName.Name) -User $serviceaccount -AccessRights $acl | Select-Object Identity, FolderName, User, AccessRights
}

Save as PS script, call with two params: serviceaccount & mailboxtype