Adopting SharePoint into your company’s future is excellent choice, but most are not planned out for growth. Just as the first house you buy is usually not your last, the first go-around of SharePoint may not be the healthiest. Here are some points that you may want to consider changing to better suit SharePoint and its success and productivity in your company.
1. Everything in one site collection
Whenever SharePoint goes from an idea to an idea in motion, there usually isn’t much planning involved. Most companies and IT departments want to break SharePoint open to see what it can do and how they can best utilize it–and rightfully so. This is especially true in small IT departments, where decentralization comes into play. However, once it starts to grow, the structure sticks. Having all content in one site collection seems like a benign decision at first, but the problems start to creep up whenever more users start to using SharePoint in their daily workday. Sites can seem slow, especially with resource-intensive services such as Search, Excel Services, and PerformancePoint.
Microsoft recommends having a departmental structure. Having one site collection per department works, because it isolates permissions, and allows users to easily find a file, team resource, project leader, calendar, or that one document that they saw last week, etc.
Solution: PowerShell scripts can come to the rescue here, breaking out each subsite into their own site collection. There are also 3rd party tools that can accomplish the same task for you.
2. All site collections in one content database
This goes with the first point, but should be a very simple fix. Having multiple site collections are great to segregate data into their respective categories and an isolated security model. However, part of the reason to separate them into site collections is for the added benefit of having them in different content databases. Site collections are the lowest logical structure that allows for a separate content database. This increases performance and is easier to maintain. DBA’s will thank you for it! It’s much nicer to see lots of smaller databases rather than one large database.
This also helps the practice of testing with a testing environment, which I will cover later. In short, if you are working on testing a feature for a specific site collection, no need to back up the entire SharePoint content. If you need to focus on one site collection, you can backup one smaller content database.
Solution: Powershell is the choice here as well. There is a SharePoint PowerShell cmdlet called Move-SPSite that should be a one-liner in moving a site collection to a different content database.
3. Document libraries with no versioning
Many companies think of SharePoint for document storage. Storing, editing, sharing documents is at the heart of a classically used SharePoint environment. However, many do not utilize a very important feature of the document libraries–versioning. This feature has saved users from themselves and others more times than I can count.
Imagine working on a document and you go to save your document, and you or someone else drastically changes the document, not to your liking or erroneously editing the wrong cells in Excel and all the formulas mess up–but it’s already been saved. Just as the recycle bin saves users from themselves for deleting documents, versioning comes in handy for erroneous changes. If you plan on using a library for highly active documents, consider turning on versioning. There is also another setting that tells SharePoint to keep only a certain number of versions, and to delete anything older.
Solution: Turn on versioning in the advanced settings of the libraries that you want turned on.
4. Pushing hardware to the limit, not scaling up/out
When SharePoint grows out of the trial stages, some environments should be scaled up or out to allow better performance. Some topologies start out with just enough to get by, a trial-basis environment, or even an all-in-one server. When the number of normal end-users are growing exponentially, then it’s time to reevaluate if the current topology fits.
Scaling up involves beefing up the hardware. I would recommend increasing the memory on the servers first, starting with the SQL Server. Scaling out is adding more servers to the farm. The type of server depends on your environment and how you are using SharePoint, but adding a 2nd web front end, may probably be the best option if you only have one web front end. If you are adding your 2nd web front end, I would also look into using a network load balancer–whether hardware related or software related. Windows Server provides a Network Load Balancer which is a starting place.
Solution: It depends on the most used aspect of SharePoint. A list of typical topologies is a good place to start: https://technet.microsoft.com/en-us/library/cc263199.aspx#architecture
5. Too many farm solutions
Don’t get me wrong, customization is good…to an extent. Most companies that miss the target do so because they are using a lot of farm solutions to customize everything under the sun. The most practical use for farm solutions I’ve seen is branding. Branding is the customization of the look and feel to “brand” your SharePoint site to your liking. Most companies I’ve seen use branding primarily for a custom navigation, and secondly to give SharePoint a familiar face, possibly one that imitates an intranet or public facing website.
Whenever SharePoint developing came around, server-side code was very popular, and it got the job done. As SharePoint versions incremented, more and more push to the cloud became more prevalent. Any sort of customization nowadays is recommended to be client-side. This also paves the migration path to SharePoint Online, which does not include farm solutions. Microsoft continues to update the client-side technology through Cumulative Updates to increase exposure to SharePoint objects that you would normally have to use farm solutions to access. This makes moving to client-side development more possible.
Solution: Minimize the number of farm solutions if you can. First, plan to develop new customizations using client-side or using apps. Second, redevelop solutions that are crucial to your business needs in client-side or using apps, if possible. Start with the less-used and least complex farm solutions, and move to more used and most complex farm solutions.
6. No dedicated SharePoint Administrator
Whenever SharePoint gets big enough, it grows out of becoming a side project. Your best bet is to hire a SharePoint Administrator. I’d recommend this if you have at least 300 people using SharePoint especially if end-users rely on SharePoint on a daily basis to get their work done.
A good SharePoint Administrator will take care of your environment, recommend changes, support your users, and keep things running smoothly. It really is a full-time job and then some. Some companies with large environments will have a SharePoint team. The features, size, and capabilities of SharePoint make it impossible to manage part-time. This is especially true with enthusiastic users that want to expand on their department’s exposure of SharePoint. Allowing your users to build on their SharePoint presence will drastically increase adoption. A SharePoint Administrator will help facilitate new changes and make sure your users are being productive using SharePoint.
Solution: Hire a SharePoint Administrator, or hire from within the company and send them to training.
7. All services are being run by one or two accounts
Microsoft recommends to segregate service accounts into respective accounts, instead of running all services under one account. This is for a vareity of reasons. Mainly for security. If one of the accounts is compromised, the account can be changed without much headache. Another reason is separation of responsibilities. If an account needs permission or access, it’s best to give that account just enough permission to get by. This practice is known as least-privileged administration. Learn more here.
I would recommend several accounts, each being specific to several distinct services, including but not limited to: sp.install, sp.farm, sp.apppool, sp.mysites, sp.search, sp.crawl, sp.profilesync, sp.services, sp.workflow, sp.unattended. More on SharePoint service accounts here.
Solution: Create the services above and change the service accounts in Central Administration. You may also have to add the account to SQL permissions or the local Administrators on the SharePoint servers. Follow the guide linked above.
8. Being out of date
This one should not be a big shocker. Whether it’s installing a cumulative update or hotfix, updating should be a practice that is a should not be taken lightly. SharePoint updates are a little more fragile than just leaving automatic updates on. With the right person, it should be a simple process that keeps your company on par with a healthy SharePoint environment.
SharePoint migrations are an even bigger animal. Migrating from SharePoint 2010 to SharePoint 2013 is big project. Depending on how big the environment is, migrating to the next version can take months of planning and testing. There are plenty of factors to take into account, including customization, branding, workflows, and environmental variables. Depending on how big your SharePoint environment is, migrations require a team of professionals from your company, including network and system administrators, DBAs, software engineers, and business analysts.
SharePoint 2010 moved into the extended support lifecycle as of October 2015. This means there will be no future design changes, and bug fixes are only provided for those with that purchased an Extended Hotfix Support. SharePoint 2007 has until October 2017 until there is no support from Microsoft. That means you are on your own with the software–use at your own risk.
Solution: Plan for your software update or SharePoint migration if you are out of date. Gather your team and talk about the pros and cons of migration and plan accordingly. Follow the software upgrade and SharePoint migration guides.
9. Continuing to use and develop new forms in InfoPath
This goes along the same lines as using customization. It has been confirmed by Microsoft that InfoPath Services will not be part of SharePoint Server 2016, and InfoPath will not be part of Office 2016. This leaves the migration paths with InfoPath forms to a) use SharePoint Designer custom forms, b) use third-party form solutions, c) use form solutions outside of SharePoint, or d) use InfoPath client. There are probably other migration paths in the future, but Microsoft has not released any tool or feature that allows InfoPath forms to be translated, and frankly, most of the SharePoint community doesn’t think it’s coming.
The best thing to do, in my opinion, is to switch to using SharePoint Designer forms. It’s free, and it has a lot of customization potential by using HTML5/CSS3, REST API and CSOM/JSOM. Make sure that any efforts made to migrate is done using client-side development, not farm solutions, unless it’s by a third-party retail solution such as Nintex Forms.
InfoPath is still supported and moving forward, you have just under a decade before support ends for SharePoint 2013. With that amount of time, I think you should be able to change all the forms you have as long as you have the right people involved.
Solution: Start with the simple and less used InfoPath forms and work your way out to the more complex and most used forms last. Plan a migration path and notify your users of the change. Also cease all new projects involving InfoPath forms.
10. No test environment
Every healthy SharePoint implementation has a test environment. It’s one of those items on the list that people miss, but it’s important for testing any new features that are associated with SharePoint. You can test third-party solutions and webparts, new customizations, new development, test code, test the features and services, all without breaking production. If you are going to build a new test environment, though, there are some key points that make it more useful.
One thing to make sure of is to always have the development environment build match the build of production. That means the same service pack and the same build (cumulative update). You should be able to find the build you are using in Central Admin -> Servers in this farm. Production and development environments that share the same build can transfer databases, which is helpful for testing out customizations and code on production data.
Another point is to have the test environment on the same domain. This allows any references to the domain to work, allows for users in the domain to be referenced in any workflows, lists, and custom code, and also allows permissions to be transferred. For example, if you backup a production content database, and restore it to the development farm, having a matching build will allow you to mount that database to the SharePoint farm, otherwise the schema would not match and you will receive an error. Whenever that database is mounted, you should immediately be able to browse to it, and with having the same domain, the same permissions will be applied.
Solution: Build a test environment in the same domain, and patch it up to the same build as production. Put Visual Studios and SharePoint Designer on it for developers and SharePoint administrators to use.
Having a SharePoint environment can really help companies thrive and expand their reach to others, but comes with a caveat–you must configure it for growth. These points can ensure that your SharePoint users are using SharePoint in the most productive way possible: by increasing performance, maintaning supportability, providing room for growth, and being in a state of good practice according to Microsoft. These points all depend on the company, and may not always be the best option, but are suggested for most companies.