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

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 更新プログラムと比較しないでください。

更新プログラムのビルドの種類については、「Azure Stack Hub での更新プログラム管理の概要」を参照してください。

新機能

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

変更点

• Azure Stack Hub 2306 リリースは、Intel の Broadwell CPU プラットフォームに基づく統合システムにインストールできる最後の主要な更新プログラムです。 2311 (以降) リリースは、Intel によって Broadwell プラットフォームでサポートされていない Windows Server 2022 コード ベースに基づいています。 CPU プロセッサ ファミリまたはハードウェア関連の質問については、ハードウェア 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 更新プログラムのビルドの種類は完全です。

2301 更新プログラムには、内部テストに基づいて次のランタイムが必要です。

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

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

更新プログラムのビルドの種類については、「Azure Stack Hub での更新プログラム管理の概要」を参照してください。

新機能

• Azure Stack Hub 用 Azure Site Recovery リソース プロバイダー のパブリック プレビュー リリース。
• 新しい VPN Gateway SKU を使用した VPN ファースト パスのパブリック プレビュー リリース。
• Azure Stack Hub オペレーターと Azure Stack Hub ユーザー向けの新しい VPN ファースト パス ドキュメント。
• 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 更新プログラムのビルドの種類は完全です。

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

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

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 期間がこの予測値よりも短くなったり長くなったりするのは珍しいことではなく、更新が失敗した場合を除き、Azure Stack Hub オペレーターによるアクションは不要です。 この実行時間の概算は 2206 更新プログラムに固有であるため、他の Azure Stack Hub 更新プログラムと比較しないでください。

更新プログラムのビルドの種類については、「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 更新プログラムのビルドの種類は完全です。

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

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

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 期間がこの予測値よりも短くなったり長くなったりするのは珍しいことではなく、更新が失敗した場合を除き、Azure Stack Hub オペレーターによるアクションは不要です。 この実行時間の概算は 2102 更新プログラムに固有であるため、他の Azure Stack Hub 更新プログラムと比較しないでください。

更新プログラムのビルドの種類については、「Azure Stack Hub での更新プログラム管理の概要」を参照してください。

新機能

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

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

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

• Azure Stack Hub ストレージで、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 ドライバー 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 が追加されました。
• Active Directory 証明書サービス (ADCS) と CA VM が 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 は有効になっていません。 有効にするには、-EnableWac フラグを指定します (例: unlock-supportsession -EnableWac)。
• オペレーターに表示されないエラー状態の間にログをキャプチャする、強化されたアルゴリズムが、事前ログ収集で使用されるようになりました。 このアルゴリズムにより、正しい診断情報が確実かつ適切なタイミングで収集されるようになります。オペレーターとの対話は不要です。 場合によっては、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 のサポートされているバージョンについてのリリース ノートは、[概要] > [リリースノート]の順にクリックしてください

2108 ビルドのリファレンス

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

更新の種類

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

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

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

更新プログラムの正確な期間は一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 期間がこの予測値よりも短くなったり長くなったりするのは珍しいことではなく、更新が失敗した場合を除き、Azure Stack Hub オペレーターによるアクションは不要です。 この実行時間の概算は 2108 更新プログラムに固有であるため、他の Azure Stack Hub 更新プログラムと比較しないでください。

更新プログラムのビルドの種類については、「Azure Stack Hub での更新プログラム管理の概要」を参照してください。

新機能

• Azure Stack Hub オペレーターは、VM の GPU クォータを構成できるようになります。
• 緊急 VM アクセスが、Microsoft サポートに連絡しなくても Azure Stack Hub で使用できるようになります。
• Windows Server 2022 が、ゲスト オペレーティング システムとしてサポートされるようになります。 Windows Server 2022 VM は、バージョン 2108 以降を実行している Azure Stack Hub 上の Windows Server で仮想マシンの自動ライセンス認証を使用して手動でライセンス認証する必要があります。 以前のバージョンではライセンス認証できません。
• このバージョン以降、事前ログ収集が無効になっている場合、事前障害イベントについてキャプチャされたログはローカル環境に保存されます。 ローカル ログには、サポート ケースのコンテキストでのみ Microsoft がアクセスできます。 事前ログ収集の Alert ライブラリに、新しいアラートが追加されました。
• このリリースでは、Azure Kubernetes Service と Azure Container Registry の 2 つの新しいサービスを、パブリック プレビューで利用できます。
• AzureStack モジュール 2.2.0 は、Azure Stack Hub バージョン 2108 に合わせてリリースされます。 バージョンの更新には、コンピューティング管理者モジュールの変更と、新しいモジュール Azs.ContainerRegistry.Admin および Azs.ContainerService.Admin が含まれます。 その他の詳細については、変更ログに関するページをご覧ください。
• このリリースでは、テレメトリ データは Microsoft によって管理および制御される Azure ストレージ アカウントにアップロードされます。 Azure Stack Hub テレメトリ サービスは、Microsoft にテレメトリ データを正常にアップロードするため、https://*.blob.core.windows.net/ と https://azsdiagprdwestusfrontend.westus.cloudapp.azure.com/ に接続します。 ポート 443 (HTTPS) が開かれている必要があります。 詳しくは、Azure Stack Hub テレメトリに関するページをご覧ください。
• このリリースには、リモート サポートのパブリック プレビューが含まれています。これにより、Microsoft のサポート プロフェッショナルは、お客様のデバイスにリモート アクセスして、限られたトラブルシューティングと修復を実行できるため、サポート ケースをより迅速に解決できます。 お客様は、同意することでこの機能を有効にすることができ、アクセス レベルとアクセス期間を制御できます。 サポートは、サポート要求が送信された後にのみ、デバイスにアクセスできます。 詳しくは、「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 更新プログラムのビルドの種類は完全です。

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

更新プログラムのビルドの種類については、「Azure Stack Hub での更新プログラム管理の概要」を参照してください。

新機能

• Azure Stack Hub で VNET ピアリングがサポートされるようになりました。これにより、ネットワーク仮想アプライアンス (NVA) を使用せずに VNET に接続できるようになります。 詳細については、新しい VNET ピアリングのドキュメントを参照してください。
• Azure Stack Hub の Blob Storage で、ユーザーが不変 BLOB を使用できるようになりました。 コンテナーで不変ポリシーを設定することにより、ビジネス クリティカルなデータ オブジェクトを WORM (Write Once, Read Many) 状態で格納することができます。 このリリースでは、不変ポリシーは REST API またはクライアント SDK によってのみ設定できます。 このリリースでは、追加 BLOB の書き込みもできません。 不変 BLOB の詳細については、「不変ストレージを使用してビジネスに不可欠な BLOB データを保存する」を参照してください。
• Azure Stack Hub ストレージで、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 Engine v 0.55.4 を使用する Azure CNI と Windows コンテナーのパブリック プレビューが含まれています。 API モデルでこれらを使用する方法の例については、GitHub のこちらの例を参照してください。
• AKS Engine v 0.55.4 によってデプロイされたクラスターでの Istio 1.3 デプロイがサポートされるようになりました。 詳細については、こちらの手順を参照してください。
• AKS Engine v 0.55.4 を使用したプライベート クラスターのデプロイがサポートされるようになりました。
• このリリースでは、Azure および Azure Stack Hub Key Vault インスタンスからの Kubernetes の構成シークレットのソーシングがサポートされています。

機能強化

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

変更点

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

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

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

• Windows Server 2019 用に定義されている現在のベスト プラクティスに合わせるために、Azure Stack Hub は、追加のトラフィック クラスまたは優先順位を使用して、フェールオーバー クラスタリング制御通信をサポートするサーバー間通信をさらに分離するように変更されています。 これらの変更により、フェールオーバー クラスターの通信の回復性が向上します。 このトラフィック クラスと帯域幅の予約の構成は、Azure Stack Hub ソリューションの Top-of-Rack (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 更新プログラムのビルドの種類は完全です。

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

更新プログラムのビルドの種類については、「Azure Stack Hub での更新プログラム管理の概要」を参照してください。

新機能

• このビルドでは、NCv3 (Nvidia V100)、NVv4 (AMD MI25)、NCas_v4 (NVIDIA T4) VM サイズの 3 つの新しい GPU VM の種類がサポートされます。 適切なハードウェアを使用し、Azure Stack Hub GPU プレビュー プログラムにオンボードされていれば、VM のデプロイは成功します。 関心がある場合は、https://aka.ms/azurestackhubgpupreview で 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 で wireserver プロトコルが使用されることを発表しました。これにより、お客様は 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 プラットフォームとシグネチャのバージョンの不一致、および検出されたマルウェアに対するアクションの失敗を報告するために、Azure Stack 管理者ポータルに Windows Defender 関連のイベントのアラートが追加されました。
• Azure Stack Hub をデータセンターに統合するときに、4 つの境界デバイスのサポートが追加されました。

変更点

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

フィックス

• ベース OS イメージへのパスが見つからないためスケール ユニット ノードの修復が失敗する原因となる問題を修正しました。
• スケール ユニット ノードの修復に連鎖的な影響を及ぼすサポート インフラストラクチャ ロールのスケールインとスケールアウトに関する問題を修正しました。
• オペレーターが [すべてのサービス] > [コンピューティング] > [VM イメージ] > [追加] で Azure Stack Hub 管理者ポータルに独自のイメージを追加するときに (.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 更新プログラムのビルドの種類は完全です。

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

更新プログラムのビルドの種類については、「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] ([ノード名] の時間ソースが無効です) です。
• 2002 での TLS 制限に関連する破壊的変更により、Java SDKの新しいパッケージがリリースされました。 新しい Java SDK 依存関係をインストールする必要があります。 手順については、「Java と API バージョンのプロファイル」を参照してください。
• System Center Operations Manager - Azure Stack Hub MP の新しいバージョン (1.0.5.10) が利用できます。これは、API の破壊的変更により、2002 を実行しているすべてのシステムで必要となります。 この API の変更は、バックアップとストレージのパフォーマンス ダッシュボードに影響します。最初にすべてのシステムを 2002 に更新してから MP を更新することをお勧めします。

機能強化

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

変更点

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

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

  リソース プロバイダー	リソース	バージョン
  Microsoft.Storage.Admin	farms	2015-12-01-preview
  Microsoft.Storage.Admin	farms/acquisitions	2015-12-01-preview
  Microsoft.Storage.Admin	farms/shares	2015-12-01-preview
  Microsoft.Storage.Admin	farms/storageaccounts	2015-12-01-preview

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

  リソース プロバイダー	リソース	バージョン
  Microsoft.Backup.Admin	backupLocation	2016-05-01
  Microsoft.Backup.Admin	バックアップ	2016-05-01
  Microsoft.Backup.Admin	operations	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 の更新の準備フェーズ中に更新ステータスが [準備中] ではなく [インストール中] と表示されていた、更新ブレードのバグを修正しました。
• 仮想スイッチ上の 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 更新プログラムのビルドの種類は高速です。

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

更新プログラムのビルドの種類については、「Azure Stack Hub での更新プログラム管理の概要」を参照してください。

新機能

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

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

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

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

• Azure Stack Hub 管理 PowerShell モジュールの新しいバージョンがリリースされました。

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

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

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

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

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

機能強化

• Azure Stack Hub では、以前に更新の失敗を引き起こしたり、オペレーターによる Azure Stack Hub の更新開始を妨げたりしていた修正プログラムや更新プログラムの問題を自動修復する機能が向上しています。 その結果、Test-AzureStack -UpdateReadiness グループに含まれるテストの数が減っています。 詳細については、「Azure Stack Hub システムの状態を検証する」を参照してください。 次の 3 つのテストは UpdateReadiness グループに残っています。

  • AzSInfraFileValidation
  • 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
  Dead Peer Detection	サポートされています

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

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

変更点

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

• 1910 リリース以降、Azure Stack Hub システムには追加で /20 プライベート内部 IP 空間が必要になりました。 詳細については、「Azure Stack のためのネットワーク統合計画」を参照してください。

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

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

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

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

フィックス

• 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 更新プログラムのビルドの種類は完全です。 そのため、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 オペレーターは、ポータル ユーザー データを削除できるようになりました。 詳細については、「Clear portal user data from Azure Stack」 (Azure Stack からポータル ユーザー データをクリアする) を参照してください。

機能強化

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

変更点

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

フィックス

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

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

Azure Stack のこの更新でのセキュリティ更新プログラムについては、「Azure Stack security updates」 (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 更新プログラムには、システムのハードウェア プロバイダーからの Azure Stack OEM バージョン 2.1 以降が必要です。 OEM 更新プログラムには、Azure Stack システム ハードウェアのドライバーとファームウェアの更新プログラムが含まれています。 OEM 更新プログラムの適用の詳細については、「Azure Stack に OEM (相手先ブランド供給) 更新プログラムを適用する」を参照してください

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 更新プログラムのビルドの種類は高速です。 更新プログラムのビルドの種類については、「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 エンドポイントへの接続が示されます。 さらに、ID プロバイダーとして Azure AD を使用する場合に Azure への、または ADFS を使用する場合にフェデレーション サーバーへの接続が確認されます。 詳細については、Azure Stack 検証ツールに関する記事を参照してください。

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

機能強化

• Azure Stack の更新ブレードに、アクティブな更新の最後のステップが完了した時刻が表示されるようになりました。 これは、更新ブレードに移動し、実行中の更新をクリックすると表示されます。 [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 以降に更新するようにオペレーターに指示する警告アラートが含まれています。 Azure Stack の OEM 更新プログラムの適用方法の詳細については、「Azure Stack に OEM (相手先ブランド供給) 更新プログラムを適用する」を参照してください。

• Azure Stack 診断ログ収集サービスの通信を有効にするための新しいアウトバウンド規則 (HTTPS) が追加されました。 詳細については、Azure Stack データセンター統合 - エンドポイントの発行に関するページをご覧ください。

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

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

• [コンピューティング] > [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 security updates」 (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 更新プログラムのビルドの種類は高速です。 更新プログラムのビルドの種類については、「Azure Stack での更新プログラムの管理概要」を参照してください。 1906 更新プログラムが完了するまでの予測所要時間は、ご使用の Azure Stack 環境内の物理ノード数に関係なく、約 10 時間です。 更新プログラムの正確なランタイムは一般的に、ご使用のシステムでテナント ワークロードによって使用されている容量、システム ネットワーク接続 (インターネットに接続されている場合)、およびシステム ハードウェアの仕様に左右されます。 ランタイムがこの予測値よりも長くなることは一般的ではなく、更新が失敗した場合を除き、Azure Stack オペレーターによるアクションは不要です。 このおおよその実行時間は、1906 更新プログラムに固有であり、他の Azure Stack 更新プログラムと比較することはできません。

この更新プログラムの新機能

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

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

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

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

• AD FS を使用した Azure Stack のデプロイで Visual Studio Code がサポートされるようになりました。

機能強化

• 特権エンドポイントの Get-GraphApplication コマンドレットで、現在使用されている証明書の拇印が表示されるようになりました。 これにより、AD FS で Azure Stack がデプロイされるときのサービス プリンシパルの証明書の管理が改善されます。

• 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 security updates」 (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 に更新プログラムを適用する方法については、「Azure Stack で更新を適用する」を参照してください。
• Azure Stack 統合システムのサービス ポリシーについて、およびサポートを受けられる状態にシステムを維持するために必要な作業について確認するには、「Azure Stack サービス ポリシー」を参照してください。
• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。

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

適用対象: Azure Stack 統合システム

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

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

ビルドのリファレンス

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

更新の種類

Azure Stack 1905 更新プログラムのビルドの種類は完全です。 そのため、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 を通した配信に利用できます。 この更新プログラムでは、2016 ホスト上で Windows Server 2019 を正常にアクティブにできるようになりました。

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

機能強化

• 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 ポータルの新しいヘルプとサポートの概要により、オペレーターは簡単にサポート オプションを確認したり、専門家の支援を得たり、Azure Stack の詳細について学習したりできます。 統合システムでは、サポート リクエストを作成するときは Azure Stack サービスが事前に選択されます。 グローバルな Azure portal を使うのではなく、このエクスペリエンスを使ってチケットを送信することをお客様に強くお勧めします。 詳しくは、「Azure Stack Help and Support」(Azure Stack のヘルプとサポート) をご覧ください。

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

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

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

• Azure Stack のすべての最新機能がサポートされている新しいハイブリッド プロファイル 2019-03-01-Hybrid がリリースされました。 2019-03-01-Hybrid プロファイルは、Azure PowerShell と Azure CLI の両方でサポートされています。 .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	44 GB
  12 ノード	54 vCPU	60 GB
  16 ノード	70 vCPU	76 GB

変更点

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

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

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

フィックス

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

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

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

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

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

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

Azure Stack のこの更新でのセキュリティ更新プログラムについては、「Azure Stack security updates」 (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 に更新プログラムを適用する方法については、「Azure Stack で更新を適用する」を参照してください。
• Azure Stack 統合システムのサービス ポリシーについて、およびサポートを受けられる状態にシステムを維持するために必要な作業について確認するには、「Azure Stack サービス ポリシー」を参照してください。
• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。

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

適用対象: Azure Stack 統合システム

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

ビルドのリファレンス

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

更新の種類

Azure Stack 1904 更新プログラムのビルドの種類は高速です。 更新プログラムのビルドの種類については、「Azure Stack での更新プログラムの管理概要」を参照してください。 1904 更新プログラムが完了するまでの予測所要時間は約 16 時間ですが、正確な時間は変わる可能性があります。 このおおよその実行時間は、1904 更新プログラムに固有であり、他の Azure Stack 更新プログラムと比較することはできません。

この更新プログラムの新機能

機能強化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

変更点

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

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

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

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

  • "ソフト" な警告アラートの場合、ポータルに "The most recent update needs attention. Microsoft recommends opening a service request during normal business hours. As part of the update process, Test-AzureStack is performed, and based on the output we generate the most appropriate alert. In this case, Test-AzureStack passed." (最新の更新プログラムには注意が必要です。マイクロソフトは通常の営業時間中にサポート リクエストを開くことをお勧めします。更新プロセスの一環として Test-AzureStack が実行され、その出力に基づいて最も適切なアラートが生成されます。このケースでは、Test-AzureStack は合格しています。)

  • "ハード" で重大なアラートの場合、ポータルに "The most recent update failed. Microsoft recommends opening a service request as soon as possible. As part of the update process, Test-AzureStack is performed, and based on the output we generate the most appropriate alert. In this case, Test-AzureStack also failed." (最新の更新プログラムは失敗しました。マイクロソフトはできるだけ早くサポート リクエストを開くことをお勧めします。更新プロセスの一環として Test-AzureStack が実行され、その出力に基づいて最も適切なアラートが生成されます。このケースでは、Test-AzureStack も失敗しています。)

• Azure Linux Agent バージョン 2.2.38.0 を更新しました。 このサポートにより、お客様は Azure と Azure Stack との間で一貫性のある Linux イメージを保持できるようになります。

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

フィックス

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

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

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

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

• グローバル Azure portal について不適切な通知が表示されるという、管理者ポータルとユーザー ポータルの両方の問題を修正しました。

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

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

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

• Azure Stack が VM インスタンスへの 4 つを超えるネットワーク インターフェイス (NIC) のアタッチをサポートしていなかった問題を修正しました。

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

• ネットワーク セキュリティ グループ (NSG) がグローバル Azure と同様に Azure Stack で機能しなかった問題を修正しました。

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

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

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

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

• オフライン シンジケーション ツールを使用してイメージをアップロードしたときに、マーケットプレース管理画面に何も表示されず、いずれにもアイコンの 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 更新プログラムを適用する前

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

• Azure Stack 修正プログラム 1.1903.2.39

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

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

• Azure Stack 修正プログラム 1.1904.4.45

自動更新通知

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

次のステップ

• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「Azure Stack で更新を適用する」を参照してください。
• Azure Stack 統合システムのサービス ポリシーについて、およびサポートを受けられる状態にシステムを維持するために必要な作業について確認するには、「Azure Stack サービス ポリシー」を参照してください。
• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。

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

適用対象: Azure Stack 統合システム

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

ビルドのリファレンス

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

更新の種類

Azure Stack 1903 更新プログラムのビルドの種類は高速です。 更新プログラムのビルドの種類については、「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 を適用する前に、Microsoft Azure Stack 用の管理パックをバージョン 1.0.3.11 に更新してください。

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

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

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

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

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

更新後の手順

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

• 保存データの暗号化キーを取得し、お客様の Azure Stack デプロイの外部に安全に保管します。 キーを取得する方法の手順に関する記事に従ってください。

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

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

ポータル

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

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

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

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

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

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

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

  • New-AzureStorageContainerStoredAccessPolicy
  • Get-AzureStorageContainerStoredAccessPolicy
  • Set-AzureStorageContainerStoredAccessPolicy
  • Remove-AzureStorageContainerStoredAccessPolicy

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

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

• ユーザー ポータル ダッシュボードで [フィードバック] タイルを選択しようとすると、空のブラウザー タブが開きます。 回避策として、Azure Stack 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. 同じサブスクリプションで、[アクセス制御 (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 を [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] ブレードから削除することはできません。 回避策として、削除するスケール セットを選択し、[概要] ウィンドウから [削除] ボタンをクリックします。

• 4 ノードの Azure Stack 環境では、障害ドメインが 3 つの可用性セット内での VM の作成および仮想マシン スケール セット インスタンスの作成が更新プロセス中に FabricVmPlacementErrorUnsupportedFaultDomainSize エラーで失敗します。 障害ドメインが 2 つの可用性セット内には 1 つの VM を正常に作成できます。 ただし、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 で有効なのは次のオプションだけです。

  • Internet
  • VirtualNetwork
  • AzureLoadBalancer

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

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

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

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) の一般提供以降、Azure Stack のすべてのバージョンに当てはまります。 この問題を回避するには、Azure Stack の更新プログラムを適用した後に syslog クライアントを再構成してください。

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

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

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

次のステップ

• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「Azure Stack で更新を適用する」を参照してください。
• Azure Stack 統合システムのサービス ポリシーについて、およびサポートを受けられる状態にシステムを維持するために必要な作業について確認するには、「Azure Stack サービス ポリシー」を参照してください。
• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。

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

適用対象: Azure Stack 統合システム

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

ビルドのリファレンス

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

更新の種類

Azure Stack 1902 更新プログラムのビルドの種類は完全です。 更新プログラムのビルドの種類については、「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
  

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

• Azure Stack を System Center Operations Manager で管理している場合は、1902 を適用する前に、Microsoft Azure Stack 用の管理パックをバージョン 1.0.3.11 に更新してください。

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

機能強化

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

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

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

• Test-AzureStack を実行するとき、Include ステートメントの後に 10 個ものパラメーターを追加で渡す必要があったのが、"Test-AzureStack -Group UpdateReadiness" を使用するだけで済むようになり、Azure Stack 運用担当者にとってのエクスペリエンスが改善しました。

    Test-AzureStack -Group UpdateReadiness  
  

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

  • 最適な状態にないインフラストラクチャ仮想マシンがあるかどうかを確認し、必要に応じて修復を試みる。
  • コントロール プランの一部としての SQL サービスに問題が発生していないかどうかを確認し、必要に応じて修復を試みる。
  • ネットワーク コントローラー (NC) の一部を構成するソフトウェア ロード バランサー (SLB) サービスの状態を確認し、必要に応じて修復を試みる。
  • ネットワーク コントローラー (NC) サービスの状態を確認し、必要に応じて修復を試みる
  • 緊急回復コンソール サービス (ERCS) のサービス ファブリック ノードの状態を確認し、必要に応じて修復する。
  • インフラストラクチャ ロールの状態を確認し、必要に応じて修復する。
  • Azure Consistent Storage (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 デプロイの外部に安全に保管します。 キーを取得する方法の手順に関する記事に従ってください。

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

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

ポータル

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

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

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

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

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

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

  • New-AzureStorageContainerStoredAccessPolicy
  • Get-AzureStorageContainerStoredAccessPolicy
  • Set-AzureStorageContainerStoredAccessPolicy
  • Remove-AzureStorageContainerStoredAccessPolicy

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 からダウンロードしておいた別の CentOS イメージを指定する Azure Resource Manager テンプレートをご使用ください。

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

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

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

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

• 4 ノードの Azure Stack 環境では、障害ドメインが 3 つの可用性セット内での VM の作成および仮想マシン スケール セット インスタンスの作成が更新プロセス中に FabricVmPlacementErrorUnsupportedFaultDomainSize エラーで失敗します。 障害ドメインが 2 つの可用性セット内には 1 つの VM を正常に作成できます。 ただし、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 で有効なのは次のオプションだけです。

  • Internet
  • VirtualNetwork
  • AzureLoadBalancer

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

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

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

• ユーザー ポータルで、バックエンド プールをロード バランサーに追加しようとすると、"ロード バランサーを更新できませんでした...." のエラー メッセージで操作が失敗します。この問題を回避するには、PowerShell、CLI、または Azure Resource Manager テンプレートを使用して、バックエンド プールをロード バランサー リソースに関連付けます。

• ユーザー ポータルで、ロード バランサーのインバウンド NAT 規則を作成しようとすると、"ロード バランサーを更新できませんでした...." のエラー メッセージで操作が失敗します。この問題を回避するには、PowerShell、CLI、または Azure Resource Manager テンプレートを使用して、バックエンド プールをロード バランサー リソースに関連付けます。

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

App Service

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

Syslog

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

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

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

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

次のステップ

• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「Azure Stack で更新を適用する」を参照してください。
• Azure Stack 統合システムのサービス ポリシーについて、およびサポートを受けられる状態にシステムを維持するために必要な作業について確認するには、「Azure Stack サービス ポリシー」を参照してください。
• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。

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

適用対象: Azure Stack 統合システム

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

ビルドのリファレンス

2019 年 2 月 26 日以降、Azure Stack 1901 更新プログラムのビルド番号は 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 のマネージド ディスクに関するページを参照してください。

• AzureRm 2.4.0

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

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

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

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

修正された問題

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

• Virtual Network の DNS 設定が [Use Azure Stack DNS]\(Azure Stack DNS を使用\) から [Custom DNS]\(カスタム 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:

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

• [compute quota types]\(Compute クォータの種類\) でマネージド ディスク クォータの値を 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 セッションを使用できるようになりました。

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

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

• [有効なセキュリティ ルール] リンクが [ネットワーク プロパティ] ブレードから削除されました。これは、この機能が Azure Stack でサポートされないためです。 このリンクが表示されていたため、この機能がサポートされているような印象がありましたが、この機能は動作しません。 混乱を避けるために、このリンクは削除されました。

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

変更点

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

• 2019 年 1 月以降、Kubernetes クラスターを、Active Directory フェデレーション サービス (AD FS) に登録されている、接続済みの Azure Stack スタンプにデプロイできます (インターネット アクセスが必要です)。 新しい 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 更新プログラムでは、作成できる仮想マシンの合計数に制限があります。 この制限は、ソリューションの不安定性を回避するための一時的なものです。 VM の数が多い場合の安定性の問題の原因は対処されていますが、修復のための具体的なタイムラインは決定されていません。 1901 更新プログラムでは、VM の数が、サーバーごとに 60 個、ソリューションの合計で 700 個に制限されています。 たとえば、8 サーバーの Azure Stack VM の制限は 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 を -Repair フラグで実行するように求められます。 このコマンドを実行すると、次のエラー メッセージが表示されて失敗します: 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 デプロイの外部に安全に保管します。 キーを取得する方法の手順に関する記事に従ってください。

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

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

ポータル

• 管理ポータルとユーザー ポータルの両方で、"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 では使用できないため、デプロイ用に別のオペレーティング システムを選択するか、またはデプロイする前にオペレーターが Marketplace からダウンロードしておいた別の CentOS イメージを指定する Azure Resource Manager テンプレートをご使用ください。

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

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

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

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

ネットワーク

• 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 で有効なのは次のオプションだけです。

  • Internet

  • VirtualNetwork

  • AzureLoadBalancer

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

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

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

App Service

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

Syslog

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

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

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

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

次のステップ

• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「Azure Stack で更新を適用する」を参照してください。
• Azure Stack 統合システムのサービス ポリシーについて、およびサポートを受けられる状態にシステムを維持するために必要な作業について確認するには、「Azure Stack サービス ポリシー」を参照してください。
• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。

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

適用対象: Azure Stack 統合システム

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

ビルドのリファレンス

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

修正プログラム

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

Azure Stack 修正プログラム

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

前提条件

• Azure Stack の拡張機能ホスト用にお客様の Azure Stack デプロイを準備します。 次のガイダンスを使用してシステムを準備します。 Azure Stack 用の拡張機能ホストを準備します。

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

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

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

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

  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://video2.skills-academy.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://video2.skills-academy.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 管理者 PowerShell または特権エンドポイントを使用して、更新プログラムの状態を確認したり、失敗した更新プログラムのインストールを再開したりできます。

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

新機能

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

• このリリースでは、拡張機能ホストが有効になります。 拡張機能ホストによって、ネットワークの統合が簡素化され、Azure Stack のセキュリティ体制が強化されます。

• Active Directory Federated Services (AD FS) でのデバイス認証に対するサポートが追加されました (特に Azure CLI を使用している場合)。 詳細については、「Azure Stack での Azure CLI による API バージョンのプロファイルの使用」を参照してください。

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

• このリリースでは、次の Azure Storage Service API バージョン (2017-07-29、 2017-11-09) のサポートが追加されます。 また、次の Azure Storage Resource Provider API バージョン (2016-05-01、2016-12-01、2017-06-01、2017-10-01) のサポートも追加されています。 詳しくは、「Azure Stack ストレージ: 違いと考慮事項」をご覧ください。

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

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

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

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

• Azure portal と同様に、管理者ポータルとユーザー ポータルの右上隅にあるサポート アイコン (疑問符) とヘルプを通じて Azure ロードマップにアクセスできるようになりました。

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

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

• Azure Stack PowerShell がバージョン 1.6.0 に更新されました。 この更新には、Azure Stack の新しいストレージ関連機能のサポートが含まれます。 詳細については、PowerShell ギャラリーで Azure Stack Administration Module 1.6.0 のリリース ノートを参照してください。Azure Stack PowerShell の更新とインストールについては、「PowerShell for Azure Stack をインストールする」を参照してください。

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

• このリリースでは、Azure Stack オペレーター向けにアラートの修復操作が採用されています。 1811 のいくつかのアラートには、[修復] ボタンが表示され、そのボタンを選択することで問題を解決できます。 詳細については、「Azure Stack での正常性およびアラートの監視」を参照してください。

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

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

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

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

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

  • オンラインの Azure Stack スケール ユニットでは、更新プログラムが利用可能になると利用可能な更新プログラムを自動的に受け取ります。

  • オフラインの Azure Stack スケール ユニットでは、前と同じように、更新プログラムをインポートできます。

  • ポータルから JSON ログをダウンロードするプロセスに変更はありません。 Azure Stack オペレーターは、手順を展開して進行状況を見ることができます。

    詳しくは、「Azure Stack で更新を適用する」をご覧ください。

修正された問題

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

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

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

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

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

• 新しい Azure Stack 環境をインストールするときに発生していた問題 ("アクティブ化が必要" であること示すアラートが表示されない) が修正されました。 今後は正しく表示されます。

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

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

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

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

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

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

変更点

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

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

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

共通脆弱性識別子

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

• CVE-2018-8256
• CVE-2018-8407
• CVE-2018-8408
• CVE-2018-8415
• CVE-2018-8417
• CVE-2018-8450
• CVE-2018-8471
• CVE-2018-8476
• CVE-2018-8485
• CVE-2018-8544
• CVE-2018-8547
• CVE-2018-8549
• CVE-2018-8550
• CVE-2018-8553
• CVE-2018-8561
• CVE-2018-8562
• CVE-2018-8565
• CVE-2018-8566
• CVE-2018-8584

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

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

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

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

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

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

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

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

• この更新プログラムのインストール中に、"エラー - FaultType UserAccounts.New のテンプレートが見つかりません" というタイトルのアラートが表示される場合があります。これらのアラートは無視してかまいません。 この更新プログラムのインストールが完了した後、これらのアラートは自動的に閉じられます。
• Azure Stack の更新をお客様の OEM から適用した場合は、Azure Stack 管理者ポータルに **利用可能な更新プログラムがあります** という通知が表示されないことがあります。 Microsoft Update をインストールするには、こちらの「Azure Stack で更新を適用する」 (../azure-stack-apply-updates.md) に記載されている手順を使用して、手動でダウンロードおよびインポートしてください。

更新後の手順

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

• 保存データの暗号化キーを取得し、お客様の Azure Stack デプロイの外部に安全に保管します。 キーを取得する方法の手順に関する記事に従ってください。

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

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

ポータル

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

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

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

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

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

正常性と監視

• 以下の詳細情報の正常性コントローラー コンポーネントのアラートが表示されることがあります:

  • アラート #1:

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

  • アラート #2:

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

    いずれのアラートも無視してかまいません。 時間が経つと自動的に閉じられます。

Compute

• 新しい Windows 仮想マシン (VM) を作成するとき、作業を続行するために [設定] ブレードでパブリック受信ポートを選択するよう要求されます。 1811 では、この設定が必須ですが、作用はありません。 この機能は Azure Firewall に依存していますが、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 では使用できないため、デプロイ用に別のオペレーティング システムを選択するか、またはデプロイする前にオペレーターが Marketplace からダウンロードしておいた別の 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 のクォータは 2,048 GiB が割り当てられているものの、管理者ポータルでは値 0 が表示されます。 値は実際のニーズに基づいて増減することができ、新しく設定したクォータ値が 2,048 GiB の既定値をオーバーライドします。
  • クォータ値を 0 に更新することは、2,048 GiB の既定値と同じことになります。 回避策として、クォータ値を 1 に設定します。

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

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

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

ネットワーク

• [ネットワーク] で、[Create VPN Gateway]\(VPN ゲートウェイの作成\) をクリックして VPN 接続を設定する場合、VPN の種類として [ポリシー ベース] が表示されます。 このオプションを選択しないでください。 Azure Stack では [ルート ベース] オプションのみがサポートされています。

• Azure Stack では、IP アドレスごとに 1 つの "ローカル ネットワーク ゲートウェイ" がサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると拒否されます。

• 自動の DNS サーバー設定を使用して作成された仮想ネットワークでは、カスタム DNS サーバーへの変更が失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• Azure Stack の "シークレット ローテーション" 中は、2 分から 5 分、パブリック IP アドレスが到達不能になる期間があります。

• テナントが S2S VPN トンネルを使用して仮想マシンにアクセスするシナリオでは、ゲートウェイが既に作成された後でオンプレミスのサブネットがローカル ネットワーク ゲートウェイに追加された場合、接続しようとしても失敗するシナリオが発生する可能性があります。

• 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 アドレスは変更されます。

• ポータルの [Networking Properties]\(ネットワーク プロパティ\) ブレードに、[有効なセキュリティ規則] のリンクがネットワーク アダプターごとに存在します。 このリンクを選択すると、新しいブレードが開き、Not Found. というエラー メッセージが表示されます。このエラーが発生する理由は、Azure Stack がまだ有効なセキュリティ規則をサポートしていないためです。

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

  • Internet

  • VirtualNetwork

  • AzureLoadBalancer

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

• New-AzureRmIpSecPolicy PowerShell コマンドレットの DHGroup パラメーターでは、DHGroup24 設定がサポートされません。

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

Infrastructure Backup

• 自動バックアップを有効にした後、スケジューラ サービスが予期せず無効状態になります。 バックアップ コントローラー サービスによって、自動バックアップが無効であることが検出され、管理者ポータルに警告が生成されます。 この警告は、自動バックアップが無効になっていると発生する可能性があります。
  • 原因: この問題は、スケジューラの構成が失われるサービスのバグが原因です。 このバグによって、保存場所、ユーザー名、パスワード、暗号化キーが変わることはありません。
  • 修復: この問題を軽減するには、インフラストラクチャ バックアップ リソース プロバイダーの [バックアップ コントローラーの設定] ブレードを開き、[自動バックアップを有効にする] を選択 します。 必要な頻度と保持期間を設定してください。
  • 発生回数: 低

App Service

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

Syslog

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

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

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

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

次のステップ

• Azure Stack 統合システムのサービス ポリシーについて、およびサポートを受けられる状態にシステムを維持するために必要な作業について確認するには、「Azure Stack サービス ポリシー」を参照してください。
• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。
• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「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 インフラストラクチャに関連する監査ログ、アラート、およびセキュリティ ログを、Azure Stack の外部にある Syslog サーバーまたはセキュリティ情報イベント管理 (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 ネットワークからバックアップ ストレージの場所にアクセスできることを確認する必要があります。

共通脆弱性識別子

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

• ADV180022
• CVE-2018-0965
• CVE-2018-8271
• CVE-2018-8320
• CVE-2018-8330
• CVE-2018-8332
• CVE-2018-8333
• CVE-2018-8335
• CVE-2018-8392
• CVE-2018-8393
• CVE-2018-8410
• CVE-2018-8411
• CVE-2018-8413
• CVE-2018-8419
• CVE-2018-8420
• CVE-2018-8423
• CVE-2018-8424
• CVE-2018-8433
• CVE-2018-8434
• CVE-2018-8435
• CVE-2018-8438
• CVE-2018-8439
• CVE-2018-8440
• CVE-2018-8442
• CVE-2018-8443
• CVE-2018-8446
• CVE-2018-8449
• CVE-2018-8453
• CVE-2018-8455
• CVE-2018-8462
• CVE-2018-8468
• CVE-2018-8472
• CVE-2018-8475
• CVE-2018-8481
• CVE-2018-8482
• CVE-2018-8484
• CVE-2018-8486
• CVE-2018-8489
• CVE-2018-8490
• CVE-2018-8492
• CVE-2018-8493
• CVE-2018-8494
• CVE-2018-8495
• CVE-2018-8497

これらの脆弱性の詳細については、上記のリンクをクリックするか、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 での更新プログラムの管理概要」を参照してください。

• Azure Stack の更新を OEM から適用した場合は、Azure Stack の管理者ポータルに "利用可能な更新プログラムがあります" の通知が表示されないことがあります。 Microsoft Update をインストールするには、こちらの「Azure Stack で更新を適用する」に記載されている手順を使用して、手動でダウンロードおよびインポートしてください。

更新後の手順

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

• KB 4481548 - Azure Stack 修正プログラム Azure Stack 修正プログラム 1.1809.12.114

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

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

ポータル

• Azure Stack のテクニカル ドキュメントは、最新のリリースについて説明しています。 リリースごとにポータルが変更されるため、Azure Stack ポータルを使用した場合の動作と、ドキュメントに示されている内容が異なる場合があります。

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

• 管理ポータルとユーザー ポータルの両方で、ポータルの設定をクリックした後、[すべての設定とプライベート ダッシュボードを削除] を選んでも、想定どおりに機能しません。 エラー通知が表示されます。

• 管理ポータルとユーザー ポータルの両方で、[すべてのサービス] の下に、資産 [DDoS protection プラン] が表示されますが、これは正しくありません。 これは Azure Stack でご利用になれません。 これを作成しようとすると、ポータルが Marketplace アイテムを作成できなかったというエラーが表示されます。

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

• Azure Stack の管理ポータルまたはユーザー ポータルへのサインインに使用したアカウントが、[識別されないユーザー] と表示されます。 このメッセージは、アカウントに名と姓がどちらも指定されていない場合に表示されます。 この問題を回避するには、ユーザー アカウントを編集して、名または姓のどちらかを指定してください。 その後、いったんサインアウトし、ポータルにもう一度サインインする必要があります。

• ポータルを使用して仮想マシン スケール セット (VMSS) を作成するとき、Internet Explorer を使用すると [インスタンス サイズ] ドロップダウンが正しく読み込まれません。 この問題を回避するには、ポータルを使用して VMSS を作成するときに別のブラウザーをご使用ください。

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

• このバージョンを実行する新しい Azure Stack 環境をインストールすると、「アクティブ化が必要」を示すアラートが表示されない場合があります。 マーケットプレース シンジケーションを使用するには、アクティブ化する必要があります。

• バージョン 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 オペレーターで、メモリ不足のアラートを受信し、テナント仮想マシンがファブリック 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 サイズを選択するときに、[米国ドル/月] 列に [利用不可] のメッセージが表示されます。 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 のクォータは 2,048 GiB が割り当てられているものの、管理者ポータルでは値 0 が表示されます。 値は実際のニーズに基づいて増減することができ、新しく設定したクォータ値が 2,048 GiB の既定値をオーバーライドします。
  • クォータ値を 0 に更新することは、2,048 GiB の既定値と同じことになります。 回避策として、クォータ値を 1 に設定します。

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

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

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

ネットワーク

• [ネットワーク] で、[Create VPN Gateway]\(VPN ゲートウェイの作成\) をクリックして VPN 接続を設定する場合、VPN の種類として [ポリシー ベース] が表示されます。 このオプションを選択しないでください。 Azure Stack では [ルート ベース] オプションのみがサポートされています。

• Azure Stack では、IP アドレスごとに 1 つの "ローカル ネットワーク ゲートウェイ" がサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• "自動" の DNS サーバー設定を使用して作成した仮想ネットワークで、カスタム DNS サーバーに変更すると失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• Azure Stack の "シークレット ローテーション" 中は、2 ～ 5 分間、Public IP Addresses に到達できない期間があります。

• テナントが S2S VPN トンネルを使用して仮想マシンにアクセスするシナリオでは、ゲートウェイが既に作成された後でオンプレミスのサブネットがローカル ネットワーク ゲートウェイに追加された場合、接続しようとしても失敗するシナリオが発生する可能性があります。

App Service

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

使用方法

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

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

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

次のステップ

• Azure Stack 統合システムのサービス ポリシーについて、およびサポートを受けられる状態にシステムを維持するために必要な作業について確認するには、「Azure Stack サービス ポリシー」を参照してください。
• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。
• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「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 Monitor 上の Azure Stack では、ほとんどのサービスに対して標準となるインフラストラクチャのメトリックおよびログを提供します。 詳細については、「Azure Stack 上の Azure Monitor」を参照してください。

• 拡張機能ホストのための準備。 拡張機能ホストを使用することで、必要とされる TCP/IP ポートの数を減らして Azure Stack のセキュリティ保護を支援できます。 1808 の更新では、拡張機能ホストに対応するよう Azure Stack を準備できます。 詳細については、「Azure Stack 用の拡張機能ホストの準備」を参照してください。

• 仮想マシン スケール セット用のギャラリー アイテムが組み込まれました。 仮想マシン スケール セットのギャラリー項目がユーザーおよび管理者のポータルで利用可能になりました。ダウンロードする必要はありません。 1808 にアップグレードする場合は、アップグレードの完了時に利用可能になります。

• 仮想マシン スケール セットのスケーリング。 ポータルを使用して、仮想マシン スケール セットをスケールすることができます (VMSS)。

• カスタムの IPSec/IKE ポリシー構成のサポート。Azure Stack 内の VPN ゲートウェイ用です。

• Kubernetes Marketplace アイテム。 Kubernetes クラスターのデプロイに Kubernetes Marketplace アイテムを使用できるようになりました。 ユーザーは Kubernetes アイテムを選択し、いくつかのパラメーターに値を入力すれば、Kubernetes クラスターを Azure Stack にデプロイできます。 このテンプレートの目的は、ユーザーが少ないステップで開発/テスト用の Kubernetes デプロイをセットアップできるように簡素化することです。

• Blockchain テンプレート。 Azure Stack で Ethereum コンソーシアムのデプロイを実行できるようになりました。 Azure Stack クイック スタート テンプレートに 3 つの新しいテンプレートが追加されています。 これらを利用すると、ユーザーは、Azure と Ethereum の最小限の知識があれば、マルチメンバー コンソーシアム Ethereum ネットワークをデプロイして構成できます。 このテンプレートの目的は、ユーザーが少ないステップで開発/テスト用のブロックチェーン デプロイをセットアップできるように簡素化することです。

• API バージョン プロファイル 2017-03-09-profile が 2018-03-01-hybrid に更新されました。 API プロファイルでは、Azure リソース プロバイダーと Azure REST エンドポイントの API バージョンが指定されます。 プロファイルの詳細については、「Azure Stack での API バージョンのプロファイルの管理」を参照してください。

修正された問題

• ポータルで可用性セットを作成すると 1 の障害ドメインと更新ドメインがセットに含められるという問題が修正されました。

• 仮想マシン スケール セットのスケーリング設定がポータルで使用できるようになりました。

• デプロイの VM サイズを選択するときに F シリーズの一部の仮想マシン サイズが表示されないという問題が解決されました。

• 仮想マシンの作成時のパフォーマンスが向上し、基になるストレージの使用がさらに最適化されました。

• さまざまな修正 - パフォーマンス、安定性、セキュリティ、Azure Stack で使用されるオペレーティング システムが修正されました。

変更点

• クイック スタート チュートリアル。ユーザー ポータルのダッシュボードにあるこのチュートリアルに、オンラインの Azure Stack ドキュメントにある関連する記事へのリンクが掲載されています。

• [その他のサービス] が [すべてのサービス] に置き換えられました (Azure Stack の管理者ポータルとユーザー ポータル)。 [すべてのサービス] は、Azure portal の場合と同じように Azure Stack ポータル内を移動するために使用できるようになりました。

• [+ 新規] が [+ リソースの作成] に置き換えられました (Azure Stack の管理ポータルとユーザー ポータル)。 [+ リソースの作成] は、Azure portal の場合と同じように Azure Stack ポータル内を移動するために使用できるようになりました。

• Basic A の仮想マシン サイズは、ポータルを介して仮想マシン スケール セット (VMSS) を作成するものとしては廃止されました。 このサイズの VMSS を作成するには、PowerShell またはテンプレートをご使用ください。

共通脆弱性識別子

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

• CVE-2018-0952
• CVE-2018-8200
• CVE-2018-8204
• CVE-2018-8253
• CVE-2018-8339
• CVE-2018-8340
• CVE-2018-8341
• CVE-2018-8343
• CVE-2018-8344
• CVE-2018-8345
• CVE-2018-8347
• CVE-2018-8348
• CVE-2018-8349
• CVE-2018-8394
• CVE-2018-8398
• CVE-2018-8401
• CVE-2018-8404
• CVE-2018-8405
• CVE-2018-8406

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

この更新プログラムには、L1 Terminal Fault (L1TF) と呼ばれる投機的実行サイド チャネルの脆弱性に対する軽減策も含まれています (Microsoft セキュリティ アドバイザリ ADV180018 に説明があります)。

前提条件

• 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

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

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

ポータル

• Azure Stack のテクニカル ドキュメントは、最新のリリースについて説明しています。 リリースごとにポータルが変更されるため、Azure Stack ポータルを使用した場合の動作と、ドキュメントに示されている内容が異なる場合があります。

• ポータルに空のダッシュボードが表示されることがあります。 ダッシュボードを回復するには、[ダッシュボードの編集] をクリックし、右クリックして、[既定の状態にリセット] を選んでください。

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

• 管理ポータルとユーザー ポータルの両方で、ポータルの設定をクリックした後、[すべての設定とプライベート ダッシュボードを削除] を選んでも、想定どおりに機能しません。 エラー通知が表示されます。

• 管理ポータルとユーザー ポータルの両方で、[すべてのサービス] の下に、資産 [DDoS protection プラン] が表示されますが、これは正しくありません。 実際には、これは Azure Stack でご利用になれません。 これを作成しようとすると、ポータルが Marketplace アイテムを作成できなかったというエラーが表示されます。

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

• Azure Stack の管理ポータルまたはユーザー ポータルへのサインインに使用したアカウントが、[識別されないユーザー] と表示されます。 これは、アカウントに名と姓がどちらも指定されていない場合に発生します。 この問題を回避するには、ユーザー アカウントを編集して、名または姓のどちらかを指定してください。 その後、いったんサインアウトし、ポータルにもう一度サインインする必要があります。

• ポータルを使用して仮想マシン スケール セット (VMSS) を作成するとき、Internet Explorer を使用すると [インスタンス サイズ] ドロップダウンが正しく読み込まれません。 この問題を回避するには、ポータルを使用して VMSS を作成するときに別のブラウザーをご使用ください。

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

• このバージョンを実行する新しい Azure Stack 環境をインストールすると、「アクティブ化が必要」を示すアラートが表示されない場合があります。 マーケットプレース シンジケーションを使用するには、アクティブ化する必要があります。

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

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

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

正常性と監視

• 以下の詳細情報の正常性コントローラー コンポーネントのアラートが表示されることがあります:

  アラート #1:

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

  アラート #2:

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

  どちらのアラートも無視しても問題ありません。時間が経過すると、自動的に閉じられます。

• 以下の詳細情報を含む Storage コンポーネントのアラートが表示される場合があります:

  • 名前: Storage サービスの内部通信エラー

  • 重大度: 緊急

  • コンポーネント: Storage

  • 説明: 次のノードに要求を送信するときに Storage サービスの内部通信エラーが発生しました。

    アラートは無視しても差し支えありませんが、手動で閉じる必要があります。

• Azure Stack オペレーターで、メモリ不足のアラートを受信し、テナント仮想マシンがファブリック VM の作成エラーでデプロイできなかった場合、Azure Stack スタンプに使用できるメモリが不足している可能性があります。 ワークロードに使用できる容量の詳細については、Azure Stack Capacity Planner に関するページを参照してください。

Compute

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

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

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

• Add-AzsPlatformImage コマンドレットを使用する場合は、ディスクのアップロード先のストレージ アカウント URI として -OsUri パラメーターを使用する必要があります。 ディスクのローカル パスを使用すると、コマンドレットは次のエラーで失敗します。 実行時間の長い操作は失敗し、状態は Failed です。

• 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 を選択するか、またはデプロイする前にオペレーターが Marketplace からダウンロードしておいた別の 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 使用率グラフを表示するには、メトリック ブレードに移動して、サポートされているすべての Windows VM ゲスト メトリックを表示します。

ネットワーク

• [ネットワーク] で、[Create VPN Gateway]\(VPN ゲートウェイの作成\) をクリックして VPN 接続を設定する場合、VPN の種類として [ポリシー ベース] が表示されます。 このオプションを選択しないでください。 Azure Stack では [ルート ベース] オプションのみがサポートされています。

• Azure Stack では、IP アドレスごとに 1 つの "ローカル ネットワーク ゲートウェイ" がサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• "自動" の DNS サーバー設定を使用して作成した仮想ネットワークで、カスタム DNS サーバーに変更すると失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• 動的割り当てメソッドを使用してデプロイされているパブリック IP は、停止 - 割り当て解除が発行された後も保持される保証はありません。

• Azure Stack の "シークレット ローテーション" 中は、2 ～ 5 分間、Public IP Addresses に到達できない期間があります。

• テナントが S2S VPN トンネルを使用して仮想マシンにアクセスするシナリオでは、ゲートウェイが既に作成された後でオンプレミスのサブネットがローカル ネットワーク ゲートウェイに追加された場合、接続しようとしても失敗するシナリオが発生する可能性があります。

App Service

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

• インフラストラクチャ (worker、管理、フロントエンド ロール) をスケールアウトするには、コンピューティングのリリース ノートの説明に従って PowerShell を使用する必要があります。

使用方法

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

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

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

次のステップ

• Azure Stack 統合システムのサービス ポリシーについて、およびサポートを受けられる状態にシステムを維持するために必要な作業について確認するには、「Azure Stack サービス ポリシー」を参照してください。
• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。
• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「Azure Stack で更新を適用する」を参照してください。

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

適用対象: Azure Stack 統合システム

この記事では、1807 更新プログラム パッケージの内容について説明します。 このバージョンの Azure Stack の既知の問題、機能強化、修正された内容のほか、更新プログラムをダウンロードする場所について取り上げます。 既知の問題は、更新プロセスに直接関係する問題と、ビルド (インストール後) に関する問題に分けられています。

ビルドのリファレンス

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

新機能

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

• 定義済みのスケジュールでバックアップを開始 - アプライアンスとしての Azure Stack に、インフラストラクチャ バックアップを自動で定期的にトリガーする機能が追加され、人の介入が不要になりました。 また、定義されている保有期間を超えたバックアップについては、外部共有が自動的にクリーンアップされます。 詳細については、「PowerShell で Azure Stack のバックアップを有効にする」をご覧ください。

• 合計バックアップ時間にデータ転送時間が追加されました。 詳細については、「PowerShell で Azure Stack のバックアップを有効にする」をご覧ください。

• 外部バックアップ容量に、外部共有の正確な容量が表示されるようになりました。 (以前は、これは 10 GB のハード コードでした)。)詳細については、「PowerShell を使用して Azure Stack のバックアップを有効にする」を参照してください。

• 容量を拡張するには、新たにスケール ユニット ノードを追加します。

• Azure Resource Manager テンプレートで条件要素がサポートされるようになりました - 条件を使用して Azure Resource Manger テンプレートでリソースをデプロイできるようになりました。 パラメーター値の有無の評価などの条件に基づいてリソースをデプロイするようにテンプレートを設計することができます。 テンプレートを条件として使用する方法については、Azure ドキュメントの「リソースを条件付きでデプロイする」および「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 インフラストラクチャに関連する監査とログを、Azure Stack 外部の Syslog サーバーまたはセキュリティ情報イベント管理 (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 リセラー モデルとの整合性を高めるため、委任されたプロバイダー モデルは単純化されました。委任されたプロバイダーは他の委任されたプロバイダーを作成することができなくなって、本質的にモデルが平坦化され、委任されたプロバイダーの機能を単一レベルで利用できるようになりました。 新しいモデルへの切り替えとサブスクリプションの管理を可能にするために、同じディレクトリ テナントに属する新規または既存の委任されたプロバイダー サブスクリプション間でユーザーサブスクリプションを移動できるようになりました。 また、既定プロバイダー サブスクリプションに属しているユーザーサブスクリプションも、同じディレクトリ テナント内にある委任されたプロバイダー サブスクリプションに移動できます。 詳細については、「Azure Stack でのプランの委任」を参照してください。

• Azure Marketplace からダウンロードしたイメージを使用して作成された VM の VM 作成時間が改善されました。

• Azure Stack Capacity Planner のユーザビリティの強化。 Azure Stack Capacity Planner では、ソリューション SKU を定義するときに S2D キャッシュと S2D 容量を入力できるよう、シンプルな機能が用意されました。 1000 VM の制限が削除されました。

修正された問題

• 更新プロセスをより信頼できるものにするために、さまざまな改善が行われました。 さらに、基になるインフラストラクチャに修正が加えられました。これにより、更新中に発生する可能性のあるワークロードのダウンタイムが最小限に抑えられます。

• 変更したクォータ制限が既存のサブスクリプションに適用されない問題を修正しました。 今後は、ユーザーのサブスクリプションに関連付けられているオファーとプランについて、そこに含まれるネットワーク リソースのクォータ制限を引き上げると、新しいサブスクリプションだけでなく既存のサブスクリプションにも新しい制限が適用されます。

• UTC+N タイム ゾーンでデプロイされているシステムをアクティビティ ログから検索するクエリが問題なく実行できるようになりました。

• バックアップ構成パラメーター (パス/ユーザー名/パスワード/暗号化キー) の事前確認で、バックアップ構成に間違った設定が適用される問題を修正しました。 (以前は、バックアップに間違った設定が適用され、トリガーされた時点でバックアップが失敗していました。)

• 外部共有から手動でバックアップを削除したときにバックアップ リストが最新の情報に更新されるようになりました。

• このバージョンに更新すると、AD FS を使ってデプロイするときに、既定のプロバイダー サブスクリプションの既定の所有者が、ビルトインの CloudAdmin ユーザーにリセットされていましたが、この問題は修正されました。

• データセンターの統合を設定する際、今後は、Azure のファイル共有場所の AD FS メタデータ ファイルにはアクセスしません。 詳細については、「フェデレーション メタデータ ファイルを指定して AD FS の統合を設定する」を参照してください。

• ネットワーク インターフェイスまたはロード バランサーに割り当てられている既存のパブリック IP アドレスを新しいネットワーク インターフェイスまたは Azure 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 です。

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

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

ポータル

• Azure Stack のテクニカル ドキュメントは、最新のリリースについて説明しています。 リリースごとにポータルが変更されるため、Azure Stack ポータルを使用した場合の動作と、ドキュメントに示されている内容が異なる場合があります。

• 管理ポータルのドロップダウン リストから新しいサポート要求を開く機能は使用できません。 代わりに、Azure Stack 統合システムでは、リンク https://aka.ms/newsupportrequest をご使用ください。

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

• このバージョンを実行する新しい Azure Stack 環境をインストールすると、「アクティブ化が必要」を示すアラートが表示されない場合があります。 マーケットプレース シンジケーションを使用するには、アクティブ化する必要があります。

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

• 管理ポータルとユーザー ポータルの下部に水平スクロールバーが表示されない可能性があります。 水平スクロールバーにアクセスできない場合は、ポータルの左上にある階層リンク リストから表示するブレードの名前を選択して、階層リンクを使用してポータル内の前のブレードに移動します。

• 管理ポータルでコンピューティング リソースやストレージ リソースを表示できない場合があります。 この問題の原因は、更新プログラムのインストール中にエラーが発生し、更新が正常に行われたことが誤って報告されたためです。 この問題が発生した場合は、Microsoft カスタマー サポート サービスにお問い合わせください。

• ポータルに空のダッシュボードが表示されることがあります。 ダッシュボードを復元するには、ポータルの右上にある歯車アイコンを選択し、[既定の設定に戻す] を選択します。

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

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

正常性と監視

• 以下の詳細情報の正常性コントローラー コンポーネントのアラートが表示されることがあります:

  アラート #1:

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

  アラート #2:

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

  どちらのアラートも無視しても問題ありません。時間が経過すると、自動的に閉じられます。

• 以下の詳細情報を含む Storage コンポーネントのアラートが表示される場合があります:

  • 名前: Storage サービスの内部通信エラー

  • 重大度: 緊急

  • コンポーネント: Storage

  • 説明: 次のノードに要求を送信するときに Storage サービスの内部通信エラーが発生しました。

    アラートは無視しても差し支えありませんが、手動で閉じる必要があります。

• Azure Stack オペレーターで、メモリ不足のアラートを受信し、テナント仮想マシンがファブリック 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 テンプレート: テンプレートを使用する際に、テンプレートの vmSize を使用する VM サイズと同じに設定します。 たとえば、F32s_v2 サイズを使用する VM をデプロイするには、次のように入力します。

        "properties": {
        "hardwareProfile": {
                "vmSize": "Standard_F32s_v2"
        },
    

  • Azure CLI:az vm create コマンドを使用して、--size "Standard_F32s_v2" と同様に VM サイズをパラメーターとして指定できます。

  • PowerShell: Powershell では、-VMSize "Standard_F32s_v2" と同様に VM サイズを指定するパラメーターとともに New-AzureRMVMConfig を使用することができます。

• 仮想マシン スケール セットのスケーリング設定は、ポータルで使用できません。 回避策として、Azure PowerShell を使用できます。 PowerShell のバージョンの違いにより、-VMScaleSetName パラメーターの代わりに -Name を使用する必要があります。

• ポータルで [新規]>[コンピューティング]>[可用性セット] に移動して可用性セットを作成した場合、障害ドメインと更新ドメインが 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 使用率グラフなどのメトリック データを表示するには、[メトリック] ブレードに移動して、サポートされているすべての Windows VM ゲスト メトリックを表示します。

ネットワーク

• [ネットワーク] で、[Create VPN Gateway]\(VPN ゲートウェイの作成\) をクリックして VPN 接続を設定する場合、VPN の種類として [ポリシー ベース] が表示されます。 このオプションを選択しないでください。 Azure Stack では [ルート ベース] オプションのみがサポートされています。

• Azure Stack では、IP アドレスごとに 1 つの "ローカル ネットワーク ゲートウェイ" がサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• "自動" の DNS サーバー設定を使用して作成した仮想ネットワークで、カスタム DNS サーバーに変更すると失敗します。 更新した設定は、その Vnet 内の VM にプッシュされません。

• 動的割り当てメソッドを使用してデプロイされているパブリック IP は、停止 - 割り当て解除が発行された後も保持される保証はありません。

• Azure Stack の "シークレット ローテーション" 中は、2 ～ 5 分間、Public IP Addresses に到達できない期間があります。

• テナントが S2S VPN トンネルを使用して仮想マシンにアクセスするシナリオでは、ゲートウェイが既に作成された後でオンプレミスのサブネットがローカル ネットワーク ゲートウェイに追加された場合、接続しようとしても失敗するシナリオが発生する可能性があります。

SQL および MySQL

• SQL と MySQL リソース プロバイダーの SKU を作成する場合、[ファミリ] 名では、スペースやピリオドなどの特殊文字はサポートされていません。

• SQL または MySQL をホストするサーバー上に項目を作成できるのは、リソース プロバイダーのみです。 リソース プロバイダー以外がホスト サーバー上に項目を作成すると、不一致状態になる可能性があります。

App Service

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

• インフラストラクチャ (worker、管理、フロントエンド ロール) をスケールアウトするには、コンピューティングのリリース ノートの説明に従って PowerShell を使用する必要があります。

• 現在、App Service は、既定のプロバイダー サブスクリプションにのみデプロイできます。

使用方法

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

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

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

次のステップ

• Azure Stack 統合システムのサービス ポリシーについて、およびサポートを受けられる状態にシステムを維持するために必要な作業について確認するには、「Azure Stack サービス ポリシー」を参照してください。
• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。
• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「Azure Stack で更新を適用する」を参照してください。

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

適用対象: Azure Stack 統合システム

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

ビルドのリファレンス

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

新機能

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

• Azure Stack には、プレビュー機能として Syslog クライアントが追加されました。 このクライアントを使用すると、Azure Stack インフラストラクチャに関連する監査ログとセキュリティログを、Azure Stack の外部にある Syslog サーバーまたはセキュリティ情報イベント管理 (SIEM) ソフトウェアに転送できます。 現在、Syslog クライアントは、既定のポート 514 を介した認証されていない UDP 接続のみをサポートしています。 各 Syslog メッセージのペイロードは、共通イベント形式 (CEF) です。

  Syslog クライアントを構成するには、特権エンドポイントで公開されている Set-SyslogServer コマンドレットを使用します。

  このプレビューでは、次の 3 つのアラートが表示されることがあります。 Azure Stack でこれらのアラートが表示される場合、アラートには説明と修復のガイダンスが記載されます。

  • タイトル: コードの整合性のオフ
  • タイトル: 監査モードのコードの整合性
  • タイトル: ユーザー アカウントの作成

  この機能はプレビュー段階ですが、運用環境では使用しないでください。

修正された問題

• 管理ポータル内のドロップダウンから新しいサポート リクエストを開くことができない問題を修正しました。 このオプションは意図したとおりに機能するようになりました。

• さまざまな修正 - パフォーマンス、安定性、セキュリティ、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。

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

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

ポータル

• Azure Stack のテクニカル ドキュメントは、最新のリリースについて説明しています。 リリースごとにポータルが変更されるため、Azure Stack ポータルを使用した場合の動作と、ドキュメントに示されている内容が異なる場合があります。

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

• このバージョンの Azure Stack では、OEM Extension パッケージを使用してドライバーの更新プログラムを適用することはできません。 この問題の回避策はありません。

• 管理ポータルまたはユーザー ポータルでストレージ アカウントの [概要] を選択すると、[基本] ウィンドウの情報が表示されません。 [基本] ウィンドウには、リソース グループ、リージョン、サブスクリプション ID などのアカウントに関する情報が表示されます。 [概要] のその他のオプションにアクセスできます。たとえば、[サービス]、[監視]、[Explorer で開く]、[ストレージ アカウントの削除] のオプションです。

  利用不可の情報を表示するには、Get-azureRMstorageaccount PowerShell コマンドレットを使用します。

• 管理ポータルまたはユーザー ポータルでストレージ アカウントに [タグ] を選択したときに、情報が読み込まれず、表示されません。

  利用不可の情報を表示するには、Get-AzureRmTag PowerShell コマンドレットを使用します。

• Azure Stack ID システムに AD FS を使用し、このバージョンの Azure Stack に更新したとき、既定のプロバイダー サブスクリプションの既定の所有者は､組み込みの CloudAdmin ユーザーにリセットされます。
  回避策: この更新プログラムのインストール後にこの問題を解決するには、「Azure Stack で自動化をトリガーしてクレーム プロバイダー信頼を構成する」の手順 3 を使用して、既定のプロバイダー サブスクリプションの所有者をリセットします。

• 一部の管理サブスクリプションの種類は利用できません。 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 オペレーターで、メモリ不足のアラートを受信し、テナント仮想マシンがファブリック 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 テンプレート: テンプレートを使用する際に、テンプレートの vmSize を使用する VM サイズと同じに設定します。 たとえば、F32s_v2 サイズを使用する VM をデプロイするには、次のように入力します。

        "properties": {
        "hardwareProfile": {
                "vmSize": "Standard_F32s_v2"
        },
    

  • Azure CLI:az vm create コマンドを使用して、--size "Standard_F32s_v2" と同様に VM サイズをパラメーターとして指定できます。

  • PowerShell: Powershell では、-VMSize "Standard_F32s_v2" と同様に VM サイズを指定するパラメーターとともに New-AzureRMVMConfig を使用することができます。

• 仮想マシン スケール セットのスケーリング設定は、ポータルで使用できません。 回避策として、Azure PowerShell を使用できます。 PowerShell のバージョンの違いにより、-VMScaleSetName パラメーターの代わりに -Name を使用する必要があります。

• ポータルで [新規]>[コンピューティング]>[可用性セット] に移動して可用性セットを作成した場合、障害ドメインと更新ドメインが 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 を使用します。

• [ネットワーク] で、[Create VPN Gateway]\(VPN ゲートウェイの作成\) をクリックして VPN 接続を設定する場合、VPN の種類として [ポリシー ベース] が表示されます。 このオプションを選択しないでください。 Azure Stack では [ルート ベース] オプションのみがサポートされています。

• VM を作成してパブリック IP アドレスに関連付けた後は、IP アドレスからその VM の関連付けを解除することはできません。 関連付けの解除は機能したように見えますが、以前に割り当てられたパブリック IP アドレスは、元の VM に関連付けられたままになります。

  現時点では、作成した新しい VM には新しいパブリック IP アドレスのみを使用する必要があります。

  この動作は、IP アドレスを新しい VM に 再割り当てした (一般に VIP スワップと呼ばれます) 場合でも行われます。 以降のこの IP アドレスによるすべての接続の試みは、新しい VM ではなく、元の VM に接続する結果になります。

• テナントのサブスクリプションに関連付けられているオファーとプランの一部であるネットワーク リソースのクォータ制限を引き上げた場合、新しい制限がそのサブスクリプションに適用されません。 ただし、クォータを増加した後に作成した新しいサブスクリプションには新しい制限が適用されます。

  この問題を回避するには、プランがサブスクリプションに既に関連付けられている場合は、アドオン プランを使用して、ネットワーク クォータを増やします。 詳細については、アドオン プランを利用できるようにする方法を参照してください。

• DNS ゾーン リソースまたはそれに関連付けられたルート テーブル リソースがあるサブスクリプションを削除することができません。 サブスクリプションを正常に削除するには、まずテナント サブスクリプションから DNS ゾーンとルート テーブルのリソースを削除する必要があります。

• Azure Stack では、IP アドレスごとに 1 つの "ローカル ネットワーク ゲートウェイ" がサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• "自動" の DNS サーバー設定を使用して作成した仮想ネットワークで、カスタム 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 更新プログラム パッケージは、ここからダウンロードできます。

関連項目

• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。
• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「Azure Stack で更新を適用する」を参照してください。

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

適用対象: Azure Stack 統合システム

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

ビルドのリファレンス

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

新機能

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

• Visual Studio で、接続されていない Azure Stack を AD FS を利用してデプロイ。 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 統合システムの新しいデプロイと、Azure Stack Development Kit バージョン 1804 以降のインストールでは、3 種類すべてのサブスクリプションにアクセスできます。

  これらの新しい種類のサブスクリプションは、Default Provider サブスクリプションを保護し、SQL Hosting サーバーなど、共有リソースのデプロイを簡易化するための大規模な変更の一環です。 Azure Stack の将来の更新でこの大規模な変更をさらに進めるとき、これらの新しい種類のサブスクリプションでデプロイされたリソースが失われることがあります。

  現在表示されている 3 種類のサブスクリプションは次のとおりです。

  • Default Provider サブスクリプション: 引き続き、この種類のサブスクリプションを使用してください。
  • Metering サブスクリプション: この種類のサブスクリプションは使用しないでください。
  • Consumption サブスクリプション: この種類のサブスクリプションは使用しないでください。

修正された問題

• 管理ポータルで、情報を表示する前に [更新] タイルを更新する必要がなくなりました。

• これで、管理ポータルを使用して、BLOB サービス、Table service、Queue サービスのストレージ メトリックを編集できるようになりました。

• [ネットワーク] で [接続] をクリックして VPN 接続を設定すると、サイト間 (IPsec) が使用可能な唯一のオプションになりました。

• さまざまな修正 - パフォーマンス、安定性、セキュリティ、Azure Stack で使用されるオペレーティング システムが修正されました。

この更新に合わせた追加のリリース

次が利用できるようになりましたが、Azure Stack 更新プログラム 1804 は必要ありません。

• Microsoft Azure Stack System Center Operations Manager Monitoring Pack の更新プログラム。 Microsoft System Center Operations Manager Monitoring Pack for Azure Stack の新しいバージョン (1.0.3.0) がダウンロードできるようになりました。 このバージョンでは、接続済みの Azure Stack のデプロイを追加するときに、サービス プリンシパルを使用できます。 このバージョンでは、Operations Manager 内から直接修復アクションを実行できるようにする Update Management エクスペリエンスの機能もあります。 リソース プロバイダー、スケール単位、スケール ユニットのノードを表示する新しいダッシュボードもあります。

• 新しい Azure Stack 管理の PowerShell バージョン 1.3.0。 Azure Stack PowerShell 1.3.0 がインストールに使用できるようになりました。 このバージョンでは、Azure Stack を管理するためにすべての管理リソース プロバイダーにコマンドを提供します。 このリリースにより、Azure Stack ツールの GitHub リポジトリから一部のコンテンツが廃止される予定です。

  インストールの詳細については、Azure Stack Module 1.3.0 の指示またはヘルプ コンテンツに従ってください。

• Azure Stack API Rest リファレンスの初回リリース。 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 のインストール後について次の既知の問題があります。

ポータル

• Azure Stack のテクニカル ドキュメントは、最新のリリースについて説明しています。 リリースごとにポータルが変更されるため、Azure Stack ポータルを使用した場合の動作と、ドキュメントに示されている内容が異なる場合があります。

• このバージョンの Azure Stack では、OEM Extension パッケージを使用してドライバーの更新プログラムを適用することはできません。 この問題の回避策はありません。

• このバージョンの Azure Stack をインストールまたは更新した後、管理ポータルで Azure Stack スケール ユニットを表示できない場合があります。
  回避策: PowerShell を使用し、スケール ユニットに関する情報を表示します。 詳細については、Azure Stack Module 1.3.0 のヘルプ コンテンツをご覧ください。

• Azure Stack ID システムに AD FS を使用し、このバージョンの Azure Stack に更新したとき、既定のプロバイダー サブスクリプションの既定の所有者は､組み込みの CloudAdmin ユーザーにリセットされます。
  回避策: この更新プログラムのインストール後にこの問題を解決するには、「Azure Stack で自動化をトリガーしてクレーム プロバイダー信頼を構成する」の手順 3 を使用して、既定のプロバイダー サブスクリプションの所有者をリセットします。

• 一部の管理サブスクリプションの種類は利用できません。 Azure Stack をこのバージョンにアップグレードすると、バージョン 1804 で導入された 2 つのサブスクリプションの種類はコンソールに表示されません。 これは "予期されること" です。 利用不可のサブスクリプションの種類は、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 テンプレート: テンプレートを使用する際に、テンプレートの vmSize を必要な VM サイズと同じに設定します。 たとえば、F32s_v2 サイズを使用する VM をデプロイするには、次を使用します。

        "properties": {
        "hardwareProfile": {
                "vmSize": "Standard_F32s_v2"
        },
    

  • Azure CLI:az vm create コマンドを使用して、--size "Standard_F32s_v2" と同様に VM サイズをパラメーターとして指定できます。

  • PowerShell: Powershell では、-VMSize "Standard_F32s_v2" と同様に VM サイズを指定するパラメーターとともに New-AzureRMVMConfig を使用することができます。

• 仮想マシン スケール セットのスケーリング設定は、ポータルで使用できません。 回避策として、Azure PowerShell を使用できます。 PowerShell のバージョンの違いにより、-VMScaleSetName パラメーターの代わりに -Name を使用する必要があります。

• ポータルで [新規]>[コンピューティング]>[可用性セット] に移動して可用性セットを作成した場合、障害ドメインと更新ドメインが 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 の基本メトリックを有効にした場合も、展開が失敗します。

ネットワーク

• [ネットワーク] で、[Create VPN Gateway]\(VPN ゲートウェイの作成\) をクリックして VPN 接続を設定する場合、VPN の種類として [ポリシー ベース] が表示されます。 このオプションを選択しないでください。 Azure Stack では [ルート ベース] オプションのみがサポートされています。

• VM を作成してパブリック IP アドレスに関連付けた後は、IP アドレスからその VM の関連付けを解除することはできません。 関連付けの解除は機能したように見えますが、以前に割り当てられたパブリック IP アドレスは、元の VM に関連付けられたままになります。

  現時点では、作成した新しい VM には新しいパブリック IP アドレスのみを使用する必要があります。

  この動作は、IP アドレスを新しい VM に 再割り当てした (一般に VIP スワップと呼ばれます) 場合でも行われます。 以降のこの IP アドレスによるすべての接続の試みは、新しい VM ではなく、元々関連付けられていた VM に接続する結果になります。

• テナントのサブスクリプションに関連付けられているオファーとプランの一部であるネットワーク リソースのクォータ制限を引き上げた場合、新しい制限がそのサブスクリプションに適用されません。 ただし、クォータを増加した後に作成した新しいサブスクリプションには新しい制限が適用されます。

  この問題を回避するには、プランがサブスクリプションに既に関連付けられている場合は、アドオン プランを使用して、ネットワーク クォータを増やします。 詳細については、アドオン プランを利用できるようにする方法を参照してください。

• DNS ゾーン リソースまたはそれに関連付けられたルート テーブル リソースがあるサブスクリプションを削除することができません。 サブスクリプションを正常に削除するには、まずテナント サブスクリプションから DNS ゾーンとルート テーブルのリソースを削除する必要があります。

• Azure Stack では、IP アドレスごとに 1 つの "ローカル ネットワーク ゲートウェイ" がサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• "自動" の DNS サーバー設定を使用して作成した仮想ネットワークで、カスタム 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 で導入された新しい Metering サブスクリプションにデプロイされ、既存のデプロイもすべてこの新しいサブスクリプションに統合されます。

使用方法

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

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

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

関連項目

• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。
• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「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 をインストールします。 この修正プログラムで Windows Defender が更新されます。この修正プログラムは 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 シークレットの更新 - (アカウントおよび証明書)。 シークレットの管理に関する詳細については、「Azure Stack でシークレットをローテーションする」をご覧ください。

• HTTP を使用して管理者ポータルとユーザー ポータルにアクセスする場合の、HTTPS への自動ダイレクト。 この機能強化は、Azure Stack の UserVoice フィードバックに基づいて行われたものです。

• Marketplace へのアクセス – Azure portal の場合と同じ方法で、管理者ポータルとユーザー ポータル内から [+新規] オプションを使用して、Azure Stack Marketplace を開けるようになりました。

• Azure Monitor - Azure Stack では、Azure Monitor が管理者ポータルとユーザー ポータルに追加されます。 これには、メトリックおよびアクティビティ ログ用の新しいエクスプローラーが含まれます。 外部ネットワークからこの Azure Monitor にアクセスするには、ファイアウォール構成でポート 13012 を開く必要があります。 Azure Stack で必要なポートの詳細については、「Azure Stack とデータセンターの統合 - エンドポイントの公開」を参照してください。

  この変更の一環として、[More services]\(その他のサービス\) 下では、[監査ログ] が [アクティビティ ログ] と表示されるようになります。 Azure Portal との機能の一貫性が確保できました。

• スパース ファイル - Azure Stack に新しいイメージを追加する場合や、マーケットプレース シンジケーションを介してイメージを追加する場合は、イメージがスパース ファイルに変換されます。 Azure Stack バージョン 1803 を使用する前に追加されたイメージを変換することはできません。 この機能を利用するには、代わりにマーケットプレース シンジケーションを使用して、それらのイメージを再送信する必要があります。

  スパース ファイルは、記憶域スペースの使用を減らして I/O を改善するために使用される、効率的なファイル形式です。 詳細については、Windows Server の「fsutil sparse」をご覧ください。

修正された問題

• 内部負荷分散 (ILB) がバックエンド VM の MAC アドレスを適切に処理するようになりました。これにより、ILB はバックエンド ネットワーク上の Linux インスタンスを使用するときに、バックエンド ネットワークにパケットをドロップします。 ILB は、バックエンド ネットワーク上の Windows インスタンスでは問題なく動作します。

• Azure Stack で IKE ポリシーの設定が Azure とは異なるために、Azure Stack 間の VPN 接続が切断される問題。 SALifetime (時間) と SALiftetime (バイト) の値が Azure と互換性がなかったため、Azure の設定と一致するように 1803 で変更されました。 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-AzureRmVirtualNetworkSubnetConfig コマンドレットを使用して、この情報を表示および管理します。

• 仮想マシンを作成する際、VM サイズ用のサイズを選択したときのメッセージ "価格を表示できません" は表示されなくなりました。

• さまざまな修正 - パフォーマンス、安定性、セキュリティ、Azure Stack で使用されるオペレーティング システムが修正されました。

変更点

• 新しく作成されたオファーの状態を [プライベート] から [パブリック] または [使用停止] に切り替える方法が変更されました。 詳細については、オファ―の作成に関するページをご覧ください。

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

1803 更新プログラムのインストール中に、BLOB サービスと BLOB サービスを使用する内部サービスのダウンタイムが発生する可能性があります。 これには、一部の仮想マシンの操作が含まれます。 このダウン タイムにより、テナントの操作が失敗したり、データにアクセスできないサービスからのアラートが表示されたりする可能性があります。 この問題は、更新プログラムのインストールの完了時に自動的に解決します。

更新後の手順

• 1803 のインストール後、適用可能な修正プログラムがあればインストールします。 詳細については、以下のサポート技術情報とサービス ポリシーに関するページを参照してください。

  • KB 4344115 - Azure Stack 修正プログラム 1.0.180427.15.

• この更新プログラムをインストールしたら、ファイアウォールの設定で必要なポートが開いていることを確認します。 たとえば、この更新プログラムには、監査ログをアクティビティ ログに変更することを含む Azure Monitor が入っています。 この変更によりポート 13012 が使用されるようになったため、開いている必要があります。

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

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

ポータル

• Azure Stack ID システムに AD FS を使用し、このバージョンの Azure Stack に更新したとき、既定のプロバイダー サブスクリプションの既定の所有者は､組み込みの CloudAdmin ユーザーにリセットされます。
  回避策: この更新プログラムのインストール後にこの問題を解決するには、「Azure Stack で自動化をトリガーしてクレーム プロバイダー信頼を構成する」の手順 3 を使用して、既定のプロバイダー サブスクリプションの所有者をリセットします。

• 管理者ポータルのドロップダウン リストから新しいサポート要求を開く機能は使用できません。 代わりに、次のリンクを使用します。

  • 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 のバージョンの違いにより、-VMScaleSetName パラメーターの代わりに -Name を使用する必要があります。

• ポータルで [新規]>[コンピューティング]>[可用性セット] に移動して可用性セットを作成した場合、障害ドメインと更新ドメインが 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 アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• "自動" の DNS サーバー設定を使用して作成した仮想ネットワークで、カスタム 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 ツールのダウンロード

• PowerShell の invoke-webrequest コマンドレットを使用して GitHub から Azure Stack ツールをダウンロードすると、次のエラーが発生します。

  • "invoke-webrequest : 要求は中止されました: SSL/TLS のセキュリティで保護されたチャネルを作成できませんでした。"

  このエラーは、GitHub で、Tlsv1 および Tlsv1.1 の暗号化標準 (PowerShell の既定) のサポートが最近廃止されたために発生します。 詳細については、脆弱な暗号化標準の削除の通知に関するページを参照してください。

  この問題を解決するには、スクリプトの先頭に [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 を追加して、GitHub リポジトリからダウンロードするときに TLSv1.2 を使用するよう PowerShell コンソールに強制します。

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

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

関連項目

• 特権エンドポイント (PEP) を使用して更新プログラムを監視および再開するには、「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。
• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「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 をインストールします。 この修正プログラムで Windows Defender が更新されます。この修正プログラムは 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 に対する次の機能強化と修正が含まれています。

• 次の Azure Storage Service API バージョンのサポートが追加されました。

  • 2017-04-17
  • 2016-05-31
  • 2015-12-11
  • 2015-07-08

  詳細については、「Azure Stack Storage: 違いと考慮事項」を参照してください。

• より大きなブロック BLOB のサポート:

  • 最大許容ブロック サイズは 4 MB から 100 MB に増加しました。
  • 最大 BLOB サイズは 195 GB から 4.75 TB に増加しました。

• インフラストラクチャのバックアップが [リソース プロバイダー] タイルに表示され、バックアップのアラートが有効になりました。 インフラストラクチャ バックアップ サービスの詳細については、「インフラストラクチャ バックアップ サービスを使用した Azure Stack のバックアップとデータの回復」を参照してください。

• Test-AzureStack コマンドレットの更新。ストレージの診断を改善します。 このコマンドレットの詳細については、Azure Stack の検証に関するページを参照してください。

• ロールベースのアクセス制御 (RBAC) の改善 - Azure Stack と AD FS がデプロイされている場合、RBAC を使用して、アクセス許可をユニバーサル ユーザー グループに委任できるようになりました。 RBAC の詳細については、RBAC の管理に関するページを参照してください。

• 複数の障害ドメインのサポートが追加されました。 詳細については、Azure Stack の高可用性に関するページを参照してください。

• 物理メモリのアップグレードのサポート - 初めてのデプロイ後に、Azure Stack に統合されたシステムのメモリ容量を増やすことができます。 詳しくは、「Azure Stack の物理メモリ容量を管理する」をご覧ください。

• さまざまな修正 - パフォーマンス、安定性、セキュリティ、Azure Stack で使用されるオペレーティング システムが修正されました。

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

更新プログラム 1802 のインストールに関する既知の問題はありません。

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

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

ポータル

• Azure Stack ID システムに AD FS を使用し、このバージョンの Azure Stack に更新したとき、既定のプロバイダー サブスクリプションの既定の所有者は､組み込みの CloudAdmin ユーザーにリセットされます。
  回避策: この更新プログラムのインストール後にこの問題を解決するには、「Azure Stack で自動化をトリガーしてクレーム プロバイダー信頼を構成する」の手順 3 を使用して、既定のプロバイダー サブスクリプションの所有者をリセットします。

• 管理者ポータルのドロップダウン リストから新しいサポート要求を開く機能は使用できません。 代わりに、次のリンクを使用します。

  • 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-AzureRmVirtualNetworkSubnetConfig コマンドレットを使用して、この情報を表示および管理します。

• 管理ポータルとユーザー ポータルの両方で、古い API バージョン (2015-06-15 など) で作成されたストレージ アカウントの [概要] ブレードを選択した場合、[概要] ブレードの読み込みに失敗します。 これには、パッチと更新プログラムの実行時に使用される updateadminaccount などのシステム ストレージ アカウントが含まれます。

  この問題を回避するには、PowerShell を使用して Start-ResourceSynchronization.ps1 スクリプトを実行し、ストレージ アカウントの詳細へのアクセスを復元します。 このスクリプトは GitHub から入手可能であり、特権エンドポイントでサービス管理者の資格情報で実行する必要があります。

• [サービス正常性] ブレードの読み込みに失敗します。 管理ポータルまたはユーザー ポータルで [サービス正常性] ブレードを開くと、Azure Stack にエラーが表示され、情報は読み込まれません。 これは正しい動作です。 [サービス正常性] を選択して開けますが、この機能はまだ利用できません。Azure Stack の今後のバージョンに実装されます。

正常性と監視

• 以下の詳細情報の正常性コントローラー コンポーネントのアラートが表示されることがあります:

  アラート #1:

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

  アラート #2:

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

  いずれのアラートも無視してかまいません。 時間が経つと自動的に閉じられます。

Marketplace

• ユーザーはサブスクリプションなしですべてのマーケットプレースを参照し、プランやオファーなどの管理アイテムを表示できます。 ユーザーはこれらのアイテムを使用できません。

Compute

• 仮想マシン スケール セットのスケーリング設定は、ポータルで使用できません。 回避策として、Azure PowerShell を使用できます。 PowerShell のバージョンの違いにより、-VMScaleSetName パラメーターの代わりに -Name を使用する必要があります。

• バージョン 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 は、バックエンド ネットワーク上の Windows インスタンスでは問題なく動作します。

• IP 転送機能がポータルに表示されますが、IP 転送を有効にしても何も起こりません。 この機能は、まだサポートされていません。

• Azure Stack では、IP アドレスごとに 1 つの "ローカル ネットワーク ゲートウェイ" がサポートされます。 これは、テナントのすべてのサブスクリプションに当てはまります。 最初のローカル ネットワーク ゲートウェイ接続を作成した後に、続いて同じ IP アドレスでローカル ネットワーク ゲートウェイ リソースを作成しようとすると、ブロックされます。

• "自動" の DNS サーバー設定を使用して作成した仮想ネットワークで、カスタム 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 ツールのダウンロード

• PowerShell の invoke-webrequest コマンドレットを使用して GitHub から Azure Stack ツールをダウンロードすると、次のエラーが発生します。

  • "invoke-webrequest : 要求は中止されました: SSL/TLS のセキュリティで保護されたチャネルを作成できませんでした。"

  このエラーは、GitHub で、Tlsv1 および Tlsv1.1 の暗号化標準 (PowerShell の既定) のサポートが最近廃止されたために発生します。 詳細については、脆弱な暗号化標準の削除の通知に関するページを参照してください。

  この問題を解決するには、スクリプトの先頭に [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 を追加して、GitHub リポジトリからダウンロードするときに TLSv1.2 を使用するよう PowerShell コンソールに強制します。

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

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

詳細

Microsoft は、更新プログラム 1710 でインストールされる特権エンドポイント (PEP) を使用して、更新プログラムを監視および再開するための方法を提供しています。

• 「特権エンドポイントを使用して Azure Stack での更新プログラムをモニターする」をご覧ください。

関連項目

• Azure Stack での更新プログラム管理の概要については、「Azure Stack での更新プログラムの管理概要」を参照してください。
• Azure Stack に更新プログラムを適用する方法については、「Azure Stack で更新を適用する」を参照してください。