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
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:"
Recently I have run into some issues with Search. Indexing Errors, Propagation Errors, Account Errors, etc. Accounts that have been imported for months couldn't search items that were newly created and newly imported accounts could search, some search items were showing up immediately after the incremental crawl, while others that had been uploaded and checked-in for quite some time and still failed to show up, etc., etc... After about a week of research and some mild head bashing I have come up with some solutions as well as some proactive maintenance and scheduling plans that should help you out.
Here's what I did:
First off, install the latest infrastructures upgrades. There are two; one for WSS and one for MOSS. Make sure you implement the WSS one first and the MOSS one Second. However, make sure you implement them both! The WSS upgrade will fix some things and make a few improvements but the MOSS Infrastructure upgrade will give you a whole new feature set and it's own administrative console. For all of the updates see Microsoft's article http://blogs.msdn.com/sharepoint/archive/2008/07/15/announcing-availability-of-infrastructure-updates.aspx
Once the upgrades are in place its time to review the second part; the Search schedule. It was brought to my attention (with a call to Microsoft regarding another matter) that a full crawl everyday for a large SharePoint implemtation is not necessary and more than likely counter productive. Perform a Full Crawl once a week on a Friday or Saturday morning. Perform incremental crawls 2 times a day (at most) in the morning and the evening.
Next we move on to the SQL/Database side of things where there are also a few recommendations. The first has to do with the Transaction Logs. The TL's are used to record any and all modifications made to databases, including the search/index database. Make sure that your TL's have enough space and are growing accordingly with the rest of your farm. After all of this, you should continue to perform routine database maintenace as well as a few other things. Once a month you or your DBA's should defrag your SharePoint Databases just to keep them organized and dust free. One other thing to consider doing monthly is Rebuilding and Reindexing your SharePoint Search. This is again to de-clutter, clean up, and start fresh.
To Summarize:
Install WSS 3.0 Infrastructure Upgrade
Install MOSS 2007 Infrastructure Upgrade
Run a Full Crawl Once a Week
Run 2 Incremental Crawls daily
Ensure your Transaction Logs have space to grow and grow accordingly with your farm
Perform database maintenance regularly
Once per month Perform SharePoint DB Defrag
Once per month (or two months) Perform a complete Rebuild/Reindex of SharePoint Search
When migrating from SPS 2003 to MOSS 2007 we all know there are 3 options to pick from;
In-Place (Quickest, most room for error)
Gradual and (Ease of use and control)
Database (More manual, ease of use, leaves old farm completely in tact)
For all intents and purposes this post will summarize a Database Migration and Resetting Site Definitions, but the focus is primarily on the stsadm command mergecontentdbs and how I used it to restore multiple site collections at once rather than using backup and restore.
Here's what I did:
Backup and Restore (from SPS 2003 to Development MOSS 2007)
Put Content DB's in Read Only Mode
Run Pre-Upgrade Scan
Reset to original Site Definition
Backup Content DB's
Transfer .bak files to Development
Restore DB's in Development SQL Environment
Upgrade and UAT (In Development MOSS 2007)
Attach newly upgraded datbase(s) as new content database(s)
Upgrade Process (Automatic)
User Acceptance Testing
Restore (to Production MOSS 2007)
Once sites have passed UAT and all functionality can be accounted for, sites will be “merged,” or moved to a new content database that is ready to be attached in the production environment. The new database will be backed up and then restored as an entire collection. With this method we can move multiple sites at once rather than manually moving each site collection one by one. The following command line prompt is an example of merging content databases;
First, the option that I will be showing here (#3) requires a file to read from. That file is a list of the sites in the database that you want to move to another one. This list can be edited to exclude certain sites. In our case excluding sites that haven't passed UAT.
If you have been trying to search for a number or a combination of numbers in SharePoint such as an IP address or strictly version numbers, you have probably been coming up short. This is due to "Noise Filtering." There is a text file that filters noise words such as "a," "the," "and," numbers, etc.
Here's what I did:
Edit the noiseenu.txt file Go to "Sharepoint Portal Server Install directory"/Applications/Guid/Config/noiseenu.txtRemove the "numbers" from the file Restart the SharePoint Search Service Reset the search indexes and perform a full crawl
Once the crawl is finished you should now be able to search for numbers.
.jpg)
Posts
