Version 2.26 of OneDriveMapper has been released.
- Fixed a bug causing the second cookie for Sharepoint URL’s to not be registered, resulting in error 224.
Get the new version here
Monthly Archives: January 2016
Giving all users access to a mailbox in Office 365 – Exchange Online
So you noticed the ‘All Users’, ‘Everyone’ and ‘Domain Users’ groups are missing in Office 365! That’s a pity if you have a mailbox that your whole organisation should be able to access, because Dynamic Distribution lists can’t be used as a security group.
At first, I thought this would be as simple as enabling ‘Dedicated Groups‘ in AzureAD for the tenant. But no, apparently builtin groups already exist, but are simply invisible in the Office 365 / Exchange Online interface.
So, I looked up the SID of the group I wanted to add here, and used Powershell to add the group to the mailbox’s ACL. Here’s an example, where we’re giving Everyone access to a Office 365 shared mailbox called ‘Public Calendar’:
Add-MailboxPermission -Identity "Public Calendar" -User S-1-1-0 -AccessRights FullAccess
Note: these permissions will be invisible in the web interface of Exchange Online, user Get-MailboxPermission to verify / view them.
Warning: obviously, you should never give ‘everyone’ Full Access permissions to anything.
Onedrivemapper v2.25 released!
Version 2.25 of OneDriveMapper has been released.
- Added functionality to make the drive visible even when it is mapped under elevated permissions (local admins with UAC disabled).
Get the new version here
Onedrivemapper v2.24 released!
Version 2.24 of OneDriveMapper has been released.
- Added support for mapping both O4B and Sharepoint Online in the same run of the script
- Added support for mapping multiple Sharepoint Libraries in a single run of the script
Get the new version here
Script too Complicated
Sometimes, an error can really make you:
Look at this one:
At line:1 char:1
+ & { Set-StrictMode -Version 1; $this.Exception.InnerException.PSMessa …
+ ~
Processing was stopped because the script is too complex.
+ CategoryInfo : ParserError: (:) [cleanFolder], ParseException
+ FullyQualifiedErrorId : ScriptTooComplicated,cleanFolder
When Powershell tells you your script is too complex, you know you’re coding an awesome script but that you’ve either made a mistake or are running into some builtin limit. Finding documentation about this error is hard, but a reply on a forum somewhere pointed me to recursive functions.
Yes, I was using a recursive function in this script. The script itself was started by the Start-Job function in a ‘main’ parent script. If I ran the child script seperately on its own, it had no issues and ran fine.
Start-Job apparently gets you into trouble when you’re using recursive functions and the recursion level becomes too deep. I ended up using Runspaces instead to avoid this issue altogether, and noticed the resulting script was faster and more stable as well.