Merge pull request #301252 from MicrosoftDocs/main

6/12/2025 AM Publish

Author: Taojunshen

articles/automation/automation-create-standalone-account.md

@@ -48,7 +48,7 @@ The following table describes the fields on the **Basics** tab.
 |---|---|---|
 |Subscription|Required |From the drop-down list, select the Azure subscription for the account.|
 |Resource group|Required |From the drop-down list, select your existing resource group, or select **Create new**.|
-|Automation account name|Required |Enter a name unique for it's location and resource group. Names for Automation accounts that have been deleted might not be immediately available. You can't change the account name once it has been entered in the user interface. |
+|Automation account name|Required |Enter a name unique for its location and resource group. Names for Automation accounts that have been deleted might not be immediately available. You can't change the account name once it has been entered in the user interface. |
 |Region|Required |From the drop-down list, select a region for the account. For an updated list of locations that you can deploy an Automation account to, see [Products available by region](https://azure.microsoft.com/global-infrastructure/services/?products=automation&regions=all).|
 
 The following image shows a standard configuration for a new Automation account.
@@ -68,7 +68,7 @@ The following table describes the fields on the **Advanced** tab.
 |System-assigned |Optional |A Microsoft Entra identity that is tied to the lifecycle of the Automation account. |
 |User-assigned |Optional |A managed identity represented as a standalone Azure resource that is managed separately from the resources that use it.|
 
-You can chose to enable managed identities later, and the Automation account is created without one. To enable a managed identity after the account is created, see [Enable managed identity](enable-managed-identity-for-automation.md). If you select both options, for the user-assigned identity, select the **Add user assigned identities** option. On the **Select user assigned managed identity** page, select a subscription and add one or more user-assigned identities created in that subscription to assign to the Automation account.
+You can choose to enable managed identities later, and the Automation account is created without one. To enable a managed identity after the account is created, see [Enable managed identity](enable-managed-identity-for-automation.md). If you select both options, for the user-assigned identity, select the **Add user assigned identities** option. On the **Select user assigned managed identity** page, select a subscription and add one or more user-assigned identities created in that subscription to assign to the Automation account.
 
 The following image shows a standard configuration for a new Automation account.
 
@@ -109,7 +109,7 @@ When the Automation account is successfully created, several resources are autom
 
 ## Manage Automation account keys
 
-When you create an Automation account, Azure generates two 512-bit automation account access keys for that account. These keys are shared access keys that are used as registration keys for registering [DSC nodes](./automation-dsc-onboarding.md#use-dsc-metaconfiguration-to-register-hybrid-machines) as well as [Windows](./automation-windows-hrw-install.md#manual-deployment) and [Linux](./automation-linux-hrw-install.md#manually-run-powershell-commands) Hybrid runbook workers. These keys are only used while registering DSC nodes and Hybrid workers. Existing machines configured as DSC nodes or hybrid workers won’t be affected after rotation of these keys. 
+When you create an Automation account, Azure generates two 512-bit automation account access keys for that account. These keys are shared access keys that are used as registration keys for registering [DSC nodes](./automation-dsc-onboarding.md#use-dsc-metaconfiguration-to-register-hybrid-machines) These keys are only used while registering DSC nodes. Existing machines configured as DSC nodes or hybrid workers won’t be affected after rotation of these keys. 
 
 ### View Automation account keys
 
@@ -124,7 +124,7 @@ You can use any of the two keys to access your Automation account. However, we r
 
 We recommend that you rotate your access keys periodically to keep the Automation account secure. As you have two access keys, you can rotate them using Azure portal or Azure PowerShell cmdlet.
 
-Choose a client
+Choose a client:
 
 # [Azure portal](#tab/azureportal)
 

articles/automation/automation-disaster-recovery.md

@@ -47,30 +47,12 @@ If the Windows or Linux Hybrid Runbook worker is deployed using the extension-ba
 1. [Add](extension-based-hybrid-runbook-worker-install.md?tabs=windows#create-hybrid-worker-group) the same Hybrid Runbook worker to a Hybrid Worker group in the Automation account in the secondary region. The Hybrid worker extension is installed on the machine in the replica of the Automation account.
 1. Execute the jobs on the Hybrid Runbook worker created in Step 2.
 
-For Hybrid Runbook worker deployed using the agent-based approach, choose from below:
-
-#### [Windows Hybrid Runbook worker](#tab/win-hrw)
-
-If the Windows Hybrid Runbook worker is deployed using an agent-based approach in a region different from the primary region of failure, follow the steps to continue executing Hybrid jobs: 
-1. [Uninstall](automation-windows-hrw-install.md#remove-windows-hybrid-runbook-worker) the agent from the Hybrid Runbook worker present in the Automation account in the primary region. 
-1. [Re-install](automation-windows-hrw-install.md#installation-options) the agent on the same machine in the replica Automation account in the secondary region. 
-1. You can now execute jobs on the Hybrid Runbook worker created in Step 2. 
-
-#### [Linux Hybrid Runbook worker](#tab/linux-hrw)
-
-If the Linux Hybrid Runbook worker is deployed using agent-based approach in a region different from the primary region of failure, follow the below steps to continue executing Hybrid jobs: 
-1. [Uninstall](automation-linux-hrw-install.md#remove-linux-hybrid-runbook-worker) the agent from the Hybrid Runbook worker present in Automation account in the primary region. 
-1. [Re-install](automation-linux-hrw-install.md#install-a-linux-hybrid-runbook-worker) the agent on the same machine in the replica Automation account in the secondary region. 
-1. You can now execute jobs on the Hybrid Runbook worker created in Step 2. 
-
 ---
 
 ### Scenario: Execute jobs on Hybrid Runbook Worker deployed in the primary region of failure
 If the Hybrid Runbook worker is deployed in the primary region, and there's a compute failure in that region, the machine won't be available for executing Automation jobs. You must provision a new virtual machine in an alternate region and register it as Hybrid Runbook Worker in Automation account in the secondary region.
 
 - See the installation steps in [how to deploy an extension-based Windows or Linux User Hybrid Runbook Worker](extension-based-hybrid-runbook-worker-install.md?tabs=windows#create-hybrid-worker-group).
-- See the installation steps in [how to deploy an agent-based Windows Hybrid Worker](automation-windows-hrw-install.md#installation-options).
-- See the installation steps in [how to deploy an agent-based Linux Hybrid Worker](automation-linux-hrw-install.md#install-a-linux-hybrid-runbook-worker).
 
 ## Script to migrate Automation account assets from one region to another
 
@@ -83,7 +65,6 @@ You can use these scripts for migration of Automation account assets from the ac
  1. Ensure that the system assigned managed identities of the primary Automation account have contributor access to the subscription it belongs to.
  1. Ensure that the primary Automation account's managed identity has Contributor access with read and write permissions to the Automation account in secondary region. To enable, provide the necessary permissions in secondary Automation account's managed identities. [Learn more](../role-based-access-control/quickstart-assign-role-user-portal.md).
  1. Ensure that the script has access to the Automation account assets in primary region. Hence, it should be executed as a runbook in that Automation account for successful migration.
- 1. If the primary Automation account is deployed using a Run as account, then it must be switched to Managed Identity before migration. [Learn more](migrate-run-as-accounts-managed-identity.md).
  1. Modules required are:
 
       - Az.Accounts version 2.8.0 

articles/automation/automation-hybrid-runbook-worker.md

@@ -91,16 +91,10 @@ To control the distribution of runbooks on Hybrid Runbook Workers and when or ho
 
 ## Hybrid Runbook Worker installation
 
-The process to install a user Hybrid Runbook Worker depends on the operating system. The table below defines the deployment types.
-
-|Operating System  |Deployment Types  |
-|---------|---------|
-|Windows | [Automated](automation-windows-hrw-install.md#automated-deployment)<br>[Manual](automation-windows-hrw-install.md#manual-deployment). |
-|Linux   | [Manual](automation-linux-hrw-install.md#install-a-linux-hybrid-runbook-worker) |
-|Either  | For user Hybrid Runbook Workers, see [Deploy an extension-based Windows or Linux user Hybrid Runbook Worker in Automation](./extension-based-hybrid-runbook-worker-install.md). This is the recommended method. |
+To install, see [Deploy an extension-based Windows or Linux user Hybrid Runbook Worker in Automation](./extension-based-hybrid-runbook-worker-install.md).
 
 >[!NOTE]
-> Hybrid Runbook Worker is currently not supported on VM Scale Sets.
+> Hybrid Runbook Worker is currently not supported on Azure Virtual Machine Scale Sets.
 
 ## <a name="network-planning"></a>Network planning
 
@@ -120,8 +114,8 @@ Azure Automation supports Azure virtual network service tags, starting with the
 
 The service tag for the Azure Automation service only provides IPs used for the following scenarios:
 
-* Trigger webhooks from within your virtual network
-* Allow Hybrid Runbook Workers or State Configuration agents on your VNet to communicate with the Automation service
+* Trigger webhooks from within your virtual network.
+* Allow Hybrid Runbook Workers or State Configuration agents on your VNet to communicate with the Automation service.
 
 >[!NOTE]
 >The service tag **GuestAndHybridManagement** currently doesn't support runbook job execution in an Azure sandbox, only directly on a Hybrid Runbook Worker.