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 passer de StoreFront à SQL au lieu d’ESENT est que vous pouvez facilement utiliser des instructions de mise à jour SQL pour 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 l’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.

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, qu’elles utilisent 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 des 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 une base de données ESENT ou 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 maintient 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, telles que 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, telles que 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 d’entreprise de grande envergure.

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 d’entreprise de grande envergure 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, telles que 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 dans ESENT en 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 nommé <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 "AppPools ajoutés au groupe local $LocalGroupName" -ForegroundColor "Green"
<!--NeedCopy-->

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.

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. 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’abonnements dans SQL.

Ajoutez tous les comptes d’ordinateur de domaine du groupe de serveurs StoreFront au groupe \<SQLServer\>\StoreFrontServers. Seuls les comptes d’ordinateur de domaine des serveurs 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, crée le groupe de sécurité local et y ajoute deux serveurs StoreFront nommés StoreFrontSQL1 et StoreFrontSQL2.

function Add-RemoteSTFMachineAccounts
{
[CmdletBinding()]
param([Parameter(Mandatory=$True)][string]$Domain,
[Parameter(Mandatory=$True)][array]$StoreFrontServers)

# Créer un groupe local pour les serveurs StoreFront sur le serveur de base de données
$LocalGroupName = "StoreFrontServers"
$Description = "Contient les comptes d'ordinateur de serveur StoreFront ou les comptes virtuels AppPool StoreFront"

# Vérifier si le groupe de sécurité local existe déjà
if ([ADSI]::Exists("WinNT://$env:ComputerName/$LocalGroupName"))
{
    Write-Host "$LocalGroupName existe déjà !" -ForegroundColor "Yellow"
}
else
{
    Write-Host "Création du groupe local $LocalGroupName" -ForegroundColor "Yellow"

    # Créer un groupe de sécurité local
    $Computer = [ADSI]"WinNT://$env:ComputerName,Computer"
    $LocalGroup = $Computer.Create("group",$LocalGroupName)
    $LocalGroup.setinfo()
    $LocalGroup.description = $Description
    $Localgroup.SetInfo()
Write-Host "$LocalGroupName groupe local créé" -ForegroundColor "Green"
}
Write-Host "Ajout de $StoreFrontServers au groupe local $LocalGroupName" -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 ajouté à $LocalGroupName" -ForegroundColor "Green"
}
Add-RemoteSFAccounts -Domain "example" -StoreFrontServers @("StoreFrontSQL1","StoreFrontSQL2")
<!--NeedCopy-->

Configurer le schéma de la base de données d’abonnements 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 où ses fichiers de base de données sont stockés. 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 que le script Create-StoreSubscriptionsDB-2016.sql crée :

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’abonnements d’origine seront toujours présents.

Pour réactiver les abonnements ESENT sur un magasin

Ouvrez l’ISE PowerShell 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"

# Définit la chaîne de connexion de la base de données SQL
$StoreObject = Get-STFStoreService -SiteID $SiteID -VirtualPath $StoreVirtualPath

# Supprime la chaîne de connexion de la base de données SQL et revient à l'utilisation d'ESENT
Set-STFStoreSubscriptionsDatabase -StoreService $StoreObject -UseLocalStorage
Get-STFStoreSubscriptionsDatabase -StoreService $StoreObject
<!--NeedCopy-->

Scénarios 2, 3 et 4

Ouvrez l’ISE PowerShell 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"

# Pour une instance de base de données distante
$ConnectionString = "Server=$DBServer\$SQLInstance;Database=$DBName;Trusted_Connection=True;"
<!--NeedCopy-->

OU

# Pour une instance de base de données installée localement
$ConnectionString = "$DBLocalServer\$SQLInstance;Database=$DBName;Trusted_Connection=True;"

# Définit la chaîne de connexion de la base de données SQL
$StoreObject = Get-STFStoreService -SiteID $SiteID -VirtualPath "/Citrix/Store"
Set-STFStoreSubscriptionsDatabase -StoreService $StoreObject -ConnectionString $ConnectionString
Get-STFStoreSubscriptionsDatabase -StoreService $StoreObject
<!--NeedCopy-->

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 historiques de souscription ESENT sont transformées au format SQL et les utilisateurs peuvent également voir leurs ressources précédemment souscrites.

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

Étape 1 : Utiliser 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 de souscription.

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 de souscription 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 de souscriptions traitées.

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

Étape 2 : Utiliser 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 de souscription. 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 d’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 de souscription 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 de souscriptions du script de transformation doit correspondre au nombre total rapporté par SQL via

SELECT COUNT(*) AS TotalSubscriptions
FROM [Subscription]
<!--NeedCopy-->

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]
<!--NeedCopy-->

Si le script de transformation affiche 100 utilisateurs uniques et 1000 enregistrements de souscription au total, 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 de souscription. Les enregistrements de souscription existants sont mis à jour dans SQL lorsque les utilisateurs souscrivent ou se désabonnent de leurs ressources. De nouveaux utilisateurs et enregistrements de souscription sont également créés dans SQL.

Étape 3 : Exécuter 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.

-- Get all SQL subscription records
Use [STFSubscriptions]
SELECT * FROM [Subscription]
SELECT * FROM [User]
<!--NeedCopy-->

-- Get all subscription records for a particular user SID
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'

-- Get total number of Subscription records for a particular user SID
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'
<!--NeedCopy-->

-- Get all subscription records for a particular delivery controller
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'

-- OR for aggregated resources use the name of the aggregation group
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'

-- Get all subscription records for a particular application
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] = ' DeliveryController.Application'
<!--NeedCopy-->

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

AVERTISSEMENT :

Toutes les instructions SQL d’exemple de mise à jour et de suppression sont utilisées entièrement à vos propres risques. Citrix n’est pas responsable de toute perte ou altération accidentelle de vos données de souscription due à une utilisation incorrecte des exemples fournis. Les instructions T-SQL suivantes sont fournies à titre indicatif pour permettre d’effectuer des mises à jour simples. Sauvegardez toutes les données de souscription dans des sauvegardes complètes de la base de données SQL avant de tenter de mettre à jour vos souscriptions ou de supprimer des enregistrements obsolètes. Le non-respect des sauvegardes nécessaires peut entraîner une perte ou une corruption des 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 site sont sensibles à la casse et doivent correspondre exactement à la casse et au nom utilisés dans StoreFront.

-- Update the site name used in all subscriptions.
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldSiteName.','NewSiteName.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'
<!--NeedCopy-->

-- After enabling multi-site aggregation, update the resource_id
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','DefaultAggregationGroup.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'
<!--NeedCopy-->

-- Delete all subscription records for a particular site
Use [STFSubscriptions]
DELETE FROM [Subscription]
WHERE [resource_id] LIKE 'site.%'
<!--NeedCopy-->

-- OR for aggregated resources use the name of the aggregation group
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'
<!--NeedCopy-->

-- Delete all subscription records for a particular application
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE '%.Application'
<!--NeedCopy-->

-- Delete all subscription records for an application published via a specific site
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] = 'Site.Application'
<!--NeedCopy-->

-- Delete all subscription records for a particular user SID
-- relies on cascade to delete records from [Subscription]
Use [STFSubscriptions]
DELETE FROM [User]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'
<!--NeedCopy-->

-- Delete ALL subscription data from a particular database and reset the primary key clustered index to start numbering from 0.
-- USE WITH EXTREME CARE AND NOT ON LIVE PRODUCTION DATABASES.
-- Can be useful whilst debugging data import issues to start with a clean database.

Use [STFSubscriptions]
DELETE FROM [Subscription]
DBCC CHECKIDENT ([Subscription], RESEED, 0)
DELETE FROM [User]
DBCC CHECKIDENT ([User], RESEED, 0)
<!--NeedCopy-->