「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
サーバ更改（バージョン・アップ移行）のケース
共通的な変更点 †
2003 → 2008 †
- UAC
- Session0分離
- パス(e.g. %USERPROFILE%)
2008 → 2019 †
ウォッチできてません。
移行パス †
インプレースアップグレードがサポートされている。 †
こちらがサポートされているとだいぶ楽だが、
周辺のソフトウェアもアップグレードされたOSでサポートされている必要がある。
Windows Server 2003は、Windows Server 2008 R2までのインプレースアップグレードがサポートされている。ただし、次のような要件がある。
- 「Service Pack（SP）2」が適用されていないWindows Server 2003はサポートしない
- 異なるアーキテクチャ間のインプレースアップグレード（x86からx64など）はサポートしない
- 異なる言語間のインプレースアップグレード（英語からドイツ語など）はサポートしない
- 異なるエディション間のアップグレード（例えば、Windows Server 2008 Foundation SKUからWindows Server 2008 Datacenter SKU）はサポートしない
- 種類が異なるビルド間のインプレースアップグレードはサポートしない
インプレースアップグレードがサポートされていない。 †
再構築が必要になる。
・・・その理由は、Windows Server 2003からWindows Server 2012 R2へのインプレースアップグレードがサポートされていないからだ。
2003 ---> 2008 ---> 2012 †
2003 ---> 2008 ---> 2012というインプレースアップグレードも考えられるが、
2003、2008が32bitの時は、このアップグレードパスは成立しない。
- マイクロソフト認定トレーナーが教える、Windows Server 2012 マイグレーションの手引き - (page 3) - ZDNet Japan
http://japan.zdnet.com/extra/windows_server_2012/35029010/3/
Windows Server 2012へインプレースアップグレードができるのは、既存のOSがWindows Server 2008 R2、または64ビット版のWindows Server 2008だけである。
既存のOSがWindows Server 2003以前、または32ビット版の場合は、インプレースアップグレードができないため、新しいハードウェアに移行する方法をとる必要がある。
2012 ---> 2016 ---> 2019 †
ウォッチできてません。
サーバ・アプリケーション †
種々の要件から、サーバ・アプリケーションの移行が可能か調査が必要になる。
シェル（スクリプト）のバージョン・アップ移行 †
CMDやWSHの構文は、2003→2008でもほぼ変わりません(違いが探せないくらい)。
従って、移行性は、その中でどのようなコマンド、API類を使用しているかに100%依存する。
業務系スクリプトの移行性 †
WSHでADODBやoo4oなどのCOM系データプロバイダを使用した
業務処理のスクリプトの場合、ほぼストコンで問題も少ない。
基盤系・運用系スクリプト †
OSやミドルウェアの提供するコマンド、API類を使用した基盤系・運用系スクリプトの場合、
＃WSHから利用できるAPIはCOMインターフェイスに限定される。
バージョン・アップによるインターフェイス・ミドルウェア変更により
スクリプト修正の負荷が増加する可能性がある。
また、これらの基盤系・運用系スクリプトのテストでは、特にWMIのスタブ開発は困難であるため、
＃WMIを使用している場合、WMIクエリに対応したスタブを作成する必要があるが実質的に不可能。
これらのスクリプトのテストには、OSやミドルウェアを含め構築済みの環境を準備しておく必要がある。
移行性の確認 †
- WSHであれば、OSやミドルウェアの提供するCOMインターフェイスのAPIを使用している
箇所のインターフェイス変更によりWSHのポーティングが必要になる可能性がある。
従って、この部分をグレップで検索して引っ掛けて、個々に確認すると良い。
- COM
- CreateObject?（プログラム IDからCOMオブジェクトを生成するAPI）
CUI系もCreateObject?("WScript.Shell")で引っかかる。
- GetObject?（ファイルからCOMオブジェクトを生成するAPI）
再構築の場合 †
OSパラメタの移行 †
基本方針 †
- パラメタをそのまま2003→2008R2に変換するのは困難な所もある（既定値が違う、マップが違う）
- GUIの表記では、OSバージョンで揺らぎがあるので、一致する項目を、画面上から探すのは難しい。
- なので、要件一覧や機能一覧などから、「必要な機能」と言う要件の観点から見ることも必要。
- 2003と同じに.. ではなく、2008R2 の既定、に加えて、何が必要か？を検討すべき。
- ただし、お客様としては、現行パラメタ踏襲により、リスク回避したいという意向もある。
- ただし、過去事例からOSのTCP/IPスタックの実装が変わっている等の変更もあるようなので、
現行パラメタ踏襲で問題が全く起きないとは言い切れない。
変更点 †
変更もあるので、ガイドラインに従うか、個別に変更を確認した方が良い。
e.g.
- セキュリティポリシー
- 変更点
- 既定値が変わっている可能性がある。
構成しない場合、既定値はクライアント依存。
- 選択肢の増減
ドメインの機能レベル、バージョンで異なる。
マップが違う †
e.g.
- 2003のWindowsコンポーネントと、
- 2008のサーバーの役割と機能
では、対応付けが困難なほど変更されており、
この部分のパラメタ・シートの流用は困難。
（
機能・役割（2003→2008R2）.xlsx参照）
firewall †
firewall関係は、大きく変わっている。
2008から、
などのプロファイルができた。
netsh firewall xxx コマンドは、ほぼ役に立たなくなっていて、
netsh advfirewall firewall xxx に変わっている。
MSCS/WSFC †
こちらを参照。
ハードウェア †
NIC †
NIC設定はNICのドライバに依存する。
従って、物理移行や、仮想化でパラメタが変更される可能性あり。
ベンチマークツール †
ベンチマークツール
構成変更 †
ライセンス変更 †
ライセンスが変更になるケースがある。
e.g.
IIS の リモートデスクトップWeb接続 (ActiveXとサンプルページ)が有効のサーバがあるが、
2008R2 では、リモートデスクトップWebアクセス に含まれる、と思われる。
この役割・機能に変更する場合、リモートデスクトップ は、RDS CAL が必要なので、
要件とライセンスについて、検討が必要になる可能性がある。
仮想化 †
物理の2003の構成パラメタを、そのまま仮想（ゲストOS）の2008R2の構成パラメタへ変換しよう、
など考えないで、移行の全体像をよく検討してから、細部のパラメタをどうするか、検討する。
- 物理、仮想、どちらで、なにを行うか、行えるか(特に、ネットワークとストレージ)。
- ゲストOS上でのNICのチーミング方法の変更（ホスト側のチーミング機能を利用）。
- ゲストOS上でテープ・ドライブを使用できない（バックアップ方法の変更）。
移行ツール †
移行ツールは探せばあるものも多い。
- XXXX Migration Tool (XXXXMT)
ただし、Microsoftは、移行を支援するツールは出しても、
差異を明確にした資料、設定値を移行する資料は、出さない
（単純にマップできず、説明も難しいためと思われる）。
Tags: :Windows, :移行
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
