La fin du support de Windows Server 2012 R2 et SQL Server 2012 approchant, beaucoup d'infrastructures initialement montées sous SCCM 2012 risquent d'avoir besoin d'une montée de version.
Voici donc un REX sur une montée d'environnement MECM sous Windows Server 2012 R2 / SQL Server 2012 vers Windows Server 2019 / SQL Server 2019.
Pour commencer, le client m'appelait pour monter une nouvelle infra MECM directement en 2019. Il se chargerait de migrer les éléments de l'ancien vers le nouvel environnement.
Rappelons que la cohabitation et la migration d'environnements MECM ne sont des opérations ni faciles ni rapides. Bref, nous nous sommes rapidement tournés vers une montée de version de l'environnement existant.
Voici donc un REX sur une montée d'environnement MECM sous Windows Server 2012 R2 / SQL Server 2012 vers Windows Server 2019 / SQL Server 2019.
Pour commencer, le client m'appelait pour monter une nouvelle infra MECM directement en 2019. Il se chargerait de migrer les éléments de l'ancien vers le nouvel environnement.
Rappelons que la cohabitation et la migration d'environnements MECM ne sont des opérations ni faciles ni rapides. Bref, nous nous sommes rapidement tournés vers une montée de version de l'environnement existant.
L'opération de montée d'OS et de SQL Server d'un environnement MECM est supportée et décrite par Microsoft ici : https://docs.microsoft.com/en-us/mem/configmgr/core/servers/manage/upgrade-on-premises-infrastructure
Personnellement, après quelques soucis lors des montées de plusieurs versions, je préfère les montées de version progressives (statistiquement jouées le plus souvent donc avec le plus grand nombre de REX).
Il est évidemment recommandé de prendre quelques précautions avant de se lancer dans des opérations impactantes, comme ici :
Upgrade WS2012 -> 2016 -> 2019
Personnellement, après quelques soucis lors des montées de plusieurs versions, je préfère les montées de version progressives (statistiquement jouées le plus souvent donc avec le plus grand nombre de REX).
Il est évidemment recommandé de prendre quelques précautions avant de se lancer dans des opérations impactantes, comme ici :
- Snapshot à froid (serveur éteint) - à chaque étape ;
- Sauvegarde MECM - Rappelons que la seule vraie méthode de sauvegarde réellement supportée est la sauvegarde réalisée par MECM lui-même ;
- Antivirus désinstallé - J'ai eu des pépins d'AV qui se réveillaient en cours de migration, donc pour éviter le retour des morts-vivants, je n'enterre pas, je désintègre 😅 ;
- Évidemment, on s'assure avant de commencer et à chaque étape que l'environnement MECM est en bonne santé.
Upgrade WS2012 -> 2016 -> 2019
- Depuis la console MECM, Retirer les composants SUP et Reporting.
- Si vous avez des tâches planifiées, sauvegardez les ! Elles risquent de sauter.
- Désinstaller WSUS. Rien de compliqué, tout se fait depuis Server Manager.
- Désinstaller SSRS (SQL Reporting) - Non sans avoir préalablement fait quelques captures d'écran de la configuration et sauvegardé les rapports personnalisés.
Si, comme moi, vous ne parvenez pas à lancer l'assistant, vous pouvez aussi lancer SetupARP.exe (à rechercher parmi les binaires de SQL Server).
Sur son blog, Anoop détaille étape par étape, la sauvegarde des rapports et la désinstallation de SSRS.
Attention : En désinstallant le rôle SUP, MECM estime qu'il ne gère plus le patch-management des postes. Les postes vont donc être livrés à eux-même et risquent même de partir sur Internet, peut être pour appliquer la dernière version de Windows...
Il est donc fortement recommandé d'activer la GPO Computer Configuration > Administrative Templates > System > Internet Communication
Management > Internet Communication settings > Turn off
access to all Windows Update features
Il s'agit d'ailleurs d'une GPO que je recommande de mettre en place constamment chez mes clients.
Il vous reste à vérifier que tous les éléments spécifiques à votre environnement sont respectés avant Upgrade :
Une fois ces quelques points traités, la montée de version de Windows Server peut être lancée depuis l'iso Windows Server 2016 puis Windows Server 2019. Si l'assistant ne propose pas d'upgrade, mais seulement une réinstallation complète, c'est qu'un pré-requis ne va pas. Un problème de langue peut-être ?
En maquette comme en production, la migration vers Windows Server 2016 puis Windows Server 2019 n'a posé strictement aucun problème.
Validation de la montée de version d'OS
Après un dernier redémarrage, on peut s'assurer que le serveur et MECM sont de retour.
En particulier, on vérifie que Windows Defender est actif ainsi que les principaux services MECM.
Encore une fois, je vous renvoie à la liste exacte des vérifications fournies par Microsoft :
L'upgrade s'est bien passé sur notre maquette. En revanche, il a fallu réappliquer les droits WMI dans l’environnement de prod.
Rien de compliqué, cela fait parti des problèmes connus et pour lesquels Microsoft donne un mode opératoire précis :
Réinstallation de WSUS/SUP
A partir de là, il est possible de réinstaller WSUS (simplement depuis le Server Manager + initialisation de composant) + SUP.
Il reste à vérifier que le composant fonctionne correctement en lançant une synchronisation des updates depuis la console MECM.
En maquette, comme en production, nous avons eu des soucis avec des Timeout (section Monitoring de la console MECM) et le message Sync failed: The operation has timed out. Source: Microsoft.UpdateServices.Internal.DatabaseAccess.ApiRemotingCompressionProxy.GetWebResponse dans le fichier wsyncmgr.log, alors qu'aucun proxy n'était en œuvre dans notre contexte.
Nous avons résolu cette erreur simplement en modifiant la liste des produits à synchroniser dans MECM.
Upgrade SQL Server 2012 -> 2016 -> 2019
Comme
déjà mentionné, SQL Server Reporting Service (SSRS) ne fait plus partie des
composants natifs de SQL Server 2019. Si le composant est encore présent, l'assistant d'upgrade SQL 2019 proposera de le désinstaller.
Il est donc fortement recommandé de :
- Réaliser des captures d'écran de la configuration de SSRS (console Report Server Configuration Manager);
- d'Exporter les rapports spécifiques.
Sur son blog, Anoop détaille étape par étape, la sauvegarde des rapports et la désinstallation de SSRS.
https://www.anoopcnair.com/upgrade-ssrs-sql-server-reporting-services-2019/Les étapes de montées de version de SQL Server sont décrites ici :
Difficile de faire plus simple :
- Arrêter les services MECM ;
- Lancer l'upgrade SQL Server ;
- Relancer les services MECM (personnellement, je préfère un bon vieux redémarrage).
Réinstallation de SSRS
Nous allons aborder l'étape qui nous a donné le plus de difficulté et sur laquelle Microsoft ne dit pourtant pas un mot.
Le composant SSRS 2019 doit être téléchargé depuis le site de Microsoft https://www.microsoft.com/en-us/download/details.aspx?id=100122.
Anoop décrit assez précisément les étapes pour désinstaller puis réinstaller SSRS 2019 (https://www.anoopcnair.com/upgrade-ssrs-sql-server-reporting-services-2019/).
Malheureusement en maquette comme en production, nous avons eu énormément de difficultés à faire fonctionner SSRS 2019 (erreurs 500) puis à remettre sur pied le composant de Reporting MECM.
Avant de réinstaller le composant SSRS 2019, voici les étapes supplémentaires que nous avons réalisées :
1. Depuis SQL Server Management Studio, suppression des bases ReportServer et ReportServerTempDB.
2. Suppression (ou renommage) du répertoire SMS_SRSRP (même chemin que le répertoire d'installation de MECM).
Pendant la configuration de la base SSRS, il ne faut donc pas sélectionner "Choose an existing Report Server Daabase" (comme dans la procédure de Anoop), mais "Create a new report database". L'assistant se chargera de recréer la base ReportServer.
A la fin de la configuration de SSRS et avant de procéder à l'installation du rôle Reporting, il est recommandé de vérifier que SSRS fonctionne.
Pour cela, on peut au moins tenter d'accéder au web service via un navigateur sur le serveur.
Le navigateur doit au moins de demander des identifiants admin. Si le serveur renvoie un code 500 ou 503, c'est qu'il faut vérifier la configuration.
Les logs SSRS sont désormais dans <Microsoft SQL Server Reporting Services>\SSRS\LogFiles
En production, nous avons notamment découvert que le compte de service SSRS n'avait pas les droits suffisants sur le répertoire temporaire de SSRS !?! Nous avons donc simplement ajouté les autorisations et tout est rentré dans l'ordre...
Une fois SSRS fonctionnel, il reste à ajouter le service Reporting Server depuis la console MECM.
Le log srsrp.log fait apparaître l'injection des rapports dans SSRS.
Il ne reste plus qu'à vérifier avec quelques rapports que tout fonctionne à nouveau.
J'espère que ce retour d'expérience vous a plu.
A la prochaine !
Julien
