Skip to content

MS_CRMUpgrade2011To2013

nishi_74322014 edited this page Sep 1, 2026 · 1 revision

CRMのアップグレード(2011→2013)

概要

アップグレードの計画、考慮事項、手順。

補足(本ページの位置づけ): 本ページは
移行・コンバージョン方式で言う
アップグレード(開発ツール・ランタイムのバージョンアップ)の
具体例として読める。
サーバ更改(バージョン・アップ移行)で扱った
「インプレースか、再構築か」という選択が、
ここでは3 つの方法の比較
という形で整理されている。

考慮事項

制限、要件、タイムスケールを把握し、ダウンタイムを最小限に抑える。

パス

バージョン

CRM2011 以前のバージョンのアップグレード パスは、
後継のバージョンへのアップグレードのみ有効。

  • CRM3.0 → 4.0 → 2011 → 2013

補足: サーバ更改(バージョン・アップ移行)
「インプレースは原則 1 世代ずつ」と同じ制約である。
世代を飛ばせないため、古い版からの移行は多段になり、
各段でメディア・ライセンス・前提条件が必要になる。

エディション

エディションは同じになる。

  • CRM2011 Workgroup → CRM2013 Workgroup
  • CRM2011 Server → CRM2013 Server

経由する場合は、評価版を使用。

  • CRM4.0 → 2011(評価版)→ 2013

更新プログラム

CRM2013 にアップグレードできる CRM2011 は
以下の更新プログラムのロールアップを適用した CRM2011 だけ。

  • 更新プログラムのロールアップ 6
  • 更新プログラムのロールアップ 14 以降

方法

一括(インプレース アップグレード)

CRM 2011 Server を CRM 2013 Server にアップグレード

SQL Serverの同じインスタンスを使用した移行

[既存の展開に接続し、必要な場合はアップグレードする]オプションを選択し、
構成データベースと組織データベースがアップグレードされる。

SQL Serverの新しいインスタンスを使用した移行

組織データベースを新しい SQL Server インスタンスに復元してインポートする。

比較

一括(インプレース アップグレード)の特徴

  • 旧サーバがインストール要件を満たす。
  • 新しいハードウェアは必要ない。
  • 最も簡単
  • ダウンタイムは最長
  • 失敗からの回復が困難
  • 組織データベースのアップグレードは必須でない。
  • 無効になった組織は展開マネージャでアップグレードする。

SQL Serverの同じインスタンスを使用した移行の特徴

  • 追加ハードウェアが必要
  • 既存の CRM2011 は影響を受けない。
  • 組織データベースがアップグレード可能な
    更新プログラムのロールアップのバージョンである必要がある。
  • アップグレードされるのは既定の組織だけ。
  • その他の組織は展開マネージャでアップグレードする。

SQL Serverの新しいインスタンスを使用した移行の特徴

  • 追加ハードウェアが必要
  • 新しい SQL Server or 新しい SQL Server インスタンスが必要
  • 既存の CRM2011 は影響を受けない。
  • 既存の CRM2011 は最終的な移行まで維持される。
  • 移行のリトライが可能
  • ダウンタイム最短
  • テスト環境、トレーニング環境の構築に役立つ。

補足(3 つの方法のトレードオフ): 上記を整理すると次のようになる。

一括(インプレース) 同じインスタンスへ移行 新インスタンスへ移行
追加ハードウェア 不要 必要 必要
旧環境の維持 不可(上書き) 可(DB は共有) (完全に独立)
リトライ 困難
ダウンタイム 最長 最短
手間 最小 最大

「元に戻せるか」と「コスト」のトレードオフという、
ローリング・アップグレード
サーバ更改(バージョン・アップ移行)
同じ構図になっている。
本番システムでは、リトライ可能性を買うために
新インスタンスへの移行を選ぶのが定石である。

その他

CRM2011レポート拡張機能

アンインストールする必要がある。

プロダクトキー

アップグレードの開始前に入手。

権限

  • 展開管理者ロール
  • システム管理者セキュリティロール
  • 管理者権限
  • 組織単位に新しいセキュリティグループを作成する権限

機能

互換性の無い機能

展開内の CRM2011 と CRM2013 には互換性が無いので、
全ての役割をアップグレードする必要がある。

推奨されない機能

推奨されない SDK カスタマイズはアップグレードされない。

  • 推奨されない SDK カスタマイズ
    • CRM4.0 プラグイン
    • CRM4.0 クライアント側スクリプティング
    • CRM4.0 カスタム ワークフロー
    • 2007 Web サービスエンドポイント
    • カスタム Web アプリケーション用の ISV フォルダー
    • Solutions Down Level ツール

推奨されない SDK カスタマイズの検出ツール

補足(検出ツールの意義): 移行性評価作業の作業内容
「網羅的なチェックリストは作成困難なので、実際に移行してみて洗い出す」と
述べられていたが、本節のようにベンダが検出ツールを提供している場合は、
移行性評価の初動を大きく短縮できる
移行性評価作業の最初にやるべきは、
「そういうツールが提供されていないか」を調べることだと言える。

テーブルの結合

CRM2011 以前では、以下に分割されていた。

  • XXXXXBase テーブル
    • システム フィールド
  • XXXXXExtentionBase テーブル
    • カスタム フィールド

CRM2013 ではパフォーマンス向上のため、単一のテーブルに。

  • XXXXX テーブル
    • システム フィールド
    • カスタム フィールド

補足(なぜ分割されていたか/なぜ結合したか): 分割していたのは、
カスタム フィールドの追加でシステム テーブルの構造を変えずに済ませるためである。
ただし、参照のたびに 2 テーブルの結合が発生するため性能が犠牲になっていた。
CRM2013 での結合は、その性能を取り戻す変更にあたる。

ここで重要なのは、この変更が既存のカスタム レポートに影響することである。
CRMのサポート・テクノロジ
「テーブルに直接クエリを実行することはサポートされない」
と強く述べられているのは、まさにこのような
内部構造の変更に巻き込まれないためである。
フィルター・ビュー経由で作られたレポートは
このテーブル結合の影響を受けない。

テーブル結合の延期

ダウンタイム短縮のため、テーブル結合を延期できる。

一括(インプレース アップグレード)の場合

  • [アップグレードする組織を選択して下さい]

    • → [なし]を選択(結合されない)。
    • → 任意の[組織]を選択(結合される)。
  • [なし]の選択後に、レジストリに次のサブキーを追加。

    • 場所: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM\MergeBaseAndExtensionTables
    • 種類: DWORD (32 ビット)
    • 値: 0
  • 展開マネージャーを使用して既存の組織をアップグレード。

    • 展開マネージャーを起動
    • アップグレードする組織を右クリック
    • [アップグレード]をクリック
    • テーブルは結合されない。

SQL Serverの同じインスタンスを使用した移行の場合

データベースがアップグレードされる(そもそも結合される)。

SQL Serverの新しいインスタンスを使用した移行の場合

データベースがアップグレードされない(そもそも結合されない)。

遅延させたテーブルの結合

新機能を使用できないので早めの結合完了が推奨される。

概要

  • レジストリに次のサブキーを設定。

    • テーブルの結合
      • 場所: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM\MergeBaseAndExtensionTables
      • 種類: DWORD (32 ビット)
      • 値: 1
    • カスタムのインデックス再作成
      • 場所: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM\EnableRecreateCustomIndexes
      • 種類: DWORD (32 ビット)
      • 値: 1
    • その他、トランザクションログの扱いを決めるキーなどもある。
      エンティティ マージ操作の完了後、閾値に達していたら切り捨てる。
  • テーブル結合ツールを実行する対象の組織を無効にする。

  • テーブル結合ツールを実行する。

移行メモ(正誤): 元ページの「設定/設定」は「設定」の重複、
「達していたらに切り捨てる」は「達していたら切り捨てる」の誤記、
「実行する体操の組織」は「実行する対象の組織」の誤変換と判断し、修正した。

テーブル結合ツール

c:\Program Files\Microsoft Dynamics CRM\Tools\CrmMergeBaseAndExtensionTableTool.exe

  • コンソール アプリケーション
  • 展開管理サーバか SQL Server が実行されているコンピュータで実行する。
  • 結合するテーブルを選択できるため、ダウンタイムを最小限にできる。

前提

  • 展開管理者ロール
  • 管理者権限
  • 組織データベースに対する db_owner アクセス許可

方法

CrmMergeBaseAndExtensionTableTool /s: /o: [/b:] [/log:] [/u:] [/p:] [/e:,...]
  • すべてのエンティティ テーブルをマージする例:
CrmMergeBaseAndExtensionTableTool /s:CRMSQLServer /o:Contoso_MSCRM /log:c:\Logs\mergetoollog.txt
  • 取引先企業および取引先担当者エンティティ テーブルをマージする例:
CrmMergeBaseAndExtensionTableTool /s:10.125.156.135 /o:Contoso_MSCRM /e:Account,Contact c:\Logs\mergetoollog.txt

マージされなかったエンティティの確認

SELECT e.Name, e.ExtensionTableName
FROM EntityView e
where e.IsActivity = 0 and e.ExtensionTableName is not null
and e.IsIntersect = 0
and e.IsLogicalEntity = 0
order by e.Name

補足(この「分割してダウンタイムを刻む」手法): エンティティ単位で
マージできるという設計は、
ローリング・アップグレードで述べた
**「一括切り替えではなく、少しずつ切り替える」**という考え方の
データ移行版にあたる。
大きなテーブルだけ夜間に分けて処理する、といった運用が可能になる。

アップグレードの計画

  • アップグレードの準備
  • テスト環境の確立
  • テスト環境を使用したアップグレード検証
  • 運用環境を使用したアップグレード検証

アップグレードの準備

  • リソース

    • 人員
    • 時間
  • テスト環境

    • ハードウェア
    • ソフトウェア
    • 検証

戦略

  • アップグレードの必要性
  • アップグレードの対象コンポーネント
  • アップグレード パス
  • テスト環境構築に必要なもの
  • アップグレード スケジュール
  • サードパーティのアドオン・コネクタのサポート

補足: 最後の「サードパーティのアドオン・コネクタのサポート」は、
移行性評価作業の作業内容
最も見積もりが外れやすい箇所として挙げられている項目と同じである。

エラー時の復旧計画

  • 問題の文書化と代替計画の用意。

    • JScript のコード
    • カスタム レポート
    • ワークフロー
    • サードパーティのアドイン
  • システムのロールバックの準備

    • 運用環境のバックアップ
    • 運用環境の復旧

チェック リストの準備

  • アップグレード後、システムが機能していることを確認。

テスト環境の確立

アップグレードの検証用に使用する CRM2011 のコピー。
仮想化テクノロジは、このプロセスに役立つ。

  • ユーザの受け入れテスト

    • さまざまなエンティティの CRUD や、関連するエンティティの検証。
    • レポートが想定どおりに実行されていることを確認。
    • ワークフローが想定どおりに実行されていることを確認。
      構成、データ モデルの変更の影響を受けるワークフロー アイテムを更新
    • カスタム コード、JScript のコード、カスタム レポートのテスト
    • 統合プロセスのテスト
    • アドオンのテスト
  • 「SQL Server の新しいインスタンスを使用した移行」の場合、
    テスト環境がアップグレード後に運用環境になる。

  • テストの範囲、厳格さ

    • 構成

      • 負荷分散構成
      • クラスタリング
    • コンポーネント

    • , etc.

補足: これは移行時のテスト工程の工数で述べた
「移行では入出力が変わらないことが期待値になるため、
回帰テスト(差分比較)と相性が良い」という話が
そのまま当てはまる場面である。

ドメイン

テスト用のドメインを確立

既存環境のバックアップ

  • 構成データベース
  • 組織データベース
  • レジストリ
  • サードパーティ製ソリューション

方法毎の手順

一括(インプレース アップグレード)の準備

  • SQL Server のデータベースのバックアップとリストア

    • 構成データベース
    • 組織データベース
  • CRM2011 をインストールし[既存の展開に接続]。

  • サードパーティ製ソリューションの適用など。

SQL Serverの同じインスタンスを使用した移行の準備

  • SQL Server のデータベースのバックアップとリストア

    • 構成データベース
    • 組織データベース
  • CRM2011 はインストールしない。

SQL Serverの新しいインスタンスを使用した移行の準備

  • SQL Server の組織データベースのバックアップとリストア
  • CRM2011 はインストールしない。

テスト環境のアップグレード検証

以下の方法に対してテスト環境でアップグレード検証を行う。

  • 一括(インプレース アップグレード)
  • SQL Server の同じインスタンスを使用した移行
  • SQL Server の新しいインスタンスを使用した移行

受け入れテスト

結果によって、アップグレードを運用環境に実装するか・どうかを決定する。

  • あらゆる日常業務を実行するユーザ
  • チェックリストを処理
  • テスト結果と受入条件のチェック

移行メモ(正誤): 元ページの「チェッック」は「チェック」の誤記と判断し、修正した。

運用環境のアップグレード

  • 以下の方法に対して運用環境のアップグレードを行う。

    • 一括(インプレース アップグレード)
    • SQL Server の同じインスタンスを使用した移行
    • SQL Server の新しいインスタンスを使用した移行
  • 運用環境のデータベースの完全バックアップを忘れずに行う。

    • 構成データベース
    • 組織データベース
  • リストアを考慮して、空き容量も確保しておく。

    • データ ファイル サイズの 3 倍
    • ログ ファイル サイズの 4 倍

一括(インプレース アップグレード)の手順

  • CRM2011 レポート拡張機能がインストールされている場合はアンインストールする。

  • アップグレードするサーバーで CRM2013 のセットアップを起動する。

  • CRM2011 が検出されると[Microsoft Dynamics CRM 2013 へのアップグレード]ページが表示される。

  • [アップグレードする組織]を選択するから[なし]を選択する。

  • サービス アカウントを指定する。

    • CRM Server のサービス アカウントを指定する(CRM2011 の設定を引き継ぐことも出来る)。
    • VSS ライターサービスのサービス アカウントを指定する。
    • 監視サービスのサービス アカウントを指定する。
  • [E-Mail Router の設定の指定]にインストール先コンピュータ名を入力する。

  • [Microsoft Update 基本設定の選択]でオプションを選択する。

  • [システムのチェック]ページが表示される。

  • [サービスの中断の警告]ページが表示される。

  • [アプリケーションのアップグレード準備の完了]ページが表示される。

  • [Microsoft Dynamics CRM Server のセットアップが完了しました]ページが表示される。

  • CRM2013 レポート拡張機能をインストールする。

  • 展開マネージャでアップグレードされていない組織をアップグレードする。

SQL Serverの同じインスタンスを使用した移行の手順

  • CRM2013 のセットアップを起動する。
  • [展開オプションの指定]ページで[既存の展開に接続し、必要な場合はアップグレードする]を選択する。
  • データベースがアップグレードされると既存の CRM 2011 Server は使用できなくなる。
  • 必要に応じて、CRM 2011 Server を停止するか、アップグレードする。

SQL Serverの新しいインスタンスを使用した移行の手順

  • CRM2013 のセットアップを起動する。

  • [展開オプションの指定]ページで[新しい展開の作成]を選択する。

  • CRM 2011 Server で展開マネージャを起動して展開を無効にする。

  • 旧 SQL Server インスタンスの組織データベースをバックアップする。

  • 新 SQL Server インスタンスに組織データベースをリストアする。

  • CRM 2013 Server で展開マネージャを起動し組織データベースをインポート(アップグレード)する。

    • インポート毎に展開マネージャを再起動するとログが分割される。
      ログ ファイルのパス:%APPDATA%\Microsoft\MSCRM\Logs

E-Mail Routerのアップグレード

アップグレードにより構成設定を維持できる。

移行メモ(正誤): 元ページの「構成セッテ」は「構成設定」の誤記と判断し、修正した。

状態記録用ファイルのバックアップ

アップグレード前に状態記録用ファイルのバックアップを行う。

  • Drive:\Program Files\Microsoft CRM Email\Service\
    • Microsoft.Crm.Tools.EmailAgent.Configuration.bin
    • Microsoft.Crm.Tools.EmailAgent.SystemState.xml
    • Microsoft.Crm.Tools.EmailAgent.xml
    • Microsoft.Crm.Tools.Email.Management.config
    • EncryptionKey.xml

補足: EncryptionKey.xml が含まれている点に注意。
CRMの展開の管理とトラブルシューティング
レコードの暗号化と同様に、鍵を失うと復旧できない

アップグレード

  • ローカルコンピューターの Administrators グループの
    メンバとなっているユーザとしてドメインにログオンしてインストール。
  • SetupEmailRouter.exe ファイルを実行(ダウンロード or メディア)。

セットアップ ページ

[Microsoft Dynamics CRM の更新プログラムを取得する(推奨)]をクリック(推奨)。

更新プログラムの確認

[更新プログラムを確認しています]ページで[次へ]をクリック。

使用許諾契約書

[使用許諾契約書]ページで[同意する]をクリック。

必要なコンポーネントのインストール

[必要なコンポーネントのインストール]ページで[インストール]をクリック。

  • 全てインストールされている場合は、スキップ。

  • コンポーネントのセットアップファイルが見つからない場合、
    インターネット接続が要求されることがある。

  • インストール時に再起動が必要とされる場合がある。
    その場合、再起動後に SetupEmailRouter.exe を再起動する。

アップグレードするE-Mail Routerのコンポーネントを選択

[Router コンポーネントの選択]ページで
インストール済みのコンポーネントがアップグレード対象として選択される。

システムのチェック(E-Mail Router)

(元ページ未記載)

アップグレードの準備完了

(元ページ未記載)

アップグレードの成功

(元ページ未記載)

アップグレードの失敗

アップグレードが失敗した場合、以下の手順に従う。

  • アップグレードに失敗した CRM 2011 E-Mail Router をアンインストールする。
  • CRM 2011 E-Mail Router を再インストールする。
  • 更新プログラムのロールアップを再インストールする。
  • CRM 2011 E-Mail Router サービスを停止する。
  • 状態記録用ファイルを復元する。
    • Drive:\Program Files\Microsoft CRM Email\Service\
  • CRM 2011 E-Mail Router サービスを開始する。
  • アップグレードをリトライする。

Outlook用Microsoft Dynamics CRM 2011のアップグレード

計画

段階的なロールアウト

には互換性があるため、段階的なロールアウトを実行できる。

※ 先にクライアントをアップグレードしない(互換性がないので)。

補足: サーバを先、クライアントを後という順序は、
CRMの展開の管理とトラブルシューティング
「クライアント・サーバは同じロールアップである必要はない。
バージョンの差が 1 以下」という記述と一貫している。
ローリング・アップグレードで述べた
混在期間の互換性を、この方向でのみ保証している、ということである。

クライアント再構成の回避

以下の方法でクライアント再構成を回避できる。
(クライアントの URL を変更しなくて済むようにする。)

  • CRM Server で 2011 → 2013 と同じサーバ名を使用する。

  • 異なるサーバ名とするが、CRM 2011 Server の DNS の名前解決で
    CRM 2013 Server の IP アドレスを指すように変更する。

  • DNS とホストヘッダーを使用して、
    CRM 2011 Server の既存の URL を別名として CRM 2013 Server で処理できるようにする。

補足(移行の常套手段): 「接続先の名前を変えずに実体を差し替える」という
この 3 つの手は、CRM に限らずサーバ移行全般で使える
サーバ更改(バージョン・アップ移行)
移行後に各クライアントの設定を配り直す手間を避けたい場合、
まずこの方向を検討するとよい。

基本言語

の基本言語が一致していること。

オフライン データ アクセス

  • オフライン データ アクセスが必要な場合は、
    Outlook 用 Microsoft Dynamics CRM 2013 へのアップグレードが必要。

  • また、オフライン モードでは、
    Outlook 用 Microsoft Dynamics CRM 2013 へのアップグレードができないので、
    アップグレード前に
    Outlook 用 Microsoft Dynamics CRM 2011 をオンラインにする。

異なるCPUアーキテクチャ間でのアップグレード

サポートされていない。
また、同じ CPU アーキテクチャの Office が必要になる。

参考


Tags: Dynamics CRM

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally