-Access tokens and ID tokens are short-lived. After they expire, you must refresh them to continue to access resources. To do this, submit another POST request to the `/token` endpoint. This time, provide the `refresh_token` instead of the `code`:

-2. Navigate to the [API Key Management page](https://app.mailjet.com/account/api_keys). Record the **API Key** and **Secret Key** for use in a later step. Both keys are generated automatically when your account is created.

-ID tokens expire in a short period of time. Refresh the tokens after they expire to continue being able to access resources. You can refresh a token by submitting another `POST` request to the `/token` endpoint. This time, provide the `refresh_token` parameter instead of the `code` parameter:

- > You can disable provisioning based on assignments for an enterprise application by changing settings in the [Scope](../app-provisioning/user-provisioning.md#how-do-i-set-up-automatic-provisioning-to-an-application) menu under the provisioning settings to **Sync all users and groups**.

-| Global Administrator| To implement combined registration experience. |

-1. The client machine contacts an on-premises Azure AD DC and trades the partial TGT for a fully formed TGT.

-To retrieve a security key, sign in to the Azure portal, and then go to the **Security info** page.

-1. Browse to **Microsoft Intune** > **Device enrollment** > **Windows enrollment** > **Windows Hello for Business** > **Properties**.

-1. Under **Settings**, set **Use security keys for sign-in** to **Enabled**.

-1. Browse to **Device** > **Windows** > **Configuration Profiles** > **Create profile**.

- - Name: Security Keys for Windows Sign-In

- - Description: Enables FIDO Security Keys to be used during Windows Sign In

- - Custom OMA-URI Settings:

-1. This policy can be assigned to specific users, devices, or groups. For more information, see [Assign user and device profiles in Microsoft Intune](/intune/device-profile-assign).

-[Learn more about Azure AD Multi-Factor Authentication](../authentication/howto-mfa-getstarted.md)

- 

-2. Search for and select **Azure Active Directory**, then choose **Users**.

-3. Select **Multi-Factor Authentication** from the navigation bar across the top of the *Users* window.

-4. Under Multi-Factor Authentication, select **service settings**.

-5. On the **Service Settings** page, select the **Allow users to create app passwords to sign in to non-browser apps** option.

-For more information on how to allow users to quickly register for Azure AD Multi-Factor Authentication, see [Combined security information registration overview](concept-registration-mfa-sspr-combined.md).

- - **OMA-URI** set to `./Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset`

-Define a timeframe that is your indicator for a stale device. When defining your timeframe, factor the window noted for updating the activity timestamp into your value. For example, you shouldn't consider a timestamp that is younger than 21 days (includes variance) as an indicator for a stale device. There are scenarios that can make a device look like stale while it isn't. For example, the owner of the affected device can be on vacation or on a sick leave. that exceeds your timeframe for stale devices.

-## Delete a subscription

- Set-AzureADDirectorySetting -Id $grpUnifiedSetting.Id -DirectorySetting $setting

-Managing security can be difficult with common identity-related attacks like password spray, replay, and phishing becoming more popular. Security defaults make it easier to help protect your organization from these attacks with preconfigured security settings:

-## Why security defaults?

-Quoting Alex Weinert, Director of Identity Security at Microsoft:

-> ...our telemetry tells us that more than 99.9% of organization account compromise could be stopped by simply using MFA, and that disabling legacy authentication correlates to a 67% reduction in compromise risk (and completely stops password spray attacks, 100% of which come in via legacy authentication)...

-More details on why security defaults are being made available can be found in Alex Weinert's blog post, [Introducing security defaults](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/introducing-security-defaults/ba-p/1061414).

-Microsoft is making security defaults available to everyone. The goal is to ensure that all organizations have a basic level of security enabled at no extra cost. You turn on security defaults in the Azure portal. If your tenant was created on or after October 22, 2019, security defaults may be enabled in your tenant. To protect all of our users, security defaults are being rolled out to new tenants at creation.

-### Who's it for?

-## Policies enforced

-### Unified Multi-Factor Authentication registration

-### Protecting administrators

-Users with privileged access have increased access to your environment. Because of the power these accounts have, you should treat them with special care. One common method to improve the protection of privileged accounts is to require a stronger form of account verification for sign-in. In Azure AD, you can get a stronger account verification by requiring multi-factor authentication. We recommend having separate accounts for administration and standard productivity tasks to significantly reduce the number of times your admins are prompted for MFA.

-### Protecting all users

-### Blocking legacy authentication

-### Protecting privileged actions

-The following extra considerations are related to deployment of security defaults.

-### Emergency access accounts

-Every organization should have at least two emergency access account configured.

-You may choose [disable password expiration](../authentication/concept-sspr-policy.md#set-a-password-to-never-expire) to for these accounts using Azure AD PowerShell.

-### Authentication methods

-These free security defaults allow registration and use of Azure AD Multi-Factor Authentication **using only the Microsoft Authenticator app using notifications**. Conditional Access allows the use of any authentication method the administrator chooses to enable.

-| Method | Security defaults | Conditional Access |

-| | | |

-| Notification through mobile app | X | X |

-| Verification code from mobile app or hardware token | X** | X |

-| Text message to phone | | X |

-| Call to phone | | X |

-| App passwords | | X*** |

-> [!WARNING]

-> Do not disable methods for your organization if you are using Security Defaults. Disabling methods may lead to locking yourself out of your tenant. Leave all **Methods available to users** enabled in the [MFA service settings portal](../authentication/howto-mfa-getstarted.md#choose-authentication-methods-for-mfa).

-You can use Conditional Access to configure policies similar to security defaults, but with more granularity including user exclusions, which aren't available in security defaults. If you're using Conditional Access and have Conditional Access policies enabled in your environment, security defaults won't be available to you. More information about Azure AD licensing can be found on the [Azure AD pricing page](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

-Here are step-by-step guides for Conditional Access to configure a set of policies, which form a good starting point for protecting your identities:

-## Enabling security defaults

-To enable security defaults in your directory:

-1. Sign in to the [Azure portal](https://portal.azure.com) as a security administrator, Conditional Access administrator, or global administrator.

-1. Browse toΓÇ»**Azure Active Directory**ΓÇ»>ΓÇ»**Properties**.

-1. Select **Manage security defaults**.

-1. Set the **Enable security defaults** toggle to **Yes**.

-1. Select **Save**.

-

-## Disabling security defaults

-[Common Conditional Access policies](../conditional-access/concept-conditional-access-policy-common.md)

-* [Microsoft Defender for Cloud Apps](/cloud-app-security/what-is-cloud-app-security) ΓÇô enables you to discover and manage apps, govern across apps and resources, and check your cloud appsΓÇÖ compliance.

-[Taksel](https://help.ubuntu.com/community/Tasksel), [IDrive360](../saas-apps/idrive360-tutorial.md), [VIDA](../saas-apps/vida-tutorial.md), [ProProfs Classroom](../saas-apps/proprofs-classroom-tutorial.md), [WAN-Sign](../saas-apps/wan-sign-tutorial.md), [Citrix Cloud SAML SSO](../saas-apps/citrix-cloud-saml-sso-tutorial.md), [Fabric](../saas-apps/fabric-tutorial.md), [DssAD](https://cloudlicensing.deepseedsolutions.com/), [RICOH Creative Collaboration RICC](https://www.ricoh-europe.com/products/software-apps/collaboration-board-software/ricc/), [Styleflow](../saas-apps/styleflow-tutorial.md), [Chaos](https://accounts.chaosgroup.com/corporate_login), [Traced Connector](https://control.traced.app/signup), [Squarespace](https://account.squarespace.com/org/azure), [MX3 Diagnostics Connector](https://mx3www.playground.dynuddns.com/signin-oidc), [Ten Spot](https://tenspot.co/api/v1/sso/azure/login/), [Finvari](../saas-apps/finvari-tutorial.md), [Mobile4ERP](https://play.google.com/store/apps/details?id=com.negevsoft.mobile4erp), [WalkMe US OpenID Connect](https://www.walkme.com/), [Neustar UltraDNS](../saas-apps/neustar-ultradns-tutorial.md), [cloudtamer.io](../saas-apps/cloudtamer-io-tutorial.md), [A Cloud Guru](../saas-apps/a-cloud-guru-tutorial.md), [PetroVue](../saas-apps/petrovue-tutorial.md), [Postman](../saas-apps/postman-tutorial.md), [ReadCube Papers](../saas-apps/readcube-papers-tutorial.md), [Peklostroj](https://app.peklostroj.cz/), [SynCloud](https://onboard.syncloud.io/), [Polymerhq.io](https://www.polymerhq.io/), [Bonos](../saas-apps/bonos-tutorial.md), [Astra Schedule](../saas-apps/astra-schedule-tutorial.md), [Draup](../saas-apps/draup-inc-tutorial.md), [Inc](../saas-apps/draup-inc-tutorial.md), [Applied Mental Health](../saas-apps/applied-mental-health-tutorial.md), [iHASCO Training](../saas-apps/ihasco-training-tutorial.md), [Nexsure](../saas-apps/nexsure-tutorial.md), [XEOX](https://login.xeox.com/), [Plandisc](https://create.plandisc.com/account/logon), [foundU](../saas-apps/foundu-tutorial.md), [Standard for Success Accreditation](../saas-apps/standard-for-success-accreditation-tutorial.md), [Penji Teams](https://web.penjiapp.com/), [CheckPoint Infinity Portal](../saas-apps/checkpoint-infinity-portal-tutorial.md), [Teamgo](../saas-apps/teamgo-tutorial.md), [Hopsworks.ai](../saas-apps/hopsworks-ai-tutorial.md), [HoloMeeting 2](https://backend2.holomeeting.io/)

-[Zii Travel Azure AD Connect](https://azuremarketplace.microsoft.com/marketplace/apps/aad.ziitravelazureadconnect?tab=Overview), [Cerby](../saas-apps/cerby-tutorial.md), [Selflessly](https://app.selflessly.io/sign-in), [Apollo CX](https://apollo.cxlabs.de/sso/aad), [Pedagoo](https://account.pedagoo.com/), [Measureup](https://account.measureup.com/), [Wistec Education](https://wisteceducation.fi/login/index.php), [ProcessUnity](../saas-apps/processunity-tutorial.md), [Cisco Intersight](../saas-apps/cisco-intersight-tutorial.md), [Codility](../saas-apps/codility-tutorial.md), [H5mag](https://account.h5mag.com/auth/request-access/ms365), [Check Point Identity Awareness](../saas-apps/check-point-identity-awareness-tutorial.md), [Jarvis](https://jarvis.live/login), [desknet's NEO](../saas-apps/desknets-neo-tutorial.md), [SDS & Chemical Information Management](../saas-apps/sds-chemical-information-management-tutorial.md), [W├║ru App](../saas-apps/wuru-app-tutorial.md), [Holmes](../saas-apps/holmes-tutorial.md), [Tide Multi Tenant](https://gallery.tideapp.co.uk/), [Telenor](https://admin.smartansatt.telenor.no/), [Yooz US](https://us1.getyooz.com/?kc_idp_hint=microsoft), [Mooncamp](https://app.mooncamp.com/#/login), [inwise SSO](https://app.inwise.com/defaultsso.aspx), [Ecolab Digital Solutions](https://ecolabb2c.b2clogin.com/account.ecolab.com/oauth2/v2.0/authorize?p=B2C_1A_Connect_OIDC_SignIn&client_id=01281626-dbed-4405-a430-66457825d361&nonce=defaultNonce&redirect_uri=https://jwt.ms&scope=openid&response_type=id_token&prompt=login), [Taguchi Digital Marketing System](https://login.taguchi.com.au/), [XpressDox EU Cloud](https://test.xpressdox.com/Authentication/Login.aspx), [EZSSH](https://docs.keytos.io/getting-started/registering-a-new-tenant/registering_app_in_tenant/), [EZSSH Client](https://portal.ezssh.io/signup), [Verto 365](https://www.vertocloud.com/Login/), [KPN Grip](https://www.grip-on-it.com/), [AddressLook](https://portal.bbsonlineservices.net/Manage/AddressLook), [Cornerstone Single Sign-On](../saas-apps/cornerstone-ondemand-tutorial.md)

-[Bambuser Live Video Shopping](https://lcx.bambuser.com/), [DeepDyve Inc](https://www.deepdyve.com/azure-sso), [Moqups](../saas-apps/moqups-tutorial.md), [RICOH Spaces Mobile](https://ricohspaces.app/welcome), [Flipgrid](https://auth.flipgrid.com/), [hCaptcha Enterprise](../saas-apps/hcaptcha-enterprise-tutorial.md), [SchoolStream ASA](https://jsd.schoolstreamk12.com/AS)

-[Backup365](https://portal.backup365.io/login), [Soapbox](https://app.soapboxhq.com/create?step=auth&provider=azure-ad2-oauth2), [Alma SIS](https://almau.getalma.com/), [Enlyft Dynamics 365 Connector](http://enlyft.com/), [Serraview Space Utilization Software Solutions](../saas-apps/serraview-space-utilization-software-solutions-tutorial.md), [Uniq](https://web.uniq.app/), [Visibly](../saas-apps/visibly-tutorial.md), [Zylo](../saas-apps/zylo-tutorial.md), [Edmentum - Courseware Assessments Exact Path](https://auth.edmentum.com/elf/login), [CyberLAB](https://cyberlab.evolvesecurity.com/#/welcome), [Altamira HRM](../saas-apps/altamira-hrm-tutorial.md), [WireWheel](../saas-apps/wirewheel-tutorial.md), [Zix Compliance and Capture](https://sminstall.zixcorp.com/teams/teams.php?install_request=true&tenant_id=common), [Greenlight Enterprise Business Controls Platform](../saas-apps/greenlight-enterprise-business-controls-platform-tutorial.md), [Genetec Clearance](https://www.clearance.network/), [iSAMS](../saas-apps/isams-tutorial.md), [VeraSMART](../saas-apps/verasmart-tutorial.md), [Amiko](https://amiko.web.rivero.app/), [Twingate](https://auth.twingate.com/signup), [Funnel Leasing](https://nestiolistings.com/sso/oidc/azure/authorize/), [Scalefusion](https://scalefusion.com/users/sign_in/), [Bpanda](https://goto.bpanda.com/login), [Vivun Calendar Connect](https://app.vivun.com/dashboard/calendar/connect), [FortiGate SSL VPN](../saas-apps/fortigate-ssl-vpn-tutorial.md), [Wandera End User](https://www.wandera.com/)

-[Clap Your Hands](http://www.rmit.com.ar/), [Appreiz](https://microsoftteams.appreiz.com/), [Inextor Vault](https://inexto.com/inexto-suite/inextor), [Beekast](https://my.beekast.com/), [Templafy OpenID Connect](https://app.templafy.com/), [PeterConnects receptionist](https://msteams.peterconnects.com/), [AlohaCloud](https://appfusions.alohacloud.com/auth), [Control Tower](https://bpm.tnxcorp.com/sso/microsoft), [Cocoom](https://start.cocoom.com/), [COINS Construction Cloud](https://sso.coinsconstructioncloud.com/#login/), [Medxnote MT](https://task.teamsmain.medx.im/authorization), [Reflekt](https://reflekt.konsolute.com/login), [Rever](https://app.reverscore.net/access), [MyCompanyArchive](https://login.mycompanyarchive.com/), [GReminders](https://app.greminders.com/o365-oauth), [Titanfile](../saas-apps/titanfile-tutorial.md), [Wootric](../saas-apps/wootric-tutorial.md), [SolarWinds Orion](https://support.solarwinds.com/SuccessCenter/s/orion-platform?language=en_US), [OpenText Directory Services](../saas-apps/opentext-directory-services-tutorial.md), [Datasite](../saas-apps/datasite-tutorial.md), [BlogIn](../saas-apps/blogin-tutorial.md), [IntSights](../saas-apps/intsights-tutorial.md), [kpifire](../saas-apps/kpifire-tutorial.md), [Textline](../saas-apps/textline-tutorial.md), [Cloud Academy - SSO](../saas-apps/cloud-academy-sso-tutorial.md), [Community Spark](../saas-apps/community-spark-tutorial.md), [Chatwork](../saas-apps/chatwork-tutorial.md), [CloudSign](../saas-apps/cloudsign-tutorial.md), [C3M Cloud Control](../saas-apps/c3m-cloud-control-tutorial.md), [SmartHR](https://smarthr.jp/), [NumlyEngageΓäó](../saas-apps/numlyengage-tutorial.md), [Michigan Data Hub Single Sign-On](../saas-apps/michigan-data-hub-single-sign-on-tutorial.md), [Egress](../saas-apps/egress-tutorial.md), [SendSafely](../saas-apps/sendsafely-tutorial.md), [Eletive](https://app.eletive.com/), [Right-Hand Cybersecurity ADI](https://right-hand.ai/), [Fyde Enterprise Authentication](https://enterprise.fyde.com/), [Verme](../saas-apps/verme-tutorial.md), [Lenses.io](../saas-apps/lensesio-tutorial.md), [Momenta](../saas-apps/momenta-tutorial.md), [Uprise](https://app.uprise.co/sign-in), [Q](https://q.moduleq.com/login), [CloudCords](../saas-apps/cloudcords-tutorial.md), [TellMe Bot](https://tellme365liteweb.azurewebsites.net/), [Inspire](https://app.inspiresoftware.com/), [Maverics Identity Orchestrator SAML Connector](https://www.strata.io/identity-fabric/), [Smartschool (School Management System)](https://smartschoolz.com/login), [Zepto - Intelligent timekeeping](https://user.zepto-ai.com/signin), [Studi.ly](https://studi.ly/), [Trackplan](http://www.trackplanfm.com/), [Skedda](../saas-apps/skedda-tutorial.md), [WhosOnLocation](../saas-apps/whos-on-location-tutorial.md), [Coggle](../saas-apps/coggle-tutorial.md), [Kemp LoadMaster](https://kemptechnologies.com/cloud-load-balancer/), [BrowserStack Single Sign-on](../saas-apps/browserstack-single-sign-on-tutorial.md)

-**Type:** New feature

-[Azure AD SAML Toolkit](../saas-apps/saml-toolkit-tutorial.md), [Otsuka Shokai (大塚商会)](../saas-apps/otsuka-shokai-tutorial.md), [ANAQUA](../saas-apps/anaqua-tutorial.md), [Azure VPN Client](https://portal.azure.com/), [ExpenseIn](../saas-apps/expensein-tutorial.md), [Helper Helper](../saas-apps/helper-helper-tutorial.md), [Costpoint](../saas-apps/costpoint-tutorial.md), [GlobalOne](../saas-apps/globalone-tutorial.md), [Mercedes-Benz In-Car Office](https://me.secure.mercedes-benz.com/), [Skore](https://app.justskore.it/), [Oracle Cloud Infrastructure Console](../saas-apps/oracle-cloud-tutorial.md), [CyberArk SAML Authentication](../saas-apps/cyberark-saml-authentication-tutorial.md), [Scrible Edu](https://www.scrible.com/sign-in/#/create-account), [PandaDoc](../saas-apps/pandadoc-tutorial.md), [Perceptyx](https://apexdata.azurewebsites.net/docs.microsoft.com/azure/active-directory/saas-apps/perceptyx-tutorial), [Proptimise OS](https://proptimise.co.uk/), [Vtiger CRM (SAML)](../saas-apps/vtiger-crm-saml-tutorial.md), Oracle Access Manager for Oracle Retail Merchandising, Oracle Access Manager for Oracle E-Business Suite, Oracle IDCS for E-Business Suite, Oracle IDCS for PeopleSoft, Oracle IDCS for JD Edwards

-**Type:** New feature

-# Configure separation of duties checks for an access package in Azure AD entitlement management (Preview)

-1. In the left menu, click **Separation of duties (preview)**.

-1. In the left menu, click **Separation of duties (preview)**.

-When a user grants consent on his or her own behalf, the following events occur:

-| Azure Media services | [Managed identities](/media-services/latest/concept-managed-identities) |

-| Azure Media services | [Access the Azure Media Services API with Azure AD authentication](/media-services/previous/media-services-use-aad-auth-to-access-ams-api) |

-5. Under the **Admin Credentials** section, input the **SCIM 2.0 base URL** of https://scim.smartsheet.com/v2 and **Access Token** value retrieved earlier from Smartsheet in **Secret Token** respectively. Click **Test Connection** to ensure Azure AD can connect to Smartsheet. If the connection fails, ensure your Smartsheet account has SysAdmin permissions and try again.

-* 02/12/2022 - Added SCIM base/tenant URL of https://scim.smartsheet.com/v2 for SmartSheet integration under Admin Credentials section.

-| [Microsoft Defender for Cloud Apps](%20/defender-cloud-apps/what-is-defender-for-cloud-apps) (MDCA)| Previously known as Microsoft Cloud App Security (MCAS), Defender for Cloud Apps scans firewall logs to detect cloud apps, IaaS and PaaS services used by your organization. Integrating MDCA with Defender for Endpoint allows discovery to happen from data analyzed from window client devices. |

-It's important to monitor your Azure AD tenant. You must adopt an "assume breach" mindset and meet compliance standards set forth in [Memorandum M-22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf) and [Memorandum M-21-31](https://www.whitehouse.gov/wp-content/uploads/2021/M-21-31). There are three primary log types used for security analysis and ingestion:

-Learn more about [Media Service - AccountQuotaLimit (Increase Media Services quotas or limits to ensure continuity of service.)](/media-services/latest/limits-quotas-constraints-reference).

-| `net.netfilter.nf_conntrack_max` | 131072 - 589824 | 131072 | `nf_conntrack` is a module that tracks connection entries for NAT within Linux. The `nf_conntrack` module uses a hash table to record the *established connection* record of the TCP protocol. `nf_conntrack_max` is the maximum number of nodes in the hash table, that is, the maximum number of connections supported by the `nf_conntrack` module or the size of connection tracking table. |

- To restore app content only and not the app configuration, use the `--restore-content-only` parameter. For more information, see [az webapp config snapshot restore](/cli/webapp/config/snapshot#az-webapp-config-snapshot-restore).

- By default, values for app settings are hidden in the portal for security. To see a hidden value of an app setting, click its **Value** field. To see the hidden values of all app settings, click the **Show value** button.

-description: Learn how to attach custom network share in a containerized app in Azure App Service. Share files between apps, manage static content remotely and access locally, etc.

-# Mount Azure Storage as a local share in a custom container in App Service

-curl -X POST -u <username> --data-binary @"<zip-package-path>" https://<app-name>.scm.azurewebsites.net/api/publish?type=zip

-curl -X POST -u <username> https://<app-name>.scm.azurewebsites.net/api/publish -d '{"packageUri": "https://storagesample.blob.core.windows.net/sample-container/myapp.zip?sv=2021-10-01&sb&sig=slk22f3UrS823n4kSh8Skjpa7Naj4CG3"}'

-<!-- markdownlint-disable MD044 -->

-<!-- markdownlint-enable MD044 -->

-> [!NOTE]

-> Azure PowerShell is recommended for creating apps on the Windows hosting platform. To create apps on Linux, use a different tool, such as [Azure CLI](quickstart-dotnetcore.md?pivots=development-environment-cli)

- az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app-name> --runtime 'PHP|7.4' --deployment-local-git

-az sql server firewall-rule create -resource-group msdocs-core-sql --server <yoursqlserver> --name LocalAccess --start-ip-address <your-ip> --end-ip-address <your-ip>

-If you are working in VS Code, right-click the database server and select **Open in Portal** to go to the Azure portal. Or, go to the [Azure Cloud Shell](https://shell.zure.com) and run the Azure CLI commands.

-The size of the error page must be less than 1 MB. You may reference either internal or external images/CSS for this HTML file. For externally referenced resources, use absolute URLs that are publicly accessible. Be aware of the HTML file size when using internal images (Base64-encoded inline image) or CSS. Relative links with files in the same blob location are currently not supported.

-1. In the **Source: URL** field, paste paste the following URL `https://raw.githubusercontent.com/Azure-Samples/cognitive-services-REST-api-samples/master/curl/form-recognizer/layout-page-001.jpg` and select the **Fetch** button.

-# Tutorial: Use GitOps with Flux v2 in Azure Arc-enabled Kubernetes or AKS clusters (public preview)

-General availability of Azure Arc-enabled Kubernetes includes GitOps with Flux v1. The public preview of GitOps with Flux v2, documented here, is available in both AKS and Azure Arc-enabled Kubernetes. Flux v2 is the way forward, and Flux v1 will eventually be deprecated.

->GitOps with Flux v2 is in public preview. In preparation for general availability, features are still being added to the preview. One important feature, multi-tenancy, could affect some users when it is released. To prepare yourself for the release of multi-tenancy, [please review these details](#multi-tenancy).

-GitOps is currently supported in the regions that Azure Arc-enabled Kubernetes supports. These regions are a subset of the regions that AKS supports. GitOps is currently not supported in all AKS regions. [See the supported regions](https://azure.microsoft.com/global-infrastructure/services/?regions=all&products=kubernetes-service,azure-arc). The GitOps service is adding new supported regions on a regular cadence.

-The GitOps agents require TCP on port 443 (`https://:443`) to function. The agents also require the following outbound URLs:

->The `k8s-configuration` CLI extension has been upgraded to manage either Flux v2 or Flux v1 configurations. Flux v2 is an important upgrade to Flux v1, and eventually Azure will stop supporting GitOps with Flux v1. Begin using Flux v2 as soon as possible.

-You can also use the portal to create and delete GitOps configurations.

-Flux v2 supports [multi-tenancy](https://github.com/fluxcd/flux2-multi-tenancy) in [version 0.26](https://fluxcd.io/blog/2022/01/january-update/#flux-v026-more-secure-by-default). This capability will be integrated into Azure GitOps with Flux v2 prior to general availability.

->You need to prepare for the multi-tenancy feature release if you have any cross-namespace sourceRef for HelmRelease, Kustomization, ImagePolicy, or other objects, or [if you use a Kubernetes version less than 1.20.6](https://fluxcd.io/blog/2022/01/january-update/#flux-v026-more-secure-by-default). To prepare, take these actions:

-Multi-tenancy will be enabled by default to assure security by default in your clusters. However, if you need to disable multi-tenancy, you can opt out by creating or updating the `microsoft.flux` extension in your clusters with "--configuration-settings multiTenancy.enforce=false".

-If you've been using Flux v1 in Azure Arc-enabled Kubernetes or AKS clusters and want to migrate to using Flux v2 in the same clusters, you first need to delete the Flux v1 `sourceControlConfigurations` from the clusters. The `microsoft.flux` cluster extension won't be installed if there are `sourceControlConfigurations` resources installed in the cluster.

-The examples refer to a `ToDoItem` type and a corresponding database table:

-```cs

-namespace AzureSQLSamples

-{

- public class ToDoItem

- {

- public string Id { get; set; }

- public int Priority { get; set; }

- public string Description { get; set; }

- }

-}

-```

-```sql

-CREATE TABLE dbo.ToDo (

- [Id] int primary key,

- [Priority] int null,

- [Description] nvarchar(200) not null

-)

-```

- [Sql("select * from dbo.ToDo where Id = @Id",

- [Sql("select * from dbo.ToDo where [Priority] > @Priority",

-The examples refer to a `ToDoItem` type and a corresponding database table:

-```cs

-namespace AzureSQLSamples

-{

- public class ToDoItem

- {

- public string Id { get; set; }

- public int Priority { get; set; }

- public string Description { get; set; }

- }

-}

-```

-```sql

-CREATE TABLE dbo.ToDo (

- [Id] int primary key,

- [Priority] int null,

- [Description] nvarchar(200) not null

-)

-```

-The following example shows a [C# function](functions-dotnet-class-library.md) that adds a document to a database, using data provided in message from Queue storage.

-```cs

-using Microsoft.Azure.WebJobs;

-using Microsoft.Azure.WebJobs.Host;

-using Microsoft.Extensions.Logging;

-using System;

-namespace AzureSQLSamples

- public static class WriteOneRecord

- [FunctionName("WriteOneRecord")]

- public static IActionResult Run(

- [HttpTrigger(AuthorizationLevel.Function, "get", Route = "addtodo")] HttpRequest req,

- [Sql("dbo.ToDo", ConnectionStringSetting = "SqlConnectionString")] out ToDoItem newItem)

- newItem = new ToDoItem

- Id = req.Query["id"],

- Description =req.Query["desc"]

- };

- log.LogInformation($"C# HTTP trigger function inserted one row");

- return new CreatedResult($"/api/addtodo", newItem);

-The following example shows a [C# function](functions-dotnet-class-library.md) that adds a collection of records to a database, using data provided in an HTTP POST body JSON.

- [Sql("dbo.Products", ConnectionStringSetting = "SqlConnectionString")] IAsyncCollector<ToDoItem> newItems)

- - name: Setup Node 12.x Environment

- NODE_VERSION: '12.x' # set this to the node version to use (supports 8.x, 10.x, 12.x)

- NODE_VERSION: '10.x' # set this to the node version to use (supports 8.x, 10.x, 12.x)

-Azure addresses the perceived risk of resource sharing by providing a trustworthy foundation for assuring multi-tenant, cryptographically certain, logically isolated cloud services using a common set of principles: (1) user access controls with authentication and identity separation, (2) compute isolation for processing, (3) networking isolation including data encryption in transit, (4) storage isolation with data encryption at rest, and (5) security assurance processes embedded in service design to correctly develop logically isolated services.

-Multi-tenancy in the public cloud improves efficiency by multiplexing resources among disparate customers at low costs; however, this approach introduces the perceived risk associated with resource sharing. Azure addresses this risk by providing a trustworthy foundation for isolated cloud services using a multi-layered approach depicted in Figure 1.

- - *User context-based isolation* for services that are composed solely of Microsoft-controlled code and customer code is not allowed to run. </br>

-In addition to robust logical compute isolation available by design to all Azure tenants, if you desire physical compute isolation, you can use Azure Dedicated Host or Isolated Virtual Machines, which are deployed on server hardware dedicated to a single customer.

-In line with the [shared responsibility](../security/fundamentals/shared-responsibility.md) model in cloud computing, as you migrate workloads from your on-premises datacenter to the cloud, the delineation of responsibility between you and cloud service provider varies depending on the cloud service model. For example, with the Infrastructure as a Service (IaaS) model, MicrosoftΓÇÖs responsibility ends at the Hypervisor layer, and you are responsible for all layers above the virtualization layer, including maintaining the base operating system in guest VMs. You can use Azure isolation technologies to achieve the desired level of isolation for your applications and data deployed in the cloud.

-> Use of Azure Key Vault for Customer Managed Keys (CMK) is optional and represents your responsibility.

-> *Additional resources:*

-> For recommendations on how to improve the security of applications and data deployed in Azure, you should review the **[Azure Security Benchmark](../security/benchmarks/index.yml)**.

-> Additional resources:

-> - To learn more about how to implement Zero Trust architecture on Azure, read the **[6-part blog series](https://devblogs.microsoft.com/azuregov/implementing-zero-trust-with-microsoft-azure-identity-and-access-management-1-of-6/)**.

-The separation of the accounts used to administer cloud applications is critical to achieving logical isolation. Account isolation in Azure is achieved using [Azure Active Directory](../active-directory/fundamentals/active-directory-whatis.md) (Azure AD) and its capabilities to support granular [Azure role-based access control](../role-based-access-control/overview.md) (Azure RBAC). Each Azure account is associated with one Azure AD tenant. Users, groups, and applications from that directory can manage resources in Azure. You can assign appropriate access rights using the Azure portal, Azure command-line tools, and Azure Management APIs. Each Azure AD tenant is distinct and separate from other Azure ADs. An Azure AD instance is logically isolated using security boundaries to prevent customer data and identity information from comingling, thereby ensuring that users and administrators of one Azure AD cannot access or compromise data in another Azure AD instance, either maliciously or accidentally. Azure AD runs physically isolated on dedicated servers that are logically isolated to a dedicated network segment and where host-level packet filtering and Windows Firewall services provide extra protections from untrusted traffic.

-With Key Vault, you can import or generate encryption keys in HSMs, ensuring that keys never leave the HSM protection boundary to support *bring your own key* (BYOK) scenarios, as shown in Figure 3. **Keys generated inside the Key Vault HSMs are not exportable ΓÇô there can be no clear-text version of the key outside the HSMs.** This binding is enforced by the underlying HSM. BYOK functionality is available with both [key vaults](../key-vault/keys/hsm-protected-keys.md) and [managed HSMs](../key-vault/managed-hsm/hsm-protected-keys-byok.md). Methods for transferring HSM-protected keys to Key Vault vary depending on the underlying HSM, as explained in online documentation.

-**Azure Key Vault is designed, deployed, and operated such that Microsoft and its agents do not see or extract your cryptographic keys.**

-Azure AD enforces tenant isolation and implements robust measures to prevent access by unauthorized parties, as described previously in *[Azure Active Directory](#azure-active-directory)* section. Access to a key vault or managed HSM is controlled through two interfaces or planes - management plane and data plane - with both planes using Azure AD for authentication.

- - Operations on the key vault such as creation, deletion, setting access policies, etc.

- - Operations on keys and secrets in the key vault, including a) creating, modifying, or deleting keys or secrets, and b) signing, verifying, encrypting keys, etc.

-> *Additional resources:*

-You can also use the [Azure Key Vault solution in Azure Monitor](../azure-monitor/insights/key-vault-insights-overview.md) to review Key Vault logs. To use this solution, you need to enable logging of Key Vault diagnostics and direct the diagnostics to a Log Analytics workspace. With this solution, it is not necessary to write logs to Azure Blob storage.

-**[Vaults](../key-vault/general/overview.md)** provide a multi-tenant, low-cost, easy to deploy, zone-resilient (where available), and highly available key management solution suitable for most common cloud application scenarios. Vaults can store and safeguard [secrets, keys, and certificates](../key-vault/general/about-keys-secrets-certificates.md). They can be either software-protected (standard tier) or HSM-protected (premium tier). To see a comparison between the standard and premium tiers, see the [Azure Key Vault pricing page](https://azure.microsoft.com/pricing/details/key-vault/). Software-protected secrets, keys, and certificates are safeguarded by Azure, using industry-standard algorithms and key lengths. If you require extra assurances, you can choose to safeguard your secrets, keys, and certificates in vaults protected by multi-tenant HSMs. The corresponding HSMs are validated according to the [FIPS 140 standard](/azure/compliance/offerings/offering-fips-140-2), and have an overall Security Level 2 rating, which includes requirements for physical tamper evidence and role-based authentication. These HSMs meet Security Level 3 rating for several areas, including physical security, electromagnetic interference / electromagnetic compatibility (EMI/EMC), design assurance, and roles, services, and authentication.

-Vaults enable support for [customer-managed keys](../security/fundamentals/encryption-models.md) (CMK) where you can control your own keys in HSMs and use them to encrypt data at rest for a wide range of Azure services. As mentioned previously, you can [import or generate encryption keys](../key-vault/keys/hsm-protected-keys.md) in HSMs ensuring that keys never leave the HSM boundary to support bring your own key (BYOK) scenarios.

-> *Additional resources:*

-**[Managed HSM](../key-vault/managed-hsm/overview.md)** provides a single-tenant, fully managed, highly available, zone-resilient (where available) HSM as a service to store and manage your cryptographic keys. It is most suitable for applications and usage scenarios that handle high value keys. It also helps you meet the most stringent security, compliance, and regulatory requirements. Managed HSM uses [FIPS 140 Level 3 validated HSMs](/azure/compliance/offerings/offering-fips-140-2) to protect your cryptographic keys. Each managed HSM pool is an isolated single-tenant instance with its own [security domain](../key-vault/managed-hsm/security-domain.md) controlled by you and isolated cryptographically from instances belonging to other customers. Cryptographic isolation relies on [Intel Software Guard Extensions](https://software.intel.com/sgx) (SGX) technology that provides encrypted code and data to help ensure your control.

-> Unlike with key vaults, granting your users management plane access to a managed HSM does not grant them any access to data plane to access keys or data plane role assignments managed HSM local RBAC. This isolation is by design to prevent inadvertent expansion of privileges affecting access to keys stored in managed HSMs.

-As mentioned previously, managed HSM supports [importing keys generated](../key-vault/managed-hsm/hsm-protected-keys-byok.md) in your on-premises HSMs, ensuring the keys never leave the HSM protection boundary, also known as bring your own key (BYOK) scenario. Managed HSM supports integration with Azure services such as [Azure Storage](../storage/common/customer-managed-keys-overview.md), [Azure SQL Database](../azure-sql/database/transparent-data-encryption-byok-overview.md), [Azure Information Protection](/azure/information-protection/byok-price-restrictions), and others.

-Physical servers hosting VMs are grouped into clusters, and they are independently managed by a scaled-out and redundant platform software component called the **[Fabric Controller](../security/fundamentals/isolation-choices.md#the-azure-fabric-controller)** (FC). Each FC manages the lifecycle of VMs running in its cluster, including provisioning and monitoring the health of the hardware under its control. For example, the FC is responsible for recreating VM instances on healthy servers when it determines that a server has failed. It also allocates infrastructure resources to tenant workloads and it manages unidirectional communication from the Host to virtual machines. Dividing the compute infrastructure into clusters isolates faults at the FC level and prevents certain classes of errors from affecting servers beyond the cluster in which they occur.

-The FC is the brain of the Azure compute platform and the Host Agent is its proxy, integrating servers into the platform so that the FC can deploy, monitor, and manage the virtual machines used by you and Azure cloud services. The Hypervisor/Host OS pairing applies decades of MicrosoftΓÇÖs experience in operating system security, including security focused investments in [Microsoft Hyper-V](/windows-server/virtualization/hyper-v/hyper-v-technology-overview) to provide strong isolation of Guest VMs. Hypervisor isolation is discussed later in this section, including assurances for strongly defined security boundaries enforced by the Hypervisor, defense-in-depth exploit mitigation, and strong security assurance processes.

-Communication is permitted from the FC VLAN to the main VLAN but cannot be initiated from the main VLAN to the FC VLAN. This bridge from the FC VLAN to the Main VLAN is used to reduce the overall complexity and improve reliability/resiliency of the network. The connection is secured in several ways to ensure that commands are trusted and successfully routed:

-Communication is also blocked from the main VLAN to the device VLAN. This way, even if a node running customer code is compromised, it cannot attack nodes on either the FC or device VLANs.

-The Hypervisor and the Host OS provide network packet filters so untrusted VMs cannot generate spoofed traffic or receive traffic not addressed to them, direct traffic to protected infrastructure endpoints, or send/receive inappropriate broadcast traffic. By default, traffic is blocked when a VM is created, and then the FC agent configures the packet filter to add rules and exceptions to allow authorized traffic. More detailed information about network traffic isolation and separation of tenant traffic is provided in *[Networking isolation](#networking-isolation)* section.

-The Azure FC allocates infrastructure resources to tenants and manages unidirectional communications from the Host OS to Guest VMs. The VM placement algorithm of the Azure FC is highly sophisticated and nearly impossible to predict. The FA resides in the Host OS and it manages tenant VMs. The collection of the Azure Hypervisor, Host OS and FA, and customer VMs constitute a compute node, as shown in Figure 4. FCs manage FAs although FCs exist outside of compute nodes - separate FCs exist to manage compute and storage clusters. If you update your applicationΓÇÖs configuration file while running in the MC, the MC communicates through CRP with the FC and the FC communicates with the FA.

-Communications among various components (for example, Azure Resource Manager to and from CRP, CRP to and from FC, FC to and from Hypervisor Agent) all operate on different communication channels with different identities and different permissions sets. This design follows common least-privilege models to ensure that a compromise of any single layer will prevent more actions. Separate communications channels ensure that communications cannot bypass any layer in the chain. Figure 6 illustrates how the MC and MP securely communicate within the Azure cloud for Hypervisor interaction initiated by a userΓÇÖs [OAuth 2.0 authentication to Azure Active Directory](../active-directory/azuread-dev/v1-protocols-oauth-code.md).

-The Azure Hypervisor makes extensive use of these processor facilities to provide isolation between partitions. The emergence of speculative side channel attacks has identified potential weaknesses in some of these processor isolation capabilities. In a multi-tenant architecture, any cross-VM attack across different tenants involves two steps: placing an adversary-controlled VM on the same Host as one of the victim VMs, and then breaching the logical isolation boundary to perform a side-channel attack. Azure provides protection from both threat vectors by using an advanced VM placement algorithm enforcing memory and process separation for logical isolation, and secure network traffic routing with cryptographic certainty at the Hypervisor. As discussed in section titled *[Exploitation of vulnerabilities in virtualization technologies](#exploitation-of-vulnerabilities-in-virtualization-technologies)* later in the article, the Azure Hypervisor has been architected to provide robust isolation within the hypervisor itself that helps mitigate a wide range of sophisticated side channel attacks.

-|**Platform integrity**|The integrity of the Hypervisor depends on the integrity of the hardware and software on which it relies. Although the Hypervisor does not have direct control over the integrity of the platform, Azure relies on hardware and firmware mechanisms such as the [Cerberus](https://azure.microsoft.com/blog/microsoft-creates-industry-standards-for-datacenter-hardware-storage-and-security/) security microcontroller to [protect the underlying platform integrity](https://www.youtube.com/watch?v=oUvKEw8OchI), thereby preventing the VMM and Guests from running should platform integrity be compromised.|

- - [Arbitrary Code Guard](https://blogs.windows.com/msedgedev/2017/02/23/mitigating-arbitrary-native-code-execution/) ΓÇô Dynamically generated code cannot be loaded in the VM Worker process.

- - NoChildProcess ΓÇô The worker process cannot create child processes (useful for bypassing CFG).

- - NoLowImages / NoRemoteImages ΓÇô The worker process cannot load DLLΓÇÖs over the network or DLLΓÇÖs that were written to disk by a sandboxed process.

- - NoWin32k ΓÇô The worker process cannot communicate with Win32k, which makes sandbox escapes more difficult.

-|**Control flow integrity**|Increases cost to perform control flow integrity attacks (for example, return-orientedΓÇöprogramming exploits)|[Control Flow Guard](https://www.blackhat.com/docs/us-16/materials/us-16-Weston-Windows-10-Mitigation-Improvements.pdf) (CFG) ensures indirect control flow transfers are instrumented at compile time and enforced by the kernel (user-mode) or secure kernel (kernel-mode), mitigating stack return vulnerabilities.|

-Pico-processes are grouped into isolation units called *sandboxes*. The sandbox defines the applications, file system, and external resources available to the pico-processes. When a process running inside a pico-process creates a new child process, it is run with its own Library OS in a separate pico-process inside the same sandbox. Each sandbox communicates to the Security Monitor and is not able to communicate with other sandboxes except via allowed I/O channels (sockets, named pipes etc.), which need to be explicitly allowed by the configuration given the default opt-in approach depending on service needs. The outcome is that code running inside a pico-process can only access its own resources and cannot directly attack the Host system or any colocated sandboxes. It is only able to affect objects inside its own sandbox.

-When the pico-process needs system resources, it must call into the Drawbridge host to request them. The normal path for a virtual user process would be to call the Library OS to request resources and the Library OS would then call into the ABI. Unless the policy for resource allocation is set up in the driver itself, the Security Monitor would handle the ABI request by checking policy to see if the request is allowed and then servicing the request. This mechanism is used for all system primitives therefore ensuring that the code running in the pico-process cannot abuse the resources from the Host machine.

-In cases where an Azure service is composed of Microsoft-controlled code and customer code is not allowed to run, the isolation is provided by a user context. These services accept only user configuration inputs and data for processing ΓÇô arbitrary code is not allowed. For these services, a user context is provided to establish the data that can be accessed and what Azure role-based access control (Azure RBAC) operations are allowed. This context is established by Azure Active Directory (Azure AD) as described earlier in *[Identity-based isolation](#identity-based-isolation)* section. Once the user has been identified and authorized, the Azure service creates an application user context that is attached to the request as it moves through execution, providing assurance that user operations are separated and properly isolated.

-You can deploy both Windows and Linux virtual machines into dedicated hosts by selecting the server and CPU type, number of cores, and extra features. Dedicated Host enables control over platform maintenance events by allowing you to opt in to a maintenance window to reduce potential impact to your provisioned services. Most maintenance events have little to no impact on your VMs; however, if you are in a highly regulated industry or with a sensitive workload, you may want to have control over any potential maintenance impact.

-The logical isolation of tenant infrastructure in a public multi-tenant cloud is [fundamental to maintaining security](https://azure.microsoft.com/resources/azure-network-security/). The overarching principle for a virtualized solution is to allow only connections and communications that are necessary for that virtualized solution to operate, blocking all other ports and connections by default. Azure [Virtual Network](../virtual-network/virtual-networks-overview.md) (VNet) helps ensure that your private network traffic is logically isolated from traffic belonging to other customers. Virtual Machines (VMs) in one VNet cannot communicate directly with VMs in a different VNet even if both VNets are created by the same customer. [Networking isolation](../security/fundamentals/isolation-choices.md#networking-isolation) ensures that communication between your VMs remains private within a VNet. You can connect your VNets via [VNet peering](../virtual-network/virtual-network-peering-overview.md) or [VPN gateways](../vpn-gateway/vpn-gateway-about-vpngateways.md), depending on your connectivity options, including bandwidth, latency, and encryption requirements.

-Network access to VMs is limited by packet filtering at the network edge, at load balancers, and at the Host OS level. You can additionally configure your host firewalls to further limit connectivity, specifying for each listening port whether connections are accepted from the Internet or only from role instances within the same cloud service or VNet.

- - VMs cannot capture any traffic on the network that is not intended for them.

-These implementations give each service the illusion that all the servers assigned to it, and only those servers, are connected by a single non-interfering Ethernet switch ΓÇô a Virtual Layer 2 (VL2) ΓÇô and maintain this illusion even as the size of each service varies from one server to hundreds of thousands. This VL2 implementation achieves traffic performance isolation, ensuring that it is not possible for the traffic of one service to be affected by the traffic of any other service, as if each service were connected by a separate physical switch.

-A server cannot send packets to a PA if the directory service refuses to provide it with a CA through which it can route its packets, which means that the directory service enforces access control policies. Further, since the directory system knows which server is making the request when handling a lookup, it can **enforce fine-grained isolation policies**. For example, it can enforce a policy that only servers belonging to the same service can communicate with each other.

-You are also able to use Azure services to further isolate and protect your resources. Using [network security groups](../virtual-network/manage-network-security-group.md) (NSGs), a feature of Azure Virtual Network, you can filter traffic by source and destination IP address, port, and protocol via multiple inbound and outbound security rules ΓÇô essentially acting as a distributed virtual firewall and IP-based network access control list (ACL). You can apply an NSG to each NIC in a virtual machine, apply an NSG to the subnet that a NIC or another Azure resource is connected to, and directly to virtual machine scale set, allowing finer control over your infrastructure.

-At the infrastructure layer, Azure implements a Hypervisor firewall to protect all tenants running within virtual machines on top of the Hypervisor from unauthorized access. This Hypervisor firewall is distributed as part of the NSG rules deployed to the Host, implemented in the Hypervisor, and configured by the Fabric Controller agent, as shown in Figure 4. The Host OS instances use the built-in Windows Firewall to implement fine-grained ACLs at a greater granularity than router ACLs - they are maintained by the same software that provisions tenants, so they are never out of date. The fine-grained ACLs are applied using the Machine Configuration File (MCF) to Windows Firewall.

-At the top of the operating system stack is the Guest OS, which you use as your operating system. By default, this layer does not allow any inbound communication to cloud service or virtual network, essentially making it part of a private network. For PaaS Web and Worker roles, remote access is not permitted by default. You can enable Remote Desktop Protocol (RDP) access as an explicit option. For IaaS VMs created using the Azure portal, RDP and remote PowerShell ports are opened by default; however, port numbers are assigned randomly. For IaaS VMs created via PowerShell, RDP and remote PowerShell ports must be opened explicitly. If the administrator chooses to keep the RDP and remote PowerShell ports open to the Internet, the account allowed to create RDP and PowerShell connections should be secured with a strong password. Even if ports are open, you can define ACLs on the public IPs for extra protection if desired.

-> You can create inbound/outbound network security group rules to deny traffic to/from the Internet and allow traffic to/from Azure. Service tags are available for a wide range of Azure services for use in network security group rules.

-> *Additional resources:*

-> *Additional resources:*

-**Transport Layer Security (TLS):** Azure uses the TLS protocol to help protect data when it is traveling between your end users and Azure services. Most of your end users will connect to Azure over the Internet, and the precise routing of network traffic will depend on the many network providers that contribute to Internet infrastructure. As stated in the Microsoft Online Services Terms [Data Protection Addendum](https://aka.ms/DPA) (DPA), Microsoft does not control or limit the regions from which you or your end users may access or move customer data.

-**In-transit encryption for VMs:** Remote sessions to Windows and Linux VMs deployed in Azure can be conducted over protocols that ensure data encryption in transit. For example, the [Remote Desktop Protocol](/windows/win32/termserv/remote-desktop-protocol) (RDP) initiated from your client computer to Windows and Linux VMs enables TLS protection for data in transit. You can also use [Secure Shell](../virtual-machines/linux/ssh-from-windows.md) (SSH) to connect to Linux VMs running in Azure. SSH is an encrypted connection protocol available by default for remote management of Linux VMs hosted in Azure.

-**Azure Storage transactions:** When interacting with Azure Storage through the Azure portal, all transactions take place over HTTPS. Moreover, you can configure your storage accounts to accept requests only from secure connections by setting the &#8220;[secure transfer required](../storage/common/storage-require-secure-transfer.md)&#8221; property for the storage account. The &#8220;secure transfer required&#8221; option is enabled by default when creating a Storage account in the Azure portal.

-**VPN encryption:** [Virtual Network](../virtual-network/virtual-networks-overview.md) (VNet) provides a means for Azure Virtual Machines (VMs) to act as part of your internal (on-premises) network. With VNet, you choose the address ranges of non-globally-routable IP addresses to be assigned to the VMs so that they will not collide with addresses you are using elsewhere. You have options to securely connect to a VNet from your on-premises infrastructure or remote locations.

-**Azure ExpressRoute encryption:** [Azure ExpressRoute](../expressroute/expressroute-introduction.md) allows you to create private connections between Microsoft datacenters and your on-premises infrastructure or colocation facility. ExpressRoute connections do not go over the public Internet and offer lower latency and higher reliability than IPsec protected VPN connections. [ExpressRoute locations](../expressroute/expressroute-locations-providers.md) are the entry points to MicrosoftΓÇÖs global network backbone and they may or may not match the location of Azure regions. Once the network traffic enters the Microsoft backbone, it is guaranteed to traverse that private networking infrastructure instead of the public Internet. You can use ExpressRoute with several data [encryption options](../expressroute/expressroute-about-encryption.md), including [MACsec](https://1.ieee802.org/security/802-1ae/) that enable you to store [MACsec encryption keys in Azure Key Vault](../expressroute/expressroute-about-encryption.md#point-to-point-encryption-by-macsec-faq). MACsec encrypts data at the Media Access Control (MAC) level, that is, data link layer (Network Layer 2). Both AES-128 and AES-256 block ciphers are [supported for encryption](../expressroute/expressroute-about-encryption.md#which-cipher-suites-are-supported-for-encryption). You can use MACsec to encrypt the physical links between your network devices and Microsoft network devices when you connect to Microsoft via [ExpressRoute Direct](../expressroute/expressroute-erdirect-about.md). ExpressRoute Direct allows for direct fiber connections from your edge to the Microsoft Enterprise edge routers at the peering locations.

-Azure services such as Storage and SQL Database can be configured for geo-replication to help ensure durability and high availability especially for disaster recovery scenarios. Azure relies on [paired regions](../availability-zones/cross-region-replication-azure.md) to deliver [geo-redundant storage](../storage/common/storage-redundancy.md) (GRS) and paired regions are also recommended when configuring active [geo-replication](../azure-sql/database/active-geo-replication-overview.md) for Azure SQL Database. Paired regions are located within the same geography; however, network traffic is not guaranteed to always follow the same path from one Azure region to another. To provide the reliability needed for the Azure cloud, Microsoft has many physical networking paths with automatic routing around failures for optimal reliability.

-Azure provides you with many features to help you achieve your security and isolation goals, including [Microsoft Defender for Cloud](../defender-for-cloud/defender-for-cloud-introduction.md), [Azure Monitor](../azure-monitor/overview.md), [Azure Firewall](../firewall/overview.md), [VPN Gateway](../vpn-gateway/vpn-gateway-about-vpngateways.md), [network security groups](../virtual-network/network-security-groups-overview.md), [Application Gateway](../application-gateway/overview.md), [Azure DDoS Protection](../ddos-protection/ddos-protection-overview.md), [Network Watcher](../network-watcher/network-watcher-monitoring-overview.md), [Microsoft Sentinel](../sentinel/overview.md), and [Azure Policy](../governance/policy/overview.md). In addition to the built-in capabilities that Azure provides, you can use third-party [network virtual appliances](https://azure.microsoft.com/solutions/network-appliances/) to accommodate your specific network isolation requirements while at the same time applying existing in-house skills. Azure supports a wide range of appliances, including offerings from F5, Palo Alto Networks, Cisco, Check Point, Barracuda, Citrix, Fortinet, and many others. Network appliances support network functionality and services in the form of VMs in your virtual networks and deployments.

-> *Additional resources:*

-While Azure Storage supports a wide range of different externally facing customer storage scenarios, internally, the physical storage for the above services is managed by a common set of APIs. To provide durability and availability, Azure Storage relies on data replication and data partitioning across storage resources that are shared among tenants. To ensure cryptographic certainty of logical data isolation, Azure Storage relies on data encryption at rest using advanced algorithms with multiple ciphers as described in this section.

-Detailed information about various [data encryption models](../security/fundamentals/encryption-models.md) and specifics on key management for a wide range of Azure platform services is available in online documentation. Moreover, some Azure services provide other [encryption models](../security/fundamentals/encryption-overview.md#azure-encryption-models), including client-side encryption, to further encrypt their data using more granular controls. The rest of this section covers encryption implementation for key Azure storage scenarios such as Storage service encryption and Azure Disk encryption for IaaS Virtual Machines, including server-side encryption for managed disks.

-> *Additional resources:*

-Storage service encryption is enabled by default for all new and existing storage accounts and it [cannot be disabled](../storage/common/storage-service-encryption.md#about-azure-storage-encryption). As shown in Figure 17, the encryption process uses the following keys to help ensure cryptographic certainty of data isolation at rest:

-These three keys are combined to protect any data that is written to Azure Storage and provide cryptographic certainty for logical data isolation in Azure Storage. As mentioned previously, Azure Storage service encryption is enabled by default and it cannot be disabled.

-Azure Storage service encryption encrypts the page blobs that store Azure Virtual Machine disks. Additionally, you may optionally use [Azure Disk encryption](../security/fundamentals/azure-disk-encryption-vms-vmss.md) to encrypt Azure [Windows](../virtual-machines/windows/disk-encryption-overview.md) and [Linux](../virtual-machines/linux/disk-encryption-overview.md) IaaS Virtual Machine disks to increase storage isolation and assure cryptographic certainty of your data stored in Azure. This encryption includes [managed disks](../virtual-machines/managed-disks-overview.md), as described later in this section. Azure disk encryption uses the industry standard [BitLocker](/windows/security/information-protection/bitlocker/bitlocker-overview) feature of Windows and the [DM-Crypt](https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt) feature of Linux to provide OS-based volume encryption that is integrated with Azure Key Vault.

-For managed disks, Azure Disk encryption allows you to encrypt the OS and Data disks used by an IaaS virtual machine; however, Data cannot be encrypted without first encrypting the OS volume. The solution relies on Azure Key Vault to help you control and manage the disk encryption keys in key vaults. You can supply your own encryption keys, which are safeguarded in Azure Key Vault to support *bring your own key* (BYOK) scenarios, as described previously in *[Data encryption key management](#data-encryption-key-management)* section.

-Azure Disk encryption is not supported by Managed HSM or an on-premises key management service. Only key vaults managed by the Azure Key Vault service can be used to safeguard customer-managed encryption keys for Azure Disk encryption.

-You are [always in control of your customer data](https://www.microsoft.com/trust-center/privacy/data-management) in Azure. You can access, extract, and delete your customer data stored in Azure at will. When you terminate your Azure subscription, Microsoft takes the necessary steps to ensure that you continue to own your customer data. A common concern upon data deletion or subscription termination is whether another customer or Azure administrator can access your deleted data. The following sections explain how data deletion, retention, and destruction work in Azure.

-Storage is allocated sparsely, which means that when a virtual disk is created, disk space is not allocated for its entire capacity. Instead, a table is created that maps addresses on the virtual disk to areas on the physical disk and that table is initially empty. The first time you write data on the virtual disk, space on the physical disk is allocated and a pointer to it is placed in the table.

-In Azure Storage, all disk writes are sequential. This approach minimizes the number of disk &#8220;seeks&#8221; but requires updating the pointers to objects every time they are written - new versions of pointers are also written sequentially. A side effect of this design is that it is not possible to ensure that a secret on disk is gone by overwriting it with other data. The original data will remain on the disk and the new value will be written sequentially. Pointers will be updated such that there is no way to find the deleted value anymore. Once the disk is full, however, the system has to write new logs onto disk space that has been freed up by the deletion of old data. Instead of allocating log files directly from disk sectors, log files are created in a file system running NTFS. A background thread running on Azure Storage nodes frees up space by going through the oldest log file, copying blocks that are still referenced from that oldest log file to the current log file, and updating all pointers as it goes. It then deletes the oldest log file. Therefore, there are two categories of free disk space on the disk: (1) space that NTFS knows is free, where it allocates new log files from this pool; and (2) space within those log files that Azure Storage knows is free since there are no current pointers to it.

-The sectors on the physical disk associated with the deleted data become immediately available for reuse and are overwritten when the corresponding storage block is reused for storing other data. The time to overwrite varies depending on disk utilization and activity. This process is consistent with the operation of a log-structured file system where all writes are written sequentially to disk. This process is not deterministic and there is no guarantee when particular data will be gone from physical storage. **However, when exactly deleted data gets overwritten or the corresponding physical storage allocated to another customer is irrelevant for the key isolation assurance that no data can be recovered after deletion:**

-Customers are not provided with direct access to the underlying physical storage. Since customer software only addresses virtual disks, there is no way for another customer to express a request to read from or write to a physical address that is allocated to you or a physical address that is free.

-If your subscription expires or is terminated, Microsoft will preserve your customer data for a 90-day retention period to permit you to extract your data or renew your subscriptions. After this retention period, Microsoft will delete all your customer data within another 90 days, that is, your customer data will be permanently deleted 180 days after expiration or termination. Given the data retention procedure, you can control how long your data is stored by timing when you end the service with Microsoft. It is recommended that you do not terminate your service until you have extracted all data so that the initial 90-day retention period can act as a safety buffer should you later realize you missed something.

-If you deleted an entire storage account by mistake, you should contact [Azure Support](https://azure.microsoft.com/support/options/) promptly for assistance with recovery. You can [create and manage support requests](../azure-portal/supportability/how-to-create-azure-support-request.md) in the Azure portal. A storage account deleted within a subscription is retained for two weeks to allow for recovery from accidental deletion, after which it is permanently deleted. However, when a storage object (for example, blob, file, queue, table) is itself deleted, the delete operation is immediate and irreversible. Unless you made a backup, deleted storage objects can't be recovered. For Blob storage, you can implement extra protection against accidental or erroneous modifications or deletions by enabling [soft delete](../storage/blobs/soft-delete-blob-overview.md). When [soft delete is enabled](../storage/blobs/soft-delete-blob-enable.md) for a storage account, blobs, blob versions, and snapshots in that storage account may be recovered after they are deleted, within a retention period that you specified. To avoid retention of data after storage account or subscription deletion, you can delete storage objects individually before deleting the storage account or subscription.

-If a disk drive used for storage suffers a hardware failure, it is securely [erased or destroyed](https://www.microsoft.com/trustcenter/privacy/data-management) before decommissioning. The data on the drive is erased to ensure that the data cannot be recovered by any means. When such devices are decommissioned, Microsoft follows the [NIST SP 800-88 R1](https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final) disposal process with data classification aligned to FIPS 199 Moderate. Magnetic, electronic, or optical media are purged or destroyed in accordance with the requirements established in NIST SP 800-88 R1 where the terms are defined as follows:

-If you are accustomed to traditional on-premises data center deployment, you would typically conduct a risk assessment to gauge your threat exposure and formulate mitigating measures when migrating to the cloud. In many of these instances, security considerations for traditional on-premises deployment tend to be well understood whereas the corresponding cloud options tend to be new. The next section is intended to help you with this comparison.

-A multi-tenant cloud platform implies that multiple customer applications and data are stored on the same physical hardware. Azure uses [logical isolation](../security/fundamentals/isolation-choices.md) to segregate your applications and data from other customers. This approach provides the scale and economic benefits of multi-tenant cloud services while rigorously helping enforce controls designed to keep other customers from accessing your data or applications. If you are migrating from traditional on-premises physically isolated infrastructure to the cloud, this section addresses concerns that may be of interest to you.

-|**Firewalls, networking**|- Physical network enforcement (switches, etc.) </br>- Physical host-based firewall can be manipulated by compromised application </br>- 2 layers of enforcement|- Physical network enforcement (switches, etc.) </br>- Hyper-V host virtual network switch enforcement cannot be changed from inside VM </br>- VM host-based firewall can be manipulated by compromised application </br>- 3 layers of enforcement|

-|**Security analytics**|- Security analytics dependent on host-based security solutions, which assume host/security software has not been compromised|- Outside VM (hypervisor based) forensics/snapshot capability allows assessment of potentially compromised workloads|

-|**Security policy**|- Security policy verification (patch scanning, vulnerability scanning, etc.) subject to tampering by compromised host </br>- Inconsistent security policy applied across customer entities|- Outside VM verification of security policies </br>- Possible to enforce uniform security policies across customer entities|

-Compared to traditional on-premises hosted systems, Azure provides a greatly **reduced attack surface** by using a locked-down Windows Server core for the Host OS layered over the Hypervisor. Moreover, by default, guest PaaS VMs do not have any user accounts to accept incoming remote connections and the default Windows administrator account is disabled. Your software in PaaS VMs is restricted by default to running under a low-privilege account, which helps protect your service from attacks by its own end users. You can modify these permissions, and you can also choose to configure your VMs to allow remote administrative access.

-PaaS VMs offer more advanced **protection against persistent malware** infections than traditional physical server solutions, which if compromised by an attacker can be difficult to clean, even after the vulnerability is corrected. The attacker may have left behind modifications to the system that allow re-entry, and it is a challenge to find all such changes. In the extreme case, the system must be reimaged from scratch with all software reinstalled, sometimes resulting in the loss of application data. With PaaS VMs, reimaging is a routine part of operations, and it can help clean out intrusions that have not even been detected. This approach makes it more difficult for a compromise to persist.

-When VMs belonging to different customers are running on the same physical server, it is the HypervisorΓÇÖs job to ensure that they cannot learn anything important about what the other customerΓÇÖs VMs are doing. Azure helps block unauthorized direct communication by design; however, there are subtle effects where one customer might be able to characterize the work being done by another customer. The most important of these effects are timing effects when different VMs are competing for the same resources. By carefully comparing operations counts on CPUs with elapsed time, a VM can learn something about what other VMs on the same server are doing. Known as **side-channel attacks**, these exploits have received plenty of attention in the academic press where researchers have been seeking to learn much more specific information about what is going on in a peer VM. Of particular interest are efforts to learn the cryptographic keys of a peer VM by measuring the timing of certain memory accesses and inferring which cache lines the victimΓÇÖs VM is reading and updating. Under controlled conditions with VMs using hyper-threading, successful attacks have been demonstrated against commercially available implementations of cryptographic algorithms. There are several mitigations in Azure that reduce the risk of such an attack:

-You can also leverage your own custom metrics that your application(s) may be emitting. If you have configured your application(s) to send metrics to Application Insights you can leverage those metrics to make decisions on whether to scale or not.

-* Terraform

-Currently, VM insights does not support multi-homing.

- $SubId = (Get-AzureRmContext).Subscription.Id

-[See the Azure NetApp Files REST API reference](/rest/api/netapp/)

-1. In your Device Update for IoT Hub resource, click **Access control (IAM)**.

-1. Click **+Add** and then select **Add role assignment**.

-1. For **Role**, select **Device Update Administrator**. For **Assign access to** select **User, group, or service principle**. For **Select**, select your account or the account of the person who will be deploying updates. Click **Save**.

-Each read-only replica of a database has its own resources, such as vCores, memory, data IOPS, TempDB, workers, and sessions. Each read-only replica is subject to the resource limits detailed later in this article.

-|TempDB max data size (GB)|32|64|128|192|256|

-|TempDB max data size (GB)|320|384|448|512|

-|TempDB max data size (GB)|576|640|768|1024|1280|

-|[RBPEX](service-tier-hyperscale.md#compute) Size|3X Memory|3X Memory|3X Memory|3X Memory|3X Memory|3X Memory|

-|TempDB max data size (GB)|32|64|96|128|160|192|

-¹ Besides local SSD IO, workloads will use remote [page server](service-tier-hyperscale.md#page-server) IO. Effective IOPS will depend on workload. For details, see [Data IO Governance](resource-limits-logical-server.md#resource-governance), and [Data IO in resource utilization statistics](hyperscale-performance-diagnostics.md#data-io-in-resource-utilization-statistics).

-|[RBPEX](service-tier-hyperscale.md#compute) Size|3X Memory|3X Memory|3X Memory|3X Memory|3X Memory|3X Memory|

-|TempDB max data size (GB)|224|256|288|320|512|768|

-¹ Besides local SSD IO, workloads will use remote [page server](service-tier-hyperscale.md#page-server) IO. Effective IOPS will depend on workload. For details, see [Data IO Governance](resource-limits-logical-server.md#resource-governance), and [Data IO in resource utilization statistics](hyperscale-performance-diagnostics.md#data-io-in-resource-utilization-statistics).

-|[RBPEX](service-tier-hyperscale.md#compute) Size|3X Memory|3X Memory|3X Memory|3X Memory|3X Memory|3X Memory|3X Memory|

-|TempDB max data size (GB)|64|128|192|256|320|384|448|

-¹ Besides local SSD IO, workloads will use remote [page server](service-tier-hyperscale.md#page-server) IO. Effective IOPS will depend on workload. For details, see [Data IO Governance](resource-limits-logical-server.md#resource-governance), and [Data IO in resource utilization statistics](hyperscale-performance-diagnostics.md#data-io-in-resource-utilization-statistics).

-|[RBPEX](service-tier-hyperscale.md#compute) Size|3X Memory|3X Memory|3X Memory|3X Memory|3X Memory|3X Memory|3X Memory|

-|TempDB max data size (GB)|512|576|640|768|1024|1280|2560|

-¹ Besides local SSD IO, workloads will use remote [page server](service-tier-hyperscale.md#page-server) IO. Effective IOPS will depend on workload. For details, see [Data IO Governance](resource-limits-logical-server.md#resource-governance), and [Data IO in resource utilization statistics](hyperscale-performance-diagnostics.md#data-io-in-resource-utilization-statistics).

-|[RBPEX](service-tier-hyperscale.md#compute) Size|3X Memory|3X Memory|3X Memory|3X Memory|

-|TempDB max data size (GB)|64|128|192|256|

-¹ Besides local SSD IO, workloads will use remote [page server](service-tier-hyperscale.md#page-server) IO. Effective IOPS will depend on workload. For details, see [Data IO Governance](resource-limits-logical-server.md#resource-governance), and [Data IO in resource utilization statistics](hyperscale-performance-diagnostics.md#data-io-in-resource-utilization-statistics).

-|TempDB max data size (GB)|32|64|96|128|160|192|

-|TempDB max data size (GB)|224|256|288|320|512|768|

-|TempDB max data size (GB)|64|128|192|256|320|384|384|

-|TempDB max data size (GB)|512|576|640|768|1024|1280|2560|

-|TempDB max data size (GB)|37|46|56|65|74|

-|TempDB max data size (GB)|83|93|111|148|167|333|

-|TempDB max data size (GB)|64|128|192|256|

-|TempDB max data size (GB)|32|64|96|128|160|192|

-|TempDB max data size (GB)|224|256|288|320|512|768|

-|TempDB max data size (GB)|64|128|192|256|320|384|448|

-|TempDB max data size (GB)|512|576|640|768|1024|1280|2560|

-|TempDB max data size (GB)|256|320|384|448|512|576|

-|TempDB max data size (GB)|640|768|1024|2048|4096|

-|TempDB max data size (GB)|64|128|192|256|

-> - Databases in the Hyperscale service tier cannot currently be changed to a different service tier.

-Azure SQL Database is based on SQL Server Database Engine architecture that is adjusted for the cloud environment in order to ensure 99.99% availability even in the cases of infrastructure failures. There are three architectural models that are used in Azure SQL Database:

-The vCore-based service tiers are differentiated based on database availability and storage type, performance, and maximum storage size, as described in the following table:

-|| **General Purpose** | **Hyperscale** | **Business Critical** |

-| **Best for** | Offers budget oriented balanced compute and storage options.|Most business workloads. Autoscaling storage size up to 100 TB,fast vertical and horizontal compute scaling, fast database restore.| OLTP applications with high transaction rate and low IO latency. Offers highest resilience to failures and fast failovers using multiple synchronously updated replicas.|

-| **Compute size** | 1 to 80 vCores | 1 to 80 vCores¹ | 1 to 80 vCores |

-| **Storage type** | Premium remote storage (per instance) | De-coupled storage with local SSD cache (per instance) | Super-fast local SSD storage (per instance)|

-| **Storage size**¹ | 5 GB ΓÇô 4 TB | Up to 100 TB | 5 GB ΓÇô 4 TB |

-| **IOPS** | 500 IOPS per vCore with 7000 maximum IOPS | Hyperscale is a multi-tiered architecture with caching at multiple levels. Effective IOPS will depend on the workload. | 5000 IOPS with 200,000 maximum IOPS |

-| **Availability** | 1 replica, no Read Scale-out, zone-redundant HA (preview), no local cache | Multiple replicas, up to 4 Read Scale-out, zone-redundant HA (preview), partial local cache | 3 replicas, 1 Read Scale-out, zone-redundant HA, full local storage |

-| **Backups** | A choice of geo-redundant, zone-redundant, or locally-redundant backup storage, 1-35 day retention (default 7 days) | A choice of geo-redundant, zone-redundant, or locally-redundant backup storage, 7 day retention. | A choice of geo-redundant,zone-redundant, or locally-redundant backup storage, 1-35 day retention (default 7 days) |

-Unlike traditional database engines that have centralized all of the data management functions in one location/process (even so called distributed databases in production today have multiple copies of a monolithic data engine), a Hyperscale database separates the query processing engine, where the semantics of various data engines diverge, from the components that provide long-term storage and durability for the data. In this way, the storage capacity can be smoothly scaled out as far as needed (initial target is 100 TB). High-availability and named replicas share the same storage components so no data copy is required to spin up a new replica.

-A Hyperscale database contains the following different types of components:

-### Compute

-The compute node is where the relational engine lives. This is where language, query, and transaction processing occur. All user interactions with a Hyperscale database happen through these compute nodes. Compute nodes have SSD-based caches (labeled RBPEX - Resilient Buffer Pool Extension in the preceding diagram) to minimize the number of network round trips required to fetch a page of data. There is one primary compute node where all the read-write workloads and transactions are processed. There are one or more secondary compute nodes that act as hot standby nodes for failover purposes, as well as act as read-only compute nodes for offloading read workloads (if this functionality is desired).

-The database engine running on Hyperscale compute nodes is the same as in other Azure SQL Database service tiers. When users interact with the database engine on Hyperscale compute nodes, the supported surface area and engine behavior are the same as in other service tiers, with the exception of [known limitations](#known-limitations).

-### Page server

-Page servers are systems representing a scaled-out storage engine. Each page server is responsible for a subset of the pages in the database. Nominally, each page server controls either up to 128 GB or up to 1 TB of data. No data is shared on more than one page server (outside of page server replicas that are kept for redundancy and availability). The job of a page server is to serve database pages out to the compute nodes on demand, and to keep the pages updated as transactions update data. Page servers are kept up to date by playing transaction log records from the log service. Page servers also maintain covering SSD-based caches to enhance performance. Long-term storage of data pages is kept in Azure Storage for additional reliability.

-### Log service

-The log service accepts transaction log records from the primary compute replica, persists them in a durable cache, and forwards the log records to the rest of compute replicas (so they can update their caches) as well as the relevant page server(s), so that the data can be updated there. In this way, all data changes from the primary compute replica are propagated through the log service to all the secondary compute replicas and page servers. Finally, transaction log records are pushed out to long-term storage in Azure Storage, which is a virtually infinite storage repository. This mechanism removes the need for frequent log truncation. The log service also has local memory and SSD caches to speed up access to log records. The log on hyperscale is practically infinite, with the restriction that a single transaction cannot generate more than 1 TB of log. Additionally, if using [Change Data Capture](/sql/relational-databases/track-changes/about-change-data-capture-sql-server), at most 1 TB of log can be generated since the start of the oldest active transaction. It is recommended to avoid unnecessarily large transactions to stay below this limit.

-### Azure storage

-Azure Storage contains all data files in a database. Page servers keep data files in Azure Storage up to date. This storage is used for backup purposes, as well as for replication between Azure regions. Backups are implemented using storage snapshots of data files. Restore operations using snapshots are fast regardless of data size. A database can be restored to any point in time within its backup retention period.

-## Create a Hyperscale database

-A Hyperscale database can be created using the [Azure portal](https://portal.azure.com), [T-SQL](/sql/t-sql/statements/create-database-transact-sql), [PowerShell](/powershell/module/azurerm.sql/new-azurermsqldatabase), or [CLI](/cli/azure/sql/db#az-sql-db-create). Hyperscale databases are available only using the [vCore-based purchasing model](service-tiers-vcore.md).

-The following T-SQL command creates a Hyperscale database. You must specify both the edition and service objective in the `CREATE DATABASE` statement. Refer to the [resource limits](./resource-limits-vcore-single-databases.md#hyperscaleprovisioned-computegen4) for a list of valid service objectives.

-```sql

-CREATE DATABASE [HyperscaleDB1] (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');

-GO

-```

-This will create a Hyperscale database on Gen5 hardware with four cores.

-## Upgrade existing database to Hyperscale

-You can move your existing databases in Azure SQL Database to Hyperscale using the [Azure portal](https://portal.azure.com), [T-SQL](/sql/t-sql/statements/alter-database-transact-sql), [PowerShell](/powershell/module/azurerm.sql/set-azurermsqldatabase), or [CLI](/cli/azure/sql/db#az-sql-db-update). At this time, this is a one-way migration. You can't move databases from Hyperscale to another service tier, other than by exporting and importing data. For proofs of concept (POCs), we recommend making a copy of your production databases, and migrating the copy to Hyperscale. Migrating an existing database in Azure SQL Database to the Hyperscale tier is a size of data operation.

-The following T-SQL command moves a database into the Hyperscale service tier. You must specify both the edition and service objective in the `ALTER DATABASE` statement.

-```sql

-ALTER DATABASE [DB2] MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');

-GO

-```

-> [!NOTE]

-> To move a database that is a part of a [geo-replication](active-geo-replication-overview.md) relationship, either as the primary or as a secondary, to Hyperscale, you have to stop replication. Databases in a [failover group](auto-failover-group-overview.md) must be removed from the group first.

->

-> Once a database has been moved to Hyperscale, you can create a new Hyperscale geo-replica for that database. Geo-replication for Hyperscale is in preview with certain [limitations](active-geo-replication-overview.md).

-The Azure SQL Database Hyperscale tier is enabled in the vast majority of Azure regions. If you want to create a Hyperscale database in a region where Hyperscale is not enabled by default, you can send an onboarding request via Azure portal. For instructions, see [Request quota increases for Azure SQL Database](quota-increase-request.md) for instructions. When submitting your request, use the following guidelines:

-These are the current limitations to the Hyperscale service tier as of GA. We're actively working to remove as many of these limitations as possible.

-| Migration to Hyperscale is currently a one-way operation | Once a database is migrated to Hyperscale, it can't be migrated directly to a non-Hyperscale service tier. At present, the only way to migrate a database from Hyperscale to non-Hyperscale is to export/import using a bacpac file or other data movement technologies (Bulk Copy, Azure Data Factory, Azure Databricks, SSIS, etc.) Bacpac export/import from Azure portal, from PowerShell using [New-AzSqlDatabaseExport](/powershell/module/az.sql/new-azsqldatabaseexport) or [New-AzSqlDatabaseImport](/powershell/module/az.sql/new-azsqldatabaseimport), from Azure CLI using [az sql db export](/cli/azure/sql/db#az-sql-db-export) and [az sql db import](/cli/azure/sql/db#az-sql-db-import), and from [REST API](/rest/api/sql/) is not supported. Bacpac import/export for smaller Hyperscale databases (up to 200 GB) is supported using SSMS and [SqlPackage](/sql/tools/sqlpackage) version 18.4 and later. For larger databases, bacpac export/import may take a long time, and may fail for various reasons.|

-| Elastic Jobs | Using a Hyperscale database as the Job database is not supported. However, elastic jobs can target Hyperscale databases in the same way as any other Azure SQL database. |

-You can create a resource group, server, and single database using Windows PowerShell.

- --resrouce-group myResourceGroup

-| Australia Central | Yes | |

-| North Central US | Yes | |

-| West US | Yes | Yes |

- This step also includes creation of a [performance baseline](sql-server-to-managed-instance-performance-baseline.md#create-a-baseline) to determine resource usage on your source SQL Server instance. This step is needed if you want to deploy a properly sized managed instance and verify that performance after migration is not affected.

-Determine whether SQL Managed Instance is compatible with the database requirements of

-your application. SQL Managed Instance is designed to provide easy lift and shift migration for

-the majority of existing applications that use SQL Server. However, you may sometimes require

-features or capabilities that are not yet supported and the cost of implementing a workaround is

-too high.

-You can use the Data Migration Assistant (version 4.1 and later) to assess databases to get:

- - The **compatibility issues** category identifies partially supported or unsupported feature compatibility issues that might block migration as well as recommendations to address them (`CONNECT SQL`, `VIEW SERVER STATE`, and `VIEW ANY DEFINITION` permissions required).

-If SQL Managed Instance is not a suitable target for your workload, SQL Server on Azure VMs might be a viable alternative target for your business.

-#### Scaled Assessments and Analysis

-Data Migration Assistant supports performing scaled assessments and consolidation of the assessment reports for analysis. If you have multiple servers and databases that need to be assessed and analyzed at scale to provide a wider view of the data estate, click on the following links to learn more.

-Based on the information in the discover and assess phase, create an appropriately-sized target SQL Managed Instance. You can do so by using the [Azure portal](../../managed-instance/instance-create-quickstart.md), [PowerShell](../../managed-instance/scripts/create-configure-managed-instance-powershell.md), or an [Azure Resource Manager (ARM) Template](../../managed-instance/create-template-quickstart.md).

-SQL Managed Instance is tailored for on-premises workloads that are planning to move to the cloud. It introduces a [purchasing model](../../database/service-tiers-vcore.md) that provides greater flexibility in selecting the right level of resources for your workloads. In the on-premises world, you are probably accustomed to sizing these workloads by using physical cores and IO bandwidth. The purchasing model for managed instance is based upon virtual cores, or "vCores," with additional storage and IO available separately. The vCore model is a simpler way to understand your compute requirements in the cloud versus what you use on-premises today. This purchasing model enables you to right-size your destination environment in the cloud. Some general guidelines that might help you to choose the right service tier and characteristics are described here:

-After you have completed tasks associated with the Pre-migration stage, you are ready to perform the schema and data migration.

-SQL Managed Instance targets user scenarios requiring mass database migration from on-premises or

-Azure VM database implementations. They are the optimal choice when you need to lift and shift

-the back end of the applications that regularly use instance level and/or cross-database

-functionalities. If this is your scenario, you can move an entire instance to a corresponding

-environment in Azure without the need to re-architect your applications.

-credentials, SQL Agent jobs and operators, and server-level triggers.

-SQL Managed Instance is a managed service that allows you to delegate some of the regular DBA

-activities to the platform as they are built in. Therefore, some instance-level data does not

-need to be migrated, such as maintenance jobs for regular backups or Always On configuration, as

-[high availability](../../database/high-availability-sla.md) is built in.

-downtime.

-### Database Migration Service

-To perform migrations using DMS, follow the steps below:

-1. [Register the **Microsoft.DataMigration** resource provider](../../../dms/quickstart-create-data-migration-service-portal.md#register-the-resource-provider) in your subscription if you are performing this for the first time.

-1. Create an Azure Database Migration Service Instance in a desired location of your choice (preferably in the same region as your target Azure SQL Managed Instance) and select an existing virtual network or create a new one to host your DMS instance.

-1. After creating your DMS instance, create a new migration project and specify the source server type as **SQL Server** and the target server type as **Azure SQL Database Managed Instance**. Choose the type of activity in the project creation blade - online or offline data migration.

-1. Specify the source SQL Server details on the **Migration source** details page and the target Azure SQL Managed Instance details on the **Migration target** details page. Select **Next**.

-1. Choose the database you want to migrate.

-1. Provide configuration settings to specify the **SMB Network Share** that contains your database backup files. Use Windows User credentials with DMS that can access the network share. Provide your **Azure Storage account details**.

-1. Review the migration summary, and choose **Run migration**. You can then monitor the migration activity and check the progress of your database migration.

-1. After database is restored, choose **Start cutover**. The migration process copies the tail-log backup once you make it available in the SMB network share and restore it on the target.

-1. Stop all incoming traffic to your source database and update the connection string to the new Azure SQL Managed Instance database.

-For a detailed step-by-step tutorial of this migration option, see [Migrate SQL Server to an Azure SQL Managed Instance online using DMS](../../../dms/tutorial-sql-server-managed-instance-online.md).

-### Backup and restore

-One of the key capabilities of Azure SQL Managed Instance to enable quick and easy database migration is the native restore of database backup (`.bak`) files stored on on [Azure Storage](https://azure.microsoft.com/services/storage/). Backup and restore is an asynchronous operation based on the size of your database.

-

-source SQL Server version you are running:

-> - When you're migrating a database protected by [Transparent Data Encryption](../../database/transparent-data-encryption-tde-overview.md) to a managed instance using native restore option,

-the corresponding certificate from the on-premises or Azure VM SQL Server needs to be migrated

-before database restore. For detailed steps, see [Migrate a TDE cert to a managed instance](../../managed-instance/tde-certificate-migrate.md).

-> - Restore of system databases is not supported. To migrate instance-level objects (stored in

-master or msdb databases), we recommend to script them out and run T-SQL scripts on the

-destination instance.

-> A database restore operation is asynchronous and retryable. You might get an error in SQL Server Management Studio if the connection breaks or a time-out expires. Azure SQL Database will keep trying to restore database in the background, and you can track the progress of the restore using the [sys.dm_exec_requests](/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-requests-transact-sql) and [sys.dm_operation_status](/sql/relational-databases/system-dynamic-management-views/sys-dm-operation-status-azure-sql-database) views.

-After you verify that data is the same on both source and target, you can cutover from the source to the target environment. It is important to plan the cutover process with business / application teams to ensure minimal interruption during cutover does not affect business continuity.

-After you have successfully completed the migration stage, go through a series of post-migration tasks to ensure that everything is functioning smoothly and efficiently.

-The post-migration phase is crucial for reconciling any data accuracy issues and verifying completeness, as well as addressing performance issues with the workload.

-Once you have completed the migration to a managed instance, you should track the application behavior and performance of your workload. This process includes the following activities:

-1. **Develop validation tests**: To test database migration, you need to use SQL queries. You must create the validation queries to run against both the source and the target databases. Your validation queries should cover the scope you have defined.

-## Leverage advanced features

-Be sure to take advantage of the advanced cloud-based features offered by SQL Managed Instance, such as [built-in high availability](../../database/high-availability-sla.md), [threat detection](../../database/azure-defender-for-sql.md), and [monitoring and tuning your workload](../../database/monitor-tune-overview.md).

-> Azure SQL Managed Instance guarantees 99.99 percent availability, even in critical scenarios. Overhead caused by some features in SQL Managed Instance can't be disabled. For more information, see the [Key causes of performance differences between SQL Managed Instance and SQL Server](https://azure.microsoft.com/blog/key-causes-of-performance-differences-between-sql-managed-instance-and-sql-server/) blog entry.

-|[Bulk copy](/sql/relational-databases/import-export/import-and-export-bulk-data-by-using-the-bcp-utility-sql-server)| The [bulk copy program (bcp) tool](/sql/tools/bcp-utility) copies data from an instance of SQL Server into a data file. Use the tool to export the data from your source and import the data file into the target SQL managed instance. </br></br> For high-speed bulk copy operations to move data to Azure SQL Managed Instance, you can use the [Smart Bulk Copy tool](/samples/azure-samples/smartbulkcopy/smart-bulk-copy/) to maximize transfer speed by taking advantage of parallel copy tasks. |

-|[Azure Data Factory](../../../data-factory/connector-azure-sql-managed-instance.md)| The [Copy activity](../../../data-factory/copy-activity-overview.md) in Azure Data Factory migrates data from source SQL Server databases to SQL Managed Instance by using built-in connectors and an [integration runtime](../../../data-factory/concepts-integration-runtime.md).</br> </br> Data Factory supports a wide range of [connectors](../../../data-factory/connector-overview.md) to move data from SQL Server sources to SQL Managed Instance. |

-|[Azure SQL Migration extension for Azure Data Studio](../../../dms/migration-using-azure-data-studio.md) | - Migrate single databases or multiple databases at scale. </br> - Can run in both online (minimal downtime) and offline (acceptable downtime) modes. </br> </br> Supported sources: </br> - SQL Server (2005 to 2019) on-premises or Azure VM </br> - AWS EC2 </br> - AWS RDS </br> - GCP Compute SQL Server VM | - Easy to setup and get started. </br> - Requires setup of self-hosted integration runtime to access on-premises SQL Server and backups. </br> - Includes both assessment and migration capabilities. |

-|[Azure Database Migration Service](../../../dms/tutorial-sql-server-to-managed-instance.md) | - Migrate single databases or multiple databases at scale. </br> - Can accommodate downtime during the migration process. </br> </br> Supported sources: </br> - SQL Server (2005 to 2019) on-premises or Azure VM </br> - AWS EC2 </br> - AWS RDS </br> - GCP Compute SQL Server VM | - Migrations at scale can be automated via [PowerShell](../../../dms/howto-sql-server-to-azure-sql-managed-instance-powershell-offline.md). </br> - Time to complete migration depends on database size and is affected by backup and restore time. </br> - Sufficient downtime might be required. |

-|[Native backup and restore](../../managed-instance/restore-sample-database-quickstart.md) | - Migrate individual line-of-business application databases. </br> - Quick and easy migration without a separate migration service or tool. </br> </br> Supported sources: </br> - SQL Server (2005 to 2019) on-premises or Azure VM </br> - AWS EC2 </br> - AWS RDS </br> - GCP Compute SQL Server VM | - Database backup uses multiple threads to optimize data transfer to Azure Blob Storage, but partner bandwidth and database size can affect transfer rate. </br> - Downtime should accommodate the time required to perform a full backup and restore (which is a size of data operation).|

-|[Log Replay Service](../../managed-instance/log-replay-service-migrate.md) | - Migrate individual line-of-business application databases. </br> - More control is needed for database migrations. </br> </br> Supported sources: </br> - SQL Server (2008 to 2019) on-premises or Azure VM </br> - AWS EC2 </br> - AWS RDS </br> - GCP Compute SQL Server VM | - The migration entails making full database backups on SQL Server and copying backup files to Azure Blob Storage. Log Replay Service is used to restore backup files from Azure Blob Storage to SQL Managed Instance. </br> - Databases being restored during the migration process will be in a restoring mode and can't be used for read or write workloads until the process is complete.|

-|[Managed Instance link](../../managed-instance/managed-instance-link-feature-overview.md) | - Migrate individual line-of-business application databases. </br> - More control is needed for database migrations. </br> - Minimum downtime migration is needed. </br> </br> Supported sources: </br> - SQL Server (2016 to 2019) on-premises or Azure VM </br> - AWS EC2 </br> - GCP Compute SQL Server VM | - The migration entails establishing a network connection between SQL Server and SQL Managed Instance, and opening communication ports. </br> - Uses [Always On availability group](/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server) technology to replicate database near real-time, making an exact replica of the SQL Server database on SQL Managed Instance. </br> - The database can be used for read-only access on SQL Managed Instance while migration is in progress. </br> - Provides the best performance during migration with minimum downtime. |

-|[Transactional replication](../../managed-instance/replication-transactional-overview.md) | - Migrate by continuously publishing changes from source database tables to target SQL Managed Instance database tables. </br> - Do full or partial database migrations of selected tables (subset of a database). </br> </br> Supported sources: </br> - SQL Server (2012 to 2019) with some limitations </br> - AWS EC2 </br> - GCP Compute SQL Server VM | </br> - Setup is relatively complex compared to other migration options. </br> - Provides a continuous replication option to migrate data (without taking the databases offline).</br> - Transactional replication has limitations to consider when you're setting up the publisher on the source SQL Server instance. See [Limitations on publishing objects](/sql/relational-databases/replication/publish/publish-data-and-database-objects#limitations-on-publishing-objects) to learn more. </br> - Capability to [monitor replication activity](/sql/relational-databases/replication/monitor/monitoring-replication) is available. |

-|[Bulk copy](/sql/relational-databases/import-export/import-and-export-bulk-data-by-using-the-bcp-utility-sql-server)| - Do full or partial data migrations. </br> - Can accommodate downtime. </br> </br> Supported sources: </br> - SQL Server (2005 to 2019) on-premises or Azure VM </br> - AWS EC2 </br> - AWS RDS </br> - GCP Compute SQL Server VM | - Requires downtime for exporting data from the source and importing into the target. </br> - The file formats and data types used in the export or import need to be consistent with table schemas. |

-|[Import Export Wizard/BACPAC](../../database/database-import.md)| - Migrate individual line-of-business application databases. </br>- Suited for smaller databases. </br> Does not require a separate migration service or tool. </br> </br> Supported sources: </br> - SQL Server (2005 to 2019) on-premises or Azure VM </br> - AWS EC2 </br> - AWS RDS </br> - GCP Compute SQL Server VM | </br> - Requires downtime because data needs to be exported at the source and imported at the destination. </br> - The file formats and data types used in the export or import need to be consistent with table schemas to avoid truncation or data-type mismatch errors. </br> - Time taken to export a database with a large number of objects can be significantly higher. |

-|[Azure Data Factory](../../../data-factory/connector-azure-sql-managed-instance.md)| - Migrate and/or transform data from source SQL Server databases.</br> - Merging data from multiple sources of data to Azure SQL Managed Instance is typically for business intelligence (BI) workloads. </br> - Requires creating data movement pipelines in Data Factory to move data from source to destination. </br> - [Cost](https://azure.microsoft.com/pricing/details/data-factory/data-pipeline/) is an important consideration and is based on factors like pipeline triggers, activity runs, and duration of data movement. |

-After you restart the service, Windows user or group logins appear in the list of logins available for migration. For any Windows user or group logins that you migrate, you're prompted to provide the associated domain name. Service user accounts (accounts with the domain name NT AUTHORITY) and virtual user accounts (accounts with the domain name NT SERVICE) are not supported. To learn more, see [How to migrate Windows users and groups in a SQL Server instance to Azure SQL Managed Instance using T-SQL](../../managed-instance/migrate-sql-server-users-to-instance-transact-sql-tsql-tutorial.md).

-The PowerShell utility automatically maps Windows Server Active Directory accounts to Azure AD accounts, and it can do a UPN lookup for each login against the source Active Directory instance. The utility scripts custom server and database roles, along with role membership and user permissions. Contained databases are not yet supported, and only a subset of possible SQL Server permissions are scripted.

-Restore of system databases is not supported. To migrate instance-level objects (stored in the master and msdb databases), script them by using T-SQL and then re-create them on the target managed instance.

-In this guide, you learn how to *discover*, *assess*, and *migrate* your user databases from SQL Server to an instance of SQL Server on Azure Virtual Machines by using backup and restore and log shipping that uses [Data Migration Assistant](/sql/dma/dma-overview) for assessment.

-After you've discovered all the data sources, use [Data Migration Assistant](/sql/dma/dma-overview) to assess on-premises SQL Server instances migrating to an instance of SQL Server on Azure Virtual Machines to understand the gaps between the source and target instances.

-> [!NOTE]

-> If you're _not_ upgrading the version of SQL Server, skip this step and move to the [Migrate](#migrate) section.

-Data Migration Assistant assists your migration to a modern data platform by detecting compatibility issues that can affect database functionality in your new version of SQL Server. Data Migration Assistant recommends performance and reliability improvements for your target environment and also allows you to move your schema, data, and login objects from your source server to your target server.

-To learn more, see [Assessment](/sql/dma/dma-migrateonpremsql).

->Based on the type of assessment, the permissions required on the source SQL Server can be different:

- > - For the *feature parity* advisor, the credentials provided to connect to the source SQL Server database must be a member of the *sysadmin* server role.

- > - For the *compatibility issues* advisor, the credentials provided must have at least `CONNECT SQL`, `VIEW SERVER STATE`, and `VIEW ANY DEFINITION` permissions.

- > - Data Migration Assistant will highlight the permissions required for the chosen advisor before running the assessment.

-If you have multiple servers that require a Data Migration Assistant assessment, you can automate the process by using the [command-line interface](/sql/dma/dma-commandline). Using the interface, you can prepare assessment commands in advance for each SQL Server instance in the scope for migration.

-For summary reporting across large estates, Data Migration Assistant assessments can now be [consolidated into Azure Migrate](/sql/dma/dma-assess-sql-data-estate-to-sqldb).

-#### Refactor databases with Data Migration Assistant

-Based on the Data Migration Assistant assessment results, you might have a series of recommendations to ensure your user databases perform and function correctly after migration. Data Migration Assistant provides details on the impacted objects and resources for how to resolve each issue. Make sure to resolve all breaking changes and behavior changes before you start production migration.

-You need to script all Data Migration Assistant fixes and apply them to the target SQL Server database during the [post-migration](#post-migration) phase.

-### Log shipping (minimize downtime)

-To perform a minimal downtime migration by using backup and restore and log shipping:

-1. Set up connectivity to the SQL Server on Azure Virtual Machines based on your requirements. For more information, see [Connect to a SQL Server virtual machine on Azure (Resource Manager)](../../virtual-machines/windows/ways-to-connect-to-sql.md).

-1. Ensure on-premises user databases to be migrated are in full or bulk-logged recovery model.

-1. Perform a full database backup to an on-premises location, and modify any existing full database backups jobs to use the [COPY_ONLY](/sql/relational-databases/backup-restore/copy-only-backups-sql-server) keyword to preserve the log chain.

-1. Copy your on-premises backup files to your VM by using a remote desktop, [Azure Data Explorer](/azure/data-explorer/data-explorer-overview), or the [AzCopy command-line utility](../../../storage/common/storage-use-azcopy-v10.md). (Greater than 1-TB backups are recommended.)

-1. Restore full database backups on SQL Server on Azure Virtual Machines.

-1. Set up [log shipping](/sql/database-engine/log-shipping/configure-log-shipping-sql-server) between the on-premises database and SQL Server on Azure Virtual Machines. Be sure not to reinitialize the databases because this task was already completed in the previous steps.

-1. Cut over to the target server.

- 1. Pause or stop applications by using databases to be migrated.

- 1. Ensure user databases are inactive by using [single user mode](/sql/relational-databases/databases/set-a-database-to-single-user-mode).

- 1. When you're ready, perform a log shipping [controlled failover](/sql/database-engine/log-shipping/fail-over-to-a-log-shipping-secondary-sql-server) of on-premises databases to SQL Server on Azure Virtual Machines.

-When determining the correct size of VM and Storage for your SQL Server workload, refer to the [Performance Guidelines for SQL Server on Azure Virtual Machines.](../../virtual-machines/windows/performance-guidelines-best-practices-checklist.md#vm-size). To determine the VM size and storage requirements for your workload. it is recommended that these are sized through a Performance-Based [Azure Migrate Assessment](../../../migrate/concepts-assessment-calculation.md#types-of-assessments). If this is not an available option, see the following article on creating your own [baseline for performance](https://azure.microsoft.com/services/virtual-machines/sql-server/).

-|**Migrate** | Use a migrate strategy when you want to upgrade the target SQL Server and/or operating system version. <br /> <br /> Select an Azure VM from Azure Marketplace or a prepared SQL Server image that matches the source SQL Server version. <br/> <br/> Use the [Azure SQL Migration extension for Azure Data Studio](../../../dms/migration-using-azure-data-studio.md) to migrate SQL Server database(s) to SQL Server on Azure virtual machines with minimal downtime. | Use when there is a requirement or desire to use features available in newer versions of SQL Server, or if there is a requirement to upgrade legacy SQL Server and/or OS versions that are no longer in support. <br /> <br /> May require some application or user database changes to support the SQL Server upgrade. <br /><br />There may be additional considerations for migrating [Business Intelligence](#business-intelligence) services if in the scope of migration. |

-| **[Azure SQL Migration extension for Azure Data Studio](../../../dms/migration-using-azure-data-studio.md)** | SQL Server 2005 | SQL Server 2008 | [Azure VM storage limit](../../../index.yml) | This is an easy to use wizard based extension in Azure Data Studio for migrating SQL Server database(s) to SQL Server on Azure virtual machines. Use compression to minimize backup size for transfer. <br /><br /> The Azure SQL Migration extension for Azure Data Studio provides both assessment and migration capabilities in a simple user interface. |

-In this article, you'll establish a VPN (IPsec IKEv1 and IKEv2) site-to-site tunnel terminating in the Microsoft Azure Virtual WAN hub. The hub contains the Azure VMware Solution ExpressRoute gateway and the site-to-site VPN gateway. It connects an on-premise VPN device with an Azure VMware Solution endpoint.

-[Policy-based VPN setups](../virtual-wan/virtual-wan-custom-ipsec-portal.md) require on-premise and Azure VMware Solution networks to be specified, including the hub ranges. These ranges specify the encryption domain of the policy-based VPN tunnel on-premise endpoint. The Azure VMware Solution side only requires the policy-based traffic selector indicator to be enabled.

-1. In the **Pre-shared key** field, enter the key previously defined for the on-premise endpoint.

-1. Test your connection by [creating an NSX-T Data Center segment](./tutorial-nsx-t-network-segment.md) and provisioning a VM on the network. Ping both the on-premise and Azure VMware Solution endpoints.

-A Backup vault is an entity that stores the backups and recovery points created over time. The Backup vault also contains the backup policies that are associated with the protected virtual machines.

-| Easy integration with Azure services, such as [Storage](cdn-create-a-storage-account-with-cdn.md), [Web Apps](cdn-add-to-web-app.md), and [Media Services](/media-services/previous/media-services-portal-manage-streaming-endpoints) | **&#x2713;** |**&#x2713;** |**&#x2713;** |**&#x2713;** |

-| 🆕Somali | `so` |✔|||✔||

-| 🆕Zulu | `zu` |✔|||||

-To Access the Pre-Call API, you will need to initialize a `callClient` and provision an Azure Communication Services access token. Then you can access the `NetworkTest` feature and run it.

-const networkTest = await callClient.feature(Features.NetworkTest).beginTest(tokenCredential);

-Individual result objects can be accessed as such using the `networkTest` constant above.

-const browserSupport = await networkTest.browserSupport;

- const deviceAccess = await networkTest.deviceAccess;

- const deviceEnumeration = await networkTest.deviceEnumeration;

- const inCallDiagnostics = await networkTest.inCallDiagnostics;

-For granular stats on quality metrics like jitter, packet loss, rtt, etc. `callMediaStatistics` are provided as part of the `NetworkTest` feature. You can subscribe to the call media stats to get full collection of them.

-[Fortanix](https://www.fortanix.com/) has portal and Command Line Interface (CLI) experiences to convert their containerized applications to SGX-capable confidential containers. You don't need to modify or recompile the application. Fortanix provides the flexibility to run and manage a broad set of applications. You can use existing applications, new enclave-native applications, and pre-packaged applications. Start with Fortanix's [Enclave Manager](https://em.fortanix.com/) UI or [REST APIs](https://www.fortanix.com/api/em/). Create confidential containers using the Fortanix's [quickstart guide for AKS](https://support.fortanix.com/hc/en-us/articles/360049658291-Fortanix-Confidential-Container-on-Azure-Kubernetes-Service).

-description: Azure confidential computing offers confidential virtual machines (confidential VMs) for tenants with high security and confidentiality requirements.

-# About Azure DCasv5/ECasv5-series confidential virtual machines (preview)

-Starting in 2022, encrypted OS disks will begin to incur higher costs. This change is because encrypted OS disks use more space, and compression isn't possible. For more information, see [the pricing guide for managed disks](https://azure.microsoft.com/pricing/details/managed-disks/).

-description: Learn how to quickly create an AMD-based confidential virtual machine (confidential VM) using an ARM template. Deploy the confidential VM from the Azure portal or the Azure CLI.

-You can use an Azure Resource Manager template (ARM template) to create a [confidential VM](confidential-vm-overview.md) quickly. The confidential VM you create runs on AMD processors backed by AMD SEV-SNP to achieve VM memory encryption and isolation. For more information, see [Confidential VM Overview](confidential-vm-overview.md).

-## Deploy confidential VM template from Azure portal

-To create and deploy a confidential VM using an ARM template in the Azure portal:

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

-1. [Open the confidential VM ARM template](./quick-create-confidential-vm-portal-amd.md).

- 1. For **Subscription**, select an Azure subscription that meets the [prerequisites](#prerequisites).

-

- 1. For **Resource group**, select an existing resource group from the drop-down menu. Or, select **Create new**, enter a unique name, then select **OK**.

-

- 1. For **Region**, select the Azure region in which to deploy the VM.

-

- 1. For **Vm Name**, enter a name for your VM.

-

- 1. For **Vm Location**, select a location for your VM.

-

- > [!NOTE]

- > Confidential VMs are not available in all locations. For currently supported locations, see which [VM products are available by Azure region](https://azure.microsoft.com/global-infrastructure/services/?products=virtual-machines).

-

- 1. For **Vm Size**, select the VM size to use.

-

- 1. For **Os Image Name**, select the OS image to use for your VM.

-

- 1. For **Os Disk Type**, select the OS disk type to use.

-

- 1. For **Admin Username**, enter an administrator username for your VM.

-

- 1. For **Admin Password Or Key**, enter a password for the administrator account. Make sure your password meets the complexity requirements for [Linux VMs](../virtual-machines/linux/faq.yml#what-are-the-password-requirements-when-creating-a-vm-) or [Windows VMs](../virtual-machines/windows/faq.yml#what-are-the-password-requirements-when-creating-a-vm-).

-

- 1. For **Boot Diagnostics**, select whether you want to use boot diagnostics for your VM. The default setting is **false**.

-

- 1. For **Security Type**, select whether you want to use full OS disk encryption before VM deployment. The option **VMGuestStateOnly** doesn't offer OS disk encryption. The option **DiskWithVMGuestState** enables full OS disk encryption using platform-managed keys.

-

- 1. For **Secure Boot Enabled**, select **true**. This setting makes sure only properly signed boot components can load.

-1. Select **Review + create** to validate your configuration.

-1. Wait for validation to complete. If necessary, fix any validation issues, then select **Review + create** again.

-1. In the **Review + create** pane, select **Create** to deploy the VM.

-To create and deploy a confidential VM using an ARM template through the Azure CLI:

- > Confidential VMs are not available in all locations. For currently supported locations, see which [VM products are available by Azure region](https://azure.microsoft.com/global-infrastructure/services/?products=virtual-machines).

-1. Deploy your VM to Azure using ARM template with custom parameter file

-When you create your confidential VM using the Azure CLI, you need to define custom parameter file. To create a custom JSON parameter file:

-1. Sign into your Azure account in the Azure CLI.

-1. Depending on the OS image you're using, copy in the [example Windows parameter file](#example-windows-parameter-file) or the [example Linux parameter file](#example-linux-parameter-file).

-1. Edit the JSON code in the parameter file as needed. For example, you might want to update the OS image name (`osImageName`), the administrator username (`adminUsername`), and more.

- "value": "Password123@@"

- "value": {your ssh public key}

-A Cosmos container (or shared throughput database) must have a minimum throughput of 400 RU/s. As the container grows, Cosmos DB requires a minimum throughput to ensure the database or container has sufficient resource for its operations.

-In summary, here are the minimum provisioned RU limits.

-| Minimum RUs per container ([dedicated throughput provisioned mode](./account-databases-containers-items.md#azure-cosmos-containers)) | 400 |

-| Minimum RUs per database ([shared throughput provisioned mode](./account-databases-containers-items.md#azure-cosmos-containers)) | 400 RU/s for first 25 containers. |

-Depending on the current RU/s provisioned and resource settings, each resource can scale synchronously and immediately between the minimum RU/s to up to 100x the minimum RU/s. If the requested throughput value is outside the range, scaling is performed asynchronously. Asynchronous scaling may take minutes to hours to complete depending on the requested throughput and data storage size in the container.

-| Minimum autoscale max RU/s for a container | `MAX(4000, highest max RU/s ever provisioned / 10, current storage in GB * 100)` rounded to nearest 1000 RU/s |

-| Minimum autoscale max RU/s for a database | `MAX(4000, highest max RU/s ever provisioned / 10, current storage in GB * 100, 4000 + (MAX(Container count - 25, 0) * 1000))`, rounded to nearest 1000 RU/s. <br></br>Note if your database has more than 25 containers, the system increments the minimum autoscale max RU/s by 1000 RU/s per additional container. For example, if you have 30 containers, the lowest autoscale maximum RU/s you can set is 9000 RU/s (scales between 900 - 9000 RU/s).

-* [Availability and performance tradeoffs for various consistency levels](./consistency-levels.md)

-If you provision autoscale throughput at the entry point of max RU/s of 4000 RU/s, the resource will scale between 400 to 4000 RU/s. Since the autoscale throughput billing rate per RU/s is 1.5x of the standard (manual) rate, for hours where the system has scaled down to the minimum of 400 RU/s, your bill will be higher than if you provisioned 400 RU/s manually. However, with autoscale, at any time, if your application traffic spikes, you can consume up to 4000 RU/s with no user action required. In general, you should weigh the benefit of being able to consume up to the max RU/s at any time with the 1.5x rate of autoscale.

-Checking this option will limit your account's total throughput to 4,000 RU/s. You can change this value after your account has been created.

-* **New applications:** If you're developing a new application and not sure about the throughput (RU/s) you need, autoscale makes it easy to get started. You can start with the autoscale entry point of 400 - 4000 RU/s, monitor your usage, and determine the right RU/s over time.

-The entry point for autoscale maximum throughput `Tmax` starts at 4000 RU/s, which scales between 400 - 4000 RU/s. You can set `Tmax` in increments of 1000 RU/s and change the value at any time.

-When you use database level throughput with autoscale, you can have the first 25 containers share an autoscale maximum RU/s of 4000 (scales between 400 - 4000 RU/s), as long as you don't exceed 40 GB of storage. See this [documentation](autoscale-faq.yml#can-i-change-the-max-ru-s-on-the-database-or-container--) for more information.

-* [Azure Cosmos DB SLAs](https://azure.microsoft.com/support/legal/sla/cosmos-db/v1_2/)

-ThroughputProperties autoscaleThroughputProperties = ThroughputProperties.CreateAutoscaleThroughput(4000); //Set autoscale max RU/s

-ThroughputProperties autoscaleThroughputProperties = ThroughputProperties.CreateAutoscaleThroughput(4000); //Set autoscale max RU/s

-ThroughputProperties autoscaleThroughputProperties = ThroughputProperties.createAutoscaledThroughput(4000); //Set autoscale max RU/s

-ThroughputProperties autoscaleThroughputProperties = ThroughputProperties.createAutoscaledThroughput(4000); //Set autoscale max RU/s

-ThroughputProperties autoscaleThroughputProperties = ThroughputProperties.createAutoscaledThroughput(4000); //Set autoscale max RU/s

-ThroughputProperties autoscaleThroughputProperties = ThroughputProperties.createAutoscaledThroughput(4000); //Set autoscale max RU/s

-> Cross-partition queries require the SDK to visit all existing partitions to check for results. The more [physical partitions](../partitioning-overview.md#physical-partitions) the container has, the slowed they can potentially be.

-description: Learn how to analyze unexpected charges for your Azure subscription.

-# Analyze unexpected charges

-The cloud resource infrastructure that you've built for your organization is likely complex. Many Azure resource types can have different types of charges. Azure resources might be owned by different teams in your organization and they might have different billing model types that apply to various resources. To gain a better understanding of the charges, begin your analysis using one or more of the strategies in the following sections.

-## Review invoice for resource responsible for charge

-How you purchase your Azure services helps you determine the methodology and tools that are available to you as you identify the resource associated with a charge. To determine which methodology applies to you, first [determine your Azure offer type](../costs/understand-cost-mgt-data.md#determine-your-offer-type). Then, identify your customer category in the list of [supported Azure offers](../costs/understand-cost-mgt-data.md#supported-microsoft-azure-offers).

-The following articles provide detailed steps that explain how to review your bill based on your customer type. In each article there are instructions about how to download a CSV file containing usage and cost details for a given billing period.

-Your Azure bill aggregates charges for the month on a per-_meter_ basis. Meters are used to track a resource's usage over time and are used to calculate your bill. When you create a single Azure resource, like a virtual machine, one or more-meter instances are created for the resource.

-Filter the usage CSV file based on the _MeterName_ as shown on the bill that you want to analyze to see all line items that apply to the meter. The _InstanceID_ for the line item corresponds to the actual Azure resource that generated the charge.

-When you've identified the resource in question, you can use Cost analysis in Cost Management to further analyze the costs related to the resource. To learn more about using cost analysis, see [Start analyzing costs](../costs/quick-acm-cost-analysis.md).

-## Review invoiced charges in Cost analysis

-To view your invoice details in the Azure portal, navigate to Cost analysis for the scope associated with the invoice that you're analyzing. Select the **Invoice details** view. Invoice details show you the charges as seen on the invoice.

-[](./media/analyze-unexpected-charges/invoice-details.png#lightbox)

-Viewing invoice details, you can identify the service that has unexpected costs and determine which resources are directly associated with the resource in Cost analysis. For example, if you want to analyze charges for the Virtual Machines service, navigate to the **Accumulated cost** view. Then, set the granularity to **Daily** and filter charges **Service name: Virtual machines** and group charges by **Resource**.

-[](./media/analyze-unexpected-charges/virtual-machines.png#lightbox)

-## Identify spikes in cost over time

-Sometimes you might not know what recent costs resulted in changes to your billed charges. To understand what changed, you can use Cost analysis to [see a daily or monthly breakdown of costs over time](../costs/cost-analysis-common-uses.md#view-costs-per-day-or-by-month). After you create the view, group your charges by either **Service** or **Resource** to identify the changes. You can also change your view to a **Line** chart to better visualize the data.

-

-## Determine resource pricing and billing model

-A single resource can accrue charges across multiple Azure products and services. View the [Azure pricing by product](https://azure.microsoft.com/pricing/#product-pricing) page to learn more about the pricing for each Azure service. For example, a single virtual machine (VM) created in Azure can have the following meters created to track its usage. Each might have different pricing.

-When the VM is created, each meter begins emitting usage records. The usage and the meter's price are tracked in the Azure metering system. You can see the meters that were used to calculate your bill in the usage CSV file.

-## Find people responsible for the resource and engage

-Often, the team responsible for a given resource will know about changes that were made for a resource. Engaging them is useful as you identify why charges might appear. For example, the owning team may have recently created the resource, updated its SKU (thereby changing the resource rate) or increased the load on the resource due to code changes. Continue reading the following sections for more techniques to determine who owns a resource.

-If you have permissions to view a resource, you should be able to access its audit logs. Review the logs to find the user who was responsible for the most recent changes to a resource. To learn more, see [View and retrieve Azure Activity log events](../../azure-monitor/essentials/activity-log.md#view-the-activity-log).

-People that have write access to a subscription or resource group typically have information about the resources were created. They should be able to explain the purpose of a resource or point you to the person who knows. To identify the people with permissions for a Subscription scope, see [Check access for a user to Azure resources](../../role-based-access-control/check-access.md). You can use a similar process for resource groups.

-If you've used the preceding strategies and you still don't understand why you received a charge or if you need other help with billing issues, please [create a support request](https://go.microsoft.com/fwlink/?linkid=2083458).

-2. Make sure you grant at least **Reader** role to the user or service principal on the data lake account. Here is how to make it:

- 1. Go to the Azure portal -> your Data Lake Store account

- 2. Click **Access control (IAM)** on the blade of the Data Lake Store

- 3. Click **Add role assignment**

- 4. Set **Role** as **Reader**, and select the user or the service principal you use for copy to grant access

-3. If you don't want to grant **Reader** role to the user or service principal, alternative is to [explicitly specify an execution location](data-factory-data-movement-activities.md#global) in copy activity with the location of your Data Lake Store. Example:

- - **Use switches and NIC teaming**. Use this option when you need port level redundancy through teaming. NIC Teaming allows you to group two physical ports on the device node, Port 3 and Port 4 in this case, into two software-based virtual network interfaces. These teamed network interfaces provide fast performance and fault tolerance in the event of a network interface failure. For more information, see [NIC teaming on Windows Server](/windows-server/networking/technologies/nic-teaming/nic-teaming).

-This tutorial describes how to ingest data by using the data copy service without an intermediate host. The data copy service runs locally on Microsoft Azure Data Box, connects to your network-attached storage (NAS) device via SMB, and copies data to Data Box.

- |**File optimization** |When this feature is enabled, files smaller than 1 MB are packed during ingestion. This packing speeds up the data copy for small files. It also saves a significant amount of time when the number of files far exceeds the number of directories.</br>If you use file optimization:<ul><li>After you run prepare to ship, you can [download a BOM file](data-box-logs.md#inspect-bom-during-prepare-to-ship), which lists the original file names, to help you ensure that all the right files are copied.</li><li>Don't delete the packed files, whose file names begin with "ADB_PACK_". If you delete a packed file, the original file isn't uploaded during future data copies.</li><li>Don't copy the same files that you copy with the Copy Service via other protocols such as SMB, NFS, or REST API. Using different protocols can result in conflicts and failure during data uploads. </li></ul> |

-Specific steps are provided to copy metadata with Windows and Linux data copy tools. Metadata isn't preserved when transferring data to blob storage.

-In this article, the ACLs, timestamps, and file attributes that are transferred are referred to collectively as *metadata*.

-## Transferred metadata

-The following metadata is transferred when data from the Data Box is uploaded to Azure Files.

-#### Timestamps

-

-#### File attributes

-#### ACLs

-**ACLs transfer over SMB**

-ACLs aren't transferred when you [copy data over NFS](./data-box-deploy-copy-data-via-nfs.md) or [use the data copy service](data-box-deploy-copy-data-via-copy-service.md). The data copy service reads data directly from your shares and can't read ACLs.

-**Default ACLs transfer**

- - A Continuous scan based on an image pull. This scan is performed every seven days after an image was pulled, and only for 30 days after the image was pulled. This mode doesn't require the security profile, or extension.

-The recommendation **Running container images should have vulnerability findings resolved** shows vulnerabilities for running images by using the scan results from ACR registeries and information on running images from the Defender security profile/extension. Images that are deployed from a non ACR registry, will appear under the Not applicable tab.

-### Does Microsoft Defender for Containers support AKS without scale set (default) ?

- - [What are the benefits of enabling enhanced security features?](#what-are-the-benefits-of-enabling-enhanced-security-features)

- - [FAQ - Pricing and billing](#faqpricing-and-billing)

- - [How can I track who in my organization enabled a Microsoft Defender plan in Defender for Cloud?](#how-can-i-track-who-in-my-organization-enabled-a-microsoft-defender-plan-in-defender-for-cloud)

- - [What are the plans offered by Defender for Cloud?](#what-are-the-plans-offered-by-defender-for-cloud)

- - [How do I enable Defender for Cloud's enhanced security for my subscription?](#how-do-i-enable-defender-for-clouds-enhanced-security-for-my-subscription)

- - [Can I enable Microsoft Defender for Servers on a subset of servers in my subscription?](#can-i-enable-microsoft-defender-for-servers-on-a-subset-of-servers-in-my-subscription)

- - [If I already have a license for Microsoft Defender for Endpoint can I get a discount for Defender for Servers?](#if-i-already-have-a-license-for-microsoft-defender-for-endpoint-can-i-get-a-discount-for-defender-for-servers)

- - [My subscription has Microsoft Defender for Servers enabled, do I pay for not-running servers?](#my-subscription-has-microsoft-defender-for-servers-enabled-do-i-pay-for-not-running-servers)

- - [Will I be charged for machines without the Log Analytics agent installed?](#will-i-be-charged-for-machines-without-the-log-analytics-agent-installed)

- - [If a Log Analytics agent reports to multiple workspaces, will I be charged twice?](#if-a-log-analytics-agent-reports-to-multiple-workspaces-will-i-be-charged-twice)

- - [If a Log Analytics agent reports to multiple workspaces, is the 500-MB free data ingestion available on all of them?](#if-a-log-analytics-agent-reports-to-multiple-workspaces-is-the-500-mb-free-data-ingestion-available-on-all-of-them)

- - [Is the 500-MB free data ingestion calculated for an entire workspace or strictly per machine?](#is-the-500-mb-free-data-ingestion-calculated-for-an-entire-workspace-or-strictly-per-machine)

- - [What data types are included in the 500-MB data daily allowance?](#what-data-types-are-included-in-the-500-mb-data-daily-allowance)

- - [Next steps](#next-steps)

-In October 2021, we released [a new Microsoft Defender for Endpoint solution stack](https://techcommunity.microsoft.com/t5/microsoft-defender-for-endpoint/defending-windows-server-2012-r2-and-2016/ba-p/2783292) to public preview for Windows Server 2012 R2 and 2016. The new solution stack does not use or require installation of the Microsoft Monitoring Agent (MMA).

-The new version of Microsoft Defender for Endpoint is deployed by Defender for Servers Plan 1 for Windows Server 2012 R2 and 2016.

-# Migrate databases with Azure SQL Migration extension for Azure Data Studio (Preview)

-> [!IMPORTANT]

-> **Known issue when migrating multiple databases to SQL Server on Azure VM:** Concurrently migrating multiple databases to the same SQL Server on Azure VM results in migration failures for most databases. Ensure you only migrate a single database to a SQL Server on Azure VM at any point in time.

-# Tutorial: Migrate SQL Server to an Azure SQL Managed Instance offline using Azure Data Studio with DMS (Preview)

-# Tutorial: Migrate SQL Server to an Azure SQL Managed Instance online using Azure Data Studio with DMS (preview)

-# Tutorial: Migrate SQL Server to SQL Server on Azure Virtual Machine offline using Azure Data Studio with DMS (Preview)

-# Tutorial: Migrate SQL Server to SQL Server on Azure Virtual Machine online using Azure Data Studio with DMS (Preview)

-* [React to Blob Storage events locally](react-blob-storage-events-locally.md)

- > [!NOTE]

- > Currently, you can't use an Event Grid trigger for a function app when the event is delivered in the **CloudEvents** schema. Instead, use an HTTP trigger.

-| **[Zirro](https://zirro.com/services/)**| Cologix, Equinix | Montreal, Toronto |

-> The same technique, using Local Preference, can be applied to routing from customer to Azure Virtual Network. We don't tag BGP Community value to the prefixes advertised from Azure to your network. However, since you know which of your Virtual Network deployment is close to which of your office, you can configure your routers accordingly to prefer one ExpressRoute circuit to another.

->

-## Autonomous System numbers

-An ExpressRoute circuit provides private connectivity to Microsoft backbone network.

-* It offers *Private peering* to connect to private endpoints of your IaaS deployment in Azure regions

-* Also, it offers *Microsoft peering* to connect to public endpoints of IaaS, PaaS, and SaaS services in Microsoft network.

-For more information about ExpressRoute, see the [Introduction to ExpressRoute][ExR-Intro] article.

-Often there's a confusion whether ExpressRoute can be used or not for routing Microsoft 365 SaaS traffic.

-* One side argument: ExpressRoute does offer Microsoft peering, using which you can reach most of the public endpoints in Microsoft network.

-In fact, using a *Route Filter* you can select Microsoft 365 service prefixes that need to be advertised via Microsoft peering to your on-premises network.

-These routes advertisement enables routing Microsoft 365 service traffic over the ExpressRoute circuit.

-* The counter argument: Microsoft 365 is a distributed service. It is designed to enable customers all over the world to connect to the service using the Internet.

-So, it's recommended not to use ExpressRoute for Microsoft 365.

-The goals of this article are:

-* to provide technical reasoning for the arguments, and

-* objectively discuss when to use ExpressRoute for routing Microsoft 365 traffic and when not to use it.

-Microsoft 365 service often includes real-time traffic such as voice & video calls, online meetings, and real-time collaboration. This real-time traffic has stringent network performance requirements in terms of latency and jitter. Within certain limits of network latency, jitter can be effectively handled using buffer at the client device. Network latency is a function of physical distance traffic need to travel, link bandwidth, and network processing latency.

-Microsoft strives to optimize network performance of all the cloud applications both in terms of architecture and features. To begin with, Microsoft owns one of the largest global networks, which is optimized to achieve the core objective of offering best network performance. Microsoft network is software defined, and it's a "Cold Potato" network. "Cold Potato" network in the sense, it attracts and egress traffic as close as possible to client-device/customer-network. Besides, Microsoft network is highly redundant and highly available. For more information about architecture optimization, see [How Microsoft builds its fast and reliable global network][MGN].

-* dynamically routing the end-user connection to the nearest Microsoft 365 entry point, and

-* from the entry point efficiently routing them within the Microsoft global network to the nearest (and authorized) Microsoft 365 data center.

-The Microsoft 365 entry points are serviced by Azure Front Door (AFD). AFD is a widely distributed service present at Microsoft global edge network and it helps to create fast, secure, and highly scalable SaaS applications. To further understand how AFD accelerates web application performance, see [What is Azure Front Door?][AFD]. While choosing the nearest Microsoft 365 data center, Microsoft does take into consideration data sovereignty regulations within the geo-political region.

-Between a client-server when you force the traffic to flow through certain network device(s) located in a geographical location, then it's referred to as geo-pinning the network connections. Traditional network architecture, with the underlying design principle that the clients-servers are statically located, commonly geo-pins the connections.

-For example, when you force your enterprise Internet connections traverse through your corporate network, and egress from a central location (typically via a set of proxy-servers or firewalls), you're geo-pinning the Internet connections.

-Similarly, in SaaS application architecture if you force route the traffic through an intermediate datacenter (for example, cloud security) in a region or via one or more intermediate network devices (for example, ExpressRoute) in a specific location then you're geo-pinning the SaaS connections.

-## When not to use ExpressRoute for Microsoft 365?

-Because of its ability to dynamically shorten the route length and dynamically choose the closest server datacenter depending on the location of the clients, Microsoft 365 is said to be designed for the Internet.

-Besides, certain Microsoft 365 traffic is routed only through the Internet.

-When you have your SaaS clients widely distributed across a region or globally, and if you geo-pin the connections to a particular location then you are forcing the clients further away from the geo-pined location to experience higher network latency.

-Higher network latency results in suboptimal network performance and poor application performance.

-Therefore, in scenarios where you have widely distributed SaaS clients or clients that are highly mobile, you don't want to geo-pin connections by any means including forcing the traffic through an ExpressRoute circuit in a specific peering location.

-* Your SaaS clients are concentrated in a geo-location and the most optimal way to connect to Microsoft global network is via ExpressRoute circuits

-* Your SaaS clients are concentrated in multiple global locations and each location has its own ExpressRoute circuits that provide optimal connectivity to Microsoft global network

-* You're required by law to route cloud-bound traffic via private connections

-* You're required to route all the SaaS traffic to a geo-pinned centralized location (be it a private or a public datacenter) and the optimal way to connect the centralized location to the Microsoft global network is via ExpressRoute

-* For some of your static SaaS clients only ExpressRoute provides optimal connectivity, while for the other clients you use Internet

-While you use ExpressRoute, you can apply the route filter associated with Microsoft peering of ExpressRoute to route only a subset of Microsoft 365 services and/or Azure PaaS services over the ExpressRoute circuit. For more information, see [Tutorial: Configure route filters for Microsoft peering][ExRRF].

-Learn how to use the Azure Policy extension for Visual Studio Code to look up

-The Azure Policy extension for Visual Studio Code can be installed on Linux, Mac, and Windows.

-After you meet the prerequisites, you can install Azure Policy extension for Visual Studio Code by

-1. Select **File\Preferences\Settings**.

- - Command Palette:

-resource group in the **Resources** pane. The treeview includes the following groupings of resources

- - Command Palette:

-treeview, the Azure Policy extension opens the JSON file representing that resource and all its

-The Azure Policy extension lists policy types and policy assignments as a treeview for the

- - Command Palette:

-the treeview, the Azure Policy extension opens the JSON that represents the policy or assignment and

-[constraint template](https://open-policy-agent.github.io/gatekeeper/website/docs/howto/#constraint-templates). The YAML

-# Connect to Apache Beeline on HDInsight or install it locally

-[Apache Beeline](https://cwiki.apache.org/confluence/display/Hive/HiveServer2+Clients#HiveServer2Clients-BeelineΓÇôNewCommandLineShell) is a Hive client that is included on the head nodes of your HDInsight cluster. This article describes how to connect to the Beeline client installed on your HDInsight cluster across different types of connections. It also discusses how to [Install the Beeline client locally](#install-beeline-client).

-#### From cluster head or inside Azure Virtual Network with Apache Spark

-| patch | Yes | Yes | Support for [JSON Patch](https://www.hl7.org/fhir/http.html#patch) only. We've included a workaround to use JSON Patch in a bundle in [this PR](https://github.com/microsoft/fhir-server/pull/2143).|

-| patch (conditional) | Yes | Yes | Support for [JSON Patch](https://www.hl7.org/fhir/http.html#patch) only. We've included a workaround to use JSON Patch in a bundle in [this PR](https://github.com/microsoft/fhir-server/pull/2143).

-Patch is a valuable RESTful operation when you need to update only a portion of the FHIR resource. Using Patch allows you to specify the element(s) that you want to update in the resource without having to update the entire record. FHIR defines three types of ways to Patch resources in FHIR: JSON Patch, XML Patch, and FHIR Path Patch. Azure API for FHIR supports JSON Patch and Conditional JSON Patch (which allows you to Patch a resource based on a search criteria instead of an ID). To walk through some examples of using JSON Patch, refer to the sample [REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/FhirPatchRequests.http).

-### Testing Patch

-Within Patch, there's a test operation that allows you to validate that a condition is true before doing the patch. For example, if you wanted to set a patient deceased, only if they weren't already marked as deceased, you could use the example below:

-PATCH `http://{FHIR-SERVICE-NAME}/Patient/{PatientID}`

- ΓÇ£opΓÇ¥: ΓÇ£testΓÇ¥,

- ΓÇ£pathΓÇ¥: ΓÇ£/deceasedBooleanΓÇ¥,

- ΓÇ£valueΓÇ¥: false

- ΓÇ£opΓÇ¥: ΓÇ£replaceΓÇ¥

- ΓÇ£pathΓÇ¥: ΓÇ£/deceasedBooleanΓÇ¥,

- ΓÇ£valueΓÇ¥: true

-### Patch in Bundles

-By default, JSON Patch isn't supported in Bundle resources. This is because a Bundle only supports with FHIR resources and JSON Patch isn't a FHIR resource. To work around this, we'll treat Binary resources with a content-type of `"application/json-patch+json"`as base64 encoding of JSON string when a Bundle is executed. For information about this workaround, log in to [Zulip](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Transaction.20with.20PATCH.20request).

-POST `https://{FHIR-SERVICE-NAME}/`

-content-type: `application/json`

- ΓÇ£resourceTypeΓÇ¥: ΓÇ£BundleΓÇ¥

- ΓÇ£idΓÇ¥: ΓÇ£bundle-batchΓÇ¥,

- ΓÇ£typeΓÇ¥: ΓÇ£batchΓÇ¥

- ΓÇ£entryΓÇ¥: [

- ΓÇ£fullUrlΓÇ¥: ΓÇ£Patient/{PatientID}ΓÇ¥,

- ΓÇ£resourceΓÇ¥: {

- ΓÇ£resourceTypeΓÇ¥: ΓÇ£BinaryΓÇ¥,

- ΓÇ£contentTypeΓÇ¥: ΓÇ£application/json-patch+jsonΓÇ¥,

- ΓÇ£dataΓÇ¥: "W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9nZW5kZXIiLCJ2YWx1ZSI6ImZlbWFsZSJ9XQ=="

- ΓÇ£requestΓÇ¥: {

- ΓÇ£methodΓÇ¥: ΓÇ£PATCHΓÇ¥,

- ΓÇ£urlΓÇ¥: ΓÇ£Patient/{PatientID}ΓÇ¥

-{

- "templateType": "CollectionContent",

- "template": [

- {

- "templateType": "IotJsonPathContent",

- "template": {

- "typeName": "heartrate",

- "typeMatchExpression": "$..[?(@Body.telemetry.HeartRate)]",

- "patientIdExpression": "$.Properties.iotcentral-device-id",

- "values": [

- {

- "valueExpression": "$.Body.telemetry.HeartRate",

- }

- ]

-|Allow JSON patch in bundles | [JSON patch in bundles](././../azure-api-for-fhir/fhir-rest-api-capabilities.md#patch-in-bundles)|

-| patch | Yes | Yes | Support for [JSON Patch](../../healthcare-apis/fhir/fhir-rest-api-capabilities.md#patch-and-conditional-patch) only. |

-| patch (conditional) | Yes | Yes |

-# FHIR Rest API capabilities for Azure Health Data Services FHIR service

-Patch is a valuable RESTful operation when you need to update only a portion of the FHIR resource. Using Patch allows you to specify the element(s) that you want to update in the resource without having to update the entire record. FHIR defines three types of ways to Patch resources in FHIR: JSON Patch, XML Patch, and FHIR Path Patch. The FHIR service support JSON Patch and Conditional JSON Patch (which allows you to Patch a resource based on a search criteria instead of an ID). To walk through some examples of using JSON Patch, refer to the sample [REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/FhirPatchRequests.http).

-### Testing Patch

-Within Patch, there's a test operation that allows you to validate that a condition is true before doing the patch. For example, if you want to set a patient as deceased (only if they're not already marked as deceased) you can use the example below:

-PATCH `http://{FHIR-SERVICE-NAME}/Patient/{PatientID}`

-### Patch in Bundles

-By default, JSON Patch isn't supported in Bundle resources. This is because a Bundle only supports with FHIR resources and JSON Patch isn't a FHIR resource. To work around this, we'll treat Binary resources with a content-type of `"application/json-patch+json"`as base64 encoding of JSON string when a Bundle is executed. For information about this workaround, log in to [Zulip](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Transaction.20with.20PATCH.20request).

-POST `https://{FHIR-SERVICE-NAME}/`

-content-type: `application/json`

-|Allow JSON patch in bundles | [JSON patch in bundles](./././azure-api-for-fhir/fhir-rest-api-capabilities.md#patch-in-bundles)|

-To access and use the **Administration** section, you must be in the **Administrator** role for an Azure IoT Central application. If you create an Azure IoT Central application, you're automatically assigned to the **Administrator** role for that application.

-In the **Application Settings** page, you can change the name and URL of your application, then select **Save**.

-

-1. In your IoT Central application, navigate to the **Administration > Device Connection** page.

-1. Select **Device file upload**.

-1. Navigate to the **Administration** section in your application.

-1. Select **Device file upload**.

-To start using organizations, you need to define your organization hierarchy. Each organization in the hierarchy acts as a logical container where you place devices, save dashboards and device groups, and invite users. To create your organizations, go to the **Administration** section in your IoT Central application, select the **Organizations** tab, and select either **+ New** or use the context menu for an existing organization. To create one or many organizations at a time, select **+ Add another organization**:

-To invite a user, navigate to **Administration > Users**. Enter their email address, the organization they're assigned to, and the role or roles the user is a member of. The organization you select filters the list of available roles to make sure you assign the user to a valid role:

-To access and use the **Administration** section, you must be in the **App Administrator** role for an Azure IoT Central application or in a custom role that includes administration permissions. If you create an Azure IoT Central application, you're automatically added to the **App Administrator** role for that application.

-Users in the **App Builder** role can manage every part of the app, but can't make changes on the Administration or Continuous Data Export tabs.

-If your solution requires finer-grained access controls, you can create roles with custom sets of permissions. To create a custom role, navigate to the **Roles** page in the **Administration** section of your application, and choose one of these options:

-In **Administration/Application Settings**, copy the **Application ID**. You use this value in later steps.

-1. Navigate to **Administration > Device connection**.

-Many of the tools you use as an administrator are available in the **Administration** section of each IoT Central application. You can also use the following tools to complete some administrative tasks:

- > On the **Administration > Device connection** page, the **Auto approve** option controls whether an operator must manually approve the device before it can start sending data.

-1. From the left pane of your Azure IoT Central app, select **Administration**.

-1. Select **Application** > **Management** > **Delete**.

-1. For your IoT Central application, go to the Administration tab and select **Delete**.

-If you've finished with your IoT Central application, you can delete it by signing in to the application and navigating to the **Application Settings** page in the **Administration** section.

-IoT Plug and Play devices should follow a set of conventions when they exchange messages with an IoT hub. IoT Plug and Play devices use the MQTT protocol to communicate with IoT Hub.

-When a device starts up for the first time, it can send an initial value for a reported property if it doesn't receive an initial desired property from the hub. In this case, the device should set `av` to `1`. For example:

- "ac": 200,

- "av": 1,

- "av": 3,

- sudo apt-get install aziot-edge

-1. Install the most recent version of IoT Edge, along with the IoT identity service.

- sudo apt-get install aziot-edge

-Stay up-to-date with recent updates and announcements in the [Internet of Things blog](https://azure.microsoft.com/blog/topics/internet-of-things/)

-[Understand Azure IoT Edge modules](iot-edge-modules.md)

-[Configure an IoT Edge device to act as a transparent gateway](how-to-create-transparent-gateway.md)

-| [1.2](https://github.com/Azure/azure-iotedge/releases/tag/1.2.0) | Stable | April 2021 | [IoT Edge devices behind gateways](how-to-connect-downstream-iot-edge-device.md?view=iotedge-2020-11&preserve-view=true)<br>[IoT Edge MQTT broker (preview)](how-to-publish-subscribe.md?view=iotedge-2020-11&preserve-view=true)<br>New IoT Edge packages introduced, with new installation and configuration steps. For more information, see [Update from 1.0 or 1.1 to 1.2](how-to-update-iot-edge.md#special-case-update-from-10-or-11-to-12).<br>Includes [Microsoft Defender for IoT micro-agent for Edge](/azure/defender-for-iot/device-builders/overview.md).

-| Operation | Billing information |

-| Identity registry operations <br/> (create, retrieve, list, update, delete) | Not charged. |

-| Device-to-cloud messages | Successfully sent messages are charged in 4-KB chunks on ingress into IoT Hub. For example, a 6-KB message is charged 2 messages. |

-| Cloud-to-device messages | Successfully sent messages are charged in 4-KB chunks, for example a 6-KB message is charged 2 messages. |

-| File uploads | File transfer to Azure Storage is not metered by IoT Hub. File transfer initiation and completion messages are charged as messaged metered in 4-KB increments. For example, transferring a 10-MB file is charged as two messages in addition to the Azure Storage cost. |

-| Direct methods | Successful method requests are charged in 4-KB chunks, and responses are charged in 4-KB chunks as additional messages. Requests to disconnected devices are charged as messages in 4-KB chunks. For example, a method with a 4-KB body that results in a response with no body from the device is charged as two messages. A method with a 6-KB body that results in a 1-KB response from the device is charged as two messages for the request plus another message for the response. |

-| Device and module twin reads | Twin reads from the device or module and from the solution back end are charged as messages in 4-KB chunks. For example, reading a 8-KB twin is charged as 2 messages. |

-| Device and module twin updates (tags and properties) | Twin updates from the device or module and from the solution back end are charged as messages in 4-KB chunks. For example, reading a 12-KB twin is charged as 3 messages. |

-| Device and module twin queries | Queries are charged as messages depending on the result size in 4-KB chunks. |

-| Jobs operations <br/> (create, update, list, delete) | Not charged. |

-| Jobs per-device operations | Jobs operations (such as twin updates, and methods) are charged as normal. For example, a job resulting in 1000 method calls with 1-KB requests and empty-body responses is charged 1000 messages. |

-| Keep-alive messages | When using AMQP or MQTT protocols, messages exchanged to establish the connection and messages exchanged in the negotiation are not charged. |

-* One message * 60 minutes * 24 hours = 1440 messages per day for the device-to-cloud messages.

-* Two request plus response * 6 times per hour * 24 hours = 288 messages for the methods.

-* 25 (100 KB / 4 KB) messages * 24 hours for device-to-cloud messages.

-* Two messages (1 KB / 0.5 KB) * six times per day for device twin updates.

-This calculation gives a total of 612 messages per day.

-The solution back end consumes 28 messages (14 KB / 0.5 KB) to read the device twin, plus one message to update it, for a total of 29 messages.

-In total, the device and the solution back end consume 641 messages per day.

-### Azure Machine Learning CLI (v2) v2.2.0

- # ip = socket.gethostbyname(socket.gethostname())

- try:

- ip = args.remote_debug_client_ip

- except:

- print("Need to supply IP address for VS Code client")

-from azureml.core.webservice import Webservice

-GET: https://marketplaceapi.microsoft.com/api/usageEvents

- implementation 'androidx.appcompat:appcompat:1.0.0'

- setContentView(R.layout.activity\_main);

- NotificationHub.start(this.getApplication(), ΓÇ£Connection-StringΓÇ¥, "Hub Name");

-### Day 2 worker node

-The following instance types are supported as a day 2 operation by configuring machine sets. For information on how to create a machine set, see [Creating a machine set on Azure](https://docs.openshift.com/container-platform/4.8/machine_management/creating_machinesets/creating-machineset-azure.html).

-| Azure SignalR | EAST US, SOUTH CENTRAL US,<br/>WEST US 2, All China regions | | Preview <br/> [Learn how to create a private endpoint for Azure SignalR.](../azure-signalr/howto-private-endpoints.md) |

-| - Office 365 GCC High | - | Not Available |

-| - Office 365 DoD | - | Not Available |

- return new FabricTransportServiceRemotingListener(c, this,

- new ServiceRemotingJsonSerializationProvider());

-1. Select **Create** to start the creation of the App Service Static Web App and provision a GitHub Action for deployment.

-1. Select **Create** to start the creation of the App Service Static Web App and provision a GitHub Action for deployment.

-1. Select **Create** to start the creation of the App Service Static Web App and provision a GitHub Action for deployment.

-If you don't have an Azure subscription, [create a free trial account](https://azure.microsoft.com/free).

-1. Select **Create** to start the creation of the App Service Static Web App and provision a GitHub Action for deployment.

-1. On the resource screen, click the _URL_ link to open your deployed application. You may need to wait a minute or two for the GitHub Action to complete.

-To configure environment variables, such as `JEKYLL_ENV`, add an `env` section to the Azure Static Web Apps GitHub Action in the workflow.

-The Azure Active Directory (Azure AD) managed identities for Azure resources feature solves this problem. The feature provides Azure services with an automatically managed identity in Azure AD. This allows you to assign an identity to your Stream Analytics job which can then authenticate to any input or outputs that supports Azure AD authentication, without any credentials. See [managed identities for Azure resources overview page](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) for more information about this service.

-To create a user-assigned managed identity, your account needs the [Managed Identity Contributor role](https://docs.microsoft.com/azure/role-based-access-control/built-in-roles#managed-identity-contributor) assignment.

-> Only alphanumeric characters (0-9, a-z, and A-Z) and the hyphen (-) are supported when you create user-assigned managed identities. For the assignment to a virtual machine or virtual machine scale set to work correctly, the name is limited to 24 characters. For more information, see [**FAQs and known issues**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/known-issues)

-For more information on how to manager user-assigned managed identities please visit the [Managed user-assigned managed identities page](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities?pivots=identity-mi-methods-azp).

- -ManagedVirtualNetwork $config

-#Creating an Data Lake Storage Gen2 account

-The following script creates a Spark pool with two workers and one driver node. Update the values to match your source region workspace Spark pool.

-#Getting the restore points

-

-<#

-Transform Synapse SQL pool resource ID to SQL database ID because currently the command only accepts the SQL database ID.

-For example: /subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Sql/servers/<WorkspaceName>/databases/<DatabaseName>

-#>

- -replace "sqlPools", "databases"

-#Tracks the status of the restore

-## Step 5: Create a serverless SQL pool, Spark pool database and objects

-```powershell

-# Adding Storage Blob Data Contributor to WS Managed Identity on the storage account. This errors out with the message New-AzRoleAssignment : Exception of type 'Microsoft.Rest.Azure.CloudException' was thrown.

-# But it creates the required permissions on the storage account.

-#Getting principal ID for WS Managed Identity

-# Add the Synapse RBAC assignment. Use the objectId of the Azure AD user or group you want to assign.

-# Check if user is added to the access control by running this command.

-To get the ObjectIds and RoleIds in the source region workspace, run the Get-AzSynapseRoleAssignment command. Assign the same Azure Synapse RBAC roles to the Azure AD users or groups in the target region workspace.

-Instead of using -ObjectId as the parameter, you can also use -SignInName, where you provide the email address or the user principal name of the user. To find out more about the available options, see [Azure Synapse RBAC - PowerShell cmdlet](/powershell/module/az.synapse/new-azsynapseroleassignment?view=azps-6.3.0&preserve-view=true).

-#Get the Object Id of the user and assign the required Azure Synapse RBAC permissions to the Azure AD user. You can provide the email address of the user (username@contoso.com) for the --assignee parameter.

-

-To commit the changes and complete the move of the workspace, delete the source region workspace after testing the workspace in the target region. To do so, go to the resource group which has the source region workspace from your dashboard in the portal and select the workspace and select Delete at the top of the Resource group page.

-User accounts can be cloud-only or hybrid users from the same Azure AD tenant.

-You can deploy Azure AD-joined VMs directly from the Azure portal when you [create a new host pool](create-host-pools-azure-marketplace.md) or [expand an existing host pool](expand-existing-host-pool.md). To deploy an Azure AD-joined VM, open the **Virtual Machines** tab, then select whether to join the VM to Active Directory or Azure Active Directory. Selecting **Azure Active Directory** gives you the option to enroll VMs with Intune automatically, which lets you easily manage [Windows 10 Enterprise](/mem/intune/fundamentals/windows-virtual-desktop) and [Windows 10 Enterprise multi-session](/mem/intune/fundamentals/windows-virtual-desktop-multi-session) VMs. Keep in mind that the Azure Active Directory option will only join VMs to the same Azure AD tenant as the subscription you're in.

-> - Host pools should only contain VMs of the same domain join type. For example, AD-joined VMs should only be with other AD VMs, and vice-versa.

-> - The host pool VMs must be Windows 10 single-session or multi-session, version 2004 or later.

-> - Managing Azure Virtual Desktop session hosts using Microsoft Endpoint Manager (Intune) is currently only supported in the Azure Public cloud.

-After you've created your host pool, you must assign users access to let them access their resources. To grant access to resources, add each user to the app group. Follow the instructions in [Manage app groups](manage-app-groups.md) to assign user access to apps and desktops. We recommend that you use user groups instead of individual users wherever possible.

-The default configuration supports connections from Windows 10 using the [Windows Desktop client](user-documentation/connect-windows-7-10.md). You can use your credentials, smart card, [Windows Hello for Business certificate trust](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust) or [Windows Hello for Business key trust with certificates](/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs) to sign in to the session host. However, to access the session host, your local PC must meet one of the following conditions:

-You can use FSLogix profile containers with Azure AD-joined VMs when you store them on Azure Files. For more information, see [Create a profile container with Azure Files and Azure AD](create-profile-container-azure-ad.md).

- - For **How is your subscription configured**, select **Empty subscription**. An "empty" subscription is a subscription that doesn't require an identity provider like Azure AD or AD DS.

-1. Go to the [Azure Virtual Desktop pricing page](https://azure.microsoft.com/pricing/details/virtual-desktop/) and look for the "Apps" and "Apps + Desktops" prices for your region.

-We recommend that you use [PowerShell](/powershell/module/az.Compute/Add-azVmssExtension?view=azps-7.0.0), the [Azure CLI](/cli/azure/vmss/extension), or an [Azure Resource Manager template](/azure/templates/microsoft.compute/virtualmchinescalesets/extensions) when you deploy the Custom Script Extension on a virtual machine scale set. This way, you can choose to use a managed identity or have direct control of the expiration of the SAS token for accessing the script in your storage account for as long as you need.

-The latest version of the Network Watcher extension is currently `1.4.1974.1`.

-| Debian by credativ |8.x, 9.x, 10.x |In kernel |Package: In repo under "waagent" <br/>Source code: [GitHub](https://github.com/Azure/WALinuxAgent) |

-| [Red Hat Enterprise Linux by Red Hat](../workloads/redhat/overview.md) |6.x, 7.x, 8.x |In kernel |Package: In repo under "WALinuxAgent" <br/>Source code: [GitHub](https://github.com/Azure/WALinuxAgent) |

-| Ubuntu by Canonical |Ubuntu Server and Pro. 16.x, 18.x, 20.x<p>Information about extended support for Ubuntu 12.04 and 14.04 can be found here: [Ubuntu Extended Security Maintenance](https://www.ubuntu.com/esm). |In kernel |Package: In repo under "walinuxagent" <br/>Source code: [GitHub](https://github.com/Azure/WALinuxAgent) |

- > Deallocating the VM also releases any dynamic IP addresses assigned to the VM. The OS and data disks are not affected.

-> [!WARNING]

-> Deallocating the VM releases any dynamic IP addresses assigned to the VM. The OS and data disks are not affected.

->

->

-* This tutorial will create a NAT rule on a VpnGateway which will be associated with a VpnSiteConnection, so this assumes you have an existing VpnGateway connection to two branches with overlapping address spaces.

-You can configure and view NAT rules on your VPN gateway settings at any time using Azure PowerShell

-1. Declare the variables for the existing resources

-1. Create the new NAT rule to ensure the Site-to-site VPN gateway is able to distinguish between the two branches with overlapping address spaces.

- * IngressSnat mode (also known as Ingress Source NAT) is applicable to traffic entering the Azure hubΓÇÖs Site-to-site VPN gateway.

- * EgressSnat mode (also known as Egress Source NAT) is applicable to traffic leaving the Azure hubΓÇÖs Site-to-site VPN gateway.

- * **InternalMapping:** An address prefix range of source IPs on the inside network that will be mapped to a set of external IPs. In other words, your pre-NAT address prefix range.

- * **ExternalMapping:** An address prefix range of destination IPs on the outside network that source IPs will be mapped to. In other words, your post-NAT address prefix range.

- * **Link Connection:** Connection resource that virtually connects a VPN site to the Azure Virtual WAN Hub's Site-to-site VPN gateway.

-

- ### Syntax

- ```

- New-AzVpnGatewayNatRule

- -ResourceGroupName <String>

- -ParentResourceName <String>

- -Name <String>

- [-Type <String>]

- [-Mode <String>]

- -InternalMapping <String[]>

- -ExternalMapping <String[]>

- [-InternalPortRange <String[]>]

- [-ExternalPortRange <String[]>]

- [-IpConfigurationId <String>]

- [-AsJob]

- [-DefaultProfile <IAzureContextContainer>]

- [-WhatIf]

- [-Confirm] [<CommonParameters>]

- ```

-

- ```azurepowershell-interactive

-1. Declare the variable to create a new object for the new NAT rule

-1. Declare the variable to get the existing VPN connection

-1. Set the appropriate index for the NAT rule in the VPN connection

-1. Finally, update the existing VPN connection with the new NAT rule

-For more information about Site-to-site configurations, see [Configure a Virtual WAN Site-to-site connection](virtual-wan-site-to-site-portal.md).

-# Configure NAT Rules for your Virtual WAN VPN gateway

- :::image type="content" source="./media/nat-rules-vpn-gateway/diagram.png" alt-text="Diagram showing architecture.":::

-

-In order to use NAT, VPN devices need to use any-to-any (wildcard) traffic selectors. Policy Based (narrow) traffic selectors are not supported in conjunction with NAT configuration.

-* **Static NAT**: Static rules define a fixed address mapping relationship. For a given IP address, it will be mapped to the same address from the target pool. The mappings for static rules are stateless because the mapping is fixed. For example, a NAT rule created to map 10.0.0.0/24 to 192.168.0.0/24 will have a fixed 1-1 mapping. 10.0.0.0 is translated to 192.168.0.0, 10.0.0.1 is translated to 192.168.0.1, and so on.

-* **Dynamic NAT**: For dynamic NAT, an IP address can be translated to different target IP addresses and TCP/UDP port based on availability, or with a different combination of IP address and TCP/UDP port. The latter is also called NAPT, Network Address and Port Translation. Dynamic rules will result in stateful translation mappings depending on the traffic flows at any given time. Due to the nature of Dynamic NAT and the ever changing IP/Port combinations, flows that make use of Dyanmic NAT rules have to be initiated from the **InternalMapping** (Pre-NAT) IP Range. The dynamic mapping is released once the flow is disconnected or gracefully terminated.

-> Site-to-site NAT is not supported with Site-to-site VPN connections where policy based traffic selectors are used.

- * **Type:** Static or Dynamic. Static one-to-one NAT establishes a one-to-one relationship between an internal address and an external address while Dynamic NAT assigns an IP and port based on availability.

- * **IP Configuration ID:** A NAT rule must be configured to a specific VPN Gateway instance. This is applicable to Dynamic NAT only. Static NAT rules are automatically applied to both VPN Gateway instances.

- * **Mode:** IngressSnat or EgressSnat.

- * IngressSnat mode (also known as Ingress Source NAT) is applicable to traffic entering the Azure hubΓÇÖs Site-to-site VPN gateway.

- * EgressSnat mode (also known as Egress Source NAT) is applicable to traffic leaving the Azure hubΓÇÖs Site-to-site VPN gateway.

- * **InternalMapping:** An address prefix range of source IPs on the inside network that will be mapped to a set of external IPs. In other words, your pre-NAT address prefix range.

- * **ExternalMapping:** An address prefix range of destination IPs on the outside network that source IPs will be mapped to. In other words, your post-NAT address prefix range.

- * **Link Connection:** Connection resource that virtually connects a VPN site to the Azure Virtual WAN Hub's Site-to-site VPN gateway.

-

-> If you want the Site-to-site VPN Gateway to advertise translated (**ExternalMapping**) address prefixes via BGP, click the **Enable BGP Translation** button, due to which on-premises will automatically learn the post-NAT range of Egress Rules and Azure (Virtual WAN Hub, connected Virtual Networks, VPN and ExpressRoute branches) will automatically learn the post-NAT range of Ingress rules. The new POST NAT ranges will be shown in the Effective Routes table in a Virtual Hub.

-> Please note that the **Enable Bgp Translation** setting is applied to all NAT rules on the Virtual WAN Hub Site-to-site VPN Gateway.

-### Ingress SNAT (BGP-Enabled VPN Site)

-**Ingress SNAT rules** are applied on packets that are entering Azure through the Virtual WAN Site-to-site VPN gateway. In this scenario, you want to connect two Site-to-site VPN branches to Azure. VPN Site 1 connects via Link A, and VPN Site 2 connects via Link B. Each site has the same address space 10.30.0.0/24.

-In this example, we will NAT site1 to 127.30.0.0.0/24. The Virtual WAN spoke Virtual Networks and branches other will automatically learn this post-NAT address space.

- Specify a NAT rule to ensure the Site-to-site VPN gateway is able to distinguish between the two branches with overlapping address spaces (such as 10.30.0.0/24). In this example, we focus on Link A for VPN Site 1.

- The following NAT rule can be set up and associated to Link A. Because this is a static NAT rule, the address spaces of the **InternalMapping** and **ExternalMapping** contain the same number of IP addresses.

- * **InternalMapping:** 10.30.0.0/24

- * **ExternalMapping:** 172.30.0.0/24

- 2. Toggle **BGP Route Translation** to 'Enable'.

- :::image type="content" source="./media/nat-rules-vpn-gateway/enable-bgp.png" alt-text="Screenshot showing how to enable BGP translation.":::

-3. Ensure the Site-to-site VPN Gateway is able to peer with the on-premises BGP peer.

- In this example, the **Ingress NAT Rule** will need to translate 10.30.0.132 to 127.30.0.132. In order to do that, click 'Edit VPN site' to configure VPN site Link A BGP address to reflect this translated BGP peer address (127.30.0.132).

-

-* If **BGP Translation** is enabled, the Site-to-site VPN Gateway will automatically advertise the **External Mapping** of **Egress NAT rules** to on-premises as well as **External Mapping** of **Ingress NAT rules** to Azure (Virtual WAN Hub, connected Spoke Virtual Networks, connected VPN/ExpresRoute). If **BGP Translation** is disabled, translated routes are not automatically advertised to the on-premises. As such, the on-premises BGP speaker must be configured to advertise the post-NAT (**ExternalMapping**) range of **Ingress NAT** rules associated to that VPN site link connection. Similarly, a route for the post-NAT (**ExternalMapping**) range of **Egress NAT Rules** must be applied on the on-premises device.

-* The Site-to-site VPN Gateway automatically translates the on-premises BGP peer IP address **if** the on-premises BGP peer IP address is contained within the **Internal Mapping** of an **Ingress NAT Rule**. As a result, the VPN site's **Link Connection BGP address** must reflect the NAT-translated address (part of the External Mapping).

- For instance, if the on-premises BGP IP address is 10.30.0.133 and there is an **Ingress NAT Rule** that translates 10.30.0.0/24 to 127.30.0.0/24, the VPN Site's **Link Connection BGP Address** must be configured to be the translated address (127.30.0.133).

-* In Dynamic NAT, on-premises BGP peer IP cannot be part of the pre-NAT address range (**Interal Mapping**) as IP and port translations are not fixed. If there is a need to translate the on-premises BGP peering IP, please create a separate **Static NAT Rule** that translates BGP Peering IP address only.

-

- For instance, if the on-premises network has an address space of 10.0.0.0/24 with an on-premise BGP peer IP of 10.0.0.1 and there is an **Ingress Dynamic NAT Rule** to translate 10.0.0.0/24 to 192.198.0.0/32, a separate **Ingress Static NAT Rule** translating 10.0.0.1/32 to 192.168.0.02/32 is required and the corresponding VPN site's **Link Connection BGP address** must be updated to the NAT-translated address (part of the External Mapping).

-

-**Ingress SNAT rules** are applied on packets that are entering Azure through the Virtual WAN Site-to-site VPN gateway. In this scenario, you want to connect two Site-to-site VPN branches to Azure. VPN Site 1 connects via Link A, and VPN Site 2 connects via Link B. Each site has the same address space 10.30.0.0/24.

-In this example, we will NAT VPN site 1 to 172.30.0.0.0/24. However, because the VPN Site is not connected to the Site-to-site VPN Gateway via BGP, the configuration steps are slightly different than the BGP-enabled example.

- Specify a NAT rule to ensure the Site-to-site VPN gateway is able to distinguish between the two branches with the same address space 10.30.0.0/24. In this example, we focus on Link A for VPN Site 1.

- The following NAT rule can be set up and associated to Link A of one of VPN site 1. Because this is a static NAT rule, the address spaces of the **InternalMapping** and **ExternalMapping** contain the same number of IP addresses.

- * **InternalMapping**: 10.30.0.0/24

- * **ExternalMapping**: 172.30.0.0/24

-2. Edit the 'Private Address space' field of VPN Site 1 to ensure the Site-to-site VPN Gateway learns the post-NAT range (172.30.0.0/24)

- * Navigate to the Virtual hub resource that contains the Site-to-site VPN gateway. On the virtual hub page, under Connectivity, select VPN (Site-to-site).

- * Select the VPN site that is connected to the Virtual WAN hub via Link A. Select Edit Site and input 172.30.0.0/24 as the private address space for the VPN site.

-* Edit the VPN site in Azure portal to add the prefixes in the **ExternalMapping** of **Ingress NAT Rules** in the 'Private Address Space' field.

-* For configurations involving **Egress NAT Rules**, a Route Policy or Static Route with the **ExternalMapping** of the **Egress NAT rule** needs to be applied on the on-premises device.

-In the preceding examples, an on-premises device wants to reach a resource in a Spoke Virtual Network. The packet flow is as follows, with the NAT translations in bold.

-1. Traffic enters Site-to-site gateway and is translated using the NAT rule and then sent to the Spoke.

-1. Traffic enters the Site-to-site VPN gateway and the translation is reversed and sent to on-premises.

-This section shows checks to verify that your configuration is set up properly.

- * Use Dynamic NAT Rules if the target address pool is smaller than the original address pool.

- * As IP/Port combinations are not fixed in a Dynamic NAT Rule, the on-premises BGP Peer IP cannot be part of the pre-NAT (**InternalMapping**) addres range. Please create a specific Static NAT Rule that translates the BGP Peering IP address only.

-

- For example:

-

- * **On-Premises Address Range:** 10.0.0.0/24

- * **On-premises BGP IP:** 10.0.0.1

- * **Ingress Dynamic NAT Rule:** 192.168.0.1/32

- * **Ingress Static NAT Rule:** 10.0.0.1 -> 192.168.0.2

-

-Branches in Virtual WAN associate to the **DefaultRouteTable**, implying all branch connections learn routes that are populated within the DefaultRouteTable. You will see the NAT rule with the translated prefix in the effective routes of the DefaultRouteTable.

-* **Prefix:** 172.30.0.0/24

-This example applies to resources in Virtual Networks that are associated to the DefaultRouteTable.

-The **Effective Routes** on the Network Interface Cards (NIC) of any virtual machine that is sitting in a Spoke Virtual Network connected to the Virtual WAN hub should also contain the address prefixes of the **ExternalMapping** specified in the **Ingress NAT rule** .

-The on-premises device should also contain routes for prefixes contained within the **External Mapping** of **Egress NAT Rules**.

-#### Common configuration patterns

-> Site-to-site NAT is not supported with Site-to-site VPN connections where policy based traffic selectors are used.

-The following table shows common configuration patterns that arise when configuring different types of NAT rules on the Site-to-site VPN Gateway.

-| Type of VPN Site | Ingress NAT Rules | Egress NAT Rules

-|VPN Site with Statically Configured Routes |Edit 'Private Address Space' in the VPN Site to contain the **ExternalMapping** of the NAT rule| Apply routes for the **ExternalMapping** of the NAT Rule on the on-premises device.|

-|VPN Site (BGP Translation Enabled)|Put the **ExternalMapping** address of the BGP peer in the VPN site Link Connection's BGP address. | No special considerations. |

-| VPN Site (BGP Translation Disabled) | Ensure the on-premises BGP Speaker advertises the prefixes in the **ExternalMapping** of the NAT Rule. Also put the ExternalMapping address of the BGP peer in the VPN site Link Connection's BGP address.| Apply routes for the **ExternalMapping** of the NAT rule on the on-premises device.|

-For more information about Site-to-site configurations, see [Configure a Virtual WAN Site-to-site connection](virtual-wan-site-to-site-portal.md).

-description: Learn how to create a Site-to-Site connection from your branch site to Azure Virtual WAN using PowerShell.

-# Create a Site-to-Site connection to Azure Virtual WAN using PowerShell

-This article shows you how to use Virtual WAN to connect to your resources in Azure over an IPsec/IKE (IKEv1 and IKEv2) VPN connection via PowerShell. This type of connection requires a VPN device located on-premises that has an externally facing public IP address assigned to it. For more information about Virtual WAN, see the [Virtual WAN Overview](virtual-wan-about.md).

-* Decide the IP address range that you want to use for your virtual hub private address space. This information is used when configuring your virtual hub. A virtual hub is a virtual network that is created and used by Virtual WAN. It's the core of your Virtual WAN network in a region. The address space range must conform the certain rules:

- * The address range that you specify for the hub can't overlap with any of the existing virtual networks that you connect to.

- * If you are unfamiliar with the IP address ranges located in your on-premises network configuration, coordinate with someone who can provide those details for you.

-Before you can create a virtual wan, you have to create a resource group to host the virtual wan or use an existing resource group. Create a resource group with [New-AzResourceGroup](/powershell/module/az.Resources/New-azResourceGroup). This example creates a new resource group named **testRG** in the **West US** location:

-Create a resource group:

-```azurepowershell-interactive

-New-AzResourceGroup -Location "West US" -Name "testRG"

-```

-Create the virtual wan:

-```azurepowershell-interactive

-$virtualWan = New-AzVirtualWan -ResourceGroupName testRG -Name myVirtualWAN -Location "West US"

-```

-1. Set the variables for the existing resource group

-A hub is a virtual network that can contain gateways for site-to-site, ExpressRoute, or point-to-site functionality. Create a virtual hub with [New-AzVirtualHub](/powershell/module/az.Network/New-AzVirtualHub). This example creates a default virtual hub named **westushub** with the specified address prefix and a location for the hub:

-```azurepowershell-interactive

-```

-In this section, you create a site-to-site VPN gateway that will be in the same location as the referenced VirtualHub. The site-to-site VPN gateway scales based on the scale unit specified and can take about 30 minutes to create.

-```azurepowershell-interactive

-New-AzVpnGateway -ResourceGroupName "testRG" -Name "testvpngw" -VirtualHubId $virtualHub.Id -VpnGatewayScaleUnit 2

-```

-Once your VPNgateway is created, you can view it using the following example.

-```azurepowershell-interactive

-Get-AzVpnGateway -ResourceGroupName "testRG" -Name "testvpngw"

-```

-## <a name="site"></a>Create a site and the connections

-In this section, you create sites that correspond to your physical locations and the connections. These sites contain your on-premises VPN device endpoints, you can create up to 1000 sites per virtual hub in a virtual WAN. If you have multiple hubs, you can create 1000 per each of those hubs.

-Set the variable for the vpnGateway and for the IP address space that is located on your on-premises site, traffic destined for this address space is routed to your local site. This is required when BGP is not enabled for the site:

-```azurepowershell-interactive

-$vpnGateway = Get-AzVpnGateway -ResourceGroupName "testRG" -Name "testvpngw"

-$vpnSiteAddressSpaces = New-Object string[] 2

-$vpnSiteAddressSpaces[0] = "192.168.2.0/24"

-$vpnSiteAddressSpaces[1] = "192.168.3.0/24"

-```

-Create Links to add information about the physical links at the branch including metadata about the link speed, link provider name and add the public IP address of the on-premise device.

-```azurepowershell-interactive

-$vpnSiteLink1 = New-AzVpnSiteLink -Name "testVpnSiteLink1" -IpAddress "15.25.35.45" -LinkProviderName "SomeTelecomProvider" -LinkSpeedInMbps "10"

-$vpnSiteLink2 = New-AzVpnSiteLink -Name "testVpnSiteLink2" -IpAddress "15.25.35.55" -LinkProviderName "SomeTelecomProvider2" -LinkSpeedInMbps "100"

-```

-Create the vpnSite and reference the variables of the vpnSiteLinks just created:

-```azurepowershell-interactive

-$vpnSite = New-AzVpnSite -ResourceGroupName "testRG" -Name "testVpnSite" -Location "West US" -VirtualWan $virtualWan -AddressSpace $vpnSiteAddressSpaces -DeviceModel "SomeDevice" -DeviceVendor "SomeDeviceVendor" -VpnSiteLink @($vpnSiteLink1, $vpnSiteLink2)

-```

-Next is the Vpn Site Link connection which is composed of 2 Active-Active tunnels from a branch/Site known as VPNSite to the scalable gateway:

-```azurepowershell-interactive

-$vpnSiteLinkConnection1 = New-AzVpnSiteLinkConnection -Name "testLinkConnection1" -VpnSiteLink $vpnSite.VpnSiteLinks[0] -ConnectionBandwidth 100

-$vpnSiteLinkConnection2 = New-AzVpnSiteLinkConnection -Name "testLinkConnection2" -VpnSiteLink $vpnSite.VpnSiteLinks[1] -ConnectionBandwidth 10

-```

-Finally, you connect your VPN site to the hub Site-to-Site VPN gateway:

-1. Declare the variables

-1. Delete all gateway entities following the below order for the VPN gateway. This can take 30 minutes to complete.

- Delete the VPN Gateway connection to the VPN Sites.

-

- ```azurepowershell-interactive

- Remove-AzVpnConnection -ResourceGroupName $vpnGateway.ResourceGroupName -ParentResourceName $vpnGateway.Name -Name "testConnection"

- ```

- Delete the VPN Gateway.

- Note that deleting a VPN Gateway will also remove all VPN Express Route Connections associated with it.

-

- ```azurepowershell-interactive

- Remove-AzVpnGateway -ResourceGroupName "testRG" -Name "testvpngw"

- ```

-1. You can delete the Resource Group to delete all the other resources in the resource group, including the hubs, sites and the virtual WAN.

- ```azurepowershell-interactive

- Remove-AzResourceGroup -Name "testRG"

- ```

-1. Or you can choose to delete each of the resources in the Resource Group

- Delete the VPN site

-

- ```azurepowershell-interactive

- Remove-AzVpnSite -ResourceGroupName "testRG" -Name "testVpnSite"

- ```

-

- Delete the Virtual Hub

-

- ```azurepowershell-interactive

- Remove-AzVirtualHub -ResourceGroupName "testRG" -Name "westushub"

- ```

-

- Delete the Virtual WAN

-

- ```azurepowershell-interactive

- Remove-AzVirtualWan -Name "MyVirtualWan" -ResourceGroupName "testRG"

- ```

-## Next steps

-Next, to learn more about Virtual WAN, see:

-> [!div class="nextstepaction"]

-> * [Virtual WAN FAQ](virtual-wan-faq.md)

-description: Learn how to configure custom IPsec policy for Azure Virtual WAN using the portal.

-# Configure a Point-to-Site User VPN connection - Azure Active Directory authentication

-This article shows you how to configure Azure AD authentication for User VPN in Virtual WAN to connect to your resources in Azure over an OpenVPN VPN connection. Azure Active Directory authentication is only available for gateways using the OpenVPN protocol. For more information about Virtual WAN, see the [Virtual WAN Overview](virtual-wan-about.md).

-Verify that you have met the following criteria before beginning your configuration:

-* Your virtual network does not have any virtual network gateways. If your virtual network has a gateway (either VPN or ExpressRoute), you must remove all gateways. This configuration requires that virtual networks are connected instead, to the Virtual WAN hub gateway.

-* Obtain an IP address range for your hub region. The hub is a virtual network that is created and used by Virtual WAN. The address range that you specify for the hub cannot overlap with any of your existing virtual networks that you connect to. It also cannot overlap with your address ranges that you connect to on premises. If you are unfamiliar with the IP address ranges located in your on-premises network configuration, coordinate with someone who can provide those details for you.

-A User VPN configuration defines the parameters for connecting remote clients. It is important to create the User VPN configuration before configuring your virtual hub with P2S settings, as you must specify the User VPN configuration you want to use.

- * **Audience** - Type in the Application ID of the [Azure VPN](openvpn-azure-ad-tenant.md) Enterprise Application registered in your Azure AD tenant.

-1. Click **Create** to create the User VPN configuration. You will select this configuration later in the exercise.

-For this exercise, we create an empty virtual hub. In the next section, you add a gateway to an already existing hub. However, it is also possible to combine these steps and create the hub with the P2S gateway settings all at once.

-# Tutorial: Create a User VPN connection using Azure Virtual WAN

-This tutorial shows you how to use Virtual WAN to connect to your resources in Azure over an OpenVPN or IPsec/IKE (IKEv2) VPN connection using a User VPN (P2S) configuration. This type of connection requires the native VPN client to be configured on each connecting client computer.

-* If you want to create a User VPN connection using Azure AD authentication, use the [Configure a User VPN connection - Azure Active Directory authentication](virtual-wan-point-to-site-azure-ad.md) article instead.

-* **Azure Active Directory authentication:** Use the [Configure a User VPN connection - Azure Active Directory authentication](virtual-wan-point-to-site-azure-ad.md) article, which contains the specific steps necessary for this configuration.

-When you connect to VNet using User VPN (P2S), you use the VPN client that is natively installed on the operating system from which you are connecting. All of the necessary configuration settings for the VPN clients are contained in a VPN client configuration zip file. The settings in the zip file help you easily configure the VPN clients. The VPN client configuration files that you generate are specific to the User VPN configuration for your gateway. In this section, you generate and download the files used to configure your VPN clients.

-In this section, you create a connection between your virtual hub and your VNet. For this tutorial, you do not need to configure the routing settings.

-description: In this tutorial, learn how to use Azure Virtual WAN to create a User VPN (point-to-site) connection to Azure using PowerShell

-# Tutorial: Create a User VPN connection to Azure Virtual WAN using PowerShell

-This tutorial shows you how to use Virtual WAN to connect to your resources in Azure over an OpenVPN or IPsec/IKE (IKEv2) VPN connection using a User VPN (P2S) configuration using PowerShell. This type of connection requires the native VPN client to be configured on each connecting client computer.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Create a virtual WAN

-> * Create the User VPN configuration

-> * Create the virtual hub and gateway

-> * Generate client configuration files

-> * Configure VPN clients

-> * Connect to a VNet

-> * Clean up resources

-Before you can create a virtual wan, you have to create a resource group to host the virtual wan or use an existing resource group. Create a resource group with [New-AzResourceGroup](/powershell/module/az.Resources/New-azResourceGroup). This example creates a new resource group named **testRG** in the **West US** location:

-Create a resource group:

-```azurepowershell-interactive

-New-AzResourceGroup -Location "West US" -Name "testRG"

-```

-Create the virtual wan:

-```azurepowershell-interactive

-$virtualWan = New-AzVirtualWan -ResourceGroupName testRG -Name myVirtualWAN -Location "West US"

-```

-The User VPN (P2S) configuration defines the parameters for remote clients to connect depending on the authentication method you want to use. When selecting the authentication method, there are three methods available with each method having its specific requirements.

-* **Azure certificates:** For this configuration, certificates are required. You need to either generate or obtain certificates. A client certificate is required for each client. Additionally, the root certificate information (public key) needs to be uploaded. For more information about the required certificates, see [Generate and export certificates](certificates-point-to-site.md).

-* **Azure Active Directory authentication:** Use the [Configure a User VPN connection - Azure Active Directory authentication](virtual-wan-point-to-site-azure-ad.md) article, which contains the specific steps necessary for this configuration.

-User VPN (point-to-site) connections can use certificates to authenticate. To create a self-signed root certificate and generate client certificates using PowerShell on Windows 10 or Windows Server 2016, see [Generate and export certificates](certificates-point-to-site.md).

-Once you have generated and exported the self-signed root certificate, you need to reference the location of the stored certificate. If using Cloud Shell on the Azure portal, you would need to upload the certificate first.

-```azurepowershell-interactive

-$VpnServerConfigCertFilePath = Join-Path -Path /home/name -ChildPath "\P2SRootCert1.cer"

-$listOfCerts = New-Object "System.Collections.Generic.List[String]"

-$listOfCerts.Add($VpnServerConfigCertFilePath)

-```

-Next is to create the User VPN Server Configuration. For the VPN Protocol, you can choose IKEv2 VPN, OpenVPN, and OpenVpn and IKEv2 depending on your requirements.

-```azurepowershell-interactive

-New-AzVpnServerConfiguration -Name testconfig -ResourceGroupName testRG -VpnProtocol IkeV2 -VpnAuthenticationType Certificate -VpnClientRootCertificateFilesList $listOfCerts -VpnClientRevokedCertificateFilesList $listOfCerts -Location westus

-```

-## <a name="hub"></a>Create the hub and Point-to-Site Gateway

-```azurepowershell-interactive

-New-AzVirtualHub -VirtualWan $virtualWan -ResourceGroupName "testRG" -Name "westushub" -AddressPrefix "10.11.0.0/24" -Location "westus"

-```

-Next you declare the variables for the existing resources and also specify the Client address pool from which IP addresses will be automatically assigned to VPN clients.

-```azurepowershell-interactive

-$virtualHub = Get-AzVirtualHub -ResourceGroupName testRG -Name westushub

-$vpnServerConfig = Get-AzVpnServerConfiguration -ResourceGroupName testRG -Name testconfig

-$vpnClientAddressSpaces = New-Object string[] 1

-$vpnClientAddressSpaces[0] = "192.168.2.0/24"

-```

-For the Point-to-Site Gateway, you need to specify the Gateway scale units and also reference the User VPN Server Configuration created earlier. Creating a Point-to-Site Gateway can take 30 minutes or more to complete

-```azurepowershell-interactive

-$P2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName testRG -Name p2svpngw -VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig -EnableInternetSecurityFlag -EnableRoutingPreferenceInternetFlag

-```

-When you connect to VNet using User VPN (P2S), you use the VPN client that is natively installed on the operating system from which you are connecting. All of the necessary configuration settings for the VPN clients are contained in a VPN client configuration zip file. The settings in the zip file help you easily configure the VPN clients. The VPN client configuration files that you generate are specific to the User VPN configuration for your gateway. In this section, you run the script to get the profile URL to generate and download the files used to configure your VPN clients.

-```azurepowershell-interactive

-```

-First the declare a variable to get the already existing Virtual network

-```azurepowershell-interactive

-$remoteVirtualNetwork = Get-AzVirtualNetwork -Name "testRGvnet" -ResourceGroupName "testRG"

-```

-Then you create a connection between your virtual hub and your VNet.

-

-```azurepowershell-interactive

-New-AzVirtualHubVnetConnection -ResourceGroupName "testRG" -VirtualHubName "westushub" -Name "testvnetconnection" -RemoteVirtualNetwork $remoteVirtualNetwork

-```

-1. Delete the gateway entities following the below order for the Point-to-Site VPN configuration. This can take up to 30 minutes to complete.

- Delete the Point-to-Site VPN Gateway

-

- ```azurepowershell-interactive

- Remove-AzP2sVpnGateway -Name "p2svpngw" -ResourceGroupName "testRG"

- ```

- Delete the User VPN Server configuration

-

- ```azurepowershell-interactive

- Remove-AzVpnServerConfiguration -Name "testconfig" -ResourceGroupName "testRG"

- ```

-1. You can delete the Resource Group to delete all the other resources in the resource group, including the hubs, sites and the virtual WAN.

- ```azurepowershell-interactive

- Remove-AzResourceGroup -Name "testRG"

- ```

-1. Or you can choose to delete each of the resources in the Resource Group

-

- Delete the Virtual Hub

-

- ```azurepowershell-interactive

- Remove-AzVirtualHub -ResourceGroupName "testRG" -Name "westushub"

- ```

-

- Delete the Virtual WAN

-

- ```azurepowershell-interactive

- Remove-AzVirtualWan -Name "MyVirtualWan" -ResourceGroupName "testRG"

-## Next steps

-Next, to learn more about Virtual WAN, see:

-> [!div class="nextstepaction"]

-> * [Virtual WAN FAQ](virtual-wan-faq.md)

-description: Learn how to use Azure Virtual WAN to create a Site-to-Site VPN connection to Azure.

-# Tutorial: Create a Site-to-Site connection using Azure Virtual WAN