Abonnementdaten mit Microsoft SQL Server speichern

Hinweis:

Dieses Dokument setzt Grundkenntnisse in MS SQL Server und T-SQL-Abfragen voraus. Administratoren müssen mit der Konfiguration, Verwendung und Verwaltung von SQL Server vertraut sein, bevor sie die Informationen dieses Dokuments nutzen.

Einführung

ESENT ist eine einbettbare transaktionale Datenbankengine, die von Windows verwendet werden 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 zur Verwendung einer SQL-Verbindungszeichenfolge konfiguriert ist.

Der Hauptvorteil des Umstiegs von ESENT auf SQL in StoreFront besteht darin, dass Abonnementdatensätze mit T-SQL-Update-Anweisungen verwaltet, geändert und gelöscht werden können. Wenn Sie SQL verwenden, müssen Sie für geringfügige Änderungen an den Abonnementdaten nicht die gesamten ESENT-Abonnementdaten exportieren, ändern und wieder importieren.

Um Abonnementdaten von ESENT nach Microsoft SQL Server zu migrieren, müssen die aus StoreFront exportierten ESENT-Flat-Daten in ein SQL-freundliches Format für den Massenimport umgewandelt werden. Bei neuen Bereitstellungen ohne neue Abonnementdaten ist dieser Schritt nicht erforderlich. Die Datentransformation ist nur einmal erforderlich. In diesem Artikel wird die für StoreFront-Versionen ab Version 3.5 (mit der das hier genannte PowerShell-SDK -STF eingeführt wurde) unterstützte Konfiguration beschrieben.

Hinweis:

Fehler beim Herstellen der Verbindung mit der zum Speichern der Abonnementdaten verwendeten SQL Server-Instanz aufgrund von Netzwerkausfällen machen die StoreFront-Bereitstellung nicht unbrauchbar. Ausfälle führen lediglich zu einer vorübergehend verschlechterten Benutzererfahrung: Die Benutzer können keine bevorzugten Ressourcen hinzufügen, entfernen oder anzeigen, bis die Verbindung zu SQL Server wiederhergestellt wurde. Ressourcen können während eines Ausfalls weiterhin angezeigt und gestartet werden. Das erwartete Verhalten ist mit dem identisch, wenn bei Verwendung von ESENT der Citrix Subscription Store-Dienst beendet wird.

Tipp:

Mit KEYWORDS:Auto oder KEYWORDS:Mandatory konfigurierte Ressourcen verhalten sich bei Verwendung von ESENT und SQL gleich. Neue SQL-Abonnementdatensätze werden automatisch erstellt, wenn sich ein Benutzer zum ersten Mal anmeldet, wenn ein KEYWORD in den Ressourcen des Benutzers enthalten ist.

Vorteile von ESENT und SQL Server

Nachteile von ESENT und SQL Server

Bereitstellungsszenarios

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 in StoreFront auf Store-Ebene festgelegt.

Citrix empfiehlt, alle Store-Datenbanken in derselben Microsoft SQL Server-Instanz zu führen, um die Verwaltung zu vereinfachen und das Potenzial von Fehlkonfigurationen zu verringern.

Stores können dieselbe Datenbank gemeinsam nutzen, vorausgesetzt, sie sind zur Verwendung derselben Verbindungszeichenfolge konfiguriert. Es spielt keine Rolle, ob sie unterschiedliche Delivery Controller verwenden. Der Nachteil der Verwendung einer Datenbank durch mehrere Stores besteht darin, dass nicht erkennbar ist, welchem Store die einzelnen Abonnementdatensätze entsprechen.

Eine Kombination beider Datenspeichermethoden in einer einzelnen StoreFront-Bereitstellung mit mehreren Stores ist technisch möglich. Ein Speicher kann für ESENT und ein zweiter für SQL konfiguriert werden. Das wird aufgrund der komplexeren Verwaltung und des Potenzials für Fehlkonfigurationen nicht empfohlen.

Zum Speichern von Abonnementdaten in SQL Server gibt es vier Szenarien:

Szenario 1: Einzelner StoreFront -Server oder Servergruppe mit ESENT (Standard)

Standardmäßig verwenden alle Versionen von StoreFront ab 2.0 eine ESENT-Flat-Datenbank, um Abonnementdaten einer Servergruppe zu speichern und zu replizieren. Auf jedem Mitglied der Servergruppe wird eine identische Kopie der Abonnementdatenbank geführt und mit allen anderen Mitgliedern der Servergruppe synchronisiert. Dieses Szenario erfordert keine zusätzliche Konfiguration. Das Szenario eignet sich für die meisten Kunden, bei denen keine häufigen Änderungen an Delivery Controller-Namen und keine häufigen Verwaltungsaufgaben an Abonnementdaten (Entfernen oder Aktualisieren alter Benutzerabonnements) zu erwarten sind.

Szenario 2: Einzelner StoreFront-Server und 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 StoreFront-Bereitstellung, bei der häufig Änderungen an Delivery Controller-Namen oder Verwaltungsschritte wie Entfernen oder Aktualisieren von Abonnementdaten nötig sind, jedoch keine hohe Verfügbarkeit der StoreFront-Bereitstellung erforderlich ist. Citrix empfiehlt dieses Szenario nicht für Servergruppen, da damit ein zentraler Ausfallpunkt auf dem Servergruppenmitglied entsteht, das die Microsoft SQL-Datenbankinstanz hostet. Das Szenario ist nicht für große Enterprise-Bereitstellungen geeignet.

Szenario 3: StoreFront-Servergruppe und eine dedizierte, für hohe Verfügbarkeit konfigurierte Microsoft SQL Server-Instanz (empfohlen)

Alle Mitglieder der StoreFront-Servergruppe stellen eine Verbindung mit derselben dedizierten Microsoft SQL Server-Instanz bzw. einem SQL-Failovercluster her. Dies ist das am besten geeignete Modell für große Enterprise-Bereitstellungen, in denen Citrix Administratoren häufig Änderungen an Delivery Controller-Namen vornehmen oder häufig Verwaltungsaufgaben an Abonnementdaten ausgeführt werden (z. B. Entfernen oder Aktualisieren) und die hohe Verfügbarkeit erfordern.

Szenario 4: Mehrere StoreFront-Servergruppen und eine dedizierte Microsoft SQL Server-Instanz für jede Servergruppe in jedem Datencenter

Hinweis:

Dies ist eine fortgeschrittene Konfiguration. Sie sollte nur von erfahrenen SQL Server-Administratoren erstellt werden, die mit der Transaktionsreplikation vertraut sind und über die erforderlichen Kenntnisse verfügen.

Das Szenario ähnelt Szenario 3, erweitert auf Umgebungen, in denen mehrere StoreFront-Servergruppen in verschiedenen Datencentern erforderlich sind. Citrix Administratoren können die Abonnementdaten zwischen verschiedenen Servergruppen in denselben oder verschiedenen Datencentern synchronisieren. Für Redundanz- und Failoverzwecke und eine hohe Leistung stellt jede Servergruppe im Datencenter eine Verbindung zu einer dedizierten Microsoft SQL Server-Instanz her. Das Szenario erfordert eine erhebliche zusätzliche Microsoft SQL Server-Konfiguration und -Infrastruktur. Sie nutzt für die Replikation von Abonnementdaten und für SQL-Transaktionen ausschließlich Microsoft SQL-Technologie.

Ressourcen

Sie können die folgenden hilfreichen Skripts von https://github.com/citrix/sample-scripts/tree/master/storefront herunterladen:

Konfigurationsskripts

• Set-STFDatabase.ps1 – Legt die MS SQL-Verbindungszeichenfolge für jeden Store fest. Führen Sie das Skript auf dem StoreFront-Server aus.

• Add-LocalAppPoolAccounts.ps1 – Gewährt den App-Pools des lokalen StoreFront-Servers Lese- und Schreibzugriff auf die SQL-Datenbank. Führen Sie das Skript für Szenario 2 auf dem SQL-Server aus.

• Add-RemoteSFAccounts.ps1 – Gewährt allen StoreFront-Servern in einer Servergruppe Lese- und Schreibzugriff auf die SQL-Datenbank. Führen Sie das Skript für Szenario 3 auf dem SQL-Server aus.

• Create-StoreSubscriptionsDB-2016.sql – Erstellt die SQL-Datenbank und das Schema. Führen Sie das Skript auf dem SQL-Server aus.

Skripts für Datentransformation und Import

• Transform-SubscriptionDataForStore.ps1 – Exportiert Abonnementdaten aus ESENT und wandelt sie in ein SQL-freundliches Format für den Import um.

• Create-ImportSubscriptionDatasp.sql – Erstellt eine gespeicherte Prozedur zum Importieren der von Transform-SubscriptionDataForStore.ps1 umgewandelten Daten. Führen Sie das 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 lokal installierte Microsoft SQL Server-Instanz

Erstellen Sie eine lokale Sicherheitsgruppe unter dem Namen <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, damit das lokal installierte StoreFront Lese- und Schreibvorgänge an SQL ausführen kann. Auf diese Sicherheitsgruppe wird in dem SQL-Skript verwiesen, das das Schema für die Store-Abonnementdatenbank erstellt. Stellen Sie daher sicher, dass die Gruppennamen übereinstimmen.

Sie können hierfür das Skript Add-LocalAppPoolAccounts.ps1 herunterladen.

Installieren Sie StoreFront, bevor Sie das Skript Add-LocalAppPoolAccounts.ps1 ausführen. Das Skript erfordert, dass das virtuelle IIS-Konto von IIS APPPOOL\Citrix Receiver for Web gefunden werden kann, welches erst nach der Installation und Konfiguration von StoreFront vorhanden ist. 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)

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

Aktivieren Sie mithilfe von SQL Server-Konfigurations-Manager Named Pipes in Ihrer lokalen SQL-Instanz. Named Pipes sind für die Kommunikation zwischen StoreFront- und SQL Server-Prozessen erforderlich.

Stellen Sie sicher, dass die Windows-Firewallregeln korrekt konfiguriert sind, sodass SQL Server-Verbindungen über einen bestimmten Port oder dynamische Ports zugelassen sind. Spezifische Informationen hierzu für Ihre Umgebung finden Sie in der Microsoft-Dokumentation.

Tipp:

Wenn die Verbindung zur lokalen SQL-Instanz fehlschlägt, überprüfen Sie, ob localhost bzw. die Angabe <hostname> in der Verbindungszeichenfolge in die richtige IPv4-Adresse aufgelöst wird. Windows versucht möglicherweise, IPv6 anstelle von IPv4 zu verwenden, und die DNS-Auflösung von localhost kann ::1 anstelle der richtigen IPv4-Adresse des StoreFront- und SQL-Servers zurückgeben. Möglicherweise ist das vollständige Deaktivieren des IPv6-Netzwerkstapels auf dem Hostserver erforderlich, um dieses Problem zu beheben.

Szenario 3: StoreFront-Servergruppe und eine dedizierte Microsoft SQL Server-Instanz

Erstellen Sie eine lokale Sicherheitsgruppe unter dem Namen <SQLServer>\StoreFrontServers auf dem Microsoft SQL-Server und fügen Sie alle Mitglieder der StoreFront-Servergruppe hinzu. Auf diese Sicherheitsgruppe wird später im Skript Create-StoreSubscriptionsDB-2016.SQL verwiesen, das das Schema der Abonnementdatenbank in SQL erstellt.

Fügen Sie der Gruppe alle Domänencomputerkonten der StoreFront-Servergruppe <SQLServer>\StoreFrontServers hinzu. Nur in der Gruppe aufgelistete StoreFront-Server-Domänenkonten können Abonnementdatensätze in SQL lesen und schreiben, wenn die Windows-Authentifizierung von SQL Server verwendet wird. Die folgende PowerShell-Funktion in Skript Add-RemoteSFAccounts.ps1 erstellt die lokale Sicherheitsgruppe und fügt ihr zwei StoreFront-Server mit dem Namen “StoreFrontSQL1” und “StoreFrontSQL2” hinzu.

function Add-RemoteSTFMachineAccounts
{
[CmdletBinding()]
param([Parameter(Mandatory=$True)][string]$Domain,
[Parameter(Mandatory=$True)][array]$StoreFrontServers)

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

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

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

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

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 innerhalb des .SQL-Skripts auf den Installationsort der SQL-Version oder den Speicherort der Datenbankdateien fest. Das Beispielskript Create-StoreSubscriptionsDB-2016.sql verwendet SQL Server 2016 Enterprise.

Erstellen Sie mit SQL Server Management Studio (SSMS) eine leere Datenbank, indem Sie mit der rechten Maustaste auf Datenbanken klicken und Neue Datenbank auswählen.

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

Ändern Sie vor dem Ausführen des Skripts für jeden Store in Ihrer StoreFront Bereitstellung die Verweise im Beispielskript so, dass sie Ihren StoreFront- und SQL-Bereitstellungen entsprechen. Beispiel:

• Benennen Sie jede von Ihnen erstellte Datenbank so, dass sie mit dem Storenamen in StoreFront unter USE [STFSubscriptions] übereinstimmt.

• Legen Sie den Pfad der MDF- und LDF-Datenbankdateien auf den Pfad fest, an dem die Datenbank gespeichert werden soll.

  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 den Verweis 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.

Die folgende Abbildung zeigt das Schema der mit dem Skript Create-StoreSubscriptionsDB-2016.SQL erstellten Abonnementdatenbank:

Konfigurieren der SQL Server-Verbindungszeichenfolge für jeden StoreFront-Store

Szenario 1

Tipp:

Die auf dem Datenträger gespeicherten ursprünglichen Abonnementdaten der ESENT-Datenbank werden nicht gelöscht. Wenn Sie von Microsoft SQL Server wieder auf ESENT umsteigen möchten, können Sie die Store-Verbindungszeichenfolge entfernen und einfach wieder die ursprünglichen Daten verwenden. Abonnements, die während der Verwendung von SQL für den Store erstellt wurden, sind in ESENT nicht vorhanden und die Benutzer sehen diese neuen Abonnementdatensätze nicht. Alle ursprünglichen Abonnementdatensätze sind weiterhin vorhanden.

Erneutes Aktivieren von ESENT-Abonnements in einem Store

Öffnen Sie 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
<!--NeedCopy-->

Szenarios 2, 3 und 4

Öffnen Sie PowerShell ISE, und wählen Sie Als Administrator ausführen.

Geben Sie mit $StoreVirtualPath den Store an, für den Sie eine Verbindungszeichenfolge festlegen möchten.

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

# For a remote database instance
$ConnectionString = "Server=$DBServer$SQLInstance;Database=$DBName;Trusted_Connection=True;"
<!--NeedCopy-->

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
<!--NeedCopy-->

Wiederholen Sie den Vorgang für jeden Store in der Bereitstellung, wenn Sie alle Stores für die Verwendung einer SQL-Verbindungszeichenfolge konfigurieren möchten.

Migrieren von Daten von ESENT nach Microsoft SQL Server

Zur Migration vorhandener ESENT-Daten nach SQL ist ein zweistufiger Datentransformationsprozess erforderlich. Zwei Skripts stehen zur Verfügung, die bei der Ausführung dieser einmaligen Operation helfen. Wenn die Verbindungszeichenfolge in StoreFront und der SQL-Instanz korrekt konfiguriert ist, werden alle neuen Abonnements automatisch in SQL im richtigen Format erstellt. Nach der Migration werden die ESENT-Abonnementdaten in ein SQL-Format umgewandelt und die Benutzer sehen auch ihre zuvor abonnierten Ressourcen.

Beispiel: vier SQL-Abonnements für einen Domänenbenutzer

Schritt 1: Konvertieren der ESENT-Daten in ein SQL-Format für den Massenimport mit Transform-SubscriptionDataForStore.ps1

Melden Sie sich bei dem StoreFront-Server an, dessen ESENT-Daten Sie umwandeln möchten.

Jedes Mitglied einer Servergruppe ist geeignet, sofern alle die gleiche Anzahl Abonnementdatensätze enthalten.

Öffnen Sie 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 bietet ausführliches Feedback zu jeder verarbeiteten Abonnementzeile, um das Debuggen und die Prüfung des Erfolgs des Vorgangs zu unterstützen. Die Verarbeitung kann lange dauern.

Die umgewandelten Daten werden nach Abschluss des Skripts in die Datei <StoreName>SQL.txt auf dem Desktop des aktuellen Benutzers 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 nach SQL Server migrieren möchten.

Schritt 2: Massenimport der umgewandelten Daten mit einer gespeicherten T-SQL-Prozedur

Die Daten müssen für jeden Stores gesondert importiert werden.

Kopieren Sie die in Schritt 1 erstellte Datei <StoreName>SQL.txt vom Desktop des StoreFront-ServersC:\ auf den Computer mit Microsoft SQL Server und benennen Sie sie in SubscriptionsSQL.txt um.

Das Skript Create-ImportSubscriptionDataSP.sql erstellt eine gespeicherte T-SQL-Prozedur zum Massenimport der Abonnementdaten. Es entfernt doppelte Einträge für eindeutige 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] auf die Datenbank, in 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 enthaltenen Code aus. Das Skript fügt der zuvor erstellten Datenbank die gespeicherte Prozedur ImportSubscriptionDatasp hinzu.

Nach Erstellung der gespeicherten Prozedur wird in der SQL-Konsole die folgende Meldung 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, Gespeicherte Prozedur ausführen wählen und auf OK klicken.

Der Rückgabewert 0 zeigt an, dass alle Daten erfolgreich importiert wurden. Jegliche Probleme beim Import werden in der SQL-Konsole protokolliert. Nach dem erfolgreichen Ausführen der gespeicherten Prozedur vergleichen Sie die von Transform-SubscriptionDataForStore.ps1 zurückgegebene Gesamtzahl der Abonnementdatensätze und eindeutigen Benutzer mit dem Ergebnis der beiden SQL-Abfragen unten. Die beiden Summen müssen übereinstimmen.

Die Gesamtanzahl der Abonnements aus dem Transformationsskript muss mit der Gesamtzahl übereinstimmen, die von folgender SQL-Abfrage zurückgegeben wird:

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

Die Anzahl der eindeutigen Benutzer aus dem Transformationsskript muss mit der Anzahl übereinstimmen, die von folgender SQL-Abfrage aus der Tabelle “User” zurückgegeben wird:

SELECT COUNT(*) AS TotalUsers
FROM [User]
<!--NeedCopy-->

Wenn das Transformationsskript 100 eindeutige Benutzer und 1000 Abonnementdatensätze insgesamt anzeigt, muss SQL nach erfolgreicher Migration dieselben 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 Ressourcen abonnieren oder abbestellen. Neue Benutzer- und Abonnementdatensätze werden ebenfalls in SQL erstellt.

Schritt 3: Ausführen der T-SQL-Abfragen an importierten Daten

Hinweis:

Bei allen Delivery Controller-Namen wird zwischen Groß- und Kleinschreibung unterschieden. Die Schreibung muss mit der in StoreFront verwendeten Groß- und Kleinschreibung übereinstimmen.

-- Get all SQL subscription records
Use [STFSubscriptions]
SELECT * FROM [Subscription]
SELECT * FROM [User]
<!--NeedCopy-->

-- Get all subscription records for a particular user SID
Use [STFSubscriptions]
SELECT * FROM [Subscription]
INNER JOIN [User]
ON [Subscription].[user_id] = [User].[id]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'

-- Get total number of Subscription records for a particular user SID
Use [STFSubscriptions]
SELECT COUNT(Subscription.id)
FROM [Subscription]
INNER JOIN [User]
ON [Subscription].[user_id] = [User].[id]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'
<!--NeedCopy-->

-- Get all subscription records for a particular delivery controller
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'

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

-- Get all subscription records for a particular application
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] = ' DeliveryController.Application'
<!--NeedCopy-->

Aktualisieren oder Löschen von Abonnementdatensätzen mit T-SQL

Haftungsausschluss:

Sie verwenden alle SQL-Anweisungen zum Aktualisieren und Löschen ausschließlich auf eigenes Risiko. Citrix ist nicht haftbar bei einem Verlust oder einer versehentlichen Änderung Ihrer Abonnementdaten durch die falsche Anwendung der angegebenen Beispiele. Die folgenden T-SQL-Anweisungen sollen als Leitfaden für einfache Aktualisierungen dienen. Führen Sie für alle Abonnementdaten in der SQL-Datenbank ein vollständiges Backup aus, bevor Sie versuchen, Abonnements zu aktualisieren oder veraltete Datensätze zu entfernen. Wenn Sie diese erforderlichen Backups nicht ausführen, kann dies zu Datenverlust oder -beschädigung führen. Bevor Sie eigene T-SQL-UPDATE- oder DELETE-Anweisungen an der Produktionsdatenbank ausführen, testen Sie diese an Testdaten oder einer redundanten Kopie der Produktionsdaten außerhalb der Live-Produktionsdatenbank.

Hinweis:

Bei allen Delivery Controller-Namen wird zwischen Groß- und Kleinschreibung unterschieden. Die Schreibung muss mit der in StoreFront verwendeten Groß- und Kleinschreibung übereinstimmen.

-- Update the delivery controller used in all subscriptions.
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','NewDeliveryController.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'
<!--NeedCopy-->

-- After enabling multi-site aggregation, update the resource_id
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','DefaultAggregationGroup.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'
<!--NeedCopy-->

-- Delete all subscription records for a particular Delivery Controller
Use [STFSubscriptions]
DELETE FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'
<!--NeedCopy-->

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

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

-- Delete all subscription records for an application published via a specific delivery controller
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] = 'DeliveryController.Application'
<!--NeedCopy-->

-- Delete all subscription records for a particular user SID
-- relies on cascade to delete records from [Subscription]
Use [STFSubscriptions]
DELETE FROM [User]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'
<!--NeedCopy-->

-- Delete ALL subscription data from a particular database and reset the primary key clustered index to start numbering from 0.
-- USE WITH EXTREME CARE AND NOT ON LIVE PRODUCTION DATABASES.
-- Can be useful whilst debugging data import issues to start with a clean database.

Use [STFSubscriptions]
DELETE FROM [Subscription]
DBCC CHECKIDENT ([Subscription], RESEED, 0)
DELETE FROM [User]
DBCC CHECKIDENT ([User], RESEED, 0)
<!--NeedCopy-->