第14回 Windows Server 2012 R2プレビュー版の新機能と削除された機能：Windows Server 2012クラウドジェネレーション
次期Server OSであるWindows Server 2012 R2のプレビュー版の機能解説の第2回。今回は、追加／削除された役割と機能についてまとめる。PowerShell 4.0の重要な新機能であるDSCについても解説する。
2013年6月に次期Server OSである「Windows Server 2012 R2」の情報が公開され、Preview版の配布も始まった。前回はWindows Server 2012 R2 Preview版の概要について紹介したが、今回はその続きとして、追加または削除されたサーバ役割／機能について見ていく。また、PowerShellに追加された非常に有用な新機能である「DSC（Desired State Configuration）」についても簡単に解説する。
追加された「役割」
Windows Server 2012 R2の新機能を素早く知るには、サーバ・マネージャで役割や機能の追加画面を見るとよいだろう。まずは役割の設定画面を見てみよう。以下は、「役割と機能の追加ウィザード」で役割の一覧を表示させたところである。
追加されたサーバの「役割」
新しく役割が2つ追加された（削除は特になし）。
（1）Essentialsエディションの管理ツールや機能などを追加できる。
（2）Work Foldersは、いわゆるBYODを可能にするための機能。クライアントのWindows 8.1と組み合わせて使う。
追加された役割としては次の2つがある。
●「Windows Server Essentials エクスペリエンス」役割
これは前回触れたように、Windows Server 2012 R2にWindows Server Essentialエディション相当の機能を追加するための役割である。Windows Server 2012やそれ以前のServer OSでは別エディションとして分かれていたEssentialsであるが、Windows Server 2012 R2では追加の「役割」の1つとしても提供される（同時に別個のエディションとしても引き続き提供される）。Essentialsエディションでのみ提供されていた「ダッシュボード」のような、簡単なサーバ管理ツールなどがそのまま使えるので、小規模な組織では有用だろう。
●「Work Folders」役割
これは、クライアントOSであるWindows 8.1（現在はPreview版が提供されている。「GUIを改善したWindows 8.1 Preview」参照）と組み合わせて利用する機能である。Work Foldersを使うと、Windows Server 2012 R2のファイル・サーバ上に置いたファイルを社内から利用するだけでなく、インターネットを介して社外や自宅からでも利用できるようになる。いわゆる「BYOD」を実現するためのものである。SkyDriveのようなインターネット・ストレージ・サービスと機能を提供するものだが、パブリックなサーバではなく自社のサーバを使って実現するので、セキュリティやコスト、容量なども自由に設定／管理できる。単にファイル・サーバをインターネット向けに公開するのではなく、ローカルのPC（Windows 8.1）上のコピーと自動的に同期させたり、セキュリティを確保する機能などが含まれる。この機能の詳細については、今後回を改めて解説する。
追加／削除された「機能」
次は「機能」の選択画面を見てみよう。ここではいくつかの機能が追加／削除されている。
追加されたサーバの「機能」
新しく役割が3つ追加された一方で、以前から非推奨扱いだった2つの機能が削除されている。
（1）ゲームなどで通信用に使われるDirectPlayはオプションとなった。ただしServer OSではあまり関係ないだろう。
（2）このWindows Server 2012 R2 PreviewではまだSMB 1.0がサポートされているが、将来は使えなくなる予定。
（3）SMBプロトコルで使用する帯域を制限する機能。
（4）PowerShellの新機能DSCにおいて、設定ファイルを中央のサーバで集中して管理する場合に利用する機能。詳細は後述。
●削除された機能
この選択画面では、以下の2つの機能が削除されている。いずれもWindows Server 2012の時点で「非推奨（将来廃止される可能性がある）」と告知されていたものである（連載 第2回「新しいサーバ・マネージャの使い勝手を計る」参照）。
- UNIX ベース アプリケーション用サブシステム（SUA）
- Windows システム リソース マネージャー
UNIX互換環境を提供するSUA機能は（TIPS「UNIX互換環境を実現するSUAを利用する」参照）、Windows Server 2012 R2では廃止されることになった。必要なら仮想マシン上にUNIXやLinuxなどをインストールして利用することが推奨されている。
Windowsシステム・リソース・マネージャは、プロセスやユーザー、（ターミナル・サービスの）セッションなどに、それぞれどれくらいのリソース（CPUやメモリなど）を割り当てるかを制御するための機能である。最近ではHyper-Vのような仮想化環境の利用が進み、単一OS内でのリソース管理があまり意味を持たなくなってきたためか、Windows Server 2012 R2では廃止されることになった。必要なら、Hyper-Vの仮想マシンでリソース管理ができるので、そちらを利用する。
●追加された機能
次の2つの項目はメニュー上で新しく追加されているが、これはWindows Server 2012 R2で新しく機能が追加されたわけではなく、将来廃止する予定なので、明示的にオフにできるように用意されたものである。
■Direct Play機能
DirectPlayとは、ゲーム向けAPIであるDirectXに含まれる通信用の機能の名称である。ゲーム・ソフトウェアがほかのユーザーやゲーム・サーバと通信する場合に使われているが、機能不足などを理由に廃止が予告されていた。Windows Server 2012 R2の場合は、ユーザーが明示的にインストールしない限り、利用できなくなる。
■SMB 1.0/CIFS ファイル共有のサポート
SMB 1.0（CIFS）は、Windowsネットワークの初期の頃から使われているファイル共有プロトコルである。Windows Vista／Windows Server 2008以降のWindows OSでは機能を強化したSMB 2.0以上が使われており、現在ではSMB 1.0は互換性のためにのみ残されている。SMB 1.0のみ利用可能なWindows Server 2003やWindows XP（およびそれ以前のWindows OS）をまだ使っている場合は、オフにしないように注意する必要がある。デフォルトではこの機能はまだ有効だが、明示的にオフにするために、新しく機能選択用のチェック・ボックスが用意された。SMB 2.0では、複数のコマンド（ファイルI/O API）をまとめて送信したり、より大きなバッファを使ってパフォーマンスを向上させたりしているほか、ネットワーク切断後の自動的な再接続、シンボリック・リンク・サポート、ファイルのローカル・キャッシュ機能など、より進んだ機能が利用できる。
●新機能「SMB Bandwidth Limit」
これはSMBプロトコルで使用するネットワーク帯域を制御する機能である。Hyper-Vの仮想マシンなどで使用する帯域を制限できる。
●PowerShellのDesired State Configuration Service機能
これはPowerShell 4.0の新しい拡張機能であり、特に複数サーバの管理効率を大幅に向上させることができる。これについては、すぐ後で解説する。
●そのほかの廃止／非推奨機能
以上のほかにもいくつか削除、変更された機能がある。詳細は以下のサイトを参照していただきたい。
- Windows Server 2012 で削除された機能または推奨されなくなった機能（TechNetサイト）
- Features Removed or Deprecated in Windows Server 2012 R2 Preview［英語］（TechNetサイト）
上に掲載した機能選択画面には「非推奨」とは記述されていないが、次のような機能が非推奨もしくは廃止となっている。このことから、Windows Server 2012 R2のさらに次のバージョンでは廃止されたり、機能がデフォルトでオフになったりすることが予想される。
- dfscmd.exe（分散ファイル・システムDFSの管理コマンド）。今後はPowerShellの使用を推奨
- ファイル複製サービスFRS
- IIS 6.0マネージャ
- 印刷用のLPR／LPDプロトコル
- ネットワーク・アクセス保護
- SQL 7やSQL Server 2000に対するODBC/OLEサポート
- SMTPサービスと関連する管理ツール
- Telnetサーバ機能
- Active Directory Rights Management Services（AD RMS）SDK
- Active Directoryにおける、Windows Server 2003ドメイン／フォレスト機能レベル。Windows Server 2003のドメイン・コントローラが存在するActive DirectoryにWindows Server 2012 R2のドメイン・コントローラを導入する場合は注意（TIPS「Active Directoryドメイン／フォレストの機能レベルとは？」参照）
PowerShell 4.0のDesired State Configuration Service
Windows Server 2012 R2に付属のPowerShellはバージョンが4.0となり、いくつか機能追加や強化が行われている。
このうち主な機能強化／変更点を以下に記しておく。
| 機能強化／変更点 | 内容 |
|---|---|
| Desired State Configuration | 手続き的な記述だけでなく、宣言的な記述も可能にするDesired State Configuration（DSE）機能をサポート |
| Save-Help | インターネットから不足しているヘルプ・メッセージをダウンロードする |
| 実行セキュリティ・ポリシーの変更 | デフォルトではRestrictedだったPowerShellの実行セキュリティ・ポリシーのデフォルトは、Windows Server 2012 R2ではRemoteSignedに変更された（Windows 8.1はRestrictedのまま）。TIPS「PowerShellスクリプトの実行セキュリティ・ポリシーを変更する」参照 |
| Get-FileHash | ファイルのハッシュ値を返すコマンドレットの追加 |
| PowerShell ISEのデバッグ・サポート | PowerShell ISEにおいて、Workflowとリモート・スクリプト・デバッグをサポート |
| PowerShell 4.0の主な機能強化（抜粋） | |
この中でも特に重要で期待されるのが「PowerShell Desired State Configuration（以下DSC）」だ。
これは、PowerShellに新しく導入された機能（書式、記述方法）の1つで、今までの手続き的な記述とは違い、操作や設定変更対象の「状態を記述する」、宣言的なプログラム機能である。分かりやすく表すならば設定用のコンフィギュレーション・ファイルのようなもの、とでも言えばよいだろうか。
例えばWindows OSのインストール時に使う無人セットアップ・ファイル（TIPS「sysprep用の応答ファイルを作る」参照）や、Active Directoryの自動インストールのときに使う応答ファイル（TIPS「Windows Server 2008でActive Directoryを無人インストールする」参照）のようなものである。ほかにも、自動セットアップ用の構成ファイルはいろいろなアプリケーションで使われているので、だいたい想像はできるだろう。
だがアプリケーションの設定用ファイルはそれぞれが独自の書式やデータ形式を持っており、互換性がない。これに対してPowerShellのDSCは、サーバの設定作業などに利用するための、新しい「システム構成情報記述用の共通仕様」になっている。
従来のPowerShellのスクリプトは、何らかの操作をするためのコマンドレットが順番に並んだ手続き的なものであったが、DSCでは、Windows Server OSの設定などを記述する、宣言的な記述が並んだものになる。例えばIISをインストールして、ファイルを用意する手順を抽象的な言葉で書けば次のようになる。
※今までのスクリプト
- まだIIS役割をインストールしていないなら、
→IIS役割を追加する（Add-WindowsFeature Web-Server） - c:\wwwrootにサイトを作成する（New-WebSite 〜〜）
- 指定された場所から、元となるファイルをコピーしてくる
これに対してDSCでは次のようになる
※PowerShell 4.0のDSCの場合
- インストールするWindowsの役割
−「Web-Server」役割 - 作成するサイト（の場所）とマスタ・イメージのパス
−「C:\inetpub\wwwroot」と「\\filesrv\WebFiles」
プログラムというよりは、設定するサーバの（最終的な）状態／構成仕様／設定項目のメモをただ並べただけ（のようなもの）である。「Desired State Configuration」を直訳すると「（最終的に）望まれる、（サーバの）状態の構成」となることからも分かるように、最終的なサーバの設定を記述（宣言）するための言語仕様である。もちろんPowerShellの拡張なので、必要に応じてコマンドレットを呼び出したりすることも可能である（実際にはPowerShellだけの機能で実現されているわけではなく、OS自身にもこのような設定を受け付ける機能が含まれている）。
具体的なDSCのスクリプトの例を次に示す（上のTechNetページからの抜粋）。#から行末まではコメントなので、実質的な記述部分は非常に短い。
※PowerShell 4.0のDSCの実際のスクリプト例（ファイル「MyWebConfig.ps1>」）
Configuration MyWebConfig
{
# パラメータはオプション
param($MachineName, $WebsiteFilePath)
# 以下には0個以上のノード・ブロックを記述する
Node $MachineName
{
# 以下には複数のリソース・ブロックを記述する
# WindowsFeatureは組み込みリソースの1つ
# IISは、このインスタンスを参照するために付けた名前
WindowsFeature IIS
{
Ensure ="Present" # これはインストール。"Absent"にするとアンインストール
Name ="Web-Server" # Get-WindowsFeatureのプロパティ名
}
# ファイルやフォルダを指定するにはFileリソースを使う
# WebDirectoryは、このインスタンスを参照するために付けた名前
File WebDirectory
{
Ensure ="Present" # "Present"で作成、"Absent"で削除
Type ="Directory" # デフォルトは"File"
Recurse=$true
SourcePath=$WebsiteFilePath # Webサイトにコピーする元ファイルのパスの指定
DestinationPath ="C:¥inetpub¥wwwroot"
Requires ="[WindowsFeature]IIS" # 依存関係の記述。上のIISリソースが必要であることを宣言している
}
}
}
MyWebConfig # 設定を実行
先頭にある「Configuration 〜」は、この中がDSCの記述であることを表す、PowerShell 4.0の新しいキーワードである。
「param 〜」は、このスクリプトへのパラメータを表す。この例では、MachineNameとWebsiteFilePathという2つのパラメータを要求している。
「Node 〜」は、サーバ名と、そのサーバに設定するべき内容を記述している。この例ではWindowsFeatureとFileの2つのリソース・ブロックが定義（宣言）されている。
「WindowsFeature 〜」は必要なWindows OS役割を表す組み込みリソース・レコードである。IISをインストールさせるには「WindowsFeature Web-Server」と記述する。「File 〜」は、用意するべきファイルやフォルダを記述するDSCの組み込みリソースである。
リソース・レコードには役割やファイル宣言のほかに、レジストリを設定するリソース、環境変数を設定するリソース、サービスやユーザー、グループなどを設定するリソース、ZIPファイルの展開を指示するリソース、PowerShellのコードを含むスクリプト・リソースなどいくつかある。
以上のスクリプトを例えば「MyWebConfig.ps1」というファイル名で保存しておき、次のように実行すると（システム管理のための標準規格DMTF用の）MOFファイルが作成される。
.¥MyWebConfig -MachineName "TestMachine" -WebsiteFilePath "¥¥filesrv¥WebFiles" -OutputPath"C:¥temp" # -OutputPathはオプション。デフォルトではカレント・パスに新しいフォルダが作成され、その中にMOFファイルが出力される
作成されたMOFファイルは、Start-DscConfigurationコマンドレットでターゲットとなるシステムに送って適用すればよい（送信されたファイルはWMIで適用される）。
この例ではただ1台のシステムにIIS役割をインストールしたが、パラメータを変えたり、複数のノードに適用したりすれば、多数のシステムを素早く設定できる。
このようにDSCでは「何をするか」ではなく、「どのようになるか／どのように設定するか」を記述するだけである。そのため手続き的ではなく、（プログラミング言語用語でいうところの）宣言的と呼ばれている。またシステムの状態を記述しているだけなので、何度適用しても結果は同じになる（間違えて複数回適用しても問題ない）。またこの例では、設定をプッシュ（相手ノードに送信）して適用していたが、中央にDSC用のサーバを用意して設定を保存しておき、各ノードがプルして（各ノードが定期的に取得して）適用するような運用もできる。
DSCについては今後回を改めて詳しく取り上げるが、これは管理者だけに便利な機能ではなく、開発者にとっても有用な機能だろう。開発したシステムを動作させるためには、サーバをあらかじめ決められた状態にセットアップしておく必要があるが、このとき必要なServer OSの役割や機能の組み合わせなどが複雑だったり、設定項目が多数あると、その準備は簡単ではないし、日常の管理も非常に面倒である。だがDSCであらかじめ設定をスクリプト化しておけば運用管理者はそれを適用するだけでよく、その内容を（深く）把握する必要はなくなる。開発者と運用担当者のスムースな連携は円滑なシステム運用のためには必須であり、最近では「DevOps（development＋operations)」などと呼ばれて注目されているが、PowerShell 4.0のDSCは、このDevOpsを支援するための重要な機能となりそうだ。
今回はWindows Server 2012 R2で追加／削除された機能の概要と、PowerShell 4.0のDSCについて簡単に見てきた。次回は改善されたHyper-V機能について取り上げる予定である。
Copyright© Digital Advantage Corp. All Rights Reserved.