If you’re a Cloud Solution Provider and you supply a CSP azure subscription to that tenant, your AdminAgents will have Owner access to that subscription by default. Lets say the customer also has an existing subscription (maybe a non-profit donation?).
When you add your accounts as Owner to the existing tenant’s (non-csp) subscription, your users are added as Guest accounts in the customer’s Azure AD. This removes the delegated CSP rights on the CSP subscription because the references to foreign accounts break due to the new guest accounts having the same UPN.
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):
Note: if you run this script in an Exchange Shell, something in the Exchange Shell modules will still prompt for reconnects every 1-2 days. In a normal PS window, I’ve verified it working for up to a week until it asks for a reconnect.
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.
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:
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.
