Abonnementsdaten mit Microsoft SQL Server speichern
Hinweis:
Dieses Dokument setzt grundlegende Kenntnisse von MS SQL Server und T-SQL-Abfragen voraus. Administratoren müssen mit der Konfiguration, Verwendung und Verwaltung von SQL Server vertraut sein, bevor sie versuchen, diesem Dokument zu folgen.
Einführung
ESENT ist eine einbettbare, transaktionale Datenbank-Engine, die Windows verwenden kann. Alle Versionen von StoreFront unterstützen standardmäßig die Verwendung einer integrierten ESENT-Datenbank. Sie können auch eine Verbindung zu einer Microsoft SQL Server-Instanz herstellen, wenn der Store für die Verwendung einer SQL-Verbindungszeichenfolge konfiguriert ist.
Der Hauptvorteil der Umstellung von StoreFront auf SQL anstelle von ESENT besteht darin, dass Sie SQL-Update-Anweisungen einfach verwenden können, um Abonnementsdatensätze zu verwalten, zu ändern oder zu löschen. Wenn Sie SQL verwenden, müssen Sie nicht die gesamten ESENT-Abonnementsdaten exportieren, ändern und erneut importieren, wenn kleinere Änderungen an den Abonnementsdaten vorgenommen werden.
Um vorhandene Abonnementsdaten von ESENT zu Microsoft SQL Server zu migrieren, müssen die aus StoreFront exportierten flachen ESENT-Daten in ein SQL-freundliches Format für den Massenimport umgewandelt werden. Für neue Bereitstellungen ohne neue Abonnementsdaten ist dieser Schritt nicht erforderlich. Der Datenumwandlungsschritt ist nur einmal erforderlich.
Hinweis:
Fehler beim Herstellen einer Verbindung zur SQL Server-Instanz, die von StoreFront zum Speichern der Abonnementsdaten verwendet wird, aufgrund von Netzwerkausfällen machen die StoreFront-Bereitstellung nicht unbrauchbar. Ausfälle führen lediglich zu einer vorübergehend beeinträchtigten Benutzererfahrung; Benutzer können keine bevorzugten Ressourcen hinzufügen, entfernen oder anzeigen, bis die Verbindung zum SQL Server wiederhergestellt ist. Ressourcen können während des Ausfalls weiterhin aufgelistet und gestartet werden. Das erwartete Verhalten ist dasselbe, als ob der Citrix Subscription Store-Dienst bei Verwendung von ESENT angehalten würde.
Tipp:
Ressourcen, die mit KEYWORDS:Auto oder KEYWORDS:Mandatory konfiguriert sind, verhalten sich bei Verwendung von ESENT oder SQL auf die gleiche Weise. Neue SQL-Abonnementsdatensätze werden automatisch erstellt, wenn sich ein Benutzer zum ersten Mal anmeldet, falls eines der KEYWORDS in den Ressourcen des Benutzers enthalten ist.
Vorteile von ESENT und SQL Server
| ESENT | SQL |
|---|---|
| Standard und erfordert keine zusätzliche Konfiguration, um StoreFront “out of the box” zu verwenden. | Wesentlich besser verwaltbar, und Abonnementsdaten können einfach mit T-SQL-Abfragen bearbeitet oder aktualisiert werden. Ermöglicht das Löschen oder Aktualisieren von Datensätzen pro Benutzer. Ermöglicht einfache Möglichkeiten, Datensätze pro Anwendung, Delivery Controller oder Benutzer zu zählen. Ermöglicht einfache Möglichkeiten, unnötige Benutzerdaten für Benutzer zu entfernen, die das Unternehmen/die Organisation verlassen haben. Ermöglicht einfache Möglichkeiten, Delivery Controller-Referenzen zu aktualisieren, z. B. wenn der Administrator auf Aggregation umstellt oder neue Delivery Controller bereitgestellt werden. |
| Einfachere Konfiguration der Replikation zwischen verschiedenen Servergruppen mithilfe von Abonnementsynchronisierung und Pull-Zeitplänen. Siehe Abonnementsynchronisierung konfigurieren | Von StoreFront entkoppelt, sodass keine Sicherung der Abonnementsdaten vor einem StoreFront-Upgrade erforderlich ist, da die Daten auf einem separaten SQL Server verwaltet werden. Die Abonnementsicherung ist unabhängig von StoreFront und verwendet SQL-Sicherungsstrategien und -mechanismen. |
| SQL ist unnötig, wenn keine Abonnementsverwaltung erforderlich ist. Wenn die Abonnementsdaten niemals aktualisiert werden müssen, erfüllt ESENT wahrscheinlich die Kundenanforderungen. | Eine einzige Kopie der Abonnementsdaten, die von allen Mitgliedern der Servergruppe gemeinsam genutzt wird, wodurch die Wahrscheinlichkeit von Datenunterschieden zwischen Servern oder Datenreplikationsproblemen verringert wird. |
Nachteile von ESENT und SQL Server
| ESENT | SQL |
|---|---|
| Keine einfache Möglichkeit, Abonnementsdaten einfach und granular zu verwalten. Erfordert, dass Abonnementsmanipulationen in exportierten .txt-Dateien vorgenommen werden. Die gesamte Abonnementsdatenbank muss exportiert und erneut importiert werden. Potenziell müssen Tausende von Datensätzen mithilfe von Suchen-und-Ersetzen-Techniken geändert werden, was arbeitsintensiv und potenziell fehleranfällig ist. | Erfordert grundlegende SQL-Kenntnisse und -Infrastruktur. Kann den Kauf einer SQL-Lizenz erfordern, was die Gesamtbetriebskosten der StoreFront-Bereitstellung erhöht. Eine Citrix Virtual Apps and Desktops-Datenbankinstanz kann jedoch auch mit StoreFront geteilt werden, um Kosten zu senken. |
| Eine Kopie der ESENT-Datenbank muss auf jedem StoreFront-Server innerhalb einer Servergruppe vorgehalten werden. In seltenen Fällen kann diese Datenbank innerhalb einer Servergruppe oder zwischen verschiedenen Servergruppen asynchron werden. | Die Replikation von Abonnementsdaten zwischen Servergruppen ist eine nicht triviale Bereitstellungsaufgabe. Sie erfordert mehrere SQL-Instanzen und Transaktionsreplikation zwischen jeder von ihnen pro Rechenzentrum. Dies erfordert spezialisierte MS SQL-Kenntnisse. |
| Datenmigration von ESENT und Transformation in ein SQL-freundliches Format erforderlich. Dieser Prozess ist nur einmal erforderlich. | |
| Zusätzliche Windows-Server und Lizenzen können erforderlich sein. | |
| Zusätzliche Schritte zur Bereitstellung von StoreFront. |
Bereitstellungsszenarien
Hinweis:
Jeder in StoreFront konfigurierte Store erfordert entweder eine ESENT-Datenbank oder eine Microsoft SQL-Datenbank, wenn Sie Benutzerabonnements unterstützen möchten. Die Methode zum Speichern der Abonnementsdaten wird auf Store-Ebene innerhalb von StoreFront festgelegt.
Citrix® empfiehlt, dass alle Store-Datenbanken auf derselben Microsoft SQL Server-Instanz liegen, um die Verwaltungskomplexität zu reduzieren und das Risiko von Fehlkonfigurationen zu minimieren.
Mehrere Stores können dieselbe Datenbank gemeinsam nutzen, vorausgesetzt, sie sind alle für die Verwendung derselben identischen Verbindungszeichenfolge konfiguriert. Es spielt keine Rolle, ob sie unterschiedliche Delivery Controller verwenden. Der Nachteil, dass mehrere Stores eine Datenbank gemeinsam nutzen, besteht darin, dass es keine Möglichkeit gibt zu erkennen, welchem Store jeder Abonnementsdatensatz entspricht.
Eine Kombination der beiden Datenspeichermethoden ist technisch auf einer einzelnen StoreFront-Bereitstellung mit mehreren Stores möglich. Es ist möglich, einen Store für die Verwendung von ESENT und einen anderen für die Verwendung von SQL zu konfigurieren. Dies wird aufgrund der erhöhten Verwaltungskomplexität und des Risikos von Fehlkonfigurationen nicht empfohlen.
Es gibt vier Szenarien, die Sie zum Speichern von Abonnementsdaten in SQL Server verwenden können:
Szenario 1: Einzelner StoreFront-Server oder Servergruppe mit ESENT (Standard)
Standardmäßig verwenden alle StoreFront-Versionen ab Version 2.0 eine flache ESENT-Datenbank, um Abonnementsdaten zwischen Mitgliedern einer Servergruppe zu speichern und zu replizieren. Jedes Mitglied der Servergruppe verwaltet eine identische Kopie der Abonnementsdatenbank, die mit allen anderen Mitgliedern der Servergruppe synchronisiert wird. Dieses Szenario erfordert keine zusätzlichen Konfigurationsschritte. Dieses Szenario eignet sich für die meisten Kunden, die keine häufigen Änderungen an Delivery Controller-Namen erwarten oder keine häufigen Verwaltungsaufgaben an ihren Abonnementsdaten durchführen müssen, wie das Entfernen oder Aktualisieren alter Benutzerabonnements.
Szenario 2: Einzelner StoreFront-Server und eine lokal installierte Microsoft SQL Server-Instanz
StoreFront verwendet eine lokal installierte SQL Server-Instanz, und beide Komponenten befinden sich auf demselben Server. Dieses Szenario eignet sich für eine einfache Einzel-StoreFront-Bereitstellung, bei der Kunden möglicherweise häufig Änderungen an Delivery Controller-Namen vornehmen müssen oder häufige Verwaltungsaufgaben an ihren Abonnementsdaten durchführen müssen, wie das Entfernen oder Aktualisieren alter Benutzerabonnements, aber keine hochverfügbare StoreFront-Bereitstellung benötigen. Citrix empfiehlt dieses Szenario nicht für Servergruppen, da es einen Single Point of Failure auf dem Servergruppenmitglied erzeugt, das die Microsoft SQL-Datenbankinstanz hostet. Dieses Szenario ist nicht für große Unternehmensbereitstellungen geeignet.
Szenario 3: StoreFront-Servergruppe und eine dedizierte Microsoft SQL Server-Instanz, die für Hochverfügbarkeit konfiguriert ist (empfohlen)
Alle Mitglieder der StoreFront-Servergruppe stellen eine Verbindung zur selben dedizierten Microsoft SQL Server-Instanz oder einem SQL-Failover-Cluster her. Dies ist das am besten geeignete Modell für große Unternehmensbereitstellungen, bei denen Citrix-Administratoren häufig Änderungen an Delivery Controller-Namen vornehmen oder häufige Verwaltungsaufgaben an ihren Abonnementsdaten durchführen möchten, wie das Entfernen oder Aktualisieren alter Benutzerabonnements, und Hochverfügbarkeit benötigen.

Szenario 4: Mehrere StoreFront-Servergruppen und eine dedizierte Microsoft SQL Server-Instanz in jedem Rechenzentrum pro Servergruppe
Hinweis:
Dies ist eine erweiterte Konfiguration. Versuchen Sie dies nur, wenn Sie ein erfahrener SQL Server-Administrator sind, der mit der Transaktionsreplikation vertraut ist und über die erforderlichen Fähigkeiten verfügt, um sie erfolgreich bereitzustellen.
Dies ist dasselbe wie Szenario 3, erweitert es jedoch auf Situationen, in denen mehrere StoreFront-Servergruppen in verschiedenen entfernten Rechenzentren erforderlich sind. Citrix-Administratoren können wählen, Abonnementsdaten zwischen verschiedenen Servergruppen in denselben oder unterschiedlichen Rechenzentren zu synchronisieren. Jede Servergruppe im Rechenzentrum stellt eine Verbindung zu ihrer eigenen dedizierten Microsoft SQL Server-Instanz her, um Redundanz, Failover und Leistung zu gewährleisten. Dieses Szenario erfordert eine beträchtliche zusätzliche Microsoft SQL Server-Konfiguration und -Infrastruktur. Es basiert vollständig auf der Microsoft SQL-Technologie, um die Abonnementsdaten und ihre SQL-Transaktionen zu replizieren.

Ressourcen
Sie können die folgenden Skripte von https://github.com/citrix/sample-scripts/tree/master/storefront herunterladen, um Unterstützung zu erhalten:
Konfigurationsskripte
-
Set-STFDatabase.ps1 – legt die MS SQL-Verbindungszeichenfolge für jeden Store fest. Auf dem StoreFront-Server ausführen.
-
Add-LocalAppPoolAccounts.ps1 – gewährt den App-Pools des lokalen StoreFront-Servers Lese- und Schreibzugriff auf die SQL-Datenbank. Für Szenario 2 auf dem SQL Server ausführen.
-
Add-RemoteSFAccounts.ps1 – gewährt allen StoreFront-Servern in einer Servergruppe Lese- und Schreibzugriff auf die SQL-Datenbank. Für Szenario 3 auf dem SQL Server ausführen.
-
Create-StoreSubscriptionsDB-2016.sql – erstellt die SQL-Datenbank und das Schema. Auf dem SQL Server ausführen.
Datentransformations- und Importskripte
-
Transform-SubscriptionDataForStore.ps1 – exportiert und transformiert vorhandene Abonnementsdaten innerhalb von ESENT in ein SQL-freundliches Format für den Import.
-
Create-ImportSubscriptionDataSP.sql – erstellt eine gespeicherte Prozedur zum Importieren der durch Transform-SubscriptionDataForStore.ps1 transformierten Daten. Führen Sie dieses Skript einmal auf dem SQL Server aus, nachdem Sie das Datenbankschema mit Create-StoreSubscriptionsDB-2016.sql erstellt haben.
Konfigurieren der lokalen Sicherheitsgruppe des StoreFront-Servers auf dem SQL Server
Szenario 2: Einzelner StoreFront-Server und eine lokal installierte Microsoft SQL Server-Instanz
Erstellen Sie eine lokale Sicherheitsgruppe namens <SQLServer>\StoreFrontServers auf dem Microsoft SQL Server und fügen Sie die virtuellen Konten für IIS APPPOOL\DefaultAppPool und IIS APPPOOL\Citrix Receiver for Web hinzu, um dem lokal installierten StoreFront das Lesen und Schreiben in SQL zu ermöglichen. Diese Sicherheitsgruppe wird im .SQL-Skript referenziert, das das Datenbankschema für den Store erstellt, stellen Sie daher sicher, dass der Gruppenname übereinstimmt.
Sie können das Skript Add-LocalAppPoolAccounts.ps1 herunterladen, um Unterstützung zu erhalten.
Installieren Sie StoreFront, bevor Sie das Skript Add-LocalAppPoolAccounts.ps1 ausführen. Das Skript hängt von der Fähigkeit ab, das virtuelle IIS-Konto IIS APPPOOL\Citrix Receiver for Web zu finden, das erst existiert, nachdem StoreFront installiert und konfiguriert wurde. IIS APPPOOL\DefaultAppPool wird automatisch durch die Installation der IIS-Webserverrolle erstellt.
# 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 added to $LocalGroupName local group” -ForegroundColor “Green”
Aktivieren Sie benannte Pipes in Ihrer lokalen SQL-Instanz mithilfe des SQL Server-Konfigurations-Managers. Benannte Pipes sind für die Interprozesskommunikation zwischen StoreFront und dem SQL Server erforderlich.

Stellen Sie sicher, dass die Windows-Firewallregeln korrekt konfiguriert sind, um SQL Server-Verbindungen entweder über einen bestimmten Port oder dynamische Ports zuzulassen. Informationen zur Vorgehensweise in Ihrer Umgebung finden Sie in der Microsoft-Dokumentation.
> **Tipp:**
>
> Wenn die Verbindung zur lokalen SQL-Instanz fehlschlägt, überprüfen Sie, ob localhost oder `<hostname>`, die in der Verbindungszeichenfolge verwendet werden, in die korrekte IPv4-Adresse aufgelöst werden. Windows versucht möglicherweise, IPv6 anstelle von IPv4 zu verwenden, und die DNS-Auflösung von localhost gibt möglicherweise ::1 anstelle der korrekten IPv4-Adresse des StoreFront- und SQL-Servers zurück. Möglicherweise ist es erforderlich, den IPv6-Netzwerkstack auf dem Hostserver vollständig zu deaktivieren, um dieses Problem zu beheben.
### Szenario 3: StoreFront-Servergruppe und eine dedizierte Microsoft SQL Server-Instanz
Erstellen Sie auf dem Microsoft SQL Server eine lokale Sicherheitsgruppe namens `<SQLServer>\StoreFrontServers` und fügen Sie alle Mitglieder der StoreFront-Servergruppe hinzu. Diese Sicherheitsgruppe wird später im Skript **Create-StoreSubscriptionsDB-2016.sql** referenziert, das das Abonnementdatenbankschema in SQL erstellt.

Fügen Sie alle Domänencomputer-Konten der StoreFront-Servergruppe der Gruppe `<SQLServer>\StoreFrontServers` hinzu. Nur die in der Gruppe aufgeführten Domänencomputer-Konten der StoreFront-Server können Abonnementdatensätze in SQL lesen und schreiben, wenn die Windows-Authentifizierung vom SQL Server verwendet wird. Die folgende PowerShell-Funktion, die im Skript [Add-RemoteSFAccounts.ps1](https://raw.githubusercontent.com/citrix/sample-scripts/master/storefront/Add-RemoteSFAccounts.ps1) bereitgestellt wird, erstellt die lokale Sicherheitsgruppe und fügt ihr zwei StoreFront-Server mit den Namen StoreFrontSQL1 und StoreFrontSQL2 hinzu.
<!--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")
Konfigurieren des Abonnementdatenbankschemas in Microsoft SQL Server für jeden Store
Erstellen Sie eine benannte Instanz auf Ihrem Microsoft SQL Server zur Verwendung durch StoreFront. Legen Sie den Pfad im .SQL-Skript so fest, dass er dem Installationsort Ihrer SQL-Version oder dem Speicherort ihrer Datenbankdateien entspricht. Das Beispielskript Create-StoreSubscriptionsDB-2016.sql verwendet SQL Server 2016 Enterprise.
Erstellen Sie eine leere Datenbank mithilfe von SQL Server Management Studio (SSMS), indem Sie mit der rechten Maustaste auf Databases klicken und dann New Database auswählen.

Geben Sie einen Datenbanknamen ein, der Ihrem Store entspricht, oder wählen Sie einen anderen Namen, z. B. STFSubscriptions.
Bevor Sie das Skript ausführen, ändern Sie für jeden Store in Ihrer StoreFront-Bereitstellung die Referenzen im Beispielskript so, dass sie Ihren StoreFront- und SQL-Bereitstellungen entsprechen. Ändern Sie beispielsweise:
-
Benennen Sie jede von Ihnen erstellte Datenbank so, dass sie dem Store-Namen in StoreFront in
USE [STFSubscriptions]entspricht. -
Legen Sie den Pfad zu den Datenbankdateien .mdf und .ldf fest, wo Sie die Datenbank speichern möchten.
C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.mdfC:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.ldf -
Legen Sie die Referenz auf den Namen Ihres SQL Servers innerhalb des Skripts fest:
CREATE LOGIN [SQL2016\StoreFrontServers] FROM WINDOWS;ALTER LOGIN [SQL2016\StoreFrontServers]
Führen Sie das Skript aus. Nach erfolgreicher Konfiguration des Schemas werden drei Datenbanktabellen erstellt: SchemaDetails, Subscription und User.

Das folgende Datenbankdiagramm zeigt das Abonnementdatenbankschema, das das Skript Create-StoreSubscriptionsDB-2016.sql erstellt:

Konfigurieren der SQL Server-Verbindungszeichenfolge für jeden StoreFront-Store
Szenario 1
Tipp:
Die ursprünglichen Abonnementdaten, die auf der Festplatte in der ESENT-Datenbank gespeichert sind, werden nicht zerstört oder entfernt. Wenn Sie sich entscheiden, vom Microsoft SQL Server zur Verwendung von ESENT zurückzukehren, ist es möglich, die Store-Verbindungszeichenfolge zu entfernen und einfach wieder die ursprünglichen Daten zu verwenden. Zusätzliche Abonnements, die erstellt wurden, während SQL für den Store verwendet wurde, existieren nicht in ESENT, und Benutzer sehen diese neuen Abonnementdatensätze nicht. Alle ursprünglichen Abonnementdatensätze sind weiterhin vorhanden.
So aktivieren Sie ESENT-Abonnements für einen Store erneut
Öffnen Sie die PowerShell ISE und wählen Sie Als Administrator ausführen.
Verwenden Sie die Option -UseLocalStorage, um den Store anzugeben, für den Sie ESENT-Abonnements erneut aktivieren möchten:
$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
Szenarien 2, 3 und 4
Öffnen Sie die PowerShell ISE und wählen Sie Als Administrator ausführen.
Geben Sie den Store an, für den Sie eine Verbindungszeichenfolge festlegen möchten, mithilfe von $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;"
ODER
# 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
Wiederholen Sie den Vorgang für jeden Store in Ihrer Bereitstellung, wenn Sie alle für die Verwendung einer SQL-Verbindungszeichenfolge konfigurieren möchten.
Vorhandene Daten von ESENT in Microsoft SQL Server migrieren
Um Ihre vorhandenen ESENT-Daten zu SQL zu migrieren, ist ein zweistufiger Datentransformationsprozess erforderlich. Zwei Skripte werden bereitgestellt, um Sie bei der Durchführung dieses einmaligen Vorgangs zu unterstützen. Wenn die Verbindungszeichenfolge in StoreFront und die SQL-Instanz korrekt konfiguriert sind, werden alle neuen Abonnements automatisch in SQL im richtigen Format erstellt. Nach der Migration werden die historischen ESENT-Abonnementdaten in ein SQL-Format transformiert, und Benutzer können auch ihre zuvor abonnierten Ressourcen sehen.
Beispiel: Vier SQL-Abonnements für denselben Domänenbenutzer

Schritt 1 Verwenden Sie das Skript Transform-SubscriptionDataForStore.ps1, um die ESENT-Daten in ein SQL-freundliches Format für den Massenimport zu konvertieren
Melden Sie sich bei dem StoreFront-Server an, von dem Sie ESENT-Daten transformieren möchten.
Jedes Mitglied einer Servergruppe ist geeignet, vorausgesetzt, alle enthalten die gleiche Anzahl von Abonnementdatensätzen.
Öffnen Sie die PowerShell ISE und wählen Sie Als Administrator ausführen.
Führen Sie das Skript Transform-SubscriptionDataForStore.ps1 aus, das eine <StoreName>.txt-Datei aus der ESENT-Datenbank auf den Desktop des aktuellen Benutzers exportiert.
Das PowerShell-Skript liefert ausführliches Feedback zu jeder verarbeiteten Abonnementzeile, um die Fehlersuche zu erleichtern und Ihnen bei der Beurteilung des Erfolgs des Vorgangs zu helfen. Die Verarbeitung kann lange dauern.
Die transformierten Daten werden nach Abschluss des Skripts auf dem Desktop des aktuellen Benutzers in die Datei <StoreName>SQL.txt geschrieben. Das Skript fasst die Anzahl der eindeutigen Benutzerdatensätze und die Gesamtzahl der verarbeiteten Abonnements zusammen.
Wiederholen Sie diesen Vorgang für jeden Store, den Sie auf den SQL-Server migrieren möchten.
Schritt 2 Verwenden Sie eine T-SQL-gespeicherte Prozedur, um die transformierten Daten per Massenimport in SQL zu importieren
Die Daten jedes Stores müssen einzeln importiert werden.
Kopieren Sie die in Schritt 1 erstellte Datei <StoreName>SQL.txt vom Desktop des StoreFront-Servers nach C:\ auf dem Microsoft SQL-Server und benennen Sie sie in SubscriptionsSQL.txt um.
Das Skript Create-ImportSubscriptionDataSP.sql erstellt eine T-SQL-gespeicherte Prozedur, um die Abonnementdaten per Massenimport zu importieren. Es entfernt doppelte Einträge für jeden eindeutigen Benutzer, sodass die resultierenden SQL-Daten korrekt normalisiert und in die richtigen Tabellen aufgeteilt werden.
Bevor Sie Create-ImportSubscriptionDataSP.sql ausführen, ändern Sie USE [STFSubscriptions], um es an die Datenbank anzupassen, unter der Sie die gespeicherte Prozedur erstellen möchten.
Öffnen Sie die Datei Create-ImportSubscriptionDataSP.sql mit SQL Server Management Studio und führen Sie den darin enthaltenen Code aus. Dieses Skript fügt die gespeicherte Prozedur ImportSubscriptionDataSP der zuvor von Ihnen erstellten Datenbank hinzu.
Nach erfolgreicher Erstellung der gespeicherten Prozedur wird die folgende Meldung in der SQL-Konsole angezeigt, und die gespeicherte Prozedur ImportSubscriptionDataSP wird der Datenbank hinzugefügt:
Commands completed successfully.

Führen Sie die gespeicherte Prozedur aus, indem Sie mit der rechten Maustaste darauf klicken, dann Gespeicherte Prozedur ausführen auswählen und auf OK klicken.

Der Rückgabewert 0 zeigt an, dass alle Daten erfolgreich importiert wurden. Alle Probleme beim Import werden in der SQL-Konsole protokolliert. Nachdem die gespeicherte Prozedur erfolgreich ausgeführt wurde, vergleichen Sie die Gesamtzahl der Abonnementdatensätze und eindeutigen Benutzer, die Transform-SubscriptionDataForStore.ps1 bereitstellt, mit dem Ergebnis der beiden unten stehenden SQL-Abfragen. Die beiden Gesamtzahlen sollten übereinstimmen.
Die Gesamtzahl der Abonnements aus dem Transformationsskript sollte mit der von SQL gemeldeten Gesamtzahl übereinstimmen, die durch folgende Abfrage ermittelt wird:
SELECT COUNT(*) AS TotalSubscriptions
FROM [Subscription]
Die Anzahl der eindeutigen Benutzer aus dem Transformationsskript sollte mit der Anzahl der Datensätze in der Benutzertabelle übereinstimmen, die von SQL durch folgende Abfrage gemeldet wird:
SELECT COUNT(*) AS TotalUsers
FROM [User]
Wenn das Transformationsskript 100 eindeutige Benutzer und 1000 Abonnementdatensätze anzeigt, sollte SQL nach erfolgreicher Migration dieselben beiden Zahlen anzeigen.
Melden Sie sich bei StoreFront an, um zu überprüfen, ob bestehende Benutzer ihre Abonnementdaten sehen können. Bestehende Abonnementdatensätze werden in SQL aktualisiert, wenn Benutzer ihre Ressourcen abonnieren oder abbestellen. Neue Benutzer und Abonnementdatensätze werden ebenfalls in SQL erstellt.
Schritt 3 Führen Sie T-SQL-Abfragen für Ihre importierten Daten aus
Hinweis:
Alle Delivery Controller-Namen sind Groß- und Kleinschreibung-sensitiv und müssen exakt der Groß- und Kleinschreibung sowie dem Namen entsprechen, die in StoreFront verwendet werden.
-- 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'
Vorhandene Abonnementdatensätze mit T-SQL aktualisieren oder löschen
HAFTUNGSAUSSCHLUSS:
Alle Beispiel-SQL-Update- und Delete-Anweisungen werden ausschließlich auf Ihr eigenes Risiko verwendet. Citrix ist nicht verantwortlich für Verluste oder versehentliche Änderungen Ihrer Abonnementdaten durch falsche Verwendung der bereitgestellten Beispiele. Die folgenden T-SQL-Anweisungen dienen als Leitfaden, um einfache Aktualisierungen zu ermöglichen. Sichern Sie alle Abonnementdaten in vollständigen SQL-Datenbank-Backups, bevor Sie versuchen, Ihre Abonnements zu aktualisieren oder veraltete Datensätze zu entfernen. Das Versäumnis, die erforderlichen Backups durchzuführen, kann zu Datenverlust oder -beschädigung führen. Bevor Sie Ihre eigenen T-SQL-UPDATE- oder DELETE-Anweisungen für die Produktionsdatenbank ausführen, testen Sie diese mit Dummy-Daten oder auf einer redundanten Kopie der Produktionsdaten, getrennt von der aktiven Produktionsdatenbank.
Hinweis:
Alle Site-Namen sind Groß- und Kleinschreibung-sensitiv und müssen exakt der Groß- und Kleinschreibung sowie dem Namen entsprechen, die in StoreFront verwendet werden.
-- 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)
```
In diesem Artikel
- Einführung
- Konfigurieren der lokalen Sicherheitsgruppe des StoreFront-Servers auf dem SQL Server
- Konfigurieren des Abonnementdatenbankschemas in Microsoft SQL Server für jeden Store
- Konfigurieren der SQL Server-Verbindungszeichenfolge für jeden StoreFront-Store
- Vorhandene Daten von ESENT in Microsoft SQL Server migrieren
- Vorhandene Abonnementdatensätze mit T-SQL aktualisieren oder löschen