Doing logon scripts is easy for some, less easy for others, and in general not great in certain types of environments.
And this led to some questions if I could also make a version of M365AutoLink that can run centrally. There was a hurdle to overcome: how do we know what libraries a user has access to?
M365Permissions already has the answer, so a quick copy paste from the code there and voila, we now have a centrally runnable version of M365AutoLink!
It can run either as managed identity, or cert-based service principal. I recommend running it as a runbook, and don’t run it on tenants with thousands of users or commercially….for commercial use click here 🙂
We often still have legacy apps around. First advice is always; get rid of them 🙂
But sometimes, that’s not the option the customer wants to pay for, so alternatives need to be researched. Commercial tools like IAMCloud Drive Mapper work really well in exposing Teams/Sharepoint as driveletters on endpoints (for a price).
But free solutions are limited to automapping using GPO’s or letting users sync each team they need access to manually. This often causes issues on multiple fronts that I’m sure you’ve already experienced if you’re reading this.
So here’s an alternative to try! M365AutoLink is a PowerShell script you can execute on the user’s device. It’ll try to use SSO and then:
check all sites the user has access to (including Teams)
filter sites you do and don’t want
create a folder in their onedrive if it doesn’t exist yet (you can decide how to name it)
add all these sites as shortcuts in this folder
remove any shortcuts the user no longer has access to
And since Onedrive syncs these links, any legacy apps on the user’s device can now also directly access Teams/Sharepoint, without syncing down the entire library or using drive mappings!
