トップ回答者
AUOptionsの値が、dword:00000004からAUOptions"=dword:00000003に勝手に変更されてしまう問題

質問
-
クライアント十数台に下記のレジストリファイルを登録しました。
"AUOptions"=dword:00000004としていますが、数台で"AUOptions"=dword:00000003に
勝手に変更されてしまうものがあります。
そのため、タスクトレイに更新を促すアイコンは表示されますが、"AUOptions"=dword:00000003に
変更されてしまっているため、予定の時刻にインストールされません。
この問題の対処方法をご存知の方がいらっしゃいましたら、ご教授下さい。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"=http://xxxxxxxx"
"WUStatusServer"="http://xxxxxxxx"
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="xxxxxxx"[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoRebootWithLoggedOnUsers"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:0000000f
"DetectionFrequencyEnabled"=dword:00000001
"DetectionFrequency"=dword:00000002
"RebootRelaunchTimeout"=dword:0000012c
"RebootRelaunchTimeoutEnabled"=dword:00000001
回答
-
ボラカイ さん、こんにちは。フォーラムオペレーターの鈴木裕子です
AUOptionsの値がいつの間にか変更されているという現象について、私の方でも調べてみたのですが、残念ながら情報・事例ともありませんでした(USのフォーラムなども調べてみたのですが、残念ながら見つからず・・・)。
なので、現象について調査するならば・・・という視点での回答になってしまうのですが、もし、一度は設定どおりにWindowsUpdateが実行されてその後設定どおりに実行されなくなる(で、確認するとレジストリキーが変わっていた)というような状況であれば、現象が発生しているクライアントのWindowsUpdateログを確認してみると、何かヒントになる情報が得られるかもと思います。Microsoft Update/自動更新のエラー・ログを調査する
http://www.atmarkit.co.jp/fwin2k/win2ktips/804muerrlog/muerrlog.html
WindowsUpdateが一度も実行されないうちに値が変わっているのならば、このログを見てもあまり意味がないかもしれませんが・・・
あとは、オブジェクトアクセスの監査機能を利用して、該当のレジストリキーのアクセスを監視するとか(ある程度タイミングを絞り込んでからでないと、ログが膨大になってしまいますが・・・)オブジェクト アクセスの監査
http://technet.microsoft.com/ja-jp/library/cc776774.aspxこれも、変更されるタイミングがある程度絞り込まれてからになりますが、ProcessMonitorのようなツールを使って、レジストリを書き換えてるプロセスがないかを調べるという方法もあるかなと思います。
Process Monitor v2.03
http://technet.microsoft.com/ja-jp/sysinternals/bb896645(en-us).aspxこう考えてみると、やはりまずは、レジストリの値が変わるタイミングを絞り込んで、そこから、何が書き換えているかを調べていく、という調査方法になっていくのかなと思います。
すでにタイミングを絞り込んだうえでの投稿だった場合はごめんなさい!その場合は、上記のようなツールを使って調査してみてください。
また、何かのアプリケーションやツール等が書き換えている可能性もあるのではと思うので、書き換わるマシン・書き換わらないマシンで何が違うか(インストールされているアプリケーションや環境等)を確認するのも、基本的な調査ですが重要かなと思います(これも既にやってらした場合はごめんなさい・・・)。
ただ、このようなツールを使って調査を行っても原因が特定できない場合は、情報がない現象なので、サポート窓口で詳細に調査をしていただく方向になるのかなと思います。。。ただ、ボラカイ さんの方で解決できるのが何よりだと思いますので、まずは上記のような点を確認してみていただくとよいと思います。参考までに、該当のレジストリキーを変更する別の方法が、日本のセキュリティチームのブログにPOSTしてありましたので、紹介させていただきますね。
http://blogs.technet.com/jpsecurity/archive/2008/07/25/3093567.aspx
3番の方法でも、キーの値をdword:00000004に変更できて、かつUpdateの実行までできるようですね。
ボラカイ さんが実施されていた方法(2番)が消してあるのが気になると思うのですが(私も気になりまして)、POSTした弊社 小野寺に確認したところ、3番の方法を追加した際に、結局同じことをしているということで削除しただけのようです。何か問題があって削除したわけではないようですのでご安心を。ご興味があれば試してみて下さい。ご参考となれば幸いです!
- 回答としてマーク 大久保直美Microsoft employee 2009年2月12日 4:18
すべての返信
-
ボラカイ さん、こんにちは。フォーラムオペレーターの鈴木裕子です
AUOptionsの値がいつの間にか変更されているという現象について、私の方でも調べてみたのですが、残念ながら情報・事例ともありませんでした(USのフォーラムなども調べてみたのですが、残念ながら見つからず・・・)。
なので、現象について調査するならば・・・という視点での回答になってしまうのですが、もし、一度は設定どおりにWindowsUpdateが実行されてその後設定どおりに実行されなくなる(で、確認するとレジストリキーが変わっていた)というような状況であれば、現象が発生しているクライアントのWindowsUpdateログを確認してみると、何かヒントになる情報が得られるかもと思います。Microsoft Update/自動更新のエラー・ログを調査する
http://www.atmarkit.co.jp/fwin2k/win2ktips/804muerrlog/muerrlog.html
WindowsUpdateが一度も実行されないうちに値が変わっているのならば、このログを見てもあまり意味がないかもしれませんが・・・
あとは、オブジェクトアクセスの監査機能を利用して、該当のレジストリキーのアクセスを監視するとか(ある程度タイミングを絞り込んでからでないと、ログが膨大になってしまいますが・・・)オブジェクト アクセスの監査
http://technet.microsoft.com/ja-jp/library/cc776774.aspxこれも、変更されるタイミングがある程度絞り込まれてからになりますが、ProcessMonitorのようなツールを使って、レジストリを書き換えてるプロセスがないかを調べるという方法もあるかなと思います。
Process Monitor v2.03
http://technet.microsoft.com/ja-jp/sysinternals/bb896645(en-us).aspxこう考えてみると、やはりまずは、レジストリの値が変わるタイミングを絞り込んで、そこから、何が書き換えているかを調べていく、という調査方法になっていくのかなと思います。
すでにタイミングを絞り込んだうえでの投稿だった場合はごめんなさい!その場合は、上記のようなツールを使って調査してみてください。
また、何かのアプリケーションやツール等が書き換えている可能性もあるのではと思うので、書き換わるマシン・書き換わらないマシンで何が違うか(インストールされているアプリケーションや環境等)を確認するのも、基本的な調査ですが重要かなと思います(これも既にやってらした場合はごめんなさい・・・)。
ただ、このようなツールを使って調査を行っても原因が特定できない場合は、情報がない現象なので、サポート窓口で詳細に調査をしていただく方向になるのかなと思います。。。ただ、ボラカイ さんの方で解決できるのが何よりだと思いますので、まずは上記のような点を確認してみていただくとよいと思います。参考までに、該当のレジストリキーを変更する別の方法が、日本のセキュリティチームのブログにPOSTしてありましたので、紹介させていただきますね。
http://blogs.technet.com/jpsecurity/archive/2008/07/25/3093567.aspx
3番の方法でも、キーの値をdword:00000004に変更できて、かつUpdateの実行までできるようですね。
ボラカイ さんが実施されていた方法(2番)が消してあるのが気になると思うのですが(私も気になりまして)、POSTした弊社 小野寺に確認したところ、3番の方法を追加した際に、結局同じことをしているということで削除しただけのようです。何か問題があって削除したわけではないようですのでご安心を。ご興味があれば試してみて下さい。ご参考となれば幸いです!
- 回答としてマーク 大久保直美Microsoft employee 2009年2月12日 4:18
-
鈴木様、大久保様
鈴木様回答にあります自動更新のエラー・ログを調査してみましたが、原因らしきものが見つかりませんでした。
回避方法としては、
①下記regファイルを再度ユーザーに実行してもらいWindows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"=http://xxxxxxxx"
"WUStatusServer"="http://xxxxxxxx"
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="xxxxxxx"[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoRebootWithLoggedOnUsers"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:0000000f
"DetectionFrequencyEnabled"=dword:00000001
"DetectionFrequency"=dword:00000002
"RebootRelaunchTimeout"=dword:0000012c
②下記batファイルを実行してもらっています。
@echo offproxycfg -d
net stop wuauserv
net start wuauserv
wuauclt.exe /resetauthorization /detectnow
運用していくなかで、何か分かり次第投稿させていただきますので、
今後とも宜しくお願いします。