Installing SharePoint 2010 using Least Privilege Service Accounts

SharePoint 2010 is definitely generating a lot of buzz out there in the community, especially amongst partners and customers and with the official launch only a day away, I thought it would be ideal to update my installation which I first blogged about Installing SharePoint 2010 on a Windows 2008 R2 Server using all the RTM bits. For those of you that aren’t aware, SharePoint 2010 and SQL 2008 R2 are now available for download via TechNet or MSDN and will be available to Volume Licensing customers post launch, 12 May 2010.

The below setup will be based on SharePoint 2007 best practices and SharePoint 2010 TechNet documentation on “proposed” best practices with this setup utilising the least privilege model for our SharePoint service accounts. Before delving into the setup which will form the basis of all future blog posts on SharePoint 2010, I have provided the below summary of the environment that I will be working with.


  • Windows 2008 R2 server running Active Directory Domain Services
  • Windows 2008 R2 server running SQL 2008 R2
  • Windows 2008 R2 server running SharePoint 2010 RTM
  • Windows 2008 R2 server running Exchange 2010 RTM
  • Windows 7 client running Office 2010 RTM

The Preparation

Before we delve into the actual installation, let’s begin to talk about what service accounts are required for the new SharePoint Farm setup. TechNet has a great article on the service accounts required and their respective privileges which you can read in some detail here. In summary, these are not much different to the SharePoint 2007 best practices for utilising the Least Privilege model for service accounts and goes as follows;

  1. SQL Server Service Account
    This should be a standard domain user account which will be used to run the MSSQLSERVER and SQLSERVERAGENT services on your SQL server.
    e.g. DOMAIN\sp_sql
  2. SharePoint Setup User Account
    This should be a standard domain user account that will be used as the logged in user when installing SharePoint and for when running the SharePoint Products Configuration Wizard. This account must be a member of the Local Administrators group for each server where SharePoint 2010 will be installed. You will also need to create a SQL server login with the following SQL server security roles; “securityadmin” and “dbcreator”. Instructions below.
    e.g. DOMAIN\sp_admin
  3. Server Farm/Database Access Account
    You guessed it, this should also be a standard domain user account, however we do not need to grant any necessary permissions to this account as this is handled by the SharePoint Setup User Account during the SharePoint Products Configuration Wizard. This is the account that we nominate as the “Database Access” account during the SharePoint Configuration Wizard. This account will be applied against the SharePoint Foundation Workflow Timer Service and the SharePoint Central Administration Web Site Application Pool.
    e.g. DOMAIN\sp_farm

It’s imperative that these accounts are created and provisioned before attempting any installation of the SharePoint 2010 bits. This article is assuming that SQL 2008 R2 has already been installed in your environment using the SQL server service account.

Firstly, have your Active Directory Administrator create the above accounts in Active Directory as standard domain users. Then navigate to each server in which you will install SharePoint 2010 and add the DOMAIN\sp_admin account (SharePoint Setup User Account) to the Local Administrator’s group of that respective server.

Navigate to Start / Administrative Tools / Server Manager / Local Users and Groups and then click on the Groups folder.

Add the DOMAIN\sp_admin user to the Administrator’s group.


We next venture to our SQL 2008 R2 server to configure our sp_admin account as a SQL server login.

Launch the SQL 2008 R2 Management Console and navigate to Security / Logins.


Right click on Logins and select New Login;

Search for the newly created sp_admin domain account


Click on Server Roles and select dbcreator and securityadmin as your server roles. Public will be selected by default.


Now that our environment is prepped up with your service accounts, we can now proceed with the installation, so let the *games* begin!!

The Install

Launch the SharePoint 2010 splash installation screen and ensure you have met the necessary hardware and software requirements. You can find more details in the following TechNet article. It’s important that you download and install the WCF hotfix listed in the above TechNet article. This hotfix is specific to the OS version that you are installing SharePoint 2010 on.


Run the Install software prerequisites first! This preparation tool will actually install the majority of the prerequisites listed in the TechNet article.


Click Next

Accept the terms of the License Agreement

The preparation tool begins installing the pre-requisites. It’s imperative that your SharePoint server has an internet connection as it will connect to the internet during the preparation and download the necessary software listed above.


After the installation of the prerequisites is complete, you will be asked to re-start your computer.


After your server has restarted, the preparation tool should pick up from where it last left and finalise any further configuration that is required. You should then receive a successful completed installation dialog window as per the below.


Click Finish.

You will then be required to re-launch the install splash screen and this time round click on Install SharePoint Server.

Enter your product key

Accept the Microsoft Software License Terms.


Select Server Farm (we all know not to select Standalone right?! Big no no in production)


Again, don’t be fooled into selecting the Stand-alone option which is identical to the Stand-alone option in the previous screen. Be sure to select Complete and click Next to proceed with the installation.

Once SharePoint has copied it’s files, the Run Configuration Wizard window will appear.


Click Close

The SharePoint Products Configuration Wizard will then launch


Click Next

Click Yes on the following warning.


Select “Create a new server farm”


Click Next

Enter the name of your SQL 208 R2 server and keep the default database name for SharePoint 2010 Configuration database. Then enter the SharePoint Farm account as the Database Access Account. i.e. DOMAIN\sp_farm


Click Next

Enter a Passphrase. As mentioned below, this designated passphrase is configured to ensure that no other SharePoint servers can join this farm unless the passphrase is provided. The passphrase must meet the following requirements;

  • Contains at least eight characters
  • Contains at least three of the following four character groups:
  • English uppercase characters (from A through Z)
  • English lowercase characters (from a through z)
  • Numerals (from 0 through 9)
  • Nonalphabetic characters (such as !, $, #, %)


Configure your SharePoint Central Administration Web Application settings. I always like to change the default port number to something that is easier to remember.

You are also presented with the authentication provider options for your CA Web Application in which it is usually best practice to utilise Kerberos for your SharePoint Web Sites, however NTLM will suffice for your SharePoint CA Web Application.


Click Next


Click Next.

The infamous performing configuration task screen is displayed. All we can do now is cross our fingers and wait…


Upon completion you should receive the following confirmation that the configuration was a success.


Click Finish

The SharePoint 2010 Central Administration website that was just created should launch.

The Customer Experience Improvement Program which is available with most Microsoft products will pop up in a separate Window.


After answering Yes or No the Customer Experience Improvement Program the Configure your SharePoint farm wizard option will appear. We will click Cancel and go through the configuration of our service applications in subsequent future articles.


That’s all that is to it. Before signing out, let’s venture into a couple of key areas to confirm the details of our farm configuration and then venture across to our SQL server and launch SQL Management Studio to determine what databases are created by default.

Let’s begin by navigating to Central Administration / System Settings / Manage servers in this farm. After confirming the server listing as per our installation, navigate to your SQL 2008 R2 server and launch SQL Management studio. Browse to databases to see our SharePoint 2010 Databases listed, namely the SharePoint config database and the SharePoint Central Administration Database.

I hope this article has some shed some light with your SharePoint 2010 deployment and we will continue our focus in near future articles in configuring our SharePoint farm and focusing on the service applications that are on offer.


Administrative and service accounts required for initial deployment (SharePoint Server 2010)

Prepare for deployment (SharePoint Server 2010)

Deployment scenarios (SharePoint Server 2010)

Upgrading your Content Database From SharePoint 2007 to SharePoint 2010 – Part 2 – Database Attach method

Welcome back to the second article in this series on upgrading a SharePoint 2007 content database to SharePoint 2010. In Upgrading your Content DB From SharePoint 2007 to SharePoint 2010 – Part 1, The preupgradecheck we deep dived into the preupgrade tool that Microsoft made available with SharePoint 2007 SP2 and today we will complete our upgrade journey utilising one of the 3 upgrade models that are available to you by Microsoft. These are listed as follows;

  1. In-place upgrade
  2. Database attach upgrade to a new farm
  3. Hybrid approach (Read –only databases or Detach databases)

There is a wealth of information regarding these different approaches on the Microsoft TechNet site under the Upgrade and Migration Resource Center for SharePoint 2010. I will also outline other resources at the end of this article for convenience.

The upgrade model that I have chosen in this article series is the Database attach upgrade approach in which I will outline in this step by step guide. The upgrade choice you choose is dependent on a number of factors such as how much down time can you afford and whether you are moving onto newer hardware. All three options have their strong and weak points which is outlined in the following TechNet article; Determine Upgrade approach (SharePoint 2010)

This article is assuming that your SharePoint 2010 environment is up and running (albeit in beta form). I have published a 3 part series in getting your SharePoint 2010 environment up and running that you can access from the following links;

  1. Installing SharePoint 2010 Beta on a Windows 2008 R2 Server
  2. Configuring SharePoint 2010 (Beta) Service Applications and User Profile Service Synchronization
  3. Creating your first SharePoint 2010 Beta Web Application and Site Collection

When using the database attach method to upgrade your databases to SharePoint 2010, you need to be aware that none of your configuration settings in SharePoint 2007 will migrate. You will need to ensure that you have replicated your 2007 environment in the newly created 2010 farm. Some of the items to consider include the following;

  • Outgoing email server
  • Alternate Access Mappings (AAM)
  • Quota templates
  • Included paths
  • Install any custom or 3rd party features, including web parts, solutions
  • Custom site definitions
  • Custom CSS

In order for you to perform a database attach upgrade into your SharePoint 2010 environment you need to ensure that you have created a new web application. If you have not done so, you can follow my step by step guide on Creating your first SharePoint 2010 Beta Web Application and Site Collection.

Step 1 :: Restoring a copy of your SharePoint 2007 content database

Now that we have ensured that all our configuration settings are in place, and that all custom features, web parts and solutions have been re-instated, we can now proceed with our upgrade. You will need to firstly backup and take a copy of your SharePoint 2007 content database and restore it to the newly created SharePoint 2010 farm.

I’m performing my database restore utilising SQL 2008 Management Console. Right click on Databases and select Restore Database.

Select your source and destination as follows;


Click on Options and ensure you have selected Overwrite the existing database


Click OK.

We should receive the following confirmation message once the database has been successfully restored.


Step 2 :: Verifying the Content Database

As you have already noticed from our first article, in particular with the introduction of the preupgrade check tool, Microsoft have done a great job in providing us with the necessary tools to ensure a successful upgrade. The next tool that we will be using is the Test-SPContentDatabase Windows PowerShell cmdlet. This cmdlet will test and verify that any custom components that are required for this content database has been installed and configured in the SharePoint 2010 environment.

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

Launch the SharePoint 2010 Management Shell and type the above command, ensuring you have entered your Database Name and URL. e.g. below

Test-SPContentDatabase –Name WSS_Content_Intranet -WebApplication

The Test-SPContentDatabase is a great reporting tool that will list any missing setup files, web parts and provide you with information on how to remedy any errors. It will also specify whether these missing features will block the upgrade from succeeding.


You can either attend to these missing features pre or post-upgrade but this depends on whether there are any items that will block the upgrade from proceeding. Once you have remedied the above, we can proceed with our next tool, which will add the content database to our Web Application. The stsadm addcontenddb command line parameter is as follows;

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

Before proceeding, ensure that there are currently no databases connected to the web application that we will be attaching to. You can check this via Central Administration / Application Management / Manage content databases.


If one is listed, you can remove the existing attached database by clicking on the actual database name and then clicking on the “Remove content database” check box.


You will receive the above warning which is safe to ignore. In this instance we are not deleting the actual database but disassociating it from the selected Web Application. This is the exact same behaviour that was available to us in SharePoint 2007.

We can now proceed and attach our restored SharePoint 2007 database via the following stsadm command line;

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

In my instance, the command looked as follows;

stsadm -o addcontentdb -url -databasename WSS_Content_Intranet

This will initiate the upgrade process as per the below screen capture.


You will eventually receive a message similar to the below advising that the upgrade was completed albeit with errors in my case. You should review the upgrade log file which is quite extensive and lengthy, and sure enough the errors were all related to missing features etc which I was already aware of.


We can now verify that the upgrade was completed successfully by first navigating back to Central Administration / Application Management / Manage content databases, which now displays the upgraded database under my designated Web Application.


We can also view the upgrade status page which is located within Central Administration / Upgrade and Migration / Check upgrade status. The page will list all previous upgrade attempts and summarise the number of errors and warnings that may have been encountered. In my case, there were a number of features that were not installed in the new SharePoint 2010 farm that the current portal relies on. All of the upgrade logs are located in the following location, providing you with finer detail on the errors and warnings encountered;

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS


By default, your site will retain it’s 2007 theme which Microsoft have done on purpose and you will need to manually change this 2010 if you wish to do so. This is referred to as the “Visual Upgrade”, providing site administrators the ability to switch to the new look and feel at their own leisure. This is a great move by the SharePoint product team as the new interface can be quite overwhelming to begin with. Think about the move from Office 2003-2007 with the introduction of the new ribbon interface. There was a week or two of frustration for most users before eventually getting the hang of it and finding the new interface to be more productive.

The below screen capture is my upgraded SharePoint 2010 portal running in “SharePoint 2007 theme mode”.


To perform the Visual upgrade, navigate to Site Actions / Visual Upgrade.


Here you are provided with 3 options in which I will select “Use the new SharePoint user interface, and don’t ask me again”. After clicking on OK, I am now presented with the same site utilising the default SharePoint 2010 theme.


We have now successfully upgraded one of our SharePoint 2010 content databases housing our main Intranet portal, albeit with some missing web parts and features. So what’s next on the agenda? Upgrading My Sites of course! This will involve attaching and upgrading your Shared Service Provider (SSP) to upgrade your user profile information followed by upgrading the My Sites content database. This process will be left for a future post.

I hope you have found this 2 part series useful and I am interested hear how many of you have attempted a SharePoint 2010 upgrade and your experiences.

Resources from TechNet

Determine Upgrade approach (SharePoint 2010)

Microsoft SharePoint 2010 Products Upgrade Approaches – Diagrams

Upgrading to SharePoint Server 2010

Preparing to upgrade to SharePoint 2010 Products

Attach databases and upgrade to SharePoint Server 2010

Upgrading your Content DB From SharePoint 2007 to SharePoint 2010 – Part 1, The preupgradecheck

There are a lot of SharePointers out there who are excited about the 2010 release and as I have been working my way through the installation and configuration of this updated beast, I have also been providing you with posts along the way sharing my experiences. Today isn’t any different, and in this two part series I will be providing you with a guide to upgrading your SharePoint 2007 content databases to SharePoint 2010. There are already some great resources out there regarding upgrade options and preparation guidance including those from Microsoft on the TechNet Site and others which I will list at the end of this article. The prime focus of part 1 of this 2 part series will be to outline the many tools that are available to you at no cost, assisting and ensuring that your SharePoint farm and SharePoint databases are up to scratch and ready for 2010. The series will proceed as follows;

  1. Upgrading your Content DB to SharePoint 2010 –The preupgradecheck
  2. Upgrading your Content DB to SharePoint 2010 – Using the Database Attach method

First and foremost, Microsoft have provided us with the pre-upgrade command line stsadm parameter switch in SharePoint 2007 Service Pack 2, which has been further updated with the latest October 2009 Cumulative Update (CU),. This will be our primary analysis and reporting tool providing us with invaluable information regarding your SharePoint 2007 farm and actions that may be required to be taken prior to upgrading to SharePoint 2010, so let’s begin our journey here.

Launch a Windows command prompt on your SharePoint Server and type the following stsadm command from the following directory;

%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\bin

stsadm.exe -o preupgradecheck

This will begin the pre-upgrade process checks which will display the relevant steps in your command prompt window.


When the pre-upgrade process completes, you will receive the following “Operation completed successfully” message in which it will then launch your web browser displaying the results in HTML format, titled “SharePoint Products and Technologies Pre-Upgrade Check Report”. These results can also be located under the following location;

%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Logs\


What you will notice is that the report being displayed does a great job in not only notifying you of any issues regarding your SharePoint farm such as missing Site Definition Information or missing Feature Information, but it also provides you with a blueprint of your SharePoint Farm setup. Such useful information which will be required to be taken into consideration when upgrading to SharePoint 2010 includes the following items;

  • Search content sources and start addresses

  • Office Server Search topology

  • Servers in the current farm

  • SharePoint version and list of components running in the farm

  • Supported upgrade types (Inplace Upgrade and Content Database Attach)

  • Site Definition and Feature Information

  • Language pack information

  • Alternate Access Mappings (AAM) that will need to be recreated

  • Customized List views (these will not be upgraded)

  • Customized field types (these will not be upgraded)

  • WSS Search topology

  • List of Content Databases and SQL server location

Joel Oleson does a great job in explaining these items in great detail in his blog post Preparing for Upgrade to 2010 Today – Part 1 Preupgradecheck, however I will outline some of the issues that I personally encountered with my SharePoint 2007 content database.

The majority of your issues will most likely evolve around Missing Site Definition and or missing Feature Information. These missing items are listed at the bottom of each of these respective sections in the pre-upgrade report. My first problem area was a missing Site Definition.


name = Unknown, language = 1033, template id = 75816, count = 5, status = Missing

Notice that the name of this feature is “unknown”, which isn’t of much help, however this is where Google (or your preferred search engine provider) comes into play. The key identifier is the template id which in this case is 75816, and after typing this ID number in my search criteria I was immediately presented with a number of results all pointing to the Help Desk Fab 40 template. Aha! my eyes lit up and I recall back in the day installing some of the Fab 40 templates (I’m sure many did at the time of release). So I downloaded the solution from the Microsoft Download Center and re-installed the template. I then re-ran the preupgrade check and whalla! my missing site definition now has a name against it with a status of “Installed”.


My next problematic area was a plethora of missing features. Now this will all depend on how much history is attached against your current SharePoint farm environment and how many 3rd party solutions and or custom development have been installed or uninstalled over time.


One thing you will learn throughout this process is that the preupgrade check utility does a great job in naming features against GUID’s when they are installed, but fails miserably in displaying names when they are missing. Once again, Google quickly becomes a point of reference and 9 times out of 10, utilising the GUID in your search criteria will yield the results that you are after, and that is the actual name of the missing feature. A few of mine were features from the Codeplex site so I was easily able to identify whether I needed to re-install or remove these rogue items. In most instances, if they are missing, they are missing due to failed uninstalls, so this is where the stsadm becomes your next best friend.

Let’s take a single example where the following GUID was listed as being missing; 758a6fdf-005a-bcaa-0ea0-1d4931979fec. You will need to run the following stsadm –o deactivatefeature command to remove the rogue entry. More information on the this command can be located in the following TechNet article.

STSADM -o deactivatefeature -id 758a6fdf-005a-bcaa-0ea0-1d4931979fec -url -force

In addition to the STSADM command line tool, there are a couple of other tools that really assisted with the process of removing rogue features where the stsadm actually failed. The first tool which is provided by Gilham Consulting , is the WssAnalyzeFeatures tool, which will assist in listing features against their GUID similar to that of the preupgrade report.


The second tool required as part of the removal process is the WssRemoveFeatureFromSite which will remove rogue features installed in your SharePoint farm where the stsadm –o deactivate feature might fail. Eventually you would want the output of the WssAnalyzeFeatures command to display no problems.


So after re-installing or removing any rogue features and site definitions we should be ready to proceed with our SharePoint 2010 upgrade, taking into account that there were no other problematic areas that were outlined in the preupgrade check.

There are several other tools worth mentioning that also assisted with outputting information and configuration details of my farm and assisted with the SharePoint farm cleansing process.

The SharePoint Feature Administration and Clean Up Tool which you can download from the Codeplex site, does a great job in listing Feature Definitions across Site Collections and Sub Webs and cleanly uninstalling them. My favourite feature in this tool is its ability to locate any faulty features and then providing you with the ability to remove them from your entire farm.


Clicking on the Find Faulty Feature in Farm should hopefully return the following “No Faulty Feature was found” message.


SharePoint Manager 2007 (note there is already a SharePoint Manager 2010 available) can also be downloaded from the CodePlex Site and is a great tool for administrators and developers in providing an understanding of any SharePoint farm topology.


My last tool of choice is from Bamboo Solutions, namely the Bamboo SharePoint Analyzer. Similar to that of SharePoint Manager 2007, this utility also does a great job is listing everything you need to know about your SharePoint environment and your entire farm topology. This is also available as a free download and should be installed as part of any SharePoint Farm deployment. These tools will also greatly assist in replicating your environment for your SharePoint 2010 deployment.


Hopefully I have provided you with a comprehensive list of tools and tips to assist you in getting your Content DB’s primed for your SharePoint 2010 upgrade. In the next part of this series I will focus on the actual upgrade itself utilising the Database attach method, so stay tuned!


Upgrading to SharePoint Server 2010 – TechNet

Run the pre-upgrade checker (SharePoint Server 2010) – TechNet

5 Reasons SharePoint 2010 PreUpgradeCheck is better than Prescan – SharePoint Joel

Preparing for Upgrade to 2010 Today – Part 1 Preupgradecheck – SharePoint Joel

Planning for SharePoint 2010 – Upgrade Planning Part 4 – Using preupgradecheck – Chandima.Net

Preparing for Upgrade to SharePoint 2010 with Joel Oleson Quest Software Webcast

Creating your first Web Application & Site Collection in SharePoint 2010

We are at the final article in this series in getting your SharePoint 2010 environment up and running, however the fun doesn’t end here (there will be plenty more posts on 2010 now that our test environment is up and running) . In this post I will be providing you with a step by step guide in creating your first SharePoint Web Application and Site Collection to host your sub webs. If you need to catch up on my previous posts in this series you can access them from the following links;

  1. Installing SharePoint 2010 Beta on a Windows 2008 R2 Server
  2. Configuring SharePoint 2010 Beta Service Applications and User Profile Service Synchronization

Now that you are up to speed, let’s begin by navigating to SharePoint 2010 Central Administration / Application Management. You will notice that the redesigned interface organises and categorises items in an orderly fashion, with a lot of familiarity with SharePoint 2007.


The first step in the process is creating your first Web Application to host our Site Collections.

Under the section Web Applications, click on Manage web applications.

On the new fluent ribbon UI, click on New. (By the way, I think the ribbon UI is a welcome addition to the 2010 interface making it easier for administrators and end users to make decisions and change details within a couple of clicks).


The all so familiar Create New Web Application window appears albeit as a pop up window which does make navigation a lot nicer.


There are a couple of enhancements and improvements worth noting, with the first being the two types of authentication that you are provided with when creating your new web application, being Claims Based Authentication vs. Classic Mode Authentication. In summary, SharePoint 2010 is now “claims aware” making SharePoint a lot easier to work with systems such as Active Directory and providing single sign on for on-premises and cloud based applications across organisations. The following link provides a great overview on Claims Based Authentication and the role it will play within SharePoint 2010.

Proceed and fill out the Create New Web Application Form. As a guide, I have provided sample answers below .

Authentication: Claims Based Authentication

IIS Web Site:

Create a new IIS web site

Name: SharePoint Intranet Portal (Always best practice to create a new IIS website for each new SharePoint Web Application.)

Port: 80

Host Header: Leave Blank or specify a preferred host header. (If you specify a host header, the alternate access mapping will be created for you automatically. Please ensure that you also create the relevant A record in DNS.

Path: Leave default C:\inetpub\wwwroot\wss\VirtualDirectories\80 (This is usually determined by Port number and or Host Header Input)

Security Configuration

Allow Anonymous: No

Use Secure Sockets Layer (SSL): No

Identity Providers

Enable Windows Authentication: Negotiate (Kerberos or NTLM)

Sign in Page URL

Default Sign In Page

Public URL

Keep default Entry against your Default Zone.

Application Pool

Create new Application pool: SharePoint Intranet Portal (I have matched the pool name against my IIS website name for consistency, again it’s best practice to create a new application pool for each SharePoint Web Application that you create.

Database Name and Authentication

Specify your Database Server, Database Name and keep Windows authentication which is recommended.

Failover Server

This is a new feature in SharePoint 2010 providing you with the ability to specify a second SQL server that is participating in database mirroring, allowing you to easily failover if the primary SQL server fails. This is a welcome addition providing a means of high availability.

Service Application Connections:

Edit the following group of connections: default

Note, SharePoint 2010 allows you to connect a web application to all service applications available in a farm or a subset that you define. This can be changed at any time.

Customer Experience Improvement Program

Enable Customer Experience Improvement Program: Yes or No

Click OK to initiate the creation process.



Click OK

Our new Web Application will now be listed along side our SharePoint Central Administration v4 Web Application under Central Administration/ Application Management / Manage web applications


We are now ready to create our first site collection. Navigate to Central Administration / Application Management / Create Site collections.


As you can see, the interface hasn’t changed at all from SharePoint 2007.

Ensure that the newly created Web Application is selected.

Enter a Title and Description. Under Template Selection I will click on the Collaboration Tab and select the trusty Team Site as this will be my starter site hierarchy for my development Intranet Portal.

Enter the Primary and Secondary Site collection administrators and then click OK.

That’s it. Our first site collection is up and running.

This is only the beginning of our journey. In upcoming posts I will delve into the nitty gritty and get my hands dirty discussing the new features of SharePoint 2010.


This concludes our series on getting the basics of SharePoint 2010 up and running and will serve as a base for all future posts on introducing SharePoint 2010.