環境：
Windows Server 2008 R2 (Server Core) Beta
Visual Studio 2008 SP1

こんにちは。

1. ちょっと UI 編
2. 完全にコマンド編

Windows Server 2008 R2 の Server Core では .NET Framework が動作するようになっているため、Server Core で動く ASP.NET アプリケーションの開発なども可能ですが、Channel 9 には、既にこうした観点での How-To がいくつか掲載されています。

[Channel9] サーバーコアにおける ASP.NET アプリケーションの配置方法 :
https://channel9.msdn.com/posts/philpenn/How-to-Deploy-ASPNET-Applications-on-Server-Core/
[Channel9] サーバーコアにおける ASP.NET アプリケーションのデバッグ :
https://channel9.msdn.com/posts/philpenn/How-To-Debug-ASPNET-Applications-on-Server-Core/

ここでは、これらビデオで紹介されている内容に基づき、リモートデバッグの方法などのはまりそうなポイントも含め、方法を書き出してみたいと思います。あとから「あそこのコマンド何だっけ . . .」といった場合や、コマンドファイルにして自動設定したい場合などにお役立てください。

ASP.NET のインストール

まずは ASP.NET の環境の準備からです。OS の役割や機能の設定には、以前、奥主 も IT Pro 道場で紹介していたようにいくつか方法があるのですが、R2 からの機能オプションの確認 / 設定用のコマンドである DISM コマンドを使用すると、PowerShell のようにテーブル形式、リスト形式などで表示の展開 (加工) ができるなど便利です。(この DISM コマンドの実行ログは、%sysdrive%\Windows\Logs\DISM\dism.log に保存されます。)

まずは、この DISM コマンドで、.NET Framework 及び WAS 関連、ASP.NET 関連などの関係する機能の状態 (有効 / 無効) を簡単に確認してみましょう (きっと、どれも、最初は無効になっているはずです) :

dism /online /get-features /format:table | findstr /i "asp"dism /online /get-features /format:table | findstr /i "net"dism /online /get-features /format:table | findstr /i "was"

では、設定に入っていきましょう。まずは IIS を有効にします :

dism /online /enable-feature /featurename:IIS-WebServerRole

つぎに、IIS のサービスが起動していることを確認します (起動していなければ、net start コマンドで起動をしておきましょう) :

sc query w3svc

IIS の機能 (ASP.NET, IIS マネージャ, など) を確認してみましょう。きっと ASP.NET が無効になっているはずなのでこれからインストールをしていくのですが、ASP.NET のインストールに依存する IIS-ISAPIFilter, IIS-ISAPIExtensions, IIS-NetFxExtensibility などのオプションも有効になっているか確認してみてください :

dism /online /get-features /format:table | findstr "IIS"

もし上記が無効なら、以下を実行してこれら依存するオプションを有効にします。

dism /online /enable-feature /featurename:IIS-ISAPIFilterdism /online /enable-feature /featurename:IIS-ISAPIExtensionsdism /online /enable-feature /featurename:IIS-NetFxExtensibility

そして、ASP.NET のインストールをおこないます。

dism /online /enable-feature /featurename:IIS-ASPNET

デフォルトで使用される .NET Framework はバージョン 2.0 ですので、例えば、.NET Framework 3.0 以降 (WCF など) も使用するのであれば以下も実行しておきましょう。(WAS などについても同様です。作るものにあわせて、上記の方法で機能の有効化/無効化を確認し、必要なものをインストールします。) :

例: .NET Framework 3.0 を有効にする :

dism /online /enable-feature /featurename:NetFx3-ServerCore

IIS のリモート管理

つぎに、IIS 上にアプリケーションの追加などの設定をおこなっていきます。

ご存じの方も多いと思いますが、これまた奥主がよくブログなどで書いている appcmd.exe という IIS 7 から使えるコマンドを使用すると、IIS の設定はほとんどすべて可能です。作業の自動化という観点でも、この機会に appcmd をおぼえておくと良いかもしれません。

しかし、上記の Channel 9 では、「もうコマンドはこりごり」、「みんなで管理したい」という方のために、IIS のリモート管理の方法を使用しています。よって、以下もこの方法で記載してみましょう。

まず、管理機能をインストールしてリモートから管理ができるように、「リモート接続」を有効にします。(念のため、ファイアウォールの設定を確認して、必要なプロトコルを通すようにしておきましょう。私の場合は、よくないことですが、デモのために ファイアウォールをオフにしてしまいました。)
まず、IIS 管理サービス (Web Management Service) を有効化します :

dism /online /enable-feature /featurename:IIS-ManagementService

そして、IIS のリモート管理を有効にするため、regedit (レジストリエディタ) を起動し、HKLMSoftwareMicrosoftWebManagementServerEnableRemoteManagement  を 1 に変更します。

インストールした上記の Web Management Service のサービスを起動します。

net start wmsvc

今後のためにも、このサービスは「自動」で起動するようにしておくと良いでしょう。

sc config wmsvc start= auto

これでクライアント上の IIS マネージャを使用して IIS のリモート管理をおこなうことができるようになりました。
ただし、従来の IIS の機能とバージョンの差異があるようで (R2 では IIS 7.5 が使用されています)、Windows Vista や 現時点では、Windows Server 2008 や Vista の IIS 7 マネージャから接続すると、接続は可能ですが、Default Web Site の表示などさまざまな設定が表示されない状態で接続されてしまうようです。このため、現時点では、リモート接続の際は、Windows Server 2008 R2 上の IIS マネージャからリモート接続をおこなってください。
(なお、今回は関係ありませんが、Windows Vista では Windows Server 2008 の IIS マネージャと違いリモート管理ができないようになっています。Vista でリモート接続をおこなう場合は、IIS 7.0 Manager for Remote Administration (x86 版、x64 版) をダウンロードして接続します。同様に Windows 7 用もリモート管理はできないので、現状は、Windows Server 2008 R2 からしか接続して管理することはできないということです。Windows 7 用のリモート管理ツールの提供など、いずれこうした点は解決されることでしょう . . .) (2009/07/01 追記 : RC 版で、Windows 7 からの接続は可能になっています . . .)

ASP.NET アプリケーションの開発とデバッグ

さて、これでアプリケーションの追加なども IIS マネージャを使ってリモートから可能になりましたので、あとは開発した ASP.NET アプリケーションを開発 / デバッグするのみです。
ASP.NET の開発を実施された経験者の方は実感して戴けると思いますが、開発したアプリケーションがマシンによって動いたり、動かなかったりといったことはそうそう頻繁に起こることではないので、通常は、Server Core とは別のクライアントマシン上で開発をおこなっておき、統合ビルドなど、必要な場合のみ Server Core 上に配置をおこなえば良いでしょう。(ただし、Server Core では、例えば WPF 関連、メディア関連など、.NET Framework の一部の名前空間 / クラスは持っていないのでその点だけは注意をしてください。)

また、簡易な配置をおこないたいだけならば、共有フォルダ経由でのファイルコピーなどでも良いでしょう。今回の私のデモ環境では、Server Core で公開した共有フォルダをネットワークドライブにマウントし (今回は G: ドライブとします)、プロジェクトのプロパティでビルド後のアクションとして以下を設定してみました。(毎回、ビルドのたびに配置をおこないます。)

rd /s /q G:bindel /q G:*xcopy /s /y "$(ProjectDir)*.aspx" G:xcopy /s /y "$(ProjectDir)*.config" G:mkdir G:binxcopy /s /e /y "$(ProjectDir)bin" G:bin

さて、「環境によって動かないということは頻繁にはないであろう」とは書きつつも、実際の開発では、たまには そうしたケースにも遭遇することでしょう。こうした場合に、リモートデバッグをおこなって、Server Core 上での ASP.NET アプリケーションのデバッグをおこなう手順について以下に記載します。(普通のリモートデバッグと何ら変わりませんが、、、)

まず、当然のことながら、デバッグをおこなうために、サーバー上には (シンボル情報などを含む) デバッグ版のモジュールを配置しておきましょう。

つぎに、リモートデバッガの実行のために、デバッグする Server Core のマシン上にデバッグ用のサービスを配置して実行します。ご存じの通り、Windows Server 2008 R2 からは 64 bit のみがサポート対象ですので、皆さんもよくあると思いますが、開発環境は 32 bit で、Server Core の実行環境は 64 bit (x64) というケースが頻繁にあるでしょう。こうした場合はちょっと面倒になります。
32 bit (x86) 環境にインストールされた Visual Studio 2008 を探しても 64 bit 用のリモートデバッグモニターは見当たりません。そこで、今回の場合は、どこか別の 64 bit 環境にリモートデバッガのみをインストールして、

%programfiles%\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x64

のフォルダを Server Core の環境へコピーし、この中の msvsmon.exe (リモートデバッグモニター) を実行してみましょう。
リモートデバッガのみのインストールモジュールは下記からダウンロードできます。

Visual Studio 2008 Service Pack 1 リモート デバッガ :
http://www.microsoft.com/downloads/details.aspx?FamilyID=440ec902-3260-4cdc-b11a-6a9070a2aaab&DisplayLang=ja

さて、msvsmon.exe の実行の際にリモートデバッグモニターに表示されるサーバー名をちゃんとおぼえておいてください。 (これはあとで使用します。そのまま何の設定もせずに起動すると、通常は、<実行 Account 名>@<Remote Machine 名> という名前になっているはずです。)

開発環境のマシンに戻り、Visual Studio のプロジェクトのプロパティを開き、[Web] タブの [開始動作] で [ページを開かずに外部アプリケーションからの要求を待つ] を選択し、[カスタム Web サーバーを使用する] を選択して接続する URL を入力します。

コードにブレークポイントなどを置きます。

メニュー [デバッグ] – [プロセスにアタッチ] を選択してデバッグをおこないますが、この際、表示される画面の [修飾子] 欄で、上記のリモートデバッグモニターに表示されたサーバー名 (<実行 Account 名>@<Remote Machine 名>) を入力して [更新] ボタンを押すと、サーバー側 (Server Core のリモートマシン) に接続し、アタッチ可能なプロセスの一覧が表示されます。

ここで、リモートデバッグをされたことがある方はおわかりと思いますが、ファイアウォールの設定、接続するユーザーアカウントの設定などに注意してください。
デフォルトでは Windows 認証を使用して接続しますので、接続するユーザーにリモートデバッグモニターへの接続の権限が設定されていないとつながりません (例えば、開発マシンはドメインに入っていて、リモートサーバーはワークグループで動いている場合などはやっかいなことになります)。今回の私の環境では、双方のマシンともにワークグループのマシンで、マシンの Administrator でログインしてそれぞれのパスワードを同一にしています。リモートデバッグモニターを設定して認証をなしにすることもできますが、この場合ネイティブコードしかデバッグできないため今回はこの手は使用できません。
また、ポートも専用のポートを使用しますので、Windows ファイアウォールでそのポートが利用できるよう、リモートマシン、開発マシンの双方のファイアウォールの設定をおこなう必要があります。(なお、今回の私の環境では、開発マシン側と Server Core のサーバー側のファイアウォールをともにオフにしてしまいました。)

つぎに、プロセスアタッチの設定画面で [選択] ボタンを押して、今回の場合、「マネージ」のコードのみをデバッグするように設定をおこないます。(下図)

[すべてのユーザーからのプロセスを表示する] を選択すると w3wp.exe のプロセスが表示されると思いますので、このプロセス (IIS のワーカープロセス) にアタッチすることでデバッグが開始します。(w3wp.exe が表示されない場合は、ブラウザでサーバーに接続するなどして確実にワーカープロセスが起動するようにしてから表示します。)

あとは、ブラウザを使って接続をおこなうことで、ブレークポイントでちゃんと停止してデバッグをおこなうことができるはずです。

さいごに

このように、非常に開発が楽しくなりそうな Server Core なのですが、 残念なのは、まだ SQL Server が Server Core をサポートしていない という点です。しばらくは、データベースサーバーとは分離した構成で、アプリケーションサーバーの役割として Server Core を活用していくという利用シナリオになるでしょう。

また、今回、アプリケーション展開についても共有フォルダを使ってそのままコピーするという簡易な方法ですが、実際の開発では 「接続先の WCF サービスのアドレス」、「データベース接続文字列」など、web.config の内容も変更しないと展開はできない場合がほとんどでしょう。こうした点も考慮し、次期開発環境の Visual Studio 2010 からは「ASP.NET Web Deployment」と呼ばれる配置の新しい仕組みによって、ステージング用、リリース用など、複数の配布イメージ (構成情報を含む) を管理できるようになる予定ですので、Visual Studio 2010 になると、さらに Server Core の Web 開発は柔軟になってくることでしょう。(なお、Visual Studio からの [発行] によるリモート配置では FrontPage Server Extension が必要になるなど、一般に、いくつかの設定が必要でした。)