-1. Add a `Predicates` element as a child of `BuildingBlocks` section by using the following code:

-1. Add a `PredicateValidations` element as a child of `BuildingBlocks` section by using the following code:

- * If the issue persists after verifying the previous steps, try restarting the *Microsoft Entra ID Sync Service*. From your Microsoft Entra Connect server, open a command prompt, then run the following commands:

-Office apps with modern authentication enabled send '*prompt=login*' to Microsoft Entra ID in their request. By default, Microsoft Entra ID translates '*prompt=login*' in the request to AD FS as '*wauth=usernamepassworduri*' (asks AD FS to do U/P Auth) and '*wfresh=0*' (asks AD FS to ignore SSO state and do a fresh authentication). If you want to enable certificate-based authentication for these apps, you need to modify the default Microsoft Entra behavior. Set the '*PromptLoginBehavior*' in your federated domain settings to '*Disabled*'.

-You can use the [MSOLDomainFederationSettings](/powershell/module/msonline/set-msoldomainfederationsettings) cmdlet to perform this task:

-Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled

-| Password | Yes | |

-To retrieve all user objects that have the value 'bob@contoso.com' in certificateUserIds:

-GET https://graph.microsoft.com/v1.0/users?$filter=authorizationInfo/certificateUserIds/any(x:x eq 'bob@contoso.com')&$count=true

-PATCH https://graph.microsoft.com/v1.0/users/{id}

-¹Security key biometrics or PIN for user verficiation isn't currently supported on Android by Google. Microsoft Entra ID requires user verification for all FIDO2 authentications.

-> If you enabled Microsoft Authenticator passwordless sign-in using Azure AD PowerShell, it was enabled for your entire directory. If you enable using this new method, it supersedes the PowerShell policy. We recommend you enable for all users in your tenant via the new **Authentication Methods** menu, otherwise users who aren't in the new policy can't sign in without a password.

- - **Reset Password** resets the user's password and assigns a temporary password that must be changed on the next sign-in.

- - **Require Re-register MFA** deactivates the user's hardware OATH tokens and deletes the following authentication methods from this user: phone numbers, Microsoft Authenticator apps and software OATH tokens. If needed, the user is requested to set up a new MFA authentication method the next time they sign in.

- - **Revoke MFA Sessions** clears the user's remembered MFA sessions and requires them to perform MFA the next time it's required by the policy on the device.

-

- :::image type="content" source="media/howto-mfa-userdevicesettings/manage-authentication-methods-in-azure.png" alt-text="Manage authentication methods from the Microsoft Entra admin center":::

-## Delete users' existing app passwords

-For users that have defined app passwords, administrators can also choose to delete these passwords, causing legacy authentication to fail in those applications. These actions may be necessary if you need to provide assistance to a user, or need to reset their authentication methods. Non-browser apps that were associated with these app passwords will stop working until a new app password is created.

-To delete a user's app passwords, complete the following steps:

-1. Look for the *Microsoft Entra ID Sync* entry.

-App protection policies apply mobile application management (MAM) to specific applications on a device. These policies allow for securing data within an application in support of scenarios like bring your own device (BYOD). In the preview, we support applying policy to the Microsoft Edge browser on Windows 11 devices.

-Customers interested in the public preview need to opt in using the [MAM for Windows Public Preview Sign Up Form](https://aka.ms/MAMforWindowsPublic).

-The following steps help create a Conditional Access policy requiring an app protection policy when using a Windows device. The app protection policy must also be configured and assigned to your users in Microsoft Intune. For more information about how to create the app protection policy, see the article [Preview: App protection policy settings for Windows](/mem/intune/apps/app-protection-policy-settings-windows). The following policy includes multiple controls allowing devices to either use app protection policies for mobile application management (MAM) or be managed and compliant with mobile device management (MDM) policies.

- 1. **Device platforms**, set **Configure** to **Yes**.

- 1. **Client apps**, set **Configure** to **Yes**.

-After selecting **OK**, you may see a progress window while policy is applied. After a few moments, you should see a window saying "you're all set", app protection policies are applied.

-If there's a pre-existing, unregistered account, like `user@contoso.com` in Microsoft Edge, or if a user signs in without registering using the Heads Up Page, then the account isn't properly enrolled in MAM. This configuration blocks the user from being properly enrolled in MAM. This is a known issue.

-1. Configure the [SSO app extension](/mem/intune/configuration/device-features-configure#single-sign-on-app-extension) settings of a configuration profile.

-### Migrate tenant restrictions v1 policies to v2

-When using tenant restrictions v2 to manage access for your Windows device users, we recommend also configuring your corporate proxy to enforce tenant restrictions v2 to manage other devices and apps in your corporate network. Although configuring tenant restrictions on your corporate proxy doesn't provide data plane protection, it provides authentication plane protection. For details, see [Set up tenant restrictions v2 on your corporate proxy](#option-2-set-up-tenant-restrictions-v2-on-your-corporate-proxy).

-Tenant restrictions v2 policies can't be directly enforced on non-Windows 10, Windows 11, or Windows Server 2022 devices, such as Mac computers, mobile devices, unsupported Windows applications, and Chrome browsers. To ensure sign-ins are restricted on all devices and apps in your corporate network, configure your corporate proxy to enforce tenant restrictions v2. Although configuring tenant restrictions on your corporate proxy don't provide data plane protection, it does provide authentication plane protection.

-These settings are configured by the [Azure AD PowerShell module](/previous-versions/azure/jj151815(v=azure.100)). Download and install it separately from Microsoft Entra Connect. The cmdlets documented in this topic were introduced in the [2016 March release (build 9031.1)](https://social.technet.microsoft.com/wiki/contents/articles/28552.microsoft-azure-active-directory-powershell-module-version-release-history.aspx#Version_9031_1). If you do not have the cmdlets documented in this topic or they do not produce the same result, then make sure you run the latest version.

-To see the configuration in your Microsoft Entra directory using the Graph Powershell, use the following commands:

-Get-MgDirectoryOnPremisSynchronization | Select-Object -ExpandProperty Features | Format-List

-After you have enabled a feature, it cannot be disabled again.

-The following settings are configured by Microsoft Entra Connect and cannot be modified by `Set-MsolDirSyncFeature`:

-| [DuplicateProxyAddressResiliency<br/>DuplicateUPNResiliency](#duplicate-attribute-resiliency) |Allows an attribute to be quarantined when it is a duplicate of another object rather than failing the entire object during export. |

-If you need to match on-premises AD accounts with existing accounts created in the cloud and you are not using Exchange Online, then this feature is useful. In this scenario, you generally donΓÇÖt have a reason to set the SMTP attribute in the cloud.

-## Using the Graph Powershell module

-If this feature is not enabled for your Microsoft Entra directory, then you can enable it by running:

-When this feature is enabled it will block the Soft Match feature. Customers are encouraged to enable this feature and keep it at enabled until Soft Matching is required again for their tenancy. This flag should be enabled again after any soft matching has completed and is no longer needed.

-* The user has not been assigned a license.

-## Using the Graph Powershell module

-If this feature is not enabled for your Microsoft Entra directory, then you can enable it by running:

-## June 2023

-### Updated articles

-Contact Hypervault support to configure Hypervault to support provisioning with Microsoft Entra ID.

-This section guides you through the steps to configure the Microsoft Entra provisioning service to create, update, and disable users in TestApp based on user assignments in Microsoft Entra ID.

-1. Under the **Admin Credentials** section, input your Hypervault Tenant URL and Secret Token. Click **Test Connection** to ensure Microsoft Entra ID can connect to Hypervault. If the connection fails, ensure your Hypervault account has Admin permissions and try again.

-² Version `0314` of gpt-4 and gpt-4-32k will be retired no earlier than July 5, 2024. See [model updates](#model-updates) for model upgrade behavior.<br>

-¹ Version `0301` of gpt-35-turbo will be retired no earlier than July 5, 2024. See [model updates](#model-updates) for model upgrade behavior.

-## Working with models

-### Finding what models are available

-You can get a list of models that are available for both inference and fine-tuning by your Azure OpenAI resource by using the [Models List API](/rest/api/cognitiveservices/azureopenaistable/models/list).

-### Model updates

-Azure OpenAI now supports automatic updates for select model deployments. On models where automatic update support is available, a model version drop-down will be visible in Azure OpenAI Studio under **Create new deployment** and **Edit deployment**:

-### Auto update to default

-When **Auto-update to default** is selected your model deployment will be automatically updated within two weeks of a change in the default version.

-If you are still in the early testing phases for inference models, we recommend deploying models with **auto-update to default** set whenever it is available.

-### Specific model version

-As your use of Azure OpenAI evolves, and you start to build and integrate with applications you may want to manually control model updates so that you can first test and validate that model performance is remaining consistent for your use case prior to upgrade.

-When you select a specific model version for a deployment this version will remain selected until you either choose to manually update yourself, or once you reach the retirement date for the model. When the retirement date is reached the model will auto-upgrade to the default version at the time of retirement.

-### GPT-35-Turbo 0301 and GPT-4 0314 retirement

-The `gpt-35-turbo` (`0301`) and both `gpt-4` (`0314`) models will be retired no earlier than July 5, 2024. Upon retirement, deployments will automatically be upgraded to the default version at the time of retirement. If you would like your deployment to stop accepting completion requests rather than upgrading, then you will be able to set the model upgrade option to expire through the API. We will publish guidelines on this by September 1.

-### Viewing deprecation dates

-For currently deployed models, from Azure OpenAI Studio select **Deployments**:

-To view deprecation/expiration dates for all available models in a given region from Azure OpenAI Studio select **Models** > **Column options** > Select **Deprecation fine tune** and **Deprecation inference**:

-### Model deployment upgrade configuration

-There are three distinct model deployment upgrade options which are configurable via REST API:

-| Name | Description |

-||--|

-| `OnceNewDefaultVersionAvailable` | Once a new version is designated as the default, the model deployment will auto-upgrade to the default version within two weeks of that designation change being made. |

-`OnceCurrentVersionExpired` | Once the retirement date is reached the model deployment will auto-upgrade to the current default version. |

-`NoAutoUpgrade` | The model deployment will never auto-upgrade. Once the retirement date is reached the model deployment will stop working. You will need to update your code referencing that deployment to point to a non-expired model deployment. |

-To query the current model deployment settings including the deployment upgrade configuration for a given resource use [`Deployments List`](/rest/api/cognitiveservices/accountmanagement/deployments/list?tabs=HTTP#code-try-0)

-```http

-GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/deployments?api-version=2023-05-01

-```

-**Path parameters**

-| Parameter | Type | Required? | Description |

-|--|--|--|--|

-| ```acountname``` | string | Required | The name of your Azure OpenAI Resource. |

-| ```resourceGroupName``` | string | Required | The name of the associated resource group for this model deployment. |

-| ```subscriptionId``` | string | Required | Subscription ID for the associated subscription. |

-| ```api-version``` | string | Required |The API version to use for this operation. This follows the YYYY-MM-DD format. |

-**Supported versions**

-### Example response

-```json

-{

- "id": "/subscriptions/{Subcription-GUID}/resourceGroups/{Resource-Group-Name}/providers/Microsoft.CognitiveServices/accounts/{Resource-Name}/deployments/text-davinci-003",

- "type": "Microsoft.CognitiveServices/accounts/deployments",

- "name": "text-davinci-003",

- "sku": {

- "name": "Standard",

- "capacity": 60

- },

- "properties": {

- "model": {

- "format": "OpenAI",

- "name": "text-davinci-003",

- "version": "1"

- },

- "versionUpgradeOption": "OnceNewDefaultVersionAvailable",

- "capabilities": {

- "completion": "true",

- "search": "true"

- },

- "raiPolicyName": "Microsoft.Default",

- "provisioningState": "Succeeded",

- "rateLimits": [

- {

- "key": "request",

- "renewalPeriod": 10,

- "count": 60

- },

- {

- "key": "token",

- "renewalPeriod": 60,

- "count": 60000

- }

- ]

- }

-```

-You can then take the settings from this list to construct an update model REST API call as described below if you want to modify the deployment upgrade configuration.

-### Update & deploy models via the API

-```http

-PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/deployments/{deploymentName}?api-version=2023-05-01

-```

-**Path parameters**

-| Parameter | Type | Required? | Description |

-|--|--|--|--|

-| ```acountname``` | string | Required | The name of your Azure OpenAI Resource. |

-| ```deploymentName``` | string | Required | The deployment name you chose when you deployed an existing model or the name you would like a new model deployment to have. |

-| ```resourceGroupName``` | string | Required | The name of the associated resource group for this model deployment. |

-| ```subscriptionId``` | string | Required | Subscription ID for the associated subscription. |

-| ```api-version``` | string | Required |The API version to use for this operation. This follows the YYYY-MM-DD format. |

-**Supported versions**

-**Request body**

-This is only a subset of the available request body parameters. For the full list of the parameters, you can refer to the [REST API reference documentation](/rest/api/cognitiveservices/accountmanagement/deployments/create-or-update).

-|Parameter|Type| Description |

-|--|--|--|

-|versionUpgradeOption | String | Deployment model version upgrade options:<br>`OnceNewDefaultVersionAvailable`<br>`OnceCurrentVersionExpired`<br>`NoAutoUpgrade`|

-|capacity|integer|This represents the amount of [quota](../how-to/quota.md) you are assigning to this deployment. A value of 1 equals 1,000 Tokens per Minute (TPM)|

-#### Example request

-```Bash

-curl -X PUT https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resource-group-temp/providers/Microsoft.CognitiveServices/accounts/docs-openai-test-001/deployments/text-embedding-ada-002-test-1?api-version=2023-05-01 \

- -H "Content-Type: application/json" \

- -H 'Authorization: Bearer YOUR_AUTH_TOKEN' \

- -d '{"sku":{"name":"Standard","capacity":1},"properties": {"model": {"format": "OpenAI","name": "text-embedding-ada-002","version": "2"},"versionUpgradeOption":"OnceCurrentVersionExpired"}}'

-```

-> [!NOTE]

-> There are multiple ways to generate an authorization token. The easiest method for initial testing is to launch the Cloud Shell from the [Azure portal](https://portal.azure.com). Then run [`az account get-access-token`](/cli/azure/account?view=azure-cli-latest#az-account-get-access-token&preserve-view=true). You can use this token as your temporary authorization token for API testing.

-#### Example response

-```json

-{

- "id": "/subscriptions/{subscription-id}/resourceGroups/resource-group-temp/providers/Microsoft.CognitiveServices/accounts/docs-openai-test-001/deployments/text-embedding-ada-002-test-1",

- "type": "Microsoft.CognitiveServices/accounts/deployments",

- "name": "text-embedding-ada-002-test-1",

- "sku": {

- "name": "Standard",

- "capacity": 1

- },

- "properties": {

- "model": {

- "format": "OpenAI",

- "name": "text-embedding-ada-002",

- "version": "2"

- },

- "versionUpgradeOption": "OnceCurrentVersionExpired",

- "capabilities": {

- "embeddings": "true",

- "embeddingsMaxInputs": "1"

- },

- "provisioningState": "Succeeded",

- "ratelimits": [

- {

- "key": "request",

- "renewalPeriod": 10,

- "count": 2

- },

- {

- "key": "token",

- "renewalPeriod": 60,

- "count": 1000

- }

- ]

- },

- "systemData": {

- "createdBy": "docs@contoso.com",

- "createdByType": "User",

- "createdAt": "2023-06-13T00:12:38.885937Z",

- "lastModifiedBy": "docs@contoso.com",

- "lastModifiedByType": "User",

- "lastModifiedAt": "2023-06-13T02:41:04.8410965Z"

- },

- "etag": "\"{GUID}\""

-}

-```

- - Your chat model can use version `gpt-35-turbo (0301)`, `gpt-35-turbo-16k`, `gpt-4`, and `gpt-4-32k`. You can view or change your model version in [Azure OpenAI Studio](./concepts/models.md#model-updates).

-The following [text to speech](text-to-speech.md) locales and voices are available out of box. We welcome your input to help us gauge demand for additional languages and voices. Check the full text to speech language and voice list [here](language-support.md?tabs=tts).

-| Locale (BCP-47) | Language | Text to speech voices |

-| -- | -- | -- |

-| `de-DE` | German (Germany) | `de-DE-KatjaNeural` (Female)<br/>`de-DE-ConradNeural` (Male)|

-| `en-AU` | English (Australia) | `en-AU-AnnetteNeural` (Female)<br/>`en-AU-WilliamNeural` (Male)|

-| `en-CA` | English (Canada) | `en-CA-ClaraNeural` (Female)<br/>`en-CA-LiamNeural` (Male)|

-| `en-GB` | English (United Kingdom) | `en-GB-LibbyNeural` (Female)<br/>`en-GB-RyanNeural` (Male)|

-| `en-US` | English (United States) | `en-US-AriaNeural` (Female)<br/>`en-US-GuyNeural` (Male)<br/>`en-US-JennyNeural` (Female)|

-| `es-ES` | Spanish (Spain) | `es-ES-ElviraNeural` (Female)<br/>`es-ES-AlvaroNeural` (Male)|

-| `es-MX` | Spanish (Mexico) | `es-MX-DaliaNeural` (Female)<br/>`es-MX-JorgeNeural` (Male)|

-| `fr-CA` | French (Canada) | `fr-CA-SylvieNeural` (Female)<br/>`fr-CA-JeanNeural` (Male)|

-| `fr-FR` | French (France) | `fr-FR-DeniseNeural` (Female)<br/>`fr-FR-HenriNeural` (Male)|

-| `it-IT` | Italian (Italy) | `it-IT-IsabellaNeural` (Female)<br/>`it-IT-DiegoNeural` (Male)|

-| `ja-JP` | Japanese (Japan) | `ja-JP-NanamiNeural` (Female)<br/>`ja-JP-KeitaNeural` (Male)|

-| `ko-KR` | Korean (Korea) | `ko-KR-SunHiNeural` (Female)<br/>`ko-KR-InJoonNeural` (Male)|

-| `pt-BR` | Portuguese (Brazil) | `pt-BR-FranciscaNeural` (Female)<br/>`pt-BR-AntonioNeural` (Male)|

-| `zh-CN` | Chinese (Mandarin, Simplified) | `zh-CN-XiaoxiaoNeural` (Female)<br/>`zh-CN-YunxiNeural` (Male)|

-| Role | Can list resource keys | Access to data, models, and endpoints|

-| | | |

-|**Owner** |Yes |View, create, edit, and delete |

-|**Contributor** |Yes |View, create, edit, and delete |

-|**Cognitive Services Contributor** |Yes |View, create, edit, and delete |

-|**Cognitive Services User** |Yes |View, create, edit, and delete |

-|**Cognitive Services Speech Contributor** |No | View, create, edit, and delete |

-|**Cognitive Services Speech User** |No |View only |

-|**Cognitive Services Data Reader (Preview)** |No |View only |

-| `{MODEL_PATH}` | The path where the model is located.<br/><br/>For example: `/path/to/model/` |

-| `{MODEL_PATH}` | The path where the model is located.<br/><br/>For example: `/path/to/model/` |

-### Mount file share as an inline volume

-> [!NOTE]

-> Inline volume can only access secrets in the same namespace as the pod. To specify a different secret namespace, instead use the [persistent volume example][persistent-volume-example].

-To mount the Azure Files file share into your pod, you configure the volume in the container spec.

-1. Create a new file named `azure-files-pod.yaml` and copy in the following contents. If you changed the name of the file share or secret name, update the `shareName` and `secretName`. You can also update the `mountPath`, which is the path where the Files share is mounted in the pod. For Windows Server containers, specify a `mountPath` using the Windows path convention, such as *'D:'*.

-```yaml

-apiVersion: v1

-kind: Pod

-metadata:

- name: mypod

-spec:

- nodeSelector:

- kubernetes.io/os: linux

- containers:

- - image: 'mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine'

- name: mypod

- resources:

- requests:

- cpu: 100m

- memory: 128Mi

- limits:

- cpu: 250m

- memory: 256Mi

- volumeMounts:

- - name: azure

- mountPath: /mnt/azure

- volumes:

- - name: azure

- csi:

- driver: file.csi.azure.com

- readOnly: false

- volumeAttributes:

- secretName: azure-secret # required

- shareName: aksshare # required

- mountOptions: 'dir_mode=0777,file_mode=0777,cache=strict,actimeo=30,nosharesock' # optional

-```

-2. Create the pod using the [`kubectl apply`][kubectl-apply] command.

- ```bash

- kubectl apply -f azure-files-pod.yaml

- ```

- You now have a running pod with an Azure Files file share mounted at */mnt/azure*. You can verify the share is mounted successfully using the [`kubectl describe`][kubectl-describe] command.

- ```bash

- kubectl describe pod mypod

- ```

- - secretName: ingress-tls-csi

- type: kubernetes.io/tls

- data:

- - objectName: $CERT_NAME

- key: tls.key

- - objectName: $CERT_NAME

- key: tls.crt

- > If not using Azure Active Directory (Azure AD) pod-managed identity as your method of access, remove the line with `--set controller.podLabels.aadpodidbinding=$AAD_POD_IDENTITY_NAME`

-description: Learn how to update AKS nodes using GitHub Actions

-# Apply security updates to Azure Kubernetes Service (AKS) nodes automatically using GitHub Actions

-Running `az aks upgrade` gives you a zero downtime way to apply updates. The command handles applying the latest updates to all your cluster's nodes, cordoning and draining traffic to the nodes, and restarting the nodes, then allowing traffic to the updated nodes. If you update your nodes using a different method, AKS will not automatically restart your nodes.

-> The main difference between `az aks upgrade` when used with the `--node-image-only` flag is that, when it's used, only the node images will be upgraded. If omitted, both the node images and the Kubernetes control plane version will be upgraded. You can check [the docs for managed upgrades on nodes][managed-node-upgrades-article] and [the docs for cluster upgrades][cluster-upgrades-article] for more in-depth information.

-All Kubernetes' nodes run in a standard Azure virtual machine (VM). These VMs can be Windows or Linux-based. The Linux-based VMs use an Ubuntu image, with the OS configured to automatically check for updates every night.

-When you use the `az aks upgrade` command, Azure CLI creates a surge of new nodes with the latest security and kernel updates, these nodes are initially cordoned to prevent any apps from being scheduled to them until the update is finished. After completion, Azure cordons (makes the node unavailable for scheduling of new workloads) and drains (moves the existent workloads to other node) the older nodes and uncordon the new ones, effectively transferring all the scheduled applications to the new nodes.

-This process is better than updating Linux-based kernels manually because Linux requires a reboot when a new kernel update is installed. If you update the OS manually, you also need to reboot the VM, manually cordoning and draining all the apps.

-This article shows you how you can automate the update process of AKS nodes. You'll use GitHub Actions and Azure CLI to create an update task based on `cron` that runs automatically.

-Node image upgrades can also be performed automatically, and scheduled by using planned maintenance. For more details, see [Automatically upgrade node images][auto-upgrade-node-image].

-## Before you begin

-This article assumes that you have an existing AKS cluster. If you need an AKS cluster, see the AKS quickstart [using the Azure CLI][aks-quickstart-cli], [using Azure PowerShell][aks-quickstart-powershell], or [using the Azure portal][aks-quickstart-portal].

-You also need the Azure CLI version 2.0.59 or later installed and configured. Run `az --version` to find the version. If you need to install or upgrade, see [Install Azure CLI][install-azure-cli].

-This article also assumes you have a [GitHub][github] account to create your actions in.

-`cron` is a utility that allows you to run a set of commands, or job, on an automated schedule. To create job to update your AKS nodes on an automated schedule, you'll need a repository to host your actions. Usually, GitHub actions are configured in the same repository as your application, but you can use any repository. For this article we'll be using your [profile repository][profile-repository]. If you don't have one, create a new repository with the same name as your GitHub username.

-1. Navigate to your repository on GitHub

-2. Select the **Actions** tab at the top of the page.

-3. If you already set up a workflow in this repository, you'll be directed to the list of completed runs, in this case, select the **New Workflow** button. If this is your first workflow in the repository, GitHub will present you with some project templates, select the **Set up a workflow yourself** link below the description text.

-4. Change the workflow `name` and `on` tags similar to the below. GitHub Actions use the same [POSIX cron syntax][cron-syntax] as any Linux-based system. In this schedule, we're telling the workflow to run every 15 days at 3am.

-5. Create a new job using the below. This job is named `upgrade-node`, runs on an Ubuntu agent, and will connect to your Azure CLI account to execute the needed steps to upgrade the nodes.

- name: Upgrade cluster node images

- on:

- schedule:

- - cron: '0 3 */15 * *'

-In the `steps` key, you'll define all the work the workflow will execute to upgrade the nodes.

-Download and sign in to the Azure CLI.

-1. On the right-hand side of the GitHub Actions screen, find the *marketplace search bar* and type **"Azure Login"**.

-2. You'll get as a result, an Action called **Azure Login** published **by Azure**:

-3. Select **Azure Login**. On the next screen, select the **copy icon** in the top right of the code sample.

- :::image type="content" source="media/node-upgrade-github-actions/azure-login.png" alt-text="Azure Login action result pane with code sample below, red square around a copy icon highlights the select spot":::

-4. Paste the following under the `steps` key:

- uses: Azure/login@v1.4.3

-5. From the Azure CLI, run the following command to generate a new username and password.

- > This example creates the `Contributor` role at the *Subscription* scope. You may provide the role and scope that meets your needs. For more information, see [Azure built-in roles][azure-built-in-roles] and [Azure RBAC scope levels][azure-rbac-scope-levels].

- The output should be similar to the following json:

- "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",

- "clientSecret": "xXxXxXxXx",

- "subscriptionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

- "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

- "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",

- "resourceManagerEndpointUrl": "https://management.azure.com/",

- "activeDirectoryGraphResourceId": "https://graph.windows.net/",

- "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",

- "galleryEndpointUrl": "https://gallery.azure.com/",

- "managementEndpointUrl": "https://management.core.windows.net/"

-6. **In a new browser window** navigate to your GitHub repository and open the **Settings** tab of the repository. Select **Secrets** then, select **New Repository Secret**.

-7. For *Name*, use `AZURE_CREDENTIALS`.

-8. For *Value*, add the entire contents from the output of the previous step where you created a new username and password.

- :::image type="content" source="media/node-upgrade-github-actions/azure-credential-secret.png" alt-text="Form showing AZURE_CREDENTIALS as secret title, and the output of the executed command pasted as JSON":::

-9. Select **Add Secret**.

-The CLI used by your action will be logged to your Azure account and ready to run commands.

-To create the steps to execute Azure CLI commands.

-1. Navigate to the **search page** on *GitHub marketplace* on the right-hand side of the screen and search *Azure CLI Action*. Choose *Azure CLI Action by Azure*.

-1. Select the copy button on the *GitHub marketplace result* and paste the contents of the action in the main editor, below the *Azure Login* step, similar to the following:

- uses: Azure/login@v1.4.3

- uses: Azure/cli@v1.0.6

- > You can decouple the `-g` and `-n` parameters from the command by adding them to secrets similar to the previous steps. Replace the `{resourceGroupName}` and `{aksClusterName}` placeholders by their secret counterparts, for example `${{secrets.RESOURCE_GROUP_NAME}}` and `${{secrets.AKS_CLUSTER_NAME}}`

-1. Rename the file to `upgrade-node-images`.

-1. Select **Start Commit**, add a message title, and save the workflow.

-Once you create the commit, the workflow will be saved and ready for execution.

-> To upgrade a single node pool instead of all node pools on the cluster, add the `--name` parameter to the `az aks nodepool upgrade` command to specify the node pool name. For example:

-## Run the GitHub Action manually

-You can run the workflow manually, in addition to the scheduled run, by adding a new `on` trigger called `workflow_dispatch`. The finished file should look like the YAML below:

-```yml

-name: Upgrade cluster node images

-on:

- schedule:

- - cron: '0 3 */15 * *'

- workflow_dispatch:

-jobs:

- upgrade-node:

- runs-on: ubuntu-latest

- steps:

- - name: Azure Login

- uses: Azure/login@v1.4.3

- with:

- creds: ${{ secrets.AZURE_CREDENTIALS }}

- # Code for upgrading one or more node pools

-```

-[cron-syntax]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07

-[system-pools]: use-system-pools.md

-[spot-pools]: spot-node-pool.md

-[use-multiple-node-pools]: create-node-pools.md

-| Qatar Central | ✅ | ✅ | |

-* Learn how to [use Azure Policy to apply configurations at scale](./use-azure-policy.md).

-{

- ΓÇ£locationΓÇ¥: ΓÇ£SAME_REGION_AS_MACHINEΓÇ¥,

- ΓÇ£propertiesΓÇ¥: {

- ΓÇ£esuProfileΓÇ¥: {

- ΓÇ£assignedLicenseΓÇ¥: ΓÇ£RESOURCE_ID_OF_LICENSEΓÇ¥

- }

- }

- ΓÇ£locationΓÇ¥: ΓÇ£SAME_REGION_AS_MACHINEΓÇ¥,

- ΓÇ£propertiesΓÇ¥: {

- ΓÇ£esuProfileΓÇ¥: {

- ΓÇ£assignedLicenseΓÇ¥: ΓÇ£ΓÇ¥

-1. To create a new WS2012 license, select **Create ESUs license**, and then provide the information required to configure the license on the page.

-### Is my cache be available during scaling?

-> On 30 September 2026, the **[URL ping tests](/previous-versions/azure/azure-monitor/app/monitor-web-app-availability)** will be retired, and ping tests. Before that date, you'll need to transition to **[standard tests](/editor/availability-standard-tests.md)**.

-We recommend using these commands to migrate a URL ping test to a standard test and take advantage of the available capabilities. Remember, this migration is optional.

-The following types of authentication are supported by the `Opencensus` Azure Monitor exporters. We recommend using managed identities in production environments.

- :::image type="content" source="./media/azure-ad-authentication/enabled.png" alt-text="Screenshot that shows Properties under the Configure section and the Enabled (click to change) local authentication button.":::

- :::image type="content" source="./media/azure-ad-authentication/overview.png" alt-text="Screenshot that shows the Overview tab with the Disabled (click to change) local authentication button.":::

-Azure Policy for `DisableLocalAuth` will deny users the ability to create a new Application Insights resource without this property set to `true`. The policy name is `Application Insights components should block non-AAD auth ingestion`.

-When developing a custom client to obtain an access token from Azure AD for the purpose of submitting telemetry to Application Insights, refer to the table provided below to determine the appropriate audience string for your particular host environment.

-Please note that the audience parameter, AADAudience, may vary depending on your specific environment.

-The ingestion service will return specific errors, regardless of the SDK language. Network traffic can be collected by using a tool such as Fiddler. You should filter traffic to the ingestion endpoint set in the connection string.

-If Azure AD is enabled in the agent, outbound traffic will include the HTTP header `Authorization`.

- This scenario can occur if the application hasn't been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.

-With the upgraded offering of ContainerLogV2 becoming generally available, on 30th September 2026, the ContainerLog table will be retired. If you currently ingest container insights data to the ContainerLog table, please make sure to transition to using ContainerLogV2 prior to that date.

-3. Enable the ContainerLogV2 schema through either the container insights data collection rules (DCRs) or ConfigMap

-| Onboarding | Only configurable through the ConfigMap | Configurable through both the ConfigMap and DCR |

-If you are currently using ContainerLog in your alerts, then migrating to ContainerLogV2 will require updates to your alert queries for them to continue functioning as expected.

-* [Tenant deployments](deploy-to-tenant.md)

- $output = \'Hello {0}. The username is {1}, the password is {2}.\' -f $name,\${Env:UserName},\${Env:Password}

- $DeploymentScriptOutputs[\'text\'] = $output

-The supporting resources including the container instance can't be deployed to a private virtual network. To access a private virtual network from your deployment script, you can create another virtual network with a publicly accessible virtual machine or a container instance, and create a peering from this virtual network to the private virtual network.

-To ensure that Azure is compliant with regulatory requirements, and provide improved security for our customers, **Azure Resource Manager will stop supporting protocols older than TLS 1.2 on November 30, 2023.**

-The supporting resources including the container instance can't be deployed to a private virtual network. To access a private virtual network from your deployment script, you can create another virtual network with a publicly accessible virtual machine or a container instance, and create a peering from this virtual network to the private virtual network.

-> This integration is only supported in limited regions for Azure AI services, for more information about which regions are supported please view the limitations section at the bottom of this document. It is also recommended that when you're creating a new Azure Cognitive Service resource that you create a Multi-service Cognitive Service resource.

-| External name resolution | Be sure that all computers running the Communication Services SDKs can resolve external DNS queries to discover the services provided by communication servicers and that your firewalls aren't preventing access. Ensure that the SDKs can resolve the addresses *.skype.com, *.microsoft.com, *.azure.net, *.azureedge.net, *.office.com, and *.trouter.io. |

-description: Provides a how-to guide for playing audio to participants as part of a call.

-zone_pivot_groups: acs-csharp-java

-# Customize voice prompts to users with Play action using Text-to-Speech

->[!IMPORTANT]

->Functionality described on this document is currently in private preview. Private preview includes access to SDKs and documentation for testing purposes that are not yet available publicly.

->Apply to become an early adopter by filling out the form for [preview access to Azure Communication Services](https://aka.ms/acs-tap-invite).

-This guide will help you get started with playing audio to participants by using the play action provided through Azure Communication Services Call Automation SDK.

-## Event codes

-|Status|Code|Subcode|Message|

-|-|--|--|--|

-|PlayCompleted|200|0|Action completed successfully.|

-|PlayFailed|400|8535|Action failed, file format is invalid.|

-|PlayFailed|400|8536|Action failed, file could not be downloaded.|

-|PlayCanceled|400|8508|Action failed, the operation was canceled.|

-## Clean up resources

-If you want to clean up and remove a Communication Services subscription, you can delete the resource or resource group. Deleting the resource group also deletes any other resources associated with it. Learn more about [cleaning up resources](../../quickstarts/create-communication-resource.md#clean-up-resources).

-## Next steps

-description: Provides a how-to guide for gathering user voice input from participants on a call.

-zone_pivot_groups: acs-csharp-java

-# Gather user input with Recognize action and voice input

-This guide helps you get started recognizing user input in the forms of DTMF or voice input provided by participants through Azure Communication Services Call Automation SDK.

-## Event codes

-|Status|Code|Subcode|Message|

-|-|--|--|--|

-|RecognizeCompleted|200|8531|Action completed, max digits received.|

-|RecognizeCompleted|200|8533|Action completed, DTMF option matched.|

-|RecognizeCompleted|200|8545|Action completed, speech option matched.|

-|RecognizeCompleted|200|8514|Action completed as stop tone was detected.|

-|RecognizeCompleted|200|8569|Action completed, speech was recognized.|

-|RecognizeCompleted|400|8532|Action failed, inter-digit silence time out reached.|

-|RecognizeFailed|400|8563|Action failed, speech could not be recognized.|

-|RecognizeFailed|408|8570|Action failed, speech recognition timed out.|

-|RecognizeFailed|400|8510|Action failed, initial silence time out reached.|

-|RecognizeFailed|500|8511|Action failed, encountered failure while trying to play the prompt.|

-|RecognizeFailed|400|8547|Action failed, recognized phrase does not match a valid option.|

-|RecognizeFailed|500|8534|Action failed, incorrect tone entered.|

-|RecognizeFailed|500|9999|Unspecified error.|

-|RecognizeCanceled|400|8508|Action failed, the operation was canceled.|

-## Limitations

-## Clean up resources

-If you want to clean up and remove a Communication Services subscription, you can delete the resource or resource group. Deleting the resource group also deletes any other resources associated with it. Learn more about [cleaning up resources](../../quickstarts/create-communication-resource.md#clean-up-resources).

-## Next Steps

-This step is required for internal only container app environments as it allows your Application Gateway to communicate with your Container App on the backend through the virtual network.

- > ConnectionMode = ConnectionMode.Gateway

-> When you increase the RU/s of a database or container, this can impact the minimum RU/s you can lower to in the future. Typically, the minimum RU/s is equal to MAX(400 RU/s, Current storage in GB * 10 RU/s, Highest RU/s ever provisioned / 100). For example, if the highest RU/s you've ever scaled to is 100,000 RU/s, the lowest RU/s you can set in the future is 1000 RU/s. Learn more about [minimum RU/s](concepts-limits.md#minimum-throughput-limits).

-# Mandatory fields.

-# Mandatory fields.

-#

-* [Query the twin graph](how-to-query-graph.md)

-description: Learn how to use the Azure Database for MySQL Data Migration - MySQL Login Migration

-description: Learn how to use the Azure Database for MySQL Data Migration - MySQL Schema Migration

-* For troubleshooting source database connectivity issues while using DMS, see article [Issues connecting source databases](./known-issues-troubleshooting-dms-source-connectivity.md).

-* For troubleshooting source database connectivity issues while using DMS, see article [Issues connecting source databases](./known-issues-troubleshooting-dms-source-connectivity.md).

-* To troubleshoot, review [Known issues](known-issues-azure-sql-migration-azure-data-studio.md).

-description: Learn to migrate from SQL Server to Azure SQL Database offline by using Azure Database Migration Service (classic).

- - seo-lt-2019

- - ignite-2022

-# Tutorial: Migrate SQL Server to Azure SQL Database using DMS (classic)

-> [!NOTE]

-> This tutorial uses an older version of the Azure Database Migration Service. For improved functionality and supportability, consider migrating to Azure SQL Database by using the [Azure SQL migration extension for Azure Data Studio](tutorial-sql-server-azure-sql-database-offline-ads.md).

->

-> To compare features between versions, review [compare versions](dms-overview.md#compare-versions).

-You can use Azure Database Migration Service to migrate the databases from a SQL Server instance to [Azure SQL Database](/azure/sql-database/). In this tutorial, you migrate the [AdventureWorks2016](/sql/samples/adventureworks-install-configure#download-backup-files) database restored to an on-premises instance of SQL Server 2016 (or later) to a single database or pooled database in Azure SQL Database by using Azure Database Migration Service.

-You will learn how to:

-> [!div class="checklist"]

->

-> - Assess and evaluate your on-premises database for any blocking issues by using the Data Migration Assistant.

-> - Use the Data Migration Assistant to migrate the database sample schema.

-> - Register the Azure DataMigration resource provider.

-> - Create an instance of Azure Database Migration Service.

-> - Create a migration project by using Azure Database Migration Service.

-> - Run the migration.

-> - Monitor the migration.

-## Prerequisites

-To complete this tutorial, you need to:

- > [!NOTE]

- > If you use SQL Server Integration Services (SSIS) and want to migrate the catalog database for your SSIS projects/packages (SSISDB) from SQL Server to Azure SQL Database, the destination SSISDB will be created and managed automatically on your behalf when you provision SSIS in Azure Data Factory (ADF). For more information about migrating SSIS packages, see the article [Migrate SQL Server Integration Services packages to Azure](./how-to-migrate-ssis-packages.md).

-

- > [!NOTE]

- > During virtual network setup, if you use ExpressRoute with network peering to Microsoft, add the following service [endpoints](../virtual-network/virtual-network-service-endpoints-overview.md) to the subnet in which the service will be provisioned:

- >

- > - Target database endpoint (for example, SQL endpoint, Azure Cosmos DB endpoint, and so on)

- > - Storage endpoint

- > - Service bus endpoint

- >

- > This configuration is necessary because Azure Database Migration Service lacks internet connectivity.

- >

- >If you donΓÇÖt have site-to-site connectivity between the on-premises network and Azure or if there is limited site-to-site connectivity bandwidth, consider using Azure Database Migration Service in hybrid mode (Preview). Hybrid mode leverages an on-premises migration worker together with an instance of Azure Database Migration Service running in the cloud. To create an instance of Azure Database Migration Service in hybrid mode, see the article [Create an instance of Azure Database Migration Service in hybrid mode using the Azure portal](./quickstart-create-data-migration-service-hybrid-portal.md).

- > [!IMPORTANT]

- > Creating an instance of Azure Database Migration Service requires access to virtual network settings that are normally not within the same resource group. As a result, the user creating an instance of DMS requires permission at subscription level. To create the required roles, which you can assign as needed, run the following script:

- >

- > ```

- >

- > $readerActions = `

- > "Microsoft.Network/networkInterfaces/ipConfigurations/read", `

- > "Microsoft.DataMigration/*/read", `

- > "Microsoft.Resources/subscriptions/resourceGroups/read"

- >

- > $writerActions = `

- > "Microsoft.DataMigration/services/*/write", `

- > "Microsoft.DataMigration/services/*/delete", `

- > "Microsoft.DataMigration/services/*/action", `

- > "Microsoft.Network/virtualNetworks/subnets/join/action", `

- > "Microsoft.Network/virtualNetworks/write", `

- > "Microsoft.Network/virtualNetworks/read", `

- > "Microsoft.Resources/deployments/validate/action", `

- > "Microsoft.Resources/deployments/*/read", `

- > "Microsoft.Resources/deployments/*/write"

- >

- > $writerActions += $readerActions

- >

- > # TODO: replace with actual subscription IDs

- > $subScopes = ,"/subscriptions/00000000-0000-0000-0000-000000000000/","/subscriptions/11111111-1111-1111-1111-111111111111/"

- >

- > function New-DmsReaderRole() {

- > $aRole = [Microsoft.Azure.Commands.Resources.Models.Authorization.PSRoleDefinition]::new()

- > $aRole.Name = "Azure Database Migration Reader"

- > $aRole.Description = "Lets you perform read only actions on DMS service/project/tasks."

- > $aRole.IsCustom = $true

- > $aRole.Actions = $readerActions

- > $aRole.NotActions = @()

- >

- > $aRole.AssignableScopes = $subScopes

- > #Create the role

- > New-AzRoleDefinition -Role $aRole

- > }

- >

- > function New-DmsContributorRole() {

- > $aRole = [Microsoft.Azure.Commands.Resources.Models.Authorization.PSRoleDefinition]::new()

- > $aRole.Name = "Azure Database Migration Contributor"

- > $aRole.Description = "Lets you perform CRUD actions on DMS service/project/tasks."

- > $aRole.IsCustom = $true

- > $aRole.Actions = $writerActions

- > $aRole.NotActions = @()

- >

- > $aRole.AssignableScopes = $subScopes

- > #Create the role

- > New-AzRoleDefinition -Role $aRole

- > }

- >

- > function Update-DmsReaderRole() {

- > $aRole = Get-AzRoleDefinition "Azure Database Migration Reader"

- > $aRole.Actions = $readerActions

- > $aRole.NotActions = @()

- > Set-AzRoleDefinition -Role $aRole

- > }

- >

- > function Update-DmsConributorRole() {

- > $aRole = Get-AzRoleDefinition "Azure Database Migration Contributor"

- > $aRole.Actions = $writerActions

- > $aRole.NotActions = @()

- > Set-AzRoleDefinition -Role $aRole

- > }

- >

- > # Invoke above functions

- > New-DmsReaderRole

- > New-DmsContributorRole

- > Update-DmsReaderRole

- > Update-DmsConributorRole

- > ```

-## Assess your on-premises database

-Before you can migrate data from a SQL Server instance to a single database or pooled database in Azure SQL Database, you need to assess the SQL Server database for any blocking issues that might prevent migration. Using the Data Migration Assistant, follow the steps described in the article [Performing a SQL Server migration assessment](/sql/dma/dma-assesssqlonprem) to complete the on-premises database assessment. A summary of the required steps follows:

-1. In the Data Migration Assistant, select the New (+) icon, and then select the **Assessment** project type.

-2. Specify a project name. From the **Assessment type** drop-down list, select **Database Engine**, in the **Source server type** text box, select **SQL Server**, in the **Target server type** text box, select **Azure SQL Database**, and then select **Create** to create the project.

- When you're assessing the source SQL Server database migrating to a single database or pooled database in Azure SQL Database, you can choose one or both of the following assessment report types:

- - Check database compatibility

- - Check feature parity

- Both report types are selected by default.

-3. In the Data Migration Assistant, on the **Options** screen, select **Next**.

-4. On the **Select sources** screen, in the **Connect to a server** dialog box, provide the connection details to your SQL Server, and then select **Connect**.

-5. In the **Add sources** dialog box, select **AdventureWorks2016**, select **Add**, and then select **Start Assessment**.

- > [!NOTE]

- > If you use SSIS, DMA does not currently support the assessment of the source SSISDB. However, SSIS projects/packages will be assessed/validated as they are redeployed to the destination SSISDB hosted by Azure SQL Database. For more information about migrating SSIS packages, see the article [Migrate SQL Server Integration Services packages to Azure](./how-to-migrate-ssis-packages.md).

- When the assessment is complete, the results display as shown in the following graphic:

- 

- For databases in Azure SQL Database, the assessments identify feature parity issues and migration blocking issues for deploying to a single database or pooled database.

- - The **SQL Server feature parity** category provides a comprehensive set of recommendations, alternative approaches available in Azure, and mitigating steps to help you plan the effort into your migration projects.

- - The **Compatibility issues** category identifies partially supported or unsupported features that reflect compatibility issues that might block migrating SQL Server database(s) to Azure SQL Database. Recommendations are also provided to help you address those issues.

-6. Review the assessment results for migration blocking issues and feature parity issues by selecting the specific options.

-## Migrate the sample schema

-After you're comfortable with the assessment and satisfied that the selected database is a viable candidate for migration to a single database or pooled database in Azure SQL Database, use DMA to migrate the schema to Azure SQL Database.

-> [!NOTE]

-> Before you create a migration project in Data Migration Assistant, be sure that you have already provisioned a database in Azure as mentioned in the prerequisites.

-> [!IMPORTANT]

-> If you use SSIS, DMA does not currently support the migration of source SSISDB, but you can redeploy your SSIS projects/packages to the destination SSISDB hosted by Azure SQL Database. For more information about migrating SSIS packages, see the article [Migrate SQL Server Integration Services packages to Azure](./how-to-migrate-ssis-packages.md).

-To migrate the **AdventureWorks2016** schema to a single database or pooled database Azure SQL Database, perform the following steps:

-1. In the Data Migration Assistant, select the New (+) icon, and then under **Project type**, select **Migration**.

-2. Specify a project name, in the **Source server type** text box, select **SQL Server**, and then in the **Target server type** text box, select **Azure SQL Database**.

-3. Under **Migration Scope**, select **Schema only**.

- After performing the previous steps, the Data Migration Assistant interface should appear as shown in the following graphic:

- 

-4. Select **Create** to create the project.

-5. In the Data Migration Assistant, specify the source connection details for your SQL Server, select **Connect**, and then select the **AdventureWorks2016** database.

- 

-6. Select **Next**, under **Connect to target server**, specify the target connection details for the Azure SQL Database, select **Connect**, and then select the **AdventureWorksAzure** database you had pre-provisioned in Azure SQL Database.

- 

-7. Select **Next** to advance to the **Select objects** screen, on which you can specify the schema objects in the **AdventureWorks2016** database that need to be deployed to Azure SQL Database.

- By default, all objects are selected.

- 

-8. Select **Generate SQL script** to create the SQL scripts, and then review the scripts for any errors.

- 

-9. Select **Deploy schema** to deploy the schema to Azure SQL Database, and then after the schema is deployed, check the target server for any anomalies.

- 

-## Create a migration project

-After the service is created, locate it within the Azure portal, open it, and then create a new migration project.

-1. In the Azure portal menu, select **All services**. Search for and select **Azure Database Migration Services**.

- 

-2. On the **Azure Database Migration Services** screen, select the Azure Database Migration Service instance that you created.

-3. Select **New Migration Project**.

- 

-4. On the **New migration project** screen, specify a name for the project, in the **Source server type** text box, select **SQL Server**, in the **Target server type** text box, select **Azure SQL Database**, and then for **Choose Migration activity type**, select **Data migration**.

- 

-5. Select **Create and run activity** to create the project and run the migration activity.

-## Specify source details

-1. On the **Select source** screen, specify the connection details for the source SQL Server instance.

- Make sure to use a Fully Qualified Domain Name (FQDN) for the source SQL Server instance name. You can also use the IP Address for situations in which DNS name resolution isn't possible.

-2. If you have not installed a trusted certificate on your source server, select the **Trust server certificate** check box.

- When a trusted certificate is not installed, SQL Server generates a self-signed certificate when the instance is started. This certificate is used to encrypt the credentials for client connections.

- > [!CAUTION]

- > TLS connections that are encrypted using a self-signed certificate do not provide strong security. They are susceptible to man-in-the-middle attacks. You should not rely on TLS using self-signed certificates in a production environment or on servers that are connected to the internet.

- > [!IMPORTANT]

- > If you use SSIS, DMS does not currently support the migration of source SSISDB, but you can redeploy your SSIS projects/packages to the destination SSISDB hosted by Azure SQL Database. For more information about migrating SSIS packages, see the article [Migrate SQL Server Integration Services packages to Azure](./how-to-migrate-ssis-packages.md).

- 

-

-3. Select **Next: Select databases**.

-## Select databases for migration

-Select either all databases or specific databases that you want to migrate to Azure SQL Database. DMS provides you with the expected migration time for selected databases. If the migration downtimes are acceptable continue with the migration. If the migration downtimes are not acceptable, consider migrating to [SQL Managed Instance with near-zero downtime](tutorial-sql-server-managed-instance-online.md) or submit ideas/suggestions for improvement, and other feedback in the [Azure Community forum ΓÇö Azure Database Migration Service](https://feedback.azure.com/d365community/forum/2dd7eb75-ef24-ec11-b6e6-000d3a4f0da0).

-1. Choose the database(s) you want to migrate from the list of available databases.

-1. Review the expected downtime. If it's acceptable, select **Next: Select target >>**

- 

-## Specify target details

-1. On the **Select target** screen, provide authentication settings to your Azure SQL Database.

- 

-

- > [!NOTE]

- > Currently, SQL authentication is the only supported authentication type.

-1. Select **Next: Map to target databases** screen, map the source and the target database for migration.

- If the target database contains the same database name as the source database, Azure Database Migration Service selects the target database by default.

- 

-1. Select **Next: Configuration migration settings**, expand the table listing, and then review the list of affected fields.

- Azure Database Migration Service auto selects all the empty source tables that exist on the target Azure SQL Database instance. If you want to remigrate tables that already include data, you need to explicitly select the tables on this blade.

- 

-1. Select **Next: Summary**, review the migration configuration and in the **Activity name** text box, specify a name for the migration activity.

- 

-## Run the migration

- The migration activity window appears, and the **Status** of the activity is **Pending**.

- 

-## Monitor the migration

-1. On the migration activity screen, select **Refresh** to update the display until the **Status** of the migration shows as **Completed**.

- 

-2. Verify the target database(s) on the target **Azure SQL Database**.

-## Additional resources

-See [Subscribe to Azure Resource Notifications - Health Resources events](subscribe-to-resource-notifications-health-resources-events.md).

-See [Azure Resource Notifications - Health Resources events in Azure Event Grid](event-schema-health-resources.md).

-You can find Go samples for Azure Event Hubs in the [azure-event-hubs-go](https://github.com/Azure/azure-event-hubs-go/tree/master/_examples) GitHub repository.

-For all other downgrade scenarios, you'll need to delete and recreate the gateway. Recreating a gateway incurs downtime.

-When you're planning your gateway subnet size, refer to the documentation for the configuration that you're planning to create. For example, the ExpressRoute/VPN Gateway coexist configuration requires a larger gateway subnet than most other configurations. Further more, you may want to make sure your gateway subnet contains enough IP addresses to accommodate possible future configurations. While you can create a gateway subnet as small as /29, we recommend that you create a gateway subnet of /27 or larger (/27, /26 etc.). If you plan on connecting 16 ExpressRoute circuits to your gateway, you **must** create a gateway subnet of /26 or larger. If you're creating a dual stack gateway subnet, we recommend that you also use an IPv6 range of /64 or larger. This set up will accommodate most configurations.

-## Connectivity to Private Endpoints

-When you create or delete an Azure Route Server from a virtual network that contains a Virtual Network Gateway (ExpressRoute or VPN), expect downtime until the operation gets completed.

-By default, connectivity between virtual networks is enabled when you link multiple virtual networks to the same ExpressRoute circuit. Microsoft recommends not using your ExpressRoute circuit for communication between virtual networks. Instead, it is recommended to use [VNet peering](../virtual-network/virtual-network-peering-overview.md). For more information about why VNet-to-VNet connectivity isn't recommended over ExpressRoute, see [connectivity between virtual networks over ExpressRoute](virtual-network-connectivity-guidance.md).

-1. Go to the Azure Front Door profile you enabled managed identity and select **Secret** from under *Settings*.

-description: In this article, you'll learn concepts of DICOM and the DICOM service.

-# What is the DICOM service?

-DICOM (Digital Imaging and Communications in Medicine) is the international standard to transmit, store, retrieve, print, process, and display medical imaging information, and is the primary medical imaging standard accepted across healthcare.

-The DICOM service is a managed service within [Azure Health Data Services](../healthcare-apis-overview.md) that ingests and persists DICOM objects at multiple thousands of images per second. It facilitates communication and transmission of imaging data with any DICOMweb&trade; enabled systems or applications via DICOMweb Standard APIs like [Store (STOW-RS)](dicom-services-conformance-statement-v2.md#store-stow-rs), [Search (QIDO-RS)](dicom-services-conformance-statement-v2.md#search-qido-rs), [Retrieve (WADO-RS)](dicom-services-conformance-statement-v2.md#retrieve-wado-rs). It's backed by a managed Platform-as-a Service (PaaS) offering in the cloud with complete [PHI](https://www.hhs.gov/answers/hipaa/what-is-phi/https://docsupdatetracker.net/index.html) compliance that you can upload PHI data to the DICOM service and exchange it through secure networks.

-[Open-source DICOM-server project](https://github.com/microsoft/dicom-server) is also constantly monitored for feature parity with managed service so that developers can deploy open source version as a set of Docker containers to speed up development and test in their environments, and contribute to potential future managed service features.

-## Applications for the DICOM service

-In order to effectively treat patients, research new treatments, diagnose solutions, or provide an effective overview of the health history of a single patient, organizations must integrate data across several sources. One of the most pressing integrations is between clinical and imaging data. DICOM service enables imaging data to securely persist in the Microsoft cloud and allows it to reside with EHR and IoT data in the same Azure subscription.

-FHIR&trade; is becoming an important standard for clinical data and provides extensibility to support integration of other types of data directly, or through references. By using DICOM service, organizations can store references to imaging data in FHIR&trade; and enable queries that cross clinical and imaging datasets. This can enable many different scenarios, for example:

-## Deploy DICOM service to Azure

-DICOM service needs an Azure subscription to configure and run the required components. These components are, by default, created inside of an existing or new Azure Resource Group to simplify management. Additionally, an Azure Active Directory account is required. For each instance of DICOM service, we create a combination of isolated and multi-tenant resource.

-## DICOM server

-The Medical Imaging Server for DICOM (hereby known as DICOM server) is an open source DICOM server that is easily deployed on Azure. It allows standards-based communication with any DICOMwebΓäó enabled systems, and injects DICOM metadata into a FHIR server to create a holistic view of patient data. See [DICOM server](https://github.com/microsoft/dicom-server).

-## Summary

-This conceptual article provided you with an overview of DICOM and the DICOM service.

-

-## Next steps

-To get started using the DICOM service, see

->[!div class="nextstepaction"]

->[Deploy DICOM service to Azure](deploy-dicom-services-in-azure.md)

-For more information about how to use the DICOMweb&trade; Standard APIs with the DICOM service, see

->[!div class="nextstepaction"]

->[Using DICOMweb&trade;Standard APIs with DICOM service](dicomweb-standard-apis-with-dicom-services.md)

-FHIR&#174; is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.

->

-Documentation navigation improvements include a new hub page for Azure Health Data

-**Incremental Import feature is Generally Available (GA)**

-Details per resource, on the number of completed reindexed resources can be obtained with help of the new field, added in the response- "resourceReindexProgressByResource". For details, visit [3286](https://github.com/microsoft/fhir-server/pull/3286).

-This bug fix addresses the issue, where the FHIR service wouldn't load the latest SearchParameter status in event of failure.

-This feature improvement is applicable to System export, for more information on export, visit [FHIR specification](https://hl7.org/fhir/uv/bulkdata/export/https://docsupdatetracker.net/index.html)

-Also visit [Export your FHIR data by invoking the $export command on the FHIR service | Microsoft Learn](./../healthcare-apis/fhir/export-data.md)

-This bug fix addresses the issue. Identified resources are returned per search criteria with :contains modifier . for more information on bug fix visit [#3041](https://github.com/microsoft/fhir-server/pull/3041)

-With failure in export job due to a long time span, a customer will see `RequestEntityTooLarge` HTTP status code. For more information, see [#2790](https://github.com/microsoft/fhir-server/pull/2790).

-Some customers have run into issues storing DICOM files that don't perfectly conform to the specification. To enable those files to be stored in the DICOM service, we have reduced the strictness of the validation performed on STOW.

-The service accepts the following:

-Attributes that are defined to have a single value but have specified multiple values are leniently accepted. The first value for such attributes are indexed.

-For invalid JSON body requests, the FHIR server was returning a 500 error. Now we'll return a `BadRequestException` with a valid message instead of 500. [#2239](https://github.com/microsoft/fhir-server/pull/2239)

-In certain instances, the continuation token was too long to be able to follow the [next link](./../healthcare-apis/fhir/overview-of-search.md#pagination) in searches and would result in a 404. To resolve this, we compressed the continuation token to ensure it stays below the size limit [#2279](https://github.com/microsoft/fhir-server/pull/2279). Addresses issue [#2250](https://github.com/microsoft/fhir-server/issues/2250).

-Use the Device Provisioning Service to [Provision multiple X.509 devices using enrollment groups](../iot-dps/tutorial-custom-hsm-enrollment-group-x509.md).

-

-* [Create your own workbooks](../azure-monitor/visualize/workbooks-overview.md), you can take inspiration by clicking on the edit button in your detailed metrics dashboard

-A Load Balancer can either be **zone redundant, zonal,** or **non-zonal**. To configure the zone-related properties for your load balancer, select the appropriate type of frontend needed.

-In a region with Availability Zones, a Standard Load Balancer can be zone-redundant with traffic served by a single IP address. A single frontend IP address survives zone failure. The frontend IP may be used to reach all (nonimpacted) backend pool members no matter the zone. One or more availability zones can fail and the data path survives as long as one zone in the region remains healthy.

-To use customer-managed encryption keys with Azure Load Testing, you need to store the key in Azure Key Vault. You can use an existing or create a new key vault. The load testing resource and key vault may be in different regions or subscriptions in the same tenant.

-## Add a key

-The user-assigned managed identity for accessing the customer-managed keys in Azure Key Vault must have appropriate permissions to access the key vault.

-## Configure customer-managed keys for a new load testing resource

-## Change the managed identity

-> [!NOTE]

-> The selected managed identity should have access granted on the Azure Key Vault.

-## Change the key

-## Key rotation

-You can rotate a customer-managed key in Azure Key Vault according to your compliance policies. To rotate a key, in Azure Key Vault, update the key version or create a new key. You can then update the load testing resource to [encrypt data using the new key URI](#change-the-key).

-## Next steps

-> [!NOTE]

->

-> In Standard logic app workflows, the **Flat File** actions are currently in preview.

-> [!VIDEO https://learn.microsoft.com/Shows/Azure-Friday/Connect-and-extend-your-mainframe-to-the-cloud-with-Logic-Apps/player]

-serverless Spark compute works well for most user scenarios that require quick access to distributed computing through Apache Spark. However, to make an informed decision, users should consider the advantages and disadvantages of this approach.

-The Spark session configuration offers an option that defines a session timeout (in minutes). The Spark session will end after an inactivity period that exceeds the user-defined timeout. If another Spark session doesn't start in the following ten minutes, resources provisioned for the serverless Spark compute will be torn down.

-> For a session-level conda package:

-> - the *Warm start*, using same conda package, will need about one minute.

-> - the *Warm start*, with a different conda package, will also need about ten to fifteen minutes.

-> - If the package that you're installing is large or takes a long time to install, it might affect the Spark instance's startup time.

-A conda dependency YAML file can define a number of session-level conda packages in a session configuration. A session will time out if it takes longer than fifteen minutes to install the conda packages defined in the YAML file. It becomes important to first check whether a required package is already available in the Azure Synapse base image. To do this, users should follow the link to determine *packages available in the base image for* the Apache Spark version in use:

-In Azure Machine Learning Spark jobs, you can define Spark cluster size with three parameter values:

-You should consider an Azure Machine Learning Apache Spark executor as equivalent to Azure Spark worker nodes. An example can explain these parameters. Let's say that you defined the number of executors as 6 (equivalent to six worker nodes), executor cores as 4, and executor memory as 28 GB. Your Spark job then has access to a cluster with 24 cores and 168 GB of memory.

-To access data and other resources, a Spark job can use either a user identity passthrough or a managed identity. This table summarizes the mechanisms that Spark jobs use to access resources.

- resource_group_name=resource_group)

- az ml workspace sync-keys -w myworkspace -g myresourcegroup

->- To learn more about resource access while using Azure Machine Learning serverless Spark compute, and attached Synapse Spark pool, see [Ensuring resource access for Spark jobs](apache-spark-environment-configuration.md#ensuring-resource-access-for-spark-jobs).

-1. Execute the following command in the PowerShell prompt or the command prompt, to attach the user-assigned managed identity to the workspace.

-A Python script developed by [interactive data wrangling](./interactive-data-wrangling-with-apache-spark-azure-ml.md) can be used to submit a batch job to process a larger volume of data, after making necessary changes for Python script parameterization. A simple data wrangling batch job can be submitted as a standalone Spark job.

-> This Python code sample uses `pyspark.pandas`, which is only supported by Spark runtime version 3.2.

-To create a job, a standalone Spark job can be defined as a YAML specification file, which can be used in the `az ml job create` command, with the `--file` parameter. Define these properties in the YAML file as follows:

- - `3.1`

- > * Azure Synapse Runtime for Apache Spark 3.1:

- > * End of Life (EOLA) Announcement Date: January 26, 2023

- > * End of Support Date: July 31, 2023. After this date, the runtime will be disabled.

- An example is shown here:

-> To use an attached Synapse Spark pool, define the `compute` property in the sample YAML specification file shown above, instead of the `resources` property.

-The YAML files shown above can be used in the `az ml job create` command, with the `--file` parameter, to create a standalone Spark job as shown:

- - `3.1.0`

- > * Azure Synapse Runtime for Apache Spark 3.1:

- > * End of Life (EOLA) Announcement Date: January 26, 2023

- > * End of Support Date: July 31, 2023. After this date, the runtime will be disabled.

- > * Azure Synapse Runtime for Apache Spark 3.1:

- > * End of Life (EOLA) Announcement Date: January 26, 2023

- > * End of Support Date: July 31, 2023. After this date, the runtime will be disabled.

-YAML syntax for a Spark component resembles the [YAML syntax for Spark job specification](#yaml-properties-in-the-spark-job-specification) in most ways. These properties are defined differently in the Spark component YAML specification:

- runtime_version: "3.2"

-The above YAML specification file can be used in `az ml job create` command, using the `--file` parameter, to create a pipeline job as shown:

-To create an Azure Machine Learning pipeline with a Spark component, you should have familiarity with creation of [Azure Machine Learning pipelines from components, using Python SDK](./tutorial-pipeline-python-sdk.md#create-the-pipeline-from-components). A Spark component is created using `azure.ai.ml.spark` function. The function parameters are defined almost the same way as for the [standalone Spark job](#standalone-spark-job-using-python-sdk). These parameters are defined differently for the Spark component:

-> A Spark component created using `azure.ai.ml.spark` function does not define `identity`, `compute` or `resources` parameters. The Azure Machine Learning pipeline defines these parameters.

-Before starting data wrangling tasks, you need familiarity with the process of storing secrets

- > [!IMPORTANT]

- >

- > End of life announcement (EOLA) for Azure Synapse Runtime for Apache Spark 3.1 was made on January 26, 2023. In accordance, Apache Spark 3.1 will not be supported after July 31, 2023. We recommend that you use Apache Spark 3.2.

-9. To use a conda file to configure a Spark session, check the **Upload conda file** checkbox. Then, select **Browse**, and choose the conda file with the Spark session configuration you want.

-> Data wrangling with a serverless Spark compute, and user identity passthrough to access data in Azure Data Lake Storage (ADLS) Gen 2 storage account requires the least number of configuration steps.

- > This Python code sample uses `pyspark.pandas`, which is only supported by Spark runtime version 3.2.

- - The `get_secret()` call in the code depends on name of the Azure Key Vault, and the names of the Azure Key Vault secrets created for the service principal tenant ID, client ID and client secret. The corresponding property name/values to set in the configuration are as follows:

-2. Execute the data wrangling code in the same notebook. Format the data URI as `wasbs://<BLOB_CONTAINER_NAME>@<STORAGE_ACCOUNT_NAME>.blob.core.windows.net/<PATH_TO_DATA>` similar to this code snippet

- > This Python code sample uses `pyspark.pandas`, which is only supported by Spark runtime version 3.2.

- > This Python code sample uses `pyspark.pandas`, which is only supported by Spark runtime version 3.2.

-The Azure Machine Learning datastores can access data using Azure storage account credentials

-or provide credential-less data access. Depending on the datastore type and the underlying Azure storage account type, adopt an appropriate authentication mechanism to ensure data access. This table summarizes the authentication mechanisms to access data in the Azure Machine Learning datastores:

-^<b>*</b> user identity passthrough works for credential-less datastores that point to Azure Blob storage accounts, only if [soft delete](../storage/blobs/soft-delete-blob-overview.md) isn't enabled.

-> This Python code sample uses `pyspark.pandas`, which is only supported by Spark runtime version 3.2.

-|Compute| [Creating compute instance after a workspace move results in an Etag conflict error.](workspace-move-compute-instance-same-name.md)| August 14, 2023 |

-While using the compute instance terminal inside a mounted path of a data folder, any commands executed from the terminal result in slowness. This issue is restricted to the terminal; running the commands from SDK using a notebook works as expected.

-<! Choose the correct include >

-When trying to launch an R kernel in JupyterLab or a notebook in a new compute instance, the kernel fails to start with `Error: .onLoad failed in loadNamespace()`

-After a moving a workspace to a different subscription or resource group, creating a compute instance with the same name as a previous compute instance will fail with an Etag conflict error.

-<! Choose the correct include >

-| `Resource` | Name of the server |

-| `Resource` | Name of the server |

-| `Resource` | Name of the server |

- | where Resource == '<your server name>'

- | where Resource == '<your server name>'

- | where Resource == '<your server name>'

- | where Resource == '<your server name>'

-|(When an item is created)[./connectors/azuremysql/#when-an-item-is-created]|Triggers a flow when an item is created in MySQL (Available only for Power Automate.)|

-|(When an item is modified)[./connectors/azuremysql/#when-an-item-is-modified]|Triggers a flow when an item is modified in MySQL. (Available only for Power Automate.)|

-# Traffic analytics

-Traffic analytics is a cloud-based solution that provides visibility into user and application activity in your cloud networks. Specifically, traffic analytics analyzes Azure Network Watcher NSG flow logs to provide insights into traffic flow in your Azure cloud. With traffic analytics, you can:

-> [!NOTE]

-> Traffic analytics now supports collecting NSG flow logs data at a frequency of every 10 minutes.

-With Azure virtual networks, NSG flow logs collect data about the network. These logs provide information about ingress and egress IP traffic through a network security group that's associated with individual network interfaces, VMs, or subnets. Traffic analytics analyzes raw NSG flow logs and combines the log data with intelligence about security, topology, and geography. Traffic analytics then provides you with insights into traffic flow in your environment.

- - Outbound and inbound flows on a per rule basis.

- - The NIC that the flow applies to.

- - Information about the flow, such as the source and destination IP addresses, the source and destination ports, and the protocol.

- - The status of the traffic, such as allowed or denied.

- For more information about NSG flow logs, see [NSG flow logs](network-watcher-nsg-flow-logging-overview.md).

-Traffic analytics examines raw NSG flow logs. It then reduces the log volume by aggregating flows that have a common source IP address, destination IP address, destination port, and protocol.

-One of the following [Azure built-in roles](../role-based-access-control/built-in-roles.md) needs to be assigned to your account:

-|Deployment model | Role |

-| | |

-|Resource Manager | Owner |

-| | Contributor |

-| | Network Contributor |

-> [!IMPORTANT]

-> [Network contributor](../role-based-access-control/built-in-roles.md?toc=%2fazure%2fnetwork-watcher%2ftoc.json#network-contributor) does not cover `Microsoft.OperationalInsights/workspaces/*` actions.

-If none of the preceding built-in roles are assigned to your account, assign a [custom role](../role-based-access-control/custom-roles.md?toc=%2fazure%2fnetwork-watcher%2ftoc.json) to your account. The custom role should support the following actions at the subscription level:

-For information about how to check user access permissions, see [Traffic analytics FAQ](traffic-analytics-faq.yml#what-are-the-prerequisites-to-use-traffic-analytics-).

-## Frequently asked questions

-To get answers to frequently asked questions about traffic analytics, see [Traffic analytics FAQ](traffic-analytics-faq.yml).

-## Next steps

-To run your Playwright tests in your Microsoft Playwright Testing workspace, you need to add a service configuration file alongside your Playwright configuration file. The service configuration file references the environment variables to get the workspace endpoint and your access token. In the next step, you pass this service configuration file to the Playwright CLI.

-You've now prepared the configuration for running your Playwright tests in the cloud with Microsoft Playwright Testing. To run your Playwright tests, you use the Playwright CLI and specify the service configuration file and number of workers on the command-line.

-Perform the following steps to run your Playwright tests:

-1. Open a terminal window and enter the following command to run your Playwright tests on remote browsers in your workspace:

- Depending on the size of your test suite, the tests run on up to 20 parallel workers.

- ```bash

- npx playwright test --config=playwright.service.config.ts --workers=20

- ```

- You should see a similar output when the tests complete:

- ```output

- Running 6 tests using 6 workers

- 6 passed (18.2s)

-

- To open last HTML report run:

- npx playwright show-report

- ```

-1. Go to the [Playwright portal](https://aka.ms/mpt/portal) to view your test run.

- The activity log lists for each test run the following details: the total test completion time, the number of parallel workers, and the number of test minutes.

- :::image type="content" source="./media/quickstart-run-end-to-end-tests/playwright-testing-activity-log.png" alt-text="Screenshot that shows the activity log for a workspace in the Playwright Testing portal." lightbox="./media/quickstart-run-end-to-end-tests/playwright-testing-activity-log.png":::

-> Storage autogrow always trigger disk scaling operations online. In specific scenarios where disk scaling process cannot be done online storage autogrow does not trigger and you need to manually increase the storage. These scenarios include reaching, starting at, or crossing the 4,096-GiB limit.

-* General availability of [Storage auto-grow](./concepts-compute-storage.md#storage-auto-grow-preview) for Azure Database for PostgreSQL ΓÇô Flexible Server.

- :::image type="content" source="./media/concepts-single-to-flexible/azure-portal-overview-page.png" alt-text="Screenshot of the Overview page." lightbox="./media/concepts-single-to-flexible/azure-portal-overview-page.png":::

- :::image type="content" source="./media/concepts-single-to-flexible/single-to-flex-migrate-single-server.png" alt-text="Screenshot of the Migrate from Single Server tab." lightbox="./media/concepts-single-to-flexible/single-to-flex-migrate-single-server.png":::

- :::image type="content" source="./media/concepts-single-to-flexible/single-to-flex-initiate-migrate-from-single-server.png" alt-text="Screenshot to initiate migration from Single Server tab." lightbox="./media/concepts-single-to-flexible/single-to-flex-initiate-migrate-from-single-server.png":::

- :::image type="content" source="./media/concepts-single-to-flexible/single-to-flex-choose-between-flexible-server.png" alt-text="Screenshot to choose existing flexible server option." lightbox="./media/concepts-single-to-flexible/single-to-flex-choose-between-flexible-server.png":::

- :::image type="content" source="./media/concepts-single-to-flexible/single-to-flex-create-new.png" alt-text="Screenshot to choose new flexible server option." lightbox="./media/concepts-single-to-flexible/single-to-flex-create-new.png":::

-Under **Choose databases to migrate**, there's a list of user databases inside the Single Server. You can select and migrate up to eight databases in a single migration attempt. If there are more than eight user databases, the migration process is repeated between the source and target servers for the next set of databases.

-The final property on the **Source** tab is **Migration mode**. The migration tool offers offline mode of migration as default.

-For **Authorize DB overwrite**:

-When you select each of the databases in migration, a fan-out pane appears. It has all the table count - copied, queued, copying and errors apart from the database migration status.

- - github-actions-azure

- - mode-other

-> For selected data sources, you can choose the alternative *indexer* approach which simplifies and reduces the amount of code required for indexing. For more information, see [Indexer operations](/rest/api/searchservice/indexer-operations).

-Once you've created your alias, you're ready to start using it. Aliases can be used for all [document operations](/rest/api/searchservice/document-operations) including querying, indexing, suggestions, and autocomplete.

-> You can only use an alias with [document operations](/rest/api/searchservice/document-operations) or to get and update an index definition. Aliases can't be used to delete an index, can't be used with the Analyze Text API, and can't be used as the `targetIndexName` on an indexer.

-Refer to the [Index operations (REST)](/rest/api/searchservice/index-operations) for help with formulating index requests.

-+ [Index operations (REST API)](/rest/api/searchservice/index-operations)

-## Indexer definition at a glance

-### Indexer for text-based indexing

-### Indexer for skills-based indexing and AI enrichment

-Refer to the [Indexer operations (REST)](/rest/api/searchservice/Indexer-operations) for help with formulating indexer requests.

-+ [Indexer operations (REST)](/rest/api/searchservice/indexer-operations)

-1. Open a command shell for Azure CLI. If you don't have Azure CLI installed, you can open [Create a service principal](/cli/azure/create-an-azure-service-principal-azure-cli#1-create-a-service-principal), select **Try It**.

-|Database search | Many database platforms include a built-in search experience. SQL Server has [full text search](/sql/relational-databases/search/full-text-search). Azure Cosmos DB and similar technologies have queryable indexes. When evaluating products that combine search and storage, it can be challenging to determine which way to go. Many solutions use both: DBMS for storage, and Azure Cognitive Search for specialized search features.<br/><br/>Compared to DBMS search, Azure Cognitive Search stores content from heterogeneous sources and offers specialized text processing features such as linguistic-aware text processing (stemming, lemmatization, word forms) in [56 languages](/rest/api/searchservice/language-support). It also supports autocorrection of misspelled words, [synonyms](/rest/api/searchservice/synonym-map-operations), [suggestions](/rest/api/searchservice/suggestions), [scoring controls](/rest/api/searchservice/add-scoring-profiles-to-a-search-index), [facets](search-faceted-navigation.md), and [custom tokenization](/rest/api/searchservice/custom-analyzers-in-azure-search). The [full text search engine](search-lucene-query-architecture.md) in Azure Cognitive Search is built on Apache Lucene, an industry standard in information retrieval. However, while Azure Cognitive Search persists data in the form of an inverted index, it isn't a replacement for true data storage and we don't recommend using it in that capacity. For more information, see this [forum post](https://stackoverflow.com/questions/40101159/can-azure-search-be-used-as-a-primary-database-for-some-data). <br/><br/>Resource utilization is another inflection point in this category. Indexing and some query operations are often computationally intensive. Offloading search from the DBMS to a dedicated solution in the cloud preserves system resources for transaction processing. Furthermore, by externalizing search, you can easily adjust scale to match query volume.|

-Indexer functionality is exposed in the [Azure portal](search-import-data-portal.md), the [REST API](/rest/api/searchservice/Indexer-operations), and the [.NET SDK](/dotnet/api/azure.search.documents.indexes.searchindexerclient).

-2. Add a node to the node type from a cluster by following the procedure to [modify node type](how-to-managed-cluster-modify-node-type.md).

-3. Remove a node to the node type from a cluster by following the procedure to [modify node type](how-to-managed-cluster-modify-node-type.md).

-description: Learn how to set up disaster recovery for Hyper-V VMs between your on-premises sites with Azure Site Recovery.

-# Set up disaster recovery for Hyper-V VMs to a secondary on-premises site

-The [Azure Site Recovery](site-recovery-overview.md) service contributes to your disaster recovery strategy by managing and orchestrating replication, failover, and failback of on-premises machines, and Azure virtual machines (VMs).

-This article shows you how to set up disaster recovery to a secondary site, for on-premises Hyper-V VMs managed in System Center Virtual Machine Manager (VMM) clouds. In this article, you learn how to:

-> [!div class="checklist"]

-> * Prepare on-premises VMM servers and Hyper-V hosts

-> * Create a Recovery Services vault for Site Recovery

-> * Set up the source and target replication environments.

-> * Set up network mapping

-> * Create a replication policy

-> * Enable replication for a VM

-## Prerequisites

-To complete this scenario:

-### Prepare for network mapping

-[Network mapping](hyper-v-vmm-network-mapping.md) maps between on-premises VMM VM networks in source and target clouds. Mapping does the following:

-Prepare VMM as follows:

-1. Make sure you have [VMM logical networks](/system-center/vmm/network-logical) on the source and target VMM servers.

- - The logical network on the source server should be associated with the source cloud in which Hyper-V hosts are located.

- - The logical network on the target server should be associated with the target cloud.

-1. Make sure you have [VM networks](/system-center/vmm/network-virtual) on the source and target VMM servers. VM networks should be linked to the logical network in each location.

-2. Connect VMs on the source Hyper-V hosts to the source VM network.

-## Create a Recovery Services vault

-## Choose a protection goal

-Select what you want to replicate and where you want to replicate to.

-1. Click **Site Recovery** > **Step 1: Prepare Infrastructure** > **Protection goal**.

-2. Select **To recovery site**, and select **Yes, with Hyper-V**.

-3. Select **Yes** to indicate you're using VMM to manage the Hyper-V hosts.

-4. Select **Yes** if you have a secondary VMM server. If you're deploying replication between clouds on a single VMM server, click **No**. Then click **OK**.

-## Set up the source environment

-Install the Azure Site Recovery Provider on VMM servers, and discover and register servers in the vault.

-1. Click **Prepare Infrastructure** > **Source**.

-2. In **Prepare source**, click **+ VMM** to add a VMM server.

-3. In **Add Server**, check that **System Center VMM server** appears in **Server type**.

-4. Download the Azure Site Recovery Provider installation file.

-5. Download the registration key. You need this when you install the Provider. The key is valid for five days after you generate it.

- 

-6. Install the Provider on each VMM server. You don't need to explicitly install anything on Hyper-V hosts.

-### Install the Azure Site Recovery Provider

-1. Run the Provider setup file on each VMM server. If VMM is deployed in a cluster, install for the first time as follows:

- - Install the Provider on an active node, and finish the installation to register the VMM server in the vault.

- - Then, install the Provider on the other nodes. Cluster nodes should all run the same version of the Provider.

-2. Setup runs a few prerequisite checks, and requests permission to stop the VMM service. The VMM service will be restarted automatically when setup finishes. If you install on a VMM cluster, you're prompted to stop the Cluster role.

-3. In **Microsoft Update**, you can opt in to specify that provider updates are installed in accordance with your Microsoft Update policy.

-4. In **Installation**, accept or modify the default installation location, and click **Install**.

-5. After installation is complete, click **Register** to register the server in the vault.

- 

-6. In **Vault name**, verify the name of the vault in which the server will be registered. Click **Next**.

-7. In **Proxy Connection**, specify how the Provider running on the VMM server connects to Azure.

- - You can specify that the provider should connect directly to the internet, or via a proxy. Specify proxy settings as needed.

- - If you use a proxy, a VMM RunAs account (DRAProxyAccount) is created automatically, using the specified proxy credentials. Configure the proxy server so that this account can authenticate successfully. The RunAs account settings can be modified in the VMM console > **Settings** > **Security** > **Run As Accounts**.

- - Restart the VMM service to update changes.

-8. In **Registration Key**, select the key that you downloaded and copied to the VMM server.

-9. The encryption setting isn't relevant in this scenario.

-10. In **Server name**, specify a friendly name to identify the VMM server in the vault. In a cluster, specify the VMM cluster role name.

-11. In **Synchronize cloud metadata**, select whether you want to synchronize metadata for all clouds on the VMM server. This action only needs to happen once on each server. If you don't want to synchronize all clouds, leave this setting unchecked. You can synchronize each cloud individually, in the cloud properties in the VMM console.

-12. Click **Next** to complete the process. After registration, Site Recovery retrieves metadata from the VMM server. The server is displayed in **Servers** > **VMM Servers** in the vault.

-13. After the server appears in the vault, in **Source** > **Prepare source** select the VMM server, and select the cloud in which the Hyper-V host is located. Then click **OK**.

-## Set up the target environment

-Select the target VMM server and cloud:

-1. Click **Prepare infrastructure** > **Target**, and select the target VMM server.

-2. VMM clouds that are synchronized with Site Recovery are displayed. Select the target cloud.

- 

-## Set up a replication policy

-Before you start, make sure that all hosts using the policy have the same operating system. If hosts are running different versions of Windows Server, you need multiple replication policies.

-1. To create a new replication policy, click **Prepare infrastructure** > **Replication Settings** > **+Create and associate**.

-2. In **Create and associate policy**, specify a policy name. The source and target type should be **Hyper-V**.

-3. In **Hyper-V host version**, select which operating system is running on the host.

-4. In **Authentication type** and **Authentication port**, specify how traffic is authenticated between the primary and recovery Hyper-V host servers.

- - Select **Certificate** unless you have a working Kerberos environment. Azure Site Recovery will automatically configure certificates for HTTPS authentication. You don't need to do anything manually.

- - By default, port 8083 and 8084 (for certificates) will be opened in the Windows Firewall on the Hyper-V host servers.

- - If you do select **Kerberos**, a Kerberos ticket will be used for mutual authentication of the host servers. Kerberos is only relevant for Hyper-V host servers running on Windows Server 2012 R2 or later.

-1. In **Copy frequency**, specify how often you want to replicate delta data after the initial replication (every 30 seconds, 5 or 15 minutes).

-2. In **Recovery point retention**, specify \how long (in hours) the retention window will be for each recovery point. Replicated machines can be recovered to any point within a window.

-3. In **App-consistent snapshot frequency**, specify how frequently (1-12 hours) recovery points containing application-consistent snapshots are created. Hyper-V uses two types of snapshots:

- - **Standard snapshot**: Provides an incremental snapshot of the entire virtual machine.

- - **App-consistent snapshot**: Takes a point-in-time snapshot of the application data inside the VM. Volume Shadow Copy Service (VSS) ensures that apps are in a consistent state when the snapshot is taken. Enabling application-consistent snapshots, affects app performance on source VMs. Set a value that's less than the number of additional recovery points you configure.

-4. In **Data transfer compression**, specify whether transferred replication data should be compressed.

-5. Select **Delete replica VM**, to specify that the replica virtual machine should be deleted if you disable protection for the source VM. If you enable this setting, when you disable protection for the source VM it's removed from the Site Recovery console, Site Recovery settings for the VMM are removed from the VMM console, and the replica is deleted.

-6. In **Initial replication method**, if you're replicating over the network, specify whether to start the initial replication or schedule it. To save network bandwidth, you might want to schedule it outside your busy hours. Then click **OK**.

- 

-

-7. The new policy is automatically associated with the VMM cloud. In **Replication policy**, click **OK**.

-## Enable replication

-1. Click **Replicate application** > **Source**.

-2. In **Source**, select the VMM server, and the cloud in which the Hyper-V hosts you want to replicate are located. Then click **OK**.

-3. In **Target**, verify the secondary VMM server and cloud.

-4. In **Virtual machines**, select the VMs you want to protect from the list.

-You can track progress of the **Enable Protection** action in **Jobs** > **Site Recovery jobs**. After the **Finalize Protection** job completes, the initial replication is complete, and the VM is ready for failover.

-## Next steps

-[Run a disaster recovery drill](hyper-v-vmm-test-failover.md)

-description: Learn how to fail over Hyper-V VMs to your secondary on-premises site and fail back to primary site, during disaster recovery with Azure Site Recovery.

-# Fail over and fail back Hyper-V VMs replicated to your secondary on-premises site

-The [Azure Site Recovery](site-recovery-overview.md) service manages and orchestrates replication, failover, and failback of on-premises machines, and Azure virtual machines (VMs).

-This article describes how to fail over a Hyper-V VM managed in a System Center Virtual Machine Manager (VMM) cloud, to a secondary VMM site. After you've failed over, you fail back to your on-premises site when it's available. In this article, you learn how to:

-> [!div class="checklist"]

-> * Fail over a Hyper-V VM from a primary VMM cloud to a secondary VMM cloud

-> * Reprotect from the secondary site to the primary, and fail back

-> * Optionally start replicating from primary to secondary again

-## Failover and failback

-Failover and failback has three stages:

-1. **Fail over to secondary site**: Fail machines over from the primary site to the secondary.

-2. **Fail back from the secondary site**: Replicate VMs from secondary to primary, and run a planned failover to fail back.

-3. After the planned failover, optionally start replicating from the primary site to the secondary again.

-## Prerequisites

-## Run a failover from primary to secondary

-You can run a regular or planned failover for Hyper-V VMs.

- This procedure describes how to run a regular failover.

-1. In **Settings** > **Replicated items** click the VM > **Failover**.

-1. Select **Shut down machine before beginning failover** if you want Site Recovery to attempt to do a shutdown of source VMs before triggering the failover. Site Recovery will also try to synchronize on-premises data that hasn't yet been sent to the secondary site, before triggering the failover. Note that failover continues even if shutdown fails. You can follow the failover progress on the **Jobs** page.

-2. You should now be able to see the VM in the secondary VMM cloud.

-3. After you verify the VM, **Commit** the failover. This deletes all the available recovery points.

-> [!WARNING]

-> **Don't cancel a failover in progress**: Before failover is started, VM replication is stopped. If you cancel a failover in progress, failover stops, but the VM won't replicate again.

-## Reverse replicate and failover

-Start replicating from the secondary site to the primary, and fail back to the primary site. After VMs are running in the primary site again, you can replicate them to the secondary site.

-

-1. Click the VM > click on **Reverse Replicate**.

-2. Once the job is complete, click the VM >In **Failover**, verify the failover direction (from secondary VMM cloud), and select the source and target locations.

-4. Initiate the failover. You can follow the failover progress on the **Jobs** tab.

-5. In the primary VMM cloud, check that the VM is available.

-6. If you want to start replicating the primary VM back to the secondary site again, click on **Reverse Replicate**.

-## Next steps

-[Review the step](hyper-v-vmm-disaster-recovery.md) for replicating Hyper-V VMs to a secondary site.

-description: Describes how to set up IP addressing for connecting to VMs in a secondary on-premises site after disaster recovery and failover with Azure Site Recovery.

-# Set up IP addressing to connect to a secondary on-premises site after failover

-After you fail over Hyper-V VMs in System Center Virtual Machine Manager (VMM) clouds to a secondary site, you need to be able connect to the replica VMs. This article helps you to do this.

-## Connection options

-After failover, there are a couple of ways to handle IP addressing for replica VMs:

-

-## Retain the IP address

-If you want to retain the IP addresses from the primary site, after failover to the secondary site, you can:

-### Deploy a stretched subnet

-In a stretched configuration, the subnet is available simultaneously in both the primary and secondary sites. In a stretched subnet, when you move a machine and its IP (Layer 3) address configuration to the secondary site, the network automatically routes the traffic to the new location.

-### Fail over a subnet

-You can fail over the entire subnet to obtain the benefits of the stretched subnet, without actually stretching it. In this solution, a subnet is available in the source or target site, but not in both simultaneously.

-#### Example

-Here's an example of complete subnet failover.

-The following graphics illustrate the subnets before and after failover.

-**Before failover**

-

-**After failover**

-

-After failover, Site Recovery allocates an IP address for each network interface on the VM. The address is allocated from the static IP address pool in the relevant network, for each VM instance.

-### Validate the IP address

-After you enable protection for a VM, you can use following sample script to verify the address assigned to the VM. This IP address is set as the failover IP address, and assigned to the VM at the time of failover:

-```powershell

-$vm = Get-SCVirtualMachine -Name <VM_NAME>

-$na = $vm[0].VirtualNetworkAdapters>

-$ip = Get-SCIPAddress -GrantToObjectID $na[0].id

-$ip.address

-```

-## Use a different IP address

-In this scenario, the IP addresses of VMs that fail over are changed. The drawback of this solution is the maintenance required. DNS and cache entries might need to be updated. This can result in downtime, which can be mitigated as follows:

- ```powershell

- param(

- string]$Zone,

- [string]$name,

- [string]$IP

- )

- $Record = Get-DnsServerResourceRecord -ZoneName $zone -Name $name

- $newrecord = $record.clone()

- $newrecord.RecordData[0].IPv4Address = $IP

- Set-DnsServerResourceRecord -zonename $zone -OldInputObject $record -NewInputObject $Newrecord

- ```

-

-### Example

-In this example we have different IP addresses across primary and secondary sites, and there's a third site from which applications hosted on the primary or recovery site can be accessed.

-**Before failover**

-

-**After failover**

-

-## Next steps

-[Run a failover](hyper-v-vmm-failover-failback.md)

-description: This article provides information about performance testing for replication of Hyper-V VMs in VMM clouds to a secondary site using Azure Site Recovery.

-# Test results for Hyper-V replication to a secondary site

-This article provides the results of performance testing when replicating Hyper-V VMs in System Center Virtual Machine Manager (VMM) clouds, to a secondary datacenter.

-## Test goals

-The goal of testing was to examine how Site Recovery performs during steady state replication.

-## What we did

-Here's what we did in the test pass:

-1. Created VMs using VMM templates.

-2. Started VMs, and captured baseline performance metrics over 12 hours.

-3. Created clouds on the primary and recovery VMM servers.

-4. Configured replication in Site Recovery, including mapping between source and recovery clouds.

-5. Enabled protection for VMs, and allowed them to complete initial replication.

-6. Waited a couple of hours for system stabilization.

-7. Captured performance metrics over 12 hours, where all VMs remained in an expected replication state for those 12 hours.

-8. Measured the delta between the baseline performance metrics, and the replication performance metrics.

-## Primary server performance

-* Hyper-V Replica (used by Site Recovery) asynchronously tracks changes to a log file, with minimum storage overhead on the primary server.

-* Hyper-V Replica utilizes self-maintained memory cache to minimize IOPS overhead for tracking. It stores writes to the VHDX in memory, and flushes them into the log file before the time that the log is sent to the recovery site. A disk flush also happens if the writes hit a predetermined limit.

-* The graph below shows the steady state IOPS overhead for replication. We can see that the IOPS overhead due to replication is around 5%, which is quite low.

- 

-Hyper-V Replica uses memory on the primary server, to optimize disk performance. As shown in the following graph, memory overhead on all servers in the primary cluster is marginal. The memory overhead shown is the percentage of memory used by replication, compared to the total installed memory on the Hyper-V server.

-

-Hyper-V Replica has minimum CPU overhead. As shown in the graph, replication overhead is in the range of 2-3%.

-

-## Secondary server performance

-Hyper-V Replica uses a small amount of memory on the recovery server, to optimize the number of storage operations. The graph summarizes the memory usage on the recovery server. The memory overhead shown is the percentage of memory used by replication, compared to the total installed memory on the Hyper-V server.

-

-The amount of I/O operations on the recovery site is a function of the number of write operations on the primary site. LetΓÇÖs look at the total I/O operations on the recovery site in comparison with the total I/O operations and write operations on the primary site. The graphs show that the total IOPS on the recovery site is

-* Around 1.5 times the write IOPS on the primary.

-* Around 37% of the total IOPS on the primary site.

-

-

-## Effect on network utilization

-An average of 275 Mb per second of network bandwidth was used between the primary and recovery nodes (with compression enabled), against an existing bandwidth of 5 Gb per second.

-

-## Effect on VM performance

-An important consideration is the impact of replication on production workloads running on the virtual machines. If the primary site is adequately provisioned for replication, there shouldnΓÇÖt be any impact on the workloads. Hyper-V ReplicaΓÇÖs lightweight tracking mechanism ensures that workloads running in the virtual machines are not impacted during steady-state replication. This is illustrated in the following graphs.

-This graph shows IOPS performed by virtual machines running different workloads, before and after replication was enabled. You can observe that there is no difference between the two.

-

-The following graph shows the throughput of virtual machines running different workloads, before and after replication was enabled. You can observe that replication has no significant impact.

-

-## Conclusion

-The results clearly show that Site Recovery, coupled with Hyper-V Replica, scales well with minimum overhead for a large cluster. Site Recovery provides simple deployment, replication, management and monitoring. Hyper-V Replica provides the necessary infrastructure for successful replication scaling.

-## Test environment details

-### Primary site

-* The primary site has a cluster containing five Hyper-V servers, running 470 virtual machines.

-* The VMs run different workloads, and all have Site Recovery protection enabled.

-* Storage for the cluster node is provided by an iSCSI SAN. Model ΓÇô Hitachi HUS130.

-* Each cluster server has four network cards (NICs) of one Gbps each.

-* Two of the network cards are connected to an iSCSI private network, and two are connected to an external enterprise network. One of the external networks is reserved for cluster communications only.

-

-| Server | RAM | Model | Processor | Number of processors | NIC | Software |

-| | | | | | | |

-| Hyper-V servers in cluster: <br />ESTLAB-HOST11<br />ESTLAB-HOST12<br />ESTLAB-HOST13<br />ESTLAB-HOST14<br />ESTLAB-HOST25 |128<br />ESTLAB-HOST25 has 256 |Dell Γäó PowerEdge Γäó R820 |Intel(R) Xeon(R) CPU E5-4620 0 \@ 2.20GHz |4 |I Gbps x 4 |Windows Server Datacenter 2012 R2 (x64) + Hyper-V role |

-| VMM Server |2 | | |2 |1 Gbps |Windows Server Database 2012 R2 (x64) + VMM 2012 R2 |

-### Secondary site

-* The secondary site has a six-node failover cluster.

-* Storage for the cluster node is provided by an iSCSI SAN. Model ΓÇô Hitachi HUS130.

-

-| Server | RAM | Model | Processor | Number of processors | NIC | Software |

-| | | | | | | |

-| Hyper-V servers in cluster: <br />ESTLAB-HOST07<br />ESTLAB-HOST08<br />ESTLAB-HOST09<br />ESTLAB-HOST10 |96 |Dell Γäó PowerEdge Γäó R720 |Intel(R) Xeon(R) CPU E5-2630 0 \@ 2.30GHz |2 |I Gbps x 4 |Windows Server Datacenter 2012 R2 (x64) + Hyper-V role |

-| ESTLAB-HOST17 |128 |Dell Γäó PowerEdge Γäó R820 |Intel(R) Xeon(R) CPU E5-4620 0 \@ 2.20GHz |4 | |Windows Server Datacenter 2012 R2 (x64) + Hyper-V role |

-| ESTLAB-HOST24 |256 |Dell Γäó PowerEdge Γäó R820 |Intel(R) Xeon(R) CPU E5-4620 0 \@ 2.20GHz |2 | |Windows Server Datacenter 2012 R2 (x64) + Hyper-V role |

-| VMM Server |2 | | |2 |1 Gbps |Windows Server Database 2012 R2 (x64) + VMM 2012 R2 |

-### Server workloads

-* For test purposes we picked workloads commonly used in enterprise customer scenarios.

-* We use [IOMeter](http://www.iometer.org) with the workload characteristic summarized in the table for simulation.

-* All IOMeter profiles are set to write random bytes to simulate worst-case write patterns for workloads.

-| Workload | I/O size (KB) | % Access | %Read | Outstanding I/Os | I/O pattern |

-| | | | | | |

-| File Server |4<br />8<br />16<br />32<br />64 |60%<br />20%<br />5%<br />5%<br />10% |80%<br />80%<br />80%<br />80%<br />80% |8<br />8<br />8<br />8<br />8 |All 100% random |

-| SQL Server (volume 1)<br />SQL Server (volume 2) |8<br />64 |100%<br />100% |70%<br />0% |8<br />8 |100% random<br />100% sequential |

-| Exchange |32 |100% |67% |8 |100% random |

-| Workstation/VDI |4<br />64 |66%<br />34% |70%<br />95% |1<br />1 |Both 100% random |

-| Web File Server |4<br />8<br />64 |33%<br />34%<br />33% |95%<br />95%<br />95% |8<br />8<br />8 |All 75% random |

-### VM configuration

-* 470 VMs on the primary cluster.

-* All VMs with VHDX disk.

-* VMs running workloads summarized in the table. All were created with VMM templates.

-| Workload | # VMs | Minimum RAM (GB) | Maximum RAM (GB) | Logical disk size (GB) per VM | Maximum IOPS |

-| | | | | | |

-| SQL Server |51 |1 |4 |167 |10 |

-| Exchange Server |71 |1 |4 |552 |10 |

-| File Server |50 |1 |2 |552 |22 |

-| VDI |149 |.5 |1 |80 |6 |

-| Web server |149 |.5 |1 |80 |6 |

-| TOTAL |470 | | |96.83 TB |4108 |

-### Site Recovery settings

-* Site Recovery was configured for on-premises to on-premises protection

-* The VMM server has four clouds configured, containing the Hyper-V cluster servers and their VMs.

-| Primary VMM cloud | Protected VMs | Replication frequency | Additional recovery points |

-| | | | |

-| PrimaryCloudRpo15m |142 |15 mins |None |

-| PrimaryCloudRpo30s |47 |30 secs |None |

-| PrimaryCloudRpo30sArp1 |47 |30 secs |1 |

-| PrimaryCloudRpo5m |235 |5 mins |None |

-### Performance metrics

-The table summarizes the performance metrics and counters that were measured in the deployment.

-| Metric | Counter |

-| | |

-| CPU |\Processor(_Total)\% Processor Time |

-| Available memory |\Memory\Available MBytes |

-| IOPS |\PhysicalDisk(_Total)\Disk Transfers/sec |

-| VM read (IOPS) operations/sec |\Hyper-V Virtual Storage Device(\<VHD>)\Read Operations/Sec |

-| VM write (IOPS) operations/sec |\Hyper-V Virtual Storage Device(\<VHD>)\Write Operations/S |

-| VM read throughput |\Hyper-V Virtual Storage Device(\<VHD>)\Read Bytes/sec |

-| VM write throughput |\Hyper-V Virtual Storage Device(\<VHD>)\Write Bytes/sec |

-## Next steps

-[Set up replication](hyper-v-vmm-disaster-recovery.md)

-description: Learn how to add a VMM script to a recovery plan for disaster recovery of Hyper-V VMs in VMM clouds.

-# Add a VMM script to a recovery plan

-This article describes how to create a System Center Virtual Machine Manager (VMM) script and add it to a recovery plan in [Azure Site Recovery](site-recovery-overview.md).

-Post any comments or questions at the bottom of this article, or on the [Microsoft Q&A question page for Azure Recovery Services](/answers/topics/azure-site-recovery.html).

-## Prerequisites

-You can use PowerShell scripts in your recovery plans. To be accessible from the recovery plan, you must author the script and place the script in the VMM library. Keep the following considerations in mind while you write the script:

-* Ensure that scripts use try-catch blocks, so that exceptions are handled gracefully.

- - If an exception occurs in the script, the script stops running, and the task shows as failed.

- - If an error occurs, the remainder of the script doesn't run.

- - If an error occurs when you run an unplanned failover, the recovery plan continues.

- - If an error occurs when you run a planned failover, the recovery plan stops. Fix the script, check that it runs as expected, and then run the recovery plan again.

- - The `Write-Host` command doesnΓÇÖt work in a recovery plan script. If you use the `Write-Host` command in a script, the script fails. To create output, create a proxy script that in turn runs your main script. To ensure that all output is piped out, use the **\>\>** command.

- - The script times out if it doesn't return within 600 seconds.

- - If anything is written to STDERR, the script is classified as failed. This information is displayed in the script execution details.

-* Scripts in a recovery plan run in the context of the VMM service account. Ensure that this account has read permissions for the remote share on which the script is located. Test the script to run with the same level of user rights as the VMM service account.

-* VMM cmdlets are delivered in a Windows PowerShell module. The module is installed when you install the VMM console. To load the module into your script, use the following command in the script:

- `Import-Module -Name virtualmachinemanager`

- For more information, see [Get started with Windows PowerShell and VMM](/previous-versions/system-center/system-center-2012-R2/hh875013(v=sc.12)).

-* Ensure that you have at least one library server in your VMM deployment. By default, the library share path for a VMM server is located locally on the VMM server. The folder name is MSCVMMLibrary.

- If your library share path is remote (or if it's local but not shared with MSCVMMLibrary), configure the share as follows, using \\libserver2.contoso.com\share\ as an example:

-

- 1. Open the Registry Editor, and then go to **HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Azure Site Recovery\Registration**.

- 1. Change the value for **ScriptLibraryPath** to **\\\libserver2.contoso.com\share\\**. Specify the full FQDN. Provide permissions to the share location. This is the root node of the share. To check for the root node, in VMM, go to the root node in the library. The path that opens is the root of the path. This is the path that you must use in the variable.

- 1. Test the script by using a user account that has the same level of user rights as the VMM service account. Using these user rights verifies that standalone, tested scripts run the same way that they run in recovery plans. On the VMM server, set the execution policy to bypass, as follows:

- a. Open the **64-bit Windows PowerShell** console as an administrator.

-

- b. Enter **Set-executionpolicy bypass**. For more information, see [Using the Set-ExecutionPolicy cmdlet](/previous-versions/windows/it-pro/windows-powershell-1.0/ee176961(v=technet.10)).

- > [!IMPORTANT]

- > Set **Set-executionpolicy bypass** only in the 64-bit PowerShell console. If you set it for the 32-bit PowerShell console, the scripts don't run.

-## Add the script to the VMM library

-If you have a VMM source site, you can create a script on the VMM server. Then, include the script in your recovery plan.

-1. In the library share, create a new folder. For example, \<VMM server name>\MSSCVMMLibrary\RPScripts. Place the folder on the source and target VMM servers.

-1. Create the script. For example, name the script RPScript. Verify that the script works as expected.

-1. Place the script in the \<VMM server name>\MSSCVMMLibrary folder on the source and target VMM servers.

-## Add the script to a recovery plan

-After you've added VMs or replication groups to a recovery plan and created the plan, you can add the script to the group.

-1. Open the recovery plan.

-1. In the **Step** list, select an item. Then, select either **Script** or **Manual Action**.

-1. Specify whether to add the script or action before or after the selected item. To move the position of the script up or down, select the **Move Up** and **Move Down** buttons.

-1. If you add a VMM script, select **Failover to VMM script**. In **Script Path**, enter the relative path to the share. For example, enter **\RPScripts\RPScript.PS1**.

-1. If you add an Azure Automation runbook, specify the Automation account in which the runbook is located. Then, select the Azure runbook script that you want to use.

-1. To ensure that the script works as expected, do a test failover of the recovery plan.

-## Next steps

-* Learn more about [running failovers](site-recovery-failover.md).

-description: Learn how to run a DR drill for Hyper-V VMs in VMM clouds to a secondary on-premises datacenter using Azure Site Recovery.

-# Run a DR drill for Hyper-V VMs to a secondary site

-This article describes how to do a disaster recovery (DR) drill for Hyper-V VMs that are managed in System Center Virtual Machine Manager V(MM) clouds, to a secondary on-premises site, using [Azure Site Recovery](site-recovery-overview.md).

-You run a test failover to validate your replication strategy, and perform a DR drill without any data loss or downtime. A test failover doesn't have any impact on the ongoing replication, or on your production environment.

-## How do test failovers work?

-You run a test failover from the primary to the secondary site. If you simply want to check that a VM fails over, you can run a test failover without setting anything up on the secondary site. If you want to verify app failover works as expected, you will need to set up networking and infrastructure in the secondary location.

- - You can run a test failover without a network. This option is useful if you simply want to check that a VM was able to fail over, but you won't be able to verify any network configuration.

- - Run the failover with an existing network. We recommend you don't use a production network.

- - Run the failover and let Site Recovery automatically create a test network. In this case Site Recovery will create the network automatically, and clean it up when test failover is complete.

- - **Latest processed**: This option fails a VM over to the latest recovery point processed by Site Recovery. This option provides a low RTO (Recovery Time Objective), because no time is spent processing unprocessed data.

- - **Latest app-consistent**: This option fail over a VM to the latest application-consistent recovery point processed by Site Recovery.

- - **Latest**: This option first processes all the data that has been sent to Site Recovery service, to create a recovery point for each VM before failing over to it. This option provides the lowest RPO (Recovery Point Objective), because the VM created after failover will have all the data replicated to Site Recovery when the failover was triggered.

- - **Latest multi-VM processed**: Available for recovery plans that include one or more VMs that have multi-VM consistency enabled. VMs with the setting enabled fail over to the latest common multi-VM consistent recovery point. Other VMs fail over to the latest processed recovery point.

- - **Latest multi-VM app-consistent**: This option is available for recovery plans with one or more VMs that have multi-VM consistency enabled. VMs that are part of a replication group fail over to the latest common multi-VM application-consistent recovery point. Other VMs fail over to their latest application-consistent recovery point.

- - **Custom**: Use this option to fail over a specific VM to a particular recovery point.

-## Prepare networking

-When you run a test failover, you're asked to select network settings for test replica machines, as summarized in the table.

-| **Option** | **Details** |

-| | |

-| **None** | The test VM is created on the host on which the replica VM is located. It isn't added to the cloud, and isn't connected to any network.<br/><br/> You can connect the machine to a VM network after it has been created.|

-| **Use existing** | The test VM is created on the host on which the replica VM is located. It isn't added to the cloud.<br/><br/>Create a VM network that's isolated from your production network.<br/><br/>If you're using a VLAN-based network, we recommend that you create a separate logical network (not used in production) in VMM for this purpose. This logical network is used to create VM networks for test failovers.<br/><br/>The logical network should be associated with at least one of the network adapters of all the Hyper-V servers that are hosting virtual machines.<br/><br/>For VLAN logical networks, the network sites that you add to the logical network should be isolated.<br/><br/>If you're using a Windows Network VirtualizationΓÇôbased logical network, Azure Site Recovery automatically creates isolated VM networks. |

-| **Create a network** | A temporary test network is created automatically based on the setting that you specify in **Logical Network** and its related network sites.<br/><br/> Failover checks that VMs are created.<br/><br/> You should use this option if a recovery plan uses more than one VM network.<br/><br/> If you're using Windows Network Virtualization networks, this option can automatically create VM networks with the same settings (subnets and IP address pools) in the network of the replica virtual machine. These VM networks are cleaned up automatically after the test failover is complete.<br/><br/> The test VM is created on the host on which the replica virtual machine exists. It isn't added to the cloud.|

-### Best practices

- - If the replica uses DHCP and VLAN-based isolation, the VM network for the replica doesn't need a static IP address pool. So using Windows Network Virtualization for the test failover won't work because no address pools are available.

-

- - Test failover won't work if the replica network uses no isolation, and the test network uses Windows Network Virtualization. This is because the no-isolation network doesn't have the subnets required to create a Windows Network Virtualization network.

-

-### VM network configured with no isolation or VLAN isolation

-If a VM network is configured in VMM with no isolation, or VLAN isolation, note the following:

-### VM network with Windows Network Virtualization

-If a VM network is configured in VMM with Windows Network Virtualization, note the following:

-## Prepare the infrastructure

-If you simply want to check that a VM can fail over, you can run a test failover without an infrastructure. If you want to do a full DR drill to test app failover, you need to prepare the infrastructure at the secondary site:

-### Prepare DHCP

-If the virtual machines involved in test failover use DHCP, create a test DHCP server within the isolated network for the purpose of test failover.

-### Prepare Active Directory

-To run a test failover for application testing, you need a copy of the production Active Directory environment in your test environment. For more information, review the [test failover considerations for Active Directory](site-recovery-active-directory.md#test-failover-considerations).

-### Prepare DNS

-Prepare a DNS server for the test failover as follows:

-* **DHCP**: If virtual machines use DHCP, the IP address of the test DNS should be updated on the test DHCP server. If you're using a network type of Windows Network Virtualization, the VMM server acts as the DHCP server. Therefore, the IP address of DNS should be updated in the test failover network. In this case, the virtual machines register themselves to the relevant DNS server.

-* **Static address**: If virtual machines use a static IP address, the IP address of the test DNS server should be updated in test failover network. You might need to update DNS with the IP address of the test virtual machines. You can use the following sample script for this purpose:

- ```powershell

- Param(

- [string]$Zone,

- [string]$name,

- [string]$IP

- )

- $Record = Get-DnsServerResourceRecord -ZoneName $zone -Name $name

- $newrecord = $record.clone()

- $newrecord.RecordData[0].IPv4Address = $IP

- Set-DnsServerResourceRecord -zonename $zone -OldInputObject $record -NewInputObject $Newrecord

- ```

-## Run a test failover

-This procedure describes how to run a test failover for a recovery plan. Alternatively, you can run the failover for a single virtual machine on the **Virtual Machines** tab.

-1. Select **Recovery Plans** > *recoveryplan_name*. Click **Failover** > **Test Failover**.

-2. On the **Test Failover** blade, specify how replica VMs should be connected to networks after the test failover.

-3. Track failover progress on the **Jobs** tab.

-4. After failover is complete, verify that the VMs start successfully.

-5. When you're done, click **Cleanup test failover** on the recovery plan. In **Notes**, record and save any observations associated with the test failover. This step deletes any VMs and networks that were created by Site Recovery during test failover.

-

-

-> [!TIP]

-> The IP address given to a virtual machine during test failover is the same IP address that the virtual machine would receive for a planned or unplanned failover (presuming that the IP address is available in the test failover network). If the same IP address isn't available in the test failover network, the virtual machine receives another IP address that's available in the test failover network.

-### Run a test failover to a production network

-We recommend that you don't run a test failover to your production recovery site network that you specified during network mapping. But if you do need to validate end-to-end network connectivity in a failed-over VM, note the following points:

-* Make sure that the primary VM is shut down when you're doing the test failover. If you don't, two virtual machines with the same identity will be running in the same network at the same time. That situation can lead to undesired consequences.

-* Any changes that you make to the test failover VMs are lost when you clean up the test failover virtual machines. These changes are not replicated back to the primary VMs.

-* Testing like this leads to downtime for your production application. Ask users of the application not to use the application when the DR drill is in progress.

-## Next steps

-After you have successfully run a DR drill, you can [run a full failover](site-recovery-failover.md).

- 

- 

-description: Details about Upcoming deprecation of DR between customer owned sites using Hyper-V and between sites managed by SCVMM to Azure and alternate options

-# Deprecation of disaster recovery between customer-managed sites (with VMM) using Azure Site Recovery

-This article describes the upcoming deprecation plan, the corresponding implications, and the alternative options available for the customers for the following scenario:

-DR between customer owned sites managed by System Center Virtual Machine Manager (SCVMM) using Site Recovery

-> [!IMPORTANT]

-> Customers are advised to take the remediation steps at the earliest to avoid any disruption to their environment.

-## What changes should you expect?

-

-## Alternatives

-Below are the alternatives that the customer can choose from to ensure that their DR strategy is not impacted once the scenario is deprecated.

-## Remediation steps

-If you are choosing to go with Option 1, please execute the following steps:

-1. [Disable protection of all the virtual machines associated with the VMMs](site-recovery-manage-registration-and-protection.md#disable-protection-for-a-hyper-v-virtual-machine-replicating-to-secondary-vmm-server-using-the-system-center-vmm-to-vmm-scenario). Use the **Disable replication and remove** option or run the scripts mentioned to ensure the replication settings on-premises are cleaned up.

-2. [Unregister all the VMM servers](site-recovery-manage-registration-and-protection.md#unregister-a-vmm-server) from the site-to-site replication configuration.

-3. [Prepare Azure resources](tutorial-prepare-azure-for-hyperv.md) for enabling replication of your VMs.

-4. [Prepare on-premises Hyper-V servers](hyper-v-prepare-on-premises-tutorial.md)

-5. [Set up replication for the VMs in the VMM cloud](hyper-v-vmm-azure-tutorial.md)

-6. Optional but recommended: [Run a DR drill](tutorial-dr-drill-azure.md)

-If you are choosing to go with Option 2 of using Hyper-V replica, execute the following steps:

-1. In **Protected Items** > **Replicated Items**, right-click the machine > **Disable replication**.

-2. In **Disable replication**, select **Remove**.

- This removes the replicated item from Azure Site Recovery (billing is stopped). Replication configuration on the on-premises virtual machine **will not** be cleaned up.

-## Next steps

-Plan for the deprecation and choose an alternate option that's best suited for your infrastructure and business. In case you have any queries regarding this, reach out to Microsoft Support

-## Before you start

-Verify properties as follows:

-2. In the **Replicated item** pane, there's a summary of VM information, health status, and the

- latest available recovery points. Select **Properties** to view more details.

-If your on-premises environment is not ready or in case of any challenges, you can cancel the planned failover

-You can perform a planned failover any time later, once your on-premises conditions turn favorable.

-> [!div class="nextstepaction"]

-> [Reprotect Azure VMs](failover-failback-overview-modernized.md)

-> [Fail back from Azure](failover-failback-overview-modernized.md)

-For information about failover in modernized release, [see this article](vmware-azure-tutorial-failover-failback-modernized.md).

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Verify that the VMware VM properties conform with Azure requirements.

-> * Fail over specific VMs to Azure.

-> [!NOTE]

-> Tutorials show you the simplest deployment path for a scenario. They use default options where possible and don't show all possible settings and paths. If you want to learn about failover in detail, see [Fail over VMs and physical servers](site-recovery-failover.md).

-[Learn about](failover-failback-overview.md#types-of-failover) different types of failover. If you want to fail over multiple VMs in a recovery plan, review [this article](site-recovery-failover.md).

-## Before you start

-Complete the previous tutorials:

-1. Make sure you've [set up Azure](tutorial-prepare-azure.md) for on-premises disaster recovery of VMware VMs, Hyper-V VMs, and physical machines to Azure.

-> [!div class="nextstepaction"]

-> [Reprotect Azure VMs](vmware-azure-reprotect.md)

-> [Fail back from Azure](vmware-azure-failback.md)

-description: Learn how to set up disaster recovery of VMware VMs, or Windows and Linux physical servers, to a secondary site with Azure Site Recovery.

-# Set up disaster recovery of on-premises VMware virtual machines or physical servers to a secondary site

-InMage Scout in [Azure Site Recovery](site-recovery-overview.md) provides real-time replication between on-premises VMware sites. InMage Scout is included in Azure Site Recovery service subscriptions.

-## End-of-support announcement

-The Azure Site Recovery scenario for replication between on-premises VMware or physical datacenters is reaching end-of-support.

-During 2018 and 2019, two updates will be released:

-After Update 8, no further updates will be released. There will be limited hotfix support for the operating systems added in Update 8, and bug fixes based on best effort.

-Azure Site Recovery continues to innovate by providing VMware and Hyper-V customers a seamless and best-in-class DRaaS solution with Azure as a disaster recovery site. Microsoft recommends that existing InMage / ASR Scout customers consider using Azure Site RecoveryΓÇÖs VMware to Azure scenario for their business continuity needs. Azure Site Recovery's VMware to Azure scenario is an enterprise-class DR solution for VMware applications, which offers RPO and RTO of minutes, support for multi-VM application replication and recovery, seamless onboarding, comprehensive monitoring, and significant TCO advantage.

-### Scenario migration

-As an alternative, we recommend setting up disaster recovery for on-premises VMware VMs and physical machines by replicating them to Azure. Do this as follows:

-1. Review the quick comparison below. Before you can replicate on-premises machines, you need check that they meet [requirements](./vmware-physical-azure-support-matrix.md#replicated-machines) for replication to Azure. If youΓÇÖre replicating VMware VMs, we recommend that you review [capacity planning guidelines](./site-recovery-plan-capacity-vmware.md), and run the [Deployment Planner tool](./site-recovery-deployment-planner.md) to identity capacity requirements, and verify compliance.

-2. After running the Deployment Planner, you can set up replication:

-o For VMware VMs, follow these tutorials to [prepare Azure](./tutorial-prepare-azure.md), [prepare your on-premises VMware environment](./vmware-azure-tutorial-prepare-on-premises.md), and [set up disaster recovery](./vmware-azure-tutorial-prepare-on-premises.md).

-o For physical machines, follow this [tutorial](./physical-azure-disaster-recovery.md).

-3. After machines are replicating to Azure, you can run a [disaster recovery drill](./site-recovery-test-failover-to-azure.md) to make sure everythingΓÇÖs working as expected.

-### Quick comparison

-**Feature** | **Replication to Azure** |**Replication between VMware datacenters**

-**Required components** |Mobility service on replicated machines. On-premises configuration server, process server, master target server.Temporary process server in Azure for failback.|Mobility service, Process Server, Configuration Server and Master Target

-**Configuration and orchestration** |Recovery Services vault in the Azure portal | Using vContinuum

-**Replicated** |Disk (Windows and Linux) |Volume-Windows<br> Disk-Linux

-**Shared disk cluster** |Not supported|Supported

-**Data churn limits (average)** |10 MB/s data per disk<br> 25MB/s data per VM<br> [Learn more](./site-recovery-vmware-deployment-planner-analyze-report.md#azure-site-recovery-limits) | > 10 MB/s data per disk <br> > 25 MB/s data per VM

-**Monitoring** |From Azure portal|From CX (Configuration Server)

-**Support Matrix** | [Click here for details](./vmware-physical-azure-support-matrix.md)|[Download ASR Scout compatible matrix](https://aka.ms/asr-scout-cm)

-## Prerequisites

-To complete this tutorial:

-## Download and install component updates

- Review and install the latest [updates](#updates). Updates should be installed on servers in the following order:

-1. RX server (if applicable)

-2. Configuration servers

-3. Process servers

-4. Master Target servers

-5. vContinuum servers

-6. Source server (both Windows and Linux Servers)

-Install the updates as follows:

-> [!NOTE]

->All Scout components' file update version may not be the same in the update .zip file. The older version indicate that there is no change in the component since previous update to this update.

-Download the [update](https://aka.ms/asr-scout-update7) .zip file and the [MySQL and PHP upgrade](https://aka.ms/asr-scout-u7-mysql-php-manualupgrade) configuration files. The update .zip file contains the all the base binaries and cumulative upgrade binaries of the following components:

- 1. Extract the .zip files.

- 2. **RX server**: Copy **RX_8.0.7.0_GA_Update_7_2965621_28Dec18.tar.gz** to the RX server, and extract it. In the extracted folder, run **/Install**.

- 3. **Configuration server and process server**: Copy **CX_Windows_8.0.7.0_GA_Update_7_2965621_28Dec18.exe** to the configuration server and process server. Double-click to run it.<br>

- 4. **Windows Master Target server**: To update the unified agent, copy **InMage_UA_8.0.7.0_Windows_GA_27Dec2018_release.exe** to the server. Double-click it to run it. The same file can also be used for fresh installation. The same unified agent update is also applicable for the source server.

- The update does not need to apply on the Master target prepared with **InMage_Scout_vContinuum_MT_8.0.7.0_Windows_GA_27Dec2018_release.exe** as this is new GA installer with all the latest changes.

- 5. **vContinuum server**: Copy **InMage_Scout_vContinuum_MT_8.0.7.0_Windows_GA_27Dec2018_release.exe** to the server. Make sure that you've closed the vContinuum wizard. Double-click on the file to run it.

- 6. **Linux master target server**: To update the unified agent, copy **InMage_UA_8.0.7.0_RHEL6-64_GA_03Dec2018_release.tar.gz** to the Linux Master Target server and extract it. In the extracted folder, run **/Install**.

- 7. **Windows source server**: To update the unified agent, copy **InMage_UA_8.0.7.0_Windows_GA_27Dec2018_release.exe** to the source server. Double-click on the file to run it.

- 8. **Linux source server**: To update the unified agent, copy the corresponding version of the unified agent file to the Linux server, and extract it. In the extracted folder, run **/Install**. Example: For RHEL 6.7 64-bit server, copy **InMage_UA_8.0.7.0_RHEL6-64_GA_03Dec2018_release.tar.gz** to the server, and extract it. In the extracted folder, run **/Install**.

- 9. After upgrading Configuration Server, Process Server and RX server with the above mentioned installers, the PHP and MySQL libraries needs to be upgraded manually with steps mentioned in section 7.4 of the [quick installation guide](https://aka.ms/asr-scout-quick-install-guide).

-## Enable replication

-1. Set up replication between the source and target VMware sites.

-2. Refer to following documents to learn more about installation, protection, and recovery:

- * [Release notes](https://aka.ms/asr-scout-release-notes)

- * [Compatibility matrix](https://aka.ms/asr-scout-cm)

- * [User guide](https://aka.ms/asr-scout-user-guide)

- * [RX user guide](https://aka.ms/asr-scout-rx-user-guide)

- * [Quick installation guide](https://aka.ms/asr-scout-quick-install-guide)

- * [Upgrading MYSQL and PHP libraries](https://aka.ms/asr-scout-u7-mysql-php-manualupgrade)

-## Updates

-### Site Recovery Scout 8.0.1 Update 7

-Updated: December 31, 2018

-Download [Scout update 7](https://aka.ms/asr-scout-update7).

-Scout Update 7 is a full installer which can be used for fresh installation as well as to upgrade existing agents/MT which are on previous updates (from Update 1 to Update 6). It contains all fixes from Update 1 to Update 6 plus the new fixes and enhancements described below.

-

-#### New features

-* PCI compliance

-* TLS v1.2 Support

-#### Bug and Security Fixes

-* Fixed: Windows Cluster/Standalone Machines have incorrect IP configuration upon recovery/DR-Drill.

-* Fixed: Sometimes Add disk operation fails for V2V cluster.

-* Fixed: vContinuum Wizard gets stuck during recovery phase if the Master Target is Windows Server 2016

-* Fixed: MySQL security issues are mitigated by upgrading MySQL to version 5.7.23

-#### Manual Upgrade for PHP and MySQL on CS,PS, and RX

-The PHP scripting platform should be upgraded to version 7.2.10 on Configuration Server, Process Server and RX Server.

-The MySQL database management system should be upgraded to version 5.7.23 on Configuration Server, Process Server and RX Server.

-Please follow the manual steps given in the [Quick installation guide](https://aka.ms/asr-scout-quick-install-guide) to upgrade PHP and MySQL versions.

-### Site Recovery Scout 8.0.1 Update 6

-Updated: October 12, 2017

-Download [Scout update 6](https://aka.ms/asr-scout-update6).

-Scout Update 6 is a cumulative update. It contains all fixes from Update 1 to Update 5 plus the new fixes and enhancements described below.

-#### New platform support

-* Support has been added for Source Windows Server 2016

-* Support has been added for following Linux operating systems:

- - Red Hat Enterprise Linux (RHEL) 6.9

- - CentOS 6.9

- - Oracle Linux 5.11

- - Oracle Linux 6.8

-* Support has been added for VMware Center 6.5

-Install the updates as follows:

-> [!NOTE]

->All Scout components' file update version may not be the same in the update .zip file. The older version indicate that there is no change in the component since previous update to this update.

-Download the [update](https://aka.ms/asr-scout-update6) .zip file. The file contains the following components:

- 1. Extract the .zip files.

- 2. **RX server**: Copy **RX_8.0.4.0_GA_Update_4_8725872_16Sep16.tar.gz** to the RX server, and extract it. In the extracted folder, run **/Install**.

- 3. **Configuration server and process server**: Copy **CX_Windows_8.0.6.0_GA_Update_6_13746667_18Sep17.exe** to the configuration server and process server. Double-click to run it.<br>

- 4. **Windows Master Target server**: To update the unified agent, copy **UA_Windows_8.0.5.0_GA_Update_5_11525802_20Apr17.exe** to the server. Double-click it to run it. The same unified agent update is also applicable for the source server. If source hasn't been updated to Update 4, you should update the unified agent.

- The update does not need to apply on the Master target prepared with **InMage_Scout_vContinuum_MT_8.0.1.0_Windows_GA_10Oct2017_release.exe** as this is new GA installer with all the latest changes.

- 5. **vContinuum server**: Copy **vCon_Windows_8.0.6.0_GA_Update_6_11525767_21Sep17.exe** to the server. Make sure that you've closed the vContinuum wizard. Double-click on the file to run it.

- The update does not need to apply on the Master Target prepared with **InMage_Scout_vContinuum_MT_8.0.1.0_Windows_GA_10Oct2017_release.exe** as this is new GA installer with all the latest changes.

- 6. **Linux master target server**: To update the unified agent, copy **UA_RHEL6-64_8.0.4.0_GA_Update_4_9035261_26Sep16.tar.gz** to the master target server and extract it. In the extracted folder, run **/Install**.

- 7. **Windows source server**: To update the unified agent, copy **UA_Windows_8.0.5.0_GA_Update_5_11525802_20Apr17.exe** to the source server. Double-click on the file to run it.

- You don't need to install the Update 5 agent on the source server if it has already been updated to Update 4 or source agent is installed with latest base installer **InMage_UA_8.0.1.0_Windows_GA_28Sep2017_release.exe**.

- 8. **Linux source server**: To update the unified agent, copy the corresponding version of the unified agent file to the Linux server, and extract it. In the extracted folder, run **/Install**. Example: For RHEL 6.7 64-bit server, copy **UA_RHEL6-64_8.0.4.0_GA_Update_4_9035261_26Sep16.tar.gz** to the server, and extract it. In the extracted folder, run **/Install**.

-> [!NOTE]

-> * Base Unified Agent(UA) installer for Windows has been refreshed to support Windows Server 2016. The new installer **InMage_UA_8.0.1.0_Windows_GA_28Sep2017_release.exe** is packaged with the base Scout GA package (**InMage_Scout_Standard_8.0.1 GA-Oct17.zip**). The same installer will be used for all supported Windows version.

-> * Base Windows vContinuum & Master Target installer has been refreshed to support Windows Server 2016. The new installer **InMage_Scout_vContinuum_MT_8.0.1.0_Windows_GA_10Oct2017_release.exe** is packaged with the base Scout GA package (**InMage_Scout_Standard_8.0.1 GA-Oct17.zip**). The same installer will be used to deploy Windows 2016 Master Target and Windows 2012R2 Master Target.

-> * Windows server 2016 on physical server is not supported by ASR Scout. It supports only Windows Server 2016 VMware VM.

->

-#### Bug fixes and enhancements

-### Site Recovery Scout 8.0.1 Update 5

-Scout Update 5 is a cumulative update. It contains all fixes from Update 1 to Update 4, and the new fixes described below.

-#### New platform support

-* SUSE Linux Enterprise Server 11 Service Pack 4(SP4)

-* SLES 11 SP4 64 bit **InMage_UA_8.0.1.0_SLES11-SP4-64_GA_13Apr2017_release.tar.gz** is packaged with the base Scout GA package (**InMage_Scout_Standard_8.0.1 GA.zip**). Download the GA package from the portal, as described in create a vault.

-#### Bug fixes and enhancements

-* Fixes for increased Windows cluster support reliability:

- * Fixed- Some of the P2V MSCS cluster disks become RAW after recovery.

- * Fixed- P2V MSCS cluster recovery fails due to a disk order mismatch.

- * Fixed- The MSCS cluster operation to add disks fails with a disk size mismatch error.

- * Fixed- The readiness check for the source MSCS cluster with RDM LUNs mapping fails in size verification.

- * Fixed- Single node cluster protection fails because of a SCSI mismatch issue.

- * Fixed- Re-protection of the P2V Windows cluster server fails if target cluster disks are present.

-

-* Fixed: During failback protection, if the selected master target server isn't on the same ESXi server as the protected source machine (during forward protection), then vContinuum picks up the wrong master target server during failback recovery, and the recovery operation fails.

-> [!NOTE]

-> * The P2V cluster fixes are applicable only to physical MSCS clusters that are newly protected with Site Recovery Scout Update 5. To install the cluster fixes on protected P2V MSCS clusters with older updates, follow the upgrade steps mentioned in section 12 of the [Site Recovery Scout Release Notes](https://aka.ms/asr-scout-release-notes).

-> * if at the time of re-protection, the same set of disks are active on each of the cluster nodes as they were when initially protected, then re-protection of a physical MSCS cluster can only reuse existing target disks. If not, then use the manual steps in section 12 of [Site Recovery Scout Release Notes](https://aka.ms/asr-scout-release-notes), to move the target side disks to the correct datastore path, for reuse during re-protection. If you reprotect the MSCS cluster in P2V mode without following the upgrade steps, it creates a new disk on the target ESXi server. You will need to manually delete the old disks from the datastore.

-> * When a source SLES11 or SLES11 (with any service pack) server is rebooted gracefully, then manually mark the **root** disk replication pairs for re-synchronization. There's no notification in the CX interface. If you don't mark the root disk for resynchronization, you might notice data integrity issues.

-### Azure Site Recovery Scout 8.0.1 Update 4

-Scout Update 4 is a cumulative update. It includes all fixes from Update 1 to Update 3, and the new fixes described below.

-#### New platform support

-* Support has been added for vCenter/vSphere 6.0, 6.1 and 6.2

-* Support has been added for these Linux operating systems:

- * Red Hat Enterprise Linux (RHEL) 7.0, 7.1 and 7.2

- * CentOS 7.0, 7.1 and 7.2

- * Red Hat Enterprise Linux (RHEL) 6.8

- * CentOS 6.8

-> [!NOTE]

-> RHEL/CentOS 7 64 bit **InMage_UA_8.0.1.0_RHEL7-64_GA_06Oct2016_release.tar.gz** is packaged with the base Scout GA package **InMage_Scout_Standard_8.0.1 GA.zip**. Download the Scout GA package from the portal as described in create a vault.

-#### Bug fixes and enhancements

-* Improved shutdown handling for the following Linux operating systems and clones, to prevent unwanted resynchronization issues:

- * Red Hat Enterprise Linux (RHEL) 6.x

- * Oracle Linux (OL) 6.x

-* For Linux, all folder access permissions in the unified agent installation directory are now restricted to the local user only.

-* On Windows, a fix for a timing out issue that occurred when issuing common distributed consistency bookmarks, on heavily loaded distributed applications such as SQL Server and SharePoint clusters.

-* A log related fix in the configuration server base installer.

-* A download link to VMware vCLI 6.0 was added to the Windows master target base installer.

-* Additional checks and logs were added, for network configuration changes during failover and disaster recovery drills.

-* A fix for an issue that caused retention information not to be reported to the configuration server.

-* For physical clusters, a fix for an issue that caused volume resizing to fail in the vContinuum wizard, when shrinking the source volume.

-* A fix for a cluster protection issue that failed with error: "Failed to find the disk signature", when the cluster disk is a PRDM disk.

-* A fix for a cxps transport server crash, caused by an out-of-range exception.

-* Server name and IP address columns are now resizable in the **Push Installation** page of the vContinuum wizard.

-* RX API enhancements:

- * The five latest available common consistency points now available (only guaranteed tags).

- * Capacity and free space details are displayed for all protected devices.

- * Scout driver state on the source server is available.

-> [!NOTE]

-> * **InMage_Scout_Standard_8.0.1_GA.zip** base package has:

-> * An updated configuration server base installer (**InMage_CX_8.0.1.0_Windows_GA_26Feb2015_release.exe**)

-> * A Windows master target base installer (**InMage_Scout_vContinuum_MT_8.0.1.0_Windows_GA_26Feb2015_release.exe**).

-> * For all new installations, use the new configuration server and Windows master target GA bits.

-> * Update 4 can be applied directly on 8.0.1 GA.

-> * The configuration server and RX updates canΓÇÖt be rolled back after they've been applied.

-### Azure Site Recovery Scout 8.0.1 Update 3

-All Site Recovery updates are cumulative. Update 3 contains all fixes from Update 1 and Update 2. Update 3 can be directly applied on 8.0.1 GA. The configuration server and RX updates canΓÇÖt be rolled back after they've been applied.

-#### Bug fixes and enhancements

-Update 3 fixes the following issues:

-* The configuration server and RX aren't registered in the vault when they're behind the proxy.

-* The number of hours in which the recovery point objective (RPO) wasn't reached is not updated in the health report.

-* The configuration server isn't syncing with RX when the ESX hardware details, or network details, contain any UTF-8 characters.

-* Windows Server 2008 R2 domain controllers don't start after recovery.

-* Offline synchronization isn't working as expected.

-* After VM failover, replication-pair deletion doesn't progress in the configuration server console for a long time. Users can't complete the failback or resume operations.

-* Overall snapshot operations by the consistency job have been optimized, to help reduce application disconnects such as SQL Server clients.

-* Consistency tool (VACP.exe) performance has been improved. Memory usage required for creating snapshots on Windows has been reduced.

-* The push install service crashes when the password is larger than 16 characters.

-* vContinuum doesn't check and prompt for new vCenter credentials, when credentials are modified.

-* On Linux, the master target cache manager (cachemgr) isn't downloading files from the process server. This results in replication pair throttling.

-* When the physical failover cluster (MSCS) disk order isn't the same on all nodes, replication isn't set for some of the cluster volumes. The cluster must be reprotected to take advantage of this fix.

-* SMTP functionality isn't working as expected, after RX is upgraded from Scout 7.1 to Scout 8.0.1.

-* More statistics have been added in the log for the rollback operation, to track the time taken to complete it.

-* Support has been added for Linux operating systems on the source server:

- * Red Hat Enterprise Linux (RHEL) 6 update 7

- * CentOS 6 update 7

-* The configuration server and RX consoles now show notifications for the pair, which goes into bitmap mode.

-* The following security fixes have been added in RX:

- * Authorization bypass via parameter tampering: Restricted access to non-applicable users.

- * Cross-site request forgery: The page-token concept was implemented, and it generates randomly for every page. This means there's only a single sign-in instance for the same user, and page refresh doesn't work. Instead, it redirects to the dashboard.

- * Malicious file upload: Files are restricted to specific extensions: z, aiff, asf, avi, bmp, csv, doc, docx, fla, flv, gif, gz, gzip, jpeg, jpg, log, mid, mov, mp3, mp4, mpc, mpeg, mpg, ods, odt, pdf, png, ppt, pptx, pxd, qt, ram, rar, rm, rmi, rmvb, rtf, sdc, sitd, swf, sxc, sxw, tar, tgz, tif, tiff, txt, vsd, wav, wma, wmv, xls, xlsx, xml, and zip.

- * Persistent cross-site scripting: Input validations were added.

-### Azure Site Recovery Scout 8.0.1 Update 2 (Update 03Dec15)

-Fixes in Update 2 include:

-* **Configuration server**: Issues that prevented the 31-day free metering feature from working as expected, when the configuration server was registered to Azure Site Recovery vault.

-* **Unified agent**: Fix for an issue in Update 1 that resulted in the update not being installed on the master target server, during upgrade from version 8.0 to 8.0.1.

-### Azure Site Recovery Scout 8.0.1 Update 1

-Update 1 includes the following bug fixes and new features:

-* 31 days of free protection per server instance. This enables you to test functionality, or set up a proof-of-concept.

-* All operations on the server, including failover and failback, are free for the first 31 days. The time starts when a server is first protected with Site Recovery Scout. From the 32nd day, each protected server is charged at the standard instance rate for Site Recovery protection to a customer-owned site.

-* At any time, the number of protected servers currently being charged is available on the **Dashboard** in the vault.

-* Support was added for vSphere Command-Line Interface (vCLI) 5.5 Update 2.

-* Support was added for these Linux operating systems on the source server:

- * RHEL 6 Update 6

- * RHEL 5 Update 11

- * CentOS 6 Update 6

- * CentOS 5 Update 11

-* Bug fixes to address the following issues:

- * Vault registration fails for the configuration server, or RX server.

- * Cluster volumes don't appear as expected when clustered VMs are reprotected as they resume.

- * Failback fails when the master target server is hosted on a different ESXi server from the on-premises production VMs.

- * Configuration file permissions are changed when you upgrade to 8.0.1. This change affects protection and operations.

- * The resynchronization threshold isn't enforced as expected, causing inconsistent replication behavior.

- * The RPO settings don't appear correctly in the configuration server console. The uncompressed data value incorrectly shows the compressed value.

- * The Remove operation doesn't delete as expected in the vContinuum wizard, and replication isn't deleted from the configuration server console.

- * In the vContinuum wizard, the disk is automatically unselected when you click **Details** in the disk view, during protection of MSCS VMs.

- * In the physical-to-virtual (P2V) scenario, required HP services (such as CIMnotify and CqMgHost) aren't moved to manual in VM recovery. This issue results in additional boot time.

- * Linux VM protection fails when there are more than 26 disks on the master target server.

-Consider an existing Azure App Service instance that exposes an endpoint via the following location.

-| Customer-managed | Storage account | The storage service endpoints for the primary region become unavailable, but the secondary region is available. <br></br> You received an Azure Advisory in which Microsoft advises you to perform a failover operation of storage accounts potentially affected by an outage. | [Yes](#anticipate-data-loss-and-inconsistencies) | [Yes *(In preview)*](#azure-data-lake-storage-gen2) |

-| Microsoft-managed | Entire region, datacenter or scale unit | The primary region becomes completely unavailable due to a significant disaster, but the secondary region is available. | [Yes](#anticipate-data-loss-and-inconsistencies) | [Yes](#azure-data-lake-storage-gen2) |

->

-> A Microsoft-managed failover would be initiated for an entire physical unit, such as a region, datacenter or scale unit. It can't be initiated for individual storage accounts, subscriptions, or tenants. For the ability to selectively failover your individual storage accounts, use [customer-managed account failover](#customer-managed-failover).

- > The space occupied by tiered files is allocated by NTFS. Therefore, it will not show up in any UI.

-> You can use the `nconnect` Linux mount option to improve performance for NFS Azure file shares at scale. For more information, see [Improve NFS Azure file share performance](nfs-performance.md).

-1. Connect to your client and use the provided mounting script.

-> Column-level security is supported in Azure Synapse and dedicated SQL pool (formerly SQL DW), but it's not supported for Apache Spark pool and serverless SQL pool.

-| Production | 1.0.7255.1400 |

-| Validation | 1.0.7539.5800 |

-## Version 1.0.7539.5800 (validation)

-This update was released at the beginning of September 2023 and includes the following changes:

-`((Base CPU performance * number of vCPU)/2 - (Percentage CPU * number of vCPU)/2)/100`.

-Putting this calculation into action, let's say that a customer deploys the Standard_B2ts_v2 VM size and their workload demands 10% of the 'Percentage CPU' or CPU performance, then the 'credits banked per minute' calculation will be as follows: `((20%*2)/2 - (10%*2)/2)/100 = 0.1 credits/minute`. In such a scenario, a B-series VM is accumulating credits given the 'Percentage CPU'/ CPU performance requirement is below the 'Base CPU performance' of the Standard_B2ts_v2.

-Similarly, utilizing the example of a Standard_B32as_v2 VM size, if the workload demands 60% of the CPU performance for a measurement of time - then the 'credits banked per minute' calculation will be as follows: `((40%*32)/2 - (60%*32)/2)/100 = (6.4 - 9.6)/100 = -3.2 credits per minute`. Here the negative result implies the B-series VM is consuming credits given the 'Percentage CPU'/CPU performance requirement is above the 'Base CPU performance' of the Standard_B32as_v2.

-| Standard_B2pls_v2 | 2 | 4 | 30% | 60 | 24 | 576 | 3750/85 | 10,000/960 | 4 | 6.250 | 2 |

-| Standard_B2ps_v2 | 2 | 8 | 40% | 60 | 24 | 576 | 3750/85 | 10,000/960 | 4 | 6.250 | 2 |

-| Standard_B4pls_v2 | 4 | 8 | 30% | 120 | 48 | 1152 | 6,400/145 | 20,000/960 | 8 | 6.250 | 2 |

-| Standard_B4ps_v2 | 4 | 16 | 40% | 120 | 48 | 1152 | 6,400/145 | 20,000/960 | 8 | 6.250 | 2 |

-| Standard_B8pls_v2 | 8 | 16 | 30% | 240 | 96 | 2304 | 12,800/290 | 20,000/960 | 16 | 6.250 | 2 |

-| Standard_B8ps_v2 | 8 | 32 | 40% | 240 | 96 | 2304 | 12,800/290 | 20,000/960 | 16 | 6.250 | 2 |

-| Standard_B16pls_v2 | 16 | 32 | 30% | 480 | 192 | 4608 | 25,600/600 | 40,000/960 | 32 | 6.250 | 4 |

-| Standard_B16ps_v2 | 16 | 64 | 40% | 480 | 192 | 4608 | 25,600/600 | 40,000/960 | 32 | 6.250 | 4 |

-> With Secure Boot enabled, all OS boot components (boot loader, kernel, kernel drivers) must be signed by trusted publishers (key trusted by the system). Secure Boot is not supported using Windows or Linux extensions. For more information on manually installing GPU drivers with Secure Boot enabled, see [Azure N-series GPU driver setup for Linux](../linux/n-series-driver-setup.md).

-**A:** Follow this page [Increase VM-family vCPU quotas](../azure-portal/supportability/per-vm-quota-requests.md). NP VMs are available in East US, West US2, West Europe, SouthEast Asia, and SouthCentral US.

- | Subscription|Yes|Must exist in the same [subscription](../../azure-glossary-cloud-terminology.md?toc=%2fazure%2fvirtual-network%2ftoc.json#subscription) as the resource you want to associate the public IP address to. |

- | Resource group|Yes|Can exist in the same, or different, [resource group](../../azure-glossary-cloud-terminology.md?toc=%2fazure%2fvirtual-network%2ftoc.json#resource-group) as the resource you want to associate the public IP address to. |

- | Prefix size | Yes | The size of the prefix you need. A range with 16 IP addresses (/28 for v4 or /124 for v6) is the default. |

-> - The default status for the clientconfig tag is `<clientconfig i:nil="true" />`, which can be modified based on the requirement.

-> - A duplicate clientconfig tag is not supported on macOS, so make sure the clientconfig tag is not duplicated in the XML file.

-> - To include/exclude multiple destination routes, put each destination address under a separate route tag _(as shown in the above examples)_, because multiple destination addresses in a single route tag won't work.

-> - If you encounter the error "_Destination cannot be empty or have more than one entry inside route tag_", check the profile XML file and ensure that the includeroutes/excluderoutes section has only one destination address inside a route tag.

-## Version Information

-Version 3.2.0.0

-New in this Release:

- - AAD Authentication is now available from the settings page.

- - Server High Availability(HA), releasing on a rolling basis until October 20.

- - Accesibility Improvements

- - Connection logs in UTC

- - Minor bug fixes

-

-## Azure VPN Client Version Information

-Version 3.2.0.0

-New in this Release:

-For more information, see [Create an Azure AD tenant for P2S Open VPN connections that use Azure AD authentication](openvpn-azure-ad-tenant.md).

-* **VPN type:** Route-based

-* **VPN type:** Route-based