Just noticed that Joel has released a list of the top 17 support calls for the latest version of SharePoint products – well worth a look and could be an effective "List of things to check when reviewing a Client’s site for the first time" type of list. Some timely reminders in there of basic things that can trip up a SharePoint deployment, especially around permissions. What’s the first one at the top of the list?
Oops – different speech. The point is, make sure your backup plan is running and can be restored before you start making wholesale changes to the environments or investing months of development time into a custom SharePoint app.
- Do you know your backup frequency and last successful backup? You would be surprised how many customers call support with catastrophic failure and have no backup to recover with.
- Are you monitoring all your disks? If you did a simple/basic all in one install is it all on one drive that you are watching? Disk space available on WFE and SQL, common support issue is Basic install running out of drive space for SQL
- When you enumerate your site collections in your farm are the URLs correct? Are you using localhost or servernames? If you are are you using alternate access mappings. AAM not set or misconfigured is common. This is a top support issue and one to watch out for. If you are confused about these check out the SharePoint blog which has 3 posts on what every administrator needs to know about alternate access mappings. http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx
- Changing permissions behind the back of SharePoint on the installation directories, home directories, where the app pool doesn’t have appropriate permissions can and will break the farm silently (browse/read access often will look good) without you realizing it – Permissions check, do all of the managed directories owned by WSS/MOSS have default or expected permissions configured
- Ensure that each content database in the manage web application manage databases has a server assigned for indexing – Search, are content databases assigned to an indexer (WSS Search top support issue)
- Kerberos more secure right? It is more complex, no question, but it can be worth it. If Kerberos is enabled does customer have an SPN configured, http://support.microsoft.com/kb/832769
- One of the more common problems I’ve seen… Status of service accounts, are any service account passwords expired or otherwise broken, http://support.microsoft.com/kb/934838
- If large file support is enable are the myriad of configuration settings to make this work configured, http://support.microsoft.com/?id=925083
- Scan the SharePoint farm and report if any of our capacity limits are exceeded, http://technet2.microsoft.com/WindowsServer/WSS/en/library/2aa12954-2ea7-475c-9dce-663f543820811033.mspx
- SMTP relay or anonymous relay – Ensure outgoing email server settings set correctly and can we relay through specified SMTP server (you can verify by using telnet to the SMTP server and if we get 220 then it’s successful)
- Is Client Integration turned on even though we don’t support it with Forms Auth (warning/caution)
- SQL and OS versions – Is SharePoint deployed on a supported OS. Common problem is for MOSS customer dose not have SQL 2005 SP 2 installed and Search breaks, WSS 3.0/MOSS 2007 is not supported on Windows 2000/NT 4.0
- Does web server administrator have admin permissions on SQL server to run stsadm? Stsadm runs in context of logged in user and must have service account level permissions on SQL to run commands. Also ensure app pool account when switching has appropriate access.
- Remember, remember to install prerequisite service packs and run prescan as successful before upgrade.
- Ensure that a domain account is used to connect to the databases prior to upgrade
- Check if /3GB switch is enabled in boot.ini, WSS does not support /3GB switch http://support.microsoft.com/kb/933560