Monday, November 24, 2008

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 templatesMOSS 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 2003SQL 2000/2005Winrar, 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 installedRun PSConfigThis Reconfigures the Farm to work with Project Server 2007Installs Templates, Files, DataIt 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, PWSRisksCopy Installed FilesUninstall 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***IISResetMove copied files to correct locations on your Production Server…/upgrade, /xml, /site templatesRe-run PSConfig (THIS WILL BRING YOUR SHAREPOINT ENVIRONMENT BACK)Connect to existing FarmReattach SQL ServerReattach Config_DBRun through PSConfig Steps 1-9IISResetReDeploy Solutions (the Uninstall will retract all deployments)Restore Migrated DB to DevelopmentAttach Migraged DB to DevelopmentAt this point in time you should now be able to browse to your SPS 2003 PWA Sites in your Development MOSS 2007 environmentIf everything seems fine in Development restore and attach to Production

Monday, November 10, 2008

"Full Backup Model w/ TruncationThe 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.

TruncationUnder 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.

Simple Backup ModelThe 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 ModelThis 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

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 SitesNew GroupsNew DivisionsAny new or non existing major heading or internal site

ExamplesITFinanceHRSalesMarketing

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

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 possibleA 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 manageabilityPlan 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

Tuesday, November 4, 2008

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 UpScaleup 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.

ScaleoutScaleout 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.

Friday, October 17, 2008

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;

Wednesday, October 15, 2008

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:"