Comme de plus en plus de produits Microsoft (et autres Ă©diteurs), les solutions tendent Ă  ĂŞtre de plus en plus complexe. Il a beau faire partie de la gamme « System Center » de Microsoft, il quelques singularitĂ©s auxquelles je me suis frottĂ© rĂ©cemment. InstallĂ© avant mon arrivĂ©, on a souhaitĂ© dĂ©placer les bases de donnĂ©es associĂ©es au produit d’un serveur SQL Ă  un autre.

1er challenge: où est stocké le nom du serveur SQL ?

Recherche dans la base de registre (comme SCOM) ? rien
Recherche dans les fichiers dans le rĂ©pertoire d’installation ? rien
Il stocke l’information dans Active Directory (un SCP / Service Connection Point). Un petit coup d’adsiedit plus tard, il pointe sur le nouveau serveur SQL
Ce point est évoqué dans un article Technet lors de la restauration des bases

2ème challenge: SQL

L’Ă©quipe du produit utilise pleinement SQL Server, notamment:

  • L’encryption des donnĂ©es via la clĂ© de l’instance (Service Master Key)
  • Job via l’agent SQL

Cela me semble assez « riche » pour ce type de solutions, mais bon… Vous l’avez compris, il faut sauvegarder et restaurer la clĂ© d’encryption de l’instance de l’ancien serveur SQL…

Pour rappel, les bases SQL pour MDM portent les noms suivants:

  • AdminServices
  • MobileEnrollment
  • TEEDB
  • SUSDB

La documentation Microsoft du produit: http://technet.microsoft.com/en-us/scmdm/cc304592.aspx

Popularity: 3% [?]