Stocker les données d’abonnement à l’aide de Microsoft SQL Server

Remarque :

Ce document suppose une connaissance de base de MS SQL Server et des requêtes T-SQL. Les administrateurs doivent être à l’aise avec la configuration, l’utilisation et l’administration de SQL Server avant de tenter de suivre ce document.

Introduction

ESENT est un moteur de base de données transactionnel et embarqué que Windows peut utiliser. Toutes les versions de StoreFront prennent en charge l’utilisation d’une base de données ESENT intégrée par défaut. Elles peuvent également se connecter à une instance Microsoft SQL Server si le magasin est configuré pour utiliser une chaîne de connexion SQL.

Le principal avantage de faire passer StoreFront à l’utilisation de SQL au lieu d’ESENT est que les instructions de mise à jour T-SQL vous permettent de gérer, modifier ou supprimer des enregistrements d’abonnement. Si vous utilisez SQL, vous n’avez pas besoin d’exporter, de modifier et de réimporter l’intégralité des données d’abonnement ESENT chaque fois que des modifications mineures sont apportées aux données d’abonnement.

Pour migrer les données d’abonnement existantes d’ESENT vers Microsoft SQL Server, les données ESENT brutes exportées de StoreFront doivent être transformées dans un format compatible SQL pour une importation en masse. Pour les nouveaux déploiements sans nouvelles données d’abonnement, cette étape n’est pas nécessaire. L’étape de transformation des données n’est requise qu’une seule fois. Cet article décrit la configuration prise en charge qui peut être utilisée dans toutes les versions de StoreFront à partir de la version 3.5, qui a introduit le SDK PowerShell -STF référencé dans l’article.

Remarque :

Les échecs de connexion à l’instance SQL Server utilisée par StoreFront pour stocker les données d’abonnement en raison de pannes réseau ne rendent pas le déploiement StoreFront inutilisable. Les pannes n’entraînent qu’une dégradation temporaire de l’expérience utilisateur ; les utilisateurs ne peuvent pas ajouter, supprimer ou afficher les ressources favorites tant que la connexion à SQL Server n’est pas rétablie. Les ressources peuvent toujours être énumérées et lancées pendant la panne. Le comportement attendu est le même que si le service Citrix Subscription Store devait s’arrêter lors de l’utilisation d’ESENT.

Conseil :

Les ressources configurées avec KEYWORDS:Auto ou KEYWORDS:Mandatory se comportent de la même manière, que ce soit avec ESENT ou SQL. De nouveaux enregistrements d’abonnement SQL sont créés automatiquement lorsqu’un utilisateur se connecte pour la première fois si l’un ou l’autre de ces mots-clés est inclus dans les ressources de l’utilisateur.

Avantages d’ESENT et de SQL Server

Inconvénients d’ESENT et de SQL Server

Scénarios de déploiement

Remarque :

Chaque magasin configuré dans StoreFront nécessite soit une base de données ESENT, soit une base de données Microsoft SQL si vous souhaitez prendre en charge les abonnements utilisateur. La méthode de stockage des données d’abonnement est définie au niveau du magasin dans StoreFront.

Citrix® recommande que toutes les bases de données de magasin résident sur la même instance Microsoft SQL Server afin de réduire la complexité de la gestion et les risques de mauvaise configuration.

Plusieurs magasins peuvent partager la même base de données, à condition qu’ils soient tous configurés pour utiliser la même chaîne de connexion. Peu importe s’ils utilisent des contrôleurs de livraison différents. L’inconvénient de plusieurs magasins partageant une base de données est qu’il n’y a aucun moyen de savoir à quel magasin correspond chaque enregistrement d’abonnement.

Une combinaison des deux méthodes de stockage de données est techniquement possible sur un déploiement StoreFront unique avec plusieurs magasins. Il est possible de configurer un magasin pour utiliser ESENT et un autre pour utiliser SQL. Cela n’est pas recommandé en raison de la complexité de gestion accrue et des risques de mauvaise configuration.

Il existe quatre scénarios que vous pouvez utiliser pour stocker les données d’abonnement dans SQL Server :

Scénario 1 : Serveur StoreFront unique ou groupe de serveurs utilisant ESENT (par défaut)

Par défaut, toutes les versions de StoreFront depuis la version 2.0 utilisent une base de données ESENT plate pour stocker et répliquer les données d’abonnement entre les membres d’un groupe de serveurs. Chaque membre du groupe de serveurs conserve une copie identique de la base de données d’abonnement, qui est synchronisée avec tous les autres membres du groupe de serveurs. Ce scénario ne nécessite aucune étape de configuration supplémentaire. Ce scénario convient à la plupart des clients qui ne s’attendent pas à des changements fréquents de noms de contrôleurs de livraison ou qui n’ont pas besoin d’effectuer des tâches de gestion fréquentes sur leurs données d’abonnement, comme la suppression ou la mise à jour d’anciens abonnements utilisateur.

Scénario 2 : Serveur StoreFront unique et instance Microsoft SQL Server locale installée

StoreFront utilise une instance SQL Server installée localement et les deux composants résident sur le même serveur. Ce scénario convient à un déploiement StoreFront unique et simple où les clients pourraient avoir besoin d’apporter des modifications fréquentes aux noms des contrôleurs de livraison, ou d’effectuer des tâches de gestion fréquentes sur leurs données d’abonnement, comme la suppression ou la mise à jour d’anciens abonnements utilisateur, mais ils ne nécessitent pas un déploiement StoreFront à haute disponibilité. Citrix ne recommande pas ce scénario pour les groupes de serveurs car il crée un point de défaillance unique sur le membre du groupe de serveurs qui héberge l’instance de base de données Microsoft SQL. Ce scénario ne convient pas aux déploiements de grande entreprise.

Scénario 3 : Groupe de serveurs StoreFront et instance Microsoft SQL Server dédiée configurée pour la haute disponibilité (recommandé)

Tous les membres du groupe de serveurs StoreFront se connectent à la même instance Microsoft SQL Server dédiée ou au même cluster de basculement SQL. C’est le modèle le plus adapté aux déploiements de grande entreprise où les administrateurs Citrix souhaitent apporter des modifications fréquentes aux noms des contrôleurs de livraison ou effectuer des tâches de gestion fréquentes sur leurs données d’abonnement, comme la suppression ou la mise à jour d’anciens abonnements utilisateur, et nécessitent une haute disponibilité.

Scénario 4 : Plusieurs groupes de serveurs StoreFront et une instance Microsoft SQL Server dédiée dans chaque centre de données par groupe de serveurs

Remarque :

Il s’agit d’une configuration avancée. Ne tentez de la mettre en œuvre que si vous êtes un administrateur SQL Server expérimenté, familiarisé avec la réplication transactionnelle, et que vous possédez les compétences nécessaires pour la déployer avec succès.

Ceci est identique au scénario 3, mais l’étend aux situations où plusieurs groupes de serveurs StoreFront sont requis dans différents centres de données distants. Les administrateurs Citrix peuvent choisir de synchroniser les données d’abonnement entre différents groupes de serveurs dans les mêmes centres de données ou dans des centres de données différents. Chaque groupe de serveurs du centre de données se connecte à sa propre instance Microsoft SQL Server dédiée pour la redondance, le basculement et les performances. Ce scénario nécessite une configuration et une infrastructure Microsoft SQL Server supplémentaires considérables. Il repose entièrement sur la technologie Microsoft SQL pour répliquer les données d’abonnement et ses transactions SQL.

Ressources

Vous pouvez télécharger les scripts suivants depuis https://github.com/citrix/sample-scripts/tree/master/storefront pour vous aider :

Scripts de configuration

• Set-STFDatabase.ps1 – définit la chaîne de connexion MS SQL pour chaque magasin. À exécuter sur le serveur StoreFront.

• Add-LocalAppPoolAccounts.ps1 – accorde aux pools d’applications du serveur StoreFront local un accès en lecture et en écriture à la base de données SQL. À exécuter pour le scénario 2 sur le serveur SQL.

• Add-RemoteSFAccounts.ps1 – accorde à tous les serveurs StoreFront d’un groupe de serveurs un accès en lecture et en écriture à la base de données SQL. À exécuter pour le scénario 3 sur le serveur SQL.

• Create-StoreSubscriptionsDB-2016.sql – crée la base de données et le schéma SQL. À exécuter sur le serveur SQL.

Scripts de transformation et d’importation de données

• Transform-SubscriptionDataForStore.ps1 – exporte et transforme les données d’abonnement existantes au sein d’ESENT dans un format compatible SQL pour l’importation.

• Create-ImportSubscriptionDataSP.sql – crée une procédure stockée pour importer les données transformées par Transform-SubscriptionDataForStore.ps1. Exécutez ce script une fois sur le serveur SQL après avoir créé le schéma de base de données à l’aide de Create-StoreSubscriptionsDB-2016.sql.

Configurer le groupe de sécurité local du serveur StoreFront sur le serveur SQL

Scénario 2 : Serveur StoreFront unique et instance Microsoft SQL Server locale installée

Créez un groupe de sécurité local appelé <SQLServer>\StoreFrontServers sur le serveur Microsoft SQL, et ajoutez les comptes virtuels pour IIS APPPOOL\DefaultAppPool et IIS APPPOOL\Citrix Receiver for Web afin de permettre à StoreFront installé localement de lire et d’écrire dans SQL. Ce groupe de sécurité est référencé dans le script .SQL qui crée le schéma de la base de données d’abonnement du magasin, assurez-vous donc que le nom du groupe correspond.

Vous pouvez télécharger le script Add-LocalAppPoolAccounts.ps1 pour vous aider.

Installez StoreFront avant d’exécuter le script Add-LocalAppPoolAccounts.ps1. Le script dépend de la capacité à localiser le compte IIS virtuel IIS APPPOOL\Citrix Receiver for Web, qui n’existe pas tant que StoreFront n’a pas été installé et configuré. IIS APPPOOL\DefaultAppPool est créé automatiquement lors de l’installation du rôle de serveur web IIS.

# Create Local Group for StoreFront servers on DB Server
$LocalGroupName = "StoreFrontServers"
$Description = "Contains StoreFront Server Machine Accounts or StoreFront AppPool Virtual Accounts"

# Check whether the Local Group Exists
if ([ADSI]::Exists("WinNT://$env:ComputerName/$LocalGroupName"))
{
    Write-Host "$LocalGroupName already exists!" -ForegroundColor "Yellow"
}
else
{
Write-Host "Creating $LocalGroupName local security group" -ForegroundColor "Yellow"

# Create Local User Group
$Computer = [ADSI]"WinNT://$env:ComputerName,Computer"
$LocalGroup = $Computer.Create("group",$LocalGroupName)
$LocalGroup.setinfo()
$LocalGroup.description = $Description
$Localgroup.SetInfo()
Write-Host "$LocalGroupName local security group created" -ForegroundColor "Green"
}
$Group = [ADSI]"WinNT://$env:ComputerName/$LocalGroupName,group"

# Add IIS APPPOOL\DefaultAppPool
$objAccount = New-Object System.Security.Principal.NTAccount("IIS APPPOOL\DefaultAppPool")
$StrSID = $objAccount.Translate([System.Security.Principal.SecurityIdentifier])
$DefaultSID = $StrSID.Value

$Account = [ADSI]"WinNT://$DefaultSID"
$Group.Add($Account.Path)

# Add IIS APPPOOL\Citrix Receiver for Web
$objAccount = New-Object System.Security.Principal.NTAccount("IIS APPPOOL\Citrix Receiver for Web")
$StrSID = $objAccount.Translate([System.Security.Principal.SecurityIdentifier])
$WebRSID = $StrSID.Value

$Account = [ADSI]"WinNT://$WebRSID"
$Group.Add($Account.Path)
<!--NeedCopy-->

Write-Host “Pools d’applications ajoutés au groupe local $LocalGroupName” -ForegroundColor “Green”

Activez les canaux nommés dans votre instance SQL locale à l'aide du gestionnaire de configuration SQL Server. Les canaux nommés sont requis pour la communication interprocessus entre StoreFront et SQL Server.

![Capture d'écran des canaux nommés activés](/en-us/storefront/2402-ltsr/media/configure-manage-stores/sql-server-named-pipes.png)

Assurez-vous que les règles du pare-feu Windows sont correctement configurées pour autoriser les connexions SQL Server à l'aide d'un port spécifique ou de ports dynamiques. Reportez-vous à la documentation Microsoft pour savoir comment procéder dans votre environnement.

> **Conseil :**
>
> Si la connexion à l'instance SQL locale échoue, vérifiez que localhost ou `\<hostname\>` utilisé dans la chaîne de connexion se résout à la bonne adresse IPv4. Windows peut tenter d'utiliser IPv6 au lieu d'IPv4, et la résolution DNS de localhost peut renvoyer ::1 au lieu de la bonne adresse IPv4 du serveur StoreFront et SQL Server. La désactivation complète de la pile réseau IPv6 sur le serveur hôte peut être nécessaire pour résoudre ce problème.

### Scénario 3 : Groupe de serveurs StoreFront et instance de serveur Microsoft SQL dédiée

Créez un groupe de sécurité local appelé `\<SQLServer\>\StoreFrontServers` sur le serveur Microsoft SQL et ajoutez-y tous les membres du groupe de serveurs StoreFront. Ce groupe de sécurité est référencé ultérieurement dans le script **Create-StoreSubscriptionsDB-2016.sql** qui crée le schéma de la base de données d'abonnement dans SQL.

![Capture d'écran du groupe de sécurité StoreFrontServers](/en-us/storefront/2402-ltsr/media/configure-manage-stores/sql-server-security-groups.png)

Ajoutez tous les comptes d'ordinateur de domaine du groupe de serveurs StoreFront au groupe `\<SQLServer\>\StoreFrontServers`. Seuls les comptes d'ordinateur de domaine du serveur StoreFront répertoriés dans le groupe pourront lire et écrire des enregistrements d'abonnement dans SQL si l'authentification Windows est utilisée par SQL Server. La fonction PowerShell suivante, fournie dans le script [Add-RemoteSFAccounts.ps1](https://raw.githubusercontent.com/citrix/sample-scripts/master/storefront/Add-RemoteSFAccounts.ps1), crée le groupe de sécurité local et y ajoute deux serveurs StoreFront nommés StoreFrontSQL1 et StoreFrontSQL2.

<!--NeedCopy-->
```powershell
function Add-RemoteSTFMachineAccounts
{
[CmdletBinding()]
param([Parameter(Mandatory=$True)][string]$Domain,
[Parameter(Mandatory=$True)][array]$StoreFrontServers)

# Create Local Group for StoreFront servers on DB Server
$LocalGroupName = "StoreFrontServers"
$Description = "Contains StoreFront Server Machine Accounts or StoreFront AppPool virtual accounts"

# Check whether the Local Security Group already exists
if ([ADSI]::Exists("WinNT://$env:ComputerName/$LocalGroupName"))
{
    Write-Host "$LocalGroupName already exists!" -ForegroundColor "Yellow"
}
else
{
    Write-Host "Creating $LocalGroupName local group" -ForegroundColor "Yellow"

    # Create Local Security Group
    $Computer = [ADSI]"WinNT://$env:ComputerName,Computer"
    $LocalGroup = $Computer.Create("group",$LocalGroupName)
    $LocalGroup.setinfo()
    $LocalGroup.description = $Description
    $Localgroup.SetInfo()
Write-Host "$LocalGroupName local group created" -ForegroundColor "Green"
}
Write-Host "Adding $StoreFrontServers to $LocalGroupName local group" -ForegroundColor "Yellow"

foreach ($StoreFrontServer in $StoreFrontServers)
{
    $Group = [ADSI]"WinNT://$env:ComputerName/$LocalGroupName,group"
    $Computer = [ADSI]"WinNT://$Domain/$StoreFrontServer$"
    $Group.Add($Computer.Path)
}
Write-Host "$StoreFrontServers added to $LocalGroupName" -ForegroundColor "Green"
}
Add-RemoteSTFMachineAccounts -Domain "example" -StoreFrontServers @("StoreFrontSQL1","StoreFrontSQL2")

Configurer le schéma de la base de données d’abonnement dans Microsoft SQL Server pour chaque magasin

Créez une instance nommée sur votre serveur Microsoft SQL à utiliser par StoreFront. Définissez le chemin dans le script .SQL pour qu’il corresponde à l’emplacement où votre version de SQL est installée ou à l’emplacement de stockage de ses fichiers de base de données. Le script d’exemple Create-StoreSubscriptionsDB-2016.sql utilise SQL Server 2016 Enterprise.

Créez une base de données vide à l’aide de SQL Server Management Studio (SSMS) en cliquant avec le bouton droit sur Bases de données, puis en sélectionnant Nouvelle base de données.

Saisissez un Nom de la base de données correspondant à votre magasin, ou choisissez un nom différent tel que STFSubscriptions.

Avant d’exécuter le script, pour chaque magasin de votre déploiement StoreFront, modifiez les références dans le script d’exemple pour qu’elles correspondent à vos déploiements StoreFront et SQL. Par exemple, modifiez :

• Nommez chaque base de données que vous créez pour qu’elle corresponde au nom du magasin dans StoreFront dans USE [STFSubscriptions].

• Définissez le chemin d’accès aux fichiers .mdf et .ldf de la base de données à l’emplacement où vous souhaitez stocker la base de données.

  C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.mdf

  C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.ldf

• Définissez la référence au nom de votre serveur SQL dans le script :

  CREATE LOGIN [SQL2016\StoreFrontServers] FROM WINDOWS;

  ALTER LOGIN [SQL2016\StoreFrontServers]

Exécutez le script. Après la configuration réussie du schéma, trois tables de base de données sont créées : SchemaDetails, Subscription et User.

Le diagramme de base de données suivant montre le schéma de la base de données d’abonnements créé par le script Create-StoreSubscriptionsDB-2016.sql :

Configurer la chaîne de connexion SQL Server pour chaque magasin StoreFront

Scénario 1

Conseil :

Les données d’abonnement d’origine stockées sur le disque dans la base de données ESENT ne sont ni détruites ni supprimées. Si vous décidez de revenir de Microsoft SQL Server à l’utilisation d’ESENT, il est possible de supprimer la chaîne de connexion du magasin et de simplement revenir à l’utilisation des données d’origine. Tous les abonnements supplémentaires créés pendant que SQL était utilisé pour le magasin n’existeront pas dans ESENT et les utilisateurs ne verront pas ces nouveaux enregistrements d’abonnement. Tous les enregistrements d’abonnement d’origine seront toujours présents.

Pour réactiver les abonnements ESENT sur un magasin

Ouvrez PowerShell ISE et sélectionnez Exécuter en tant qu’administrateur.

Utilisez l’option -UseLocalStorage pour spécifier le magasin sur lequel vous souhaitez réactiver les abonnements ESENT :

$SiteID = 1
$StoreVirtualPath = "/Citrix/Store1"

# Sets SQL DB Connection String
$StoreObject = Get-STFStoreService -SiteID $SiteID -VirtualPath $StoreVirtualPath

# Removes the SQL DB Connection string and reverts back to using ESENT
Set-STFStoreSubscriptionsDatabase -StoreService $StoreObject -UseLocalStorage
Get-STFStoreSubscriptionsDatabase -StoreService $StoreObject

Scénarios 2, 3 et 4

Ouvrez PowerShell ISE et sélectionnez Exécuter en tant qu’administrateur.

Spécifiez le magasin pour lequel vous souhaitez définir une chaîne de connexion à l’aide de $StoreVirtualPath

$SiteID = 1
$VirtualPath= "/Citrix/Store1"
$DBName = "Store1"
$DBServer = "SQL2016Ent"
$DBLocalServer = "localhost"
$SQLInstance = "StoreFrontInstance"

# For a remote database instance
$ConnectionString = "Server=$DBServer\$SQLInstance;Database=$DBName;Trusted_Connection=True;"

OU

# For a locally installed database instance
$ConnectionString = "$DBLocalServer\$SQLInstance;Database=$DBName;Trusted_Connection=True;"

# Sets SQL DB Connection String
$StoreObject = Get-STFStoreService -SiteID $SiteID -VirtualPath "/Citrix/Store"
Set-STFStoreSubscriptionsDatabase -StoreService $StoreObject -ConnectionString $ConnectionString
Get-STFStoreSubscriptionsDatabase -StoreService $StoreObject

Répétez le processus pour chaque magasin de votre déploiement si vous souhaitez tous les configurer pour utiliser une chaîne de connexion SQL.

Migrer les données existantes d’ESENT vers Microsoft SQL Server

Pour migrer vos données ESENT existantes vers SQL, un processus de transformation de données en deux étapes est nécessaire. Deux scripts sont fournis pour vous aider à effectuer cette opération unique. Si la chaîne de connexion dans StoreFront et l’instance SQL sont correctement configurées, toutes les nouvelles souscriptions sont créées automatiquement dans SQL au format correct. Après la migration, les données d’abonnement ESENT historiques sont transformées au format SQL et les utilisateurs peuvent également voir leurs ressources précédemment souscrites.

Exemple : quatre abonnements SQL pour le même utilisateur de domaine

Étape 1 Utilisez le script Transform-SubscriptionDataForStore.ps1 pour convertir les données ESENT dans un format compatible SQL pour l’importation en masse

Connectez-vous au serveur StoreFront à partir duquel vous souhaitez transformer les données ESENT.

Tout membre d’un groupe de serveurs convient, à condition qu’ils contiennent tous le même nombre d’enregistrements d’abonnement.

Ouvrez PowerShell ISE et sélectionnez Exécuter en tant qu’administrateur.

Exécutez le script Transform-SubscriptionDataForStore.ps1 qui exporte un fichier <StoreName>.txt de la base de données ESENT vers le bureau de l’utilisateur actuel.

Le script PowerShell fournit un retour d’information détaillé sur chaque ligne d’abonnement traitée pour faciliter le débogage et vous aider à évaluer le succès de l’opération. Le traitement peut prendre beaucoup de temps.

Les données transformées sont écrites dans <StoreName>SQL.txt sur le bureau de l’utilisateur actuel une fois le script terminé. Le script résume le nombre d’enregistrements d’utilisateurs uniques et le nombre total d’abonnements traités.

Répétez ce processus pour chaque magasin que vous souhaitez migrer vers le serveur SQL.

Étape 2 Utilisez une procédure stockée T-SQL pour importer en masse les données transformées dans SQL

Les données de chaque magasin doivent être importées un magasin à la fois.

Copiez le fichier <StoreName>SQL.txt créé à l’étape 1 du bureau du serveur StoreFront vers C:\ sur le serveur Microsoft SQL et renommez-le en SubscriptionsSQL.txt.

Le script Create-ImportSubscriptionDataSP.sql crée une procédure stockée T-SQL pour importer en masse les données d’abonnement. Il supprime les entrées en double pour chaque utilisateur unique afin que les données SQL résultantes soient correctement normalisées et réparties dans les tables appropriées.

Avant d’exécuter Create-ImportSubscriptionDataSP.sql, modifiez USE [STFSubscriptions] pour qu’il corresponde à la base de données sous laquelle vous souhaitez créer la procédure stockée.

Ouvrez le fichier Create-ImportSubscriptionDataSP.sql à l’aide de SQL Server Management Studio et exécutez le code qu’il contient. Ce script ajoute la procédure stockée ImportSubscriptionDataSP à la base de données que vous avez créée précédemment.

Après la création réussie de la procédure stockée, le message suivant s’affiche dans la console SQL, et la procédure stockée ImportSubscriptionDataSP est ajoutée à la base de données :

Commands completed successfully.

Exécutez la procédure stockée en cliquant dessus avec le bouton droit, puis sélectionnez Exécuter la procédure stockée, et cliquez sur OK.

Une valeur de retour de 0 indique que toutes les données ont été importées avec succès. Tout problème lors de l’importation est enregistré dans la console SQL. Une fois la procédure stockée exécutée avec succès, comparez le nombre total d’enregistrements d’abonnement et d’utilisateurs uniques fournis par Transform-SubscriptionDataForStore.ps1 avec le résultat des deux requêtes SQL ci-dessous. Les deux totaux doivent correspondre.

Le nombre total d’abonnements du script de transformation doit correspondre au nombre total rapporté par SQL via

SELECT COUNT(*) AS TotalSubscriptions
FROM [Subscription]

Le nombre d’utilisations uniques du script de transformation doit correspondre au nombre d’enregistrements dans la table User rapporté par SQL via

SELECT COUNT(*) AS TotalUsers
FROM [User]

Si le script de transformation affiche 100 utilisateurs uniques et 1000 enregistrements d’abonnement totaux, alors SQL doit afficher les mêmes deux nombres après une migration réussie.

Connectez-vous à StoreFront pour vérifier si les utilisateurs existants peuvent voir leurs données d’abonnement. Les enregistrements d’abonnement existants sont mis à jour dans SQL lorsque les utilisateurs s’abonnent ou se désabonnent de leurs ressources. De nouveaux utilisateurs et enregistrements d’abonnement sont également créés dans SQL.

Étape 3 Exécutez des requêtes T-SQL sur vos données importées

Remarque :

Tous les noms de Delivery Controller sont sensibles à la casse et doivent correspondre exactement à la casse et au nom utilisés dans StoreFront.

-- Obtenir tous les enregistrements d'abonnement SQL
Use [STFSubscriptions]
SELECT * FROM [Subscription]
SELECT * FROM [User]

-- Obtenir tous les enregistrements d'abonnement pour un SID utilisateur particulier
Use [STFSubscriptions]
SELECT * FROM [Subscription]
INNER JOIN [User]
ON [Subscription].[user_id] = [User].[id]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'

-- Obtenir le nombre total d'enregistrements d'abonnement pour un SID utilisateur particulier
Use [STFSubscriptions]
SELECT COUNT(Subscription.id)
FROM [Subscription]
INNER JOIN [User]
ON [Subscription].[user_id] = [User].[id]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'

-- Obtenir tous les enregistrements d'abonnement pour un Delivery Controller particulier
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'

-- OU pour les ressources agrégées, utilisez le nom du groupe d'agrégation
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'

-- Obtenir tous les enregistrements d'abonnement pour une application particulière
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] = ' DeliveryController.Application'

Mettre à jour ou supprimer des enregistrements d’abonnement existants à l’aide de T-SQL

AVERTISSEMENT :

Toutes les instructions d’exemple de mise à jour et de suppression SQL sont utilisées entièrement à vos propres risques. Citrix n’est pas responsable de toute perte ou altération accidentelle de vos données d’abonnement due à une utilisation incorrecte des exemples fournis. Les instructions T-SQL suivantes sont fournies à titre indicatif pour permettre des mises à jour simples. Sauvegardez toutes les données d’abonnement dans des sauvegardes complètes de la base de données SQL avant de tenter de mettre à jour vos abonnements ou de supprimer des enregistrements obsolètes. Le non-respect des sauvegardes nécessaires peut entraîner une perte ou une corruption de données. Avant d’exécuter vos propres instructions T-SQL UPDATE ou DELETE sur la base de données de production, testez-les sur des données factices ou sur une copie redondante des données de production, loin de la base de données de production en direct.

Remarque :

Tous les noms de Delivery Controller sont sensibles à la casse et doivent correspondre exactement à la casse et au nom utilisés dans StoreFront.

-- Mettre à jour le Delivery Controller utilisé dans tous les abonnements.
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','NewDeliveryController.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'

-- Après avoir activé l'agrégation multi-site, mettez à jour le resource_id
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','DefaultAggregationGroup.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'

-- Supprimer tous les enregistrements d'abonnement pour un Delivery Controller particulier
Use [STFSubscriptions]
DELETE FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'

-- OU pour les ressources agrégées, utilisez le nom du groupe d'agrégation
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'

-- Supprimer tous les enregistrements d'abonnement pour une application particulière
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE '%.Application'

-- Supprimer tous les enregistrements d'abonnement pour une application publiée via un Delivery Controller spécifique
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] = 'DeliveryController.Application'

-- Supprimer tous les enregistrements d'abonnement pour un SID utilisateur particulier
-- s'appuie sur la cascade pour supprimer les enregistrements de [Subscription]
Use [STFSubscriptions]
DELETE FROM [User]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'

-- Supprimer TOUTES les données d'abonnement d'une base de données particulière et réinitialiser l'index clusterisé de la clé primaire pour qu'il commence la numérotation à partir de 0.
-- À UTILISER AVEC UNE EXTRÊME PRUDENCE ET NON SUR DES BASES DE DONNÉES DE PRODUCTION EN DIRECT.
-- Peut être utile lors du débogage des problèmes d'importation de données pour commencer avec une base de données propre.

Use [STFSubscriptions]
DELETE FROM [Subscription]
DBCC CHECKIDENT ([Subscription], RESEED, 0)
DELETE FROM [User]
DBCC CHECKIDENT ([User], RESEED, 0)

```