Windows Server 2003のサポート終了に伴う移行計画～アプリケーションの観点から～日本マイクロソフト株式会社

コンサルティングサービス統括本部

コンサルタント

稲葉歩

Agenda

• はじめに

• 移行プロジェクトの概要

• 後方互換性のポイント

• コンサルティングサービスのご紹介

• Q＆ A

はじめに

Windows Server のサポート

Windows Server 2003 / 2003 R2の延長サポート終了まで残り 1年と 5か月 Windows Server 2008 / 2008 R2では残り 6年 5か月

Windows Server 2012では残り 9年のメイン／延長サポートが提供される

本セッションのテーマ

• Windows Server 2003上で動作する業務アプリケーション移行の勘所を紹介します• 主として IIS上で動作する ASP.NETアプリケーションおよび

Windows DNAアプリケーション（ASP）を対象に解説します

Cloud OS Roadshowなのに・・・

•今回はオンプレミスからオンプレミスへの移行

をお勧めします

Windows Server 2003 Windows Server 2012 R2

Windows Azure

移行プロジェクトの概要

移行プロセス

移行方針は大きく３種類新規開発・再構築 後方互換性 仮想化

特徴新しいインフラ・ランタイム上で設計・実行からやり直す

ソースコードを極力修正せず、新しいインフラ・ランタイム上で動作させる

現行相当のインフラ・ランタイムを仮想環境に再構築し、まるごと延命する

アプローチ アプリ的 ← → インフラ的

有効期間 長期的 ← → 短期的

適用対象 個別 ← → 広範囲

コスト 高 ← → 低

自由度 高 ← → 低

メリット最新技術をフル活用することができ、機能追加や修正も可能

コストを抑えつつ、最新の環境に移行することが可能

互換性問題が発生しにくく、短期的なコストを安く抑えることが可能

デメリット開発のコストが大きくなり、プロジェクト期間も長期化しがち

非互換問題が発生しうるため、多少の修正が必要になる

あくまでも短期的な延命策であり、いずれは何らかの移行が必要

後方互換性による移行のススメ

• サポート切れに伴う移行プロジェクトでは基本的に後方互換性方式の採用を推奨• 組織内の多数の業務アプリが同時多発的に移行を迫られるため、新規開発・再構築方式はリソース・スケジュール的に厳しくなりがち

• 仮想環境上の Windows 2003も同様にサポートが切れるため、このシチュエーションでは仮想化方式は選択肢になりえない

• ソフトウェアテストの目的は業務アプリケーションの品質保証• 後方互換性は「新しいインフラ・ランタイム上で動かす」ためのコストを極力抑えるための手段に過ぎない

• 互換性が高ければ高いほどテスト時に問題が発生するリスクを抑えることもできる

• しかしそれを根拠に「大丈夫なはずだからテストはしなくてよい」という発想は非常に危険

結局大変なのはテスト

移行が終わったその後に

• まずは確実に移行を終わらせた上で、様々な機能追加・拡張等を行うことを推奨

Windows 2003 Windows Server 2012 R2

後方互換性のポイント

後方互換性は 4レベル

• アプリケーションスタックの 4つのレベルで互換性を意識する必要がある• 特に赤字で示されたような特色を持つ現行資源は、互換性の問題を引き起こす可能性が高い

レベル移行前

Windows Server 2003

移行後

Windows Server 2012 R2互換性のキーワード

アプリVisual Studio 2003 / 2005で開発

Visual Studio 2012 / 2013で開発ソースコードとバイナリの互換性保守環境のアップグレード

ASP.NETASP.NET 1.1 / 2.0が主流(ASP.NET 4.0も動作は可能)

ASP.NET 2.0 / 4.0が動作可能IIS統合パイプラインとASP.NET 独立パイプライン

IIS 構成設定をメタベースで管理 ASP.NET構成設定と部分的に統合 メタベースと構成ファイル

OSWindows Server 2003の時代はx86版が主流

Windows Server 2008 R2以降のサーバー OSは x64版のみ

WOW64

Windows 32-bit On Windows 64-bit

64ビットWindowsにはWOW64と呼ばれる x86命令セットを処理するエミュレータが搭載 互換性は極めて高く、デバイスドライバ類を除けばほとんど動作する

x86版Windows OS上でのネイティブ動作と比較しても性能的な遜色がない

64bit化をがんばらない

現状 32bit プロセスで問題なく運用されているアプリならば無理に 64bit化する必要はない ASP.NETや ASPの場合は独立したプロセスを作成せず、 IISワーカープロセス（ w3wp.exe ）に読み込まれことで動作する

WOW64を使用することで 32ビット版の ISAPI拡張、ISAPIフィルタ、ネイティブ DLL / COM といった既存資産を動作させることができる

IIS / ASP.NETの設定

IIS 7以降で IISと ASP.NETの構成設定ファイルの部分的な統合が行われた これにより同一の枠組みの中で構成していくことが出来るようになったが、正しく理解していないと混乱するため注意が必要

Windows 2003 2012 R2

IISのバージョン 6.0 8.5

IIS設定の保存先 メタベース applicationHost.config, web.config

IIS設定の編集 IISサービスマネージャ IISサービスマネージャ、テキストエディタ

ASP.NET設定の保存先 machine.config, web.config machine.config, web.config

ASP.NETの編集 テキストエディタ IISサービスマネージャ、テキストエディタ

設定内容とその保存先

ASP.NET独立／ IIS統合パイプライン

IIS / ASP.NETは本体となるメインの処理を行うほかに前処理や後処理を行う仕組みを提供している パイプライン型の処理モデルによって共通的な前処理／後処理を組み込めるようになっている

これによってアプリケーションランタイムとしてのカスタマイズ性を確保している

パイプラインもこれまで通り

IIS 6.0 以前は IIS と ASP.NET パイプラインは独立していたが、IIS 7.0 からは統合パイプラインを提供 IIS 8.5においてもクラシックモードのパイプラインが利用できるため、ASP.NETパイプラインが IISパイプラインから独立した動作をさせることができる

つまり IIS 6.0と互換性のある動作をさせることができるため、あえて苦労してまで新しく追加された統合パイプラインモードを採用する必要はない

アプリの後方互換（その前に）

• 比較的最近作られたアプリであればそのまま移行できる可能性が高い• IIS 8.5でも ASP.NET 2.0はサポートされている

• つまりVisual Studio 2005～ 2008の頃に作られたアプリであればそのまま動作させることができる

アプリの後方互換は２種類

• アプリケーションランタイムによるバイナリ互換

• 統合開発環境／コンパイラによるソースコード互換

開発・保守環境

最後までお付き合い

• アプリの移行ではソースコード互換方式を推奨• 実は Visual Studio .NET 2003も既にサポートが切れている

• 新しい実行環境で動作するアプリを、古い開発環境で保守するのは非現実的

非互換に当たれば修正が必要

• .NET Frameworkの API互換性は完全ではない• .NET Framework の互換性と移行に関する情報• http://msdn.microsoft.com/ja-jp/library/cc825635.aspx

• .NET Framework 2.0 での重大な変更点• http://www.microsoft.com/japan/msdn/netframework/programming/breakingchanges/default.a

spx

• .NET Framework 1.1/3.5 移行ホワイトペーパー• http://download.microsoft.com/download/5/5/b/55b34c74-2b8f-423c-94ad-

4e22c0ae60f0/netFramework_migration_1.1_to_3.5.pdf

• .NET Framework 2.0～3.5 から .NET Framework 4.0 への移行• http://www.microsoft.com/ja-jp/net/migration/document4.aspx

• 手間はかかるが開発環境も移行すべき• そもそも非互換問題は 3rd Party製品でも発生しうる

Windows DNAアプリは？

• ASPの場合も ASP.NETの場合と考え方はほぼ同じ• クラシックモードパイプラインによる IIS 6.0互換動作

• IIS構成設定をメタベースから構成ファイルへ移行

• WOW64による 32bitプロセスエミュレーション

レベル移行前

Windows Server 2003

移行後

Windows Server 2012 R2互換性のキーワード

アプリ ASP＋ VB6 COM + OLE DB ASP + VB6 COM + OLE DB －

ASPランタイム

ISAPIフィルタで拡張ISAPIフィルタで拡張.NET HTTPモジュールで拡張

クラシックモードパイプライン

IIS 構成設定をメタベースで管理 ASP.NET構成設定と部分的に統合 メタベースと構成ファイル

OSWindows Server 2003の時代はx86版が主流

Windows Server 2008 R2以降のサーバー OSは x64版のみ

WOW64

Windows DNAアプリは？

• Windows DNA世代の既存資産は、往々にして 32bitしかサポート／想定していないことが多い• ASPランタイムには 64bit版も提供されているが、その他の資産が全て 64bit 対応していない限り使用できない

• これまでWindows Server 2003上で 32bit動作させていなければ、わざわざ 64bitを選ぶ意味がない

まとめ

後方互換性のポイント

• IIS管理ツールを使用してランタイムの互換性を構成する• WOW64 による 32bitプロセスエミュレーション

• クラシックパイプラインによる IIS6互換動作

• CLRバージョンはアプリに合わせる

• その他の各種設定も構成ファイルへ移行

• ASP.NET 2.0アプリはそのまま、1.1アプリはソースコード移行

• Windows DNAアプリは COMやランタイムの互換性を考慮

移行は計画的に

• アップグレード戦略は大きく２つ• どちらも一長一短だが、サポート切れに伴う一括アップグレードは対応が後手に回りやすいので注意が必要

2003 2003R2 2008 2008 R2 2012 2012 R2 2003 2003R2 2008 2008 R2 2012 2012 R2

Microsoft Consulting Services

#751 .NET Framework Application Upgrade

• 互換性についてもっと詳しく、サーバー以外についても知りたい！• コンサルティングサービスで培われてきたノウハウを効率的に学習できるワークショップ

• Part 1. 移行に関する基礎知識• Module 1 .NET Framework の各バージョンの関係

• Module 2 .NET アプリケーションの互換性基礎

• Module 3 .NET Framework の 64 ビットサポート

• Module 4 アップグレードに関する基本的な考え方

• Part 2. 実際の移行手法• Module 5 クライアントアプリケーションのアップグレード

• Module 6 サーバーアプリケーションのアップグレード

• Module 7 開発環境のアップグレード

#505 Source Control Migration from VSS to TFS

• 開発環境（Visual Studio）を移行するならソース管理も移行しなきゃ！• Visual Studio .NET 2003とともに使用されていた Visual SourceSafeはソースコード管理システムとしての役割をすでに終えている

• Agenda• Module 1 VSS と TFS の違い

• Module 2 VSS によるソースコード管理概要

• Module 3 TFS によるソースコード管理概要

• Module 4 VSS から TFS へのソースコードの移行

クラウド化全力支援サービス

• どのシステムをクラウド化すればよいかわからない？• 約 4週間のクイック診断を実施

• クラウド化の実現に向けたオポチュニティを抽出

• システムの優先順位を評価してロードマップを策定

Internet Explorer 11移行ガイド

• 従来の IE向けに作られた業務アプリを IE11で動作させるためのポイントを紹介したホワイトペーパー• MCSのコンサルタントが執筆• 移行プロジェクトの進め方

• IEの互換性機能の解説

• 互換性検証用のサンプルスクリプト

• 最新のWeb標準規格への対応

• Technetにて公開中• http://technet.microsoft.com/ja-jp/ie/dn262703

事例紹介

• IT環境・ビジネス環境の変化への俊敏な対応を目指して、プロアクティブな活動を開始• Windows 7対応に数年を要したため、環境変化への追随に不安

• 組織の体質・体制の改善のために MCSがご支援

環境変化に追随できる俊敏性の獲得

アプリケーションインベントリー

標準化された改修作業

工程・方式の標準

化・定型化標準化の定着

改修労力の少ないアプリケーション実行

環境

Windows 互換性機

能の活用

アプリケーション

インフラの活用

アプリケーション

配布

SCCMの利用拡大

Q&A