Yet another SharePoint thread
-
The biggest issues we've had with SharePoint is with permissions. You can't have your classic permissions scheme, it's waterfall or nothing.
Meaning your most private data must be buried the furthest down vs what a lot of people do which is put that data at a readily available location.
-
We utilized it pretty heavily at a prior job in the early days of Office 365. It was decent. Most of our problems were with the client. One thing it does require is a bit more upfront thinking about structure. Since you are limited in the number of folders it will display, and there might be something about how far down in the folder path it will allow you to go before making your data inaccessible, you have to plan carefully especially if people love to folder everything in your current network shares.
I'd recommend breaking your lowest consistent divider into a subsite. That may be client or department. Then you can work with it from there. This makes the permissions issues that @DustinB3403 mentioned much easier to handle. We did it by department, and then let each department dictate how they went from there. We did have the advantage of not needing much overlap between departments though.
-
We're a small company (about 20 employees), so don't have departments or any kind of hierarchy. Everyone has access to everything. If we use Teams to create a team for each client, then Teams will create a separate SharePoint site for each one, so yeah, we'd end up with each client having their own site, and sub-folders within that.
-
@carnival-boy said in Yet another SharePoint thread:
We're a small company (about 20 employees), so don't have departments or any kind of hierarchy. Everyone has access to everything. If we use Teams to create a team for each client, then Teams will create a separate SharePoint site for each one, so yeah, we'd end up with each client having their own site, and sub-folders within that.
You can also create separate Document Libraries to simplify permissions and structure. You really can't do anything with permissions below the level of a webpart very efficiently.
-
We use SharePoint extensively internally and support a number of clients that we put on to it (former SBS MVP here).
The permissions structure is similar to Group Policy or CSS where the shirt closest to your back wins permissions wise. Traverse is not something that we can do in SharePoint unlike other file permissions/shares setups. That's something to keep in mind when it comes to folder permissions structures.
We set up up dedicated subsites for our various needs.
We set up split DNS for the Internet FQDN internally and externally to make things simple for folks in and out of the office. But then, we host our own.
We set up WebDAV and use a shortcut \\sharepoint.domain.com@SSL@PORTID\DavWWWRoot for folks accessing externally. In the case of O365 the simple way to grab that UNC is to open in IE, use the Open in File Explorer option for a library, and pull the icon down from the address bar in File Explorer to Quick Access/Favourites. Right click the shortcut and Properties to get the UNC.
The simplest way to sell SP is to show folks the Check Out/In and Reviewer Approve/Disapprove and the Versions features. We enable mandatory check out/in and draft/final versioning on all libraries.
All users add Check Out/Check In/Server to their Office app's Quick Access Toolbar:
Having those three buttons up there eliminates most support calls as folks get used to checking them for a file's status.
-
Sharegate blogs are a good place to understand more about migration, limitations of SP etc
https://en.share-gate.com/blog/prepare-file-share-migration-to-sharepoint
https://en.share-gate.com/blog?category=sharepoint_migration
-
Thanks. I've a pretty good understanding of SharePoint. My purpose for this thread is to try and get some examples of real-world experiences, both good and bad, when dealing with a large number of documents.
I've used it for quite for a few years now, but not at large scale. As @scottalanmiller said, "I like SharePoint conceptually, but not in practice". Well, what are the issues in practice?
-
@carnival-boy said in Yet another SharePoint thread:
As @scottalanmiller said, "I like SharePoint conceptually, but not in practice". Well, what are the issues in practice?
Performance, cost, overhead of management, licensing, end user problems.
-
It's included in our O365 subscription so there is no cost or licensing issues. I'm not sure what you mean by overhead of management. What kind of performance and end user problems have you experienced?
-
@carnival-boy said in Yet another SharePoint thread:
It's included in our O365 subscription so there is no cost or licensing issues. I'm not sure what you mean by overhead of management. What kind of performance and end user problems have you experienced?
Cost and Licensing: Yes, you have paid for Sharepoint in a bundle, but you are still paying for it. In the E4 breakout, it's $4/mo of the $20/mo total. And you need to pay for that for everyone who uses it. Most organizations have lots of exceptions that would only need that one thing, but have to pay for more or whatever just for that one thing.
Cost of Management: Sharepoint takes a bit of time and effort to maintain. Plus backups, if you want any protection from mistakes on the client end, isn't included so is both effort and money. Sharepoint requires training and work to keep working
Performance: The system, especially through O365, is very slow and cumbersome to use. It's just not fast so people get frustrated with it.
End User: We found our less technical end users unable to cope with basic data management concepts and would throw data all over Sharepoint because they couldn't understand basic things like tagging, filtering and metadata
