System policies must have Full Control.

If you encounter event log errors like:
Application synchronization failed for Microsoft.Office.Excel.Server.ExcelServerSharedWebService.
Reason: System policies must have Full Control.
Then browse to Central Admin, Application Management, Policy for web application and uncheck the propertie 'operates as System account' for each account listed. See if that solves your problem.

If it is still happening:

with an event ID 6483 with error 'System policies must have full control'Resolved it by going to Central Administration --> Application Management --> Application Security --> Policy for Web Application, changed permissions for the Search user to Full Control

No more errors in the Event Viewer!

Still happening?

Take a look at the event viewer for your SQL Server machine and see which account is authenticating at the moment in which you are getting these errors. Then ensure that this account is infact listed in the System Policy. Don't forget to check EVERY Web application.


Hopes this helps get you going in the right direction!

Jason

Seems that Microsoft forgot to add a link to "Save site as Template" for Publishing sites in MOSS 2007, and it appears the problem is not addressed in SP1, either. Makes me wonder if the lack-of-link was intentional.
Nevertheless, in order to save any Publishing Site as a template, you must manually append the site template address "/_layouts/savetmpl.aspx" to the site URL. So for instance, if your site is http://intranet/offices/sandiego, you can save the template by manually browsing to http://intranet/offices/sandiego/_layouts/savetmpl.aspx

Debugging Timer Jobs in MOSS 2007

In the Execute method of the job (the method you override to write your job execution logic) place the following code (Thanks Joe!): System.Diagnostics.Debugger.Break();
Assuming you have already added your solution to the site and deployed it using Central Admin, simply uninstall the job assembly from the GAC and add the newly built one back in again
What I did here is to stop the OWSTIMER service (to prevent my job from running a million times while I do these steps)
Remove and copy the job assembly to the GAC
Map the GAC folder so you can actually see the files to place the .pdb file in for debugging using subst Z C:\Windows\Assembly (this command run from the command prompt maps the file structure of the windows assembly folder to the z:\ drive so you can copy your assembly into the Z:\GAC_MSIL\MyAssembly\10000___StrongNameKey\ folder
Reset IIS and restart the OWSTIMER service
Quickly attach your VS.NET debugger to the OWSTIMER process and wait for your job to kick off inside OWSTIMER. The debugger will break on the System.Diagnostics.Debugger.Break(); allowing you to step through your job

UnauthorizedAccessException and SPSecurity.RunWithElevatedPrivileges to the rescue

This issue occured when a user with read-only access would access a page with a web part that did some Excel parsing.

The code would throw an UnauthorizedAccessException error when attempting to instantiate the Microsoft.Office.Interop.Excel.Application() COM object, . To get around this in MOSS we can elevate the permissions to that of the SharePoint system account by wrapping that code as follows:

SPSecurity.RunWithElevatedPrivileges(
delegate()
{
// Put the code that needs to run with elevated permissions here
BashExcelSpreadsheet();
}
);

We love you SPSecurity

Office application does not quit after automation from Visual Studio .NET client

This is the result of a known Microsoft issue -- if you directly reference any members of the Microsoft.Office.Interop.Excel COM objects, the objects will not terminate in spite of garbage collection and as a result, the EXCEL.EXE process will not terminate.

The workaround is to instantiate new objects as references to the same members, then forcibly release the COM object using System.Runtime.InteropServices.Marshal.ReleaseComObject, the objects will then terminate correctly by garbage collection, and the process now terminates as expected.

Here is the Microsoft kb identifying this issue and the workaround:

Office application does not quit after automation from Visual Studio .NET client
http://support.microsoft.com/default.aspx?scid=kb;en-us;317109

Workaround for Installing Extensions for VS2005 on x64

1. Download Visual Studio 2005 Extensions, Version 1.1 for Windows Server 2003 Enterprise Edition 64-bit
A. http://www.microsoft.com/downloads/details.aspx?familyid=3E1DCCCD-1CCA-433A-BB4D-97B96BF7AB63&displaylang=en
2. Save the install file: C:\Temp\VSeWSSv11.exe

3. Extract the MSI using this command: C:\Temp\> VSeWSSv11.exe /Extract

4. Output MSI file: C:\Temp\VSeWSSv11.msi

5. Downloaded Windows® Server 2003 SP1 Platform SDK
A. Installed just Orca

6. Edit MSI using Orca
A. In the Tables column
1. Select: InstallExecuteSequence
2. In the right pane, drop these two rows.
a. X64System
b. WSSNotInstalled
3. Select: InstallUISequence
4. In the right pane, drop these two rows.
a. X64System
b. WSSNotInstalled
B. Save MSI

7. Run edited MSI and follow the prompts.

The reason for this blog

Recently went for lunch with a few other professionals, and after an intense discussion, I was scathingly REBUKED and DEVOURED by another developer for selfishly not giving back to the technical community. (just kidding Hemant ;)) Especially, after I have used many coders blogs to help me solve some of my own problems. So, as a nod to my fellow passionate coder, and as an acknowledgement of my moral obligation to the coding community, I have officially created my first technical blog.

For now, if I run into problems I'll just be stating the issue and pasting in links to what helped solve it.

Thanks Hemant!

The project type is not supported by this installation

Kept randomally getting this error when me and another developer were working on the same project. We narrowed it down to the other developer checking in the .csproj file from his machine.

The following steps temporarily solved it until the other developer overwrote the .csproj file.

1. Right click on the project and choose “Edit …” to open the project file as XML.
2. Delete ProjectTypeGuids node.
3. Save and close the XML file.
4. Right click on the project and reload it.

While this solved the problem until the next check-in of the .csproj, on further investigation it turned out one of the machines didn't have Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions installed. After installing this, the problem was really solved.