エントリー

しばらく前、私はプログラムでリモートIISを制御し、それをモジュールとして実装する最良の方法を見つけることを任されました。 このタスクは面白く、多くの困難を伴うため、私の経験を共有したいと思います。



実装されたモジュールの基本的な要件のリストは次のとおりです。

• IISで基本的な操作を実行する機能：
  
  
  • ウェブサイトの作成
  • 仮想アプリケーションの作成
  • 仮想ディレクトリの作成
  • SSL証明書のインストールを含む、サイトのバインドの設定
  • 詳細なアプリケーションプーリング
• 異なるファームサーバー上の複数のIISによる並列操作のサポート
• IISバージョン8.0のサポート（以前のバージョンをサポートする必要はありません）。

つまり、モジュールは、 IISマネージャーを介して実行できる実質的にすべてを実行できるはずです。



問題を解決するのに適した3つのツールを見つけて調査しました。

1. Windows Management Instrumentation（WMI）
2. ASP.NET構成API
3. Microsoft Web管理

検討した各オプションを使用してテストアプリケーションを作成した後、最も有望なものとしてMicrosoft.Web.Administrationを選択しました。



ツールのメソッドを理解するのは非常に難しく、エラーの可能性が高くなるため、最初のオプションは拒否しました。 同時に、それを扱うことは、COMコンポーネントを扱うことに似ています。

WMIを使用してサイトを作成する例：

DirectoryEntry IIS = new DirectoryEntry("IIS://localhost/W3SVC"); object[] bindings = new object[] { "127.0.0.1:4000:", ":8000:" }; IIS.Invoke("CreateNewSite", "TestSite", bindings, "C:\\InetPub\\WWWRoot");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目のオプションは、XML構成ファイルを操作することです。 つまり、Webサーバー上のルートweb.configファイルをほとんど手動で変更することになっています。 ご存知のように、このオプションは私にも適していません。



3番目のオプションでは、サイトを作成し、開発者のためにすべての低レベルの作業を行うことができました。 このツールのもう1つの利点は、 IISマネージャーがこの特定のライブラリを使用して、利用可能なすべての操作を実行することです。



もちろん、ソリューションの実装にはまだ困難がありました。 このMicrosoft.Web.Administrationを必要な方法で動作させるために、私は多くのGoogleの時間を費やしました。 インターネットでは、このライブラリを操作する方法、それで何ができるかなど、多くの情報を見つけることができます。 ただし、これらの情報はすべて、さまざまな記事に散在しています。 これは、Microsoft.Web.Administrationの「落とし穴の世界に没頭する」私の経験について書くことを私に促しました。 私が遭遇したすべての問題とその解決策を集めようとしました。 突然誰かが便利になります。



それでは、技術的な部分から始めましょう。

システム構成

Webサーバーのファームがあり、それぞれがIIS 8.0を備えたWindows Server 2012 Standardによって管理されています 。 モジュールを使用してWindowsサービスを実行している別のアプリケーションサーバーがあります。 IISはこのサーバーに展開されません。 アプリケーションサーバーからWebサーバーを管理する必要があります。

開発

Microsoft.Web.Administration接続

最初の問題は、ライブラリをテストする段階ですぐに現れました。 プロジェクトに接続し、サイトを作成することになっているコードを記述し、HRESULTからアクセスエラー例外0x80070005（E_ACCESSDENIED）を受け取りました。 同様の問題に関する多くの説明（ stackoverflow.com/questions/8963641/permissions-required-to-use-microsoft-web-administrationなど ）を読んだ後に判明したように、Microsoft.Web.Administrationにはルートweb.configファイルにアクセスするための管理者権限が必要です。



さて、リモートサーバー上にユーザー名とパスワードを使用してユーザーを作成します。 ローカルコンピューター上に同じユーザー名とパスワードで同じユーザーを作成します（これは重要です。そうしないと、アプリケーションはリモートマシンにログインしません）。 始めます。 同じ問題！



アクセス問題をより詳細に調査します。 adminユーザーを作成するだけでは不十分であることがわかりました。 結局のところ、Windows Vistaから始めて、UACシステムが登場しました。 また、このシステムを理解しているコンピューター管理者でさえ、まったく管理者ではなく、高度な権限を持つユーザーです。 アプリケーションが機能するには、リモートサーバーでUACを無効にする必要があることがわかります。 ただし、Windowsの管理からUACを無効にするだけでは十分ではありません。 問題は残っています。 UACを完全に無効にする必要があります。 参照による記事で説明されているように、レジストリを介してこれを行いました。 はい、同意しますが、これは安全ではありません。 しかし、これが唯一の解決策です。 幸いなことに、顧客は同意します。



アプリケーションを実行しようとしています。 ユーレカ！ サイトが作成されました。 だから、先に進むことができます。

アプリケーションがテストサーバーに展開された後、2番目の構成の問題が発生しました。モジュールはMicrosoft.Web.Administrationライブラリを見つけることができず、エラーでクラッシュしました。 サーバー上のGACでは、異なるバージョンのビルドであることが判明しました。 この困難に対処するために、プロジェクトBinに目的のライブラリのコピーを含めることが決定されました。



ライブラリの接続に関連する最後の問題も、アセンブリのバージョン管理のために発生しました。 アクティブな開発の段階で、バージョン7.0.0.0および7.5.0.0のライブラリが見つかりましたが、2番目の方法では、アプリケーションプールにAlwaysRunningをインストールするなど、重要なものの実装を簡素化しました。 したがって、最初に接続しました。 しかし、テストサーバーにアップロードした後、アプリケーションは再びクラッシュしました。 Microsoft.Web.Administration 7.5.0.0はIIS Expressでのみ機能することがわかりました。 したがって、本格的なIISを管理する予定の場合は、バージョン7.0.0.0を使用してください。



これらは、Microsoft.Web.Administrationライブラリを接続するとき、およびタスクを解決するための準備における主な問題でした。 先は、顧客の要件に応じた機能の実装でした。 それらについてさらに説明します。

実装要件

モジュールに実装したメソッドには、一般的なものと、頭を打ち砕かなければならなかったものがあります。 インターネットで簡単に見つけることができるものについては説明しません。Microsoft.Web.Administrationライブラリのメソッドの名前、たとえばWebサイトやそのバインダーの作成から既に明らかなことはすべて説明します。 代わりに、私が考えなければならない問題、およびインターネットで解決策を見つけることが困難であった（またはまったく解決しなかった）問題に集中します。

マルチスレッドとマルチタスク

モジュールの要件に応じて、1つまたは複数のリモートサーバー上に複数のWebサイトを並行して作成できるようにする必要がありました。 同時に、2つのスレッドは1つのリモートIISを制御できません。 実際、これは同じルートweb.configファイルを変更することを意味します。 したがって、Webサーバーの名前でロックスレッドを作成することが決定されました。 これは次のように行われます。

 private ServerManager _server; private static readonly ConcurrentDictionary<string, object> LockersByServerName = new ConcurrentDictionary<string, object>(); private object Locker { get { return LockersByServerName.GetOrAdd(ServerName, new object()); } } private void ConnectAndProcess(Action handler, CancellationToken token) { token.ThrowIfCancellationRequested(); lock (Locker) { try { _server = ServerManager.OpenRemote(ServerName); token.ThrowIfCancellationRequested(); try { handler(); } catch (FileLoadException) { // try again token.ThrowIfCancellationRequested(); if (_server != null) _server.Dispose(); _server = ServerManager.OpenRemote(ServerName); token.ThrowIfCancellationRequested(); handler(); } } finally { if(_server != null) _server.Dispose(); _server = null; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、ServerNameはローカルネットワーク上のコンピューターのNetBIOS名です。



開発されたモジュールの各メソッドは、このハンドラーでラップされます。 たとえば、ウェブサイトの存在を確認する：

 public bool WebSiteExists(string name, CancellationToken token) { return ConnectAndGetValue(() => { Site site = _server.Sites[name]; return site != null; }, token); } private TValue ConnectAndGetValue<TValue>(Func<TValue> func, CancellationToken token) { TValue result = default(TValue); ConnectAndProcess(() => { result = func(); }, token); return result; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

毎回サーバーに再接続するのはなぜですか？

まず、このモジュールが作成されたシステムは自由に構成できます。 したがって、モジュールクラスのインスタンスがどのメソッドで、どの順序で、どのくらいの期間必要になるかが事前にわかりません（MWAConnectorと呼びましょう）。

次に、別のスレッドがコネクタを必要とする場合があります。 そして、1つのコネクタの接続を開いている場合、2番目のコネクタの接続を許可できません。 そうしないと、編集するファイルへの並列アクセスエラーが発生します。

これらの考慮事項に基づいて、コードには複数の操作のMWAConnectorクラスの1つのインスタンスが含まれ、各操作は個別の接続の独立したコンテキストで実行されます。

このアプローチの欠点は、接続を作成するためのリソースのコストです。 これらのコストを無視することが決定されました。 これらはモジュールのボトルネックではありません。操作の直接実行には、接続の作成よりも数倍のプロセッサ時間がかかります。

AlwaysRunningのインストール

タスクの1つは、AlwaysRunningフラグを使用してアプリケーションプールを作成することでした。 Microsoft.Web.Administration 7.0.0.0ライブラリのApplicationPoolクラスのプロパティには、AutoStart、Enable32BitAppOnWin64、ManagedRuntimeVersion、QueueLengthがたくさんあります。 ただし、RunningModeはありません。 このプロパティはバージョン7.5.0.0のビルドにありますが、上記のように、このバージョンはIIS Expressでのみ機能します 。

問題の解決策がありました。 これは次のように行われます。

 ApplicationPool pool = _server.ApplicationPools.Add(name); //some code to set pool properties if (alwaysRunning) { pool["startMode"] = "AlwaysRunning"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変更を保存するには、CommitChanges（）メソッドを呼び出す必要があります。

 _server.CommitChanges();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PreloadEnabledをインストールする

私が遭遇した別の問題は、WebアプリケーションとサイトにPreloadEnabledフラグを設定するための組み込みプロパティの欠如でした。 このフラグは、再起動後のサイトの初期ロード時間を短縮します。 サイトが長時間ウォームアップしているときに役立ちます。 そして、顧客が展開したサイトの一部はまさにそれです。

解決策として、サイトのWebアプリケーションを作成するコードフラグメントを提供します。

 Site site = _server.Sites[siteName]; string path = string.Format("/{0}", applicationName); Application app = site.Applications.Add(path, physicalPath); app.ApplicationPoolName = applicationPoolName; if (preload) app.SetAttributeValue("preloadEnabled", true); _server.CommitChanges();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Webアプリケーションの名前は「/」で始まる必要があることに注意してください。 これが必要な理由は そうしないと、アプリケーションの取得、作成、または削除の方法でエラーが発生します。

Webアプリケーションとしてサイトの設定を変更する

サイト自体のアプリケーションプールを変更することが必要になる場合があります。 問題は、Siteクラスにこのプロパティがないことです。 Applicationクラスのインスタンスでのみ見つけることができます。

解決策は、サイトのWebアプリケーションを取得することです。

 Site site = _server.Sites[siteName]; Application app = site.Applications["/"];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サイトを削除

サイトの削除は簡単なタスクのように思え、_server.Sites.Remove（site）を呼び出すだけです。 ただし、最近、httpsバインディングを持つサイトを削除するときに問題が発生しました。 実際には、Microsoft.Web.Administrationがサイトを削除すると、バインディングに関する情報も削除されます。これは論理的です。 同時に、ライブラリはIP：ポート：SSL準拠に関するシステムkofigのエントリも削除します。 したがって、同じ証明書を使用するバインディングが複数のサイトにある場合、これらのサイトのいずれかを削除すると、他のすべてのサイトはバインディングと証明書のバインディングを失います。



最新のMicrosoft.Web.Administrationライブラリには、システム構成からレコードを削除する必要があることを示す2番目のパラメーターを受け取るバインディングを削除するメソッドが含まれています。 したがって、問題の解決策は次のとおりです。

 Site site = _server.Sites[name]; if (site == null) return; var bindings = site.Bindings.ToList(); foreach (Binding binding in bindings) { site.Bindings.Remove(binding, true); } _server.Sites.Remove(site); _server.CommitChanges();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

現在、このモジュールはタスクを正常に処理し、本番環境で動作します。 これにより、数十のサイト、Webアプリケーション、プール、仮想ディレクトリが毎週作成されます。



モジュールの作業中に遭遇した主な問題と、見つけた解決策を挙げました。 この資料が誰かに役立つことを願っています。 誰かが質問や提案があれば、尋ねてください-私は答えようとします。