File not found when creating a Document Set with CSOM

I had to debug an error which was hard to reproduce from Visual Studio or hard to find a solution for. In this case a Document Set is created through CSOM in SharePoint 2013, triggered by an external application.

The user receives the error “File not found” when creating the document set. Luckily this was SharePoint 2013 on-premises and I could go into the ULS logs to find the details of the CSOM request. There you could find errors like:

“System.IO.FileNotFoundException: The filename, directory name, or volume label syntax is incorrect. (Exception from HRESULT: 0x8007007B)”

and

“DocumentSet Create [libraryname] in [document set title] : throws exception: The filename, directory name, or volume label syntax is incorrect. (Exception from HRESULT: 0x8007007B).”

SharePoint also logs the XML of the CSOM request. There I found something in the Document Set title that shouldn’t be there, a trailing space.

So lesson learned, if you create SharePoint artifacts from an external system, make sure to trim your strings.

Permissions on a group connected team site

With Office 365 anything you do which has members will create an Office 365 Group. This applies to (new) SharePoint sites, Teams, Groups, PowerBi workspaces, Planner, Yammer and so on. With every group comes it’s own new SharePoint team site and vice versa. I do like the self service capabilities of these groups. It’s easy for end users to manage members and owners. And if needed, admins can create dynamic groups to give access based on user properties.

For us SharePoint enthusiasts it also comes with some new decisions we have to make. Whilst the membership management of groups is great, we do not always like the default permissions that are given to group members on SharePoint sites. So now we have to choose. Do we stick with the default Microsoft gives us and make sure we don’t break anything with future updates, or do we change the permissions to suit our customer needs. And if we choose for the latter, how do we change the permissions?

Default Permissions

As far as I remember we’ve had three default groups with SharePoint: owners, members and visitors. The owner group is easy, they get full control over the SharePoint site. The same with visitors, they only get read access. The default for members is edit permissions (source), and that’s somewhat opinionated. Do we need to give members permissions to add, edit and delete lists and libraries? Or have them change the metadata of a list?

In old SharePoint you had to have somewhat more advanced knowledge on how to take steps in changing the structure. These settings were not that obvious. Now with the new UI, the SharePoint team made it very easy. And when it’s easy, people start using it.

If you know SharePoint, the solution is easy. Just go to the advanced permission of a SharePoint site, tick the Members groups and change permissions…..
And then you find out, you can’t, as the option is grayed out:

As you can read from this thread on the Techcommunity, the option has been available, but removed: Best Practices for Permissions on an O365 Group SharePoint Site

Possible solutions

From the Techcommunity I found one proposed solution in the comments of a post. That simply states, create a new SharePoint group and move the group members claim from the SharePoint Members group to the newly created group.

Another option I experimented with, is using this PowerShell command:

Should I?

The PowerShell option easy and it works flawlessly at the moment. But then I started thinking, should I even use this option? To start the discussion on this PowerShell option, I started this thread on the Techcommunity.

A lot of people on various threads on the Techcommunity share the same pain with regard to the default edit permissions, but they also seem to share the same opinion that you should not change the default permission the SharePoint team gives you. There seems to be a big fear that you might break stuff that Microsoft might introduce in the future. And by the way, the contribute permission level is on the backlog of the SharePoint team, so it might be solved one day.

On the other hand, you still get the options to manage advanced permission on a SharePoint site. They even added it to the new UI. And we still have the option to break inheritance on lists and libraries. Although it might not be recommended, it’s still an option. And not everybody reads the Techcommunity for guidance.

Consequences

There are a few things that I can think of when I think of possible consequences:

  • Microsoft disables the PowerShell option. They’ve disable the UI, why shouldn’t they disable the PowerShell option?
  • Microsoft might introduce a better solution and you will end up with two solutions for the same problem. My fix: revert the setting with PowerShell on all sites and start using the default.
  • It has consequences for other products using SharePoint as a service. The main product would be Microsoft Teams. And as far as I know Teams doesn’t need edit permissions. Not for the wiki, OneNote or for storing files.

My view

First of all, make up your own opinion. There’s no official guidance and Microsoft haven’t completely removed all options, although keep it standard seems to be the favored opinion.

When we need to solve real business pain, there are two options. Either use classic SharePoint sites with modern elements and manage the SharePoint groups as we have always done. I don’t like this option, as I favor the Group membership management and I would like to use features like the new Hub sites, site designs and site scripts. These are not available on classic sites (yet).

The other option is to change the permissions on a Group connected Site by adding a new SharePoint group or changing the edit permissions to contribute with PowerShell.

In the end, I chose the latter. In my cases, I was using SharePoint for just SharePoint. No connected teams or any other products. And my customer has a good experience with the new SharePoint UI and hub sites and they can easily manage Group membership.

Now we just hope Microsoft doesn’t remove this option in PowerShell.

Creating an activity through the CRM WebApi

Recentely I had to create a phonecall activity through the WebApi in Dynamics 365 CRM. As most WebApi calls are pretty straight forward, I didn’t think much of this task, although I haven’t done this before. As I knew activities are special in CRM I looked around to see examples and couldn’t find any good ones. Therefore I’m writing this post, to make sure I have an example on hand when I need one.

Endpoint

To create an activity you use the relevant endpoint. These are /api/data/v8.2/phonecalls, /api/data/v8.2/emails, ect. Maybe there’s an option to use the generic endpoint, but I haven’t tested this.

Json message

For a phonecall the Json message could look like this:

The special part in this are the activity parties. More special even, that it’s called phonecall_activity_parties. That array contains two objects with a navigation lookup to the record and a participationtypemask. The number in the participationtypemask stands for From (1) and To (2).