Site Collection Owner Webpart Code

public class OwnerPart : WebPart
{
protected override void CreateChildControls()
{
SPSite site = Microsoft.SharePoint.WebControls.SPControl.GetContextSite(HttpContext.Current);
string owner = site.Owner.Name;
Controls.Add(new LiteralControl("Owner: " + owner));
}
}

-Brian Grabowski

Migrating SharePoint 2003 PWA Sites to MOSS 2007

Migrating SPS 2003 to MOSS 2007 can be tricky to begin with. Now throw in Project Server 2003, PWA Sites, and templates that don't exist in your MOSS 2007 environment. All is not lost and it's actually easier than you might think. In this scenario we again will be using the database upgrade method. (This entire scenario is based upon the assumption that you do not and probably will not have Project Server 2007 installed with your MOSS 2007 deployment.)

Here's what I did:

So let me set up the scenario. You have;
SPS2003 with Project Server 2003 and a mix of default templates and PWA templates
MOSS 2007 with NO Project Server and the same mix of default templates and PWA templates that need to be migrated into MOSS 2007

What you will need; (for a database migration)
SPS 2003
SQL 2000/2005
Winrar, Winzip, etc...(compressing backed up databases before you move them decreases the risk of corrupting your databases)
Project Server 2007 (Trial or Licensed...A trial version will work on a server with other trial licenses. You can not mix and match trial versions with licensed versions.)
MOSS 2007

On to the fix;

BEFORE YOU PERFORM ANY OF THESE STEPS MAKE SURE YOU HAVE CLEAN BACKUPS OF EVERYTHING SHAREPOINT!!!

Install Project Server on a Development Server or VM with MOSS 2007 installed
Run PSConfig
This Reconfigures the Farm to work with Project Server 2007
Installs Templates, Files, Data
It will install key files to;/config/upgrade/pwsupgrade.xml
/template/1033/xml/webtemppwa.xml
/template/site templates/PWA and PWS
/template/features/PWA, PWAProposals, PWS, PWSCommitments, PWSCTypes, PWSocLibs, PWSFields, PWSIssues, PWSRisks
Copy Installed Files
Uninstall Project Server 2007
(You can leave it installed if you wish, but if you want to uninstall it continue to the next step)
(Uninstalling Project Server 2007 kills the SharePoint Farm…nothing in IIS, no CA, nothing…all you have left is DB’s in SQL)
***IMPORTANT***
At this point SharePoint is no more, you won't be able to access sites or CA
***DON'T WORRY***
IISReset
Move copied files to correct locations on your Production Server…/upgrade, /xml, /site templates
Re-run PSConfig (THIS WILL BRING YOUR SHAREPOINT ENVIRONMENT BACK)
Connect to existing Farm
Reattach SQL Server
Reattach Config_DB
Run through PSConfig Steps 1-9
IISReset
ReDeploy Solutions (the Uninstall will retract all deployments)
Restore Migrated DB to Development
Attach Migraged DB to Development
At this point in time you should now be able to browse to your SPS 2003 PWA Sites in your Development MOSS 2007 environment
If everything seems fine in Development restore and attach to Production

-Brian Grabowski

SharePoint Backup Models

Types and Descriptions of Backup Models as suggested by Microsoft.

"Full Backup Model w/ Truncation
The full recovery model uses log backups to prevent data loss in the broadest range of failure scenarios, and backing and restoring the transaction log (log backups) is required. The advantage of using log backups is that they let you to restore a database to any point of time that is contained within a log backup (point-in-time recovery). Assuming you can back up the active log after a disaster occurs; you can restore the database up to the point of failure without data loss. The disadvantages of using log backups are that they require storage space and increase restore time and complexity.

Truncation
Under the full recovery model or bulk-logged recovery model, the inactive part of the log cannot be truncated until all its log records have been captured in a log backup. This is needed to maintain the log chain—a series of log records having an unbroken sequence of log sequence numbers (LSNs). The log is truncated when you back up the transaction log.

Optional Backup Models

Simple Backup Model
The simple recovery model provides the simplest form of backup and restore. Backup is easy to manage because the transaction log is never backed up. However, if there are no log backups, a database can be restored only to the end of the most recent backup of the data. If a failure were to occur, updates that are made after the most recent backup of the data are lost.

Bulk Logged Backup Model
This topic is relevant for optimizing bulk operations on SQL Server databases that typically use the full recovery model.

The bulk-logged recovery model is a special-purpose recovery model that should be used only intermittently to improve the performance of certain large-scale bulk operations, such as bulk imports of large amounts of data. Much of the description of backup under the full recovery model also applies to the bulk-logged recovery model. This topic looks only at considerations that are unique to the bulk-logged recovery model." -Microsoft

-Brian Grabowski

Growth Model for Site Collections and Content Databases

When to Create a New Site Collection

A site collection is a group of sites built on Microsoft Windows SharePoint Services that all exist under a top-level site. To make managing the sites and their content more convenient, you can assign users to be site collection administrators or site collection owners. These are permission levels to give to users who you want to have full administrative rights to all sites and content within a site collection.

Site Collections should be created for;
New Top Level Sites
New Groups
New Divisions
Any new or non existing major heading or internal site

Examples
IT
Finance
HR
Sales
Marketing

Site Collections should NOT be created for;
Personal Sites
Project Sites
Any minor heading or internal site that should fall under one of the larger more generic, “encompassing” Site Collections

To create Site Collections, Administrators can use;
Central Administration GUI
Application Management
Create Site Collection
STSADM
stsadm.exe -o createsite -url http://myserver/sites/site1 -ownerlogin -owneremail someone@example.com -ownername

When to create a New DB

By default Site Collection are created in the same or last created Content Database unless specified other wise. Content Databases are the warehouses for a Site Collection’s Files, Documents, List Items, Subsites, and overall general data contained within the Site Collection.

New Content Databases should be created for/when;
A Site Collection contains/will contain highly sensitive information that if lost must be backed up as quickly as possible
A current Site Collection is approaching the 100 GB limit (or the pre-determined limit)
A Database is approaching or has hit its maximum number of sites allowed

Limit content database size to enhance manageability
Plan for database sizing that will allow for manageability and performance of your environment.

In most circumstances, to enhance the performance of SharePoint, the use of content databases larger than 100 GB is not suggested. If your design requires a database larger than 100 GB, follow the guidance below. (100 GB is a suggestion only from a SQL Manageability and Usability standpoint. SQL 2005 is “capable” of handling Terabytes of data, however managing a database that large is not feasible. To determine the actual limit or cut off points for your SQL environment speak with the DBA’s and see what they are comfortable with managing and how the current backup model is setup.)

Use a single site collection for the data.
Use a differential backup solution, such as SQL Server or Microsoft System Center Data Protection Manager, rather than the built-in backup and recovery tools.
Test the server running SQL Server and the I/O subsystem before moving to a solution that depends on a 100 GB content database.
Split content from a site collection that is approaching 100 GB into a new site collection in a separate content database to avoid performance or manageability issues.
Limit content databases that contain multiple site collections to approximately 100 GB.

STSADM Command Quick Tip:
To create a new Site Collection in a new Content Database use the following command with the appropriate parameters;
stsadm -o createsiteinnewdb

-Brian Grabowski

Capacity and Scaling

Scalability is the ability of an application to efficiently use more resources in order to do more useful work. For example, an application that can service four users on a single-processor system may be able to service 15 users on a four-processor system. In this case, the application is scalable. If adding more processors doesn't increase the number of users serviced (if the application is single threaded, for example), the application isn't scalable.
In regards to SharePoint to accommodate greater user load, add Web Front End Servers. To accommodate greater data load, add capacity to the database server role by increasing the capacity of a single (clustered or mirrored) server, by upgrading to a 64-bit server, increasing Processing Power, increasing RAM, or by adding clustered or mirrored servers. Maintain a ratio of no greater than eight Web server computers to 1 (clustered or mirrored) database server computer.

Scale Up
Scaleup means scaling to a bigger, more powerful server—going from a four-processor server to a 16-processor or 32-processor server, for example. This is the most common way for databases to scale. When your database runs out of resources on your current hardware, you go out and buy a bigger box with more processors and more memory. Scaleup has the advantage of not requiring significant changes to the database. In general, you just install your database on a bigger box and keep running the way you always have, with more database power to handle a heavier load.

Scaleout
Scaleout means expanding to multiple servers rather than a single, bigger server. Scaleout usually has some initial hardware cost advantages—eight four-processor servers generally cost less than one 32-processor server—but this advantage is often cancelled out when licensing and maintenance costs are included. In some cases, the redundancy offered by a scaleout solution is also useful from an availability perspective.

-Brian Grabowski

SharePoint 403 Forbidden Error

During recent migrations we used the database migration method to move SPS 2003 Sites into a MOSS 2007 Farm. The basic process went like this;

• (SPS 2003 Farm)
• Prescan
• Set DB's to read-only
• Backup DB's
• Move DB's to MOSS 2007
• (MOSS 2007 Farm)
• Restore DB's
• Attach DB's

Now view your Sites and all works fine right? Not so much, how about a "403 Forbidden" error. Thats always nice! On the SPS 2003 side the sites had been "locked." This can be done through SPSSiteManager.exe or the Central Administration. Either way they were locked.

Once on the MOSS 2007 side all we had to do was "unlock" the sites. The command has changed a little bit and there were a ton of sites, so we opted to script the command that looked something like this;

Here's what I did:

The actual command is;
stsadm.exe -o setsitelock -url -lock

@echoCd\Cd “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN”stsadm.exe -o setsitelock -url http://sharepoint/sites/sitename -lock none
Repeat for Site #2
Repeat for Site #3
etc... etc...
@echo off
pause
exit

-Brian Grabowski

Wiki Pages not in Search Results

With the addition of a rather large Wiki Site in our SharePoint Farm, users began adding new "posts" like wildfire. However, when they went to search for them, all they got was the link to the main Wiki Page or a document or link that contained the word "wiki." After adding content sources, creating rules, and creating scopes I found the quick and simple fix. Click the box that enables search to crawl .aspx pages!

Here's what I did:

• Go to Site
• Site Actions
• Site Settings
• Search Visibility
• Check "Yes" for "Allow this web to appear in search results?"
• Check "Always index all ASPX pages on this site" for "This site does not contain fine-grained permissions. Specify the site's ASPX page indexing behavior:"

• Click OK
• Wait for the next or Start an incremental crawl
• Search for .aspx Wiki Pages

-Brian Grabowski