SP2010: Connection forcibly closed
8 February, 2012
While restoring a site collection I got an error message resulting in a restore failure. Investing the logs I came across the following message:
provider: TCP Provider, error: 0 – An existing connection was forcibly closed by the remote host.
Searching on the error message I came across this msdn article which lists following possible causes for the above error message:
- Client is connecting with an unsupported version of the SQL Server Native Client.
- Faulty network hardware is dropping portions of the TCP traffic.
- The SynAttackProtect setting may be dropping connections.
As soon a I read the article I knew there could only be one possible cause for the connection problem since:
-
all my labo servers are virtualized and the underlying hardware is running just fine
-
the SynAttackProtect setting is only applicable for Windows 2003 SP1 and above servers, but deprecated for the Windows 2008 en 2008 R2 family
which left me with the only other option: the SQL Server Native client version.
[REMARK: for those who don’t know what the SQL Server Native client is: it’s a set of ODBC and OLE DB drivers that can be installed on a client machine to support native SQL Server connectivity; it’s also one of the components that is installed by the SharePoint prerequisites installer]
The SQL Server Native client version can be verified by querying the registry, this is the result on my client machine:
10.0.1600.22, the version I expected since it corresponds to the SQL Server 2008 R2 October 2011 feature pack; in line with the latest SQL Server cumulative update I installed.
Then I checked the version on my server:
Strange, because the last cumulative update I installed on SQL Server dated from October 2011 … and then I remembered: yes, I installed the October 2011 cumulative update but for SQL Server Service Pack 1; since I installed the service pack at the same time.
[NOTE: for SQL Server Microsoft maintains update tracks for each supported install base; which means you have separate updates available for installations without service packs and for each combination of released service packs]
At this point I thought the issue was solved: just download the sqlncli package from the October SQL Server feature pack site and I’d be in the clear.
Well, not exactly … when you go to feature pack site the version stated is 10.50.2500.0, but the version installed on my server is 10.51.2789 so where do I get my hands on that?
Fortunately that’s pretty easy: extract it from the October cumulative update package for SQL Server Service Pack 1 and install it on your server, problem solved!
All in all this was an easy fix, it probably took me 10 times longer to write this post, but I do feel like ranting a bit:
Why on earth does a company like Microsoft release two accompanying products on the same day with the same name but with different build numbers? What makes this even more annoying is that there are known connectivity issues with differences in client versions, as I personally experienced.
And why is there no mention anywhere that you should update clients connecting to the server to the same version as well? Preferably with a mention of the client version required.
From a company like Microsoft I definitely expect better!
Restore-SPSite fails after site deletion
8 February, 2012
Yesterday our SharePoint admin ran into issue while trying to move a site to a new location within the same web application.
The procedure followed is pretty straight forward: backup the site, delete the existing site and perform a restore to the new location, but when he tried to restore the site using the Restore-SPSite cmdlet he got following error (reproduced on my lab environment):
Restore-SPSite : The operation that you are attempting to perform cannot be com
pleted successfully. No content databases in the web application were availabl
e to store your site collection. The existing content databases may have reached the maximum number of site collections, or be set to read-only, or be offline, or may already contain a copy of this site collection. Create another content database for the Web application and then try the operation again.
At line:1 char:15
+ Restore-SPSite <<<< -Identity http://intranet.xtrain.com -Path C:\Intranet.b
ak
+ CategoryInfo : InvalidData: (Microsoft.Share…dletRestoreSite:
SPCmdletRestoreSite) [Restore-SPSite], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRestoreS
ite
If you’ve ever worked with SharePoint 2003 or 2007 the highlighted line above might jog your memory: it’s those infamous orphaned objects again.
In SharePoint 2003 and 2007 you’re only choice for fixing the issue was to use the stsadm –databaserepair command.
In SharePoint 2010 the command is still available but we have few more options:
Using PowerShell:
$db = Get-SPContentDatabase "Content_Db_Name" #true to repair the database, $false to check for orphaned objects $db.Repair($true) $db.Update()
(above example found here)
Using Central Administration:
The new Health Checker includes a rule that checks for orphaned items but by default it is scheduled to run only once a month.
To start the rule manually:
-
Open Central Administration
-
Select the Monitoring category
-
Select Review Health Rules in the Health Analyzersection
-
Browse to the Content databases contain orphaned itemsrule in the Availability category of the Configuration section
-
Click the rule to open the rule definition properties
-
Click the Run Now button and close the properties page
Verify and repair orphaned items:
-
Go back to the Health Analyzer section in the Monitoring category
-
Select Review problems and solutions
-
If the rule detected orphaned items it will show up in the Availability category
-
Click the rule to open the Review Problems and Solutions page for the rule
-
Click Repair Automatically
-
Now the timer job should kick in to repair the database
-
After a couple of minutes click Reanalyze Now
-
Now the rule should have disappeared, if not, the timer job probably hasn’t finished yet. Try again after a couple more minutes
After all orphaned objects have been cleaned, the site can be restored as normal.
PowerShell Fun: Creating a Simple UI
18 December, 2010
Yesterday I was strolling around the net looking for new ideas for our Upgrading and Migrating SharePoint 2007 to SharePoint 2010 course when I stumbled on this post about the PowerShell Pack that was released as part of the Windows 7 Resource Kit.
Apparently it has been around for over a year and I somehow managed to miss it but the PowerShell Pack requires PowerShell v2 and since v2 stayed in beta for ages –remind you of Gmail, anyone?– I stopped following the progress and got back to v1 scripting, since that was the version we had available on our production systems.
What is the PowerShell Pack?
The PowerShell Pack is a set of PowerShell V2 scripts that were written over the years by some of the PowerShell team members and the Scripting Guys, now collected in a set of modules that focus on handling specific tasks like scheduling, managing users and computers, etc. Hit the link above for a complete overview.
For most of the tasks included in the modules you can find a number of solutions spread around the net but one module deserves a closer look, and that is the WPK module: a collection of GUI components that allow you to create rich user interfaces for PowerShell scripts.
Test-driving the WPK
The home page for the PowerShell Pack on codeplex contains an introductory video for the WPK but the examples are pretty basic, and since no amount of demos or documentation can replace hands-on experience I decided to create a little tool to see how difficult it is to create a slightly more complex application.
The goals I set out to test are:
-
Creating a more complex layout than a label with some text and a button
-
Binding to data coming from an external data source – as in “not coming from an existing PowerShell command like Get-Service”
-
Passing data between controls in the UI
-
Subscribing to events
The demo-“project” I created is a simple SQL Server browser. Here’s a screenshot when the script is first launched:
(Never mind the hideous color scheme and ugly gridlines, it’s just to highlight the different components used and how they relate to each other)
A quick overview of the features
Clicking the Connect button connects to a SQL Server of choice that can be typed in the textbox (default is a local SQL Express instance):
Once the connection with SQL Server is established the combo box is populated with the databases found on the server:
Clicking the Get Properties button will collect a few commonly used properties from the selected database in the combo-box and populates the corresponding textboxes with the values retrieved:
The Code
The code sample requires PowerShell v2 and uses sql-smo to connect to SQL Server so if you want to test this, you will either need to
- run the script on a server that has SQL Server installed
or
- download and install a copy of the SQL Native client from the SQL Server feature pack website for your version of SQL Server: 2005 or 2008
I only tested the sample with SQL Server 2008 so no guarantees that it will work on 2005.
<#
Name: WPK-SimpleSQLServerBrower
Purpose: a small demo application to test the WPK functionality
Author: YSTEX
#>
function New-SQLConnection {
param($srvName)
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO') | Out-Null
return $script:srv = New-Object('Microsoft.SqlServer.Management.Smo.Server')$srvName
}
New-Window -Name Window1 -Title "Simple SQL Server Browser" -Height 260 -Width 500 -Content {
New-Grid -Columns 2 -ShowGridLines -Rows 8 -Background yellow -name Grid1 -Children {
New-TextBox -Row 0 -Column 0 -Name serverName -Height 50 -Text ".\SQLExpress";
New-ComboBox -Row 1 -Column 0 -Name databaseList -IsReadOnly -SelectedIndex 0 -Background lime -VerticalContentAlignment Center
New-Label -Row 3 -Column 0 -Name databaseName -HorizontalContentAlignment Right -VerticalContentAlignment Center -Background silver -Content "Database Name: " -Foreground white -FontSize 12 -FontWeight Bold
New-Label -Row 4 -Column 0 -Name databaseOwner -HorizontalContentAlignment Right -VerticalContentAlignment Center -Background silver -Content "Database Owner: " -Foreground white -FontSize 12 -FontWeight Bold
New-Label -Row 5 -Column 0 -Name databaseSize -HorizontalContentAlignment Right -VerticalContentAlignment Center -Background silver -Content "Database Size: " -Foreground white -FontSize 12 -FontWeight Bold
New-Label -Row 6 -Column 0 -Name databaseLogFile -HorizontalContentAlignment Right -VerticalContentAlignment Center -Background silver -Content "LogFile Name: " -Foreground white -FontSize 12 -FontWeight Bold
New-Label -Row 7 -Column 0 -Name databaseLogFileSize -HorizontalContentAlignment Right -VerticalContentAlignment Center -Background silver -Content "LogFile Size: " -Foreground white -FontSize 12 -FontWeight Bold
New-Button -Row 0 -Column 1 -Content Connect -Name serverConnect -On_Click {
$srvName = $window | Get-ChildControl serverName
$srv = New-SQLConnection $srvName.Text
$srv.ConnectionContext.LoginSecure = $true
$dbsList = $window | Get-ChildControl databaseList
$dbsList.ItemsSource = $srv.get_Databases() | %{$_.Name}
}
New-Button -Row 1 -Column 1 -Content "Get Properties" -Name databaseProperties -On_Click {
$dbName = $window | Get-ChildControl dbName
$dbOwner = $window | Get-ChildControl dbOwner
$dbSize = $window | Get-ChildControl dbSize
$dbLogFile = $window | Get-ChildControl dbLogFile
$dbLogFileSize = $window | Get-ChildControl dbLogFileSize
$selectedDb = $window | Get-ChildControl databaseList
$dbName.Text = [string]$srv.Databases[$selectedDb.SelectedValue].Name
$dbOwner.Text = [string]$srv.Databases[$selectedDb.SelectedValue].Owner
$dbSize.Text = [string]$srv.Databases[$selectedDb.SelectedValue].Size + " MB"
$dbLogFile.Text = [string]$srv.Databases[$selectedDb.SelectedValue].LogFiles[0].Name
$dbLogFileSize.Text = [string]$srv.Databases[$selectedDb.SelectedValue].LogFiles[0].Size + " KB"
}
New-TextBox -Row 3 -Column 1 -Name dbName -VerticalContentAlignment Center -Padding 5
New-TextBox -Row 4 -Column 1 -Name dbOwner -VerticalContentAlignment Center -Padding 5
New-TextBox -Row 5 -Column 1 -Name dbSize -VerticalContentAlignment Center -Padding 5
New-TextBox -Row 6 -Column 1 -Name dbLogFile -VerticalContentAlignment Center -Padding 5
New-TextBox -Row 7 -Column 1 -Name dbLogFileSize -VerticalContentAlignment Center -Padding 5
}
} -AsJob
#==========================================================================================================
So is it really as easy to use as they claim?
The description for the WPK on the home page for the PowerShell Pack states: “Think HTA, but easy”.
I must admit I was a bit skeptical when I first read this statement since the WPK is based on the Windows Presentation Foundation, but early experimental examples I came across, like the one in this blog post, required writing a lot of boilerplate code to build even the simplest of components.
Turns out the WPK really is easy to use.
For the WPK Microsoft wrapped the WPF boilerplate code into a set of PowerShell commands that you can use just like any other command.
Once you import the module in your script – using the Import-Module command – creating a new component is as easy as executing a New- command followed by the name of the component, for example New-Button, and voilà: you have yourself a shiny new WPF control.
Building a UI is very similar to creating a web page: each component acts as a container for other components and uses a parent-child relationship to interact with the other components.
The base type for WPK UIs is $window and to get or set the values of the other controls you pipe $window to the Get-ChildControl command, followed by the name of the control you want to manipulate.
Here’s an example taken from the code sample above:
$window | Get-ChildControl serverName
The name used as a parameter to the Get-ChildControl is set by the –Name property of the control in question.
Event handlers are written in plain PowerShell which makes for a very clean overall experience which is quite a relief in comparison to the HTA “spaghetti” code that required you to revert to JavaScript or VBScript to respond to events
Conclusion
Personally I believe Microsoft did a really great job with the WPK.
It might not be everybody’s cup of tea, I know a few hardcore PowerShell scripters that shiver at the idea of adding a UI on top of their carefully crafted scripts, and it takes a bit of time getting used to, but once you get the hang of it, it allows you write UIs really quickly and I for one definitely see some potential for future use.
Resources
The PowerShellPack homepage: http://code.msdn.microsoft.com/PowerShellPack
PowerShell Fun: Setting SharePoint Antivirus settings
12 December, 2010
While working on an automation script for Symantec Protection for SharePoint Server I ran across a few forum posts of people trying to configure SharePoint antivirus settings using PowerShell, but with no apparent solution.
In order to do this you need to hook up the SharePoint Administration webservice:
#
# Load the SharePoint Assembly
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | Out-Null
# Get a reference to the Administration WebService
$admService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
#
Now you can use that instance to set the properties:
# # Set the antivirus settings $admService.AntivirusSettings.AllowDownload = $false $admService.AntivirusSettings.DownloadScanEnabled = $true $admService.AntivirusSettings.UploadScanEnabled = $true $admService.AntivirusSettings.CleaningEnabled = $true # ... more settings available #
And finally, the complete code snippet:
#
# Load the SharePoint Assembly, using old style for backward compatibility with V1
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | Out-Null
# Get a reference to the Administration WebService
$admService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
# Set the antivirus settings
$admService.AntivirusSettings.AllowDownload = $false
$admService.AntivirusSettings.DownloadScanEnabled = $true
$admService.AntivirusSettings.UploadScanEnabled = $true
$admService.AntivirusSettings.CleaningEnabled = $true
# ... more settings available
#
Resources
MSDN: Overview: Virus Scan Engine API Implementation
REMARK: The article referenced above states that the API is now obselete but maintained for backward compatibility, no clues are given on the preferred way for SharePoint 2010 though …
Upgrading SQL Server 2008 Standard to Enterprise
9 January, 2010
It took me some time to find this information so as a reminder to myself:
Select Maintenance from the SQL Server Installation Center and then select Edition Upgrade. Follow the wizard’s steps.
Resources
msdn article: How to: Upgrade to a Different Edition of SQL Server 2008 (Setup)
OpsMgr 2007 R2: Failed to execute SQL string … Incorrect Syntax
16 November, 2009
I just returned from tech-ed Europe 2009 with a mind packed with fresh knowledge. Since there are some new product launches — SharePoint 2010 and SQL Server R2 at the top of the list — I decided to start with a fresh lab environment to test some of the new functionality offered by the new releases.
During the configuration of OpsMgr 2007 I came across an odd error I hadn’t seen before:
failed to execute SQL string, error detail: incorrect syntax error near ‘-’
Some quick googling revealed that I made a mistake naming the OpsMgr database: I used hyphens which SQL Server doesn’t accept unless you enclose the database name with square brackets, obviously the OpsMgr database creation script passes the name without
Replacing the hyphens with underscores solved the problem in no time.
References
Credit where credit’s due, I found the solution here: SCOM Reporting installation error
Quick Tip SharePoint Server 2007: Moving Web Application files to a different location
16 August, 2009
Earlier this week I was asked to move SharePoint Web Application files from the default %systemdrive%\inetpub folder to a dedicated websites folder on a different drive. Strangely enough I had never done this on a production system before.
So here goes, the supported way to move SharePoint web application files to a different location:
- Extend the Web application to a temporary website
- Delete the original website
- Extend the temporary web site back to the original location
- Delete the temporary website
Cheers
During the setup of Operations Manager R2 in my lab environment I ran into this little configuration issue that gave me quite a few headaches: for every agent installed on a domain controller I started receiving errors and warnings about the health service and shortly after the domain controller would switch to an unhealthy state.
The symptoms pointed to a problem with the permissions for the action account installed on the domain controller but, unfortunately, neither the OpsMgr deployment guide nor the security guide offered a clue to what the missing permissions might be.
After some a lot of googling I finally stumbled on this KB on technet which helped solve the issue. What follows is a little summary for future reference:
The symptoms
As stated above, immediately after the installation of the OpsMgr Agent I started receiving errors about the health server in the OpsMgr console:
Also, a couple of warnings would appear about not being able to run the discovery script(s):
When verifying the health state of the domain controllers they appeared grayed out, indicating there was a problem. Note the “unknown” status for the Version and Action Account which is a clear indication that the action account has not enough permissions to execute commands:
The solution
First Option
As usual the solution is really simple, just run following command:
hslockdown "Management_Group _Name" /R "NT AUTHORITY\SYSTEM"
Where Management_Group _Name is the OpsMgr management group of which the agent is a member. All this command does is assign the necessary permissions to the Health Service for the NT AUTHORITY\SYSTEM security principle.
Now restart the HealthService service and the errors should disappear from the OpsMgr console.
(If you want more details on the what’s and why’s, please refer to the original article)
Second Option
For completeness the KB article also mentions a second solution which involves configuring the Privileged Monitoring Account profile with a domain user that has local administrator rights on the domain controllers you are monitoring. Needless to say that this will work, I didn’t need a KB to figure that out, but there is a downside to this solution:
By default the Privileged Monitoring account runs in the context of the system account. When you assign a domain user to the profile it will default to that user for privileged access to the system. Since there are quite a few OpsMgr tasks that require the Privileged Monitoring Account profile to execute, you will need to add the user to the local administrators group on each of the servers monitored by OpsMgr.
That’s a lot of overkill to solve an issue with a couple of domain controllers and while it might not be an issue for some, it makes this system engineer feel a bit uncomfortable so I went with the more elegant solution described above.
Conclusion
All in all I spent the better part of my last four weekends to try and solve this issue and given the number of (fruitless) forum posts I encountered during my investigations, I’m definitely not the only person who was faced with this issue.
I ended up reading through the complete Opsmgr 2007 R2 deployment and security guides, most of the Operations Manager 2007 Unleashed book and visited at least a dozen forums to no avail. It was only after some 50 something google queries using different keywords that I stumbled on the KB mentioned above.
It’s not the first time that I’m faced with a service account permissions issue and as much as a like Microsoft’s System Center products, when configured correctly they can really make a system engineer’s [professional] life a lot easier, I wouldn’t mind if Microsoft would either
- make a better effort at keeping their documentation in sync with KB articles describing [important] issues found after releasing a product
or
- give a more detailed description in the deployment guides of required permissions for service and other accounts needed for configuring their products
Just a thought for saving valuable time …
A couple of weeks ago a colleague of mine was having trouble installing language packs on one of our clients SharePoint 2007 farm. Today I received an email from a colleague requesting some advice for another client who was having problems adding an additional Web Front End to their SharePoint 2007 Farm.
Since both issues share the same root cause I thought a quick post was in order.
What happened?
In both cases the engineers tried to use RTM installation sources on an updated SharePoint 2007 farm, in this case with SP1 and one of the recent cumulative updates installed.
Logically this doesn’t work as expected.
Whenever you make a change to your SharePoint 2007 farm you should do so with installation sources that are the same version as the farm you are trying to update or reconfigure. The easiest way to do so is by adding the update(s) in question into the updates directory of the installation sources using the /extract switch from the setup program.
A short step by step procedure:
- copy / extract the installation sources into a directory, for this step by step I’ll use C:\Temp. Make sure the Setup program is in the root and you have a directory structure with an updates folder
- download the update(s) from the Microsoft site
- open a command prompt en CD into the directory where you downloaded the update packages
- for each update you want to slipstream type the command:
setup /extract:C:\Temp\Updates
A few notes:
- “setup” in the above command refers to the setup program you downloaded from the internet but sometimes it has a more descriptive name to identify the package e.g. SharePoint.exe
- you can also type setup /? to view all the switches for the command
- for each update you need to download the WSS and SharePoint Server versions so you will need to extract two packages / update to the updates folder
- As of the december cumulative update Microsoft uses “über” update packages that contain the infrastructure update, language packs updates etc… so there’s no need to download these seperately: just extract the latest cumulative update to the updates folder
Once you executed the steps above you can execute the installation as you would normally, the setup program will check the updates folder and apply them at the end of the installation progress.
Additional Resources:
A Marvellous Point: How to ‘Slipstream’ installation for MOSS with SP1
Last Monday the Microsoft SharePoint Team announced the availability of the February Cumulative Update packages.
Quick links
A quick introduction
Because of the way SharePoint Server 2007 is implemented behind the scenes, the upgrade process differs quite a bit from the usual update progress we have come accustomed to with other Windows based technologies.
Usually installing updates comes down to:
- downloading an update package
- launching a setup program
- follow on-screen instructions
In the background the upgrade process updates or replaces some files, makes backups of the existing files and the process is terminated. This works just fine for Windows Applications because in most cases the only dependency is the operating system. As long as the update process doesn’t need to update files that are in use, we can continue working as we did before launching the update.
For SharePoint Server 2007 things are somewhat different:
- First of all SharePoint Server 2007 builds upon the Windows SharePoint Services 3.0 platform which in turn is build on top the .NET framework.
- Secondly, all members of a SharePoint farm are dependent on a common data store: the SharePoint Server and content databases.
- Thirdly, as a ASP.NET 2.0 web platform SharePoint Server 2007 requires IIS 6 / IIS 7 .
The diagram below shows how the different components relate:
For the update process this means that, whenever a new update comes available for SharePoint Server 2007, Windows SharePoint Services 3.0 also needs to be updated. Sometimes it might even occur that an update of the .NET framework is required as well e.g. when an update makes use of .NET framework functionality that was introduced in a new version of the .NET Framework released after the previous update for WSS / MOSS.
The use of a common data store for all SharePoint farm members and the dependency on IIS also means that you cannot update a SharePoint farm without downtime unless a fully synchronized standby farm is available, a luxury rarely seen in the real world.
Now let’s see what steps are involved in updating a SharePoint farm.
Preparing to update a farm
Before you can start installing the SharePoint Server update packages, there is some preparing to do. This section is an overview of the tasks you must execute before starting the update process.
Update your documentation
As a first step in your preparation you should verify if your documentation is up to date and includes documentation on all changes that occurred after the initial installation of your SharePoint farm:
- Search customizations
- Custom solutions
- Third-party add-ons
- Alternate Access Mappings
- …
This list is just an example to help you get started but I assume you get the idea.
| Note |
|
One of the strong points of SharePoint Products and Technologies, as they are officially referred to, is that it is relatively easy to add or extend out-of-the-box functionality. The recommended way of extending SharePoint Products and Technologies is through the use of solutions that will add one or more features to the SharePoint Server 2007 farm which can then be activated.
Unfortunately this extensibility also has a downside: apart from a huge selection of commercial software there are literally thousands of solutions, add-ons, features and what else available for SharePoint through open-source platforms like Codeplex.
While many of these solutions are often gems in their own right, sometimes offering very useful functionality, they are not always implemented using Microsoft best practices and require you to manually install files or update configuration files.
If you installed such solutions, make sure you have the sources and installation information of those solutions available before starting the update process. The same advice applies for solutions that are developed in-house. — YSTEX |
Backup your index and important files
Make a backup of following files and folders:
- The Internet Information Services metabase — default location on Windows Server 2003: %systemroot%\system32\inetsrv
- The website root folder — default location on Windows Server 2003: %systemdrive%\inetpub\wwwroot
- Depending on your environment there might be other files and folders to backup as well: check your documentation
- Create a backup of your index files using STSADM or the Central Administration backup page.
| Note |
|
Of course you should also have a full backup of your farm and system state available but because most updates are executed after hours — and often before the backup process starts — the instructions above insure you can return your farm to the state it was before executing the update. — YSTEX |
Prevent access to the SharePoint farm
During the update process no activity is allowed on the SharePoint Server 2007 websites so you will need to shut them down.
Quiesce farm
SharePoint Server 2007 has an option to gradually take a farm offline so that users can finish their work in a timely fashion. The option is called Quiesce farm and is located in the Global Configuration section of the Central Administration Operations tab.
To use Quiesce farm:
-
Set a time frame during which you want the close the connections and click Start Quiescing
-
Wait until you see the Status Quiesced message
Disconnect the content database from the SharePoint web applications
This step is optional.
During the update progress the SharePoint databases schemas are upgraded, a process that takes up quite some time because the update package needs to detect each content database connected to the farm. Disconnecting the content databases reduces the number of databases the update process needs to detect and thus greatly reduces the time needed for installing the packages.
Once the update is installed you can re-connect the content databases which initiates the upgrade process for the database in question. An additional advantage of this way of working is that it gives you the option of prioritizing web applications and connect critical applications first.
Stop the SharePoint Server 2007 web applications
This step is optional but will ensure none of the SharePoint Server 2007 web applications is accessed during the update progress.
To shut down the web applications:
- Open internet information manager
- Expand the Application Pools section
- Stop each of the application pools hosting the SharePoint Server 2007 web applications
Optionally you can stop the web server by typing iisreset /stop in a command prompt or the Windows Start Menu run box. However, this will stop all running websites on the web server as well. The method described above is a little less brutal, especially if you have other web sites running on the web server.
Download the update packages
Download and extract the update packages from the Microsoft download site, remember that you will need at least two packages for the update in question:
- the Windows SharePoint Services update package
- the Office SharePoint Server 2007 update package
| Note |
|
As of the December Cumulative Update package, cumulative updates are truly cumulative and contain all previous updates and language pack updates, with the exception of Service Pack 1. Cumulative updates released before the December Cumulative Update package often required one or more packages to be installed before the upgrade could start. On top of that it was also necessary to do separate installations for SharePoint Server Languages Pack update packages, each time requiring both the WSS and MOSS update packages. The previous update strategy meant that a farm could be down for two or more days, especially if you were using a lot of language packs: I know of one client where the number of update packages required for upgrading to Service Pack 1 amounted to 18 packages per server! — YSTEX |
Installing updates
Now that all farm activity on the farm is suspended you can start installing the updates.
As with the SharePoint Products and Technologies installation process, we need to take several actions to complete the update process:
- Install the Cumulative Update package binaries
- Run the configuration wizard to update the existing binaries
- Run the configuration wizard
Installing the binaries
The first step in the actual update progress is to install the binaries for the Windows Server Services 3.0 and Office SharePoint Server 2007 update packages.
The steps below need to be repeated on each member of the farm that has the Office SharePoint Server 2007 binaries installed: Web Front Ends, Application Servers, Indexer, Query etc…
Install WSS binaries
The screenshots shown here are made while installing the December Cumulative Update package for Windows Server Services 3.0 but the steps described here can be re-used for other updates or Service Packs up to the February Cumulative Update package for Windows Server Services 3.0.
- Launch the setup program for the Windows Server Services 3.0 update package
- Accept the License Agreement and click Next
- Click Ok for the warning message
- The update progress starts
- Wait until the update finishes installing and click Ok
Install MOSS binaries
The screenshots shown here are made while installing the December Cumulative Update package for Office SharePoint Server 2007 but the steps described here can be reused for other updates or Service Packs up to the February Cumulative Update package for Office SharePoint Server 2007.
- Launch the setup program for the Office SharePoint Server 2007 update package
- Accept the License Agreement and click Next
- Click Ok for the warning message
- The update progress starts
- Wait until the update finishes installing and click Ok
- Reboot the server if needed
Run the configuration wizard
Because of the common data store — all farm members connect to the same databases on a SQL Server — and the fact that the update process updates the database schemas with each package, we have to:
- initialize the configuration wizard on each server to update the installed binaries
- finish the configuration wizard in sequence: one server at a time
Initialize the configuration wizard
- Log on to the server that has the Central Administration application installed
- Launch the SharePoint Products and Technologies Configuration Wizard from the Microsoft Office Server menu in the All Programs section of the Windows Start menu
- Click Yes to the warning message and click Next when you return to the SharePoint Products and Technologies Configuration Wizard
- After a few seconds you will receive a warning, do not click Ok
- Repeat steps 2 – 5 on all member servers of the SharePoint farm
- When all servers in the farm are showing the message as described in step 4, return to the server that has the Central Administration application installed and click Ok
- The Configuration Wizard starts the upgrade process
- Wait until the Configuration Wizard finishes the upgrade process
- Finish the Configuration Wizard upgrade process on the other member servers of the SharePoint farm, one by one, wait each time until the Configuration Wizard has finished the upgrade process
Troubleshooting
From time to time the Configuration Wizard upgrade process exits with an error:
If you receive such an error run the following command in a command prompt to force the upgrade process:
psconfig -cmd upgrade -inplace b2b -force
This should finish the upgrade process correctly or at least give you a detailed description of what went wrong.
Finish the update process
-
Reconnect the content databases to their respective SharePoint server 2007 web applicationsTIP: if you want to rename your content databases to comply with a naming convention, you can do so before re-attaching them to the SharePoint server 2007 web applications
- Assign an indexer server to the content databases you just attached
- Start a full crawl
- Recompile any audiences you have configured
Verify the configuration
When all members of your SharePoint farm have been updated you now need to verify your configuration.
- Open the Central Administration Application and browse to Quiesce farm, located in the Global Configuration section of the Central Administration Operations tab
- Click Stop Quiescing
-
Test all the SharePoint server 2007 web applications to see if they can be accessed
- repeat this for all the zones you might have configured
-
Test all the functionality of your SharePoint server 2007 web applications.If one or more web application(s) do(es) not work as expected:
- Verify if all solutions were deployed correctly, re-deploy if needed
- Verify your documentation to see if you need to do some manual tasks
- Check for missing entries in the new web.config files by comparing them with the web.config files from your websites backup
- Check the bin folders from your websites backup for custom components, copy them to their respective bin folders of the updated SharePoint server 2007 web applications
- Test the search engine
- ….
Conclusion
That’s it, my preferred way for installing updates. I’m not going to say that the described method is full-proof because each SharePoint Server 2007 implementation is different, and you might need to do additional steps to complete the update process.
What I can confirm is that I never had any significant problems during the dozen or more farm updates I have done so far — ranging from small farm implementations to fully scaled out farms — using the practices described above.
