ews
9 TopicsUpdating unattended EWS scripts using modern auth
Hi there, a lot of possibilities about phasing out legacy authentication have been discussed here. But I still have a lack of information or let's say I want to find the most comfortable and most secure possibility for my customers. https://docs.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps But if your scripts contain EWS connections you have to initialize a different way of authentication. So I found the following option using MSAL, unfortunately this does not work in unattended mode. https://morgantechspace.com/2022/03/connect-ews-api-with-modern-authentication-using-powershell.html And then there is the possibility using the secure application model. https://docs.microsoft.com/en-us/powershell/partnercenter/multi-factor-auth?view=partnercenterps-3.0#secure-application-model I got this working now, the creation of the token for the first time has to be done interactively and the token only lasts for 90 days. I read the hint for securely saving the token to the Azure KeyVault, but how do I do this and how can I re-call this token? Is there even a better way of refreshing the token manually? Is this now the new go-to solution for unattended EWS scripts, or do you have a even better solution?3.8KViews0likes1CommentMicrosoft Signals the End for Exchange Web Services
On September 19, 2023 Microsoft announced their intention to retire the Exchange Web Services API on 1 October 2026. The suggested replacement is the Microsoft Graph API. Microsoft acknowledges that some gaps exist that they need to close before EWS retirement happens, but one big issue they didn’t discuss is what happens to the backup products that currently use EWS to backup Exchange Online. https://office365itpros.com/2023/09/20/exchange-web-services-retire/3KViews0likes0CommentsAccess control for Azure Active Directory Application to EWS mailboxes
I'm uncertain if this is in the correct place, so please bear with me. We are currently in process of migrating our Exchange environment from On-Premise to Exchange 365. Our developer team has an on premise application that uses EWS to read mailbox contents, then delete those messages. We were able to create an application registration in Azure Active Directory, and are able to access our mailboxes in 365 through impersonation and read contents - Our application is using OAuth with certificate authentication (no login credentials), and we have granted our Application the Use Exchange Web Services with full access to all mailboxes rights. The problem, however, is that we don't want this application to be able to access all mailboxes, only a specific set of mailboxes. Currently it is able to access any mailbox. My question is how can we properly secure this application to only be able to access mailboxes that we specify? I've seen different suggestions on scoping and roles, but have not been able to find a definitive answer. If we do not use OAuth, and use user credentials to log into EWS, we have a means of defining write scope in Exchange 365, which will limit that impersonation access. I've been unable to find similar means when using OAuth with a certificate, and not using specific login credentials. If anyone can provide some help or direction here, it would be greatly apprediated. Please let me know if any additional details are required.2.8KViews0likes0CommentsEWS API - For-Each using User Impersonation
Could someone show me how I would take this script and run it against a list of users? Currently it is only designed to run against the user which is authenticated. I understand the on behalf permissions in Office 365 has to be granted, I just want to know how can I run this against a list of users, perhaps in a text file? function Get-TeamsMeetingsFolder{ param( [Parameter(Position = 1, Mandatory = $true)] [string]$MailboxName, [Parameter(Position = 2, Mandatory = $false)] [string]$AccessToken, [Parameter(Position = 3, Mandatory = $false)] [string]$url, [Parameter(Position = 4, Mandatory = $false)] [switch]$useImpersonation, [Parameter(Position = 5, Mandatory = $false)] [switch]$basicAuth, [Parameter(Position = 6, Mandatory = $false)] [System.Management.Automation.PSCredential]$Credentials, [Parameter(Position =7, Mandatory = $false) ] [Microsoft.Exchange.WebServices.Data.ExchangeService]$service ) Process { if($service -eq $null){ if ($basicAuth.IsPresent) { if (!$Credentials) { $Credentials = Get-Credential } $service = Connect-Exchange -MailboxName $MailboxName -url $url -basicAuth -Credentials $Credentials } else { $service = Connect-EXCExchange -MailboxName $MailboxName -ModernAuth #-AccessToken $AccessToken } $service.HttpHeaders.Add("X-AnchorMailbox", $MailboxName); if ($useImpersonation.IsPresent) { $service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $MailboxName) } } $folderid= new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName) $TeamMeetingsFolderEntryId = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition([System.Guid]::Parse("{07857F3C-AC6C-426B-8A8D-D1F7EA59F3C8}"), "TeamsMeetingsFolderEntryId", [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Binary); $psPropset= new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties) $psPropset.Add($TeamMeetingsFolderEntryId) $RootFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$folderid,$psPropset) $FolderIdVal = $null $TeamsMeetingFolder = $null if ($RootFolder.TryGetProperty($TeamMeetingsFolderEntryId,[ref]$FolderIdVal)) { $TeamMeetingFolderId= new-object Microsoft.Exchange.WebServices.Data.FolderId((ConvertId -HexId ([System.BitConverter]::ToString($FolderIdVal).Replace("-","")) -service $service)) $TeamsMeetingFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$TeamMeetingFolderId); } return $TeamsMeetingFolder } }2.2KViews0likes1CommentTeams uses EWS-API wrong which leads to wrong timezone in meetings
Hi, we do have an Exchange Hybrid Setup. On-Prem we do use OWA only. No Outlook-Client. When a user creates a Teams meeting (inside the Teams calendar) they sometimes use OWA when changing the meeting for comfort reasons (drag&drop). Here the problems begin. A little example: - User sets up meeting at 11:00 a.m. within the Teams calendar. - User changes meeting to 9:00 a.m. via OWA on the Exchange on-prem - Within in the organisation, everything is OK. But every External now has the appointment at 1:00 p.m. So somehow Exchange does a +2h (summertime maybe involved) to the orginal starting time of the meeting. But just for external participants. Inside the organisation everything is fine. Exchange always does the +2h based from the original meeting starttime. So moving the appointment to 3:00 p.m. will also lead to 1 p.m. for the External. Technically the .ics gets changed from "W. Europe Standard Time" to "UTC". If we change the meeting in the Teams calendar, everything is fine. If you create the meeting On-Prem and change it On-Prem or in the Teams calendar, everything is fine. It is just Online created meetings, changed On-Prem what causes the issue. I attached a screenshot of the .ics file. Right side shows the original meeting from Teams. Left side shows the changes of the meeting after leaving Exchange On-Prem. Does anybody have an idea where to look? Cheers Sebastian1.9KViews0likes3CommentsExchange Web Services - Admin Account but without License
Hi, Is there a way to call the Exchange Web Services using an unlicensed Exchange Administrator account [unlicensedexchangeadmin@test.com] to list all public folders? Scenario: Listing Public Folders 1. Using the Exchange Admin Center with the unlicensed Exchange Administrator account, I can list the public folders. 2. Using the EWS.GetFolder with the same credentials, ErrorNonExistentMailbox was returned and no folders were listed. Thanks, Christle1.1KViews0likes2CommentsCannot Get EmailMessage Name to Display in Sent Emails Using EWS
Hi, I cannot set EmailMessage.Name to display a custom name in emails sent via Microsoft.Exchange.WebServices.Data 2.2 (assembly v15). Is it being overridden by Exchange, using the email account's Name? I've tried all possible ways, even the "display name<email-address>" format, nothing seems to work. Thanks. // Example var senderEmailAddress = new EmailAddress("myemail@blah.com") { Name = "My Name" }; // Or senderEmailAddress = new EmailAddress("My Name <myemail@blah.com>") // Or... etc. tried many diff. ways, nothing works. :( var message = new EmailMessage(exchangeService) { Sender = senderEmailAddress, Body = new MessageBody(BodyType.HTML, "test"), Subject = "test" }; message.SendAndSaveCopy(WellKnownFolderName.SentItems);905Views0likes0CommentsErstellen von Terminen in Outlookkalendern anderer User mit PS/EWS bricht unregelmäßig ab
Hi zusammen, ich habe seit einigen Wochen ein eigenartiges Problem mit einem Skript, welches vorher monatelang fehlerfrei lief. Das Problem habe ich auf folgender Seite (auf Englisch) beschrieben: https://stackoverflow.com/questions/67388303/create-appointments-in-other-uses-calendars-using-ews-sometimes-fails-because-s Hat vielleicht jemand von euch eine Idee, wie ich das Problem lösen kann? Bin dankbar für alle Tipps! Viele Grüße Tim442Views0likes0CommentsHow to Delete a Composing Email Attachment via Outlook Add-in?
Context: Server: Exchange Server 2019 on premise Client: OWA Category: Outlook Add-in Office JS API Set: Supported up to 1.5 only Problem Details: Delete an attachment added manually or through EWS API to an email item. Limitations: 1. Limitation of makeEWSRequestAsync() Office JS method: The makeEWSRequestAsync method in Office.js does not support the DeleteAttachment SOAP operation, which is required from outlook add in. -> Attempted Workaround - Using fetch with EWS SOAP Request: I tried invoking the DeleteAttachment operation via a fetch call to the EWS endpoint. However, EWS response states "requested web method is not allowed for this application". 2. OWA Limitation: As OWA in this environment only supports Office.js up to version 1.5, the modern attachment Office JS APIs and Graph APIs are not an option. Question: In an Exchange On-Premises scenario, how can I programmatically delete attachments via my add-in? Specifically, is there a recommended approach to obtain a valid token for EWS requests, or any supported alternative to perform DeleteAttachment? Any way to convert EWS attachment ID to Office JS attachment UUID? Additional Notes: I am aware that Exchange Online supports more modern APIs (Graph/REST), but my current deployment is strictly Exchange On-Premises. The add-in works well for reading attachments and other operations, except for deletion. Any guidance or recommendations would be highly appreciated! Thank you in advance.93Views0likes1Comment