When attempting to restore a large database using SQL Server 2008 Management Studio, the following error may be thrown:

An exception occurred while executing a Transact-SQL statement or batch
Timeout expired

Microsoft Knowledge Base article 967205 discusses the problem, although the article is referring to problems restoring from tape. The article suggests that this problem has been corrected by a SQL Server 2008 Cumulative Update. Our environment is running SQL Server 2008 Service Pack 2 with the June 2011 cumulative update applied and the problem remains.

The workaround mentioned in the article did resolve the issue. SQL Management Studio can still be used to perform the restore, but a Transact-SQL query must be written to perform the restore. To restore a backup to a new database, the query looks like this:

RESTORE DATABASE My-Big-Fat-Database
FROM DISK = 'DRIVE:\PATH\MyBigFatDatabase.bak'
WITH RECOVERY
GO

If a newer differential backup will also be restored, change WITH RECOVERY to WITH NORECOVERY like so:
RESTORE DATABASE My-Big-Fat-Database
FROM DISK = 'DRIVE:\PATH\MyBigFatDatabase.bak'
WITH NORECOVERY
GO

If restoring to an existing database, add the REPLACE option:
RESTORE DATABASE My-Big-Fat-Database
FROM DISK = 'DRIVE:\PATH\MyBigFatDatabase.bak'
WITH RECOVERY, REPLACE
GO

If restoring to a different server where the SQL databases and logs reside in a different location, first do a FILELISTONLY restore:
RESTORE FILELISTONLY
FROM DISK = 'DRIVE:\PATH\My-Big-Fat-Database.bak'
GO

This will provide a list of logical and physical names for the files in the backup

LogicalName PhysicalName
My-Big-Fat-Database E:\My-Big-Fat-Database.mdf
My-Big-Fat-Database-log E:\My-Big-Fat-Database-log.ldf

 
Perform the restore using the MOVE option to relocate the database files to the correct location:

RESTORE DATABASE My-Big-Fat-Database
FROM DISK = 'DRIVE:\PATH\MyBigFatDatabase.bak'
WITH NORECOVERY,
MOVE 'My-Big-Fat-Database' TO NEWDRIVE:\NEWPATH\My_Big_Fat_Database.mdf',
MOVE 'My-Big-Fat-Database-log' TO NEWDRIVE:\NEWPATH\My-Big-Fat-Database-log.ldf'
GO

In SharePoint, when a user chooses to upload a single document or multiple documents into a document library that does not have versioning enabled, the check box for "Overwrite existing files" is automatically checked. If the document library has versioning enabled, the option changes to "Add as a new version to existing files" and is automatically checked.

This behavior can be changed so that the check box is not automatically checked. The steps involved depend on which version of SharePoint you are modifying.

SharePoint 2007

SharePoint 2010

Now, when the "Upload Document" or "Upload Multiple Documents" dialogs are presented, the "Overwrite existing files" and "Add as a new version to existing files" option will not be checked by default.

When running SharePoint on Server 2008 and using a Network Load Balancing (NLB) cluster, the following warning messages may sporadically appear in the System event log:

SOURCE: NLB
Event ID: 105
NLB cluster []: Timer starvation has been detected. This might be due to a denial of service attack or a very high server load. During this period some connections might fail. If this problem recurs frequently, analyze the threat and take appropriate measures and/or add more servers to the cluster. An informational message event log entry will be logged when the attack has subsided.

Shortly after the warning message, the informational event will get logged:

SOURCE: NLB
Event ID: 106
NLB cluster []: Timer starvation has subsided

Information regarding this problem is discussed in Microsoft Support Knowledge Base article 951037. Basically, Server 2008 introduces a TCP Chimney Offload feature and it's incompatible with NLB. To turn off the TCP Chimney feature:

Offload properties will vary by NIC. Look for things like:

It's always a good idea to test your SharePoint backups to ensure they will actually work in case you ever need them. You are doing backups, right?

(more…)

When working with Central Administration and Service Accounts, you may find application pools listed that no longer exist on the portal. More than likely this was caused by application pools being changed or deleted directly through IIS. Although IIS knows the application pools are gone, SharePoint has no idea.

Fortunately, PowerShell can help with this. Fire up PowerShell and enter the following:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$WebApp = Microsoft.SharePoint.Administration.SPWebApplication]::Lookup ('http://<em>your_portal</em>')
$WebApp.WebService.ApplicationPools | select Name,Id | format-table -auto

This will show you a list of what application pools SharePoint has configured. To get rid of an orphaned application pool, perform the following
$WebApp.WebService.ApplicationPools.remove("<em>ID_OF_POOL_TO_DELETE</em>")

To confirm the object was deleted, re-run
$WebApp.WebService.ApplicationPools | select Name,Id | format-table -auto

 

It may become necessary to reconfigure your SharePoint service accounts. This was the case when implementing our development portal. There are several steps involved, depending on what is being changed.

(more…)

While you can perform a Visual Upgrade on a SharePoint 2007 site after importing it into SharePoint 2010, what if you want to change it back?

The SharePoint 2007/2010 visual style is determined by the site's UIVersion property. A value of 3 dictates a 2007 look and feel, while a value of 4 dictates a 2010 appearance.

We can use PowerShell to change the UIVersion at will.  The following script will recursively upgrade or downgrade a site's visual style.

# Title Set-SPWebUIVersion
# Version 1.1 25JAN12
# Author James Sanders
# Purpose Perform a Visual Upgrade/Downgrade of SharePoint 2010 web site and subsites

Param([string]$URL, [string]$Style)

# Internal script functions
Function ShowHelp() {
$HelpText [email protected]"

SP2010SiteStyle
Perform a "Visual Upgrade/Downgrade" of SharePoint 2010 web site

PARAMETERS
-url [REQUIRED] URL of site to change
-style [REQUIRED] (2007|2010) Which UI version to apply

EXAMPLES

Changes site to 2007 style
Set-SPWebUIVersion.ps1 -url http://web_to_change -style 2007

Changes site to 2010 style
Set-SPWebUIVersion.ps1 -url http://web_to_change -style 2010

"@
$HelpText
}

# Enumerate SharePoint web site to include all subwebs
Function EnumerateWebs ([Microsoft.SharePoint.SPWeb]$Web, [array]$Webs) {
  If ($Web.Webs.Count -gt 0) {
    $Webs = $Webs + $Web.Url
    ForEach ($SubWeb In $Web.Webs) {
      EnumerateWebs $SubWeb
    }
  }
  Else {
    $Webs = $Webs + $Web.Url
  }
  Return $Webs
}

# Show help and exit if no URL specified

If (!$URL -Or !$Style) {ShowHelp; Exit}
Switch ($Style) {
  "2007" {$VisualStyle = 3}
  "2010" {$VisualStyle = 4}
  Default {ShowHelp; Exit}
}

"`nSet-SPWebUIVersion`n"

# Load SharePoint Snap-In
"- Loading SharePoint PowerShell snap-in"
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

# Retrieve SharePoint Site
$Web = Get-SPWeb($URL) -ErrorAction SilentlyContinue

If (!$Web) {
  "`nERROR: Unable to open web site $URL"
  Exit
}

# Retrieve subsites
$Webs = EnumerateWebs $Web|Sort-Object
$Web.Dispose()

# Display site info
"`nDETAILS"
"Web Site: $URL"
"Sub Sites: $($Webs.Count)`n"
"Applying $Style style ...`n"

$Webs = $Webs|Sort-Object -Descending
ForEach ($WebURL In $Webs) {
  "- Reconfiguring $WebURL"
  $Web = Get-SPWeb $WebURL
  $Web.UIVersion = $VisualStyle
  $Web.Update()
  $Web.Dispose()
}
"`nDone!`n"

 

Windows does not like inaccurate time. When the system time between a domain controller and a remote machine is more than 5 minutes apart, the remote machine will not be able to authenticate, and the user at the remote machine will not be able to log on. Not the start to a great day.

Windows SharePoint is no exception. If the system time gets moved forward and then moved backward due to misconfigured or low accuracy time servers, the SharePoint Timer service becomes very unhappy. In this case, system time was moved forward roughly 24 hours, then corrected a few hours later moving the clock back 24 hours.
The SharePoint Timer Service maintains a cache folder which keeps track of what is going on. In a farm environment, individual servers can enable a "Timer Lock" which prevents other farm servers from performing jobs. The timer lock is used when critical jobs are being ran that should not be interruped or possibly conflicted with by jobs running from other servers.

When the system time gets disrupted, the result is cache files that are newer than the current time. Then the Timer Service doesn't know what's going on, starts freaking out and puts the following warning message in the application event log every 5 minutes:

SOURCE: Windows SharePoint Services 3
Event ID: 5219
Task Category: Timer
The timer lock for Web server 'servera' was overriden by Web server 'serverb' because the lock had not been refreshed within the 20 minute timeout. The timer service on 'servera' may be malfunctioning.

To correct the problem, perform the following steps on the server experiencing the timer lock issue:

The config folder will repopulate and the warning message should stop appearing in the application log. If ALL SharePoint servers are exhibiting this behavior, perform the above steps on each server and wait at least 5 minutes between servers.

 

I received the following fun message while attempting to change SQL Server 2008 database properties:

Cannot show requested dialog (sqlMgmt)

Property Owner is not available for database xyz.  This property may not exist for this object, or may not be retrievable due to insufficient access rights.

Visiting Uncle Google came up with some information regarding changing database ownership, which ultimately turned out to be the problem.

Running the sp_helpdb query showed there were several SharePoint databases with UNKNOWN listed as the owner.  To fix this, the following query was created and executed against the problem databases:

USE DBNAME
EXEC sp_changedbowner 'DOMAIN\ACCOUNT'

For my query, I used the farm domain account and made it the owner.
Problem resolved.

04/05/14 UPDATE - New job, new fun.  I found several databases where the original database owner no longer worked for the organization and their account was expired/deleted.  When  changing the database owner, you may receive a message stating that the new owner account already exists in the database.  To resolve this, expand the database > Security > Users and delete the user account.  Run the above T-SQL query and all will be right in the world again.

 

Copyright 2011 - 2021 The Lazy SharePoint Admin | All Rights Reserved
menu-circlecross-circle linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram