spsバックアップデータ復旧中に発生した問題
4756 ワード
portalのデータベースをバックアップした後、会社のドメインコントローラを再インストールしたが、ドメイン名は変更されずspsのデータベースを復元した後に問題が発生し、ドメイン管理者のアカウントを除いてspsにログインできなかった.ユーザーはad統合検証を正しく通過できますが、sps自体の権限チェック時にsiteデータベースのuserinfoテーブルを開くことができず、tp_を発見しました.loginフィールドに格納されているドメイン名とユーザー名は正しいです.portalのユーザー管理機能では、すべてのユーザーが変更できないか、「このユーザーはすでに存在します」というプロンプトを追加できます.現在の新しいドメインに新しいユーザーを追加し、ユーザーは正常に使用できます.portal上のユーザー管理で元のユーザーを削除し、同じユーザーを追加すると、ユーザーが存在する必要があり、正しく追加できないことをプロンプトします.再データベースuserinfoテーブルでは、元のユーザーレコードを削除し、同じユーザーを追加すると、増加したユーザーが正常に使用できます.問題はuserinfoのデータとadのユーザー情報の同期にあるようです.tp_loginフィールドの内容は同じで、ユーザー情報を表す別のフィールドがあるに違いありません.userinfoをチェックするフィールドごとにtp_を発見します.システムIDは最も疑わしいが、データ型はbinaryタイプであり、このフィールドがad中のユーザのIDフィールドに対応していると推定される.問題が見つかりましたが、どうやってtpを修正するか分かりません.SystemID、インターネット検索でやっとブログを見つけました.(dustinに感謝)http://www.sharepointblogs.com/dustin/archive/2004/09/10/756.aspxの内容は以下の通りです.
Fix those SIDs
Thanks to my good friend Jeremy McMahan for finding the suser_sid() function for me -- My original solution was a crazy mix of linked servers and the Directory Services provider for OLEDB!
Ever migrate your SharePoint site to a totally new environment and discover that your efforts to re-create your Active Directory were all for nothing, since all the users got new SIDs? Symptoms like: The administrator of the server can log in, but nobody else can, even though you're SURE their usernames and passwords are right.
Here's a script that'll fix that up for you in a jif. Open Query Analyzer and run it against the content database for your site, and it will update all the SIDs for your users to the SID that is reported for that user by Active Directory.
Big fat disclaimer: Microsoft does NOT support ANY modifications to your SharePoint databases. That's not to say they won't support your SharePoint site, but if this operation breaks your server, Microsoft won't help you. I'm not responsible for the results, either, while we're on the subject of passing the buck. BACK UP YOUR DATABASE.
Okay, now that we've gotten that mumbo-jumbo out of the way, here's the code.
.coloredcode .cmt { color: #0f0; }
.coloredcode .cmtg { color: #666; }
.coloredcode .st { color: #f00; }
.coloredcode .kwdt { color: #666; }
.coloredcode .kwd { color: #00f; }
.coloredcode .attr { color: #f00; }
.coloredcode .attrv { color: #00f; }
.coloredcode .ec { color: #00f; }
.coloredcode .tag { color: #800000; }
.coloredcode .dir { color: #000; background: #FEFF22; }
.coloredcode .sel { color: #800000; }
.coloredcode .val { color: #00f; }
.coloredcode .unit { color: #800000; }
.coloredcode .sqlcmt { color: #008080; }
.coloredcode .sqlkwd { color: #00f; }
.coloredcode .sqlkwd2 { color: #f0f; }
.coloredcode .sqlkwd3 { color: #999; }
.coloredcode .sqlkwd4 { color: #800000; }
.coloredcode .num { color: #00f; }
.coloredcode .sqlst { color: #008000;}
Fix those SIDs
Thanks to my good friend Jeremy McMahan for finding the suser_sid() function for me -- My original solution was a crazy mix of linked servers and the Directory Services provider for OLEDB!
Ever migrate your SharePoint site to a totally new environment and discover that your efforts to re-create your Active Directory were all for nothing, since all the users got new SIDs? Symptoms like: The administrator of the server can log in, but nobody else can, even though you're SURE their usernames and passwords are right.
Here's a script that'll fix that up for you in a jif. Open Query Analyzer and run it against the content database for your site, and it will update all the SIDs for your users to the SID that is reported for that user by Active Directory.
Big fat disclaimer: Microsoft does NOT support ANY modifications to your SharePoint databases. That's not to say they won't support your SharePoint site, but if this operation breaks your server, Microsoft won't help you. I'm not responsible for the results, either, while we're on the subject of passing the buck. BACK UP YOUR DATABASE.
Okay, now that we've gotten that mumbo-jumbo out of the way, here's the code.
.coloredcode .cmt { color: #0f0; }
.coloredcode .cmtg { color: #666; }
.coloredcode .st { color: #f00; }
.coloredcode .kwdt { color: #666; }
.coloredcode .kwd { color: #00f; }
.coloredcode .attr { color: #f00; }
.coloredcode .attrv { color: #00f; }
.coloredcode .ec { color: #00f; }
.coloredcode .tag { color: #800000; }
.coloredcode .dir { color: #000; background: #FEFF22; }
.coloredcode .sel { color: #800000; }
.coloredcode .val { color: #00f; }
.coloredcode .unit { color: #800000; }
.coloredcode .sqlcmt { color: #008080; }
.coloredcode .sqlkwd { color: #00f; }
.coloredcode .sqlkwd2 { color: #f0f; }
.coloredcode .sqlkwd3 { color: #999; }
.coloredcode .sqlkwd4 { color: #800000; }
.coloredcode .num { color: #00f; }
.coloredcode .sqlst { color: #008000;}
DECLARE @login varchar(40), @systemid varbinary(128)
DECLARE curUsers CURSOR LOCAL FOR
SELECT tp_login, tp_systemid FROM userinfo where tp_deleted = 0
OPEN curUsers
FETCH NEXT FROM curUsers INTO @login, @systemid
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT 'Resetting user ' + @login + ' to new SID '
PRINT suser_sid(@login)
UPDATE UserInfo
SET tp_systemid = suser_sid(tp_login) WHERE CURRENT OF curUsers
FETCH NEXT FROM curUsers INTO @login, @systemid
END
CLOSE curUsers
DEALLOCATE curUsers
GO
, userinfo
,