Installing SharePoint is absolutely more than just a wizard, and there are a number of places where a misclick or a guess can send you into a world of hurt. With a product as complex as SharePoint, with so many moving parts, there are many intricacies to installing the software and many opportunities to cause yourself some unintended grief. Here are some quick tips on items to watch for when installing SharePoint.

Picking the right farm configuration when you install SharePoint

Unless you are installing into a test environment, you almost certainly will never want to install SharePoint into a standalone configuration—that is a scenario where all of SharePoint’s components as well as the database holding all of the content and configuration resides on just one server. That is a great setup for a lab or for your developers, because it drastically cuts down on both the number of servers required as well as the administrative overhead of managing all of those components (developers don’t make the best administrators, come to find out), but the performance under any type of load whatsoever is just miserable. Rather, you want to install SharePoint in a web farm configuration, even if you are installing to production on one server for now. This allows you to spread the production load over several servers, and importantly, you can expand as you need—whereas standalone installations are always and forever standalone.

Managed service accounts for SharePoint when it’s running on-premise

Creating, verifying, and administering service accounts—the user accounts on your company’s system that services like SharePoint and its associated programs run under—is one of the most tedious parts of being in the IT profession. What service accounts are required to run SharePoint? Which of those require certain levels of administrator access? Just to get a server farm operational, you need to have ready a SQL Server service account, a Setup user account that runs the GUI setup, the SharePoint Products Configuration Wizard, and the PSConfig and STSADM command-line tools. That’s not to take into account any service application accounts. Be sure to have all of this lined up before you start installing into a production. And of course there is the provision that you should never, ever use the Local System account (the very privileged one in Windows that gives you access to essentially everything) to administer your farm or do any SharePoint related tasks.

Choosing SQL Server instances and database locations

During SharePoint installation, you get to choose between installing SharePoint’s databases into certain instances of SQL Server. Instances, in SQL Server speak, are simply different databases that are stored on a machine – SQL Server spins up a separate instance for each created database. The bottom line is that if you intend to install any other solutions on your SharePoint server besides just SharePoint, you should install SharePoint itself into a new instance of SQL Server, rather than just the default instance that comes automatically when installing SQL Server or SQL Server Express. This will allow you maximum flexibility to put solutions like PowerPivot, and it is a real headache to try to switch database instances after SharePoint installation completes—a pounding headache. And if you get around to scripting SharePoint installations when your farm grows to multiple machines, it’s easier to script for custom SQL database names in a way that makes sense to you.

Setting up a development environment

As we have written about before, many people look to SharePoint because it is seen as an application platform on top of which custom code can be run. The folks who are writing that code will need a place to run on it while they are working on their apps, and for so many reasons, your production deployment of SharePoint is not the place for that. Have a development environment available and make sure any and all custom applications that you install on SharePoint are first staged in this development environment to work out any show-stopping issues.

SharePoint is a huge product and SharePoint installation is a process, not a task. Avoiding administrative tedium like this is a big reason why subscriptions to alternative cloud services are growing. Someone else takes on the responsibility for handling all of these little details and you simply consume a service that is delivered to you, ready to use.

See how Huddle, the #1 SharePoint alternative, works in this quick 2-minute demo.

Start the demo now

James Matthews


Request a Demo
trillatron

© 2006 - 2019. All Rights Reserved.