Almacenar datos de suscripción usando 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 realicen 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 la 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. Los nuevos registros de suscripción de SQL se crean automáticamente cuando un usuario inicia sesión por primera vez si alguna de estas PALABRAS CLAVE está incluida en los recursos del usuario.
Ventajas de ESENT y SQL Server
| ESENT | SQL |
|---|---|
| Predeterminado y no requiere configuración adicional para usar StoreFront “listo para usar”. | Mucho más manejable y los datos de suscripción se pueden manipular o actualizar fácilmente usando consultas T-SQL. Permite eliminar o actualizar registros por usuario. Permite contar fácilmente los registros por aplicación, controlador de entrega o usuario. Permite eliminar fácilmente datos de usuario innecesarios para usuarios que han dejado la empresa/organización. Permite actualizar fácilmente las referencias del controlador de entrega, por ejemplo, cuando el administrador cambia a usar agregación o se aprovisionan nuevos controladores de entrega. |
| Más sencillo de configurar la replicación entre diferentes grupos de servidores usando la sincronización de suscripciones y los programas de extracción. Consulta Configurar la sincronización de suscripciones | Desacoplado de StoreFront, por lo que no es necesario hacer una copia de seguridad de los datos de suscripción antes de la actualización de StoreFront, ya que los datos se mantienen en un servidor SQL independiente. La copia de seguridad de la suscripción es independiente de StoreFront y utiliza estrategias y mecanismos de copia de seguridad de SQL. |
| SQL innecesario cuando no se necesita la gestión de suscripciones. Si los datos de suscripción nunca necesitarán actualización, es probable que ESENT satisfaga las necesidades del cliente. | Una única copia de los datos de suscripción compartida por todos los miembros del grupo de servidores, lo que reduce la posibilidad de diferencias de datos entre servidores o problemas de sincronización de datos. |
Desventajas de ESENT y SQL Server
| ESENT | SQL |
|---|---|
| No hay una forma sencilla de administrar los datos de suscripción de manera fácil y granular. Requiere que las manipulaciones de suscripción se realicen en archivos .txt exportados. Toda la base de datos de suscripciones debe exportarse y volver a importarse. Potencialmente, miles de registros pueden necesitar ser cambiados usando técnicas de buscar y reemplazar, lo cual es laborioso y potencialmente propenso a errores. | Requiere conocimientos básicos de SQL e infraestructura. Puede requerir la compra de una licencia de SQL, lo que aumenta el costo total de propiedad de la implementación de StoreFront. Aunque una instancia de base de datos de Citrix Virtual Apps and Desktops también se puede compartir con StoreFront para reducir costos. |
| Se debe mantener una copia de la base de datos ESENT en cada servidor StoreFront dentro de un grupo de servidores. En raras ocasiones, esta base de datos puede desincronizarse dentro de un grupo de servidores o entre diferentes grupos de servidores. | Replicar datos de suscripción entre grupos de servidores es una tarea de implementación no trivial. Requiere múltiples instancias de SQL y replicación de transacciones entre cada una de ellas por centro de datos. Esto requiere experiencia especializada en MS SQL. |
| Se requiere la migración de datos de ESENT y la transformación a un formato compatible con SQL. Este proceso solo se requiere una vez. | |
| Es posible que se necesiten servidores y licencias de Windows adicionales. | |
| Pasos adicionales para implementar StoreFront. |
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 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 controladores de entrega. 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 al aumento de la complejidad de la administración y al alcance de la configuración incorrecta.
Hay cuatro escenarios que puedes usar para almacenar datos de suscripción en SQL Server:
Escenario 1: Servidor StoreFront único o grupo de servidores 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 controladores de entrega 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 simple de StoreFront único donde los clientes podrían necesitar hacer 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 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 la 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 hacer 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 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 inténtalo 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 en las que 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 en 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 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 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 SQL Server
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 de Microsoft SQL y agrega las cuentas virtuales para IIS APPPOOL\DefaultAppPool e 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 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 “Grupos de aplicaciones 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:**
>
> Si la conexión a la instancia local de SQL falla, verifica que `localhost` o `<hostname>` utilizados en la cadena de conexión se resuelvan 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 StoreFront y SQL. 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.

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 StoreFront que figuren 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](https://raw.githubusercontent.com/citrix/sample-scripts/master/storefront/Add-RemoteSFAccounts.ps1), crea el grupo de seguridad local y le agrega dos servidores StoreFront llamados StoreFrontSQL1 y StoreFrontSQL2.
<!--NeedCopy-->
```powershell
function Add-RemoteSTFMachineAccounts
{
[CmdletBinding()]
param([Parameter(Mandatory=$True)][string]$Domain,
[Parameter(Mandatory=$True)][array]$StoreFrontServers)
# Crea un grupo local para los servidores de StoreFront en el servidor de base de datos
$LocalGroupName = "StoreFrontServers"
$Description = "Contiene cuentas de equipo de servidor de StoreFront o cuentas virtuales de grupo de aplicaciones 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")
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 luego 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.mdfC:\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 eliminan. 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 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 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 al uso de 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 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;"
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
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 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 procesada 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 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 y dividen correctamente en las tablas adecuadas.
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 reportado 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 reportados 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, 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 utilizados en StoreFront.
-- Obtener todos los registros de suscripción SQL
Use [STFSubscriptions]
SELECT * FROM [Subscription]
SELECT * FROM [User]
-- Obtener todos los registros de suscripción para un SID de usuario particular
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'
-- Obtener el número total de registros de suscripción para un SID de usuario particular
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'
-- Obtener todos los registros de suscripción para un Delivery Controller particular
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'
-- O para recursos agregados, usa el nombre del grupo de agregación
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'
-- Obtener todos los registros de suscripción para una aplicación particular
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] = ' DeliveryController.Application'
Actualizar o eliminar registros de suscripción existentes usando T-SQL
EXENCIÓN DE RESPONSABILIDAD:
Todas las sentencias de ejemplo de actualización y eliminación de SQL se utilizan bajo tu propia responsabilidad. 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. Realiza una copia de seguridad de todos los datos de suscripción en copias de seguridad completas de 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 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 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.
-- Actualiza el Delivery Controller utilizado en todas las suscripciones.
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','NewDeliveryController.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'
-- Después de habilitar la agregación multisitio, actualiza el resource_id
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','DefaultAggregationGroup.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'
-- Elimina todos los registros de suscripción para un Delivery Controller particular
Use [STFSubscriptions]
DELETE FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'
-- O para recursos agregados, usa el nombre del grupo de agregación
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'
-- Elimina todos los registros de suscripción para una aplicación particular
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE '%.Application'
-- Elimina todos los registros de suscripción para una aplicación publicada a través de un Delivery Controller específico
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] = 'DeliveryController.Application'
-- Elimina todos los registros de suscripción para un SID de usuario particular
-- depende de la cascada para eliminar registros de [Subscription]
Use [STFSubscriptions]
DELETE FROM [User]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'
-- Elimina TODOS los datos de suscripción de una base de datos particular y restablece el índice agrupado de clave principal para que comience a numerar desde 0.
-- ÚSALO CON EXTREMO CUIDADO Y NO EN BASES DE DATOS DE PRODUCCIÓN EN VIVO.
-- Puede ser útil al depurar problemas de importación de datos para empezar con una base de datos limpia.
Use [STFSubscriptions]
DELETE FROM [Subscription]
DBCC CHECKIDENT ([Subscription], RESEED, 0)
DELETE FROM [User]
DBCC CHECKIDENT ([User], RESEED, 0)
```
En este artículo
- Introducción
- Configurar el grupo de seguridad local del servidor StoreFront en SQL Server
- Configura el esquema de la base de datos de suscripciones en Microsoft SQL Server para cada almacén
- Configura la cadena de conexión de SQL Server para cada almacén de StoreFront
- Migra los datos existentes de ESENT a Microsoft SQL Server