Microsoft SharePoint 2010 Administration Cookbook

By Peter Serzo
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Upgrading and Configuring SharePoint 2010

About this book

Collaboration and content management are the major business needs of every organization in this increasingly global and connected environment. Microsoft SharePoint is a solution to these needs that offers a software platform that facilitates collaboration and provides content management features for the effective implementation of business processes. With a vast amount of functionality available with SharePoint, it is easy to get confused in carrying out administrative tasks.

Microsoft SharePoint 2010 Administration Cookbook starts off by demonstrating the various upgrading and post-upgrading tasks to be performed in SharePoint 2010. Next come recipes for managing SharePoint service-level applications and for monitoring the SharePoint environment. The book introduces one of the best new tools that should be in your arsenal, PowerShell, and the commands you will need to script your tasks with Powershell.

Collaboration and content management are the most important features of SharePoint and this book contains many recipes that focus on improving them. Enterprise monitoring and reporting are also covered in detail so that you can ensure that your SharePoint implementation is up and running all the time. You will find recipes to manage and customize SharePoint Search.

When you are half way through the book, you will explore more advanced and interesting topics such as customizing and securing the SharePoint environment. You will learn to extend SharePoint to include features similar to social networking sites such as Facebook and Twitter. Lastly, the book covers backup and recovery solutions for SharePoint so that you can ensure that your system is protected from data loss and virus attacks.

Publication date:
January 2011
Publisher
Packt
Pages
288
ISBN
9781849681087

 

Chapter 1. Upgrading and Configuring SharePoint 2010

In this chapter, we will cover:

  • Checking current installation upgradeability

  • Upgrading MOSS 2007 to SharePoint 2010

  • Upgrading with minimal downtime

  • Visual upgrade

  • Creating and associating content databases to a specific web application and site collection

  • Configuring a content database

  • Creating an Alternate Access Mapping (AAM)

  • Patching (compatibility boundaries)

 

Introduction


SharePoint 2010 requires 64-bit architecture on the servers, with a minimum of 8 gigabytes of RAM. The result of this requirement is that there will be installations upgrading their 32-bit architecture and then upgrading/migrating their sites.

Upgrading SharePoint 2010 is optimally a one time job. In reality, this is not always the case as there may be business reasons one web application is upgraded and another is left in MOSS 2007. This could be due to software integration with SharePoint, components that are not ready for SharePoint 2010, or a segment of users that need time before upgrading to SharePoint 2007.

SharePoint 2010 has been architected with the capability to migrate sites methodically. With this in mind, every recipe in this chapter approaches the upgrade from the viewpoint of iterative tasks after an upgrade. This means that a majority of the tasks can be performed several times against different web applications.

Every recipe here (except the first one) should be performed and understood by the administrator of the SharePoint 2010 farm. There are many new items in SharePoint 2010 that will become common tasks; some more than others depending on the size of your environment.

One of the best new tools that should be in your arsenal is PowerShell. The recipes in this section outline the commands you will need. However, after reviewing and trying these recipes, look at scripting your tasks with PowerShell. This will enable you to become a more effective and proactive IT Professional.

 

Checking current installation upgradeability


In order to upgrade to SharePoint 2010 from your current Windows SharePoint Services 3.0 (WSS) or Microsoft Office SharePoint Server 2007 (MOSS) implementation, you need to plan your new infrastructure carefully. When thinking about planning your new architecture, take into account the logical design and the physical design of the new SharePoint 2010 installation.

Issues need to be identified, resolved, and requirements need to be met. Issues can range from addressing 32-bit architecture to custom site definitions. These items need to be resolved before being able to update to SharePoint 2010.

Begin your planning by identifying and documenting your current infrastructure. Review the hardware, WSS/MOSS configurations, and potential customizations.

A typical farm installation will have multiple servers with diverse roles: web front ends, applications servers, database servers, among others. Extrapolating from there, an installation can have multiple content databases, web applications, site collections, Shared Service Providers, to name a few of the components.

In order to manage your infrastructure and plan for the SharePoint 2010 upgrade, Microsoft has provided organizations with a tool called preupgradecheck. This tool is shipped as part of MOSS Service Pack 2. As long as this service pack is applied, the tool is available.

This tool documents the current installation, checks your MOSS/WSS installation against SharePoint 2010 requirements, and applies best practice rules identifying areas of concern.

Getting ready

In order to execute this tool, the WSS 3.0/MOSS 2007 installation must have the Office 2007 Service Pack 2 installed. This tool is native to the SharePoint installation and an extension of the stsadm command.

You must be a member of the Farm Administrators SharePoint Group, with administrator permissions on the server.

How to do it...

  1. 1. Click Start and Run... on the web front-end server.

  2. 2. Type in cmd and press Enter.

  3. 3. Navigate to c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN. This can be achieved with the help of the CD (Change Directory) command.

  4. 4. Type the following in the command prompt:

    stsadm -o preupgradecheck
    

    You should see a report that looks similar to the following screenshot:

How it works...

The pre-upgrade application leverages rules that can be found in the following two files: OssPreUpgradeCheck.xml and WssPreUpgradeCheck.xml.

These files were created in 12\CONFIG\PreUpgradeCheck when the Microsoft Office SharePoint 2007 Service Pack 2 was installed. Refer to the next screenshot:

In the command prompt window shown in step 4 of the previous section, a summary of the operations is shown. The objects marked with the colors yellow and red must be addressed. The farm will not get upgraded until objects in red color are addressed.

As you can see from the preceding screenshot, an HTML file is created in the 12\Logs folder, which contains the information the pre-upgrade application produced. The first part of the report produces important information as shown in the following screenshot:

Other information collected includes the SharePoint version, supported upgrade types, along with information on your servers, including roles, amount of data, number of web applications, site collections, and number of servers.

The rest of the HTML report lists the checks that were done and any issues that were found. If an issue is found, the report will include a description on fixing the issue or a link to a Microsoft Knowledge Base article that corresponds to the issue.

There's more...

The pre-upgrade application performs read-only operations against the database. No changes are made to your SharePoint installation. This means you can run the application multiple times and there is no adverse effect on your SharePoint installation. As you resolve issues, it is advisable that you rerun the pre-upgrade application.

More info

Using the preupgradecheck rule files parameter, you can create your own custom rules to identify items that are specific to your installation.

 

Upgrading MOSS 2007 to SharePoint 2010


There are two approaches to upgrading your WSS 3.0/MOSS 2007 farm to SharePoint 2010. They are:

  • In-place upgrade: This is where you will upgrade your current installation on the hardware it currently resides on.

  • Database attach upgrade: To perform this type of upgrade, you must have a new SharePoint 2010 farm up and running. You will take the content databases from the MOSS 2007 farm, attach them to the new farm, and upgrade them.

The latter method of upgrading your MOSS 2007 farm is the preferred method and the one that this recipe outlines. It has many advantages over the in-place upgrade method. Some of these advantages are:

  • It leverages backup and restore through SQL Server Management Studio. SharePoint IT Administrators should already be familiar and comfortable using these tools.

  • The addcontentdb stsadm command should already be familiar to many SharePoint Administrators. It creates a new content database or as in the case outlined in this recipe, adds a database that needs to be upgraded. Attaching a database reduces the downtime of your SharePoint installation. This reduces the pain your customers will feel and enhances the success and acceptance of your upgrade.

  • You can perform the upgrade in an iterative fashion, or even in parallel. The in-place upgrade is a one-way, don't-look-back upgrade.

  • You can have granular control over the steps of your upgrade. You control what gets upgraded, when, and how. This allows for flexibility, which is the key to a successful upgrade.

SharePoint 2010 has a completely different Services architecture as compared to MOSS 2007 Shared Services. This new architecture must be planned carefully and implemented according to the organization's needs. By doing a database attach, your farm will correctly consume the new architecture as architected.

Getting ready

The preupgradecheck should already have been run on your current installation and any issues should have been resolved. Be sure to identify the content database that is being upgraded.

A new SharePoint Server 2010 farm must be set up and configured using a web application.

You must have access to SQL Management Studio with the ability to create databases.

How to do it...

  1. 1. Log in to the WSS 3.0/MOSS 2007 database server.

  2. 2. Open Microsoft SQL Server Management Studio and connect to the database server hosting the SharePoint content database.

  3. 3. In the Object Explorer, click on the folder named Databases.

  4. 4. Find the identified content database. By default, this is called wss_content_{guid}. The {guid} is a unique number generated when the database is created but it may not be present.

  5. 5. Right-click on the content database and select Tasks | Back Up. A screen similar to the following screenshot appears:

  6. 6. Ensure Backup type is set to Full. Also the Name and Destination field should be populated correctly.

  7. 7. Click OK. The file should be backed up successfully after a period of time.

  8. 8. Ensure the backup is accessible to the SharePoint 2010 database server. If the SQL Server is physically not on the same server as SharePoint, copy the backup to the destination server where it is accessible.

  9. 9. Through SQL Server Management Studio, connect to the SQL Server instance where the SharePoint 2010 databases are installed.

  10. 10. In the Object Explorer window, right-click Databases. Navigate and click on Restore Database. The following screenshot appears and must be filled with appropriate values:

    • Fill in the To Database textbox.

    • Choose the backup file in the From Device option. Check the Restore option under the Select the backup sets to restore option. Click OK.

  11. 11. After the content database is successfully restored, it must be added to the SharePoint 2010 Web Application using addcontentdb, which is an argument to the stsadm command.

  12. 12. Open a command window. Make sure to run it as administrator when you open it. If you right-click on the command prompt, there is an option provided to Run as Administrator.

  13. 13. Type in the following command:

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

    Here is the screenshot I get when I run this command:

  14. 14. When the operation finishes successfully, navigate to the SharePoint 2010 Central Administration site.

  15. 15. Click the Application Management option. Under Site Collections, click the Change Site Collection Administrators option.

  16. 16. Ensure that there is a valid site collection administrator.

Navigate to the new site.

How it works...

Steps 1 through 7 showed how to take a backup of the content database that was being upgraded. Step 8 is copying the physical file that is created from the backup to the new server. Using file storage and rights, the file may not have to be copied. The important part of this process is that the new SQL instance for SharePoint 2010 has access to this file.

Steps 9 through 11 performed a restore to put the backup file into the new SQL database instance.

Steps 12 through 14 ran the command that performs the physical upgrade of the file. An upgrade of the content database is nothing more than schema changes, table changes, and stored procedure changes. It also adds the content database to the specified web application.

In steps 15 and 16, we, as Farm Administrators, ensured that the Site Collection Administrator from MOSS 2007 is still a valid account in the now upgraded SharePoint 2010 farm.

The database attach method is the least intrusive upgrade when it comes to your SharePoint Farms. For SharePoint 2010, upgrading with addcontentdb can be done only through the stsadm command; its functionality is not found in the Central Administration User Interface.

Finally, there is a parameter called preserveolduserexperience in the addcontentdb command. This is an optional parameter and set to true by default. When the site is upgraded to SharePoint 2010, it will contain the same look as it did in MOSS 2007. If you want the site to use the new SharePoint 2010 look, then ensure that you use this parameter and set it to false.

Depending on the farm architecture, you may have more than one content database per web application. In a case such as this, it is more efficient to upgrade both simultaneously. This is accomplished by doing multiple attaches in parallel. Instead of using the addcontentdb command, use PowerShell and the Mount-SPContentDatabase command.

There's more...

Before adding the content database to the web application, there is an additional tool that has been added via SharePoint's PowerShell commands. This tool confirms that the new web application has all the necessary components to support the upgrade. It functions by comparing the database you are about to attach/upgrade against the web application you wish to attach.

The command is Test-SPContentDatabase.

  1. 1. Click Start | All Programs. Select Microsoft SharePoint 2010 Products and then SharePoint 2010 Management Shell. Refer to the following screenshot:

  2. 2. At the command prompt, type in the following command:

    test-spcontentdatabase -name <database name> webapplication <url>
    

    This command will produce a report in the window that can be piped to a file through PowerShell. The report will identify issues such as missing site definitions, features, or assemblies. The benefit of this command is that it works read-only against your web application so that it can be run iteratively. As you resolve issues, you can rerun the command.

    Keep this command as part of the IT Professional toolkit. It is very useful to scan and identify issues against WSS 3.0/MOSS 2007 and SharePoint 2010 databases.

More info—further upgrade info

After the upgrade and migration is complete, you will see a successful or unsuccessful indicator in the command prompt. However, the best place to view the status of your upgrade is in Central Administration. This is especially true if there are parallel upgrades happening.

  1. 1. Open the SharePoint 2010 Central Administration site.

  2. 2. Click Upgrade and Migration.

  3. 3. Click Check Upgrade Status. There will be a screenshot similar to the following:

As can be seen in the preceding screenshot, there were two upgrades that took place. One failed and one succeeded. One of the items on the report is the location of the log file, which shows detailed information about the failures.

There is also a custom error log file created that is necessary to look at when there are errors in the upgrade.

Also, there is a category named Remedy. In here is located a hyperlink to a possible resolution for the issues found.

More info—errors when upgrading

There are times when the upgrade fails. If that occurs, you may see a screen similar to the following:

When this occurs, you are directed to the log file in order to determine what the issue is and how to go about resolving it.

 

Upgrading with minimal downtime


The SharePoint farm administrator must minimize the impact of upgrading a MOSS 2007 farm to SharePoint 2010. How long this process takes is dependent on the size of the installation.

MOSS 2007 SP2 installed a new capability that allows an administrator to set the content database to read-only. The result of this is that users can only read from the database and cannot perform any write operation.

The advantage of this when doing an upgrade is that users can continue using the MOSS 2007 farm while the data is being upgraded on the SharePoint 2010 farm.

This recipe shows how to set a database as read-only.

Getting ready

WSS 3.0/MOSS 2007 installation must have the Office 2007 Service Pack 2 installed.

How to do it...

  1. 1. Open Microsoft SQL Server Management Studio.

  2. 2. Log in to the WSS 3.0/MOSS 2007 database server.

  3. 3. In the Object Explorer, click the folder named Databases.

  4. 4. Find the correct content database. By default, this is called wss_content_{guid}.

  5. 5. Right-click on correct content database, and select Properties.

  6. 6. Under the Options selection, scroll down until the main window with the State section is visible. Refer to the next screenshot:

  7. 7. Change the Database Read-Only property to True from the existing value of False.

  8. 8. Click OK.

How it works...

Once the content database is read-only, no changes can be saved to the database. The WSS 3.0/MOSS 2007 site is still available to query information to the entire user population. The database can now be backed up with confidence in the integrity of the data state.

The database can be copied to the new SharePoint 2010 SQL Server and upgraded as shown in the previous recipe. When the new environment is ready to go, perform an Alternate Access Mapping (AAM) redirect to route users to the new environment and detach the database in SharePoint 2007.

This is referred to in Microsoft Technet as a Hybrid upgrade.

See also

  • Upgrading MOSS 2007 to SharePoint 2010.

 

Visual upgrade


When upgrading your site to SharePoint 2010 from MOSS 2007, there is a significant difference in the user interface (UI). SharePoint 2010 has a new master page that includes new and changed components that must be taken into account when designing the UI. They are:

  • The ribbon

  • Social features such as being able to tag

  • Disappearance of My Links

  • Changes to core.css

These factors may present a challenge when porting the site's look and feel to SharePoint 2010. The business may not have the time and bandwidth to accommodate the changes.

As seen in the upgrade from recipe 2, there is an option to preserve the MOSS 2007 UI in SharePoint 2010.

Then, as the organization is ready for the new look and feel, it can be applied at a site level or at a site collection level. This can be done as a preview and then rolled back. Or the SharePoint 2010 UI can be committed permanently to your site.

Getting ready

The person doing this must be a site collection administrator or site owner, and the upgrade must have been applied with the MOSS 2007 look preserved.

How to do it...

  1. 1. Navigate to the site where the SharePoint 2010 UI will be applied.

  2. 2. Click Site Actions and then Visual Upgrade as seen in the following screenshot:

  3. 3. A screen is presented with three options:

    • Display the Previous SharePoint user interface

    • Preview the new SharePoint user interface (it can be rolled back if there is a problem)

    • Use the new SharePoint user interface (this is permanent)

    Choose the Preview... option.

  4. 4. The site is now presented with the new SharePoint 2010 UI.

  5. 5. To roll the site back or commit the site to the new UI, click Site actions | Visual Upgrade. Choose either of the options: Display the Previous SharePoint user interface or Use the new SharePoint user interface.

How it works...

SharePoint 2010 ships with the MOSS 2007 master pages, application pages, and CSS files. It provides the facility to convert those deprecated layouts to the new UI through the visual upgrade.

This makes sure organizations do not have to make the visual leap to SharePoint 2010 all at one time. It can be phased in and tested properly, ensuring all the UI assets and UI changes function correctly.

There's more...

The visual upgrade can also be done at the site collection level through the administration page. This will allow the site collection administrator to apply the SharePoint 2010 UI to all sites under the Site Collection or hide the visual upgrade from the site owners.

The caveat to doing an upgrade to all sites is there is no preview. Any issues that result in the new UI must be dealt with immediately. There is no changing back to the MOSS 2007 pages.

The steps to achieve this are:

  1. 1. Click Site Actions, Site Settings.

  2. 2. Under the Site Collection Administration, there is an option for visual upgrade. The screenshot is the screen we get:

    Choose either of the following options: Hide Visual Upgrade or Upgrade All Sites.

More info—changing UI version with PowerShell

There are times when a visual upgrade must be rolled back after it has been committed. This may be due to issues with the ribbon or CSS styling. In any event, the upgrade has been made and now the company wants to roll it back.

Using PowerShell, it is possible to change the look back to MOSS 2007. Use the following snippet to change the look back for a single site:

$web = Get-SPWeb http://server/site
$web.UIVersion = 3
$web.UIVersionConfigurationEnabled = $true
$web.Update()

 

Creating and associating content databases to a specific web application and site collection


A web application is not limited to using a single content database. SharePoint allows you to associate many content databases to a web application. One of the reasons to do this could be based on the size of the content database. If the content database is larger than 200 gigabytes, it makes more sense to distribute this content across two content databases.

A different consideration is factoring the type of data that is being housed in the content database. If there is a marketing site that contains media files such as photos and video, it may be desirable to create a content database just for this site collection data. Another example is housing all legal data into one content database/site collection for a litigation department.

Finally, a major benefit of doing this is disaster recovery. Knowing where your data is, and how it is structured, will allow you to implement a disaster recovery strategy that is efficient, effective, and flexible.

The data that is created is not the same, that is, we have various kinds of data. Data has different properties and may even have different backup and restore service level agreements. However, multiple content databases may be connected to one web application.

This recipe will show how to create multiple content databases to one web application and apply the appropriate site collection to the corresponding content database.

Getting ready

Ensure that you are a member of the Farm Administrators SharePoint group on the computer accessing the Central Administration site. You must have the correct permissions to create a database (typically dbcreator and sysadmin).

How to do it...

  1. 1. Open the Central Administration screen. Under Application Management in the Databases section, click Manage Content Databases.

  2. 2. At the top of the resultant page is the Add a content database option. Click the option and the following screenshot will be displayed:

  3. 3. The database name is given a GUID suffix by default. Change the database name to be relevant but use a naming convention. In the case of the preceding screen, I will change database name to WSS_Content_Marketing. Keep the rest of the defaults and click OK.

    The content database will be created and listed under Manage Content Databases.

  4. 4. To ensure that the site collection gets added to the proper content database, ensure that you are still under Manage Content Databases.

  5. 5. Click on the content database(s) you don't want the site collection to get added to.

  6. 6. Under the Database Information settings, set the Database status to Offline. Click OK. Refer to the next screenshot:

  7. 7. Navigate to Application Management, then Site Collections. Under this section, click Create site collections.

  8. 8. Fill the information for Title, URL, select a template, and include a primary site collection administrator. Click OK.

  9. 9. The site collection should be created and added to the appropriate content database. To check this, navigate back to the Manage Content Databases screen. See the example shown in the following screenshot. WSS_content_7777 is Stopped (offline) and the new site has been added to WSS_Content_Marketing.

  10. 10. Reverse the action from step 6 and put the content database back in Ready state.

How it works...

The first half of the procedure is self explanatory. We are creating a content database under the appropriate web application. The second half of the procedure takes the database offline. This action will ensure that the next site collection cannot be added to that database.

The action of assigning a site collection to a content database is very similar to network load balancing. The site collections are assigned quite evenly across the content databases while they are online.

There's more...

When doing a SharePoint 2010 upgrade of multiple content databases, ensure that the first content database that you add contains the root site for the associated web application. The rest of the content databases for the web application can be added in any order afterwards.

More info

There will be times when you do not want to add any more site collections to a content database. In order to accomplish this, perform the following steps:

  1. 1. In Central Administration, under the Databases section, click on the Manage Content Databases option.

  2. 2. Click on the database that you wish to no longer add site collections to.

  3. 3. Change the Maximum number of site collections settings (under Database Capacity Settings) to be equal to the current number of site collections.

  4. 4. Change the Number of sites before a warning event is generated setting to be one less that the current number of site collections.

More info

You have seen how to do this recipe through the user interface. There is a way to do the same procedure through scripting. PowerShell is the new way of scripting, but the stsadm command set is still available. Here are both methods:

  • Using stsadm command:

    stsadm -o createsiteinnewdb -url <url> -owneremail <email> -ownerlogin <domain/name> -sitetemplate <site template> -title <title> -databaserver <serverdb> -databasename <dbname>
    
  • Using PowerShell, we need to run the following two commands:

    New-SPContentDatabase
    New-SPSite
    
 

Configuring a content database


In SharePoint 2010, content databases are the heart of an organization's data. This is where all the site content information, such as documents, list data, and web part properties, is stored. By default, the content database is set up with parameters that may not be optimal to your organization.

Thankfully, these parameters can be changed and tweaked to fit your installation. It is important to note what can be changed and the ramifications of the change. In this recipe, you will be exposed to the parameters and the possible changes that can be made.

Getting ready

Ensure that you are a member of the Farm Administrators SharePoint group on the computer accessing the Central Administration site.

How to do it...

  1. 1. Open Central Administration. Under the Databases section, click Manage Content Databases. A listing of content databases will be shown in blue.

  2. 2. Click on the content database whose parameter you wish to change. The screen with the parameters to be changed will appear. The items that can be changed are:

    • Database Information

    • Failover Server

    • Database Capacity Settings

    • Search Server

    • Remove Content Database

    • Preferred Server for Timer Jobs

  3. 3. Make the appropriate changes and click OK.

How it works...

  • Database Information: This section gives information on the status of the database. The drop-down list allows the administrator to change the database state. When a content database is taken offline, it is not available and sites cannot be created within it. Refer to the next screenshot:

  • Failover Server: This is a new option within SharePoint 2010. Entering a server name into this box will not set up the failover server. It tells SharePoint what failover database server to utilize in the event one is needed. Refer to the following screenshot:

  • Database Capacity Settings: This section controls the number of site collections that will be created within the content database. There is a warning level, which must be at least one less than the maximum number of sites that can be created. Refer to the following screenshot:

  • Search Server: The content database will utilize a search server. Depending on your environment, there may be more than one server in this drop down.

  • Remove Content Database: This section allows the administrator to disassociate the content database from the web application. It does not delete the content database from the SQL Server. The data is still available and untouched. Any content in the site collections, contained in the content database, will no longer be accessible. Refer to the next screenshot:

  • Preferred Server for Timer Jobs: In SharePoint 2010, we can dedicate a server for timer jobs. This server would be indicated here for the content database. Refer to the following screenshot:

 

Creating an Alternate Access Mapping (AAM)


SharePoint's repository is the content database that resides in the SQL server. These databases house all the data for an organization. Organizations may require that users outside the company have access to a subset of this data. For example, vendors may wish to see if their invoices have been paid.

Another example at a large enterprise is hourly workers may see a different subset of data than salary workers. The data all resides in the same content database.

Appropriately architecting the taxonomy and authentication lead into providing two different URLs. The end user will put in the appropriate URL and be directed to the trimmed content associated with that URL.

This is the point of AAMs. This recipe shows how to set up an AAM and the components involved.

Getting ready

Ensure that you are a member of the Farm Administrators SharePoint group on the computer accessing the Central Administration site.

There should also be an existing web application.

How to do it...

  1. 1. Open the Central Administration screen and click System Settings.

  2. 2. Under the Farm Management section, select the Configure alternate access mappings option.

  3. 3. A list of the current AAMs, associated with the web application, will be presented. This will be shown in the upper right-hand portion of the screen.

  4. 4. Click Add Internal URLs.

  5. 5. Fill in the data in the screen that appears. In the following screenshot, we have entered a URL as an example:

  6. 6. Click Save. The updated listing of AAMs will be visible.

  7. 7. Set up DNS to correctly reference the URL that was just entered.

How it works...

When the URL is entered by a user, IIS takes the page request and passes it to SharePoint. It is SharePoint's job to fulfill this request. SharePoint checks the AAM to make a decision on which web application to map the request.

There's more...

A point of confusion about AAMs is that they can be used for redirecting sites, with a completely new URL, to a custom port. For example, consider the following URL: http://spmysite:2222.

This URL cannot be redirected to a URL such as http://mysite.

If a SharePoint site is created on a port other than port 80(HTTP) or port 443(HTTPS), the port number must be supplied. AAMs deal only with the base URL for a web application.

More info

Host headers allow IIS to use a single port for multiple sites on the same machine. The result of this is that organizations do not need to use custom ports. That is why in this book, we have asked to use port 80.

See also

  • Extending a web application

 

Patching (compatibility boundaries)


SharePoint 2010 brings a new story when it comes to applying updates. Typically when applying a service patch, there are two components that get updated: the web front end (WFE) and the database(s). When applying patches with WSS 3.0/MOSS 2007, an administrator had to start the process on one WFE, get it to a certain point, then start the patching on another server, and when the process got to a certain point, finish the patching process.

With SharePoint 2010, there is a new concept known as Compatibility Boundaries as it applies to patching. This will allow your WFEs to be at a different patch level than your database(s). The administrator can upgrade multiple SharePoint servers at the same time. The configuration wizard (PSConfigUI) handles this process itself without any manual intervention.

If you have large content databases, it can take some time to apply patches. This new approach means you can now patch the files on your SharePoint servers, but delay the updates to the databases until a more appropriate time. This is useful to quickly protect your environment against any newly discovered security vulnerabilities or resolve any non-database bugs.

In addition, Central Administration has several components where your patching level can be monitored. This recipe shows you the components within Central Administration where you should be checking for database schema versions, patch levels, and general monitoring of the patching process.

Getting ready

Ensure that you are a member of the Farm Administrators SharePoint group on the computer accessing the Central Administration site.

How to do it...

  1. 1. Open the Central Administration screen and click Upgrade and Migration.

  2. 2. Click on Check product and patch installation status. A report is pulled up showing all the product components from the farm.

  3. 3. There is a drop-down list at the top that allows you to select whether to look at the whole farm or only the components on a particular server. A part of the report looks like the following screenshot:

  4. 4. Navigate back to Upgrade and Migration and select Review database status. A report is displayed, detailing all the databases for the Farm and their status.

  5. 5. Navigate to Application management | Databases | Manage Content Databases.

  6. 6. Click on a content database. The second section is called Database Versioning and Upgrade. It details the database schema versions and looks as shown in the next screenshot:

How it works...

The recipe shows three components of the patching story. Together, these components provide a comprehensive view to the administrator of the SharePoint Farm. Utilizing this information, the administrator can make informed decisions as issues are brought up, and can decide if a new patch must be applied.

The three components are:

  • Patch Status: This shows the patch level of the servers. If there is something missing or required, it will be flagged with a hyperlink to the patch that is needed.

  • Database Status: This is a listing of all the databases in the farm including SQL instance. With SharePoint 2010, there are many databases and they can be run in a compatibility range. Under status, there will be a message letting the administrator know what is required or what is happening.

  • Database Schema Versions: This shows the current schema version and the maximum schema version that the database can be updated to.

There's more...

SharePoint 2010 monitors the health of your farm using a set of rules that are programmed against best practices. An administrator can review these rules and run them on demand or change their schedule. When a rule is broken, the issue is flagged and a red bar with a hyperlink to view the issues will appear on the Central Administration home page.

These are found under Central Administration, under a section called Monitoring. In that section is a Review rule definitions hyperlink. The rules for patch management can be found under the section Configuration. Refer to the following screenshot:

More info

PowerShell is a powerful enabler for the SharePoint Administrator. There are three commands that are applicable to this process.

  • To produce a listing of all the patches on the server:

    Get-hotfix
    
  • Return a listing of content databases and their GUIDs:

    Get-spcontentdatabase
    
  • To upgrade the database:

    Upgrade-spcontentdatabase -id <GUID>
    

About the Author

  • Peter Serzo

    Peter Serzo is an English major from Kent State who started his technical career with EDS out of college. 20 years later, all as a consultant, he is a national speaker regarding to SharePoint having worked at organizations of all sizes. His next challenge is to bring SharePoint to children and teach them. He has been working with SharePoint since 2003 in companies such as Microsoft, Ford, ADP, and many others throughout the United States. He is a Senior SharePoint Architect for High Monkey Consulting. The name refers to an old Jamaican proverb that means the higher up you go, the more responsible you must be; High Monkey takes pride in its accountability and excellence of work in regards to its clients' needs.

    Browse publications by this author
Book Title
Access this book and the full library for FREE
Access now