To find STSADM.exe navigate to the bin folder in the 12 hive – here C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN

Open a command window and drag stsadm.exe onto it and use the following command to add the solution to the solution store.

stsadm -o addsolution -filename c:\solution.wsp

You can also use stsadm to deploy the solution but here I am going to describe the point and click method using SharePoint Central Admin which does the same thing.

Open SharePoint Central Admin and select the Operations tab.

Select Solution Management.

Click the link to the .wsp solution you just added.

Click Deploy Solution – If the solution is not globally deployed select the web applications you want to deploy to.

Click OK.

The solution is now deployed to the web applications you selected or to all web applications if it deployed globally. This is not the end of the deployment process though. If the solution contains a web part there are still a few steps to go before it will be displayed on your site. To add the web part to a page on your site do the following:

Navigate to the site collection where you want to place the web part and go to Site Settings and Site Collection Features (this assumes that the feature is scoped at the site collection level, sorry for making more assumptions that you understand scopes but that is another post and something that other people have already written plenty about if you want to find out more).

Activate the feature that contains the web part that has been deployed in the solution.

Next, go to Site Settings and Web Parts and click New.

Select the web part to add it to the wbe aprt gallery for that site collection.

The web part is now ready to be added to a page in the usual way – edit page, add web part to zone, browse to web part.

stsadm -o backup -filename “\\gl-nas-01\backup$\Sharepoint\GL-SP-01\%date:~-10,3%%date:~-7,3%%date:~-4%.dat” -url http://intranet/sites/home

Source : http://workerthread.wordpress.com/2008/01/03/configure-pdf-ifilter-in-wss-30/

• Service Account – You cannot use any built in accounts when specifiying the Service Account, however you can use local accounts. One account you can choose to use is the default Administrator account on your server, “myserver\Administrator”.
• Content Access Account – Use an account that has full read access to your SharePoint Content Databases. As a security precaution, try not to use an account that has write permissions on the database. For example: “mydomain\sqlserveruser”.
• Search Database – In most cases the default settings will work, change them as required.
• Indexing Schedule – No new files will be searchable until they are indexed, depending on the load you wish to put on the server you can set this to be done as often as you want.

Upon submitting the form, the search service should start and begin indexing the content in your SharePoint site. Now would be a good time to install the Adobe IFilter to allow your search service be able to index PDF files, the earlier you install it the better, since it will only recognize PDF files added after the addon was installed.

Source : http://geekswithblogs.net/karskip/archive/2007/11/30/117263.aspx

The  thing you should check are the version numbers of the original and target SharePoint servers are the same.
They MUST be the same.
In my case the SharePoint Services 3.0 was updated with SP1. The version number is : 12.0.0.6219
You can check this at “Central Administration, Site Actions, Site Settings”.
The site specifications are at the top of the page. Here you will find the version number.

Backup

First the backup of the original site. The easiest way to do this is with stsadm.exe. This command line util will let you schedule your backup of SharePoint Services 3.0.

stsadm -o backup -filename “\\backupserver\share\sitename – %date:~-2%%date:~4,2%%date:~7,2%.dat -url http://sitename

This should give you a full backup of your SharePoint in a single file.
This file will get the name “sitename – YYMMDD.dat” where YY is the year, MM the month and DD the day of the backup.
This is very handy to put in a scheduled task and keep multiple backups of your site.
A disadvantage of this scheduled task is that you need the control the amount of backup files you create.
This can also be done with a simple batch file.

forfiles /d -7 /m *.dat /c “cmd /c del @file”

So with the backup behind us, now the main challenge.

Restore

As mentioned before it is VERY important to get the same version number on the target SharePoint Server.
Before you go further, make sure the versions are the same.

First we need to create a new web application. For now just take the servername as the name for the web application. For example http://newserver.

stsadm -o restore -filename “\\backupserver\share\sitename – 100322.dat -url http://newserver

The site is now on the new server, to make it accessible to a url of your choice, lets add the new URL to the SharePoint site.
To do this lets go over to “Central Administration, Operations, Alternative allocations for Access”
Choose at the top right for ( yellow drop-down menu ) SharePoint – 80. This way the Central Administration page will not  be changed so nothing terrible can happen to it.
Now click on “Add internal URL” and add the URL of your choice.
To make the new URL the standard, click on “Edit public URL”
Switch the standard URL with your chosen URL.

Now the only thing that’s left is the third party software to install.
Personally I use Smiling Goat Feed Reader for RSS feeds on SharePoint Services sites.

• If you are running an x86-based edition of Microsoft Windows Server 2003, use the following command line to remove Windows Internal Database from the computer:
  msiexec /x {CEB5780F-1A70-44A9-850F-DE6C4F6AA8FB} CALLERID=ocsetup.exe
• If you are running an x64-based edition of Windows Server 2003, use the following command line to remove Windows Internal Database from the computer:
  msiexec /x {BDD79957-5801-4A2D-B09E-852E7FA64D01} CALLERID=ocsetup.exe

Source : http://support.microsoft.com/kb/920277

Turns out the fix required adding one simple JavaScript call to a Google JavaScript API function. When adding Google Analytics tracking code to a site with a single name in the URL you need to call _setDomainName(“none”) prior to making the call to _trackPageView:

By default the Google Tracking Code snippet provided in the Google Analytics Profile Settings uses the “auto” domain name mode which expects to see a fully-qualified domain name (FQDN) composed of the domain name, followed by a period, followed by the domain extension (.com, .net, .biz, etc.). Setting the domain name to “none” disables the FQDN requirement and will record your pages in Google Analytics the same as a site with a FQDN.

I have deployed this fix with success to both a SharePoint 2007 Team Site and Publishing Portal site available only by a single name URL and port number. In both cases the site data was not showing up in Analytics until I added the call to set the domain name to “none”. It’s critical that you call _setDomainName before calling _trackPageView for this change to have any effect.

As with all changes to JavaScript tracking code it can take up to 24 hours before you see data start showing up in the Google Analytics dashboard reports, and changes only apply going forward so there’s no way to recover clicks from before you deployed the code change.

Here’s an example of the tracking code with the domain name set to “none”. Replace YOUR_WEB_PROPERTY_ID with the value assigned to your site profile by Google Analytics:

Source : http://mikeknowles.com/blog/2009/07/11/EnableGoogleAnalyticsPageTrackingInASingleNameIntranetSite.aspx