On-premise Exchange 2013 CU22/PowerShell EWS authorization problems

[dayzd]

I've recently upgraded my Exchange 2013 server with CU22.

 

Since doing so, any Powershell scripts I have that use EWS all fail with '401 Unauthorized' errors the first time the script tries to bind to a folder.

 

I understand 401s are normally caused by credential problems, but I've checked I'm using the correct details and I can log in with OWA. EWSEditor can also connect to the mailboxes I need.

 

I'm so confused. Nothing has changed, other than the CU update (which was a mare to install). All my scripts, user accounts, permissions and passwords have not been touched.

 

Is there much in the way of configuration or permissions I can look at?

Can anyone spot what might be set up badly in the below script?

 

# Modified from: https://www.linkedin.com/pulse/powershell-script-ews-working-calendar-items-using-managed-chauhan

Param(
   $EmailAddress,
   $cred,
   [system.URI]$fullEWSUrl
)
$searchStart = (Get-Date).AddDays(-31) # The EWS API can only return a max range of 2 years.
$searchEnd = (Get-Date).AddDays(699) # Set Start to one month ago, and end to 23 months from now
$itemsView = 5000
$userName = $cred.UserName
$password = $cred.GetNetworkCredential().password
$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll"

Import-Module $dllpath
$ExchangeVersion = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2013
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService($ExchangeVersion)
$service.Credentials = New-Object Microsoft.Exchange.WebServices.Data.WebCredentials -ArgumentList $userName, $password
$service.url = $fullEWSUrl
# Take out this impersonation line, and we can search our own mailboxes. This will work for the schedule accounts, as we use them directly with their own credentials already
# $service.ImpersonatedUserId = New-Object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId ([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SMTPAddress,$EmailAddress)

$Folderid = new-object Microsoft.Exchange.WebServices.Data.FolderId ([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar,$EmailAddress)
$cal = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$Folderid)

# Define the calendar view
$CalendarView = New-Object Microsoft.Exchange.WebServices.Data.CalendarView($searchStart,$searchEnd,$itemsView)    
$findCalItems = $service.FindAppointments($Cal.Id,$CalendarView)

$findCalItems | Select Start,End,Duration,AppointmentType,Subject,Location,Organizer,DisplayTo,DisplayCC,HasAttachments,IsReminderSet,ReminderDueBy

 

The script is run by a domain admin, but used the password for each mailbox it accesses as it is run. I've rebooted everything, reset account passwords and used known good details throughout, reset the EWS virtual directory... I'm no Exchange specialist, and I've run out of things to try!

 

Help!?

[dayzd]

Dear people from the future, finding this long-abandoned post through an obscure Google search,

 

I fixed this problem by running my scripts from a machine that was not my Exchange server.

 

I'd always run my calendar-based scheduled tasks on the Exchange server because it made sense - server with calendars + script querying calendars = run scripts here.

I guess one of the security changes introduced in CU22 that affected EWS functionality was where it would accept requests from.

 

I now have all my scripts working again, simply by installing EWS on a different server and running them there, instead.

[thirdman]

Dear people from the future, finding this long-abandoned post through an obscure Google search,

I fixed this problem by running my scripts from a machine that was not my Exchange server.

I'd always run my calendar-based scheduled tasks on the Exchange server because it made sense - server with calendars + script querying calendars = run scripts here.

I guess one of the security changes introduced in CU22 that affected EWS functionality was where it would accept requests from.

I now have all my scripts working again, simply by installing EWS on a different server and running them there, instead.

 

THIS THIS SOOO much THIS.... I ran in circles for ages until I found your post. Fixed my problem instantly.

 

Thank you, stranger from the past!!!

Edited March 8, 2024 by thirdman