If you get the following error:
ProtocolError occured trying to complete the request. The server returned a status code of : Forbidden and the status description is : "Forbidden"
Problem: The machine account or app pool identity is trying to access the feed and cannot.
Solution:

• Enbable anonymous access to the RSS feed. This may or may not be allowed in your environment.
• If you are using Kerberos...(i.e. have already configured for delegation)
  • Go to Central Admin
  • Application Management
  • In Application Security, click Authentication Providers
  • change to Negotiate (Kerberos)

Ensure that your app pool identity is configured for delegation. Heres a good article, http://blogs.msdn.com/markarend/archive/2006/10/03/RSS-Viewer-web-part-and-authenticated-feeds.aspx

Why backup and restore is not high availability. Pick a strategy

• Recovery Time Objective (RTO) - how long can the application be down
• Recovery Point Objective (RPO) - how much data can be lost

The lower the RTO and RPO the higher the cost and complexity of the solution. The key to meeting the organizations needs is to establish goals for each "region" of your application. You may offer different RTO/RPO agreements for:

• My sites
• Indexing services
• Departmental sites
• Blogs, Wikis, etc

Another important metric is how much data churn does your organization produce. This represents the results of all the CRUD operations that occur in a given period of time. This key will greatly impact your RPO policy. How do you measure churn? A typical day's worth of transaction logs will help you determine the size of one day's CRUD. You should separate your disaster recovery plan from your standard recovery SLA. This will make your plan cheaper and more achievable. In other words recovering from a typical hardware failure should adhere to your standard SLA, however, recovering from a major disaster may take more time. Where to start you plan: Recovery scenarios (plan each separately):

• Hardware failure
• Infrastructure Failure (network local/wide/ISP, power failure, etc)
• Disaster
• Application Availability (interop problems, patch/compatability problems)

The key is to know your environment, infrastructure, and political landscape. What disasters do you need to account for? Backup and Restore ○ MOSS/WSS native backup/restore - recommended for small environments (small is ~ < 5 servers and < 100GB) Note: this is the only out of box solution for the index. You may decide to separately your RTO agreement for the index. Keep in mind this is not a compete backup solution, you are still missing configs, IIS settings, customization to files, etc.

• SQL only Backup - covers data only, no front-end customizations, must be manually restored
• Third-Party Tools:
  • Disk Replication - replicates differences bit by bit
  • Backup & Restore - SQL and files backed up
  • Sync Solutions - moves content

Make sure that your vendors solution does not impact your MS support. A great backup and restore plan will not give you high availability. The best recovery plan will take the better part of a day for a terabyte or so of data and you will surely lose some config or customizations. Plan high availability (HA) as a separate concern. SQL Server Failover Clustering - offers high availability, but is not a disaster recovery option. However, your SAN will be the single point of failure. Database Mirroring - offers a warm standby You choose:

• High performance - synchronous
• High Availability (low RPO) - asynchronous

MOSS is not mirroring aware. You will need to point to failover machines or use some DNS aliasing, etc. To change the name in MOSS use the STSAMD command (stsadm –o renameserver). More at: http://technet2.microsoft.com/Office/en-us/library/80609398-b01d-4d0a-b429-040b74cae51c1033.mspx
I hope this information helps. Happy failing over.

It is very important to plan your URL strategy upfront. Often times organizations start out with a small SharePoint implementation and bind themselves to a poor URL. You often see examples like this: http://marketing - Even though you're starting off with one department; your site will soon grow and you'll have a lot of links to fix. http://moss2007 - I've seen people name their server and URL to indicate the product they are implementing. This naming convention adds no value in explaining the purpose of the site. Here are some good URLs: http://intranet.mycompany.com http://intranet.mycompany.com/marketing http://marketing.mycompany.com A good URL strategy will allow you to easily scale