Since world is moving towards Cloud and away from Basic authentication, I also have to address this in my scripts. With the latest announcement on The Microsoft Exchange Team Blog about the Upcoming changes to Exchange Web Services (EWS) API for Office 365, I get a lot of questions from people about this.
First of all: This change is ONLY for Office 365!
Besides this I appreciate this change and believe it or not with the latest Exchange versions you can use OAuth already on your on-premises environment.
In this post I describe how get your tokens using ADAL, which can be used for accessing a mailbox via EWS. Most of you might already used a tool, which supports OAuth, but weren’t aware of: EWS Editor
In my previous post Troubleshooting Autodiscover I wrote about Autodiscover service and the difference between POX and SOAP requests. Over the last years Microsoft evolved Autodiscover and introduced a new Autodiscover service V2. The new version is based on JSON and the main difference is the fact you don’t need to be authenticated.
When you read the headline, you’re might thinking “Oh no! Another post about this topic!”. But I think this post is worth reading as I’ll go deep into details.
Over the last months I have seen an increase of questions from various teammates and other teams in regards of the Exchange Online Remote PowerShell Module. The questions where mostly related to connectivity issue and prompts for re-authentication as PSSessions got into a broken state.
Also the fact that in some areas a proxy needs to be used, might be confusing as well as the question what to do if you have a service account or want to use the module in ISE.
A while ago I wrote a script, which helps me troubleshooting calendar issues:
Troubleshooting calendar items
Lately I wanted to improve the script and needed to translate two properties. These properties reflect what action a user has taken on and how a meeting object has changed:
Both properties are specified by a bit field.
This post is about my personal journey with a cross-forest migration.
When it comes to account migration there is no way to do so without sIDHistory. It would be really hard to have a smooth migration without.
By using this attribute a end-user most likely won’t experience any impact…..unless you start doing a cleanup of this attribute.
In terms of Exchange users might see something like this
But what’s behind those issues and how could you mitigate this? I was part of a migration, where those issues popped up and I’m going to describe how you could determine possible impact for end-users before it happens.
Sometimes you want to get Exchange server objects from AD without having the need to install management tools. For those cases the option to get your objects with just a search using LDAP is your friend.
A simple filter will return all existing Exchange server:
But what when you want server with a specific role in a specific AD site?