Microsoft SQL Serverを使用したサブスクリプションデータの保存
注：
このドキュメントは、MS SQL ServerとT-SQLクエリに関する基本的な知識を前提としています。管理者がこのドキュメントを参照するには、SQL Serverを問題なく構成、使用、管理できるようにする必要があります。
はじめに
ESENTは、Windowsで使用できる埋め込み可能なトランザクションデータベースエンジンです。StoreFrontのすべてのバージョンは、デフォルトで組み込みのESENTデータベースの使用をサポートしています。また、ストアがSQL接続文字列を使用するように構成されている場合、Microsoft SQL Serverインスタンスに接続することもできます。
StoreFrontをESENTではなくSQLを使用するように切り替えることの主な利点は、T-SQLのUPDATEステートメントを使用して、サブスクリプションレコードを管理、変更、または削除できることです。SQLを使用すると、サブスクリプションデータでわずかな変更が実行されるたびにESENTサブスクリプションデータ全体をエクスポート、変更、再インポートする必要はありません。
既存のサブスクリプションデータをESENTからMicrosoft SQL Serverに移行するには、StoreFrontからエクスポートされたESENTのフラットデータを、一括インポート用のSQLフレンドリーな形式に変換する必要があります。新しいサブスクリプションデータのない新しい展開の場合、この手順は不要です。データ変換手順が必要なのは一度だけです。ここでは、参照している-STF PowerShell SDKが導入されたバージョン3.5以降のすべてのStoreFrontバージョンで使用できる、サポート対象の構成について説明します。
注：
ネットワークの停止が原因でStoreFrontがサブスクリプションデータを保存するために使用するSQL Serverインスタンスへの接続に失敗した場合、StoreFront展開は利用不能として表示されません。停止は、ユーザーエクスペリエンスを一時的に低下させるだけです。ユーザーは、SQL Serverへの接続が復元されるまで、お気に入りのリソースを追加、削除、または表示できません。リソースは、停止でも列挙および起動できます。予測される動作は、ESENTの使用中にCitrix Subscription Storeサービスが停止する場合と同じです。
ヒント：
リソースがKEYWORDS:AutoまたはKEYWORDS:Mandatoryで構成されていると、ESENTまたはSQLで両方を使用する場合と同じように動作します。いずれかのKEYWORDがユーザーのリソースに含まれている場合、ユーザーが最初にログオンすると、新しいSQLサブスクリプションレコードが自動的に作成されます。
ESENTおよびSQL Serverの利点
| ESENT | SQL |
|---|---|
| デフォルト。StoreFrontを「そのまま」使用するため追加構成は不要です。 | 非常に管理しやすい。T-SQLクエリを使用してサブスクリプションデータを簡単に操作または更新できます。ユーザーごとのレコードを削除または更新可能。アプリケーション、Delivery Controller、またはユーザーごとに簡単にレコードをカウントできます。企業/組織から離職したユーザーの不要なユーザーデータを簡単に削除できます。管理者がアグリゲーションの使用に切り替えたときや、新しいDelivery Controllerがプロビジョニングされたときなど、Delivery Controllerの参照を簡単に更新できます。 |
| サブスクリプションの同期と取得スケジュールを使用して、異なるサーバーグループ間でレプリケーションを簡単に構成できます。 「サブスクリプション同期の構成」を参照してください。 | StoreFrontから切り離されているため、StoreFrontをアップグレードする前にサブスクリプションデータをバックアップする必要はありません。データは別のSQL Serverで維持されます。サブスクリプションのバックアップはStoreFrontに依存せず、SQLのバックアップ戦略とメカニズムを使用します。 |
| サブスクリプション管理が不要な場合、SQLは不要です。サブスクリプションデータを更新する必要がない場合、ESENTの方が顧客のニーズに適している可能性が高くなります。 | サーバーグループのすべてのメンバーが共有するサブスクリプションデータの単一コピー。サーバー間のデータの違いやデータ同期の問題が発生する可能性が低くなります。 |
ESENTおよびSQL Serverの欠点
| ESENT | SQL |
|---|---|
| サブスクリプションデータを簡単かつきめ細かく管理する簡単な手段はありません。エクスポートされた.txtファイルでサブスクリプションの操作を行う必要があります。サブスクリプションデータベース全体をエクスポートおよび再インポートする必要があります。場合によっては、何千ものレコードを検索と置換の手法を使用して変更する必要があります。この手法は手間がかかりエラーの可能性も高くなります。 | 基本的なSQLの専門知識とインフラストラクチャが必要です。SQLライセンスの購入が必要になる場合があり、StoreFront展開の総所有コストが増加します。ただし、Citrix Virtual Apps and DesktopsデータベースインスタンスをStoreFrontと共有してコストを削減することもできます。 |
| サーバーグループ内の各StoreFrontサーバーでESENTデータベースのコピーを保持する必要があります。まれに、このデータベースがサーバーグループ内または異なるサーバーグループ間で同期しなくなることがあります。 | サーバーグループ間でのサブスクリプションデータのレプリケーションは、重要な展開タスクです。複数のSQLインスタンスと、データセンターごとに各インスタンス間のトランザクションのレプリケーションが必要です。これには、MS SQLの専門知識が必要です。 |
| ESENTからのデータ移行およびSQLフレンドリーな形式への変換が必要です。このプロセスが必要なのは一度だけです。 | |
| 追加のWindowsサーバーとライセンスが必要になる場合があります。 | |
| StoreFrontを展開するための追加手順。 |
展開シナリオ
注：
ユーザーサブスクリプションをサポートするには、StoreFront内で構成された各ストアにESENTデータベースまたはMicrosoft SQLデータベースが必要です。サブスクリプションデータの保存方法は、StoreFront内のストアレベルで設定されます。
管理の複雑さを軽減し、構成ミスのスコープを減らすために、すべてのストアデータベースを同じMicrosoft SQL Serverインスタンスに配置することをCitrixではお勧めします。
すべて同じ接続文字列を使用するように構成されていれば、複数のストアで同じデータベースを共有できます。異なるDelivery Controllerを使用していても問題ありません。複数のストアがデータベースを共有することの欠点は、各サブスクリプションレコードがどのストアに対応するかを知る方法がないことです。
複数のストアを持つ単一のStoreFront展開では、技術的には2つのデータストレージ方法の組み合わせが可能です。ESENTを使用するように1つのストアを構成し、別のストアではSQLを使用するように構成できます。これは、管理の複雑さと構成ミスのスコープがあるためお勧めしません。
SQL Serverにサブスクリプションデータを保存する場合、4つのシナリオがあります：
シナリオ1：ESENTを使用する単一のStoreFrontサーバーまたはサーバーグループ（デフォルト）
デフォルトではバージョン2.0以降のStoreFrontのすべてのバージョンは、フラットESENTデータベースを使用して、サーバーグループのメンバー間でサブスクリプションデータを保存および複製します。サーバーグループの各メンバーは、サブスクリプションデータベースの同一のコピーを保持し、これはサーバーグループの他のすべてのメンバーと同期されます。このシナリオでは、追加の構成手順は必要ありません。このシナリオは、Delivery Controllerの名前を頻繁に変更しないお客様や、古いユーザーサブスクリプションの削除や更新など、サブスクリプションデータの管理タスクを頻繁に実行する必要がない大半のお客様に適しています。
シナリオ2：単一のStoreFrontサーバーとローカルMicrosoft SQL Serverインスタンスがインストールされている
StoreFrontはローカルにインストールされたSQL Serverインスタンスを使用します。両方のコンポーネントは同じサーバー上にあります。このシナリオは、Delivery Controllerの名前を頻繁に変更する必要があるお客様や、古いユーザーサブスクリプションの削除や更新など、サブスクリプションデータの管理タスクを頻繁に実行する必要があるものの、高可用性StoreFront展開は必要ないお客様のシンプルな単一StoreFront展開に適しています。このシナリオは、Microsoft SQLデータベースインスタンスをホストするサーバーグループメンバーに単一障害点を作成するため、サーバーグループにはお勧めしません。このシナリオは、大規模なエンタープライズ展開には適していません。
シナリオ3：高可用性用に構成されたStoreFrontサーバーグループおよび専用のMicrosoft SQL Serverインスタンス（推奨）
すべてのStoreFrontサーバーグループメンバーは、同じ専用のMicrosoft SQL ServerインスタンスまたはSQLフェールオーバークラスターに接続します。これは、Citrix管理者がDelivery Controllerの名前を頻繁に変更する必要性や、古いユーザーサブスクリプションの削除や更新など、サブスクリプションデータの管理タスクを頻繁に実行する必要性があり、高可用性が必要とされる大規模なエンタープライズ展開に適したモデルです。
シナリオ4：複数のStoreFrontサーバーグループ、およびサーバーグループごとの各データセンター内の専用Microsoft SQL Serverインスタンス
注：
これは高度な構成です。トランザクションレプリケーションに精通した経験豊富なSQL Server管理者が存在し、正常に展開するために必要なスキルがある場合にのみ実行してください。
これはシナリオ3と同様のシナリオですが、異なるリモートデータセンターで複数のStoreFrontサーバーグループが必要な状況に応じて拡張されています。Citrix管理者は、サブスクリプションデータを同じデータセンター内の異なるサーバーグループ間で同期するか、異なるデータセンター内の異なるサーバーグループ間で同期するかを選択できます。データセンター内の各サーバーグループは、冗長性、フェールオーバー、パフォーマンスのために、専用のMicrosoft SQL Serverインスタンスに接続します。このシナリオでは、Microsoft SQL Server構成とインフラストラクチャに大幅な追加が必要です。サブスクリプションデータとそのSQLトランザクションのレプリケーションは、Microsoft SQLテクノロジに完全に依存しています。
リソース
https://github.com/citrix/sample-scripts/tree/master/storefrontから次のスクリプトをダウンロードできます：
構成スクリプト
-
Set-STFDatabase.ps1 – 各ストアのMS SQL接続文字列を設定します。StoreFrontサーバーで実行します。
-
Add-LocalAppPoolAccounts.ps1 – ローカルStoreFrontサーバーのアプリプールに、SQLデータベースへの読み取りおよび書き込みアクセスを許可します。SQL Serverでシナリオ2を実行します。
-
Add-RemoteSFAccounts.ps1 – サーバーグループ内のすべてのStoreFrontサーバーに、SQLデータベースへの読み取りおよび書き込みアクセスを許可します。SQL Serverでシナリオ3を実行します。
-
Create-StoreSubscriptionsDB-2016.sql – SQLデータベースとスキーマを作成します。SQL Serverで実行します。
データの変換およびインポートスクリプト
-
Transform-SubscriptionDataForStore.ps1 – ESENT内の既存のサブスクリプションデータをインポート用のSQLフレンドリーな形式にエクスポートして変換します。
-
Create-ImportSubscriptionDataSP.sql – ストアドプロシージャを作成してTransform-SubscriptionDataForStore.ps1で変換されたデータをインポートします。Create-StoreSubscriptionsDB-2016.sqlを使用してデータスキーマを作成後、SQL Serverでこのスクリプトを実行します。
SQL ServerでStoreFrontサーバーのローカルセキュリティグループを構成する
シナリオ2：単一のStoreFrontサーバーとローカルMicrosoft SQL Serverインスタンスがインストールされている
Microsoft SQL Serverで<SQLServer>\StoreFrontServersというローカルセキュリティグループを作成し、IIS APPPOOL\DefaultAppPoolおよびIIS APPPOOL\Citrix Receiver for Webの仮想アカウントを追加してローカルにインストールされたStoreFrontがSQLに読み取りおよび書き込みアクセスを許可します。このセキュリティグループは、ストアサブスクリプションデータベーススキーマを作成する.SQLスクリプトで参照されるため、グループ名が一致することを確認してください。
スクリプトAdd-LocalAppPoolAccounts.ps1をダウンロードできます：
Add-LocalAppPoolAccounts.ps1スクリプトを実行する前にStoreFrontをインストールします。このスクリプトは、StoreFrontがインストールされ構成されるまで存在しないIIS APPPOOL\Citrix Receiver for Web仮想IISアカウントを検出する機能に依存するためです。IIS APPPOOL\DefaultAppPoolは、IIS Webサーバーの役割をインストールすることで自動的に作成されます。
# 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-->
SQL Server構成マネージャーを使用して、ローカルSQLインスタンス内の名前付きパイプを有効にします。StoreFrontとSQL Serverのプロセス間通信には名前付きパイプが必要です。
特定のポートまたは動的ポートを使用してSQL Server接続を許可するように、Windowsファイアウォール規則が正しく構成されていることを確認します。使用中の環境でこれを実行する方法について詳しくは、Microsoft社のドキュメントを参照してください。
ヒント：
ローカルSQLインスタンスへの接続に失敗する場合は、localhostまたは接続文字列で使用される
<hostname>が正しいIPv4アドレスに解決されていることを確認します。WindowsはIPv4の代わりにIPv6の使用を試み、localhostのDNS解決はStoreFrontおよびSQL Serverの正しいIPv4アドレスではなく::1を返すことがあります。この問題を解決するために、場合によってはホストサーバーでIPv6ネットワークスタックを完全に無効にする必要があります。
シナリオ3：StoreFrontサーバーグループおよび専用のMicrosoft SQL Serverインスタンス
Microsoft SQL Serverで<SQLServer>\StoreFrontServersと呼ばれるローカルセキュリティグループを作成し、StoreFrontサーバーグループのすべてのメンバーを追加します。このセキュリティグループは、後からSQL内にサブスクリプションデータベーススキーマを作成するCreate-StoreSubscriptionsDB-2016.sqlスクリプトで参照されます。
すべてのStoreFrontサーバーグループのドメインコンピューターアカウントを<SQLServer>\StoreFrontServersグループに追加します。SQL ServerがWindows認証を使用している場合、このグループに登録されているStoreFrontサーバーのドメインコンピューターアカウントのみが、SQLでサブスクリプションレコードを読み書きできます。スクリプトAdd-RemoteSFAccounts.ps1で提供される次のPowerShell関数は、ローカルセキュリティグループを作成し、StoreFrontSQL1およびStoreFrontSQL2という名前の2つのStoreFrontサーバーに追加します。
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-->
Microsoft SQL Server内でストアごとにサブスクリプションデータベーススキーマを構成する
StoreFrontで使用するMicrosoft SQL Serverに名前付きインスタンスを作成します。使用するSQLのバージョンがインストールされている場所、またはそのデータベースファイルが保存されている場所に対応するように、.SQLスクリプト内のパスを設定します。サンプルスクリプトCreate-StoreSubscriptionsDB-2016.sqlはSQL Server 2016 Enterpriseを使用しています。
［データベース］ を右クリックしてから ［新しいデータベース］ を選択し、SQL Server Management Studio（SSMS）を使用して空のデータベースを作成します。
ストアに一致する ［データベース名］ を入力するか、STFSubscriptionsのような異なる名前を選択します。
スクリプトを実行する前に、StoreFront展開環境の各ストアでサンプルスクリプトの参照を変更してStoreFront展開とSQL展開を一致させます。たとえば、次の項目を変更します：
-
作成する各データベースに
USE [STFSubscriptions]のStoreFrontのストア名と一致する名前を付けます。 -
データベースの.mdfファイルと.ldfファイルへのパスを、データベースを保存する場所に設定します。
C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.mdfC:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.ldf -
スクリプト内でSQL Serverの名前への参照を設定します：
CREATE LOGIN [SQL2016\StoreFrontServers] FROM WINDOWS;ALTER LOGIN [SQL2016\StoreFrontServers]
スクリプトを実行します。スキーマが正常に構成されると、次の3つのデータベーステーブルが作成されます：SchemaDetails、Subscription、User。
次のデータベース図は、Create-StoreSubscriptionsDB-2016.sqlスクリプトが作成したサブスクリプションデータベーススキーマです。
各StoreFrontストアのSQL Server接続文字列を構成する
シナリオ1
ヒント：
ESENTデータベースのディスクに保存されている元のサブスクリプションデータは、破棄または削除されません。Microsoft SQL ServerからESENTの使用に戻す場合、ストア接続文字列を削除して、元のデータの使用に切り替えることができます。ストアでSQLが使用されている間に作成された追加のサブスクリプションはESENTに存在せず、ユーザーにはこれらの新しいサブスクリプションレコードは表示されません。元のサブスクリプションレコードはすべて、引き続き存在します。
ストアでのESENTサブスクリプションを再度有効にするには
PowerShell ISEを開き、［管理者として実行］ を選択します。
-UseLocalStorageオプションを使用して、ESENTサブスクリプションを再度有効にするストアを指定します：
$SiteID = 1
$StoreVirtualPath = "/Citrix/Store1"
# Sets SQL DB Connection String
$StoreObject = Get-STFStoreService -SiteID $SiteID -VirtualPath $StoreVirtualPath
# Removes the SQL DB Connection string and reverts back to using ESENT
Set-STFStoreSubscriptionsDatabase -StoreService $StoreObject -UseLocalStorage
Get-STFStoreSubscriptionsDatabase -StoreService $StoreObject
<!--NeedCopy-->
シナリオ2、3、4
PowerShell ISEを開き、［管理者として実行］ を選択します。
$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;"
<!--NeedCopy-->
または
# 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-->
すべてのストアでSQL接続文字列を使用するように構成する場合は、展開内のすべてのストアに対してこのプロセスを繰り返します。
ESENTからMicrosoft SQL Serverに既存のデータを移行する
既存のESENTデータをSQLに移行するには、2段階のデータ変換プロセスが必要です。この一度のみの操作を実行するために役立つ2つのスクリプトが提供されています。StoreFrontの接続文字列とSQLインスタンスが正しく構成されている場合、新しいサブスクリプションはすべてSQL内で正しい形式で自動的に作成されます。移行後、過去のESENTサブスクリプションデータはSQL形式に変換され、ユーザーは以前にサブスクライブしたリソースも表示できます。
例：同じドメインユーザーの4つのSQLサブスクリプション
手順1 Transform-SubscriptionDataForStore.ps1スクリプトを使用して、ESENTデータを一括インポート用のSQLフレンドリー形式に変換する
ESENTデータを変換するStoreFrontサーバーにログインします。
サーバーグループのすべてのメンバーに同じ数のサブスクリプションレコードが含まれている場合、どのメンバーでも使用できます。
PowerShell ISEを開き、［管理者として実行］ を選択します。
スクリプトTransform-SubscriptionDataForStore.ps1を実行すると、<StoreName>.txtファイルがESENTデータベースから現在のユーザーのデスクトップにエクスポートされます。
PowerShellスクリプトは、デバッグを支援し、操作の成功を評価するために処理される各サブスクリプション行に関する詳細なフィードバックを提供します。この処理には時間がかかる場合があります。
変換されたデータはスクリプトが完了した後、現在のユーザーのデスクトップの<StoreName>SQL.txtに書き出されます。このスクリプトは、一意のユーザーレコード数と処理されたサブスクリプションの総数をまとめます。
SQL Serverに移行するストアごとにこの処理を繰り返します。
手順2 T-SQLストアドプロシージャを使用して変換されたデータを一括SQLインポートする
一度に1つのストアのデータのみをインポートする必要があります。
手順1で作成された<StoreName>SQL.txtファイルをStoreFrontサーバーのデスクトップからMicrosoft SQL ServerのC:\にコピーして、SubscriptionsSQL.txtに名前を変更します。
Create-ImportSubscriptionDataSP.sqlスクリプトはT-SQLストアドプロシージャを作成して、サブスクリプションデータを一括インポートします。一意のユーザーごとに重複するエントリが削除されるため、結果のSQLデータは正しく正規化され、正しいテーブルに分割されます。
Create-ImportSubscriptionDataSP.sqlを実行する前に、USE [STFSubscriptions]を変更してストアドプロシージャを作成するデータベースに一致させます。
SQL Server Management Studioを使用してCreate-ImportSubscriptionDataSP.sqlファイルを開き、その中のコードを実行します。このスクリプトはImportSubscriptionDataSPストアドプロシージャを以前に作成したデータベースに追加します。
ストアドプロシージャが正常に作成されると、SQLコンソールに次のメッセージが表示され、ImportSubscriptionDataSPストアドプロシージャがデータベースに追加されます：
Commands completed successfully.
ストアドプロシージャを右クリックして実行し、［ストアドプロシージャの実行］ を選択し ［OK］ をクリックします。
戻り値0は、すべてのデータが正常にインポートされたことを示します。インポートに関する問題はすべてSQLコンソールに記録されます。ストアドプロシージャが正常に実行された後、サブスクリプションレコードの合計数と以下の2つのSQLクエリの結果とともにTransform-SubscriptionDataForStore.ps1が提供する一意のユーザー数を比較します。2つの合計数は一致する必要があります。
変換スクリプトからのサブスクリプションの総数は、SQLから報告される合計数と一致する必要があります。
SELECT COUNT(*) AS TotalSubscriptions
FROM [Subscription]
<!--NeedCopy-->
変換スクリプトからの一意のユーザー数は、SQLから報告されるUserテーブルのレコード数と一致する必要があります。
SELECT COUNT(*) AS TotalUsers
FROM [User]
<!--NeedCopy-->
変換スクリプトで100の一意のユーザーと1000の合計サブスクリプションレコードが表示された場合、移行が成功した後、SQLで同じ2つの数値が表示される必要があります。
StoreFrontにログインして、既存のユーザーがサブスクリプションデータを表示できるかどうかを確認します。ユーザーがリソースをサブスクライブしたり、サブスクリプションを解除したりすると、既存のサブスクリプションレコードがSQLで更新されます。新しいユーザーとサブスクリプションレコードもSQLで作成されます。
手順3 インポートされたデータでT-SQLクエリを実行する
注：
Delivery Controllerの名前はすべて大文字と小文字が区別され、StoreFront内で使用される名前および大文字と小文字に正確に一致する必要があります。
-- 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-->
T-SQLを使用して既存のサブスクリプションレコードを更新または削除する
免責：
すべてのサンプルSQL UPDATEおよびDELETEステートメントは、完全にお客様の責任において使用されます。Citrixは、提供された例を誤って使用したことによるサブスクリプションデータの損失または偶発的な変更について責任を負いません。以下のT-SQLステートメントは、簡単な更新を実行できるようにするためのガイドとして提供されています。サブスクリプションの更新または古いレコードの削除を試みる前に、SQLデータベースの完全バックアップですべてのサブスクリプションデータのバックアップを作成してください。必要なバックアップの実行に失敗すると、データの損失または破損が発生する可能性があります。独自のT-SQL UPDATEまたはDELETEステートメントを実稼働データベースに実行する前に、実際の実稼働データベースから離れてダミーデータまたは実稼働データの冗長コピーでテストします。
注：
Delivery Controllerの名前はすべて大文字と小文字が区別され、StoreFront内で使用される名前および大文字と小文字に正確に一致する必要があります。
-- 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-->