Since everything is shifting towards cloud, folks are looking more and more into possibilities and how cloud features can be incorporated into products.
One crucial topic is all around Authentication and Authorization. OAuth is the most used word in the past month,when I was approached by developers and they wanted to access somehow Exchange related data. I realized that many people having problems writing their code and usually we get blamed that we haven’t registered an application correctly in Azure AD.
Thus it’s on us to prove everything is okay and therefore I wrote a simple script for testing several scenarios in an easy way to make sure everything is configured correctly and you’re able to retrieve tokens.
I often have to perform searches in the Exchange AdminAuditLogs on-premises and in EXO or in the UnifiedAuditLogs, which are only in EXO available. Depending on the need I either analyse them using Out-GridView or export them to CSV file.
Challenge is always proper formatting. There are thousands way of doing, but here are my.
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
I’m sure that a lot of people have seen this issue before when migrating to Exchange Online:
The BadItemLimit was exceeded and therefore the move request failed.
A while a go Ben Winzenz wrote an excellent post on the You Had Me At EHLO blog, where he mentioned that there was a change in Exchange Online and now failed mapping of SIDs will count towards the BadItemLimit.
So far so good, but how do we solve such issues when increasing of bad item limit is not an option and you have to migrate approx. 130.000 mailboxes?
Due to some issues while removing invalid permissions with Exchange Cmdlets, I enhanced the script. Read more about it here…
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.
In a previous post here, I wrote about a few basic commands, which are useful to quickly gather information about transport component of an Exchange server.
In this post I want to give you a deep dive about it and how you can explore what the CmdLet can do for you as it evolves in each Exchange version and can be very useful.