初コメントですm(_ _)m

ありがとうございます！
ADアカウントを削除してもサイトに残り続けるのが、若干、気持ち悪かったのですが、今、すっきりしました
毎回、楽しく購読しておりますので、次回の記事も楽しみにしてます！

taku さん、コメントをありがとうございます! ブログは相手が見えない状態で書くものですから、直接、こうした反応を頂けると素直に嬉しいです。今後とも引き続きよろしくお願いいたします。

いつも拝見しております。
日本語にてこのように詳細に解説をして下さるサイトは
大変ありがたく感じております。

UserInfoテーブルに関してふとした疑問があるのですが、
私も動作確認を色々やってみましたが、UserInfoのレコード
そのものが削除されることは無いのでしょうか。
（動作から行くと削除済みフラグONとなるだけのような、、、

こういった場合、あるユーザー向けに作成したコンテンツを
別のユーザーさんに画像等を差し替えて売りたい！なんて
場合に、当初のユーザー会社のプロファイルとかが残存している･･･
なんて事になってしまうような気が致します。
それって個人情報保護上大変危険な気がするのですが、、、
そもそも上記のようなコンテンツの再利用自体認められていないのでしょうか。

ご意見いただけますと幸いです。
今後も随時拝読させていただきます！

onsatuさん
いつも閲覧いただいているようで、ありがとうございます!

念のためいろいろと調べてみたのですが、UserInfo のレコードそのものが削除されることはないようです。たとえば AllUserData など見てみるとユーザーにひもづいた形でアイテムなどの情報が格納されています。となると誰かが退職した場合に、その方が残していったアイテムがあるわけでして、これは会社の資産となりうる情報ですからこちらは削除するわけにはいきません。で、ユーザー情報の方だけ削除してしまうと拠り所をもたないアイテムとなってしまい都合が悪い、ということだと思います。そう考えれば、これは仕様でしょう。

さて、気にされているコンテンツの再利用のことですが、通常はサイトテンプレートもしくはサイト定義の形で提供することになるのではないかと思います。そうすれば、ユーザー情報は含まれません。マイクロソフトさんの方でも、カスタムで作成してある「サイト管理テンプレート」というものを提供されています。詳細はURLをご参照ください。http://www.microsoft.com/japan/technet/windowsserver/sharepoint/wssapps/templates/default.mspx
こういった方法がよいと思われますが、いかがでしょうか。

お返事ありがとうございます！

削除されることはないのですね、、、
となると

・既存ユーザー向けWSS_Content系をバックアップ
・新規ユーザー向けMOSSを構成
・Webアプリ作成
・コンテンツデータベースをバックアップから復元したものに入れ替え
・SSP作成
・完成

というお手軽（手抜き？）構成を目指した
私の目論見はダメダメですね、、、
それぞれコアとなるテンプレートを移行する方法で
がんばっていきます！

わざわざ調査頂いた上に資料までご提示頂きまして
誠にありがとうございました

今後とも参考にさせて頂きますので
これからも頑張ってください！

はじめまして。Kunitakaさんのブログからこちらに導かれ、勉強させていただいておりますmomochiroです。

ちょうど偶然、SPS2003でですが、この仕組みをはじめて知ったときの驚きを自分のブログに書いたところです。

弊社では、、この仕組みのところに何らかの問題があるのか・・改姓した人の表示名が自動的に新姓にならない、つまりユーザー情報にプロファイルからちゃんとデータコピーがされないようなんですが、、。orz
手でちまちまと直しております。
何か代表的な問題とか考えられるものはありますでしょうか？

なお、こちらの講師もつとめられていらっしゃるのでしょうか？ぜひぜひ開催を！
https://www.crie-illuminate.jp/training/courselist01.aspx

momochiroさん
はじめまして。お返事が遅くなりましてすみません。SPS2003ではユーザープロファイルとUserInfo間での同期はされていなかったと思います。それが、MOSS 2007 になり、同期の仕組みができてこれまでの問題が改修されたという認識です。MOSS 2007は SPS 2003 と比較してかなり詳細な部分が変わっていますが、そのひとつですね。
(参考)http://www.andrewconnell.com/blog/archive/2005/08/18/1912.aspx

またご指摘のコースは「Microsoft Office SharePoint Server 2007 ベーススキル トレーニング」でしょうか? このコースは私が現場ではきっと必要とされるはず! と思い最近開発したものでして、一部定期開催日程が決定されていませんが、近々スケジュールを公開する予定です。このコースを含め一般集客となるコースで自分が登壇する予定のものは、こちらのブログでも公開しようかと思っております。もし、ご都合がつくようでしたら、ぜひ、ご参加くださいませ。
引き続きよろしくお願いいたします

山崎さん

お返事アリガトウゴザイマス。
＞SPS2003ではユーザープロファイルとUserInfo間での同期はされていなかったと思います

そうなんですか。。MSのエンジニアが勘違いしたのでしょうか。。

トレーニングはご指摘のコースです！crie-illuminateさんに開催日をお問い合わせしましたところ4月にでもとおっしゃっていただけました。上司にも承諾もらいましたし、開催される暁には絶対に参加させていただきます！

お疲れ様です。Sunmoretecの富です。

InfoPathでの表示ユーザ絞込み方法で困っています。

InfoPathのプルダウンメニューにADのユーザ表示名を出力するようにしています。
元データは個々で紹介されている「userinfo」テーブル（データ接続）です。
ただ、ユーザ数が多く、プルダウンメニュに表示するユーザをADで登録したグループで絞りたいのですが、このテーブルにある「tp_DomainGroup」項目がすべて「false」となっていて取得できないようです。

何とか、ADユーザをAD登録グループで絞り込んでInfoPathのプルダウンメニューに表示することは出来ないでしょうか？

利用しているのは SharePoint Service 3 です。

富さん

ご無沙汰しております。コメントをありがとうございます。ADユーザーをADグループで絞り込んで表示したいということですが、この場合はuserInfoテーブルではなくて、ADからLDAPなどを使って情報を取得するようなWebサービスを構築するのが妥当ではないかと思います。

そもそも InfoPath はあまり多い情報を取得してしまうと、パフォーマンス低下を招く可能性が高いので、できる限り必要な情報だけを抽出して取得することも重要ですから、そうした Web サービスは可能であれば用意したいところです。

なお、Web サービスを作成する際に、AD上のグループやグループ内のメンバシップの列挙方法については C# ベースの資料であれば、次のMSDNサイトに情報がありますので、参考になりそうです。

・http://msdn.microsoft.com/ja-jp/library/ms180909(VS.80).aspx
・http://msdn.microsoft.com/ja-jp/library/ms180906(VS.80).aspx

現在、InfoPathプルダウンメニューにADユーザ情報を出力できるようになりました。

LogParserでCSV出力したADユーザ情報をSharePointのリストへ読込ませて、
InfoPathのデータ接続（SharePointライブラリ、リスト）で結びつけてInfoPath内で利用しています。

また、最初に「部署」を入力してもらうことで「申請者」の表示データを絞り込んでいます。
これで、何とか実用というところまできました。

ただ、この方法だとActiveDirectoryのADユーザが追加／削除された場合、
SharePointで管理しているリストの手作業での更新が必要です。

InfoPathの他のデー接続で何とか、ADとSharePointの登録情報の自動連携を検討しましたが、

・XMLデータ接続　
　InfoPathを最初に開いたときは「部署」は取れるのですが「申請者」がうまく取れないようで断念しました

・DBデータ接続
　SharePointのDBへ接続してデータを取ろうと思いましたが、ユーザ所属グループがとれず断念しました

私が作成している感じではSharePointリストしか持続的にInfoPathでデータを利用できないような気がしています。

後は、ActiveDirectoryのADユーザ情報 ～ SharePointリスト との間で自動同期させられないものか、
検討中です。そして　SharePointリスト ～ InfoPath（リスト、データ接続）へ。

今回のワークフロー＆InfoPathフォームによる申請フォームは本番運用できそうですが、
やはりこの点が運用としては２重登録になり問題です。

　ActiveDirectoryのADユーザ情報 ～ SharePointリスト ～ InfoPath（リスト、データ接続）

「ActiveDirectoryのADユーザ情報 ～ SharePointリスト」間の自動更新について
お知恵を拝借できれば助かります。

このフォームの後も、社内では沢山のフォーム化（InfoPath＋SharePointワークフロー）されるのを
待っている業務があるので何とかここを越ええたいと思っています。

理想としては、事務業務の半自動化／浮いた時間による社員のスキルアップ実現です。・・・（上司用）
（本当の目標は、残業時間４０時間越えが続く職場環境の改善です）・・・（本音）

・・・SharePointが職場環境の救世主ソフトになってもらいたいものです。

富さん、すみません、ずっとお返事ができませんでした。AD連携の部分はInfoPathにはぜひ欲しい機能なのですが、標準では提供されていないので、いろいろと工夫が必要ですが、おそらくメンテナンスなど考えると一番効率がよいのはWebサービスで連携できるようにすることです。

ちなみに、昨日(2009/2/2)に投稿した記事に書きました書籍のサンプルコードに比較的単純なAD連携可能なWebサービスのサンプルが含まれます。まだ、弊社の側でダウンロードサイトを準備しているところなのですのでダウンロードできるようになったら、こちらのブログでも告知しますので、参考にしていただけるかと思います。

また、AD連携およびデータベース連携を比較的容易に行えるようにするWebサービス作成ツールがあります。Qdabra,Incという会社がInfoPath連携ソリューションをいろいろと出しているのですが、その会社の一製品です。ちなみに、このツールは前職のクリエ・イルミネートで販売などを扱っていますので、詳細はそちらにお問い合わせいただくとよいと思います。

★参考★ http://thesource.ofallevil.com/japan/office/2007/oba/partner/crie.mspx#ECC

はじめまして

私、MOSS駆け出し中のwolfwoodと申します。

４月から弊社内でトレーニング用のMOSSをAD環境で構築しています。

当初から
【ADに追加したドメインユーザーをSharePointサイトに追加してもアクセスできない。】
という問題がありました。

原因が全く分からず、今回質問させて頂いております。

１．ADに新規ユーザーを追加
２．ユーザープロファイルのインポート
３．トップレベルサイトにユーザーを追加

という手順で処理しても、追加したユーザーでサイトにアクセスすることができません。

Windowsにはログインできるので、コンテンツDBの問題かなとも思うのですが。。。

ただ、不思議なことに、一瞬だけアクセスすることができる方法があります。

１．サーバーのドメインを再設定（マイコンピューターのプロパティで変更）
２．再起動

を行うと、ドメインユーザーでアクセス出来る時があります。

何が原因だったのか分からず腑に落ちないまま、そのユーザーで作業をしていると、いつの間にかアクセス不能となります。。。

これは【タイマージョブによる同期】の影響なのでしょうか。

このような状態なのですが、どの辺りに問題がありそうなのか推測することは出来ますでしょうか？

無茶な質問すみません orz

wolfwoodさん、コメントをありがとうございます。お返事がなかなかできず申し訳ありませんでした。コメントをいただいてから、しばらく経っておりますが、現状はいかがでしょうか。ご質問いただいたところからは、ちょっと詳細状況がわかりませんが、ユーザー認証にユーザープロファイルは関係していませんので、切り分けて問題解決に臨んだ方が良いですね。また、トップレベルサイトに追加しただけでは、全サイトにアクセスできるとは限りません。まずは、認証周りで確認すべきはIIS側の認証がNTLMなのかKerberosのいずれで構成されているかを確認することです。Kerberosだと追加設定が必要な場合がありますので。また、SharePointのセキュリティ管理(アクセス権管理)の考え方が混乱されているようですので、一度整理されるとよいと思いますよ。

お返事ありがとうございました

状況は、残念ながら全く変わっておりません

IIS認証は、【SharePointの全体管理】から確認したところ、【NTLM】でした。

【Kerberos】の場合は、SharePointアプリケーションプールIDを固有ユーザーで設定した場合、そのユーザーをサービスプリンシパル名に登録するという処理が必要なようですが、
【NTLM】の場合は、特に設定は必要ないのでしょうか？

とりあえず、
Active Directoryに関しても全く知識がないので、
そこから勉強してみようと思います

ありがとうございました

wolfwoodさん、その後も状況は変わらずですか。。。お役に立てずすみません。

ですが、そもそもSharePointのユーザー管理はそんなに難しい設定ではないので、SharePointだけでないところにも原因があるような気もしますし、SharePoint自体の調子が悪いのかも、、なんて色々と憶測してしまいます。どちらにせよ、これ以上は貴社の環境依存の問題がありそうなので、がんばって調査してみてください(そんなことしか、いえずすみません)。

-追伸-
ちなみに、IISがNTLMの場合はWindows認証基盤が整っていれば、SPN登録などは不要で基本的にはすぐ使えるはずです。

もしご存知であれば教えてください。

サイトコレクションのアクセス権限として
ADのセキュリティグループを登録した環境にて
メンテナンス（部署名変更）のため
DCのセキュリティグループの名前変更を行うという処理を行う場合、
サイトコレクション内からユーザの削除を実施し
再度、登録するという方法しかないでしょうか？

「migrateuser」のコマンドを試しましたが、
グループアカウントのため処理出来ませんといった
応答がありました。

Onoさん、
SharePoint Server 2007の場合は、ユーザープロファイルによる一元管理の考え方がWindowsグループにも適用されてしまい、いったん登録されたらユーザーアカウントと同様に直接編集はできくなってしまいますね。

厳密に言えば、AD側のグループ名を変更した場合は、いったん削除せずに、再度サイトコレクションにアカウントを追加すればログオン アカウント名(ex. EXAMPLE\TestGroup)は更新されます。このままでも、Windowsグループに所属するユーザーはアクセス可能です。ただし、表示名は変更されませんので、そのままでは運用上望ましくありません。そこで、表示名まで更新するには、御指摘通り一度削除してから再登録するというのがマニュアル操作では一般的ではないかと思います。

なお、表示名の変更は、つまるところサイトコレクションで管理されているUserInfoテーブルを変更すればよいのですが、データベースの直接変更はサポートされていないため、SharePoint オブジェクトモデル経由で変更することが推奨されます。もし、データベースを直接変更する場合は自己責任のもとで実施します。

SharePointオブジェクトモデルを操作する場合のソースコードを、参考までに記載しておきますね。
***********
using (SPWeb web = new SPSite("目的のSharePointサイトのURL").OpenWeb())
{
SPUser winGroup = web.AllUsers['ログイン名'];
winGroup.Name = "変更したい表示名";
winGroup.Update(); };
***********
※SPUserオブジェクトはWindowsユーザーおよびグループを表します。

適切なご回答ありがとうございます
PowerShellにて、下記のように変更を試してみたところ上手くいきました。

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$SPSite = New-Object Microsoft.SharePoint.SPSite("http://moss")
$OpenWeb = $SPSite.OpenWeb("/")
$spUser = $OpenWeb.SiteUsers["demo\testgroup-4"]
$spUser.Name = "NEW USER DISPLAY NAME"
$spUser.Update()

運用としては、グループアカウントの名前変更を行った後、
上記スクリプトを元にしたアカウント名＋名前を
変更する物を用意し対応したいと存じます。

はじめまして。大変参考になりました。

フォームベース認証を構成してSSPへプロファイルをインポートしたいと思っているのですが、どうにもうまくいきません。

やったこと＞
下記を参考にしてフォームベース認証のSSP管理サイトを構成しました。
http://technet.microsoft.com/ja-jp/library/cc262201.aspx
この例ではLDAPサーバーを使っていますが、認証プロバイダにはAspNetSqlMemberShipProviderを利用しています。そうするとインポート接続を作ることができませんでした。ビジネスデータカタログにすればOK？と思ったんですがStandardエディションでは使えないようです。「ユーザープロファイルの追加」で一人ずつ追加していくことはできるのですが、メールなどの情報がマッピングできませんし…
いい方法をご存じないでしょうか？

ka2さん、はじめまして。コメントをありがとうございます。

フォーム認証を利用してらっしやるんですね。この場合プロファイルインポートを行うにはカスタム ツールを作成するか、CodePlexサイトのオープンソースツールの一つである「MOSS 2007 Profile Import Tool 」を使うかのいずれかになりますね。

参考となる情報は、下記MSDNサイトの方が充実しています。http://msdn.microsoft.com/ja-jp/library/bb977430.aspx

以下は抜粋です。
「プロファイル インポートは、ユーザーの情報を SharePoint プロファイル システムにインポートする MOSS 2007 の機能です。このプロファイル情報は個人用サイト エリアに表示されます。ユーザーはこの情報を表示して、組織内の他のユーザーに関して公開されている情報 (各自の技能や興味、組織の階層、配布リストのメンバシップなど) を参照することができます。プロファイルは、Windows ベース ディレクトリのユーザーか、LDAP (Lightweight Directory Access Protocol) ベースのディレクトリから作成できます。プロファイルの属性は、ビジネス データ カタログを介して、他の基幹業務 (LOB) システムから追加することもできます。

フォーム認証を使用する場合、ユーザーやユーザーの属性をプロファイル システムにインポートできるツールは用意されていません。フォーム認証ユーザーのデータをインポートするには、ユーザー、属性、およびロール情報 (オプション) を列挙し、その情報を基に SharePoint 製品とテクノロジでプロファイル データを作成または更新できるカスタム アプリケーションが必要です。(以下、略)」

ちなみにMOSS 2007 Profile Import Toolは、まだ利用したことがないので、逆に感想などいただけると助かります

ありがとうございます！

このツール、実はダウンロードだけしていたんですが、英語だったので「うーんよくわからん」という状況でこちらのページを拝見しました。ユーザー管理についてだいぶ理解できた（ような気がします）ので、試してみますね。ご報告はだいぶ後になるかもしれませんが…

お世話になります。紹介いただいたツールでユーザープロファイルのインポートができましたので、簡単にレポートしておきます。

■概要
設定ファイルに登録したメンバシッププロバイダとプロファイルプロバイダの内容をローカルサーバー上SSPのユーザープロファイルにインポートするツールです。
コマンドラインでの実行とWindowsフォームアプリとしての実行が可能です。（/runオプションをつけるとコマンド実行になります）

ダウンロードした内容はVS2005のソリューション形式になっています。
（VS2008だと変換ウィザードが実行されますが、エラーなく変換できます）
プロジェクトは以下の四つで、C#でコーディングされています。
・CustomProviders
・CustomTasks
・SampleProviders
・Driver

本体はDriverプロジェクトで、ビルドするとProfileImporter.exeになります。
MOSSがセットアップされていないマシンでは参照エラーが出るので、MOSSをセットアップしたサーバーにVS2005なりVS2008なりをインストールして使う必要があります。
エラーの出る参照は以下の二つです。
・Microsoft.Office.Server
・Microsoft.SharePoint
MOSSがセットアップされていないマシンでも上記dllをコピーして参照すればビルド可能ですが、実行するとサイトがないのでエラーになります。

■前提条件
MOSSがフォームベース認証で構成されていること。検証環境ではメンバシッププロバイダにSystem.Web.Security.SqlMembershipProvider、プロファイルプロバイダにSystem.Web.Profile.SqlProfileProviderを利用しています。また、二つのプロバイダは同一接続文字列を利用して、ローカルのSQLExpressのデータベースに接続しています。

■使い方
Driverプロジェクト内のApp.Configに必要な設定をして実行すれば設定したメンバシッププロバイダとプロファイルプロバイダの内容がローカルサーバー上のSSPのユーザープロファイルにインポートされます。インポート先を指定する必要はありません。（App.ConfigはビルドするとProfileImporter.exe.configになります）
フォームとして実行する場合、4つの実行用ボタンとサイト指定テキストボックスが表示されます。コマンド実行した場合は右上の「Import All Providers」ボタンを押した場合と同じコードが実行されます。上の段がアプリにインポート、下の段がSSPにインポートという切り分けになっているようですが、左下のボタンはコードがコメントになっていたり、右下のボタンは右上と同じだったり、左上の「Import Default Providers」ボタンはエラーになったりしました。プロバイダを1つだけ登録して右上ImportAllが確実なようです。左のエリアには実行結果が表示されます。

■App.Configの設定
１～５の設定を行います。もともとサンプルの設定が記述されているので、該当する箇所を書き直します。

１．Configuration Handler登録
検証環境ではここは特になにもしなくても動作しました。

２．SQL接続文字列の登録
メンバシッププロバイダとプロファイルプロバイダのデータベース接続文字列を登録します。検証環境では同一DBなのでひとつだけ設定しました。MOSSのWeb.Configにも設定してあるはずですので、それを持ってくればOKです。

３．メンバシッププロバイダの登録
MOSSのWeb.Configで利用している設定をそのまま持ってくればOKです。

４．プロファイルプロバイダの登録
propertiesの内容は変更していません。providersは以下のようにしています。
※＜＞は全角で投稿しました。

＜providers＞
＜remove name="AspNetSqlProfileProvider" /＞
＜add name="AspNetSqlProfileProvider" connectionStringName="WSS_MEMBERDB" applicationName="WSS_MEMBER" type="System.Web.Profile.SqlProfileProvider" /＞
＜/providers＞

５．インポートプロバイダの登録
このツール独自の設定です。インポート元となるメンバシッププロバイダとプロファイルプロバイダの組に適当な名前をつけます。
指定するのはname、membershipProvider、profileProvider属性で、nameを適当につけます。

■感想
英語のドキュメントで「プロバイダ」が何度も出てくるので？？？となっていました。このあたりの仕組みはわかればとても便利ですね。前々回の投稿で触れた、SSP管理サイトのフォーム認証用拡張は不要な気がします。ありがとうございました。

ka2さん、早速の詳細なご報告をありがとうございました!　私自身とても参考になりました。こうした情報交換をさせていただけると非常に助かります。また、私も時間のある時に、試してみたいと思います!