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 von Windows verwendet werden kann. Alle StoreFront-Versionen 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 T-SQL-Update-Anweisungen es Ihnen ermöglichen, Abonnementdatensätze zu verwalten, zu ändern oder zu löschen. Wenn Sie SQL verwenden, müssen Sie nicht die gesamten ESENT-Abonnementdaten exportieren, ändern und erneut importieren, wenn kleinere Änderungen an den Abonnementdaten vorgenommen werden.

Um vorhandene Abonnementdaten 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 Abonnementdaten ist dieser Schritt nicht erforderlich. Der Datentransformationsschritt ist nur einmal erforderlich. Dieser Artikel beschreibt die unterstützte Konfiguration, die in allen StoreFront-Versionen ab Version 3.5 verwendet werden kann, welche das im Artikel referenzierte -STF PowerShell SDK eingeführt hat.

Hinweis:

Fehler beim Herstellen einer Verbindung zur SQL Server-Instanz, die von StoreFront zum Speichern der Abonnementdaten 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-Abonnementdatensä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

Nachteile von ESENT und SQL Server

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 Abonnementdaten 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 Abonnementdatensatz 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 Abonnementdaten 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 Abonnementdaten zwischen Mitgliedern einer Servergruppe zu speichern und zu replizieren. Jedes Mitglied der Servergruppe verwaltet eine identische Kopie der Abonnementdatenbank, 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 Abonnementdaten durchführen müssen, wie z. B. 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 Abonnementdaten durchführen müssen, wie z. B. 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 zu 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 Abonnementdaten durchführen möchten, wie z. B. 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 Remote-Rechenzentren erforderlich sind. Citrix-Administratoren können wählen, Abonnementdaten 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 Abonnementdaten 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 Sie zu unterstützen:

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.

Skripte zur Datentransformation und zum Import

• Transform-SubscriptionDataForStore.ps1 – exportiert und transformiert vorhandene Abonnementdaten 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 auf dem Microsoft SQL Server eine lokale Sicherheitsgruppe namens <SQLServer>\StoreFrontServers 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 Store-Abonnementdatenbankschema erstellt. Stellen Sie daher sicher, dass der Gruppenname übereinstimmt.

Sie können das Skript Add-LocalAppPoolAccounts.ps1 herunterladen, um Sie zu unterstützen.

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.

# Lokale Gruppe für StoreFront-Server auf dem DB-Server erstellen
$LocalGroupName = "StoreFrontServers"
$Description = "Contains StoreFront Server Machine Accounts or StoreFront AppPool Virtual Accounts"

# Prüfen, ob die lokale Gruppe existiert
if ([ADSI]::Exists("WinNT://$env:ComputerName/$LocalGroupName"))
{
    Write-Host "$LocalGroupName existiert bereits!" -ForegroundColor "Yellow"
}
else
{
Write-Host "Erstelle lokale Sicherheitsgruppe $LocalGroupName" -ForegroundColor "Yellow"

# Lokale Benutzergruppe erstellen
$Computer = [ADSI]"WinNT://$env:ComputerName,Computer"
$LocalGroup = $Computer.Create("group",$LocalGroupName)
$LocalGroup.setinfo()
$LocalGroup.description = $Description
$Localgroup.SetInfo()
Write-Host "Lokale Sicherheitsgruppe $LocalGroupName erstellt" -ForegroundColor "Green"
}
$Group = [ADSI]"WinNT://$env:ComputerName/$LocalGroupName,group"

# IIS APPPOOL\DefaultAppPool hinzufügen
$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)

# IIS APPPOOL\Citrix Receiver for Web hinzufügen
$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 zur lokalen Gruppe $LocalGroupName hinzugefügt” -ForegroundColor “Green”

Aktivieren Sie benannte Pipes in Ihrer lokalen SQL-Instanz mithilfe des SQL Server-Konfigurationsmanagers. Benannte Pipes sind für die Interprozesskommunikation zwischen StoreFront und dem SQL Server erforderlich.

![Screenshot: Benannte Pipes aktiviert](/en-us/storefront/2402-ltsr/media/configure-manage-stores/sql-server-named-pipes.png)

Stellen Sie sicher, dass die Windows-Firewallregeln korrekt konfiguriert sind, um SQL Server-Verbindungen ü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` kann `::1` anstelle der korrekten IPv4-Adresse des StoreFront- und SQL-Servers zurückgeben. 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.

![Screenshot: Sicherheitsgruppe StoreFrontServers](/en-us/storefront/2402-ltsr/media/configure-manage-stores/sql-server-security-groups.png)

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 des StoreFront-Servers 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)

# Lokale Gruppe für StoreFront-Server auf dem DB-Server erstellen
$LocalGroupName = "StoreFrontServers"
$Description = "Enthält StoreFront Server-Computerkonten oder virtuelle StoreFront AppPool-Konten"

# Überprüfen, ob die lokale Sicherheitsgruppe bereits existiert
if ([ADSI]::Exists("WinNT://$env:ComputerName/$LocalGroupName"))
{
    Write-Host "$LocalGroupName existiert bereits!" -ForegroundColor "Yellow"
}
else
{
    Write-Host "Erstelle lokale Gruppe $LocalGroupName" -ForegroundColor "Yellow"

    # Lokale Sicherheitsgruppe erstellen
    $Computer = [ADSI]"WinNT://$env:ComputerName,Computer"
    $LocalGroup = $Computer.Create("group",$LocalGroupName)
    $LocalGroup.setinfo()
    $LocalGroup.description = $Description
    $Localgroup.SetInfo()
Write-Host "Lokale Gruppe $LocalGroupName erstellt" -ForegroundColor "Green"
}
Write-Host "Füge $StoreFrontServers zur lokalen Gruppe $LocalGroupName hinzu" -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 zu $LocalGroupName hinzugefügt" -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 mit SQL Server Management Studio (SSMS), indem Sie mit der rechten Maustaste auf Datenbanken klicken und dann Neue Datenbank auswählen.

Geben Sie einen Datenbanknamen ein, der Ihrem Store entspricht, oder wählen Sie einen anderen Namen wie STFSubscriptions.

Bevor Sie das Skript ausführen, ändern Sie für jeden Store in Ihrer StoreFront-Bereitstellung die Referenzen im Beispielskript, um sie an Ihre StoreFront- und SQL-Bereitstellungen anzupassen. Ä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.mdf

  C:\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, können Sie die Store-Verbindungszeichenfolge entfernen und einfach wieder die ursprünglichen Daten verwenden. Alle zusätzlichen 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"

# Legt die SQL DB-Verbindungszeichenfolge fest
$StoreObject = Get-STFStoreService -SiteID $SiteID -VirtualPath $StoreVirtualPath

# Entfernt die SQL DB-Verbindungszeichenfolge und kehrt zur Verwendung von ESENT zurück
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, indem Sie $StoreVirtualPath verwenden.

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

# Für eine Remote-Datenbankinstanz
$ConnectionString = "Server=$DBServer\$SQLInstance;Database=$DBName;Trusted_Connection=True;"

ODER

# Für eine lokal installierte Datenbankinstanz
$ConnectionString = "$DBLocalServer\$SQLInstance;Database=$DBName;Trusted_Connection=True;"

# Legt die SQL DB-Verbindungszeichenfolge fest
$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 so konfigurieren möchten, dass sie eine SQL-Verbindungszeichenfolge verwenden.

Migrieren vorhandener Daten von ESENT zu Microsoft SQL Server

Zur Migration Ihrer vorhandenen ESENT-Daten zu SQL ist ein zweistufiger Datentransformationsprozess erforderlich. Es werden zwei Skripte bereitgestellt, die Sie bei der Durchführung dieses einmaligen Vorgangs 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 detailliertes Feedback zu jeder verarbeiteten Abonnementzeile, um das Debugging 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] so, dass es der Datenbank entspricht, 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 liefert, 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

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 gemeldet wird durch

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.

-- Alle SQL-Abonnementdatensätze abrufen
Use [STFSubscriptions]
SELECT * FROM [Subscription]
SELECT * FROM [User]

-- Alle Abonnementdatensätze für eine bestimmte Benutzer-SID abrufen
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'

-- Gesamtzahl der Abonnementdatensätze für eine bestimmte Benutzer-SID abrufen
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'

-- Alle Abonnementdatensätze für einen bestimmten Delivery Controller abrufen
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'

-- ODER für aggregierte Ressourcen den Namen der Aggregationsgruppe verwenden
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'

-- Alle Abonnementdatensätze für eine bestimmte Anwendung abrufen
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 unsachgemäße 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 außerhalb der aktiven Produktionsdatenbank.

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.

-- Den in allen Abonnements verwendeten Delivery Controller aktualisieren.
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','NewDeliveryController.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'

-- Nach dem Aktivieren der Multi-Site-Aggregation die resource_id aktualisieren
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','DefaultAggregationGroup.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'

-- Alle Abonnementdatensätze für einen bestimmten Delivery Controller löschen
Use [STFSubscriptions]
DELETE FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'

-- ODER für aggregierte Ressourcen den Namen der Aggregationsgruppe verwenden
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'

-- Alle Abonnementdatensätze für eine bestimmte Anwendung löschen
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE '%.Application'

-- Alle Abonnementdatensätze für eine Anwendung löschen, die über einen bestimmten Delivery Controller veröffentlicht wurde
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] = 'DeliveryController.Application'

-- Alle Abonnementdatensätze für eine bestimmte Benutzer-SID löschen
-- basiert auf Kaskadierung, um Datensätze aus [Subscription] zu löschen
Use [STFSubscriptions]
DELETE FROM [User]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'

-- ALLE Abonnementdaten aus einer bestimmten Datenbank löschen und den gruppierten Primärschlüsselindex zurücksetzen, um die Nummerierung bei 0 zu beginnen.
-- MIT EXTREMER VORSICHT UND NICHT AUF LIVE-PRODUKTIONSDATENBANKEN VERWENDEN.
-- Kann nützlich sein, um Probleme beim Datenimport zu debuggen und mit einer sauberen Datenbank zu beginnen.

Use [STFSubscriptions]
DELETE FROM [Subscription]
DBCC CHECKIDENT ([Subscription], RESEED, 0)
DELETE FROM [User]
DBCC CHECKIDENT ([User], RESEED, 0)

```