業務の合間を縫って、Direct Access の環境を作成しております。
使用している環境が 2 台のノート PC (ちなみに 1 台は借り物) で、検証のシナリオに必要な 5 台のサーバーはすべて Hyper-V の仮想マシンで補っております。
"赤貧" という二文字がこの上なく似合うこの環境では、当然のことながらマシンリソースは不足がちで、"本当に検証の環境が動せるんかいな??" と疑問に不安にさいなまれつつも、256 MB のメモリでも文句もいわずちゃんと動作してくれる Windows Server 2008 R2 のデキの良さに感動し、深まる愛情を抑えることができません。
それにしてもなぜ、こんなに検証環境の作成にに時間がかかっているかというと、ノート PC で使用できる NIC がなかなか見つけられなかったためです。
Direct Access サーバーは NIC が二枚必要です。当然、通常のノート PC には NIC が一枚(?) しかついていないので増設する必要があります。
しかし、Windows Server 2008 R2 というか、Vista 以降の 64bit Windows に対応したドライバを持った PCMCIA 形式のネットワークカードは、私が探した限りさっぱり見つかりません。
仕方がないので私の持っている少ない ニュータイプ 能力(ヤマカンともいう) 使用して、適当、もとい、適切と思われるものを発注することになります。
正式な発注の前にメーカーさんがご親切にも試用品を送ってくださるのですが、動作しなかったり、動作しても 100 BaseT だったりすると、欲張って 1000 BaseT がほしくなったり、と、まぁ、そんな感じでズルズルと期間が延びていったわけです。
ちなみに最終的に落ち着いたのは I-O DATA さんの CBET100-CL というものです。残念ながら 100 BaseT で、メーカーの Windows Vista 64 bit での動作保障 はありません(というか、"Vista は 32 bit のみ" と明記w)が、PnP でドライバが入り私の環境では問題なく動作しております。
さて、そんなこんなで今週必要な機器がすべて揃い、本日組み合わせてみました。
ところが、クライアントから Direct Access サーバーを介して背後のサーバーに IPv6 での Ping は飛ぶものの、名前解決やその他はうまくいきません。
しかたがないので、参考にしていた Step By Step Guide: Demonstrate DirectAccess in a Test Lab の設定を最初から見直そうと思った矢先、私のゴーストがこう囁く (©攻殻機動隊) のです。
"おそらくアップデートされたドキュメントが公開されているはずだ。そうに違いない。"
すると本当に、ドキュメントの Update 日付が昨日 (2009/12/2) のものが、しかも、日本語版が用意されておりました。
日本語ということで、読み直しが簡単にできるということはうれしいのですが、今まで少ない英語能力で頑張ってきた自分の健気な努力を思うとなにか複雑な気分を禁じ得なかったりもします。
まぁ、そんなわけで、これから Direct Access の環境を作成される方は以下の日本語のドキュメントを参照されると良いでしょう。
Step By Step Guide: Demonstrate DirectAccess in a Test Lab (日本語)
http://www.microsoft.com/DOWNLOADS/details.aspx?displaylang=ja&FamilyID=8d47ed5f-d217-4d84-b698-f39360d82fac
さて、このところブログでお伝えしている IIS 7.x のプロビジョニングのサンプルアプリケーションなのですが、ドキュメントの整理がまだ終わっていないので公開は来週くらいになりそうです。
もし、楽しみにされている方がいましたら、申し訳ありませんがしばしお待ちを。。。
現在、デモ、開発、検証と、さまざまな環境を作成しているのですが、その中でも珍しいエラーに遭遇したのでメモがてら書いておきます。
状況はというと、Hyper-V 環境上で動作するドメインコントローラー (以下、DC) がホストするドメインに、その Hyper-V の管理 OS を参加させようとしたところ、以下のようなエラーが発生し、ドメインに参加させることができませんでした。
"ネットワークに到達できません。ネットワークのトラブルシューティングについては、Windows ヘルプを参照してください。"
DC は、他の仮想サーバーを問題なくドメインに参加させてきたもので、クライアントもつい先ほどまで別のドメインに参加していたものです。
まっ先に考えられるのはネットワークの構成なので、クライアント側で ipconfig すると、DC マシン内の DHCP により IP アドレスが正しく割り振られ、DNS も同じく DC マシン内のものが正しく自動設定されているのを確認できました。
当然のことながら ping による名前解決も両側から問題なく行えます。
しかながら ANC パスによる参照はできませんでした。
この状況で有名な問題は以下のものですが、問題の環境では TCP/IP NetBIOS Network Helper サービスは正常に動作しているため、このケースには当てはまりません。
http://support.microsoft.com/kb/329866/ja
サーバーとクライアント、この 2 つのマシンの、今回の作業のための変更点について考えてみると、変更がある (というか、今までのドメイン参加時と状況が異なる) のは、Hyper-V しているクライアントです。
なぜなら、Hyper-V のホスト OS は、ゲスト OS と通信を行う際には、物理的な NIC ではなく、"仮想ネットワーク" と名前のついた、仮想スイッチに接続された"仮想 NIC" を使用するようになるからです。
というわけで、"仮想ネットワーク" が割り当てられている [ローカル エリア接続 3] のプロパティは以下のようになっていました。

どこかピンとくる点はありませんでしょうか?
そうです、 [Microsoft ネットワーク用クライアント] にチェックがついておりません。
と、いうわけで、上記チェックボックスをオンに設定して、再度作業を行ったところ、問題なくドメインに参加することができました。
さて、今回のこの問題が発生した際、参考になる解決事例はないか、すぐに Web で検索をしてみましたが、さまざまな掲示板に同様の問題の質問があるにも関わらず、残念ながら、ほとんどの場合、原因がわからないまま "リカバリして解決"、"再インストールして解決" という結果でした。
もし、今後コンピューターをドメインに参加させる際に同様のエラーが発生した場合は、ネットワークアダプタのプロトコルの一覧で [ Microsoft ネットワーク用クライアント ] にチェックがついているかどうかをご確認いただければと思います。
もっとも、"もうちょっとわかりやすいエラーメッセージを出せよ...。" という話しでもありますが。(^_^;)
先日のこのブログの記事に掲載したサンプルコードの "Web サイトの作成" のコメントに "(アプリケーションプールは自動生成される)" とありますが、すみません、これはコメントミスで、実際は自動生成されません。
Web サイトを単純に作成した場合は、規定の設定が継承され、DefaultAppPool が設定されます。
作成する Web サイト、あるいは既存の Web サイトに任意のアプリケーションプールを設定するには、あらかじめアプリケーションプールを作成しておき、それを設定するようにします。
というわけで、アプリケーションプールを作成するためのサンプルーコードは以下です。2 つメソッドが定義されていますが、どちらを使っても OK ですので用途に合わせてお使いください。
サンプル(C#) : アプリケーションプールの作成
|
//アプリケーションプールの作成:其の壱 public Exception CreateApplicationPool(string poolName, bool autoStart, string modeType) { Exception returnExp = null; try { using (ServerManager serverManager = new ServerManager()) { Configuration config = serverManager.GetApplicationHostConfiguration(); ConfigurationSection applicationPoolsSection = config.GetSection("system.applicationHost/applicationPools"); ConfigurationElementCollection applicationPoolsCollection = applicationPoolsSection.GetCollection(); ConfigurationElement addElement = applicationPoolsCollection.CreateElement("add"); addElement["name"] = poolName; addElement["autoStart"] = autoStart; addElement["managedPipelineMode"] = modeType; applicationPoolsCollection.Add(addElement); serverManager.CommitChanges(); } } catch (Exception exp) { returnExp = exp; }
return returnExp; }
//アプリケーションプールの作成:其の弐 public Exception CreateApplicationPool(string poolName, bool autoStart, ManagedPipelineMode modeType, ProcessModelIdentityType identityType) { Exception returnExp = null; try { using (ServerManager serverManager = new ServerManager()) { serverManager.ApplicationPools.Add(poolName); ApplicationPool appPool = serverManager.ApplicationPools[poolName]; appPool.AutoStart = autoStart; appPool.ManagedPipelineMode = modeType; appPool.ProcessModel.IdentityType = identityType; serverManager.CommitChanges(); } } catch (Exception exp) { returnExp = exp; }
return returnExp; } |
サンプル(C#) : アプリケーションプールを作成するメソッドの呼び出し方
|
"其の壱"の場合 (引数: プール名, 自動的に開始するか否か,プールの動作モード) Exception exp = CreateApplicationPool("myAppPool", true, "Integrated");
"其の弐"の場合 (引数:プール名, 自動的に開始するか否か,プールの動作モード,プールの動作アカウント種別) using Microsoft.Web.Administration; Exception exp = CreateApplicationPool("myAppPool", true, ManagedPipelineMode.Integrated,ProcessModelIdentityType.ApplicationPoolIdentity); |
Web サイトのアプリケーションに任意のアプリケーションプールを割り当てるメソッドのサンプルは以下の通りです。呼び出す際には、第一引数に サイト名, 第二引数に アプリケーションプール名を指定します。
このメソッドは、既存の Web サイトのアプリケーションプールの置き換えにも使用できます。
サンプル(C#):Web サイトへのアプリケーションプールの適用
//Web サイトに任意のアプリケーションプールを設定する public Exception ChangeApplicationPool(string siteName, string AppPoolName) { Exception returnExp = null; try { ServerManager serverManager = new ServerManager(); serverManager.Sites[siteName].Applications[0].ApplicationPoolName = AppPoolName; serverManager.CommitChanges(); } catch(Exception exp) { returnExp = exp; } return returnExp; } |
さて、前回からコードのサンプルを掲載していますが、うまく実行できましたでしょうか?
もしうまくいかない場合でも、後日、動作確認可能なサンプルアプリケーションをソースごとご提供しますので、もう少々お待ちください。
前回のブログに書いた通り、ホスティング事業者様向けのイベントに向けて、エンドユーザーに IIS7 の Web サイトを管理させるためのプロビジョニング用を作成しています。
セットアップ用のコンテンツはまだ書いていませんが、コードができたのでご紹介しましょう。
このコードは以下の処理を行うためのものです。
1. IIS マネージャーユーザーアカウントを作成
2. Web サイト用の物理フォルダを作成
3. Web (HTTP) サイトを作成
4. 作成した Web サイトに FTP をバインド
5. 作成した Web サイトの [IIS マネージャーのアクセス許可] に作成したIIS マネージャーユーザーアカウントを登録
この一連の処理が完了すると、エンドユーザーは、IIS マネージャーを使用して、指定した自分の Web サイトに、指定した IIS マネージャーユーザーアカウント情報でログインし、Web サイトの管理を行えるようになります。
またコンテンツの更新などは FTP を使用して行えます。
もちろん、サーバー側でしっかり設定しておけば、ユーザーに任意で ASP.NET や、PHP のアプリケーションを実行させることが可能です。
これらの処理を完全に行わせるのは、プログラミングのコードだけではなくて、サーバーの設定も必要ですが、今回は前述の 5 つの機能を実行するサンプルコードのみをご紹介します。
なお、サンプルはクラスライブラリのものですので、そのままでは実行できませんので、適宜アプリケーションに組み込み、管理者アカウントで実行してみてください。
サンプル(C#) : IishostingHepler クラスの定義
|
using System; using Microsoft.Web.Administration; using System.Security.Cryptography; using System.Text;
namespace IisHostingHepler { public class Provisoning {
#region Webサイト関連の処理
//Web サイト用のフォルダを作成する public Exception CreatePhysicalPath(string physicalPath) { try { System.IO.DirectoryInfo dirInf = new System.IO.DirectoryInfo(physicalPath); if (!dirInf.Exists) { dirInf.Create(); } return null; } catch (Exception ex) { return ex; } }
//Web サイトの作成(アプリケーションプールはDefaultAppPool が設定される) public Exception CreateWebSite(string siteName, string physicalPath, string ipAddress, string portNumber, string hostName) { Exception returnExp = null; string bindingInformation = (ipAddress == "") ? "*:" + portNumber + ":" + hostName : ipAddress + ":" + portNumber + ":" + hostName;
try { ServerManager serverManager = new ServerManager();
Site mySite = serverManager.Sites.Add(siteName, "http", bindingInformation, physicalPath);
mySite.ServerAutoStart = true; serverManager.CommitChanges(); } catch (Exception exp) { returnExp = exp; } return returnExp; }
//指定された名前の Web サイトがすでにあるか確認する public bool ExistWebSite(string siteName) { ServerManager serverManager = new ServerManager(); foreach (Site site in serverManager.Sites) { if (String.Equals(site.Name, siteName, StringComparison.OrdinalIgnoreCase)) { return true; } } return false; }
//既存の Web サイトに FTP バインドを追加 public Exception AddFtpBind(string siteName, string ipAddress, string portNumber, string hostName, string accountName, string permType, string serverCertHash, string sslCtrlPolicy, string sslDataPolicy) { Exception returnExp = null; string bindingInformation = (ipAddress == "") ? "*:" + portNumber + ":" + hostName : ipAddress + ":" + portNumber + ":" + hostName;
try { using (ServerManager serverManager = new ServerManager()) { Site site = serverManager.Sites[siteName];
// FTP のバインド情報を追加 site.Bindings.Add(bindingInformation, @"ftp");
ConfigurationElement ftpServerElement = site.GetChildElement("ftpServer");
ConfigurationElement securityElement = ftpServerElement.GetChildElement("security");
//SSL の設定 ConfigurationElement sslElement = securityElement.GetChildElement("ssl");
//証明書のハッシュが設定されていない場合は、とりあえずなにもしない if (serverCertHash != "") sslElement["serverCertHash"] = serverCertHash; sslElement["controlChannelPolicy"] = sslCtrlPolicy; sslElement["dataChannelPolicy"] = sslDataPolicy;
//基本認証の設定 ConfigurationElement authenticationElement = securityElement.GetChildElement("authentication"); ConfigurationElement basicAuthenticationElement = authenticationElement.GetChildElement("basicAuthentication"); basicAuthenticationElement["enabled"] = true;
//IIS 管理ユーザー用 カスタム認証プロバイダーの設定 ConfigurationElement customAuthenticationElement = authenticationElement.GetChildElement("customAuthentication"); ConfigurationElement customAuthenticationPoviderElement = customAuthenticationElement.ChildElements["providers"]; ConfigurationElementCollection providers = customAuthenticationPoviderElement.GetCollection(); ConfigurationElement addElement = providers.CreateElement("add"); addElement["name"] = "IisManagerAuth"; addElement["enabled"] = "true"; providers.Add(addElement);
// Add Authorization Rules Configuration appHost = serverManager.GetApplicationHostConfiguration(); ConfigurationSection authorization = appHost.GetSection("system.ftpServer/security/authorization", site.Name); ConfigurationElementCollection authorizationRules = authorization.GetCollection(); ConfigurationElement authElement = authorizationRules.CreateElement(); authElement["accessType"] = "Allow"; authElement["users"] = accountName; authElement["permissions"] = permType; authorizationRules.Add(authElement);
serverManager.CommitChanges(); } } catch (Exception exp) { returnExp = exp; } return returnExp; }
#endregion
#region 管理者アカウントの処理
//サイトの管理用アカウントを生成する public Exception CreateAdminAccount(string userName, string passWord) { Exception returnExp = null; try { using (ServerManager serverManager = new ServerManager()) { Configuration config = serverManager.GetAdministrationConfiguration();
ConfigurationSection authenticationSection = config.GetSection("system.webServer/management/authentication"); ConfigurationElementCollection credentialsCollection = authenticationSection.GetCollection("credentials"); ConfigurationElement addElement = credentialsCollection.CreateElement("add"); addElement["name"] = userName; addElement["password"] = GetHashPwssword(passWord); //addElement["enabled"] = true; credentialsCollection.Add(addElement); serverManager.CommitChanges(); } } catch (Exception exp) { returnExp = exp; } return returnExp; }
//管理用アカウントがすでに存在するか確認する public bool ExistAdminAccount(string userName) { using (ServerManager serverManager = new ServerManager()) { Configuration config = serverManager.GetAdministrationConfiguration(); ConfigurationSection authenticationSection = config.GetSection("system.webServer/management/authentication"); ConfigurationElementCollection credentialsCollection = authenticationSection.GetCollection("credentials"); foreach (ConfigurationElement conf in authenticationSection.GetCollection("credentials")) { if (conf.Attributes["name"].Value.ToString() == userName) { return true; } } return false; } }
//管理アカウントで Web サイトにアクセス可能とする public Exception AllowLogon(string siteName, string adminName) { Exception returnExp = null;
try { siteName = @"/" + siteName; using (ServerManager serverManager = new ServerManager()) { Configuration config = serverManager.GetAdministrationConfiguration(); ConfigurationSection authorizationSection = config.GetSection("system.webServer/management/authorization"); ConfigurationElementCollection authorizationRulesCollection = authorizationSection.GetCollection("authorizationRules");
ConfigurationElement scopeElement = FindElement(authorizationRulesCollection, "scope", siteName); if (scopeElement == null) { scopeElement = authorizationRulesCollection.CreateElement("scope"); scopeElement["path"] = siteName; authorizationRulesCollection.Add(scopeElement); } ConfigurationElementCollection scopeCollection = scopeElement.GetCollection();
//すでにアカウントが登録されていたら処理を抜ける if(ExistAccount(scopeCollection,adminName)) return returnExp;
ConfigurationElement addElement = scopeCollection.CreateElement("add"); addElement["name"] = adminName; scopeCollection.Add(addElement); serverManager.CommitChanges(); } } catch (Exception exp) { returnExp = exp; }
return returnExp; }
//すでにアカウントが登録されているかどうかチェック private bool ExistAccount(ConfigurationElementCollection scopeCollection, string AccountName) { foreach (ConfigurationElement confElement in scopeCollection) { if (confElement.Attributes["Name"].Value.ToString() == AccountName) return true; } return false; }
//<scope> 要素が Web サイト の <authorizationRules> 要素に既に追加されているかどうかを確認するコード。※新規作成の際には必要ないはずであるが念のため private static ConfigurationElement FindElement(ConfigurationElementCollection collection, string elementTagName, string keyValues) { foreach (ConfigurationElement element in collection) { if (String.Equals(element.ElementTagName, elementTagName, StringComparison.OrdinalIgnoreCase)) { if (string.Equals(element.Attributes["path"].Value.ToString(), keyValues, StringComparison.OrdinalIgnoreCase)) { return element; } } } return null; }
//パスワードを SHA256 でハッシュする public string GetHashPwssword(string passWord) { SHA256 sha = SHA256.Create(); byte[] hashBytes = sha.ComputeHash(System.Text.Encoding.UTF8.GetBytes(passWord));
byte f1 = 0xf0; byte f2 = 0x0f; string hexString = "";
foreach (byte b in hashBytes) { int first4 = (b & f1) >> 4; int second4 = (b & f2); hexString = hexString + ((first4 > 9) ? (char)('A' + (first4 - 10)) : (char)('0' + first4)); hexString = hexString + ((second4 > 9) ? ((char)('A' + (second4 - 10))) : (char)('0' + second4)); } return hexString; } }
#endregion
} |
サンプル(C#):アプリケーション側の呼び出し例
|
//Provisoning クラスのインスタンスを生成 Provisoning Prov = new Provisoning(); Exception exp = null;
//管理用ユーザーアカウントを作成 exp = Prov.CreateAdminAccount(userInfo.userName, userInfo.password); if (exp != null) return exp.Message;
//Web サイト用の物理パスを作成 string newPhysicalPath = webSiteInfo.physicalPath + "\\" + webSiteInfo.siteName; exp = Prov.CreatePhysicalPath(newPhysicalPath); if (exp != null) return exp.Message;
//Web サイトを作成 exp = Prov.CreateWebSite(webSiteInfo.siteName, newPhysicalPath, webSiteInfo.ipAddress, webSiteInfo.portNumber, webSiteInfo.hostName); if (exp != null) return exp.Message;
//Web サイトに FTP をバインド exp = Prov.AddFtpBind(webSiteInfo.siteName, ftpSiteInfo.ipAddress, ftpSiteInfo.portNumber, ftpSiteInfo.hostName, userInfo.userName, "Read,Write", "", "SslAllow", "SslAllow"); if (exp != null) return exp.Message;
//Web サイトに管理ユーザーアカウントを登録 exp = Prov.AllowLogon(webSiteInfo.siteName, userInfo.userName); if (exp != null) return exp.Message; |
管理者アカウントでの実行については、Web アプリケーションの場合は、WCF あるいは ASP.NET Web サービスとして作成し、アプリケーションを管理者権限で動作させるのが簡単です。また、その際には IIS 側の設定で、localhost (127.0.0.1) からの接続にのみ実行するようにしておけばセキュリティが保たれます。
Windows フォームアプリケーションに組み込んで検証を行う場合は、アプリケーションの実行時に管理者アカウントを使用するだけで結構です。
なお、このコードは、Windows 7, Windows Vista のクライアント OS 用の IIS7.x でも実行できますが、これらクライアント OS に付属する IIS マネージャーでは、[管理サービス] に関する設定を確認する機能が搭載されていないので、コードの実行結果を確認するには、administration.config ファイル、applicationHost.config ファイルの内容を直接確認する必要があります。
クライアント OS の IIS7.x において、これらの設定を確認/更新する機能は Microsoft.Web.Administration、Microsoft.Web.Management を使用して作成が可能と思われるので、ニーズがあるようであれば、IIS7.x のアドインとして作成してみようかな、なんて思っています。
また、作成中のプロビジョニングページの実際のサンプルプロジェクトは、後日、配置/検証の手順書と合わせてこのブログで公開予定ですので、興味のある方はお楽しみに。
――― ・ ――― ・ ――― ・ ――― ・ ――― ・ ――― ・ ――― ・ ――― ・ ―――
おしらせ
Windows Server を操る IT Pro の熱い戦い INSTALL MANIAX の第三弾が "Hyper-V 祭り" と題して年末年始に開催されることになりました。
http://www.thinkit.co.jp/maniax/3/index.html
本コンテストは、IIS へのオープンソース・アプリケーションのインストール数を競うという非常にシンプルな協議内容で、参加者にはサーバーマシンと Windos Server OS が無償提供されます。
なんと今回は決勝戦が海外で行われるという噂もちらほら....。(あくまでも噂です)
"ぅおおっ、インストールならまかせんしゃい!!" という、腕に覚えのあるそこのアナタ、ふるってご応募してみませんか?
IIS7.x の数ある新機能の中で、とりわけ私が気に入っているのが "IIS 管理ユーザー" の機能です。
以前のバージョンまでの IIS では、Web サイトの管理を行うには、サーバーの管理者権限を持ったユーザーアカウントで作業する必要があり、当然ながら管理者のアカウントはマシンローカルか、Windows ドメインにユーザーアカウントを作成する必要がありました。
しかし、IIS 7.x では、サーバーの管理者権限を持たないユーザーアカウントに対し、任意の Web サイトの管理を任せること (委任) ができるうえ、管理用のアカウントも IIS 内でのみ有効な管理アカウントを作成できるのです。
そうです、もはや IIS の管理を行うためだけに Windows のユーザーアカウントを作る必要はないのです。
『IIS マネージャー ユーザー』
http://technet.microsoft.com/ja-jp/library/cc733028(WS.10).aspx
『IIS 7.0: IIS マネージャ ユーザーを構成する』
http://technet.microsoft.com/ja-jp/library/cc771311(WS.10).aspx
しかも、FTP7.5 では、この IIS マネージャーユーザー のアカウントを認証処理に使用できるので、コンテンツの管理も問題なく行えます。
『IIS 7.0 マネージャー認証を使用した FTP の構成』
http://technet.microsoft.com/ja-jp/library/dd939052.aspx
これと、 IIS7.x の管理サービスの機能を組み合わせると、不特定多数のユーザーに Web サイトを提供する、いわゆる Web サイトの共有ホスティングサービスが、それほど難しくなく (慣れている人からみれば驚くほど簡単に) 実現できるのです。
『IIS 7.0: サイトまたはアプリケーションへの接続を IIS マネージャのユーザー アカウントに許可する』
http://technet.microsoft.com/ja-jp/library/cc770968(WS.10).aspx
このサービスの使い勝手としては、サービスを利用するユーザーは、自分のローカルマシンにインストールされた IIS マネージャーを使用して、インターネット経由でダイレクトに IIS 内の自分の Web サイトにアクセスして管理を行うようになります。

そういった使用を見越してかどうかは不明ですが、下記のページでは、以下に示す Windows OS 用の、リモート接続用の IIS マネージャーがダウンロード可能となっています。
IIS マネージャーが提供されている OS
Windows 7
Windows Vista
Windows XP
Windows Server 2003
IIS マネージャーのダウンロードページ
『IIS Manager for Remote Administration』
http://www.iis.net/extensions/IISManager
と、まぁ、上に掲載したリンク先のドキュメントをご参照された方は、IIS 7.x の管理共有がいかに手軽に利用できるのかご理解いただけたと思います。
しかし、これらが手軽に利用できるのは、前もって Web サイトが使用できるように準備、いわゆる プロビジョニングが済んでいればの話しです。
しかも、サービスとして提供するにはプロビジョニングの処理は自動化したいところです。
これらに関してもサンプルコードが記述されたページが豊富に用意されていて、それらを利用することで、それほど難しくなくプロビジョニングの自動化を行うことができます。
実は現在、私のほうで、ホスティング事業者様向けのイベントに向けて、Web サイトの共有ホスティングのためのサンプルアプリケーションを作成しており、今回の記事では、その過程で見つけた公開されているサンプルコードの不具合と回避策を書こうと思っていたのですが、前置きが長くなってしまいました(笑
上の記事についてはまた後日書きたいと思います。
では。
少し日が経ってしまったのですが、先週の土曜日(2009/10/31) にオープンソースカンファレンスに弊社の出展対応要員として、参加してきました。
オープンソースカンファレンス 2009 Tokyo/Fall
http://www.ospn.jp/osc2009-fall/
"MS がオープンソース?" と、以外に思われる方もいらっしゃると思うのですが、いえいえ、そもそも弊社はプラットフォームベンダーなので、Windows 上で動作するプログラムを書いてくださるデベロッパーなんであれ大歓迎なのです。(もちろん、"悪意のあるプログラム"作成者に対してはその限りではありません。)
それどころか、弊社は自ら CodePlex というオープンソースのコミュニティを運営するくらいオープンソースに関わっていたりします。
『CodePlex』
http://www.codeplex.com/
『マイクロソフトのオープンソース』
http://www.microsoft.com/japan/opensource/default.mspx
このオープンソースへの取り組みは、ユーザーが行っているプロジェクトのギャラリーのみならず、今や弊社製品の機能にも関わってきており、ASP.NET の MVC Framework や、IIS.NET で公開されている IIS を機能アップするための各種モジュールなどもオープンソースで提供されています。
また、プラットフォームとしてオープンな実行環境を提供するために Windows には NT の時代から POSIX サブシステムを搭載していましたし、最近では IIS に FastCGI モジュールを搭載したりとなかなか頑張っております :-)
さて、オープンソースカンファレンスにいらっしゃったお客様方の反応なのですが、とくに アンチ MS とという方には遭遇することもなく、いたって平穏に過ぎていきました。
というか、いままで Web 2.0 カンファレンスや、なぜか Linux World Expo といった、あまり弊社とは関係が薄いようなイベントにも出展対応で参加してきましたが、アンチMS な方にはほとんど会ったことがなく、みなさんフレンドリーで、技術的な話で結構盛り上がり対応する側としてもかなり楽しく過ごせております。
また機会があればぜひ参加させていただきたいと思います。
さて、オープンソースカンファレンス出展中においでいただいたお客様で、ご自分で開発中のライブラリのデモを見せてくださった方がいらっしゃいました。
どんなライブラリかというと、なんと、実写に仮想的な動画をリアルタイムに合成する、いわゆる世界カメラを作成するためのものです。
見せていただいたデモでは、携帯電話のカメラ越しに、ある文字の印刷された紙を見ると、3D の初音ミクが踊っているというものです。
もちろん、リアルタイムに動画にオブジェクトの動作は追従し、カメラの角度を変えると、初音ミクの見える角度も変わります。
ちなみにライブラリは C# で書かれていて、Windows モバイル機で動作します。
開発者の方の悩みとしては、動作検証を行うために Windows モバイルのデバイスを購入し続けなければならず、さすがにお金が続かないということで、検証環境を提供してくれるスポンサーを探しておいででした。
以下にプロジェクトのリンクを掲載します(※承諾済み) ので、ご興味のある方、またはビジネスの種を探されている方はアクセスしてみてください。
『NyARToolkit』
http://nyatla.jp/nyartoolkit/wiki/index.php
IIS 7.0 から FastCGI が標準搭載されたことにより、PHP アプリケーションを使うだけのためにわざわざ Linux + Apache を使用する必要はなくなってきました。
そのせいかどうか知りませんが、"社内にある Linux を Windows Server にするので、Apache から IIS へのマイグレーションの資料がほしい"というお話もちらほらといただくようになりました。
そういった状況を見越して.....、なのかどうかは不明ですが、『Apache to IIS 7.0 – Migration Guide』 なるドキュメントが用意されておりました。
『Apache to IIS 7.0 – Migration Guide』
http://download.microsoft.com/download/2/D/8/2D863347-3AFF-48A6-9FCF-EC6554C18DCF/Apache%20to%20IIS%207%200%20Migration%20Guide.doc
ちなみに Apache から IIS 6.0 へのマイグレーションについては、 『Internet Information Services (IIS) 6.0 Resource Kit』 の 7 章の "Migrating Apache Web Sites to IIS 6.0" に書かれておりますので Windows Server 2003 をご使用の方はこちらをご覧ください。
『Migrating Apache Web Sites to IIS 6.0』
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=80a1b6e6-829e-49b7-8c02-333d9c148e69
"FastCGI モジュールが搭載されたのは IIS7.0 からなのになぜ IIS6 が?" と思われる方もいらっしゃるかもしれませんが、実は IIS.NET から IIS6.0/5.1 (Windows Server 2003/XP ) 用の FastCGI モジュールを入手することができるのです。
『FastCGI for IIS 6』
http://www.iis.net/extensions/FastCGI
使用しているサーバーを Windows で統一したい、ASP、ASP.NET、PHP アプリケーションのサーバーをまとめたい、また、インターネットの Web サーバーをユーザーフレンドリーな IIS に替えたい、という方はぜひ参考にしてみてください。
それと、IIS のホスティングは初めてで不安がある、という方はホスティングガイドを参考にされるといいでしょう。(IIS6 も兼用です)
『IIS 7.0 ホスティング展開ガイド [ドラフト v1]』
http://www.microsoft.com/japan/serviceproviders/technical/070702_1.mspx
ただいま Direct Access のテンポラリの検証環境を作成しております。
Direct Access をご存知ない方のために簡単に説明すると、Windows Server 2008 R2 と、Windows 7 の組み合わせで使用できるリモートアクセスの機能です。
今までの RAS の仕組みとなにが違うかというと、通信を IPv6 で行い IPSec トンネリングを使用して通信を行うため VPN を使用する必要がありません。
あと、ダイレクトに目的のネットワークにログイン処理を行うので、インターネット越しにアクセスしてきたクライアントに対し、グループポリシーなども適用することが可能です。
なお、Direst Access の詳細については、以下のページをご参照いただければと思います。
http://technet.microsoft.com/ja-jp/windows/dd572177.aspx (Web キャスト)
さて、この Direct Access、関連のオンラインドキュメントを参考に環境を作成し始めたのですが、途中で Step By Step Guide と呼ばれる、検証環境の作成手順書があることを知りました。
途中まで作成してしまった環境をどうしようか、と迷ったのですが、とりあえず イチから Step By Step Guide で環境を作成しなおすみことにしました。
現在、作業の半ばまで来ていますが、やはり、最初から環境を作り直して正解だったと痛感しております。
やはり、Direct Access は複数の技術の集合だけあって、設定箇所も多く、手順もかなり複雑です。
とくに、証明書の設定箇所が多く、じっくり考えながら手順を追わないと理屈が理解できません。(※当然のことながら、手順を理解しながら行わないと、途中でエラーが発生した際に修正できません)
そんなわけで、これから Direct Access の環境を作成するという方は、とりあえず一度、以下の Step By Step Guide を使用して検証環境を作成することをお勧めするしだいです。
『Step By Step Guide: Demonstrate DirectAccess in a Test Lab』
http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=8D47ED5F-D217-4D84-B698-F39360D82FAC&displaylang=en
<備考>
『DirectAccess Technical Overview for Windows 7 and Windows Server 2008 R2』
http://technet.microsoft.com/ja-jp/library/dd637827(WS.10).aspx
ちょっと前にお客様からいただいた質問で以下のようなものがありました。
IIS7.0 で ホストヘッダーを使用したバーチャルドメインの運用を https で対応は可能か?
Windows 2003 までは未対応だったが、Windows 2008 R2 ではどうか?
はい。可能です。しかし、厳密にいうと仕組み上できません。
なにを言ってるんだ? と思われるかもしれませんが、この問題はそう単純ではありません。
バーチャルドメインと呼ばる、一つの IP アドレスで複数のホスト名のサービスを提供する方法として、HTTP 1.1 で使用されているのがホストヘッダーを利用するものです。
この方法では、Web サーバーは、クライアントからの HTTP リクエスト内の "Host:" フィールドに記載されているホスト名をもとに Web サイトを判定し、レスポンスを切り替えます。
しかし、HTTPS で通信を行う場合、Web サーバーは SSL 通信を開始するにあたり、まず 最初にサーバー証明書をクライアントへ送ります。
そのため、その後クライアントから送られる HTTP リクエスト中に、別のホスト名が書いてあったとしても、すで遅く、別のホスト名での証明書が発行されているため"証明書とホスト名が一致しない" という旨の警告がブラウザに表示されます。

このような動作につき、標準的な Web サーバーで、"ホストヘッダー だけ" を使用して HTTPS の バーチャルドメインの運用はできません。
しかし、現在においては、 RFC 3546 に記載されている、Transport Layer Security (TLS) Extensions という仕様を使用して(しゃれではありません:-) )、一つの IP アドレスで、SSL を使用した複数のホスト名のサービスを提供することができます。
ただし、この方法は、HTTP クライアントも RFC 3564 に対応しているものを使用する必要があります。( ※と、いっても Internet Explorer なら 7 以降、FireFox なら 2 以降、GoogleChrome、Opera と最近のブラウザであれば対応しているのでほとんど問題ないと思いますが。)
RFC 3546 に準拠した HTTP クライアントは、SSL 接続時のネゴシエーションメッセージ (CLIENT HELLO) と同時に要求ホスト名もサーバーに送出します。
IIS ではこの Server Name Indication (SNI) 拡張を利用して、複数の HTTPS サイトをホストすることが可能です。
これは、なにも IIS7 からの新機能というわけではなくて、IIS6 からも可能でした。
IIS6 における上記設定の詳細と、具体的なコマンドラインの記述は以下のドキュメントをご参照ください。
Microsoft TechNet - 『SSL ホスト ヘッダーのサーバー バインドを構成する』
http://technet.microsoft.com/ja-jp/library/cc756897(WS.10).aspx
さて、IIS7.x で同様の設定を行うには以下のようにします。(表示の関係で折りかえってますが、一行で記述します。)
appcmd set site /site.name:"サイトの識別子" /+bingings.[protocol='https',bindingInformation='*:443:ホストヘッダー]
※<ホスト ヘッダー> は、site2.contoso.com や site4.contoso.com など、Web サイトのホスト ヘッダーです。
なお、バインディングを解除するには、/+bindingsのプラス記号をマイナスマイナス記号で指定してください。
ただし、手元に複数サイトの証明書がないので試せてはいませんので、実際に使用する際には十分に検証を行い、正常に動作することを確認後に実装を行ってください。
あ、それから逆に、複数の Web サイトで、単純に同じ証明書を使用したい場合は、ワイルドカードサーバー証明書を使用すれば OK です。
詳しくは以下のドキュメントをご参照ください。
Microsoft TechNet - 『ワイルドカード サーバー証明書を取得およびインストールする』
http://technet2.microsoft.com/WindowsServer/ja/library/b5999267-fc46-4430-a6af-e0b483886c8a1041.mspx?mfr=true
<参考>
Microsoft TechNet - 『SSL ホスト ヘッダーを構成する』
http://technet.microsoft.com/ja-jp/library/cc738897(WS.10).aspx
ではまた。
先日、同僚が IIS7.5 (Windows 7) への PHP 5.3 のインストールがうまくいかない、とのことでお手伝いしました。
同僚は php.net からダウンロードした msi を使用してインストールを行っていたのですが、なんと、最近の PHP インストーラーには IIS 用の Fast CGI の設定が含まれているのですね。IIS 用のインストーラーで設定可能なのは ISAPI と、ふつーの CGI だけだと思っていたのですが、時代は進んでいるようです。

インストーラーの終了後、念のために IIS の設定を確認すると、正しくハンドラーマッピングの設定がされておりました。
PHP のランタイムのインストール場所は、同僚が変更していたので、デフォルトでどこになるかは不明ですが、セットアップ後に PHP ランタイムがコピーされたフォルダのアクセス権を確認すると、ワーカープロセスが使用するアカウントへのアクセス権は設定されていないので、これは別途手動で行う必要がありそうです。
さて、IIS7.5 では、このアクセス権の設定にコツがあります、というか、注意すべき点があります。
それはアプリケーションプールの動作アカウントです。
IIS7. 5 ではアプリケーションプールの既定の動作アカウントを ApplicationPoolIdentity という特殊なアカウントが使用されます。
この ApplicationPoolIdentity は仮想アカウントであり、アプリケーションが動作する際には、そのアプリケーションプールと同じ名前のアカウントが生成されて、そのアカウントを使用してアプリケーションプールが動作します。
たとえば、アプリケーションプールの名前が DefaultAppPool の場合は、DefaultAppPool という名前のアカウントで動作します。これは、複数のアプリケーションプールのプロセスが、同じ名前のアカウントで動作するセキュリティ的なリスクへの対応を強化するためのものです。
しかし、これらはあくまでも仮想アカウントであるため、ディスクやデータベースへのアクセス権の設定には、まだ(2009 年 10 月現在) 使用することができません。
よって、これらのリソースにアプリケーションプールの動作アカウントでアクセスする必要がある場合には、従来の NetworkService アカウントを使用するなどの工夫が必要になります。
今回の PHP のインストールでは、個別に NetworkService アカウントで動作するアプリケーションを作成してそれを使うようにし、PHP のランタイムのフォルダには NetworkService アカウントへの読み取りのアクセス権を設定しました。
※なんと、解決方法がありました。
ApplicationPoolIdentity で設定された仮想 ID は、それそのものを使用してアクセス権の設定を行うことはできませんが、ビルトインセキュリティグループの IIS_IUSRS に対してアクセス権を設定することにより仮想 ID を使用することが可能になります。
ただし、この方法はセキュリティグループでの設定が必要となりますので、SQL Server のアクセス権設定には使用できません。
ちなみに、Web サイトに .NET 認証の設定をする際にも、このような処理を行い、SQL Server のログオンアカウントに、使用するアプリケーションプールの動作アカウントを追加する必要があります。
さて、設定が完了し、動作させてみると HTTP 500 エラーが返り、PHP が正しく動作しません。
php.ini の内容を変更し、HTTP 500 は回避できたものの、今度は phpinfo() 関数が正しくない、と言ったエラーが発生します。
仕方がないので、念のために PHP のランタイムをアンインストールしてもらい、今度はいつもやっているとおり msi でなく、zip 形式でパッケージをダウンロードして手動で設定を行ったところすんなりと php.info() 関数が動作するようになりました。
このインストーラーと、手動での設定方式の違いについてなのですが、IIS の設定については、とくに違いがあるようには見えませんでした。
PHP 側の設定が、インストーラー (msi) と、手動で行うのでは違いがあるのかも知れませんが、残念ながら私は PHP に詳しくないので相違点があるのか or ないのか? それはどこなのか? というところは不明です。
というわけで、個人的には PHP 5.3 のインストールは手動で行うことをお勧めします。その際には IIS のアプリケーションプールの動作アカウントを OS 側で使用可能なものとし、そのアカウントに対し、PHP ランタイムのあるフォルダで [読み取り] のアクセス権を付与してください。
それから PHP のランタイムなのですが、IIS で使用するからといって Thread Safe モデルを選択する必要はもうありません。IIS 上の FastGCI モジュールはプロセスモードで動作するため、処理効率の良い Non-Thread Safe モデルのランタイムを使用することができます。
PHP も設定も、慣れてしまえば簡単なので、ぜひ IIS 上で PHP を動かせてみてください。
イベントのお知らせを終了後に行うのもなんだかなー、という感じなのですが(私の不徳のいたすところです、はい。どおもすみません)、土曜日(9/5) に IISUG さんの以下イベントでセッションに登壇してまいりました。
タイトル: 『 見る、知る、使う、IIS7 (IISUGユーザーミーティング #01)』
日時: 2009年9月5日 (土曜日) 13:30 - 17:00付開 (受始 13:00)
場所: マイクロソフト株式会社 新宿オフィス5F セミナールーム
担当セッション: 『IIS7 での Web サイト共有サービス構築』
セッション概要 : IIS7では構成のモジュール化をはじめ多くの機能追加が行われました。今回のセッションでは、この IIS の豊富な機能と、その母体である Windows Server の機能を組み合わせ、Windows の標準機能のみでどのようにして、Web サイトの共有サービスを構築するかについて考察します。
イベントに参加してくださった皆さん、ありがとうございました。
参加者がイベントを作り上げているという雰囲気が非常に良くて、こういったイベントがもっと増えていけばいいのになと思いました。
また参加させてください。
さて、セッションで使用したスライドを SkyDrive にアップしました。Tech Ed 2009 後に急いで作成したので、けっこうな "あらびき" 感がありますがご容赦を。
そういえば Tech Ed 2009 ネタをなにも書いてませんでしたね...。
Thech Ed 2009 にむけて、セッションで使用するデモ環境を作成しております。
本日、IIS7 サイトに .NET フォーム認証を適用すべく IIS 管理ツールから ".NET ユーザー" の作成を行おうとしたところ以下のエラーが発生。。
| ユーザーインスタンスのプロセス起動中のエラーにより、SQL Server のユーザー インスタンスを生成できませんでした。接続は閉じられます。 |
原因と対処策はすでに分かっているのですが、以前それを知るまで大変苦しんだので、ここに載せておこうとおもいます。
回避策の前に、問題の発生した環境を簡単に紹介。
| 環境 |
| OS |
Windows 7 (64 bit) |
| Visual Studio |
2008 |
| SQL Server |
2005 Express を削除して 2008 Express Edition をインストール |
| アカウント |
administrator |
キモとなるのは "SQL Server 2005 Express を削除して、SQL Server 2008 Express Edition" をインストールしたというところです。
他のバージョンとエディションがどうなのか検証していないのでわかりませんが、この SQL Server 2005 Express エディションは、アンインストールの際にファイルを完全には削除しないようなのです。
回避策からの結果論ではあるのですが、この残ったファイルが原因で SQL Server 2008 が新規にデータベースファイルを作成できないことがエラーの原因となっているようです。
それでは回避策についてです。
回避策
=====
以下のフォルダにある *.mdf 、*.ldf ファイルを別の場所に移動するか、削除 。
C:\Users\アカウント名\AppData\Local\Microsoft\Microsoft SQL Server Data\SQLEXPRESS
ちなみにアカウント名のフォルダの下の AppData フォルダは非表示属性になっているのでご注意ください。
それではまた。
前回のポストからずいぶんと時間がたってしまいました。
ただサボっていたわけではありません、今後 IIS TechCenter で公開予定の IIS.NET のコンテンツ(※1)の和訳の検証をしていたり、Tech・Ed09 用のデモ(※2)を作成したりと、真面目に働いでおりました(汗)
(※1) IIS.NET で公開されている管理用ドキュメントから選りすぐったものを翻訳し、近日 IIS TechCenter にて公開予定です。一般の書籍に負けない非常に濃くて有用な情報が満載ですのでご期待ください。
(※2) .NET を使用して IIS の機能を拡張する方法についてお話しさせていただきます。リクエスト、レスポンスのハンドリングはもちろんのこと、IIS 管理ツールの拡張方法、Hostable WebCore 等についてもご紹介 & サンプルの提供を行う予定です。
さて、私、普段の業務では、ホスティング事業者様にお邪魔して弊社テクノロジーのご紹介などをさせていただいてるわけなのですが、最近話題の上ることが多いのが "クラウド" の構築についてです。
Hyper-V と SystemCenter の組み合わせにより柔軟なリソース提供の基盤が作成可能とあり、ある程度規模が大きく、先進性のあるパートナー企業様の多くが検討されているようです。
しかし、そのほとんどが現在のステータスが"検討中"(あるいは検証中) であるにも関わらず、先日 IDC フロンティア様がクラウド型システム開発基盤の提供を開始しました。
IDCフロンティア 日本版クラウド型システム開発基盤を提供開始!
http://www.idcf.jp/pressrelease/2009/20090623001.html
以下のページでシステム構成をみることができるのですが、内容を見ると我々が普段セッションや、お客様先でお話しさせていただいてる構成が見事に実現されています。
NOHA プラットフォームサービス
http://www.idcf.jp/services/hosting/noah_p/platform.html
いよいよ、クラウドサービスというものが本格的に現実化し、広まっていくような予感がします。
さて、その IDCフロンティア様主催のセミナーが、7 月 22 日 水曜日に弊社関西支店にて開催されます。
実際にクラウド型サービスを構築した方々の話しを聞けるというのは、現段階ではなかなか無いチャンスかと思いますので、今後 Windows Server を使用してクラウドライクなシステムの構築を考えられている方は参加をお勧めいたします。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ 7/ 22 (水) 日本版クラウド型システム開発基盤活用セミナー
~ Hyper-V 業界新価格のプラットフォーム ~
───────────────────────────────────
システム設計、開発を担当するみなさまを対象に、Hyper-V を採用した
日本版クラウドの活用方法をご紹介します。
日本国内の実績のあるデータセンター、NEC 社の高性能サーバー、
Windows Server 2008、Hyper-V を採用したプラットフォームによるコスト削減、
信頼性、拡張性をビジネスに活用する情報を提供します。
【日時】7/ 22 (水) 16:00 ~ 18:30
【主催】株式会社IDCフロンティア、マイクロソフト株式会社 (協賛)
【会場】マイクロソフト株式会社 関西支店 5F セミナールーム 1
【お申し込み】
http://co1piltwb.partners.extranet.microsoft.com/mcoeredir/mcoeredirect.aspx?linkId=12202947&s1=d7f82796-7fb9-ecfe-103b-09e492a1d208
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
先日、日本独自の IIS 技術ポータル 『IIS TechCenter』 が公開されました。
『IIS TechCenter』
http://technet.microsoft.com/ja-jp/iis/default.aspx
だからというわけでもないのですが、以前所属していたチームブログに書いていた IIS 関連の記事で、資料性のあるものを再投稿していこうと思います。
第一弾としては、IIS 7 上の Web サイトに ASP.NET のフォーム認証を適用する方法についてです。
さて、ASP.NETフォーム 認証ってなに? という方もいると思うので簡単に説明しておきましょう。
ASP.NET フォーム認証とは、ASP.NET アプリケーションにそれ独自の認証処理を実装するための仕組みです。
この ASP.NET 認証は、アプリケーション ( 仮想ディレクトリ または Web サイト) 単位でアカウントベースを持たさせることが可能であるため、コンピューターや Windows ドメイン上にいちいちユーザーアカウントを作る必要もなく、また、ログオン画面なども自由に作成できるという、非常に小回りがきいて便利なものでした。
しかし、惜しむらくは、前バージョンの IIS では、ASP.NET フォーム 認証によるアクセス制御は ASP.NET が管理するファイル (拡張子が aspx とか ascx とか ashx とか) にしか有効ではありませんでした。
つまり、ASP.NET アプリケーションに ASP.NET フォーム認証を適用しても、アプリケーション内の ASP.NET で管理されないファイル (拡張子が htm とか jpg とか gif とか) に対して、直接 URL を指定された場合は、そのアクセスを制御することはできなかったのです。
IIS 7 では機能のモジュール化に伴うパイプラインの変更により、ASP.NET フォーム認証を使用して ASP.NET 以外のファイルに対してアクセス制御を行えるのはもちろんのこと、ASP.NET アプリケーションを作成しなくてもその機能を IIS7 の認証方式の一つとして使用することができます。
つまり、*.html や *.jpg といった静的なコンテンツにはもちろんのこと、PHP 等の ASP.NET とは違うランタイムで動作する Web アプリケーションに対しても、完全後付けで ASP.NET 認証の仕組みと、認証画面を追加することができるのです。
もちろん、既存アプリケーションのコードの変更は一切必要がありません。
また、認証ベースを格納するファイルは、既定では Web アプリケーションのフォルダ内の App_Data フォルダ内に格納されため、配布する際には、アプリケーションと一緒に配布することができます。
つまり、Web アプリケーションの配布先で、いちいちユーザーを作成し直す必要が無いのです。
なお、ASP.NET 認証は、設定手順はことなるものの FTP サイトにも適用することが可能です。
今回は、Web サイトへの ASP.NET 認証の具体的な手順を以下に記述します。
IIS 7 に ASP.NET 認証を適用する方法
準備
====
SQL Server をインストール(※1)
IIS の追加セットアップで [フォーム認証]、[URL 認証] (※2)をインストール
login.aspx を作成し、目的の仮想ディレクトリに配置
※1: DB への接続文字が既定で Express Edtion のものになっているので、初めは Express Edtion を入れておくのが良いでしょう。もちろん、接続先を任意で変更も可能です。
※2: Windows Server 2008 では R2 βも含め [URL 承認] となっています。
login.aspx の内容
-------------------------
<html>
<head>
<title>Login to my web page</title>
</head>
<body>
<form runat="server">
<asp:Login runat="server" />
</form>
</body>
</html>
設定手順
========
- [スタート] ボタン – [コントロールパネル] – [管理ツール] から [インターネット インフォメーション サービス(IIS) マネージャ] (※以下 [IIS マネージャー ] と表記) を起動
- 画面左のツリーを展開し、目的の仮想ディレクトリを選択
- 仮想ディレクトリのアイコンがフォルダアイコンの場合は、マウスの右ボタンをクリックし、表示されたコンテキストメニューより [アプリケーションへの変換] を選択
- .NET ユーザーの作成
- 4-1. 画面右の [機能ビュー] より [.NET ユーザー] をダブルクリック
- 4-2. [.NET ユーザー] 設定画面の右 [操作] パネルから [追加...] リンクをクリック
- 4-3. [.NET ユーザーアカウントの詳細] 画面が表示されるので各項目に適切な値を入力し [OK] ボタンをクリック
- フォーム認証の有効化
- 5-1. [機能ビュー] より [認証] アイコンをダブルクリック
- 5-2. [認証] の設定画面が表示され、使用可能な認証方式の一覧が表示されるので、”フォーム認証”、”匿名認証” を “有効” に設定し、他は “無効” に設定
- 5-3. 認証方式の一覧の “フォーム認証” 上でマウスの右ボタンをクリックし、表示されたコンテキストメニューより [編集...] を選択
- 5-4. [フォーム認証設定の編集] ダイアログボックスが表示されるので、同ダイアログボックスの [ログイン URL] の内容が “login.aspx” になっていることを確認
- 認証規則の設定
- 6-1. [機能ビュー] より [認証規則] アイコンをダブルクリック
- 6-2. [認証規則] の設定が面が表示されるので、画面右の [操作] パネルから [拒否規則の追加...] リンクをクリック
- 6-3. [拒否の認証規則の設定] ダイアログボックスが表示されるので、[この Web コンテンツのアクセスを拒否する : ] の項目で、オプションボタン ”すべての匿名ユーザー” にチェックを付け [OK] ボタンをクリック
- web.config ファイルの編集
- 7-1. エクスプローラーを使用して目的の仮想ディレクトリの物理パスにアクセス
- 7-2. web.config ファイルをメモ帳でオープン
- 7-3. 要素に があるか確認し、なければ追加
- 7-4. 要素内を以下のように設定
<modules> <remove name="FormsAuthentication" /> <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" /> </modules> |
- 7-5. web.config ファイルを上書き保存
- 設定を行った仮想ディレクトリ内のコンテンツにアクセスし、ログイン用ダイアログボックスが表示されるか確認
- 作成した .NET ユーザーの情報をログイン画面に入力し、ログインすることが可能か確認
以上で設定は完了です。
ブラウザから目的のコンテンツにアクセスし、以下のような認証画面が表示されるか確認してください。

認証画面が表示されたら、次に作成した .NET ユーザーのアカウント情報を使用してログオンし、目的のコンテンツが表示されるか確認してください。
次は FTP サイトへ ASP.NET 認証を適用する手順について書きたいと思います。
最近外出ばかりしているので、ブログを更新する暇がとんとありません。
外出してなにをしているかというと、パートナー企業様にお邪魔して、Windows Server 2008 R2 の新機能がいかに素晴らしく、ビジネスの可能性を広げてくれるかを熱く語っております。
こういう優秀なプロダクトだと、胸を張ってお客様にご紹介できるので非常に助かりますね(自画自賛)。
また、ご使用いただいているお客様の評判も上々なので、外回りにも力が入ります。
ちなみに私のミッションはなにかというと、IIS の普及であり、このブログに書いているような ASP.NET にはあんまり関係なかったりします。(でもタイトルは Developer Evangelist 。なぜ??)
さて、昨日訪問したお客様から、Windows Server 2008 R2 の Windows 展開サービスの新機能についてご質問をいただき、この流れで MDT (Microsoft Deployment Toolkit) 2010 について調べたので書いておきます。
MDT 2010 は既に Beta 1 が公開されており、以下のサイトからダウンロードして入手することができます。
Microsoft Connect -『Microsoft Deployment Connection』(※アクセスするには Windows Live ID による登録が必要です)
https://connect.microsoft.com/content/content.aspx?ContentID=10790&SiteID=14
なお、Microsoft Deployment Toolkit 2010 Bata 1 の新機能と変更点は以下のとおりです。
MDT 2010 Bata1 の新機能
- Windows 7 Bata の展開のサポート
- Windows Server 2008 R2 Bata 展開のサポート
- Windows Automated Installation Kit (Windows AIK) version 2.0 のサポート
- Windows 7 Bata、Windows serv er 2008 R2 Bata の配布には Windows AIK 2.0 が必要です。
- Windows User State Migration Toolkit (USMT) version 4.0 のサポート
- USMT 4.0 : ハードリンクマイクレーションをサポート
- USMT 4.0 : シャドウ コピー をサポート
- Deployment Image Servicing and Management (DISM) をサポート
- Windows PE version 3.0 をサポート
- Windows PE3.0は、Windows AIKバージョン2.0 の一部として含まれます。
- Boot Configuration Data (BCD) マネージメント ツールのサポート
- MDT 2008 Updata 1 は、ブート設定の管理に BitLocker Drive Preparation Tool (BdeHdCfg.exe) を使用します。
- Windows 7 のデフォルトパーティション設定
MDT 2010Beta1 では、Windows 7 Beta のためのディスクパーティション構成は Windows BitLocker Drive 暗号化ディスク構成と同様になります。
オペレーティングシステムがDisk0 の Partition2にインストールされ、システムパーティションがDisk0(Partition1)に設置されます。
MDT 2008 Update 1 からの変更点
MDT2010Beta1リリースはMDT2008Update1に存在した以下の機能を含んでいません:
- Microsoft Systems Management Server (SMS) 2003 のサポート
MDT 2010 Beta 1 では Systems Management Server を使用して実行する ZTI 展開がサポートされていません。
※MDT 2008 Update1 でサポートされているすべての展開シナリオは、MDT 2010 Beta 1 でサポートされます。
MDT 2010 Beta 1 でサポートされる OS
|
Operating system |
LTI |
ZTI |
|
Windows 7 Beta |
|
|
|
Window Server 2008 R2 Beta |
|
|
|
Windows PE version 3.0 Beta |
|
|
|
Windows Vista (with Service Pack 1 [SP1] and later) |
|
|
|
Windows Server 2008 (all service pack levels) |
|
|
|
Windows XP (with SP3) |
|
|
|
Windows Server 2003 R2 |
|
|
|
Windows PE version 2.1 |
|
|
= サポート
MDT 2010 Beta 1 でサポートされる AIK
|
Windows AIK |
LTI |
ZTI |
|
Windows AIK version 2.0 Beta |
|
|
|
Windows AIK version 1.1 |
|
|
= サポート
こんどから IIS ネタも少し書こうと思ってます。