Azure の Update Management ソリューションUpdate Management solution in Azure

Azure Automation の Update Management ソリューションを使用すると、Azure、オンプレミスの環境、またはその他のクラウド プロバイダーで、Windows コンピューターと Linux コンピューターに対してオペレーティング システムの更新プログラムを管理できます。You can use the Update Management solution in Azure Automation to manage operating system updates for your Windows and Linux computers in Azure, in on-premises environments, or in other cloud providers. すべてのエージェント コンピューターで利用可能な更新プログラムの状態をすばやく評価し、サーバーに必要な更新プログラムをインストールするプロセスを管理できます。You can quickly assess the status of available updates on all agent computers and manage the process of installing required updates for servers.

仮想マシンの Update Management は、Azure Automation アカウントから直接有効にすることができます。You can enable Update Management for virtual machines directly from your Azure Automation account. Automation アカウントから仮想マシンの Update Management を有効にする方法については、複数の仮想マシンの更新管理に関するページを参照してください。To learn how to enable Update Management for virtual machines from your Automation account, see Manage updates for multiple virtual machines. また、Azure portal の仮想マシン ページから仮想マシンの Update Management を有効にすることもできます。You can also enable Update Management for a virtual machine from the virtual machine page in the Azure portal. このシナリオは、Linux および Windows の仮想マシンに対して使用できます。This scenario is available for Linux and Windows virtual machines.

注意

Update Management ソリューションでは、Log Analytics ワークスペースを Automation アカウントにリンクする必要があります。The Update Management solution requires linking a Log Analytics workspace to your Automation account. サポートされているリージョンの確定的な一覧については、Azure でのワークスペースのマッピングに関する記事をご覧ください。For a definitive list of supported regions, see Azure Workspace mappings. リージョン マッピングは、Automation アカウントとは別のリージョンの仮想マシンを管理する機能には影響しません。The region mappings do not affect the ability to manage virtual machines in a separate region than your Automation account.

注意

この記事は最近、Log Analytics ではなく Azure Monitor ログという用語を使うように更新されました。This article was recently updated to use the term Azure Monitor logs instead of Log Analytics. ログ データは引き続き Log Analytics ワークスペースに格納され、同じ Log Analytics サービスによって収集されて分析されます。Log data is still stored in a Log Analytics workspace and is still collected and analyzed by the same Log Analytics service. Azure Monitor のログの役割をより適切に反映させるために、用語を更新しています。We are updating the terminology to better reflect the role of logs in Azure Monitor. 詳しくは、Azure Monitor の用語の変更に関するページをご覧ください。See Azure Monitor terminology changes for details.

ソリューションの概要Solution overview

Update Management で管理されるコンピューターでは、評価と更新プログラムのデプロイに次の構成を使用します。Computers that are managed by Update Management use the following configurations to perform assessment and update deployments:

  • Windows または Linux 用の Microsoft Monitoring Agent (MMA)Microsoft Monitoring Agent (MMA) for Windows or Linux
  • PowerShell Desired State Configuration (DSC) (Linux の場合)PowerShell Desired State Configuration (DSC) for Linux
  • Automation Hybrid Runbook WorkerAutomation Hybrid Runbook Worker
  • Microsoft Update または Windows Server Update Services (WSUS) (Windows コンピューターの場合)Microsoft Update or Windows Server Update Services (WSUS) for Windows computers

次の図は、動作とデータ フローの概念図です。ワークスペース内の接続された Windows Server と Linux コンピューターすべてがこのソリューションによってどのように評価され、セキュリティ更新プログラムが適用されるかを示しています。The following diagram shows a conceptual view of the behavior and data flow with how the solution assesses and applies security updates to all connected Windows Server and Linux computers in a workspace:

Update Management プロセスのフロー

Update Management を使用して、同じテナント内の複数のサブスクリプションにマシンをネイティブにオンボードできます。Update Management can be used to natively onboard machines in multiple subscriptions in the same tenant.

パッケージがリリースされた後、Linux マシンの評価用に修正プログラムが表示されるまで 2、3 時間かかります。Once a package is released, it takes 2-3 hours for the patch to show up for Linux machines for assessment. Windows マシンの場合、リリースされてから評価用に修正プログラムが表示されるまで 12 ~ 15 時間かかります。For Windows machines, it takes 12-15 hours for the patch to show up for assessment after it has been released.

コンピューターが更新プログラムのコンプライアンスを確認するためにスキャンを完了した後、エージェントによって情報が Azure Monitor ログに一括転送されます。After a computer completes a scan for update compliance, the agent forwards the information in bulk to Azure Monitor logs. Windows コンピューターでは、コンプライアンス スキャンは既定で 12 時間ごとに実行されます。On a Windows computer, the compliance scan is run every 12 hours by default.

このスキャン スケジュールに加えて、MMA の再起動後 15 分以内、更新プログラムのインストール前、および更新プログラムのインストール後に、更新プログラムのコンプライアンスを確認するためのスキャンが開始されます。In addition to the scan schedule, the scan for update compliance is initiated within 15 minutes of the MMA being restarted, before update installation, and after update installation.

Linux コンピューターでは、コンプライアンス スキャンは既定で 1 時間ごとに実行されます。For a Linux computer, the compliance scan is performed every hour by default. MMA エージェントを再起動した場合は、コンプライアンス スキャンは 15 分以内に開始されます。If the MMA agent is restarted, a compliance scan is initiated within 15 minutes.

このソリューションは、同期先として構成されたソースに基づいて、コンピューターがどの程度最新の状態であるかをレポートします。The solution reports how up-to-date the computer is based on what source you're configured to sync with. Windows コンピューターが WSUS にレポートするよう構成されている場合、WSUS が Microsoft Update と最後に同期したタイミングによっては、その結果が Microsoft Updates の示す内容と一致しない場合があります。If the Windows computer is configured to report to WSUS, depending on when WSUS last synced with Microsoft Update, the results might differ from what Microsoft Updates shows. この動作は、パブリック リポジトリではなくローカル リポジトリにレポートするよう構成されている Linux コンピューターも同様です。This behavior is the same for Linux computers that are configured to report to a local repo instead of to a public repo.

注意

サービスに正しく報告するためには、Update Management で、特定の URL とポートを有効にする必要があります。To properly report to the service, Update Management requires certain URLs and ports to be enabled. これらの要件の詳細については、Hybrid Worker のためのネットワーク計画に関する記事を参照してください。To learn more about these requirements, see Network planning for Hybrid Workers.

更新が必要なコンピューターへのソフトウェア更新プログラムのデプロイとインストールに、スケジュールされたデプロイを使用できます。You can deploy and install software updates on computers that require the updates by creating a scheduled deployment. Windows コンピューターの場合、"オプション" に分類されている更新プログラムはデプロイの範囲に含まれません。Updates classified as Optional aren't included in the deployment scope for Windows computers. デプロイの範囲には、必須の更新プログラムのみが含まれています。Only required updates are included in the deployment scope.

スケジュールされたデプロイでは、適用可能な更新プログラムを受け取る対象コンピューターを定義する際に、コンピューターを明示的に指定するか、特定のコンピューター セットのログ検索、または指定した条件に基づいて動的に Azure VM を選択する Azure クエリに基づいたコンピューター グループを選択します。The scheduled deployment defines what target computers receive the applicable updates, either by explicitly specifying computers or by selecting a computer group that's based on log searches of a specific set of computers, or an Azure query that dynamically selects Azure VMs based on specified criteria. これらのグループはスコープ構成とは異なります。これは、ソリューションを有効にする管理パックを取得するマシンを決定するためにのみ使用されます。These groups are different from Scope Configuration, which is only used to determine what machines get the management packs that enable the solution.

また、スケジュールを指定するときは、更新プログラムのインストールを許可する期間を承認し、設定します。You also specify a schedule to approve and set a period of time during which updates can be installed. この期間は、メンテナンス期間と呼ばれます。This period of time is called the maintenance window. 再起動が必要な場合、適切な再起動オプションを選択していれば、再起動のために 20 分間のメンテナンス期間が予約されます。Twenty minutes of the maintenance window is reserved for reboots if a reboot is needed and you selected the appropriate reboot option. パッチ適用に予想よりも時間がかかり、メンテナンス期間の残りが 20 分を切った場合、再起動は行われません。If patching takes longer than expected and there is less than twenty minutes in the maintenance window, a reboot will not occur.

更新プログラムは、Azure Automation の Runbook によってインストールされます。Updates are installed by runbooks in Azure Automation. これらの Runbook は表示できません。また、これらは構成不要です。You can't view these runbooks, and the runbooks don’t require any configuration. 更新プログラムのデプロイを作成すると、対象に含めたコンピューターに対して、指定した時間にマスター更新 Runbook を開始するスケジュールが作成されます。When an update deployment is created, the update deployment creates a schedule that starts a master update runbook at the specified time for the included computers. このマスター Runbook は、必須の更新プログラムをインストールする子 Runbook を各エージェントで開始します。The master runbook starts a child runbook on each agent to install the required updates.

更新プログラムのデプロイで指定した日時に、対象のコンピューターでデプロイが並列で実行されます。At the date and time specified in the update deployment, the target computers execute the deployment in parallel. まず、スキャンが実行され、その更新プログラムが依然として必須であることが確認されてからインストールされます。Before installation, a scan is run to verify that the updates are still required. WSUS クライアント コンピューターの場合、更新プログラムが WSUS で承認されていないと更新プログラムのデプロイは失敗します。For WSUS client computers, if the updates aren't approved in WSUS, the update deployment fails.

1 つのマシンを複数の Log Analytics ワークスペースで Update Management 用に登録すること (マルチホーム) は、サポートされていません。Having a machine registered for Update Management in more than one Log Analytics workspaces (multi-homing) isn't supported.

クライアントClients

サポートされているクライアントの種類Supported client types

次の表は、更新プログラム評価でサポートされているオペレーティング システムの一覧です。The following table shows a list of supported operating systems for Update Assessments. 修正プログラムを適用するには、Hybrid Runbook Worker が必要です。Patching requires a Hybrid Runbook Worker. Hybrid Runbook Worker の要件の詳細については、Windows HRW および Linux HRW のインストール ガイドを参照してください。For information on Hybrid Runbook Worker requirements, see the installation guides for Windows HRW and Linux HRW.

オペレーティング システムOperating system メモNotes
Windows Server 2019 (Datacenter、Datacenter Core、Standard)Windows Server 2019 (Datacenter/Datacenter Core/Standard)

Windows Server 2016 (Datacenter、Datacenter Core、Standard)Windows Server 2016 (Datacenter/Datacenter Core/Standard)

Windows Server 2012 R2 (Datacenter、Standard)Windows Server 2012 R2(Datacenter/Standard)

Windows Server 2012Windows Server 2012

Windows Server 2008 R2 (RTM および SP1 Standard)Windows Server 2008 R2 (RTM and SP1 Standard)
CentOS 6 (x86/x64) および 7 (x64)CentOS 6 (x86/x64) and 7 (x64) Linux エージェントは、更新リポジトリへのアクセスが必要です。Linux agents must have access to an update repository. 分類に基づく修正プログラムでは、CentOS に既定では設定されていない、セキュリティ データを返すための "yum" が必須です。Classification-based patching requires 'yum' to return security data which CentOS doesn't have out of the box. 分類に基づく CentOS への修正プログラムの適用の詳細については、Linux での分類の更新に関するページを参照してください。For more information on classification-based patching on CentOS, see Update classifications on Linux
Red Hat Enterprise 6 (x86/x64) および 7 (x64)Red Hat Enterprise 6 (x86/x64) and 7 (x64) Linux エージェントは、更新リポジトリへのアクセスが必要です。Linux agents must have access to an update repository.
SUSE Linux Enterprise Server 11 (x86/x64) および 12 (x64)SUSE Linux Enterprise Server 11 (x86/x64) and 12 (x64) Linux エージェントは、更新リポジトリへのアクセスが必要です。Linux agents must have access to an update repository.
Ubuntu 14.04 LTS、16.04 LTS、18.04 (x86/x64)Ubuntu 14.04 LTS, 16.04 LTS, and 18.04 (x86/x64) Linux エージェントは、更新リポジトリへのアクセスが必要です。Linux agents must have access to an update repository.

注意

Azure 仮想マシン スケール セットは、Update Management で管理できます。Azure virtual machine scale sets can be managed with Update Management. Update Management は、基本イメージではなくインスタンス自体で動作します。Update Management works on the instances themselves and not the base image. 一度にすべての VM インスタンスを更新しない場合、段階的に更新をスケジュールする必要があります。You'll need to schedule the updates in an incremental way, as to not update all VM instances at once. Azure 以外のマシンのオンボードの手順に従って、VMSS ノードを追加することができます。VMSS Nodes can be added by following the steps under Onboard a non-Azure machine.

サポートされていないクライアントの種類Unsupported client types

次の表は、サポートされていないオペレーティング システムの一覧です。The following table lists operating systems that aren't supported:

オペレーティング システムOperating system メモNotes
Windows クライアントWindows client クライアント オペレーティング システム (Windows 7 や Windows 10 など) はサポートされません。Client operating systems (such as Windows 7 and Windows 10) aren't supported.
Windows Server 2016 Nano ServerWindows Server 2016 Nano Server サポートされていません。Not supported.
Azure Kubernetes Service ノードAzure Kubernetes Service Nodes サポートされていません。Not supported. Azure Kubernetes Service (AKS) の Linux ノードにセキュリティとカーネルの更新を適用します」で詳しく説明されている修正プログラム適用プロセスを使用します。Use the patching process detailed in Apply security and kernel updates to Linux nodes in Azure Kubernetes Service (AKS)

クライアントの要件Client requirements

WindowsWindows

Windows エージェントは、WSUS サーバーと通信するように構成するか、Microsoft Update にアクセスできる必要があります。Windows agents must be configured to communicate with a WSUS server or they must have access to Microsoft Update. System Center Configuration Manager と Update Management を統合して使用できます。You can use Update Management with System Center Configuration Manager. 統合シナリオの詳細については、「System Center Configuration Manager と Update Management の統合」を参照してください。To learn more about integration scenarios, see Integrate System Center Configuration Manager with Update Management. Windows エージェントが必要です。The Windows agent is required. Azure 仮想マシンのオンボードを実行すると、このエージェントは自動的にインストールされます。The agent is installed automatically if you're onboarding an Azure virtual machine.

注意

ユーザーは、グループ ポリシーを変更して、システムではなくユーザーだけがコンピューターの再起動を実行できるようにすることができます。It is possible for a user to modify Group Policy so that machine reboots can only performed by the user, not by the system. Update Management にユーザーによる手動操作なしでコンピューターを再起動する権限がない場合、管理対象のコンピューターが停止する可能性があります。Managed machines may get stuck, if Update Management does not have rights to reboot the machine without manual interaction from the user.

詳しくは、「自動更新のグループ ポリシー設定を構成する」をご覧ください。For more information, see Configure Group Policy Settings for Automatic Updates.

LinuxLinux

Linux コンピューターには、更新リポジトリへのアクセスが必要です。For Linux, the machine must have access to an update repository. プライベートまたはパブリックの更新リポジトリが使用できます。The update repository can be private or public. Update Management と対話するには、TLS 1.1 または TLS 1.2 が必要です。TLS 1.1 or TLS 1.2 is required to interact with Update Management. このソリューションでは、Linux 用 Log Analytics エージェントが複数の Azure Log Analytics ワークスペースにレポートする構成はサポートされていません。A Log Analytics Agent for Linux that's configured to report to more than one Log Analytics workspaces isn't supported with this solution. マシンには Python 2.x もインストールされている必要があります。The machine must also have Python 2.x installed.

Linux 用 Log Analytics エージェントをインストールして最新バージョンをダウンロードする方法の詳細については、Linux 用 Log Analytics エージェントに関するページを参照してください。For information about how to install the Log Analytics Agent for Linux and to download the latest version, see Log Analytics Agent for Linux. Windows 用 Log Analytics エージェントをインストールする方法の詳細については、Microsoft Monitoring Agent for Windows に関するページを参照してください。For information about how to install the Log Analytics Agent for Windows, see Microsoft Monitoring Agent for Windows.

アクセス許可Permissions

更新プログラムのデプロイを作成および管理するには、特定のアクセス許可が必要です。To create and manage update deployments, you need specific permissions. これらのアクセス許可の詳細については、Update Management へのロールベースのアクセスに関するページをご覧ください。To learn about these permissions, see Role-based access - Update Management.

ソリューションのコンポーネントSolution components

このソリューションは、次のリソースで構成されています。The solution consists of the following resources. リソースは、Automation アカウントに追加されます。The resources are added to your Automation account. これらは、直接接続しているエージェントであるか、または Operations Manager に接続された管理グループの中に存在します。They're either directly connected agents or in an Operations Manager-connected management group.

ハイブリッド worker グループHybrid Worker groups

このソリューションを有効にすると、ソリューションに含まれている Runbook をサポートするために、Log Analytics ワークスペースに直接接続された Windows コンピューターが自動的に Hybrid Runbook Worker として構成されます。After you enable this solution, any Windows computer that's directly connected to your Log Analytics workspace is automatically configured as a Hybrid Runbook Worker to support the runbooks that are included in this solution.

ソリューションで管理されている各 Windows コンピューターは、Automation アカウントの [システム ハイブリッド worker グループ] として、 [ハイブリッド Worker グループ] ページに表示されます。Each Windows computer that's managed by the solution is listed in the Hybrid worker groups pane as a System hybrid worker group for the Automation account. ソリューションは、Hostname FQDN_GUID の名前付け規則を使用します。The solutions use the naming convention Hostname FQDN_GUID. アカウントの Runbook でこれらのグループを対象として指定することはできません。You can't target these groups with runbooks in your account. 指定すると失敗します。They fail if you try. これらのグループは、管理ソリューションをサポートすることのみを目的としています。These groups are intended to support only the management solution.

このソリューションと Hybrid Runbook Worker グループ メンバーシップの両方に同じアカウントを使用すると、Windows コンピューターを Automation アカウントの Hybrid Runbook Worker グループに追加して Automation Runbook をサポートすることができます。You can add the Windows computers to a Hybrid Runbook Worker group in your Automation account to support Automation runbooks if you use the same account for both the solution and the Hybrid Runbook Worker group membership. この機能は、Hybrid Runbook Worker のバージョン 7.2.12024.0 で追加されました。This functionality was added in version 7.2.12024.0 of the Hybrid Runbook Worker.

管理パックManagement packs

System Center Operations Manager 管理グループが Log Analytics ワークスペースに接続されている場合は、以下の管理パックが Operations Manager にインストールされます。If your System Center Operations Manager management group is connected to a Log Analytics workspace, the following management packs are installed in Operations Manager. これらの管理パックは、このソリューションを追加した後、直接接続された Windows コンピューターにもインストールされます。These management packs are also installed on directly connected Windows computers after you add the solution. これらの管理パックを構成または管理する必要はありません。You don't need to configure or manage these management packs.

  • Microsoft System Center Advisor 更新プログラム評価インテリジェンス パック (Microsoft.IntelligencePacks.UpdateAssessment)Microsoft System Center Advisor Update Assessment Intelligence Pack (Microsoft.IntelligencePacks.UpdateAssessment)
  • Microsoft.IntelligencePack.UpdateAssessment.Configuration (Microsoft.IntelligencePack.UpdateAssessment.Configuration)Microsoft.IntelligencePack.UpdateAssessment.Configuration (Microsoft.IntelligencePack.UpdateAssessment.Configuration)
  • 更新プログラムの展開 MPUpdate Deployment MP

注意

ワークスペースに関連付けられるように管理グループ レベルでエージェントが構成されている Operations Manager 1807 または 2019 管理グループがある場合、それらを表示するための現在の回避策としては、Microsoft.IntelligencePacks.AzureAutomation.HybridAgent.Init ルールで IsAutoRegistrationEnabledTrue にオーバーライドします。If you have an Operations Manager 1807 or 2019 Management Group with agents configured at the Management Group level to be associated to a workspace, the current workaround to get them to show up is to override IsAutoRegistrationEnabled to True in the Microsoft.IntelligencePacks.AzureAutomation.HybridAgent.Init rule.

ソリューション管理パックの更新方法の詳細については、Azure Monitor ログへの Operations Manager の接続に関するページを参照してください。For more information about how solution management packs are updated, see Connect Operations Manager to Azure Monitor logs.

注意

Operations Manger エージェントを使用しているシステムを Update Management によって完全に管理できるようにするには、エージェントを Microsoft Monitoring Agent に更新する必要があります。For systems with the Operations Manger Agent, to be able to be fully managed by Update Management, the agent needs to be updated to the Microsoft Monitoring Agent. エージェントを更新する方法については、Operations Manager エージェントのアップグレード方法に関する記事を参照してください。To learn how to update the agent, see How to upgrade an Operations Manager agent. Operations Manager を使用する環境では、System Center Operations Manager 2012 R2 UR 14 以降を実行している必要があります。For environments using Operations Manager, it is required that you are running System Center Operations Manager 2012 R2 UR 14 or later.

Update Management の有効化Enable Update Management

システムへの修正プログラムの適用を開始するには、Update Management ソリューションを有効にする必要があります。To begin patching systems, you need to enable the Update Management solution. Update Management にマシンをオンボードする方法は多数あります。There are many ways to onboard machines to Update Management. 以下に、推奨およびサポートされている、ソリューションにオンボードする方法を示します。The following are the recommended and supported ways to onboard the solution:

Azure 以外のマシンが配布準備済みであることを確認するConfirm that non-Azure machines are onboarded

直接接続されたマシンが Azure Monitor ログと通信していることを確認するには、数分経ってから、次のログ検索を実行します。To confirm that directly connected machines are communicating with Azure Monitor logs, after a few minutes, you can run one the following log searches.

LinuxLinux

Heartbeat
| where OSType == "Linux" | summarize arg_max(TimeGenerated, *) by SourceComputerId | top 500000 by Computer asc | render table

WindowsWindows

Heartbeat
| where OSType == "Windows" | summarize arg_max(TimeGenerated, *) by SourceComputerId | top 500000 by Computer asc | render table

Windows コンピューターでは、次の情報を調べて、Azure Monitor ログとエージェントの接続を確認できます。On a Windows computer, you can review the following information to verify agent connectivity with Azure Monitor logs:

  1. [コントロール パネル] から [Microsoft Monitoring Agent] を開きます。In Control Panel, open Microsoft Monitoring Agent. [Azure Log Analytics] タブで、エージェントに"Microsoft Monitoring Agent は Log Analytics に正常に接続しました" というメッセージが表示されます。On the Azure Log Analytics tab, the agent displays the following message: The Microsoft Monitoring Agent has successfully connected to Log Analytics.
  2. Windows イベント ログを開きます。Open the Windows Event Log. アプリケーションとサービス ログ\Operations Manager に移動して、ソースの [サービス コネクタ] でイベント ID 3000 および 5002 を検索します。Go to Application and Services Logs\Operations Manager and search for Event ID 3000 and Event ID 5002 from the source Service Connector. これらのイベントは、コンピューターが Log Analytics ワークスペースに登録され、構成を受信していることを示しています。These events indicate that the computer has registered with the Log Analytics workspace and is receiving configuration.

エージェントが Azure Monitor ログと通信できず、ファイアウォールまたはプロキシ サーバーを介してインターネットと通信するよう構成されている場合は、ファイアウォールまたはプロキシ サーバーが正しく構成されていることを確認します。If the agent can't communicate with Azure Monitor logs and the agent is configured to communicate with the internet through a firewall or proxy server, confirm the firewall or proxy server is properly configured. ファイアウォールまたはプロキシ サーバーが正しく構成されていることを確認する方法については、Windows エージェントのネットワーク構成または Linux エージェントのネットワーク構成に関する記事を参照してください。To learn how to verify the firewall or proxy server is properly configured, see Network configuration for Windows agent or Network configuration for Linux agent.

注意

Linux システムがプロキシまたは Log Analytics ゲートウェイと通信するよう構成されており、このソリューションの配布準備を行っている場合は、次のコマンドを実行し、ファイルに対する読み取り権限を omiuser グループに付与するよう、proxy.conf のアクセス許可を更新します。If your Linux systems are configured to communicate with a proxy or Log Analytics Gateway and you're onboarding this solution, update the proxy.conf permissions to grant the omiuser group read permission on the file by using the following commands:

sudo chown omsagent:omiusers /etc/opt/microsoft/omsagent/proxy.conf sudo chmod 644 /etc/opt/microsoft/omsagent/proxy.conf

新しく追加された Linux エージェントは、評価が完了した後、状態が "更新済み" と表示されます。Newly added Linux agents show a status of Updated after an assessment has been performed. このプロセスには最大で 6 時間かかります。This process can take up to 6 hours.

Operations Manager 管理グループが Azure Monitor ログと通信していることを確認する方法については、Operations Manager と Azure Monitor ログの統合の検証に関するページを参照してください。To confirm that an Operations Manager management group is communicating with Azure Monitor logs, see Validate Operations Manager integration with Azure Monitor logs.

データ収集Data collection

サポートされているエージェントSupported agents

次の表では、このソリューションでサポートされている接続先ソースについて説明します。The following table describes the connected sources that are supported by this solution:

接続先ソースConnected source サポートされていますSupported 説明Description
Windows エージェントWindows agents はいYes ソリューションは、Windows エージェントからシステムの更新プログラムに関する情報を収集し、必要な更新プログラムのインストールを開始します。The solution collects information about system updates from Windows agents and then initiates installation of required updates.
Linux エージェントLinux agents はいYes ソリューションは、Linux エージェントからシステムの更新プログラムに関する情報を収集し、サポート対象のディストリビューションに対して必要な更新プログラムのインストールを開始します。The solution collects information about system updates from Linux agents and then initiates installation of required updates on supported distributions.
Operations Manager 管理グループOperations Manager management group はいYes ソリューションは、接続された管理グループ内のエージェントからシステムの更新プログラムに関する情報を収集します。The solution collects information about system updates from agents in a connected management group.
Operations Manager エージェントから Azure Monitor ログへの直接接続は必要ありません。A direct connection from the Operations Manager agent to Azure Monitor logs isn't required. データは管理グループから Log Analytics ワークスペースに転送されます。Data is forwarded from the management group to the Log Analytics workspace.

収集の頻度Collection frequency

管理対象の各 Windows コンピューターでは、1 日 2 回スキャンが実行されます。A scan is performed twice per day for each managed Windows computer. 15 分ごとに Windows API が呼び出され、最後の更新時間を照会することで、状態が変化したかどうかが確認されます。Every 15 minutes, the Windows API is called to query for the last update time to determine whether the status has changed. 状態が変更された場合、コンプライアンス スキャンが開始されます。If the status has changed, a compliance scan is initiated.

各マネージド Linux コンピューターでは、1 時間ごとにスキャンが実行されます。A scan is performed every hour for each managed Linux computer.

管理対象のコンピューターの更新されたデータがダッシュボードに表示されるまでに、30 分~ 6 時間かかる場合があります。It can take between 30 minutes and 6 hours for the dashboard to display updated data from managed computers.

Update Management を使用しているマシンでの Azure Monitor ログの平均データ使用量は、1 か月あたり約 25 MB です。The average Azure Monitor logs data usage for a machine using Update Management is approximately 25MB per month. この値は概数にすぎず、環境によって異なる可能性があります。This value is only an approximation and is subject to change based on your environment. お使いの環境を監視し、実際に必要な正確な使用量を確認することをお勧めします。It's recommended that you monitor your environment to see the exact usage that you have.

更新の評価を表示するView update assessments

Automation アカウントで [Update Management] をクリックすると、使用しているマシンの状態が表示されます。In your Automation account, select Update Management to view the status of your machines.

このビューには、ご利用のマシン、不足している更新プログラム、更新プログラムのデプロイ、およびスケジュールされている更新プログラムのデプロイに関する情報が表示されます。This view provides information about your machines, missing updates, update deployments, and scheduled update deployments. [対応] 列では、マシンが評価された最終時刻を確認できます。In the COMPLIANCE COLUMN, you can see the last time the machine was assessed. [エージェントの更新の準備] 列では、更新エージェントの正常性を確認できます。In the UPDATE AGENT READINESS column, you can see if the health of the update agent. 問題がある場合は、問題を解決するために必要な手順が記載されたトラブルシューティング ドキュメントへのリンクを選択してください。If there's an issue, select the link to go to troubleshooting documentation that can help you learn what steps to take to correct the problem.

マシン、更新プログラム、またはデプロイに関する情報を返すログ検索を実行するには、一覧から項目を選択します。To run a log search that returns information about the machine, update, or deployment, select the item in the list. これにより、項目のクエリが選択された状態で [ログ検索] ページが開きます。The Log Search pane opens with a query for the item selected:

Update Management の既定のビュー

更新プログラムをインストールするInstall updates

ご利用のワークスペースにある Linux コンピューターと Windows コンピューターのすべてで更新プログラムが評価されたら、"更新プログラムのデプロイ" を作成して、必要な更新プログラムをインストールできます。After updates are assessed for all the Linux and Windows computers in your workspace, you can install required updates by creating an update deployment. 更新プログラムのデプロイを作成するには、Automation アカウントに対する書き込みアクセス権と、デプロイで対象とされる Azure VM に対する書き込みアクセス権が必要です。To create an Update Deployment, you must have write access to the Automation Account and write access to any Azure VMs that are targeted in the deployment. 更新プログラムのデプロイとは、1 台以上のコンピューターに対して、必要な更新プログラムをスケジュールに従ってインストールすることです。An update deployment is a scheduled installation of required updates for one or more computers. デプロイの範囲に含めるコンピューターまたはコンピューター グループと、デプロイの日時を指定します。You specify the date and time for the deployment and a computer or group of computers to include in the scope of a deployment. コンピューター グループの詳細については、Azure Monitor ログのコンピューター グループに関するページを参照してください。To learn more about computer groups, see Computer groups in Azure Monitor logs.

更新プログラムのデプロイにコンピューター グループを含めると、スケジュールの作成時にグループ メンバーシップが 1 回だけ評価されます。When you include computer groups in your update deployment, group membership is evaluated only once, at the time of schedule creation. その後で加えられたグループへの変更は反映されません。Subsequent changes to a group aren't reflected. このような動的グループの使用を回避するため、これらのグループはデプロイ時に解決され、Azure VM に対するクエリまたは Azure 以外の VM に関する保存された検索によって定義されます。To get around this use Dynamic groups, these groups are resolved at deployment time and are defined by a query for Azure VMs or a saved search for Non-Azure VMs.

注意

Azure Marketplace からデプロイされた Windows 仮想マシンは、既定で Windows Update Service から自動更新を受信するように設定されています。Windows virtual machines that are deployed from the Azure Marketplace by default are set to receive automatic updates from Windows Update Service. このソリューションまたは Windows 仮想マシンをワークスペースに追加しても、この動作は変わりません。This behavior doesn't change when you add this solution or add Windows virtual machines to your workspace. このソリューションで更新プログラムを能動的に管理しない場合は、既定の動作 (更新プログラムが自動的に適用される) が適用されます。If you don't actively manage updates by using this solution, the default behavior (to automatically apply updates) applies.

Ubuntu でメンテナンス期間外に更新プログラムが適用されないようにするには、無人アップグレード パッケージを再構成して自動更新を無効にします。To avoid updates being applied outside of a maintenance window on Ubuntu, reconfigure the Unattended-Upgrade package to disable automatic updates. パッケージの構成方法については、Ubuntu サーバー ガイドの自動更新に関するトピックをご覧ください。For information about how to configure the package, see Automatic Updates topic in the Ubuntu Server Guide.

Azure Marketplace から利用できるオンデマンドの Red Hat Enterprise Linux (RHEL) イメージから作成した仮想マシンは、Azure にデプロイされた Red Hat Update Infrastructure (RHUI) にアクセスするよう登録されています。Virtual machines that were created from the on-demand Red Hat Enterprise Linux (RHEL) images that are available in the Azure Marketplace are registered to access the Red Hat Update Infrastructure (RHUI) that's deployed in Azure. その他の Linux ディストリビューションは、サポートされている方法に従って、ディストリビューション オンライン ファイル リポジトリから更新する必要があります。Any other Linux distribution must be updated from the distribution's online file repository by following the distribution's supported methods.

新しい更新プログラムのデプロイを作成するには、 [更新プログラムの展開のスケジュール] を選択します。To create a new update deployment, select Schedule update deployment. [新しい更新プログラムの展開] ページが開きます。The New Update Deployment page opens. 次の表で説明されているプロパティの値を入力し、 [作成] をクリックします。Enter values for the properties described in the following table and then click Create:

プロパティProperty DescriptionDescription
NameName 更新プログラムの展開を識別する一意の名前。Unique name to identify the update deployment.
オペレーティング システムOperating System Linux または WindowsLinux or Windows
更新するグループGroups to update Azure マシンの場合、サブスクリプション、リソース グループ、場所、およびタグの組み合わせに基づいてクエリを定義し、デプロイに含める Azure VM の動的グループを構築します。For Azure machines, define a query based on a combination of subscription, resource groups, locations, and tags to build a dynamic group of Azure VMs to include in your deployment.
Azure 以外のマシンの場合、既存の保存された検索を選択して、デプロイに含める Azure 以外のマシンのグループを選択します。For Non-Azure machines, select an existing saved search to select a group of Non-Azure machines to include in the deployment.

詳しくは、動的グループに関するページをご覧ください。To learn more, see Dynamic Groups
更新するマシンMachines to update 保存した検索条件、インポートしたグループを選択するか、ドロップダウンから [マシン] を選択し、個別のマシンを選択します。Select a Saved search, Imported group, or pick Machine from the drop-down and select individual machines. [マシン] を選択すると、マシンの準備状況が [エージェントの更新の準備] 列に示されます。If you choose Machines, the readiness of the machine is shown in the UPDATE AGENT READINESS column.
Azure Monitor ログでコンピューター グループを作成するさまざまな方法については、Azure Monitor ログのコンピューター グループに関するページを参照してくださいTo learn about the different methods of creating computer groups in Azure Monitor logs, see Computer groups in Azure Monitor logs
更新プログラムの分類Update classifications 必要な更新プログラムの分類すべてを選択しますSelect all the update classifications that you need
更新プログラムの包含/除外Include/exclude updates [包含/除外] ページが開きます。This opens the Include/Exclude page. 含めるまたは除外する更新プログラムは別のタブに表示されます。Updates to be included or excluded are on separate tabs. 包含を処理する方法について詳しくは、包含の動作に関するページをご覧ください。For more information on how inclusion is handled, see inclusion behavior
スケジュール設定Schedule settings 開始する時刻を選択し、繰り返しの設定として、[1 回] または [定期的] のいずれかを選択しますSelect the time to start, and select either Once or recurring for the recurrence
事前スクリプトと事後スクリプトPre-scripts + Post-scripts デプロイの前後に実行するスクリプトを選択しますSelect the scripts to run before and after your deployment
メンテナンス期間Maintenance window 更新プログラムに対して設定された分数です。Number of minutes set for updates. 30 分未満の値を指定することはできません。また、6 時間を超えることはできませんThe value can't be less than 30 minutes and no more than 6 hours
再起動制御Reboot control 再起動の処理方法を決定します。Determines how reboots should be handled. 使用できるオプションは次のとおりです。Available options are:
必要に応じて再起動 (既定値)Reboot if required (Default)
常に再起動Always reboot
再起動しないNever reboot
Only reboot - will not install updates (再起動のみ - 更新プログラムをインストールしない)Only reboot - will not install updates

更新プログラムのデプロイはプログラムで作成することもできます。Update Deployments can also be created programmatically. REST API を使用して更新プログラムのデプロイを作成する方法については、「Software Update Configurations - Create」(ソフトウェア更新プログラムの構成 - 作成) をご覧ください。To learn how to create an Update Deployment with the REST API, see Software Update Configurations - Create. 週単位の更新プログラムのデプロイを作成するために使用できるサンプル Runbook もあります。There is also a sample runbook that can be used to create a weekly Update Deployment. この Runbook について詳しくは、「Create a weekly update deployment for one or more VMs in a resource group」(リソース グループ内の VM に対して週単位の更新プログラムのデプロイを作成する) をご覧ください。To learn more about this runbook, see Create a weekly update deployment for one or more VMs in a resource group.

注意

[再起動制御][再起動しない] に設定されている場合、[Registry keys used to manage restart](再起動の管理に使用するレジストリ キー) に一覧表示されているレジストリ キーにより再起動イベントが発生する場合があります。The Registry keys listed under Registry keys used to manage restart can cause a reboot event if Reboot Control is set to Never Reboot.

メンテナンス期間Maintenance Windows

メンテナンス期間によって、更新プログラムをインストールするために許容される時間を制御します。Maintenance windows control the amount of time allowed for updates to install. メンテナンス期間を指定するときは、次の点を考慮してください。Consider the following details when specifying a maintenance window.

  • メンテナンス期間によって、インストールを試みる更新プログラムの数が制御されます。Maintenance windows control how many updates are attempted to be installed.
  • メンテナンス期間の終了が近づいている場合でも、Update Management では、新しい更新プログラムのインストールは停止されません。Update Management does not stop installing new updates if the end of a maintenance window is approaching.
  • メンテナンス期間を超過した場合でも、Update Management では、進行中の更新は終了されません。Update Management does not terminate in-progress updates if when the maintenance window is exceeded.
  • Windows でメンテナンス期間が超過する理由は、多くの場合、Service Pack の更新プログラムのインストールに時間がかかるためです。If the maintenance window is exceeded on Windows, it is often because of a service pack update taking a long time to install.

テナント間の更新プログラムのデプロイCross-tenant Update Deployments

修正プログラムを適用する必要がある Update Management に報告する別の Azure テナントにマシンが存在する場合は、次の対処法を使用して、スケジュールを設定する必要があります。If you have machines in another Azure tenant reporting to Update Management that you need to patch, you'll need to use the following workaround to get them scheduled. スケジュールは、New-AzureRmAutomationSchedule コマンドレットと -ForUpdate スイッチを使用して作成できます。New-AzureRmAutomationSoftwareUpdateConfiguration コマンドレットを使用する際、-NonAzureComputer パラメーターに他のテナントのマシンを渡すことができます。You can use the New-AzureRmAutomationSchedule cmdlet with the switch -ForUpdate to create a schedule, and use the New-AzureRmAutomationSoftwareUpdateConfiguration cmdlet and pass the machines in the other tenant to the -NonAzureComputer parameter. 以下の例は、その方法を示しています。The following example shows an example on how to do this:

$nonAzurecomputers = @("server-01", "server-02")

$startTime = ([DateTime]::Now).AddMinutes(10)

$sched = New-AzureRmAutomationSchedule -ResourceGroupName mygroup -AutomationAccountName myaccount -Name myupdateconfig -Description test-OneTime -OneTime -StartTime $startTime -ForUpdate

New-AzureRmAutomationSoftwareUpdateConfiguration  -ResourceGroupName $rg -AutomationAccountName <automationAccountName> -Schedule $sched -Windows -NonAzureComputer $nonAzurecomputers -Duration (New-TimeSpan -Hours 2) -IncludedUpdateClassification Security,UpdateRollup -ExcludedKbNumber KB01,KB02 -IncludedKbNumber KB100

不足している更新プログラムを表示するView missing updates

[不足している更新プログラム] をクリックすると、ご利用のマシンで不足している更新プログラムの一覧が表示されます。Select Missing updates to view the list of updates that are missing from your machines. 各更新プログラムが表示され、選択することができます。Each update is listed and can be selected. 更新プログラムを必要とするマシンの数やオペレーティング システムに関する情報、および詳細情報にアクセスするためのリンクが表示されます。Information about the number of machines that require the update, the operating system, and a link for more information is shown. [ログ検索] ウィンドウには更新プログラムに関する詳細情報が表示されます。The Log search pane shows more details about the updates.

更新プログラムのデプロイを表示するView update deployments

[更新プログラムの展開] タブをクリックすると、既存の更新プログラムのデプロイの一覧が表示されます。Select the Update Deployments tab to view the list of existing update deployments. 表で更新プログラムのデプロイのいずれかをクリックすると、その更新プログラムのデプロイの [更新プログラムの展開の実行] ページが開きます。Select any of the update deployments in the table to open the Update Deployment Run pane for that update deployment. ジョブのログは、最大 30 日間保存されます。Job logs are stored for a max of 30 days.

更新プログラムのデプロイ結果の概要

REST API から更新プログラムのデプロイを表示する方法については、「Software Update Configuration Runs」(ソフトウェア更新プログラムの構成の実行) をご覧ください。To view an update deployment from the REST API, see Software Update Configuration Runs.

更新プログラムの分類Update classifications

次の表は、Update Management の更新プログラムの分類と、各分類の定義を示します。The following tables list the update classifications in Update Management, with a definition for each classification.

WindowsWindows

分類Classification 説明Description
緊急更新プログラムCritical updates セキュリティに関連しない重大なバグを修正する、特定の問題に対する更新プログラムです。An update for a specific problem that addresses a critical, non-security-related bug.
セキュリティ更新プログラムSecurity updates 製品固有のセキュリティに関連する問題に対する更新プログラムです。An update for a product-specific, security-related issue.
更新プログラムのロールアップUpdate rollups 容易なデプロイのためにパッケージにまとめられた修正プログラムの累積セットです。A cumulative set of hotfixes that are packaged together for easy deployment.
Feature PackFeature packs 製品リリース外で配布される製品の新機能です。New product features that are distributed outside a product release.
Service PackService packs アプリケーションに適用される修正プログラムの累積セットです。A cumulative set of hotfixes that are applied to an application.
定義の更新Definition updates ウイルスまたは他の定義ファイルに対する更新プログラムです。An update to virus or other definition files.
ツールTools 1 つまたは複数のタスクを完了するのに役立つユーティリティまたは機能です。A utility or feature that helps complete one or more tasks.
更新プログラムUpdates 現在インストールされているアプリケーションまたはファイルに対する更新プログラムです。An update to an application or file that currently is installed.

LinuxLinux

分類Classification 説明Description
緊急更新プログラムとセキュリティ更新プログラムCritical and security updates 特定の問題または製品固有のセキュリティに関連する問題に対する更新プログラムです。Updates for a specific problem or a product-specific, security-related issue.
他の更新プログラムOther updates 本質的に重要ではない、またはセキュリティ更新プログラムではない、他のすべての更新プログラムです。All other updates that aren't critical in nature or aren't security updates.

Linux の場合、クラウドでのデータ エンリッチメントにより、Update Management は、評価データを表示しながら、重要な更新プログラムとセキュリティ更新プログラムを識別できます。For Linux, Update Management can distinguish between critical and security updates in the cloud while displaying assessment data due to data enrichment in the cloud. 修正プログラムの場合、Update Management はマシン上にある分類データを使用します。For patching, Update Management relies on classification data available on the machine. 他のディストリビューションとは異なり CentOS では、既定ではこの情報は使用できません。Unlike other distributions, CentOS does not have this information available out of the box. CentOS マシンで、次のコマンドに対しセキュリティ データを返すように構成されている場合、Update Management は分類に基づいて修正プログラムを適用できます。If you have CentOS machines configured in a way to return security data for the following command, Update Management will be able to patch based on classifications.

sudo yum -q --security check-update

CentOS 上でネイティブ分類データを使用できるようにするためのサポートされている方法はありません。There's currently no method supported method to enable native classification-data availability on CentOS. 現時点では、独自の方法で分類データを使用するお客様には、できる範囲内のサポートのみを提供しています。At this time, only best-effort support is provided to customers who may have enabled this on their own.

詳細設定Advanced settings

Update Management は、Windows の更新プログラムのダウンロードとインストールに Windows Update を使用しています。Update Management relies on Windows Update to download and install Windows Updates. そのため、Windows Update で使用される多くの設定を尊重しています。As a result, we respect many of the settings used by Windows Update. Windows 以外の更新プログラムを有効にする設定を使用している場合、Update Management では、それらの更新プログラムも管理されます。If you use settings to enable non-Windows updates, Update Management will manage those updates as well. 更新プログラムの展開が行われる前の更新プログラムのダウンロードを有効にすると、更新プログラムの展開が速くなり、メンテナンス期間を超過する可能性が低くなります。If you want to enable downloading updates before an update deployment occurs, update deployments can go faster and be less likely to exceed the maintenance window.

更新プログラムの事前ダウンロードPre download updates

グループ ポリシーで更新プログラムを自動的にダウンロードするように構成するには、[自動更新を構成する] 設定を [3] に設定します。To configure automatically downloading updates in Group Policy, you can set the Configure Automatic Updates setting to 3. これで、必要な更新プログラムはバックグラウンドでダウンロードされますが、インストールされません。This downloads the updates needed in the background, but doesn't install them. そのため、Update Management のスケジュールを管理しながら、更新プログラムの管理のメンテナンス期間以外に更新プログラムをダウンロードできます。This keeps Update Management in control of schedules but allow updates to download outside of the Update Management maintenance window. この方法で Update Management の "メンテナンス期間を超過しました" エラーを防ぐことができます。This can prevent Maintenance window exceeded errors in Update Management.

この設定は PowerShell で行うこともできます。更新プログラムを自動ダウンロードするシステム上で、次の PowerShell を実行してください。You can also set this with PowerShell, run the following PowerShell on a system that you want to auto-download updates.

$WUSettings = (New-Object -com "Microsoft.Update.AutoUpdate").Settings
$WUSettings.NotificationLevel = 3
$WUSettings.Save()

自動インストールを無効化するDisable automatic installation

Azure VM では、更新プログラムの自動インストールが既定で有効になっています。Azure VMs have Automatic installation of updates enabled by default. そのため、更新プログラムは、Update Management によってインストールされるようにユーザーがスケジュールする前に、インストールされる可能性があります。This can cause updates to be installed before you schedule them to be installed by Update Management. この動作は、NoAutoUpdate レジストリ キーを 1 に設定すると無効化できます。You can disable this behavior by setting the NoAutoUpdate registry key to 1. 次の PowerShell スニペットは、この操作を行う 1 つの方法を示しています。The following PowerShell snippet shows you one way to do this.

$AutoUpdatePath = "HKLM:SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"
Set-ItemProperty -Path $AutoUpdatePath -Name NoAutoUpdate -Value 1

他の Microsoft 製品の更新プログラムを有効にするEnable updates for other Microsoft products

既定では、Windows Update は Windows の更新プログラムのみを提供します。By default, Windows Update only provides updates for Windows. [Windows の更新時に他の Microsoft 製品の更新プログラムも入手します] をオンにすると、SQL Server や他のファースト パーティ ソフトウェアのセキュリティ修正プログラムなど、他の製品の更新プログラムも提供されます。If you enable Give me updates for other Microsoft products when I update Windows, you're provided with updates for other products, including security patches for SQL Server or other first party software. このオプションをグループ ポリシーで構成することはできません。This option can't be configured by Group Policy. 他のファースト パーティの修正プログラムを有効にするシステム上で次の PowerShell を実行すると、Update Management はその設定に従います。Run the following PowerShell on the systems that you wish to enable other first party patches on, and Update Management will honor this setting.

$ServiceManager = (New-Object -com "Microsoft.Update.ServiceManager")
$ServiceManager.Services
$ServiceID = "7971f918-a847-4430-9279-4a52d1efe18d"
$ServiceManager.AddService2($ServiceId,7,"")

Windows でのサード パーティの修正プログラムThird-party patches on Windows

Update Management は、サポート対象の Windows システムへの修正プログラムの適用を、ローカルに構成された更新リポジトリに依存しています。Update Management relies on the locally configured update repository to patch supported Windows systems. これは、WSUS または Windows Update のいずれかです。This is either WSUS or Windows Update. System Center Updates Publisher (Updates Publisher) などのツールを使用すれば、カスタム更新プログラムを WSUS に公開できます。Tools like System Center Updates Publisher (Updates Publisher) allow you to publish custom updates into WSUS. このシナリオでは、サード パーティ製ソフトウェアで System Center Configuration Manager を更新リポジトリとして使用するマシンに、Update Management で修正プログラムを適用できます。This scenario allows Update Management to patch machines that use System Center Configuration Manager as their update repository with third-party software. Updates Publisher を構成する方法については、「Install Updates Publisher」(Updates Publisher のインストール) を参照してください。To learn how to configure Updates Publisher, see Install Updates Publisher.

ネットワークの計画Network Planning

Update Management には次のアドレスが明示的に必要です。The following addresses are required specifically for Update Management. このアドレスへの通信は、ポート 443 を使用して行われます。Communication to these addresses occurs over port 443.

Azure PublicAzure Public Azure GovernmentAzure Government
*.ods.opinsights.azure.com*.ods.opinsights.azure.com *.ods.opinsights.azure.us*.ods.opinsights.azure.us
*.oms.opinsights.azure.com*.oms.opinsights.azure.com *.oms.opinsights.azure.us*.oms.opinsights.azure.us
*.blob.core.windows.net*.blob.core.windows.net *.blob.core.usgovcloudapi.net*.blob.core.usgovcloudapi.net
*.azure-automation.net*.azure-automation.net *.azure-automation.us*.azure-automation.us

Windows コンピューターの場合は、Windows Update で必要なすべてのエンドポイントへのトラフィックも許可する必要があります。For Windows Machines, you must also allow traffic to any endpoints required by Windows Update. 必要なエンドポイントの更新された一覧は、「HTTP またはプロキシに関連する問題」で確認できます。You can find an updated list of required endpoints in Issues related to HTTP/Proxy. ローカル環境に Windows Update サーバーがある場合は、WSUS キーで指定されているサーバーへのトラフィックも許可する必要があります。If you have a local Windows Update Server, you must also allow traffic to the server specified in your WSUS Key.

Red Hat Linux コンピューターで必要なエンドポイントについては、「RHUI コンテンツ配信サーバーの IP アドレス」をご覧ください。For Red Hat Linux Machines, please refer to The IPs for the RHUI content delivery servers for required endpoints. 他の Linux ディストリビューションについては、プロバイダーのドキュメントをご覧ください。For other Linux Distributions, refer to provider documentation.

Hybrid Runbook Worker で必要なポートの詳細については、ハイブリッド worker ロールのポートに関するページをご覧ください。For more information about ports that the Hybrid Runbook Worker requires, see Hybrid Worker role ports.

例外を定義するときは、一覧に示されているアドレスを使用することをお勧めします。It's recommended to use the addresses listed when defining exceptions. Microsoft Azure データセンターの IP 範囲の IP アドレスをダウンロードできます。For IP addresses you can download the Microsoft Azure Datacenter IP Ranges. このファイルは毎週更新され、現在デプロイされている範囲と今後変更される IP 範囲が反映されます。This file is updated weekly, and reflects the currently deployed ranges and any upcoming changes to the IP ranges.

インターネットにアクセスできないコンピューターの接続に関するページの手順に従って、インターネットにアクセスできないマシンを構成します。Follow the instructions in Connect computers without internet access to configure machines that do not have internet access.

検索ログSearch logs

Azure Portal で提供されている詳細情報に加え、ログに対する検索を実行できます。In addition to the details that are provided in the Azure portal, you can do searches against the logs. ソリューション ページで [Log Analytics] を選択します。On the solution pages, select Log Analytics. [ログ検索] ウィンドウが開きます。The Log Search pane opens.

クエリをカスタマイズする方法や、さまざまなクライアントから使用する方法などについては、Log Analytics の検索 API のドキュメントを参照してください。You can also learn how to customize the queries or use them from different clients and more by visiting: Log Analytics search API documentation.

サンプル クエリSample queries

以下のセクションは、このソリューションによって収集された更新レコードのログ クエリの例です。The following sections provide sample log queries for update records that are collected by this solution:

単一の Azure VM 評価クエリ (Windows)Single Azure VM Assessment queries (Windows)

VMUUID 値を、クエリの対象である仮想マシンの VM GUID に置き換えます。Replace the VMUUID value with the VM GUID of the virtual machine you're querying. Azure Monitor ログで次のクエリを実行することで、使用する必要がある VMUUID を確認できます。Update | where Computer == "<machine name>" | summarize by Computer, VMUUIDYou can find the VMUUID that should be used by running the following query in Azure Monitor logs: Update | where Computer == "<machine name>" | summarize by Computer, VMUUID

不足している更新プログラムの概要Missing updates summary
Update
| where TimeGenerated>ago(14h) and OSType!="Linux" and (Optional==false or Classification has "Critical" or Classification has "Security") and VMUUID=~"b08d5afa-1471-4b52-bd95-a44fea6e4ca8"
| summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification, Approved) by Computer, SourceComputerId, UpdateID
| where UpdateState=~"Needed" and Approved!=false
| summarize by UpdateID, Classification
| summarize allUpdatesCount=count(), criticalUpdatesCount=countif(Classification has "Critical"), securityUpdatesCount=countif(Classification has "Security"), otherUpdatesCount=countif(Classification !has "Critical" and Classification !has "Security")
不足している更新プログラム一覧Missing updates list
Update
| where TimeGenerated>ago(14h) and OSType!="Linux" and (Optional==false or Classification has "Critical" or Classification has "Security") and VMUUID=~"8bf1ccc6-b6d3-4a0b-a643-23f346dfdf82"
| summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification, Title, KBID, PublishedDate, Approved) by Computer, SourceComputerId, UpdateID
| where UpdateState=~"Needed" and Approved!=false
| project-away UpdateState, Approved, TimeGenerated
| summarize computersCount=dcount(SourceComputerId, 2), displayName=any(Title), publishedDate=min(PublishedDate), ClassificationWeight=max(iff(Classification has "Critical", 4, iff(Classification has "Security", 2, 1))) by id=strcat(UpdateID, "_", KBID), classification=Classification, InformationId=strcat("KB", KBID), InformationUrl=iff(isnotempty(KBID), strcat("https://support.microsoft.com/kb/", KBID), ""), osType=2
| sort by ClassificationWeight desc, computersCount desc, displayName asc
| extend informationLink=(iff(isnotempty(InformationId) and isnotempty(InformationUrl), toobject(strcat('{ "uri": "', InformationUrl, '", "text": "', InformationId, '", "target": "blank" }')), toobject('')))
| project-away ClassificationWeight, InformationId, InformationUrl

単一の Azure VM 評価クエリ (Linux)Single Azure VM assessment queries (Linux)

Linux のディストリビューションによっては、Azure Resource Manager に由来する VMUUID 値と、Azure Monitor ログに格納されている値との間でエンディアンが一致しない場合があります。For some Linux distros, there is a endianness mismatch with the VMUUID value that comes from Azure Resource Manager and what is stored in Azure Monitor logs. 次のクエリは、いずれかのエンディアンでの一致をチェックします。The following query checks for a match on either endianness. 結果を適切に返すために、VMUUID 値を GUID のビッグエンディアン形式とリトルエンディアン形式に置き換えます。Replace the VMUUID values with the big-endian and little-endian format of the GUID to properly return the results. Azure Monitor ログで次のクエリを実行することで、使用する必要がある VMUUID を確認できます。Update | where Computer == "<machine name>" | summarize by Computer, VMUUIDYou can find the VMUUID that should be used by running the following query in Azure Monitor logs: Update | where Computer == "<machine name>" | summarize by Computer, VMUUID

不足している更新プログラムの概要Missing updates summary
Update
| where TimeGenerated>ago(5h) and OSType=="Linux" and (VMUUID=~"625686a0-6d08-4810-aae9-a089e68d4911" or VMUUID=~"a0865662-086d-1048-aae9-a089e68d4911")
| summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification) by Computer, SourceComputerId, Product, ProductArch
| where UpdateState=~"Needed"
| summarize by Product, ProductArch, Classification
| summarize allUpdatesCount=count(), criticalUpdatesCount=countif(Classification has "Critical"), securityUpdatesCount=countif(Classification has "Security"), otherUpdatesCount=countif(Classification !has "Critical" and Classification !has "Security")
不足している更新プログラム一覧Missing updates list
Update
| where TimeGenerated>ago(5h) and OSType=="Linux" and (VMUUID=~"625686a0-6d08-4810-aae9-a089e68d4911" or VMUUID=~"a0865662-086d-1048-aae9-a089e68d4911")
| summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification, BulletinUrl, BulletinID) by Computer, SourceComputerId, Product, ProductArch
| where UpdateState=~"Needed"
| project-away UpdateState, TimeGenerated
| summarize computersCount=dcount(SourceComputerId, 2), ClassificationWeight=max(iff(Classification has "Critical", 4, iff(Classification has "Security", 2, 1))) by id=strcat(Product, "_", ProductArch), displayName=Product, productArch=ProductArch, classification=Classification, InformationId=BulletinID, InformationUrl=tostring(split(BulletinUrl, ";", 0)[0]), osType=1
| sort by ClassificationWeight desc, computersCount desc, displayName asc
| extend informationLink=(iff(isnotempty(InformationId) and isnotempty(InformationUrl), toobject(strcat('{ "uri": "', InformationUrl, '", "text": "', InformationId, '", "target": "blank" }')), toobject('')))
| project-away ClassificationWeight, InformationId, InformationUrl

マルチ VM の評価クエリMulti-VM assessment queries

コンピューターの概要Computers summary
Heartbeat
| where TimeGenerated>ago(12h) and OSType=~"Windows" and notempty(Computer)
| summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
| where Solutions has "updates"
| distinct SourceComputerId
| join kind=leftouter
(
    Update
    | where TimeGenerated>ago(14h) and OSType!="Linux"
    | summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Approved, Optional, Classification) by SourceComputerId, UpdateID
    | distinct SourceComputerId, Classification, UpdateState, Approved, Optional
    | summarize WorstMissingUpdateSeverity=max(iff(UpdateState=~"Needed" and (Optional==false or Classification has "Critical" or Classification has "Security") and Approved!=false, iff(Classification has "Critical", 4, iff(Classification has "Security", 2, 1)), 0)) by SourceComputerId
)
on SourceComputerId
| extend WorstMissingUpdateSeverity=coalesce(WorstMissingUpdateSeverity, -1)
| summarize computersBySeverity=count() by WorstMissingUpdateSeverity
| union (Heartbeat
| where TimeGenerated>ago(12h) and OSType=="Linux" and notempty(Computer)
| summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
| where Solutions has "updates"
| distinct SourceComputerId
| join kind=leftouter
(
    Update
    | where TimeGenerated>ago(5h) and OSType=="Linux"
    | summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification) by SourceComputerId, Product, ProductArch
    | distinct SourceComputerId, Classification, UpdateState
    | summarize WorstMissingUpdateSeverity=max(iff(UpdateState=~"Needed", iff(Classification has "Critical", 4, iff(Classification has "Security", 2, 1)), 0)) by SourceComputerId
)
on SourceComputerId
| extend WorstMissingUpdateSeverity=coalesce(WorstMissingUpdateSeverity, -1)
| summarize computersBySeverity=count() by WorstMissingUpdateSeverity)
| summarize assessedComputersCount=sumif(computersBySeverity, WorstMissingUpdateSeverity>-1), notAssessedComputersCount=sumif(computersBySeverity, WorstMissingUpdateSeverity==-1), computersNeedCriticalUpdatesCount=sumif(computersBySeverity, WorstMissingUpdateSeverity==4), computersNeedSecurityUpdatesCount=sumif(computersBySeverity, WorstMissingUpdateSeverity==2), computersNeedOtherUpdatesCount=sumif(computersBySeverity, WorstMissingUpdateSeverity==1), upToDateComputersCount=sumif(computersBySeverity, WorstMissingUpdateSeverity==0)
| summarize assessedComputersCount=sum(assessedComputersCount), computersNeedCriticalUpdatesCount=sum(computersNeedCriticalUpdatesCount),  computersNeedSecurityUpdatesCount=sum(computersNeedSecurityUpdatesCount), computersNeedOtherUpdatesCount=sum(computersNeedOtherUpdatesCount), upToDateComputersCount=sum(upToDateComputersCount), notAssessedComputersCount=sum(notAssessedComputersCount)
| extend allComputersCount=assessedComputersCount+notAssessedComputersCount


不足している更新プログラムの概要Missing updates summary
Update
| where TimeGenerated>ago(5h) and OSType=="Linux" and SourceComputerId in ((Heartbeat
| where TimeGenerated>ago(12h) and OSType=="Linux" and notempty(Computer)
| summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
| where Solutions has "updates"
| distinct SourceComputerId))
| summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification) by Computer, SourceComputerId, Product, ProductArch
| where UpdateState=~"Needed"
| summarize by Product, ProductArch, Classification
| union (Update
| where TimeGenerated>ago(14h) and OSType!="Linux" and (Optional==false or Classification has "Critical" or Classification has "Security") and SourceComputerId in ((Heartbeat
| where TimeGenerated>ago(12h) and OSType=~"Windows" and notempty(Computer)
| summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
| where Solutions has "updates"
| distinct SourceComputerId))
| summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification, Approved) by Computer, SourceComputerId, UpdateID
| where UpdateState=~"Needed" and Approved!=false
| summarize by UpdateID, Classification )
| summarize allUpdatesCount=count(), criticalUpdatesCount=countif(Classification has "Critical"), securityUpdatesCount=countif(Classification has "Security"), otherUpdatesCount=countif(Classification !has "Critical" and Classification !has "Security")
コンピューター一覧Computers list
Heartbeat
| where TimeGenerated>ago(12h) and OSType=="Linux" and notempty(Computer)
| summarize arg_max(TimeGenerated, Solutions, Computer, ResourceId, ComputerEnvironment, VMUUID) by SourceComputerId
| where Solutions has "updates"
| extend vmuuId=VMUUID, azureResourceId=ResourceId, osType=1, environment=iff(ComputerEnvironment=~"Azure", 1, 2), scopedToUpdatesSolution=true, lastUpdateAgentSeenTime=""
| join kind=leftouter
(
    Update
    | where TimeGenerated>ago(5h) and OSType=="Linux" and SourceComputerId in ((Heartbeat
    | where TimeGenerated>ago(12h) and OSType=="Linux" and notempty(Computer)
    | summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
    | where Solutions has "updates"
    | distinct SourceComputerId))
    | summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification, Product, Computer, ComputerEnvironment) by SourceComputerId, Product, ProductArch
    | summarize Computer=any(Computer), ComputerEnvironment=any(ComputerEnvironment), missingCriticalUpdatesCount=countif(Classification has "Critical" and UpdateState=~"Needed"), missingSecurityUpdatesCount=countif(Classification has "Security" and UpdateState=~"Needed"), missingOtherUpdatesCount=countif(Classification !has "Critical" and Classification !has "Security" and UpdateState=~"Needed"), lastAssessedTime=max(TimeGenerated), lastUpdateAgentSeenTime="" by SourceComputerId
    | extend compliance=iff(missingCriticalUpdatesCount > 0 or missingSecurityUpdatesCount > 0, 2, 1)
    | extend ComplianceOrder=iff(missingCriticalUpdatesCount > 0 or missingSecurityUpdatesCount > 0 or missingOtherUpdatesCount > 0, 1, 3)
)
on SourceComputerId
| project id=SourceComputerId, displayName=Computer, sourceComputerId=SourceComputerId, scopedToUpdatesSolution=true, missingCriticalUpdatesCount=coalesce(missingCriticalUpdatesCount, -1), missingSecurityUpdatesCount=coalesce(missingSecurityUpdatesCount, -1), missingOtherUpdatesCount=coalesce(missingOtherUpdatesCount, -1), compliance=coalesce(compliance, 4), lastAssessedTime, lastUpdateAgentSeenTime, osType=1, environment=iff(ComputerEnvironment=~"Azure", 1, 2), ComplianceOrder=coalesce(ComplianceOrder, 2)
| union(Heartbeat
| where TimeGenerated>ago(12h) and OSType=~"Windows" and notempty(Computer)
| summarize arg_max(TimeGenerated, Solutions, Computer, ResourceId, ComputerEnvironment, VMUUID) by SourceComputerId
| where Solutions has "updates"
| extend vmuuId=VMUUID, azureResourceId=ResourceId, osType=2, environment=iff(ComputerEnvironment=~"Azure", 1, 2), scopedToUpdatesSolution=true, lastUpdateAgentSeenTime=""
| join kind=leftouter
(
    Update
    | where TimeGenerated>ago(14h) and OSType!="Linux" and SourceComputerId in ((Heartbeat
    | where TimeGenerated>ago(12h) and OSType=~"Windows" and notempty(Computer)
    | summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
    | where Solutions has "updates"
    | distinct SourceComputerId))
    | summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification, Title, Optional, Approved, Computer, ComputerEnvironment) by Computer, SourceComputerId, UpdateID
    | summarize Computer=any(Computer), ComputerEnvironment=any(ComputerEnvironment), missingCriticalUpdatesCount=countif(Classification has "Critical" and UpdateState=~"Needed" and Approved!=false), missingSecurityUpdatesCount=countif(Classification has "Security" and UpdateState=~"Needed" and Approved!=false), missingOtherUpdatesCount=countif(Classification !has "Critical" and Classification !has "Security" and UpdateState=~"Needed" and Optional==false and Approved!=false), lastAssessedTime=max(TimeGenerated), lastUpdateAgentSeenTime="" by SourceComputerId
    | extend compliance=iff(missingCriticalUpdatesCount > 0 or missingSecurityUpdatesCount > 0, 2, 1)
    | extend ComplianceOrder=iff(missingCriticalUpdatesCount > 0 or missingSecurityUpdatesCount > 0 or missingOtherUpdatesCount > 0, 1, 3)
)
on SourceComputerId
| project id=SourceComputerId, displayName=Computer, sourceComputerId=SourceComputerId, scopedToUpdatesSolution=true, missingCriticalUpdatesCount=coalesce(missingCriticalUpdatesCount, -1), missingSecurityUpdatesCount=coalesce(missingSecurityUpdatesCount, -1), missingOtherUpdatesCount=coalesce(missingOtherUpdatesCount, -1), compliance=coalesce(compliance, 4), lastAssessedTime, lastUpdateAgentSeenTime, osType=2, environment=iff(ComputerEnvironment=~"Azure", 1, 2), ComplianceOrder=coalesce(ComplianceOrder, 2) )
| order by ComplianceOrder asc, missingCriticalUpdatesCount desc, missingSecurityUpdatesCount desc, missingOtherUpdatesCount desc, displayName asc
| project-away ComplianceOrder
不足している更新プログラム一覧Missing updates list
Update
| where TimeGenerated>ago(5h) and OSType=="Linux" and SourceComputerId in ((Heartbeat
| where TimeGenerated>ago(12h) and OSType=="Linux" and notempty(Computer)
| summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
| where Solutions has "updates"
| distinct SourceComputerId))
| summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification, BulletinUrl, BulletinID) by SourceComputerId, Product, ProductArch
| where UpdateState=~"Needed"
| project-away UpdateState, TimeGenerated
| summarize computersCount=dcount(SourceComputerId, 2), ClassificationWeight=max(iff(Classification has "Critical", 4, iff(Classification has "Security", 2, 1))) by id=strcat(Product, "_", ProductArch), displayName=Product, productArch=ProductArch, classification=Classification, InformationId=BulletinID, InformationUrl=tostring(split(BulletinUrl, ";", 0)[0]), osType=1
| union(Update
| where TimeGenerated>ago(14h) and OSType!="Linux" and (Optional==false or Classification has "Critical" or Classification has "Security") and SourceComputerId in ((Heartbeat
| where TimeGenerated>ago(12h) and OSType=~"Windows" and notempty(Computer)
| summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
| where Solutions has "updates"
| distinct SourceComputerId))
| summarize hint.strategy=partitioned arg_max(TimeGenerated, UpdateState, Classification, Title, KBID, PublishedDate, Approved) by Computer, SourceComputerId, UpdateID
| where UpdateState=~"Needed" and Approved!=false
| project-away UpdateState, Approved, TimeGenerated
| summarize computersCount=dcount(SourceComputerId, 2), displayName=any(Title), publishedDate=min(PublishedDate), ClassificationWeight=max(iff(Classification has "Critical", 4, iff(Classification has "Security", 2, 1))) by id=strcat(UpdateID, "_", KBID), classification=Classification, InformationId=strcat("KB", KBID), InformationUrl=iff(isnotempty(KBID), strcat("https://support.microsoft.com/kb/", KBID), ""), osType=2)
| sort by ClassificationWeight desc, computersCount desc, displayName asc
| extend informationLink=(iff(isnotempty(InformationId) and isnotempty(InformationUrl), toobject(strcat('{ "uri": "', InformationUrl, '", "text": "', InformationId, '", "target": "blank" }')), toobject('')))
| project-away ClassificationWeight, InformationId, InformationUrl

動的グループの使用Using dynamic groups

Update Management では、Azure または Azure 以外の VM の動的グループを更新プログラムのデプロイの対象にする機能が提供されています。Update Management provides the ability to target a dynamic group of Azure or Non-Azure VMs for update deployments. これらのグループはデプロイ時に評価されるため、マシンを追加するためにデプロイを編集する必要はありません。These groups are evaluated at deployment time so you do not have to edit your deployment to add machines.

注意

更新プログラムのデプロイを作成するには、適切なアクセス許可が必要です。You must have the proper permissions when creating an update deployment. 詳細については、「更新プログラムをインストールする」を参照してください。To learn more, see Install Updates.

Azure マシンAzure machines

これらのグループはクエリによって定義され、更新プログラムのデプロイが開始するときに、そのグループのメンバーが評価されます。These groups are defined by a query, when an update deployment begins, the members of that group are evaluated. 動的なグループは、クラシック VM では動作しません。Dynamic groups do not work with classic VMs. クエリを定義するときに、次の項目をまとめて使用して動的グループを設定できます。When defining your query, the following items can be used together to populate the dynamic group

  • SubscriptionSubscription
  • リソース グループResource groups
  • 場所Locations
  • TagsTags

グループを選択する

動的グループの結果をプレビューするには、 [プレビュー] ボタンをクリックします。To preview the results of a dynamic group, click the Preview button. このプレビューでは、その時点でのグループのメンバーシップが表示されます。この例では、タグ RoleBackendServer に等しいマシンを検索しています。This preview shows the group membership at that time, in this example, we are searching for machines with the tag Role is equal to BackendServer. このタグを持つマシンがさらに追加された場合、そのグループに対する将来のデプロイに追加されます。If more machines have this tag added, they will be added to any future deployments against that group.

グループをプレビューする

Azure 以外のマシンNon-Azure machines

Azure 以外のマシンの場合、動的グループの作成にコンピューター グループが使用されるため、保存された検索も参照されます。For Non-Azure machines, saved searches also referred to as computer groups are used to create the dynamic group. 保存された検索の作成方法については、「コンピューター グループの作成」を参照してください。To learn how to create a saved search, see Creating a computer group. グループを作成した後は、保存された検索の一覧からそのグループを選択できます。Once your group is created you can select it from the list of saved searches. [プレビュー] をクリックすると、保存された検索でのその時点でのコンピューターをプレビューできます。Click Preview to preview the computers in the saved search at that time.

グループを選択する

System Center Configuration Manager との統合Integrate with System Center Configuration Manager

PC、サーバー、モバイル デバイスを管理するために System Center Configuration Manager に投資してきたお客様は、Configuration Manager の強みと成熟度を活用してソフトウェア更新プログラムを管理できます。Customers who have invested in System Center Configuration Manager for managing PCs, servers, and mobile devices also rely on the strength and maturity of Configuration Manager to help them manage software updates. Configuration Manager は、そのソフトウェア更新プログラムの管理 (SUM) サイクルの一部です。Configuration Manager is part of their software update management (SUM) cycle.

管理ソリューションを System Center Configuration Manager と統合する方法については、「System Center Configuration Manager と Update Management の統合」を参照してください。To learn how to integrate the management solution with System Center Configuration Manager, see Integrate System Center Configuration Manager with Update Management.

包含の動作Inclusion behavior

更新プログラムの包含では、適用する特定の更新プログラムを指定できます。Update inclusion allows you to specify specific updates to apply. 包含されている修正プログラムまたはパッケージがインストールされます。Patches or packages that are included are installed. 修正プログラムまたはパッケージが包含されていて、分類も選択されていると、包含されるアイテムと分類に一致するアイテムの両方がインストールされます。When Patches or packages are included and a classification is selected as well, both the included items and items that meet the classification are installed.

包含より除外の方が優先されることを知っておく必要があります。It is important to know that exclusions override inclusions. たとえば、除外ルール * を定義した場合、修正プログラムまたはパッケージはすべて除外されるためインストールされません。For instance, if you define an exclusion rule of *, then no patches or packages are installed as they are all excluded. 除外されたパッチは、マシンに不足しているものとして表示されます。Excluded patches still show as missing from the machine. Linux マシンでは、包含されているパッケージに除外された依存パッケージがある場合、パッケージはインストールされません。For Linux machines if a package is included but has a dependant package that was excluded, the package is not installed.

Linux マシンのパッチPatch Linux machines

次のセクションでは、Linux のパッチ適用に関する潜在的な問題について説明します。The following sections explain potential issues with Linux patching.

予期しない OS レベルのアップグレードUnexpected OS-level upgrades

Red Hat Enterprise Linux など、Linux バリエーションの中には、パッケージによって OS レベルのアップグレードが発生することがあります。On some Linux variants, such as Red Hat Enterprise Linux, OS-level upgrades might occur via packages. これにより、OS バージョン番号の変更を伴う Update Management が実行される可能性があります。This might lead to Update Management runs where the OS version number changes. Update Management がパッケージを更新するときに使用する方法は、管理者がローカルで Linux コンピューターに使用する方法と同じであるため、この動作は意図的なものです。Because Update Management uses the same methods to update packages that an administrator would use locally on the Linux computer, this behavior is intentional.

Update Management の実行による OS バージョンの更新を回避するには、除外機能を使用します。To avoid updating the OS version via Update Management runs, use the Exclusion feature.

Red Hat Enterprise Linux で、除外するパッケージ名は redhat-release-server.x86_64 ですIn Red Hat Enterprise Linux, the package name to exclude is redhat-release-server.x86_64.

Linux の除外するパッケージ

重要なパッチまたはセキュリティ パッチが適用されないCritical / security patches aren't applied

更新プログラムを Linux マシンにデプロイする場合、更新プログラムの分類を選択できます。When you deploy updates to a Linux machine, you can select update classifications. これにより、更新プログラムは、指定した条件を満たすマシンにのみ適用されるようにフィルター処理されます。This filters the updates that are applied to the machine that meet the specified criteria. このフィルターは、更新プログラムが展開されるときに、マシンに対してローカルに適用されます。This filter is applied locally on the machine when the update is deployed.

Update Management は更新プログラムの強化をクラウドで実行するため、Update Management では、一部の更新プログラムに "セキュリティへの影響あり" のフラグが設定されることがありますが、ローカル マシンにはその情報がありません。Because Update Management performs update enrichment in the cloud, some updates can be flagged in Update Management as having security impact, even though the local machine doesn't have that information. このため、重大な更新プログラムを Linux マシンに適用する場合、そのマシンの "セキュリティへの影響あり" とマークされていない更新プログラムが存在する可能性があり、これらは適用されません。As a result, if you apply critical updates to a Linux machine, there might be updates that aren't marked as having security impact on that machine and the updates aren't applied.

ただし、Update Management には関連更新プログラムに関する追加情報があるため、そのマシンは引き続き "非対応" として報告されることがあります。However, Update Management might still report that machine as being non-compliant because it has additional information about the relevant update.

更新プログラムの分類ごとの更新プログラムのデプロイは CentOS では既定では動作しません。Deploying updates by update classification doesn't work on CentOS out of the box. CentOS 用の更新プログラムを正しく展開するには、更新プログラムが確実に適用されるように、すべての分類を選択します。To properly deploy updates for CentOS, select all classifications to ensure updates are applied. SUSE で '他の更新プログラム' のみを分類として選択すると、zypper (パッケージ マネージャー) に関連するセキュリティ更新プログラムもインストールされるか、またはその依存関係がまず必要になる場合があります。For SUSE, selecting only 'Other updates' as the classification may result in some security updates also being installed if security updates related to zypper (package manager) or its dependencies are required first. この動作は、zypper の制限です。This behavior is a limitation of zypper. 場合によっては、更新プログラムのデプロイを再実行する必要があります。In some cases, you may be required to rerun the update deployment. 確認するには、更新プログラムのログを調べてください。To verify, check the update log.

Update Management から VM を削除するRemove a VM from Update Management

Update Management から VM を削除するには:To remove a VM from Update Management:

  • Log Analytics ワークスペースで、スコープ構成 MicrosoftDefaultScopeConfig-Updates の保存された検索条件から VM を削除します。In your Log Analytics workspace, remove the VM from the saved search for the Scope Configuration MicrosoftDefaultScopeConfig-Updates. 保存された検索条件は、ワークスペース内の [全般] にあります。Saved searches can be found under General in your workspace.
  • Microsoft Monitoring Agent または Linux 用 Log Analytics エージェントを削除します。Remove the Microsoft Monitoring agent or the Log Analytics agent for Linux.

次の手順Next steps

使用している Windows 仮想マシンの更新プログラムの管理方法を学習するためのチュートリアルに進みます。Continue to the tutorial to learn how to manage updates for your Windows virtual machines.