Azure Stack Hub のアーカイブ リリースノート

2408 ビルド リファレンス

Azure Stack Hub 2408 更新プログラムのビルド番号は 1.2408.0.19 です。

更新の種類

Azure Stack Hub 2408 更新プログラムのビルドの種類は Full です。 このビルドには、重要なセキュリティ更新プログラムのみが含まれています。

2408 更新プログラムの内部テスト結果に基づく予想稼働時間は次のとおりです。

• 4 ノード: 8 から 28 時間
• 8 ノード: 11 から 30 時間
• 12 ノード: 14 から 34 時間
• 16 ノード: 17 から 40 時間

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いまたは長い期間は一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイムの近似値は 2408 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• 2408 更新プログラムでは、ESv3 と DSv3 VM SKU が導入されます。 これらの新しい SKU は、OS ディスクとデータ ディスクの両方に高い IOPS を提供するように設計されています。 詳細については、「Azure Stack Hub VM SKU」を参照してください。
• また、L40s GPU サポートする 2 つの新しい VM SKU も導入。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hubは定期的に修正プログラムをリリースします。 2005 リリース以降では、新しいメジャー バージョンに更新すると (たとえば、1.2008.x から 1.2102.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

詳細については、サービス ポリシーに関する記事を参照してください。

2408 更新プログラムを適用する前のホットフィックスの前提条件

Azure Stack Hubの 2408 リリースは、次の修正プログラムがインストールされている 2406 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.2406.1.23

2408 更新プログラムを正常に適用した後

新しいメジャー バージョン (1.2108.x から 1.2206.x など) に更新すると、新しいメジャー バージョンの最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

2408 のインストール後、2408 の修正プログラムが後でリリースされた場合は、それらをインストールする必要があります。

• Azure Stack Hub 修正プログラム 1.2408.1.50

2406 ビルド リファレンス

Azure Stack Hub 2406 更新プログラムのビルド番号は 1.2406.0.8 です。

更新の種類

Azure Stack Hub 2406 更新プログラムのビルドの種類は Full です。 このビルドには、重要なセキュリティ更新プログラムのみが含まれています。

2406 更新プログラムには、内部テストに基づいて次の予想されるランタイムがあります。

• 4 ノード: 8 から 28 時間
• 8 ノード: 11 から 30 時間
• 12 ノード: 14 から 34 時間
• 16 ノード: 17 から 40 時間

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いまたは長い期間は一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイムの近似値は 2406 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• 2406 では、Azure Stack Hub Standard Load Balancerの一般提供が発表されます。 Standard Load Balancerでは、バックエンド プール内のスタンドアロン VM、HTTPs プローブ、高可用性ポート、アイドル時の TCP リセットなど、いくつかの新しい負荷分散シナリオが可能になります。
• 2406 では、Azure Container Registry の一般提供が発表されます。 Azure Container Registryは、Windows コンテナー イメージ、Linux コンテナー イメージ、Helm チャート、およびその他の OCI 成果物用のプライベートでセキュリティで保護された、コンピューティングに近いレジストリです。 追加コストなしで、接続されている顧客と切断された顧客の両方が、ユーザー ポータル、PowerShell、Azure CLI、Docker CLI を使用して、コンテナー ワークロードを迅速かつ確実に格納、デプロイ、管理できます。 また、これらの顧客はロールベースのアクセス制御 (RBAC) を割り当て、Webhook を作成することもできます。 Container Registry は完全にサポートされ、Azure Kubernetes Service (AKS) エンジンなど、Azure Stack Hubの他のコンポーネントと完全に統合されました。 Container Registry をインストールするには、 こちらの手順に従います。
• 2406 では、Azure Site Recovery の一般提供が発表されます。 Azure Stack HubのAzure Site Recoveryは、仮想マシン (VM) ワークロードをプライマリ サイトからセカンダリの場所にレプリケートすることで、ビジネス継続性を確保するのに役立ちます。 GA バージョンには、デプロイが簡略化されています (依存関係サービスはありません)。 プレビュー バージョンから GA への移行には、Azure Site Recovery ソリューションを完全に再インストールする必要があることに注意してください (アップグレード パスは使用できません)。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hubは定期的に修正プログラムをリリースします。 2005 リリース以降では、新しいメジャー バージョンに更新すると (たとえば、1.2008.x から 1.2102.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

詳細については、サービス ポリシーに関する記事を参照してください。

修正プログラムの前提条件: 2406 更新プログラムを適用する前

Azure Stack Hubの 2406 リリースは、次の修正プログラムがインストールされている 2311 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.2311.3.62

2406 更新プログラムを正常に適用した後

新しいメジャー バージョン (1.2108.x から 1.2206.x など) に更新すると、新しいメジャー バージョンの最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

2406 のインストール後、2406 の修正プログラムが後でリリースされた場合は、それらをインストールする必要があります。

• Azure Stack Hub 修正プログラム 1.2406.1.19

2311 ビルドのリファレンス

Azure Stack Hub 2311 更新プログラムのビルド番号は 1.2311.1.22 です。

更新の種類

Azure Stack Hub 2311 更新プログラムのビルドの種類は Full です。 このビルドには、重要なセキュリティ更新プログラムのみが含まれています。

2311 更新プログラムには、内部テストに基づいて次の予想されるランタイムがあります。

• 4 ノード: 36 ~ 50 時間
• 8 ノード: 36 ~ 50 時間
• 12 ノード: 50 ~ 80 時間
• 16 ノード: 50 ~ 90 時間

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いまたは長い期間は一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイムの近似値は 2311 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• オペレーター向けの VPN Fast Pathand for users 機能が一般公開されました。 新しい VPN SKU を使用すると、より高いネットワーク スループットが必要なシナリオが可能になります。 この機能の詳細については、ドキュメントを参照してください。
• 2311 では、Azure Stack Hub Standard Load Balancerのパブリック プレビューを発表します。 この機能により、スタンドアロン VM をバックエンド プール、HTTPS プローブ、高可用性ポート、アイドル時の TCP リセットなど、いくつかのシナリオで実現できます。
• Azure Site Recoveryは現在、public preview 段階であり、1 つの依存関係のみを必要とする簡略化されたデプロイ プロセスを備えています。 2024 年初頭の一般提供開始までにこのソリューションをさらに効率化することを目指しています。その時点で、Site Recovery リソース プロバイダー自体を除くすべての依存関係を排除する予定です。 それまでの間は、GA バージョンの強化に役立つパブリック プレビューに関するテストとフィードバックを提供することをお勧めします。 プレビューから GA への移行には、Azure Site Recovery ソリューションを完全に再インストールする必要があることに注意してください (更新プログラムやアップグレード パスは使用できません)。

変更点

• 2311 では、将来の更新プログラムとセキュリティ修正プログラムを簡略化するために、ベース ホスト OS の変更がWindows Server 2022に更新されます。 この変更はファブリックの一部です。 送信接続があるAzure Stack Hub環境では、追加の変更は必要なく、更新プログラムは直接インストールされます。

  重要

  接続されていないお客様は、SQL Server 2019 プロダクト キー (PID) を取得して更新する必要があります。 更新を開始する前に、キーを取得する必要があります。 このキーを取得するには、Microsoft サポートにお問い合わせください。 このキーを指定せずに更新を開始すると、開始直後に更新が失敗し、サポートに問い合わせる "ロール クラウドの準備で例外が発生しました" というメッセージが表示されます。 新しいキーを適用した後、更新プログラムを再開できます。

• Azure Stack Hub 2311 以降では、Azure Stack Development Kit (ASDK) の新しいバージョンはリリースされません。 この決定は、ASDK の大幅な複雑さにつながる内部サービスの変更によるものです。 現在リリースされている ASDK バージョンは、Azure Stack Hub Foundation Core スクリプトAzure-Stack-Hub-Foundation-Core 用など、運用、テスト、またはトレーニングの目的に適しています。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hubは定期的に修正プログラムをリリースします。 2005 リリース以降では、新しいメジャー バージョンに更新すると (たとえば、1.2008.x から 1.2102.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

詳細については、サービス ポリシーに関する記事を参照してください。

Azure Stack Hub修正プログラムは、Azure Stack Hub統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

修正プログラムの前提条件: 2311 更新プログラムを適用する前

Azure Stack Hubの 2311 リリースは、次の修正プログラムがインストールされている 2306 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.2306.4.102

2311 更新プログラムを正常に適用した後

新しいメジャー バージョン (1.2108.x から 1.2206.x など) に更新すると、新しいメジャー バージョンの最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

2311 のインストール後、2311 の修正プログラムが後でリリースされた場合は、それらをインストールする必要があります。

• Azure Stack Hub 修正プログラム 1.2311.3.62

2306 ビルド リファレンス

Azure Stack Hub 2306 更新プログラムのビルド番号は 1.2306.2.47 です。

更新の種類

Azure Stack Hub 2306 更新プログラムのビルドの種類は Full です。 このビルドには、重要なセキュリティ更新プログラムのみが含まれています。

2306 更新プログラムには、内部テストに基づく予想される実行時間が次のように示されています。

• 4 ノード: 8 から 28 時間
• 8 ノード: 11 から 30 時間
• 12 ノード: 14 から 34 時間
• 16 ノード: 17 から 40 時間

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いまたは長い期間は一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイムの近似値は 2306 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• このビルドには、重要な セキュリティ更新プログラムが含まれています。 その他の主な機能の追加はありません。

変更点

• Azure Stack Hub 2306 リリースは、Intel の Broadwell CPU プラットフォームに基づく統合システムにインストールできる最後の主要な更新プログラムです。 2311 (以降) のリリースは、intel によって Broadwell プラットフォームでサポートされていないWindows Server 2022 コード ベースに基づいています。 CPU プロセッサ ファミリまたはハードウェア関連の質問については、 hardware OEM パートナーにお問い合わせください。
• このビルドには、これらの重要な セキュリティ更新プログラムが含まれています。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hubは定期的に修正プログラムをリリースします。 2005 リリース以降では、新しいメジャー バージョンに更新すると (たとえば、1.2008.x から 1.2102.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

詳細については、サービス ポリシーに関する記事を参照してください。

Azure Stack Hub修正プログラムは、Azure Stack Hub統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

修正プログラムの前提条件: 2306 更新プログラムを適用する前

Azure Stack Hubの 2306 リリースは、次の修正プログラムがインストールされている 2301 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.2301.3.97

2306 更新プログラムを正常に適用した後

新しいメジャー バージョン (1.2108.x から 1.2206.x など) に更新すると、新しいメジャー バージョンの最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

2306 のインストール後、2306 の修正プログラムが後でリリースされた場合は、それらをインストールする必要があります。

• Azure Stack Hub 修正プログラム 1.2306.4.98

2301 ビルドのリファレンス

Azure Stack Hub 2301 更新プログラムのビルド番号は 1.2301.2.58 です。

更新の種類

Azure Stack Hub 2301 更新プログラムのビルドの種類は Full です。

2301 更新プログラムには、内部テストに基づいて予測されるランタイムは次の通りです。

• 4 ノード: 8 から 28 時間
• 8 ノード: 11 から 30 時間
• 12 ノード: 14 から 34 時間
• 16 ノード: 17 から 40 時間

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いまたは長い期間は一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイムの近似値は 2301 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• Azure Stack Hubの Azure Site Recovery リソース プロバイダーのパブリック プレビュー リリース。
• 新しいVPN Gateway SKU を使用した VPN Fast Path のパブリック プレビュー リリース。
• 新しい VPN Fast Path ドキュメント は Azure Stack Hub オペレーター および Azure Stack Hub ユーザー 用です。
• 112 GB を超えるメモリを必要とする大規模なデータベース ワークロードをサポートするために、新しい VM サイズの Standard_E20_v3 を追加しました。
• NVIDIA A100 Tensor GPU のサポートが追加されました。 ハードウェアが GPU 要件をサポートできるかどうかを OEM で検証します。
• A100 用の新しい VM シリーズを追加しました。 詳細については、Azure Stack Hub の GPU に関するページを参照してください。
• この更新プログラムには、Azure Stack Hubに Azure Site Recovery を追加するためのプラットフォーム要件がすべて含まれています。 最初に有効にするシナリオは、2 つのAzure Stack Hub リージョン間で VM をレプリケートすることに重点を置いているものです。 Azure Stack Hub上の ASR はアドオン RP であり、Marketplace Management を通じて追加する必要があります。
• オペレーターが、Azure Stack Hub管理ポータルですべてのユーザー サブスクリプションの仮想マシンの状態情報を表示する機能を追加しました。

変更点

• SQL リソース プロバイダー 2.0.13 と MySQL リソース プロバイダー 2.0.13 は、Azure Stack Hub 2301 で導入された UI の破壊的変更に対応するためにリリースされています。 Azure Stack Hubを更新する前に、SQL リソース プロバイダーと MySQL リソース プロバイダーを最新バージョンに更新します。 新しい UI の変更を有効にするには、ブラウザー キャッシュの更新が必要になる場合があります。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hubは定期的に修正プログラムをリリースします。 2005 リリース以降では、新しいメジャー バージョンに更新すると (たとえば、1.2008.x から 1.2102.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

詳細については、サービス ポリシーに関する記事を参照してください。

Azure Stack Hub修正プログラムは、Azure Stack Hub統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

ホットフィックスの前提条件: 2301 更新プログラムを適用する前

Azure Stack Hubの 2301 リリースは、次の修正プログラムがインストールされている 2206 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.2206.2.77

2301 更新プログラムを正常に適用した後

新しいメジャー バージョン (1.2108.x から 1.2206.x など) に更新すると、新しいメジャー バージョンの最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

2301 のインストール後、2301 の修正プログラムが後でリリースされた場合は、それらをインストールする必要があります。

• Azure Stack Hub 修正プログラム 1.2301.3.72

2206 ビルドのリファレンス

Azure Stack Hub 2206 更新プログラムのビルド番号は 1.2206.1.24 です。

更新の種類

Azure Stack Hub 2206 更新プログラムのビルドの種類は Full です。

2206 更新プログラムの実行時間は、内部テストに基づいて次のように予想されます。

• 4 ノード: 8 から 28 時間
• 8 ノード: 11 から 30 時間
• 12 ノード: 14 から 34 時間
• 16 ノード: 17 から 40 時間

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いまたは長い期間は一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイムの近似値は 2206 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• 欧州連合に拠点を置くお客様は、すべてのデータを欧州連合の境界内で保管して処理することを選択できるようになりました。 詳細については、Azure Stack Hub の EU Schrems II イニシアチブを参照してください。
• Azure Stack Hubでは、保存データ暗号化用の BitLocker キーの取得がサポートされるようになりました。 詳細については、「BitLocker 回復キーを取得する」を参照してください。

変更点

• SQL RP V2 と MySQL RP V2 は、アクセスを許可されているサブスクリプションでのみ使用できます。 SQL RP V1 と MySQL RP V1 をまだ使用している場合は、Azure Stack Hub 2206 にアップグレードする前にサポート ケースを開いてアップグレード プロセスを実行することを強くお勧めします。
• このリリースは、Azure Stack Hubのルート証明書の更新をサポートしています。 以前は、シークレットのローテーションではルートのローテーションは行われませんでした。 この更新プログラムをインストールすると、ルート証明書をローテーションできるようになります。 そのためには、有効期限アラートを介して次回通知を受け取る前に、内部シークレット ローテーションを実行します。 ルート証明書のローテーションや内部シークレットのローテーションの実行に失敗すると、スタンプが回復不能になる可能性があります。

修正

• SLB スループットを改善するための修正。
• スケール ユニット ノードの再起動時にストレージ サブシステムへのアクセスを妨げていた問題を修正しました。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hubは定期的に修正プログラムをリリースします。 2005 リリース以降では、新しいメジャー バージョンに更新すると (たとえば、1.2008.x から 1.2102.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

詳細については、サービス ポリシーに関する記事を参照してください。

Azure Stack Hub修正プログラムは、Azure Stack Hub統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

修正プログラムの前提条件: 2206 更新プログラムを適用する前

Azure Stack Hubの 2206 リリースは、次の修正プログラムを使用して 2108 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.2108.2.130

2206 更新プログラムが正常に適用された後

新しいメジャー バージョンに更新すると (たとえば、1.2102.x から 1.2108.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

2206 のインストール後に、2206 の修正プログラムがリリースされた場合は、それらをインストールする必要があります。

• Azure Stack Hub 修正プログラム 1.2206.2.77

2102 ビルドのリファレンス

最新の Azure Stack Hub 2102 更新プログラムのビルド番号は 1.2102.30.97 です。 更新されたビルドと修正プログラムについては、「修正プログラム」セクションを参照してください。

更新の種類

Azure Stack Hub 2102 更新プログラムのビルドの種類は Full です。

2102 更新プログラムのランタイムは、内部テストに基づいて次のように予測されました。

• 4 ノード: 8 から 20 時間
• 8 ノード: 11 から 26 時間
• 12 ノード: 14 から 32 時間
• 16 ノード: 17 から 38 時間

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いまたは長い期間は一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイムの近似値は 2102 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• このリリースには、リモート サポートのパブリック プレビューが含まれています。これにより、Microsoft のサポート プロフェッショナルは、お客様のデバイスにリモート アクセスして、限られたトラブルシューティングと修復を実行できるため、サポート ケースをより迅速に解決できます。 お客様は、同意することでこの機能を有効にすることができ、アクセス レベルとアクセス期間を制御できます。 サポートは、サポート要求が送信された後にのみ、デバイスにアクセスできます。 詳細については、「Remote support for Azure Stack Hub」を参照してください。

• Azure Stack Hub インフラストラクチャ バックアップ サービスでプログレッシブ バックアップがサポートされるようになりました。 この機能により、外部バックアップの場所のストレージ要件を軽減し、外部バックアップ ストア上でのファイルの整理方法を変更することができます。 バックアップ ルート ディレクトリの下のファイルは操作しないことをお勧めします。

• Azure Stack Hubマネージド ディスクでは、使用可能な機能のサブセットを含む Azure Disk API バージョン 2019-07-01 がサポートされるようになりました。

• Azure Stack Hub Storage では、Azure Storage サービス管理 API バージョン 2019-06-01 がサポートされるようになりました。使用可能な機能のサブセットが含まれています。

• Azure Stack Hub管理者ポータルに、容量データを含む GPU 関連の情報が表示されるようになりました。 これには、システムに GPU をインストールする必要があります。

• Azure Stack Hub ユーザー ポータルを使用して、Nvidia T4 を使用して、サポートされているすべての VM サイズをデプロイできるようになりました。

• Azure Stack Hubオペレーターは、管理者ポータルを使用して、Azure Stack Hubでマルチテナントを構成できるようになりました。 詳細については、マルチテナントの構成に関するページをご覧ください。

• Azure Stack Hubオペレーターは、特権エンドポイントを使用して法的通知を構成できるようになりました。 詳細については、「セキュリティコントロールの構成Azure Stack Hubを参照してください。

• 更新プロセスには、詳細なビットマップ修復 (GBR) が導入されています。これは、ストレージ修復プロセス内での最適化で、これにより同期されていないデータが修復されます。 以前のプロセスと比べ、修復されるセグメントが小さいため修復時間が短くなり、全体的な更新時間が短縮されます。 GBR は、2102 のすべての新規デプロイに対して既定で有効になっています。 以前のバージョン (2008) から 2102 に更新すると、更新中に GBR が有効になります。 GBR を使用するには、すべての物理ディスクが正常な状態である必要があるため、追加検証が UpdateReadiness チェックに追加されました。 検証が失敗すると、パッチと更新プログラムが早い段階で失敗します。 その時点で、クラウド管理者は、更新プログラムを再開する前に、ディスクの問題を解決するためのアクションを実行する必要があります。 OEM のフォローアップを行う場合は、「OEM の連絡先情報」をご確認ください。

• Azure Stack Hubでは、新しい Dv3、Ev3、SQL 固有の D シリーズ VM サイズがサポートされるようになりました。

• Azure Stack Hubでは、既存のシステムへの GPU の追加がサポートされるようになりました。 GPU を追加するには、stop-azurestack を実行し、stop-azurestack のプロセスを実行して、GPU を追加します。その後、完了するまで start-azurestack を実行します。 システムに GPU が既に存在する場合は、前に作成したすべての GPU VM の停止-割り当て解除を行い、再起動する必要があります。

• ライブ更新プロセスを使用した OEM 更新時間が短縮されました。

• Azure Stack Hubの AKS エンジンには、次の新機能が追加されました。 詳細については、AKS エンジンのドキュメントのリリース ノートをご覧ください。

  • Ubuntu 18.04 の一般提供。
  • Kubernetes 1.17.17 および 1.18.15 のサポート。
  • 証明書ローテーション コマンドのパブリック プレビュー。
  • CSI Driver Azure Disks パブリック プレビュー。
  • CSI ドライバー NFS のパブリック プレビュー。
  • Azure BLOB のプライベート プレビュー用 CSI ドライバー。
  • T4 Nvidia GPU サポートのプライベート プレビュー。
  • Azure Active Directoryの統合プライベートプレビュー。

改善

• ネットワーク コントローラーのログ保持期間が長くなったため、問題が解決した後も、エンジニアは、効果的なトラブルシューティングに役立つログをより長く使用することができます。
• 更新中にネットワーク コントローラー、ゲートウェイ VM、Load Balancer、ホスト エージェントのログを保持するための機能強化。
• プロビジョニングに失敗した状態によってブロックされたネットワーク リソースの削除ロジックが改善されました。
• XRP メモリが VM あたり 14 GB に、WAS メモリが VM あたり 10 GB に減りました。 合計 VM メモリ占有領域が増えないようにすると、より多くのテナント VM をデプロイできます。
• スタンプと診断の共有上のファイルのスナップショットが提供される、ログの収集 HTML レポートに、収集されたファイル、ロール、リソース プロバイダー、イベントに関する概要情報が表示されるようになりました。これは、ログ収集プロセスの成功率と失敗率を把握するのに役立ちます。
• デプロイ後にログイン バナー テキストのコンテンツを取得および更新するために、特権エンドポイント (PEP) に PowerShell コマンドレット AzSLegalNotice と AzSLegalNotice が追加されました。
• 証明書サービス (ADCS) と CA VM Active Directory Azure Stack Hubから完全に削除されました。 これにより、インフラストラクチャの占有領域が削減され、更新時間を最大 2 時間節約できます。

変更点

• Fabric リソース プロバイダー API で GPU 情報が公開されるようになりました (スケール ユニットで使用できる場合)。
• Azure Stack Hubオペレーターは、PowerShell を使用して GPU パーティション分割比を変更できるようになりました (AMD のみ)。 これには、すべての仮想マシンの割り当てを解除する必要があります。
• このビルドには、新しいバージョンのAzure Resource Managerが含まれています。
• Azure Stack Hub ユーザー ポータルでは、ロード バランサー、ネットワーク セキュリティ グループ、DNS ゾーン、ディスクと VM の作成に全画面表示エクスペリエンスが使用されるようになりました。
• 2102 リリースでは、Windows Admin Center (WAC) はロック解除された PEP セッションからオンデマンドで有効になります。 既定では、WAC は有効になっていません。 有効にするには、 フラグを指定します (例: )。
• オペレーターに表示されないエラー状態の間にログをキャプチャする、強化されたアルゴリズムが、事前ログ収集で使用されるようになりました。 このアルゴリズムにより、正しい診断情報が確実かつ適切なタイミングで収集されるようになります。オペレーターとの対話は不要です。 場合によっては、Microsoft サポートがトラブルシューティングを開始し、問題をより早く解決することができます。 最初のアルゴリズムの改善では、パッチと更新の操作に重点が置かれています。 より多くの操作が最適化され、メリットが増えるため、事前ログ収集を有効にすることをお勧めします。
• Azure Stack Hub インフラストラクチャで使用されるメモリが一時的に 10 GB 増加しています。

修正

• 更新中、内部 DNS ゾーンが同期されなくなり、更新が失敗するという問題を修正しました。 この修正は、修正プログラムによって 2008 と 2005 に移植されました。
• 物理ホスト、ネットワーク コントローラー、ゲートウェイ、ロード バランサー上のログによってディスク領域が使い尽くされるという問題を修正しました。 この修正は 2008 に移植されました。
• ネットワーク コントローラー レイヤー内の孤立したリソースが原因でリソース グループまたは仮想ネットワークの削除が失敗するという問題を修正しました。
• サポートされていない VM サイズ、ND6s_dev サイズが VM サイズ ピッカーから削除されました。
• VM 上で停止-割り当て解除を行うと、VM 上の MTU 構成が削除されるという問題を修正しました。 この動作は、Azureと矛盾していました。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hubは定期的に修正プログラムをリリースします。 2005 リリース以降では、新しいメジャー バージョンに更新すると (たとえば、1.2005.x から 1.2008.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

詳細については、サービス ポリシーに関する記事を参照してください。

Azure Stack Hub修正プログラムは、Azure Stack Hub統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

ホットフィックスの前提条件: 2102 更新プログラムを適用する前

Azure Stack Hubの 2102 リリースは、次の修正プログラムを使用して 2008 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.2008.41.161

2102 更新プログラムが正常に適用された後

新しいメジャー バージョンに更新すると (たとえば、1.2008.x から 1.2102.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

2102 のインストール後に、2102 の修正プログラムがリリースされた場合は、それらをインストールする必要があります。

• Azure Stack Hub 修正プログラム 1.2102.30.148

サポートされているバージョンのリリースノート

サポートされているバージョンのAzure Stack Hubのリリース ノートは、Overview リリース ノート

2108 ビルドのリファレンス

最新の Azure Stack Hub 2108 更新プログラムのビルド番号は 1.2108.2.65 です。 更新されたビルドと修正プログラムについては、「修正プログラム」セクションを参照してください。

更新の種類

Azure Stack Hub 2108 更新プログラムのビルドの種類は Full です。

2108 更新プログラムの実行時間は、内部テストに基づいて次のように予想されます。

• 4 ノード: 8 から 28 時間
• 8 ノード: 11 から 30 時間
• 12 ノード: 14 から 34 時間
• 16 ノード: 17 から 40 時間

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いまたは長い期間は一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイム近似は 2108 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• Azure Stack Hubオペレーターは、VM の GPU クォータを構成できるようになりました。
• Emergency VM Access は、Microsoft サポートに連絡せずにAzure Stack Hubで使用できるようになりました。
• Windows Server 2022はゲスト オペレーティング システムとしてサポートされるようになりました。 Windows Server 2022 VM は、バージョン 2108 以降を実行しているAzure Stack HubのWindows Serverで Automatic Virtual Machine Activation を使用して手動でアクティブ化する必要があります。 以前のバージョンではアクティベートできません。
• このバージョン以降、事前ログ収集が無効になっている場合、事前障害イベントについてキャプチャされたログはローカル環境に保存されます。 ローカル ログには、サポート ケースのコンテキストでのみ Microsoft がアクセスできます。 事前ログ収集の Alert ライブラリに、新しいアラートが追加されました。
• このリリースでは、Azure Kubernetes Service と Azure Container Registry の 2 つの新しいサービスをパブリック プレビューで利用できます。
• AzureStack モジュール 2.2.0 は、Azure Stack Hub バージョン 2108 に合わせてリリースされました。 バージョンの更新には、コンピューティング管理者モジュールの変更と、新しいモジュール および が含まれます。 詳細については、change log を参照してください。
• このリリースでは、テレメトリ データは、Microsoft によって管理および制御されるAzure Storage アカウントにアップロードされます。 テレメトリ サービスAzure Stack Hubhttps://*.blob.core.windows.net/ と https://azsdiagprdwestusfrontend.westus.cloudapp.azure.com/ に接続して、テレメトリ データを Microsoft に正常にアップロードします。 ポート 443 (HTTPS) が開かれている必要があります。 詳細については、「Azure Stack Hub テレメトリ」を参照してください。
• このリリースには、リモート サポートのパブリック プレビューが含まれています。これにより、Microsoft のサポート プロフェッショナルは、お客様のデバイスにリモート アクセスして、限られたトラブルシューティングと修復を実行できるため、サポート ケースをより迅速に解決できます。 お客様は、同意することでこの機能を有効にすることができ、アクセス レベルとアクセス期間を制御できます。 サポートは、サポート要求が送信された後にのみ、デバイスにアクセスできます。 詳細については、「Remote support for Azure Stack Hub」を参照してください。

改善

• 外部 SMB 共有がほぼいっぱいになったときのアラートの説明が、プログレッシブ バックアップに合わせて調整されています。
• アップロードが失敗しないよう、外部 SMB 共有への並列インフラストラクチャ バックアップ リポジトリ アップロードの数が制限されるようになります。
• Node-Inaccessible-for-vm-placement アラートが、host-unresponsive シナリオと hostagent-service-on-node-unresponsive シナリオを区別する複数のアラートに置き換えられました。
• App Service は、アウトバウンド接続の既定の NAT IP を検出できるようになりました。

変更点

• 2108 更新プログラムを開始する前に、更新プログラムが正常に完了できるよう、GPU を使用しているすべての仮想マシンを停止 (割り当て解除) する必要があります。 基になる実装がプールされたリソースなしに変わるため、これは AMD と NVIDIA の GPU に適用されます。
• SQL RP と MySQL RP は、アクセスを許可されているサブスクリプションでのみ使用できます。 これらのリソース プロバイダーを使い始める場合、または以前のバージョンからアップグレードする必要がある場合は、サポート ケースを開くと、Microsoft のサポート エンジニアがデプロイまたはアップグレードのプロセスをお手伝いできます。
• Set-AzSLegalNotice によって、コマンドを実行したときに設定されたキャプションとテキストを含む新しい画面の表示がトリガーされます。 この画面は、ポータルの新しいインスタンスが作成されるたびに表示されます。

修正

• 外部 SMB 共有へのアップロード時に 1 つのリポジトリで障害が発生するとインフラストラクチャのバックアップ全体が失敗する問題を修正しました。
• 複数の GPU を使用する N シリーズ VM の作成が失敗する原因となる問題を修正しました。
• VM 拡張機能をアンインストールすると、既存の VM 拡張機能の保護された設定が消去される問題を修正しました。
• 内部ロード バランサーが外部 IP を使用する原因となる問題を修正しました。
• ポータルからのシリアル ログのダウンロードに関する問題を修正しました。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hubは定期的に修正プログラムをリリースします。 2005 リリース以降では、新しいメジャー バージョンに更新すると (たとえば、1.2005.x から 1.2008.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

修正プログラムについて詳細については、サービス ポリシーに関する記事を参照してください。

Azure Stack Hub修正プログラムは、Azure Stack Hub統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

修正プログラムの前提条件: 2108 更新プログラムを適用する前

Azure Stack Hubの 2108 リリースは、次の修正プログラムを使用して 2102 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.2102.31.153

2108 更新プログラムが正常に適用された後

新しいメジャー バージョンに更新すると (たとえば、1.2102.x から 1.2108.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

2108 のインストール後に、2108 の修正プログラムがリリースされた場合は、それらをインストールする必要があります。

• Azure Stack Hub 修正プログラム 1.2108.2.130

2008年ビルドの参考

最新の Azure Stack Hub 2008 更新プログラムのビルド番号は 1.2008.40.149 です。 更新されたビルドと修正プログラムについては、「修正プログラム」セクションを参照してください。

更新の種類

Azure Stack Hub 2008 更新プログラムのビルドの種類は Full です。

2008 更新プログラム パッケージは、以前の更新プログラムと比較してサイズが大きくなっています。 サイズが大きいため、ダウンロード時間が長くなります。 この更新プログラムは準備中状態の時間が長くなります。オペレーターは以前の更新プログラムよりもこのプロセスの時間が長くなることを想定してください。 2008 年の更新プログラムでは、内部テストで想定されるランタイムが 4 ノード (13 ~ 20 時間、8 ノード: 16 ~ 26 時間、12 ノード: 19 ~ 32 時間、16 ノード: 22 ~ 38 時間) に含まれています。 更新プログラムの正確なランタイムは一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いランタイムまたは長いランタイムは一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイム近似は 2008 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• Azure Stack Hubは VNET ピアリングをサポートするようになりました。これにより、ネットワーク仮想アプライアンス (NVA) なしで VNET を接続できます。 詳細については、新しい VNET ピアリングのドキュメントを参照してください。
• Azure Stack Hub BLOB ストレージを使用すると、ユーザーは不変の BLOB を使用できるようになりました。 コンテナーで不変ポリシーを設定することにより、ビジネス クリティカルなデータ オブジェクトを WORM (Write Once, Read Many) 状態で格納することができます。 このリリースでは、不変ポリシーは REST API またはクライアント SDK によってのみ設定できます。 このリリースでは、追加 BLOB の書き込みもできません。 不変 BLOB の詳細については、「不変ストレージを使用してビジネスに不可欠な BLOB データを保存する」を参照してください。
• Azure Stack Hub Storage では、Azure Storage サービス API バージョン 2019-07-07 がサポートされるようになりました。 新しい REST API バージョンと互換性のあるクライアント ライブラリAzureについては、Azure Stack Hub ストレージ開発ツールを参照してください。 Azure Storage サービス管理 API の場合、2018-02-01 は、使用可能な機能の合計のサブセットを含むサポートを追加しました。
• Azure Stack Hub コンピューティングでは、使用可能な機能のサブセットを含む Azure Compute API バージョン 2020-06-01 がサポートされるようになりました。
• Azure Stack Hubマネージド ディスクでは、使用可能な機能のサブセットを含む Azure Disk API バージョン 2019-03-01 がサポートされるようになりました。
• Azure Stack Hubに接続して、サポート操作中にインフラストラクチャに関する詳細な分析情報を提供できるWindows Admin Centerのプレビュー (中断が必要)。
• デプロイ時に特権エンドポイント (PEP) にログイン バナーを追加する機能。
• より多くの排他的操作バナーがリリースされました。これにより、システムで現在行われている操作の可視性が向上し、ユーザーは他の排他的な操作を開始することが (そして、後で失敗することが) なくなります。
• Azure Stack Hub Marketplace アイテムの製品ページごとに 2 つの新しいバナーが導入されました。 Marketplace のダウンロードに失敗した場合、オペレーターはエラーの詳細を表示し、問題を解決するために推奨される手順を試行できます。
• お客様がフィードバックを提供するための評価ツールがリリースされました。 これにより、Azure Stack Hubはカスタマー エクスペリエンスを測定して最適化できます。
• このAzure Stack Hubのリリースには、Azure Kubernetes Service (AKS) と Azure Container Registry (ACR) のプライベート プレビューが含まれています。 プライベート プレビューの目的は、Azure Stack Hubでの AKS と ACR の品質、機能、ユーザー エクスペリエンスに関するフィードバックを収集することです。
• このリリースには、AKS エンジン v0.55.4 を使用した Azure CNI および Windows コンテナーのパブリック プレビューが含まれています。 API モデルでそれらを使用する方法の例については、 GitHub のこの例を参照してください。
• AKS エンジン v0.55.4 によってデプロイされたクラスターで、>Istio 1.3 のデプロイがサポートされるようになりました。 詳細については、こちらの手順を参照してください。
• AKS エンジン v0.55.4 を使用した private クラスターのデプロイがサポートされるようになりました。
• このリリースには、Azure および Azure Stack Hub Key Vault インスタンスからの sourcing Kubernetes 構成シークレットのサポートが含まれています。

改善

• ネットワーク コントローラーと SLB ホスト エージェントの内部監視が実装されたため、停止状態になったサービスは自動的に修復されます。
• Active Directory フェデレーション サービス (AD FS) (AD FS) は、顧客が独自の AD FS サーバーで交換した後、新しいトークン署名証明書を取得するようになりました。 既に構成されているシステムでこの新機能を利用するには、AD FS 統合を再度構成する必要があります。 詳細については、「 Azure Stack Hub データセンターでの AD FS ID の統合を参照してください。
• インフラストラクチャ ロール インスタンスおよびスケール ユニット ノードでのそれらの依存関係における、スタートアップ プロセスとシャットダウン プロセスの変更。 これらの変更により、Azure Stack Hubの起動とシャットダウンの信頼性が向上します。
• Test-AzureStack 検証ツールの AzSScenarios スイートが、すべての顧客アカウントに多要素認証が適用されている場合にクラウド サービス プロバイダーがこのスイートを正常に実行できるように更新されました。
• ライフサイクル操作中の 29 の顧客向けアラートの抑制ロジックを追加することで、アラートの信頼性が向上しました。
• ログ コレクションの役割、期間、およびステータスの詳細を提供する詳細なログ コレクション HTML レポートを表示できるようになりました。 このレポートは、収集したログの概要をユーザーがまとめやすくなるよう提供されています。 その後、Microsoft カスタマー サポート サービスがレポートを迅速に査定してログ データを評価し、システムの問題をトラブルシューティングして軽減するサポートを行います。
• CPU 使用率やメモリ消費量などのユーザー シナリオにまたがる、障害検知の信頼性向上に貢献する 7 つのモニターが新たに追加されたことで、インフラストラクチャの障害検知範囲が拡張されました。

変更点

• SRP API バージョン 2016-01-0 の supportHttpsTrafficOnly ストレージ アカウント リソースの種類プロパティ 1 および 2016-05-01 は有効になっていますが、このプロパティはAzure Stack Hubではサポートされていません。

• ボリューム容量使用率アラートのしきい値が、80% (警告) と 90% (重大) から、90% (警告) と 95% (重大) に引き上げられました。 詳細については、「記憶域スペースのアラート」を参照してください

• AD Graph の構成手順が、このリリースで変更されます。 詳細については、「 Azure Stack Hub データセンターでの AD FS ID の統合を参照してください。

• Windows Server 2019に定義されている現在のベスト プラクティスに合わせて、Azure Stack Hubは、フェールオーバー クラスタリング制御通信をサポートするために、追加のトラフィック クラスまたは優先順位を使用してサーバー間通信をさらに分離するように変更されています。 これらの変更により、フェールオーバー クラスターの通信の回復性が向上します。 このトラフィック クラスと帯域幅予約の構成は、Azure Stack Hub ソリューションのトップ オブ ラック (ToR) スイッチと、Azure Stack Hubのホストまたはサーバー上の変更によって実現されます。

  これらの変更は、Azure Stack Hub システムのホスト レベルで追加されます。 OEM に連絡して、Top-of-Rack (ToR) ネットワーク スイッチで変更してください。 この ToR の変更は、2008 リリースに更新する前に実行することも、2008 に更新した後に実行することもできます。 詳細については、ネットワーク統合に関するドキュメントを参照してください。

• このビルドでは、GPU 対応の VM サイズ NCas_v4 (NVIDIA T4) が、Azureと一致するように VM サイズ NCasT4_v3 に置き換えられました。 これらはまだポータルに表示されず、Azure Resource Manager テンプレート経由でのみ使用できます。

修正

• 実行中の VM にアタッチされていない NIC の NSG の削除が失敗する問題を修正しました。
• ロード バランサーに関連付けられているパブリック IP の IdleTimeoutInMinutes の値を変更すると、パブリック IP がエラー状態になるという問題を修正しました。
• アタッチされたマネージド ディスクに対して OnlineMigration ではなく、正しく Attached 状態が返されるように、Get-AzsDisk コマンドレットを修正しました。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hubは定期的に修正プログラムをリリースします。 2008 に更新する前に、最新の 2005 修正プログラムをインストールしてください。 また、2005 リリース以降、新しいメジャー バージョンに更新すると (たとえば、1.2005.x から 1.2008.x)、その新しいメジャー バージョン内の最新の修正プログラム (パッケージのダウンロード時に使用可能なものがある場合) が自動的にインストールされます。 これにより 2008 インストールにすべての修正プログラムが適用され、最新の状態になります。 それ以降は、2008 の修正プログラムがリリースされたら、それをインストールする必要があります。

詳細については、サービス ポリシーに関する記事を参照してください。

Azure Stack Hub修正プログラムは、Azure Stack Hub統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

2008 更新プログラムが正常に適用された後

Azure Stack Hub修正プログラムは累積的であるため、ベスト プラクティスとして、メジャー リリース間で最適な更新エクスペリエンスを確保するために、ビルド用にリリースされたすべての修正プログラムをインストールする必要があります。 新しいメジャー バージョンに更新すると (たとえば、1.2005.x から 1.2008.x)、その新しいメジャー バージョン内の最新の修正プログラム (パッケージのダウンロード時に使用可能なものがある場合) が自動的にインストールされます。

2008 のインストール後に、2008 修正プログラムがリリースされた場合は、それらをインストールする必要があります。

• Azure Stack Hub 修正プログラム 1.2008.40.154

2005 アーカイブされたリリース ノート

Azure Stack Hub 2005 更新プログラムのビルド番号は 1.2005.6.53 です。

更新の種類

Azure Stack Hub 2005 更新プログラムのビルドの種類は Full です。

2005 更新プログラム パッケージは、以前の更新プログラムと比較してサイズが大きくなっています。 サイズが大きいため、ダウンロード時間が長くなります。 この更新プログラムは準備中状態の時間が長くなります。オペレーターは以前の更新プログラムよりもこのプロセスの時間が長くなることを想定してください。 2005 年の更新プログラムでは、内部テストで想定されるランタイムが 4 ノード、13 ~ 20 時間、8 ノード: 16 ~ 26 時間、12 ノード: 19 ~ 32 時間、16 ノード: 22 ~ 38 時間でした。 更新プログラムの正確なランタイムは一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いランタイムまたは長いランタイムは一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイム近似は 2005 年の更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• このビルドでは、NCv3 (Nvidia V100)、NVv4 (AMD MI25)、NCas_v4 (NVIDIA T4) VM サイズの 3 つの新しい GPU VM の種類がサポートされます。 VM のデプロイは、適切なハードウェアを持ち、Azure Stack Hub GPU プレビュー プログラムにオンボードされているユーザーに対して成功します。 関心がある場合は、 で GPU プレビュー プログラムにサインアップしてください。 詳細については、参照してください。
• このリリースには、エラーを検出し、影響を評価して、システムの問題を安全に軽減する自律復旧機能を有効にする新機能が用意されています。 この機能により、Microsoft は手動による介入なしでシステムの可用性を向上させることを目指しています。 リリース 2005 以降では、アラートの数が減少します。 このパイプラインでエラーが発生した場合、通知されない限り、Azure Stack Hubオペレーターによるアクションは必要ありません。
• Azure Stack Hub管理ポータルには、ローカルにログを保存するための、エアギャップまたは切断されたAzure Stack Hubのお客様向けの新しいオプションがあります。 Azure Stack HubがAzureから切断されている場合は、ローカル SMB 共有にログを格納できます。
• システム操作が既に進行中の場合、Azure Stack Hub管理ポータルによって特定の操作がブロックされるようになりました。 たとえば、更新が進行中の場合、新しいスケール ユニット ノードを追加することはできません。
• このリリースでは、1910 より前に作成された VM 上のAzureとのファブリック整合性が高くなります。 1910 年、Microsoft は、新しく作成されたすべての VM がワイヤサーバー プロトコルを使用すると発表しました。これにより、お客様はAzureと同じ WALA エージェントとWindowsゲスト エージェントを使用できるようになり、Azure Stack HubでAzureイメージを簡単に使用できるようになります。 今回のリリースでは、1910 より前に作成されたすべての VM が、wireserver プロトコルを使用するよう自動的に移行されます。 これにより、より信頼性の高い VM の作成、VM 拡張機能のデプロイ、安定状態のアップタイムの向上も実現します。
• Azure Stack Hub ストレージでは、Azure Storage サービス API バージョン 2019-02-02 がサポートされるようになりました。 Azureクライアント ライブラリの場合、新しい REST API バージョンと互換性があります。 詳細については、「Azure Stack Hub ストレージ開発ツールを参照してください。
• Azure Stack Hubでは、最新バージョンの CreateUiDefinition (バージョン 2) がサポートされるようになりました。
• バッチ処理された VM デプロイに関する新しいガイダンス。 詳細については、こちらの記事を参照してください。
• Azure Stack Hub Marketplace CoreOS Container Linux 項目は、その有効期間の終了に近づいている。 詳細については、CoreOS Container Linux からの移行に関するページをご覧ください。

改善

• ストレージ インフラストラクチャ クラスター サービスのログとイベントの機能強化。 ストレージ インフラストラクチャ クラスター サービスのログとイベントは、診断とトラブルシューティングの向上のために最大 14 日間保持されます。
• Azure Stack Hubの開始と停止の信頼性を向上させる機能強化。
• 分散を使用し、依存関係を削除することで、更新プログラムの実行時間を短縮する機能強化。 2002 更新プログラムと比較すると、4 ノードのスタンプ更新時間が、15 から 42 時間から、13 から 20 時間に短縮されます。 8 ノードでの時間は、20～50時間から16～26時間に減少します。 12 ノードでは、20 から 60 時間から、19 から 32 時間に短縮されます。 16 ノードでは、所要時間が 25 ～ 70 時間から 22 ～ 38 時間に短縮されます。 更新プログラムの正確なランタイムは一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。
• 特定の回復不能なエラーが発生した場合、更新が早期に失敗するようになりました。
• インターネットからのダウンロード中に更新プログラム パッケージの回復性が向上しました。
• VM の停止 - 割り当て解除中の回復性が向上しました。
• ネットワーク コントローラーのホスト エージェントの回復性が向上しました。
• 特権エンドポイントと復旧エンドポイントへの接続に使用されるソース IP とアカウントを報告するために、syslog メッセージの CEF ペイロードにフィールドが追加されました。 詳細については、 syslog 転送を使用した監視ソリューションを使用したAzure Stack Hubの統合に関するページを参照してください。
• syslog クライアントを介して出力されるイベントの一覧に、Windows Defender イベント (イベント ID 5001、5010、5012) を追加しました。
• Defender プラットフォームと署名のバージョンの不整合と検出されたマルウェアに対するアクションの実行に失敗した場合に報告するために、Windows Defender 関連のイベントに関するアラートをAzure Stack管理者ポータルに追加しました。
• Azure Stack Hubをデータセンターに統合するときの 4 つのボーダー デバイスのサポートを追加しました。

変更点

• インフラストラクチャ ロール インスタンスを停止、シャットダウン、再起動するアクションが、管理ポータルから削除されました。 また、ファブリック リソース プロバイダーの対応する API も削除されました。 管理者 RM モジュールと az preview for Azure Stack Hubの次の PowerShell コマンドレットは機能しなくなりました:Stop-AzsInfrastructureRoleInstance, Disable-InfrastructureRoleInstance、および Restart-InfrastructureRoleInstance。 これらのコマンドレットは、Azure Stack Hubの次の管理者 AZ モジュール リリースから削除されます。
• Azure Stack Hub 2005 では、Azure Stack Hub 2020 (バージョン 87.x) の App Service のみがサポートされるようになりました。
• セキュリティを強化するために、ハードウェア監視に必要なユーザー暗号化設定が DES から AES に変更されました。 ベースボード管理コントローラー (BMC) の設定を変更する方法については、ハードウェア パートナーにお問い合わせください。 場合によっては、BMC で変更を行った後、特権エンドポイントを使用して Set-BmcCredential コマンドを再実行する必要があります。 詳細については、「Azure Stack Hub のシークレットのローテーション」を参照してください。

修正

• ベース OS イメージへのパスが見つからないためスケール ユニット ノードの修復が失敗する原因となる問題を修正しました。
• スケール ユニット ノードの修復に連鎖的な影響を及ぼすサポート インフラストラクチャ ロールのスケールインとスケールアウトに関する問題を修正しました。
• 管理者ポータル内のすべてのサービス > コンピュート > VM イメージ > 追加において、オペレーターが独自のイメージを追加すると、.VHD 拡張子（.vhdではなく）が許可されなかった問題を修正しました。
• 以前の VM 再起動操作によって、他の VM 更新操作 (ディスク、タグなどの追加) 後に予期しない再起動が発生する問題を修正しました。
• 重複する DNS ゾーンを作成するとポータルが応答しなくなる問題を修正しました。 適切なエラーが表示されるようになりました。
• Get-AzureStackLogs で、ネットワークの問題のトラブルシューティングに必要なログが収集されていない問題を修正しました。
• ポータルで接続が許可される NIC の数が、実際に許可されている数よりも少ないという問題を修正しました。
• 特定の内部ソフトウェアに対して違反イベントが生成されないようにコードの整合性ポリシーを修正しました。 これにより、syslog クライアントによって生成されるコードの整合性違反イベントのノイズが減少します。
• https サービスの再起動またはホストの再起動を求めることなく新しいポリシーを適用するように Set-TLSPolicy コマンドレットを修正しました。
• Linux NTP サーバーを使用したときに管理ポータルで誤ってアラートが生成される問題を修正しました。
• バックアップ コントローラー サービス インスタンスのフェールオーバーによって自動バックアップが無効になる問題を修正しました。
• インフラストラクチャ サービスがインターネットに接続されていないときに内部シークレットのローテーションが失敗する問題を修正しました。
• ユーザーが Azure Stack Hub ポータルを使用してサブスクリプションのアクセス許可を表示できない問題を修正しました。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hubは定期的に修正プログラムをリリースします。 2005 リリース以降では、新しいメジャー バージョンに更新すると (たとえば、1.2002.x から 1.2005.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。 それ以降は、ビルドの修正プログラムがリリースされたら、それをインストールする必要があります。

詳細については、サービス ポリシーに関する記事を参照してください。

Azure Stack Hub修正プログラムは、Azure Stack Hub統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

前提条件: 2005 更新プログラムを適用する前

Azure Stack Hubの 2005 リリースは、次の修正プログラムを使用して 2002 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.2002.66.173

2005 更新プログラムが正常に適用された後

2005 リリース以降では、新しいメジャー バージョンに更新すると (たとえば、1.2002.x から 1.2005.x)、その新しいメジャー バージョン内の最新の修正プログラム (存在する場合) が自動的にインストールされます。

2005 のインストール後に、2005 修正プログラムがリリースされた場合は、それらをインストールする必要があります。

• Azure Stack Hub 修正プログラム 1.2005.35.112

2002 アーカイブされたリリース ノート

この記事では、Azure Stack Hub更新プログラム パッケージの内容について説明します。 この更新プログラムには、Azure Stack Hubの最新リリースの機能強化と修正が含まれています。

更新プログラムの計画

更新プログラムを適用する前に、必ず次の情報を確認してください。

• 更新プログラム適用前後のアクティビティのチェックリスト
• 既知の問題
• 修正プログラム
• セキュリティ更新プログラム

更新プログラムのトラブルシューティングと更新プロセスのヘルプについては、「Azure Stack Hubを参照してください。

更新プログラムのダウンロード

Azure Stack Hub更新プログラム パッケージは、 Azure Stack Hub 更新ダウンローダー ツール を使用してダウンロードできます。

2002 ビルドのリファレンス

Azure Stack Hub 2002 更新プログラムのビルド番号は 1.2002.0.35 です。

更新の種類

Azure Stack Hub 2002 更新プログラムのビルドの種類は Full です。

2002 更新プログラム パッケージは、以前の更新プログラムよりも大きなサイズです。 サイズが大きいため、ダウンロード時間が長くなります。 この更新プログラムは準備中状態の時間が長くなります。オペレーターは以前の更新プログラムよりもこのプロセスの時間が長くなることを想定してください。 2002 年の更新プログラムでは、内部テストで想定されるランタイムが 4 ノード (15 ~ 42 時間、8 ノード: 20 ~ 50 時間、12 ノード: 20 ~ 60 時間、16 ノード: 25 ~ 70 時間) でした。 更新プログラムの正確なランタイムは一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 予想される値より短いランタイムまたは長いランタイムは一般的ではなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイム近似値は 2002 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• AzureRM に基づく Azure Stack Hub 管理者 PowerShell モジュールの新しいバージョン (1.8.1) を使用できます。
• Azure Stack Hub管理者 REST API の新しいバージョンを使用できます。 エンドポイントと破壊的変更の詳細については、API リファレンスでご確認ください。
• 新しいAzure PowerShell テナント モジュールは、2020 年 4 月 15 日にAzure Stack Hub用にリリースされる予定です。 現在使用されているAzure RM モジュールは引き続き機能しますが、ビルド 2002 以降は更新されません。
• 構成された syslog サーバーとの接続の問題を報告するために、Azure Stack Hub管理者ポータルに新しい警告アラートを追加しました。 アラートのタイトルは、The Syslog client encountered a networking issue while sending a Syslog message (syslog クライアントは syslog メッセージの送信中にネットワークの問題を検出しました) です。
• ネットワーク タイム プロトコル (NTP) サーバーとの接続の問題を報告するために、Azure Stack Hub管理者ポータルに新しい警告アラートを追加しました。 アラートのタイトルは、Invalid Time Source on [node name] ([ノード名] の時間ソースが無効です) です。
• Java SDK は、TLS 制限に関連する 2002 年の破壊的変更により、新しいパッケージをリリースしました。 新しい Java SDK 依存関係をインストールする必要があります。 手順については、Java API バージョン プロファイルを参照してください。
• SYSTEM CENTER OPERATIONS MANAGERの新しいバージョン (1.0.5.10) - Azure Stack Hub MP が利用可能であり、API の破壊的変更により、2002 を実行しているすべてのシステムに必要です。 この API の変更は、バックアップとストレージのパフォーマンス ダッシュボードに影響します。最初にすべてのシステムを 2002 に更新してから MP を更新することをお勧めします。

改善

• この更新プログラムには、今後の完全な更新のパフォーマンスを大幅に向上させる更新プロセスの変更が含まれています。 これらの変更は、2002 リリース後の次の完全な更新で有効になり、特にホスト オペレーティング システムが更新される完全な更新のフェーズのパフォーマンスを向上させます。 ホスト オペレーティング システムの更新のパフォーマンスを向上させると、完全な更新中にテナントのワークロードが影響を受ける時間が大幅に短縮されます。
• Azure Stack Hub適合性チェッカー ツールは、AD Graph に割り当てられているすべての TCP IP ポートを使用して AD Graph 統合を検証するようになりました。
• オフライン シンジケーション ツールは、信頼性に関する機能強化によって更新されました。 このツールはGitHubでは使用できなくなり、PowerShell ギャラリー。 詳細については、「Download Marketplace items to Azure Stack Hub」を参照してください。
• 新しい監視機能が導入されています。 物理ホストとインフラストラクチャ VM のディスク領域の不足アラートはプラットフォームによって自動修復され、このアクションが失敗した場合にのみ、オペレーターがアクションを実行するために、Azure Stack Hub管理者ポータルにアラートが表示されます。
• 診断ログの収集に対する改善。 新しいエクスペリエンスでは、BLOB ストレージ アカウントを事前に構成する必要がなくなるため、診断ログの収集が合理化されて簡素化されます。 ストレージ環境が事前構成されるため、サポート ケースを開く前にログを送信でき、サポート コールにかかる時間が短縮されます。
• 事前ログ収集とオンデマンドのログ収集の両方にかかる時間が 80% 削減されました。 ログ収集時間はこの予想値より長くなる可能性がありますが、ログ収集が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。
• 更新プログラムの開始後、Azure Stack Hub更新プログラム パッケージのダウンロードの進行状況が更新ブレードに表示されるようになりました。 これは、自動ダウンロードを使用して更新パッケージをprepareすることを選択する接続されたAzure Stack Hubシステムにのみ適用されます。
• ネットワーク コントローラーのホスト エージェントの信頼性に関する機能強化。
• 修正プログラムや更新プログラムを適用中の内部 DNS サービスの回復性ロジックを向上させる、DNS Orchestrator と呼ばれる新しいマイクロサービスが導入されました。
• VM の作成中にブート診断ストレージ アカウントパラメーターの無効な BLOB URI をエラーとする新しい要求検証を追加しました。
• VM の CRUD 操作を容易にするホスト上の 2 つのサービスである Rdagent とホスト エージェントの自動修復とログ作成の機能強化が追加されました。
• Azure Stackバージョンや課金モデルなど、さまざまなプロパティにより、管理者がAzure Stackと互換性のないマーケットプレース製品をダウンロードできないようにする属性を Microsoft が Marketplace 管理に追加しました。 これらの属性を追加できるのは Microsoft だけです。 詳細については、「ポータルを使用して Marketplace 項目をダウンロードする」を参照してください。

変更点

• 管理者ポータルは、操作が進行中かどうかを示すようになり、Azure Stack リージョンの横にアイコンが表示されます。 アイコンの上にマウスポインターを置くと、操作の名前が表示されます。 これにより、何時間も実行されることがあるバックアップ ジョブやストレージの拡張など、実行中のシステム バックグラウンド操作を識別することができます。

• 次の管理者 API が非推奨となりました。

  リソース プロバイダー	リソース	バージョン
  Microsoft.Storage.Admin	農場	2015-12-01-プレビュー
  Microsoft.Storage.Admin	農場/買収	2015-12-01-プレビュー
  Microsoft.Storage.Admin	ファーム/シェア	2015-12-01-プレビュー
  Microsoft.Storage.Admin	農場/ストレージアカウント	2015-12-01-プレビュー

• 次の管理者 API は、新しいバージョン (2018-09-01) に置き換えられました。

  リソース プロバイダー	リソース	バージョン
  Microsoft.Backup.Admin	バックアップ場所	2016-05-01
  Microsoft.Backup.Admin	バックアップ	2016-05-01
  Microsoft.Backup.Admin	操作	2016-05-01

• PowerShell を使用して Windows VM を作成する場合は、vm に拡張機能をデプロイする場合は、必ず provisionvmagent フラグを追加してください。 このフラグがない場合、VM はゲスト エージェントなしで作成され、VM 拡張機能をデプロイする機能が削除されます。

  $VirtualMachine = Set-AzureRmVMOperatingSystem `
     -VM $VirtualMachine `
     -Windows `
     -ComputerName "MainComputer" `
     -Credential $Credential -ProvisionVMAgent
  

修正

• 仮想マシンの同じ NIC に複数のパブリック IP を追加すると、インターネット接続の問題が発生する問題を修正しました。 これで、2 つのパブリック IP を持つ NIC は正常に動作するようになります。
• Azure AD ホーム ディレクトリを構成する必要があることを示すアラートがシステムによって発生する問題を修正しました。
• アラートが自動的に閉じない原因となった問題を修正しました。 アラートは、Azure AD ホーム ディレクトリを構成する必要があることを示しましたが、問題が軽減された後も閉じませんでした。
• 更新リソース プロバイダーの内部エラーの結果として、更新準備フェーズ中に更新が失敗する原因となった問題を修正しました。
• シークレットローテーションを実行した後、Azure Stack Hubでアドオンリソースプロバイダーの操作に失敗する問題を修正しました。
• ERCS ロールのメモリ不足によるAzure Stack Hub更新エラーの一般的な原因であった問題を修正しました。
• Azure Stack Hub更新の準備フェーズで、更新プログラムの状態が Installing ではなく Preparing と表示されるバグを修正しました。
• 仮想スイッチ上の RSC 機能で不整合が発生し、ロード バランサーを通過するトラフィックが破棄される問題を修正しました。 RSC 機能は既定で無効化されるようになりました。
• NIC の複数の IP 構成が原因でトラフィックが誤ってルーティングされ、送信接続が妨げられていた問題を修正しました。
• NIC の MAC アドレスがキャッシュされているときに、そのアドレスを別のリソースに割り当てると VM のデプロイ エラーが発生する問題が修正されました。
• RETAIL チャネルWindows VM イメージのライセンスを AVMA によってアクティブ化できない問題を修正しました。
• VM によって要求された仮想コアの数がノードの物理コアと等しい場合に VM が作成されないという問題を修正しました。 VM の仮想コアがノードの物理コアの数以下でも許可されるようになりました。
• ライセンスの種類を "null" に設定して、従量課金制イメージを BYOL に切り替えることができない問題を修正しました。
• VM スケール セットに拡張機能を追加できるようにするために問題を修正しました。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

修正プログラム

Azure Stack Hub定期的に修正プログラムをリリースします。 Azure Stack Hubを 2002 に更新する前に、1910 の最新のAzure Stack Hub修正プログラムをインストールしてください。

Azure Stack Hub修正プログラムは、Azure Stack Hub統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

修正プログラムの詳細については、Azure Stack Hub サービス ポリシーを参照してください。

前提条件: 2002 更新プログラムを適用する前

Azure Stack Hubの 2002 リリースは、次の修正プログラムを使用して 1910 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.1910.84.230

2002 更新プログラムの適用に成功した後

この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。

• Azure Stack Hub 修正プログラム 1.2002.68.177

1910 アーカイブされたリリース ノート

この記事では、Azure Stack Hub更新プログラム パッケージの内容について説明します。 この更新プログラムには、Azure Stack Hubの最新リリースの機能強化と修正が含まれています。

更新プログラムの計画

更新プログラムを適用する前に、必ず次の情報を確認してください。

• 更新プログラム適用前後のアクティビティのチェックリスト
• 既知の問題
• 修正プログラム
• セキュリティ更新プログラム

更新プログラムのトラブルシューティングと更新プロセスのヘルプについては、「Azure Stack Hubを参照してください。

更新プログラムのダウンロード

Azure Stack Hub更新プログラム パッケージは、 Azure Stack Hub 更新ダウンローダー ツール を使用してダウンロードできます。

1910 ビルドのリファレンス

Azure Stack Hub 1910 更新プログラムのビルド番号は 1.1910.0.58 です。

更新の種類

1908 以降、Azure Stack Hub実行される基になるオペレーティング システムがWindows Server 2019に更新されました。 この更新プログラムでは、コアの基本的な機能強化と、Azure Stack Hubに追加の機能を提供する機能が有効になります。

Azure Stack Hub 1910 更新プログラムのビルドの種類は Express です。

1910 更新プログラム パッケージは、以前の更新プログラムと比較してサイズが大きくなっており、ダウンロードにより長い時間がかかります。 更新プログラムは長い時間、準備中状態のままになり、オペレーターは以前の更新プログラムよりもこのプロセスに長い時間がかかることを予想できます。 Azure Stack Hub環境内の物理ノードの数に関係なく、1910 年の更新が完了するまでの予想時間は約 10 時間です。 更新プログラムの正確なランタイムは一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 ランタイムが予想される値より長く持続することは珍しくなく、更新が失敗しない限り、Azure Stack Hub演算子によるアクションは必要ありません。 このランタイム近似は 1910 更新プログラムに固有であり、他のAzure Stack Hub更新プログラムと比較しないでください。

更新プログラムのビルドの種類の詳細については、「manage updates in Azure Stack Hub」を参照してください。

新着情報

• 管理者ポータルでは、リージョンのプロパティ メニューに特権エンドポイントの IP アドレスが表示され、簡単に見つけられるようになりました。 さらに、現在構成されているタイム サーバーと DNS フォワーダーも表示されます。 詳細については、「Azure Stack Hubを参照してください。

• Azure Stack Hubの正常性と監視システムで、エラーが発生した場合にさまざまなハードウェア コンポーネントに対してアラートを生成できるようになりました。 これらのアラートには、追加の構成が必要になります。 詳細については、「Monitor Azure Stack Hub ハードウェア コンポーネント」を参照してください。

• cloud-init Azure Stack Hubのサポート: Cloud-init は、Linux VM を初めて起動する際にカスタマイズするために広く使用されているアプローチです。 cloud-init を使って、パッケージをインストールしてファイルを書き込んだり、ユーザーとセキュリティを構成したりすることができます。 cloud-init は初回起動プロセスの間に呼び出されるので、構成を適用するために追加の手順や必要なエージェントはありません。 マーケットプレースの Ubuntu イメージは、プロビジョニング用の cloud-init をサポートするように更新されました。

• Azure Stack Hubでは、AzureとしてすべてのWindows Azure Linux エージェント バージョンがサポートされるようになりました。

• 新しいバージョンのAzure Stack Hub管理者 PowerShell モジュールを使用できます。

• 2020 年 4 月 15 日に、Azure Stack Hub用の新しいAzure PowerShell テナント モジュールがリリースされました。 現在使用されているAzure RM モジュールは引き続き機能しますが、ビルド 2002 以降は更新されません。

• 特権エンドポイント (PEP) に Set-AzSDefenderManualUpdate コマンドレットを追加し、Azure Stack Hub インフラストラクチャの Windows Defender 定義の手動更新を構成しました。 詳細については、Azure Stack Hub で Windows Defender アンチウイルスを更新するを参照してください。

• 特権エンドポイント (PEP) に Set-AzSDnsForwarder コマンドレットを追加し、Azure Stack Hubの DNS サーバーのフォワーダー設定を変更しました。 DNS の構成の詳細については、「Azure Stack Hub データセンターの DNS 統合を参照してください。

• AKS エンジンを使用する Kubernetes クラスターの管理のサポートを追加しました。 この更新プログラムから、運用環境の Kubernetes クラスターをデプロイできるようになりました。 AKS エンジンによって、以下のことが可能になっています。

  • Kubernetes クラスターのライフ サイクルを管理します。 クラスターの作成、更新、およびスケールを行うことができます。
  • AKS チームと Azure Stack Hub チームによって生成されたマネージド イメージを使用してクラスターを維持します。
  • ネイティブ Azure リソースを使用してクラスターを構築する、Azure Resource Manager統合 Kubernetes クラウド プロバイダーを活用します。
  • 接続または切断されたAzure Stack Hub スタンプでクラスターをデプロイして管理します。
  • Azureハイブリッド機能を使用します。
    • Azure Arcとの統合。
    • Azure Monitor for Containers との統合。
  • AKS エンジンで Windows コンテナーを使用します。
  • Microsoftサポートとエンジニアリングサポートを展開に対して受ける。

改善

• Azure Stack Hubは、以前に更新エラーの原因となった修正プログラムや更新プログラムの問題を自動修復したり、オペレーターがAzure Stack Hub更新プログラムを開始できないようにしたりする機能を強化しました。 その結果、Test-AzureStack -UpdateReadiness グループに含まれるテストの数が減っています。 詳細については、「Validate Azure Stack Hub システム状態を参照してください。 次の 3 つのテストは UpdateReadiness グループに残っています。

  • AzSインフラファイル検証
  • AzSActionPlanStatus
  • AzsStampBMCSummary

• 外部デバイス (USB キーなど) が Azure Stack Hub インフラストラクチャのノードにマウントされたときに報告する監査規則を追加しました。 監査ログは syslog を介して出力され、Microsoft-Windows-Security-Auditing: 6416|プラグ アンド プレイ イベントとして表示されます。 syslog クライアントの構成方法の詳細については、Syslog の転送に関する記事を参照してください。

• Azure Stack Hub内部証明書の 4096 ビット RSA キーに移行します。 内部シークレットのローテーションを実行すると、以前の 2048 ビット証明書は 4096 ビット長の証明書に置き換えられます。 Azure Stack Hub でのシークレットのローテーションの詳細については、「Azure Stack Hub でシークレットをローテーションする」を参照してください。

• Committee on National Security Systems - Policy 15 (CNSSP-15) (安全な情報共有のための公開標準の使用に関するベスト プラクティスが記載されています) に準拠するために、いくつかの内部コンポーネントについて暗号化アルゴリズムの複雑さとキー強度をアップグレードします。 強化された点として、Kerberos 認証用の AES256 と、VPN 暗号化用の SHA384 があります。 CNSSP-15 の詳細については、Committee on National Security Systems の「Policies (ポリシー)」ページを参照してください。

• 上記のアップグレードにより、Azure Stack Hubには IPsec/IKEv2 構成の新しい既定値が追加されました。 Azure Stack Hub側で使用される新しい既定値は次のとおりです。

  IKE フェーズ 1 (メイン モード) のパラメーター

  プロパティ	価値
  IKE のバージョン	IKEv2
  Diffie-hellman グループ	ECP384
  認証方法	事前共有キー
  暗号化とハッシュ アルゴリズム	AES256、SHA384
  SA の有効期間 (時間)	28,800 秒

  IKE フェーズ 2 (クイック モード) のパラメーター

  プロパティ	価値
  IKE のバージョン	IKEv2
  暗号化とハッシュ アルゴリズム (暗号化)	GCMAES256
  暗号化とハッシュ アルゴリズム (認証)	GCMAES256
  SA の有効期間 (時間)	27,000 秒
  SA の有効期間 (キロバイト単位)	33,553,408
  Perfect Forward Secrecy (PFS)	ECP384
  デッド ピア検出	サポートされています

  これらの変更は、既定の IPsec/IKE 提案のドキュメントにも反映されます。

• インフラストラクチャ バックアップ サービスのロジックは、固定のしきい値を利用するのではなく、バックアップに必要な空き領域を計算するように改善されました。 このサービスでは、バックアップのサイズ、アイテム保持ポリシー、予約、および外部ストレージの場所の現在の使用率が使用され、オペレーターに警告を発する必要があるかどうかが決定されます。

変更点

• AzureからAzure Stack Hubにマーケットプレースアイテムをダウンロードする場合、複数のバージョンが存在する場合にアイテムのバージョンを指定できる新しいユーザー インターフェイスがあります。 新しい UI は、接続されたシナリオと切断されたシナリオの両方で使用できます。 詳細については、「マーケットプレースアイテムをAzureからAzure Stack Hubを参照してください。

• 1910 リリース以降、Azure Stack Hub システムは追加の /20 プライベート内部 IP 領域を必要とします。 詳細については、「network integration planning for Azure Stack」を参照してください。

• アップロード手順中に外部ストレージの場所の容量が不足すると、インフラストラクチャ バックアップ サービスによって、部分的にアップロードされたバックアップ データが削除されます。

• インフラストラクチャ バックアップ サービスでは、AAD デプロイのためのバックアップ ペイロードに ID サービスが追加されました。

• Azure Stack Hub PowerShell モジュールは、1910 リリースのバージョン 1.8.0 に更新されました。
  変更内容:

  • 新しい DRP 管理モジュール: デプロイ リソース プロバイダー (DRP) を使用すると、リソース プロバイダーの調整されたデプロイをAzure Stack Hubできます。 これらのコマンドは、DRP と対話するためにAzure Resource Manager レイヤーと対話します。
  • BRP:
    - Azure Stack インフラストラクチャ バックアップの 1 つのロールの復元をサポートします。
    - パラメーター をコマンドレット に追加します。
  • FRP: API バージョン でのドライブ リソースと リソースに関する破壊的変更。 機能は、Azure Stack Hub 1910 以降でサポートされています。
    - 、、、および の値が変更されました。
    - リソースの新しいプロパティ 、、、 がサポートされるようになりました。
    - リソースのプロパティ および は廃止されました。代わりに を使用してください。

修正

• Azure Stack Hub 1904 リリースより前に展開された環境で TLS 1.2 ポリシーを適用できなくなる問題を修正しました。
• SSH の承認を有効にして作成された Ubuntu 18.04 VM では、SSH キーを使用してサインインできない問題を修正しました。
• 仮想マシン スケール セットの UI から [パスワードのリセット] を削除しました。
• ポータルからロード バランサーを削除しても、インフラストラクチャ レイヤーにあるオブジェクトが削除されない問題を修正しました。
• 管理者ポータル上でゲートウェイ プール使用率アラートの割合が正しく表示されない問題を修正しました。

セキュリティ更新プログラム

Azure Stack Hubのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack Hub セキュリティ更新プログラムを参照してください。

このリリースの Qualys 脆弱性レポートは、Qualys Web サイトからダウンロードできます。

修正プログラム

Azure Stack Hub定期的に修正プログラムをリリースします。 Azure Stack Hubを 1910 に更新する前に、1908 の最新のAzure Stack Hub修正プログラムをインストールしてください。

Azure Stack Hub修正プログラムは、Azure Stack Hub統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

前提条件: 1910 更新プログラムを適用する前

Azure Stack Hubの 1910 リリースは、次の修正プログラムを使用して 1908 リリースに適用する必要があります。

• Azure Stack Hub 修正プログラム 1.1908.51.133

1910 更新プログラムの適用に成功した後

この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、サービス ポリシーに関する記事を参照してください。

• Azure Stack Hub 修正プログラム 1.1910.63.186

1908年 アーカイブ済みリリースノート

統合システムAzure Stack適用

この記事では、Azure Stack の更新プログラム パッケージの内容を説明します。 この更新プログラムには、このリリースのAzure Stack向けに追加された新機能、改善、および修正が含まれています。

別のバージョンのリリース ノートにアクセスするには、左側の目次の上部にあるバージョン セレクターのドロップダウンを使用します。

更新プログラムの計画

更新プログラムを適用する前に、必ず次の情報を確認してください。

• 既知の問題
• セキュリティ更新プログラム
• 更新プログラム適用前後のアクティビティのチェックリスト

更新プログラムのトラブルシューティングと更新プロセスのヘルプについては、「Azure Stackを参照してください。

1908 ビルドのリファレンス

Azure Stack 1908 更新プログラムのビルド番号は 1.1908.4.33 です。

更新の種類

1908 年の場合、Azure Stackが実行される基になるオペレーティング システムがWindows Server 2019に更新されました。 これにより、コアおよび基本的な強化が可能になるとともに、近い将来Azure Stackに追加の機能を提供することができるようになります。

Azure Stack 1908 更新プログラムのビルドの種類は Full です。 そのため、1908 更新プログラムは、1906 や 1907 のような高速更新プログラムよりもランタイムが長くなります。 完全な更新の正確なランタイムは、通常、Azure Stack インスタンスに含まれるノードの数、テナント ワークロードによってシステムで使用される容量、システムのネットワーク接続 (インターネットに接続されている場合)、システムハードウェアの構成によって異なります。 1908 更新プログラムには、内部テストで想定されるランタイムが含まれています。4 ノード - 42 時間、8 ノード - 50 時間、12 ノード - 60 時間、16 ノード - 70 時間。 これらの予想値よりも長く続く更新ランタイムは一般的ではなく、更新が失敗しない限り、Azure Stack演算子によるアクションは必要ありません。

更新プログラムのビルドの種類の詳細については、 Azure Stack。

• 更新プログラムの正確な実行時間は一般に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの構成に左右されます。
• ランタイムが予想よりも長く持続することは珍しくなく、更新が失敗しない限り、Azure Stack演算子によるアクションは必要ありません。
• このランタイム近似は 1908 更新プログラムに固有であり、他のAzure Stack更新プログラムと比較しないでください。

新着情報

• 1908 年の場合、Azure Stackが実行される基になるオペレーティング システムがWindows Server 2019に更新されていることに注意してください。 これにより、コアおよび基本的な強化が可能になるとともに、近い将来Azure Stackに追加の機能を提供することができるようになります。
• Azure Stack インフラストラクチャのすべてのコンポーネントが FIPS 140-2 モードで動作するようになりました。
• Azure Stackオペレーターがポータルのユーザー データを削除できるようになりました。 詳細については、「Azure Stack からの Clear portal ユーザー データ」を参照してください。

改善

• 物理ノードのハードウェアトラステッド プラットフォーム モジュール (TPM) にシークレットを保持するためのAzure Stackの保存データ暗号化の機能強化。

変更点

• ハードウェア プロバイダーは、AZURE STACK バージョン 1908 と同時に OEM 拡張機能パッケージ 2.1 以降をリリースします。 OEM 拡張機能パッケージ 2.1 以降は、Azure Stack バージョン 1908 の前提条件です。 OEM 拡張機能パッケージ 2.1 以降をダウンロードする方法の詳細については、システムのハードウェア プロバイダーに問い合わせてください。また、OEM 更新プログラムの記事を参照してください。

修正

• 将来のAzure Stack OEM 更新プログラムとの互換性に関する問題と、顧客のユーザー イメージを使用した VM のデプロイに関する問題を修正しました。 この問題は 1907 で見つかり、修正プログラム KB4517473 で修正されました
• OEM ファームウェア更新プログラムに関する問題が修正され、Fabric リングの正常性についての Test-AzureStack での誤診断に関する問題が修正されました。 この問題は 1907 で見つかり、修正プログラム KB4515310 で修正されました
• OEM ファームウェア更新プロセスに関する問題を修正しました。 この問題は 1907 で見つかり、修正プログラム KB4515650 で修正されました

セキュリティ更新プログラム

Azure Stackのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack セキュリティ更新プログラムを参照してください。

更新プログラムのダウンロード

Azure Stack 1908 更新プログラム パッケージは、Azure Stackダウンロード ページ。

修正プログラム

Azure Stack定期的に修正プログラムをリリースします。 Azure Stackを 1908 に更新する前に、1907 の最新のAzure Stack修正プログラムをインストールしてください。

Azure Stack修正プログラムは、Azure Stack統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

前提条件: 1908 更新プログラムを適用する前

Azure Stackの 1908 リリースは、次の修正プログラムを使用して 1907 リリースに適用する必要があります。

• Azure Stack 修正プログラム 1.1907.17.54

Azure Stack 1908 Update には、システムのハードウェア プロバイダーからAzure Stack OEM バージョン 2.1 以降が必要です。 OEM 更新プログラムには、Azure Stack システム ハードウェアのドライバーとファームウェアの更新プログラムが含まれます。 OEM 更新プログラムの適用の詳細については、「Azure Stack オリジナル機器メーカー更新を適用する」を参照してください。

1908 更新プログラムの適用に成功した後

この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、サービス ポリシーに関する記事を参照してください。

• Azure Stack 修正プログラム 1.1908.6.37

1907年保存済みリリースノート

この記事では、Azure Stack の更新プログラム パッケージの内容を説明します。 この更新プログラムには、このリリースのAzure Stack向けに追加された新機能、改善、および修正が含まれています。

別のバージョンのリリース ノートにアクセスするには、左側の目次の上部にあるバージョン セレクターのドロップダウンを使用します。

更新プログラムの計画

更新プログラムを適用する前に、必ず次の情報を確認してください。

• 既知の問題
• セキュリティ更新プログラム
• 更新プログラム適用前後のアクティビティのチェックリスト

更新プログラムのトラブルシューティングと更新プロセスのヘルプについては、「Azure Stackを参照してください。

1907 ビルドのリファレンス

Azure Stack 1907 更新プログラムのビルド番号は 1.1907.0.20 です。

更新の種類

Azure Stack 1907 更新プログラムのビルドの種類は Express です。 更新プログラムのビルドの種類の詳細については、「Azure Stack での更新管理」記事を参照してください。 内部テストに基づいて、1907 更新プログラムが完了するまでの予測所要時間は約 13 時間です。

• 更新プログラムの正確な実行時間は一般に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの構成に左右されます。
• ランタイムが予想よりも長く持続することは珍しくなく、更新が失敗しない限り、Azure Stack演算子によるアクションは必要ありません。
• このランタイム近似は 1907 更新プログラムに固有であり、他のAzure Stack更新プログラムと比較しないでください。

この更新プログラムの内容

新着情報

• 診断ログ収集を容易にし、改善するために、Azure Stack診断ログ収集サービスの一般提供リリース。 Azure Stack診断ログ収集サービスは、診断ログを収集して Microsoft カスタマー サポート サービス (CSS) と共有する簡単な方法を提供します。 この診断ログ収集サービスは、Azure Stack管理者ポータルで新しいユーザー エクスペリエンスを提供します。これにより、オペレーターは、特定の重大なアラートが発生したときにストレージ BLOB への診断ログの自動アップロードを設定したり、必要に応じて同じ操作を実行したりできます。 詳細については、診断ログの収集に関する記事を参照してください。

• Azure Stack検証ツール Test-AzureStack の一部としてのAzure Stack ネットワーク インフラストラクチャ検証の一般提供リリース。 Azure Stackネットワーク インフラストラクチャは、Test-AzureStack の一部となり、Azure Stackのネットワーク インフラストラクチャで障害が発生したかどうかを特定します。 テストでは、Azure Stackソフトウェア定義ネットワークをバイパスして、ネットワーク インフラストラクチャの接続を確認します。 パブリック VIP から構成済みの DNS フォワーダー、NTP サーバー、および ID エンドポイントへの接続が示されます。 さらに、AZURE AD を ID プロバイダーとして使用する場合はAzureへの接続、または ADFS を使用する場合はフェデレーション サーバーへの接続がチェックされます。 詳細については、Azure Stack検証ツールに関する記事を参照してください。

• システムの更新中に、必要に応じて、内部の SQL TLS 証明書をローテーションする、内部シークレットのローテーション プロシージャが追加されました。

改善

• Azure Stack更新ブレードに、アクティブな更新の Last Step Completed 時間が表示されるようになりました。 これは、更新ブレードに移動し、実行中の更新をクリックすると表示されます。 [Last Step Completed]\(最後のステップの完了\) は、[Update run details]\(更新実行の詳細\) セクションにあります。

• Start-AzureStack と Stop-AzureStack オペレーター アクションの改善。 Azure Stackを開始する時間は平均で 50%短縮されました。 Azure Stackをシャットダウンする時間が平均で 30%短縮されました。 平均の起動とシャットダウンの時間は、スケールユニットのノード数が増加しても変わりません。

• 切断された Marketplace ツールのエラー処理が改善されました。 Export-AzSOfflineMarketplaceItem を使用した場合に、ダウンロードが失敗するか、部分的に成功した場合、エラーと軽減手順 (存在する場合) に関する詳細を示す詳細なエラーメッセージが表示されます。

• 大きなページ BLOB/スナップショットからのマネージド ディスク作成のパフォーマンスが向上しました。 以前は、大容量ディスクの作成時にタイムアウトが発生しました。

• 予期しない仮想ディスクのデタッチを避けるために、ノードをシャットダウンする前の仮想ディスクの正常性チェックが改善されました。

• 管理者操作のための内部ログのストレージが改善されました。 その結果、内部ログ プロセスのメモリとストレージの消費量を最小限に抑えることで、管理者の操作中にパフォーマンスと信頼性が向上します。 また、管理者ポータルの更新ブレードのページ読み込み時間が短縮される可能性もあります。 この改善の一環として、6 か月を経過した更新ログはシステムで使用できなくなります。 これらの更新のログが必要な場合は、1907 更新を実行する前に、6 か月より前のすべての更新の実行の概要をダウンロードしてください。

変更点

• Azure Stack バージョン 1907 には、バージョン 1908 に更新する前に、システムの OEM パッケージをバージョン 2.1 以降に更新するようにオペレーターに指示する警告アラートが含まれています。 OEM 更新プログラムAzure Stack適用する方法の詳細については、「Azure Stackの製造元の更新プログラムを適用するを参照してください。

• Azure Stack の診断ログ収集サービスの通信を有効にする新しい送信ルール (HTTPS) を追加しました。 詳細については、「Azure Stack データセンターの統合 - エンドポイントの発行に関するページを参照してください。

• 外部ストレージの場所の容量が不足している場合、インフラストラクチャ バックアップ サービスによって、部分的にアップロードされたバックアップが削除されるようになりました。

• インフラストラクチャのバックアップに、ドメイン サービス データのバックアップが含まれなくなりました。 これは、ID プロバイダーとしてAzure Active Directoryを使用するシステムにのみ適用されます。

• [コンピューティング] [VM イメージ] ブレードに取り込まれたイメージが、ページ BLOB の種類であることを検証するようになりました。

修正

• Resource Manager テンプレートにおいて、発行元、オファー、SKU が大文字と小文字の区別があるとして扱われていた問題を修正しました。画像パラメーターが発行元、オファー、SKU と同じ大文字小文字でない限り、画像はデプロイ用にフェッチされませんでした。

• ストレージ サービス メタデータのバックアップ中のタイムアウトのため、PartialSucceeded エラー メッセージでバックアップが失敗する問題を修正しました。

• ユーザー サブスクリプションを削除すると、リソースが孤立する問題を修正しました。

• オファーの作成時に説明フィールドが保存されなかった問題を修正しました。

• 読み取り専用のアクセス許可を持つユーザーが、リソースの作成、編集、および削除を行うことができる問題を修正しました。 これで、共同作成者のアクセス許可が割り当てられている場合にのみ、ユーザーはリソースを作成できるようになりました。

• WMI プロバイダー ホストによって DLL ファイルがロックされるために更新が失敗する問題を修正しました。

• 更新サービスで、更新タイルまたはリソース プロバイダーで、使用可能な更新が表示されない問題を修正しました。 この問題は 1906 で見つかり、修正プログラム KB4511282 で修正されました。

• 不正な構成によって、管理プレーンが異常になるために、更新が失敗する可能性のある問題を修正しました。 この問題は 1906 で見つかり、修正プログラム KB4512794 で修正されました。

• ユーザーがマーケットプレースからサードパーティのイメージのデプロイを実行できない問題を修正しました。 この問題は 1906 で見つかり、修正プログラム KB4511259 で修正されました。

• ユーザー イメージ マネージャー サービスのクラッシュのため、管理対象イメージからの VM の作成が失敗する可能性がある問題を修正しました。 この問題は 1906 で見つかり、修正プログラム KB4512794 で修正されました

• アプリ ゲートウェイ キャッシュが想定どおりに更新されないために VM CRUD 操作が失敗することがある問題を修正しました。 この問題は 1906 で見つかり、修正プログラム KB4513119 で修正されました

• 管理ポータルでリージョンおよびアラート ブレードの可用性に影響を与えていたヘルスリソースプロバイダーの問題を修正しました。 この問題は 1906 で見つかり、修正プログラム KB4512794 で修正されました。

セキュリティ更新プログラム

Azure Stackのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack セキュリティ更新プログラムを参照してください。

更新プログラムのダウンロード

Azure Stack 1907 更新プログラム パッケージは、Azure Stackダウンロード ページ。

修正プログラム

Azure Stack定期的に修正プログラムをリリースします。 Azure Stackを 1907 に更新する前に、1906 の最新のAzure Stack修正プログラムをインストールしてください。

Azure Stack修正プログラムは、Azure Stack統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

1907 更新プログラムを適用する前

Azure Stackの 1907 リリースは、次の修正プログラムを使用して 1906 リリースに適用する必要があります。

• Azure Stack 修正プログラム 1.1906.15.60

1907 更新プログラムの適用に成功した後

この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、サービス ポリシーに関する記事を参照してください。

• Azure Stack 修正プログラム 1.1907.17.54

1906 アーカイブ版リリースノート

この記事では、Azure Stack の更新プログラム パッケージの内容を説明します。 この更新プログラムには、このリリースのAzure Stack向けに追加された新機能、改善、および修正が含まれています。

別のバージョンのリリース ノートにアクセスするには、左側の目次の上部にあるバージョン セレクターのドロップダウンを使用します。

更新プログラムの計画

更新プログラムを適用する前に、必ず次の情報を確認してください。

• 既知の問題
• セキュリティ更新プログラム
• 更新プログラム適用前後のアクティビティのチェックリスト

更新プログラムのトラブルシューティングと更新プロセスのヘルプについては、「Azure Stackを参照してください。

1906 ビルドのリファレンス

Azure Stack 1906 更新プログラムのビルド番号は 1.1906.0.30 です。

更新の種類

Azure Stack 1906 更新プログラムのビルドの種類は Express です。 更新プログラムのビルドの種類の詳細については、「Azure Stack での更新管理」記事を参照してください。 Azure Stack環境内の物理ノードの数に関係なく、1906 年の更新が完了するまでに予想される時間は約 10 時間です。 更新プログラムの正確なランタイムは一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 ランタイムが予想される値より長く持続することは一般的ではなく、更新が失敗しない限り、Azure Stack演算子によるアクションは必要ありません。 このランタイム近似は 1906 更新プログラムに固有であり、他のAzure Stack更新プログラムと比較しないでください。

この更新プログラムの内容

• すべてのエンドポイントで TLS 1.2 を強制するため、特権エンドポイント (PEP) に Set-TLSPolicy コマンドレットが追加されました。 詳細については、「Azure Stack セキュリティ制御」を参照してください。

• 適用されている TLS ポリシーを取得するため、特権エンドポイント (PEP) に Get-TLSPolicy コマンドレットが追加されました。 詳細については、「Azure Stack セキュリティ制御」を参照してください。

• システムの更新中に、必要に応じて、内部の TLS 証明書をローテーションする、内部シークレットのローテーション プロシージャが追加されました。

• 期限切れ間近のシークレットに関する重大なアラートが無視された場合に、内部シークレットのローテーションを強制することで、内部シークレットの有効期限切れを回避するための保護が追加されました。 これを通常の運用手順として依存しないでください。 シークレットのローテーションは、メンテナンス期間中に計画する必要があります。 詳細については、「Azure Stackシークレットローテーションを参照してください。

• VISUAL STUDIO CODEは、AD FS を使用したAzure Stack展開でサポートされるようになりました。

改善

• 特権エンドポイントの Get-GraphApplication コマンドレットで、現在使用されている証明書の拇印が表示されるようになりました。 これにより、AZURE STACKが AD FS と共に展開される場合のサービス プリンシパルの証明書管理が向上します。

• AD Graph と AD FS の可用性を検証するため、アラートを生成する機能を含む、新しい正常性の監視ルールが追加されました。

• インフラストラクチャ バックアップ サービスを別のインスタンスに移動するときに、バックアップ リソース プロバイダーの信頼性が向上しました。

• メンテナンス期間のスケジュール設定を円滑にするため、均一な実行時間を提供する外部シークレットのローテーション プロシージャのパフォーマンスが最適化されました。

• Test-AzureStack コマンドレットで、有効期限が近づいている (重大なアラート) 内部シークレットについて報告されるようになりました。

• 特権エンドポイントの Register-CustomAdfs コマンドレットで、AD FS に対してフェデレーションの信頼を構成するときに、証明書失効リストのチェックをスキップできるようにする新しいパラメーターが使用できるようになりました。

• 1906 リリースでは、更新プログラムが一時停止していないことが確認できるように、更新プログラムの進行状況の可視性が向上しています。 これにより、[更新] ブレードでオペレーターに表示される更新手順の合計数が増えました。 また、以前の更新プログラムよりも並列で行われる更新手順が増えています。

ネットワークの更新

• DHCP レスポンダーで設定されたリース時間が、Azureと一致するように更新されました。

• リソースのデプロイに失敗したシナリオで、リソース プロバイダーへの再試行回数が改善されました。

• Standard SKU オプションは、現在サポートされていないため、ロード バランサーとパブリック IP の両方から削除されました。

変更点

• ストレージ アカウント エクスペリエンスの作成は、Azureと一致するようになりました。

• 内部シークレットの有効期限のアラート トリガーが変更されました。

  • 警告アラートが、シークレットの有効期限の 90 日前に表示されるようになりました。
  • 重大なアラートが、シークレットの有効期限の 30 日前に表示されるようになりました。

• 用語の一貫性のため、インフラストラクチャ バックアップ リソース プロバイダー内の文字列が更新されました。

修正

• 内部操作エラーでマネージド ディスク VM のサイズ変更が失敗する問題を修正しました。

• ユーザー イメージの作成の失敗により、イメージを管理するサービスが不適切な状態になり、これにより失敗したイメージの削除と新しいイメージの作成がブロックされる問題を修正しました。 これは 1905 修正プログラムでも修正されます。

• 期限切れ間近の内部シークレットのアクティブなアラートが、内部シークレットのローテーションが正常に実行された後に自動的に終了されるようになりました。

• 更新プログラムが 99 時間を超えて実行されていた場合、[更新履歴] タブの更新期間の最初の桁がトリミングされる問題を修正しました。

• [更新] ブレードに、失敗した更新プログラムの [再開] オプションが含まれるようになりました。

• 管理者ポータルとユーザー ポータルで、Docker 拡張機能が検索から誤って返されたが、Azure Stackでは使用できないので、それ以上のアクションを実行できないマーケットプレースの問題を修正しました。

• テンプレートの名前がアンダー スコア ('_') で始まる場合、テンプレートのデプロイ UI でパラメーターが設定されない問題を修正しました。

• 仮想マシン スケール セットの作成エクスペリエンスで、デプロイのオプションとして CentOS-based 7.2 が提供される問題を修正しました。 CentOS 7.2 は、Azure Stackでは使用できません。 Centos 7.5 をデプロイのオプションとして提供するようになりました

• [仮想マシン スケール セット] ブレードからスケール セットを削除できるようになりました。

セキュリティ更新プログラム

Azure Stackのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack セキュリティ更新プログラムを参照してください。

更新プログラムのダウンロード

Azure Stack 1906 更新プログラム パッケージは、Azure Stackダウンロード ページ。

修正プログラム

Azure Stack定期的に修正プログラムをリリースします。 Azure Stackを 1906 に更新する前に、必ず 1905 の最新のAzure Stack修正プログラムをインストールしてください。 更新後、1906 に対して利用可能な修正プログラムがあればインストールします。

Azure Stack修正プログラムは、Azure Stack統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

1906 更新プログラムを適用する前

Azure Stackの 1906 リリースは、次の修正プログラムを使用して 1905 リリースに適用する必要があります。

• Azure Stack ホットフィックス 1.1905.3.48

1906 更新プログラムの適用に成功した後

この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、サービス ポリシーに関する記事を参照してください。

• Azure Stack 修正プログラム 1.1906.15.60

次のステップ

• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。
• Azure Stack統合システムのサービス ポリシーと、システムをサポートされている状態に保つために何を行う必要があるかを確認するには、「Azure Stack サービス ポリシーを参照してください。
• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。

1905 アーカイブ化されたリリースノート

統合システムAzure Stack適用

この記事では、1905 更新プログラム パッケージの内容について説明します。 この更新プログラムには、このリリースのAzure Stack向けに追加された新機能、改善、および修正が含まれています。 この記事には、次の情報が含まれています。

• 新機能、機能強化、修正、およびセキュリティ更新プログラムの説明
• 計画の更新

ビルドのリファレンス

Azure Stack 1905 更新プログラムのビルド番号は 1.1905.0.40 です。

更新の種類

Azure Stack 1905 更新プログラムのビルドの種類は Full です。 そのため、1905 更新プログラムは、1903 や 1904 のような高速更新プログラムよりもランタイムが長くなります。 完全な更新の正確なランタイムは、通常、Azure Stack インスタンスに含まれるノードの数、テナント ワークロードによってシステムで使用される容量、システムのネットワーク接続 (インターネットに接続されている場合)、システムハードウェアの構成によって異なります。 1905 更新プログラムには、内部テストで想定されるランタイムが含まれています。4 ノード - 35 時間、8 ノード - 45 時間、12 ノード - 55 時間、16 ノード - 70 時間。 1905 ランタイムは、これらの予想される値よりも長く持続することは一般的ではなく、更新が失敗しない限り、Azure Stack演算子によるアクションを必要としません。 更新プログラムのビルドの種類の詳細については、 Azure Stack。

この更新プログラムの内容

• この更新プログラムでは、Azure Stackの更新エンジンがスケール ユニット ノードのファームウェアを更新できます。 これには、ハードウェア パートナーからの準拠している更新プログラム パッケージが必要です。 使用できるかどうか詳しくは、ハードウェア パートナーに問い合わせてください。

• Windows Server 2019がサポートされ、Azure Stack Marketplace 経由で配信できるようになりました。 この更新プログラムにより、Windows Server 2019が 2016 ホストで正常にアクティブ化できるようになりました。

• 新しいAzure アカウント用 Visual Studio Code 拡張機能を使用すると、開発者はサブスクリプションにログインして表示できるだけでなく、他の多くのサービスを利用して Azure Stack をターゲットにできます。 Azure アカウント拡張機能は、Azure Active Directory (Azure AD) 環境と AD FS 環境の両方で機能し、Visual Studio Codeユーザー設定を少し変更するだけで済みます。 Visual Studio Codeでは、この環境で実行するために、サービス プリンシパルにアクセス許可が付与されている必要があります。 これを行うには、ID スクリプトをインポートし、Azure StackMulti-tenancy> で指定されたコマンドレットを実行します。 これには、ホーム ディレクトリの更新と、各ディレクトリのゲスト テナント ディレクトリの登録が必要です。 Visual Studio Code サービス プリンシパルが含まれているホーム ディレクトリ テナントを更新するために、1905 以降に更新した後にアラートが表示されます。

改善

• Azure Stackでの TLS 1.2 の適用の一環として、次の拡張機能がこれらのバージョンに更新されました。

  • microsoft.customscriptextension-arm-1.9.3
  • microsoft.iaasdiagnostics-1.12.2.2
  • microsoft.antimalware-windows-arm-1.5.5.9
  • microsoft.dsc-arm-2.77.0.0
  • microsoft.vmaccessforlinux-1.5.2

  これらのバージョンの拡張機能をすぐにダウンロードして、将来のリリースで TLS 1.2 が適用されるときに、拡張機能の新しいデプロイが失敗しないようにしてください。 常に autoUpgradeMinorVersion=true を設定し、拡張機能に対するマイナー バージョンの更新プログラム (たとえば、1.8 から 1.9) が自動的に実行されるようにします。

• Azure Stack ポータルの新しい Help and Support Overview を使用すると、オペレーターはサポート オプションの確認、専門家の支援の取得、Azure Stackの詳細を簡単に確認できます。 統合システムでは、サポート要求を作成すると、Azure Stackサービスが事前に選択されます。 グローバル Azure ポータルを使用するのではなく、このエクスペリエンスを使用してチケットを送信することを強くお勧めします。 詳細については、「Azure Stack ヘルプとサポートを参照してください。

• 複数のAzure Active Directory がオンボードされている場合 (このプロセス)、特定の更新が発生したとき、または Azure AD サービス プリンシパルの承認に対する変更によって権限が失われた場合に、スクリプトの再実行を無視する可能性があります。 これにより、特定の機能に対するアクセスのブロックから、元の問題まで追跡することが困難なさらに個別の障害まで、さまざまな問題が発生する可能性があります。 これを防ぐため、1905 では、これらのアクセス許可をチェックし、特定の構成の問題が見つかったときはアラートを作成する、新しい機能が導入されています。 この検証は 1 時間ごとに実行され、問題を解決するために必要な修復アクションが表示されます。 すべてのテナントが正常な状態になると、アラートは閉じます。

• サービスのフェールオーバーの間の、インフラストラクチャのバックアップ操作の信頼性の向上。

• 認証に Azure Stack Nagios プラグインの新しいバージョンAzure Active Directory認証ライブラリ (ADAL) を使用できます。 このプラグインでは、Azure Stack Azure AD および Active Directory フェデレーション サービス (AD FS) (AD FS) のデプロイもサポートされるようになりました。 詳しくは、Nagios プラグインの交換に関するサイトをご覧ください。

• Azure Stackのすべての最新機能をサポートする新しいハイブリッド プロファイル 2019-03-01-Hybrid がリリースされました。 Azure PowerShellとAzure CLIの両方で、2019-03-01-Hybrid プロファイルがサポートされます。 .NET、Ruby、Node.js、Go、Python SDK には、2019-03-01-Hybrid プロファイルをサポートするパッケージが公開されています。 その変更を反映するように、それぞれのドキュメントといくつかのサンプルが更新されています。

• Node.js SDK では、API プロファイルがサポートされるようになっています。 2019-03-01-Hybrid プロファイルをサポートするパッケージが、公開されます。

• 1905 Azure Stack更新プログラムでは、プラットフォームの信頼性とサポート性を向上させるために、次の 2 つの新しいインフラストラクチャ ロールが追加されました。

  • インフラストラクチャ リング: 将来的には、インフラストラクチャ リングは、現在独自の指定されたインフラストラクチャ VM を必要とする既存のインフラストラクチャ ロール (xrp など) のコンテナー化されたバージョンをホストします。 これにより、プラットフォームの信頼性が向上し、Azure Stackに必要なインフラストラクチャ VM の数が減ります。 これにより、将来的にAzure Stackのインフラストラクチャ ロールの全体的なリソース消費量が削減されます。
  • サポート リング: 将来的には、サポート リングを使用して、お客様のサポート シナリオの強化に対応する予定です。

  さらに、このロールの可用性向上のため、ドメイン コントローラー VM にインスタンスを追加しました。

  これらの変更により、次の方法でAzure Stackインフラストラクチャのリソース消費量が増加します。

  Azure Stack SKU	コンピューティング消費量の増加	メモリ消費量の増加
  4 ノード	22 vCPU（仮想中央処理装置）	28 GB
  8 ノード	38 vCPU（仮想CPU）	44 GB
  12 ノード	54 vCPU	60 GB
  16 ノード	70 仮想CPU（vCPU）	76 GB

変更点

• 計画済みおよび計画外のメンテナンス シナリオ中の信頼性と可用性を向上させるために、Azure Stackはドメイン サービス用のインフラストラクチャ ロール インスタンスを追加します。

• この更新プログラムでは、修復および追加のノード操作の間に、ハードウェアが検証されて、スケール ユニット内のスケール ユニット ノードが同種であることが確認されます。

• スケジュールされたバックアップが完了できず、定義されている保持期間を超えた場合、インフラストラクチャ バックアップ コントローラーにより、少なくとも 1 つの成功したバックアップが保持されていることが確認されます。

修正

• スケール ユニット内のノードの再起動後にコンピューティング ホスト エージェントの警告が表示される問題が修正されました。

• フィルター適用時に正しくない結果が表示され、発行元フィルターで発行元の名前が重複して表示されるという、管理者ポータルでのマーケットプレース管理の問題が修正されました。 また、パフォーマンスが強化されて、結果の表示が速くなりました。

• 外部ストレージの場所へのアップロードが完了する前に、新しい利用可能なバックアップが一覧表示される、利用可能バックアップ ブレードでの問題が修正されました。 利用可能なバックアップは、ストレージの場所に正常にアップロードされた後で、一覧に表示されるようになります。

• バックアップ操作中の回復キーの取得に関する問題が修正されました。

• オペレーター ポータルでバージョンが "未定義" と表示される、OEM 更新プログラムでの問題が修正されました。

セキュリティ更新プログラム

Azure Stackのこの更新プログラムのセキュリティ更新プログラムの詳細については、「Azure Stack セキュリティ更新プログラムを参照してください。

更新プログラムの計画

更新プログラムを適用する前に、必ず次の情報を確認してください。

• 既知の問題
• セキュリティ更新プログラム
• 更新プログラム適用前後のアクティビティのチェックリスト

更新プログラムのダウンロード

Azure Stack 1905 更新プログラム パッケージは、Azure Stackダウンロード ページ。 ダウンローダー ツールを使用する場合は、ダウンロード ディレクトリからキャッシュされたコピーではなく最新バージョンを使用してください。

修正プログラム

Azure Stack定期的に修正プログラムをリリースします。 Azure Stackを 1905 に更新する前に、1904 の最新のAzure Stack修正プログラムをインストールしてください。

Azure Stack修正プログラムは、Azure Stack統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

1905 更新プログラムを適用する前

Azure Stackの 1905 リリースは、次の修正プログラムを使用して 1904 リリースに適用する必要があります。

• Azure Stack 修正プログラム 1.1904.4.45

1905 更新プログラムの適用に成功した後

この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、サービス ポリシーに関する記事を参照してください。

• Azure Stack ホットフィックス 1.1905.3.48

自動更新通知

インフラストラクチャ ネットワークからインターネットにアクセスできるシステムをご利用の場合は、オペレーター ポータルに "利用可能な更新プログラムがあります" というメッセージが表示されます。 インターネットにアクセスできないシステムでは、対応する .xml を含む .zip ファイルをダウンロードしてインポートできます。

次のステップ

• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。
• Azure Stack統合システムのサービス ポリシーと、システムをサポートされている状態に保つために何を行う必要があるかを確認するには、「Azure Stack サービス ポリシーを参照してください。
• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。

1904 アーカイブされたリリース ノート

統合システムAzure Stack適用

この記事では、1904 更新プログラム パッケージの内容について説明します。 この更新プログラムには、このリリースのAzure Stack向けに追加された新機能、改善、および修正が含まれています。 この記事には、次の情報が含まれています。

ビルドのリファレンス

Azure Stack 1904 更新プログラムのビルド番号は 1.1904.0.36 です。

更新の種類

Azure Stack 1904 更新プログラムのビルドの種類は Express です。 更新プログラムのビルドの種類の詳細については、「Azure Stack での更新管理」記事を参照してください。 1904 更新プログラムが完了するまでの予測所要時間は約 16 時間ですが、正確な時間は変わる可能性があります。 このランタイム近似は 1904 更新プログラムに固有であり、他のAzure Stack更新プログラムと比較しないでください。

この更新プログラムの内容

改善

• 1904 では、ソフトウェア定義ネットワーク (SDN) スタックが大幅に強化されました。 これらの機能強化により、Azure Stackでの SDN スタックの全体的なサービスと信頼性が向上します。

• 現在ログインしているユーザーに必要なアクセス許可がない場合の通知を管理者ポータルに追加しました。これで、ダッシュボードを適切に読み込むことができるようになります。 また、デプロイ中に使用された ID プロバイダーに応じて、適切なアクセス許可を持つアカウントについて説明したドキュメントのリンクも含まれています。

• VM の回復性と稼働時間の機能強化が追加されました。これにより、VM の構成ファイルを含むストレージ ボリュームがオフラインになった場合にすべての VM がオフラインになるシナリオが解決されます。

• ネットワークに大きな負荷がかかっている場合の VM の電圧低下または停電に対処するために、同時に退避させる VM の数の最適化を追加し、消費される帯域幅に上限を設定しました。 この変更により、システム更新時の VM の稼働時間が長くなります。

• 内部プロセスによってプラットフォーム リソースがすべて使用され、その結果、ポータルでの操作が失敗することを防ぐために、システムが大規模に実行されているときのリソースの調整機能を強化しました。

• フィルター機能が強化され、オペレーターは同時に複数のフィルターを適用できるようになりました。 新しいユーザー インターフェイスでは [名前] 列のみで並べ替えることができます。

• オファー、プラン、クォータ、およびサブスクリプションの削除プロセスの改良。 削除するオブジェクトに依存関係がない場合は、管理者ポータルからオファー、クォータ、プラン、およびサブスクリプションを正常に削除できるようになりました。 詳細については、 こちらの記事を参照してください。

• 不要なイベントを除外し、転送されるメッセージに目的の重大度を選択する構成パラメーターを用意することで、syslog メッセージの量を改良しました。 重大度レベルを構成する方法の詳細については、「Azure Stack データセンター統合 - syslog 転送」を参照してください。

• 追加のパラメーター を組み込むことで、 コマンドレットに新しい機能を追加しました。 環境からAzure Stackログを収集し、指定したAzure Storage BLOB コンテナーに格納できるようになりました。 詳細については、「Azure Stack diagnostics」を参照してください。

• Test-AzureStack グループに新しいメモリ チェックが追加されました。更新が正常に完了するのに十分なメモリがスタックに存在するかどうかを確認します。

• Service Fabric の正常性を評価するための Test-AzureStack の機能強化。

• ハードウェア更新プログラムの機能強化。ドライブ ファームウェアの更新プログラムを完了するまでにかかる時間が 2 - 4 時間に短縮されました。 更新プログラム エンジンでは、パッケージの内容に基づいて、更新プログラムのどの部分を実行する必要があるかが動的に判断されます。

• 可用性に影響を与える破壊的なインフラストラクチャ ロール インスタンス操作を防ぐために、堅牢な操作の事前チェックを追加しました。

• インフラストラクチャのバックアップ アクション プランのべき等性の改良。

• Azure Stack ログ収集の機能強化。 これらの機能強化により、一連のログの取得にかかる時間が短縮されます。 また、Get-AzureStackLog コマンドレットから OEM ロールの既定のログが生成されなくなりました。 OEM ログを取得するロールを指定して、Invoke-AzureStackOnDemandLog コマンドレットを実行する必要があります。 詳細については、「Azure Stack diagnostics を参照してください。

• Azure Stackは、データセンターと ADFS の統合のために提供されるフェデレーション データ URL を監視するようになりました。 これにより、お客様の ADFS インスタンスまたはファームのシークレット ローテーション中の信頼性が向上します。

変更点

• Azure Stackオペレーターが管理者ポータルでインフラストラクチャ ロール インスタンスをシャットダウンするオプションを削除しました。 再起動機能により、インフラストラクチャ ロール インスタンスを再起動する前にクリーン シャットダウンが確実に試行されます。 高度なシナリオでは、API と PowerShell の機能を引き続き使用できます。

• Marketplace 管理エクスペリエンスが新しくなり、Marketplace イメージ用とリソース プロバイダー用に個別の画面が表示されるようになりました。 現在のところ、[リソース プロバイダー] ウィンドウは空ですが、今後のリリースでは新しい PaaS サービス オファリングが表示され、[リソース プロバイダー] ウィンドウで管理されるようになる予定です。

• オペレーター ポータルでの更新プログラム エクスペリエンスの変更。 リソース プロバイダーの更新プログラム用の新しいグリッドがあります。 リソース プロバイダーを更新する機能はまだ利用できません。

• オペレーター ポータルでの更新プログラム インストール エクスペリエンスの変更。 Azure Stackオペレーターが更新の問題に適切に対応できるように、ポータルでは、スケール ユニットの正常性に基づいて、Test-AzureStack を実行して結果を解析することで自動的に派生するように、より具体的な推奨事項が提供されるようになりました。 結果に基づいて、2 つのアクションのうちいずれかを実行するようにオペレーターに通知されます。

  • ポータルには「ソフト警告」が表示されており、「最新の更新に注意が必要です」と記載されています。 Microsoftは、通常の営業時間内にサービスリクエストを開くことを推奨しています。 更新プロセスの一環として、Test-AzureStack が実行され、その出力に基づいて最も適切なアラートを生成します。 このケースでは、Test-AzureStack は合格しています。

  • ポータルに「最新の更新に失敗しました。」と表示される深刻な重要アラートです。 Microsoft は、できるだけ早くサービスリクエストを開くことをお勧めします。 更新プロセスの一環として、Test-AzureStack が実行され、その出力に基づいて最も適切なアラートを生成します。 In this case, Test-AzureStack also failed." (最新の更新プログラムは失敗しました。マイクロソフトはできるだけ早くサポート リクエストを開くことをお勧めします。更新プロセスの一環として Test-AzureStack が実行され、その出力に基づいて最も適切なアラートが生成されます。このケースでは、Test-AzureStack も失敗しています。)

• Azure Linux エージェント バージョン 2.2.38.0 が更新されました。 このサポートにより、お客様は Azure と Azure Stack の間で一貫した Linux イメージを維持できます。

• オペレーター ポータルでの更新ログの変更。 成功した更新ログを取得する要求は利用できなくなりました。 失敗した更新ログは、診断のためのアクションにつながるため、引き続きダウンロードできます。

修正

• syslog の構成が更新サイクル全体で保持されず、その結果、syslog クライアントがその構成を失い、syslog メッセージが転送されなくなる問題を修正しました。 syslog の構成が保持されるようになりました。

• VM の割り当て解除がブロックされる CRP の問題を修正しました。 以前は、VM に複数の大きなマネージド ディスクが含まれている場合、VM の割り当て解除がタイムアウト エラーで失敗することがありました。

• Windows Defender エンジンがスケール ユニット ストレージへのアクセスに影響する問題を修正しました。

• BLOB Storage アカウントの [アクセス ポリシー] ウィンドウの読み込みに失敗するユーザー ポータルの問題を修正しました。

• グローバル Azure ポータルに関する誤った通知が表示される、管理者ポータルとユーザー ポータルの両方の問題を修正しました。

• [フィードバック] タイルを選択すると空のブラウザー タブが開くユーザー ポータルの問題を修正しました。

• VM インスタンスにアタッチされたネットワーク アダプターにバインドされている IP 構成の静的 IP アドレスを変更すると、エラー メッセージが表示されるというポータルの問題を修正しました。

• [ネットワーク] ウィンドウを介して既存の VM に対して [ネットワーク インターフェイスの接続] を実行しようとすると、エラー メッセージが表示されて操作が失敗するというユーザー ポータルの問題を修正しました。

• Azure Stackが 4 つ以上のネットワーク インターフェイス (NIC) を VM インスタンスにアタッチできない問題を修正しました。

• 受信セキュリティ規則を追加し、ソースとして Service Tag を選択すると、Azure Stackに使用できないいくつかのオプションが表示されるポータルの問題を修正しました。

• ネットワーク セキュリティ グループ (NSG) がグローバル Azureと同じ方法でAzure Stackで動作しない問題を修正しました。

• 登録の期限が切れた場合、または削除された場合に、ダウンロードされたすべての製品が非表示になる Marketplace 管理の問題を修正しました。

• 既存の仮想ネットワーク ゲートウェイ接続に対して PowerShell で Set-AzureRmVirtualNetworkGatewayConnection コマンドを発行すると、エラー メッセージ "無効な共有キーが構成されています..." が表示されて失敗する問題を修正しました。

• ネットワーク リソース プロバイダー (NRP) がネットワーク コントローラーと同期しなくなり、その結果、重複するリソースが要求される問題を修正しました。 場合によっては、結果として親リソースがエラー状態のままになります。

• サブスクリプションに共同作成者ロールが割り当てられていても読み取りアクセス許可が明示的に与えられていないユーザーが、リソースの変更を保存しようとすると、"オブジェクト ID 'GUID' のクライアント '' は、... アクション '...' の実行を承認されていません..." というエラーが生成されていた問題を修正しました。

• オフライン シンジケーション ツールを使用してイメージをアップロードしたときに、マーケットプレース管理画面に何も表示されず、いずれにもアイコンの URI が表示されない問題を修正しました。

• ダウンロードに失敗した製品が Marketplace Management から削除されるのを妨げる問題を修正しました。

セキュリティ更新プログラム

Azure Stackのこの更新プログラムには、Azure Stackをホストする基になるオペレーティング システムのセキュリティ更新プログラムは含まれません。

更新プログラムの計画

更新プログラムを適用する前に、必ず次の情報を確認してください。

• 既知の問題
• セキュリティ更新プログラム
• 更新プログラム適用前後のアクティビティのチェックリスト

更新プログラムのダウンロード

Azure Stack 1904 更新プログラム パッケージは、Azure Stackダウンロード ページ。

修正プログラム

Azure Stack定期的に修正プログラムをリリースします。 Azure Stackを 1904 に更新する前に、1903 の最新のAzure Stack修正プログラムをインストールしてください。

Azure Stack修正プログラムは、Azure Stack統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

1904 更新プログラムを適用する前

Azure Stackの 1904 リリースは、次の修正プログラムを使用して 1903 リリースに適用する必要があります。

• Azure Stack 修正プログラム 1.1903.2.39

1904 更新プログラムの適用に成功した後

この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、サービス ポリシーに関する記事を参照してください。

• Azure Stack 修正プログラム 1.1904.4.45

自動更新通知

インフラストラクチャ ネットワークからインターネットにアクセスできるシステムをご利用の場合は、オペレーター ポータルに "利用可能な更新プログラムがあります" というメッセージが表示されます。 インターネットにアクセスできないシステムでは、対応する .xml を含む .zip ファイルをダウンロードしてインポートできます。

次のステップ

• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。
• Azure Stack統合システムのサービス ポリシーと、システムをサポートされている状態に保つために何を行う必要があるかを確認するには、「Azure Stack サービス ポリシーを参照してください。
• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。

1903 アーカイブ版のリリースノート

統合システムAzure Stack適用

この記事では、1903 更新プログラム パッケージの内容について説明します。 この更新プログラムには、このバージョンのAzure Stackの機能強化、修正、および新機能が含まれています。 またこの記事では、このリリースの既知の問題についても説明し、更新プログラムをダウンロードできるリンクも掲載しています。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1903 更新プログラムのビルド番号は 1.1903.0.35 です。

更新の種類

Azure Stack 1903 更新プログラムのビルドの種類は Express です。 更新プログラムのビルドの種類の詳細については、「Azure Stack での更新管理」記事を参照してください。 1903 更新プログラムが完了するまでの予測所要時間は約 16 時間ですが、正確な時間は変わる可能性があります。 このランタイム近似は 1903 更新プログラムに固有であり、他のAzure Stack更新プログラムと比較しないでください。

修正プログラム

Azure Stack定期的に修正プログラムをリリースします。 Azure Stackを 1903 に更新する前に、必ず 1902 の最新のAzure Stack修正プログラムをインストールしてください。

Azure Stack修正プログラムは、Azure Stack統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

Azure Stack修正プログラム

• 1902: KB 4500637 - Azure Stack修正プログラム 1.1902.3.75
• 1903: KB 4500638 - Azure Stack 修正プログラム 1.1903.2.39

改善

• パブリック IP アドレスのアイドル タイムアウト (分) 値の変更が有効になるのを阻止するネットワークのバグを修正しました。 以前はこの値の変更が無視されていたため、変更内容に関係なく値は既定値の 4 分でした。 この設定では、クライアントからキープアライブ メッセージを送信しなくても TCP 接続が開いたまま維持される時間 (分) が制御されます。 このバグの影響を受けていたのはインスタンス レベルのパブリック IP のみで、ロード バランサーに割り当てられたパブリック IP への影響はありませんでした。

• 一般的な問題の自動修正を含めた更新エンジンの信頼性が改善され、更新プログラムが中断なしに適用されるようになりました。

• ディスクの空き領域が少ない状態での検出と修復の機能が強化されました。

• Azure Stackは、バージョン2.2.35より新しいWindows AzureのLinuxエージェントをサポートするようになりました。 このサポートにより、お客様は Azure と Azure Stack の間で一貫した Linux イメージを維持できます。 これは 1901 と 1902 の修正プログラムの一部として追加されました。

秘密管理

• Azure Stackでは、外部シークレットのローテーションに証明書によって使用されるルート証明書のローテーションがサポートされるようになりました。 詳細については、こちらの記事を参照してください。

• 1903 には、内部シークレットのローテーションを実行するために必要な時間を短縮する、シークレットのローテーション向けのパフォーマンスの改善が含まれています。

前提条件

• ワークロードの計画とサイズ設定を行うには、最新バージョンの Azure Stack capacity planner を使用してください。 最新バージョンにはバグ修正が含まれており、各Azure Stack更新プログラムでリリースされる新機能が提供されます。

• この更新プログラムのインストールを開始する前に、Test-AzureStack を次のパラメーターで実行して、Azure Stackの状態を検証し、検出されたすべての警告やエラーなどの操作上の問題を解決します。 また、アクティブなアラートを確認し、アクションが必要なアラートを解決します。

  Test-AzureStack -Group UpdateReadiness
  

• Azure StackがSystem Center Operations Managerによって管理されている場合は、1903 を適用する前に、必ず Management Pack for Microsoft Azure Stack をバージョン 1.0.3.11 に更新してください。

• Azure Stack更新プログラムのパッケージ形式は、1902 リリース以降、.bin/.exe/.xml から .zip/.xml に変更されました。 接続されたAzure Stack スケール ユニットをお持ちのお客様は、ポータルに Update available メッセージが表示されます。 インターネット接続のないお客様の場合には、.zip と対応する .xml ファイルをダウンロードしてインポートできます。

更新プロセスに関する既知の問題

• Azure Stack更新プログラムをインストールしようとすると、更新プログラムの状態が失敗し、状態が PreparationFailed に変更されることがあります。 これは、更新リソース プロバイダー (URP) が、処理のためにストレージ コンテナーから内部インフラストラクチャ共有にファイルを正しく転送できないことが原因です。 バージョン 1901 (1.1901.0.95) 以降、この問題は、[今すぐ更新] ([再開] ではない) をもう一度クリックすることで回避できるようになりました。 それにより、URP は前回の試行のファイルをクリーンアップして、もう一度ダウンロードを開始します。

• Test-AzureStack を実行すると、ベースボード管理コントローラー (BMC) からの警告メッセージが表示されます。 この警告は無視しても問題ありません。

• この更新プログラムのインストール中に、"エラー - FaultType UserAccounts.New のテンプレートが見つかりません" というタイトルのアラートが表示される場合があります。これらのアラートは無視してかまいません。 この更新プログラムのインストールが完了した後、これらのアラートは自動的に閉じられます。

更新後の手順

• この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、「修正プログラム」および Microsoft のサービス ポリシーを参照してください。

• 静止データの暗号化キーを取得して、Azure Stack 環境の外部に安全に格納します。 キーを取得する方法の手順に関する記事に従ってください。

既知の問題 (インストール後)

このビルド バージョンのインストール後について次の既知の問題があります。

Portal

• ユーザー ポータル ダッシュボードで [フィードバック] タイルをクリックしようとすると、空のブラウザー タブが開きます。 回避策として、Azure Stack User Voice を使用して、ユーザー音声要求を提出できます。

• 管理ポータルとユーザー ポータルの両方で、"Docker" を検索すると、返される項目が正しくありません。 Azure Stackでは使用できません。 これを作成しようとすると、エラーを示すブレードが表示されます。

• アドオン プランとしてユーザー サブスクリプションに追加されたプランは、ユーザー サブスクリプションからプランを削除しても削除できません。 アドオン プランを参照するサブスクリプションも削除されるまで、プランは残ります。

• バージョン 1804 で導入された 2 種類の管理サブスクリプションは使用しないでください。 このサブスクリプションの種類は Metering サブスクリプションと Consumption サブスクリプションです。 これらのサブスクリプションの種類は、バージョン 1804 以降の新しいAzure Stack環境で表示されますが、まだ使用できる状態ではありません。 既定のプロバイダー サブスクリプションの種類を引き続き使用する必要があります。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

• ユーザー ポータルでストレージ アカウント内の BLOB に移動し、ナビゲーション ツリーからアクセス ポリシーを開こうとすると、後続のウィンドウの読み込みに失敗します。 この問題を回避するには、次の PowerShell コマンドレットによって、それぞれアクセス ポリシーの作成、取得、設定、削除を有効にできます。

  • New-AzStorageContainerStoredAccessPolicy
  • Get-AzStorageContainerStoredAccessPolicy
  • Set-AzStorageContainerStoredAccessPolicy
  • Remove-AzStorageContainerStoredAccessPolicy

• ユーザー ポータルで [OAuth(preview)]\(OAuth (プレビュー)\) オプションを使用して BLOB をアップロードしようとすると、タスクがエラー メッセージにより失敗します。 この問題を回避するには、[SAS] オプションを使用して BLOB をアップロードします。

• Azure Stack ポータルにログインすると、グローバル Azure ポータルに関する通知が表示されることがあります。 これらの通知は、現在Azure Stackには適用されないため、無視しても問題ありません (たとえば、"1 つの新しい更新プログラム - 次の更新プログラムが利用可能になりました: Azure ポータル 2019 年 4 月の更新プログラム")。

• ユーザー ポータル ダッシュボードで [フィードバック] タイルを選択しようとすると、空のブラウザー タブが開きます。 回避策として、Azure Stack User Voice を使用して User Voice 要求を提出できます。

Compute

• 新しいWindows仮想マシン (VM) を作成すると、次のエラーが表示されることがあります。

  'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

  このエラーは、VM でブート診断を有効にしても、ブート診断ストレージ アカウントを削除した場合に発生します。 この問題を回避するには、以前使用したものと同じ名前のストレージ アカウントを再作成します。

• 仮想マシン スケール セットの作成エクスペリエンスでは、デプロイのオプションとして CentOS-based 7.2 が提供されます。 そのイメージは Azure Stack Marketplace では使用できないため、デプロイ用に別のオペレーティング システムを選択するか、オペレーターが Marketplace からデプロイする前にダウンロードした別の CentOS イメージを指定するAzure Resource Manager テンプレートを使用します。

• 1903 更新プログラムを適用した後、Managed Disksを使用して VM をデプロイするときに、次の問題が発生する可能性があります。

  • 1808 更新プログラムの前にサブスクリプションが作成された場合、Managed Disksを使用して VM をデプロイすると、内部エラー メッセージで失敗する可能性があります。 エラーを解決するには、サブスクリプションごとに次の手順に従います。
    1. テナント ポータルで、[サブスクリプション] に移動して、サブスクリプションを検索します。 [リソース プロバイダー] を選択し、[Microsoft.Compute] を選択してから、[再登録] をクリックします。
    2. 同じサブスクリプションで、Access Control (IAM) に移動し、Azure Stack - マネージド ディスクが一覧表示されていることを確認します。
  • マルチテナント環境を構成した場合、ゲスト ディレクトリに関連付けられているサブスクリプションで VM をデプロイすると、内部エラー メッセージが出て失敗することがあります。 このエラーを解決するには、この記事にある手順に従って、各ゲスト ディレクトリを構成します。

• SSH の認可を有効にして作成した Ubuntu 18.04 VM では、SSH キーを使用してサインインすることはできません。 回避策として、プロビジョニング後に Linux 拡張機能用の VM アクセスを使用して SSH キーを実装するか、パスワードベースの認証を使用してください。

• ハードウェア ライフサイクル ホスト (HLH) がない場合:ビルド 1902 より前に、グループ ポリシー Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options を Send LM & に設定する必要がありました。NTLM - ネゴシエートされた場合は NTLMv2 セッション セキュリティを使用します。 ビルド 1902 からは、[定義されていません] のままにするか、[NTLMv2 応答のみ送信する] (既定値) に設定する必要があります。 そうしないと、PowerShell リモート セッションを確立できず、"アクセスが拒否されました" というエラーが表示されます。

  $Session = New-PSSession -ComputerName x.x.x.x -ConfigurationName PrivilegedEndpoint -Credential $Cred
  New-PSSession : [x.x.x.x] Connecting to remote server x.x.x.x failed with the following error message : Access is denied. For more information, see the
  about_Remote_Troubleshooting Help topic.
  At line:1 char:12
  + $Session = New-PSSession -ComputerName x.x.x.x -ConfigurationNa ...
  +            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
      + FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailed
  

• Virtual Machine Scale Sets ブレードからスケール セットを削除することはできません。 回避策として、削除するスケール セットを選択し、[概要] ウィンドウから [削除] ボタンをクリックします。

• 3 つの障害ドメインの可用性セットに VM を作成し、仮想マシン スケール セット インスタンスを作成すると、FabricVmPlacementErrorUnsupportedFaultDomainSize 4 ノード Azure Stack環境での更新プロセス中にエラーが発生して失敗します。 2 つの障害ドメインを持つ可用性セット内で、単一の仮想マシンを作成することができます。 ただし、スケール セット インスタンスの作成は、4 ノード Azure Stackの更新プロセス中は使用できません。

ネットワーク

• Azure Stack ポータルで、VM インスタンスに接続されているネットワーク アダプターにバインドされている IP 構成の静的 IP アドレスを変更すると、次のような警告メッセージが表示されます。

  The virtual machine associated with this network interface will be restarted to utilize the new private IP address...

  このメッセージは無視してかまいません。たとえ VM インスタンスが再起動しなくても IP アドレスは変更されます。

• ポータルで受信セキュリティ規則を追加し、ソースとして Service Tag を選択すると、Azure Stackで使用できないいくつかのオプションが Source Tag リストに表示されます。 Azure Stackで有効なオプションは次のとおりです。

  • インターネット
  • VirtualNetwork
  • AzureLoadBalancer

  その他のオプションは、Azure Stackではソース タグとしてサポートされていません。 同様に、送信セキュリティ規則を追加し、[Service Tag]\(サービス タグ\) を宛先として選択した場合も、[Source Tag]\(ソース タグ\) のリストに同じオプションが表示されます。 有効なオプションは、前述のリストで説明した [Source Tag]\(ソース タグ\) と同じものに限られます。

• ネットワーク セキュリティ グループ (NSG) は、グローバル Azureと同じ方法でAzure Stackで機能しません。 Azureでは、1 つの NSG ルールに複数のポートを設定できます (ポータル、PowerShell、Resource Manager テンプレートを使用)。 ただし、Azure Stackでは、ポータルを介して 1 つの NSG ルールに複数のポートを設定することはできません。 この問題を回避するには、Resource Manager テンプレートまたは PowerShell を使用して、これらの追加の規則を設定します。

• Azure Stackでは、現在、インスタンス のサイズに関係なく、4 つ以上のネットワーク インターフェイス (NIC) を VM インスタンスにアタッチすることはできません。

App Service

• テナントは、サブスクリプションで最初の Azure 関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。
• 1903 のポータル フレームワークと互換性がないため、テナント ポータルの一部のユーザー エクスペリエンス (主に、デプロイ スロット、運用環境でのテスト、およびサイト拡張機能のユーザー エクスペリエンス) は壊れています。 この問題を回避するには、Azure App Service PowerShell モジュール または Azure CLI を使用します。 ポータル エクスペリエンスは、Azure Stack 1.6 (Update 6) のAzure App Serviceの今後のリリースで復元されます。

Syslog

• syslog 構成が更新サイクル全体で維持されず、その結果、syslog クライアントがその構成を失い、syslog メッセージは転送されなくなります。 この問題は、syslog クライアント (1809) の GA 以降のすべてのバージョンのAzure Stackに適用されます。 この問題を回避するには、Azure Stack更新プログラムを適用した後、syslog クライアントを再構成します。

更新プログラムのダウンロード

Azure Stack 1903 更新プログラム パッケージは、here からダウンロードできます。

接続されているシナリオでのみ、Azure Stackデプロイでは、セキュリティで保護されたエンドポイントが定期的にチェックされ、クラウドで更新プログラムが利用可能かどうかが自動的に通知されます。 詳細については、 Azure Stackを参照してください。

次のステップ

• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。
• Azure Stack統合システムのサービス ポリシーと、システムをサポートされている状態に保つために何を行う必要があるかを確認するには、「Azure Stack サービス ポリシーを参照してください。
• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。

1902 アーカイブされたリリース ノート

統合システムAzure Stack適用

この記事では、1902 更新プログラム パッケージの内容について説明します。 この更新プログラムには、このバージョンのAzure Stackの機能強化、修正、および新機能が含まれています。 またこの記事では、このリリースの既知の問題についても説明し、更新プログラムをダウンロードできるリンクも掲載しています。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1902 更新プログラムのビルド番号は 1.1902.0.69 です。

更新の種類

Azure Stack 1902 更新プログラムのビルドの種類は Full です。 更新プログラムのビルドの種類の詳細については、「Azure Stack での更新管理」記事を参照してください。

修正プログラム

Azure Stack定期的に修正プログラムをリリースします。 Azure Stackを 1902 に更新する前に、必ず 1901 最新のAzure Stack修正プログラムをインストールしてください。

Azure Stack修正プログラムは、Azure Stack統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

Azure Stack修正プログラム

• 1901: KB 4500636 - Azure Stack 修正プログラム 1.1901.5.109
• 1902: KB 4500637 - Azure Stack修正プログラム 1.1902.3.75

前提条件

• この更新プログラムのインストールを開始する前に、次のパラメーターを指定して Test-AzureStack を実行して、Azure Stackの状態を検証し、検出されたすべての警告やエラーなどの操作上の問題を解決します。 また、アクティブなアラートを確認し、アクションが必要なアラートを解決します。

  Test-AzureStack -Include AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary, AzsHostingServiceCertificates
  

  AzsControlPlane の実行時に パラメーターが含まれている場合、Test-AzureStack 出力に次のエラーが表示されます: FAIL Azure Stack コントロールプレーン Websites 概要。 この特定のエラーは無視してかまいません。

• Azure StackがSystem Center Operations Managerによって管理されている場合は、1902 を適用する前に、Management Pack for Microsoft Azure Stack をバージョン 1.0.3.11 に更新してください。

• Azure Stack更新プログラムのパッケージ形式は、1902 リリース以降、.bin/.exe/.xml から .zip/.xml に変更されました。 接続されたAzure Stack スケール ユニットをお持ちのお客様は、ポータルに Update available メッセージが表示されます。 インターネット接続のないお客様の場合には、.zip と対応する .xml ファイルをダウンロードしてインポートできます。

改善

• 1902 ビルドでは、プラン、オファー、クォータ、アドオン プランを作成するための新しいユーザー インターフェイスがAzure Stack管理者ポータルに導入されています。 スクリーンショットを含めた詳細については、プラン、オファー、クォータの作成に関するページを参照してください。

• ノード追加操作による容量拡張にあたりスケール ユニットの状態を "Expanding storage" (ストレージの拡張中) から "実行中" に切り替える際の信頼性を向上させました。

• パッケージの整合性とセキュリティを向上させ、オフラインでの取り込みの管理を容易に行えるようにするため、Microsoft では、更新プログラム パッケージの形式を .exe ファイルと .bin ファイルから .zip ファイルに変更しました。 新しい形式では、パッケージの展開プロセスの信頼性が向上しています (旧形式では、更新プログラムの準備が止まってしまうことがありました)。 OEM から提供される更新プログラム パッケージにも、同じパッケージ形式が適用されます。

• Test-AzureStack を実行する際の Azure Stack 演算子のエクスペリエンスを向上させるために、演算子は、Include ステートメントの後に 10 個の追加パラメーターを渡すのではなく、"updateReadinessTest-AzureStack -Group" を単純に使用できるようになりました。

    Test-AzureStack -Group UpdateReadiness  
  

• コアとなるインフラストラクチャ サービスの更新プロセスにおける全般的な信頼性と可用性を向上させるために、更新アクション プランの一部としてのネイティブ更新リソースプロバイダーにより、必要に応じてグローバル修復が自動で検出および呼び出されるようになりました。 グローバル修復の "修復" ワークフローに含まれる項目は次のとおりです。

  • 最適な状態にないインフラストラクチャ仮想マシンがあるかどうかを確認し、必要に応じて修復を試みる。
  • コントロール プランの一部としての SQL サービスに問題が発生していないかどうかを確認し、必要に応じて修復を試みる。
  • ネットワーク コントローラー (NC) の一部としてソフトウェア Load Balancer (SLB) サービスの状態を確認し、必要に応じて修復を試みます。
  • ネットワーク コントローラー (NC) サービスの状態を確認し、必要に応じて修復を試みる
  • 緊急回復コンソール サービス (ERCS) のサービス ファブリック ノードの状態を確認し、必要に応じて修復する。
  • インフラストラクチャ ロールの状態を確認し、必要に応じて修復する。
  • Azure整合性ストレージ (ACS) サービス ファブリック ノードの状態を確認し、必要に応じて修復します。

• ログ収集の信頼性とパフォーマンスを向上させるためのAzure Stack診断ツールの機能強化。 ネットワーク サービスおよび ID サービスのログ項目を追加しました。

• シークレット ローテーションの準備テストのための Test-AzureStack の信頼性を向上させました。

• お客様のActive Directory環境と通信するときの AD Graph の信頼性を向上させる機能強化

• Get-AzureStackStampInformation のハードウェア インベントリ コレクションを改善しました。

• ERCS インフラストラクチャ上で実行する操作の信頼性を向上させるため、各 ERCS インスタンスのメモリを 8 GB から 12 GB に増やしました。 Azure Stack統合システムのインストールでは、全体的に 12 GB 増加します。

• 1902 では、特定のノード上のすべての VM がオフラインになるというネットワーク コントローラー VSwitch サービスの問題が修正されました。 この問題が原因で、プライマリが失われた状態のままになり、プライマリに接続できず、ロールが別の正常なインスタンスにフェールオーバーされませんでした。この問題を解決するには、Microsoft サポート サービスに問い合わせる必要がありました。

共通脆弱性と脆弱性曝露

この更新では、次のセキュリティ更新プログラムがインストールされます。

• ADV190005
• CVE-2019-0595
• CVE-2019-0596
• CVE-2019-0597
• CVE-2019-0598
• CVE-2019-0599
• CVE-2019-0600
• CVE-2019-0601
• CVE-2019-0602
• CVE-2019-0615
• CVE-2019-0616
• CVE-2019-0618
• CVE-2019-0619
• CVE-2019-0621
• CVE-2019-0623
• CVE-2019-0625
• CVE-2019-0626
• CVE-2019-0627
• CVE-2019-0628
• CVE-2019-0630
• CVE-2019-0631
• CVE-2019-0632
• CVE-2019-0633
• CVE-2019-0635
• CVE-2019-0636
• CVE-2019-0656
• CVE-2019-0659
• CVE-2019-0660
• CVE-2019-0662
• CVE-2019-0663

これらの脆弱性の詳細については、上記のリンクをクリックするか、Microsoft サポート技術情報の記事 4487006 を参照してください。

更新プロセスに関する既知の問題

• Azure Stack更新プログラムをインストールしようとすると、更新プログラムの状態が失敗し、状態が PreparationFailed に変更されることがあります。 これは、更新リソース プロバイダー (URP) が、処理のためにストレージ コンテナーから内部インフラストラクチャ共有にファイルを正しく転送できないことが原因です。 バージョン 1901 (1.1901.0.95) 以降、この問題は、[今すぐ更新] ([再開] ではない) をもう一度クリックすることで回避できるようになりました。 それにより、URP は前回の試行のファイルをクリーンアップして、もう一度ダウンロードを開始します。

• Test-AzureStack を実行すると、ベースボード管理コントローラー (BMC) からの警告メッセージが表示されます。 この警告は無視しても問題ありません。

• この更新プログラムのインストール中に、"エラー - FaultType UserAccounts.New のテンプレートが見つかりません" というタイトルのアラートが表示される場合があります。これらのアラートは無視してかまいません。 この更新プログラムのインストールが完了した後、これらのアラートは自動的に閉じられます。

更新後の手順

• この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、「修正プログラム」および Microsoft のサービス ポリシーを参照してください。

• 静止データの暗号化キーを取得して、Azure Stack 環境の外部に安全に格納します。 キーを取得する方法の手順に関する記事に従ってください。

既知の問題 (インストール後)

このビルド バージョンのインストール後について次の既知の問題があります。

Portal

• 管理ポータルとユーザー ポータルの両方で、"Docker" を検索すると、返される項目が正しくありません。 Azure Stackでは使用できません。 これを作成しようとすると、エラーを示すブレードが表示されます。

• アドオン プランとしてユーザー サブスクリプションに追加されたプランは、ユーザー サブスクリプションからプランを削除しても削除できません。 アドオン プランを参照するサブスクリプションも削除されるまで、プランは残ります。

• バージョン 1804 で導入された 2 種類の管理サブスクリプションは使用しないでください。 このサブスクリプションの種類は Metering サブスクリプションと Consumption サブスクリプションです。 これらのサブスクリプションの種類は、バージョン 1804 以降の新しいAzure Stack環境で表示されますが、まだ使用できる状態ではありません。 既定のプロバイダー サブスクリプションの種類を引き続き使用する必要があります。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

• ユーザー ポータルでストレージ アカウント内の BLOB に移動し、ナビゲーション ツリーからアクセス ポリシーを開こうとすると、後続のウィンドウの読み込みに失敗します。 この問題を回避するには、次の PowerShell コマンドレットによって、それぞれアクセス ポリシーの作成、取得、設定、削除を有効にできます。

  • New-AzStorageContainerStoredAccessPolicy
  • Get-AzStorageContainerStoredAccessPolicy
  • Set-AzStorageContainerStoredAccessPolicy
  • Remove-AzStorageContainerStoredAccessPolicy

Compute

• 新しいWindows仮想マシン (VM) を作成すると、次のエラーが表示されることがあります。

  'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

  このエラーは、VM でブート診断を有効にしても、ブート診断ストレージ アカウントを削除した場合に発生します。 この問題を回避するには、以前使用したものと同じ名前のストレージ アカウントを再作成します。

• 仮想マシン スケール セットの作成エクスペリエンスでは、デプロイのオプションとして CentOS-based 7.2 が提供されます。 そのイメージはAzure Stackでは使用できないため、展開用に別のオペレーティング システムを選択するか、オペレーターがマーケットプレースからデプロイする前にダウンロードした別の CentOS イメージを指定するAzure Resource Manager テンプレートを使用します。

• 1902 更新プログラムを適用した後、Managed Disksを使用して VM をデプロイするときに、次の問題が発生する可能性があります。

  • 1808 更新プログラムの前にサブスクリプションが作成された場合、Managed Disksを使用して VM をデプロイすると、内部エラー メッセージで失敗する可能性があります。 エラーを解決するには、サブスクリプションごとに次の手順に従います。
    1. テナント ポータルで、[サブスクリプション] に移動して、サブスクリプションを検索します。 [リソース プロバイダー] を選択し、[Microsoft.Compute] を選択してから、[再登録] をクリックします。
    2. 同じサブスクリプションで、Access Control (IAM) に移動し、Azure Stack - マネージド ディスクが一覧表示されていることを確認します。
  • マルチテナント環境を構成した場合、ゲスト ディレクトリに関連付けられているサブスクリプションで VM をデプロイすると、内部エラー メッセージが出て失敗することがあります。 このエラーを解決するには、この記事にある手順に従って、各ゲスト ディレクトリを構成します。

• SSH の認可を有効にして作成した Ubuntu 18.04 VM では、SSH キーを使用してログインすることはできません。 回避策として、プロビジョニング後に Linux 拡張機能用の VM アクセスを使用して SSH キーを実装するか、パスワードベースの認証を使用してください。

• Virtual Machine Scale Sets ブレードからスケール セットを削除することはできません。 回避策として、削除するスケール セットを選択し、[概要] ウィンドウから [削除] ボタンをクリックします。

• 3 つの障害ドメインの可用性セットに VM を作成し、仮想マシン スケール セット インスタンスを作成すると、FabricVmPlacementErrorUnsupportedFaultDomainSize 4 ノード Azure Stack環境での更新プロセス中にエラーが発生して失敗します。 2 つの障害ドメインを持つ可用性セット内で、単一の仮想マシンを作成することができます。 ただし、スケール セット インスタンスの作成は、4 ノード Azure Stackの更新プロセス中は使用できません。

ネットワーク

• Azure Stack ポータルで、VM インスタンスに接続されているネットワーク アダプターにバインドされている IP 構成の静的 IP アドレスを変更すると、次のような警告メッセージが表示されます。

  。

  このメッセージは無視してかまいません。たとえ VM インスタンスが再起動しなくても IP アドレスは変更されます。

• ポータルで受信セキュリティ規則を追加し、ソースとして Service Tag を選択すると、Azure Stackで使用できないいくつかのオプションが Source Tag リストに表示されます。 Azure Stackで有効なオプションは次のとおりです。

  • インターネット
  • VirtualNetwork
  • AzureLoadBalancer

  その他のオプションは、Azure Stackではソース タグとしてサポートされていません。 同様に、送信セキュリティ規則を追加し、[Service Tag]\(サービス タグ\) を宛先として選択した場合も、[Source Tag]\(ソース タグ\) のリストに同じオプションが表示されます。 有効なオプションは、前述のリストで説明した [Source Tag]\(ソース タグ\) と同じものに限られます。

• ネットワーク セキュリティ グループ (NSG) は、グローバル Azureと同じ方法でAzure Stackで機能しません。 Azureでは、1 つの NSG ルールに複数のポートを設定できます (ポータル、PowerShell、Resource Manager テンプレートを使用)。 ただし、Azure Stackでは、ポータルを介して 1 つの NSG ルールに複数のポートを設定することはできません。 この問題を回避するには、Resource Manager テンプレートまたは PowerShell を使用して、これらの追加の規則を設定します。

• Azure Stackでは、現在、インスタンス のサイズに関係なく、4 つ以上のネットワーク インターフェイス (NIC) を VM インスタンスにアタッチすることはできません。

• ユーザー ポータルで、Backend Pool を Load Balancer に追加しようとすると、エラー メッセージ Failed to update Load Balancer.... この問題を回避するには、PowerShell、CLI、またはAzure Resource Manager テンプレートを使用して、バックエンド プールをload balancer リソースに関連付けます。

• ユーザー ポータルで、Load Balancer に対して Inbound NAT 規則 を作成しようとすると、エラーメッセージ Load Balancer の更新に失敗しました... が表示され、操作は失敗します。この問題を回避するには、PowerShell、CLI、または Azure Resource Manager テンプレートを使用して、バックエンド プールを Load Balancer リソースに関連付けてください。

• ユーザー ポータルの Create Load Balancer ウィンドウに、Standard load balancer SKU を作成するオプションが表示されます。 このオプションは、Azure Stackではサポートされていません。

App Service

• サブスクリプションで最初のAzure関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。

Syslog

• syslog 構成が更新サイクル全体で維持されず、その結果、syslog クライアントがその構成を失い、syslog メッセージは転送されなくなります。 この問題は、syslog クライアント (1809) の GA 以降のすべてのバージョンのAzure Stackに適用されます。 この問題を回避するには、Azure Stack更新プログラムを適用した後、syslog クライアントを再構成します。

更新プログラムのダウンロード

Azure Stack 1902 更新プログラム パッケージは、here からダウンロードできます。

接続されているシナリオでのみ、Azure Stackデプロイでは、セキュリティで保護されたエンドポイントが定期的にチェックされ、クラウドで更新プログラムが利用可能かどうかが自動的に通知されます。 詳細については、 Azure Stackを参照してください。

次のステップ

• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。
• Azure Stack統合システムのサービス ポリシーと、システムをサポートされている状態に保つために何を行う必要があるかを確認するには、「Azure Stack サービス ポリシーを参照してください。
• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。

1901 年アーカイブ済みリリースノート

統合システムAzure Stack適用

この記事では、1901 更新プログラム パッケージの内容について説明します。 この更新プログラムには、このバージョンのAzure Stackの機能強化、修正、および新機能が含まれています。 またこの記事では、このリリースの既知の問題についても説明し、更新プログラムをダウンロードできるリンクも掲載しています。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1901 更新プログラムのビルド番号は、2019 年 2 月 26 日以降、1.1901.0.95 または 1.1901.0.99 です。 次のメモを参照してください。

修正プログラム

Azure Stack定期的に修正プログラムをリリースします。 Azure Stackを 1901 に更新する前に、必ず 1811 の最新のAzure Stack修正プログラムをインストールしてください。

Azure Stack修正プログラムは、Azure Stack統合システムにのみ適用されます。ASDK に修正プログラムをインストールしないでください。

Azure Stack修正プログラム

既に 1901 があり、まだいずれの修正プログラムもインストールしていない場合は、最初に 1901 修正プログラムをインストールすることなく 1902 を直接インストールすることができます。

• 1811: 現在の修正プログラムは使用できません。
• 1901: KB 4500636 - Azure Stack 修正プログラム 1.1901.5.109

前提条件

• この更新プログラムのインストールを開始する前に、次のパラメーターを指定して Test-AzureStack を実行して、Azure Stackの状態を検証し、検出されたすべての警告やエラーなどの操作上の問題を解決します。 また、アクティブなアラートを確認し、アクションが必要なアラートを解決します。

  Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary, AzsHostingServiceCertificates
  

• Azure StackがSystem Center Operations Managerによって管理されている場合は、1901 を適用する前に、必ず Microsoft Azure Stack 用管理パックをバージョン 1.0.3.11 に更新してください。

新機能

この更新プログラムには、Azure Stackの次の新機能と機能強化が含まれています。

• Azure Stack上のマネージド イメージを使用すると、今後マネージド ディスク VM のみを作成できる一般化された VM (アンマネージドとマネージドの両方) にマネージド イメージ オブジェクトを作成できます。 詳細については、「Azure Stack Managed Disksを参照してください。

• AzureRm 2.4.0

  • AzureRm.Profile
    バグの修正 - 保存済みのトークンを正しく逆シリアル化するための 。
  • AzureRm.Resources
    バクの修正 - リソースの種類別に大文字と小文字を区別せずクエリを行うための 。
  • Azure。Storage
    AzureRm ロールアップ モジュールに、api-version 2017-07-29 をサポートする既に公開済みのバージョン 4.5.0 が組み込まれました。
  • AzureRm.Storage
    AzureRm ロールアップ モジュールに、api-version 2017-10-01 をサポートする既に公開済みのバージョン 5.0.4 が組み込まれました。
  • AzureRm.Compute
    と にシンプルなパラメーター セットが追加されました。 パラメーターは、ユーザー イメージの指定をサポートします。
  • AzureRm.Insights
    AzureRm ロールアップ モジュールに、メトリック、メトリック定義リソース タイプ用の api-version 2018-01-01 をサポートする既に公開済みのバージョン 5.1.5 が組み込まれました。

• AzureStack 1.7.1: これは破壊的変更を伴うリリースです。 重大な変更について詳しくは、 を参照してください。

  • Azs.Backup.Admin モジュール
    破壊的変更: バックアップが証明書ベースの暗号化モードに変更されました。 対称キーのサポートは非推奨となりました。
  • Azs.Fabric.Admin モジュール
    は非推奨となりました。 新しいコマンドレット を使用してください。
    は非推奨となりました。 新しいコマンドレット を使用してください。
    は非推奨となりました。 オブジェクトには、容量のプロパティが含まれます。
  • Azs.Compute.Admin モジュール
    バグ修正 - 、 : 成功パスでのみ を呼び出します。
    BugFix - 、 : 成功パスでのみ ConvertTo-VmExtensionObject を呼び出します。
  • Azs.Storage.Admin モジュール
    バグの修正 - 新しい Storage クォータでは、値が未指定の場合に既定値が使用されます。

更新されたモジュールのリファレンスを確認するには、「Azure Stack モジュール リファレンスを参照してください。

修正された問題

• Azure Stackでサポートされていないポリシー ベースの VPN ゲートウェイを作成するオプションがポータルに表示される問題を修正しました。 このオプションがポータルから削除されました。

• Virtual Network の DNS 設定を Azure Stack DNS の使用 から Custom DNS の使用 に変更した後、インスタンスが新しい設定で更新されない問題を修正しました。

• v2 サフィックスを含むサイズ (Standard_A2_v2 など) で VM をデプロイする場合に、サフィックスを Standard_A2_v2 (小文字の v) で指定しなければならないという問題が修正されました。 グローバル Azureと同様に、Standard_A2_V2 (大文字の V) を使用できるようになりました。

• ポータルを使用して Premium VM サイズ (DS、Ds_v2、FS、FSv2) の仮想マシン (VM) を作成した場合に警告が発生するという問題が修正されました。 VM は Standard ストレージ アカウントで作成されました。 これは、機能、IOP、または課金には影響しませんが、警告は修正されました。

• 次のアラートを生成していた正常性コントローラーコンポーネントに関する問題が修正されました。 次のアラートは無視してもかまいません。

  • アラート #1:

    • 名前: インフラストラクチャ ロールの異常
    • 重大度: 警告
    • コンポーネント: 正常性コントローラー
    • 説明: ヘルスコントローラー「ハートビートスキャナー」は利用できません。 これは、健康レポートと指標に影響する可能性があります。

  • アラート #2:

    • 名前: インフラストラクチャ ロールの異常
    • 重大度: 警告
    • コンポーネント: 正常性コントローラー
    • 説明: ヘルスコントローラーの故障スキャナーは使用できません。 これは、健康レポートと指標に影響する可能性があります。

• Managed Disksクォータの値を compute quota types で 0 に設定すると、既定値の 2048 GiB に相当する問題を修正しました。 クォータ値 0 が尊重されるようになりました。

• スケール ユニットの管理に PowerShell コマンドレットの Start-AzsScaleUnitNode または Stop-AzsScaleunitNode を使用した場合に、スケール ユニットを開始または停止しようとすると、1 回目は失敗する可能性があるという問題が修正されました。

• サブスクリプション設定で Microsoft.Insight リソース プロバイダーを登録し、ゲスト OS 診断が有効になっているWindows VM を作成したが、VM の概要ページの CPU 使用率グラフにメトリック データが表示されない問題を修正しました。 データが正しく表示されるようになりました。

• 同じ特権エンドポイント (PEP) セッションで Test-AzureStack を実行した後に Get-AzureStackLog コマンドレットの実行が失敗するという問題が修正されました。 Test-AzureStack を実行したのと同じ PEP セッションを使用できるようになりました。

• スケジューラ サービスが予期せず無効状態になる自動バックアップに関する問題が修正されました。

• Azure Stack ポータルから Reset Gateway ボタンが削除されました。このボタンをクリックするとエラーが発生していました。 このボタンは、Azure Stackでは機能しません。Azure Stackには、各テナント VPN Gatewayの専用 VM インスタンスではなくマルチテナント ゲートウェイがあるため、混乱を防ぐために削除されました。

• Azure Stackではこの機能がサポートされていないため、Effective Security Rules リンクを Networking Properties ブレードから削除しました。 このリンクが表示されていたため、この機能がサポートされているような印象がありましたが、この機能は動作しません。 混乱を避けるために、このリンクは削除されました。

• OEM からのAzure Stackに更新プログラムが適用された後、Azure Stack管理者ポータルに Update available 通知が表示されない問題を修正しました。

変更点

• この更新プログラムでのセキュリティ強化により、ディレクトリ サービス ロールのバックアップ サイズが増えます。 外部の保存場所のサイズに関する最新のガイダンスについては、[infrastructure backup documentation../azure-stack-backup-reference.md#storage-location-sizing) をご覧ください。 この変更により、転送するデータのサイズが増えることから、バックアップの所要時間も長くなります。 この変更は、統合システムに影響します。

• 2019 年 1 月以降、接続された Azure Stack スタンプ (インターネット アクセスが必要) に登録された Active Directory Federated Services (AD FS) に Kubernetes クラスターをデプロイできます。 新しい Kubernetes Marketplace アイテムをダウンロードするには、この手順に従います。 Kubernetes クラスターをデプロイするには、この手順に従います。 ターゲット システムが ADD と AD FS のどちらに登録されているか示すための新しいパラメーターに注意してください。 AD FS の場合は、展開証明書が格納されているKey Vaultパラメーターを入力するための新しいフィールドを使用できます。

  AD FS サポートを使用する場合でも、Kubernetes クラスターをデプロイするにはインターネット アクセスが必要となるので注意してください。

• Azure Stackに更新プログラムまたは修正プログラムをインストールした後、1 つ以上の ID アプリケーションに新しいアクセス許可を付与する必要がある新機能が導入される場合があります。 これらのアクセス許可を付与するには、ホーム ディレクトリへの管理アクセスが必要です。このため、自動的にアクセス許可を付与することはできません。 次に例を示します。

  $adminResourceManagerEndpoint = "https://adminmanagement.<region>.<domain>"
  $homeDirectoryTenantName = "<homeDirectoryTenant>.onmicrosoft.com" # This is the primary tenant Azure Stack is registered to
  
  Update-AzsHomeDirectoryTenant -AdminResourceManagerEndpoint $adminResourceManagerEndpoint `
     -DirectoryTenantName $homeDirectoryTenantName -Verbose
  

• Azure Stack容量を正確に計画するための新しい考慮事項があります。 1901 更新プログラムでは、作成できるVirtual Machinesの合計数に制限が設定されました。 この制限は、ソリューションの不安定性を回避するための一時的なものです。 VM の数が多い場合の安定性の問題の原因は対処されていますが、修復のための具体的なタイムラインは決定されていません。 1901 更新プログラムでは、VM の数が、サーバーごとに 60 個、ソリューションの合計で 700 個に制限されています。 たとえば、VM の制限Azure Stack 8 台のサーバーは 480 (8 * 60) になります。 12 ~ 16 台のサーバー Azure Stackソリューションの場合、制限は 700 になります。 この制限は、オペレーターがスタンプで維持したい回復性の予約や仮想と物理の CPU の比率など、コンピューティング容量に関するすべての考慮事項を念頭に置いて作成されています。 詳細については、Capacity Planner の新しいリリースに関するページを参照してください。
  VM スケールの制限に達した場合、結果として次のエラー コードが返されます:VMPerScaleUnitLimitExceeded、VMMsPerScaleUnitNodeLimitExceeded。

• Compute API のバージョンが 2017-12-01 に更新されました。

• インフラストラクチャのバックアップで、バックアップ データの暗号化に公開キーのみを含む証明書 (.CER) が必要になりました。 対称暗号化キーのサポートは 1901 以降非推奨となりました。 1901 に更新する前にインフラストラクチャ バックアップが構成された場合、暗号キーはそのまま残ります。 バックアップ設定を更新するために、下位互換性をサポートする少なくとも 2 つの追加更新プログラムがあります。 詳細については、「Azure Stack インフラストラクチャ バックアップのベスト プラクティスを参照してください。

共通脆弱性と脆弱性曝露

この更新では、次のセキュリティ更新プログラムがインストールされます。

• CVE-2018-8477
• CVE-2018-8514
• CVE-2018-8580
• CVE-2018-8595
• CVE-2018-8596
• CVE-2018-8598
• CVE-2018-8621
• CVE-2018-8622
• CVE-2018-8627
• CVE-2018-8637
• CVE-2018-8638
• ADV190001
• CVE-2019-0536
• CVE-2019-0537
• CVE-2019-0545
• CVE-2019-0549
• CVE-2019-0553
• CVE-2019-0554
• CVE-2019-0559
• CVE-2019-0560
• CVE-2019-0561
• CVE-2019-0569
• CVE-2019-0585
• CVE-2019-0588

これらの脆弱性の詳細については、上記のリンクをクリックするか、Microsoft サポート技術情報の記事 4480977 を参照してください。

更新プロセスに関する既知の問題

• Azure Stack更新プログラムをインストールしようとすると、更新プログラムの状態が失敗し、状態が PreparationFailed に変更されることがあります。 これは、更新リソース プロバイダー (URP) が、処理のためにストレージ コンテナーから内部インフラストラクチャ共有にファイルを正しく転送できないことが原因です。 バージョン 1901 (1.1901.0.95) 以降、この問題は、[今すぐ更新] ([再開] ではない) をもう一度クリックすることで回避できるようになりました。 それにより、URP は前回の試行のファイルをクリーンアップして、もう一度ダウンロードを開始します。

• Test-AzureStack を実行しているときに、AzsInfraRoleSummary または AzsPortalApiSummary テストに失敗すると、Test-AzureStack を フラグで実行するように求められます。 このコマンドを実行すると、次のエラー メッセージで失敗します: Unexpected exception getting Azure Stack health status. Cannot bind argument to parameter 'TestResult' because it is null.

• Test-AzureStack を実行すると、ベースボード管理コントローラー (BMC) からの警告メッセージが表示されます。 この警告は無視しても問題ありません。

• この更新プログラムのインストール中に、"エラー - FaultType UserAccounts.New のテンプレートが見つかりません" というタイトルのアラートが表示される場合があります。これらのアラートは無視してかまいません。 この更新プログラムのインストールが完了した後、これらのアラートは自動的に閉じられます。

更新後の手順

• この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、「修正プログラム」および Microsoft のサービス ポリシーを参照してください。

• 静止データの暗号化キーを取得して、Azure Stack 環境の外部に安全に格納します。 キーを取得する方法の手順に関する記事に従ってください。

既知の問題 (インストール後)

このビルド バージョンのインストール後について次の既知の問題があります。

Portal

• 管理ポータルとユーザー ポータルの両方で、"Docker" を検索すると、返される項目が正しくありません。 Azure Stackでは使用できません。 これを作成しようとすると、エラーを示すブレードが表示されます。

• アドオン プランとしてユーザー サブスクリプションに追加されたプランは、ユーザー サブスクリプションからプランを削除しても削除できません。 アドオン プランを参照するサブスクリプションも削除されるまで、プランは残ります。

• バージョン 1804 で導入された 2 種類の管理サブスクリプションは使用しないでください。 このサブスクリプションの種類は Metering サブスクリプションと Consumption サブスクリプションです。 これらのサブスクリプションの種類は、バージョン 1804 以降の新しいAzure Stack環境で表示されますが、まだ使用できる状態ではありません。 既定のプロバイダー サブスクリプションの種類を引き続き使用する必要があります。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

Compute

• 新しいWindows仮想マシン (VM) を作成すると、次のエラーが表示されることがあります。

  'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

  このエラーは、VM でブート診断を有効にしても、ブート診断ストレージ アカウントを削除した場合に発生します。 この問題を回避するには、以前使用したものと同じ名前のストレージ アカウントを再作成します。

• 仮想マシン スケール セット (VMSS) の作成エクスペリエンスでは、デプロイのオプションとして CentOS-based 7.2 が提供されます。 そのイメージはAzure Stackでは使用できないため、展開用に別のオペレーティング システムを選択するか、オペレーターがマーケットプレースからデプロイする前にダウンロードした別の CentOS イメージを指定するAzure Resource Manager テンプレートを使用します。

• 1901 更新プログラムを適用した後、Managed Disksを使用して VM をデプロイするときに、次の問題が発生する可能性があります。

  • 1808 更新プログラムの前にサブスクリプションが作成された場合、Managed Disksを使用して VM をデプロイすると、内部エラー メッセージで失敗する可能性があります。 エラーを解決するには、サブスクリプションごとに次の手順に従います。
    1. テナント ポータルで、[サブスクリプション] に移動して、サブスクリプションを検索します。 [リソース プロバイダー] を選択し、[Microsoft.Compute] を選択してから、[再登録] をクリックします。
    2. 同じサブスクリプションの下で、Access Control (IAM) に移動し、AzureStack-DiskRP-Client が一覧表示されていることを確認します。
  • マルチテナント環境を構成した場合、ゲスト ディレクトリに関連付けられているサブスクリプションで VM をデプロイすると、内部エラー メッセージが出て失敗することがあります。 このエラーを解決するには、この記事にある手順に従って、各ゲスト ディレクトリを構成します。

• SSH の認可を有効にして作成した Ubuntu 18.04 VM では、SSH キーを使用してログインすることはできません。 回避策として、プロビジョニング後に Linux 拡張機能用の VM アクセスを使用して SSH キーを実装するか、パスワードベースの認証を使用してください。

• Virtual Machine Scale Sets ブレードからスケール セットを削除することはできません。 回避策として、削除するスケール セットを選択し、[概要] ウィンドウから [削除] ボタンをクリックします。

ネットワーク

• Azure Stack ポータルで、VM インスタンスに接続されているネットワーク アダプターにバインドされている IP 構成の静的 IP アドレスを変更すると、次のような警告メッセージが表示されます。

  。

  このメッセージは無視してかまいません。たとえ VM インスタンスが再起動しなくても IP アドレスは変更されます。

• ポータルで受信セキュリティ規則を追加し、ソースとして Service Tag を選択すると、Azure Stackで使用できないいくつかのオプションが Source Tag リストに表示されます。 Azure Stackで有効なオプションは次のとおりです。

  • インターネット

  • VirtualNetwork

  • AzureLoadBalancer

    その他のオプションは、Azure Stackではソース タグとしてサポートされていません。 同様に、送信セキュリティ規則を追加し、[Service Tag]\(サービス タグ\) を宛先として選択した場合も、[Source Tag]\(ソース タグ\) のリストに同じオプションが表示されます。 有効なオプションは、前述のリストで説明した [Source Tag]\(ソース タグ\) と同じものに限られます。

• ネットワーク セキュリティ グループ (NSG) は、グローバル Azureと同じ方法でAzure Stackで機能しません。 Azureでは、1 つの NSG ルールに複数のポートを設定できます (ポータル、PowerShell、Resource Manager テンプレートを使用)。 ただし、Azure Stackでは、ポータルを介して 1 つの NSG ルールに複数のポートを設定することはできません。 この問題を回避するには、Resource Manager テンプレートまたは PowerShell を使用して、これらの追加の規則を設定します。

• Azure Stackでは、インスタンス のサイズに関係なく、現在、4 つ以上のネットワーク インターフェイス (NIC) を VM インスタンスにアタッチすることはできません。

App Service

• サブスクリプションで最初のAzure関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。

Syslog

• syslog 構成が更新サイクル全体で維持されず、その結果、syslog クライアントがその構成を失い、syslog メッセージは転送されなくなります。 この問題は、syslog クライアント (1809) の GA 以降のすべてのバージョンのAzure Stackに適用されます。 この問題を回避するには、Azure Stack更新プログラムを適用した後、syslog クライアントを再構成します。

更新プログラムのダウンロード

Azure Stack 1901 更新プログラム パッケージは、here からダウンロードできます。

接続されているシナリオでのみ、Azure Stackデプロイでは、セキュリティで保護されたエンドポイントが定期的にチェックされ、クラウドで更新プログラムが利用可能かどうかが自動的に通知されます。 詳細については、 Azure Stackを参照してください。

次のステップ

• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。
• Azure Stack統合システムのサービス ポリシーと、システムをサポートされている状態に保つために何を行う必要があるかを確認するには、「Azure Stack サービス ポリシーを参照してください。
• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。

1811 アーカイブされたリリース ノート

統合システムAzure Stack適用

この記事では、1811 更新プログラム パッケージの内容について説明します。 更新プログラム パッケージには、このバージョンのAzure Stackの機能強化、修正、および新機能が含まれています。 またこの記事では、このリリースの既知の問題について説明し、更新プログラムをダウンロードできるリンクも掲載しています。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1811 更新プログラムのビルド番号は 1.1811.0.101 です。

修正プログラム

Azure Stack定期的に修正プログラムをリリースします。 Azure Stackを 1811 に更新する前に、最新のAzure Stack修正プログラムを 1809 用にインストールしてください。

Azure Stack修正プログラム

• 1809: KB 4481548 – Azure Stack修正プログラム 1.1809.12.114
• 1811: 現在の修正プログラムは使用できません。

前提条件

• Azure Stack拡張機能ホストに向けてAzure Stackの展開を準備します。 システムを準備するには、次のガイダンスをご利用ください: Azure Stack の拡張機能ホストの準備。

• 1809から1811に更新する前に、最新のAzure Stack修正プログラムをインストールしてください。

• この更新プログラムのインストールを開始する前に、次のパラメーターを指定して Test-AzureStack を実行して、Azure Stackの状態を検証し、検出されたすべての警告やエラーなどの操作上の問題を解決します。 また、アクティブなアラートを確認し、アクションが必要なアラートを解決します。

  Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary, AzsHostingServiceCertificates
  

  拡張機能ホストの要件が満たされていないと、 の出力で次のメッセージが表示されます。

  To proceed with installation of the 1811 update, you will need to import the SSL certificates required for Extension Host, which simplifies network integration and increases the security posture of Azure Stack. Refer to this link to prepare for Extension Host: https://learn.microsoft.com/azure-stack/operator/azure-stack-extension-host-prepare

• Azure Stack 1811 更新プログラムでは、必須の拡張機能ホスト証明書をAzure Stack環境に適切にインポートしている必要があります。 1811 更新プログラムのインストールを続行するには、拡張機能ホストに必要な SSL 証明書をインポートする必要があります。 証明書のインポートについては、こちらのセクションを参照してください。

  すべての警告を無視して 1811 更新プログラムのインストールを続行した場合、およそ 1 時間以内に次のメッセージが表示されて、更新に失敗します。

  The required SSL certificates for the Extension Host have not been found. The Azure Stack update will halt. Refer to this link to prepare for Extension Host: https://learn.microsoft.com/azure-stack/operator/azure-stack-extension-host-prepare, then resume the update. Exception: The Certificate path does not exist: [certificate path here]

  拡張機能ホストの必須の証明書を適切にインポートしたら、管理者ポータルから 1811 の更新を再開することができます。 Microsoft は、更新プロセス中にメンテナンス期間をスケジュールするようAzure Stackオペレーターに勧めますが、拡張機能ホスト証明書が不足しているために障害が発生した場合は、既存のワークロードやサービスに影響を与えるべきではありません。

  この更新プログラムのインストール中、拡張機能ホストの構成中は、Azure Stack ユーザー ポータルを使用できません。 拡張機能ホストの構成には最大で 5 時間かかる場合があります。 その間、更新プログラムの状態を確認するか、Azure Stack Administrator PowerShell または特権エンドポイントを使用して失敗した更新プログラムのインストールを再開できます。

• Azure StackがSystem Center Operations Managerによって管理されている場合は、1811 を適用する前に、必ず Microsoft Azure Stack 用管理パックをバージョン 1.0.3.11 に更新してください。

新機能

この更新プログラムには、Azure Stackの次の新機能と機能強化が含まれています。

• このリリースでは、拡張機能ホストが有効になります。 拡張機能ホストは、ネットワーク統合を簡略化し、Azure Stackのセキュリティ体制を向上させます。

• 特にAzure CLIを使用する場合、Active Directory フェデレーション サービス (AD FS) でのデバイス認証のサポートが追加されました。 詳細については、「 Azure Stack

• Active Directory Federated Services (AD FS) でクライアント シークレットを使用するサービス プリンシパルのサポートを追加しました。 詳細については、AD FS のサービス プリンシパルの作成に関するページを参照してください。

• このリリースでは、Azure Storage Service API バージョン (2017-07-29、2017-11-09) のサポートが追加されました。 2016-05-01 のAzure Storageリソース プロバイダー API バージョンのサポートも追加されます。 2016-12-01、2017-06-01、および 2017-10-01。 詳細については、「Azure Stack storage: 相違点と考慮事項を参照してください。

• ADFS のサービス プリンシパルを更新したり削除したりするための新しい特権エンドポイント コマンドが追加されました。 詳細については、AD FS のサービス プリンシパルの作成に関するページを参照してください。

• Azure Stackオペレーターがスケール ユニット ノードを開始、停止、シャットダウンできるようにする新しいスケール ユニット ノード操作が追加されました。 詳細については、「Scale unit node actions in Azure Stack」を参照してください。

• 環境の詳しい登録情報を表示する新しいリージョン プロパティ ブレードが追加されました。 この情報は、管理者ポータルの既定のダッシュボードにある [Region Management]\(リージョン管理\) タイルをクリックし、[プロパティ] を選択することで表示できます。

• 物理マシンとの通信に使用される BMC 資格情報をユーザー名とパスワードで更新するための新しい特権エンドポイント コマンドが追加されました。 詳細については、「ベースボード管理コントローラー (BMC) のパスワードを更新する」を参照してください。

• Azure ポータルで使用できる方法と同様に、管理者ポータルとユーザー ポータルの右上隅にあるヘルプとサポート アイコン (疑問符) を使用して、Azureロードマップにアクセスする機能を追加しました。

• 非接続ユーザー向けの Marketplace 管理エクスペリエンスが強化されました。 非接続環境で Marketplace アイテムを発行するアップロード プロセスが簡素化され、画像と Marketplace パッケージを別々にアップロードするのではなく、1 つのステップで行えるようになりました。 また、アップロードされた製品が Marketplace の管理ブレードに表示されるようになります。

• このリリースでは、Azure Stack シークレットローテーション中に外部証明書のみをローテーションする機能を追加することで、シークレットローテーションに必要なメンテナンス期間が短縮されます。

• Azure Stack PowerShell がバージョン 1.6.0 に更新されました。 この更新プログラムには、Azure Stackの新しいストレージ関連機能のサポートが含まれています。 詳細については、PowerShell ギャラリーAzure Stack 管理モジュール 1.6.0 のリリース ノートを参照してください> Azure Stack PowerShell の更新またはインストールの詳細については、「Install PowerShell for Azure Stack」を参照してください。

• Azure Stack ポータルを使用して仮想マシンを作成するときに、Managed Disksが既定で有効になりました。 Managed Disks の VM 作成エラーを回避するために必要な追加の手順については、既知の問題セクションを参照してください。

• このリリースでは、Azure Stack 演算子のアラート Repair アクションが導入されています。 1811 のいくつかのアラートには、[修復] ボタンが表示され、そのボタンを選択することで問題を解決できます。 詳細については、「Monitor health and alerts in Azure Stack」を参照してください。

• Azure Stackでの更新エクスペリエンスの更新。 更新プログラムの機能強化には以下が含まれます。

  • 進行中の更新および完了した更新の追跡向上のために、更新履歴から更新を分割するタブ。

  • 現在のバージョンと OEM バージョンおよび最終更新日に対する新しいアイコンとレイアウトによる、要点セクションの強化された状態の視覚化。

  • リリース ノート列の [表示] リンクでは、一般的な更新プログラム ページではなく、その更新プログラムに固有のドキュメントに直接移動します。

  • 各更新プログラムの実行日時を特定するために使用される [更新の履歴] タブと、強化されたフィルター処理機能。

  • Azure Stack スケールユニットが接続されると、使用可能になった際に更新プログラムが利用可能が自動的に受信されます。

  • 接続されていないスケール ユニットAzure Stack、前と同じように更新プログラムをインポートできます。

  • ポータルから JSON ログをダウンロードするプロセスに変更はありません。 Azure Stack演算子では、進行状況を表すステップが拡張されます。

    詳細については、「apply updates in Azure Stack」を参照してください。

修正された問題

• パブリック IP アドレス使用量メーターのデータが、レコードの作成日時を示す TimeDate スタンプではなく各レコードに対して同じ EventDateTime 値を示す問題が修正されました。 このデータを使用してパブリック IP アドレスの使用を正確に算出できるようになりました。

• Azure Stack ポータルを使用して新しい仮想マシン (VM) を作成するときに発生する問題を修正しました。 VM サイズを選択すると、[米国ドル/月] 列に利用不可というメッセージが表示されていました。 この列は表示されなくなりました。VM の価格列の表示は、Azure Stackではサポートされていません。

• 管理者ポータルで、ユーザーのサブスクリプションの詳細にアクセスした後、ブレードを閉じて、[最近] をクリックしても、ユーザーのサブスクリプション名が表示されませんでしたが、この問題は修正されました。 今後は、ユーザーのサブスクリプション名が表示されます。

• 管理者ポータルとユーザー ポータルの両方で、ポータルの設定をクリックした後、[すべての設定とプライベート ダッシュボードを削除] を選んでも、想定どおりに機能せず、エラー通知が表示されていましたが、この問題は修正されました。 このオプションは正しく機能するようになりました。

• 管理者ポータルとユーザー ポータルの両方で、[すべてのサービス] の下に、資産 [DDoS protection プラン] が間違って一覧表示されていましたが、この問題は修正されました。 Azure Stackでは使用できません。 この一覧は削除されました。

• 新しいAzure Stack環境をインストールしたときに発生する問題を修正しました。Activation Required を示すアラートが表示されません。 今後は正しく表示されます。

• ADFS の使用時に RBAC ポリシーをユーザー グループに適用できない問題が修正されました。

• パブリック VIP ネットワークからファイル サーバーにアクセスできないことが原因でインフラストラクチャ バックアップに失敗する問題が修正されました。 この修正により、インフラストラクチャ バックアップ サービスはパブリック インフラストラクチャ ネットワークに戻されます。 この問題に対処する 1809 の最新の Azure Stack 修正プログラムを適用した場合、1811 更新プログラムはそれ以上変更されません。

• Azure Stack管理者ポータルまたはユーザー ポータルにサインインするために使用したアカウントが Unidentified user として表示される問題を修正しました。 このメッセージは、アカウントに "名" と "姓" がどちらも指定されていない場合に表示されていました。

• ポータルを使用して仮想マシン スケール セット (VMSS) を作成すると、インスタンス サイズ ドロップダウンがInternet Explorerを使用するときに正しく読み込まれなかった問題を修正しました。 現在、このブラウザーは正しく動作します。

• インフラストラクチャ ロール インスタンスが利用できない、またはスケール ユニットがオフラインであることを示すわずらわしいアラートが表示される問題を修正しました。

• VM の概要ページに VM のメトリック グラフが正しく表示されない問題が修正されました。

変更点

• 1811 では、プランのクォータを表示したり編集したりするための新しい方法が導入されました。 詳細については、「[View an existing quota]\(既存のクォータの表示\)」を参照してください。

• この更新プログラムでのセキュリティ強化により、ディレクトリ サービス ロールのバックアップ サイズが増えます。 外部の保存場所のサイズに関する最新のガイダンスについては、Infrastructure Backup に関するドキュメントを参照してください。 この変更により、転送するデータのサイズが増えることから、バックアップの所要時間も長くなります。 この変更は、統合システムに影響します。

• BitLocker 回復キーを取得するための既存の PEP コマンドレット Get-AzsCsvsRecoveryKeys の名前が、1811 では Get-AzsRecoveryKeys に変更されました。 BitLocker 回復キーを取得する方法の詳細については、キーを取得する方法の手順に関するページを参照してください。

共通脆弱性と脆弱性曝露

これらの脆弱性の詳細については、上記のリンクをクリックするか、Microsoft サポート技術情報の記事 4478877 を参照してください。

更新プロセスに関する既知の問題

• 同じ特権エンドポイント (PEP) セッションで、Test-AzureStack の実行後に Get-AzureStackLog PowerShell コマンドレットを実行すると、Get-AzureStackLog が失敗します。 この問題を回避するには、Test-AzureStack を実行した PEP セッションを閉じてから、新しいセッションを開いて、Get-AzureStackLog を実行します。

• 1811 更新プログラムのインストール中は、その間、管理者ポータルのすべてのインスタンスを必ず閉じておいてください。 ユーザー ポータルは開いたままでかまいませんが、管理ポータルは閉じる必要があります。

• Test-AzureStack を実行しているときに、AzsInfraRoleSummary または AzsPortalApiSummary テストに失敗すると、Test-AzureStack を フラグで実行するように求められます。 このコマンドを実行すると、次のエラー メッセージで失敗します:Unexpected exception getting Azure Stack health status. Cannot bind argument to parameter 'TestResult' because it is null. この問題は、今後のリリースで修正される予定です。

• 1811 更新プログラムのインストール中、拡張機能ホストの構成中は、Azure Stack使用ポータルを使用できません。 拡張機能ホストの構成には最大で 5 時間かかる場合があります。 その間、更新プログラムの状態を確認するか、Azure Stack Administrator PowerShell または特権エンドポイントを使用して失敗した更新プログラムのインストールを再開できます。

• 1811 更新プログラムのインストール中は、ユーザー ポータルのダッシュボードを利用できない場合があり、カスタマイズが失われる可能性があります。 更新の完了後、ポータルの設定を開き、[既定の設定に戻す] を選択することで、ダッシュボードを既定の設定に復元することができます。

• Test-AzureStack を実行すると、ベースボード管理コントローラー (BMC) からの警告メッセージが表示されます。 この警告は無視しても問題ありません。

• この更新プログラムのインストール中に、"エラー - FaultType UserAccounts.New のテンプレートが見つかりません" というタイトルのアラートが表示される場合があります。これらのアラートは無視してかまいません。 この更新プログラムのインストールが完了した後、これらのアラートは自動的に閉じられます。
• OEM からAzure Stackに更新プログラムを適用した場合、Azure Stack管理者ポータルに **Update available** 通知が表示されない場合があります。 Microsoft 更新プログラムをインストールするには、「[Azure Stackで更新プログラムを適用する]」の手順に従って手動でダウンロードしてインポートします。/azure-stack-apply-updates.md)。

更新後の手順

• この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、「修正プログラム」および Microsoft のサービス ポリシーを参照してください。

• 静止データの暗号化キーを取得して、Azure Stack 環境の外部に安全に格納します。 キーを取得する方法の手順に関する記事に従ってください。

既知の問題 (インストール後)

このビルド バージョンのインストール後について次の既知の問題があります。

Portal

• 管理ポータルとユーザー ポータルの両方で、"Docker" を検索すると、返される項目が正しくありません。 Azure Stackでは使用できません。 これを作成しようとすると、エラーを示すブレードが表示されます。

• アドオン プランとしてユーザー サブスクリプションに追加されたプランは、ユーザー サブスクリプションからプランを削除しても削除できません。 アドオン プランを参照するサブスクリプションも削除されるまで、プランは残ります。

• バージョン 1804 で導入された 2 種類の管理サブスクリプションは使用しないでください。 このサブスクリプションの種類は Metering サブスクリプションと Consumption サブスクリプションです。 これらのサブスクリプションの種類は、バージョン 1804 以降の新しいAzure Stack環境で表示されますが、まだ使用できる状態ではありません。 既定のプロバイダー サブスクリプションの種類を引き続き使用する必要があります。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

健康と監視

• 以下の詳細を持つ正常性コントローラーコンポーネントのアラートが表示されることがあります。

  • アラート #1:

    • 名前: インフラストラクチャ ロールの異常
    • 重大度: 警告
    • コンポーネント: 正常性コントローラー
    • 説明: ヘルスコントローラー「ハートビートスキャナー」は利用できません。 これは、健康レポートと指標に影響する可能性があります。

  • アラート #2:

    • 名前: インフラストラクチャ ロールの異常
    • 重大度: 警告
    • コンポーネント: 正常性コントローラー
    • 説明: ヘルスコントローラーの故障スキャナーは使用できません。 これは、健康レポートと指標に影響する可能性があります。

    いずれのアラートも無視してかまいません。 時間が経つと自動的に閉じられます。

Compute

• 新しいWindows仮想マシン (VM) を作成する場合、Settings ブレードでは、続行するためにパブリック受信ポートを選択する必要があります。 1811 では、この設定が必須ですが、作用はありません。 これは、この機能がAzure Stackで実装されていないAzure Firewallに依存するためです。 [パブリック受信ポートなし] または他の任意のオプションを選択して、VM の作成を続行できます。 この の設定は影響しません。

• 新しいWindows仮想マシン (VM) を作成すると、次のエラーが表示されることがあります。

  'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

  このエラーは、VM でブート診断を有効にしても、ブート診断ストレージ アカウントを削除した場合に発生します。 この問題を回避するには、以前使用したものと同じ名前のストレージ アカウントを再作成します。

• Dv2 シリーズ VM を作成する場合、D11 14v2 VM では、それぞれ 4、8、16、32 個のデータ ディスクを作成できます。 ただし、VM の作成ウィンドウには、8、16、32、および 64 個のデータ ディスクが表示されます。

• Azure Stackの使用状況レコードには、予期しない大文字と小文字が含まれている場合があります。次に例を示します。

  {"Microsoft.Resources":{"resourceUri":"/subscriptions/<subid>/resourceGroups/ANDREWRG/providers/Microsoft.Compute/ virtualMachines/andrewVM0002","location":"twm","tags":"null","additionalInfo": "{\"ServiceType\":\"Standard_DS3_v2\",\"ImageType\":\"Windows_Server\"}"}}

  この例では、リソース グループの名前は AndrewRG である必要があります。 この不一致は無視してかまいません。

• v2 サフィックスを含むサイズ (Standard_A2_v2 など) で VM をデプロイするには、サフィックスを Standard_A2_v2 (小文字の v) と指定してください。 Standard_A2_V2 (大文字の V) は使用しないでください。 これはグローバル Azureで動作し、Azure Stackの不整合です。

• Add-AzsPlatformImage コマンドレットを使用する場合は、ディスクのアップロード先のストレージ アカウント URI として -OsUri パラメーターを使用する必要があります。 ディスクのローカル パスを使用した場合、次のエラーが出てコマンドレットが失敗します。

  Long running operation failed with status 'Failed'

• ポータルを使用して Premium VM サイズ (DS、Ds_v2、FS、FSv2) の仮想マシン (VM) を作成すると、VM は Standard ストレージ アカウントで作成されます。 Standard ストレージ アカウントで作成しても、機能、IOPS、課金に影響はありません。 次の警告は無視してかまいません。

  You've chosen to use a standard disk on a size that supports premium disks. This could impact operating system performance and is not recommended. Consider using premium storage (SSD) instead.

• 仮想マシン スケール セット (VMSS) の作成エクスペリエンスでは、デプロイのオプションとして CentOS-based 7.2 が提供されます。 そのイメージはAzure Stackでは使用できないため、展開用に別のオペレーティング システムを選択するか、オペレーターがマーケットプレースからデプロイする前にダウンロードした別の CentOS イメージを指定するAzure Resource Manager テンプレートを使用します。

• スケール ユニットの管理に PowerShell コマンドレットの Start-AzsScaleUnitNode または Stop-AzsScaleunitNode を使った場合、スケール ユニットを開始または停止しようとすると、1 回目は失敗することがあります。 初回実行時にコマンドレットが失敗した場合は、もう一度コマンドレットを実行してください。 2 回目の実行では操作が正常に完了します。

• VM のデプロイで拡張機能のプロビジョニングに時間がかかりすぎる場合は、プロセスを停止して VM の割り当て解除または削除を試みるのではなく、プロビジョニングをタイムアウトさせる必要があります。

• Linux VM 診断は、Azure Stackではサポートされていません。 VM 診断を有効にして Linux VM を展開すると、展開が失敗します。 診断設定で Linux VM の基本メトリックを有効にした場合も、展開が失敗します。

• Managed Disks は、プロビジョニング可能なマネージドディスクの最大容量を制限するために、2 つの新しい コンピュートクォータタイプを作成します。 既定では、2,048 GiB がマネージド ディスク クォータの種類ごとに割り当てられます。 ただし、次の問題が発生する可能性があります。

  • 1808 更新プログラムの前に作成されたクォータの場合、Managed Disks クォータには管理者ポータルに 0 個の値が表示されますが、2048 GiB が割り当てられます。 値は実際のニーズに基づいて増減することができ、新しく設定したクォータ値が 2,048 GiB の既定値をオーバーライドします。
  • クォータ値を 0 に更新することは、2,048 GiB の既定値と同じことになります。 回避策として、クォータ値を 1 に設定します。

• 1811 更新プログラムを適用した後、Managed Disksを使用して VM をデプロイするときに、次の問題が発生する可能性があります。

  • 1808 更新プログラムの前にサブスクリプションが作成された場合、Managed Disksを使用して VM をデプロイすると、内部エラー メッセージで失敗する可能性があります。 エラーを解決するには、サブスクリプションごとに次の手順に従います。
    1. テナント ポータルで、[サブスクリプション] に移動して、サブスクリプションを検索します。 [リソース プロバイダー] を選択し、[Microsoft.Compute] を選択してから、[再登録] をクリックします。
    2. 同じサブスクリプションで、Access Control (IAM) に移動し、AzureStack-DiskRP-Client ロールが一覧表示されていることを確認します。
  • マルチテナント環境を構成した場合、ゲスト ディレクトリに関連付けられているサブスクリプションで VM をデプロイすると、内部エラー メッセージが出て失敗することがあります。 このエラーを解決するには、この記事にある手順に従って、各ゲスト ディレクトリを構成します。

• SSH の認可を有効にして作成した Ubuntu 18.04 VM では、SSH キーを使用してログインすることはできません。 回避策として、プロビジョニング後に Linux 拡張機能用の VM アクセスを使用して SSH キーを実装するか、パスワードベースの認証を使用してください。

ネットワーク

• [Networking の下で、vpn 接続を設定するために Create VPN Gateway をクリックすると、VPN の種類として Policy Based が表示されます。 このオプションを選択しないでください。 Azure Stackでは、Route Based オプションのみがサポートされます。

• Azure Stackでは、IP アドレスごとに 1 つのローカル ネットワーク ゲートウェイがサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると拒否されます。

• 自動の DNS サーバー設定を使用して作成された仮想ネットワークでは、カスタム DNS サーバーへの変更が失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• Azure Stack Secret Rotation では、パブリック IP アドレスに 2 ~ 5 分間到達できない期間があります。

• テナントが S2S VPN トンネルを使用して仮想マシンにアクセスするシナリオでは、ゲートウェイが既に作成された後でオンプレミスのサブネットがローカル ネットワーク ゲートウェイに追加された場合、接続しようとしても失敗するシナリオが発生する可能性があります。

• Azure Stack ポータルで、VM インスタンスに接続されているネットワーク アダプターにバインドされている IP 構成の静的 IP アドレスを変更すると、次のような警告メッセージが表示されます。

  。

  このメッセージは無視してかまいません。たとえ VM インスタンスが再起動しなくても IP アドレスは変更されます。

• ポータルの [Networking Properties]\(ネットワーク プロパティ\) ブレードに、[有効なセキュリティ規則] のリンクがネットワーク アダプターごとに存在します。 このリンクを選択すると、エラー メッセージ Not Found. を示す新しいブレードが開きます。このエラーは、Azure Stackでまだ Effective Security Rules をサポートしていないために発生します。

• ポータルで受信セキュリティ規則を追加し、ソースとして Service Tag を選択すると、Azure Stackで使用できないいくつかのオプションが Source Tag リストに表示されます。 Azure Stackで有効なオプションは次のとおりです。

  • インターネット

  • VirtualNetwork

  • AzureLoadBalancer

    その他のオプションは、Azure Stackではソース タグとしてサポートされていません。 同様に、送信セキュリティ規則を追加し、[Service Tag]\(サービス タグ\) を宛先として選択した場合も、[Source Tag]\(ソース タグ\) のリストに同じオプションが表示されます。 有効なオプションは、前述のリストで説明した [Source Tag]\(ソース タグ\) と同じものに限られます。

• New-AzureRmIpSecPolicy PowerShell コマンドレットの パラメーターでは、 設定がサポートされません。

• ネットワーク セキュリティ グループ (NSG) は、グローバル Azureと同じ方法でAzure Stackで機能しません。 Azureでは、1 つの NSG ルールに複数のポートを設定できます (ポータル、PowerShell、Resource Manager テンプレートを使用)。 Azure Stackでは、ポータルを介して 1 つの NSG ルールに複数のポートを設定することはできません。 この問題を回避するには、Resource Manager テンプレートを使用して、これらの追加の規則を設定します。

インフラストラクチャのバックアップ

• 自動バックアップを有効にした後、スケジューラ サービスが予期せず無効状態になります。 バックアップ コントローラー サービスによって、自動バックアップが無効であることが検出され、管理者ポータルに警告が生成されます。 この警告は、自動バックアップが無効になっていると発生する可能性があります。
  • 原因: この問題は、スケジューラの構成が失われるサービスのバグが原因です。 このバグによって、保存場所、ユーザー名、パスワード、暗号化キーが変わることはありません。
  • 修復: この問題を軽減するには、インフラストラクチャ バックアップ リソース プロバイダーの [バックアップ コントローラーの設定] ブレードを開き、 [自動バックアップの実行]を選択します。 必要な頻度と保持期間を設定してください。
  • 発生回数: 低

App Service

• サブスクリプションで最初のAzure関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。

Syslog

• syslog 構成が更新サイクル全体で維持されず、その結果、syslog クライアントがその構成を失い、syslog メッセージは転送されなくなります。 この問題は、syslog クライアント (1809) の GA 以降のすべてのバージョンのAzure Stackに適用されます。 この問題を回避するには、Azure Stack更新プログラムを適用した後、syslog クライアントを再構成します。

更新プログラムのダウンロード

Azure Stack 1811 更新プログラム パッケージは、here からダウンロードできます。

接続されているシナリオでのみ、Azure Stackデプロイでは、セキュリティで保護されたエンドポイントが定期的にチェックされ、クラウドで更新プログラムが利用可能かどうかが自動的に通知されます。 詳細については、 Azure Stackを参照してください。

次のステップ

• Azure Stack統合システムのサービス ポリシーと、システムをサポートされている状態に保つために何を行う必要があるかを確認するには、「Azure Stack サービス ポリシーを参照してください。
• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。
• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。

1809 アーカイブされたリリース ノート

統合システムAzure Stack適用

この記事では、1809 更新プログラム パッケージの内容について説明します。 更新プログラム パッケージには、このバージョンのAzure Stackの機能強化、修正、既知の問題が含まれています。 また、更新プログラムをダウンロードできるリンクも掲載されています。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1809 更新プログラムのビルド番号は 1.1809.0.90 です。

新機能

この更新プログラムには、Azure Stackに関する次の機能強化が含まれています。

• このリリースでは、Azure Stack統合システムでは、4 から 16 個のノードの構成がサポートされます。 Azure Stack Capacity Planner を使用すると、Azure Stack容量と構成の計画に役立ちます。

• Azure Stack syslog クライアント (一般提供): このクライアントを使用すると、Azure Stack インフラストラクチャに関連する監査、アラート、セキュリティ ログを syslog サーバーまたはAzure Stack外部のセキュリティ情報およびイベント管理 (SIEM) ソフトウェアに転送できます。 Syslog のクライアントは、syslog サーバーがリッスンするポートを指定できるようになりました。

  このリリースでは、syslog クライアントは、一般利用可能であり、運用環境のために使用できます。

  詳細については、「Azure Stack syslog 転送を参照してください。

• Azureで登録リソースをリソースグループ間で再登録することなく移動できるようになりました。 また、クラウド ソリューション プロバイダー (CSP) でも、新しいサブスクリプションと古いサブスクリプションが両方とも同じ CSP パートナー ID にマッピングされている限り、サブスクリプション間で登録リソースを移動することができます。 これは、既存の顧客テナントのマッピングには影響しません。

• ネットワーク インターフェイスごとに複数の IP アドレスを割り当てられるようになりました。 詳しくは、「PowerShell を使用して仮想マシンに複数の IP アドレスを割り当てる」をご覧ください。

修正された問題

• ポータルで、空き/使用済み容量を報告するメモリのグラフが正確になりました。 作成できる VM の数をより確実に予測できるようになりました。

• Azure Stack ユーザー ポータルで仮想マシンを作成し、ポータルに DS シリーズ VM に接続できるデータ ディスクの数が正しく表示されていない問題を修正しました。 DS シリーズ VM は、Azure構成と同数のデータ ディスクに対応できます。

• 次のマネージド ディスクの問題は 1809 で修正され、1808 Azure Stack 修正プログラム 1.1808.9.117 で修正されています。

  • SSD データ ディスクを Premium サイズのマネージド ディスク仮想マシン (DS、DSv2、Fs、Fs_V2) にアタッチすると、次のエラーで失敗していた問題が修正されました。"仮想マシン vmname のディスクを更新できませんでした。エラー: ストレージ アカウントの種類 Premium_LRS は VM サイズ Standard_DS/Ds_V2/FS/Fs_v2 ではサポートされないため、要求された操作は実行できません。"

  • createOption:Attach を使用して、マネージド ディスク VM を作成すると、次のエラーで失敗します。"長時間実行処理は状態 '失敗' で失敗しました。追加情報: 内部実行エラーが発生しました。エラーコード: InternalExecutionError ErrorMessage: 内部実行エラーが発生しました。"

    この問題は修正されました。

• 動的割り当てメソッドを使用してデプロイされているパブリック IP の固定された問題は、停止-割り当て解除が発行された後も保持される保証はありませんでした。 これらは保存されるようになりました。
• VM が 1808 の前に停止‐割り当て解除された場合、これは 1808 の更新後に再割り当てできませんでした。 この問題は 1809 で修正されています。 ここの状態にあり開始できなかったインスタンスは、この修正によって 1809 で開始できます。 また、修正プログラムにより、この問題は再発しないようになります。

変更点

• インフラストラクチャ バックアップ サービスは、パブリック インフラストラクチャ ネットワークからパブリック VIP ネットワークに移動します。 お客様は、サービスがパブリック VIP ネットワークからバックアップ ストレージの場所にアクセスできることを確認する必要があります。

共通脆弱性と脆弱性曝露

これらの脆弱性の詳細については、上記のリンクをクリックするか、Microsoft サポート技術情報の記事 4457131 と 4462917 を参照してください。

前提条件

• 1809 を適用する前に、1808 の最新のAzure Stack修正プログラムをインストールします。 詳細については、「KB 4481066 - Azure Stack 修正プログラム Azure Stack 修正プログラム 1.1808.9.117 を参照してください。 Microsoft では、利用可能な最新の修正プログラムを推奨していますが、1809 のインストールに必要な最小バージョンは 1.1808.5.110 です。

• この更新プログラムのインストールを開始する前に、次のパラメーターを指定して Test-AzureStack を実行して、Azure Stackの状態を検証し、検出されたすべての警告やエラーなどの操作上の問題を解決します。 また、アクティブなアラートを確認し、アクションが必要なアラートを解決します。

  Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary
  

• Azure StackがSystem Center Operations Managerによって管理されている場合は、1809 を適用する前に、必ず Microsoft Azure Stack 用管理パックをバージョン 1.0.3.11 に更新してください。

更新プロセスに関する既知の問題

• 1809 更新の後で Test-AzureStack を実行すると、Baseboard Management Controller (BMC) からの警告メッセージが表示されます。 この警告は無視しても問題ありません。

• この更新プログラムのインストール中に、"エラー - FaultType UserAccounts.New のテンプレートが見つかりません" というタイトルのアラートが表示される場合があります。これらのアラートは無視してかまいません。 この更新プログラムのインストール後、これらのアラートは自動的に閉じられます。

• この更新プログラムのインストール中に仮想マシンを作成しようとしないでください。 更新プログラムの管理の詳細については、「Azure Stackの概要管理の更新を参照してください。

• OEM からAzure Stackに更新プログラムを適用した場合、Update available 通知がAzure Stack管理ポータルに表示されないことがあります。 Microsoft 更新プログラムをインストールするには、Azure Stack の Apply 更新プログラムに関するページにある手順に従って、手動でダウンロードしてインポートします。

更新後の手順

この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、以下のサポート技術情報とサービス ポリシーに関するページを参照してください。

• KB 4481548 - Azure Stack 修正プログラム Azure Stack 修正プログラム 1.1809.12.114

既知の問題 (インストール後)

このビルド バージョンのインストール後について次の既知の問題があります。

Portal

• Azure Stack技術ドキュメントでは、最新のリリースに焦点を当てています。 リリース間のポータルの変更により、Azure Stack ポータルの使用時に表示される内容は、ドキュメントに表示される内容とは異なる場合があります。

• 管理ポータルで、ユーザーのサブスクリプションの詳細にアクセスした後、ブレードを閉じて、[最近] をクリックした場合、ユーザーのサブスクリプション名が表示されません。

• 管理ポータルとユーザー ポータルの両方で、ポータルの設定をクリックした後、[すべての設定とプライベート ダッシュボードを削除] を選んでも、想定どおりに機能しません。 エラー通知が表示されます。

• 管理ポータルとユーザー ポータルの両方で、[すべてのサービス] の下に、資産 [DDoS protection プラン] が表示されますが、これは正しくありません。 Azure Stackでは使用できません。 これを作成しようとすると、ポータルが Marketplace アイテムを作成できなかったというエラーが表示されます。

• 管理ポータルとユーザー ポータルの両方で、"Docker" を検索すると、返される項目が正しくありません。 Azure Stackでは使用できません。 これを作成しようとすると、エラーを示すブレードが表示されます。

• Azure Stack管理者ポータルまたはユーザー ポータルへのサインインに使用するアカウントは、Unidentified ユーザーとして表示されます。 このメッセージは、アカウントに名と姓がどちらも指定されていない場合に表示されます。 この問題を回避するには、ユーザー アカウントを編集して、名または姓のどちらかを指定してください。 その後、いったんサインアウトし、ポータルにもう一度サインインする必要があります。

• ポータルを使用して仮想マシン スケール セット (VMSS) を作成すると、インスタンス サイズ ドロップダウンが Internet Explorer で正しく読み込まれません。 この問題を回避するには、ポータルを使用して VMSS を作成するときに別のブラウザーをご使用ください。

• アドオン プランとしてユーザー サブスクリプションに追加されたプランは、ユーザー サブスクリプションからプランを削除しても削除できません。 アドオン プランを参照するサブスクリプションも削除されるまで、プランは残ります。

• このバージョンを実行する新しいAzure Stack環境をインストールすると、Activation Required を示すアラートが表示されないことがあります。 マーケットプレース シンジケーションを使用するには、アクティブ化する必要があります。

• バージョン 1804 で導入された 2 種類の管理サブスクリプションは使用しないでください。 このサブスクリプションの種類は Metering サブスクリプションと Consumption サブスクリプションです。 これらのサブスクリプションの種類は、バージョン 1804 以降の新しいAzure Stack環境で表示されますが、まだ使用できる状態ではありません。 既定のプロバイダー サブスクリプションの種類を引き続き使用する必要があります。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

健康と監視

• Azure Stack システムでは、次のアラートが繰り返し表示され、表示されなくなります。

  • Infrastructure role instance unavailable\(インフラストラクチャ ロール インスタンスを利用できません\)
  • Scale unit node is offline(スケール ユニットがオフラインです)

  Test-AzureStack コマンドレットを実行して、インフラストラクチャ ロール インスタンスとスケール ユニット ノードの正常性を確認してください。 Test-AzureStack によって問題が検出されない場合は、これらのアラートを無視することができます。 問題が検出された場合は、管理ポータルまたは PowerShell を使用して、インフラストラクチャ ロール インスタンスまたはノードの開始を試みることができます。

  この問題は最新の 1809 修正プログラム リリースで修正されているので、問題が発生している場合は、この修正プログラムをインストールしてください。

• 以下の詳細を持つ正常性コントローラーコンポーネントのアラートが表示されることがあります。

  アラート #1:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラー「ハートビートスキャナー」は利用できません。 これは、健康レポートと指標に影響する可能性があります。

  アラート #2:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラーの故障スキャナーは使用できません。 これは、健康レポートと指標に影響する可能性があります。

  どちらのアラートも無視しても問題ありません。時間が経過すると、自動的に閉じられます。

• 以下の詳細情報を含む Storage コンポーネントのアラートが表示される場合があります。

  • 名前: Storage サービスの内部通信エラー

  • 重大度: 緊急

  • コンポーネント: Storage

  • 説明: 次のノードに要求を送信するときに Storage サービスの内部通信エラーが発生しました。

    アラートは無視しても差し支えありませんが、手動で閉じる必要があります。

• Azure Stackオペレーターがメモリ不足アラートを受け取り、テナント仮想マシンが Fabric VM 作成エラーでデプロイに失敗した場合、Azure Stack スタンプが使用可能なメモリ不足になっている可能性があります。 Azure Stack Capacity Planner を使用して、ワークロードで使用可能な容量を最適に把握します。

Compute

• Dv2 シリーズ VM を作成する場合、D11 14v2 VM では、それぞれ 4、8、16、32 個のデータ ディスクを作成できます。 ただし、VM の作成ウィンドウには、8、16、32、および 64 個のデータ ディスクが表示されます。

• v2 サフィックスを含むサイズ (Standard_A2_v2 など) で VM をデプロイするには、サフィックスを Standard_A2_v2 (小文字の v) と指定してください。 Standard_A2_V2 (大文字の V) は使用しないでください。 これはグローバル Azureで動作し、Azure Stackの不整合です。

• Azure Stack ポータルを使用して新しい仮想マシン (VM) を作成し、VM サイズを選択すると、USD/Month 列にUnavailable メッセージが表示されます。 この列は表示されません。VM の価格列の表示は、Azure Stackではサポートされていません。

• Add-AzsPlatformImage コマンドレットを使用する場合は、ディスクのアップロード先のストレージ アカウント URI として -OsUri パラメーターを使用する必要があります。 ディスクのローカル パスを使用した場合、次のエラーが出てコマンドレットが失敗します: 長時間実行処理が状態 失敗 で失敗しました。

• ポータルを使用して Premium VM サイズ (DS、Ds_v2、FS、FSv2) の仮想マシン (VM) を作成すると、VM は Standard ストレージ アカウントで作成されます。 Standard ストレージ アカウントで作成しても、機能、IOPS、課金に影響はありません。

  " Premium ディスクをサポートするサイズで Standard ディスクを使用することを選択しました" という警告は無視しても問題ありません。これはオペレーティング システムのパフォーマンスに影響を与える可能性があり、推奨されません。代わりに Premium Storage (SSD) を使用することを検討してください。

• 仮想マシン スケール セット (VMSS) の作成エクスペリエンスでは、デプロイのオプションとして CentOS-based 7.2 が提供されます。 そのイメージはAzure Stackでは使用できないため、デプロイ用に別の OS を選択するか、オペレーターによって Marketplace からデプロイする前にダウンロードされた別の CentOS イメージを指定するAzure Resource Manager テンプレートを使用します。

• スケール ユニットの管理に PowerShell コマンドレットの Start-AzsScaleUnitNode または Stop-AzsScaleunitNode を使った場合、スケール ユニットを開始または停止しようとすると、1 回目は失敗することがあります。 初回実行時にコマンドレットが失敗した場合は、もう一度コマンドレットを実行してください。 2 回目では、操作が正常に完了するはずです。

• VM の展開で拡張機能のプロビジョニングに時間がかかりすぎる場合、ユーザーは、プロセスを停止して VM の割り当て解除または削除を試みるのではなく、プロビジョニングをタイムアウトさせる必要があります。

• Linux VM 診断は、Azure Stackではサポートされていません。 VM 診断を有効にして Linux VM を展開すると、展開が失敗します。 診断設定で Linux VM の基本メトリックを有効にした場合も、展開が失敗します。

• サブスクリプション設定で Microsoft.Insight リソース プロバイダーを登録し、ゲスト OS 診断が有効になっているWindows VM を作成すると、VM の概要ページの CPU 使用率グラフにはメトリック データが表示されません。

  VM の CPU 使用率グラフなどのメトリック データを見つけるには、[メトリック] ウィンドウに移動し、サポートされているすべてのWindows VM ゲスト メトリックを表示します。

• Managed Disks は、プロビジョニング可能なマネージドディスクの最大容量を制限するために、2 つの新しい コンピュートクォータタイプを作成します。 既定では、2,048 GiB がマネージド ディスク クォータの種類ごとに割り当てられます。 ただし、次の問題が発生する可能性があります。

  • 1808 更新プログラムの前に作成されたクォータの場合、Managed Disks クォータには管理者ポータルに 0 個の値が表示されますが、2048 GiB が割り当てられます。 値は実際のニーズに基づいて増減することができ、新しく設定したクォータ値が 2,048 GiB の既定値をオーバーライドします。
  • クォータ値を 0 に更新することは、2,048 GiB の既定値と同じことになります。 回避策として、クォータ値を 1 に設定します。

• 1809 更新プログラムを適用した後、Managed Disksを使用して VM をデプロイするときに、次の問題が発生する可能性があります。

  • 1808 更新プログラムの前にサブスクリプションが作成された場合、Managed Disksを使用して VM をデプロイすると、内部エラー メッセージで失敗する可能性があります。 エラーを解決するには、サブスクリプションごとに次の手順に従います。
    1. テナント ポータルで、[サブスクリプション] に移動して、サブスクリプションを検索します。 [リソース プロバイダー] をクリックし、[Microsoft.Compute] をクリックした後、[再登録] をクリックします。
    2. 同じサブスクリプションで、Access Control (IAM) に移動し、AzureStack-DiskRP-Client ロールが一覧表示されていることを確認します。
  • マルチテナント環境を構成した場合、ゲスト ディレクトリに関連付けられているサブスクリプションで VM をデプロイすると、内部エラー メッセージが出て失敗することがあります。 このエラーを解決するには、この記事にある手順に従って、各ゲスト ディレクトリを構成します。

• SSH の認可を有効にして作成した Ubuntu 18.04 VM では、SSH キーを使用してログインすることはできません。 回避策として、プロビジョニング後に Linux 拡張機能用の VM アクセスを使用して SSH キーを実装するか、パスワード ベースの認証を使用してください。

ネットワーク

• [Networking の下で、vpn 接続を設定するために Create VPN Gateway をクリックすると、VPN の種類として Policy Based が表示されます。 このオプションを選択しないでください。 Azure Stackでは、Route Based オプションのみがサポートされます。

• Azure Stackでは、IP アドレスごとに 1 つのローカル ネットワーク ゲートウェイがサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• Automatic の DNS サーバー設定で作成されたVirtual Networkでは、カスタム DNS サーバーへの変更は失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• Azure Stack Secret Rotation では、パブリック IP アドレスに 2 ~ 5 分間到達できない期間があります。

• テナントが S2S VPN トンネルを使用して仮想マシンにアクセスするシナリオでは、ゲートウェイが既に作成された後でオンプレミスのサブネットがローカル ネットワーク ゲートウェイに追加された場合、接続しようとしても失敗するシナリオが発生する可能性があります。

App Service

• ユーザーは、サブスクリプションで最初の Azure 関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。

使用方法

• パブリック IP アドレス使用量メーターのデータは、レコードが作成された日時を示す TimeDate スタンプではなく、各レコードに対して同じ EventDateTime 値を示します。 現在、このデータを使用して、パブリック IP アドレスの使用を正確に算出することはできません。

更新プログラムのダウンロード

Azure Stack 1809 更新プログラム パッケージは、here からダウンロードできます。

次のステップ

• Azure Stack統合システムのサービス ポリシーと、システムをサポートされている状態に保つために何を行う必要があるかを確認するには、「Azure Stack サービス ポリシーを参照してください。
• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。
• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。

1808 アーカイブされたリリース ノート

統合システムAzure Stack適用

この記事では、1808 更新プログラム パッケージの内容について説明します。 更新プログラム パッケージには、このバージョンのAzure Stackの機能強化、修正、既知の問題が含まれています。 また、更新プログラムをダウンロードできるリンクも掲載されています。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1808 更新プログラムのビルド番号は 1.1808.0.97 です。

新機能

この更新プログラムには、Azure Stackの次の機能強化が含まれています。

• すべてのAzure Stack環境で協定世界時 (UTC) タイム ゾーン形式が使用されるようになりました。 すべてのログ データと関連情報は、UTC 形式で表示されます。 UTC を使用するようにインストールされていない以前のバージョンから更新する場合は、UTC を使用するように環境が更新されます。

• Managed Disksがサポートされています。 Azure Stack仮想マシンと仮想マシン スケール セットでManaged Disksを使用できるようになりました。 詳細については、「Azure Stack Managed Disks: 相違点と考慮事項を参照してください。

• Azure Monitor。 AzureでのAzure Monitorと同様に、Azure StackのAzure Monitorは、ほとんどのサービスに対して基本レベルのインフラストラクチャ メトリックとログを提供します。 詳細については、Azure Stackの Azure Monitor を参照してください。

• 拡張機能ホストのための準備。 拡張ホストを使用すると、必要な TCP/IP ポートの数を減らすことで、Azure Stackをセキュリティで保護できます。 1808 更新プログラムを使用すると、拡張機能ホストの準備、Azure Stackの準備を行うことができます。 詳細については、「Azure Stack の拡張ホストの準備」を参照してください。

• Virtual Machine Scale Setsのギャラリー項目が組み込みになりました。 仮想マシン スケール セットのギャラリー項目がユーザーおよび管理者のポータルで利用可能になりました。ダウンロードする必要はありません。 1808 にアップグレードする場合は、アップグレードの完了時に利用可能になります。

• 仮想マシン スケール セットのスケーリング。 ポータルを使用して、仮想マシン スケール セットをスケールすることができます (VMSS)。

• カスタム IPSec/IKE ポリシー構成のサポートは Azure Stack の VPN ゲートウェイに対応。

• Kubernetes Marketplace アイテム。 Kubernetes クラスターのデプロイに Kubernetes Marketplace アイテムを使用できるようになりました。 ユーザーは Kubernetes 項目を選択し、いくつかのパラメーターを入力して、Azure Stackする Kubernetes クラスターをデプロイできます。 このテンプレートの目的は、ユーザーが少ないステップで開発/テスト用の Kubernetes デプロイをセットアップできるように簡素化することです。

• Blockchain テンプレート。 Ethereum コンソーシアムのデプロイをAzure Stackで実行できるようになりました。 Azure Stack クイック スタート テンプレートには、3 つの新しいテンプレートがあります。 これにより、ユーザーは、最小限のAzureと Ethereum の知識を持つマルチメンバー コンソーシアム Ethereum ネットワークをデプロイして構成できます。 このテンプレートの目的は、ユーザーが少ないステップで開発/テスト用のブロックチェーン デプロイをセットアップできるように簡素化することです。

• API バージョン プロファイル 2017-03-09-profile が 2018-03-01-hybrid に更新されました。 API プロファイルでは、Azure REST エンドポイントのAzure リソース プロバイダーと API バージョンを指定します。 プロファイルの詳細については、「Azure Stack の Manage API バージョン プロファイル」を参照してください。

修正された問題

• ポータルで可用性セットを作成すると 1 の障害ドメインと更新ドメインがセットに含められるという問題が修正されました。

• 仮想マシン スケール セットのスケーリング設定がポータルで使用できるようになりました。

• デプロイの VM サイズを選択するときに F シリーズの一部の仮想マシン サイズが表示されないという問題が解決されました。

• 仮想マシンの作成時のパフォーマンスが向上し、基になるストレージの使用がさらに最適化されました。

• パフォーマンス、安定性、セキュリティ、およびAzure Stackで使用されるオペレーティング システムに関するさまざまな修正。

変更点

• ユーザー ポータル ダッシュボードの Quickstart チュートリアルは、オンライン Azure Stack ドキュメントの関連記事にリンクされるようになりました。

• すべてのサービスは、Azure Stack管理者ポータルとユーザー ポータルの More services を置き換えます。 すべてのサービスを、Azure ポータルと同じ方法でAzure Stack ポータル内を移動する代わりに使用できるようになりました。

• + リソースの作成は、Azure Stack管理者ポータルとユーザー ポータルの + New に置き換えられます。 + リソースの作成を使用して、Azure ポータルと同じ方法でAzure Stack ポータル内を移動できるようになりました。

• Basic A の仮想マシン サイズは、ポータルを介して仮想マシン スケール セット (VMSS) を作成するものとしては廃止されました。 このサイズの VMSS を作成するには、PowerShell またはテンプレートをご使用ください。

共通脆弱性と危険性

これらの脆弱性の詳細については、上記のリンクをクリックするか、Microsoft サポート技術情報の記事 4343887 をご覧ください。

この更新プログラムには、L1 ターミナル 障害 (L1TF) と呼ばれる投機的実行側チャネルの脆弱性の軽減策も含まれています。

前提条件

• Azure Stack 1808 更新プログラムを適用する前に、Azure Stack 1807 更新プログラムをインストールします。

• この更新プログラムのインストールを開始する前に、次のパラメーターを指定して Test-AzureStack を実行して、Azure Stackの状態を検証し、検出されたすべての警告やエラーなどの操作上の問題を解決します。 また、アクティブなアラートを確認し、アクションが必要なアラートを解決します。

  Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary
  

更新プロセスに関する既知の問題

• 1808 更新の後で Test-AzureStack を実行すると、Baseboard Management Controller (BMC) からの警告メッセージが表示されます。 この警告は無視しても問題ありません。

• この更新プログラムのインストール中に、"エラー - FaultType UserAccounts.New のテンプレートが見つかりません" というタイトルのアラートが表示される場合があります。これらのアラートは無視してかまいません。 この更新プログラムのインストール後、これらのアラートは自動的に閉じられます。

• この更新プログラムのインストール中に仮想マシンを作成しようとしないでください。 更新プログラムの管理の詳細については、「Azure Stackの概要管理の更新を参照してください。

• 更新で注意が必要な特定の状況では、対応するアラートが生成されないことがあります。 それでも正確な状態はポータルに反映され、影響を受けることはありません。

更新後の手順

この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、以下のサポート技術情報とサービス ポリシーに関するページを参照してください。

• KB 4465859 Azure Stack 修正プログラム Azure Stack 修正プログラム 1.1808.2.104

既知の問題 (インストール後)

このビルド バージョンのインストール後について次の既知の問題があります。

Portal

• Azure Stack技術ドキュメントでは、最新のリリースに焦点を当てています。 リリース間のポータルの変更により、Azure Stack ポータルの使用時に表示される内容は、ドキュメントに表示される内容とは異なる場合があります。

• ポータルに空のダッシュボードが表示されることがあります。 ダッシュボードを回復するには、[ダッシュボードの編集] をクリックし、右クリックして、[既定の状態にリセット] を選んでください。

• 管理ポータルで、ユーザーのサブスクリプションの詳細にアクセスした後、ブレードを閉じて、[最近] をクリックした場合、ユーザーのサブスクリプション名が表示されません。

• 管理ポータルとユーザー ポータルの両方で、ポータルの設定をクリックした後、[すべての設定とプライベート ダッシュボードを削除] を選んでも、想定どおりに機能しません。 エラー通知が表示されます。

• 管理ポータルとユーザー ポータルの両方で、[すべてのサービス] の下に、資産 [DDoS protection プラン] が表示されますが、これは正しくありません。 実際にはAzure Stackでは使用できません。 これを作成しようとすると、ポータルが Marketplace アイテムを作成できなかったというエラーが表示されます。

• 管理ポータルとユーザー ポータルの両方で、"Docker" を検索すると、返される項目が正しくありません。 実際にはAzure Stackでは使用できません。 これを作成しようとすると、エラーを示すブレードが表示されます。

• Azure Stack管理者ポータルまたはユーザー ポータルへのサインインに使用するアカウントは、Unidentified ユーザーとして表示されます。 これは、アカウントに名と姓がどちらも指定されていない場合に発生します。 この問題を回避するには、ユーザー アカウントを編集して、名または姓のどちらかを指定してください。 その後、いったんサインアウトし、ポータルにもう一度サインインする必要があります。

• ポータルを使用して仮想マシン スケール セット (VMSS) を作成すると、インスタンス サイズ ドロップダウンが Internet Explorer で正しく読み込まれません。 この問題を回避するには、ポータルを使用して VMSS を作成するときに別のブラウザーをご使用ください。

• アドオン プランとしてユーザー サブスクリプションに追加されたプランは、ユーザー サブスクリプションからプランを削除しても削除できません。 アドオン プランを参照するサブスクリプションも削除されるまで、プランは残ります。

• このバージョンを実行する新しいAzure Stack環境をインストールすると、Activation Required を示すアラートが表示されないことがあります。 マーケットプレース シンジケーションを使用するには、アクティブ化する必要があります。

• バージョン 1804 で導入された 2 種類の管理サブスクリプションは使用しないでください。 このサブスクリプションの種類は Metering サブスクリプションと Consumption サブスクリプションです。 これらのサブスクリプションの種類は、バージョン 1804 以降の新しいAzure Stack環境で表示されますが、まだ使用できる状態ではありません。 既定のプロバイダー サブスクリプションの種類を引き続き使用する必要があります。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

健康と監視

• 以下の詳細を持つ正常性コントローラーコンポーネントのアラートが表示されることがあります。

  アラート #1:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラー「ハートビートスキャナー」は利用できません。 これは、健康レポートと指標に影響する可能性があります。

  アラート #2:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラーの故障スキャナーは使用できません。 これは、健康レポートと指標に影響する可能性があります。

  どちらのアラートも無視しても問題ありません。時間が経過すると、自動的に閉じられます。

• 以下の詳細情報を含む Storage コンポーネントのアラートが表示される場合があります:

  • 名前: Storage サービスの内部通信エラー

  • 重大度: 緊急

  • コンポーネント: Storage

  • 説明: 次のノードに要求を送信するときに Storage サービスの内部通信エラーが発生しました。

    アラートは無視しても差し支えありませんが、手動で閉じる必要があります。

• Azure Stackオペレーターがメモリ不足アラートを受け取り、テナント仮想マシンが Fabric VM 作成エラーでデプロイに失敗した場合、Azure Stack スタンプが使用可能なメモリ不足になっている可能性があります。 Azure Stack Capacity Planner を使用して、ワークロードで使用可能な容量を最適に把握します。

Compute

• Azure Stack ポータルを使用して新しい仮想マシン (VM) を作成し、VM サイズを選択すると、USD/Month 列にUnavailable メッセージが表示されます。 この列は表示されません。VM の価格列の表示は、Azure Stackではサポートされていません。

• 1808 更新プログラムを適用した後、Managed Disksを使用して VM をデプロイするときに、次の問題が発生する可能性があります。

  1. 1808 更新プログラムの前にサブスクリプションが作成された場合、Managed Disksを使用して VM をデプロイすると、内部エラー メッセージで失敗する可能性があります。 エラーを解決するには、サブスクリプションごとに次の手順に従います。
     1. テナント ポータルで、[サブスクリプション] に移動して、サブスクリプションを検索します。 [リソース プロバイダー] をクリックし、[Microsoft.Compute] をクリックした後、[再登録] をクリックします。
     2. 同じサブスクリプションで、Access Control (IAM) に移動し、Azure Stackマネージド ディスクが一覧表示されていることを確認します。
  2. マルチテナント環境を構成した場合、ゲスト ディレクトリに関連付けられているサブスクリプションで VM をデプロイすると、内部エラー メッセージが出て失敗することがあります。 エラーを解決するには、次の手順に従います。
     1. 1808 Azure Stack修正プログラムを適用します。
     2. この記事にある手順に従って、各ゲスト ディレクトリを構成します。

• Add-AzsPlatformImage コマンドレットを使用する場合は、ディスクのアップロード先のストレージ アカウント URI として -OsUri パラメーターを使用する必要があります。 ディスクのローカル パスを使用すると、このコマンドレットは次のエラーで失敗します。長時間実行されている操作が「失敗」という状態で失敗しました。

• SSD データ ディスクを Premium サイズのマネージド ディスク仮想マシン (DS、DSv2、Fs、Fs_V2) にアタッチすると、次のエラーが出て失敗します: "仮想マシン vmname のディスクを更新できませんでした。エラー: ストレージ アカウントの種類 Premium_LRS は VM サイズ Standard_DS/Ds_V2/FS/Fs_v2 ではサポートされないため、要求された操作は実行できません"

  この問題を回避するには、Premium_LRS ディスクの代わりに Standard_LRS データ ディスクをご使用ください。 Standard_LRS データ ディスクを使用しても、IOPS または課金コストは変わりません。

• ポータルを使用して Premium VM サイズ (DS、Ds_v2、FS、FSv2) の仮想マシン (VM) を作成すると、VM は Standard ストレージ アカウントで作成されます。 Standard ストレージ アカウントで作成しても、機能、IOPS、課金に影響はありません。

  " Premium ディスクをサポートするサイズで Standard ディスクを使用することを選択しました" という警告は無視しても問題ありません。これはオペレーティング システムのパフォーマンスに影響を与える可能性があり、推奨されません。代わりに Premium Storage (SSD) を使用することを検討してください。

• 仮想マシン スケール セット (VMSS) の作成エクスペリエンスでは、デプロイのオプションとして CentOS-based 7.2 が提供されます。 そのイメージはAzure Stackでは使用できないため、デプロイ用に別の OS を選択するか、オペレーターがマーケットプレースからデプロイする前にダウンロードした別の CentOS イメージを指定するAzure Resource Manager テンプレートを使用します。

• スケール ユニットの管理に PowerShell コマンドレットの Start-AzsScaleUnitNode または Stop-AzsScaleunitNode を使った場合、スケール ユニットを開始または停止しようとすると、1 回目は失敗することがあります。 初回実行時にコマンドレットが失敗した場合は、もう一度コマンドレットを実行してください。 2 回目では、操作が正常に完了するはずです。

• Azure Stack ユーザー ポータルで仮想マシンを作成すると、DS シリーズ VM に接続できるデータ ディスクの数が誤って表示されます。 DS シリーズ VM は、Azure構成と同数のデータ ディスクに対応できます。

• VM の展開で拡張機能のプロビジョニングに時間がかかりすぎる場合、ユーザーは、プロセスを停止して VM の割り当て解除または削除を試みるのではなく、プロビジョニングをタイムアウトさせる必要があります。

• Linux VM 診断は、Azure Stackではサポートされていません。 VM 診断を有効にして Linux VM を展開すると、展開が失敗します。 診断設定で Linux VM の基本メトリックを有効にした場合も、展開が失敗します。

• サブスクリプション設定で Microsoft.Insight リソース プロバイダーを登録し、ゲスト OS 診断が有効なWindows VM を作成すると、VM の概要ページの CPU 使用率グラフにメトリック データを表示できなくなります。

  VM の CPU 使用率グラフを見つけるには、Metrics ブレードに移動し、サポートされているすべての Windows VM ゲスト メトリックを表示します。

ネットワーク

• [Networking の下で、vpn 接続を設定するために Create VPN Gateway をクリックすると、VPN の種類として Policy Based が表示されます。 このオプションを選択しないでください。 Azure Stackでは、Route Based オプションのみがサポートされます。

• Azure Stackでは、IP アドレスごとに 1 つのローカル ネットワーク ゲートウェイがサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• Automatic の DNS サーバー設定で作成されたVirtual Networkでは、カスタム DNS サーバーへの変更は失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• 動的割り当てメソッドを使用してデプロイされているパブリック IP は、停止 - 割り当て解除が発行された後も保持される保証はありません。

• Azure Stack Secret Rotation では、パブリック IP アドレスに 2 ~ 5 分間到達できない期間があります。

• テナントが S2S VPN トンネルを使用して仮想マシンにアクセスするシナリオでは、ゲートウェイが既に作成された後でオンプレミスのサブネットがローカル ネットワーク ゲートウェイに追加された場合、接続しようとしても失敗するシナリオが発生する可能性があります。

App Service

• ユーザーは、サブスクリプションで最初の Azure 関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。

• インフラストラクチャ (worker、管理、フロントエンド ロール) をスケールアウトするには、コンピューティングのリリース ノートの説明に従って PowerShell を使用する必要があります。

使用方法

• パブリック IP アドレス使用量メーターのデータは、レコードが作成された日時を示す TimeDate スタンプではなく、各レコードに対して同じ EventDateTime 値を示します。 現在、このデータを使用して、パブリック IP アドレスの使用を正確に算出することはできません。

更新プログラムのダウンロード

Azure Stack 1808 更新プログラム パッケージは、here からダウンロードできます。

次のステップ

• Azure Stack統合システムのサービス ポリシーと、システムをサポートされている状態に保つために何を行う必要があるかを確認するには、「Azure Stack サービス ポリシーを参照してください。
• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。
• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。

1807 アーカイブされたリリース ノート

統合システムAzure Stack適用

この記事では、1807 更新プログラム パッケージの内容について説明します。 この更新プログラムには、このバージョンのAzure Stackの機能強化、修正、既知の問題、および更新プログラムをダウンロードする場所が含まれています。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1807 更新プログラムのビルド番号は 1.1807.0.76 です。

新機能

この更新プログラムには、Azure Stackの次の機能強化が含まれています。

• 事前に定義されたスケジュールでバックアップを開始する - アプライアンスとして、Azure Stackはインフラストラクチャ バックアップを定期的に自動的にトリガーして、人間の介入を排除できるようになりました。 Azure Stackでは、定義された保有期間よりも古いバックアップの外部共有も自動的にクリーンアップされます。 詳細については、「 PowerShell を使用したAzure Stackの有効なバックアップを参照してください。

• 合計バックアップ時間にデータ転送時間が追加されました。 詳細については、「 PowerShell を使用したAzure Stackの有効なバックアップを参照してください。

• 外部バックアップ容量に、外部共有の正確な容量が表示されるようになりました。 (以前は、これは 10 GB にハードコードされていました。) 詳細については、「PowerShell を使用した Azure Stack でのバックアップを有効化する」を参照してください。

• 容量を拡張するには、新たにスケール ユニット ノードを追加します。

• Azure Resource Manager テンプレートで condition 要素がサポートされるようになりました - 条件を使用して、Azure Resource Manger テンプレートにリソースをデプロイできるようになりました。 パラメーター値の有無の評価などの条件に基づいてリソースをデプロイするようにテンプレートを設計することができます。 テンプレートを条件として使用する方法については、Azureドキュメントの「Conditionally deploy a resource and Variables」セクションを参照Azure Resource Managerテンプレートを参照してください。

  テンプレートを使用して、複数のサブスクリプションまたはリソース グループにリソースをデプロイすることもできます。

• Microsoft.Network API リソースバージョンのサポートが更新され、Azure Stack ネットワークリソースの API バージョン 2015-06-15 から 2017-10-01 のサポートが含まれるようになりました。 リソース バージョン 2017-10-01 から 2015-06-15 までのサポートは、このリリースには含まれていません。 機能の違いについては、Azure Stack ネットワークに関するページを参照してください。

• Azure Stack では、外部に接続する Azure Stack インフラストラクチャ エンドポイント (つまり、portal、adminportal、management、および adminmanagement) の逆引き DNS 参照のサポートが追加されました。 これにより、Azure Stack外部エンドポイント名を IP アドレスから解決できます。

• Azure Stackでは、既存の VM へのネットワーク インターフェイスの追加がサポートされるようになりました。 この機能は、ポータル、PowerShell、CLI を使用して利用できます。 詳細については、Azureドキュメントの「ネットワーク インターフェイスを追加または削除する」を参照してください。

• ネットワーク使用量メーターの正確性と回復性が向上しました。 ネットワーク使用量メーターがより正確になり、中断されたサブスクリプション、停止期間、競合状態が考慮されるようになりました。

• 更新プログラムが利用可能な場合の通知。 接続Azure Stackデプロイでは、セキュリティで保護されたエンドポイントが定期的にチェックされ、クラウドで更新プログラムが利用可能かどうかを判断するようになりました。 この通知は、新しい更新を手動で確認してインポートした場合と同様に、更新タイルに表示されます。 Azure Stack の更新プログラムの管理について詳しく読むには、参照してください。

• Azure Stack syslog クライアント (プレビュー機能)の改善。 このクライアントを使用すると、Azure Stack インフラストラクチャに関連する監査とログを syslog サーバーに転送したり、Azure Stack外部のセキュリティ情報およびイベント管理 (SIEM) ソフトウェアを転送したりできます。 Syslog クライアントで、プレーン テキストまたは TLS 1.2 暗号化 (後者が既定の構成) による TCP プロトコルがサポートされるようになりました。 サーバーのみの認証または相互認証のいずれかを使用して、TLS 接続を構成できます。

  Syslog クライアントが Syslog サーバーと通信する方法 (プロトコル、暗号化、認証など) を構成するには、Set-SyslogServer コマンドレットを使用します。 このコマンドレットは、特権エンドポイント (PEP) から入手できます。

  Syslog クライアント TLS 1.2 の相互認証用のクライアント側証明書を追加するには、PEP で Set-SyslogClient コマンドレットを使用します。

  このプレビューでは、監査と警告の数が大幅に増加します。

  この機能はまだプレビュー段階であるため、運用環境では使用しないでください。

  詳細については、「Azure Stack syslog 転送を参照してください。

• Azure Resource Managerにはリージョン名が含まれます。 このリリースでは、Azure Resource Managerから取得したオブジェクトにリージョン名属性が含まれるようになりました。 既存の PowerShell スクリプトが別のコマンドレットにオブジェクトを直接渡すと、スクリプトによってエラーが発生し、失敗することがあります。 これはAzure Resource Manager準拠の動作であり、呼び出し元のクライアントがリージョン属性を減算する必要があります。 Azure Resource Managerの詳細については、Azure Resource Manager ドキュメントを参照してください。

• 委任されたプロバイダーの機能の変更。 1807 以降では、Azure リセラー モデルに合わせて委任されたプロバイダー モデルが簡略化され、委任されたプロバイダーは他の委任されたプロバイダーを作成できず、基本的にモデルをフラット化し、委任されたプロバイダー機能を 1 つのレベルで使用できるようになります。 新しいモデルへの切り替えとサブスクリプションの管理を可能にするために、同じディレクトリ テナントに属する新規または既存の委任されたプロバイダー サブスクリプション間でユーザーサブスクリプションを移動できるようになりました。 また、既定プロバイダー サブスクリプションに属しているユーザーサブスクリプションも、同じディレクトリ テナント内にある委任されたプロバイダー サブスクリプションに移動できます。 詳細については、Azure Stack の Delegate オファーを参照してください。

• Azure Marketplaceからダウンロードしたイメージを使用して作成されるVMの改善された作成時間。

• Azure Stack Capacity Planner の使いやすさの向上。 Azure Stack Capacity Planner では、ソリューション SKU を定義するときに、S2D キャッシュと S2D 容量を入力するための簡略化されたエクスペリエンスが提供されるようになりました。 1000 VM の制限が削除されました。

修正された問題

• 更新プロセスをより信頼できるものにするために、さまざまな改善が行われました。 さらに、基になるインフラストラクチャに修正が加えられました。これにより、更新中に発生する可能性のあるワークロードのダウンタイムが最小限に抑えられます。

• 変更したクォータ制限が既存のサブスクリプションに適用されない問題を修正しました。 今後は、ユーザーのサブスクリプションに関連付けられているオファーとプランについて、そこに含まれるネットワーク リソースのクォータ制限を引き上げると、新しいサブスクリプションだけでなく既存のサブスクリプションにも新しい制限が適用されます。

• UTC+N タイム ゾーンでデプロイされているシステムをアクティビティ ログから検索するクエリが問題なく実行できるようになりました。

• バックアップ構成パラメーター (パス/ユーザー名/パスワード/暗号化キー) の事前確認で、バックアップ構成に間違った設定が適用される問題を修正しました。 (以前は、バックアップに間違った設定が適用され、トリガーされた時点でバックアップが失敗していました。)

• 外部共有から手動でバックアップを削除したときにバックアップ リストが最新の情報に更新されるようになりました。

• このバージョンに更新すると、AD FS を使用してデプロイする際、既定のプロバイダー サブスクリプションの既定の所有者がビルトインの CloudAdmin ユーザーにリセットされなくなりました。

• データセンター統合を設定すると、Azure ファイル共有から AD FS メタデータ ファイルにアクセスできなくなります。 詳細については、「フェデレーション メタデータ ファイルを指定して AD FS の統合を設定する」を参照してください。

• 以前にネットワーク インターフェイスまたはLoad Balancerに割り当てられていた既存のパブリック IP アドレスを新しいネットワーク インターフェイスまたはLoad Balancerに割り当てようとすると、割り当てができない問題を修正しました。

• 管理ポータルまたはユーザー ポータルでストレージ アカウントの [概要] を選択すると、[基本] ウィンドウに必要なすべての情報が正しく表示されるようになりました。

• 管理ポータルまたはユーザー ポータルでストレージ アカウントに [タグ] を選択すると、情報が正しく表示されるようになりました。

• このバージョンのAzure Stackは、OEM 拡張機能パッケージからのドライバー更新プログラムの適用を妨げる問題を修正します。

• VM の作成が失敗したときに、コンピューティング ブレードから VM を削除できないという問題が修正されました。

• メモリ容量不足に対する誤ったアラートが表示されなくなりました。

• パフォーマンス、安定性、セキュリティ、およびAzure Stackで使用されるオペレーティング システムに関するさまざまな修正。

共通脆弱性と危険性

Azure Stackでは、Windows Server 2016の Server Core インストールを使用して、キー インフラストラクチャをホストします。 このリリースでは、Azure Stackのインフラストラクチャ サーバーに次のWindows Server 2016更新プログラムがインストールされます。

• CVE-2018-8206
• CVE-2018-8222
• CVE-2018-8282
• CVE-2018-8304
• CVE-2018-8307
• CVE-2018-8308
• CVE-2018-8309
• CVE-2018-8313

これらの脆弱性の詳細については、上記のリンクをクリックするか、Microsoft サポート技術情報の記事4338814 と 4345418 を参照してください。

開始する前に

前提条件

• Azure Stack 1807 更新プログラムを適用する前に、Azure Stack 1805 更新プログラムをインストールします。 更新プログラム 1806 は存在しません。

• 最新の入手できるバージョン 1805 の更新プログラムまたは修正プログラムをインストールします。

• この更新プログラムのインストールを開始する前に、次のパラメーターを指定して Test-AzureStack を実行して、Azure Stackの状態を検証し、検出されたすべての警告やエラーなどの操作上の問題を解決します。 また、アクティブなアラートを確認し、アクションが必要なアラートを解決します。

  Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary
  

更新プロセスに関する既知の問題

• この更新プログラムのインストール中に、"エラー - FaultType UserAccounts.New のテンプレートが見つかりません" というタイトルのアラートが表示される場合があります。これらのアラートは無視してかまいません。 この更新プログラムのインストール後、これらのアラートは自動的に閉じられます。

• この更新プログラムのインストール中に仮想マシンを作成しようとしないでください。 更新プログラムの管理の詳細については、「Azure Stackの概要管理の更新を参照してください。

• 更新で注意が必要な特定の状況では、対応するアラートが生成されないことがあります。 それでも正確な状態はポータルに反映され、影響を受けることはありません。

更新後の手順

この更新プログラムをインストールした後、適用可能な修正プログラムがあればインストールします。 詳細については、以下のサポート技術情報とサービス ポリシーに関するページを参照してください。

• KB 4464231 Azure Stack 修正プログラム Azure Stack 修正プログラム 1.1807.1.78

この更新プログラムをインストールすると、失敗した更新プログラムのインストールに関して表示される状態が改善されます。これには、2 つの新しい状態カテゴリを反映するように変更された、過去の更新プログラムのインストールの失敗に関する情報が含まれる可能性があります。 これらの 2 つの新しい状態カテゴリとは、PreparationFailed および InstallationFailed です。

既知の問題 (インストール後)

このビルド バージョンのインストール後について次の既知の問題があります。

Portal

• Azure Stack技術ドキュメントでは、最新のリリースに焦点を当てています。 リリース間のポータルの変更により、Azure Stack ポータルの使用時に表示される内容は、ドキュメントに表示される内容とは異なる場合があります。

• 管理ポータルのドロップダウン リストから新しいサポート要求を開く機能は使用できません。 代わりに、Azure Stack統合システムの場合は、次のリンクを使用します: https://aka.ms/newsupportrequest。

• アドオン プランとしてユーザー サブスクリプションに追加されたプランは、ユーザー サブスクリプションからプランを削除しても削除できません。 アドオン プランを参照するサブスクリプションも削除されるまで、プランは残ります。

• このバージョンを実行する新しいAzure Stack環境をインストールすると、Activation Required を示すアラートが表示されないことがあります。 マーケットプレース シンジケーションを使用するには、アクティブ化する必要があります。

• バージョン 1804 で導入された 2 種類の管理サブスクリプションは使用しないでください。 このサブスクリプションの種類は Metering サブスクリプションと Consumption サブスクリプションです。 これらのサブスクリプションの種類は、バージョン 1804 以降の新しいAzure Stack環境で表示されますが、まだ使用できる状態ではありません。 既定のプロバイダー サブスクリプションの種類を引き続き使用する必要があります。

• 管理ポータルとユーザー ポータルの下部に水平スクロールバーが表示されない可能性があります。 水平スクロールバーにアクセスできない場合は、ポータルの左上にある階層リンク リストから表示するブレードの名前を選択して、階層リンクを使用してポータル内の前のブレードに移動します。

• 管理ポータルでコンピューティング リソースやストレージ リソースを表示できない場合があります。 この問題の原因は、更新プログラムのインストール中にエラーが発生し、更新が正常に行われたことが誤って報告されたためです。 この問題が発生した場合は、Microsoft カスタマー サポート サービスにお問い合わせください。

• ポータルに空のダッシュボードが表示されることがあります。 ダッシュボードを復元するには、ポータルの右上にある歯車アイコンを選択し、[既定の設定に戻す] を選択します。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

健康と監視

• 以下の詳細を持つ正常性コントローラーコンポーネントのアラートが表示されることがあります。

  アラート #1:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラー「ハートビートスキャナー」は利用できません。 これは、健康レポートと指標に影響する可能性があります。

  アラート #2:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラーの故障スキャナーは使用できません。 これは、健康レポートと指標に影響する可能性があります。

  どちらのアラートも無視しても問題ありません。時間が経過すると、自動的に閉じられます。

• 以下の詳細情報を含む Storage コンポーネントのアラートが表示される場合があります:

  • 名前: Storage サービスの内部通信エラー

  • 重大度: 緊急

  • コンポーネント: Storage

  • 説明: 次のノードに要求を送信するときに Storage サービスの内部通信エラーが発生しました。

    アラートは無視しても差し支えありませんが、手動で閉じる必要があります。

• Azure Stackオペレーターがメモリ不足アラートを受け取り、テナント仮想マシンが Fabric VM 作成エラーでデプロイに失敗した場合、Azure Stack スタンプが使用可能なメモリ不足になっている可能性があります。 Azure Stack Capacity Planner を使用して、ワークロードで使用可能な容量を最適に把握します。

Compute

• スケール ユニットの管理に PowerShell コマンドレットの Start-AzsScaleUnitNode または Stop-AzsScaleunitNode を使った場合、スケール ユニットを開始または停止しようとすると、1 回目は失敗することがあります。 初回実行時にコマンドレットが失敗した場合は、もう一度コマンドレットを実行してください。 2 回目では、操作が正常に完了するはずです。

• 仮想マシンの展開用に仮想マシンのサイズを選択すると、VM を作成するときに F シリーズの VM のサイズがサイズ セレクターの一部として表示されません。 セレクターに F8s_v2、F16s_v2、F32s_v2、および F64s_v2 の VM サイズが表示されません。
  この問題を回避するには、次のいずれかの方法を使用して VM をデプロイします。 どの方法でも、使用する VM のサイズを指定する必要があります。

  • Azure Resource Manager template: テンプレートを使用する場合は、テンプレートの vmSize を使用する VM サイズと同じに設定します。 たとえば、F32s_v2 サイズを使用する VM をデプロイするには、次のように入力します。

        "properties": {
        "hardwareProfile": {
                "vmSize": "Standard_F32s_v2"
        },
    

  • Azure CLI:az vm create コマンドを使用し、--size "Standard_F32s_v2" と同様に、VM サイズをパラメーターとして指定できます。

  • PowerShell: PowerShell を使用すると、と同様に、VM サイズを指定するパラメーター を使用できます。

• 仮想マシン スケール セットのスケーリング設定は、ポータルで使用できません。 回避策として、Azure PowerShellを使用できます。 PowerShell のバージョンの違いにより、 パラメーターの代わりに を使用する必要があります。

• ポータルで [新規][コンピューティング][可用性セット] に移動して可用性セットを作成した場合、障害ドメインと更新ドメインが 1 の可用性セットのみを作成できます。 回避策として、新しい仮想マシンを作成する場合は、PowerShell、CLI、またはポータル内から可用性セットを作成します。

• Azure Stack ユーザー ポータルで仮想マシンを作成すると、DS シリーズ VM に接続できるデータ ディスクの数が誤って表示されます。 DS シリーズ VM は、Azure構成と同数のデータ ディスクに対応できます。

• VM の展開で拡張機能のプロビジョニングに時間がかかりすぎる場合、ユーザーは、プロセスを停止して VM の割り当て解除または削除を試みるのではなく、プロビジョニングをタイムアウトさせる必要があります。

• Linux VM 診断は、Azure Stackではサポートされていません。 VM 診断を有効にして Linux VM を展開すると、展開が失敗します。 診断設定で Linux VM の基本メトリックを有効にした場合も、展開が失敗します。

• サブスクリプション設定で Microsoft.Insight リソース プロバイダーを登録し、ゲスト OS 診断が有効になっているWindows VM を作成すると、VM の概要ページにはメトリック データが表示されません。

  VM の CPU 使用率グラフなどのメトリック データを見つけるには、Metrics ブレードに移動し、サポートされているすべての Windows VM ゲスト メトリックを表示します。

ネットワーク

• [Networking の下で、vpn 接続を設定するために Create VPN Gateway をクリックすると、VPN の種類として Policy Based が表示されます。 このオプションを選択しないでください。 Azure Stackでは、Route Based オプションのみがサポートされます。

• Azure Stackでは、IP アドレスごとに 1 つのローカル ネットワーク ゲートウェイがサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• Automatic の DNS サーバー設定で作成されたVirtual Networkでは、カスタム DNS サーバーへの変更は失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• 動的割り当てメソッドを使用してデプロイされているパブリック IP は、停止 - 割り当て解除が発行された後も保持される保証はありません。

• Azure Stack Secret Rotation では、パブリック IP アドレスに 2 ~ 5 分間到達できない期間があります。

• テナントが S2S VPN トンネルを使用して仮想マシンにアクセスするシナリオでは、ゲートウェイが既に作成された後でオンプレミスのサブネットがローカル ネットワーク ゲートウェイに追加された場合、接続しようとしても失敗するシナリオが発生する可能性があります。

SQL および MySQL

• SQL と MySQL リソース プロバイダーの SKU を作成する場合、[ファミリ] 名では、スペースやピリオドなどの特殊文字はサポートされていません。

• SQL または MySQL をホストするサーバー上に項目を作成できるのは、リソース プロバイダーのみです。 リソース プロバイダー以外がホスト サーバー上に項目を作成すると、不一致状態になる可能性があります。

App Service

• ユーザーは、サブスクリプションで最初の Azure 関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。

• インフラストラクチャ (worker、管理、フロントエンド ロール) をスケールアウトするには、コンピューティングのリリース ノートの説明に従って PowerShell を使用する必要があります。

• 現在、App Service は、既定のプロバイダー サブスクリプションにのみデプロイできます。

使用方法

• パブリック IP アドレス使用量メーターのデータは、レコードが作成された日時を示す TimeDate スタンプではなく、各レコードに対して同じ EventDateTime 値を示します。 現在、このデータを使用して、パブリック IP アドレスの使用を正確に算出することはできません。

更新プログラムのダウンロード

Azure Stack 1807 更新プログラム パッケージは、here からダウンロードできます。

次のステップ

• Azure Stack統合システムのサービス ポリシーと、システムをサポートされている状態に保つために何を行う必要があるかを確認するには、「Azure Stack サービス ポリシーを参照してください。
• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。
• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。

1805 アーカイブされたリリース ノート

統合システムAzure Stack適用

この記事では、この 1805 更新プログラム パッケージで機能強化および修正された内容、このバージョンの既知の問題、および更新プログラムをダウンロードする場所について説明します。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1805 更新プログラムのビルド番号は 1.1805.1.47 です。

新機能

この更新プログラムには、Azure Stackの次の機能強化が含まれています。

• Azure Stack Syslog クライアントを preview 機能として含まれるようになりました。 このクライアントを使用すると、Azure Stack インフラストラクチャに関連する監査ログとセキュリティ ログを、Azure Stackの外部にある Syslog サーバーまたはセキュリティ情報およびイベント管理 (SIEM) ソフトウェアに転送できます。 現在、Syslog クライアントは、既定のポート 514 を介した認証されていない UDP 接続のみをサポートしています。 各 Syslog メッセージのペイロードは、共通イベント形式 (CEF) です。

  Syslog クライアントを構成するには、特権エンドポイントで公開されている Set-SyslogServer コマンドレットを使用します。

  このプレビューでは、次の 3 つのアラートが表示されることがあります。 Azure Stackによって表示される場合、これらのアラートには、descriptions と remediation ガイダンスが含まれます。

  • タイトル: コードの整合性のオフ
  • タイトル: 監査モードのコードの整合性
  • タイトル: ユーザー アカウントの作成

  この機能はプレビュー段階ですが、運用環境では使用しないでください。

修正された問題

• 管理ポータル内のドロップダウンから新しいサポート リクエストを開くことができない問題を修正しました。 このオプションは意図したとおりに機能するようになりました。

• パフォーマンス、安定性、セキュリティ、およびAzure Stackで使用されるオペレーティング システムに関するさまざまな修正。

開始する前に

前提条件

• Azure Stack 1805 更新プログラムを適用する前に、Azure Stack 1804 更新プログラムをインストールします。
• バージョン 1804 に対する最新の更新プログラムまたは修正プログラムをインストールします。
• 更新プログラム 1805 のインストールを開始する前に、Test-AzureStack を実行してAzure Stackの状態を検証し、見つかった操作上の問題を解決します。 また、アクティブなアラートを確認し、アクションが必要なアラートを解決します。

更新プロセスに関する既知の問題

• 1805 更新プログラムのインストール中に、"エラー - FaultType UserAccounts.New のテンプレートが見つかりません" というタイトルのアラートが表示される場合があります。これらのアラートは無視してかまいません。 1805 への更新が完了すると、これらのアラートは自動的に閉じられます。

• この更新プログラムのインストール中に仮想マシンを作成しようとしないでください。 更新プログラムの管理の詳細については、「Azure Stackの概要管理の更新を参照してください。

更新後の手順

1805 のインストール後、適用可能な修正プログラムがあればインストールします。 詳細については、以下のサポート技術情報とサービス ポリシーに関するページを参照してください。

• KB 4344102 - Azure Stack ホットフィックス 1.1805.7.57。

既知の問題 (インストール後)

このビルド バージョンのインストール後について次の既知の問題があります。

Portal

• Azure Stack技術ドキュメントでは、最新のリリースに焦点を当てています。 リリース間のポータルの変更により、Azure Stack ポータルの使用時に表示される内容は、ドキュメントに表示される内容とは異なる場合があります。

• アドオン プランとしてユーザー サブスクリプションに追加されたプランは、ユーザー サブスクリプションからプランを削除しても削除できません。 アドオン プランを参照するサブスクリプションも削除されるまで、プランは残ります。

• このバージョンのAzure Stackで OEM 拡張機能パッケージを使用してドライバーの更新プログラムを適用することはできません。 この問題の回避策はありません。

• 管理ポータルまたはユーザー ポータルでストレージ アカウントの [概要] を選択すると、[基本] ウィンドウの情報が表示されません。 [基本] ウィンドウには、リソース グループ、リージョン、サブスクリプション ID などのアカウントに関する情報が表示されます。 [概要] のその他のオプションにアクセスできます。たとえば、[サービス]、[監視]、[Explorer で開く]、[ストレージ アカウントの削除] のオプションです。

  使用できない情報を表示するには、Get-AzStorageAccount PowerShell コマンドレットを使用します。

• 管理ポータルまたはユーザー ポータルでストレージ アカウントに [タグ] を選択したときに、情報が読み込まれず、表示されません。

  使用できない情報を表示するには、Get-AzTag PowerShell コマンドレットを使用します。

• Azure Stack ID システムに AD FS を使用し、このバージョンのAzure Stackに更新すると、既定のプロバイダー サブスクリプションの既定の所有者は、組み込みの CloudAdmin ユーザーにリセットされます。
  回避策: この更新プログラムをインストールした後にこの問題を解決するには、Trigger オートメーションの手順 3 を使用して、既定のプロバイダー サブスクリプションの所有者をリセットするように Azure Stack プロシージャでクレーム プロバイダーの信頼を構成します。

• 一部の管理サブスクリプションの種類は利用できません。 Azure Stackこのバージョンにアップグレードすると、バージョン 1804 で導入された 2 つのサブスクリプションの種類がコンソールに表示されません。 これは "予期されること" です。 利用不可のサブスクリプションの種類は、Metering サブスクリプションと Consumption サブスクリプションです。 これらのサブスクリプションの種類は、バージョン 1804 以降の新しいAzure Stack環境で表示されますが、まだ使用できる状態ではありません。 既定のプロバイダー サブスクリプションの種類を引き続き使用する必要があります。

• 管理ポータルとユーザー ポータルの下部に水平スクロールバーが表示されない可能性があります。 水平スクロールバーにアクセスできない場合は、ポータルの左上にある階層リンク リストから表示するブレードの名前を選択して、階層リンクを使用してポータル内の前のブレードに移動します。

• 管理ポータルでコンピューティング リソースやストレージ リソースを表示できない場合があります。 この問題の原因は、更新プログラムのインストール中にエラーが発生し、更新が正常に行われたことが誤って報告されたためです。 この問題が発生した場合は、Microsoft カスタマー サポート サービスにお問い合わせください。

• ポータルに空のダッシュボードが表示されることがあります。 ダッシュボードを復元するには、ポータルの右上にある歯車アイコンを選択し、[既定の設定に戻す] を選択します。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

健康と監視

• 以下の詳細を持つ正常性コントローラーコンポーネントのアラートが表示されることがあります。

  アラート #1:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラー「ハートビートスキャナー」は利用できません。 これは、健康レポートと指標に影響する可能性があります。

  アラート #2:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラーの故障スキャナーは使用できません。 これは、健康レポートと指標に影響する可能性があります。

  アラート #1 と #2 は、どちらも無視しても問題ありません。時間が経過すると、自動的に閉じられます。

  容量に関する次のアラートも表示されることがあります。 このアラートでは、説明の中に示されている使用可能なメモリの割合が変化する可能性があります。

  アラート #3:

  • 名前: メモリ容量不足
  • 重大度: 緊急
  • コンポーネント: 容量
  • 説明: このリージョンは、使用可能なメモリの 80.00% を超えるメモリを消費しています。 大量のメモリを使用する仮想マシンを作成すると、エラーが発生する可能性があります。

  このバージョンのAzure Stackでは、このアラートが正しく発生しない可能性があります。 テナントの仮想マシンが引き続き正常にデプロイされる場合は、このアラートを無視しても問題はありません。

  アラート #3 は、自動的に閉じることはありません。 このアラートを閉じるとAzure Stack 15 分以内に同じアラートが作成されます。

• Azure Stackオペレーターとして、メモリ不足アラートが発生し、テナント仮想マシンが Fabric VM 作成エラーでデプロイに失敗した場合、Azure Stack スタンプが使用可能なメモリ不足になる可能性があります。 Azure Stack Capacity Planner を使用して、ワークロードで使用可能な容量を最適に把握します。

Compute

• 仮想マシンの展開用に仮想マシンのサイズを選択すると、VM を作成するときに F シリーズの VM のサイズがサイズ セレクターの一部として表示されません。 セレクターに F8s_v2、F16s_v2、F32s_v2、および F64s_v2 の VM サイズが表示されません。
  この問題を回避するには、次のいずれかの方法を使用して VM をデプロイします。 どの方法でも、使用する VM のサイズを指定する必要があります。

  • Azure Resource Manager template: テンプレートを使用する場合は、テンプレートの vmSize を使用する VM サイズと同じに設定します。 たとえば、F32s_v2 サイズを使用する VM をデプロイするには、次のように入力します。

        "properties": {
        "hardwareProfile": {
                "vmSize": "Standard_F32s_v2"
        },
    

  • Azure CLI:az vm create コマンドを使用し、--size "Standard_F32s_v2" と同様に、VM サイズをパラメーターとして指定できます。

  • PowerShell: PowerShell を使用すると、と同様に、VM サイズを指定するパラメーター を使用できます。

• 仮想マシン スケール セットのスケーリング設定は、ポータルで使用できません。 回避策として、Azure PowerShellを使用できます。 PowerShell のバージョンの違いにより、 パラメーターの代わりに を使用する必要があります。

• ポータルで [新規][コンピューティング][可用性セット] に移動して可用性セットを作成した場合、障害ドメインと更新ドメインが 1 の可用性セットのみを作成できます。 回避策として、新しい仮想マシンを作成する場合は、PowerShell、CLI、またはポータル内から可用性セットを作成します。

• Azure Stack ユーザー ポータルで仮想マシンを作成すると、DS シリーズ VM に接続できるデータ ディスクの数が誤って表示されます。 DS シリーズ VM は、Azure構成と同数のデータ ディスクに対応できます。

• VM イメージの作成に失敗した場合に、失敗したのに削除できない項目が、VM イメージのコンピューティング ブレードに追加される可能性があります。

  回避策として、Hyper-V (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB) で作成できるダミー VHD を使用して新しい VM イメージを作成します。 このプロセスによって、失敗した項目の削除を妨げている問題が修正されます。 その後、ダミーのイメージを作成してから 15 分経つと、正常に削除できます。

  次に、前に失敗した VM イメージの再ダウンロードを試行できます。

• VM の展開で拡張機能のプロビジョニングに時間がかかりすぎる場合、ユーザーは、プロセスを停止して VM の割り当て解除または削除を試みるのではなく、プロビジョニングをタイムアウトさせる必要があります。

• Linux VM 診断は、Azure Stackではサポートされていません。 VM 診断を有効にして Linux VM を展開すると、展開が失敗します。 診断設定で Linux VM の基本メトリックを有効にした場合も、展開が失敗します。

ネットワーク

• 管理ポータルまたはユーザー ポータルで、ユーザー定義のルートを作成できません。 回避策として、Azure PowerShellを使用します。

• [Networking の下で、vpn 接続を設定するために Create VPN Gateway をクリックすると、VPN の種類として Policy Based が表示されます。 このオプションを選択しないでください。 Azure Stackでは、Route Based オプションのみがサポートされます。

• VM を作成してパブリック IP アドレスに関連付けた後は、IP アドレスからその VM の関連付けを解除することはできません。 関連付けの解除は機能したように見えますが、以前に割り当てられたパブリック IP アドレスは、元の VM に関連付けられたままになります。

  現時点では、作成した新しい VM には新しいパブリック IP アドレスのみを使用する必要があります。

  この動作は、IP アドレスを新しい VM に 再割り当てした (一般に VIP スワップと呼ばれます) 場合でも行われます。 以降のこの IP アドレスによるすべての接続の試みは、新しい VM ではなく、元の VM に接続する結果になります。

• テナントのサブスクリプションに関連付けられているオファーとプランの一部であるネットワーク リソースのクォータ制限を引き上げた場合、新しい制限がそのサブスクリプションに適用されません。 ただし、クォータを増加した後に作成した新しいサブスクリプションには新しい制限が適用されます。

  この問題を回避するには、プランがサブスクリプションに既に関連付けられている場合は、アドオン プランを使用して、ネットワーク クォータを増やします。 詳細については、アドオン プランを利用できるようにする方法を参照してください。

• DNS ゾーン リソースまたはそれに関連付けられたルート テーブル リソースがあるサブスクリプションを削除することができません。 サブスクリプションを正常に削除するには、まずテナント サブスクリプションから DNS ゾーンとルート テーブルのリソースを削除する必要があります。

• Azure Stackでは、IP アドレスごとに 1 つのローカル ネットワーク ゲートウェイがサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• Automatic の DNS サーバー設定で作成されたVirtual Networkでは、カスタム DNS サーバーへの変更は失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• Azure Stackでは、VM のデプロイ後に VM インスタンスにネットワーク インターフェイスを追加することはできません。 VM に複数のネットワーク インターフェイスが必要な場合は、展開時に定義する必要があります。

• 管理ポータルを使用してネットワーク セキュリティ グループのルールを更新することはできません。

  App Service の回避策: コントローラー インスタンスへのリモート デスクトップ接続が必要な場合は、PowerShell を使用してネットワーク セキュリティ グループ内のセキュリティ規則を変更します。 "許可" する方法と、次にこの構成を復元して "拒否" する方法の例を次に示します。

  • [許可]:

    Connect-AzureRmAccount -EnvironmentName AzureStackAdmin
    
    $nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"
    
    $RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"
    
    ##This doesn't work. Need to set properties again even in case of edit
    
    #Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  
    
    Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
      -Name $RuleConfig_Inbound_Rdp_3389.Name `
      -Description "Inbound_Rdp_3389" `
      -Access Allow `
      -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
      -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
      -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
      -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
      -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
      -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
      -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange
    
    # Commit the changes back to NSG
    Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg
    

  • 拒否:

    
    Connect-AzureRmAccount -EnvironmentName AzureStackAdmin
    
    $nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"
    
    $RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"
    
    ##This doesn't work. Need to set properties again even in case of edit
    
    #Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  
    
    Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
      -Name $RuleConfig_Inbound_Rdp_3389.Name `
      -Description "Inbound_Rdp_3389" `
      -Access Deny `
      -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
      -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
      -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
      -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
      -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
      -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
      -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange
    
    # Commit the changes back to NSG
    Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg
    

SQL および MySQL

• SQL または MySQL をホストするサーバー上に項目を作成できるのは、リソース プロバイダーのみです。 リソース プロバイダー以外がホスト サーバー上に項目を作成すると、不一致状態になる可能性があります。

• SQL と MySQL リソース プロバイダーの SKU を作成する場合、[ファミリ] または [層] 名では、スペースやピリオドなどの特殊文字はサポートされていません。

App Service

• ユーザーは、サブスクリプションで最初の Azure 関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。

• インフラストラクチャ (worker、管理、フロントエンド ロール) をスケールアウトするには、コンピューティングのリリース ノートの説明に従って PowerShell を使用する必要があります。

• 現在、App Service は、既定のプロバイダー サブスクリプションにのみデプロイできます。

使用方法

• パブリック IP アドレス使用量メーターのデータは、レコードが作成された日時を示す TimeDate スタンプではなく、各レコードに対して同じ EventDateTime 値を示します。 現在、このデータを使用して、パブリック IP アドレスの使用を正確に算出することはできません。

更新プログラムのダウンロード

Azure Stack 1805 更新プログラム パッケージは、here からダウンロードできます。

関連項目

• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。
• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。

1804 アーカイブされたリリース ノート

統合システムAzure Stack適用

この記事では、この 1804 更新プログラム パッケージで機能強化および修正された内容、このリリースの既知の問題、および更新プログラムをダウンロードする場所について説明します。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1804 更新プログラムのビルド番号は 20180513.1 です。

新機能

この更新プログラムには、Azure Stackの次の機能強化が含まれています。

• Visual Studio AD FS を使用した切断されたAzure Stack展開のサポート。 Visual Studio内で、サブスクリプションを追加し、AD FS フェデレーション ユーザー資格情報を使用して認証できるようになりました。

• Av2 シリーズと F シリーズの仮想マシンを使用。 Azure Stack Av2 シリーズと F シリーズの仮想マシンのサイズに基づいて仮想マシンを使用できるようになりました。 詳細については、 Azure Stackを参照してください。

• 新しい管理サブスクリプション。 1804 では、ポータルで新しいサブスクリプションの種類 2 つを利用できるようになりました。 これらの新しいサブスクリプションの種類は、既定のプロバイダー サブスクリプションに加えて、バージョン 1804 以降の新しいAzure Stackインストールで表示されます。 このバージョンの Azure Stack でこれらの新しいサブスクリプションの種類を使用しないでください。 今後の更新プログラムでこれらのサブスクリプションの種類を使用できるようになった場合はお知らせします。

  Azure Stackをバージョン 1804 に更新した場合、2 つの新しいサブスクリプションの種類は表示されません。 ただし、Azure Stack Development Kit バージョン 1804 以降のAzure Stack統合システムとインストールの新しいデプロイでは、3 つのサブスクリプションの種類すべてにアクセスできます。

  これらの新しい種類のサブスクリプションは、Default Provider サブスクリプションを保護し、SQL Hosting サーバーなど、共有リソースのデプロイを簡易化するための大規模な変更の一環です。 今後のAzure Stackの更新により、この大きな変更の一部が追加されると、これらの新しいサブスクリプションの種類の下にデプロイされたリソースが失われる可能性があります。

  現在表示されている 3 種類のサブスクリプションは次のとおりです。

  • Default Provider サブスクリプション: 引き続き、この種類のサブスクリプションを使用してください。
  • Metering サブスクリプション: この種類のサブスクリプションは使用しないでください。
  • Consumption サブスクリプション: この種類のサブスクリプションは使用しないでください。

修正された問題

• 管理ポータルで、情報を表示する前に [更新] タイルを更新する必要がなくなりました。

• これで、管理ポータルを使用して、BLOB サービス、Table service、Queue サービスのストレージ メトリックを編集できるようになりました。

• Networkingで、[Connection をクリックして VPN 接続を設定すると、サイト間 (IPsec) のみが使用可能なオプションになりました。

• パフォーマンス、安定性、セキュリティ、およびAzure Stackで使用されるオペレーティング システムに関するさまざまな修正。

この更新に合わせた追加のリリース

以下を使用できるようになりましたが、Azure Stack更新プログラム 1804 は必要ありません。

• Microsoft Azure Stack System Center Operations Manager Monitoring Packに更新します。 Azure Stack用 Microsoft System Center Operations Manager 監視パックの新しいバージョン (1.0.3.0) が、download で使用できます。 このバージョンでは、接続Azure Stack展開を追加するときにサービス プリンシパルを使用できます。 このバージョンには、Operations Manager内から直接修復アクションを実行できる Update Management エクスペリエンスも備えています。 リソース プロバイダー、スケール単位、スケール ユニットのノードを表示する新しいダッシュボードもあります。

• New Azure Stack Admin PowerShell バージョン 1.3.0。 Azure Stack PowerShell 1.3.0 をインストールできるようになりました。 このバージョンでは、すべての管理リソース プロバイダーがAzure Stackを管理するためのコマンドが提供されます。 このリリースでは、一部のコンテンツは Azure Stack Tools GitHub repository から非推奨になります。

  インストールの詳細については、モジュール 1.3.0 の instructions または help Azure Stack コンテンツに従ってください。

• AZURE STACK API Rest Reference の初期化リリース。 すべてのAzure Stack管理リソース プロバイダーの API リファレンスが公開されました。

開始する前に

前提条件

• Azure Stack 1804 更新プログラムを適用する前に、Azure Stack 1803 更新プログラムをインストールします。

• 最新の入手できるバージョン 1803 の更新プログラムまたは修正プログラムをインストールします。

更新プロセスに関する既知の問題

• 1804 更新プログラムのインストール中に、"エラー - FaultType UserAccounts.New のテンプレートが見つかりません" というタイトルのアラートが表示される場合があります。これらのアラートは無視してかまいません。 1804 への更新が完了すると、これらのアラートは自動的に閉じられます。

• この更新プログラムのインストール中に仮想マシンを作成しようとしないでください。 更新プログラムの管理の詳細については、「Azure Stackの概要管理の更新を参照してください。

更新後の手順

1804 のインストール後、適用可能な修正プログラムがあればインストールします。 詳細については、以下のサポート技術情報とサービス ポリシーに関するページを参照してください。

• KB 4344114 - Azure Stack 修正プログラム 1.0.180527.15。

既知の問題 (インストール後)

ビルド 20180513.1 のインストール後について次の既知の問題があります。

Portal

• Azure Stack技術ドキュメントでは、最新のリリースに焦点を当てています。 リリース間のポータルの変更により、Azure Stack ポータルの使用時に表示される内容は、ドキュメントに表示される内容とは異なる場合があります。

• このバージョンのAzure Stackで OEM 拡張機能パッケージを使用してドライバーの更新プログラムを適用することはできません。 この問題の回避策はありません。

• このバージョンのAzure Stackをインストールまたは更新すると、管理ポータルでスケール ユニットAzure Stack表示できなくなる場合があります。
  回避策: PowerShell を使用し、スケール ユニットに関する情報を表示します。 詳細については、Azure Stack モジュール 1.3.0 の help コンテンツを参照してください。

• Azure Stack ID システムに AD FS を使用し、このバージョンのAzure Stackに更新すると、既定のプロバイダー サブスクリプションの既定の所有者は、組み込みの CloudAdmin ユーザーにリセットされます。
  回避策: この更新プログラムをインストールした後にこの問題を解決するには、Trigger オートメーションの手順 3 を使用して、既定のプロバイダー サブスクリプションの所有者をリセットするように Azure Stack プロシージャでクレーム プロバイダーの信頼を構成します。

• 一部の管理サブスクリプションの種類は利用できません。 Azure Stackをこのバージョンにアップグレードすると、バージョン 1804 ではコンソールに表示されません。 これは "予期されること" です。 利用不可のサブスクリプションの種類は、Metering サブスクリプションと Consumption サブスクリプションです。 これらのサブスクリプションの種類は、バージョン 1804 以降の新しいAzure Stack環境で表示されますが、まだ使用できる状態ではありません。 既定のプロバイダー サブスクリプションの種類を引き続き使用する必要があります。

• 管理者ポータルのドロップダウン リストから新しいサポート要求を開く機能は使用できません。 代わりに、次のリンクを使用してください。
  • 統合システムAzure Stack場合は、https://aka.ms/newsupportrequest を使用します。

• 管理ポータルとユーザー ポータルの下部に水平スクロールバーが表示されない可能性があります。 水平スクロールバーにアクセスできない場合は、ポータルの左上にある階層リンク リストから表示するブレードの名前を選択して、階層リンクを使用してポータル内の前のブレードに移動します。

• 管理ポータルでコンピューティング リソースやストレージ リソースを表示できない場合があります。 この問題の原因は、更新プログラムのインストール中にエラーが発生し、更新が正常に行われたことが誤って報告されたためです。 この問題が発生した場合は、Microsoft カスタマー サポート サービスにお問い合わせください。

• ポータルに空のダッシュボードが表示されることがあります。 ダッシュボードを復元するには、ポータルの右上にある歯車アイコンを選択し、[既定の設定に戻す] を選択します。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

• 管理ポータルに、Microsoft.Update.Admin コンポーネントに関する重大なアラートが表示される場合があります。 アラート名、説明、解決策が、次のようにすべて表示されます。

  • エラー - FaultType ResourceProviderTimeout 用のテンプレートが見つかりません。

  このアラートは無視してかまいません。

健康と監視

• 以下の詳細を持つ正常性コントローラーコンポーネントのアラートが表示されることがあります。

  アラート #1:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラー「ハートビートスキャナー」は利用できません。 これは、健康レポートと指標に影響する可能性があります。

  アラート #2:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラーの故障スキャナーは使用できません。 これは、健康レポートと指標に影響する可能性があります。

  いずれのアラートも無視してかまいません。 時間が経つと自動的に閉じられます。

Compute

• 仮想マシンの展開用に仮想マシンのサイズを選択すると、VM を作成するときに F シリーズの VM のサイズがサイズ セレクターの一部として表示されません。 セレクターに F8s_v2、F16s_v2、F32s_v2、および F64s_v2 の VM サイズが表示されません。
  この問題を回避するには、次のいずれかの方法を使用して VM をデプロイします。 どの方法でも、使用する VM のサイズを指定する必要があります。

  • Azure Resource Manager template: テンプレートを使用する場合は、テンプレートの vmSize を目的の VM サイズに設定します。 たとえば、F32s_v2 サイズを使用する VM をデプロイするには、次を使用します。

        "properties": {
        "hardwareProfile": {
                "vmSize": "Standard_F32s_v2"
        },
    

  • Azure CLI:az vm create コマンドを使用し、--size "Standard_F32s_v2" と同様に、VM サイズをパラメーターとして指定できます。

  • PowerShell: PowerShell を使用すると、と同様に、VM サイズを指定するパラメーター を使用できます。

• 仮想マシン スケール セットのスケーリング設定は、ポータルで使用できません。 回避策として、Azure PowerShellを使用できます。 PowerShell のバージョンの違いにより、 パラメーターの代わりに を使用する必要があります。

• ポータルで [新規][コンピューティング][可用性セット] に移動して可用性セットを作成した場合、障害ドメインと更新ドメインが 1 の可用性セットのみを作成できます。 回避策として、新しい仮想マシンを作成する場合は、PowerShell、CLI、またはポータル内から可用性セットを作成します。

• Azure Stack ユーザー ポータルで仮想マシンを作成すると、D シリーズ VM に接続できるデータ ディスクの数が誤って表示されます。 サポートされているすべての D シリーズ VM は、Azure構成と同数のデータ ディスクに対応できます。

• VM イメージの作成に失敗した場合に、失敗したのに削除できない項目が、VM イメージのコンピューティング ブレードに追加される可能性があります。

  回避策として、Hyper-V (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB) で作成できるダミー VHD を使用して新しい VM イメージを作成します。 このプロセスによって、失敗した項目の削除を妨げている問題が修正されます。 その後、ダミーのイメージを作成してから 15 分経つと、正常に削除できます。

  次に、前に失敗した VM イメージの再ダウンロードを試行できます。

• VM の展開で拡張機能のプロビジョニングに時間がかかりすぎる場合、ユーザーは、プロセスを停止して VM の割り当て解除または削除を試みるのではなく、プロビジョニングをタイムアウトさせる必要があります。

• Linux VM 診断は、Azure Stackではサポートされていません。 VM 診断を有効にして Linux VM を展開すると、展開が失敗します。 診断設定で Linux VM の基本メトリックを有効にした場合も、展開が失敗します。

ネットワーク

• [Networking の下で、vpn 接続を設定するために Create VPN Gateway をクリックすると、VPN の種類として Policy Based が表示されます。 このオプションを選択しないでください。 Azure Stackでは、Route Based オプションのみがサポートされます。

• VM を作成してパブリック IP アドレスに関連付けた後は、IP アドレスからその VM の関連付けを解除することはできません。 関連付けの解除は機能したように見えますが、以前に割り当てられたパブリック IP アドレスは、元の VM に関連付けられたままになります。

  現時点では、作成した新しい VM には新しいパブリック IP アドレスのみを使用する必要があります。

  この動作は、IP アドレスを新しい VM に 再割り当てした (一般に VIP スワップと呼ばれます) 場合でも行われます。 以降のこの IP アドレスによるすべての接続の試みは、新しい VM ではなく、元々関連付けられていた VM に接続する結果になります。

• テナントのサブスクリプションに関連付けられているオファーとプランの一部であるネットワーク リソースのクォータ制限を引き上げた場合、新しい制限がそのサブスクリプションに適用されません。 ただし、クォータを増加した後に作成した新しいサブスクリプションには新しい制限が適用されます。

  この問題を回避するには、プランがサブスクリプションに既に関連付けられている場合は、アドオン プランを使用して、ネットワーク クォータを増やします。 詳細については、アドオン プランを利用できるようにする方法を参照してください。

• DNS ゾーン リソースまたはそれに関連付けられたルート テーブル リソースがあるサブスクリプションを削除することができません。 サブスクリプションを正常に削除するには、まずテナント サブスクリプションから DNS ゾーンとルート テーブルのリソースを削除する必要があります。

• Azure Stackでは、IP アドレスごとに 1 つのローカル ネットワーク ゲートウェイがサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• Automatic の DNS サーバー設定で作成されたVirtual Networkでは、カスタム DNS サーバーへの変更は失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• Azure Stackでは、VM のデプロイ後に VM インスタンスにネットワーク インターフェイスを追加することはできません。 VM に複数のネットワーク インターフェイスが必要な場合は、展開時に定義する必要があります。

• 管理ポータルを使用してネットワーク セキュリティ グループのルールを更新することはできません。

  App Service の回避策: コントローラー インスタンスへのリモート デスクトップ接続が必要な場合は、PowerShell を使用してネットワーク セキュリティ グループ内のセキュリティ規則を変更します。 "許可" する方法と、次にこの構成を復元して "拒否" する方法の例を次に示します。

  • [許可]:

    Connect-AzureRmAccount -EnvironmentName AzureStackAdmin
    
    $nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"
    
    $RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"
    
    ##This doesn't work. Need to set properties again even in case of edit
    
    #Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  
    
    Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
      -Name $RuleConfig_Inbound_Rdp_3389.Name `
      -Description "Inbound_Rdp_3389" `
      -Access Allow `
      -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
      -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
      -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
      -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
      -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
      -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
      -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange
    
    # Commit the changes back to NSG
    Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg
    

  • 拒否:

    
    Connect-AzureRmAccount -EnvironmentName AzureStackAdmin
    
    $nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"
    
    $RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"
    
    ##This doesn't work. Need to set properties again even in case of edit
    
    #Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  
    
    Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
      -Name $RuleConfig_Inbound_Rdp_3389.Name `
      -Description "Inbound_Rdp_3389" `
      -Access Deny `
      -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
      -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
      -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
      -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
      -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
      -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
      -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange
    
    # Commit the changes back to NSG
    Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg 
    

SQL および MySQL

• SQL または MySQL をホストするサーバー上に項目を作成できるのは、リソース プロバイダーのみです。 リソース プロバイダー以外がホスト サーバー上に項目を作成すると、不一致状態になる可能性があります。

• SQL と MySQL リソース プロバイダーの SKU を作成する場合、[ファミリ] または [層] 名では、スペースやピリオドなどの特殊文字はサポートされていません。

App Service

• ユーザーは、サブスクリプションで最初の Azure 関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。

• インフラストラクチャ (worker、管理、フロントエンド ロール) をスケールアウトするには、コンピューティングのリリース ノートの説明に従って PowerShell を使用する必要があります。

• 現在、App Service は、既定のプロバイダー サブスクリプションにのみデプロイできます。 今後の更新では、App Service は Azure Stack 1804 で導入された新しい測定サブスクリプションにデプロイされ、既存のすべてのデプロイもこの新しいサブスクリプションに移行されます。

使用方法

• パブリック IP アドレス使用量メーターのデータは、レコードが作成された日時を示す TimeDate スタンプではなく、各レコードに対して同じ EventDateTime 値を示します。 現在、このデータを使用して、パブリック IP アドレスの使用を正確に算出することはできません。

更新プログラムのダウンロード

Azure Stack 1804 更新プログラム パッケージは、here からダウンロードできます。

関連項目

• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。
• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。

1803 アーカイブされたリリース ノート

統合システムAzure Stack適用

この記事では、この 1803 更新プログラム パッケージで機能強化および修正された内容、このリリースの既知の問題、および更新プログラムをダウンロードする場所について説明します。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1803 更新プログラムのビルド番号は 20180329.1 です。

開始する前に

前提条件

• Azure Stack 1803 更新プログラムを適用する前に、Azure Stack 1802 更新プログラムをインストールします。

• Azure Stack 1803 更新プログラムを適用する前に、AzS 修正プログラム 1.0.180312.1- ビルド 20180222.2 をインストールします。 この修正プログラムは Defender Windows更新プログラムであり、Azure Stackの更新プログラムをダウンロードするときに使用できます。

  修正プログラムをインストールするには、Azure Stackの更新プログラムをインストールします。 更新プログラムの名前は AzS 修正プログラム - 1.0.180312.1 と表示され、次のファイルが含まれています。

  • PUPackageHotFix_20180222.2-1.exe
  • PUPackageHotFix_20180222.2-1.bin
  • Metadata.xml

  これらのファイルをストレージ アカウントとコンテナーにアップロードした後に、管理ポータルの [更新] タイルからインストールを実行します。

  Azure Stackの更新プログラムとは異なり、この更新プログラムをインストールしても、Azure Stackのバージョンは変更されません。 この更新プログラムがインストールされているかどうかは、[インストール済み更新プログラム] の一覧を確認します。

新機能

この更新プログラムには、Azure Stackの次の機能強化と修正が含まれています。

• Azure Stack シークレットの更新 - (アカウントと証明書)。 シークレットの管理の詳細については、「rotate secrets in Azure Stack」を参照してください。

• HTTP を使用して管理者ポータルとユーザー ポータルにアクセスする場合の、HTTPS への自動ダイレクト。 この改善は、Azure Stackの UserVoice フィードバックに基づいて行われました。

• Marketplace にアクセス - Azure ポータルと同じように、管理者ポータルとユーザー ポータル内から + 新規 オプションを使用して、Azure Stack Marketplace を開くようになりました。

• Azure Monitor - Azure Stackは、Azure Monitorを管理者ポータルとユーザー ポータルに追加します。 これには、メトリックおよびアクティビティ ログ用の新しいエクスプローラーが含まれます。 外部ネットワークからこのAzure Monitorにアクセスするには、ポート 13012 をファイアウォール構成で開く必要があります。 Azure Stackに必要なポートの詳細については、「Azure Stack データセンター統合 - エンドポイントの発行」を参照してください。

  この変更の一環として、[More services]\(その他のサービス\) 下では、[監査ログ] が [アクティビティ ログ] と表示されるようになります。 この機能は、Azure ポータルと一致するようになりました。

• Sparse ファイル - Azure Stackに新しいイメージを追加するか、マーケットプレース シンジケーションを使用してイメージを追加すると、イメージはスパース ファイルに変換されます。 バージョン 1803 Azure Stack使用する前に追加されたイメージは変換できません。 この機能を利用するには、代わりにマーケットプレース シンジケーションを使用して、それらのイメージを再送信する必要があります。

  スパース ファイルは、記憶域スペースの使用を減らして I/O を改善するために使用される、効率的なファイル形式です。 ?詳細については、Windows ServerFsutil sparse を参照してください。

修正された問題

• 内部負荷分散 (ILB) がバックエンド VM の MAC アドレスを適切に処理するようになりました。これにより、ILB はバックエンド ネットワーク上の Linux インスタンスを使用するときに、バックエンド ネットワークにパケットをドロップします。 ILB は、バックエンド ネットワーク上のWindows インスタンスで正常に動作します。

• IKE ポリシーの設定がAzureとは異なるAzure Stackが原因で、Azure Stack間の VPN 接続が切断される問題。 SALifetime (Time) と SALiftetime (Bytes) の値はAzureと互換性がないため、1803 年にAzureの設定と一致するように変更されました。 1803 より前の SALifetime (秒) の値は 14,400 でしたが、1803 では 27,000 に変更されました。 1803 より前の SALifetime (バイト) の値は 819,200 でしたが、1803 では 33,553,408 に変更されました。

• 以前に VPN 接続がポータルに表示されていた IP の問題。ただし、IP 転送を有効または切り替える効果はありません。 この機能は既定で有効でになりますが、これを変更する機能はまだサポートされていません。 コントロールはポータルから削除されました。

• Azure Stackは、ポータルにオプションが表示されている場合でも、ポリシー ベースの VPN ゲートウェイをサポートしていません。 オプションはポータルから削除されました。

• Azure Stackでは、ダイナミック ディスクを使用して作成された仮想マシンのサイズ変更が禁止されるようになりました。

• 仮想マシンの使用状況データが 1 時間ごとに分離されるようになりました。 これはAzureと一致します。

• 管理者ポータルとユーザー ポータルで、vNet サブネットの [設定] ブレードの読み込みに失敗する問題。 回避策として、PowerShell と Get-AzVirtualNetworkSubnetConfig コマンドレットを使用して、この情報を表示および管理します。

• 仮想マシンを作成する際、VM サイズ用のサイズを選択したときのメッセージ "価格を表示できません" は表示されなくなりました。

• Azure Stackによって使用されるパフォーマンス、安定性、セキュリティ、オペレーティング システムに関するさまざまな修正。

変更点

• 新しく作成されたオファーの状態を [プライベート] から [パブリック] または [使用停止] に切り替える方法が変更されました。 詳細については、オファ―の作成に関するページをご覧ください。

更新プロセスに関する既知の問題

1803 更新プログラムのインストール中に、BLOB サービスと BLOB サービスを使用する内部サービスのダウンタイムが発生する可能性があります。 これには、一部の仮想マシンの操作が含まれます。 このダウン タイムにより、テナントの操作が失敗したり、データにアクセスできないサービスからのアラートが表示されたりする可能性があります。 この問題は、更新プログラムのインストールの完了時に自動的に解決します。

更新後の手順

• 1803 のインストール後、適用可能な修正プログラムがあればインストールします。 詳細については、以下のサポート技術情報とサービス ポリシーに関するページを参照してください。

  • KB 4344115 - Azure Stack ホットフィックス 1.0.180427.15。

• この更新プログラムをインストールしたら、ファイアウォールの設定で必要なポートが開いていることを確認します。 たとえば、この更新プログラムでは、アクティビティ ログへの監査ログの変更を含む Azure Monitor が導入されています。 この変更によりポート 13012 が使用されるようになったため、開いている必要があります。

既知の問題 (インストール後)

ビルド 20180323.2 のインストール後について次の既知の問題があります。

Portal

• Azure Stack ID システムに AD FS を使用し、このバージョンのAzure Stackに更新すると、既定のプロバイダー サブスクリプションの既定の所有者は、組み込みの CloudAdmin ユーザーにリセットされます。
  回避策: この更新プログラムをインストールした後にこの問題を解決するには、Trigger オートメーションの手順 3 を使用して、既定のプロバイダー サブスクリプションの所有者をリセットするように Azure Stack プロシージャでクレーム プロバイダーの信頼を構成します。

• 管理者ポータルのドロップダウン リストから新しいサポート要求を開く機能は使用できません。 代わりに、次のリンクを使用します。

  • 統合システムAzure Stack場合は、https://aka.ms/newsupportrequest を使用します。

• 管理ポータルでは、BLOB サービス、Table service、または Queue サービスのストレージ メトリックを編集することはできません。 [ストレージ] に移動し、Blob、Table、または Queue サービスのタイルを選択すると、新しいブレードが開き、そのサービスのメトリック グラフが表示されます。 メトリック グラフ タイルの上部にある [編集] を選択すると、[グラフの編集] ブレードが開きますが、メトリックを編集するオプションは表示されません。

• 管理ポータルでコンピューティング リソースやストレージ リソースを表示できない場合があります。 この問題の原因は、更新プログラムのインストール中にエラーが発生し、更新が正常に行われたことが誤って報告されたためです。 この問題が発生した場合は、Microsoft カスタマー サポート サービスにお問い合わせください。

• ポータルに空のダッシュボードが表示されることがあります。 ダッシュボードを復元するには、ポータルの右上にある歯車アイコンを選択し、[既定の設定に戻す] を選択します。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

• 管理ポータルのダッシュボードの [更新] タイルで、更新プログラムに関する情報を表示できません。 この問題を解決するには、そのタイルをクリックして更新してください。

• 管理ポータルに、Microsoft.Update.Admin コンポーネントに関する重大なアラートが表示される場合があります。 アラート名、説明、解決策が、次のようにすべて表示されます。

  • エラー - FaultType ResourceProviderTimeout 用のテンプレートが見つかりません。

  このアラートは無視してかまいません。

健康と監視

• 以下の詳細を持つ正常性コントローラーコンポーネントのアラートが表示されることがあります。

  アラート #1:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラー「ハートビートスキャナー」は利用できません。 これは、健康レポートと指標に影響する可能性があります。

  アラート #2:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラーの故障スキャナーは使用できません。 これは、健康レポートと指標に影響する可能性があります。

  いずれのアラートも無視してかまいません。 時間が経つと自動的に閉じられます。

Marketplace

• ユーザーはサブスクリプションなしですべてのマーケットプレースを参照し、プランやオファーなどの管理アイテムを表示できます。 ユーザーはこれらのアイテムを使用できません。

Compute

• 仮想マシン スケール セットのスケーリング設定は、ポータルで使用できません。 回避策として、Azure PowerShellを使用できます。 PowerShell のバージョンの違いにより、 パラメーターの代わりに を使用する必要があります。

• ポータルで [新規][コンピューティング][可用性セット] に移動して可用性セットを作成した場合、障害ドメインと更新ドメインが 1 の可用性セットのみを作成できます。 回避策として、新しい仮想マシンを作成する場合は、PowerShell、CLI、またはポータル内から可用性セットを作成します。

• Azure Stack ユーザー ポータルで仮想マシンを作成すると、D シリーズ VM に接続できるデータ ディスクの数が誤って表示されます。 サポートされているすべての D シリーズ VM は、Azure構成と同数のデータ ディスクに対応できます。

• VM イメージの作成に失敗した場合に、失敗したのに削除できない項目が、VM イメージのコンピューティング ブレードに追加される可能性があります。

  回避策として、Hyper-V (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB) で作成できるダミー VHD を使用して新しい VM イメージを作成します。 このプロセスによって、失敗した項目の削除を妨げている問題が修正されます。 その後、ダミーのイメージを作成してから 15 分経つと、正常に削除できます。

  次に、前に失敗した VM イメージの再ダウンロードを試行できます。

• VM の展開で拡張機能のプロビジョニングに時間がかかりすぎる場合、ユーザーは、プロセスを停止して VM の割り当て解除または削除を試みるのではなく、プロビジョニングをタイムアウトさせる必要があります。

• Linux VM 診断は、Azure Stackではサポートされていません。 VM 診断を有効にして Linux VM を展開すると、展開が失敗します。 診断設定で Linux VM の基本メトリックを有効にした場合も、展開が失敗します。

ネットワーク

• VM を作成してパブリック IP アドレスに関連付けた後は、IP アドレスからその VM の関連付けを解除することはできません。 関連付けの解除は機能したように見えますが、以前に割り当てられたパブリック IP アドレスは、元の VM に関連付けられたままになります。

  現時点では、作成した新しい VM には新しいパブリック IP アドレスのみを使用する必要があります。

  この動作は、IP アドレスを新しい VM に 再割り当てした (一般に VIP スワップと呼ばれます) 場合でも行われます。 以降のこの IP アドレスによるすべての接続の試みは、新しい VM ではなく、元々関連付けられていた VM に接続する結果になります。

• Azure Stackでは、IP アドレスごとに 1 つのローカル ネットワーク ゲートウェイがサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• Automatic の DNS サーバー設定で作成されたVirtual Networkでは、カスタム DNS サーバーへの変更は失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• Azure Stackでは、VM のデプロイ後に VM インスタンスにネットワーク インターフェイスを追加することはできません。 VM に複数のネットワーク インターフェイスが必要な場合は、展開時に定義する必要があります。

• 管理ポータルを使用してネットワーク セキュリティ グループのルールを更新することはできません。

  App Service の回避策: コントローラー インスタンスへのリモート デスクトップ接続が必要な場合は、PowerShell を使用してネットワーク セキュリティ グループ内のセキュリティ規則を変更します。 "許可" する方法と、次にこの構成を復元して "拒否" する方法の例を次に示します。

  • [許可]:

    Add-AzureRmAccount -EnvironmentName AzureStackAdmin
    
    $nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"
    
    $RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"
    
    ##This doesn't work. Need to set properties again even in case of edit
    
    #Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  
    
    Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
      -Name $RuleConfig_Inbound_Rdp_3389.Name `
      -Description "Inbound_Rdp_3389" `
      -Access Allow `
      -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
      -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
      -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
      -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
      -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
      -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
      -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange
    
    # Commit the changes back to NSG
    Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg
    

  • 拒否:

    
    Add-AzureRmAccount -EnvironmentName AzureStackAdmin
    
    $nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"
    
    $RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"
    
    ##This doesn't work. Need to set properties again even in case of edit
    
    #Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  
    
    Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
      -Name $RuleConfig_Inbound_Rdp_3389.Name `
      -Description "Inbound_Rdp_3389" `
      -Access Deny `
      -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
      -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
      -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
      -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
      -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
      -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
      -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange
    
    # Commit the changes back to NSG
    Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg 
    

SQL および MySQL

• 続行する前に、これらのリリース ノートの冒頭にある「開始する前に」の重要な注意事項を確認します。

• ユーザーがデータベースを新しい SQL または MySQL の展開で作成するまでに、最大で 1 時間かかる場合があります。

• SQL または MySQL をホストするサーバー上に項目を作成できるのは、リソース プロバイダーのみです。 リソース プロバイダー以外がホスト サーバー上に項目を作成すると、不一致状態になる可能性があります。

• SQL と MySQL リソース プロバイダーの SKU を作成する場合、[ファミリ] 名では、スペースやピリオドなどの特殊文字はサポートされていません。

App Service

• ユーザーは、サブスクリプションで最初の Azure 関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。

• インフラストラクチャ (worker、管理、フロントエンド ロール) をスケールアウトするには、コンピューティングのリリース ノートの説明に従って PowerShell を使用する必要があります。

使用方法

• パブリック IP アドレス使用量メーターのデータは、レコードが作成された日時を示す TimeDate スタンプではなく、各レコードに対して同じ EventDateTime 値を示します。 現在、このデータを使用して、パブリック IP アドレスの使用を正確に算出することはできません。

GitHubから Azure Stack ツールをダウンロードする

• invoke-webrequest PowerShell コマンドレットを使用してGitHubからAzure Stack ツールをダウンロードすると、エラーが表示されます。

  • "invoke-webrequest : 要求は中止されました: SSL/TLS のセキュリティで保護されたチャネルを作成できませんでした。"

  このエラーは、Tlsv1 および Tlsv1.1 暗号化標準 (PowerShell の既定値) の最近のGitHubサポートの廃止が原因で発生します。 詳細については、脆弱な暗号化標準の削除の通知に関するページを参照してください。

  この問題を解決するには、スクリプトの先頭に [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 を追加して、GitHub リポジトリからダウンロードするときに PowerShell コンソールで TLSv1.2 を使用するように強制します。

更新プログラムのダウンロード

Azure Stack 1803 更新プログラム パッケージは、here からダウンロードできます。

関連項目

• Privileged End Point (PEP) を使用して更新プログラムを監視および再開するには、「Monitor updates in Azure Stack using the privileged endpointを参照してください。
• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。

1802 アーカイブされたリリース ノート

統合システムAzure Stack適用

この記事では、この 1802 更新プログラム パッケージで機能強化および修正された内容、このリリースの既知の問題、および更新プログラムをダウンロードする場所について説明します。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

Azure Stack 1802 更新プログラムのビルド番号は 20180302.1 です。

開始する前に

前提条件

• Azure Stack 1802 更新プログラムを適用する前に、Azure Stack 1712 更新プログラムをインストールします。

• Azure Stack 1802 更新プログラムを適用する前に、AzS 修正プログラム 1.0.180312.1 - ビルド 20180222.2 をインストールします。 この修正プログラムは Defender Windows更新プログラムであり、Azure Stackの更新プログラムをダウンロードするときに使用できます。

  修正プログラムをインストールするには、Azure Stackの更新プログラムをインストールします。 更新プログラムの名前は AzS 修正プログラム - 1.0.180312.1 と表示され、次のファイルが含まれています。

  • PUPackageHotFix_20180222.2-1.exe
  • PUPackageHotFix_20180222.2-1.bin
  • Metadata.xml

  これらのファイルをストレージ アカウントとコンテナーにアップロードした後に、管理ポータルの [更新] タイルからインストールを実行します。

  Azure Stackの更新プログラムとは異なり、この更新プログラムをインストールしても、Azure Stackのバージョンは変更されません。 この更新プログラムがインストールされているかどうかは、[インストール済み更新プログラム] の一覧を確認します。

更新後の手順

1802 のインストール後、適用可能な修正プログラムがあればインストールします。 詳細については、以下のサポート技術情報とサービス ポリシーに関するページを参照してください。

• Azure Stack修正プログラム 1.0.180302.4。 KB 4131152 - 既存のVirtual Machine Scale Setsが使用できなくなる可能性があります

  この修正プログラムは、「KB 4103348 - Azure Stack更新プログラムをインストールしようとするとネットワーク コントローラー API サービスがクラッシュするで詳しく説明されている問題も解決します。

新機能と修正

この更新プログラムには、Azure Stackの次の機能強化と修正が含まれています。

• Support は、次のAzure Storage Service API バージョンに追加されます。

  • 2017-04-17
  • 2016-05-31
  • 2015-12-11
  • 2015-07-08

  詳細については、「Azure Stack Storage: 相違点と考慮事項を参照してください。

• より大容量のBlock Blobsのサポート:

  • 最大許容ブロック サイズは 4 MB から 100 MB に増加しました。
  • 最大 BLOB サイズは 195 GB から 4.75 TB に増加しました。

• インフラストラクチャのバックアップが [リソース プロバイダー] タイルに表示され、バックアップのアラートが有効になりました。 インフラストラクチャ バックアップ サービスの詳細については、「インフラストラクチャ バックアップ サービスを使用したAzure Stackのバックアップとデータ復旧を参照してください。

• Test-AzureStack コマンドレットの更新。ストレージの診断を改善します。 このコマンドレットの詳細については、「Validation for Azure Stack」を参照してください。

• Role-Based Access Control (RBAC) の機能強化 - AZURE STACKが AD FS と共にデプロイされたときに、RBAC を使用してユニバーサル ユーザー グループにアクセス許可を委任できるようになりました。 RBAC の詳細については、RBAC の管理に関するページを参照してください。

• 複数の障害ドメインのサポートが追加されました。 詳細については、「Azure Stackの高可用性」を参照してください。

• 物理メモリアップグレードのサポート - 初期デプロイ後Azure Stack統合システムのメモリ容量を拡張できるようになりました。 詳細については、「Azure Stackを参照してください。

• パフォーマンス、安定性、セキュリティ、およびAzure Stackで使用されるオペレーティング システムに関するさまざまな修正。

更新プロセスに関する既知の問題

更新プログラム 1802 のインストールに関する既知の問題はありません。

既知の問題 (インストール後)

ビルド 20180302.1 のインストール後について次の既知の問題があります。

Portal

• Azure Stack ID システムに AD FS を使用し、このバージョンのAzure Stackに更新すると、既定のプロバイダー サブスクリプションの既定の所有者は、組み込みの CloudAdmin ユーザーにリセットされます。
  回避策: この更新プログラムをインストールした後にこの問題を解決するには、Trigger オートメーションの手順 3 を使用して、既定のプロバイダー サブスクリプションの所有者をリセットするように Azure Stack プロシージャでクレーム プロバイダーの信頼を構成します。

• 管理者ポータルのドロップダウン リストから新しいサポート要求を開く機能は使用できません。 代わりに、次のリンクを使用します。

  • 統合システムAzure Stack場合は、https://aka.ms/newsupportrequest を使用します。

• 管理ポータルでは、BLOB サービス、Table service、または Queue サービスのストレージ メトリックを編集することはできません。 [ストレージ] に移動し、Blob、Table、または Queue サービスのタイルを選択すると、新しいブレードが開き、そのサービスのメトリック グラフが表示されます。 メトリック グラフ タイルの上部にある [編集] を選択すると、[グラフの編集] ブレードが開きますが、メトリックを編集するオプションは表示されません。

• 管理ポータルでコンピューティング リソースやストレージ リソースを表示できない場合があります。 この問題の原因は、更新プログラムのインストール中にエラーが発生し、更新が正常に行われたことが誤って報告されたためです。 この問題が発生した場合は、Microsoft カスタマー サポート サービスにお問い合わせください。

• ポータルに空のダッシュボードが表示されることがあります。 ダッシュボードを復元するには、ポータルの右上にある歯車アイコンを選択し、[既定の設定に戻す] を選択します。

• ユーザー サブスクリプションを削除すると、リソースが孤立します。 回避策として、まず、ユーザー リソースまたはリソース グループ全体を削除してから、ユーザー サブスクリプションを削除します。

• Azure Stack ポータルを使用してサブスクリプションへのアクセス許可を表示することはできません。 この問題を回避するには、PowerShell を使用してアクセス許可を確認します。

• 管理ポータルのダッシュボードの [更新] タイルで、更新プログラムに関する情報を表示できません。 この問題を解決するには、そのタイルをクリックして更新してください。

• 管理ポータルに、Microsoft.Update.Admin コンポーネントに関する重大なアラートが表示される場合があります。 アラート名、説明、解決策が、次のようにすべて表示されます。

  エラー - FaultType ResourceProviderTimeout 用のテンプレートが見つかりません。

  このアラートは無視してかまいません。

• 管理者ポータルとユーザー ポータルで、vNet サブネットの [設定] ブレードを読み込めません。 回避策として、PowerShell と Get-AzVirtualNetworkSubnetConfig コマンドレットを使用して、この情報を表示および管理します。

• 管理ポータルとユーザー ポータルの両方で、古い API バージョン (2015-06-15 など) で作成されたストレージ アカウントの [概要] ブレードを選択した場合、[概要] ブレードの読み込みに失敗します。 これには、パッチと更新プログラムの実行時に使用される updateadminaccount などのシステム ストレージ アカウントが含まれます。

  この問題を回避するには、PowerShell を使用して Start-ResourceSynchronization.ps1 スクリプトを実行し、ストレージ アカウントの詳細へのアクセスを復元します。 スクリプトはGitHubから使用でき、特権エンドポイントでサービス管理者の資格情報を使用して実行する必要があります。

• [サービス正常性] ブレードの読み込みに失敗します。 管理者ポータルまたはユーザー ポータルで [サービス正常性] ブレードを開くと、Azure Stackエラーが表示され、情報は読み込まれません。 これは正しい動作です。 Service Health を選択して開くことができますが、この機能はまだ使用できませんが、今後のバージョンのAzure Stackで実装される予定です。

健康と監視

• 以下の詳細を持つ正常性コントローラーコンポーネントのアラートが表示されることがあります。

  アラート #1:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラー「ハートビートスキャナー」は利用できません。 これは、健康レポートと指標に影響する可能性があります。

  アラート #2:

  • 名前: インフラストラクチャ ロールの異常
  • 重大度: 警告
  • コンポーネント: 正常性コントローラー
  • 説明: ヘルスコントローラーの故障スキャナーは使用できません。 これは、健康レポートと指標に影響する可能性があります。

  いずれのアラートも無視してかまいません。 時間が経つと自動的に閉じられます。

Marketplace

• ユーザーはサブスクリプションなしですべてのマーケットプレースを参照し、プランやオファーなどの管理アイテムを表示できます。 ユーザーはこれらのアイテムを使用できません。

Compute

• 仮想マシン スケール セットのスケーリング設定は、ポータルで使用できません。 回避策として、Azure PowerShellを使用できます。 PowerShell のバージョンの違いにより、 パラメーターの代わりに を使用する必要があります。

• バージョン 1802 より前のAzure Stackを使用しているときに作成された仮想マシン スケール セット (VMSS) をスケールアップすることはできません。 これは、仮想マシン スケールセットでの可用性セットの使用のサポートが変更されたことが原因です。 このサポートはバージョン 1802 で追加されました。 このサポートが追加される前に作成された VMSS をスケーリングするために、追加インスタンスを追加しようとすると、アクションは失敗し、"プロビジョニング状態失敗" という メッセージが表示されます。

  この問題はバージョン 1803 で解決されました。 バージョン 1802 のこの問題を解決するには、Azure Stack修正プログラム 1.0.180302.4 をインストールします。 詳細については、「KB 4131152: 既存のVirtual Machine Scale Setsが使用できなくなる可能性がありますを参照してください。

• Azure Stackでは、固定型 VHD の使用のみがサポートされています。 Azure Stackマーケットプレースを通じて提供される一部のイメージは動的 VHD を使用しますが、これらは削除されています。 ダイナミック ディスクがアタッチされている仮想マシン (VM) のサイズを変更すると、VM はエラー状態のままになります。

  この問題を軽減するには、VM のディスク、つまりストレージ アカウントの VHD BLOB を削除せずに VM を削除します。 次に、VHD をダイナミック ディスクから固定ディスクに変換した後、仮想マシンを再作成します。

• ポータルで [新規][コンピューティング][可用性セット] に移動して可用性セットを作成した場合、障害ドメインと更新ドメインが 1 の可用性セットのみを作成できます。 回避策として、新しい仮想マシンを作成する場合は、PowerShell、CLI、またはポータル内から可用性セットを作成します。

• Azure Stack ユーザー ポータルで仮想マシンを作成すると、D シリーズ VM に接続できるデータ ディスクの数が誤って表示されます。 サポートされているすべての D シリーズ VM は、Azure構成と同数のデータ ディスクに対応できます。

• VM イメージの作成に失敗した場合に、失敗したのに削除できない項目が、VM イメージのコンピューティング ブレードに追加される可能性があります。

  回避策として、Hyper-V (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB) で作成できるダミー VHD を使用して新しい VM イメージを作成します。 このプロセスによって、失敗した項目の削除を妨げている問題が修正されます。 その後、ダミーのイメージを作成してから 15 分経つと、正常に削除できます。

  次に、前に失敗した VM イメージの再ダウンロードを試行できます。

• VM の展開で拡張機能のプロビジョニングに時間がかかりすぎる場合、ユーザーは、プロセスを停止して VM の割り当て解除または削除を試みるのではなく、プロビジョニングをタイムアウトさせる必要があります。

• Linux VM 診断は、Azure Stackではサポートされていません。 VM 診断を有効にして Linux VM を展開すると、展開が失敗します。 診断設定で Linux VM の基本メトリックを有効にした場合も、展開が失敗します。

ネットワーク

• VM を作成してパブリック IP アドレスに関連付けた後は、IP アドレスからその VM の関連付けを解除することはできません。 関連付けの解除は機能したように見えますが、以前に割り当てられたパブリック IP アドレスは、元の VM に関連付けられたままになります。

  現時点では、作成した新しい VM には新しいパブリック IP アドレスのみを使用する必要があります。

  この動作は、IP アドレスを新しい VM に 再割り当てした (一般に VIP スワップと呼ばれます) 場合でも行われます。 以降のこの IP アドレスによるすべての接続の試みは、新しい VM ではなく、元々関連付けられていた VM に接続する結果になります。

• 内部負荷分散 (ILB) では、バックエンド VM の MAC アドレスが正しく処理されないため、バックエンド ネットワークで Linux インスタンスを使用すると ILB が中断します。 ILB は、Back-End ネットワーク上のWindows インスタンスで正常に動作します。

• IP 転送機能がポータルに表示されますが、IP 転送を有効にしても何も起こりません。 この機能は、まだサポートされていません。

• Azure Stackでは、IP アドレスごとに 1 つのローカル ネットワーク ゲートウェイがサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• Automatic の DNS サーバー設定で作成されたVirtual Networkでは、カスタム DNS サーバーへの変更は失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• Azure Stackでは、VM のデプロイ後に VM インスタンスにネットワーク インターフェイスを追加することはできません。 VM に複数のネットワーク インターフェイスが必要な場合は、展開時に定義する必要があります。

• 管理ポータルを使用してネットワーク セキュリティ グループのルールを更新することはできません。

  App Service の回避策: コントローラー インスタンスへのリモート デスクトップ接続が必要な場合は、PowerShell を使用してネットワーク セキュリティ グループ内のセキュリティ規則を変更します。 "許可" する方法と、次にこの構成を復元して "拒否" する方法の例を次に示します。

  • [許可]:

    Login-AzureRMAccount -EnvironmentName AzureStackAdmin
    
    $nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"
    
    $RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"
    
    ##This doesn't work. Need to set properties again even in case of edit
    
    #Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  
    
    Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
      -Name $RuleConfig_Inbound_Rdp_3389.Name `
      -Description "Inbound_Rdp_3389" `
      -Access Allow `
      -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
      -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
      -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
      -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
      -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
      -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
      -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange
    
    # Commit the changes back to NSG
    Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg
    

  • 拒否:

    
    Login-AzureRMAccount -EnvironmentName AzureStackAdmin
    
    $nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"
    
    $RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"
    
    ##This doesn't work. Need to set properties again even in case of edit
    
    #Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  
    
    Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
      -Name $RuleConfig_Inbound_Rdp_3389.Name `
      -Description "Inbound_Rdp_3389" `
      -Access Deny `
      -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
      -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
      -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
      -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
      -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
      -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
      -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange
    
    # Commit the changes back to NSG
    Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg 
    

SQL および MySQL

• 続行する前に、これらのリリース ノートの冒頭にある「開始する前に」の重要な注意事項を確認します。

• ユーザーがデータベースを新しい SQL または MySQL の展開で作成するまでに、最大で 1 時間かかる場合があります。

• SQL または MySQL をホストするサーバー上に項目を作成できるのは、リソース プロバイダーのみです。 リソース プロバイダー以外がホスト サーバー上に項目を作成すると、不一致状態になる可能性があります。

• SQL と MySQL リソース プロバイダーの SKU を作成する場合、[ファミリ] 名では、スペースやピリオドなどの特殊文字はサポートされていません。

App Service

• ユーザーは、サブスクリプションで最初の Azure 関数を作成する前に、ストレージ リソース プロバイダーを登録する必要があります。

• インフラストラクチャ (worker、管理、フロントエンド ロール) をスケールアウトするには、コンピューティングのリリース ノートの説明に従って PowerShell を使用する必要があります。

GitHubから Azure Stack ツールをダウンロードする

• invoke-webrequest PowerShell コマンドレットを使用してGitHubからAzure Stack ツールをダウンロードすると、エラーが表示されます。

  • "invoke-webrequest : 要求は中止されました: SSL/TLS のセキュリティで保護されたチャネルを作成できませんでした。"

  このエラーは、Tlsv1 および Tlsv1.1 暗号化標準 (PowerShell の既定値) の最近のGitHubサポートの廃止が原因で発生します。 詳細については、脆弱な暗号化標準の削除の通知に関するページを参照してください。

  この問題を解決するには、スクリプトの先頭に [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 を追加して、GitHub リポジトリからダウンロードするときに PowerShell コンソールで TLSv1.2 を使用するように強制します。

更新プログラムのダウンロード

Azure Stack 1802 更新プログラム パッケージは、here からダウンロードできます。

詳細

Microsoft は、更新プログラム 1710 でインストールされる特権エンドポイント (PEP) を使用して、更新プログラムを監視および再開するための方法を提供しています。

• 特権エンドポイントのドキュメントを使用して、Azure Stackの Monitor の更新を参照してください。

関連項目

• Azure Stackでの更新管理の概要については、Azure Stackの管理の概要に関するページを参照してください。
• Azure Stackで更新プログラムを適用する方法の詳細については、「apply updates in Azure Stack」を参照してください。