Thursday, December 31, 2009
When we had gone for a backup of the site collection we went ahead with the default parameter stsadm -o backup -url http://server_name/sites/site_name -filename site_name.bak
and then we restored it using the stsadm command
stsadm -o restore -url http://server_name/sites/site_name -filename site_name.bak
Once restored we faced a funny issue in which we were not able to delete Site Collection Administrators nor we were able to edit the pages.
We did our analysis and found out that when we had done a backup withe the above STSADM command, we had missed out another parameter -nositelock . This locked the site collection when the backup was done. Once restored, the lock on the site collection still persisted. We had to go Central administration page --> Application Management --> Site collection Quotas and locks link. There we have the option to remove the read only option. Once we remove the read only permission, we were able to do all site administration tasks on the site collection.
Hope this helps..
for more details you can go through
Wednesday, December 16, 2009
Below is the line which I saw in the Sharepoint log.
12/15/2009 11:20:28.42 w3wp.exe (0x0F0C) 0x0668 SharePoint Foundation General
For my analysis, I opened the task manager and added a column PID into the Processes tab.
This PID will act as a link between the w3wp process and the application pool it is linked to.
Now open the command prompt.
set the path as C:\Windows\System32\inetsrv
Then type the command
appcmd list wp
This shall give you the list of application pool along with the PID.
Using the PID I was able to identify which application pool was consuming too much memory and was able to troubleshoot the issue.
For IIS 6.0, you can write the below command,
by going to the path C:\WINDOWS\system32.
Hope this helps someone who is having issues related to IIS worker process.
Tuesday, December 8, 2009
@echo ========= SQL Server Ports ===================
@echo Enabling SQLServer default instance port 1433
netsh firewall set portopening TCP 1433 "SQLServer"
@echo Enabling Dedicated Admin Connection port 1434
netsh firewall set portopening TCP 1434 "SQL Admin Connection"
@echo Enabling conventional SQL Server Service Broker port 4022
netsh firewall set portopening TCP 4022 "SQL Service Broker"
@echo Enabling Transact-SQL Debugger/RPC port 135
netsh firewall set portopening TCP 135 "SQL Debugger/RPC"
@echo ========= Analysis Services Ports ==============
@echo Enabling SSAS Default Instance port 2383
netsh firewall set portopening TCP 2383 "Analysis Services"
@echo Enabling SQL Server Browser Service port 2382
netsh firewall set portopening TCP 2382 "SQL Browser"
@echo ========= Misc Applications ==============
@echo Enabling HTTP port 80
netsh firewall set portopening TCP 80 "HTTP"
@echo Enabling SSL port 443
netsh firewall set portopening TCP 443 "SSL"
@echo Enabling port for SQL Server Browser Service's 'Browse' Button
netsh firewall set portopening UDP 1434 "SQL Browser"
@echo Allowing multicast broadcast response on UDP (Browser Service Enumerations OK)
netsh firewall set multicastbroadcastresponse ENABLE
Let me first discuss about the Upgrade Stratergy first. There are two ways of upgrading the SQL server 2000/2005 to SQL 2008.
1> In-place upgrade.
2> Side by Side upgrade.
· When planning an upgrade to SQL Server 2008, we first have to make sure that the target servers meet the necessary hardware and software requirements for SQL Server 2008 Setup to be completed.
· .NET Framework 3.5 should be installed.
· Windows Installer 4.5 should also be installed.
· Need to back up all of the system databases and user data bases
· Power shell should be installed.
· Need to run DBCCCheckDb against all databases to see the integrity of all the databases are intact.
· Finally, Run the Upgrade Advisor. Need to go through all the errors/warnings one by one and fix the errors before going forward with upgrade. Priority will be set for the errors which needs to be mandatorily fixed before the upgrade can begin.
There are few restrictions when we are going for an In-place upgrade.
- SQL Server 2008 Setup requires that all SQL Server 2000 and SQL Server 2005 components be upgraded together. In other words, we cannot upgrade only an instance of the SQL Server 2005 Database Engine without also upgrading the Analysis Services component.
- If our legacy instance of SQL Server 2000 or SQL Server 2005 is installed on Windows 2000 Server, we must upgrade to a new server by using a side-by-side upgrade; SQL Server 2008 is not supported on Windows 2000 Server.
- A cross-platform, in-place upgrade from a 32-bit instance of SQL Server 2000 or SQL Server 2005 (x86) to a 64-bit instance of SQL Server 2008 (x64), or vice versa, is not supported.
An in-place upgrade is the fastest and easiest upgrade method because it upgrades all system and user databases and settings for us. We do not have to update client applications to connect them to a new instance of the Database Engine. In the unlikely event that an in-place upgrade of the relational Database Engine fails, we cannot quickly roll back to SQL Server 2000 or SQL Server 2005.
If the upgrade fails, we have to take the following steps:
1> From the installation media, we need to run the repair option in an attempt to fix the instance; if this does not work, we need to go for uninstall as mentioned in step 2.
2> Uninstall the corrupted SQL Server 2008 instance that was created during the failed upgrade attempt.
3> Reinstall the earlier version of SQL Server (SQL Server 2000 or SQL Server 2005).
4> Reinstall any required SQL Server service packs to your SQL Server 2000 or SQL Server 2005 instance.
5> Restore the system and user databases from database backups.
6> Review issues that prevented a successful upgrade in the previous attempt, resolve them, and restart the upgrade process.
We need to be aware that this process of in-place upgrading needs sufficient downtime, either when the upgrade is a success or when its a failure.
Activites to be done after In-place upgrade
1> Check if the Remote query timeout (s) server setting is set to 0, if not need to change.
2> Compatibility of master and User databases need to change to 100
Side by Side Upgrade
In this upgrade, we try to move all or some data from an instance of SQL 2000/2005 to SQL 2008. There can be one server move or two sever move.
In one server move, we install a new instance of SQL 2008 on the same server where SQL 2000/2005 is available.
In two server move, we install a new instance of SQL 2008 either in default or named instance on a new server. This upgrade is very time consuming in which the migration would be done manually or either by scripting. But seeing the positive side, there is no need for the application downtime, till the SQL 2008 databases are ready to be connected to the application.
Hope this helps someone...
Sunday, December 6, 2009
$url = "http://servername"
$1 = "/_catalogs/masterpage/v4.master"
$2 = "/_catalogs/masterpage/nightandday.master"
$SPSite = Get-SPSite $url
$SPWeb = $SPSite.OpenWeb()
$SPSite.AllowUnsafeUpdates = "True"
## get the current status of the Site Master Page Settings in _Layouts/ChangeSiteMasterPage.aspx ##
$a = Get-SPSite $url
$b = $a.OpenWeb()
$c = $b.get_CustomMasterUrl()
$d = $b.get_MasterUrl()
$e = $b.get_AlternateCssUrl()
#### updating the SITE MASTER PAGE SETTINGS with the new ones ####
$Custmaster = $SPWeb.CustomMasterUrl ##Site Master Page - night
$SPWeb.CustomMasterUrl = $2
foreach($SubSite in $SPSite.AllWebs)
$SubSite.AllowUnsafeUpdates = "True"
$SubSite.CustomMasterUrl = $2
Write-Host "$SubSite updated"
$SPWeb = $SPSite.OpenWeb()
$SysMaster = $SPWeb.MasterUrl
## System Master Page - v4
$SPWeb.MasterUrl = $1
foreach($SubSites in $SPSite.AllWebs)
$SubSites.AllowUnsafeUpdates = "True"
$SubSites.MasterUrl = $1$SubSites.Update()
Write-Host "$SubSites updated"
$SPWeb = $SPSite.OpenWeb()
$SPWeb.AlternateCssUrl = "/Style Library/en-us/Core Styles/my_custom.css"
foreach($WebSubSites in $SPSite.AllWebs)
$WebSubSites.AllowUnsafeUpdates = "True"
$WebSubSites.MasterUrl = $1
Write-Host "$WebSubSites updated"