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

Remarque :

Ce document part du principe que vous disposez d’une connaissance de base des requêtes MS SQL Server et T-SQL. Les administrateurs doivent savoir comment configurer, utiliser et gérer SQL Server avant de tenter de suivre ce document.

Introduction

ESENT est un moteur de base de données transactionnel intégré 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 d’utiliser StoreFront avec SQL au lieu d’ESENT est que les instructions de mise à jour T-SQL vous permettent de gérer, de modifier ou de 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 à ces données.

Pour migrer les données d’abonnement existantes ESENT vers Microsoft SQL Server, les données ESENT plates exportées depuis StoreFront doivent être converties en un format SQL convivial pour une importation en bloc. Pour les nouveaux déploiements sans nouvelles données d’abonnement, cette étape n’est pas requise. L’étape de transformation des données n’est nécessaire 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 -STF PowerShell 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 entraînent uniquement une expérience utilisateur temporairement dégradée ; les utilisateurs ne peuvent pas ajouter, supprimer ou afficher leurs ressources préférées tant que la connexion à l’instance SQL Server n’est pas restaurée. 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 la chaîne KEYWORDS:Auto ou KEYWORDS:Mandatory se comportent de la même manière lorsque vous utilisez ESENT ou SQL. Les nouveaux enregistrements d’abonnement SQL sont créés automatiquement lorsqu’un utilisateur ouvre une session pour la première fois si l’une des chaînes KEYWORD est inclue dans les ressources de l’utilisateur.

Avantages de ESENT et SQL Server

Inconvénients de ESENT et 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 de Microsoft SQL Server afin de réduire la complexité de 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 différents Delivery Controller. 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. Cependant, cette méthode n’est pas recommandée en raison de la complexité accrue de gestion et la possibilité d’une mauvaise configuration.

Vous pouvez utiliser quatre scénarios pour stocker des 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 ; celle-ci est synchronisée avec tous les autres membres du groupe de serveurs. Ce scénario ne nécessite aucune étape supplémentaire de configuration. Ce scénario convient à la plupart des clients qui ne s’attendent pas à des modifications fréquentes des noms de Delivery Controller 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 locale de Microsoft SQL Server 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 simple de StoreFront où les clients peuvent avoir besoin de modifier fréquemment les noms de Delivery Controller 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. Cependant, dans ce scénario, les clients n’ont pas besoin d’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 taille.

Scénario 3 – Groupe de serveurs StoreFront et instance Microsoft SQL Server dédiée configurés pour une 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. Il s’agit du modèle le plus approprié pour les déploiements de grande taille où les administrateurs Citrix souhaitent modifier fréquemment les noms de Delivery Controller 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, tout en nécessitant une haute disponibilité.

Scénario 4 – Plusieurs groupes de serveurs StoreFront et instance Microsoft SQL Server dédiée dans chaque data center par groupe de serveurs

Remarque :

Il s’agit d’une configuration avancée. Utilisez ce scénario uniquement si vous êtes un administrateur SQL Server expérimenté connaissant bien la réplication des transactions et que vous disposez des compétences nécessaires pour déployer cette configuration.

Il s’agit de la même configuration que le scénario 3, mais ce scénario s’applique également aux situations où plusieurs groupes de serveurs StoreFront sont requis dans différents data centers distants. Les administrateurs Citrix peuvent choisir de synchroniser les données d’abonnement entre différents groupes de serveurs dans le même data center ou dans des data centers 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 s’appuie entièrement sur la technologie Microsoft SQL pour répliquer les données d’abonnement et les transactions SQL.

Ressources

Vous pouvez télécharger les scripts suivants à partir de 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écutez ce script 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écutez ce script pour le scénario 2 sur l’instance SQL Server.

• 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écutez ce script pour le scénario 3 sur l’instance SQL Server.

• Create-StoreSubscriptionsDB-2016.sql : crée la base de données et le schéma SQL. Exécutez ce script sur l’instance SQL Server.

Scripts de transformation et d’importation de données

• Transform-SubscriptionDataForStore.ps1 : exporte et convertit les données d’abonnement existantes dans ESENT en un format SQL convivial pour l’importation.

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

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

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

Créez un groupe de sécurité local appelé <SQLServer>\StoreFrontServers sur Microsoft SQL Server et ajoutez les comptes virtuels pour IIS APPPOOL\DefaultAppPool et IIS APPPOOL\Citrix Receiver for Web pour accorder au serveur StoreFront installé localement un accès en lecture et en écriture à SQL. Ce groupe de sécurité est référencé dans le script .SQL qui crée le schéma de base de données d’abonnement au magasin. Assurez-vous donc que les noms de groupe correspondent.

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é de 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 en installant le 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)

Write-Host "AppPools added to $LocalGroupName local group" -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 entre les processus entre StoreFront et SQL Server.

Vérifiez que les règles de 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 est résolu correctement sur l’adresse IPv4. Windows peut essayer d’utiliser IPv6 au lieu d’IPv4, et la résolution DNS de localhost peut renvoyer ::1 au lieu de l’adresse IPv4 correcte de StoreFront et de 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 Microsoft SQL Server dédiée

Créez un groupe de sécurité local appelé <SQLServer>\StoreFrontServers sur l’instance Microsoft SQL Server et ajoutez 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 base de données d’abonnement dans SQL.

Ajoutez tous les comptes d’ordinateurs de domaine de groupe de serveurs StoreFront au groupe <SQLServer>\StoreFrontServers. Seuls les comptes d’ordinateurs de domaine du serveur StoreFront répertoriés dans le groupe peuvent accéder en lecture et en écriture aux 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)

# 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")
<!--NeedCopy-->

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

Créez une instance nommée sur votre instance Microsoft SQL Server à utiliser par StoreFront. Définissez le chemin d’accès dans le script .SQL pour qu’il corresponde à l’emplacement où votre version de SQL est installée ou l’emplacement où les fichiers de base de données sont stockés. L’exemple de script 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 de la souris sur Bases de données, puis en sélectionnant Nouvelle base de données.

Tapez un nom de base de données correspondant à votre magasin ou choisissez un autre nom, tel que STFSubscriptions.

Avant d’exécuter le script, pour chaque magasin de votre déploiement StoreFront, modifiez les références de l’exemple de script 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 sur 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 sur le nom de votre instance SQL Server dans le script :

  CREATE LOGIN [SQL2016\StoreFrontServers] FROM WINDOWS;

  ALTER LOGIN [SQL2016\StoreFrontServers]

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

Le diagramme suivant montre le schéma de base de données d’abonnement 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 d’utiliser ESENT au lieu de Microsoft SQL Server, il est possible de supprimer la chaîne de connexion du magasin et de revenir simplement à l’utilisation des données d’origine. Tous les abonnements supplémentaires qui ont été créés pendant l’utilisation de SQL 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.

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

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 pour l’utilisation 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;"
<!--NeedCopy-->

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
<!--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 des données existantes depuis ESENT vers Microsoft SQL Server

Pour migrer vos données ESENT existantes vers SQL, vous devez utiliser un processus de transformation des données en deux étapes. Deux scripts sont fournis pour vous aider à effectuer cette opération ponctuelle. Si la chaîne de connexion dans StoreFront et l’instance SQL sont correctement configurées, tous les nouveaux abonnements sont créés automatiquement dans SQL au format correct. Après la migration, les données d’abonnement ESENT historiques sont converties en format SQL et les utilisateurs peuvent également afficher les ressources auxquelles ils sont déjà abonnés.

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

Étape 1 – Utiliser le script Transform-SubscriptionDataForStore.ps1 pour convertir les données ESENT en un format SQL convivial pour l’importation en bloc

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

Cette opération est possible pour tous les membres d’un groupe de serveurs à 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 depuis la base de données ESENT vers le bureau de l’utilisateur actuel.

Le script PowerShell fournit des commentaires détaillés sur chaque ligne d’abonnement traitée pour faciliter le débogage et vous aider à évaluer la réussite de l’opération. Le script peut prendre du temps.

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

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

Étape 2 – Utiliser une procédure stockée T-SQL pour importer en bloc les données converties 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 à partir du bureau du serveur StoreFront C:\ sur l’instance Microsoft SQL Server et renommez-le SubscriptionsSQL.txt.

Le script Create-ImportSubscriptionDataSP.sql crée une procédure stockée T-SQL afin d’importer en bloc 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 divisées en tables correctes.

Avant d’exécuter Create-ImportSubscriptionDataSP.sql, modifiez USE [STFSubscriptions] pour que cet élément 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 qui s’y trouve. 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.

Pour exécuter la procédure stockée, cliquez dessus avec le bouton droit de la souris, sélectionnez Exécuter la procédure stockée, puis cliquez sur OK.

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

Le nombre total d’abonnements fourni par le script de transformation doit correspondre au nombre total signalé par SQL :

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

Le nombre d’utilisateurs uniques fourni par le script de transformation doit correspondre au nombre d’enregistrements de la table User signalé par SQL :

SELECT COUNT(*) AS TotalUsers
FROM [User]
<!--NeedCopy-->

Si le script de transformation affiche 100 utilisateurs uniques et 1 000 enregistrements d’abonnement, SQL doit afficher les mêmes chiffres une fois la migration effectuée.

Connectez-vous à StoreFront pour vérifier si les utilisateurs existants peuvent afficher leurs données d’abonnement. Les enregistrements d’abonnement existants sont mis à jour dans SQL lorsque les utilisateurs abonnent ou désabonnent leurs ressources. De nouveaux utilisateurs et enregistrements d’abonnement 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 aux noms 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 d’abonnement existants à l’aide de T-SQL

Clause d’exclusion de responsabilité :

Tous les exemples d’instructions SQL de mise à jour et de suppression sont utilisés entièrement à vos propres risques. Citrix n’est pas responsable de toute perte ou altération accidentelle de vos données d’abonnement par une utilisation incorrecte des exemples fournis. Les instructions T-SQL suivantes sont fournies à titre indicatif pour permettre l’exécution de mises à jour simples. Sauvegardez toutes les données d’abonnement dans les sauvegardes complètes de base de données SQL avant de tenter de mettre à jour vos abonnements ou de supprimer des enregistrements obsolètes. Si vous n’effectuez pas les sauvegardes nécessaires, vous risquez de perdre ou de corrompre les données. Avant d’exécuter vos propres instructions T-SQL de mise à jour (UPDATE) ou de suppression (DELETE) sur la base de données de production, testez-les sur des données fictives ou sur une copie redondante des données de production à l’extérieur de la base de données de production active.

Remarque :

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

-- Update the delivery controller used in all subscriptions.
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','NewDeliveryController.')
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 Delivery Controller
Use [STFSubscriptions]
DELETE FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'
<!--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 delivery controller
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] = 'DeliveryController.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-->