A few weeks ago I posted a script that would automatically, periodically, reconnect to Exchange Online. In field testing it would still prompt for credentials after 1-2 days, whatever I did.
So I took a different route and am now rewriting Microsofts’ module on the fly to no longer prompt for credentials. If you use below function to connect to Exchange Online, you should never receive reconnect prompts 🙂
disclaimer: don’t overwrite $o365Creds with invalid creds elsewhere in your script as those are used globally.
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:
this script expects you to know what you’re doing!
only tested with Exchange 2010 as source
everything on prem is left untouched
groups are not mail enabled, and security settings are not copied
contacts are not copied
make sure you read the code/in-script instructions between line 1 and line 48, and then if you’re curious, from line 71720
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
update 25/01: exported the remote exchange module and added it as inline code with a modification so it won’t prompt for credentials, nothing else seems to otherwise prevent such prompts. This means the module may not match Microsoft’s if they update Exchange Online. Let me know if that causes issues for you or re-create it yourself with export-pssession and replace.
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.
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.
handle the new tile / prompt that appears in IE login mode where Microsoft no longer always redirects to the portal
Progress bar color is now a configurable option (cloud/non cloud)
alphabetic ordering of configs (cloud only)
Fixed auto update loop issue where auto update would break itself for subsequent updates.
When restarting self (switching auth mode or auto updating) properly hide the console if this was set
Important Auto Update Instructions
If you were using Auto-Update, DO NOT do so for this version. Use the MSI to replace the old version (see last fixed issue).
New Azure AD Signin experience
As some may have read, Microsoft is previewing a potentially disruptive change without advance notice. My tenants don’t yet display the new behavior so I cannot test if OnedriveMapper will be affected. I haven’t heard of any issues yet 🙂