ワークフォルダーの実装

ITproさんで「Windows Server 2012 R2で実現するBYOD/リモートワーク」という記事を執筆させていただきました。Windows Server 2012 R2では、いつでも、どこでも、どんなデバイスでも仕事ができるワークスタイルを実現するために利用できる機能が色々と増えており、選択肢が増えたという点で様々な企業で導入しやすくなったのではないかと思います。

記事の中から、興味のある機能があれば、ぜひお試しいただきたいと考えているのですが、ワークフォルダーについて、あまり実装方法が書かれたものを見かけることができなかったので、ここで実装方法を載せておきます。

 

ワークフォルダーとは?

一言で言うなら「オンプレミス版SkyDrive」ってところでしょうか。
ワークフォルダーはクライアントPC(Windows8.1)に用意されたフォルダーにファイルを保存すると、自動的にサーバー(Windows Server 2012 R2)に用意されたフォルダーと同期を行います。これにより、

・サーバーに接続できないような外出先にいるときにサーバーに保存したファイルに
アクセスしたい
・クライアントPCに保存しているファイルをサーバーにバックアップしておきたい
・自分が利用する別のコンピューターから同じファイルにアクセスしたい

のようなときに効果を発揮します。

ワークフォルダーはSkyDriveと同じように、ユーザー単位でフォルダーが独立して管理されているため、同じユーザーであれば、どこにいようともファイルサーバーにアクセスできれば、ワークフォルダーとの同期ができます。

Workfolder

また、ファイルサーバーを外部に公開していないため、同期ができない場合でも、同期したワークフォルダーのコンテンツはローカルに残されるので、どこにいてもアクセスできるメリットがあります。

 

 

設定方法 – 概要

行うことは全部で7つあります。

1.サーバーの用意
2.ワークフォルダーの役割インストール
3.SSLサイトの実装
4.共有フォルダーの設定

5.グループポリシーの設定
6.クライアントの設定(ドメイン参加PCの場合)
7.クライアントの設定(ドメイン未参加PCの場合)

以上の手順を順番に確認していきましょう。

 

 

1.サーバーの用意

役割として、ドメインコントローラー、Webサーバー、ファイルサーバー、証明書サービス、ワークフォルダーの役割が必要になりますが、1台のサーバーにまとめることが可能です。
(Webサーバー、ファイルサーバー、ワークフォルダーは同じサーバーでなければなりません。)
ここではドメインコントローラー、Webサーバー、証明書サービスの役割のインストール方法については省略するので、事前にインストールしておいてください。
なお、Webサーバー(IIS)は、ワークフォルダーの役割をインストールする前にインストールしておく必要があります

 

2.ワークフォルダーの役割インストール

Webサーバー、ファイルサーバーとなっているサーバーにワークフォルダーの役割をインストールします。役割と機能の追加ウィザードから[ファイルサービスと記憶域サービス]-[ワークフォルダー]を追加します。

image

 

3.SSLサイトの実装

既定の設定で作られるWebサーバーのサイトはHTTPのサイトです。ワークフォルダーではSSLサイトが必要になるので、バインドの追加でSSLサイトを作成しておきます。

詳細なSSLサイトの作成手順は省きますが、大まかには次の設定を行っていれば結構です。

・サーバー証明書の追加
・Default Web Siteのバインドの設定でSSLサイトを追加し、追加した証明書を利用するように設定

このとき、SSLサイトで使われる証明書を発行した証明機関(認証局)の情報がワークフォルダーを利用するクライアントコンピューターの[信頼されたルート証明機関]に登録されていることが必須です。そのため、ドメイン参加のコンピューターを対象に使うのであれば、証明機関にはエンタープライズCAを使うことをお勧めします(グループポリシーを通じて自動的に[信頼されたルート証明機関]の情報を書き換えてくれるので)。

 

4.共有フォルダーの設定

ワークフォルダーで使用する共有フォルダーを作成します。

共有フォルダーの作成はサーバーマネージャーの[ファイルサービスと記憶域サービス]-[共有]から[新しい共有]をクリックして作成を開始します。

image

dc072

dc073

WFSyncShareという名前の共有フォルダーを作成します。

dc074

[アクセス許可設定に基づいた列挙を有効にする]にチェックをつけてください。
これにより、他人のワークフォルダーが見えなくすることが可能です。

dc075

ワークフォルダーを利用するユーザーに対する変更アクセス許可を割り当てます。
ここでは全員を意味するAuthenticated Usersグループに割り当てておきます。

dc076

dc077

共有フォルダーの作成が完了したら、続いて共有フォルダーをワークフォルダーとして利用するための設定を行います。

image

cmr2033

サーバー名を選択します。

cmr2034

前の手順で作成した共有フォルダーを選択します。

cmr2035

ここで選択するのは共有フォルダー内に作成される、各ユーザー用のフォルダーの名前の付け方です。

cmr2036

cmr2037

同期を許可するユーザーを選択します。共有フォルダーを作成するときにすべてのユーザーを選択したので、ここでもすべてのユーザーを選択しておきます。

cmr2038

セキュリティの設定です。すみません、ここの設定はまだキャッチアップしていないです。

cmr2039

cmr2040

cmr2041

 

5.グループポリシーの設定

ドメインに参加しているコンピューターの場合、ワークフォルダーの設定はグループポリシーを通じて受け取ることができます。
ワークフォルダーの同期にはWebサーバーのSSLサイトを通じて行われるので、ここではサイトのURLをグループポリシーに登録します。

グループポリシーの編集画面から、[ユーザーの構成]-[ポリシー]-[管理用テンプレート]-[Windowsコンポーネント]-[Work Folders]から[Work Foldersの設定を指定する]を開きます。

image

設定画面で、Work FoldersのURLにSSLサイトのURLを入力します。また、[自動セットアップを強制する]にチェックをつけておけば、クライアント側での初期設定は不要になります。

image

 

6.クライアント側の設定(ドメイン参加PCの場合)

クライアント側の設定はドメインに参加している場合と参加していない場合で異なります。
ここではドメインに参加している場合の設定について確認します。

コントロールパネルのワークフォルダーを開き、

WF1 

グループポリシーの設定を受け取っていれば、初期設定は自動的に行われるので、
最初から以下のような画面が表示されます。

WF2

ワークフォルダーはPC(以前のOSでいうところのマイコンピューター)の中にWork Foldersという名前のフォルダーができるので、このフォルダーにファイルを保存することで、自動的にサーバーの共有フォルダーとの間で同期が行われます。
もちろん、同期はショートカットメニューから手動で行うことも可能です。

WF3

同期が行われると、サーバー側にはユーザーごとにフォルダーを作成し、ファイルを保存します。
それぞれのフォルダーは本人しかアクセスできないようにアクセス許可が設定されています。

WF4

※ちなみにMetadataフォルダーにはEDBファイルが保存されていたので、Active Directoryでおなじみのデータベースの方式を使用してファイルのバージョン管理等を行っているのだと思います。(推測)

 

7.クライアントの設定(ドメイン未参加PCの場合)

ドメインに参加していないPCの場合、グループポリシーから設定を受け取れないので、ワークフォルダーの初期設定を自分で行う必要があります。
初期設定として行うことは大きく分けて2つあり、

1つはSSLサイトで使用する証明書に対する証明機関の情報を[信頼されたルート証明機関]に登録すること、
もう1つはワークフォルダーのセットアップです。

ここでは、ワークフォルダーのセットアップについて紹介しておきます。

コントロールパネルのワークフォルダーから、ワークフォルダーのセットアップをクリックし、

WF5 

ワークフォルダーへのURLと、SSLサイトにアクセスする際の資格情報を入力します。ここで入力した資格情報はワークフォルダーにアクセスするユーザー名になります。

図4

ここまでの設定で出来上がりです。

 

まとめ

ワークフォルダーはWindows Server 2012 R2とWindows8.1の組み合わせでしか、現在のところ利用できないので、普及するまでには相当時間がかかると思いますが、ドメイン参加の有無は関係なく利用できるので、利用可能なデバイス種類が増えてくると利用される機会も多くなるのではないかと思います。SkyDriveやDropboxに代わる、なおかつクラウドを利用しない、安全なストレージ活用方法として覚えておいて損はなさそうです。

すべてのコンピューターにグループポリシーを今すぐ適用

今回は、以前連載をさせていただいていた「Windows Server 2012で始めるActive Directory」の第10回「グループポリシーの効果的な活用」から抜粋・加筆修正し、すべてのコンピューターにグループポリシーを今すぐ適用する方法について紹介します。

■ ■ ■

グループポリシーは基本的に、コンピューターの起動時やユーザーのログオン時などに自動的に適用されるため、私たち管理者としては特に何もする必要はない。しかし、テスト目的で設定した内容を今すぐ適用したい場合や、トラブルシューティング目的で今すぐ適用したい場合もあるだろう。そのときには、「gpupdate /force」というコマンドをコンピューター上で実行し、今すぐグループポリシーを適用という方法があるが、Windows Server 2012またはWindows 8を利用しているのであれば、リモートからgpupdateコマンドが実行できるPowerShellコマンドレット「Invoke-GPUpdate」を活用しよう。

Invoke-GPUpdateコマンドレットは次のように実行する。

Invoke-GPUpdate -Computer <コンピューター名> -Force

複数のコンピューターに対してまとめて実行するときは、次の方法で行う。
(Contoso.comドメインのComputersコンテナにコンピューターオブジェクトが保存されている場合)

Get-ADComputer –filter * -Searchbase “cn=computers, dc=Contoso,dc=com” | foreach{ Invoke-GPUpdate –computer $_.name -force}

なお、このコマンドレットを実行するには、Windowsファイアウォールで以下の規則が有効になっていることが前提となる。

・スケジュールされたリモートタスク管理 (RPC)

・スケジュールされたリモートタスク管理 (RPC-EPMAP)

・Windows Management Instrumentation (WMI受信)

将来的にこの機能を使うことになるのであれば、あらかじめこれらのファイアウォール設定自体もGPOで設定しておけばよいだろう。

画面10-7

 

WMIフィルターの効果的な活用

今回は、以前連載をさせていただいていた「Windows Server 2012で始めるActive Directory」の第10回「グループポリシーの効果的な活用」から抜粋・加筆修正し、WMIフィルターの効果的な活用方法について紹介します。

■ ■ ■

WMIフィルターとは

GPOの設定が完了したら、続いてGPOを適用する対象を決定する。GPOは基本的にOUまたはドメインにリンクすることで適用する対象が決定する。ドメインにリンクすれば、ドメイン内のユーザーまたはコンピューターが対象になるし、OUにリンクすれば、OU内のユーザーまたはコンピューターが対象になるといった具合だ(画面3)。

画面10-3

画面3●ドメインにGPOをリンクしている様子

しかし、実際の運用の場面では、ドメインやOUの括りではない範囲で適用する場合があるだろう。たとえば、ノートPCとデスクトップPCで適用する内容を変更したい場合などが考えられる。そのときには、WMIフィルターを利用することをお勧めする。

WMIフィルターはWMIと呼ばれる、主にハードウェアに関連する情報にアクセスするための機能(インターフェイス)にアクセスし、管理者が定義した条件に一致したユーザー/コンピューターだけにGPOを適用するというものである。WMIフィルターを設定するときは、あらかじめ[グループポリシーの管理]ツールの[WMIフィルター]から条件を設定しておく(画面4)。

画面10-4

画面4●WMIフィルターの設定

WMIフィルターは条件として「Select * From <WMIクラス> Where <条件>」のように記述する。たとえば、日本のタイムゾーンを使用しているコンピューターだけにGPOを適用したい場合なら、

Select * From Win32_TimeZone Where Bias = 540

と記述する。

このとき、問題になるのは自分の設定したい項目をどうやって探せばよいか?ということである。WMIは「WMIクラス」と呼ばれるジャンルと、プロパティと呼ばれる項目から構成されている。まず、WMIクラスとしてどのようなものがあるか調べるときは、Windows PowerShellから「Get-WmiObject -list」というコマンドレットを実行する。すると、WMIクラスの一覧が表示されるので、その中から自分が求めているであろうWMIクラスの名前を探す。

続いて、使用するWMIクラスの中にあるプロパティを探すときは、同じくWindows PowerShellから「Get-WmiObject -Class <クラス名>」というコマンドレットを実行する。すると、利用可能なプロパティが表示される。たとえば、画面5のようにWin32_TimeZoneクラスで利用可能なプロパティを表示すると、タイムゾーンはBiasというプロパティであらわされることが確認でき、また値が540だと日本のタイムゾーンを表していることがわかる。

画面10-5

画面5●Get-WmiObject -Class Win32_TimeZoneコマンドレットを実行した様子

こうして出来上がったWMIフィルターはリンクしたGPOの[WMIフィルター処理]で設定すれば完了だ(画面6)。

image

画面6●WMIフィルターをGPOに設定した様子

参考までに、よく使われることが予想されるWMIフィルターをいくつか紹介しよう。

-デスクトップPCだけにGPOを適用

Select * From Win32_SystemEnclosure Where ChassisTypes >= 3 and ChassisTypes <=7

(ChassisTypesが3,4,5,6,7の場合はデスクトップPC)

-仮想マシンだけにGPOを適用

Select * From Win32_NetworkAdapter Where ServiceName = “netvsc”

グループポリシーでSkyDriveを利用できないようにする

Dropboxと同様に、会社ではオンラインストレージであるSkyDriveの利用を禁止しているところもあると思います。Dropboxの場合にはWindowsアプリケーションのインストールを制限すれば、それだけでもDropboxの利用を(ある程度)抑制することができますが、SkyDriveの場合には最初からアプリケーションがインストールされてしまっているので、意図的でないにせよ、使ってしまう人が出てくる可能性があります。私の場合、Windows 8 OSに対してはAutorunsというツールを使ってスタートアップからSkyDriveが起動しないように設定して対処していましたが、Windows 8.1ではそんな面倒なことをしなくても、グループポリシーから設定できるようになりました。

設定はグループポリシー管理エディターから[コンピューターの構成]-[ポリシー]-[管理用テンプレート]-[Windowsコンポーネント]-[SkyDrive]から[ファイルの保存にSkyDriveを使用できないようにする]を有効にすることでSkyDriveが使えなくなります。

image

制限がかかるとコンピューターは次のような画面になります。

image

グループポリシー管理エディターの説明書きには主にこんなことが書いてあります。

・ファイル名を付けて保存でSkyDriveを選択できない
・Windowsストア アプリからSkyDriveを利用できない
・エクスプローラーのナビゲーション(画面左側のメニューのことです)に
SkyDriveが表示されない
・SkyDriveはクラウドとの同期が行われなくなる
・カメラロールのフォルダー写真やビデオが自動アップロードされなくなる

SkyDriveは個人で使うにはとても便利な機能ですが、企業ではセキュリティのコントロールが難しくなります。代替の方法として、Office365のSkyDrive ProやWindows Server 2012 R2との組み合わせで利用できるワークフォルダー機能などを活用することが想定されますが、それでもSkyDriveの機能自体がWindows 8.1からなくなるわけではありません。企業でWindows8.1を使うときには必須の設定になりそうですね。

 

グループポリシーのクライアントサイド拡張(CSE)

今日は、先日あるお客様よりご質問をいただいた、
グループポリシーのクライアントサイド拡張(CSE)について紹介します。

通常、クライアントコンピューターがドメインコントローラーからGPOを受信するとき、
クライアント側のグループポリシーエンジン(Group Policy Clientサービス)が処理をしますが、
GPOの特定の項目だけは、グループポリシーのクライアントサイド拡張(CSE)と呼ばれるコンポーネントが処理を担当します。

 

主なCSEには、

・Group Policy Software Installation Client-Side Extension
(ソフトウェアインストールの項目を担当)

・Group Policy Scripts Client-Side Extension
(ログオン/ログオフスクリプト等の項目を担当)

・Group Policy Registry Client-Side Extension
(管理用テンプレートの項目を担当)

・Group Policy Preference Client-Side Extension
(グループポリシーの基本設定の項目を担当)

などがあります。

その他、どのようなCSEがあるかについては、
@ITさんで紹介されているので、ご覧ください。

■@IT Windows基礎解説 グループポリシーのしくみ
http://www.atmarkit.co.jp/fwin2k/tutor/gpolicy02/gpolicy02_05.html

 

こんなことを知っていて何の役に立つかといえば、やはりトラブルシューティングだと思います。
CSEにこのようなものがあるということを知っていれば、
グループポリシーのトラブルで「一部のグループポリシー項目だけが適用されない」 なんていうのが
ある場合、いずれかのCSEが処理していないのではないか、と考えることができるからです。

CSEの処理結果を見ながらトラブルシューティングを行う方法は、いくつかあるようなのですが、
ここでは、CSE関連のイベントログがイベントビューアに記録されることに着目し、
イベントログを参照する方法を紹介したいと思います。

イベントビューアのGroup Policyログではなく、アプリケーションログに表示されます。

■Group Policy Software Installation Client-Side Extension
グループポリシーによるソフトウェアのインストールを担当するCSEで
インストールの処理に失敗するときには、イベントID101~308のログが表示される場合があります。

・詳細 – Software Installation Processing
http://technet.microsoft.com/ja-jp/library/cc727267(en-us,WS.10).aspx

■Group Policy Scripts Client-Side Extension
ログオン/ログオフ/スタートアップ/シャットダウンのスクリプト実行を担当するCSEで
スクリプト実行に失敗するときには、イベントID 1130のログが表示される場合があります。

・詳細 – Group Policy Scripts Processing
http://technet.microsoft.com/ja-jp/library/cc727287(en-us,WS.10).aspx

■Group Policy Registry Client-Side Extension
グループポリシーの[管理用テンプレート]内の項目の処理を担当するCSEで
レジストリの書き換え等に失敗するときには、イベントID 1096のログが表示される場合があります。

・詳細 – Group Policy Registry Processing
http://technet.microsoft.com/ja-jp/library/cc727308(en-us,WS.10).aspx

■Group Policy Preference Client-Side Extension
グループポリシーの[基本設定]内の項目を処理するCSEでイベントIDの…
と書こうとしたのですが、残念ながら、どのようなイベントIDが出力されるのか
現時点ではわかりませんでした。

これらのログは、以前の投稿
イベントビューアからグループポリシーのトラブルシューティングを行う」でも紹介したように、
イベントビューア Group Policy ログのイベントID4016が記録された後に、
個々のCSEの処理が始まりますから、そのことも併せて頭に入れておくと
グループポリシー処理の流れを立体的に捉えることができるかと思います。

 

クライアントコンピューターが受信したGPOはレジストリにも記録されるので、
最後にGPOを受信したのがいつか?などについて、レジストリから参照することで 
トラブルがいつ発生したかなどの状況を把握することもできるようになります。
これについては@ITさんの記事の中で紹介されていたので、参考にするとよいと思います。

■@IT グループポリシーの最終適用日時をレジストリから取得する
http://www.atmarkit.co.jp/fwin2k/win2ktips/1127gptime/gptime.html

また、@ITさんで紹介されているレジストリ項目のほか、HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
または
HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
の配下から確認することも可能です。

CSE1
画面1 レジストリからCSE処理の状況を確認

Historyキーの配下にある文字の羅列はCSEのGUIDを表しており、各GUIDは前述の@ITさんの記事から
確認できます。また、GUIDの配下にある、0とか1などという数字は、そのCSEの処理をどのGPOを
利用して行ったかを確認できます。たとえば、画面1では「1」と数字をクリックすると、画面の右側に
Default Domain Controllers Policyから受信したことが表示されています(DisplayName値に表示)。

追伸
CSEについては、マイクロソフトの資料でこんなものもありました(英語)。
http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-GPAC%5D.pdf

Network Location AwarenessサービスによるGPO適用処理を確認する

 
2月1日、関東では雪が降ったようですね。
いつもと違った景色を眺めたい、と思っていたのですが、
私は現在、出張で大阪に。
雪景色を見ることなく、終わってしまいそうです。
 
 
今日はNetwork Location Awareness(NLA)サービスとトラブルシューティングについてです。
 
NLAサービスはVista/Windows Server 2008からサポートされているサービスで
ネットワークの接続状態に合わせてグループポリシーの適用(更新)管理を行う、クライアント側のサービスです。
 
NLAサービスは、pingを使わない低速リンクの検出方法を提供するほか、
ネットワークの状態に合わせたグループポリシーの更新処理を行います。
具体的な処理としては、ドメインコントローラーから切断されたクライアントが、
もう一度接続すると、接続したタイミングで(実際には少しタイムラグがありますが..)
自動的にグループポリシーの更新が始まるというものです。 
 
実際に、ネットワークが切断/接続されている状態を再現し、
その際、どのようなイベントログを残すのか、確認してみました。
 
■ネットワーク接続が失われている状態
グループポリシーの更新処理が始まると、以下のログが
イベントビューアのGroupPolicyログに出力されます。
 
順番 イベントID 説明
1 4004 ポリシーの手動処理の開始 (gpupdateで処理を開始した場合)
2 5320 アカウント情報を取得しようとしています
3 4017 アカウント情報を取得するためにシステムコールを実行しています
4 7017 呼び出しが失敗しました
 
 
 
イベントID4004はgpupdateでコンピューターポリシーの更新を行った場合に出力されるログ、
イベントID4005はgpupdateでユーザーポリシーの更新を行った場合に出力されるログです。
ですので、ネットワーク接続が失われているときに、gpupdate /forceコマンドを実行すると、
4004から始まり、7017のエラーにたどり着く、一連のログと、
4005から始まり、7017のエラーにたどり着く、一連のログがそれぞれ出力されます。
 
これらの処理が複数回繰り返された後に、最終的にイベントID7004(コンピューター)、7005(ユーザー)のログを
出力し、グループポリシーの更新に失敗したことを告げます。
 
 
■ネットワーク接続が回復した状態
ネットワーク接続が回復すると、以下のログが出力されます。
 
順番 イベントID 説明
1 5320 ネットワーク状態の変更が検出されました
2 4003 ユーザーの状態が変更されたため、ポリシーの処理を開始しています
3 5320 アカウント情報を取得しようとしています
4 4017 アカウント情報を取得するためにシステムコールを実行しています
5 5017 呼び出しが完了しました
 
イベントビューアでは、下図のように表示されます。
 
(一部画像が乱れています)
 
この一連の処理は、コンピューターに関しても同様に行われます。
 
順番 イベントID 説明
1 5320 ネットワーク状態の変更が検出されました
2 4002 コンピューターの状態が変更されたため、ポリシーの処理を開始しています
3 5320 アカウント情報を取得しようとしています
4 4017 アカウント情報を取得するためにシステムコールを実行しています
5 5017 呼び出しが完了しました
 
ここまでが完了すると、本格的なポリシー更新処理に移ります。
ここから先の追跡処理については、ActivityIDを参考に追跡すると良いと思います。
(ActivityIDをもとにしたグループポリシーイベントの追跡方法については、
 
 こうした動作を把握しておけば、クライアント側でグループポリシーの更新が適切に行われているか、
などを確認することができますね。
 

グループポリシー「基本設定」のトラブルシューティングを行う

Windows 2000の登場当時から比べると、Windows Server 2008 R2では
本当にグループポリシー設定項目が増えましたね。
ぼーっと、グループポリシーオブジェクトを眺めているだけでも、飽きることがありません。
(どんなヒマつぶしだよ!)

Windows Server 2008のグループポリシーから、「基本設定」というGPOのカテゴリが新設されました。
昔はログオンスクリプトやログオフスクリプトとして、
bat拡張子のバッチファイルやvbs拡張子のスクリプトファイルなどを作成して、割り当てなどという操作を行っていました。
そのバッチファイルなどで作成しなければならなかった設定をGUIの画面だけで設定できるようにしようというのが
GPOの「基本設定」です。

新しい機能で、便利であることは間違いないのですが、
実際に管理する立場からすれば、「トラブルシューティングはどうやって行うの?」という疑問があります。

そんなことを思いながら、GPOの設定項目に目をやると、基本設定のログ/トレースなんていう機能を見つけました。
そんなわけで、今日は基本設定のログ/トレース機能を使ってみたいと思います。

–基本情報って何?という方のための参考情報–
グループ ポリシーの基本設定による管理範囲の拡大
http://technet.microsoft.com/ja-jp/magazine/2009.01.gpprefs.aspx

基本設定のログ/トレース機能は、GPOの
[コンピューターの構成]-[ポリシー]-[管理用テンプレート]-[システム]-[グループポリシー]-[ログおよびトレース]
という、すっごい奥まで探検すると、たどり着けます。

ご覧のとおり、基本設定の項目ごとに、ログおよびトレースの構成が用意されています。
そのため、実際にトラブルシューティングを行いたい基本設定項目だけログやトレースの設定を有効にしておけば、
膨大なログの中から探す、という大変な作業が少しは軽減できると思います。

そして、設定画面がこちら。

画面左上で、「有効」を選択すると、該当項目のログとトレースの設定が有効になります。
ログについては、「イベントログ」の部分で出力レベルを設定します。
また、トレースについては、「オン」にすれば、
ユーザートレース、コンピュータトレース、計画トレースのいづれかが記録されます。

今回は、ファイルの基本設定で、c:\test.txtファイルを削除するという設定を
GPOの中に入れておきました。
実際に、グループポリシーを適用させ、ログを見てみます。

ログは、イベントビューアのGroup Policyのログの中で記録されます。
基本設定の処理が成功すると、イベントID4096で記録されます。

もう一度、GPOを実行します。
すると、今度は存在しないファイルを削除しようとするので、処理は失敗します。
このときのイベントログはこちら。

どちらのイベントも、Group Policy Filesという名前のソースで生成されます。

一方、トレースはGPOで設定したパスにファイルが作られます。
(下の図は実際にファイルを削除する処理を行った様子を表すトレースログ)

このような詳細なトレースログを使えれば、トラブルシュートの強力な武器となるでしょう。

ところで、GPOでトレースの設定を行うとき、注意しなければならないことがあります。
それは、トレースファイルが生成されるデフォルトのパスが実在しない場所をさし示しているという点です。
デフォルトのパスは、%COMMONAPPDATA%\….なのですが、このパスは利用できません。

%COMMONAPPDATA%変数は、c:\documents and settings\all users\Application Dataを表すパスで、
Windows VistaやWindows 7などの最近のOSはこのパスを持っていません。
そのため、%COMMONAPPDATA%変数も使われておらず、そのままトレースするように設定すると、
パスが存在せず、ファイル生成に失敗します。

そのため、代わりにc:\users\publicなどのパスを利用するとよいでしょう。