Almacenar datos de suscripción con Microsoft SQL Server

Nota:

Este documento asume conocimientos básicos de servidor MS SQL y consultas T-SQL. Los administradores deben sentirse cómodos configurando, usando y administrando el servidor SQL 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 servidor SQL de Microsoft si el almacén está configurado para usar una cadena de conexión SQL.

La principal ventaja de cambiar StoreFront para que use SQL en lugar de ESENT es que puedes usar fácilmente sentencias de actualización SQL para 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 ESENT planos 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.

Nota:

Los fallos de conexión a la instancia de servidor SQL utilizada por StoreFront para almacenar los datos de suscripción debido a interrupciones de red no inutilizan la implementación de StoreFront. Las interrupciones solo provocan una experiencia de usuario temporalmente degradada; los usuarios no pueden agregar, quitar ni ver recursos favoritos hasta que se restablezca la conexión al servidor SQL. Los recursos se pueden seguir enumerando e iniciando 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 palabras clave en los recursos del usuario.

Ventajas de ESENT y el servidor SQL

Desventajas de ESENT y el servidor SQL

Escenarios de implementación

Nota:

Cada almacén configurado en StoreFront requiere una base de datos ESENT o una base de datos SQL de Microsoft 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 los almacenes residan en la misma instancia de servidor SQL de Microsoft para reducir la complejidad de la administración y el margen de error de configuración.

Varios 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 controladores de entrega. La desventaja de que varios 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 varios almacenes. Es posible configurar un almacén para que use ESENT y otro para que use SQL. Esto no se recomienda debido a la mayor complejidad de la administración y el margen de error de configuración.

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

Escenario 1: Servidor StoreFront único o grupo de servidores que usa 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 controladores de entrega o que no necesitan realizar tareas de administración frecuentes en sus datos de suscripción, como quitar o actualizar suscripciones de usuario antiguas.

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

StoreFront usa una instancia de servidor SQL instalada localmente y ambos componentes residen en el mismo servidor. Este escenario es adecuado para una implementación sencilla de StoreFront único en la que los clientes podrían necesitar realizar cambios frecuentes en los nombres de los controladores de entrega, o necesitan realizar tareas de administración frecuentes en sus datos de suscripción, como quitar 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 SQL de Microsoft. Este escenario no es adecuado para implementaciones empresariales grandes.

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

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

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

Nota:

Esta es una configuración avanzada. Solo inténtalo si eres un administrador de servidor SQL experimentado familiarizado con la replicación de transacciones y tienes las habilidades necesarias para implementarlo correctamente.

Esto es lo mismo que el escenario 3, pero lo extiende a situaciones en las que se requieren varios 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 en diferentes centros de datos. Cada grupo de servidores en el centro de datos se conecta a su propia instancia de servidor SQL de Microsoft dedicada para redundancia, conmutación por error y rendimiento. Este escenario requiere una configuración e infraestructura de servidor SQL de Microsoft adicionales considerables. Se basa completamente en la tecnología SQL de Microsoft para replicar los datos de suscripción y sus transacciones SQL.

Recursos

Puedes descargar los siguientes scripts de 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 en 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 de servidor SQL de Microsoft local instalada

Crea un grupo de seguridad local llamado <SQLServer>\StoreFrontServers en el servidor SQL de Microsoft y agrega las cuentas virtuales para IIS APPPOOL\DefaultAppPool e IIS APPPOOL\Citrix Receiver for Web para permitir que 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 IIS.

# Crear grupo local para servidores StoreFront en el servidor de base de datos
$LocalGroupName = "StoreFrontServers"
$Description = "Contains StoreFront Server Machine Accounts or StoreFront AppPool Virtual Accounts"

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

# Crear grupo de usuarios local
$Computer = [ADSI]"WinNT://$env:ComputerName,Computer"
$LocalGroup = $Computer.Create("group",$LocalGroupName)
$LocalGroup.setinfo()
$LocalGroup.description = $Description
$Localgroup.SetInfo()
Write-Host "Grupo de seguridad local $LocalGroupName creado" -ForegroundColor "Green"
}
$Group = [ADSI]"WinNT://$env:ComputerName/$LocalGroupName,group"

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

# Agregar 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 added to $LocalGroupName local group” -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.

![Captura de pantalla de canalizaciones con nombre habilitadas](/en-us/storefront/current-release/media/manage-deployment/sql-server-named-pipes.png)

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

> **Sugerencia:**
>
> Si la conexión a la instancia local de SQL falla, comprueba que `localhost` o `<hostname>` usados en la cadena de conexión se resuelvan en la dirección IPv4 correcta. Windows puede intentar usar IPv6 en lugar de IPv4, y la resolución DNS de `localhost` puede devolver `::1` en lugar de la dirección IPv4 correcta de StoreFront y SQL Server. Es posible que sea necesario deshabilitar completamente la pila de red IPv6 en el servidor host para resolver este problema.

### Escenario 3: Grupo de servidores de 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 a todos los miembros del grupo de servidores de 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.

![Captura de pantalla del grupo de seguridad StoreFrontServers](/en-us/storefront/current-release/media/manage-deployment/sql-server-security-groups.png)

Agrega todas las cuentas de equipo de dominio del grupo de servidores de StoreFront al grupo `<SQLServer>\StoreFrontServers`. Solo las cuentas de equipo de dominio del servidor de StoreFront que figuren en el grupo podrán leer y escribir registros de suscripción en SQL si SQL Server usa la autenticación de Windows. La siguiente función de PowerShell, proporcionada en el script [Add-RemoteSFAccounts.ps1](https://raw.githubusercontent.com/citrix/sample-scripts/master/storefront/Add-RemoteSFAccounts.ps1), crea el grupo de seguridad local y le agrega dos servidores de StoreFront llamados StoreFrontSQL1 y StoreFrontSQL2.

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

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

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

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

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

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 usa SQL Server 2016 Enterprise.

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

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

Antes de ejecutar el script, para cada almacén en 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:

• Nombra 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 una configuración exitosa del 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 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 suscripciones 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"

# 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

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 usando $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;"

O

# 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

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

El número de usos ú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]

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

Inicia sesión en StoreFront para verificar 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 utilizados en StoreFront.

-- Get all SQL subscription records
Use [STFSubscriptions]
SELECT * FROM [Subscription]
SELECT * FROM [User]

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

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

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

AVISO LEGAL:

Todas las sentencias SQL de actualización y eliminación 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 resultar en 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 ficticios 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 sitio distinguen entre mayúsculas y minúsculas y deben coincidir exactamente con las mayúsculas, minúsculas y el nombre utilizados en 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.%'

-- 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.%'

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

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

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

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

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

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

```