views:

585

answers:

4

We have some solution that we built against a MOSS farm one of which includes a timer job. This job has been working just fine for months. Recently the administrator enlisted another server into the farm, and our timer job automatically started running on this new machine. As soon as this switch happened our timer job started yielding the error below (found this in the SP logs).

At first I thought it was a rights issue, but the timer service on the machine where it worked before and the new one are running under the same domain account. It seems to be failing while looping the site list in a site collection, on just one of the sites/webs (code snippet below). I know that this domain account has access to this because it works on the other box under same account. Does anyone have any ideas on why this cryptic error is occurring? Or if any special procedure needs to be done on this new machine to ensure it has proper ACL's for all databases in the MOSS farm?

Code:

public static void Main(string[] args)
{
    SPSecurity.RunWithElevatedPrivileges(delegate() { setInputParameters(); }); 
}

private static void setInputParameters()
{
    SPFarm farm = SPFarm.Local;
    SPWebService service = farm.Services.GetValue<SPWebService>("");
    foreach (SPWebApplication webApp in service.WebApplications) 
    { 
        foreach (SPSite siteCollection in webApp.Sites) 
        {   
            using(siteCollection)
            {
                siteCollection.CatchAccessDeniedException = false; 

                try 
                {
/* Here is the line that it fails on */
                     foreach (SPWeb web in siteCollection.AllWebs)

Exception:

The Execute method of job definition LMSDataImport (ID 4b37b285-ef8a-407c-8652-391639449790) threw an exception. 
More information is included below.  
The type initializer for 'Microsoft.SharePoint.Administration.SPPersistedObjectCollection`1' threw an exception.

Exception stack trace:    

at Microsoft.SharePoint.Administration.SPPersistedObjectCollection`1.get_BackingList()     
at Microsoft.SharePoint.Administration.SPPersistedObjectCollection`1.GetEnumerator()     
at Microsoft.SharePoint.Administration.SPAlternateUrlCollectionManager.LookupAlternateUrl(Uri canonicalRequestUri)     
at Microsoft.SharePoint.Administration.SPAlternateUrl.LookupCore(Uri uri, SPFarm farm)     
at Microsoft.SharePoint.Administration.SPWebApplication.Lookup(SPFarm farm, Uri requestUri, Boolean fallbackToHttpContext, SPAlternateUrl& alternateUrl, SiteMapInfo& hostHeaderSiteInfo, Boolean& lookupRequiredContext)     
at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, SPUserToken userToken)     
at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite)     
at Microsoft.SharePoint.Administration.SPSiteCollection.get_Item(String strSiteName)     
at Microsoft.SharePoint.Administration.SPSiteCollection.get_Item(Int32 index)     
at Microsoft.SharePoint.Administration.SPSiteCollection.ItemAtIndex(Int32 iIndex)     
at Microsoft.SharePoint.SPBaseCollection.SPEnumerator.System.Collections.IEnumerator.get_Current()     
at LMSDataImporter.setInputParameters()     
at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state)     
at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2()     
at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)     
at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)     
at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)     
at Axian.AxianCalendar.LMSDataImporter.Main(String[] args)     
at Microsoft.SharePoint.Administration.SPTimerJobInvoke.Invoke(TimerJobExecuteData& data, Int32& result)
+4  A: 

Check the DLLs for SharePoint, do all exists and all are the same version? Try putting a catch for the TypeInitializationException, and see what is wrong inside that exception.

s_hewitt
+1 They (the admins) said this new server is a clone so it should have the same dll versions, but i'll definitely check that to.
James
Did the DLLs check out? What did the inner exception say? I'm definitely no expert in SharePoint, but looking over your stack trace again, maybe nothing is even coming up in the siteColletion. Can you put break points in there and see that you're getting the correct (populated) Farm/WebApp/Site?
s_hewitt
The dll's are the same, and I have no way of doing any remote debugging without a lot of hassle. I just hope there is a simpler answer! SharePoint can be such a pain sometimes...
James
The remote debugging might be worth the hassle. That exception can sometimes tell you which assembly doesn't have access or couldn't be loaded, which would be the simple answer.
s_hewitt
+3  A: 

It's not a solution, but as a workaround in the interim, I think my suggestion to one of your other questions here:

http://stackoverflow.com/questions/714848/how-do-you-instruct-a-sharepoint-farm-to-run-a-timer-job-on-a-specific-server

will keep you running while you investigate further.

vinny
+1  A: 

A Type init exception just means an exception occurred in the .ctor of the class (as you probably know). The real exception should be in the InnerException property - can you get your hands on this? Likely it's stemming from the database alright, from Microsoft.SharePoint.Administration.SPPersistedChildCollection InitializeFromDatabse method.

Can you look into the sharepoint logs (on that errant server) for information about the database error, it will be there. Reading logs are a pain, but not if you install the ULS Log Viewer feature from http://www.codeplex.com/features

Since the stacktrace has SPAlternateUrl tinkering furhter up the stack, perhaps your zones are misconfigured (and do not include a mapping for this new server's machine name) - granted, it shouldn't fail this bad, but what can you do.

You can filter the ULS logs by source.

-Oisin

x0n
Where do you look at how the zones are configured?
James
+2  A: 

Check the NLB (Network Load Balancing) configuration. Most of the time SharePoint and applications integrated to it fails when NLB changes its state. There is a patch available to solve this problem. Just a suggestion. Not sure if this is the reason. But I have faced a similar issue and the root cause was an NLB bug

Faiz