-# Azure AD Connect group writeback

-Group Writeback is the feature that allows you to write cloud groups back to your on-premises Active Directory using the Azure AD Connect Sync client. This feature enables you to manage groups in the cloud, while controlling access to on-premises applications and resources. Group Writeback provides the following capabilities:

- 1. Microsoft 365 groups can be written as Distribution groups, Security groups, or Mail-Enabled Security groups.

- 2. Azure AD Security groups will be written back as Security groups.

- 3. All groups are written back to AD as scope universal.

- 4. Allows you to configure group writeback settings for all M365 groups within a tenant.

- 5. Nested cloud groups and devices, (if device writeback is also enabled) that are members of groups, enabled for writeback, will be written back with scope universal.

- 6. Now, you can change the common name in an Active Directory groupΓÇÖs distinguished name when configuring group writeback in Azure AD Connect.

- 7. You can now configure Azure AD groups to writeback using the Azure AD Admin portal, Graph Explorer, and PowerShell.

-The following document will walk you through how you can enable Group Writeback .

->[!NOTE]

->This document covers Azure AD Connect group writeback version 2.0. To take advantage of the new features you will need to deploy [Azure AD Connect version from 2021 December or later (2.0.89.0)](https://www.microsoft.com/download/details.aspx?id=47594).

-## Pre-requisites

-The following pre-requisites must be met in order to enable group writeback.

-The latest version of Group Writeback is enabled tenant-wide and not per Azure AD Connect server. The default values for writeback settings on cloud groups are backward compatible.

-## Deployment guidance

-You will need to deploy [Azure AD Connect version from 2021 December or later (2.0.89.0)](https://www.microsoft.com/download/details.aspx?id=47594) to use the latest version of the group writeback feature. Older builds of Azure AD Connect don't support the new version of Group Writeback and will write back Microsoft 365 groups only as Distribution lists, when Group Writeback is enabled.

-It's recommended that you follow the [swing migration](how-to-upgrade-previous-version.md#swing-migration) method for rolling out the new group writeback feature in your environment. This method will provide a clear contingency plan in the event, that a major rollback is necessary.

->[!NOTE]

-> If you are using an older build of group writeback in Azure AD Connect, the M365 groups being written back as universal distribution groups, will continue to be written back. The new version of group writeback is backwards compatible.

-## Enable group writeback

-Enabling group writeback's new features is a two step process. One step is done via Azure AD Connect. This step enables the original group writeback features. The second one is done using PowerShell and enables the new writeback features once the original features are enabled. To enable group writeback complete the steps in the table below

-Steps|Description|

-|--|--|

-|[Enable group writeback using Azure AD Connect](#enable-group-writeback-using-azure-ad-connect)|Enables group writeback with the original features included in Azure AD Connect. That is, it will writeback M365 groups as distribution groups. This option is **only** available if you have Exchange present in your on-premises Active Directory.|

-|[Enabling group writeback using PowerShell](#enable-group-writeback-using-powershell)|Enables the new group writeback features outlined in this article.

->[!NOTE]

->You must enable group writeback via Azure AD Connect before enabling group writeback via PowerShell to receive the new features outlined in this article. You must do both and in the correct order.

-### Enable group writeback using Azure AD Connect

-To enable group writeback, use the following steps:

-1. Open the Azure AD Connect wizard, select **Configure** and then click **Next**.

-2. Select **Customize synchronization options** and then click **Next**.

-3. On the **Connect to Azure AD** page, enter your credentials. Click **Next**.

-4. On the **Optional features** page, verify that the options you previously configured are still selected.

-5. Select **Group Writeback** and then click **Next**.

-6. On the **Writeback page**, select an Active Directory organizational unit (OU) to store objects that are synchronized from Microsoft 365 to your on-premises organization, and then click **Next**.

-7. On the **Ready** to configure page, click **Configure**.

-8. When the wizard is complete, click **Exit** on the Configuration complete page. Group Writeback will be automatically configured.

->[!NOTE]

->The following is performed automatically after the last step above. However, if you experience permission issues while exporting the object to AD then do the following:

->

->Open the Windows PowerShell as an Administrator on the Azure Active Directory Connect server, and run the following commands. This step is optional

->

-> ```powershell

-> $AzureADConnectSWritebackAccountDN = <MSOL_ account DN>

-> Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

->

->

->

- ># To grant the <MSOL_account> permission to all domains in the forest:

- >Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountDN $AzureADConnectSWritebackAccountDN

->

- ># To grant the <MSOL_account> permission to specific OU (eg. the OU chosen to writeback Office 365 Groups to):

- >$GroupWritebackOU = <DN of OU where groups are to be written back to>

- >Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountDN $AzureADConnectSWritebackAccountDN -ADObjectDN $GroupWritebackOU

- >```

-For more information on configuring the Microsoft 365 groups, see [Configure Microsoft 365 Groups with on-premises Exchange hybrid](/exchange/hybrid-deployment/set-up-microsoft-365-groups#enable-group-writeback-in-azure-ad-connect).

-### Enable group writeback using PowerShell

-To enable group writeback via PowerShell:

- 1. Open a PowerShell prompt as administrator.

- 2. Disable the sync scheduler after verifying that no synchronization operations are running:

- ```powershell

- Set-ADSyncScheduler -SyncCycleEnabled $false

- ```

- 3. Import the ADSync module:

- ```powershell

- Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1'

- ```

- 4. Enable the group writeback feature for the tenant:

- ```powershell

- Set-ADSyncAADCompanyFeature -GroupWritebackV2 $true

- ```

- 5. Re-enable the Sync Scheduler

- ```powershell

- Set-ADSyncScheduler -SyncCycleEnabled $true

- ```

-You've now enabled the group writeback feature, and can [select the groups for writeback](../enterprise-users/groups-write-back-portal.md).

-### Optional Configuration

-To make it easier to find groups being written back from Azure AD to Active Directory, there's an option to writeback the group distinguished name with the cloud display name.

- - Default format:

- `CN=Group_3a5c3221-c465-48c0-95b8-e9305786a271, OU=WritebackContainer, DC=domain, DC=com`ΓÇ»

- - New Format:</br>

- `CN=Administrators_e9305786a271, OU=WritebackContainer, DC=domain, DC=com`ΓÇ»

-

-When configuring group writeback, there will be a checkbox at the bottom of the Group Writeback configuration window. Select the box to enable this feature.

-[](./media/how-to-connect-group-writeback/group-1.png#lightbox)

->[!NOTE]

-> Groups being written back from Azure AD to AD will have a source of authority of the cloud. This means any changes made on-premises to groups that are written back from Azure AD will be overwritten on the next sync cycle.

-## Disabling group writeback

-To disable Group Writeback, use the following steps:

-1. Launch the Azure Active Directory Connect wizard and navigate to the Additional Tasks page. Select the **Customize synchronization options** task and click **next**.

-2. On the **Optional Features** page, uncheck group writeback. You'll receive a warning letting you know that groups will be deleted. Click **Yes**.

- > [!IMPORTANT]

- > Disabling Group Writeback will cause any groups that were previously created by this feature to be deleted from your local Active Directory on the next synchronization cycle.

- 

-3. Click **Next**.

-4. Click **Configure**.

- > [!NOTE]

- > Disabling Group Writeback will set the Full Import and Full Synchronization flags to 'true' on the Azure Active Directory Connector, causing the rule changes to propagate through on the next synchronization cycle, deleting the groups that were previously written back to your Active Directory.

-## Rolling back group writeback

-To disable or rollback group writeback via powershell, do the following:

- 1. Open a PowerShell prompt as administrator.

- 2. Disable the sync scheduler after verifying that no synchronization operations are running:

- ```powershell

- Set-ADSyncScheduler -SyncCycleEnabled $false

- ```

- 3. Import the ADSync module:

- ```powershell

- Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1'

- ```

- 4. Disable the group writeback feature for the tenant:

- ```powershell

- Set-ADSyncAADCompanyFeature -GroupWritebackV2 $false

- ```

- 5. Re-enable the Sync Scheduler

- ```powershell

- Set-ADSyncScheduler -SyncCycleEnabled $true

- ```

-## Public preview limitationsΓÇ»

-While this release has undergone extensive testing, you may still encounter issues. One of the goals of this public preview release is to find and fix any such issues before moving to General Availability.ΓÇ»

-While support is provided for this public preview release, Microsoft may not always be able to fix all issues you may encounter immediately. For this reason, it's recommended that you use your best judgment before deploying this release in your production environment.ΓÇ»

-Limitations and known issues specific to Group Writeback:

-## Next steps

-> To provide a group of users with just-in-time access to roles with permissions in SharePoint, Exchange, or Security & Compliance Center, be sure to make permanent assignments of users to the group, and then assign the group to a role as eligible for activation. If instead you assign a role permanently to a group and and assign users to be eligible to group membership, it might take significant time to have all permissions of the role activated and ready to use.

-* **Master** - When the primary node is rebooted, Azure Cache for Redis fails over to the replica node and promotes it to primary. During this failover, there may be a short interval in which connections may fail to the cache.

-To test the resiliency of your application against failure of the primary node of your cache, reboot the **Master** node. To test the resiliency of your application against failure of the replica node, reboot the **Replica** node. To test the resiliency of your application against total failure of the cache, reboot **Both** nodes.

-If you reboot both the **Master** and **Replica** nodes, all data in the cache (or in that shard when you're using a premium cache with clustering enabled) might be lost. However, the data might not be lost either. If you have configured [data persistence](cache-how-to-premium-persistence.md), the most recent backup is restored when the cache comes back online. However, any cache writes that have occurred after the backup was made are lost.

-Azure Fluid Relay doesn't currently have support for Signals. Learn about Signals [here](https://fluidframework.com/docs/concepts/signals/).

-In this tutorial, you learn how to:

-> * Enable Change Analysis to track changes for Azure resources and for Azure Web App configurations

-> * Troubleshoot a Web App issue using Change Analysis

-An Azure Web App with a Storage account dependency. Follow instructions at [ChangeAnalysis-webapp-storage-sample](https://github.com/Azure-Samples/changeanalysis-webapp-storage-sample) if you haven't already deployed one.

-## Enable Change Analysis

-In the Azure portal, navigate to theChange Analysis service home page.

-If this is your first time using Change Analysis service, the page may take up to a few minutes to register the `Microsoft.ChangeAnalysis` resource provider in your selected subscriptions.

-To use Azure CDN, you must own at least one Azure subscription. You also need to create at least one CDN profile, which is a collection of CDN endpoints. Every CDN endpoint represents a specific configuration of content deliver behavior and access. To organize your CDN endpoints by internet domain, web application, or some other criteria, you can use multiple profiles. Because [Azure CDN pricing](https://azure.microsoft.com/pricing/details/cdn/) is applied at the CDN profile level, you must create multiple CDN profiles if you want to use a mix of pricing tiers. For information about the Azure CDN billing structure, see [Understanding Azure CDN billing](cdn-billing.md).

-## Configure a private registry

-This example associates a graph of artifacts to a container image. Build and push a container image, or reference an existing image in the private registry.

-Microsoft Defender for Azure SQL includes two Microsoft Defender plans that extend Microsoft Defender for Cloud's [data security package](/azure/azure-sql/database/azure-defender-for-sql) to protect your SQL estate regardless of where it is located (Azure, multicloud or hybrid environments). Microsoft Defender for Azure SQL includes functions that can be used to discover and mitigate potential database vulnerabilities. Defender for Azure SQL can also detect anomalous activities that may be an indication of a threat to your databases.

-For more information about migrating servers from Defender for Endpoint to Defender for Cloud, see the [Microsoft Defender for Endpoint to Microsoft Defender for Cloud Migration Guide](/microsoft-365/security/defender-endpoint/migrating-mde-server-to-cloud&preserve-view=true).

-|**Hardware profile** | L500|

-|**Performance** | Max bandwidth: 60 Mbp/s<br>Max devices: 1,000 |

-|**Hardware profile** | E1800, E1000, E500 |

-<!--for example?-->

-## Enhance device inventory data

-Enhance the data in your device inventory with information from other sources, such as CMDBs, DNS, firewalls, and Web APIs. Use enhanced data to learn things such as:

-Enhancement data is shown as extra columns in the on-premises management console **Device inventory** page.

-Enhance data by adding it manually or by running customized scripts from Defender for IoT. You can also work with Defender for IoT support to set up your system to receive Web API queries.

-1. Contact [Microsoft Support](https://support.serviceshub.microsoft.com/supportforbusiness/create?sapId=82c88f35-1b8e-f274-ec11-c6efdd6dd099) to obtain the relevant scripts.

-1. Select **Automatic**. When the **UPLOAD SCRIPT** and **TEST SCRIPT** buttons appear, upload and then test the script you'd received from [Microsoft Support](https://support.serviceshub.microsoft.com/supportforbusiness/create?sapId=82c88f35-1b8e-f274-ec11-c6efdd6dd099).

-6. Save the file.

-7. Sign in to the Defender for IoT sensor console.

-8. Select **System Settings** > **Sensor management** > **Subscription & Activation Mode**.

-9. Select **Upload** and select the file that you saved.

-10. Select **Activate**.

-The data package for threat intelligence is provided with each new Defender for IoT version, or if needed between releases. The package contains signatures (including malware signatures), CVEs, and other security content.

-You can manually upload this file in the Azure portal and automatically update it to sensors.

-If you would like to evaluate Defender for IoT, you can use a trial commitment. The trial is valid for 30 days and supports 1000 committed devices. Using the trial lets you deploy one or more Defender for IoT sensors on your network. Use the sensors to monitor traffic, analyze data, generate alerts, learn about network risks and vulnerabilities, and more. The trial also allows you to download an on-premises management console to view aggregated information generated by sensors.

-PCAP files provide more detailed information about the network traffic that occurred at the time of the alert event.

-|**L500** | [Dell Edge 5200](appliance-catalog/dell-edge-5200.md) <br> (Rugged MIL-STD-810G) | **Max bandwidth**: 60Mbp/s<br>**Max devices**: 1,000 <br> 8 Cores/32G RAM/100GB | **Mounting**: Wall Mount<br>**Ports**: 3x RJ45 |

-| 22.1.6 | 06/2022 | 10/2023 |

-| 22.1.5 | 06/2022 | 10/2023 |

-|**Package upload failed** |There was an error uploading the file to the sensor |Upload error |"Verify the sensorΓÇÖs ability to communicate with download.microsoft.com and retry. <br><br>If the problem persists, open a support ticket.|

-* [Where and how to deploy](how-to-deploy-and-where.md)

-# Migrate from Azure Database for PostgreSQL Single Server to Flexible Server (preview)

-By using the migration tool, you can initiate migrations for multiple servers and databases in a repeatable way. The tool automates most of the migration steps to make the migration journey across Azure platforms as seamless as possible. The tool is free for customers.

-> The migration tool is in public preview.

->

-> Migration from Single Server to Flexible Server is enabled in preview in these regions: Central US, West US, South Central US, North Central US, East Asia, Switzerland North, Australia South East, UAE North, UK West and Canada East.

-This how-to guide describes how a data owner can delegate authoring policies in Microsoft Purview to enable access to SQL Server on Azure Arc-enabled servers. The following actions are currently enabled: *SQL Performance Monitoring*, *SQL Security Auditing* and *Read*. *Read* is only supported for policies at server level. *Modify* is not supported at this point.

-1. Turn the switch **Data Use Management** to **Enabled**. This switch enables the access-policies to be used with the given Arc-enabled SQL server. Note: Data Use Management can affect the security of your data, as it delegates to certain Microsoft Purview roles managing access to the data sources. Secure practices related to Data Use Management are described in this guide: [registering a data resource for Data Use Management](./how-to-enable-data-use-management.md)

-**Example #1: SQL Performance Monitor policy**. This policy assigns the Azure AD principal 'Christie Cline' to the *SQL Performance monitoring* role, in the scope of Arc-enabled SQL server *DESKTOP-xxx*. This policy has also been published to that server.

-**Example #2: SQL Security Auditor policy**. Similar to example 1, but choose the *SQL Security auditing* action (instead of *SQL Performance monitoring*), when authoring the policy.

-**Example #3: Read policy**. This policy assigns the Azure AD principal 'sg-Finance' to the *SQL Data reader* role, in the scope of SQL server *DESKTOP-xxx*. This policy has also been published to that server.

-> - Publish is a background operation. It can take up to **4 minutes** for the changes to be reflected in this data source.

-This how-to guide describes how a data owner can delegate authoring policies in Microsoft Purview to enable access to Azure SQL DB. The following actions are currently enabled: *SQL Performance Monitoring*, *SQL Security Auditing* and *Read*. *Modify* is not supported at this point.

-**Example #1: SQL Performance Monitor policy**. This policy assigns the Azure AD principal 'Mateo Gomez' to the *SQL Performance monitoring* role, in the scope of SQL server *relecloud-sql-srv2*. This policy has also been published to that server.

-**Example #2: SQL Security Auditor policy**. Similar to example 1, but choose the *SQL Security auditing* action (instead of *SQL Performance monitoring*), when authoring the policy.

-**Example #3: Read policy**. This policy assigns the Azure AD principal 'Robert Murphy' to the *SQL Data reader* role, in the scope of SQL server *relecloud-sql-srv2*. This policy has also been published to that server.

-> - Publish is a background operation. It can take up to **4 minutes** for the changes to be reflected in this data source.

-After you've registered your resources, you'll need to enable Data Use Management. Data Use Management affects the security of your data, as it delegates to certain users to manage access to data resources from within Microsoft Purview.

-To ensure you securely enable Data Use Management, and follow best practices, follow this guide to enable Data Use Management for your resource group or subscription:

-After you've registered your resources, you'll need to enable *Data Use Management*. Data Use Management can affect the security of your data, as it delegates to certain Microsoft Purview roles to manage access to data sources that have been registered. Secure practices related to *Data Use Management* are described in this guide:

-| Azure | [Azure Blob Storage](register-scan-azure-blob-storage-source.md)| [Yes](register-scan-azure-blob-storage-source.md#register) | [Yes](register-scan-azure-blob-storage-source.md#scan)| Limited* | [Yes (Preview)](how-to-data-owner-policies-storage.md) | [Yes](register-scan-azure-blob-storage-source.md#data-sharing)|

-|| [Azure Data Lake Storage Gen2](register-scan-adls-gen2.md)| [Yes](register-scan-adls-gen2.md#register) | [Yes](register-scan-adls-gen2.md#scan)| Limited* | [Yes (Preview)](how-to-data-owner-policies-storage.md) | [Yes](register-scan-adls-gen2.md#data-sharing) |

-|| [Azure SQL Database](register-scan-azure-sql-database.md)| [Yes](register-scan-azure-sql-database.md#register) |[Yes](register-scan-azure-sql-database.md#scan)| [Yes (Preview)](register-scan-azure-sql-database.md#lineagepreview) | [Yes (Preview)](how-to-data-owner-policies-azure-sql-db.md) | No |

-To create an access policy for Azure Data Lake Storage Gen 2, follow these guides:

-* [All sources in a subscription or resource group](./how-to-data-owner-policies-resource-group.md) - This guide will allow you to enable access policies on all enabled and available sources in a resource group, or across an Azure subscription.

-The Microsoft Sentinel Solution for SAP is now generally available (GA). [Learn about billing and offer details](/pricing/offers/microsoft-sentinel-sap-promo/).

-description: Learn how to set up a continuous deployment (CD) pipeline. This pipeline updates a group of Azure Linux virtual machines using the canary deployment strategy.

-#Customer intent: As a developer, I want to learn about CI/CD features in Azure so that I can use Azure DevOps services like Azure Pipelines to build and deploy my applications automatically.

-**Applies to:** :heavy_check_mark: Linux VMs

-## Infrastructure as a service (IaaS) - Configure CI/CD

-Azure Pipelines provides a fully featured set of CI/CD automation tools for deployments to virtual machines. You can configure a continuous-delivery pipeline for an Azure VM from the Azure portal.

-This article shows how to set up a CI/CD pipeline that uses the canary strategy for multimachine deployments. The Azure portal also supports other strategies like [rolling](./tutorial-devops-azure-pipelines-classic.md) and [blue-green](./tutorial-azure-devops-blue-green-strategy.md).

-### Configure CI/CD on virtual machines

-You can add virtual machines as targets to a [deployment group](/azure/devops/pipelines/release/deployment-groups). You can then target them for multimachine updates. After you deploy to machines, view **Deployment History** within a deployment group. This view lets you trace from VM to the pipeline and then to the commit.

-### Canary deployments

-A canary deployment reduces risk by slowly rolling out changes to a small subset of users. As you gain confidence in the new version, you can release it to more servers in your infrastructure and route more users to it.

-Using the continuous-delivery option, you can configure canary deployments to your virtual machines from the Azure portal. Here is the step-by-step walk-through:

-1. Sign in to the Azure portal and navigate to a virtual machine.

-1. In the leftmost pane of the VM settings, select **Continuous delivery**. Then select **Configure**.

- 

-1. In the configuration panel, select **Azure DevOps Organization** to choose an existing account or create a new one. Then select the project under which you want to configure the pipeline.

- 

-1. A deployment group is a logical set of deployment target machines that represent the physical environments. Dev, Test, UAT, and Production are examples. You can create a new deployment group or select an existing one.

-1. Select the build pipeline that publishes the package to be deployed to the virtual machine. The published package should have a deployment script named deploy.ps1 or deploy.sh in the deployscripts folder in the package's root folder. The pipeline runs this deployment script.

-1. In **Deployment strategy**, select **Canary**.

-1. Add a "canary" tag to VMs that are to be part of canary deployments. Add a "prod" tag to VMs that are part of deployments made after canary deployment succeeds. Tags help you target only VMs that have a specific role.

- 

-1. Select **OK** to configure the continuous-delivery pipeline to deploy to the virtual machine.

- 

-1. The deployment details for the virtual machine are displayed. You can select the link to go to the release pipeline in Azure DevOps. In the release pipeline, select **Edit** to view the pipeline configuration. The pipeline has these three phases:

- 1. This phase is a deployment-group phase. Applications are deployed to VMs that are tagged as "canary".

- 1. In this phase, the pipeline pauses and waits for manual intervention to resume the run.

- 1. This is again a deployment group phase. The update is now deployed to VMs tagged as "prod".

- 

-1. Before resuming the pipeline run, ensure that at least one VM is tagged as "prod". In the third phase of the pipeline, applications are deployed to only those VMs that have the "prod" tag.

-1. The Execute Deploy Script task by default runs the deployment script deploy.ps1 or deploy.sh. The script is in the deployscripts folder in the root folder of the published package. Ensure that the selected build pipeline publishes the deployment in the root folder of the package.

- 

-## Other deployment strategies

-## Azure DevOps Projects

-You can get started with Azure easily. With Azure DevOps Projects, start running your application on any Azure service in just three steps by selecting:

-[Learn more](https://azure.microsoft.com/features/devops-projects/).

-## Additional resources

-> | Variable | Description | Type |

-> | | | - |

-> | `user_keyvault_id` | Azure resource identifier for the user key vault | Optional |

-> | `spn_keyvault_id` | Azure resource identifier for the user key vault containing the SPN details | Optional |

-> | `deployer_private_key_secret_name` | The Azure Key Vault secret name for the deployer private key | Optional |

-> | `deployer_public_key_secret_name` | The Azure Key Vault secret name for the deployer public key | Optional |

-> | `deployer_username_secret_name` | The Azure Key Vault secret name for the deployer username | Optional |

-> | `deployer_password_secret_name` | The Azure Key Vault secret name for the deployer password | Optional |

-## Deploy the web app

-> | Variable | Description | Type | Notes |

-> | -- | -- | - | - |

-> | `environment` | Identifier for the workload zone (max 5 chars) | Mandatory | For example, `PROD` for a production environment and `NP` for a non-production environment. |

-> | `location` | The Azure region in which to deploy. | Required | |

-> | `custom_prefix` | Specifies the custom prefix used in the resource naming | Optional | |

-> | `use_prefix` | Controls if the resource naming includes the prefix | Optional | DEV-WEEU-SAP01-X00_xxxx |

-> | 'name_override_file' | Name override file | Optional | see [Custom naming](automation-naming-module.md) |

-> | Variable | Description | Type | Notes |

-> | -- | | | -- |

-> | `user_keyvault_id` | Azure resource identifier for existing system credentials key vault | Optional | |

-> | `spn_keyvault_id` | Azure resource identifier for existing deployment credentials (SPNs) key vault | Optional | |

-> | `enable_purge_control_for_keyvaults | Disables the purge protection for Azure key vaults. | Optional | Only use this for test environments |

-The table below contains the Terraform parameters. These parameters need to be entered manually if not using the deployment scripts.

-> [About SAP system deployment in automation framework](automation-deploy-workload-zone.md)

-This tutorial shows how to do enterprise scaling for deployments using the [SAP deployment automation framework on Azure](automation-deployment-framework.md). This example uses Azure Cloud Shell to deploy the control plane infrastructure. The deployer virtual machine (VM) creates the remaining infrastructure and SAP HANA configurations.

- > [!NOTE]

-

-

-> [!NOTE]

-3. Assign the **User Access Administrator** role to the service principal.

-2. Open VS Code from Cloud Shell

- > [!NOTE]

-control plane for a chosen automation area.

-1. Go to the [Azure portal](https://portal.azure.com).

-

-

-

-

-1. Open a plain text editor. Copy in the secret value.

-

-1. Save the file where you keep SSH keys. For example, `C:\\Users\\<your-username>\\.ssh`.

-

-> [!NOTE]

-1. Choose *SSH Private Key from Azure Key Vault*

-The SAP Bill of Materials (BOM) mimics the SAP maintenance planner. There are relevant product identifiers and a set of download URLs.

-

-

-

-

-

- kv_name: <Deployer KeyVault Name>

-

-

- kv_name: <Deployer KeyVault Name>

-

-

-

-

-

-1. Go to the **sap-automation** folder and optionally refresh the repository.

-

-Use the [install_workloadzone](bash/automation-install_workloadzone.md) script to deploy the SAP workload zone.

-

-

-Use the [installer.sh](bash/automation-installer.md) script to deploy the SAP system.

-

-The SAP application installation happens through Ansible playbooks.

-For a standalone SAP S/4HANA system, there are eight playbooks to execute in sequence. One way you can execute the playbooks is to use the Configuration menu.

-

-This playbook downloads the SAP software to the SCS virtual machine.

-

-

-

-

-

- --library_parameter_file LIBRARY/MGMT-${region_code}-SAP_LIBRARY/MGMT-${region_code}-SAP_LIBRARY.tfvars

-| 450 | allow_monitor | 443 | TCP | | Azure Monitor | Allow |

-| 501 | allow_keyVault | 443 | TCP | | Azure Key Vault | Allow |

-| 550 | allow_storage | 443 | TCP | | Storage | Allow |

-| 600 | allow_azure_controlplane | 443 | Any | | Azure Resource Manager | Allow |

-Learn how to block