我们有一些针对MOSS场构建的解决方案,其中包括计时器作业。这项工作已经好几个月了。最近,管理员将另一台服务器登入了服务器场,我们的计时器作业自动开始在这台新机器上运行。一旦发生这种切换,我们的计时器作业就开始产生下面的错误(在SP日志中找到它)。
起初我认为这是一个权利问题,但是之前运行的计算机上的计时器服务和新计算机服务都在同一个域帐户下运行。在网站集中的网站列表中,只在其中一个网站/网站(下面的代码段)上循环似乎失败了。我知道此域帐户可以访问此帐户,因为它适用于同一帐户下的其他框。有没有人对这个神秘错误发生的原因有任何想法?或者,如果需要在这台新机器上执行任何特殊程序,以确保它对MOSS服务器场中的所有数据库都有正确的ACL?
代码:
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)
例外:
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)
答案 0 :(得分:4)
检查SharePoint的DLL,是否存在并且所有版本都相同?尝试为TypeInitializationException设置一个catch,并查看该异常中的错误。
答案 1 :(得分:3)
这不是一个解决方案,但作为过渡期的解决方法,我认为我对你的其他一个问题提出了建议:
How do you instruct a SharePoint Farm to run a Timer Job on a specific server?
会在你进一步调查的同时让你继续跑步。
答案 2 :(得分:2)
检查NLB(网络负载平衡)配置。当NLB更改其状态时,大多数时间SharePoint和应用程序集成到它都会失败。有一个补丁可以解决这个问题。只是一个建议。不确定这是不是这个原因。但我遇到了类似的问题,根本原因是NLB错误
答案 3 :(得分:1)
类型init异常只是意味着类的.ctor中发生异常(您可能知道)。真正的异常应该在InnerException属性中 - 你可以得到这个吗?可能它源自数据库好,来自Microsoft.SharePoint.Administration.SPPersistedChildCollection InitializeFromDatabse方法。
您是否可以查看sharepoint日志(在该错误服务器上)以获取有关数据库错误的信息,将存在。读取日志很麻烦,但是如果您从http://www.codeplex.com/features
安装ULS日志查看器功能则不会由于堆栈跟踪有SPAlternateUrl修补堆栈,可能你的区域配置错误(并且不包括这个新服务器的机器名称的映射) - 授予,它不应该失败,但你能做什么。
您可以按来源过滤ULS日志。
-Oisin