January 2008 - Posts

• Web Application Timer Jobs not automatically created when restoring from SharePoint backups

  *** UPDATE ***  I was made aware of a fix in SP1 that should cover this issue. http://support.microsoft.com/kb/941422 SharePoint administrator beware!!! You must manually recreate your web applications (with the exact naming as compared to what was backed up) to ensure that all the timer jobs for each web application is created when restoring from a SharePoint backup. The problem seems to be the automatic SharePoint restore that restores the databases and web applications must not follow the same method as if you were to do it manually because the automated restore does not create the necessary timer jobs for any web application restored. This includes immediate alerts, so if you have done a restore and you are wondering what has happened to your alert emails and your assigned-to emails it is because the restore didn't do a proper job. Of course the recommendation for getting the timer jobs created and associated with the web application is to manually create the web applications BEFORE you restore. The problem is you might not realize there is a problem until after a couple weeks / months after your restore. Now you have to delete the web applications, create them manually, and restore from the last full backup. Here is the Microsoft KB article that discusses the issue. http://support.microsoft.com/kb/942989 Here is the link to my work around and fix for the issue that is less intrusive than running a complete restore of your farm. http://www.sharepointblogs.com/llowevad/archive/2008/02/18/workaround-for-creating-timer-jobs-after-a-restore-in-sharepoint.aspx   Posted Jan 25 2008, 03:18 PM by dwollerman with 11 comment(s) Filed under: MOSS, SharePoint, errors, restore, KB

• Moving to a new database server (or instance)

  Updated on 1/28/2008 to include link to post related to web application timer jobs and SharePoint restore.  There comes a time when SharePoint databases will have to be moved to another database server. The problem is that it is not that easy to just move the databases to a new database server and have everything work. In SharePoint 2003, it was realatively simple to move all the databases, but in 2007 there is alot more involved with communication between the databases making it a more complicated scenario.Outlined below are the steps taken to move a SharePoint farm to a new database server. Perform a farm level backup of the current farm using the SharePoint backup utility in Central Administration. Make sure the backup gets saved to an accesible location either on this server or on the network. Run the SharePoint Products and Technologies Configuration Wizard to disconnect the server from the configuration database. If there is only one server in farm, then all you have to do is that server. If there are multiple servers in the farm, make sure the server running central administration is the last server disconnected from the farm. I don't believe this is a requirement, but I would recommended it anyway. Once all the servers have been removed from the farm. Run the SharePoint Products and Technologies Configuration Wizard on the server to host the central administration site first to create a new SharePoint farm. Once Server is configured, run the configuration wizard on the remaining servers adding them to the new SharePoint farm. Start both the Office SharePoint Services Search and the Windows SharePoint Services Search services *** UPDATE *** Read the post about web application timer jobs before moving to step 6 VERY IMPORTANT *** UPDATE *** Restore the backup made in step 1 using the SharePoint restore utility in Central Administration. You will have to supply the file path to the files that were backed up There are 4 steps to restoring from the backup. Step 1 is to locate the backup set that was ran in Step 1 Step 2 is selecting a backup to restore from the location specified in the previous step Step 3 is selecting a component of the backtup to restore... in this case you want to restore at the farm level Step 4 is to select the restore options. In this step you want to select new configuration for the type of resture and besure to go through all the databases, web applicatons, and SSP information to specifiy the new database server name and database file locations for each item. Double check everything before hitting ok. Finally after all selections are made and the restore process is kicked off, you see a summary of the restore in progress. Once restore is complete the databases should be in their new location and the SSP should be back up and running. To finish the move, you must reconfigure the farm using central administration. Then kick off a full crawl to repopulate the content index.   Posted Jan 02 2008, 02:42 PM by dwollerman with 8 comment(s) Filed under: Configuration, MOSS, SharePoint, sql, backup, restore, Moving Databases