Glen's Exchange and Office 365 Dev Blog

Microsoft have just released the Mail.ReadBasic permission into beta for the Microsoft Graph endpoint  https://developer.microsoft.com/en-us/graph/blogs/new-basic-read-access-to-a-users-mailbox/ which is a much needed addition that allows the creation of automation and apps that can just access messages at a more meta information level without having access to the Body or Attachments. Privacy and security are always pressing issues especially around email so this can turn down the privacy concerns while also reduce the security concerns of giving full access to content.  Lets look at one use case for this new permission which is getting the Message Headers from a Message that has arrived in a users Mailbox that you suspect might be spam but you want the header information to do some analysis. Normally if you wanted to build an app to automate this you would have to at least assign Mail.Read which would give full access to all email content in a Mailbox (either deleg...

If your using the EWS Managed API in your PowerShell scripts and you need to do some extended debugging to work out why a script isn't working the way you expect in certain environments you can do this by using Tracing as described in  https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/dd633676(v=exchg.80) . What this does once it is enabled is it outputs all the requests and responses that are sent to and from the Exchange server so you can see exactly what is taking place and potentially more information on particular errors that are occurring.  So in a EWS Managed API script to enable this you just need to set the TraceEnabled property on the ExchangeService object to true eg $server.TraceEnabled = $true And you will then start seeing traces like the following in the console A much cleaner way of capturing these traces is to configure the EWS Managed API to use a separate log file to log them to a file so you can review them ...

One of the features that is currently in beta in the Microsoft Graph API is an operation that will let you unsubscribe from any mailing list that supports the List-Unsubscribe header in a message that complies with RFC-2369 (https://docs.microsoft.com/en-us/graph/api/message-unsubscribe?view=graph-rest-beta). This can have a number of uses one that does come to mind is when you have staff that are leaving the company (or even taking an extended break where they won't be reading their email) and they have signed up to quite of number of mailing lists. As part of your deprovisioning process you can include a script that will unsubscribe from the emails in a Mailbox before you remove the account instead of deleting and hoping the NDR's do it for you. The RFC state the following for List-Unsubscribe 3.2. List-Unsubscribe The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list). Examples...

Group calendars have always been one of the big asks for in any group collaboration programs back from Lotus Notes to Microsoft Exchange and now Microsoft Teams. There are a few ways of getting a Group calendar working in Teams, one is hosting the OWA web apps see or some other people advocate using a SharePoint calendar and hosting that similarly. Here is a different method you can use by taking advantage of being able to call the Graph API in a  Tab application. The getSchedule Graph action (still currently in beta) allows you to query up to 62 days of Freebusy information on up to 100 calendars in a single call this makes it a good option for this type of application. So as long as users can view each others calendars or have detailed freebusy permissions the action should return the le vel of detail required for a Group calendar.   The other thing you can do with the Graph API is get the users photo and build a nice legend for the Group calendar also. To make this visu...

First a little news about Exchange Identifiers that you may have missed (its not often that something like this changes so its rather exciting) When you access an item in an Exchange Mailbox store whether its OnPrem or in the Cloud you use the Identifier of the particular item which will vary across whatever API your using. Eg MAPI - PR_EntryId eg NameSpace.GetItemFromID(EntryId) EWS -  EWSId eg EmailMessage.Bind(service,ewsid) Rest -   RestId  eg  https://graph.microsoft.com/v1.0/me/messages('restid') The advice over the years has always been its not a good idea to store these Id's in something like a database because they change whenever and Item is moved. Eg if an Item is moved from the Inbox to a Subfolder in the Inbox it will received a different Id so whatever you have stored in your database suddenly becomes invalid and its not easy to reconcile this. However a new feature that has appeared in Exchange Online in Beta with the Graph API is imm...

One of the things you maybe considering in the new year is migrating from Skype for Business to Microsoft Teams. In this post I'm going to demonstrate how you can use the UCWA api (which is the REST API you can use to talk to a Skype for Business server either in Office365 or OnPrem) to access Skype for Business from within the Teams Client via a Teams Tab application. (For those unacquainted with UCWA this the API that is used to Access Skype within OWA). Why would you want to do this ? its one way of easing migration friction by providing a different level of interoperability (outside of using both clients) and also a way of adding functionality into the Teams client that isn't there currently.  In this post I'm going to look at showing the users Skype conversation history, while this information is also stored in a users Mailbox and also a ccessible via the Graph API, in this app I'm going to use the UCWA API to access the conversation logs via the Skype for Busin...

For those that just follow my RSS Feed I've just published the following on Linked In  https://www.linkedin.com/pulse/front-line-series-what-can-you-do-when-receive-malicious-glen-scales