Microsoft Graph: Encoding and decoding the drive id

If you have worked with the Microsoft Graph API and SharePoint items you might have encountered URL’s which include a drive id. Where you in SharePoint typically work with URL’s for a site and the document library, a drive id is an encoded representation of a document library location.

The following Graph REST request will list all items in a specific document library:

GET https://graph.microsoft.com/v1.0/drives/b!VvpCx03990mC5Lb5YxH0SUA9TgZHvEZImra6PMjrvbx85KUwT1BMTbhen6I6ffXL/root/children

Fetching the item for a file you use this signature to retrieve the file itself where item id is part of the listing: GET /drives/{drive-id}/items/{item-id}

With some reverse engineering you easily can figure out the drive-id is a prefixed base64 encoded string composed of the site id, web id and list id for a particular library.

Using PowerShell here’s a few lines converting the drive id string to the correct guid’s and back:

$driveId = "b!VvpCx03990mC5Lb5YxH0SUA9TgZHvEZImra6PMjrvbx85KUwT1BMTbhen6I6ffXL"   
$encodedDriveId = $driveId.Substring(2).Replace('_','/').Replace('-','+')    
$bytes = [Convert]::FromBase64String($encodedDriveId)
$siteIdBytes = [byte[]]$bytes[0..15]
$siteIdGuid = New-Object Guid @(,$siteIdBytes) #site id

$webIdBytes = [byte[]]$bytes[16..31]
$webIdGuid = New-Object Guid @(,$webIdBytes) #web id

$listIdBytes = [byte[]]$bytes[32..47]
$listIdGuid = New-Object Guid @(,$listIdBytes) #list/library id

$bytes = $siteIdGuid.ToByteArray() + $webIdGuid.ToByteArray() + $listIdGuid.ToByteArray()
$driveId = "b!" + [Convert]::ToBase64String($bytes)

The item-id part is a bit more tricky and looks to be some sort of base32 encoding of a SharePoint item’s unique id. As I haven’t figured out the mechanics you can still access the item by route of the list item unique id:

GET https://graph.microsoft.com/v1.0/drives/{drive-id}/list/items/{unique-id}/driveItem

Example: https://graph.microsoft.com/v1.0/drives/b!VvpCx03990mC5Lb5YxH0SUA9TgZHvEZImra6PMjrvbx85KUwT1BMTbhen6I6ffXL/list/items/7D0E814C-0798-4966-A20C-6DE4F27F2027/driveItem

Of course, if you already have the site id, web id, list id and unique item id, you can access a drive item using the following syntax as mentioned in my file preview post.

GET https://graph.microsoft.com/v1.0/sites/{site-id},{web-id}/lists/{list-id}/items/{item- id}/driveItem

Photo by https://unsplash.com/@maurosbicego

Introducing the SharePoint REST API v2.0

For as long as REST has been supported in SharePoint the endpoint programmers have used is http://server/site/_api/ or https://contoso.sharepoint.com/_api for those of us who left on-premises years and years ago.

Now Microsoft has given us a v2 endpoint for the REST API. This has sort slipped under the radar, but I’m happy to announce that it’s there, it’s supported, and you can use it!

But wait, what is this v2 API, and why should I care or use it?

API rant at the end of the day about Office 365 Groups, Yammer and Graph

Sometimes pressure just builds and you need to vent. This is one of those days where I’ll gripe about O365 Groups with Yammer, and about retrieving an Office 365 Group Photo.

Self-service of Office 365 Groups with governance and Yammer

In the perfect anarchy world of Microsoft Corp. this is all good. Everyone can create everything from anywhere. I wouldn’t say it really works for Microsoft internally as I’m sure it’s all a big mess with no structure control at all.

The rest of the world like to have some control over the self-service (which I spoke about at ESPC). This is why a typical setup is:

• Disable Office 365 Groups creation from the default UI for all users except a few in IT
• Enable a self-service solution which allows approval, configuration, metadata and what not when a user want’s a new Office 36 Group for collaboration.

So far so good. This works just fine.

Then throw in Yammer. If you lock down the oob self-service, your Yammer groups will not get an Office 365 Group – and there are no easy ways to solve this today.
There is also no option to turn of creation of Yammer groups within Yammer itself and roll your own in-place solution.

Which leads to:

• Users can create all the Yammer groups they want – but if they want them inside some structure we need to teach them to contact IT, so that IT can create the group and apply whatever metadata, configuration and what not.

I work with client which has a multitude of Yammer groups, but from an information architecture point of view they are not all the same. Some are more important than others – and the only way to classify them is to put magic names in the title or description – or if they are connected to an O365 Group we can put matedata in the Graph – but remember – we turned off self-service of Office 365 Groups.

The solution? Allow us to turn off self-service in Yammer, and allow us to create Groups with Yammer using app tokens – preferably via the MS Graph – not via the Yammer API.

Office 365 Group Logos

Fetching the logo data is possible via the Microsoft Graph – but you require a separate call for this. If I create a listing of Office 365 Groups and want to display the logo, I cannot simply add an <img> tag including the Group id and get the image. No, I need to fire off a REST call per image.

The only resource who got this right is Planner using the link:
https://tasks.office.com/tenant.onmicrosoft.com/Groups/GetGroupPhoto?groupId=<id>

..except you need to have logged in to Planner at least once for this URL to just work. If you’re in SharePoint context they have a nice URL:

/sites/groupname/_api/GroupService/GetGroupImage?id='c8ab4e69-a7a1-4f35-b3ba-96616976cd62'&hash=636476452763371703

..except the id in the above URL is not the Group id, but the id of __iconLogo_.jpg in SiteAssets. You need to fire off a REST call to either get the site url and then one to get the logo url – or hardcode to __iconLogo__ for just one extra call.

And then we have Outlook:

blob:https://outlook.office.com/a03b46be-10ad-469e-b5e6-709c34132353

where the id is something I have no idea what is – certainly not the Group id.

Which means dear users – when listing 100’s of Office 365 Groups, you have to live without the logo until I get smart – tough luck!

Or we have this one:
https://outlook.office365.com/EWS/Exchange.asmx/s/GetUserPhoto?email=group@tenant.onmicrosoft.com – which also requires auth and is a REST call, not a direct image link.

Conclusion

Please Microsoft, give us proper and easy ways to create simple solutions! Or I need to go over all existing Groups and set custom metadata for the logo URL, ensuring all data is available on the intial Graph call. See my generic schema post for more info.

Why you should use Azure AD id’s and not e-mail addresses or UPN when bulk importing user profile properties to SharePoint Online

Back in April Microsoft released details of a new API do do bulk import of user profile properties in SharePoint Online. Say you have a field with an employee id, and you want to set this for all users in your organization. As Azure AD does not allow you to map custom fields into the user profiles automatically you have to set the data your self. Previously you could use the user profile API as an admin to do this, but it was not possible if you were for example using an automated app with app tokens, and you also had to loop over all profiles, updating one at a time.

You can read more about the API and see a full code sample at https://dev.office.com/blogs/introducing-bulk-upa-custom-profile-properties-update-api.