Almacenar datos de suscripción mediante Microsoft SQL Server

Nota:

En este documento, se presupone que tiene conocimientos básicos de MS SQL Server y las consultas T-SQL. Los administradores deben estar familiarizados con la configuración, uso y administración de SQL Server antes de intentar seguir este documento.

Introducción

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

La principal ventaja de cambiar StoreFront para uso de SQL, en lugar de ESENT, es que las instrucciones de actualización T-SQL le permiten administrar, modificar o eliminar registros de suscripción. Si utiliza SQL, no es necesario exportar, modificar ni volver a importar todos los datos de suscripción de ESENT cada vez que se hagan cambios menores en estos.

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

Nota:

Los fallos en la conexión a la instancia de SQL Server utilizada por StoreFront para almacenar los datos de suscripción debido a interrupciones en la red no hacen inutilizable la implementación de StoreFront. Las interrupciones solo afectan temporalmente a la experiencia de usuario: los usuarios no pueden agregar, quitar o ver sus recursos favoritos hasta que se restaura la conexión con el servidor SQL. Los recursos sí se pueden enumerar e iniciar durante la interrupción. El comportamiento previsto es el mismo que si el servicio Citrix Subscription Store se detuviera durante el uso de ESENT.

Consejo:

Los recursos configurados con las palabras clave Auto o Mandatory funcionan de la misma manera cuando se utilizan con ESENT o SQL. Los nuevos registros de suscripción de SQL se crean automáticamente cuando un usuario inicia sesión por primera vez si se incluye cualquiera de esas dos palabras clave 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 en StoreFront requiere una base de datos ESENT o una base de datos de Microsoft SQL para compatibilidad con suscripciones de usuario. El método de almacenamiento de los datos de suscripción se establece en el nivel de almacén dentro de StoreFront.

Citrix recomienda que todas las bases de datos de almacenes residan en la misma instancia de Microsoft SQL Server para reducir la complejidad de la administración y la posibilidad de una configuración incorrecta.

Varios almacenes pueden compartir la misma base de datos, siempre que estén configurados para usar una cadena de conexión idéntica. No importa si utilizan Delivery Controllers diferentes. La desventaja de que varios almacenes compartan una misma 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 misma implementación de StoreFront con varios almacenes Es posible configurar un almacén para uso de ESENT y otro para uso de SQL. Esto no se recomienda debido a la mayor complejidad de la administración y a la posibilidad de una configuración incorrecta.

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

Escenario 1: Un único servidor o grupo de servidores de StoreFront con ESENT (predeterminado)

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

Escenario 2: Un único servidor de StoreFront y una instancia local de Microsoft SQL Server

StoreFront utiliza una instancia de SQL Server instalada localmente y ambos componentes residen en el mismo servidor. Este escenario es adecuado para una implementación simple de StoreFront en la que los clientes podrían necesitar hacer cambios frecuentes en los nombres de los Delivery Controllers o realizar tareas de administración con frecuencia en los 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, ya que da lugar a un punto único de error en el miembro del grupo de servidores que aloja la instancia de base de datos de Microsoft SQL. Este escenario no es adecuado para implementaciones en grandes empresas.

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

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

Escenario 4: Varios grupos de servidores de StoreFront y una instancia dedicada de Microsoft SQL Server en cada centro de datos para cada grupo de servidores

Nota:

Esta es una configuración avanzada. Inténtelo solo si es un administrador de SQL Server experimentado, está familiarizado con la replicación de transacciones y tiene las competencias necesarias para implementarlo correctamente.

Se trata de la misma situación que la 3, pero ampliada a situaciones en las que se requieren varios grupos de servidores de StoreFront en diferentes centros de datos remotos. Los administradores de Citrix pueden elegir sincronizar los datos de suscripción entre diferentes grupos de servidores del mismo centro de datos o de diferentes centros de datos. Cada grupo de servidores del centro de datos se conecta a su propia instancia dedicada de Microsoft SQL Server para optimizar la redundancia, la conmutación por error y el rendimiento. Este escenario requiere una infraestructura y configuración de servidores Microsoft SQL extra considerables. Confía plenamente en la tecnología de Microsoft SQL para replicar los datos de suscripción y las transacciones SQL.

Recursos

Puede descargar los siguientes scripts de https://github.com/citrix/sample-scripts/tree/master/storefront como ayuda:

Scripts de configuración

• Set-STFDatabase.ps1: establece la cadena de conexión MS SQL para cada almacén. Se ejecuta en el servidor de StoreFront.

• Add-LocalAppPoolAccounts.ps1: concede a los grupos de aplicaciones locales del servidor de StoreFront acceso de lectura y escritura a la base de datos SQL. Se ejecuta para el escenario 2 en el servidor SQL.

• Add-RemoteSFAccounts.ps1: concede a todos los servidores de StoreFront de un grupo de servidores acceso de lectura y escritura a la base de datos SQL. Se ejecuta para el escenario 3 en el servidor SQL.

• Create-StoreSubscriptionsDB-2016.sql: crea el esquema y la base de datos SQL. Se ejecuta 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 en ESENT a un formato de fácil lectura para importación en SQL.

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

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

Escenario 2: Un único servidor de StoreFront y una instancia local de Microsoft SQL Server

Cree un grupo de seguridad local llamado <SQLServer>\StoreFrontServers en el servidor Microsoft SQL y agregue las cuentas virtuales para IIS APPPOOL\DefaultAppPool y IIS APPPOOL\Citrix Receiver for Web para permitir que la instancia de StoreFront instalada localmente pueda leer y escribir en SQL. A este grupo de seguridad se hace referencia en el script .SQL que crea el esquema de base de datos de suscripciones del almacén, por lo que deberá asegurarse de que el nombre del grupo coincide.

Puede descargar el script Add-LocalAppPoolAccounts.ps1 para ayudarle.

Instale 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 ha 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)

Write-Host "AppPools added to $LocalGroupName local group" -ForegroundColor "Green"
<!--NeedCopy-->

Habilite las canalizaciones con nombre en su instancia SQL local con 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úrese de que las reglas del firewall de Windows están configuradas correctamente para permitir conexiones de SQL Server a través de un puerto específico o de puertos dinámicos. Consulte la documentación de Microsoft para saber cómo hacerlo en su entorno.

Consejo:

Si se produce un error en la conexión a la instancia SQL local, compruebe que localhost o <hostname> utilizado en la cadena de conexión se resuelve en la dirección IPv4 correcta. Windows podría intentar usar IPv6 en lugar de IPv4, y la resolución DNS de localhost podría devolver ::1 en lugar de la dirección IPv4 correcta del servidor de StoreFront y SQL. Puede ser necesario inhabilitar completamente la pila de red IPv6 en el servidor host para resolver este problema.

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

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

Agregue todas las cuentas de equipo de dominio del grupo de servidores de StoreFront al grupo <SQLServer>\StoreFrontServers. Solo las cuentas de equipo de dominio de servidor de StoreFront enumeradas en el grupo podrán leer y escribir registros de suscripción en SQL si el servidor SQL utiliza la autenticación de Windows. Esta función de PowerShell, proporcionada en el script Add-RemoteSFAccounts.ps1, crea el grupo de seguridad local y le agrega dos servidores de StoreFront denominados StoreFrontSQL1 y 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-->

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

Cree una instancia con nombre en el servidor Microsoft SQL para uso en StoreFront. Establezca la ruta de acceso en el script .SQL para que se corresponda con el lugar donde está instalada la versión de SQL o donde se almacenan sus archivos de base de datos. El script de ejemplo Create-StoreSubscriptionsDB-2016.sql usa SQL Server 2016 Enterprise.

Haga clic con el botón derecho del mouse en Bases de datos y seleccione Nueva base de datos para crear una base de datos vacía con SQL Server Management Studio (SSMS).

Introduzca un nombre de base de base de datos que coincida con el de su almacén o elija otro nombre, como STFSubscriptions.

Antes de ejecutar el script, para cada almacén de la implementación de StoreFront, modifique las referencias del script de ejemplo para que coincidan con las implementaciones de StoreFront y SQL. Por ejemplo, modifique:

• Asigne un nombre a cada base de datos que cree, de manera que coincida con el nombre del almacén de StoreFront en USE [STFSubscriptions].

• Establezca la ruta de acceso a los archivos .mdf y .ldf de la base de datos donde quiere almacenar esta.

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

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

• Establezca la referencia al nombre de su servidor SQL dentro del script:

  CREATE LOGIN [SQL2016\StoreFrontServers] FROM WINDOWS;

  ALTER LOGIN [SQL2016\StoreFrontServers]

Ejecute 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 base de datos de suscripciones que crea el script Create-StoreSubscriptionsDB-2016.sql:

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

Caso 1

Consejo:

Los datos de suscripción originales almacenados en disco en la base de datos ESENT no se destruyen ni eliminan. Si decide revertir de Microsoft SQL Server a ESENT, es posible quitar la cadena de conexión del almacén y volver a utilizar los datos originales. Las suscripciones adicionales que se crearon mientras SQL estaba en uso para el almacén no existirán en ESENT, y los usuarios no podrán ver estos nuevos registros de suscripción. Todos los registros de suscripciones originales seguirán estando presentes.

Para volver a habilitar suscripciones ESENT en un almacén

Abra PowerShell ISE y seleccione Ejecutar como administrador.

Utilice la opción -UseLocalStorage para especificar el almacén en el que quiere volver a habilitar las suscripciones 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-->

Escenarios 2, 3 y 4

Abra PowerShell ISE y seleccione Ejecutar como administrador.

Especifique el almacén para el que quiere establecer una cadena de conexión para usar $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-->

O BIEN:

# 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-->

Repita el proceso para cada almacén de la implementación si quiere configurarlos todos para que utilicen una cadena de conexión SQL.

Migrar datos existentes de ESENT a Microsoft SQL Server

Para migrar los datos existentes de ESENT a SQL se requiere un proceso de transformación de los datos en dos pasos. Se proporcionan dos scripts para ayudarle a realizar esta operación, que se ejecuta una sola vez. Si la cadena de conexión en StoreFront y la instancia SQL están correctamente configuradas, todas las nuevas suscripciones se crean automáticamente en SQL en 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 de suscripción previos.

Ejemplo: cuatro suscripciones SQL para el mismo usuario de dominio

Paso 1. Utilice el script Transform-SubscriptionDataForStore.ps1 para convertir los datos de ESENT a un formato de fácil lectura en SQL para la importación en bloque

Inicie sesión en el servidor de StoreFront para el que quiere transformar los datos de ESENT.

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

Abra PowerShell ISE y seleccione Ejecutar como administrador.

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

El script de PowerShell proporciona comentarios detallados sobre cada fila de suscripción que se procesa, a fin de ayudar a la depuración y evaluar el éxito de la operación. Esta operación puede tardar mucho tiempo en procesarse.

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

Repita este proceso para cada almacén que quiera migrar a SQL Server.

Paso 2. Utilice un procedimiento almacenado T-SQL para importar en bloque, en SQL, los datos transformados

Los datos de cada almacén deben importarse por separado.

Copie el archivo <StoreName>SQL.txt creado en el paso 1 desde el escritorio del servidor de StoreFront en C:\, en el servidor Microsoft SQL, y cambie el nombre a SubscriptionsSQL.txt.

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

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

Abra el archivo Create-ImportSubscriptionDataSP.sql con SQL Server Management Studio y ejecute el código que contiene. Este script agrega el procedimiento almacenado ImportSubscriptionDataSP a la base de datos creada anteriormente.

Después de crearse el procedimiento almacenado, se muestra el siguiente mensaje en la consola de SQL y se agrega el procedimiento almacenado ImportSubscriptionDataSP a la base de datos:

Commands completed successfully.

Para ejecutar el procedimiento almacenado, haga clic con el botón derecho en él, seleccione Ejecutar procedimiento almacenado y haga clic en Aceptar.

El valor devuelto 0 indica que todos los datos se han importado correctamente. Cualquier problema al importar se registra en la consola de SQL. Una vez que el procedimiento almacenado se haya ejecutado correctamente, compare 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 notificado desde SQL por

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

El número de usos únicos del script de transformación debe coincidir con el número de registros de la tabla de usuario notificados desde SQL por

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 debe mostrar los mismos dos números después de la migración.

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

Paso 3. Ejecute consultas T-SQL en los datos importados

Nota:

Todos los nombres de Delivery Controller distinguen entre mayúsculas y minúsculas, y deben coincidir exactamente con las mayúsculas y minúsculas utilizadas 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 eliminar registros de suscripción existentes mediante T-SQL

RENUNCIA DE RESPONSABILIDADES:

Todas las instrucciones SQL para actualización y eliminación de ejemplo las utiliza bajo su propio riesgo. Citrix no se hace responsable de ninguna pérdida o alteración accidental de sus datos de suscripción por el uso incorrecto de los ejemplos proporcionados. Las siguientes instrucciones T-SQL se proporcionan como guía para posibilitar una actualización sencilla. Haga una copia de seguridad de todos los datos de suscripción presentes en su base de datos SQL antes de intentar actualizar sus suscripciones o eliminar registros obsoletos. Si no se realizan las copias de seguridad necesarias, se pueden producir pérdidas o daños en los datos. Antes de ejecutar sus propias instrucciones UPDATE o DELETE de T-SQL en la base de datos de producción, pruebe con datos ficticios o con una copia redundante de los datos, fuera del entorno de la base de datos de producción real.

Nota:

Todos los nombres de Delivery Controller distinguen entre mayúsculas y minúsculas, y deben coincidir exactamente con las mayúsculas y minúsculas utilizadas 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-->