2007/05/16

[SPS2007]Eventlog - ProfileSynchronizationDuplicateSiteIDException

當我將 SPS 從 A Domain 移至 B Domain 時,然後直接將 SSP 還原後,就會在 Eventlog 中出現這些訊息

***********************************************************************************************************************************************************************************************************************************************************

事件類型: 錯誤

事件來源: Office SharePoint Server

事件類別目錄: 使用者設定檔

事件識別碼: 5555

日期: 2007/5/16

時間: 下午 04:00:02

使用者: N/A

電腦: SPSWEB

描述:

嘗試同步處理 Web 應用程式 4583e17b-0a47-4a5a-b88b-ce600c72c257、ContentDB 962095e4-64f2-4539-9812-c0ab73b7b098 時發生錯誤 例外狀況訊息為 發現重複的網站識別碼 040771d5-1dde-490a-a5c3-b83b2254a0f4(http://10.123.66.88)。可能因為在將某伺服器陣列的內容資料庫還原到其他伺服器陣列之前,未先移除原始資料庫並執行 stsadm -o preparetomove。如果這是原因,則可使用 stsadm -o preparetomove 命令搭配 -OldContentDB 命令列選項,以解決這個問題。

***********************************************************************************************************************************************************************************************************************************************************

事件類型: 錯誤

事件來源: Office SharePoint Server

事件類別目錄: Office Server 一般

事件識別碼: 7888

日期: 2007/5/16

時間: 下午 04:00:02

使用者: N/A

電腦: EPEWEBPROD03

描述:

已偵到到執行階段例外狀況。詳細資料如下,

訊息: 發現重複的網站識別碼 040771d5-1dde-490a-a5c3-b83b2254a0f4(http://10.123.66.88)。可能因為在將某伺服器陣列的內容資料庫還原到其他伺服器陣列之前,未先移除原始資料庫並執行 stsadm -o preparetomove。如果這是原因,則可使用 stsadm -o preparetomove 命令搭配 -OldContentDB 命令列選項,以解決這個問題。

技術詳細資料:

Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSiteIDException: 發現重複的網站識別碼 040771d5-1dde-490a-a5c3-b83b2254a0f4(http://10.123.66.88)。可能因為在將某伺服器陣列的內容資料庫還原到其他伺服器陣列之前,未先移除原始資料庫並執行 stsadm -o preparetomove。如果這是原因,則可使用 stsadm -o preparetomove 命令搭配 -OldContentDB 命令列選項,以解決這個問題。

at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSitesForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy)

at Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds()

at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSites(String strFirstChangeToken, SPChangeToken lastChangeToken)

at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContentDB()

at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

***********************************************************************************************************************************************************************************************************************************************************

以下是英文版的訊息

***********************************************************************************************************************************************************************************************************************************************************

A runtime exception was detected. Details follow. Message: A duplicate site ID e988d221-a48b-4ae8- ad91-6c6ca40548c3(https://my site url) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue. Techinal Details: Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSit eIDException: A duplicate site ID e988d221-a48b-4ae8- ad91-6c6ca40548c3(https://my site url) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue. at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSite sForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy) at Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds() at Microsoft.Office.Server.UserProfiles.SynchCollection`2.Add(T objAdd) at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSit es(String strFirstChangeToken, SPChangeToken lastChangeToken) at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContent DB() at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter( Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

***********************************************************************************************************************************************************************************************************************************************************

後來在這裡(http://www.ureader.com/message/33224010.aspx)找到了解決方式,我轉貼過來…

After extensive research of all the SharePoint databases I figured the table “sistesynch” in the sharedservices database is responsible for the errors caused by the hourly profile synchronizations service. I looked in the table and found out the database id‘s in this do not match with the database id’s from the config database of the SharePoint. Site ID’s seems to be ok in this table. This table may not have been updated when the content databases where detached and attached (could be a bug in SharePoint). After deleting the rows from this table the errors gone away and the table is re-populated back with correct sites and database id’s next time when the service ran (usually hourly). I also found that you can actually run this stsadm command which also does the same thing mentioned above (deleting rows from site sync table) and is probably a better way since this is a command from MS. Run the following command . stsadm -o sync -DeleteOldDatabases 0 The results of this command will be a list of old database id’s that have been cleaned up and the sitesync table will be emptied. Note: Since there is no documentation on any of these commands .All the above fixes are based on my personal investigation so please makes sure this works for you in your environments before you run. Backup the sharedservices and configuration databases just in case if this don’t work for you. It’s been couple of days since we ran this in our environment and we haven’t seen any issues and all the event log errors gone away. Good Luck. Vikram Garlapati

 

在下這個指令(stsadm -o sync -DeleteOldDatabases 0)之前,請先備份 SSP DB 及 Config DB 哦~

1 則留言:

Biby Cletus 提到...

Cool blog, i just randomly surfed in, but it sure was worth my time, will be back

Deep Regards from the other side of the Moon

Biby Cletus