グループポリシーは簡単には元に戻せない

ほとんどのグループポリシーは、[未構成]と[有効]と[無効]の3つから選ぶ形になっていて、初期値は[未構成]です。

グループポリシーを設定する場合は、これを[有効]か[無効]に変更する訳ですが、ここで気をつけないといけないことがあります。

それは、一度クライアントPCに適用されたグループポリシーは、簡単には元に戻せないということです。

普通に考えれば、[有効]か[無効]に変更したポリシーを[未構成]に戻すだけでいいのではないかと思えます。しかしどうやら、そうではないようなのです。

一例として、ポリシーAを[有効]に設定して、それを全クライアントPCに浸透させた場合を考えてみます（浸透という言い方は嫌がられることが多いみたいですが、私は気に入ってます）。

これをすると、ポリシーAに対応するクライアントPCのレジストリ値aが、[有効]の設定で上書きされることになります。この時、レジストリ値aの設定が元々どうだったのかは、クライアントPCでは記憶してくれていないようなのです。

記憶してくれていないので、ポリシーAを[未構成]に戻したところで、レジストリ値aが元に戻ることはありません。[有効]のままとなってしまいます。

これを元に戻すには、一度ポリシーAを[無効]に設定して、それが全クライアントに浸透した頃を見計らってから、ポリシーAを[未構成]にするという手順が必要になります。

しかし、この手順には問題があります。例えば100台のコンピュータがあるドメインにおいて、そのうち50台はレジストリ値aを[有効]にしていて、残り50台は[無効]にしていたとしたら、どうでしょう。

この場合、ドメインコントローラ側でどうグループポリシーをいじったとしても、どちらか半分の50台の設定は変わってしまうことになります。それを直すには、手作業で一台一台変えていく他ありません。

こういった事情を踏まえて考えると、グループポリシーを変える時はより慎重に、出来ることならテスト環境などを準備して、そこで十分なテストをしてから適用したほうがいいと言えるでしょう。



……ただ、個人的に少し不満を言わせてもらうと、グループポリシーなんていうかなり古くから存在する機能において、こんな不可逆で不便な仕様になっているというのは、ちょっと納得いきません。[未構成]の時の状態をクライアントPCにしっかり残しておいてほしいものです。言っても詮無いことですが。

グループポリシーをユーザーグループに適用できない原因

WindowsServerでユーザーのグループに対してグループポリシーを割り当てたい時って、あると思います。

普通に考えれば、GPO（グループポリシーオブジェクト）の[スコープ]タブの[セキュリティ処理]に、そのユーザーグループを追加するだけでいいんじゃないかと考えます。

しかし私がそれをしてみたところ、GPOのアクセス拒否とかなんとかで、適用されませんでした。

色々思考錯誤してみたところ、どうやらスコープにユーザーグループを追加する他に、[委任]タブにユーザーグループの上位に当たるもの（Usersとか）を追加しないといけないようです。

ちなみに、[スコープ]へUsersそのものを追加した場合（つまり全ユーザーへグループポリシーを適用する場合）は、自動的に[委任]のほうへもUsersが追加されるので、この手順は必要ありません。

もちろん、ユーザーのグループを[スコープ]へ追加した場合にも、同じようにそのグループは[委任]のほうへも追加されているのですが、なぜかグループに委任をしてもアクセス権限的には効果がないようで……この辺りの理屈は、私自身もまだよくわかっていません。

何にせよ、GPOの[スコープ]にユーザーのグループを追加する時は、[委任]にUsersを追加する、と覚えておけば良さそうです。

そもそもの話というか、私が色々なWeb記事を読み漁ったところでは、ユーザーのグループにグループポリシーを割り当てる手順というのが丁寧に書かれた記事は、あまり見当たりませんでした。

もしかしたら、一部のユーザーにグループポリシーを割り当てたい場合は、OU（オーガニゼーションユニット：組織単位）を使用するほうが一般的な手法なのかもしれません。こちらのやり方なら、あちこちに参考記事が見つかりました。

確かにOUでポリシーを割り当てたほうが、グループポリシーの管理画面でも階層別に分けられて、視覚的に分かりやすくなる気がします。ユーザー構成的に融通がきくようであれば、グループをOUに置き換えてもいいかもしれません（グループじゃないと出来ない分け方もあるとは思いますが……）。

WindowsServerとMSAccessは相性最悪

WindowsServerでフォルダーリダイレクトとオフラインファイルを併せて使用すると、デスクトップなどのファイルがリアルタイムでサーバ上へ保管されるようになります。

これは大変便利で使い勝手の良い機能なのですが、これを有効にしてしまうとMicrosoftAccessは極端に使い辛くなるというデメリットがあります。

MicrosoftAccessは、中小企業向けに作られたデータベース管理システムです。中小企業向けなので、データ通信のパフォーマンス効率はあまり良くありません。言い方を変えると、頻繁にたくさんのデータをやり取りするのです。

MicrosoftAccessのこの仕様を理解しているユーザーは、MicrosoftAccessファイルをローカル領域にコピーしてから使用することがよくあります。ローカル領域とはつまり、デスクトップなどのことです。

しかし、フォルダーリダイレクトとオフラインファイルを併せて使用している場合、デスクトップはサーバ上の領域という扱いになります。デスクトップにMicrosoftAccessファイルをコピーして使用しても、サーバで使用しているのとまったく同じ、遅い動作になってしまうのです。

だからと言って、同期センターでデスクトップをオフラインモードに変更してしまうと、MicrosoftAccessは最適化が出来なくなります。これについては、Microsoftサポートページにもはっきりと「仕様による動作です」と明記されています。
https://support.microsoft.com/ja-jp/help/2834831

もちろん、デスクトップをオンラインで使用するのなら、最適化は問題なく成功します。しかしこれでは前述の処理速度の問題が解決しません。

また、オフラインファイルの機能を使用していると、MicrosoftAccessを開いたり閉じたりした際に「別のユーザーが使用しているため保存できません」という旨のエラーメッセージが出て、そして実際に保存できていないという事象が頻繁に発生するようです。

これらのことを総合的に考えると、MicrosoftAccessを使用するためにはオフラインファイルは使用してはならないという結論に落ち着きます。MicrosoftAccessによるシステムを導入する際には、必ず念頭に置いておきたい事柄です。

これらの問題に対する解決策として、フォルダーリダイレクト+オフラインファイルの代わりに移動ユーザープロファイルを使うという手があります。

リアルタイムで同期を行うフォルダーリダイレクトとは違って、移動ユーザープロファイルはログオン/ログオフの時にしか同期をしません。また、OSのバージョンが変わるとユーザープロファイルが引き継がれないという問題があります。

この2点にさえ目をつぶれば、移動ユーザープロファイルでもある程度の要件は満たせます。MicrosoftAccessがどうしても外せないのであれば、こちらも検討の余地があるのではないでしょうか。



【2018/01/11　追記】

MicrosoftAccessはDFSレプリケーションとも相性が悪いことが分かりました。

レプリケーションの真っ最中にファイルを開いたり閉じたりすると「…は、既に使用されているので、使用できません。」というエラーメッセージが表示されて、度々最適化に失敗します。

レプリケーションのスケジュールを編集して、MSAccessを使用していない時にレプリケーションするように調整すれば、この問題は回避できます。

しかし前述の問題にしてもそうですが、どうもMicrosoftさんから「複雑なネットワークを構成するならMSAccessはやめなさい」と言われているような気がしてなりません。

2台目のDHCPサーバをインストール・開始するには

WindowsServerで冗長構成にしたい場合、DHCPではフェールオーバー（フェイルオーバー）という設定を行います。

フェールオーバーの設定をするには、前提条件として両方のサーバのDHCPサービスが開始されている必要があります。

しかしWindowsServerの仕様上、1台目のDHCPサーバが稼働しているドメイン内で、2台目以降のサーバにDHCPをインストールしたりサービスを開始することはできません。それをしようとした場合、「別のサーバー 192.168.x.x を検出しました」というようなエラーが記録されます。

この問題を回避するには、2台目のサーバを一度ドメインから切り離さなくてはなりません。私の場合、2台目のサーバからLANケーブルを引き抜くことで対処しました。

順序立てて説明すると、次のようになります。

① 1台目のサーバでDHCPを構成する（スコープなどもすべて設定しておく）

② 2台目のサーバにWindowsServerをインストールして、DHCP以外の構成は済ませておく。このとき、もちろんドメインには参加する

③ 2台目のサーバのLANケーブルを引き抜く

④ 2台目のサーバで[役割と機能の追加]を使ってDHCPをインストールする

⑤ DHCPサービスが正常に開始されていることを確認してから、LANケーブルを接続する

⑥ フェールオーバーの設定をする

注意点として、⑤でLANを繋いでから⑥でフェールオーバーが完了するまでの間、DHCPは機能しなくなります。

それはつまり、ドメイン内の固定アドレスを割り振られていないクライアントPCはすべてネットに繋がらない状態になるということです。

また、フェールオーバー構成では、サーバを再起動する際にも注意が必要です。

ActiveDirectoryの大抵のサービスは、OSを立ち上げると自動的に開始されます。

しかしDHCPサービスは、1台目のサーバが存在するせいで2台目がサービス開始できないという現象が起こります。

これも上記の手順とほぼ同じように、LANケーブルを抜いてから手動でサービスを開始するという手順が必要になります。

① サーバを再起動する

② LANケーブルを引っこ抜く

③ [サービス]でDHCPServerを開始する

④ LANケーブルを接続する

再起動の場合は、フェールオーバーの設定は必要ありません。LANを繋ぐだけです。LANを繋いだときにクライアントPCがネットに繋がらなくなることもありません（多分）。

再起動後にこの手順を行わなかったとしても、DHCPサービスそのものは1台目のほうで正常に稼働し続けます。単にフェールオーバーが機能しないだけであり、1台目が動き続ける限りは問題ありません（これも多分）。



◆ 注意書きという名の保険 ◆

私はインフラ専門のエンジニアではありません。

サーバ構築を始めてから1カ月程度なので、ここに書いたやり方が正しいやり方なのかどうかもよくわかっていません。

正直言って、このLANを引き抜くというやり方には自分でもかなりの雑味を感じています。コンセントを抜いてシャットダウンするのに近いレベルのことをしているのではないかという不安が拭い去れません。

しかし、私が数時間Web上を彷徨って調べた範囲では、2台目のDHCPサーバをインストールしてサービス開始する方法はどこにも書かれていませんでした。フェールオーバーの解説をする記事には、まるで出来て当たり前のことのように「DHCPをインストールします」とだけ書かれていました。

私自身が、エラーの内容から独自に試行錯誤した末に辿り着いたのが、上記のやり方です。もし、これよりももっとスマートに、例えばリモートデスクトップ接続による操作だけで再起動できる方法などをご存知の方がおられましたら、教えていただけると大変助かります。