Dear Microsoft: In Office 365, Groups are Groups are Groups – Unless They Aren’t

One of the problems with using common English words for things like “groups” or “teams” is that we end up trying to figure out the difference between things with very common names. When Sue Hanley (@susanhanley) and I were building our session Lions and Tigers and Teams, Oh My! – Sorting through the options to connect and collaborate in Office 365 for SPTechCon Austin recently, I realized just how confusing this could be – yet again.

The Problem

On the SharePoint home UI, when I want to create a “group”, I am told I will “Get a team site connected to Office 365 Groups”. So based on that one sentence, I might quite reasonably assume I’m creating a “Team” and a “Group” – which it so happens I am – sort of.

In the Groups UI in the Admin Center, we see these options:

  • Office 365 Group
  • Distribution list
  • Mail-enabled security group
  • Security group

In the Exchange admin center when we start to create a “group”, we’re given these choices:

  • Office 365 Group
  • Distribution group
  • Security group
  • Dynamic distribution group

But don’t fret. When you go to create a “group” in the Azure AD UI, you can create a “group” with Membership type of:

  • Assigned
  • Dynamic Device
  • Dynamic user

We can also check a box to “

Selecting ‘Yes’ will turn on Office 365 features for this group

I can even try to add the “group” – it’s not clear which type of “group” I’ve actually created – to the membership of another “group”. “Group Type” seems to be one of the following:

  • Distribution
  • Security
  • Office
  • Mail enabled security

When I create a Team in Microsoft Teams, there’s not even a clue that I’m also creating an Office 365 Group behind the scenes. Maybe that doesn’t really matter to an end user, but the fact that a “Team” is also a “Group” is another terminology SNAFU.

So What?

Some people might say that as an “IT Pro”, one should always understand all of these terms intrinsically, but I doubt that it’s often the case that this is true. The terms cross different “workloads” in Office 365 and can vary in terminology from their on premises counterparts, especially across server versions. Add to that the fact that many “admins” are the lone SharePoint/Exchange/Office 365/Chief Cook/Bottle Washer in their organization, and there is little hope they will understand the nuances. Heck, I do this stuff for a living and I find it confusing. Sometimes things are hard for no good reason.

Let’s assume we have an organization which is totally sold on the value of Office 365 Groups (note the capitalization of “groups”). If they have been using SharePoint and Exchange either on premises or in Office 365, they probably already have a mix of all the different types of “groups” shown above. When someone in that organization tries to create an Office 365 Group for – say – the Executive Team, it’s highly likely they will get an error like:

Note that “group alias” is not one of the terms used above, nor does the error give even an inkling of how to solve the problem. Not even a worthless “Contact your administrator” as a fine how-do-you-do. So, what is the user likely to do?

Well, I’ll posit that they will create a Group named “Executive Group” or “Executives” or something else spelled a little differently. That Group won’t be linked to any of the previous artifacts and thus will begin the route to more chaos that we had before.

Of course, this is a real use case I’ve run into at an actual client, as is often the case with my beefs. As far as I can tell, there is no way to convert a “Mail-enabled security group” to an “Office 365 group” without some sort of Powershell tomfoolery. That’s just bad. I’ve reached out to my MVP network for help here and I’ll update this post if I’m wrong – and I’d love to be.

This is where the old Microsoft line would have been that it’s a great “partner opportunity” or that there are “$9 spent in consulting for every $1 spent on server products”. Those were always crappy answers, and they were often driven by confusing things just like this. The “avoid a mess” or “clean up the mess” roles fell to partners who were more than happy to lap up the dollars agonized organizations were willing to toss them to fix things.

The new Microsoft doesn’t want to work this way, but in many cases, their own large size and competing teams (small “t”, generic use) still lead us to these sorts of problems.

One of the things we as consultants spend a *lot* of time doing is working with organizations to build a common set of terminology. Sometimes you may hear this called taxonomy or ontology, but the bottom line point is to get everyone to agree to a set of words and phrases that they can use consistently to express the same thing. If I came out of one of those efforts with as many terms as I’ve listed above, I’d consider the effort a failure, especially if several terms meant essentially the same thing.

The Ask

So, Dear Microsoft, please tighten up the terminology as quickly as you can. Next we need to know how to convert each of the old, legacy types of “groups” to an Office 365 Group – without resorting to Powershell. Ideally, we should just be able to click a button on any of the old things to make it a new thing, which would take us through a process (if we need one) to get it done.

Even better, when I try to create that Executive Team Office 365 Group, walk me – as a user – through fixing the issue. In other words, help me solve the problem BEFORE I’ve created the mess, so I don’t need to call a consultant to fix things. (Yes, nose, face, etc., but I think most of us consultants would rather be building valuable functionality than cleaning up messes. If your consultants relish this type of work – beware.)

Make it easy for us to help ourselves. Cut down on those support calls. Stop making your customers hire expensive consultants to clean up messes. Make Office 365 the best it can be.


Post 999! Sadly, I may have just used up my allotment of quote characters for any future posts.

Advertisements

Deleting a Very Large SharePoint List

I’ve complained about the 5000 item list threshold limit so many times, I’ve lost count. If you don’t believe me, you could read my posts here and  here and here and here.

Today’s difficulty was caused by needing to delete a Very Large List. This isn’t just a Large List – it’s Very Large. The number of items is way over 5000 at almost 300000. This list is part of a well-used application I built for a client about 3 years ago in SharePoint 2007. It’s been ticking away just fine, as there was no list threshold in 2007.

I’m migrating the application to SharePoint Online, so I’m totally rewriting it for several reasons. I copied across the list “shell” with Sharegate and brought along a few hundred items in the big list just for testing and building purposes.

But now I need to test “at volume”, so I brought across all 300k items. Unfortunately, I forgot to add an index to one of the columns where I need it to make some queries work. I figured “no big deal”. I’d just delete the list and start again.

Not so fast! When I tried to delete the list, I got this error:

I’m trying to DELETE the list, so what gives? Well, I found a post from Mike Smith (@TechTrainNotes) entitled SharePoint 2016: List View Threshold Limit to Delete a List is 99,993 Items??? which pretty much told me why this wasn’t working. It’s crazy, but you can’t delete a list or library which has more than 100k objects in it. (Read Mike’s post to see where he ran into a few wrinkles on this.) One would think that deleting a list would have nothing to do with any thresholds, but one would be wrong.

I tried a number of things – deleting the list in SharePoint Designer, writing some code to delete items one by one, etc. – but either my attempts didn’t work or they were taking forever.

Luckily, I have no pride and I complained on Twitter. Kelvin Hoyle (@kelvin_hoyle) came to the rescue!

By connecting to the list with Microsoft Access, I was able to select all the items and hit delete. Yes, this is taking a while as well, but it’s clearly faster.

The steps to do this are:

  • Open Access – I’m using Access 2016 – and create a blank database.
  • In the ribbon, go to External Data and in the Import & Link section, click on the More dropdown.
  • Choose SharePoint List
  • Provide the URL to the SharePoint site which houses the list
  • Be sure to leave the default radio button selected, creating a link between Access and the SharePoint list.

  • Click Next, and choose the list you want to work with.
  • Click OK.

Access will set up a new table which is linked to your list. You can open it like any other table in Access. Open the table and – voila – you can select any items you’d like to edit or delete.

Yet another workaround for something which I think shouldn’t be a limitation in the modern age. Sigh.

Addendum

It took overnight, but my list finally was whittled down below the 100k object level and I was able to delete it. Innovation: 1. Productivity: 0.

After I posted this, I heard from another corner of the Twittersphere. In SharePoint no one can hear you scream there are usually at least several ways to do anything.

Ryan Yeats’ Client-side SharePoint PowerShell on Codeplex looks like another good option. He tweeted some more details and let me know there’s a function called Clear-ListContent which does the heavy work. I’ve always avoided CSOM and I’ve spent enough time of this today but from a quick look, Ryan’s library looks useful here.

Reconciling Changes While Moving Content in SharePoint – “Flat” Views

Lots of times when I’m working on a content migration in SharePoint – almost always with Sharegate! – some stuff happens. Probably the most common thing is that someone edits content in the old location before we manage to shut off permissions. People – yeesh!

Here’s a little trick that not a lot of people know about that can really help. As we all know, folders are bad except when they aren’t. Oftentimes, Document Libraries have a lot of folders containing a lot of documents, for better or worse. If you want to hunt down documents someone has changed during a migration, you can set up a “flat” view, sort by Modified (descending) and see what they have been up to.

Here’s how…

Go into Library settings (how you get here will vary based on SharePoint version) and create a Standard view – or more likely start with one of the existing views, like All documents.

Give your view a name (I like Temp – because I’m probably going to delete it), scroll down to the Folders section, and expand it. Click on the Show all items without folders radio button and save your view.

Now you’ll see ALL the documents in a “flat” view (assuming you don’t have any filters set). You can add/remove any columns in the view, but the key thing here is you can sort ALL documents by things like Modified date (descending) in the UI to look for stragglers.

Office 365 Groups: Let People Outside the Organization Email the Group

As a consultant, on a daily basis I’m working in multiple Office 365 tenants. In some of those tenants I have an account (license) with my own Sympraxis email, and in many others, I have an email address within the client organization’s domain.

Believe me, it all gets pretty confusing – if it weren’t for LastPass keeping track of my logins, I’d be doomed!

With all the Office 365 Groups goodness going on, it’s great to try to keep track of “Group conversations” in a central place. By including the email alias for a Group in email-based exchanges, we can save those conversations for posterity.

Given the complexity of my account setup across clients (let me know if you have suggestions on how to make that easier!), it’s really helpful for me to use my Sympraxis email account to centralize *my* conversation activity, at least.

To do this in a given Office 365 Group, you can change the Let people outside the organization email the group setting for the Group, as shown below. This allows me to be a member of the group with whatever account I have in that tenant, but also to email in with my Sympraxis account.

In theory, this opens up your Group conversation to “spam” or other unwanted outside emails. In practice, it’s probably not a problem, especially for a Group which has a relatively limited lifespan. You’ll probably want to consider which Groups really need this setting enabled.

In any case, it was a little tricky to find the setting after the Group was set up, so I figured I’d share.

  • If you’re in the SharePoint site for the Group, Go to Group conversations (link in the upper right)
  • This takes you to the Outlook-in-a-browser view of the Group
  • In the upper right of the screen, click on the ellipses (…)

  • Click on Edit group

 

Now, if I could only choose the color for the Group! I’m sure that setting is somewhere, too. Any ideas?