誰もがこれについて既に知っているようです。今年の7月14日、Windows Server 2003 / R2のサポートは公式に打ち切られました。 しかし、何をする必要があるか、そして何かをする価値があるかどうかについての議論は続いています。 現在の状況を戦略的な観点から見ることをお勧めします。 まず、これが会社のビジネスプロセスにどのように影響するかを理解し、法的（および技術的および経済的）な観点から状況を調べます。 第二に、古いOSから最新バージョンへの移行コンサルタントが必要な理由を理解するために、それらの使用は何ですか。 そして最後に、Web Deployment Toolを使用してIISベースのWebサイトを移行する実際的な経験を共有することにより、多くの企業の生活を楽にします。

Windows Server 2003 / R2のサポート終了。 歌詞

WS2003 / R2サポートの終了は、ビジネスにとって何を意味しますか？ 一見したところ、これはおそらく次のようになると思われるかもしれません。

1. ライセンスおよび場合によっては新しい機器の追加費用（12年前に購入しました。再び？！？！）。
2. 規制当局の問題（特に個人データを保存している会社（および保存していない会社は？）、WS2003 / R2はセキュリティ更新プログラムを受信しなくなったため、個人データの安全性を確保するための要件を満たしていないことを意味します）
3. さまざまな基準との矛盾：地元および業界の両方。これにより、会社が多数の入札に参加したり、罰則を課したりする能力が制限される場合があります。

上記に基づいて、WS2003 / R2のサポートの終了はマイナスのイベントであり、コスト、問題、および「ITであり、危機を助長するのではなく、お金を要求する」と思われるかもしれません。 結局のところ、困難な経済状況では、誰も追加の問題、リスク、コストを必要としません。 さらに、多くの企業はIT予算を削減し、IT部門にコストを削減するだけでなく、効率を高めています。 では、そのような条件下で移行を実行する方法と、 移行を実行するかどうかはどうでしょうか。 「良い時まで」すべてを残した方がいいのではないでしょうか？



順番に理解しましょう。 典型的なIT部門の標準的な状況を、目標、要件、制限に分解します。



目的：

1. ITコスト削減
2. 効率を上げる

要件：

1. ビジネスの期待に応える
2. ITによるビジネスタスクのソリューションとサポート

制限事項：

1. IT予算の削減
2. WS2003 / R2のサポート終了

ご覧のとおり、最後のポイントは全体像の一部にすぎません。 また、IT戦略全体をレビューする絶好の機会を提供します。 会社のITインフラストラクチャを再検討します。 さまざまな角度から見て、最適化して新しい現実に適応させる方法を理解してください。 また、さまざまな技術的、財政的、およびその他の制限のために絶えず延期された近代化プロジェクトについてはどうですか？ それらをレビューし、再評価する時が来ました！



インフラストラクチャの内容を決定します。 これを行うには、まず次のような質問に対する回答を取得します。

• サーバーはいくつありますか？ どのOSがインストールされていますか？
• 彼らはどのような負荷を経験し、どのような特性/能力を持っていますか？
• Windows Server 2003 / R2をお持ちですか？ どの役割、サービス、アプリケーションが割り当てられていますか？
• 使用されているアプリケーションはどれですか？ 誰がそれらを使用しますか？
• 最新のOSを使用して、役割、サービス、およびアプリケーションを他のサーバーに転送できますか？

Microsoft Assessment and Planning Toolkitインフラストラクチャ計画アプリケーションは、この情報に役立ちます。 彼の作業の結果は、既存のインフラストラクチャの分析と、その最適化またはMS Azureクラウドへの移行に関する技術的な推奨事項を含むレポートになります。







質問に対する回答が見つかり、既存のインフラストラクチャの分析が実行された後、次のことが判明する場合があります。

1. WS2003 / R2を実行しているサーバーがありません。
2. ロール/サービス/アプリケーションをWindows Server 2003 / R2から最新バージョンのOSを備えた他の利用可能なサーバーに単純に転送し、サポートから撤回するのに十分なリソースがあります。
3. 利用可能なリソースを可能な限り効率的に使用せず、ライセンス/機器の一部を解放することができます。
4. その非常にユニークな会計アプリケーションは容赦なく時代遅れであり、最新のアナログを備えており、2003サーバーをサポートする必要はなくなりました（通常、最新のアプリケーションでは、より効率的に作業したり、新しい機能を追加したりできます）。

現在何を持っているか、そしてそれがどのように使用されているかを理解したら、ITのビジネスのニーズを理解するために、ITのさらなる発展のビジョンをビジネスと比較します。

• ビジネスの戦略的目標は何ですか？
• 近い将来の彼の計画と、ITからの期待は何ですか？ おそらくこれは従業員の機動性の向上でしょうか？ または、世界中に新しい支店を開きますか？

ビジネスの目標を評価した後、それらを達成する最も効果的な方法を選択できます。 結局のところ、将来のビジョンでインフラストラクチャを更新することで、そのさらなる利用の柔軟性、拡張性、効率性のために大きな一歩を踏み出すことになります。 おそらく、 移行コンサルタントについて覚えておく時間です。 企業、特にIT部門に外部移行コンサルタントが必要なのはなぜですか？ 結局のところ、IT部門には、すべてを自分でできるクールな専門家がいます。



以下のリストは、移行手順を示しています。 それらの期間は、特定のインフラストラクチャとそれらを実行する担当者の資格に依存します。

1. 既存のインフラストラクチャの分析
2. 移行計画の開発
3. 最適なソリューションを選択する
4. ソリューションの実装（実際には、移行）
5. 移行結果の分析とテスト

ここで評価してみてください：

• このプロジェクトに必要な時間を割り当てることができ、十分な資格と経験があるIT部門のスペシャリストがいますか？
• これは、サービスの継続的なサポートにどのように影響しますか？
• 移行プロジェクトをジョブで実行する場合、最終的な期限はどのくらいですか？
• 移行がどの程度適切かつ思慮深く実行され、これがサービスの安定性にどのように影響しますか？

あなたが持っている場合：

• 少量の作業（15台未満のサーバー）;
• 無料で十分な資格のあるリソースがあるか、移行されたサービス/アプリケーションは重要ではありませんが、

最適な解決策は、移行プロジェクトを自分で完了することです。



ただし、次の場合：

• 十分に大きいインフラストラクチャ（15台以上のサーバー）。
• ビジネスに不可欠なサービス/アプリケーションがあります。
• 「IT予算の削減」の制限により、IT部門のスタッフは忙しく、提供されるサービスを損なうことなくプロジェクトの実装に必要な時間を割り当てることができません。

すべての移行作業を完了するか、その一部を実装できる移行コンサルタント会社を選択することをお勧めします。 たとえば、既存のインフラストラクチャを評価し、その近代化に関する推奨事項を提示し、提案の実装を自分で実装します。



ITアウトソーサーの利点は、複数のプロジェクトを完了し、プロセスの潜在的な「落とし穴」と起こりそうな困難を十分に認識している高度な資格を持つ専門家を持つ会社であることです。 彼は、ビジネス戦略と同期して、IT戦略の形成と実装を支援します。







たとえば、クラウドソリューションを詳しく調べることをお勧めします。

1. ビジネスの戦略目標に従業員の機動性の向上に関する項目があり、MS Exchangeが展開されている2003サーバーもある場合、Office 365クラウドソリューションは別のサーバーに移行するのではなく役に立つかもしれません。
2. ビジネスが世界中に支店を開設することを計画している場合は、MS Azureに注意を払います。
3. ハイブリッドクラウドを詳しく調べて、重要でないサービスの多くをパブリッククラウドに移行して、ビジネスに不可欠なサービスを組織内のプライベートクラウドに展開することを検討する時が来たのでしょうか。

以下の図では、クラウドサービスを提供するためのさまざまなオプションを見ることができます。 パブリッククラウドに移行する理由は次のとおりです。

• サーバーを維持管理する必要はありません
• リソースとそのボリューム（IaaS、PaaS、またはSaaS）を取得するための適切なオプションを選択することが可能です。
• 高い耐障害性。

アプリケーションまたはサービスをパブリッククラウドのホスティングに転送できない場合は、Windows Server 2012 R2およびSystem Center 2012 R2およびWindows Azureに基づいたハイブリッドクラウドを構築できます。 長所ハイブリッドクラウド：

• 公開してはならないアプリケーションやサービスをプライベートクラウドで定義してホストします。
• クラウドとMS Azureの両方のリソースを使用する機会があるため、アプリケーションまたはサービスの可用性と必要な容量を柔軟に制御できます。

IIS 6.0でのサイト移行の経験

IIS 6.0から最新バージョンへのサイトの移行に関してかなりの実務経験があるため、Web Deployment Toolを使用して、そのような移行に関するガイドを共有したいと思います。



移行を開始する前に、次のことを確認してください。

1. バックアップがあります。
2. サイトがSQLデータベースを使用している場合、以前に新しいサーバーに移行されたことを確認します。
3. 必要なすべてのログインとパスワードがあります。
4. サイトの運用に必要なすべてのポートが新しいサーバーで開かれています。

Web Deployment Toolで何を移行できますか？

• 1つまたは1000のWebサイト（構成、コンテンツ、証明書を含む）。
• アプリケーション。
• サーバー全体（すべてのWebサイト、アプリケーションプール、レジストリキー、コンテンツなど）。
• サイト、アプリケーションプール、レジストリキー、コンテンツなどで構成されるカスタムマニフェスト。

移行するには、.NET Framework 2.0 SP1以降とWeb Deployment Toolをインストールしておく必要があります。 （Web展開ツールのインストール方法については、 こちら （eng）またはこちら （rus）をご覧ください ）。



手順1.サイトの依存関係を確認し、サイトが使用するスクリプトまたはインストール済みコンポーネントを見つけます。

1. 次のコマンドを使用してWebサイトの依存関係を確認します
   
   

   msdeploy -verb:getDependencies -source:metakey=lm/w3svc/1
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   1はサイトIDです
2. 依存関係の出力を見て、サイトが使用するコンポーネントを決定します。 たとえば、サイトがWindows認証を使用している場合、コマンドの出力は次のようになります。
   
   

    /<dependency name="WindowsAuthentication" />.
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

3. サイトがスクリプトを継承する場合、それらは依存関係のリストに含まれません;継承されたスクリプトは手動で確認する必要があります。

getDependenciesコマンド出力の分析の詳細な説明は、 ここにあります 。



ステップ2.宛先サーバーを構成する



最初のステップで取得した依存関係のリストに従って、必要なコンポーネントをインストールします。 たとえば、依存関係リストにコンポーネントが含まれている場合：

• ASP.NET
• Windows認証
• 匿名認証

したがって、この依存関係のリストに基づいて、適切なコンポーネントとモジュールをインストールする必要があります。



ステップ3.アーカイブを使用してサイトを移行する

1. 移行先のサーバーを常にバックアップしてください。 テストの場合でも。 これにより、サーバーをすばやく元の状態に戻すことができます。
   
   

    %windir%\system32\inetsrv\appcmd add backup “PreWebDeploy”
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

2. サイトアーカイブを使用してファイルを作成するには、ソースサーバーで次のコマンドを実行します。
   
   

    msdeploy -verb:sync -source:metakey=lm/w3svc/1 -dest:package=c:\Site1.zip > WebDeployPackage.log
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   1はサイトIDです
3. 結果のアーカイブをターゲットサーバーにコピーします。
4. 同期の開始時に何が起こるかを確認するには、対象サーバーでコマンドを実行します
   
   

    msdeploy -verb:sync -source:package=c:\Site1.zip -dest:metakey=lm/w3svc/1 -whatif > WebDeploySync.log
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   1はサイトIDです
5. コマンドの結果を確認した後、–whatifスイッチなしで実行します（もちろん、前のコマンドの出力にエラーがなかった場合）
   
   

    msdeploy -verb:sync -source:package=c:\Site1.zip -dest:metakey=lm/w3svc/1 > WebDeploySync.log
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   1はサイトIDです

Web Deployment Agentサービスを使用したサイト移行



リアルタイムのサイト同期を使用する場合は、Web Deployment Agentサービスを使用できます。

1. 可能な同期シナリオの柔軟性を最大限に高めるために、ソースサーバーまたはターゲットサーバー、またはその両方にWeb Deployment Agentサービスをインストールします（エージェントはソースから同期データを受信または送信できます）。
2. サービスを開始する
   
   

    net start msdepsvc
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

3. 次のコマンドを実行して、ローカルソースからリモートサーバーへの同期（データの送信）を開始します（Server1をサーバーの名前に置き換えます）。 最初に、-whatifフラグを指定してコマンドを実行し、実行結果を確認した後、コマンドを実行しないことをお勧めします。
   
   

    msdeploy -verb:sync -source:metakey=lm/w3svc/1 -dest:metakey=lm/w3svc/1,computername=Server1 -whatif > msdeploysync.log
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   1はサイトIDです
4. 次のコマンドは、リモートサーバーからのデータの「受信」モードで同期を開始します
   
   

    msdeploy -verb:sync -source:metakey=lm/w3svc/1,computername=Server1 -dest:metakey=lm/w3svc/1 -whatif > msdeploysync.log
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   1はサイトIDです

これで移行プロセスが完了し、ターゲットサーバーのサイトを確認するために残ります。 問題が発生した場合は、 トラブルシューティングWeb配置を使用して解決策を見つけることができます。



進歩は絶え間ない動きであることを覚えておくことは重要です。 時代遅れのテクノロジーの使用は、機会の制限または進捗の遅れを意味することが非常に多く、遅かれ早かれ、それを埋め合わせる必要があり、遅れが大きければ大きいほど、リーダーに追いつくことは言うまでもなく、それを減らすためにより多くの努力が必要になります。



著者aleksjoke