タイムシートの承認パスを1upで完結させる
組織構成上、上位から順にAさん-Bさん-Cさんと並んだレポートラインがあったとします。
RBSもこれに準じて組みますが、中間管理職のBさんは部下Cさんの稼働管理を上司Aさんから一任されている。Bさん→Cさんの仕事の割り振り（=予定の管理）だけでなく、Cさん→Bさんで報告される稼働実績の承認権限も与えられていて、しかしながらBさん自身の稼働実績はAさんが承認せねばならない、という場合。
このとき、タイムシートの承認パスは左側のように構成したいところです。CさんのはBさんが承認して終わり。BさんのはAさんが承認して終わり。
右側のはタイムシートで報告される実績をCさんから見て2段階で承認しています。BさんのはAさんが承認して終わりですが、CさんのはBさんがまず内容を確認し、問題なければAさんに回す。Aさんが最終的に承認して初めて「承認済み」の扱いとなるわけです。
承認を1upで終わらせる左側の構成を組む際、肝になるのはカテゴリ権限。Bさんクラスのユーザをグルーピングしてるなら、[サーバー設定] ＞[グループの管理]で該当のグループを開いて、カテゴリに「自分のリソース」を追加（既定なら＆追加してなかったら）、更に「自分のリソース」に対して「タイムシートの承認」の許可設定
を入れませう。カテゴリ権限は、既存グループをコピーして新グループを作った場合にも自動でコピーされません。要注意
そのグループなりユーザなりがグローバルアクセス権で「タイムシートの承諾」を許可されてるだけだと、承認しようとしたところで二次承認を誰に回すか聞かれてしまいます。自分を選んでも空欄にしてもエラーになるし、Aさんを選べばAさんに飛んでしまうし、[サーバー設定] ＞ [ユーザーの管理]でBさんの「タイムシート管理者」欄をAさんでなくBさん自身や空欄に設定したって駄目。肝はなにしろ「承諾」（英語版だと「Accept」）でなく「承認」（同じく「Approve」）の権限があるかどうか、なのです。まぎらわしいよね〜
やむなくAさんを選んで承認（実際には「承諾」）すると、「承認」メニュー内「タイムシート」で表示される「状況」は「承認済み」でなく「承諾可能」になります。ここ、例に挙げたAさん-Bさん-Cさんみたいな3階層だと表現が破綻してるよなあ
ますます訳分からん。ちょろっと検索してヒットする説明が更に誤解を生むような。
ひたすらRBSの話だと思って10分ほど右往左往（RBS上の配置を調整してみたりとか）してしまったのはわたしだけじゃないハズ！しかし「承認チェーンの最終承認者」になれるかどうかはカテゴリ権限が決定打を持っているんでした。や、ちゃんと読めば載ってるんですけど。
Microsoft Office Project Server 2007 のカテゴリ権限
http://technet.microsoft.com/ja-jp/library/cc197622.aspx
Microsoft Office Project Server 2007 のグローバル アクセス権
http://technet.microsoft.com/ja-jp/library/cc197631.aspx
に、したってそもそも「承認」と「承諾」を分けて考えてるってとこ、もっとガチッと最初にアピールしといてくれてもいいと思うの。Microsoftって普段はたいして用語の統一性に厳密でないように感じるのにさ〜。
RBSもこれに準じて組みますが、中間管理職のBさんは部下Cさんの稼働管理を上司Aさんから一任されている。Bさん→Cさんの仕事の割り振り（=予定の管理）だけでなく、Cさん→Bさんで報告される稼働実績の承認権限も与えられていて、しかしながらBさん自身の稼働実績はAさんが承認せねばならない、という場合。
このとき、タイムシートの承認パスは左側のように構成したいところです。CさんのはBさんが承認して終わり。BさんのはAさんが承認して終わり。
右側のはタイムシートで報告される実績をCさんから見て2段階で承認しています。BさんのはAさんが承認して終わりですが、CさんのはBさんがまず内容を確認し、問題なければAさんに回す。Aさんが最終的に承認して初めて「承認済み」の扱いとなるわけです。
承認を1upで終わらせる左側の構成を組む際、肝になるのはカテゴリ権限。Bさんクラスのユーザをグルーピングしてるなら、[サーバー設定] ＞[グループの管理]で該当のグループを開いて、カテゴリに「自分のリソース」を追加（既定なら＆追加してなかったら）、更に「自分のリソース」に対して「タイムシートの承認」の許可設定
を入れませう。カテゴリ権限は、既存グループをコピーして新グループを作った場合にも自動でコピーされません。要注意
そのグループなりユーザなりがグローバルアクセス権で「タイムシートの承諾」を許可されてるだけだと、承認しようとしたところで二次承認を誰に回すか聞かれてしまいます。自分を選んでも空欄にしてもエラーになるし、Aさんを選べばAさんに飛んでしまうし、[サーバー設定] ＞ [ユーザーの管理]でBさんの「タイムシート管理者」欄をAさんでなくBさん自身や空欄に設定したって駄目。肝はなにしろ「承諾」（英語版だと「Accept」）でなく「承認」（同じく「Approve」）の権限があるかどうか、なのです。まぎらわしいよね〜
やむなくAさんを選んで承認（実際には「承諾」）すると、「承認」メニュー内「タイムシート」で表示される「状況」は「承認済み」でなく「承諾可能」になります。ここ、例に挙げたAさん-Bさん-Cさんみたいな3階層だと表現が破綻してるよなあ
ますます訳分からん。ちょろっと検索してヒットする説明が更に誤解を生むような。
タイムシートを承認したにもかかわらず、状態が [承認済み] ではなく [承諾可能] に設定される
http://office.microsoft.com/ja-jp/projectserver/HA100920081041.aspx?pid=CH101477291041
原因
状況を実際に [承認済み] に変更できるのは、承認チェーンの最終承認者のみです。最終より前の承認者はすべて、タイムシートを承諾可能として設定することにより、次の承認者にタイムシートの承認を推奨することを示すのみです。
ひたすらRBSの話だと思って10分ほど右往左往（RBS上の配置を調整してみたりとか）してしまったのはわたしだけじゃないハズ！しかし「承認チェーンの最終承認者」になれるかどうかはカテゴリ権限が決定打を持っているんでした。や、ちゃんと読めば載ってるんですけど。
Microsoft Office Project Server 2007 のカテゴリ権限
http://technet.microsoft.com/ja-jp/library/cc197622.aspx
Microsoft Office Project Server 2007 のグローバル アクセス権
http://technet.microsoft.com/ja-jp/library/cc197631.aspx
に、したってそもそも「承認」と「承諾」を分けて考えてるってとこ、もっとガチッと最初にアピールしといてくれてもいいと思うの。Microsoftって普段はたいして用語の統一性に厳密でないように感じるのにさ〜。
共有している予定表のアクセス権をOutlookで変更できない
ググッたとき日本語文献あんまなかったので書いてみる。
Outlookで自分の予定表を誰かと共有するとき、誰にどこまで許すか（見るだけとか、編集も出来るようにするとか）というのは予定表のプロパティ「アクセス権」タブで設定します。
特に制限を設けていない環境ではエンドユーザ各自が自分の予定表を好きなように公開できる訳ですが、この画面でアクセス権を編集していざ適用させようとすると、エラーが表示されて更新出来ないことがあります。そんなとき便利なのが
PFDavAdmin〜
（ドラえもん調で）
わたしの知ってる環境では前任者が過去に、予定表の共有をリクエストしたお偉いさんに操作をお願いするのが忍びなくて、つか絶対たぶん操作を説明するのが面倒臭くて、乱暴にもExchangeのIFSドライブ（既定ではM:）をExplorerで開いて直に予定表へのアクセス権限を設定しちゃっていて、そのせいでこうした現象が起こりました。公開する相手やなんかを変更する必要が出て来たときに、秘書が「ここをこうするんですよ」ってお偉いさんに説明してやってみてNG、っていう。
Explorer上でゴリッと編集しちゃうとDACL（Discretionary Access Control List）の権限設定をNTFS的に上書いてしまって、要するに台無しなんです。台無し。サバ管としてひとまずドライブMで確認するとちゃんと当たってるのに、Outlookで予定表のプロパティを見ると名前とか役割の欄が空っぽ。「既定」とか「匿名」とかすらないし追加も出来ない。そもそも誰に公開してて誰に公開してないか、エンドユーザが画面で確認出来ないという困った事態に。
PFDavAdminは、真っ当にDACL的なアクセス権の確認・編集が行える便利なツール。インストールして使います。詳しい説明は、英語だけど：
Using PFDavAdmin to administer mailbox delegate permissions
The PFDavAdmin Tool
あたりをご参照。後者のが詳しい。PFDavAdminそのものはMSで配布してますが、MSってURLがころころ変わるんだよねえ。自サイト内でリンクが切れてて「Sorry」もザラだし、それはどうなの
ともあれ今のところこちらが有効：
PFDavAdminをダウンロード
（http://download.microsoft.com/download/2/f/0/2f0d72e2-a97a-49b6-879a-3b405cab017e/PFDAVAdmin.EXE）
このexe自体は自己解凍ファイルで、解凍して出来たフォルダ内にある同名exeを実行するとインストール開始。同梱のPFDAVAdmin.docは懇切丁寧なREAD MEです。英語。探してないけど日本語版なさげ。ツール自体もメニューとか英語しかないっぽいけど、日本語オンリーのひとにもそんなに分かりにくくはないと思う。
無論、これで他人のメールボックス（やら予定表やら）にアクセスするには十分な権限が必要です。FileメニューからExchangeに接続する際、ツールを走らせてるPCへのログイン情報を流用するか別途指定するか選べます。Exchangeに接続すると左ペインにアイテムのツリーが出るので、目的の予定表を選択して右クリック、Permissionsを表示します。
わたしと同じ状況なら、右上の「DACL state」が「Good」じゃないはず。見たまんま「Add」「Remove」ボタンを使って正しく構成し直しませう。まともに動いてる別の予定表と見比べながらやると楽だよ。詳しくは書きませんが、念のため現行の設定をXML形式で書き出しておくのが定石（PFDavAdminで出来ます）。環境如何なので自己責任は言う間でもない。
で、「Name」「Role」（日本語環境Outlookで見たときの「名前」「役割」）を正しく設定したら「Commit changes」ボタンをクリックして完了。ExplorerでドライブMのを見たときにはExchangeのシステムアカウントが入ってたりするけど、Outlookで見たときには表示されないじゃん？PFDavAdminもOutlookで見たときと同じにすれば大丈夫です。ExchangeのシステムアカウントだのDomain Adminsだのっていうものはこの画面では特に入れなくてもよろしい。DACLとNTFSで違うって、顕著なとこではそういうことかと。
このツールが便利なのは、そんなトラブルシュートに限らず本来エンドユーザが操作せねばならんアクセス権設定を（乱暴でなく）代行出来るところにあると思います。DIYってことにしててもお偉いさんに操作を説明してやってもらうのはやっぱ、ときとしてお互いに面倒臭いしね。ヒラはDIYでお願いするとして、任されてるならエグゼクティブのはPFDavAdminでサクッと設定して、「終わりました。ここで見れます。変更も出来ます」とお知らせするのがスマートじゃないかなと思う。
Outlookで自分の予定表を誰かと共有するとき、誰にどこまで許すか（見るだけとか、編集も出来るようにするとか）というのは予定表のプロパティ「アクセス権」タブで設定します。
特に制限を設けていない環境ではエンドユーザ各自が自分の予定表を好きなように公開できる訳ですが、この画面でアクセス権を編集していざ適用させようとすると、エラーが表示されて更新出来ないことがあります。そんなとき便利なのが
PFDavAdmin〜
（ドラえもん調で）
わたしの知ってる環境では前任者が過去に、予定表の共有をリクエストしたお偉いさんに操作をお願いするのが忍びなくて、つか絶対たぶん操作を説明するのが面倒臭くて、乱暴にもExchangeのIFSドライブ（既定ではM:）をExplorerで開いて直に予定表へのアクセス権限を設定しちゃっていて、そのせいでこうした現象が起こりました。公開する相手やなんかを変更する必要が出て来たときに、秘書が「ここをこうするんですよ」ってお偉いさんに説明してやってみてNG、っていう。
Explorer上でゴリッと編集しちゃうとDACL（Discretionary Access Control List）の権限設定をNTFS的に上書いてしまって、要するに台無しなんです。台無し。サバ管としてひとまずドライブMで確認するとちゃんと当たってるのに、Outlookで予定表のプロパティを見ると名前とか役割の欄が空っぽ。「既定」とか「匿名」とかすらないし追加も出来ない。そもそも誰に公開してて誰に公開してないか、エンドユーザが画面で確認出来ないという困った事態に。
PFDavAdminは、真っ当にDACL的なアクセス権の確認・編集が行える便利なツール。インストールして使います。詳しい説明は、英語だけど：
Using PFDavAdmin to administer mailbox delegate permissions
The PFDavAdmin Tool
あたりをご参照。後者のが詳しい。PFDavAdminそのものはMSで配布してますが、MSってURLがころころ変わるんだよねえ。自サイト内でリンクが切れてて「Sorry」もザラだし、それはどうなの
ともあれ今のところこちらが有効：
PFDavAdminをダウンロード
（http://download.microsoft.com/download/2/f/0/2f0d72e2-a97a-49b6-879a-3b405cab017e/PFDAVAdmin.EXE）
このexe自体は自己解凍ファイルで、解凍して出来たフォルダ内にある同名exeを実行するとインストール開始。同梱のPFDAVAdmin.docは懇切丁寧なREAD MEです。英語。探してないけど日本語版なさげ。ツール自体もメニューとか英語しかないっぽいけど、日本語オンリーのひとにもそんなに分かりにくくはないと思う。
無論、これで他人のメールボックス（やら予定表やら）にアクセスするには十分な権限が必要です。FileメニューからExchangeに接続する際、ツールを走らせてるPCへのログイン情報を流用するか別途指定するか選べます。Exchangeに接続すると左ペインにアイテムのツリーが出るので、目的の予定表を選択して右クリック、Permissionsを表示します。
わたしと同じ状況なら、右上の「DACL state」が「Good」じゃないはず。見たまんま「Add」「Remove」ボタンを使って正しく構成し直しませう。まともに動いてる別の予定表と見比べながらやると楽だよ。詳しくは書きませんが、念のため現行の設定をXML形式で書き出しておくのが定石（PFDavAdminで出来ます）。環境如何なので自己責任は言う間でもない。
で、「Name」「Role」（日本語環境Outlookで見たときの「名前」「役割」）を正しく設定したら「Commit changes」ボタンをクリックして完了。ExplorerでドライブMのを見たときにはExchangeのシステムアカウントが入ってたりするけど、Outlookで見たときには表示されないじゃん？PFDavAdminもOutlookで見たときと同じにすれば大丈夫です。ExchangeのシステムアカウントだのDomain Adminsだのっていうものはこの画面では特に入れなくてもよろしい。DACLとNTFSで違うって、顕著なとこではそういうことかと。
このツールが便利なのは、そんなトラブルシュートに限らず本来エンドユーザが操作せねばならんアクセス権設定を（乱暴でなく）代行出来るところにあると思います。DIYってことにしててもお偉いさんに操作を説明してやってもらうのはやっぱ、ときとしてお互いに面倒臭いしね。ヒラはDIYでお願いするとして、任されてるならエグゼクティブのはPFDavAdminでサクッと設定して、「終わりました。ここで見れます。変更も出来ます」とお知らせするのがスマートじゃないかなと思う。
WSUSエージェントの重複
SymantecGhostなどでイメージ展開している環境では、異なるPCが同じWSUSエージェントとして認識されてしまうことがあります。これはWSUSサーバがPCを識別する際に使用する専用ID（Client ID）が複数PCで重複してしまうせい。
WSUSで認識されたPCの一覧と、設定を撒いたPCの一覧をマッチングさせる作業を数回やれば一目瞭然。トータル台数は変わってないのに認識されてたはずのものがなくなってたり、認識されてなかったはずのものが「割り当てられていないコンピュータ」グループでなく特定の作成済みグループに入ってたり、はにゃ！Σ(||ﾟДﾟ)ってなります。UIDだのUUIDだのと闘った覚えのあるひとは、即座に不吉な予感におののくことでせう。
何が困るって例えWSUS環境の構築が初めてで、イメージ展開にSysprepを使用していたとしても何割かで発生し得る現象だっていうところです。現にわたしの知ってる環境では約100台に対して3台のみ発生しました。Client IDが生成される仕組みに起因するものと思われますが詳細は分からん。
生成されたClient IDは各PCのレジストリの：
HKLM¥SOFTWARE¥Microsoft¥Windows¥CurrentVersion¥WindowsUpdate
の直下、「PingID」「SUSClientID」「AccountDomainSID」のキー（ありもんで）に格納されてます。
クライアント側のログ（%windir%/WindowsUpdate.log）で「clientid」を検索すると、実際に使われているIDが何なのか確認できるよ。まるでオレオレ詐欺…。本来は一手間かけて、レジストリきれいにしてからWSUS設定を撒くべきなんだろな。しかし同じSysprep付きイメージから同じように展開したPCで重複するのとしないのとがある、しかも重複は消費税以下ときたらもう、まじめに「やっとくべきだった」と反省するのもなんか気が逸れるっていうか。したけど反省。
重複が判明したら該当クライアントのWindows Updatesサービスを止めて上記のキーを削除、サービス再開始＆「wuauclt /resetauthorization /detectnow」で改めてClient IDの生成＆WSUSサーバに認識させることができます。
WSUSで認識されたPCの一覧と、設定を撒いたPCの一覧をマッチングさせる作業を数回やれば一目瞭然。トータル台数は変わってないのに認識されてたはずのものがなくなってたり、認識されてなかったはずのものが「割り当てられていないコンピュータ」グループでなく特定の作成済みグループに入ってたり、はにゃ！Σ(||ﾟДﾟ)ってなります。UIDだのUUIDだのと闘った覚えのあるひとは、即座に不吉な予感におののくことでせう。
何が困るって例えWSUS環境の構築が初めてで、イメージ展開にSysprepを使用していたとしても何割かで発生し得る現象だっていうところです。現にわたしの知ってる環境では約100台に対して3台のみ発生しました。Client IDが生成される仕組みに起因するものと思われますが詳細は分からん。
生成されたClient IDは各PCのレジストリの：
HKLM¥SOFTWARE¥Microsoft¥Windows¥CurrentVersion¥WindowsUpdate
の直下、「PingID」「SUSClientID」「AccountDomainSID」のキー（ありもんで）に格納されてます。
クライアント側のログ（%windir%/WindowsUpdate.log）で「clientid」を検索すると、実際に使われているIDが何なのか確認できるよ。まるでオレオレ詐欺…。本来は一手間かけて、レジストリきれいにしてからWSUS設定を撒くべきなんだろな。しかし同じSysprep付きイメージから同じように展開したPCで重複するのとしないのとがある、しかも重複は消費税以下ときたらもう、まじめに「やっとくべきだった」と反省するのもなんか気が逸れるっていうか。したけど反省。
重複が判明したら該当クライアントのWindows Updatesサービスを止めて上記のキーを削除、サービス再開始＆「wuauclt /resetauthorization /detectnow」で改めてClient IDの生成＆WSUSサーバに認識させることができます。
ユーザデータベースの移動
ハイハイ言ってると全部システムディレクトリ（デフォルトCドライブ）行きです。そんなユーザデータベースとそのログを、圧迫されつつあるシステムディレクトリから別の場所に移す方法。データベースに関して素人のわたしは、ヘコいマシンに急いで仕立てたWSUSサーバがメタデータ（この世にどんなMSパッチがあるかというようなインデックス情報）だけでもカツカツになったため、慌てて調べて移動できました。しかし無論のことすべては自己責任です。ファイト。
SQL Server のデタッチとアタッチ機能を使用して SQL Server データベースを新しい場所に移動する方法
MS SQL Server Management Studioにログイン、データベースエンジンに接続してからの手順をまとめると：
目当てのデータベースの実体とログファイルを確認する
目当てのデータベースをデタッチする
目当てのデータベースを移動する
取り合えずコピーしといて何もかも終わってからオリジナルを削除、が定石なのは言うまでもなく。
目当てのデータベースをアタッチする
なお、WSUSサーバはデフォルトだとデータベース名は「WSUS」です。メタデータだけで数百メガは食うので馬鹿にならない。こうやって本体を移動してても、わたしはよく知らないtempdbのせいなのかなんなのか多少はやっぱり食います。しかし移動しないよりマシだ。ファイト（再）。
SQL Server のデタッチとアタッチ機能を使用して SQL Server データベースを新しい場所に移動する方法
MS SQL Server Management Studioにログイン、データベースエンジンに接続してからの手順をまとめると：
目当てのデータベースの実体とログファイルを確認する
use 'データベース名'
go
sp_helpfile
go
目当てのデータベースをデタッチする
use master
go
sp_detach_db 'データベース名'
go
目当てのデータベースを移動する
取り合えずコピーしといて何もかも終わってからオリジナルを削除、が定石なのは言うまでもなく。
目当てのデータベースをアタッチする
use master
go
sp_attach_db 'データベース名','移動先パス＆データベースのファイル名.mdf','移動先パス＆ログファイルのファイル名.ldf'
go
なお、WSUSサーバはデフォルトだとデータベース名は「WSUS」です。メタデータだけで数百メガは食うので馬鹿にならない。こうやって本体を移動してても、わたしはよく知らないtempdbのせいなのかなんなのか多少はやっぱり食います。しかし移動しないよりマシだ。ファイト（再）。
WSUSエージェントの管理
マニュアル通りにWSUSサーバを仕立ててクライアント側の設定も終えた、なのにエージェントから最新の報告が上がって来ないときに確認したい項目を絞りに絞ってご紹介。これらがOKならネットワーク（ルータとかスイッチとか）で蹴られている可能性を疑うのが正論かと。ネト管・シス管が同一の場合には、そこまで縺れることはあまりないと思われる。
Windowsファイアウォール
サーバ側、クライアント側の両方で要確認。手っ取り早いのは一時的に素通ししてみることですが、それよりいいのはログを有効化して確認する方法。Windowsファイアウォールのログ取りはデフォルトはOFFです。ウィルス対策ソフト等を入れている場合も同様に確認が必要。
Windows ファイアウォールのログを取得する方法
エージェントのログ
クライアントの%windir%直下、"WindowsUpdate.log"を見るべし。エージェント側のログです。WSUSサーバとのやり取りの様もここで確認できます。
エージェントのコマンド＆スイッチ
便利なスイッチ×2個。適切な権限があればATコマンドで仕込めます。「AT ¥¥クライアント名 時刻 コマンド＆スイッチ」ね。基本的にWSUSはゆるゆる管理でタイムラグもっさりなので、展開テストなんかはこれらがないとやってらんない（と思う）。
wuauclt /resetauthorization /detectnow
サーバ側でグループの割り当てを変更した際には特に便利。素だとクライアント側のキャッシュ情報に基づいてサーバにアクセスするため、サーバ側での変更とはタイムラグが発生します。このスイッチはそのキャッシュをチャラにして認識させ直すためのもの。
wuauclt /reportnow
サーバ側で認知後も、当たってるパッチの有無などインベントリ情報のアップデートまでには20分〜のタイムラグが発生します。待ってられないあなたにこのスイッチ。「報告されていません」の時間短縮に有効です。今のところ、ググッても日本語文献ほとんどないようなので。
ATコマンドの使い方はこちら（http://technet.microsoft.com/ja-jp/library/cc755618.aspx）をご参照。
ローカルキャッシュのクリア
それでも、待てど暮らせど上がってこない場合はこれ。クライアント内部の古い情報が更新を阻んでいるときに有効。「%Windir%SoftwareDistribution」配下をぜんぶ消してみるテスト。Automatic Updatesサービス（wuauserv）を止めないと削除できないよー。削除してサービスを再開させたら「wuauclt /resetauthorization /detectnow」で。
以上、これでだいたい解決するんじゃなかろうか。無論、クライアントのBITSサービスとかWSUS稼動要件に含まれるものは除外して書いてます。同じ無償ツールでも、MBSAなんかよりは全然まともな条件で動いてくれるツールじゃないかなあ。
Windowsファイアウォール
サーバ側、クライアント側の両方で要確認。手っ取り早いのは一時的に素通ししてみることですが、それよりいいのはログを有効化して確認する方法。Windowsファイアウォールのログ取りはデフォルトはOFFです。ウィルス対策ソフト等を入れている場合も同様に確認が必要。
Windows ファイアウォールのログを取得する方法
エージェントのログ
クライアントの%windir%直下、"WindowsUpdate.log"を見るべし。エージェント側のログです。WSUSサーバとのやり取りの様もここで確認できます。
エージェントのコマンド＆スイッチ
便利なスイッチ×2個。適切な権限があればATコマンドで仕込めます。「AT ¥¥クライアント名 時刻 コマンド＆スイッチ」ね。基本的にWSUSはゆるゆる管理でタイムラグもっさりなので、展開テストなんかはこれらがないとやってらんない（と思う）。
wuauclt /resetauthorization /detectnow
サーバ側でグループの割り当てを変更した際には特に便利。素だとクライアント側のキャッシュ情報に基づいてサーバにアクセスするため、サーバ側での変更とはタイムラグが発生します。このスイッチはそのキャッシュをチャラにして認識させ直すためのもの。
wuauclt /reportnow
サーバ側で認知後も、当たってるパッチの有無などインベントリ情報のアップデートまでには20分〜のタイムラグが発生します。待ってられないあなたにこのスイッチ。「報告されていません」の時間短縮に有効です。今のところ、ググッても日本語文献ほとんどないようなので。
ATコマンドの使い方はこちら（http://technet.microsoft.com/ja-jp/library/cc755618.aspx）をご参照。
ローカルキャッシュのクリア
それでも、待てど暮らせど上がってこない場合はこれ。クライアント内部の古い情報が更新を阻んでいるときに有効。「%Windir%SoftwareDistribution」配下をぜんぶ消してみるテスト。Automatic Updatesサービス（wuauserv）を止めないと削除できないよー。削除してサービスを再開させたら「wuauclt /resetauthorization /detectnow」で。
以上、これでだいたい解決するんじゃなかろうか。無論、クライアントのBITSサービスとかWSUS稼動要件に含まれるものは除外して書いてます。同じ無償ツールでも、MBSAなんかよりは全然まともな条件で動いてくれるツールじゃないかなあ。
