SharePoint 2010: Grow your SharePoint farm
SharePoint includes a number of tools and management interfaces for configuring and managing your SharePoint farm.
Steve Wright and Corey Erkes
Adapted from “Pro SharePoint 2010 Governance” (Apress)
One of the more confusing aspects of configuring a SharePoint farm is that there’s usually more than one way to do the same thing. That’s because SharePoint has three separate administration interfaces.
The simplest interface is the Central Administration (CA) Web site. The SharePoint installation program automatically creates the CA site when it initially creates a SharePoint farm. You can get through most administration tasks using CA and a series of simple-to-use Web pages. This interface is ideal if you aren’t comfortable writing code or if you need to perform certain tasks that don’t require automation.
The next interface, available from the Windows command line, is the SharePoint Administration tool, known as STSADM. The STS in the name of this tool dates back to the days when SharePoint was known as SharePoint Team Services.
STSADM accepts any of a large number of commands executed against the farm’s configuration. These commands include listing, adding and removing site collections. At last count, there were 177 separate STSADM commands. The tool also includes an interface that lets you develop additional commands for customized tasks and is ideal if you need to automate repetitive tasks and prefer to use Windows command language files.
It’s important to note that Microsoft considers the STSADM tool deprecated and may not include it in future versions of the product. New scripts should be written using the SharePoint 2010 Management Shell interface.
The last interface is based on the Windows PowerShell environment. This interface is called the SharePoint 2010 Management Shell. This is a command-line type of environment that lets you create more flexible object-oriented scripts. Like the STSADM tool, the Management Shell provides a large number of commands (known as cmdlets in Windows PowerShell) that drive the configuration actions in SharePoint.
One advantage of the Management Shell interface is that it allows for easier processing of repetitive tasks using built-in looping and command connections. It’s object-oriented instead of command-line oriented, so the Management Shell is best suited for you if you’re comfortable writing code in more sophisticated programming languages.
The differences between the three administration interfaces are mostly a matter of convenience and familiarity for the administrators using them. With only a few exceptions, you can do anything in any of them. For automating tasks, the CA Web site is a poor choice. STSADM is a simpler but less-flexible interface because of the limitations of the Windows command language. Also, Microsoft’s strategy is to move away from the batch environment and promote Windows PowerShell as the alternative moving forward. If you’re interested in learning one of the command-line interfaces, the Management Shell is likely your best choice.
SharePoint managed accounts
Service accounts have always been a challenge when configuring enterprise applications. These are the accounts the application uses to load and execute on the system. In general, some of the best practices around service accounts are as follows:
- Always use an Active Directory domain account, not a local system account.
- Change the account password regularly.
- Avoid using the same service account for everything.
- Use different accounts for different purposes, even within the same server farm.
- Assign only the privileges required for that service account to perform the actions required, no more.
Unfortunately, many of these practices make managing service accounts so difficult that few organizations adhere to them properly. SharePoint 2010 has introduced the use of managed accounts to simplify the process of maintaining good security practices around service accounts.
A managed account is a service account registered with SharePoint. This is an Active Directory domain account granted a set of permissions for a specific role in the server farm. The user name and password are given to SharePoint once. You can reuse them as necessary when configuring the farm. These service accounts are typically configured during initial server farm installation. You can, however, reconfigure them later as necessary.
The most difficult part of dealing with service accounts has always been the need to regularly change the password. Once the password was changed in Active Directory, the services that depended on it would begin failing until the password was manually updated in each and every place the account was used—which could be hundreds of individual configurations. Obviously, this was time-consuming and error-prone. As a result, it was also very rarely done. In contrast, when using managed accounts, the credentials for the account are stored securely within SharePoint.
SharePoint even has the ability to automatically generate new passwords on a regular basis. SharePoint changes the password in Active Directory and stores the strong password it generated in its own configuration. This keeps the accounts secure without requiring that you manually reset passwords.
Most of the functionality in the SharePoint platform can be turned on or off using features. Turning a feature on can radically change the behavior of a SharePoint site. The SharePoint Publishing feature is an excellent example. When you activate this feature, new libraries, workflows and page publishing mechanisms suddenly appear in a site that previously held simple content.
When considering the design and activation of features, it’s important to remember that each feature has a declared scope. This defines the breadth of effect the feature can have within the SharePoint farm.
Sandboxing is a new feature introduced in SharePoint 2010. It’s also known as the User Code Service. The purpose of the sandbox service is to let you introduce non-trusted executable code into the SharePoint environment without compromising the security, performance or reliability of the server farm. Code deployed to the sandbox service is said to be “running in the sandbox.”
Code running in the sandbox is isolated from the rest of the server farm’s executing code. This isolation includes running this code in an entirely different set of Windows processes. This lets you start, monitor, configure and stop these applications without impacting any other part of the system. Here are some of the most important points to remember about sandboxed code:
- You deploy sandboxed code to a site collection’s Site Solution Gallery and it always runs within the context of that single site collection.
- Sandboxed code can only access resources within the site collection to which it’s deployed.
- The actions available to sandboxed code are severely limited using a set of SharePoint API proxy libraries and Code Access Security (CAS) policies.
- Site collection administrators are ultimately responsible for deploying and removing sandboxed code.
- Farm administrators are responsible for configuring the sandbox service, monitoring its use, and setting quotas they can use to automatically disable noncompliant code in the sandbox.
- InfoPath forms can contain .NET managed code that will run in the sandbox when they’re run as browser-based forms.
For custom code to run outside the sandbox, you’ll have to deploy it to the server farm’s Solution Gallery. Only then will it run in a full-trust execution environment. As such, this code must be thoroughly tested and trusted prior to deployment.
Security experts insist you should always run code under a least-privileges set of permissions. This means that code should never be able to do anything it truly doesn’t need to do. In the context of custom SharePoint solutions, this implies all custom code should run in the sandbox unless there’s an overwhelming reason to move it to the farm level.
As a practical matter, code that’s trusted and intended for use across all of the farm’s site collections will generally be deployed as a farm solution. Custom code developed for a specific purpose for a small set of users will typically reside in the sandbox.
User profiles and My Sites
A SharePoint user profile contains all of the metadata about a particular user. This may include name, phone number, office location, specialties and skills. You can add custom metadata to the SharePoint profiles as well. The data for these profiles is either provided by the users themselves or an external system such as a human resources database or Active Directory.
The SharePoint User Profile Service stores and manages the profiles. This service application provides a common set of data for users throughout the farm. You can configure the service to provide custom behaviors such as the following:
- Policies can control the visibility of user profile properties to other users.
- You can use user profile information to create target audiences that can control information delivery to end users.
- Users can update some of their own profile properties, while others remain read-only.
The user profile feature also supports social media features in SharePoint. These include adding ratings and tags to content within the farm. There can also be references and notes on external resources. You can control these social features with the Use Social Features permission.
The My Sites feature lets each authenticated user create a Web site as a personal workspace. The user can also use this site to share information with others or create new content in a private area for later publication. My Sites often contain personal, sensitive information, so take great care when planning and configuring this feature. The volume of data stored in My Sites can be limited to prevent the system from being overwhelmed with private data. You can also disable the My Site feature at the farm level or give access to a limited set of users with the Use Personal Features permission.
Using these general sets of SharePoint features and the different management interfaces can give your SharePoint farm a unique configuration. Determine what you need from your SharePoint farm and how you want it to operate, and these tools will support your desired configuration.
Steve Wright is a senior manager in business intelligence management for Sogeti USA LLC in Omaha, Neb. Over the last 20-plus years, Wright has worked on air traffic control, financial, insurance and a multitude of other types of systems. He has authored and performed technical reviews for many previous titles covering Microsoft products including Windows, SharePoint, SQL Server and BizTalk.
Corey Erkes is a manager consultant for Sogeti USA LLC in Omaha, Neb. Erkes has worked with a wide range of companies at different points in the lifecycles of their SharePoint implementations. He’s also one of the founding members of the Omaha SharePoint Users Group.
©2012 Apress Inc. All rights reserved. Printed with permission from Apress. Copyright 2012. “Pro SharePoint 2012 Governance” by Steve Wright and Corey Erkes. For more information on this title and other similar books, please visit apress.com.