Category Archives: Powershell

Mass changing link type in Sharepoint or Onedrive

Sharing links in Onedrive/Teams/Sharepoint can be of the View, Edit, Review or No Download type.

There is no official Graph API or PnP module call that can be done to modify a link, it has to be done manually in the GUI as per Microsoft.

That didn’t work for me, as I’m working on some migration scenario’s where all links have to keep working, but should not allow users to edit or download the files.

So I did some digging, turns out there is a ShareLink GetSharingInformation endpoint that can be called for any object.

And with good ‘ol Claude, a script was built and tested in half an hour that iterates over a given sharepoint site(s) or a specific file and adjusts the link. I’ve made it configurable and use certificate based auth, enjoy!

https://github.com/jflieben/assortedFunctionsV2/blob/main/Update-SharingLinks.ps1

Unexpected Onedrive Owners

How do you know who the original owner of a Onedrive site was?

The url says a lot, it’s usually in a username_domain_com format. If you have a fixed naming structure and don’t use _’s or other characters that are translated to _, it can be reversed with reasonable accuracy, right?

But what if you have two people with the same name? Or did some migrations or takeovers? Then your logic breaks 🙁

So reverse engineering the URL won’t work, and if an admin takes ownership or if the user leaves and the manager gets ownership, the Owner/Full Control ACL on the site also won’t tell you who the original owner was because it overwrites the Owner property.

In M365permissions the option to audit ownership of Onedrive is built in, as this is a common question during certain types of audits.

But how did we solve it there?

Well, it turns out that Sharepoint’s own metadata service maintains a pretty good track record of who was ever a user on a site, even after they are deleted from Entra.

Thus by doing a call to /_api/web/siteusers?$orderby=Id, we get a nicely ordered list of all users ever assigned to the site.

Pick the first non-system user, and we have our original user! See above 🙂

Silent provisioning of Fido key to use for headless requests against hidden API’s

So there’s this problem with lots of Microsoft API’s not allowing service principals to call them. I’ve written about this a few times in the past 🙂

These api’s want a user. And a user has to do MFA, right?

Not with this!

When I read Nathan McNulty’s LinkedIn post this morning I got a bit hyped and just HAD to get it working. He has a way to use a stored passkey to log in silently to all admin portals/hidden api’s etc.

The missing part I wanted to solve, is to actually generate that passkey for a given global admin in the tenant.

Took a bit of messing around with how to generate the keys using a virtual authenticator, but it works! Here it is:

https://github.com/jflieben/assortedFunctionsV2/blob/main/New-FidoKey.ps1

So basically:

  1. register app with client id/secret and UserAuthenticationMethod.ReadWrite.All
  2. run New-FidoKey
  3. use the file it outputs with Nathan’s passkey login function

I should also give an honorary mention to Fabian Bader for the work he did to get us here!

disclaimer: don’t store this stuff where anyone can find it!

disclaimer2: you’ll have to set your fido policy to allow not force attestion or key restrictions

M365AutoLink

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:

  1. check all sites the user has access to (including Teams)
  2. filter sites you do and don’t want
  3. create a folder in their onedrive if it doesn’t exist yet (you can decide how to name it)
  4. add all these sites as shortcuts in this folder
  5. 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!

Documentation and download

https://github.com/jflieben/M365AutoLink

Microsoft Office Server Directory DirectoryObject NotFound Exception

Can’t delete a sharepoint site that used to have a group attached to it, but the group has long since been deleted?

Apparently, the sharepoint admin center is unable to handle this scenario, and just throws a “could not be deleted” error. Using fiddler the only extra info I could get was an underlying 500 Internal Server Error Microsoft.Office.Server.Directory.DirectoryObjectNotFoundException was thrown

Obviously that directory object not found means the office 365 group. Fora seem to point to MS support for manual fixes, but since Microsoft Support has rarely been a pleasant experience for me I went over the PS module for SPO and found a MUCH faster fix, hope it also works for you!

  1. start PowerShell 5 (don’t use a newer version until the module supports it)
  2. install-module Microsoft.Online.SharePoint.PowerShell -force -scope currentuser (unless you already have the module installed)
  3. import-module Microsoft.Online.SharePoint.PowerShell
  4. Set-SPOSite -Identity https://xxx.sharepoint.com/sites/xxx -ClearGroupId
  5. Remove-SPOSite -Identity https://xxx.sharepoint.com/sites/xxx -noWait