Mise à niveau de la planification de System Center 2012 - Service Manager

Date de publication : juillet 2016

S’applique à : System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager

Ce guide décrit les procédures nécessaires pour effectuer une mise à niveau vers System Center 2012 Service Pack 1 (SP1).

Une mise à niveau sur place de Service Manager RC à Service Manager SP1 est prise en charge. Une mise à niveau sur place est une mise à niveau de tous les composants de Service Manager sur le même matériel. D'autres approches, telles que des mises à niveau côte à côte ou des mises à niveau propagées, ne sont pas prises en charge.

La mise à niveau vers Service Manager SP1 nécessite une préparation. Nous vous conseillons d'installer Service Manager dans un environnement de laboratoire et de dupliquer votre base de données de production dans le laboratoire. Vous effectuerez ensuite une mise à niveau de la nouvelle installation dans le labo et lorsqu'elle aura réussi, vous effectuerez la même mise à niveau vers Service Manager SP1 dans l'environnement de production.

La version de System Center 2012 - Service Manager était disponible dans deux versions différentes :

• Version d'évaluation (valide 180 jours)

• Version de licence Select

Service Manager SP1 est disponible en version d'évaluation (valide 180 jours) ou en édition de licence Select. Les chemins de mise à niveau suivants sont pris en charge pour Service Manager SP1.

Le dossier par défaut pour l'installation de Service Manager et Service Manager SP1 est \Program Files\Microsoft System Center\Service Manager 2012. Toutefois, lorsque vous effectuez la mise à niveau vers Service Manager SP1, le logiciel est installé dans le dossier précédemment utilisé par Service Manager. Si Service Manager 2010 a été précédemment mis à niveau vers System Center 2012 - Service Manager, le dossier suivant peut être utilisé :

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

Cette version de Service Manager SP1 représente une évolution continue de la prise en charge de diverses langues. Dans Gestionnaire de service System Center 2010, vous avez utilisé le classement Latin1_General_100_CI_AS pour la langue turque.Service Manager et Service Manager SP1 prennent en charge le classement Turkish_100_CI_AS. Toutefois, si vous avez effectué une mise à niveau depuis Gestionnaire de service System Center 2010 vers System Center 2012 - Service Manager, le classement qui était utilisé pour la langue turque (Latin1_General_100_CI_AS) sera conservé dans System Center 2012 - Service Manager, ainsi que dans System Center 2012 - Service Manager SP1.

System Center 2012 - Service Manager SP1 fonctionnera sur le même matériel que vous avez utilisé pour System Center 2012 - Service Manager.

La configuration matérielle requise pour System Center 2012 - Service Manager SP1 est spécifiée dans le document Hardware Requirements for System Center 2012 - Service Manager (Configuration matérielle requise pour System Center 2012 - Service Manager).

Pour effectuer une mise à niveau vers System Center 2012 Service Pack 1 (SP1) SP1, vous devez tout d'abord appliquer la Mise à jour cumulative 2 pour System Center 2012 - Service Manager.

System Center 2012 - Service Manager SP1 nécessite la même configuration logicielle pour la Console de Service Manager que Gestionnaire de service System Center 2010, à l'exception de Microsoft SQL Server 2012 Analysis Management Objects (AMO) qui est une nouvelle condition requise. Microsoft SQL Server 2012 AMO est pris en charge sur SQL Server 2008 et SQL Server 2012. En outre, la Console de Service Manager peut désormais être installée sur des ordinateurs exécutant Windows 8 et Windows Server 2012.

Les serveurs d'administration Service Manager et de l'entrepôt de données, ainsi que le Portail libre-service sont pris en charge avec Windows Server 2012.

La configuration logicielle requise pour System Center 2012 - Service Manager SP1 est spécifiée dans le document Software Requirements for System Center 2012 - Service Manager (Configuration logicielle requise pour System Center 2012 - Service Manager).

Avant la mise à niveau

Description : Un problème lié au processus de mise à niveau entraîne l'échec de la tâche MPSync une fois la mise à niveau terminée. Pour éviter ce problème avant la mise à niveau, vous devez exécuter le script SQL ci-dessous sur la base de données DWRepository pour obtenir les scripts SQL qui suppriment et ajoutent une contrainte sur la clé principale des tables de faits dans la base de données DWRepository pour corriger le problème Les tâches de transformation et de chargement peuvent également échouer. Cette erreur peut se produire en raison du nettoyage de la base de données erronée.

;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  
  

Solution 1 : Si vous avez déjà effectué la mise à niveau et ne rencontrez pas d'échec avec les tâches de transformation ou de chargement mais des échecs de déploiement de pack d'administration, suivez les étapes de la section Avant la mise à niveau. De plus, une fois que les clés principales par défaut ont été restaurées, redémarrez le déploiement du pack d'administration qui a échoué dans la Console de Service Manager : accédez à l'espace de travail Entrepôt de données et sélectionnez Pack d'administration.

Solution 2 : Si vous avez effectué la mise à niveau et rencontrez des problèmes avec les tâches de transformation ou de chargement, vérifiez si le pack d'administration SystemDerivedMp.Microsoft.SystemCenter.Datawarehouse.Base existe dans la base de données DWStagingAndConfig en exécutant la requête suivante.

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

Si le pack d'administration n'existe pas, vous devez restaurer votre base de données avant la mise à niveau. Pour restaurer votre base de données, effectuez les opérations suivantes.

1. Effectuez les étapes de récupération d'urgence pour les sauvegardes de base de données.

2. Désactivez la planification MPSyncJob.

3. Restaurez toutes les clés primaires manquantes dans le DWRepository manuellement. Vous pouvez supprimer et recréer la clé primaire en utilisant le script SQL de la section Avant la mise à niveau.

4. Redémarrez le déploiement du pack d'administration de base qui a échoué en utilisant la Console de Service Manager.

Nous vous recommandons de tester la mise à niveau vers System Center 2012 - Service Manager SP1 dans un environnement lab.

L'ordre de vos mises à niveau est important. Effectuez les opérations de mise à niveau dans l'ordre suivant :

1. Sauvegardez vos bases de données et vos packs d'administration. Voir les rubriques relatives à la sauvegarde des bases de données Service Manager et la sauvegarde des packs d'administration non scellés dans Guide de récupération d'urgence pour System Center 2012 - Service Manager.

2. Commencez par le serveur d'administration de l'entrepôt de données. Vous allez arrêter les travaux d'entreposage de données et vous ne pourrez les redémarrer qu'à l'issue de la mise à niveau.

3. Une fois la mise à niveau du serveur d'administration de l'entrepôt de données terminée, effectuez la mise à niveau du serveur d'administration initial de Service Manager. Si vous avez créé plusieurs serveurs d'administration de Service Manager, le serveur d'administration initial de Service Manager est le premier que vous avez créé.

4. Effectuez la mise à niveau des instances de la Console de Service Manager Service Manager et des éventuels serveurs d'administration Service Manager supplémentaires.

5. Redémarrez les travaux d'entreposage de données.

6. Déployez le nouveau Portail libre-service.

Le minutage de vos mises à niveau est également important. Lorsque vous avez mis à niveau votre serveur d'administration de l'entrepôt de données, vous devez mettre à jour le serveur d'administration de Service Manager et déployer le nouveau Portail libre-service. Après avoir mis à jour votre serveur d'administration Service Manager initial, vous devez préparer la mise à niveau de votre Console de Service Manager ou de vos instances de Console de Service Manager, des autres serveurs d'administration Service Manager et du Portail libre-service en même temps.

Cette section décrit la compatibilité entre Operations Manager 2007 R2, System Center 2012 – Operations Manager et System Center 2012 - Service Manager SP1.

System Center Operations Manager 2007 R2

Avant de tenter une mise à niveau, vous devez supprimer les agents Operations Manager 2007 R2 des serveurs d'administration de Service Manager et de l'entrepôt de données.System Center 2012 - Service Manager SP1 inclut un agent System Center 2012 – Operations Manager SP1 qui est automatiquement installé lorsque vous effectuez la mise à niveau. Une fois le programme d'installation de Service Manager terminé, vous devez configurer manuellement l'agent pour communiquer avec le serveur d'administration Operations Manager.

Pour valider l'installation de l'Agent Operations Manager, ouvrez le Panneau de configuration et vérifiez que l'Agent Operations Manager est présent. Pour configurer manuellement l'Agent Operations Manager, voir Configuring Agents (Configuration des agents).

Vous pouvez mettre à niveau les Service Manager en présence d'une console Operations Manager 2007 R2.

System Center 2012 – Operations Manager

Les agents System Center 2012 – Operations Manager n'étaient pas pris en charge avec System Center 2012 - Service Manager. Cependant, l'agent qui est automatiquement installé par System Center 2012 - Service Manager SP1 est compatible avec System Center 2012 – Operations Manager et System Center 2012 – Operations Manager SP1. Une fois le programme d'installation de Service Manager terminé, vous devez configurer manuellement l'agent pour communiquer avec le serveur d'administration Operations Manager.

Pour valider l'installation de l'Agent Operations Manager, ouvrez le Panneau de configuration et vérifiez que l'Agent Operations Manager est présent. Pour configurer manuellement l'Agent Operations Manager, voir Configuring Agents (Configuration des agents).

Vous pouvez mettre à niveau les Service Manager en présence d'une console System Center 2012 – Operations Manager.

Avec System Center 2012 - Service Manager SP1, vous avez la possibilité d'installer des mini-Data Warehouses Operations Manager et Configuration Manager. Le choix de cette option va entraîner des exigences d'espace supplémentaire sur le disque dur pour les deux bases de données ainsi que pour les groupes de fichiers et fichiers journaux associés.

Avant de commencer toute mise à niveau, nous vous recommandons de sauvegarder vos bases de données de Service Manager et de l'entrepôt de données ainsi que la clé de chiffrement. Si vous avez déjà sauvegardé vos bases de données et la clé de chiffrement, vous pouvez continuer à exécuter la mise à niveau. Dans le cas contraire, passez en revue les procédures de sauvegarde dans le Guide de récupération d'urgence de System Center 2012 - Service Manager avant de continuer la mise à niveau.

Si vous avez installé un serveur d'administration d'entrepôt de données dans votre environnement dans le cadre du processus de mise à niveau, vous devez être en mesure d'afficher l'état des travaux d'entreposage de données. Vous ne pouvez pas effectuer cette tâche si vous n'avez pas procédé à une inscription auprès de l'entrepôt de données Service Manager. Si le bouton Entrepôt de données n'est pas visible dans la Console de Service Manager, suivez la procédure relative à l'inscription auprès de l'entrepôt de données de Service Manager dans Déploiement de System Center 2012 - Service Manager.

Lorsque vous avez terminé l'exécution du programme d'installation pour installer ou effectuer une mise à niveau vers System Center 2012 - Service Manager SP1, vous êtes invité à ouvrir l'Assistant de sauvegarde ou de restauration du chiffrement. Si vous avez précédemment sauvegardé les clés de chiffrement, aucune action supplémentaire n'est requise. Si vous n'avez jamais sauvegardé les clés de chiffrement, utilisez l'Assistant Sauvegarde ou restauration de clé de chiffrement pour sauvegarder les clés de chiffrement sur les serveurs d'administration de Service Manager.

Lorsque vous utilisez la version Service Manager SP1 de l'outil Authoring Tool pour créer un flux de travail, les scripts personnalisés à l'aide des applets de commande Windows PowerShell appelés par le flux de travail échouent. Cela est dû à un problème qui survient dans le fichier MonitoringHost.exe.config de Service Manager.

Pour contourner ce problème, mettez à jour le fichier XML MonitoringHost.exe.config de la façon suivante.

1. Naviguez jusqu'à %ProgramFiles%\Microsoft System Center 2012\Service Manager\ ou à l'emplacement où vous avez installé Service Manager.

2. Modifiez le fichier MonitoringHost.exe.config et ajoutez la section en italique à partir de l'exemple ci-dessous dans la section correspondante de votre fichier. Vous devez insérer la section avant <publisherPolicy apply="yes" />.

3. Enregistrez les modifications apportées au fichier.

4. Redémarrez le service d'administration de System Center sur le serveur d'administration de Service Manager.

<?xml version="1.0"?>  
<configuration>  
  <configSections>  
    <section name="uri" type="System.Configuration.UriSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />  
  </configSections>  
  <uri>  
    <iriParsing enabled="true" />  
  </uri>    
  <runtime>  
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">  
      <dependentAssembly>  
        <assemblyIdentity name="Microsoft.Mom.Modules.DataTypes" publicKeyToken="31bf3856ad364e35" />  
        <publisherPolicy apply="no" />  
        <bindingRedirect oldVersion="6.0.4900.0" newVersion="7.0.5000.0" />  
      </dependentAssembly>  
      <dependentAssembly>  
        <assemblyIdentity name="Microsoft.EnterpriseManagement.HealthService.Modules.WorkflowFoundation" publicKeyToken="31bf3856ad364e35" />  
        <publisherPolicy apply="no" />  
        <bindingRedirect oldVersion="6.0.4900.0" newVersion="7.0.5000.0" />  
      </dependentAssembly>  
  <dependentAssembly>   
         <assemblyIdentity name="Microsoft.EnterpriseManagement.Modules.PowerShell" publicKeyToken="31bf3856ad364e35" />  
        <bindingRedirect oldVersion="6.0.4900.0" newVersion="7.0.5000.0" />  
     </dependentAssembly>   
      <publisherPolicy apply="yes" />  
      <probing privatePath="" />  
    </assemblyBinding>  
    <gcConcurrent enabled="true" />  
  </runtime>  
</configuration>