The first public version of the O365Datacleaner has been released.
This script can make any given path to a folder/fileshare fully compliant with Onedrive for Business or Sharepoint Online standards, without user interaction. Including path depth resolution and intelligent renaming or moving of files and folders.
A bulk version of this tool is available for free upon request and will also be posted later.
Version 2.27 of OneDriveMapper has been released.
Get the new version here
connect-msolservice : Method not found:'VoidSystem.Runtime.InteropServices.Marshal.PtrToStructure(IntPtr, !!0)'.
Getting the above? Update .NET 3.5, one of the KB’s that comes down from Windows Update will add the correct DLL version.
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.
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.