説明
ステップ 1: int1 リージョン内のすべてのユーザーに通知し、メンテナンス期間をスケジュールします。
ステップ 2: 初期登録の実行に使用されたサブスクリプションを選択します。
注: 容量モデルを使用するには、int1 リージョンを変更する必要があります。
int1 リージョンの課金モデルと登録名を変更します。
int1 リージョンでは、従量課金制のイメージを使用する多数の Windows 仮想マシンが実行されます。
請求モデル、機能の提供方法を​​変更する、またはインスタンスを再登録する このセクションは、請求モデル、機能の提供方法を​​変更する場合、またはインスタンスを再登録する場合に適用されます。これらすべてのケースで、登録関数を呼び出して新しい値を設定します。最初に現在の登録を削除する必要はありません。
# 登録時に使用したサブスクリプションを選択します
Select-AzSubscription -Subscription '<ポータルからの登録サブスクリプション ID>'
# 新しい BillingModel (または再登録の場合は同じ請求モデル) で登録を再実行しますが、ポータルの他のパラメーター値を使用します Set-AzsRegistration -PrivilegedEndpointCredential $YourCloudAdminCredential -PrivilegedEndpoint
$YourPrivilegedEndpoint -BillingModel '<新しい請求モデル>' -RegistrationName '<ポータルからの登録名>' -ResourceGroupName '<ポータルからの登録リソース グループ>' 手順 3: Set-AzsRegistration コマンドレットを実行します。
Set-AzsRegistration を使用して、Azure Stack Hub を Azure に登録し、マーケットプレイスでのアイテムの提供と使用状況レポートを有効または無効にすることができます。
コマンドレットを実行するには、次のものが必要です。
任意のタイプのグローバル Azure サブスクリプション。
そのサブスクリプションの所有者または共同作成者であるアカウントを使用して Azure PowerShell にサインインするには。
参考: https://learn.microsoft.com/en-us/azure-stack/operator/azure-stack-registration

説明

ボックス 1: https://management.contoso.com
URI にはregion1 を含めないでください。
adminmanagementment ではなく、management を使用してください (以下を参照)。
注: テナントのリソース使用量 API リファレンス
テナントはテナント API を使用して、テナント自身のリソース使用状況データを表示できます。これらの API は、Azure 使用 API と一致しています。
Azure と同様に、Windows PowerShell コマンドレット Get-UsageAggregates を使用して使用状況データを取得できます。
API呼び出し
リクエスト
リクエストにより、リクエストされたサブスクリプションおよびリクエストされた期間の消費量の詳細が取得されます。リクエストボディがありません。
メソッドリクエストURI
得る
https://{armendpoint}/subscriptions/{subId}/providers/Microsoft.Commerce/usageAggregates?reportedStartTim パラメーター
* アームドポイント
Azure Stack Hub 環境の Azure Resource Manager エンドポイント。Azure Stack Hub の規則では、Azure Resource Manager エンドポイントの名前は https://management.{domain-name} の形式になります。たとえば、開発キットの場合、ドメイン名は local.azurestack.external で、Resource Manager エンドポイントは https://management.local.azurestack.external です。
ボックス 2: 22f2d01-...
テナントのサブスクリプション識別子を使用します。
パラメータの続き
* サブID
電話をかけているユーザーのサブスクリプション ID。この API は、単一のサブスクリプションの使用状況をクエリする場合にのみ使用できます。プロバイダーは、プロバイダーのリソース使用状況 API を使用して、すべてのテナントの使用状況をクエリできます。
参照：
https://learn.microsoft.com/en-us/azure-stack/operator/azure-stack-tenant-resource-usage-api

参照：
https://docs.microsoft.com/en-us/azure-stack/operator/azure-stack-configure-dns?view=azs-2008
トピック 2、Litware オフィス
既存の環境
ネットワーク環境
Litware オフィスと Fabrikam オフィスは専用回線を使用して接続します。各オフィスはインターネットに直接接続されています。
アイデンティティ環境
Litware ネットワークには、litwareinc.com という名前の Active Directory フォレストが含まれています。フォレストと litwareinc.com という名前の Azure Active Directory (Azure AD) テナントは、Active Directory フェデレーション サービス (AD FS) を使用して統合されます。Litware にはエンタープライズ認証局 (CA) があります。
Litware の Azure サブスクリプションは、litwareic.com Azure AD テナントに関連付けられています。
Fabrikam には Azure AD テナントもあります。
Azure Stack Hub環境
Litware には、次の 2 つの Azure Stack Hub 統合システムがあります。
ボストンにある完全に運用可能な統合システムは、インターネットに接続されており、次の構成になっています。
- 以下の管理者管理エンドポイントを使用して管理されます。
https://adminportal.eastus.litwareinc.com
- 2 つの専用の大規模 Web ワーカーを備えた Azure App Service デプロイメントがある
- 現在、Azure Stack Hub のバージョン 2005 を使用しています
シカゴに新たに提供された統合システム。インターネットからは切断されており、次の管理者管理エンドポイントを使用して管理されます。 https://adminportal.northcentralus.litwareinc.com データセンター環境 Litware のシカゴ データセンターには、次のインフラストラクチャが含まれています。テーブル。

現在の問題
使用率が高い場合、Web ワーカーの使用率が低いにもかかわらず、ボストンの App Service へのリクエストは失敗します。
要件
計画された変更
Litware は次の変更を実装する予定です。
Event Hubs リソース プロバイダーをボストンの統合システムにデプロイします。
ボストンの Azure Stack Hub ユーザーが Azure Functions を利用できるようにします。
シカゴの統合システムを本番環境に備えて準備します。
技術的要件
Litware では、次の技術要件を特定しています。
ボストンの統合システム上に Azure Functions をサポートするインフラストラクチャを実装します。
Event Hubs リソース プロバイダーをボストンの統合システムにデプロイするために必要な証明書をプロビジョニングします。
シカゴの統合システムの ID プロバイダーを構成します。
シカゴにある統合システムの特権エンドポイント (PEP) の IP アドレスを見つけます。
シカゴの統合システムでのサブスクリプションの作成を制御できるのはオペレーターのみであることを確認します。
シカゴの統合システムの Azure Resource Manager エンドポイントへのアクセスを提供する証明書をプロビジョニングします。
シカゴに統合システムを登録するには、CLIENT1 と CLIENT2 のどの PowerShell 設定を変更する必要があるかを特定します。
Azure Resource Manager を使用して、シカゴの統合システムのリソースのインベントリを作成する管理アプリを実装します。
セキュリティとコンプライアンスの要件
Litware には次のセキュリティおよびコンプライアンスの要件があります。
すべてのインフラストラクチャ ソフトウェアは、ホットフィックスを含む最新バージョンを実行する必要があります。
Litware は証明書の失効を制御する必要があります。
ビジネス要件
Litware は、Fabrikam のユーザーがボストンの統合システム上のワークロードに安全にアクセスできるようにしたいと考えています。
アップデートとホットフィックス
Azure Stack Hub で利用可能な現在の修正プログラムと更新プログラムは次のとおりです。
2005年
2005 ホットフィックス 1
2005 ホットフィックス 2
2005 ホットフィックス 3
2008年
2008 ホットフィックス 1
2008 ホットフィックス 2
2011 (最新バージョン)

1 - 管理者ポータルから、Azure ストレージ アカウントとコンテナーを作成します
2 - 共有アクセス署名 (SAS) を作成する
3 - 特権エンドポイント (PEP) に接続します。
4 - Get-AzureStackLog コマンドレットを実行します。
参照：
https://docs.microsoft.com/en-us/azure-stack/operator/azure-stack-get-azurestacklog?view=azs-2008

説明

Azure Stack Hub 公開キー インフラストラクチャ (PKI) 証明書の要件 Azure Stack Hub には、小規模な Azure Stack Hub サービスと場合によってはテナント VM に割り当てられた、外部からアクセス可能なパブリック IP アドレスを使用するパブリック インフラストラクチャ ネットワークがあります。Azure Stack Hub のデプロイ時には、これらの Azure Stack Hub パブリック インフラストラクチャ エンドポイントに適切な DNS 名を持つ PKI 証明書が必要です。
ボックス 1: 内部証明機関 (CA) からの証明書
Azure Stack Hub インフラストラクチャには、証明書で公開されている認証局の証明書失効リスト (CRL) の場所にネットワーク アクセスできる必要があります。この CRL は http エンドポイントである必要があります。注: 切断された展開の場合、CRL エンドポイントにアクセスできない場合、公的認証局 (CA) によって発行された証明書はサポートされません。
切断された展開では機能が損なわれるか、使用できない機能
Azure Stack Hub は、Azure に接続したときに最適に動作するように設計されているため、切断モードでは一部の機能が損なわれるか、完全に使用できなくなることに注意することが重要です。
プライベート/内部認証局 (CA)
影響なし - 組織内の内部 CA などのプライベート CA によって発行された証明書を展開で使用する場合、CRL エンドポイントへの内部ネットワーク アクセスのみが必要です。インターネット接続は必須ではありませんが、証明書 CDP 拡張機能で定義されている CRL エンドポイントに接続するために必要なネットワーク アクセスが Azure Stack Hub インフラストラクチャにあることを確認する必要があります。
ボックス 2: PFX
Azure Stack Hub のインストールには公開キーと秘密キーの両方が必要であるため、証明書の形式は PFX である必要があります。秘密キーにはローカル マシン キー属性が設定されている必要があります。
参照：
https://learn.microsoft.com/en-us/azure-stack/operator/azure-stack-disconnected-deployment
https://learn.microsoft.com/en-us/azure-stack/operator/azure-stack-pki-certs