次の方法で共有


System Center Service Manager のアップグレード

この記事では、System Center 2022 - Service Manager (SM) のアップグレード情報を提供します

System Center 2022 - Service Manager へのアップグレード

次のセクションでは、System Center 2022 - Service Manager (SM) にアップグレードする方法について説明します。

警告

コンポーネントのアップグレード順が重要です。 正しいアップグレード順に従わないと、回復手段がないコンポーネント エラーが発生する可能性があります。 次の System Center コンポーネントが影響を受けます。

  1. Orchestrator
  2. Service Manager
  3. Data Protection Manager
  4. Operations Manager
  5. 構成マネージャー
  6. Virtual Machine Manager
  7. App Controller

System Center 2019 から System Center 2022 にのみアップグレードできます。

重要

このガイドでは、既存の System Center バージョンに対して アップグレード を実行していることを前提としています。 以前のバージョンの Service Manager が存在しないコンピューターに System Center 2022 - Service Manager をインストールする方法については、「System Center - Service Manager の展開 参照してください

System Center 2022 - Service Manager へのアップグレードを計画する

このセクションでは、System Center 2022 にアップグレードするために必要な手順について説明します。

Service Manager 2019 からのインプレース アップグレードがサポートされています。 インプレース アップグレードは、同じハードウェア上のすべての Service Manager パーツのアップグレードです。 サイド バイ サイド アップグレードやローリング アップグレードなど、その他の方法はサポートされていません。

Service Manager 2022 にアップグレードするには、準備が必要です。 ラボ環境に Service Manager をインストールしてから、運用データベースをラボにレプリケートすることをお勧めします。 その後、ラボで新しいインストールのアップグレードを実行します。

評価版と選択バージョン

System Center 2019 - Service Manager のリリースは、次の 2 つの異なるバージョンで利用できるようになりました。

  • 評価版 (180 日間限定)
  • セレクト ライセンス版

Service Manager 2022 では、次のアップグレード パスがサポートされています。

現在のバージョン アップグレード バージョン 状態
System Center 2019 - Service Manager Eval System Center 2022 - Service Manager Eval 評価期間は同じです
System Center 2019 - Service Manager の選択 System Center 2022 - Service Manager の選択 Licensed

Note

Service Manager の評価版から Service Manager 2022 の評価版にアップグレード評価期間が 180 日間延長されます。

インストール場所

Service Manager をインストールするための既定のフォルダーは \Program Files\Microsoft System Center\Service Manager です。 ただし、Service Manager へのアップグレードを実行すると、ソフトウェアは Service Manager が以前に使用したフォルダーにインストールされます。 Service Manager 2016/1801 が以前にアップグレードされている場合は、次のフォルダーを使用できます。

\Program Files\Microsoft System Center\Service Manager

System Center 2022 - Service Manager のハードウェア要件

System Center 2022 - Service Manager のすべてのハードウェア要件については、 Hardware の要件に関する記事を参照してください。

System Center 2022 - Service Manager のソフトウェア要件

System Center 2022- Service Manager のすべてのソフトウェア要件については、 Software の要件に関する記事を参照してください。

MPSync ジョブの手すりの防止

アップグレード前

説明 : アップグレード プロセスに問題があり、アップグレードの完了後に MPSync ジョブが失敗します。 アップグレード前 この問題を回避するには DWRepository データベースで以下に示す SQL スクリプトを実行して、DWRepository データベース内の実際のテーブルの主キーに制約を削除して追加する実際の SQL スクリプトを取得して問題を修正する必要があります。 また、変換ジョブや読み込みジョブでもエラーが発生する場合があります。 このエラーは、データベースのクリーンアップに問題がある場合に発生することがあります。

;WITH FactName  
AS (  
       select w.WarehouseEntityName from etl.WarehouseEntity w  
       join etl.WarehouseEntityType t on w.WarehouseEntityTypeId = t.WarehouseEntityTypeId  
       where t.WarehouseEntityTypeName = 'Fact'  
),FactList  
AS (  
    SELECT  PartitionName, p.WarehouseEntityName,  
            RANK() OVER ( PARTITION BY p.WarehouseEntityName ORDER BY PartitionName ASC ) AS RK  
    FROM    etl.TablePartition p  
       join FactName f on p.WarehouseEntityName = f.WarehouseEntityName  
)  
, FactPKList  
AS (  
    SELECT  f.WarehouseEntityName, a.TABLE_NAME, a.COLUMN_NAME, b.CONSTRAINT_NAME, f.RK,  
            CASE WHEN b.CONSTRAINT_NAME = 'PK_' + f.WarehouseEntityName THEN 1 ELSE 0 END AS DefaultConstraints  
    FROM    FactList f  
    JOIN    INFORMATION_SCHEMA.KEY_COLUMN_USAGE a ON f.PartitionName = a.TABLE_NAME  
    JOIN    INFORMATION_SCHEMA.TABLE_CONSTRAINTS b ON a.CONSTRAINT_NAME = b.CONSTRAINT_NAME AND b.CONSTRAINT_TYPE = 'Primary key'  
)  
, FactWithoutDefaultConstraints  
AS (  
    SELECT  a.*  
    FROM    FactPKList a  
    LEFT JOIN FactPKList b ON b.WarehouseEntityName = a.WarehouseEntityName AND b.DefaultConstraints = 1  
    WHERE   b.WarehouseEntityName IS NULL AND a.RK = 1  
)  
, FactPKListStr  
AS (  
    SELECT  DISTINCT f1.WarehouseEntityName, f1.TABLE_NAME, f1.CONSTRAINT_NAME, F.COLUMN_NAME AS PKList  
    FROM    FactWithoutDefaultConstraints f1  
    CROSS APPLY (  
                    SELECT  '[' + COLUMN_NAME + '],'  
                    FROM    FactWithoutDefaultConstraints f2  
                    WHERE   f2.TABLE_NAME = f1.TABLE_NAME  
                    ORDER BY COLUMN_NAME  
                FOR  
                   XML PATH('')  
                ) AS F (COLUMN_NAME)  
)  
SELECT  'ALTER TABLE [dbo].[' + f.TABLE_NAME + '] DROP CONSTRAINT [' + f.CONSTRAINT_NAME + ']' + CHAR(13) + CHAR(10) +  
        'ALTER TABLE [dbo].[' + f.TABLE_NAME + '] ADD CONSTRAINT [PK_' + f.WarehouseEntityName + '] PRIMARY KEY NONCLUSTERED (' + SUBSTRING(f.PKList, 1, LEN(f.PKList) -1) + ')' + CHAR(13) + CHAR(10)  
FROM    FactPKListStr f  

回避策 1: アップグレード済みで、変換または読み込みジョブの失敗に問題がなく、管理パックの展開エラーがある場合は、「 アップグレード 」セクションの手順に従ってください。 さらに、既定の主キーが復元されたら、Data Warehouse ワークスペースに移動して Service Manager コンソールで失敗した管理パックの展開を再起動し、[管理パック] を選択します。

回避策 2: 変換または読み込みジョブの失敗に問題がある場合は、次のクエリを実行して、SystemDerivedMp.Microsoft.SystemCenter.Datawarehouse.Base 管理パックが DWStagingAndConfig データベースに存在するかどうかを確認します。

select * from ManagementPack where mpname like '%SystemDerivedMp.Microsoft.SystemCenter.Datawarehouse.Base%'  

管理パックが存在しない場合は、アップグレード前にデータベースを状態に復元する必要があります。 データベースを復元するには、次の手順を実行します。

  1. データベースのバックアップに関するディザスター リカバリー手順を実行します。

  2. MPSyncJob スケジュールを無効にします。

  3. DWRepository に見つからないすべてのプライマリ キーを手動で復元します。 「アップグレード前」セクションの SQL スクリプトを使用して、プライマリ キーをドロップし、作り直すことができます。

  4. Service Manager コンソールを使用して、失敗した基本管理パックの展開を再起動します。

ラボ環境でのアップグレードのテスト

ラボ環境で System Center 2022 - Service Manager へのアップグレードをテストすることをお勧めします。

アップグレードの順序とタイミング

アップグレードの実行順序は重要です。 次の順序でアップグレード手順を実行します。

  1. データベースと管理パックをバックアップします。 System Center - Service Manager の Disaster 回復ガイドの「Service Manager データベースのバックアップ封印されていない管理パックのバックアップ」のセクションを参照。

  2. データ ウェアハウス管理サーバーから開始します。

  3. データ ウェアハウス管理サーバーへのアップグレードが完了したら、初期 (プライマリ) Service Manager 管理サーバーをアップグレードします。 複数の Service Manager 管理サーバーを作成した場合は、最初に作成した Service Manager 管理サーバーが最初に作成されます。

  4. 次に、すべてのセカンダリ管理サーバー、セルフサービス ポータル、Service Manager コンソールをアップグレードします。

インストール後、次の操作を行います。

  1. すべての Data Warehouse ジョブを無効にします。 これを行うには、Service Manager シェルを開き、次のコマンドを実行します。

    $DW ='DWMS Servername' 
    Get-scdwjob -Computername $DW | %{disable-scdwjobschedule -Computername $DW -jobname $_.Name} 
    
  2. 環境内のデータ ソース ビューに基づいて、次の PowerShell スクリプトで必要な変更を行い、管理者特権を使用してスクリプトを実行します。

    $SSAS_ServerName = "ssas servername" # - to be replaced with Analysis Service instance Name 
    
    [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices") 
    $Server = New-Object Microsoft.AnalysisServices.Server 
    $Server.Connect($SSAS_ServerName) 
    $Databases = $Server.Databases 
    $DWASDB = $Databases["DWASDataBase"] 
    
    #update DWDatamart dsv. Comment the below 3 commands if DWdatamart dsv is not present  
    
    $DWASDB.DataSourceViews["DwDataMart"].Schema.Tables["OperatingsystemDim"].Columns["PhysicalMemory"].DataType  =  [decimal]  
    
    $DWASDB.DataSourceViews["DwDataMart"].Schema.Tables["LogicalDiskDim"].Columns["Size"].DataType  =  [decimal]  
    
    $DWASDB.DataSourceViews["DwDataMart"].Update([Microsoft.AnalysisServices.UpdateOptions]::ExpandFull)  
    
    #update CMDatamart dsv.Comment the below 2 commands if cmdatamart dsv is not present  
    
    $DWASDB.DataSourceViews["CMDataMart"].Schema.Tables["OperatingsystemDim"].Columns["PhysicalMemory"].DataType  =  [decimal]  
    
    $DWASDB.DataSourceViews["CMDataMart"].Update([Microsoft.AnalysisServices.UpdateOptions]::ExpandFull)  
    
    #update OperatingsystemDim 
    
    $DWASDB.Dimensions["OperatingsystemDim"].Attributes["PhysicalMemory"].KeyColumns[0].DataType =  [System.Data.OleDb.OleDbType]::Double  
    
    $DWASDB.Dimensions["OperatingsystemDim"].Update([Microsoft.AnalysisServices.UpdateOptions]::ExpandFull + [Microsoft.AnalysisServices.UpdateOptions]::AlterDependents) 
    
    #update LogicalDiskDim  
    
    $DWASDB.Dimensions["LogicalDiskDim"].Attributes["Size"].KeyColumns[0].DataType =  [System.Data.OleDb.OleDbType]::Double  
    
    $DWASDB.Dimensions["LogicalDiskDim"].Update([Microsoft.AnalysisServices.UpdateOptions]::ExpandFull + [Microsoft.AnalysisServices.UpdateOptions]::AlterDependents)  
    
    
  3. 次のコマンドを実行して、ジョブ スケジュールを有効にします。

    $DW ='DWMS Servername' 
    
    Get-scdwjob -Computername $DW | %{enable-scdwjobschedule -Computername $DW -jobname $_.Name} 
    
  4. Data Warehouse 管理サーバーを再起動します。

  5. System Center 2022 Service Manager の Update Rollup 2 を Data Warehouse 管理サーバー、プライマリ管理サーバー、セカンダリ管理サーバー、セルフサービス ポータル、およびすべてのアナリスト コンソールに適用します。

データベースへの影響

System Center 2022 - Service Manager では、Operations Manager と Configuration Manager データ マートをインストールするオプションがあります。 このオプションを選択すると、2 つのデータベースと関連するファイル グループとログ ファイルを格納するために、ハード ディスク ドライブ上でより多くの領域が必要となります。

アップグレードする前に Service Manager をバックアップする

アップグレードを開始する前に、Service Manager データベースとデータ ウェアハウス データベースと暗号化キーをバックアップすることをお勧めします。 データベースと暗号化キーを既にバックアップしている場合は、引き続きアップグレードを実行できます。 それ以外の場合は、アップグレードを続行する前に、 Disaster Recovery Guide for System Center - Service Manager のバックアップ手順を確認してください。

Service Manager データ ウェアハウスを登録する

アップグレード プロセスの一環として、環境内にデータ ウェアハウス管理サーバーをインストールした場合は、データ ウェアハウス ジョブの状態を表示できる必要があります。 Service Manager データ ウェアハウスに登録していない場合は、このタスクを実行できません。 Data Warehouse ボタンが Service Manager コンソールに表示されない場合は、「System Center - Service Manager の展開ガイド」の「 Service Manager Data Warehouse を使用してレポートを有効にする」の手順を完了

暗号化キー

System Center 2022 - Service Manager をインストールまたはアップグレードするためのセットアップの実行が完了すると、暗号化バックアップまたは復元ウィザードを開くよう求められます。 以前に暗号化キーをバックアップしたことがある場合は、追加のアクションは必要ありません。 暗号化キーをバックアップしない場合は、暗号化キーのバックアップまたは復元ウィザードを使用して、Service Manager 管理サーバー上の暗号化キーをバックアップします。

この記事では、System Center 2019 - Service Manager (SM) のアップグレード情報を提供します

System Center 2019 - Service Manager へのアップグレード

次のセクションでは、System Center 2019 - Service Manager (SM) にアップグレードする方法について説明します。

警告

コンポーネントのアップグレード順が重要です。 正しいアップグレード順に従わないと、回復手段がないコンポーネント エラーが発生する可能性があります。 次の System Center コンポーネントが影響を受けます。

  1. Orchestrator
  2. Service Manager
  3. Data Protection Manager
  4. Operations Manager
  5. 構成マネージャー
  6. Virtual Machine Manager
  7. App Controller

System Center 2016 または 1801 または 1807 からのみ System Center 2019 にアップグレードできます。

重要

このガイドでは、既存の System Center バージョンに対して アップグレード を実行していることを前提としています。 以前のバージョンの Service Manager が存在しないコンピューターに System Center 2019 - Service Manager をインストールする方法については、「System Center - Service Manager の展開を参照してください。

System Center 2019 - Service Manager へのアップグレードを計画する

このセクションでは、System Center 2019 にアップグレードするために必要な手順について説明します。

Service Manager 2016、1801、1807 からのインプレース アップグレードがサポートされています。 インプレース アップグレードは、同じハードウェア上のすべての Service Manager パーツのアップグレードです。 サイド バイ サイド アップグレードやローリング アップグレードなど、その他の方法はサポートされていません。

Service Manager 2019 にアップグレードするには、準備が必要です。 ラボ環境に Service Manager をインストールしてから、運用データベースをラボにレプリケートすることをお勧めします。 その後、ラボで新しいインストールのアップグレードを実行します。

評価版と選択バージョン

System Center 2016 および 1801 - Service Manager のリリースは、次の 2 つの異なるバージョンで利用できるようになりました。

  • 評価版 (180 日間限定)
  • セレクト ライセンス版

Service Manager 2019 では、次のアップグレード パスがサポートされています。

現在のバージョン アップグレード バージョン 状態
System Center 2016/1801 - Service Manager Eval System Center 2019 - Service Manager Eval 評価期間は同じです
System Center 2016/1801/1807 - Service Manager Select System Center 2019 - Service Manager の選択 Licensed

Note

Service Manager の評価版から Service Manager 2019 の評価版にアップグレード評価期間が 180 日間延長されません。

インストール場所

Service Manager をインストールするための既定のフォルダーは \Program Files\Microsoft System Center\Service Manager です。 ただし、Service Manager へのアップグレードを実行すると、ソフトウェアは Service Manager が以前に使用したフォルダーにインストールされます。 Service Manager 2016/1801 が以前にアップグレードされている場合は、次のフォルダーを使用できます。

\Program Files\Microsoft System Center\Service Manager

System Center 2019 - Service Manager のハードウェア要件

System Center 2019 - Service Manager のすべてのハードウェア要件については、 Hardware の要件に関する記事を参照してください。

System Center 2019 - Service Manager のソフトウェア要件

System Center 2019- Service Manager のすべてのソフトウェア要件については、 Software の要件に関する記事を参照してください。

カスタム開発への影響

System Center 2016 - Service Manager リリースでは、製品は .NET 4.5.1 をサポートするように移行しました。 この .NET 4.5.1 への移動をサポートするツール セットは、いくつかの依存関係を中断するために必要であり、アセンブリ間でのクラスの移動につながりました。

MPSync ジョブの手すりの防止

アップグレード前

説明 : アップグレード プロセスに問題があり、アップグレードの完了後に MPSync ジョブが失敗します。 アップグレード前にこの問題が発生しないようにするには、DWRepository データベースで以下の SQL スクリプトを実行して、ドロップした実際の SQL スクリプトを取得し、プライマリ キーに関する制約を DWRepository データベースのファクト テーブルに追加して、問題を修正します。 また、変換ジョブや読み込みジョブでもエラーが発生する場合があります。 このエラーは、データベースのクリーンアップに問題がある場合に発生することがあります。

;WITH FactName  
AS (  
       select w.WarehouseEntityName from etl.WarehouseEntity w  
       join etl.WarehouseEntityType t on w.WarehouseEntityTypeId = t.WarehouseEntityTypeId  
       where t.WarehouseEntityTypeName = 'Fact'  
),FactList  
AS (  
    SELECT  PartitionName, p.WarehouseEntityName,  
            RANK() OVER ( PARTITION BY p.WarehouseEntityName ORDER BY PartitionName ASC ) AS RK  
    FROM    etl.TablePartition p  
       join FactName f on p.WarehouseEntityName = f.WarehouseEntityName  
)  
, FactPKList  
AS (  
    SELECT  f.WarehouseEntityName, a.TABLE_NAME, a.COLUMN_NAME, b.CONSTRAINT_NAME, f.RK,  
            CASE WHEN b.CONSTRAINT_NAME = 'PK_' + f.WarehouseEntityName THEN 1 ELSE 0 END AS DefaultConstraints  
    FROM    FactList f  
    JOIN    INFORMATION_SCHEMA.KEY_COLUMN_USAGE a ON f.PartitionName = a.TABLE_NAME  
    JOIN    INFORMATION_SCHEMA.TABLE_CONSTRAINTS b ON a.CONSTRAINT_NAME = b.CONSTRAINT_NAME AND b.CONSTRAINT_TYPE = 'Primary key'  
)  
, FactWithoutDefaultConstraints  
AS (  
    SELECT  a.*  
    FROM    FactPKList a  
    LEFT JOIN FactPKList b ON b.WarehouseEntityName = a.WarehouseEntityName AND b.DefaultConstraints = 1  
    WHERE   b.WarehouseEntityName IS NULL AND a.RK = 1  
)  
, FactPKListStr  
AS (  
    SELECT  DISTINCT f1.WarehouseEntityName, f1.TABLE_NAME, f1.CONSTRAINT_NAME, F.COLUMN_NAME AS PKList  
    FROM    FactWithoutDefaultConstraints f1  
    CROSS APPLY (  
                    SELECT  '[' + COLUMN_NAME + '],'  
                    FROM    FactWithoutDefaultConstraints f2  
                    WHERE   f2.TABLE_NAME = f1.TABLE_NAME  
                    ORDER BY COLUMN_NAME  
                FOR  
                   XML PATH('')  
                ) AS F (COLUMN_NAME)  
)  
SELECT  'ALTER TABLE [dbo].[' + f.TABLE_NAME + '] DROP CONSTRAINT [' + f.CONSTRAINT_NAME + ']' + CHAR(13) + CHAR(10) +  
        'ALTER TABLE [dbo].[' + f.TABLE_NAME + '] ADD CONSTRAINT [PK_' + f.WarehouseEntityName + '] PRIMARY KEY NONCLUSTERED (' + SUBSTRING(f.PKList, 1, LEN(f.PKList) -1) + ')' + CHAR(13) + CHAR(10)  
FROM    FactPKListStr f  

回避策 1: アップグレード済みで、変換または読み込みジョブの失敗に問題がなく、管理パックの展開エラーがある場合は、「アップグレード前」セクションの手順に従ってください。 さらに、既定の主キーが復元されたら、Data Warehouse ワークスペースに移動して Service Manager コンソールで失敗した管理パックの展開を再起動し、[管理パック] を選択します。

回避策 2: 変換または読み込みジョブの失敗に問題がある場合は、次のクエリを実行して、SystemDerivedMp.Microsoft.SystemCenter.Datawarehouse.Base 管理パックが DWStagingAndConfig データベースに存在するかどうかを確認します。

select * from ManagementPack where mpname like '%SystemDerivedMp.Microsoft.SystemCenter.Datawarehouse.Base%'  

管理パックが存在しない場合は、アップグレード前にデータベースを状態に復元する必要があります。 データベースを復元するには、次の手順を実行します。

  1. データベースのバックアップに関するディザスター リカバリー手順を実行します。

  2. MPSyncJob スケジュールを無効にします。

  3. DWRepository に見つからないすべてのプライマリ キーを手動で復元します。 「アップグレード前」セクションの SQL スクリプトを使用して、プライマリ キーをドロップし、作り直すことができます。

  4. Service Manager コンソールを使用して、失敗した基本管理パックの展開を再起動します。

ラボ環境でのアップグレードのテスト

ラボ環境で System Center 2019 - Service Manager へのアップグレードをテストすることをお勧めします。

アップグレードの順序とタイミング

アップグレードの実行順序は重要です。 次の順序でアップグレード手順を実行します。

  1. データベースと管理パックをバックアップします。 System Center - Service Manager の Disaster 回復ガイドの「Service Manager データベースのバックアップ封印されていない管理パックのバックアップ」のセクションを参照。

  2. データ ウェアハウス管理サーバーから開始します。 データ ウェアハウス ジョブを停止します。アップグレードが完了するまで、もう一度開始することはできません。

  3. データ ウェアハウス管理サーバーへのアップグレードが完了したら、最初の Service Manager 管理サーバーをアップグレードします。 複数の Service Manager 管理サーバーを作成した場合は、最初に作成した Service Manager 管理サーバーが最初に作成されます。

  4. Service Manager コンソールとその他の Service Manager 管理サーバーをアップグレードします。

  5. データ ウェアハウス ジョブを再開します。

  6. 新しいセルフサービス ポータルをデプロイします。

アップグレードのタイミングも重要です。 データ ウェアハウス管理サーバーをアップグレードした後、Service Manager 管理サーバーを更新し、新しいセルフサービス ポータルも展開する必要があります。 最初の Service Manager 管理サーバーをアップグレードした後、Service Manager コンソールまたは Service Manager コンソール、追加の Service Manager 管理サーバー、およびセルフサービス ポータルを同時にアップグレードする準備が整っている必要があります。

データベースへの影響

System Center 2019 - Service Manager では、Operations Manager と Configuration Manager のデータ マートをインストールするオプションがあります。 このオプションを選択すると、2 つのデータベースと関連するファイル グループとログ ファイルを格納するために、ハード ディスク ドライブ上でより多くの領域が必要となります。

アップグレードする前に Service Manager をバックアップする

アップグレードを開始する前に、Service Manager データベースとデータ ウェアハウス データベースと暗号化キーをバックアップすることをお勧めします。 データベースと暗号化キーを既にバックアップしている場合は、引き続きアップグレードを実行できます。 それ以外の場合は、アップグレードを続行する前に、 Disaster Recovery Guide for System Center - Service Manager のバックアップ手順を確認してください。

Service Manager データ ウェアハウスを登録する

アップグレード プロセスの一環として、環境内にデータ ウェアハウス管理サーバーをインストールした場合は、データ ウェアハウス ジョブの状態を表示できる必要があります。 Service Manager データ ウェアハウスに登録していない場合は、このタスクを実行できません。 Data Warehouse ボタンが Service Manager コンソールに表示されない場合は、「System Center - Service Manager の展開ガイド」の「 Service Manager Data Warehouse を使用してレポートを有効にする」の手順を完了

暗号化キー

System Center 2019 - Service Manager をインストールまたはアップグレードするためのセットアップの実行が完了すると、暗号化バックアップまたは復元ウィザードを開くよう求められます。 以前に暗号化キーをバックアップしたことがある場合は、追加のアクションは必要ありません。 暗号化キーをバックアップしない場合は、暗号化キーのバックアップまたは復元ウィザードを使用して、Service Manager 管理サーバー上の暗号化キーをバックアップします。

この記事では、System Center 2016 - Service Manager (SM) のアップグレード情報を提供します

System Center 2016 - Service Manager へのアップグレード

次のセクションでは、System Center 2012 R2 - Service Manager から System Center 2016 - Service Manager (SM) にアップグレードする方法について説明します。

警告

2 つ以上の System Center コンポーネントをアップグレードする予定の場合は、最初にガイド System Center 2016 へのアップグレードを参照してください。 コンポーネントのアップグレード順が重要です。 正しいアップグレード順に従わないと、回復手段がないコンポーネント エラーが発生する可能性があります。 次の System Center コンポーネントが影響を受けます。

  1. Orchestrator
  2. Service Manager
  3. Data Protection Manager
  4. Operations Manager
  5. 構成マネージャー
  6. Virtual Machine Manager
  7. App Controller

System Center 2012 R2 - Service Manager から System Center 2016 にアップグレードできるのは、更新プログラムロールアップ 9 以降がインストールされている場合のみです。

重要

このガイドでは、System Center 2012 R2 への アップグレード を実行していることを前提としています。 以前のバージョンの Service Manager が存在しないコンピューターに System Center 2016 - Service Manager をインストールする方法については、「 System Center 2016 - Service Manager の展開を参照してください。

System Center 2016 - Service Manager へのアップグレードを計画する

このセクションでは、System Center 2016 にアップグレードするために必要な手順について説明します。

Service Manager 2012 R2 から Service Manager 2016 へのインプレース アップグレードがサポートされています。 インプレース アップグレードは、同じハードウェア上のすべての Service Manager パーツのアップグレードです。 サイド バイ サイド アップグレードやローリング アップグレードなど、その他の方法はサポートされていません。

Service Manager 2016 にアップグレードするには、準備が必要です。 ラボ環境に Service Manager をインストールしてから、運用データベースをラボにレプリケートすることをお勧めします。 その後、ラボで新しいインストールのアップグレードを実行し、正常に完了したら、運用環境で Service Manager SP1 に同じアップグレードを実行します。

評価版と選択バージョン

System Center 2012 R2 - Service Manager のリリースは、次の 2 つの異なるバージョンで利用できるようになりました。

  • 評価版 (180 日間限定)

  • セレクト ライセンス版

Service Manager 2016 では、次のアップグレード パスがサポートされています。

現在のバージョン アップグレード バージョン 状態
System Center 2012 R2 - Service Manager Eval System Center 2016 - Service Manager Eval 評価期間は同じです
System Center 2012 R2 - Service Manager の選択 System Center 2016 - Service Manager の選択 Licensed

Note

Service Manager 2012 R2 の評価版から Service Manager 2016 の評価版にアップグレード 180 日間の評価期間は延長されません。

インストール場所

Service Manager をインストールするための既定のフォルダーは \Program Files\Microsoft System Center\Service Manager です。 ただし、Service Manager へのアップグレードを実行すると、ソフトウェアは Service Manager が以前に使用したフォルダーにインストールされます。 Service Manager 2010 または Service Manager 2012 が以前にアップグレードされている場合は、次のフォルダーを使用できます。

\Program Files\Microsoft System Center\Service Manager 2010
\Program Files\Microsoft System Center\Service Manager 2012

System Center 2016 - Service Manager のハードウェア要件

System Center 2016 - Service Manager のすべてのハードウェア要件については、「System Center 2016 - Service Manager のHardware 要件 完全に記載されています

System Center 2016 - Service Manager のソフトウェア要件

System Center 2016 にアップグレードするには、最初に System Center 2012 R2 - Service Manager の更新プログラムロールアップ 9 以降を適用する必要があります。

System Center 2016 - Service Manager のすべてのソフトウェア要件については、「system Center 2016 - Service Manager の ソフトウェア要件」に完全に記載されています

カスタム開発への影響

System Center 2016 - Service Manager リリースでは、製品は .NET 4.5.1 をサポートするように移行しました。 この .NET 4.5.1 への移動をサポートするツール セットは、いくつかの依存関係を中断するために必要であり、アセンブリ間でのクラスの移動につながりました。 そのため、Service Manager 2016 へのアップグレードにより、社内またはサード パーティ (Microsoft 以外) によって行われたカスタム ソリューションが中断される可能性があります。 この問題が発生しないように、カスタム ソリューションをアップグレードする 手順を参照してください。

MPSync ジョブの失敗の防止

アップグレード前

説明 : アップグレード プロセスに問題があり、アップグレードの完了後に MPSync ジョブが失敗します。 アップグレード前にこの問題が発生しないようにするには、DWRepository データベースで以下の SQL スクリプトを実行して、ドロップした実際の SQL スクリプトを取得し、プライマリ キーに関する制約を DWRepository データベースのファクト テーブルに追加して、問題を修正します。 また、変換ジョブや読み込みジョブでもエラーが発生する場合があります。 このエラーは、データベースのクリーンアップに問題がある場合に発生することがあります。

;WITH FactName  
AS (  
       select w.WarehouseEntityName from etl.WarehouseEntity w  
       join etl.WarehouseEntityType t on w.WarehouseEntityTypeId = t.WarehouseEntityTypeId  
       where t.WarehouseEntityTypeName = 'Fact'  
),FactList  
AS (  
    SELECT  PartitionName, p.WarehouseEntityName,  
            RANK() OVER ( PARTITION BY p.WarehouseEntityName ORDER BY PartitionName ASC ) AS RK  
    FROM    etl.TablePartition p  
       join FactName f on p.WarehouseEntityName = f.WarehouseEntityName  
)  
, FactPKList  
AS (  
    SELECT  f.WarehouseEntityName, a.TABLE_NAME, a.COLUMN_NAME, b.CONSTRAINT_NAME, f.RK,  
            CASE WHEN b.CONSTRAINT_NAME = 'PK_' + f.WarehouseEntityName THEN 1 ELSE 0 END AS DefaultConstraints  
    FROM    FactList f  
    JOIN    INFORMATION_SCHEMA.KEY_COLUMN_USAGE a ON f.PartitionName = a.TABLE_NAME  
    JOIN    INFORMATION_SCHEMA.TABLE_CONSTRAINTS b ON a.CONSTRAINT_NAME = b.CONSTRAINT_NAME AND b.CONSTRAINT_TYPE = 'Primary key'  
)  
, FactWithoutDefaultConstraints  
AS (  
    SELECT  a.*  
    FROM    FactPKList a  
    LEFT JOIN FactPKList b ON b.WarehouseEntityName = a.WarehouseEntityName AND b.DefaultConstraints = 1  
    WHERE   b.WarehouseEntityName IS NULL AND a.RK = 1  
)  
, FactPKListStr  
AS (  
    SELECT  DISTINCT f1.WarehouseEntityName, f1.TABLE_NAME, f1.CONSTRAINT_NAME, F.COLUMN_NAME AS PKList  
    FROM    FactWithoutDefaultConstraints f1  
    CROSS APPLY (  
                    SELECT  '[' + COLUMN_NAME + '],'  
                    FROM    FactWithoutDefaultConstraints f2  
                    WHERE   f2.TABLE_NAME = f1.TABLE_NAME  
                    ORDER BY COLUMN_NAME  
                FOR  
                   XML PATH('')  
                ) AS F (COLUMN_NAME)  
)  
SELECT  'ALTER TABLE [dbo].[' + f.TABLE_NAME + '] DROP CONSTRAINT [' + f.CONSTRAINT_NAME + ']' + CHAR(13) + CHAR(10) +  
        'ALTER TABLE [dbo].[' + f.TABLE_NAME + '] ADD CONSTRAINT [PK_' + f.WarehouseEntityName + '] PRIMARY KEY NONCLUSTERED (' + SUBSTRING(f.PKList, 1, LEN(f.PKList) -1) + ')' + CHAR(13) + CHAR(10)  
FROM    FactPKListStr f  

回避策 1: アップグレード済みで、変換または読み込みジョブの失敗に問題がなく、管理パックの展開エラーがある場合は、「アップグレード前」セクションの手順に従ってください。 さらに、既定の主キーが復元されたら、Data Warehouse ワークスペースに移動して Service Manager コンソールで失敗した管理パックの展開を再起動し、[管理パック] を選択します。

回避策 2: 変換または読み込みジョブの失敗に問題がある場合は、次のクエリを実行して、SystemDerivedMp.Microsoft.SystemCenter.Datawarehouse.Base 管理パックが DWStagingAndConfig データベースに存在するかどうかを確認します。

select * from ManagementPack where mpname like '%SystemDerivedMp.Microsoft.SystemCenter.Datawarehouse.Base%'  

管理パックが存在しない場合は、アップグレード前にデータベースを状態に復元する必要があります。 データベースを復元するには、次の手順を実行します。

  1. データベースのバックアップに関するディザスター リカバリー手順を実行します。

  2. MPSyncJob スケジュールを無効にします。

  3. DWRepository に見つからないすべてのプライマリ キーを手動で復元します。 「アップグレード前」セクションの SQL スクリプトを使用して、プライマリ キーをドロップし、作り直すことができます。

  4. Service Manager コンソールを使用して、失敗した基本管理パックの展開を再起動します。

ラボ環境でのアップグレードのテスト

ラボ環境で System Center 2016 - Service Manager へのアップグレードをテストすることをお勧めします。

アップグレードの順序とタイミング

アップグレードの実行順序は重要です。 次の順序でアップグレード手順を実行します。

  1. データベースと管理パックをバックアップします。 System Center 2016 - Service Manager Disaster 回復ガイドの「Service Manager データベースのバックアップと封印されていない管理パックのバックアップ」のセクションを参照してください。

  2. データ ウェアハウス管理サーバーから開始します。 データ ウェアハウス ジョブを停止します。アップグレードが完了するまで、もう一度開始することはできません。

  3. データ ウェアハウス管理サーバーへのアップグレードが完了したら、最初の Service Manager 管理サーバーをアップグレードします。 複数の Service Manager 管理サーバーを作成した場合は、最初に作成した Service Manager 管理サーバーが最初に作成されます。

  4. Service Manager コンソールとその他の Service Manager 管理サーバーをアップグレードします。

  5. データ ウェアハウス ジョブを再開します。

  6. 新しいセルフサービス ポータルをデプロイします。

アップグレードのタイミングも重要です。 データ ウェアハウス管理サーバーをアップグレードした後、Service Manager 管理サーバーを更新し、新しいセルフサービス ポータルをデプロイする必要があります。 最初の Service Manager 管理サーバーをアップグレードした後、Service Manager コンソールまたは Service Manager コンソール、追加の Service Manager 管理サーバー、およびセルフサービス ポータルを同時にアップグレードする準備が整っている必要があります。

データベースへの影響

System Center 2016 - Service Manager では、Operations Manager と Configuration Manager データ マートをインストールするオプションがあります。 このオプションを選択すると、2 つのデータベースと関連するファイル グループとログ ファイルを格納するために、ハード ディスク ドライブ上でより多くの領域が必要となります。

アップグレードする前に Service Manager をバックアップする

アップグレードを開始する前に、Service Manager データベースとデータ ウェアハウス データベースと暗号化キーをバックアップすることをお勧めします。 データベースと暗号化キーを既にバックアップしている場合は、引き続きアップグレードを実行できます。 それ以外の場合は、アップグレードを続行する前に、 Disaster Recovery Guide for System Center - Service Manager のバックアップ手順を確認してください。

Service Manager データ ウェアハウスを登録する

アップグレード プロセスの一環として、環境内にデータ ウェアハウス管理サーバーをインストールした場合は、データ ウェアハウス ジョブの状態を表示できる必要があります。 Service Manager データ ウェアハウスに登録していない場合は、このタスクを実行できません。 Data Warehouse ボタンが Service Manager コンソールに表示されない場合は、「System Center 2016 - Service Manager 展開ガイド」の「 Service Manager Data Warehouse を使用してレポートを有効にする」の手順を完了します。

暗号化キー

System Center 2016 - Service Manager をインストールまたはアップグレードするためのセットアップの実行が完了すると、暗号化バックアップまたは復元ウィザードを開くよう求められます。 以前に暗号化キーをバックアップしたことがある場合は、追加のアクションは必要ありません。 暗号化キーをバックアップしない場合は、暗号化キーのバックアップまたは復元ウィザードを使用して、Service Manager 管理サーバー上の暗号化キーをバックアップします。

次のステップ