Category Archives: Exchange Online

Exchange Online Reconnect script

I’ve seen and known many scripts that interact with Exchange Online for extended periods of time. After a while, Exchange Online likes it if you reconnect, this can be an Impliciet Authentication popup, or it can simply drop you based on what command you’re using.

If you call the following function every loop in whatever you’re doing, it’ll automatically force a reconnect to Exchange Online every hour (adjustable if you prefer longer):

function validateExOConnection{
Param(
[Parameter(Mandatory=$true)]$o365Creds,
[switch]$retry
)
if($script:timeConnected){
$timeSpanMinutes = (New-TimeSpan $script:timeConnected (Get-Date)).TotalMinutes
if($timeSpanMinutes -gt 60){
$script:Session=$Null
$script:timeConnected = Get-Date
}
}else{
$script:timeConnected = Get-Date
$script:Session=$Null
}
if($script:Session -eq $Null -or $script:Session.State -ne "Opened"){
#There is no session, or it has gone stale
try{
Get-PSSession | Remove-PSSession -Confirm:$False
}catch{$Null}
$failed = $False
try{ $a = New-PSSessionOption
$a.IdleTimeout = 432000000000
$script:Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $o365Creds -Authentication Basic -AllowRedirection -SessionOption $a
$res = Import-PSSession $script:Session -AllowClobber -DisableNameChecking -WarningAction SilentlyContinue -Prefix EXO
Write-Host "Reconnected to Exchange Online" -ForegroundColor White
return $Null
}catch{
$failed = $True
}
if($failed -and !$retry){
validateExoConnection -o365Creds $o365Creds -retry
return $Null
}
if($failed -and $retry){
Throw "Failed to connect to Exchange Online $_"
}
}
}

Download: ExOReconnect.ps1 (right click, save as)

Public Folder to Office 365 Groups Migration Script

Earlier, I wrote on a new technet article that details migration to Office 365 groups from on prem public folders. Actually walking through that I noticed some inconveniences I figured I could improve on with a script. The main one being that the endpoint in Office 365 only supports a single Public Folder, excluding child folders.

So I wrote up a script (with resume support) that will map your Public Folders to O365 Groups and migrate them in as many batches as are required, fully automated.

You’ll end up with a nice csv file with all the details. Note:

  1. this script expects you to know what you’re doing!
  2. only tested with Exchange 2010 as source
  3. everything on prem is left untouched
  4. groups are not mail enabled, and security settings are not copied
  5. contacts are not copied

archivePublicFoldersToOffice365Groups_v0.05.ps1 (right click, save as)

update 05/01: improved the connection status check + reconnect for remote ExO and fixed report file path auto generation

update 11/01: moved everything to start-job so exchange sessions are always isolated (no prompting after 1-2 days) and added total migration overview display 

Setting up Okta User -> Office 365 contact synchronisation

Okta natively does not allow you to sync users to Office 365 contacts; they either exist as users in Office 365, or they don’t exist at all.

In hybrid scenarios where you are doing a staged migration to Office 365, or where you simply manage your contacts in Okta, you may want to populate the Global Address List in Office 365 with your Okta users.

I’ve written a simple solution for this, you will require:

  1. Okta Admin Access (to obtain a token)
  2. Office 365 credentials (to write / modify Contacts)
  3. An Azure Subscription (for automation)

The solution will sync your users in Okta to Office 365, take note of the following: Continue reading Setting up Okta User -> Office 365 contact synchronisation

Migrating Public Folders to Office 365 Groups

Recently, I stumbled upon an article detailing how to migrate on-premises (or online) Public Folders to Office 365 Groups

Of course I had to try that out asap 🙂 I used an older script to make a report of my on prem public folders to pick one below 50GB.

It was mostly a breeze and the interface of Office 365 groups allows users to easily search and administer their old Public Folders. We purposely only use them for archive access, where the IM team manages access to the groups holding PF data. I can really recommend this strategy, especially if you can easily split them up in under 50GB sized groups.

I did have one slight error you may run into:

“MigrationTransientException: Couldn‎’t find a request that matches the information provided. Reason: No such request exists in the specified index. –> Couldn‎’t find a request that matches the information provided. Reason: No such request exists in the specified index. “

Reason for this: The source public folder path is incorrect, make sure your CSV is mapped correctly or your batch will spin forever (or at least longer than I had patience), never completing.

 

 

Provisioning Exchange Online / Office 365 Custom Roles automatically from Okta

Natively, when connected to Office 365, Okta allows you to automatically provision users and/or groups. Additionally, Okta will assign licenses you select, and if configured, set predefined roles in Office 365. This means you have one locus of control, very nice.

Then, Exchange Online allows you to define custom roles where you can scope permissions for your users with far greater granularity compared to the default roles, Okta won’t detect or provision users into these custom roles.

As this was a business requirement for a customer, I coded up a small proof of concept you can schedule that will read membership of selected groups in Okta through the Okta API, then ensure that ONLY those members are in the matching role groups in Exchange Online.

Continue reading Provisioning Exchange Online / Office 365 Custom Roles automatically from Okta

AADSTS165000 after enabling Modern Auth in Exchange Online

If you enable Modern Auth in Exchange Online with Set-OrganizationConfig -OAuth2ClientProfileEnabled $true , and then start seeing this error in Office 2016 or 2013 clients:

AADSTS165000: Invalid request: the request tokens do not match the user context. One or more of the user context values (cookies; form fields; headers) were incorrect or invalid, these values should not be copied between requests or user sessions; always maintain ALL of the supplied values across a complete single user flow. Failure reasons:[Token is invalid;]

You need to re-activate Office.

Copy local AD contacts to O365

Recently I needed a basic method to copy over contacts from a local AD to O365, and in cases where a read-write contact already exists; update it. The scenario made sense, as we were working with multiple source AD’s where some had contacts of each other’s mail users, causing adsync conflicts. Thus we decided to take contacts out of ADsync scope and just copy them once.

The logic of the attached script is as follows:

 

 

 

 

 

 

 

 

Note that the script ONLY imports the displayname, primary and all secondary email addresses, and sets an extra X500 address for the legacy exchangeDN to avoid outlook cache hit misses.

If you need it, here’s a download link:

O365ContactImporter.ps1

Removing .onmicrosoft.com and .mail.onmicrosoft.com aliases from all groups, users and contacts in your Active Directory

My current customer had a little dabble in Office 365, they set up their Hybrid configuration and added their @xxx.onmicrosoft.com email alias to all their users and groups. This mostly happens automatically.

They then later decided to go with a new, different Office 365 tenant for production purposes, the old tenant was dismantled and the AADConnect server was deleted.

However, all AD objects still had their alias for the old Office 365 tenant, syncing that to the new tenant would be a bad idea and I cleaned that up just to be sure it wouldn’t cause trouble in the future, here’s how I did that:

cleanupAllADObjectProxyAddresses.ps1

O365GroupSync beta release

O365GroupSync is a tool that I am building for a large global NGO, because AADConnect creates Read-Only objects in Office 365.test

Read-Only objects cannot be edited in Office 365, thus users are unable to edit distribution lists in Office 365’s Outlook Web Accress (OWA) even if they are managers of said lists.

O365GroupSync was built to take over the synchronisation and initial seeding of all distribution lists, both ways, to allow users to edit distribution lists while in a hybrid Office 365 Exchange Online scenario, both on premises and in the cloud.

This beta version has been tested, but is not yet running in any production environments.

Get it here