A while back, I published a post on some most famous and important limits we have in SharePoint Online. These were limits that are most likely to be encountered by the users. Today, I want to introduce you to another limit that exists in SharePoint. Most of you will never experience it; however, for those who use lists or metadata on document libraries – you better not skip this article and read it to the end. Otherwise, you will join a very disappointed percentage of my blog readers after encountering the Lookup Column Threshold limit on a view and then desperately finding this post by googling for a solution. 😊

What is the Lookup Column Threshold limit on a view?

When you create lookup columns on a list or library, for performance reasons, Microsoft limits you to 12 (twelve) columns of that type of column in a single view. This is because when it is a lookup column, you are getting the data from either another list or another source. When you exceed the limit, you will get the following error message when trying to add the 13^th column to the view (this just proves that 13 is not a lucky number).

Something went wrong. The query cannot be completed because the number of lookup columns it contains exceeds the lookup column threshold.

And when you refresh the page and try to go to the document library, your library will go blank with the error message front and center.

What are lookup columns?

What is interesting here is that the lookup column in the content of this error message is not the same lookup column I blogged about some time ago.  In that post, I referred to the Lookup column type that we have in Lists and Libraries. Those Lookup columns were columns that referenced other lists and libraries on the same site.

In the context of the Lookup Column Threshold limitation, Lookup Column also refers to other types of columns! By lookup columns here, we imply the columns that obtain their data from other sources. Here is a complete list of the “lookup” columns that will cause the error message:

System Columns (Columns created and displayed out of the box)

• Created By Column (lookup against User/Employee Directory)
• Modified By Column (lookup against User/Employee Directory)
• Type Colum (Word, Excel, PowerPoint, PDF, etc.)
• Name Column (Filename)

Manual Columns (Columns created manually by users)

• Lookup Column (the actual Lookup column, lookup against another list or library)

• People Column (lookup against User/Employee Directory)
• Managed Metadata Column (lookup against the Term Store)
• Enterprise Keywords Column (lookup against the Term Store)

How to avoid the Lookup Threshold limit on a view

• The only way to avoid this issue is to limit your views to less than 12 lookup column types mentioned above. To be clear, you can have as many columns as you wish on a list or library, as long you do not exceed the 12 “lookup” ones in a single view. So, if you encounter the above limit, just hide some of the “lookup” columns from a view to fix it.
• Where appropriate, use other types of columns instead of the lookup columns (i.e., Choice instead of Managed Metadata) since those do not count against the limit
• If you do have many columns you need to display – create additional views on a list or library – just keep the number of “lookup” columns under 12 in any given view.

The post How to avoid Lookup Column Threshold limit on a view appeared first on SharePoint Maven.

A while back, I published a post on the top 5 limitations we have in SharePoint Online. This turned out to be a pretty popular article of mine. The limits I focused on back then were primarily related to the document management capabilities of SharePoint. Microsoft Teams, a separate application within the Microsoft 365 ecosystem, has its limits. Microsoft does a good job summarizing them all in this article. Most of those limits, documented in the Microsoft article, are technical limits of the application. So what I thought I would do in this article today is summarize what are, in my opinion, the top 10 limitations we have in Microsoft Teams from the user/usability standpoint. Not so much tech limits of the application, but rather annoyances users might encounter by using the application. When appropriate, I also try to explain the reason for the limitation as well.

Depending on when you get to read this article, some limitations could be resolved or mitigated. So I am just documenting the limitations in Microsoft Teams that exist as of the date of this article. The limits below are not listed in any particular order; they appear in the order they came to my mind as I wrote this post.

Limit # 1: Number of channels

The first limit for users to be aware of is the number of channels one can create in a given Team. As of the writing of this post, here are the limits that exist:

• Max Number of Standard Channels: 200
• Max Number of Private Channels: 30
• Max Number of Shared Channels: 200

Now, in all honesty, in most use cases, you probably won’t exceed those limits. However, I have worked with several clients over the years who tried to use channels within a Team for small projects, legal matters, real estate properties, etc. The idea was that you would create one team and then 1 Standard Channel for each project, client, legal matter, or property. Since 200 is the most you can create in terms of standard channels (including the deleted ones), you could run out of channels to create rather quickly. So my clients were forced to create another team to get around the limit.

To learn more about the various types of channels, please check out this post. Also, if you are on the fence about whether to create a new team or channel, this article will help as well!

Limit # 2: Limit on available applications in private and shared channels

This limit is extremely annoying and has to deal with the overall architecture of Microsoft Teams and Microsoft 365 Groups. If you use Private and Shared Channels within a Team, you probably noticed that some applications are not available. For example, say, you are in a private channel and are trying to add Planner App as a tab within the channel. Too bad, you won’t be able to. Same with Forms App or Channel Calendar app. How come?

Example of Planner App missing in Private or Shared Channel (when trying to add as a tab)

As mentioned above, this has to do with the overall architecture of Microsoft Teams. When you create a new Team in Teams, behind the scenes, it creates a Microsoft 365 Group, which is essentially a membership/security group. That group allows you to control access to the various applications available to the user who is part of the Microsoft 365 Group.

For example, if I create a Team and invite Mary and John into it, all 3 of us will also have access to the associated SharePoint Site, all Plans in Planner that are part of the Group, the Group Calendar in Outlook, Forms, and so on.

However, when you create either a Private or Shared Channel, you create a workspace for a subset of users from the Team. So using the above example, if I create a Private Channel and only invite Mary to it, only Mary and I will have access to the Channel/conversations + a separate SharePoint site that is created as a result.

However, while there is a separate SharePoint site created to store documents that are private to that Private channel, there is no separate “secure” Plan created in Planner. Security to all the plans in Planner is controlled by the Microsoft 365 Group, which, contains myself, John, and Mary. Same with the Group Outlook calendar. You only get one that the whole group shares. And Forms are exact same way, too – all forms that are part of a Microsoft 365 Group can be accessed by the whole group.

So that is why when you try to add a plan from Planner as a tab in a Private channel – you can’t do that. In theory, you could add a plan as a tab, but it will be the plan that is accessible by the whole team and not a subset of users from the Private Channel. So to avoid security issues and not to mislead the Private Channel members that their Private Channel Plan is private to them only, Microsoft prevents you from adding those group-related apps to Private and Shared Channels.

I honestly do not know how Microsoft will resolve this dilemma, unless Plans and Calendars and Forms break free from the Microsoft 365 Group and will have security/permissions of their own somehow.

Limit # 3: Impossible to chat with attendees while sharing screen

Alright, this limitation has baffled me from the start of Microsoft Teams. And in all honesty – this is why I prefer to use Zoom for my training and webinars. It comes down to one simple and @#$% annoyance – you cannot easily chat with attendees while you are sharing your screen. With Zoom, I can still see small videos of my attendees and can easily chat as well. Not with Teams. Yes, I know, I can purchase a second monitor or join Teams from a second device like iPad or phone just to see the chats, but I am Jewish, and a bit frugal about how I spend my money. 😀

Limit # 4: Metadata usage in Teams

Being a huge fan of metadata, this was my complaint from the release of Teams back in 2017. Metadata does not play well with Teams. While the improvements have been made, and we can now tag and filter files from a Microsoft Teams interface, the fact that for every standard channel, you get a folder – forces the users back into folder mentality.

For this reason, I always recommend creating a separate document library on a Team-connected SharePoint site, so it can be free of channel folders.

Limit # 5: Recording Expiration Limit

Another important limitation users must be aware of is how long the meeting recording is kept. With the recent switch from Stream Classic to New Stream on SharePoint, all the meeting recordings are now saved to SharePoint or OneDrive. As such, the video files count against the limit towards the overall storage limits within your tenant. And since videos tend to take much more space than images or MS Office files and PDFs, they are only kept for a certain number of days before being permanently deleted. By default, it keeps the recordings for 120 days. True, most of the recordings will probably never be watched again after a certain number of days, but there might be a case here or there when you need to watch that staff meeting or training from last year.

There are ways for both regular users and Teams Administrators to increase the limits. I explained how to achieve it in this article.

Limit # 6: Owners can be left out of a Private Channel

Here is another limit I kind of hate. If you are a Team Owner, you might end up in a situation where a user creates a private channel and does not invite you (the Team Owner!!!) into it. It is almost like a secret room in your own house. Now, I understand there might be valid scenarios for this in a project, but if I am, say, a Project Manager and a Team Owner and happen to be a control freak, and then discover the hidden Private Channels in my own Team, I am not part of, I might not like it. 😀

Example of a Private Channel I(the Team Owner) am not part of

By the way, if you want to prevent the above scenario, as a Team Owner, you can disable the creation of Private Channels on your Team (by regular members). Check out this post for instructions.

Limit # 7: Ownerless teams

Another limitation is that you might end up in a situation where you have a Team/Group that s left without the Owners. This occurs when the Team Owner leaves the organization, and IT disables/removes their account. Luckily, there is a way to enable a workflow/process within the Admin Center to prevent such occurrences from happening again. I documented the steps in this post.

Limit # 8: When copying a team, private and shared channels are not copied

I guess this is more of a “by design” limitation, but something that those looking to replicate teams need to know and understand. The ability to create a team from another team is awesome, since it allows you to easily copy Teams channels and tabs and replicate it for another project, for example. The problem is that private and shared channels are not copied – just the Standard channels and channel folders. So you would need to create standard and private channels manually.

Limit # 9: Hidden Group Calendar and a Distribution list

How you create your Team matters! This is yet another unfortunate limitation that drives many users and me crazy. As described earlier, the Teams app is part of a Microsoft 365 Group and is connected to a Team Site, Group Outlook Calendar, Group Outlook Distribution list, and Planner. However, if you create a Team from Teams and then try to access the group calendar, you will be out of luck. Same with the distribution list. The truth of the matter is that they do exist but are hidden from you. This was due to a change made by Microsoft some time ago. This is because with so many Teams created by users, you might not want to clutter their Outlook interface with extra groups created. Not to mention that if users see the same group in Outlook, they might start using email instead of Teams chat. However, there are use cases when you do want to see that group calendar in Outlook or perhaps send an email to all members via Outlook.

The workaround for this would be to create a Team Site first from SharePoint and then connect a Team to it afterward. When you do it in that order, since the Microsoft 365 group is not created via Teams, you will get the Group Calendar in Outlook that is not hidden.

Limit # 10: No easy way to move channels between Teams

When we moved from subsite to Flat Information Architecture in SharePoint, this was a time of joy and relief. No longer we had subsites stuck to a given site collection – we could easily take a site and associate it with a different Hub in a matter of seconds. However, with the evolution of Teams and channels – it seems like we are back to the rigid architecture, as was the case with SharePoint subsites.

While we can easily move files and folders between two SharePoint sites (channel folders), we cannot move channels themselves (that contain chats) between Teams. Yeah, I know what you are going to say – this is probably by design, but I thought I would still mention this as somewhat of a limitation. I understand why Private Channels cannot be moved, but I did get requests from clients in the past on the ability to move standard and shared channels between Teams. Possible Use cases for this involve:

• Unique projects merge into a bigger project
• Departments merge to form one larger department team
• Two separate Teams were created by accident and need to be merged into a single entity
• Changes in the Org Chart might prompt some of the channel mergers

I guess I understand the technical complexity behind this limitation (unique sites/folders, apps), but at the moment, the merge is only possible with 3^rd party migration tools.

The post Top 10 limitations in Microsoft Teams appeared first on SharePoint Maven.

One of the things I often get asked about is how to deal with various limitations in OneDrive and SharePoint Online. For those who don’t know, SharePoint Online is the file storage & sharing solution underpinning the Microsoft 365 universe of applications, including the popular Teams application, while OneDrive for Business provides for personal file storage (i.e., modern replacement for “My Documents”) as well as a client application for keeping all your cloud-based documents synchronized to your local device.

Our SquareOne peer group recently had an informal, ad-hoc meeting about this problem: Where do you turn when OneDrive and SharePoint are (seemingly) unable to meet the needs of the business?

This can happen for a few different reasons. So, before we talk about solutions, let’s examine the most common limitations that organizations can run into when using SharePoint and OneDrive.

Not enough (shared) file storage

Every single user in Microsoft 365 gets a minimum of 1 TB of personal data storage (OneDrive space). This is not usually a bottleneck for most organizations. However, SharePoint Online (where you would put any of your “shared” Company data), is limited to 1 TB + 10 GB per licensed user.

For an Enterprise organization with thousands of users, those seats add up quickly, and you will easily have several terabytes of storage available. For example, 10,000 employees x 10 GB each = ~100 TB. Small business subscriptions unfortunately share the same limitation as Enterprise, so that means a 30-person organization only gets a measly ~1.3 TB of storage total for all shared documents in SharePoint Online.

This is a problem. Particularly if there are very many files, or very large files such as architectural or engineering drawings, or high-density images, or anything like that. That meager storage will be consumed very quickly indeed. Yes, it is possible to buy additional SharePoint storage, but at USD $0.20/ GB/month, it is some of the most expensive storage space in the cloud.

My personal wish here is that Microsoft would just change the storage limitations for “Business” plans so that instead of 10 GB/user, we get something better like 100 GB/ user (at least). Or, better yet, just give us like a “Business Ultimate” plan that includes unlimited email and file storage and charge a premium price like USD $35 or $40/user/month.

Too many files to sync, or other limitations

OneDrive includes a client app that will automatically synchronize your personal files to the local desktop (we have a similar app to make them available on personal mobile devices, as well).  You can optionally choose to sync shared locations in SharePoint Online in addition to your OneDrive files. However, when you attempt to sync too many files, you can cause problems for the sync application, and then your employees fall into the Pit of End User Despair™.

How many files is too many? Well, that’s a complicated question. Microsoft recommends syncing no more than 300,000 files and folders total to your computer. But that is somewhat misleading, because I have seen the client sustain more files than that (especially since the release of the 64-bit client), but I have also seen the client bomb out under even less stress (more like 90-100K files). If memory serves right, this limitation actually comes from a .DAT file stored somewhere in your local app data folder.

As well, larger files such as architectural and engineering drawings will sync (and support for large files has improved in the last year since the release of the 64-bit client), but it still is not the same experience as working with general Office files. For example, co-authoring is not a thing here, and syncing large files is more demanding; upload times can be very slow, especially over budget links such as DSL.

Therefore, certain SMB organizations that regularly use larger file types (e.g., construction, engineering, architecture, attorneys who deal with patents which include engineering drawings, etc.) may still find the sync experience is less than ideal for their requirements, especially if they are used to having SMB shares available on their LAN.

There are a few other limitations on file structure (such as depth of folders/length of file path), and number of files per folder or view (5,000), but these are not run into quite as frequently as the other problems I just now touched on. Plus, they are generally more “correctable” than running up against storage quotas or sync issues, which are less in your power to control. Nevertheless, several other limitations do exist, and you should be aware of them.

What do we do about these limitations?

Historically the way we dealt with these problems was to tell the customer, “Well of course it isn’t working, because you aren’t doing it right!”

We would scold them for needing access to so many objects on every client device, all the time. “Don’t you know that it is impossible to work with that many files in any reasonable timeframe? Imagine trying to contribute to more than 300K files in a month, or even in a year! Nobody actually does that, so why sync all the data to begin with?!”

Or, “Look, you can’t expect every third-party file type to be supported equally: if you work with some larger file types, do not expect co-authoring on them, instead plan to download/upload your changes like you would have for all types of files 10 or 15 years ago.”

While these statements may be true, and difficult to argue with, the simple fact is that back in the olden days when customers just had a primitive NTFS file server with SMB file shares, users could keep whatever they wanted, for however long they wanted, and have access to it any day of the week. They didn’t have to obey the seemingly arbitrary laws of the Microsoft Cloud.

In an ideal world, we could just easily migrate all files and folders, as they exist today, from point A (usually an on-premises file server) to point B (the cloud), and have the experience be pretty much the same for end users. The problem is that file servers and SharePoint sites are apples and oranges. So, it’s not realistic yet to put those expectations out there (those who have, have paid dearly for it).

Yes, it is true that SharePoint does a bunch of cool stuff that your local file server cannot (e.g., metadata, search and indexing, retention labels, sensitivity for sites, etc.), but the reverse is also true: your old file server did some pretty basic things really well, some of which are still impossible for SharePoint and OneDrive.

Alternative #1: Use another popular cloud storage provider

I can’t speak for the Enterprise, but at least in the SMB market, the most popular alternatives to Microsoft’s “built-in” ecosystem for file sharing remain Dropbox, Box, and Citrix Sharefile (roughly in that order). Maybe Google Drive ranks in there as well, however, I know a lot of folks on Google’s platform also supplement with one of these other providers for file sharing, too. My personal favorite of these options is Box, but that’s just based on my own familiarity with it (others may feel strongly about one of these others—and that’s fine).

If you are going to supplement your Microsoft 365 subscription with one of these other solutions, I would recommend ensuring you get a real business plan, not a personal or “basic” plan. Generally speaking, this means you will be spending something like $25/user/month or more for a complete feature set, usually including unlimited storage space and Enterprise-grade security options. At the time of this writing, in the Dropbox world, this means aiming for at least the “Advanced” offering (for Teams). If you choose a Box subscription, this could mean the Business Plus or even Enterprise tier, and for Sharefile, you should be evaluating their Advanced or Premium options.

Why we do not have an “unlimited storage” plan in the Microsoft cloud is beyond me. If it were up to yours truly, Microsoft would have an unlimited offering that can compete with these other big hitters. The option for limitless capacity is probably the number one driver that pushes people into a third-party cloud when it comes to file storage. Note: You should not expect a switch into one of these other ecosystems to be a panacea: to eliminate all downsides, fix or prevent all sync issues, etc. However, when it comes to overall storage capacity, every other provider out there has Microsoft beat.

Anyway, if you decide third-party is the way to go, always set up Single Sign-On with Azure AD so that you can apply the same identity-based protections, such as Conditional Access, that you already enjoy with Microsoft 365. Also you should know that Box and Dropbox have integrations available with Microsoft Defender for Cloud Apps, so that you can monitor activity and create alerts and rules around these applications, just as you do for Microsoft 365, using the Activity log.

Alternative #2: Check out Azure File Sync

If you would rather not leave the Microsoft cloud, and especially if you want to maintain an experience as close as possible to your current Windows-based file server, then Azure Files is another solution worth taking a closer look at. This is basically SMB file shares in the cloud. However, the best implementation of it to replace existing file servers, in my opinion, would be Azure File Sync. This premium solution allows you to seamlessly extend your existing on-premises file server into the cloud, and the users generally cannot even tell the difference.

Basically, your existing file server gets an agent installed on it, which then synchronizes your shares into Azure Files. Client computers continue to connect to the local file servers, but the data can be migrated on the back end into Azure. Eventually the server just serves up cached copies of the most frequently accessed datasets. Better yet, you can choose to take the most infrequently accessed data (think: archives, etc.) and move those to “cooler temperature” storage in the cloud. This is cheap storage, which is slower to access, but less expensive to maintain. Active files can remain on “hot” storage so that access stays quick and reliable. This feature is known as “cloud tiering” and it is one of those things that makes the solution extra attractive. For backup, you simply deploy Azure Backup and configure a backup of Azure file shares on a schedule that works for your organization.

Now, let’s say that you need to replace your existing physical server, either because it is just time for a refresh, or because you had a sudden crash or hardware failure in your datacenter. No problem. In the short term, your end users can connect to Azure via VPN and get access to the cloud-based shares quickly. In the long-term, you would replace your physical server with something cheap and affordable: just install the agent to present the shares locally out to the network, and away you go.

Thus, Azure File Sync turns your local server into something resembling “Branch Cache” (if you were familiar with that Windows Server feature, it’s a very similar idea). It is not unreasonable to assume your current server capacity could be scaled back to maybe 20% of the storage requirements (most data lives in the cloud, with only the most frequently accessed items available on the local disks).

The big benefits to this service are that legacy applications generally still work with it (since it is still just SMB shares), and it tends to be more affordable per-user or “per-gigabyte” especially with cloud tiering enabled. Note also that both domain and workgroup environments are supported with this solution.

Alternative #3: Split the difference

The last option is to forge ahead (mostly) with Microsoft solutions: usually in a “hybrid” configuration where the on-premises server is going to be around for at least one more refresh cycle while your organization figures out the rest of the puzzle on its own.  Note: you can still start to relocate certain Office documents into OneDrive, Teams, and SharePoint as well, but you don’t have to go “all in” either. Take the time to learn how your organization can work around the current limitations in various ways. This makes for an easier end-user transition while still taking advantage of the elasticity and flexibility of the cloud where it makes sense.

For example, we direct people to use the SharePoint web interface and/or the Teams client for most shared repositories, and only sync very few data locations that contain smaller numbers of files (like a specific project folder), or other areas where the users work daily. We generally also recommend enabling the groups expiration policy and retention policies to keep content fresh and current (removing old, dead data regularly).

In a big migration project, we may even recommend migrating only those datasets which are considered “active” working data, versus all the “archival” stuff which may not need to exist in the cloud, at all. This helps cut down on clutter and overall storage demand. Some of these legacy items might end up on a separate network segment somewhere, on a legacy file server, SAN, or NAS device (where they go to die a slow death). Or maybe this is where we find a separate cloud storage account and place it under the care of a specific individual or individuals with access to those particular locations.

I should perhaps mention, there is also an alternative OneDrive/SharePoint sync client out there called Zee Drive, which some people have reportedly found success with (I cannot say much about it other than what others have told me—in other words, this is not an endorsement by any means).

Conclusion

Keep in mind that many organizations fit nicely within the existing limitations and have no problem moving 100% into the Microsoft 365 cloud ecosystem. Especially “Microsoft Office-centric” professional services that work primarily in the Office apps, perhaps with a splash of Adobe on the side, etc.

At the same time, there are many, many companies who run into these barriers due to legacy apps, large file types, larger file sets, etc., and therefore, these folks often wander down a different path. Sometimes, this means going to a third-party cloud, or it means remaining in a hybrid situation, or patching together some other alternative. This is not a new problem, either. Honestly it is a bit surprising that even now, in the year 2022, we are still left wanting in certain areas, and there isn’t always just one satisfying “right” answer. But, that’s where your consulting comes in, isn’t it?

What else have you been deploying for your customers when Microsoft doesn’t quite fit the bill? Let us know in the comments, below!

The post Alternatives to OneDrive and SharePoint (and when to consider them) appeared first on ITProMentor.