webtamer

There has been instances where one is unable to examine sites under IIS's ISM on a Web Front-end Server without first performing IISRESET (various switches); if you have experienced this take a look as the following KB Article: http://support.microsoft.com/?id=946517

These are links to KB articles indicating some unsupported practices in SharePoint and at random. 

 Restoration of the configuration database is not supported in SharePoint Server 2007 and in Windows SharePoint Services 3.0
http://support.microsoft.com/?id=948725

The Windows Server 2003 /3GB switch is not supported in Windows SharePoint Services 2.0 or in later versions or in SharePoint Portal Server 2003 SP2 or in later versions
http://support.microsoft.com/kb/933560

Supported and unsupported scenarios for working with custom site definitions and custom area definitions in Windows SharePoint Services, in SharePoint Portal Server 2003, and in Office SharePoint Server 2007
http://support.microsoft.com/kb/898631

One of the common poor design decisions I have seen in the field is using a single Web Application to host everything (SSP Admin, My Site & any other team sites); to me this is like putting all your eggs in one basket; instead consider creating multiple web applications one for each of the high level functional segments of your farm; so one to host SSP Admin another to host My Site and maybe one or more to host your actual team sites and organization content. also consider creating multiple content databases per web application to host the various site collections you might provision in the context of each web application so that you drive a bit more fault isolation and resilience into your design. 

So here is what happens; when you create a web application in MOSS 2007 you also create an associated content database (Example: WSS_Content) then you will need to create at least one site collection in order to be able to start browsing the web application you had created. so far so good.

Now over time your customer, team mates, etc.. will ask you to create more as some might ask for a site with a calendar and a document library and others might ask for a performance and business intelligence site; over time each new site collection you create gets stored in that original content database so in a way you end up with a possible single point of failure content database; instead why not create additional content databases and split each of these site collections across multiple databases? doing so establishes a bit more fault isolation into your design and gives you the flexibility of more granular backup and restore abilities.

More to come on this topic..

It is strongly recommended to first attempt the following procedure in a development environment (non production) prior to any production environments>
How to split sites.

1. Make sure you have this WSS hotfix installed: http://support.microsoft.com/kb/939188/ (Note: This fix is also included in WSS3.0/MOSS SP1)
2. Create a new, empty content database in your OLD web application. Let’s call it MySitesContentDB.
3. Run the following command to enumerate all the site collections in your default content database:
stsadm –o enumsites –url http://oldservername –databasename OldMySitesContentDB > MySites.xml
4. Open the MySites.xml file that is created in Notepad or another text editor. You’ll see a <Site> entry for every site in the content database. Remove any entries that refer to sites that are not MySites. You should be left with a list of all of your MySites. Save the file.
5. Run the following command to move all of your MySites from the default content database to the new content database:
stsadm –o mergecontentdbs –url http://oldservername –sourcedatabasename OldMySitesContentDB -destinationdatabasename MySitesContentDB –operation 3 –filename MySites.xml
6. Create a NEW web application to host your MySites.
7. Remove MySitesContentDB from the list of content databases for the OLD web application.
8. Add MySitesContentDB to the list of content databases for the NEW web application.
9. Update the SSP so that it uses the NEW web application as the MySite web application.
10. Test and make sure everything looks good.

One of the most common security mistakes when building your MOSS farm is using the same service account for everything (Farm Admin, SSP, Application Pools, Search etc...).

The better practice is to create a separate service accounts for each segment in your SharePoint farm; so if you have already used one service account across the board; consider changing from a single service account to multiple:

What service accounts do I need and how do I change a service account in MOSS 2007? one might ask; the answer is simply posted on the following KB Articles:

Plan for administrative and service accounts (Office SharePoint Server)
http://technet.microsoft.com/en-us/library/cc263445.aspx

How to change service accounts and service account passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0.
http://support.microsoft.com/kb/934838