Sharepoint 2010 Key



A Microsoft Office 2010 product key is a 25-digit code that allows you to activate a copy of MS Office 2010. It looks like this: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX If you don’t enter a working serial key, you will not be able to access all the features the Operating System has to offer. PerformancePoint Services in SharePoint Server 2010 can increase visibility into key organizational objectives and metrics, and enable richer depth of analysis and insight. You or others in your organization can create and use interactive dashboards with scorecards, reports, and filters to find trends. You could see the Key Filters in the left hand pane of the user interface. Select some value from the key field and click on 'Apply'. You could see the view has been changed for the list based on the key field value. Configure Key Filters in SharePoint 2010.

Home > Articles

  1. Examining SharePoint Installation Prerequisites
Page 1 of 6Next >
This chapter covers the specifics of how SharePoint 2010 is installed for a simple, single server farm. Although these examples outline a simple farm, the concepts can be extended to multiserver farm deployments.
This chapter is from the book
Microsoft SharePoint 2010 Unleashed

This chapter is from the book

This chapter is from the book

After SharePoint architecture has been established, the actual SharePoint infrastructure must be installed and servers must be deployed. For the most part, installation of SharePoint 2010 is straightforward, particularly with the free SharePoint Foundation Server. The full Microsoft SharePoint Server 2010 product, on the other hand, requires more thought and involves the installation of more components.

This chapter covers the specifics of how SharePoint 2010 is installed for a simple, single server farm. Although these examples outline a simple farm, the concepts can be extended to multiserver farm deployments. After reviewing this chapter, it is highly recommended to review the subsequent chapter (Chapter 4, 'Advanced SharePoint 2010 Installation and Scalability') for more complex farm configurations.

It is recommended to review the design chapter (Chapter 2, 'Architecting a SharePoint 2010 Deployment') before beginning installation of a production environment. However, installation of a SharePoint server for testing can be easily performed with only this chapter as a guide.

Examining SharePoint Installation Prerequisites

Before installing SharePoint 2010, several prerequisites must first be satisfied, including both hardware and software prerequisites.

Defining Hardware Prerequisites for SharePoint 2010

A server that will be running all SharePoint roles, including the database role, should have the following minimum requirements:

  • 64-bit four core (minimum) processor
  • 8GB to 16GB of RAM (8GB for evaluation or testing, 16GB for production)
  • 80GB of drive space for the system drive (plus twice as much space as the amount of RAM in the system)

The server that holds the SharePoint database, whether on the same box (an all-in-one server) or on a dedicated server or existing SQL implementation, should generally be designed toward the high level on the hardware scale, because some of the more intensive activity is centralized on that server role.

As a rule of thumb, it is always recommended to deploy SharePoint on multiple servers, and at a minimum to deploy SharePoint on at least two servers: one for the database and one for the other SharePoint-specific roles. For more information on supported farm topologies, refer to Chapter 2.

Examining Software Requirements for SharePoint 2010

SharePoint 2010 requires either Windows Server 2008 SP2 or Windows Server 2008 R2. More specifically, the following Windows OS editions are supported:

  • Windows Server 2008 R2 (x64) Standard, Enterprise, Datacenter, or Web Server Editions
  • Windows Server 2008 SP2 (x64) Standard, Enterprise, Datacenter, or Web Server Editions

In nearly all scenarios, it is recommend to use the latest version of the Windows Server operating system (in this case, the R2 edition), though in the future, it is highly likely that SharePoint will use newer editions as well. For most deployments, the Standard edition of Windows Server is sufficient, except in certain scenarios when the Enterprise Edition is required for running SQL Server Enterprise Edition. The Datacenter edition, while supported, is not required, and the Web Server edition, while supported, is not recommended.

Service Account Requirements

It is strongly recommended that you create multiple service accounts for SharePoint. Although doing so might seem tedious, SharePoint will not be secure unless multiple service accounts are used. And in any situation, do NOT use a domain admin account for any SharePoint service.

The following provides a recommended list of service accounts that should be created. This should not be considered to be an exhaustive list; more might be needed depending on the requirements of the individual deployment:

  • SQL admin account—SQL Server should be administered with a separate set of credentials than those used for SharePoint.
  • Installation account—Used to install the SharePoint binaries on the SharePoint role servers. This account requires local admin rights on each SharePoint server and DBCreator and SecurityAdmin rights on the SQL Server.
  • SharePoint farm admins—Used to administer the farm; should be configured. Typically, one account for each physical admin is created.
  • Application pool identity accounts—Needed for each app pool. Generally speaking, it is good practice to have a separate app pool for each application. These accounts must be separate from farm admin accounts.
  • Default content access account—The default account used to crawl SharePoint and other content. It must not be a farm admin, or the search results will include unpublished data in the results. There may be additional content access accounts created for other data sources that are crawled as well.
  • Search service application account—This account is used to run the search service application.
  • Additional service application accounts as needed—May require a separate service application account in certain scenarios.

Outlining Additional Prerequisites

In addition to the base Operating System, SharePoint also requires the hotfixes referenced in KB articles 976462 and 979917. These hotfixes are installed automatically when using the SharePoint installer. The SharePoint installer also installs the following server roles:

  • Web Server (IIS) role
  • Application server role
  • Microsoft .NET Framework version 3.5 SP1
  • Microsoft Sync Framework Runtime v1.0 (x64)
  • Microsoft Filter Pack 2.0
  • Microsoft Chart Controls for the Microsoft .NET Framework 3.5
  • Windows PowerShell 2.0
  • SQL Server 2008 Native Client
  • SQL Server 2008 Analysis Services ADOMD.NET
  • ADO.NET data services update for .NET Framework 3.5 SP1
  • Windows Identity Foundation (WIF)

Database Role Prerequisites

For the database role, it is recommended to deploy the latest version of SQL Server, SQL 2008 R2. The following versions of SQL Server are directly supported:

  • SQL Server 2008 R2 x64, Standard or Enterprise Editions
  • SQL Server 2008 x64 (x86 cannot be used) with SP1 and Cumulative Update 2 or CU5 (or later than CU5—CU3 and CU4 are not recommended), Standard or Enterprise Editions
  • SQL Server 2005 with SP3 x64 (x86 cannot be used) and CU3

In addition, depending on whether advanced SQL functionality is required, the following components may also be needed:

  • SQL Server 2008 R2, if working with PowerPivot workbooks.
  • SQL Server 2008 R2 Reporting Services add-in for Microsoft SharePoint Technologies 2010 (SSRS) to use Access Services for SharePoint 2010.
  • Microsoft Server Speech Platform for phonetic name matching to work correctly for SharePoint Search 2010.
  • If using the standalone server install option (not recommended), SQL Server 2008 Express with SP1, which is installed automatically.

FAST Search Requirements

If a FAST Search server for advanced SharePoint Search is required, different installation procedures and prerequisites apply. For more information on this topic, refer to Chapter 8, 'Leveraging and Optimizing Search in SharePoint 2010.'

Related Resources

  • Recorded Online Training $29.74
  • Book $27.99
  • eBook (Watermarked) $22.39

One of the greatest enhancements to upgrade to SharePoint 2010 is the work that was done in PreUpgradeCheck and in the powershell commandlets of Test-SPContentDatabase and Upgrade-SPContentDatabase. Test-SPContent Database is very similar to the stsadm command PreUpgradeCheck, but it works with both 2007 and 2010. This command can be pointed at a database that isn’t part of the farm! That’s the coolest. If you want to see how a content database would fare in a given farm you can run the Test-SPContentDatabase command and get information on issues that would impact the farm you’re importing it into. Is the database compatible? Does it have all the assemblies installed, all the relevant features and solutions all set? Well run the commandlet to find out.

Many will be building new SharePoint 2010 farms and wanting to start clean from a hardware and software perspective. I do expect this to be the most common scenario. With just options of in-place upgrade or database attach, you’ll find this command to be the key. If you only run preupgradecheck (more resources below) on the farm you’re moving from, you’re missing important steps.

Preparing for Upgrade with Powershell

Test-SPContentDatabase -Name -WebApplication [-AssignmentCollection ] [-DatabaseCredentials ] [-ServerInstance ]

Test-SPContentDatabase –name SPContentDatabase –WebApplication http://test

2010

Here’s an example of a sample Test-SPContentDatabase

In the example above, you can see examples of missing files, with a note to remedy by installing the missing feature with a path to the missing .dwp in this example. Also note that it shows if this will block the database attach upgrade. Pretty cool.

If you were to compare PreUpgradeCheck and Test-SPContentDatabase you’d see the output and reporting is very different, but they do compliment each other. For example with database attach at a minimum you should run them both. On your source you should be running preupgradecheck and in the destination you should be running test-spcontentdatabase.

Source (Your 2007 farm): PreUpgradeCheck will tell you what is broken or missing in the source.

Destination (Your Clean 2010 Farm): Test-SPContentDatabase will tell you what you’ve missed in setting up your 2010 farm.

There’s more information on TechNet on actually running the Test-SPContent database command. Here’s a couple of quotes on actual usage. Note, this is beta content and it may change. There’s some hidden gems of tips in these paragraphs below.

“Before you add the content databases to the Web applications, you can use a Windows PowerShell cmdlet to verify that you have all the custom components that you need for that database. At the command prompt, run the following cmdlet:

Test-SPContentDatabase –Name <database name> -WebApplication <URL>

[-ServerInstance <ServerInstanceName>][-DatabaseCredentials <Domainusername>]

When you add the content databases, be sure that the root site for the Web application is included in the first content database that you add. In other words, before you continue, examine the root of the Web application in the original server farm to determine the first site collection. After you add the database that contains the root site, you can add the other content databases for the Web application in any order. You do not have to create any site collections to store the content before you add the database; this process creates the site collections for you. Be sure that you do not add any new site collections until you have restored all the content databases.

You must use the Stsadm command-line tool to add a content database to a Web application. Using the SharePoint Central Administration pages to attach a content database is not supported for upgrading.” emphasis added be me.

Database Attach with STSADM AddContentDb

“To add a content database to a Web application, you must use the addcontentdb operation.” (Emphasis added)

Simple:

stsadm -o addcontentdb -url <URL> -databasename <database name>

With Options:

stsadm.exe -o addcontentdb -url <URL name> [-assignnewdatabaseid] [-clearchangelog] -databasename <database name> [-databaseserver <database server name>] [-databaseuser <database username>] [-databasepassword <database password>] [-sitewarning <site warning count>] [-sitemax <site max count>]

If you are actually running a database attach upgrade please note that some of these options on the upgrade are added for specific reasons related to troubleshooting issues, such as clearing the change log and assigning a new database id because it’s already taken.

The powershell command Upgrade-SPContentDatabase can be used to resume a database attach failure. So you’d use the test-spcontentdatabase to check for missing, and use stsadm –o addcontentdb to add the content database, and use upgrade-spcontentdatabase to resume upgrades with issues.

After Infra Update each content database IDs are retained when you restore or reattach the database by using built-in tools. “Default change log retention behavior when using built-in tools is as follows:

  • The change logs for all databases are retained when you restore a farm.

  • The change log for a content database is retained when you reattach the database.

  • The change log for a content database is NOT retained when you restore just the content database.

Clearing the change log forces Search to run a full crawl on that database so that the index no longer references items that do not exist.”

Verify Status with Upgrade Logs and Upgrade Status Page

There are many places and ways you can check upgrade status. You can use the Upgrade Status page in Central Administration to check the status of upgrade on your site collections and then check the upgrade log, and run STSADM.

  • STSADM -o localupgradestatus (To see if any sites were missed or skipped for upgrade, be sure to run it on all WFEs.)
  • Upgrade Status page – From Central Administration, click Upgrade and Migration then Check upgrade status.
  • To open the upgrade and err log files – %COMMONPROGRAMFILES%Microsoft Sharedweb server extensions14LOGS. Note there are logs for each session.

Recap with Steps for 2007 to 2010 database attach upgrade based on the information in this post:

Of Course.. Acquire hardware, run lots of backups along the way, and build out the 2010 farm with all the best practices, run it all on a test environment, etc… Also note this is back of the napkin, obviously you need to add you own additional steps of communication, validation, and any other additional operational steps, etc…

1. Run PreUpgradeCheck on 2007 farm

2. Fix and address issues

3. Run PreUpgradeCheck to verify all issues addressed

Sharepoint key terms

4. Run Test-SpContentDatabase

5. Fix issues and make planning choices appropriately

6. Re-Rerun Test-SpContentDatabase

7. Upgrade the Service Apps and verify they are all good, then Run stsadm –o addcontentdatabase to add the relevant databases to the relevant web apps

8. Check the upgrade status both in central admin and in stsadm –o localupgradestatus on each SharePoint server and check the logs to verify the upgrade process itself was successful.

9. Re-Run Test-SPContentDatabase and verify database upgrade of sites was successful

10. Troubleshoot any issues then run Upgrade-SPContentDatabase if any databases need to resume upgrade

10. Visual verification

— Ready to start visual upgrade

Powershell Commands useful around Upgrade

2010

Test-SpContentDatabase – discussed in this post

Upgrade-SPContentDatabase – to resume failed upgrades

Upgrade-SPEnterpriseSearchServiceApplication – Upgrade Search

Upgrade-SPSingleSignOnDatabase – Upgrade SSO

STSADM Commands useful around preparing for Upgrade

stsadm -o ExportIPFSAdminObjects

stsadm -o MergeContentDB

stsadm -o EnumAllWebs

stsadm -o DatabaseRepair [-deletecorruption]

stsadm -o DeleteSite [-force] [-gradualdelete]

stsadm -o DeleteWeb [-force]

Sharepoint 2010 Enterprise Keywords

stsadm -o ForceDeleteList

stsadm -o VariationsFixupTool

Sharepoint 2010 Export Keywords

stsadm –o Upgrade (Used for build to build upgrades, including service packs.)

More on TechNet

PreUpgradeCheck

Joel Oleson Preparing for Upgrade to 2010 Today – Preupgradecheck
Joel Oleson 5 Reasons SharePoint 2010 PreUpgradeCheck is better than Prescan …
Preparing for Upgrade to SharePoint 2010 with Joel Oleson Quest … (Slides on SlideShare)

Additional Resources from the Community: