前回、Computerworld.jpさんで書かせていただいたActive Directoryの連載を加筆修正して紹介させていただきました。前回の内容には続きがありますので、今日はWindows Server 2012におけるActive Directoryの変更点 Part2を紹介します。
■ ■ ■
変更点その5： dcpromoを利用しない、Active Directoryのインストール
今までActive Directoryドメインサービス(以下、Active Directory)のインストールと言えば、dcpromoであった。ところが、Windows Server 2012からは長年親しまれてきたdcpromoがなくなり(正確には互換性のためだけに残されている)、
代わりに次のステップでActive Directoryをインストールする。
1．サーバーマネージャーの[役割と機能の追加]よりActive Directoryドメインサービスの役割を追加
画面1●[役割と機能の追加ウィザード]より[Active Directoryドメインサービス]を選択してインストールする
2．サーバーマネージャーの[配置後の構成]からActive Directoryドメインサービス構成ウィザードを実行し、
ドメインコントローラーをインストール
画面2●役割の追加後、サーバーマネージャーの旗印をクリックすると、[配置後の構成]が現れる
面倒な手順に変わったように思うかもしれないが、今までのOSで利用してきたdcpromoプログラムは2つのステップを同時に実行するプログラムであっただけで、そもそも2つのステップを踏むこと自体、今までのOSと同じなのである。
それでも、dcpromoのようにコマンドから実行したいというときは、dcpromoコマンドの代わりにWindows PowerShellコマンドレットによって、Active Directoryをインストールする方法をサポートしている。それぞれのステップは次のコマンドレットを実行する。
1．[Active Directoryドメインサービス]の役割の追加
Install-WindowsFeature –Name AD-Domain-Services,GPMC –ComputerName localhost –IncludeManagementTools -Restart
2．[配置後の構成]で実行するドメインコントローラーのインストール
Import-Module ADDSDeployment
Install-ADDSForest -CreateDNSDelegation:$false -DatabasePath “c:windowsntds” -DomainMode “Win2012” -DomainName “example.com” -DomainNetbiosName “example” -ForestMode “Win2012” -InstallDNS:$true -LogPath “c:windowsntds” -NoRebootOnCompletion:$false -SysvolPath “c:windowssysvol” –Force:$true
なお、Install-ADDSForestコマンドレット実行時のオプションは、GUIから実行するActive Directoryドメインサービス構成ウィザードの最後のページにウィザード内で選択した内容が表示されるので、これをコピーしてPowerShellで実行すれば、GUIでActive Directoryドメインサービス構成ウィザードを実行するのと同じインストールが行える(画面3)。
画面3●Active Directoryドメインサービス構成ウィザードの最後のページにウィザード内で選択した内容がスクリプトとなって表示される
変更点その6：ドメインコントローラーの前提条件チェック
配置後の構成ウィザードで各種設定を行い、インストールを開始すると、最初にドメインコントローラーの前提条件チェックを行う。この前提条件チェックのみを行うのがTest-ADDSDomainControllerInstallationコマンドレットである。
Test-ADDSDomainControllerInstallationコマンドレットでは、ドメインコントローラーを新しくインストールする際に前提条件を満たしていることを事前に確認できるので、ドメインコントローラーはまだインストールしないが、インストールを行った時に問題が起こるかについて事前に確認しておきたい場合に利用するとよいだろう。
同様に、Test-ADDSDomainInstallationコマンドレットではドメインの前提条件、Test-ADDSForestInstallationコマンドレットではフォレストの前提条件をそれぞれ確認できる(画面4)。
画面4●Test-ADDSForestInstallationコマンドレットを実行した様子
変更点その7：フォレスト機能レベル/ドメイン機能レベルでWindows 2000をサポートしない
Windows Server 2012では、フォレスト機能レベル/ドメイン機能レベルでWindows Server 2003からWindows Server 2012までを選択することができる。言い方を換えると、Windows 2000 Serverをサポートしないということである。既存のドメインにWindows Server 2012を追加することを検討している場合は事前にWindows 2000 Serverのドメインコントローラーをアップグレードしておこう。
変更点その8：adprepはActive Directoryドメインサービス構成ウィザードに統合
以前のバージョンのActive Directoryでは、新しいバージョンのActive Directoryと共存させる際、adprepというコマンドを実行して事前にスキーマ拡張などを行っていた。Windows Server 2012では、adprepがActive Directoryドメインサービス構成ウィザードに統合され、Active Directoryドメインサービス構成ウィザードを実行することでadprepコマンドの処理を自動的に行われるようになった。adprepの処理とActive Directoryドメインサービス構成ウィザードを別々に実行したい場合には、Windows Server 2012でも用意されているが、adprep自体は64ビット版のプログラムのみが提供されているので、既存のドメインコントローラーで実行できない可能性があることに注意したい。
(追記：adprepが統合され、自動的に実行される理由について、MCTの憂鬱さんで紹介しています。)
変更点その9：仮想化されたドメインコントローラーの追加
Windows Server 2012では仮想マシン上に実装するActive Directoryドメインコントローラーに対する機能強化を図っている。その最たるものが仮想化されたドメインコントローラーの追加機能である。仮想環境で複数のドメインコントローラーを作成するとき、既存のドメインコントローラーをコピーすることで簡単に新しいドメインコントローラーを作成できるというものである。今まで、既存の仮想マシンでSysprepというプログラムを実行することで新しい仮想マシンを作成することができたが、Sysprepはドメインコントローラーでは利用することができなかった。仮想環境で多くのドメインコントローラーを実装しなければならないときに活用することが想定される。
(追記：仮想化されたドメインコントローラーの追加方法については、Windows Server 2012 Community Day 第4回で紹介させていただいておりますので、ご興味があればご覧になってみてください。)
画面5●コピー元となる仮想マシンのコンピューターアカウントはCloneable Domain Controllersグループに登録しておく
その他、Active Directoryでは、以下のような変更がなされているので、代表的なものをまとめてご紹介しよう。
変更点その10：Active Directoryを利用したライセンス認証の実装
KMS(Key Management Services)経由で行われていたクライアントPCのライセンス認証をActive Directory経由で行うように実装したものがActive Directoryベースのライセンス認証である。Windows ADK(Assessment and Deployment Kit)の中に含まれるVAMT (Volume Activation Management Tool)からライセンス認証のための設定を行う。現時点では、Windows 8とWindows Server 2012のみがActive Directoryベースのライセンス認証を利用できる。
変更点その11：DirectAccess経由でのドメイン参加
IPv6を利用してインターネット経由でサーバーとクライアントを接続するためのテクノロジーとしてDirectAccessをWindows Server 2008 R2から提供しているが、Windows Server 2012ではその要件が緩和され、DirectAccessで接続された、離れた拠点にあるActive Directoryドメインコントローラーに接続してドメイン参加することができるようになっている。この結果、ドメインコントローラーのない拠点にあるクライアントコンピューターでも、ドメイン参加が簡単にできるようになっている。
変更点その12：グループの管理されたサービスアカウント
サービスの起動のために使われるサービスアカウントはLocalSystemやNetworkServiceなどの既定で用意されているものに加え、Windows Server 2008 R2から管理者自身が専用のサービスアカウントを作成できるようになっていた。しかし、管理者が作成したサービスアカウントは単一のコンピューターのみで利用可能であり、サービスアカウントの権限を利用して他のサーバーにアクセスすることはできなかった。そこで、Windows Server 2012ではグループの管理されたサービスアカウント(Group Managed Service Accounts以下、gMSA)を新設し、コンピューター間におけるサービスのやりとりに管理者定義のサービスアカウントを利用できるようにした。gMSAは主に負荷分散された環境やクラスタ環境で動作するサービス用のサービスアカウントとして利用することを想定している。
細かくはまだまだ変更点があるのですが、大きな変更点としては以上になります。
次回、様々な変更点の中からダイナミックアクセス制御について紹介するので、お楽しみに。
