Wednesday, January 14, 2009
protected override void CreateChildControls()
SPSite site = Microsoft.SharePoint.WebControls.SPControl.GetContextSite(HttpContext.Current);
string owner = site.Owner.Name;
Controls.Add(new LiteralControl("Owner: " + owner));
Monday, November 24, 2008
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)
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.)
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
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/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)
At this point SharePoint is no more, you won't be able to access sites or CA
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
Run through PSConfig Steps 1-9
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
Monday, November 10, 2008
"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.
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
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
Any new or non existing major heading or internal site
Site Collections should NOT be created for;
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
Create Site Collection
stsadm.exe -o createsite -url http://myserver/sites/site1 -ownerlogin
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
Tuesday, November 4, 2008
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.
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 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
- (SPS 2003 Farm)
- 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
Wednesday, October 15, 2008
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