StoreFront

Microsoft SQL Server を使用したサブスクリプションデータの保存

March 9, 2026

寄稿者:

注:

このドキュメントは、MS SQL Server と T-SQL クエリに関する基本的な知識があることを前提としています。管理者は、このドキュメントの手順を実行する前に、SQL Server の構成、使用、および管理に習熟している必要があります。

はじめに

ESENT は、Windows が使用できる組み込みのトランザクションデータベースエンジンです。StoreFront のすべてのバージョンは、デフォルトで組み込みの ESENT データベースの使用をサポートしています。ストアが SQL 接続文字列を使用するように構成されている場合は、Microsoft SQL Server インスタンスに接続することもできます。

StoreFront を ESENT から SQL に切り替える主な利点は、SQL 更新ステートメントを使用してサブスクリプションレコードを簡単に管理、変更、または削除できることです。SQL を使用する場合、サブスクリプションデータに軽微な変更が加えられるたびに、ESENT サブスクリプションデータ全体をエクスポート、変更、再インポートする必要はありません。

既存のサブスクリプションデータを ESENT から Microsoft SQL Server に移行するには、StoreFront からエクスポートされたフラットな ESENT データを、一括インポートに適した SQL フレンドリな形式に変換する必要があります。新しいサブスクリプションデータがない新規展開の場合、この手順は不要です。データ変換手順は一度だけ必要です。

注:

ネットワーク障害により、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 クエリを使用してサブスクリプションデータを簡単に操作または更新できます。ユーザーごとのレコードの削除または更新が可能です。アプリケーション、デリバリーコントローラー、またはユーザーごとのレコードを簡単にカウントできます。会社/組織を離れたユーザーの不要なユーザーデータを簡単に削除できます。管理者がアグリゲーションの使用に切り替えたり、新しいデリバリーコントローラーがプロビジョニングされたりした場合など、デリバリーコントローラーの参照を簡単に更新できます。
サブスクリプションの同期とプルスケジュールを使用して、異なるサーバーグループ間のレプリケーションを構成するのがより簡単です。詳細については、「サブスクリプションの同期の構成」を参照してください。	StoreFront から切り離されているため、データは別の SQL Server で管理されるため、StoreFront のアップグレード前にサブスクリプションデータをバックアップする必要がありません。サブスクリプションのバックアップは StoreFront とは独立しており、SQL のバックアップ戦略とメカニズムを使用します。
サブスクリプション管理が不要な場合、SQL は不要です。サブスクリプションデータが更新される必要がない場合、ESENT は顧客のニーズを満たす可能性が高いです。	サーバーグループのすべてのメンバーで共有されるサブスクリプションデータの単一コピーであるため、サーバー間のデータ差異やデータ同期の問題が発生する可能性が低くなります。

ESENT と SQL Server の欠点

ESENT	SQL
サブスクリプションデータを簡単かつきめ細かく管理する簡単な方法がありません。サブスクリプションの操作は、エクスポートされた .txt ファイルで行う必要があります。サブスクリプションデータベース全体をエクスポートして再インポートする必要があります。数千ものレコードを検索および置換の手法で変更する必要がある可能性があり、これは手間がかかり、エラーが発生しやすいです。	基本的な SQL の専門知識とインフラストラクチャが必要です。SQL ライセンスの購入が必要になる場合があり、StoreFront 展開の総所有コストが増加します。ただし、Citrix Virtual Apps and Desktops データベースインスタンスを StoreFront と共有してコストを削減することもできます。
ESENT データベースのコピーは、サーバーグループ内の各 StoreFront サーバーで維持する必要があります。まれに、このデータベースがサーバーグループ内または異なるサーバーグループ間で同期されなくなることがあります。	サーバーグループ間でサブスクリプションデータをレプリケートすることは、簡単な展開タスクではありません。データセンターごとに複数の SQL インスタンスと、それらの間のトランザクションレプリケーションが必要です。これには、専門的な MS SQL の専門知識が必要です。
	ESENT からのデータ移行と、SQL フレンドリな形式への変換が必要です。このプロセスは一度だけ必要です。
	追加の Windows Server とライセンスが必要になる場合があります。
	StoreFront を展開するための追加手順が必要です。

展開シナリオ

注:

StoreFront 内で構成された各ストアは、ユーザーサブスクリプションをサポートする場合、ESENT データベースまたは Microsoft SQL データベースのいずれかを必要とします。サブスクリプションデータの保存方法は、StoreFront 内のストアレベルで設定されます。

Citrix® は、管理の複雑さを軽減し、誤構成の可能性を減らすために、すべてのストアデータベースが同じ Microsoft SQL Server インスタンスに配置されることを推奨しています。

複数のストアが同じデータベースを共有できますが、その場合、すべて同じ接続文字列を使用するように構成されている必要があります。異なるデリバリーコントローラーを使用しているかどうかは関係ありません。複数のストアがデータベースを共有することの欠点は、各サブスクリプションレコードがどのストアに対応しているかを判別する方法がないことです。

複数のストアを持つ単一の StoreFront 展開で、2 つのデータ保存方法を組み合わせることは技術的に可能です。1 つのストアを ESENT を使用するように構成し、別のストアを SQL を使用するように構成することも可能です。しかし、管理の複雑さが増し、誤構成の可能性が高まるため、これは推奨されません。

SQL Server にサブスクリプションデータを保存するために使用できるシナリオは 4 つあります。

シナリオ 1: ESENT を使用する単一の StoreFront サーバーまたはサーバーグループ (デフォルト)

デフォルトでは、バージョン 2.0 以降の StoreFront のすべてのバージョンは、フラットな ESENT データベースを使用して、サーバーグループのメンバー間でサブスクリプションデータを保存およびレプリケートします。サーバーグループの各メンバーは、サブスクリプションデータベースの同一のコピーを維持し、他のすべてのサーバーグループメンバーと同期されます。このシナリオでは、追加の構成手順は不要です。このシナリオは、デリバリーコントローラー名の頻繁な変更を想定していない、または古いユーザーサブスクリプションの削除や更新などのサブスクリプションデータに対する頻繁な管理タスクを実行する必要がないほとんどの顧客に適しています。

シナリオ 2: 単一の StoreFront サーバーとローカルにインストールされた Microsoft SQL Server インスタンス

StoreFront はローカルにインストールされた SQL Server インスタンスを使用し、両方のコンポーネントは同じサーバー上に存在します。このシナリオは、顧客がデリバリーコントローラー名の頻繁な変更を行う必要がある、または古いユーザーサブスクリプションの削除や更新などのサブスクリプションデータに対する頻繁な管理タスクを実行する必要があるが、高可用性 StoreFront 展開を必要としない、シンプルな単一 StoreFront 展開に適しています。Citrix は、Microsoft SQL データベースインスタンスをホストするサーバーグループメンバーに単一障害点を作成するため、サーバーグループに対してこのシナリオを推奨しません。このシナリオは、大規模なエンタープライズ展開には適していません。

シナリオ 3: StoreFront サーバーグループと高可用性用に構成された専用の Microsoft SQL Server インスタンス (推奨)

すべての StoreFront サーバーグループメンバーは、同じ専用の Microsoft SQL Server インスタンスまたは SQL フェールオーバークラスターに接続します。これは、Citrix 管理者がデリバリーコントローラー名の頻繁な変更を行いたい、または古いユーザーサブスクリプションの削除や更新などのサブスクリプションデータに対する頻繁な管理タスクを実行する必要があり、高可用性を必要とする大規模なエンタープライズ展開に最も適したモデルです。

高可用性用に構成された StoreFront サーバーグループと SQL Server

シナリオ 4: 複数の StoreFront サーバーグループと、サーバーグループごとに各データセンターに専用の Microsoft SQL Server インスタンス

注:

これは高度な構成です。トランザクションレプリケーションに精通しており、正常に展開するために必要なスキルを持つ経験豊富な SQL Server 管理者である場合にのみ試してください。

これはシナリオ 3 と同じですが、異なるリモートデータセンターで複数の StoreFront サーバーグループが必要な状況に拡張されます。Citrix 管理者は、同じデータセンター内または異なるデータセンター内の異なるサーバーグループ間でサブスクリプションデータを同期することを選択できます。データセンター内の各サーバーグループは、冗長性、フェールオーバー、およびパフォーマンスのために、独自の専用 Microsoft SQL Server インスタンスに接続します。このシナリオには、かなりの追加の Microsoft SQL Server 構成とインフラストラクチャが必要です。サブスクリプションデータとその SQL トランザクションをレプリケートするために、完全に Microsoft SQL テクノロジーに依存しています。

各データセンターの複数の StoreFront サーバーグループと SQL Server

リソース

以下のスクリプトは、https://github.com/citrix/sample-scripts/tree/master/storefront からダウンロードして利用できます。

構成スクリプト

Set-STFDatabase.ps1 – 各ストアの MS SQL 接続文字列を設定します。StoreFront サーバーで実行します。
Add-LocalAppPoolAccounts.ps1 – ローカル StoreFront サーバーのアプリプールに SQL データベースへの読み取り/書き込みアクセス権を付与します。シナリオ 2 の場合は SQL Server で実行します。
Add-RemoteSFAccounts.ps1 – サーバーグループ内のすべての StoreFront サーバーに SQL データベースへの読み取り/書き込みアクセス権を付与します。シナリオ 3 の場合は SQL Server で実行します。
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 をインストールしてください。このスクリプトは、IIS APPPOOL\Citrix Receiver for Web 仮想 IIS アカウントを見つける機能に依存しており、このアカウントは StoreFront がインストールおよび構成されるまで存在しません。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)
<!--NeedCopy-->

Write-Host “AppPools added to $LocalGroupName local group” -ForegroundColor “Green”

SQL Server構成マネージャーを使用して、ローカルSQLインスタンス内で名前付きパイプを有効にします。名前付きパイプは、StoreFrontとSQL Server間のプロセス間通信に必要です。

![名前付きパイプが有効なスクリーンショット](/en-us/storefront/current-release/media/manage-deployment/sql-server-named-pipes.png)

特定のポートまたは動的ポートのいずれかを使用して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** スクリプトで後ほど参照されます。

![StoreFrontServersセキュリティグループのスクリーンショット](/en-us/storefront/current-release/media/manage-deployment/sql-server-security-groups.png)

すべてのStoreFrontサーバーグループのドメインコンピューターアカウントを `<SQLServer>\StoreFrontServers` グループに追加します。SQL ServerでWindows認証が使用されている場合、このグループにリストされているStoreFrontサーバーのドメインコンピューターアカウントのみが、SQL内のサブスクリプションレコードを読み書きできます。スクリプト [Add-RemoteSFAccounts.ps1](https://raw.githubusercontent.com/citrix/sample-scripts/master/storefront/Add-RemoteSFAccounts.ps1) で提供されている以下のPowerShell関数は、ローカルセキュリティグループを作成し、StoreFrontSQL1とStoreFrontSQL2という2つのStoreFrontサーバーをそこに追加します。

<!--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")

各ストアでの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.mdf

C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\STFSubscriptions.ldf
スクリプト内のSQL Server名への参照を設定します。

CREATE LOGIN [SQL2016\StoreFrontServers] FROM WINDOWS;

ALTER LOGIN [SQL2016\StoreFrontServers]

スクリプトを実行します。スキーマの構成が成功すると、SchemaDetails、Subscription、User の3つのデータベーステーブルが作成されます。

新しいテーブルが作成されたスクリーンショット

次のデータベース図は、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

シナリオ 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;"

または

# 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

すべてのストアをSQL接続文字列を使用するように構成する場合は、展開内のすべてのストアに対してこのプロセスを繰り返します。

既存のデータをESENTからMicrosoft SQL Serverへ移行

既存のESENTデータをSQLに移行するには、2段階のデータ変換プロセスが必要です。この1回限りの操作を実行するために、2つのスクリプトが提供されています。StoreFrontの接続文字列とSQLインスタンスが正しく構成されている場合、すべての新しいサブスクリプションはSQL内に正しい形式で自動的に作成されます。移行後、過去のESENTサブスクリプションデータはSQL形式に変換され、ユーザーは以前にサブスクライブしたリソースも確認できるようになります。

例: 同じドメインユーザーに対する4つのSQLサブスクリプション

同じドメインユーザーに対する4つのSQLサブスクリプション

ステップ1: Transform-SubscriptionDataForStore.ps1スクリプトを使用したESENTデータのSQL一括インポート向け形式への変換

ESENTデータを変換するStoreFrontサーバーにログオンします。

すべてのサーバーグループメンバーが同じ数のサブスクリプションレコードを含んでいる限り、どのメンバーでも適しています。

PowerShell ISEを開き、管理者として実行を選択します。

スクリプト Transform-SubscriptionDataForStore.ps1 を実行します。これにより、ESENTデータベースから現在のユーザーのデスクトップに <StoreName>.txt ファイルがエクスポートされます。

このPowerShellスクリプトは、処理される各サブスクリプション行について詳細なフィードバックを提供し、デバッグを支援し、操作の成功を評価するのに役立ちます。処理には時間がかかる場合があります。

スクリプトの完了後、変換されたデータは現在のユーザーのデスクトップにある <StoreName>SQL.txt に書き出されます。スクリプトは、一意のユーザーレコードの数と処理されたサブスクリプションの合計数を要約します。

SQLサーバーに移行するすべてのストアに対して、このプロセスを繰り返します。

ステップ2: T-SQLストアドプロシージャを使用した変換済みデータの一括SQLインポート

各ストアのデータは、一度に1つのストアずつインポートする必要があります。

ステップ1で作成した <StoreName>SQL.txt ファイルをStoreFrontサーバーのデスクトップからMicrosoft SQLサーバーの 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コンソールに記録されます。ストアドプロシージャが正常に実行された後、Transform-SubscriptionDataForStore.ps1 が提供するサブスクリプションレコードの合計数と一意のユーザー数を、以下の2つのSQLクエリの結果と比較します。2つの合計は一致するはずです。

変換スクリプトからのサブスクリプションの合計数は、SQLから報告される次の合計数と一致する必要があります。

SELECT COUNT(*) AS TotalSubscriptions
FROM [Subscription]

変換スクリプトからの一意のユーザー数は、SQLから報告されるUserテーブルのレコード数と一致する必要があります。

SELECT COUNT(*) AS TotalUsers
FROM [User]

変換スクリプトが100の一意のユーザーと1000の合計サブスクリプションレコードを示している場合、SQLも移行成功後に同じ2つの数値を示すはずです。

StoreFrontにログオンして、既存のユーザーがサブスクリプションデータを確認できるかどうかをチェックします。既存のサブスクリプションレコードは、ユーザーがリソースをサブスクライブまたはサブスクライブ解除する際にSQLで更新されます。新しいユーザーとサブスクリプションレコードもSQLで作成されます。

ステップ3: インポートされたデータに対するT-SQLクエリの実行

注:

すべてのDelivery Controller名は大文字と小文字を区別し、StoreFront内で使用されている大文字と小文字および名前に正確に一致する必要があります。

-- すべてのSQLサブスクリプションレコードを取得
Use [STFSubscriptions]
SELECT * FROM [Subscription]
SELECT * FROM [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'

-- 特定のユーザー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'

-- 特定のデリバリーコントローラーのすべてのサブスクリプションレコードを取得
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DeliveryController.%'

-- または、集約されたリソースの場合は集約グループの名前を使用
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'

-- 特定のアプリケーションのすべてのサブスクリプションレコードを取得
Use [STFSubscriptions]
SELECT * FROM [Subscription]
WHERE [resource_id] = ' DeliveryController.Application'

T-SQLを使用した既存のサブスクリプションレコードの更新または削除

免責事項:

すべてのSQL更新および削除ステートメントの例は、お客様ご自身の責任において使用してください。Citrixは、提供された例の誤った使用によるサブスクリプションデータの損失または偶発的な変更について責任を負いません。以下のT-SQLステートメントは、簡単な更新を実行するためのガイドとして提供されています。サブスクリプションを更新したり、古いレコードを削除したりする前に、SQLデータベースの完全バックアップですべてのサブスクリプションデータをバックアップしてください。必要なバックアップを実行しないと、データ損失または破損が発生する可能性があります。本番データベースに対して独自のT-SQL UPDATEまたはDELETEステートメントを実行する前に、ダミーデータまたは本番データの冗長コピーで、ライブ本番データベースから離れた場所でテストしてください。

注:

すべてのサイト名は大文字と小文字を区別し、StoreFront内で使用されている大文字と小文字および名前に正確に一致する必要があります。

-- すべてのサブスクリプションで使用されているサイト名を更新
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldSiteName.','NewSiteName.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'

-- マルチサイト集約を有効にした後、resource_idを更新
Use [STFSubscriptions]
UPDATE [Subscription]
SET [resource_id] = REPLACE(resource_id,'OldDeliveryController.','DefaultAggregationGroup.')
WHERE [resource_id] LIKE 'OldDeliveryController.%'

-- 特定のサイトのすべてのサブスクリプションレコードを削除
Use [STFSubscriptions]
DELETE FROM [Subscription]
WHERE [resource_id] LIKE 'site.%'

-- または、集約されたリソースの場合は集約グループの名前を使用
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE 'DefaultAggregationGroup.%'

-- 特定のアプリケーションのすべてのサブスクリプションレコードを削除
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] LIKE '%.Application'

-- 特定のサイト経由で公開されたアプリケーションのすべてのサブスクリプションレコードを削除
Use [STFSubscriptions]
DELETE FROM [Subscription]
FROM [Subscription]
WHERE [resource_id] = 'Site.Application'

-- 特定のユーザーSIDのすべてのサブスクリプションレコードを削除
-- [Subscription]からのレコード削除はカスケードに依存
Use [STFSubscriptions]
DELETE FROM [User]
WHERE [User].[username] = 'S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx'

-- 特定のデータベースからすべてのサブスクリプションデータを削除し、主キーのクラスター化インデックスを0から番号付けを開始するようにリセットします。
-- 細心の注意を払って使用し、ライブ本番データベースでは使用しないでください。
-- データインポートの問題をデバッグする際に、クリーンなデータベースから開始するのに役立ちます。

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

```

このコンテンツの正式なバージョンは英語で提供されています。Cloud Software Groupドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Cloud Software Groupは機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。英語の原文から他言語への翻訳について、精度、信頼性、適合性、正確性、またはお使いのCloud Software Group製品またはサービスと機械翻訳されたコンテンツとの整合性に関する保証、該当するライセンス契約書またはサービス利用規約、あるいはCloud Software Groupとのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。機械翻訳されたコンテンツの使用に起因する損害または問題について、Cloud Software Groupは責任を負わないものとします。

この情報は役に立ちましたか?

Microsoft SQL Server を使用したサブスクリプションデータの保存

March 9, 2026

寄稿者:

March 9, 2026

寄稿者:

この記事の概要

はじめに
SQL Server での StoreFront サーバーのローカルセキュリティグループの構成
各ストアでのMicrosoft SQL Server内のサブスクリプションデータベーススキーマの構成
各StoreFrontストアのSQL Server接続文字列の構成
既存のデータをESENTからMicrosoft SQL Serverへ移行
T-SQLを使用した既存のサブスクリプションレコードの更新または削除

この情報は役に立ちましたか?