Almacenar datos de suscripción mediante Microsoft SQL Server

Nota:

Este documento asume conocimientos básicos de MS SQL Server y consultas T-SQL. Los administradores deben sentirse cómodos configurando, usando y administrando SQL Server antes de intentar seguir este documento.

Introducción

ESENT es un motor de base de datos transaccional incrustable que Windows puede usar. Todas las versiones de StoreFront admiten el uso de una base de datos ESENT integrada de forma predeterminada. También pueden conectarse a una instancia de Microsoft SQL Server si el almacén está configurado para usar una cadena de conexión SQL.

La principal ventaja de cambiar StoreFront para usar SQL en lugar de ESENT es que las instrucciones de actualización T-SQL te permiten administrar, modificar o eliminar registros de suscripción. Si usas SQL, no necesitas exportar, modificar y volver a importar todos los datos de suscripción de ESENT cada vez que se realizan cambios menores en los datos de suscripción.

Para migrar los datos de suscripción existentes de ESENT a Microsoft SQL Server, los datos planos de ESENT exportados de StoreFront deben transformarse a un formato compatible con SQL para la importación masiva. Para nuevas implementaciones sin datos de suscripción nuevos, este paso no es necesario. El paso de transformación de datos solo se necesita una vez. Este artículo describe la configuración compatible que se puede usar en todas las versiones de StoreFront a partir de la versión 3.5, que introdujo el SDK de PowerShell -STF al que se hace referencia en el artículo.

Nota:

Los fallos de conexión a la instancia de SQL Server utilizada por StoreFront para almacenar los datos de suscripción debido a interrupciones de red no hacen que la implementación de StoreFront sea inutilizable. Las interrupciones solo resultan en una experiencia de usuario temporalmente degradada; los usuarios no pueden agregar, quitar o ver recursos favoritos hasta que se restablezca la conexión a SQL Server. Los recursos aún se pueden enumerar e iniciar durante la interrupción. El comportamiento esperado es el mismo que si el servicio Citrix Subscription Store se detuviera mientras se usa ESENT.

Sugerencia:

Los recursos configurados con KEYWORDS:Auto o KEYWORDS:Mandatory se comportan de la misma manera al usar ESENT o SQL. Se crean automáticamente nuevos registros de suscripción SQL cuando un usuario inicia sesión por primera vez si se incluye cualquiera de las KEYWORDS en los recursos del usuario.

Ventajas de ESENT y SQL Server

Desventajas de ESENT y SQL Server

Escenarios de implementación

Nota:

Cada almacén configurado dentro de StoreFront requiere una base de datos ESENT o una base de datos de Microsoft SQL si quieres admitir suscripciones de usuario. El método de almacenamiento de los datos de suscripción se establece a nivel de almacén dentro de StoreFront.

Citrix® recomienda que todas las bases de datos de almacén residan en la misma instancia de Microsoft SQL Server para reducir la complejidad de la administración y el alcance de la configuración incorrecta.

Múltiples almacenes pueden compartir la misma base de datos, siempre que todos estén configurados para usar la misma cadena de conexión idéntica. No importa si usan diferentes Delivery Controllers. La desventaja de que múltiples almacenes compartan una base de datos es que no hay forma de saber a qué almacén corresponde cada registro de suscripción.

Una combinación de los dos métodos de almacenamiento de datos es técnicamente posible en una única implementación de StoreFront con múltiples almacenes. Es posible configurar un almacén para usar ESENT y otro para usar SQL. Esto no se recomienda debido a la mayor complejidad de la administración y el alcance de la configuración incorrecta.

Hay cuatro escenarios que puedes usar para almacenar datos de suscripción en SQL Server:

Escenario 1: Servidor o grupo de servidores StoreFront único usando ESENT (predeterminado)

De forma predeterminada, todas las versiones de StoreFront desde la versión 2.0 usan una base de datos ESENT plana para almacenar y replicar datos de suscripción entre los miembros de un grupo de servidores. Cada miembro del grupo de servidores mantiene una copia idéntica de la base de datos de suscripciones, que se sincroniza con todos los demás miembros del grupo de servidores. Este escenario no requiere pasos adicionales para configurarse. Este escenario es adecuado para la mayoría de los clientes que no esperan cambios frecuentes en los nombres de los Delivery Controllers o no necesitan realizar tareas de administración frecuentes en sus datos de suscripción, como eliminar o actualizar suscripciones de usuario antiguas.

Escenario 2: Servidor StoreFront único y una instancia local de Microsoft SQL Server instalada

StoreFront usa una instancia de SQL Server instalada localmente y ambos componentes residen en el mismo servidor. Este escenario es adecuado para una implementación sencilla de StoreFront único donde los clientes podrían necesitar realizar cambios frecuentes en los nombres de los Delivery Controllers, o necesitan realizar tareas de administración frecuentes en sus datos de suscripción, como eliminar o actualizar suscripciones de usuario antiguas, pero no requieren una implementación de StoreFront de alta disponibilidad. Citrix no recomienda este escenario para grupos de servidores porque crea un único punto de fallo en el miembro del grupo de servidores que aloja la instancia de base de datos de Microsoft SQL. Este escenario no es adecuado para grandes implementaciones empresariales.

Escenario 3: Grupo de servidores StoreFront y una instancia dedicada de Microsoft SQL Server configurada para alta disponibilidad (recomendado)

Todos los miembros del grupo de servidores StoreFront se conectan a la misma instancia dedicada de Microsoft SQL Server o clúster de conmutación por error de SQL. Este es el modelo más adecuado para grandes implementaciones empresariales donde los administradores de Citrix quieren realizar cambios frecuentes en los nombres de los Delivery Controllers o quieren realizar tareas de administración frecuentes en sus datos de suscripción, como eliminar o actualizar suscripciones de usuario antiguas, y requieren alta disponibilidad.

Escenario 4: Múltiples grupos de servidores StoreFront y una instancia dedicada de Microsoft SQL Server en cada centro de datos por grupo de servidores

Nota:

Esta es una configuración avanzada. Solo intenta realizarla si eres un administrador experimentado de SQL Server familiarizado con la replicación transaccional y tienes las habilidades necesarias para implementarla con éxito.

Esto es lo mismo que el escenario 3, pero lo extiende a situaciones donde se requieren múltiples grupos de servidores StoreFront en diferentes centros de datos remotos. Los administradores de Citrix pueden optar por sincronizar los datos de suscripción entre diferentes grupos de servidores en el mismo o diferentes centros de datos. Cada grupo de servidores en el centro de datos se conecta a su propia instancia dedicada de Microsoft SQL Server para redundancia, conmutación por error y rendimiento. Este escenario requiere una configuración e infraestructura de Microsoft SQL Server considerablemente adicionales. Se basa completamente en la tecnología de Microsoft SQL para replicar los datos de suscripción y sus transacciones SQL.

Recursos

Puedes descargar los siguientes scripts desde https://github.com/citrix/sample-scripts/tree/master/storefront para ayudarte:

Scripts de configuración

• Set-STFDatabase.ps1 – establece la cadena de conexión de MS SQL para cada almacén. Ejecútalo en el servidor StoreFront.

• Add-LocalAppPoolAccounts.ps1 – otorga a los grupos de aplicaciones del servidor StoreFront local acceso de lectura y escritura a la base de datos SQL. Ejecútalo para el escenario 2 en el servidor SQL.

• Add-RemoteSFAccounts.ps1 – otorga a todos los servidores StoreFront de un grupo de servidores acceso de lectura y escritura a la base de datos SQL. Ejecútalo para el escenario 3 en el servidor SQL.

• Create-StoreSubscriptionsDB-2016.sql – crea la base de datos y el esquema SQL. Ejecútalo en el servidor SQL.

Scripts de transformación e importación de datos

• Transform-SubscriptionDataForStore.ps1 – exporta y transforma los datos de suscripción existentes dentro de ESENT a un formato compatible con SQL para su importación.

• Create-ImportSubscriptionDataSP.sql – crea un procedimiento almacenado para importar los datos transformados por Transform-SubscriptionDataForStore.ps1. Ejecuta este script una vez en el servidor SQL después de haber creado el esquema de la base de datos usando Create-StoreSubscriptionsDB-2016.sql.

Configurar el grupo de seguridad local del servidor StoreFront en el servidor SQL

Escenario 2: Servidor StoreFront único y una instancia local de Microsoft SQL Server instalada

Crea un grupo de seguridad local llamado <SQLServer>\StoreFrontServers en el servidor Microsoft SQL y agrega las cuentas virtuales para IIS APPPOOL\DefaultAppPool y IIS APPPOOL\Citrix Receiver for Web para permitir que el StoreFront instalado localmente lea y escriba en SQL. Este grupo de seguridad se referencia en el script .SQL que crea el esquema de la base de datos de suscripciones del almacén, así que asegúrate de que el nombre del grupo coincida.

Puedes descargar el script Add-LocalAppPoolAccounts.ps1 para ayudarte.

Instala StoreFront antes de ejecutar el script Add-LocalAppPoolAccounts.ps1. El script depende de la capacidad de localizar la cuenta virtual de IIS IIS APPPOOL\Citrix Receiver for Web, que no existe hasta que StoreFront se haya instalado y configurado. IIS APPPOOL\DefaultAppPool se crea automáticamente al instalar el rol de servidor web de 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 agregados al grupo local $LocalGroupName" -ForegroundColor "Green"

Habilita las canalizaciones con nombre en tu instancia local de SQL mediante el administrador de configuración de SQL Server. Las canalizaciones con nombre son necesarias para la comunicación entre procesos entre StoreFront y SQL Server.

Asegúrate de que las reglas del firewall de Windows estén configuradas correctamente para permitir las conexiones de SQL Server mediante un puerto específico o puertos dinámicos. Consulta la documentación de Microsoft para saber cómo hacerlo en tu entorno.

Sugerencia:

Los datos de suscripción originales almacenados en el disco en la base de datos ESENT no se destruyen ni se quitan. Si decides revertir de Microsoft SQL Server a usar ESENT, es posible quitar la cadena de conexión del almacén y simplemente volver a usar los datos originales. Cualquier suscripción adicional que se haya creado mientras SQL estaba en uso para el almacén no existirá en ESENT y los usuarios no verán estos nuevos registros de suscripción. Todos los registros de suscripción originales seguirán estando presentes.

Escenario 3: Grupo de servidores StoreFront y una instancia dedicada de Microsoft SQL Server

Crea un grupo de seguridad local llamado \<SQLServer>\StoreFrontServers\ en el servidor de Microsoft SQL y agrega todos los miembros del grupo de servidores StoreFront. Este grupo de seguridad se referencia más adelante en el script Create-StoreSubscriptionsDB-2016.sql que crea el esquema de la base de datos de suscripciones en SQL.

Agrega todas las cuentas de equipo de dominio del grupo de servidores StoreFront al grupo \<SQLServer>\StoreFrontServers\. Solo las cuentas de equipo de dominio del servidor StoreFront que figuran en el grupo podrán leer y escribir registros de suscripción en SQL si SQL Server utiliza la autenticación de Windows. La siguiente función de PowerShell, proporcionada en el script Add-RemoteSFAccounts.ps1, crea el grupo de seguridad local y le agrega dos servidores StoreFront llamados StoreFrontSQL1 y StoreFrontSQL2.

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

# Crea un grupo local para los servidores StoreFront en el servidor de base de datos
$LocalGroupName = "StoreFrontServers"
$Description = "Contiene cuentas de equipo de servidor StoreFront o cuentas virtuales de AppPool de StoreFront"

# Comprueba si el grupo de seguridad local ya existe
if ([ADSI]::Exists("WinNT://$env:ComputerName/$LocalGroupName"))
{
    Write-Host "$LocalGroupName ya existe." -ForegroundColor "Yellow"
}
else
{
    Write-Host "Creando el grupo local $LocalGroupName" -ForegroundColor "Yellow"

    # Crea un grupo de seguridad local
    $Computer = [ADSI]"WinNT://$env:ComputerName,Computer"
    $LocalGroup = $Computer.Create("group",$LocalGroupName)
    $LocalGroup.setinfo()
    $LocalGroup.description = $Description
    $Localgroup.SetInfo()
Write-Host "Grupo local $LocalGroupName creado" -ForegroundColor "Green"
}
Write-Host "Agregando $StoreFrontServers al grupo 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 agregados a $LocalGroupName" -ForegroundColor "Green"
}
Add-RemoteSTFMachineAccounts -Domain "example" -StoreFrontServers @("StoreFrontSQL1","StoreFrontSQL2")
<!--NeedCopy-->

Configura el esquema de la base de datos de suscripciones en Microsoft SQL Server para cada almacén

Crea una instancia con nombre en tu servidor de Microsoft SQL para que la use StoreFront. Establece la ruta dentro del script .SQL para que se corresponda con la ubicación donde está instalada tu versión de SQL o donde se almacenan sus archivos de base de datos. El script de ejemplo Create-StoreSubscriptionsDB-2016.sql utiliza SQL Server 2016 Enterprise.

Crea una base de datos vacía mediante SQL Server Management Studio (SSMS) haciendo clic con el botón derecho en Bases de datos y, a continuación, seleccionando Nueva base de datos.

Escribe un Nombre de base de datos para que coincida con tu almacén, o elige un nombre diferente, como STFSubscriptions.

Antes de ejecutar el script, para cada almacén de tu implementación de StoreFront, modifica las referencias en el script de ejemplo para que coincidan con tus implementaciones de StoreFront y SQL. Por ejemplo, modifica:

• Asigna un nombre a cada base de datos que crees para que coincida con el nombre del almacén en StoreFront en USE [STFSubscriptions].

• Establece la ruta a los archivos .mdf y .ldf de la base de datos donde quieras almacenar la base de datos.

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

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

• Establece la referencia al nombre de tu servidor SQL dentro del script:

  CREATE LOGIN [SQL2016\StoreFrontServers] FROM WINDOWS;

  ALTER LOGIN [SQL2016\StoreFrontServers]

Ejecuta el script. Después de configurar correctamente el esquema, se crean tres tablas de base de datos: SchemaDetails, Subscription y User.

El siguiente diagrama de base de datos muestra el esquema de la base de datos de suscripciones que crea el script Create-StoreSubscriptionsDB-2016.sql:

Configura la cadena de conexión de SQL Server para cada almacén de StoreFront

Escenario 1

Sugerencia:

Los datos de suscripción originales almacenados en el disco en la base de datos ESENT no se destruyen ni se quitan. Si decides revertir de Microsoft SQL Server a usar ESENT, es posible quitar la cadena de conexión del almacén y simplemente volver a usar los datos originales. Cualquier suscripción adicional que se haya creado mientras SQL estaba en uso para el almacén no existirá en ESENT y los usuarios no verán estos nuevos registros de suscripción. Todos los registros de suscripción originales seguirán estando presentes.

Para volver a habilitar las suscripciones de ESENT en un almacén

Abre PowerShell ISE y selecciona Ejecutar como administrador.

Usa la opción -UseLocalStorage para especificar el almacén en el que quieres volver a habilitar las suscripciones de ESENT:

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

# Establece la cadena de conexión de la base de datos SQL
$StoreObject = Get-STFStoreService -SiteID $SiteID -VirtualPath $StoreVirtualPath

# Quita la cadena de conexión de la base de datos SQL y revierte a usar ESENT
Set-STFStoreSubscriptionsDatabase -StoreService $StoreObject -UseLocalStorage
Get-STFStoreSubscriptionsDatabase -StoreService $StoreObject
<!--NeedCopy-->

Escenarios 2, 3 y 4

Abre PowerShell ISE y selecciona Ejecutar como administrador.

Especifica el almacén para el que quieres establecer una cadena de conexión mediante $StoreVirtualPath

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

# Para una instancia de base de datos remota
$ConnectionString = "Server=$DBServer\$SQLInstance;Database=$DBName;Trusted_Connection=True;"
<!--NeedCopy-->

O

# Para una instancia de base de datos instalada localmente
$ConnectionString = "$DBLocalServer\$SQLInstance;Database=$DBName;Trusted_Connection=True;"

# Establece la cadena de conexión de la base de datos SQL
$StoreObject = Get-STFStoreService -SiteID $SiteID -VirtualPath "/Citrix/Store"
Set-STFStoreSubscriptionsDatabase -StoreService $StoreObject -ConnectionString $ConnectionString
Get-STFStoreSubscriptionsDatabase -StoreService $StoreObject
<!--NeedCopy-->

Repite el proceso para cada almacén de tu implementación si quieres configurarlos todos para que usen una cadena de conexión SQL.

Migra los datos existentes de ESENT a Microsoft SQL Server

Para migrar tus datos ESENT existentes a SQL, se requiere un proceso de transformación de datos de dos pasos. Se proporcionan dos scripts para ayudarte a realizar esta operación única. Si la cadena de conexión en StoreFront y la instancia de SQL están configuradas correctamente, todas las nuevas suscripciones se crearán automáticamente en SQL con el formato correcto. Después de la migración, los datos históricos de suscripción de ESENT se transforman a un formato SQL y los usuarios también pueden ver sus recursos previamente suscritos.

Ejemplo: cuatro suscripciones SQL para el mismo usuario de dominio

Paso 1 Usa el script Transform-SubscriptionDataForStore.ps1 para convertir los datos ESENT a un formato compatible con SQL para la importación masiva

Inicia sesión en el servidor de StoreFront desde el que quieres transformar los datos ESENT.

Cualquier miembro de un grupo de servidores es adecuado, siempre que todos contengan el mismo número de registros de suscripción.

Abre PowerShell ISE y selecciona Ejecutar como administrador.

Ejecuta el script Transform-SubscriptionDataForStore.ps1 que exporta un archivo <StoreName>.txt desde la base de datos ESENT al escritorio del usuario actual.

El script de PowerShell proporciona información detallada sobre cada fila de suscripción que se procesa para facilitar la depuración y ayudarte a evaluar el éxito de la operación. Esto puede tardar mucho tiempo en procesarse.

Los datos transformados se escriben en <StoreName>SQL.txt en el escritorio del usuario actual una vez que el script ha finalizado. El script resume el número de registros de usuario únicos y el número total de suscripciones procesadas.

Repite este proceso para cada almacén que quieras migrar al servidor SQL.

Paso 2 Usa un procedimiento almacenado T-SQL para importar masivamente los datos transformados a SQL

Los datos de cada almacén deben importarse de uno en uno.

Copia el archivo <StoreName>SQL.txt creado en el Paso 1 desde el escritorio del servidor de StoreFront a C:\ en el servidor de Microsoft SQL y renómbralo a SubscriptionsSQL.txt.

El script Create-ImportSubscriptionDataSP.sql crea un procedimiento almacenado T-SQL para importar masivamente los datos de suscripción. Elimina las entradas duplicadas para cada usuario único, de modo que los datos SQL resultantes se normalizan correctamente y se dividen en las tablas correctas.

Antes de ejecutar Create-ImportSubscriptionDataSP.sql, cambia USE [STFSubscriptions] para que coincida con la base de datos en la que quieres crear el procedimiento almacenado.

Abre el archivo Create-ImportSubscriptionDataSP.sql usando SQL Server Management Studio y ejecuta el código que contiene. Este script agrega el procedimiento almacenado ImportSubscriptionDataSP a la base de datos que creaste anteriormente.

Después de la creación exitosa del procedimiento almacenado, se muestra el siguiente mensaje en la consola SQL y el procedimiento almacenado ImportSubscriptionDataSP se agrega a la base de datos:

Commands completed successfully.

Ejecuta el procedimiento almacenado haciendo clic derecho sobre él, luego selecciona Ejecutar procedimiento almacenado y haz clic en Aceptar.

Un valor de retorno de 0 indica que todos los datos se importaron correctamente. Cualquier problema durante la importación se registra en la consola SQL. Después de que el procedimiento almacenado se haya ejecutado correctamente, compara el número total de registros de suscripción y usuarios únicos que proporciona Transform-SubscriptionDataForStore.ps1 con el resultado de las dos consultas SQL siguientes. Los dos totales deben coincidir.

El número total de suscripciones del script de transformación debe coincidir con el número total informado desde SQL mediante

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

El número de usuarios únicos del script de transformación debe coincidir con el número de registros en la tabla User informado desde SQL mediante

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

Si el script de transformación muestra 100 usuarios únicos y 1000 registros de suscripción totales, SQL debería mostrar los mismos dos números después de una migración exitosa.

Inicia sesión en StoreFront para comprobar si los usuarios existentes pueden ver sus datos de suscripción. Los registros de suscripción existentes se actualizan en SQL cuando los usuarios se suscriben o cancelan la suscripción a sus recursos. También se crean nuevos usuarios y registros de suscripción en SQL.

Paso 3 Ejecuta consultas T-SQL en tus datos importados

Nota:

Todos los nombres de Delivery Controller distinguen entre mayúsculas y minúsculas y deben coincidir exactamente con las mayúsculas/minúsculas y el nombre usados en 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-->

Actualizar o quitar registros de suscripción existentes usando T-SQL

AVISO LEGAL:

Todas las sentencias de actualización y eliminación de SQL de ejemplo se utilizan bajo tu propio riesgo. Citrix no se hace responsable de ninguna pérdida o alteración accidental de tus datos de suscripción por el uso incorrecto de los ejemplos proporcionados. Las siguientes sentencias T-SQL se proporcionan como guía para permitir la realización de actualizaciones sencillas. Haz una copia de seguridad completa de todos los datos de suscripción en la base de datos SQL antes de intentar actualizar tus suscripciones o quitar registros obsoletos. No realizar las copias de seguridad necesarias puede provocar la pérdida o corrupción de datos. Antes de ejecutar tus propias sentencias T-SQL UPDATE o DELETE contra la base de datos de producción, pruébalas con datos de prueba o en una copia redundante de los datos de producción, lejos de la base de datos de producción en vivo.

Nota:

Todos los nombres de Delivery Controller distinguen entre mayúsculas y minúsculas y deben coincidir exactamente con las mayúsculas/minúsculas y el nombre usados en 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-->