Base de données satellite en tant qu'abonné GeoSync

Vous appliquez cette procédure dans la situation suivante : une base de données de serveur de personnalisation a été créée via l'exportation de tout ou partie de la configuration depuis une base de données maître plus volumineuse (avec la fonction d'importation/exportation), et elle est utilisée à distance pour un plus petit nombre d'utilisateurs. Le client veut utiliser GeoSync pour synchroniser automatique une partie des utilisateurs entre le maître et le satellite, et les désignant respectivement comme éditeur et abonné GeoSync. Ce n'est pas possible avec les scripts de réplication avec fusion existants, car ils synchronisent l'ensemble de la base de données.

L'importation/exportation d'une configuration modifie les ID de base de données (GUID) sur lesquels la fonction GeoSync se base pour mettre en correspondance l'éditeur et l'abonné. Pour résoudre le problème, il faut modifier tous les GUID de l'abonné pour refléter ceux de l'éditeur. Pour ce faire, il faut temporairement rendre l'abonné inaccessible. Aucun utilisateur affecté ne peut se connecter et tous les caches hors ligne des machines utilisateur risquent de devenir non valides, car ils ne peuvent pas être réenregistrés dans la base de données modifiée lors de la connexion suivante. De plus, si les colonnes « OriginalName » des groupes Paramètres Windows ne sont pas identiques dans l'éditeur et dans l'abonné, la synchronisation est impossible.

Le mappage des GUID est effectué par un script PowerShell (PrepareGeoSubscriber.ps1), qui fait appel à l'utilitaire sqlcmd et à deux scripts SQL (CheckMapping.sql et MapUgs.sql), qui doivent obligatoirement résider dans le même dossier.

Ces scripts se trouvent ici : :%systemdrive%\Program Files\AppSense\Environment Manager\Personalization Server\Support.

Limitations

Si les bases de données éditeur et abonné n'ont pas été créées dans la même version du logiciel, les problèmes suivants peuvent surgir :

En raison de l'introduction de Windows 10 et Server 2016, certains noms de groupe Paramètres Windows (WSG) ont changé d'une version à l'autre des bases de données. Si des groupes sont exportés et importés dans l'abonné, et si l'abonné contient à la fois l'ancien nom et le nouveau, la synchronisation des groupes WSG est impossible car la colonne OriginalName ne contient pas les mêmes valeurs dans la table DesktopSettings.[Group]. Il est assez difficile de changer les noms d'origine, car cela nécessite une analyse des deux tables ApplicationData et ApplicationDataArchives. Le processus de mappage présenté dans cette rubrique ne prend pas l'opération en charge.
Si les utilisateurs à synchroniser existent à la fois dans la base de données éditeur et dans la base de données abonné, et si ces utilisateurs ont initialement été créés dans des versions de Personalization Server antérieures à 8.4, la synchronisation est impossible. En effet, avant la version 8.4, les identités utilisateur (colonne UserPK) étaient allouées aléatoirement en fonction de l'algorithme de GUID habituel. Depuis la version 8.4, les GUID sont tirés des SID des utilisateurs et sont identiques dans toutes les bases de données. La solution au problème consiste à supprimer physiquement les utilisateurs concernés de l'une des bases de données, en appliquant SQL DELETE à la table dbo.[User].table.

Prérequis

L'utilisateur qui exécute les scripts doit disposer d'un accès sysadmin aux deux bases de données, via la fonction Authentification intégrée de Windows.
Les scripts doivent être exécutés sur une machine où l'utilitaire sqlcmd.exe figure dans la variable PATH actuelle. L'un des serveurs de base de données impliqués peut sembler plus pratique, mais vous pouvez installer sqlcmd.exe sur une autre machine en téléchargeant le MSI approprié depuis le site Microsoft.
Les bases de données éditeur et abonné doivent être accessibles l'une pour l'autre, ainsi que pour le script sur le réseau. L'utilitaire sqlcmd et le logiciel GeoSync proprement dit utilisent des connexions SQL Server normales (généralement, sur le port 1433).

Configuration initiale

Le script est appliqué à un seul groupe de personnalisation à la fois. Ce groupe de personnalisation (identifié par son nom) doit apparaître à la fois dans l'éditeur et dans l'abonné avant de commencer. Nous considérons ici que vous n'avez pas encore configuré GeoSync, et les termes « éditeur » et « abonné » désignent le rôle que vous prévoyez de donner à ces éléments.

En général, l'on considère qu'un groupe de personnalisation est exporté depuis l'éditeur et importé dans l'abonné à l'aide de la fonction d'importation/exportation. Cependant, si vous créez un groupe de personnalisation dans l'abonné à l'aide des groupes d'applications et des groupes de paramètres Windows importés depuis l'éditeur, il est possible d'effectuer la synchronisation en exportant le groupe depuis l'abonné et en le réimportant dans l'éditeur.

Dans les deux cas, le script considère que le groupe de personnalisation à synchroniser existe initialement dans les deux bases de données.

Exécution du script

Le script PowerShell et les deux scripts SQL doivent se trouver dans le même répertoire. Exécutez le script PowerShell depuis une invite de commande PowerShell. Aucune élévation n'est nécessaire. Le système vous invite à entrer les détails des deux bases de données, ainsi que le nom du groupe de personnalisation à synchroniser. Il vérifie que les bases de données spécifiées existent, puis exécute les deux scripts SQL. Ces scripts s'exécutent sur l'abonné mais contactent l'éditeur en créant une entrée serveur liée, supprimée après l'opération.

Ces deux scripts effectuent les opérations suivantes :

CheckMapping.sql - Compare tous les détails du groupe pour identifier les problèmes éventuels. Il existe trois catégories de problèmes :
- Avertissement - Le groupe de personnalisation de l'éditeur contient des entités supplémentaires (groupes de personnalisation, par exemple) qui ne figurent pas dans l'abonné. Après la synchronisation, l'abonné peut par conséquent recevoir des entités supplémentaires.
- Erreur - Le groupe de personnalisation de l'abonné comporte des entités supplémentaires, absentes de l'éditeur. Cela peut faire disparaître des données de l'abonné et vous devez étudier le problème.
- Fatal - Les champs « originalname » des groupes de paramètres Windows sont différents dans l'éditeur et dans l'abonné, généralement parce que des données similaires sont déjà présentes dans l'abonné. Le mappage est impossible.
MapUGs.sql - Exécute le mappage. Ne peut pas s'exécuter si des erreurs « Fatal » ont été détectées. L'utilisateur voit d'abord une invite, avant l'exécution de ce script, et peut apporter les changements voulus avant de relancer l'opération.

Configuration de GeoSync

Après la synchronisation du groupe de personnalisation, vous pouvez activer GeoSync dans les deux bases de données en appliquant la procédure décrite ici. Après la configuration, le groupe de personnalisation synchronisé doit être désigné comme synchronisé dans l'onglet GeoSync correspondant de la console Environment Manager. Si ce groupe comporte des données existantes dans l'éditeur, vous devrez peut-être configurer les conditions GeoSync de façon à garantir que le système ne transmet pas toutes les données de l'éditeur à l'abonné.

Actions CheckMapping

Le script CheckMapping.sql vérifie les éléments suivants dans les bases de données éditeur et abonné :

Vérifications	Catégorie de problèmes
Le groupe de personnalisation n'est pas présent dans les deux bases de données.	Fatal
Les cases cochées dans l'onglet Paramètres ne sont pas les mêmes dans les deux groupes de personnalisation.	Avertissement
Les utilisateurs concernés existent dans les deux bases de données, avec le même SID mais des GUID différents.	Fatal
Le paramétrage de la propriété avancée UpgradeFbrToHive n'est pas le même dans les deux bases de données.	Fatal
Les affectations de groupes d'applications ne sont pas les mêmes.	L'éditeur comporte davantage de groupes d'applications : Avertissement L'abonné comporte davantage de groupes d'applications : Erreur
Les applications affectées aux groupes d'applications ne sont pas les mêmes.	L'éditeur en comporte davantage : Avertissement L'abonné en comporte davantage : Erreur
Les définitions d'application (EXE, version d'OS, version de fichier) sont différentes.	L'éditeur en comporte davantage : Avertissement L'abonné en comporte davantage : Erreur
Les chemins de registre, de fichier et de dossier affectés aux groupes d'applications sont différents.	L'éditeur en comporte davantage : Avertissement L'abonné en comporte davantage : Erreur
Les dossiers gérés des groupes d'applications sont différents.	L'éditeur en comporte davantage : Avertissement L'abonné en comporte davantage : Erreur
Les affectations de groupes Paramètres Windows ne sont pas les mêmes dans les deux bases de données.	L'éditeur en comporte davantage : Avertissement L'abonné en comporte davantage : Erreur
Les composants, paramètres, paramètres personnalisés ou conditions des groupes Paramètres Windows ne sont pas identiques.	L'éditeur en comporte davantage : Avertissement L'abonné en comporte davantage : Erreur
Les colonnes OriginalName des groupes WSG à synchroniser n'ont pas le même contenu. Cela peut se produit lors de l'importation si des groupes WSG existants dans l'abonné portent des noms d'origine identiques. Le problème est difficile à résoudre, parce que le nom d'origine (OriginalName) est utilisé dans les données et les archives, et n'est pas corrigé par le script MapUGs.sql.	Fatal