The first point to check is if you are observing this error on the DC.

1. For a DC there are additional steps that need to be taken for the Web app to work successfully.
2. Executed the following command in SharePoint Powershell 
• $e = Get-SPServiceApplication | where {$_.TypeName.Equals("Word Viewing Service Application")}
• $e.WordServerIsSandboxed = $false
• $e.WordServerIsSandboxed
• Browsed to server's “c:\windows\system32\inetsrv\config\applicationHost.config” and added the following line below in the end of the dynamicTypes.
• <add mimeType="application/zip" enabled="false" />
3. Do an IIS reset and you are good to go.

note: You may experience similar issues with PowerPoint too. Here are additional PowerShell command to resolve

Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedViewing $false
Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedEditing $false

You will need to enter "Y" as answer for each cmd

It is best to take a two way network capture(between WFE and desktop) and analyze the same.  make sure you do a  ipconfig /flushdns before start of capture.

We observed that some third party network appliances are blocking people picker requests as SQL injections and causing People Picker to fail.

Will add more details later.

1. The first and foremost is of course the Application log in Windows Event Viewer.

2. Next check for the ULS log; this is located under the ……/12/logs folder. It is not always that you get a horde of information here, but then there are time when the information in the log points you to the resolution. You can increase/decrease the level of reporting by changing setting in Central Admin | Operations | Logging and reporting.

3. Another important log is the upgrade.log located under the ……/12/logs folder. This file is very useful when it comes to troubleshooting issue related to upgrades (including patch updates, Service Packs.) Please note here that the message you will normally see on un-successful completion of PSConfig is “Configuration of SharePoint Products and Technologies failed.  Configuration must be performed before you use SharePoint Products and Technologies.  For further details, see the diagnostic log located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\PSCDiagnostics_x_xx_xxxx_xx_xx_xx_xxx_xxxxxxxxxx.log and the application event log.” However this log does not have a lot of information.

4. A very common error is “An unexpected error has occurred”. Of course this is very generic and does not give any clues to the actual error. To top it you may also not see any errors written to the log files or trace logs.

Changing the entry in web.config as follows can throw some light on this error.

<SafeMode MaxControls=“200“ CallStack=“false“… to <SafeMode MaxControls=“200“ CallStack=“true“… and the entry <customErrors mode=“Off“/> (by default this is on) will give a standard AP.Net  error page with the stack trace.

5. Another common error that I have observed is “The schema version (X.X.XXX.X) of the database spscontentdb on SQLMOSSServer(name of the sql server) is not consistent with the expected database schema version (Y.Y.YYY.Y) on MOSSserver(name).  Connections to this database from this server have been blocked to avoid data loss.  Upgrade the web front end or the content database to ensure that these versions match. ”

For every similar entry that you observe in the application log in Event Viewer, you can cross verify this by looking into the versions table of the respective DB. Of course we all know that directly modifying the database puts the SharePoint installation into an unsupported manner(https://support.microsoft.com/kb/841057/en-us). So what’s the alternative; use the command “psconfig -cmd upgrade -inplace b2b -wait –force” which will re-synchronize the schema versions. If you still observe errors check the upgrade log further.

1. Event Throttling Logs – These end up going to the Windows Event Log and can be viewed in the Event Viewer. They show Errors and Warnings.

1. Trace Logs – These show detailed line by line tracing information emitted during a web request or service execution. They end up being stored at a known location on the front-end server. Default Location: (System Drive):\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\

2. Audit Logs - They end up in the associated Content Database tables and can be viewed at Site Collection Level as well as Site Level using the web browser. WSS 3.0 and MOSS 2007 use different pages to show Audit Log Reports.

3. Usage Logs – They get stored locally on the front-end servers and get processed both locally and at farm level via SSP (this is based on the setup as I understand the results from the local processing are merged by SSP) and can be viewed at both the Site Level and Site Collection Level. Default Location: (System Drive):\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs

4. Search\Query Logs – These are saved in the associated SSP database but can be viewed at SSP level via the Web Browser and in MOSS at Site Collection Level by going to the settings page.

5. Information Management Logs – Stored in the associated Content Database and can be can be viewed at the Site Collection Level.

6. Content and Structure Logs – This option is only available after one enables the publication feature. This store is saved in the Content Database associated with the Site Collection and can be viewed at Site Collection level by going to the settings page.

7. IIS Logs are generally saved at (System Drive):\WINDOWS\system32\LogFiles

8. ULS Logs are located at (System Drive):\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs

There are two possible workarounds, the first of which is to disable Blog Cache(not a good workaround :-) ). This can affect performance of other file types.

The second option is to modify the web.config file. The entry <BlobCache location="C:\blob" path="\.(gif|jpg|png|css|js|flv)$" maxSize="200"  can be modified to remove the file extension type of “flv”. So basically we are telling SharePoint to disable Blob Caching for files with extension .flv

A fix is now available vide KB971620 - https://support.microsoft.com/kb/971620

note: Installation of this fix does not immediately change the license type. There is a background timer job that runs which normally takes about 20-30 minutes.

Note 1: We have also observed recently that in some scenarios entering the product key does not completely resolve licensing issues until and unless the PS Configuration wizard is run.

1. stsadm.exe -o enumallwebs -databasename <database name> [-databaseserver <database server name>]

Displays the IDs and site map status for all site collections and subsites in the content database.

More Details: https://technet.microsoft.com/en-us/library/dd793606.aspx

1. stsadm -o exportipfsadminobjects -filename <path to file>

   Description: This command can be used to export InfoPath Forms Services Admin Objects.  This command will create a CAB file containing all the deployed objects.

2. stsadm -o listqueryprocessoroptions -ssp <ssp name>

Description : Displays the current values of the SharePoint Search query processor settings.

More Details: https://technet.microsoft.com/en-us/library/dd789568.aspx

1. stsadm.exe -o preupgradecheck [ -rulefiles <rule files delimited by comma or semicolon> ] [ -listrulefiles ] [ -localonly ]

   Description : Runs rules that are intended to assist administrators in preparing for upgrade from Windows SharePoint Services 3.0 and related products to future version of SharePoint and Technology products.

    

   More Details: https://technet.microsoft.com/en-us/library/dd793605.aspx

Additional information :

• Service Pack 2 Overview : https://go.microsoft.com/fwlink/?LinkId=148374
• The full explanation of SP2 benefits - https://go.microsoft.com/fwlink/?LinkId=148551
• Description of Windows SharePoint Services 3.0 SP2 and of Windows SharePoint Services 3.0 Language Pack SP2 - https://support.microsoft.com/kb/953338
• Service Pack 2 for Windows SharePoint Services 3.0, x86 & x64 - https://www.microsoft.com/downloads/details.aspx?FamilyId=79BADA82-C13F-44C1-BDC1-D0447337051B&displaylang=en
• Description of 2007 Microsoft Office servers Service Pack 2 (SP2) and of 2007 Microsoft Office servers Language Pack Service Pack 2 (SP2) - https://support.microsoft.com/kb/953334
• Service Pack 2 for Office SharePoint Server 2007, x86 & x64 - https://www.microsoft.com/downloads/details.aspx?FamilyId=B7816D90-5FC6-4347-89B0-A80DEB27A082&displaylang=en
• Slipstream Builds For Windows SharePoint Services 3.0
  • Windows SharePoint Services 3.0 with SP2, x86 - https://www.microsoft.com/downloads/details.aspx?FamilyId=EF93E453-75F1-45DF-8C6F-4565E8549C2A&displaylang=en
  • Windows SharePoint Services 3.0 with SP2, x64 - https://www.microsoft.com/downloads/details.aspx?FamilyId=9FB41E51-CB03-4B47-B89A-396786492CBA&displaylang=en
• List of all 2007 Office system Service Pack 2 and Windows SharePoint Services 3.0 Service Pack 2 packages - https://support.microsoft.com/kb/968170

When a user opens a word document all embedded pictures/Graphics in the document  are replaced with the a blank box and a red "x" at the top left corner of the picture holder.

No error message is observed. However right clicking the blank box with the red "x" can display error messages like "Picture is corrupted", "The server application, source file, or item cannot be found", etc.

Cause and Resolution
----------------------------------

There are more than one reason for this :

Situation 1:

A document is opened from an Internet location, from a Web folder, or from any location that the Microsoft Windows redirector recognizes as being from the Internet security zone.

Situation 2:

User account created under Windows 2000 and later migrated to Windows 2003. User has a roaming profile. Word files are located on a File Share in a central location. When this user tries to open a word document stored on the central File share using Word 2003 SP2 on a machine running Windows XP SP2.

Inference
--------------

This issue may occur when either of the following conditions is true:

- The Content.mso folder does not exist.
- The Content.mso folder has insufficient permissions. These permissions prevent
users from writing to the folder.

Resolution:
---------------------

To resolve this issue, make sure that the Content.mso folder exists and that all users and processes have full permissions to the folder. By default, the
Content.mso folder is a hidden system folder that is located on the computer under C:\Documents and Settings\User name\Local Settings\Temporary Internet Files

Related KB - https://support.microsoft.com/Default.aspx?id=897693