+## Integrate with SharePoint and OneDrive

+You can [enable integration with SharePoint and OneDrive](/sharepoint/sharepoint-azureb2b-integration) to share files, folders, list items, document libraries, and sites with people outside your organization, while using Azure B2B for authentication and management. The users you share resources with are typically added to your directory as guests, and permissions and groups work the same for these guests as they do for internal users. When enabling integration with SharePoint and OneDrive, you'll also enable the [email one-time passcode](one-time-passcode.md) feature in Azure AD B2B to serve as a fallback authentication method.

+

+> | microsoft.directory/adminConsentRequestPolicy/allProperties/allTasks | Manage admin consent request policies in Azure AD |

+> | microsoft.directory/appConsent/appConsentRequests/allProperties/read | Read all properties of consent requests for applications registered with Azure AD |

+> | microsoft.directory/adminConsentRequestPolicy/allProperties/allTasks | Manage admin consent request policies in Azure AD |

+> | microsoft.directory/appConsent/appConsentRequests/allProperties/read | Read all properties of consent requests for applications registered with Azure AD |

+> | microsoft.directory/accessReviews/definitions/allProperties/allTasks | Manage access reviews of all reviewable resources in Azure AD |

+> | microsoft.directory/adminConsentRequestPolicy/allProperties/allTasks | Manage admin consent request policies in Azure AD |

+> | microsoft.directory/appConsent/appConsentRequests/allProperties/read | Read all properties of consent requests for applications registered with Azure AD |

+> | microsoft.directory/accessReviews/definitions/allProperties/read | Read all properties of access reviews of all reviewable resources in Azure AD |

+> | microsoft.directory/adminConsentRequestPolicy/allProperties/read | Read all properties of admin consent request policies in Azure AD |

+> | microsoft.directory/appConsent/appConsentRequests/allProperties/read | Read all properties of consent requests for applications registered with Azure AD |

+> | microsoft.directory/accessReviews/definitions.applications/allProperties/allTasks | Manage access reviews of application role assignments in Azure AD |

+> | microsoft.directory/accessReviews/definitions.entitlementManagement/allProperties/allTasks | Manage access reviews for access package assignments in entitlement management |

+> | microsoft.directory/accessReviews/definitions.groups/allProperties/read | Read all properties of access reviews for membership in Security and Microsoft 365 groups, including role-assignable groups. |

+> | microsoft.directory/accessReviews/definitions.groups/allProperties/update | Update all properties of access reviews for membership in Security and Microsoft 365 groups, excluding role-assignable groups. |

+> | microsoft.directory/accessReviews/definitions.groups/create | Create access reviews for membership in Security and Microsoft 365 groups. |

+> | microsoft.directory/accessReviews/definitions.groups/delete | Delete access reviews for membership in Security and Microsoft 365 groups. |

+> | microsoft.directory/accessReviews/definitions.applications/allProperties/read | Read all properties of access reviews of application role assignments in Azure AD |

+> | microsoft.directory/accessReviews/definitions.directoryRoles/allProperties/allTasks | Manage access reviews for Azure AD role assignments |

+> | microsoft.directory/accessReviews/definitions.groupsAssignableToRoles/allProperties/update | Update all properties of access reviews for membership in groups that are assignable to Azure AD roles |

+> | microsoft.directory/accessReviews/definitions.groupsAssignableToRoles/create | Create access reviews for membership in groups that are assignable to Azure AD roles |

+> | microsoft.directory/accessReviews/definitions.groupsAssignableToRoles/delete | Delete access reviews for membership in groups that are assignable to Azure AD roles |

+> | microsoft.directory/accessReviews/definitions.groups/allProperties/read | Read all properties of access reviews for membership in Security and Microsoft 365 groups, including role-assignable groups. |

+> | microsoft.directory/accessReviews/definitions/allProperties/read | Read all properties of access reviews of all reviewable resources in Azure AD |

+> | microsoft.directory/accessReviews/definitions.applications/allProperties/allTasks | Manage access reviews of application role assignments in Azure AD |

+> | microsoft.directory/accessReviews/definitions.directoryRoles/allProperties/read | Read all properties of access reviews for Azure AD role assignments |

+> | microsoft.directory/accessReviews/definitions.entitlementManagement/allProperties/allTasks | Manage access reviews for access package assignments in entitlement management |

+> | microsoft.directory/accessReviews/definitions.groups/allProperties/update | Update all properties of access reviews for membership in Security and Microsoft 365 groups, excluding role-assignable groups. |

+> | microsoft.directory/accessReviews/definitions.groups/create | Create access reviews for membership in Security and Microsoft 365 groups. |

+> | microsoft.directory/accessReviews/definitions.groups/delete | Delete access reviews for membership in Security and Microsoft 365 groups. |

+> | microsoft.directory/accessReviews/definitions.groups/allProperties/read | Read all properties of access reviews for membership in Security and Microsoft 365 groups, including role-assignable groups. |

+ Title: 'Tutorial: Configure GitHub Enterprise Managed User (OIDC) for automatic user provisioning with Azure Active Directory | Microsoft Docs'

+description: Learn how to automatically provision and de-provision user accounts from Azure AD to GitHub Enterprise Managed User (OIDC).

+documentationcenter: ''

+writer: twimmers

+ms.assetid: e39cbad7-e23a-4986-9725-54a7aeb7b1ea

+ na

+# Tutorial: Configure GitHub Enterprise Managed User (OIDC) for automatic user provisioning

+This tutorial describes the steps you need to perform in both GitHub Enterprise Managed User (OIDC) and Azure Active Directory (Azure AD) to configure automatic user provisioning. When configured, Azure AD automatically provisions and de-provisions users and groups to GitHub Enterprise Managed User (OIDC) using the Azure AD Provisioning service. For important details on what this service does, how it works, and frequently asked questions, see [Automate user provisioning and deprovisioning to SaaS applications with Azure Active Directory](../app-provisioning/user-provisioning.md).

+> [!NOTE]

+> [GitHub Enterprise Managed User](https://docs.github.com/enterprise-cloud@latest/admin/authentication/managing-your-enterprise-users-with-your-identity-provider/about-enterprise-managed-users) is a feature of GitHub Enterprise Cloud which is different from GitHub Enterprise's standard OIDC SSO and user provisioning implementation. If you haven't specifically requested EMU instance, you have standard GitHub Enterprise Cloud plan. In that case, please refer to [the documentation](./github-provisioning-tutorial.md) to configure user provisioning in your non-EMU organisation. User provisioning is not supported for [GitHub Enteprise Accounts](https://docs.github.com/enterprise-cloud@latest/admin/overview/about-enterprise-accounts)

+## Capabilities Supported

+> [!div class="checklist"]

+> * Create users in GitHub Enterprise Managed User (OIDC)

+> * Remove users in GitHub Enterprise Managed User (OIDC) when they do not require access anymore

+> * Keep user attributes synchronized between Azure AD and GitHub Enterprise Managed User (OIDC)

+> * Provision groups and group memberships in GitHub Enterprise Managed User (OIDC)

+> * [Single sign-on](../manage-apps/add-application-portal-setup-oidc-sso.md) to GitHub Enterprise Managed User (OIDC) (recommended).

+> [!NOTE]

+> This provisioning connector is enabled only for Enterprise Managed Users beta participants.

+## Prerequisites

+The scenario outlined in this tutorial assumes that you already have the following prerequisites:

+* [An Azure AD tenant](../develop/quickstart-create-new-tenant.md)

+* A user account in Azure AD with [permission](../roles/permissions-reference.md) to configure provisioning (for example, Application Administrator, Cloud Application administrator, Application Owner, or Global Administrator).

+* Enterprise Managed Users enabled GitHub Enterprise and configured to login with SAML SSO through your Azure AD tenant.

+> [!NOTE]

+> This integration is also available to use from Azure AD US Government Cloud environment. You can find this application in the Azure AD US Government Cloud Application Gallery and configure it in the same way as you do from public cloud.

+## Step 1. Plan your provisioning deployment

+1. Learn about [how the provisioning service works](../app-provisioning/user-provisioning.md).

+2. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+3. Determine what data to [map between Azure AD and GitHub Enterprise Managed User](../app-provisioning/customize-application-attributes.md).

+## Step 2. Configure GitHub Enterprise Managed User (OIDC) to support provisioning with Azure AD

+1. The Tenant URL is `https://api.github.com/scim/v2/enterprises/{enterprise}`. This value will be entered in the Tenant URL field in the Provisioning tab of your GitHub Enterprise Managed User (OIDC) application in the Azure portal.

+2. As a GitHub Enterprise Managed administrator navigate to the upper-right corner -> click your profile photo -> then click **Settings**.

+3. In the left sidebar, click **Developer settings**.

+4. In the left sidebar, click **Personal access tokens**.

+5. Click **Generate new token**.

+6. Select the **admin:enterprise** scope for this token.

+7. Click **Generate Token**.

+8. Copy and save the **secret token**. This value will be entered in the Secret Token field in the Provisioning tab of your GitHub Enterprise Managed User (OIDC) application in the Azure portal.

+## Step 3. Add GitHub Enterprise Managed User (OIDC) from the Azure AD application gallery

+Add GitHub Enterprise Managed User (OIDC) from the Azure AD application gallery to start managing provisioning to GitHub Enterprise Managed User (OIDC). If you have previously setup GitHub Enterprise Managed User (OIDC) for SSO, you can use the same application. However it is recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).

+## Step 4. Define who will be in scope for provisioning

+The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user / group. If you choose to scope who will be provisioned to your app based on assignment, you can use the following [steps](../manage-apps/assign-user-or-group-access-portal.md) to assign users and groups to the application. If you choose to scope who will be provisioned based solely on attributes of the user or group, you can use a scoping filter as described [here](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* When assigning users and groups to GitHub Enterprise Managed User (OIDC), you must select a role other than **Default Access**. Users with the Default Access role are excluded from provisioning and will be marked as not effectively entitled in the provisioning logs.

+* Start small. Test with a small set of users and groups before rolling out to everyone. When scope for provisioning is set to assigned users and groups, you can control this by assigning one or two users or groups to the app. When scope is set to all users and groups, you can specify an [attribute based scoping filter](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+## Step 5. Configure automatic user provisioning to GitHub Enterprise Managed User (OIDC)

+This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users and/or groups in TestApp based on user and/or group assignments in Azure AD.

+### To configure automatic user provisioning for GitHub Enterprise Managed User (OIDC) in Azure AD:

+1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.

+ 

+2. In the applications list, select **GitHub Enterprise Managed User (OIDC)**.

+ 

+3. Select the **Provisioning** tab.

+ 

+4. Set the **Provisioning Mode** to **Automatic**.

+ 

+5. Under the **Admin Credentials** section, input your GitHub Enterprise Managed User (OIDC) Tenant URL and Secret Token. Click **Test Connection** to ensure Azure AD can connect to GitHub Enterprise Managed User (OIDC). If the connection fails, ensure your GitHub Enterprise Managed User (OIDC) account has created the secret token as an enterprise owner and try again.

+ 

+6. In the **Notification Email** field, enter the email address of a person or group who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

+ 

+7. Select **Save**.

+8. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to GitHub Enterprise Managed User (OIDC)**.

+9. Review the user attributes that are synchronized from Azure AD to GitHub Enterprise Managed User (OIDC) in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in GitHub Enterprise Managed User (OIDC) for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you will need to ensure that the GitHub Enterprise Managed User (OIDC) API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

+ |Attribute|Type|Supported For Filtering|

+ ||||

+ |externalId|String|✓|

+ |userName|String|

+ |active|Boolean|

+ |roles|String|

+ |displayName|String|

+ |name.givenName|String|

+ |name.familyName|String|

+ |name.formatted|String|

+ |emails[type eq "work"].value|String|

+ |emails[type eq "home"].value|String|

+ |emails[type eq "other"].value|String|

+10. Under the **Mappings** section, select **Synchronize Azure Active Directory Groups to GitHub Enterprise Managed User (OIDC)**.

+11. Review the group attributes that are synchronized from Azure AD to GitHub Enterprise Managed User (OIDC) in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the groups in GitHub Enterprise Managed User (OIDC) for update operations. Select the **Save** button to commit any changes.

+ |Attribute|Type|Supported For Filtering|

+ ||||

+ |externalId|String|✓|

+ |displayName|String|

+ |members|Reference|

+12. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+13. To enable the Azure AD provisioning service for GitHub Enterprise Managed User (OIDC), change the **Provisioning Status** to **On** in the **Settings** section.

+ 

+14. Define the users and/or groups that you would like to provision to GitHub Enterprise Managed User (OIDC) by choosing the desired values in **Scope** in the **Settings** section.

+ 

+15. When you are ready to provision, click **Save**.

+ 

+This operation starts the initial synchronization cycle of all users and groups defined in **Scope** in the **Settings** section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.

+## Step 6. Monitor your deployment

+Once you've configured provisioning, use the following resources to monitor your deployment:

+1. Use the [provisioning logs](../reports-monitoring/concept-provisioning-logs.md) to determine which users have been provisioned successfully or unsuccessfully

+2. Check the [progress bar](../app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md) to see the status of the provisioning cycle and how close it is to completion

+3. If the provisioning configuration seems to be in an unhealthy state, the application will go into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).

+## Additional resources

+* [Managing user account provisioning for Enterprise Apps](../app-provisioning/configure-automatic-user-provisioning-portal.md)

+* [What is application access and single sign-on with Azure Active Directory?](../manage-apps/what-is-single-sign-on.md)

+## Next steps

+* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

+| 1.24 | Apr-22-22 | May 2022 | Jul 2022 | 1.27 GA

+| 1.25 | Aug 2022 | Sept 2022 | Nov 2022 | 1.28 GA

+> [!IMPORTANT]

+> When we add support for a new Angular version, our NPM package becomes incompatible with down-level Angular versions. Continue to use older NPM packages until you're ready to upgrade your Angular version.

+This article provides two code samples that show how to create and configure a Log Analytics workspace in Azure Monitor.

+The following sample script sample creates a workspace and configures multiple data sources. These data sources are only required if you are monitoring virtual machines using the [Log Analytics agent](../agents/log-analytics-agent.md). A workspace has unique workspace ID and resource ID. You can reuse the same workspace name when in different resource groups.

+Use the **Log Analytics workspaces** menu to create a Log Analytics workspace in the Azure portal. Log Analytics workspace is the environment for Azure Monitor log data. Each workspace has its own data repository and configuration, and data sources and solutions are configured to store their data in a particular workspace. A workspace has unique workspace ID and resource ID. You can reuse the same workspace name when in different resource groups. You require a Log Analytics workspace if you intend on collecting data from the following sources:

+The following sample creates a new empty Log Analytics workspace. A workspace has unique workspace ID and resource ID. You can reuse the same workspace name when in different resource groups.

+### AzAcSnap v5.1 Preview (Build: 20220220.55340)

+AzAcSnap v5.1 Preview (Build: 20220220.55340) has been released with the following fixes and improvements:

+- Resolved failure in matching `--dbsid` command line option with `sid` entry in the JSON configuration file for Oracle databases when using the `-c restore` command.

+Download the [latest release of the Preview installer](https://aka.ms/azacsnap-preview-installer) and read about the new features and how to use the [AzAcSnap Preview](azacsnap-preview.md).

+- Ignore `ssh` 255 exit codes. In some cases the `ssh` command, which is used to communicate with storage on Azure Large Instance, would emit an exit code of 255 when there were no errors or execution failures (refer `man ssh` "EXIT STATUS") - then AzAcSnap would trap this exit code as a failure and abort. With this update extra verification is done to validate correct execution, this includes parsing `ssh` STDOUT and STDERR for errors in addition to traditional exit code checks.

+- Fix the installer's check for the location of the hdbuserstore. The installer would check for the existence of an incorrect source directory for the hdbuserstore for the user running the install - this is fixed to check for `~/.hdb`. This fix is applicable to systems (for example, Azure Large Instance) where the hdbuserstore was pre-configured for the `root` user before installing `azacsnap`.

+- Improved exit code handling. In some cases AzAcSnap would emit an exit code of 0 (zero), even after an execution failure when the exit code should have been non-zero. Exit codes should now only be zero on successfully running `azacsnap` to completion and non-zero if there is any failure.

+ Title: Conversation transcription overview - Speech service

+# What is conversation transcription?

+> [!NOTE]

+> Multi-device conversation access is a preview feature.

+ Title: Custom Commands overview - Speech service

+ Title: Create a custom keyword quickstart - Speech service

+description: When a user speaks the keyword, your device sends their dictation to the cloud, until the user stops speaking. Customizing your keyword is an effective way to differentiate your device and strengthen your branding.

+# Quickstart: Create a custom keyword

+Direct Line Speech is a robust, end-to-end solution for creating a flexible, extensible voice assistant. It is powered by the Bot Framework and its Direct Line Speech channel, that is optimized for voice-in, voice-out interaction with bots.

+Direct Line Speech and its associated functionality for voice assistants are an ideal supplement to the [Virtual Assistant Solution and Enterprise Template](/azure/bot-service/bot-builder-enterprise-template-overview). Though Direct Line Speech can work with any compatible bot, these resources provide a reusable baseline for high-quality conversational experiences as well as common supporting skills and models to get started quickly.

+description: In this quickstart, you recognize intents from audio data with the Speech service and LUIS.

+# Quickstart: Recognize intents with the Speech service and LUIS

+description: In this quickstart, you use speaker recognition to confirm who is speaking. Learn about common design patterns for working with speaker verification and identification.

+# Quickstart: Recognize and verify who is speaking

+description: In this quickstart, you convert speech to text with recognition from a microphone.

+# Quickstart: Recognize and convert speech to text

+description: In this quickstart, you translate speech to text. Learn about object construction, supported audio input formats, and configuration options.

+# Quickstart: Recognize and translate speech to text

+description: In this quickstart, you convert text to speech. Learn about object construction and design patterns, supported audio output formats, and custom configuration options for speech synthesis.

+# Quickstart: Convert text to speech

+description: In this quickstart, learn how to transcribe meetings and other conversations. You can add, remove, and identify multiple participants by streaming audio to the Speech service.

+# Quickstart: Real-time Conversation Transcription

+# Get started with voice assistants on Windows

+ Title: Keyword recognition overview - Speech service

+# What is keyword recognition?

+ Title: Migration to neural voice - Speech service

+# Migration to neural voice

+ Title: Multi-device Conversation overview - Speech Service

+# What is Multi-device Conversation?

+Multi-device conversation makes it easy to create a speech or text conversation between multiple clients and coordinate the messages sent between them.

+> [!NOTE]

+> Multi-device conversation access is a preview feature.

+With multi-device conversation, you can:

+Whereas [Conversation Transcription](conversation-transcription.md) works on a single device with a multichannel microphone array, Multi-device Conversation is suited for scenarios with multiple devices, each with a single microphone.

+> Multi-device conversation does not support sending audio files between clients: only the transcription and/or translation.

+- **Real-time transcription:** Everyone will receive a transcript of the conversation, so they can follow along the text in real-time or save it for later.

+- **Real-time translation:** With more than 70 [supported languages](language-support.md#text-languages) for text translation, users can translate the conversation to their preferred language(s).

+- **Readable transcripts:** The transcription and translation are easy to follow, with punctuation and sentence breaks.

+- **Voice or text input:** Each user can speak or type on their own device, depending on the language support capabilities enabled for the participant's chosen language. Please refer to [Language support](language-support.md#speech-to-text).

+- **Message relay:** The multi-device conversation service will distribute messages sent by one client to all the others, in the language(s) of their choice.

+- **Message identification:** Every message that users receive in the conversation will be tagged with the nickname of the user who sent it.

+A conversation is a session that one user starts for the other participating users to join. All clients connect to the conversation using the five-letter conversation code.

+- Timestamps of when the conversation started and ended

+- List of all participants in the conversation, which includes each user's chosen nickname and primary language for speech or text input.

+There are two types of users in a conversation: host and participant.

+The host is the user who starts a conversation, and who acts as the administrator of that conversation.

+A participant is a user who joins a conversation.

+When creating or joining a conversation, each user must choose a primary language: the language that they will speak and send instant messages in, and also the language they will see other users' messages.

+There are two kinds of languages: speech-to-text and text-only:

+- If the user chooses a speech-to-text language as their primary language, then they will be able to use both speech and text input in the conversation.

+- If the user chooses a text-only language, then they will only be able to use text input and send instant messages in the conversation. Text-only languages are the languages that are supported for text translation, but not speech-to-text. You can see available languages on the [language support](./language-support.md) page.

+* [Translate conversations in real-time](quickstarts/multi-device-conversation.md)

+# What is pattern matching?

+ Title: 'Quickstart: Create a voice assistant using Custom Commands - Speech service'

+description: In this quickstart, you create and test a basic Custom Commands application in Speech Studio.

+# Quickstart: Create a voice assistant with Custom Commands

+description: In this quickstart, you use the Speech SDK to create a custom voice assistant.

+Available to organizations with a business presence in China. See more information about Azure China [here](/azure/china/overview-operations).

+# What are Speech devices?

+* [Audio processing concepts](audio-processing-overview.md)

+# What is the Speech SDK?

+* [Explore Speech Studio](https://speech.microsoft.com)

+description: In this Azure Speech CLI quickstart, you interact with speech-to-text, text-to-speech, and speech translation without having to write code.

+# Quickstart: Get started with the Azure Speech CLI

+description: Learn how to do batch speech to text (speech recognition), batch text to speech (speech synthesis) with the Speech CLI.

+In the [Speech CLI quickstart](spx-basics.md), you used the datastore to save your `@key` and `@region` values, so you did not need to specify them with each `spx` command. Keep in mind, that you can use configuration files to store your own configuration settings, or even use them to pass URLs or other dynamic content generated at runtime.

+ Title: Voice assistants overview - Speech service

+ Title: Voice Assistants on Windows overview - Speech Service

+# What are Voice Assistants on Windows?

+Voice assistant applications can take advantage of the Windows ConversationalAgent APIs to achieve a complete voice-enabled assistant experience.

+- Review the [design guidelines](windows-voice-assistants-best-practices.md) to provide the best experiences for voice activation.

+- See the voice assistants on Windows [get started](how-to-windows-voice-assistants-get-started.md) page.

+- See the [UWP Voice Assistant Sample](windows-voice-assistants-faq.yml#the-uwp-voice-assistant-sample) page and follow the steps to get the sample client running.

+description: Create workflows that manage blobs in Azure storage accounts using Azure Logic Apps.

+You can connect to Blob Storage from both **Logic App (Consumption)** and **Logic App (Standard)** resource types. You can use the connector with logic app workflows in multi-tenant Azure Logic Apps, single-tenant Azure Logic Apps, and the integration service environment (ISE). With **Logic App (Standard)**, you can use either the *built-in* **Azure Blob** operations or the **Azure Blob Storage** managed connector operations.

+- A logic app workflow from which you want to access your Azure Storage account. If you want to start your workflow with a Blob trigger, you need a [blank logic app workflow](../logic-apps/quickstart-create-first-logic-app-workflow.md).

+- By default, Blob actions can read or write files that are *50 MB or smaller*. To handle files larger than 50 MB but up to 1024 MB, Blob actions support [message chunking](../logic-apps/logic-apps-handle-large-messages.md). The [**Get blob content** action](/connectors/azureblobconnector/#get-blob-content) implicitly uses chunking.

+- Blob triggers don't support chunking. When a trigger requests file content, the trigger selects only files that are 50 MB or smaller. To get files larger than 50 MB, follow this pattern:

+ - Use a Blob trigger that returns file properties, such as [**When a blob is added or modified (properties only)**](/connectors/azureblobconnector/#when-a-blob-is-added-or-modified-(properties-only)).

+ - Follow the trigger with the Blob action named [**Get blob content**](/connectors/azureblobconnector/#get-blob-content), which reads the complete file and implicitly uses chunking.

+For more technical details about this connector, such as triggers, actions, and limits, review the [connector's reference page](/connectors/azureblobconnector/). If you don't want to use the Blob operations, you can use the [use HTTP trigger or action along with a a managed identity for blob operations instead](#access-blob-storage-with-managed-identities).

+<a name="add-trigger"></a>

+## Add a Blob trigger

+Only one Blob trigger exists and has either of the following names, based on whether you're working with a Consumption or Standard logic app workflow:

+| Logic app type | Trigger name | Description |

+|-|--|-|

+| Consumption | Managed connector only: **When a blob is added or modified (properties only)** | The trigger fires when a blob's properties are added or updated in your storage container's root folder. |

+| Standard | - Built-in: **When a blob is Added or Modified in Azure Storage** <br><br>- Managed connector: **When a blob is added or modified (properties only)** | - Built-in: The trigger fires when a blob is added or updated in your storage container. The trigger also fires for any nested folders in your storage container, not just the root folder. <br><br>- Managed connector: The trigger fires when a blob's properties are added or updated in your storage container's root folder. |

+||||

+When the trigger fires each time, Azure Logic Apps creates a logic app instance and starts running the workflow.

+To add a Blob trigger to a logic app workflow in multi-tenant Azure Logic Apps, follow these steps:

+1. Under the designer search box, make sure that **All** is selected. In the search box, enter **Azure blob**. From the **Triggers** list, select the trigger named **When a blob is added or modified (properties only)**.

+1. If you're prompted for connection details, [create a connection to your Azure Blob Storage account](#connect-blob-storage-account).

+ 1. For the **Container** property value, select the folder icon to browse for your blob storage container. Or, enter the path manually using the syntax **/<*container-name*>**, for example:

+ 1. Configure other trigger settings as needed.

+To add a Blob trigger to a logic app workflow in single-tenant Azure Logic Apps, follow these steps:

+1. On the designer, select **Choose an operation**.

+1. In the **Add a trigger** pane that opens, under the **Choose an operation** search box, you can select either **Built-in** to find the **Azure Blob** *built-in* trigger, or select **Azure** to find the **Azure Blob Storage** *managed connector* trigger.

+ This example uses the built-in **Azure Blob** trigger.

+1. Under the search box, select **Built-in**. In the search box, enter **Azure blob**.

+1. From the **Triggers** list, select the built-in trigger named **When a blob is Added or Modified in Azure Storage**.

+1. If you're prompted for connection details, [create a connection to your Azure Storage account](#connect-blob-storage-account).

+ 1. Return to the workflow designer. In the trigger's **Blob Path** property, enter the path for the container, folder, or blob, based on whether you're checking for new blobs or changes to an existing blob. The syntax varies based on the check that you want to run and any filtering that you want to use:

+ | Task | Path syntax |

+ ||-|

+ | Check the root folder for a newly added blob. | **<*container-name*>** |

+ | Check the root folder for changes to a specific blob. | **<*container-name*>/<*blob-name*>.<*blob-extension*>** |

+ | Check the root folder for changes to any blobs with the same extension, for example, **.txt**. | **<*container-name*>/{name}.txt** <br><br>**Important**: Make sure that you use **{name}** as a literal. |

+ | Check the root folder for changes to any blobs with names starting with a specific string, for example, **Sample-**. | **<*container-name*>/Sample-{name}** <br><br>**Important**: Make sure that you use **{name}** as a literal. |

+ | Check a subfolder for a newly added blob. | **<*container-name*>/<*subfolder*>** |

+ | Check a subfolder for changes to a specific blob. | **<*container-name*>/<*subfolder*>/<*blob-name*>.<*blob-extension*>** |

+ |||

+ For more syntax and filtering options, review [Azure Blob storage trigger for Azure Functions](../azure-functions/functions-bindings-storage-blob-trigger.md#blob-name-patterns).

+ The following example shows a trigger setup that checks the root folder for a newly added blob:

+ :::image type="content" source="./media/connectors-create-api-azureblobstorage/standard-trigger-root-folder.png" alt-text="Screenshot showing the workflow designer for a Standard logic app workflow with an Azure Blob trigger set up for the root folder.":::

+ The following example shows a trigger setup that checks a subfolder for changes to an existing blob:

+ :::image type="content" source="./media/connectors-create-api-azureblobstorage/standard-trigger-sub-folder-existing-blob.png" alt-text="Screenshot showing the workflow designer for a Standard logic app workflow with an Azure Blob trigger set up for a subfolder and specific blob.":::

+## Add a Blob action

+To add a Blob action to a logic app workflow in multi-tenant Azure Logic Apps, follow these steps:

+1. Under the trigger or action where you want to add the Blob action, select **New step** or **Add an action**, if between steps.

+1. Under the designer search box, make sure that **All** is selected. In the search box, enter **Azure blob**. Select the Blob action that you want to use.

+ :::image type="content" source="./media/connectors-create-api-azureblobstorage/consumption-action-add.png" alt-text="Screenshot showing Consumption logic app in designer with available Blob actions.":::

+1. If you're prompted for connection details, [create a connection to your Azure Storage account](#connect-blob-storage-account).

+ For example, in the **Get blob content** action, provide your storage account name. For the **Blob** property value, select the folder icon to browse for your storage container or folder. Or, enter the path manually.

+ | Task | Blob path syntax |

+ |||

+ | Get the content from a specific blob in the root folder. | **/<*container-name*>/<*blob-name*>** |

+ | Get the content from a specific blob in a subfolder. | **/<*container-name*>/<*subfolder*>/<*blob-name*>** |

+ |||

+ The following example shows the action setup that gets the content from a blob in the root folder:

+ :::image type="content" source="./media/connectors-create-api-azureblobstorage/consumption-action-root-folder.png" alt-text="Screenshot showing Consumption logic app in designer with Blob action setup for root folder.":::

+ The following example shows the action setup that gets the content from a blob in the subfolder:

+ :::image type="content" source="./media/connectors-create-api-azureblobstorage/consumption-action-sub-folder.png" alt-text="Screenshot showing Consumption logic app in designer with Blob action setup for subfolder.":::

+1. Set up other action settings as needed.

+1. Under the trigger or action where you want to add the Blob action, select **Insert a new step** (**+**) > **Add an action**.

+1. In the search box, enter **Azure blob**. Select the Azure Blob action that you want to use.

+1. If you're prompted for connection details, [create a connection to your Azure Storage account](#connect-blob-storage-account).

+1. For the action, provide the necessary information, which includes the following values for the **Read Blob Content from Azure Storage** action:

+ | Property | Required | Description |

+ |-|-|-|

+ | **Container Name** | Yes | The name for the storage container that you want to use |

+ | **Blob name** | Yes | The name or path for the blob that you want to use |

+ ||||

+ The following example shows the information for a specific blob in the root folder:

+ :::image type="content" source="./media/connectors-create-api-azureblobstorage/standard-action-root-folder.png" alt-text="Screenshot showing Standard logic app in designer with Blob action setup for root folder.":::

+ The following example shows the information for a specific blob in a subfolder:

+ :::image type="content" source="./media/connectors-create-api-azureblobstorage/standard-action-subfolder.png" alt-text="Screenshot showing Standard logic app in designer with Blob action setup for subfolder.":::

+1. Configure any other action settings as needed.

+## Connect to Azure Storage account

+Before you can configure your [Azure Blob Storage trigger](#add-trigger) or [Azure Blob Storage action](#add-action), you need to connect to your Azure Storage account.

+Based on the [authentication type that your storage account requires](../storage/common/authorize-data-access.md), you have to provide a connection name and select the authentication type at a minimum.

+For example, if your storage account requires *access key* authorization, you have to provide the following information:

+| **Authentication type** | Yes | - **Access Key** <br><br>- **Azure AD Integrated** <br><br>- **Logic Apps Managed Identity (Preview)** | The authentication type to use for your connection. For more information, review [Authentication types for triggers and actions that support authentication - Secure access and data](../logic-apps/logic-apps-securing-a-logic-app.md#authentication-types-for-triggers-and-actions-that-support-authentication). |

+| **Azure Storage Account name** | Yes, <br>but only for access key authentication | <*storage-account-name*> | The name for the Azure storage account where your blob container exists. <br><br><br><br>**Note**: To find the storage account name, open your storage account resource in the Azure portal. In the resource menu, under **Security + networking**, select **Access keys**. Under **Storage account name**, copy and save the name. |

+| **Azure Storage Account Access Key** | Yes, <br>but only for access key authentication | <*storage-account-access-key*> | The access key for your Azure storage account. <br><br><br><br>**Note**: To find the access key, open your storage account resource in the Azure portal. In the resource menu, under **Security + networking**, select **Access keys** > **Show keys**. Copy and save one of the key values. |

+The following example shows how a connection using access key authentication might appear:

+Before you can configure your [Azure Blob trigger](#add-trigger) or [Azure Blob action](#add-action), you need to connect to your Azure Storage account. A connection requires the following properties:

+| **Azure Blob Storage Connection String** | Yes | <*storage-account*> | Select your storage account from the list, or provide a string. <br><br><br><br>**Note**: To find the connection string, go to the storage account's page. In the navigation menu, under **Security + networking**, select **Access keys** > **Show keys**. Copy one of the available connection string values. |

+1. Select **Create** to finish creating your connection.

+> [Microservices](microservices.md)

+- Any Linux-based x86-64 (`linux/amd64`) container image

+ "cpu": 0.75,

+ "memory": "1.5Gi"

+| `resources.cpu` | The number of CPUs allocated to the container. | Values must adhere to the following rules: the value must be greater than zero and less than or equal to 2, and can be any decimal number, with a maximum of two decimal places. For example, `1.25` is valid, but `1.555` is invalid. The default is 0.5 CPU per container. |

+| `resources.memory` | The amount of RAM allocated to the container. | This value is up to `4Gi`. The only allowed units are [gibibytes](https://simple.wikipedia.org/wiki/Gibibyte) (`Gi`). Values must adhere to the following rules: the value must be greater than zero and less than or equal to `4Gi`, and can be any decimal number, with a maximum of two decimal places. For example, `1.25Gi` is valid, but `1.555Gi` is invalid. The default is `1Gi` per container. |

+| vCPUs (cores) | Memory |

+| `0.25` | `0.5Gi` |

+| `0.5` | `1.0Gi` |

+| `0.75` | `1.5Gi` |

+| `1.0` | `2.0Gi` |

+| `1.25` | `2.5Gi` |

+| `1.5` | `3.0Gi` |

+| `1.75` | `3.5Gi` |

+| `2.0` | `4.0Gi` |

+- **Operating system**: Linux-based (`linux/amd64`) container images are required.

+> [Revisions](revisions.md)

+> [Containers](containers.md)

+> [Application lifecycle management](application-lifecycle-management.md)

+> * To change the throughput (RU/s) values, redeploy the Bicep file with updated RU/s.

+To create any of the Azure Cosmos DB resources below, copy the following example into a new bicep file. You can optionally create a parameters file to use when deploying multiple instances of the same resource with different names and values. There are many ways to deploy Azure Bicep files including, [Azure CLI](../../azure-resource-manager/bicep/deploy-cli.md), [Azure PowerShell](../../azure-resource-manager/bicep/deploy-powershell.md) and [Cloud Shell](../../azure-resource-manager/bicep/deploy-cloud-shell.md).

+Create an Azure Cosmos account in two regions with options for consistency and failover, with database and container configured for autoscale throughput that has most index policy options enabled.

+Create an Azure Cosmos DB account with SQL API, Session consistency in West US and East US regions:

+ --locations regionName='West US' failoverPriority=0 isZoneRedundant=False \

+ --locations regionName='East US' failoverPriority=1 isZoneRedundant=False

+ --locations regionName="West US" failoverPriority=0 isZoneRedundant=False \

+ --locations regionName="East US" failoverPriority=1 isZoneRedundant=False

+ --locations regionName="West US" failoverPriority=0 isZoneRedundant=False \

+ --locations regionName="East US" failoverPriority=1 isZoneRedundant=False \

+ --locations regionName="West US" failoverPriority=0 isZoneRedundant=False \

+ --locations regionName="East US" failoverPriority=1 isZoneRedundant=False

+# Assume region order is initially 'West US'=0 'East US'=1 'South Central US'=2 for account

+# Make South Central US the next region to fail over to instead of East US

+ --failover-policies 'West US=0' 'South Central US=1' 'East US=2'

+# Assume region order is initially 'West US=0' 'East US=1' 'South Central US=2' for account

+ --failover-policies 'East US=0' 'South Central US=1' 'West US=2'

+For the example below, assume the current failover priority is `West US = 0`, `East US = 1`, `South Central US = 2`. The command will change this to `West US = 0`, `South Central US = 1`, `East US = 2`.

+$locations = @("West US", "South Central US", "East US") # Regions ordered by UPDATED failover priority

+For the example below, assume the account has a current failover priority of `West US = 0` and `East US = 1` and flip the regions.

+$locations = @("East US", "West US") # Regions ordered by UPDATED failover priority

+> You can use Azure Resource Manager templates update the autoscale max RU/s setting on an database and container resources already configured with autoscale. Migrating between manual and autoscale throughput is a POST operation and not supported with Azure Resource Manager templates. To migrate throughput use [Azure CLI](how-to-provision-autoscale-throughput.md#azure-cli) or [PowerShell](how-to-provision-autoscale-throughput.md#azure-powershell).

+This template creates an Azure Cosmos account in two regions with options for consistency and failover, with database and container configured for standard throughput with many indexing policy options configured. This template is also available for one-click deploy from Azure Quickstart Templates Gallery.

+| Low | 1440 (24 hours) |

+description: Learn how to configure an existing virtual network and subnet to use for creating virtual machines in Azure DevTest Labs.

+# Add a virtual network in Azure DevTest Labs

+In this article, you learn how to add a virtual network to a lab, and configure it for creating lab virtual machines (VMs).

+Azure DevTest Labs creates a new virtual network for each lab. If you have another virtual network, such as one configured with Azure ExpressRoute or site-to-site virtual private network (VPN), you can add it to your lab. You can then create lab VMs in that virtual network.

+## Add a virtual network to a lab

+To add a configured virtual network and subnet to a lab, take the following steps:

+1. In the [Azure portal](https://go.microsoft.com/fwlink/p/?LinkID=525040), on the **Overview** page for your lab, select **Configuration and policies** from the left navigation.

+ :::image type="content" source="./media/devtest-lab-configure-vnet/policies-menu.png" alt-text="Screenshot that shows the Configuration and policies menu for a lab.":::

+1. On the **Configuration and policies** page, in the left navigation under **External resources**, select **Virtual networks**.

+1. The **Virtual networks** page shows the lab's current virtual networks. Select **Add**.

+ :::image type="content" source="./media/devtest-lab-configure-vnet/lab-settings-vnet-add.png" alt-text="Screenshot that shows a lab's Virtual networks page with Add selected.":::

+1. On the **Virtual network** page, select **Select virtual network**.

+ :::image type="content" source="./media/devtest-lab-configure-vnet/lab-settings-vnets-vnet1.png" alt-text="Screenshot that shows Select virtual network selected on the Virtual network page.":::

+1. The **Choose virtual network** page appears, showing all virtual networks in the subscription that are in the same region as the lab. Select the virtual network you want to add.

+ :::image type="content" source="./media/devtest-lab-configure-vnet/choose-virtual-network.png" alt-text="Screenshot that shows the Choose virtual network page with a list of virtual networks.":::

+1. The virtual network you chose shows on the **Virtual network** page. Select **Save**.

+1. The virtual network appears in the list on the lab's **Virtual networks** page. When the **Status** shows as **Ready**, select the new virtual network.

+ :::image type="content" source="./media/devtest-lab-configure-vnet/lab-subnet.png" alt-text="Screenshot that shows the added virtual network on the lab's Virtual networks page.":::

+1. The **Virtual network** page shows the subnets for the virtual network. Select a subnet to configure.

+1. On the **Lab Subnet** pane, select **Yes** or **No** under the following options:

+ - **Use in virtual machine creation** to allow or disallow VM creation in the subnet.

+ - **Enable shared public IP** to enable or disable a [shared public IP address](devtest-lab-shared-ip.md).

+ - **Allow public IP creation** to allow or disallow creating public IP addresses in the subnet.

+1. Under **Maximum virtual machines per user**, enter the maximum number of VMs each user can create in the subnet. If you don't want to restrict the number of VMs, leave this field blank.

+1. Select **Save**.

+ :::image type="content" source="./media/devtest-lab-configure-vnet/lab-settings-vnets-vnet2.png" alt-text="Screenshot that shows the settings for the Lab subnet pane.":::

+1. On the **Virtual network** page, select **Save** again.

+## Create VMs in a virtual network

+If you allowed VM creation in one of the subnets, you can now create lab VMs in the added virtual network.

+1. Follow the instructions at [Create and add virtual machines](devtest-lab-add-vm.md) to add a lab VM and select a VM base.

+1. On the **Create lab resource** screen, select the **Advanced settings** tab.

+1. Select the drop-down arrow in the **Virtual network** field, and select the virtual network you added.

+1. If necessary, select the drop-down arrow in the **Subnet Selector** field, and select the subnet you want.

+1. Proceed with VM creation.

+- For more information about how to set up, use, and manage virtual networks, see the [Azure virtual network documentation](/azure/virtual-network).

+- You can deploy [Azure Bastion](https://azure.microsoft.com/services/azure-bastion) in a new or existing virtual network to enable browser connection to your lab VMs. For more information, see [Enable browser connection to DevTest Labs VMs with Azure Bastion](enable-browser-connection-lab-virtual-machines.md).

+ Title: Create a custom image from a lab VM

+description: Learn how to create a custom image from a provisioned virtual machine in Azure DevTest Labs by using the Azure portal.

+In this article, you learn how to create a custom image from a provisioned Azure DevTest Labs virtual machine (VM).

+The custom image includes the OS disk and all the data disks attached to the VM. Lab users can use the custom image to create identical provisioned lab VMs.

+To create a custom image from a lab VM, take the following steps:

+1. In the [Azure portal](https://go.microsoft.com/fwlink/p/?LinkID=525040), on your lab's **Overview** page, select the VM to use for the image from the **My virtual machines** list.

+ :::image type="content" source="./media/devtest-lab-create-custom-image-vm/overview-page.png" alt-text="Screenshot that shows a V M selected on a lab's Overview page.":::

+1. On the VM's **Overview** page, select **Create custom image** under **Operations** in the left navigation.

+1. On the **Create custom image** page, enter a **Name** and optional **Description** for the custom image.

+1. Under **Image preparation**, select one of the following options:

+ - **I have not generalized this virtual machine** if you haven't run [sysprep](/windows-hardware/manufacture/desktop/sysprep--system-preparation--overview) and don't want to run sysprep on the VM when creating the custom image.

+ - **I have already generalized this virtual machine** if you already ran sysprep on the VM.

+ - **Generalize this virtual machine (Run sysprep)** if you haven't run sysprep and you want sysprep to be run on the VM when creating the custom image.

+1. Select **OK**.

+ :::image type="content" source="./media/devtest-lab-create-custom-image-vm/create-custom-image.png" alt-text="Screenshot that shows the Create custom image selection on a V M's Overview page.":::

+The custom image is created and stored in the lab's storage account. The image is now available in the list of base images for creating a new lab VM.

+- [Create a custom image from a VHD file](devtest-lab-create-template.md)

+- [Compare custom images and formulas in DevTest Labs](devtest-lab-comparing-vm-base-image-types.md)

+- [Create a custom image factory in Azure DevTest Labs](image-factory-create.md)

+description: This article describes primary Azure DevTest Labs scenarios, and how an organization can begin exploring DevTest Labs.

+# Azure DevTest Labs scenarios

+This article discusses how to use Azure DevTest Labs for several different development, test, and training scenarios. Here are some popular DevTest Labs scenarios:

+- Developers need many, sometimes different virtual machines (VMs) and environments as they iterate on apps.

+- Testers use many identical or different VMs and environments for performance testing and sandboxed investigations.

+- Teachers and trainers periodically need new classroom, lab, and hackathon VMs and environments.

+The following sections describe how DevTest Labs supports these scenarios, while helping lab owners and administrators control lab access and costs.

+## Lab creation

+Labs are the starting point in DevTest Labs. After you create a lab, you can:

+- Add lab users.

+- Create preconfigured VMs that any lab user can claim.

+- Define images, formulas, and templates for lab users to quickly create their own VMs and environments.

+- Use [configuration and policies](devtest-lab-set-lab-policy.md) to manage the lab and control costs.

+- [Integrate with Azure DevOps](devtest-lab-dev-ops.md) to support DevOps scenarios.

+- Link to public and private Git repositories for access to artifacts and ARM templates.

+The following diagram shows how lab owners can configure policies and provide resources for lab users:

+

+To create a lab in the Azure portal, see [Create a lab in Azure DevTest Labs](devtest-lab-create-lab.md).

+You can also automate lab creation, including custom settings, with a reusable *Azure Resource Manager (ARM) template*. For more information, see [Create a lab by using a Resource Manager template](./devtest-lab-faq.yml#how-do-i-create-a-lab-from-a-resource-manager-template-).

+### Add a virtual network to a lab

+DevTest Labs creates a new virtual network for each lab. If you have another virtual network configured with Azure ExpressRoute or site-to-site VPN, you can add it to your lab. You can then use that virtual network for creating lab VMs. For more information, see [Configure a virtual network in Azure DevTest Labs](devtest-lab-configure-vnet.md).

+### Add users to labs

+Lab owners can add users to labs by using the Azure portal or a PowerShell script. For more information, see [Add lab owners, contributors, and users in Azure DevTest Labs](devtest-lab-add-devtest-user.md). Lab users don't need an Azure account, as long as they have a Microsoft account.

+Lab users can view all lab resources, such as VMs, policies, and virtual networks. Lab users can't modify policies, or access VMs that other users create or claim.

+### Configure lab policies to control costs

+To monitor and control costs, lab administrators and owners can:

+- [Limit the number of VMs each user can create or claim](devtest-lab-set-lab-policy.md#set-virtual-machines-per-user).

+- Allow only certain [VM sizes](devtest-lab-set-lab-policy.md#set-allowed-virtual-machine-sizes) in the lab.

+- Configure [auto-shutdown](devtest-lab-set-lab-policy.md#set-auto-shutdown) and auto-start policies to stop and restart all VMs at particular times of day. VM auto-shutdown doesn't apply to PaaS resources in environments.

+- [Manage cost targets and notifications](devtest-lab-configure-cost-management.md).

+- Use the [cost by resource](devtest-lab-configure-cost-management.md#view-cost-by-resource) page to track costs of environments.

+## Development and test VMs

+Developers and testers might need many identical VMs for performance or load testing, or need different types of VMs for different projects or iterations. DevTest Labs users can create, configure, and access VMs on demand to meet their needs. Starting with common VM images promotes consistency across teams.

+In DevTest Labs, developers can:

+- Quickly provision VMs on demand, or [claim existing preconfigured VMs](devtest-lab-add-claimable-vm.md).

+- Self-service their own VMs without needing subscription-level permissions.

+- Directly use [virtual networks](devtest-lab-configure-vnet.md) that lab owners and admins set up, without needing special permissions.

+- Easily customize their VMs by [adding artifacts](devtest-lab-add-vm.md#add-artifacts-after-installation) as needed.

+### Create VMs

+Lab users can create lab VMs in minutes by choosing from a wide variety of ready-made Azure Marketplace images. To learn about making selected Marketplace images available for lab users, see [Configure Azure Marketplace images](devtest-lab-configure-marketplace-images.md).

+Lab owners can also install needed software on a VM, save the VM as a *custom image*, and make the image available in the lab. Lab users can use the custom image to create VMs that have the software preinstalled. For more information, see [Create a custom image](devtest-lab-create-custom-image-from-vm-using-portal.md).

+You can use an *image factory* to automatically build and distribute your custom images on a regular basis. This configuration-as-code solution eliminates the need to manually maintain VM images, by keeping the base OS and components up to date. For more information, see [Create a custom image factory](image-factory-create.md).

+### Use reusable formulas for VMs

+A DevTest Labs *formula* is a list of default property values for VMs. A lab owner can create a formula in the lab by picking a VM image, a VM size based on CPU and RAM, and a virtual network. Lab users can see the formula and use it to create VMs. For more information, see [Manage DevTest Labs formulas](devtest-lab-manage-formulas.md).

+### Use artifacts for VM customization

+Lab users can add *artifacts* to configure their lab VMs. Artifacts can be:

+- Tools to install on the VM, like agents, Fiddler, or Visual Studio.

+- Actions to run on the VM, like cloning a repo.

+- Applications to test.

+Many artifacts are available out-of-the-box. You can also create *custom artifacts* if you need more customization. You store custom artifacts in a private Git repo you connect to your lab, so all lab users can add the artifacts to their VMs. For more information, see [Create custom artifacts for DevTest Labs](devtest-lab-artifact-author.md) and [Add an artifact repository to a lab](add-artifact-repository.md).

+You can add an Active Directory domain-join artifact to join VMs to an Active Directory domain at creation. This artifact applies only to domains.

+## Multi-VM environments

+Many development and test scenarios require multi-VM *environments* equipped with platform-as-a-service (PaaS) resources. Examples include Azure Web Apps, SharePoint farms, and Service Fabric clusters. Creating and managing environments across an enterprise can require significant effort.

+With DevTest Labs, teams can easily create, update, or duplicate multi-VM environments. Developers can use fully configured environments to develop and test the latest versions of their apps. DevTest Labs environments ensure consistency across teams.

+By using ARM templates to deploy environments, you can:

+- Repeatedly deploy multiple preconfigured VMs in a consistent state.

+- Define infrastructure and configuration for Windows or Linux environments.

+- Provision Azure PaaS resources and track their costs.

+For more information, see [Use ARM templates to create DevTest Labs environments](devtest-lab-create-environment-from-arm.md).

+### Give users Contributor rights to environment resources

+By default, DevTest Labs creates environments in their own resource groups, and DevTest Labs users get only read access to those environments. With read-only access, users can't add or change resources in their environments. But developers often need to investigate different technologies or infrastructure designs.

+Lab owners can allow users more control by giving them Contributor rights to the environments they create. Contributors can add or change Azure resources as necessary in their development or test environments. For more information, see [Configure environment user rights](devtest-lab-create-environment-from-arm.md#configure-environment-user-rights).

+## Classroom, training, and hackathon labs

+DevTest Labs is well-suited for transient activities like workshops, hands-on labs, training, or hackathons. In these scenarios:

+- Training leaders or lab owners can use custom templates to create identical, isolated VMs or environments.

+- Trainees can [access the lab by using a URL](./devtest-lab-faq.yml#how-do-i-share-a-direct-link-to-my-lab-).

+- Trainees can claim already-created, preconfigured machines with a single action.

+- Lab owners can control lab costs and lifespan by:

+ - Configuring policies.

+ - Setting VM expiration dates.

+ - Deleting VMs and labs when the activity is over.

+### Delete labs and VMs

+Lab owners can manage costs by deleting labs and VMs when they're no longer needed.

+- Set [expiration dates](devtest-lab-set-lab-policy.md#set-expiration-date) on VMs.

+- [Delete labs](devtest-lab-delete-lab-vm.md#delete-a-lab) and all related resources.

+- [Delete all lab VMs by running a single PowerShell script](./devtest-lab-faq.yml#how-do-i-automate-the-process-of-deleting-all-the-vms-in-my-lab-).

+## Proof of concept and scaled deployments

+To start exploring DevTest Labs, organizations can use [proof of concept](deliver-proof-concept.md) and [scaled deployments](devtest-lab-guidance-scale.md).

+- Proof of concept uses a concentrated effort from a single team to establish organizational value.

+- A scaled deployment uses weeks or months of reviewing and planning to deploy DevTest Labs to an enterprise with hundreds or thousands of developers.

+While an immediate scaled deployment sounds tempting, this approach often fails without a proof of concept. It's best to start small, learn from a single team, repeat the same approach with a few more teams, and then plan a scaled deployment based on the knowledge gained.

+For a successful proof of concept:

+1. Pick one or two teams.

+1. Identify the teams' scenarios, such as developer VMs or test environments.

+1. Document current use cases.

+1. Deploy DevTest Labs to fulfill the teams' scenarios and use cases.

+ Title: Stop and resize lab VMs

+description: Learn how to change the size of a virtual machine (VM) in Azure DevTest Labs based on changing needs for CPU, network, or disk performance.

+# Resize a lab VM in Azure DevTest Labs

+Azure DevTest Labs supports changing the size of a lab virtual machine (VM), based on changing needs for CPU, network, or disk performance. This article describes how to resize a lab VM.

+> The resize feature complies with lab policy for [allowed VM sizes](devtest-lab-set-lab-policy.md#set-allowed-virtual-machine-sizes). You can resize a VM only to sizes that lab policy allows.

+## Stop the VM

+To avoid losing work, disconnect from and stop the VM before resizing it.

+1. If you're connected to the VM through secure shell (SSH) or remote desktop session (RDP), save your work and disconnect from the VM.

+1. In the [Azure portal](https://go.microsoft.com/fwlink/p/?LinkID=525040), on your lab's **Overview** page, select the VM you want to resize from the list under **My virtual machines**.

+ :::image type="content" source="./media/devtest-lab-resize-vm/overview-page.png" alt-text="Screenshot that shows a V M selected on a lab's Overview page.":::

+1. On the VM's **Overview** page, select **Stop** on the toolbar.

+ :::image type="content" source="./media/devtest-lab-resize-vm/stop-vm.png" alt-text="Screenshot that shows selecting Stop on the Overview page for a V M.":::

+Once the VM stops, or if the VM is already stopped, **Stop** is grayed out.

+## Resize the VM

+1. On the VM's **Overview** page, select **Size** under **Settings** in the left navigation.

+ :::image type="content" source="./media/devtest-lab-resize-vm/size-menu.png" alt-text="Screenshot that shows selecting Size in the V M's left navigation.":::

+1. On the **Select a VM size** screen, select a new size for your VM, and then select **Select**.

+ :::image type="content" source="./media/devtest-lab-resize-vm/select-size.png" alt-text="Screenshot that shows selecting a V M size.":::

+ You can check the status of the resize operation in the **Notifications** window.

+ :::image type="content" source="./media/devtest-lab-resize-vm/resize-status.png" alt-text="Screenshot of the Notifications window that shows resizing status.":::

+1. When the resize finishes, start the VM by selecting **Start** from the VM's **Overview** page toolbar.

+For more information about the resize feature for Azure VMs, see [Resize virtual machines](https://azure.microsoft.com/blog/resize-virtual-machines/).

+ Title: Control costs with lab policies

+# Manage lab policies to control costs in Azure DevTest Labs

+This article describes how you can manage Azure DevTest Labs policies to control lab costs and minimize waste. Lab policies you can set to control costs include:

+- Allowed virtual machine (VM) sizes

+- Maximum VMs per user

+- Maximum VMs per lab

+- Auto-shutdown settings

+- Auto-shutdown policy settings

+- Autostart settings

+## Access lab Configuration and policies

+1. In the [Azure portal](https://go.microsoft.com/fwlink/p/?LinkID=525040), on the **Overview** page for your lab, select **Configuration and policies** from the left navigation.

+ :::image type="content" source="./media/devtest-lab-set-lab-policy/configuration-policies-menu.png" alt-text="Screenshot that shows the Configuration and policies menu for a lab.":::

+1. On the **Configuration and policies** page, select the policy you want to configure from the left navigation.

+ :::image type="content" source="./media/devtest-lab-set-lab-policy/policies-menu.png" alt-text="Screenshot that shows a lab's Configuration and Policies options.":::

+## Set allowed virtual machine sizes

+This policy specifies the VM sizes that users can create in the lab.

+1. On the lab's **Configuration and policies** page, select **Allowed virtual machines sizes** from the left navigation.

+

+1. On the **Allowed virtual machines sizes** screen, select **Yes** or **No** to enable or disable the policy.

+1. If you enable the policy, select the VM sizes to allow in the lab.

+ :::image type="content" source="./media/devtest-lab-set-lab-policy/allowed-vm-sizes.png" alt-text="Screenshot showing Allowed virtual machines sizes.":::

+This policy specifies the maximum number of VMs that an individual lab user can own.

+1. On the lab's **Configuration and policies** page, select **Virtual machines per user** from the left navigation.

+1. On the **Virtual machines per user** screen, under **Limit the number of virtual machines**, select **On** or **Off** to enable or disable the policy.

+1. If you enable the policy, under **What is the limit**, enter the maximum number of VMs that a user can own.

+1. Under **Limit the number of virtual machines using premium OS disks**, select **On** or **Off** to enable or disable limiting the number of a user's VMs that use premium solid-state disks (SSDs).

+1. If you selected **On**, enter the maximum number of VMs using premium disks that a user can own.

+ > [!NOTE]

+ > This policy applies only to Premium SSDs. The limitation doesn't apply to Standard SSDs.

+ :::image type="content" source="./media/devtest-lab-set-lab-policy/max-vms-per-user.png" alt-text="Screenshot showing Virtual machines per user.":::

+If a user tries to create or claim a VM when the user limit has been met, an error message indicates that the user can't exceed their VM limit.

+This policy specifies the maximum number of VMs that all users can create or claim in the current lab.

+1. On the lab's **Configuration and policies** page, select **Virtual machines per lab** from the left navigation.

+1. On the **Virtual machines per user** screen, under **Limit the number of virtual machines**, select **On** or **Off** to enable or disable the policy.

+1. If you enable the policy, under **What is the limit**, enter the maximum number of VMs that can be created or claimed.

+1. Under **Limit the number of virtual machines using premium OS disks**, select **On** or **Off** to enable or disable limiting the number of VMs that use premium SSDs.

+1. If you selected **On**, enter the maximum number of VMs that can use premium disks.

+ :::image type="content" source="./media/devtest-lab-set-lab-policy/max-vms-per-lab.png" alt-text="Screenshot showing Virtual machines per lab.":::

+If a user tries to create or claim a VM when the lab limit has been met, an error message indicates that the VM can't be created or claimed.

+## Set auto-shutdown

+Auto-shutdown helps minimize lab waste by shutting down lab VMs at a specific time of day.

+1. On the lab's **Configuration and policies** page, select **Auto-shutdown** from the left navigation.

+1. On the **Auto-shutdown** screen, for **Enabled**, select **On** or **Off** to enable or disable the policy.

+1. For **Scheduled shutdown** and **Time zone**, if you enabled auto-shutdown, specify the time and time zone to shut down all lab VMs.

+1. For **Send notification before auto-shutdown**, select **Yes** or **No** for the option to send a notification before the specified auto-shutdown time.

+ If you choose **Yes**, enter a webhook URL endpoint under **Webhook URL** or semicolon-separated email addresses under **Email address** where you want to post or send the notification.

+ :::image type="content" source="./media/devtest-lab-set-lab-policy/auto-shutdown.png" alt-text="Screenshot showing Auto shutdown.":::

+By default, auto-shutdown applies to all lab VMs. If allowed by policy, lab users can override auto-shutdown settings for their individual lab VMs. To access auto-shutdown settings for individual VMs:

+1. Select the VM from **My virtual machines** on the lab **Overview** page.

+1. On the home page for the VM, in the **Operations** section of the left navigation, select **Auto-shutdown**.

+For more information about auto-shutdown and sending notifications, see [Configure auto shutdown for labs and VMs in DevTest Labs](devtest-lab-auto-shutdown.md).

+## Set auto-shutdown policy

+Lab owners can configure auto-shutdown on all lab VMs centrally, and set a policy to let lab users override the settings for their own VMs. You can set auto-shutdown policy to allow lab users full control, partial control, or no control over their own VMs' auto-shutdown activity.

+> [!IMPORTANT]

+> Auto-shutdown policy changes apply only to new lab VMs, not to already-existing VMs.

+1. On the lab's **Configuration and policies** page, select **Auto shutdown policy** from the left navigation.

+1. Select one of the following options:

+ - **User sets a schedule and can opt out**: Lab users can override or opt out of lab auto-shutdown. Lab users can override the lab schedule, and they don't have to set any auto-shutdown for their VMs.

+ - **User sets a schedule and cannot opt out**: Lab users can override the lab schedule for their VMs, but they can't opt out of auto-shutdown. This option ensures that every VM in the lab is on some auto-shutdown schedule.

+ - **User has no control over the schedule set by lab administrator**: Lab users can't override or opt out of the lab auto-shutdown schedule. Lab users can set up auto-shutdown notifications for their own VMs.

+1. Select **Save**.

+ :::image type="content" source="./media/devtest-lab-set-lab-policy/auto-shutdown-policy-options.png" alt-text="Screenshot showing Auto-shutdown policy options.":::

+For more information and details about auto-shutdown policy, see [Configure lab auto shutdown policy](devtest-lab-auto-shutdown.md#configure-lab-auto-shutdown-policy).

+Autostart policy helps you minimize waste by specifying a specific time of day and days of the week to start up all lab VMs.

+1. On the lab's **Configuration and policies** page, select **Auto-start** from the left navigation.

+1. Select **Yes** or **No** to enable or disable the policy.

+1. If you enable this policy, specify the **Scheduled start**, **Time zone**, and **Days of the week** to start up the lab VMs.

+1. Select **Save**.

+ :::image type="content" source="./media/devtest-lab-set-lab-policy/auto-start.png" alt-text="Screenshot showing the Autostart selection.":::

+> [!NOTE]

+> This policy isn't automatically applied to current VMs in the lab. To apply this setting to current VMs, open the VM's page and change its **Auto-start** setting.

+For more information and details about autostart policy, see [Start up lab virtual machines automatically](devtest-lab-auto-startup-vm.md).

+Besides setting policies, here are more ways to control and manage DevTest Labs costs:

+- [Set a VM expiration date](devtest-lab-use-resource-manager-template.md#set-vm-expiration-date) when you create the VM.

+- [Delete labs or lab VMs](devtest-lab-delete-lab-vm.md) when you're finished with them.

+- [View and manage lab costs](devtest-lab-configure-cost-management.md), trends, and targets.

+> [!WARNING]

+> Cross tenant access to storage accounts is not supported. If cross tenant access is needed for your scenario, please reach out to the AzureML Data Support team alias at amldatasupport@microsoft.com for assistance with a custom code solution.

+> If you need to change your access keys for an Azure Storage account (account key or SAS token), be sure to sync the new credentials with your workspace and the datastores connected to it. Learn how to [sync your updated credentials](how-to-change-storage-access-key.md).

+> [!WARNING]

+> Cross tenant access to storage accounts is not supported. If cross tenant access is needed for your scenario, please reach out to the AzureML Data Support team alias at amldatasupport@microsoft.com for assistance with a custom code solution.

+> [!WARNING]

+> Cross tenant access to storage accounts is not supported. If cross tenant access is needed for your scenario, please reach out to the AzureML Data Support team alias at amldatasupport@microsoft.com for assistance with a custom code solution.

+ Title: Configure plan listing for a virtual machine offer on Azure Marketplace

+description: Configure plan listing for a virtual machine offer in the Microsoft commercial marketplace.

+# Configure plan listing for a virtual machine offer

+Configure the listing details of the plan. This pane displays specific information, which can differ from other plans in the same offer.

+## Plan name

+This field is automatically filled with the name that you gave your plan when you created it. This name appears on Azure Marketplace as the title of this plan. It is limited to 100 characters.

+## Plan summary

+Provide a short summary of your plan, not the offer. This summary is limited to 100 characters.

+## Plan description

+Describe what makes this software plan unique, and describe any differences between plans within your offer. Describe the plan only, not the offer. The plan description can contain up to 2,000 characters.

+Select **Save draft** before continuing to the next tab in the left-nav Plan menu, **Pricing and availability**.

+## Next steps

+- [Pricing and availability](azure-vm-plan-pricing-and-availability.md)

+- [Plan setup](azure-vm-plan-setup.md)

+ Title: Configure pricing and availability for a virtual machine offer on Azure Marketplace

+description: Configure pricing and availability for a virtual machine offer in the Microsoft commercial marketplace.

+# Configure pricing and availability for a virtual machine offer

+On this pane, you configure:

+- Markets where this plan is available. Every plan must be available in at least one [market](marketplace-geo-availability-currencies.md).

+- The price per hour.

+- Whether to make the plan visible to everyone or only to specific customers (a private audience).

+### Markets

+Every plan must be available in at least one market. Most markets are selected by default. To edit the list, select **Edit markets** and select or clear check boxes for each market location where this plan should (or shouldn't) be available for purchase. Users in selected markets can still deploy the offer to all Azure regions selected in the ["Plan setup"](azure-vm-plan-setup.md) section.

+Select **Select only Microsoft Tax Remitted** to select only countries/regions in which Microsoft remits sales and use tax on your behalf. Publishing to China is limited to plans that are either *Free* or *Bring-your-own-license* (BYOL).

+If you've already set prices for your plan in US dollar (USD) currency and add another market location, the price for the new market is calculated according to current exchange rates. Always review the price for each market before you publish. Review your pricing by selecting **Export prices (xlsx)** after you save your changes.

+When you remove a market, customers from that market who are using active deployments won't be able to create new deployments or scale up their existing deployments. Existing deployments aren't affected.

+Select **Save** to continue.

+### Pricing

+For the **License model**, select **Usage-based monthly billed plan** to configure pricing for this plan, or **Bring your own license** to let customers use this plan with their existing license.

+For a usage-based monthly billed plan, Microsoft will charge the customer for their hourly usage and they're billed monthly. This is our _Pay-as-you-go_ plan, where customers are only billed for the hours that they've used. When you select this plan, choose one of the following pricing options:

+- **Free** ΓÇô Your VM offer is free.

+- **Flat rate (recommended)** ΓÇô Your VM offer is the same hourly price regardless of the hardware it runs on.

+- **Per core** ΓÇô Your VM offer pricing is based on per CPU core count. You provide the price for one CPU core and weΓÇÖll increment the pricing based on the size of the hardware.

+- **Per core size** ΓÇô Your VM offer is priced based on the number of CPU cores on the hardware it's deployed on.

+- **Per market and core size** ΓÇô Assign prices based on the number of CPU cores on the hardware it's deployed on, and also for all markets. Currency conversion is done by you, the publisher. This option is easier if you use the import pricing feature.

+For **Per core size** and **Per market and core size**, enter a **Price per core**, and then select **Generate prices**. The tables of price/hour calculations are populated for you. You can then adjust the price per core, if you choose. If using the _Per market and core size_ pricing option, you can additionally customize the price/hour calculation tables for each market thatΓÇÖs selected for this plan.

+> [!NOTE]

+> To ensure that the prices are right before you publish them, export the pricing spreadsheet and review the prices in each market. Before you export pricing data, first select **Save draft** near the bottom of the page to save pricing changes.

+Some things to consider when selecting a pricing option:

+- For the first four options, Microsoft does the currency conversion.

+- Microsoft suggests using a flat rate pricing for software solutions.

+- Prices are fixed, so once the plan is published the prices can't be adjusted. However, if you would like to reduce prices for your VM offers you can open a [support ticket](support.md).

+> [!IMPORTANT]

+> Occasionally, Microsoft expands the list of supported core sizes available. When this occurs, we will notify you and request that you take action on your offer within a specified timeframe. If you do not review your offer within the timeframe specified, weΓÇÖll publish the new core sizes at the price that we have calculated for you. For details about updating core sizes, see [Update core size for an Azure virtual machine offer](azure-vm-plan-manage.md).

+### Free Trial

+You can offer a one-month, three-month, or six-month **Free Trial** to your customers.

+### Plan visibility

+You can design each plan to be visible to everyone or only to a preselected private audience.

+**Public**: Your plan can be seen by everyone.

+**Private**: Make your plan visible only to a preselected audience. After it's published as a private plan, you can update the private audience or change it to public. After you make a plan public, it must remain public. It can't be changed back to a private plan. If the plan is private, you can specify the private audience that will have access to this plan using *Azure tenant IDs*, *subscription IDs*, or both. Optionally, include a **Description** of each Azure tenant ID or subscription ID that you assign. Add up to 10 subscription IDs and tenant IDs manually or import a CSV spreadsheet if more than 10 IDs are required. For a published offer, select **Sync private audience** for the changes to the private audience to take effect automatically without needing to republish the offer.

+> [!NOTE]

+> A private audience is different from the preview audience that you defined on the **Preview audience** pane. A preview audience can access and view all private and public plans for validation purposes before it's published live to Azure Marketplace. A private audience can only access the specific plans that they are authorized to have access to once the offer is live.

+Private offers aren't supported with Azure subscriptions established through a reseller of the Cloud Solution Provider program (CSP).

+### Hide plan

+If your virtual machine is meant to be used only indirectly when it's referenced through another solution template or managed application, select this check box to publish the virtual machine but hide it from customers who might be searching or browsing for it directly.

+Any Azure customer can deploy the offer using either PowerShell or CLI. If you wish to make this offer available to a limited set of customers, then set the plan to **Private**.

+Hidden plans don't generate preview links. However, you can test them by [following these steps](azure-vm-create-faq.yml#how-do-i-test-a-hidden-preview-image-).

+Select **Save draft** before continuing to the next tab in the left-nav Plan menu, **Technical configuration**.

+## Next step

+- [Technical configuration](azure-vm-plan-technical-configuration.md)

+ Title: Reorder plans for a virtual machine offer on Azure Marketplace

+description: Reorder plans for a virtual machine offer in the Microsoft commercial marketplace.

+# Reorder plans

+For VM offers with more than one plan, you can change the order that your plans are shown to customers. The first plan listed will become the default plan that customers will see.

+1. Sign in to [Partner Center](https://go.microsoft.com/fwlink/?linkid=2166002).

+1. On the Home page, select the **Marketplace offers** tile.

+ [  ](./media/workspaces/partner-center-home.png#lightbox)

+1. On the Marketplace offers page, select the offer with the plans you want to reorder.

+1. In the left-nav, select **Plan overview**. Then select the **Edit display rank** button.

+1. In the menu that appears, use the hamburger icon to drag your plans to the desired order.

+1. After you reorder the plans for a currently published offer, you must [republish the offer](review-publish-offer.md).

+ Title: Plan setup for a virtual machine offer on Azure Marketplace

+description: Plan setup for a virtual machine offer in the Microsoft commercial marketplace.

+# Plan setup for a virtual machine offer

+## Plan setup

+Set the high-level configuration for the type of plan, specify whether it reuses a technical configuration from another plan, and identify the Azure regions where the plan should be available. Your selections here determine which fields are displayed on other panes for the same plan.

+### Azure regions

+Your plan must be made available in at least one Azure region.

+Select **Azure Global** to make your plan available to customers in all Azure Global regions that have commercial marketplace integration. For more information, see [Geographic availability and currency support](marketplace-geo-availability-currencies.md).

+Select **Azure Government** to make your plan available in the [Azure Government](../azure-government/documentation-government-welcome.md) region. This region provides controlled access for customers from US federal, state, local, or tribal entities, and for partners who are eligible to serve them. You, as the publisher, are responsible for any compliance controls, security measures, and best practices. Azure Government uses physically isolated datacenters and networks (located in the US only).

+Before you publish to [Azure Government](../azure-government/documentation-government-manage-marketplace-partners.md), test and validate your plan in the environment, because certain endpoints may differ. To set up and test your plan, request a trial account from the [Microsoft Azure Government trial](https://azure.microsoft.com/global-infrastructure/government/request/) page.

+> [!NOTE]

+> After your plan is published and available in a specific Azure region, you can't remove that region.

+### Azure Government certifications

+This option is visible only if you selected **Azure Government** as the Azure region in the preceding section.

+Azure Government services handle data that's subject to certain government regulations and requirements. For example, FedRAMP, NIST 800.171 (DIB), ITAR, IRS 1075, DoD L4, and CJIS. To bring awareness to your certifications for these programs, you can provide up to 100 links that describe them. These can be either links to your listing on the program directly or links to descriptions of your compliance with them on your own websites. These links are visible to Azure Government customers only.

+Select **Save draft** before continuing to the next tab in the left-nav Plan menu, **Plan listing**.

+## Next steps

+- [Plan listing](azure-vm-plan-listing.md)

+ Title: Technical configuration for a virtual machine offer on Azure Marketplace

+description: Configure the technical configuration for a virtual machine offer plan.

+# Technical configuration for a virtual machine offer

+Provide the images and other technical properties associated with this plan.

+## Reuse technical configuration

+This option lets you use the same technical configuration settings across plans within the same offer and therefore leverage the same set of images. If you enable the _reuse technical configuration_ option, your plan will inherit the same technical configuration settings as the base plan you select. When you change the base plan, the changes are reflected on the plan reusing the configuration.

+Some common reasons for reusing the technical configuration settings from another plan include:

+- The same images are available for both *Pay as you go* and *BYOL*.

+- To reuse the same technical configuration from a public plan for a private plan with a different price.

+- Your solution behaves differently based on the plan the user chooses to deploy. For example, the software is the same, but features vary by plan.

+Leverage [Azure Instance Metadata Service](../virtual-machines/windows/instance-metadata-service.md) (IMDS) to identify which plan your solution is deployed within to validate license or enabling of appropriate features.

+If you later decide to publish different changes between your plans, you can detach them. Detach the plan reusing the technical configuration by deselecting this option with your plan. Once detached, your plan will carry the same technical configuration settings at the place of your last setting and your plans may diverge in configuration. A plan that has been published independently in the past cannot reuse a technical configuration later.

+## Operating system

+Select the **Windows** or **Linux** operating system family.

+Select the Windows **Release** or Linux **Vendor**.

+Enter an **OS friendly name** for the operating system. This name is visible to customers.

+## Recommended VM sizes

+Select the link to choose up to six recommended virtual machine sizes to display on Azure Marketplace.

+## Open ports

+Add open public or private ports on a deployed virtual machine.

+## Properties

+Here is a list of properties that can be selected for your VM.

+- **Supports backup**: Enable this property if your images support Azure VM backup. Learn more about [Azure VM backup](../backup/backup-azure-vms-introduction.md).

+- **Supports accelerated networking**: Enable this property if the VM images for this plan support single root I/O virtualization (SR-IOV) to a VM, enabling low latency and high throughput on the network interface. Learn more about [accelerated networking](https://go.microsoft.com/fwlink/?linkid=2124513).

+- **Supports cloud-init configuration**: Enable this property if the images in this plan support cloud-init post deployment scripts. Learn more about [cloud-init configuration](../virtual-machines/linux/using-cloud-init.md).

+- **Supports hotpatch**: Windows Server Azure Editions supports Hot Patch. Learn more about [Hot Patch](../automanage/automanage-hotpatch.md).

+- **Supports extensions**: Enable this property if the images in this plan support extensions. Extensions are small applications that provide post-deployment configuration and automation on Azure VMs. Learn more about [Azure virtual machine extensions](./azure-vm-certification-faq.yml#vm-extensions).

+- **Is a network virtual appliance**: Enable this property if this product is a Network Virtual Appliance. A network virtual appliance is a product that performs one or more network functions, such as a Load Balancer, VPN Gateway, Firewall or Application Gateway. Learn more about [network virtual appliances](https://go.microsoft.com/fwlink/?linkid=2155373).

+- **Remote desktop or SSH disabled**: Enable this property if virtual machines deployed with these images don't allow customers to access it using Remote Desktop or SSH. Learn more about [locked VM images](./azure-vm-certification-faq.yml#locked-down-or-ssh-disabled-offer).

+- **Requires custom ARM template for deployment**: Enable this property if the images in this plan can only be deployed using a custom ARM template. To learn more see the [Custom templates section of Troubleshoot virtual machine certification](./azure-vm-certification-faq.yml#custom-templates).

+## Generations

+Generating a virtual machine defines the virtual hardware it uses. Based on your customerΓÇÖs needs, you can publish a Generation 1 VM, Generation 2 VM, or both.

+1. When creating a new offer, select a **Generation type** and enter the requested details:

+ :::image type="content" source="./media/create-vm/azure-vm-generations-image-details-1.png" alt-text="A view of the Generation detail section in Partner Center.":::

+2. To add another generation to a plan, select **Add generation**...

+ :::image type="content" source="./media/create-vm/azure-vm-generations-add.png" alt-text="A view of the 'Add Generation' link.":::

+ ...and enter the requested details:

+ :::image type="content" source="./media/create-vm/azure-vm-generations-image-details-3.png" alt-text="A view of the generation details window.":::

+<!-- The **Generation ID** you choose will be visible to customers in places such as product URLs and ARM templates (if applicable). Use only lowercase, alphanumeric characters, dashes, or underscores; it cannot be modified once published.

+-->

+3. To update an existing VM that has a Generation 1 already published, edit details on the **Technical configuration** page.

+To learn more about the differences between Generation 1 and Generation 2 capabilities, see [Support for generation 2 VMs on Azure](../virtual-machines/generation-2.md).

+> [!NOTE]

+> A published generation requires at least one image version to remain available for customers. To remove the entire plan (along with all its generations and images), select **Deprecate plan** on the **Plan Overview** page (see first section in this article).

+## VM images

+Provide a disk version and the shared access signature (SAS) URI for the virtual machine images. Add up to 16 data disks for each VM image. Provide only one new image version per plan in a specified submission. After an image has been published, you can't edit it, but you can delete it. Deleting a version prevents both new and existing users from deploying a new instance of the deleted version.

+These two required fields are shown in the prior image above:

+- **Disk version**: The version of the image you are providing.

+- **OS VHD link**: The image stored in Azure Compute Gallery (formerly know as Shared Image Gallery). Learn how to capture your image in an [Azure Compute Gallery](azure-vm-create-using-approved-base.md#capture-image).

+Data disks (select **Add data disk (maximum 16)**) are also VHD shared access signature URIs that are stored in their Azure storage accounts. Add only one image per submission in a plan.

+Regardless of which operating system you use, add only the minimum number of data disks that the solution requires. During deployment, customers can't remove disks that are part of an image, but they can always add disks during or after deployment.

+> [!NOTE]

+> If you provide your images using SAS and have data disks, you also need to provide them as SAS URI. If you are using a shared image, they are captured as part of your image in Azure Compute Gallery. Once your offer is published to Azure Marketplace, you can delete the image from your Azure storage or Azure Compute Gallery.

+Select **Save draft**, then select **← Plan overview** at the top left to see the plan you just created.

+Once your VM image has published, you can delete the image from your Azure storage.

+## Reorder plans (optional)

+For VM offers with more than one plan, you can change the order that your plans are shown to customers. The first plan listed will become the default plan that customers will see.

+1. On the **Plan overview** page, select the **Edit display rank** button.

+1. In the menu that appears, use the hamburger icon to drag your plans to the desired order.

+## Next steps

+- [Resell through CSPs](azure-vm-resell-csp.md)

+VM offers require at least one plan. A plan defines the solution scope and limits, and the associated pricing. You can create multiple plans for your offer to give your customers different technical and licensing options, as well as trial opportunities. For VM offers with more than one plan, you can change the order that your plans are shown to customers. The first plan listed will become the default plan that customers will see. For info about how to reorder plans, see [Reorder plans](azure-vm-plan-reorder-plans.md). For general guidance about plans, including pricing models, free trials, and private plans, see [Plans and pricing for commercial marketplace offers](plans-pricing.md).

+| Analytics | Added a [Revenue Dashboard](revenue-dashboard.md) to Partner Center, including a revenue report, [sample queries](analytics-sample-queries.md#revenue-report-queries), and [FAQs](/azure/marketplace/analytics-faq#revenue) page. | 2021-12-08 |

+| Offers | Additional properties at the plan level are now available for Azure Virtual Machine offers. See the [virtual machine technical configuration properties](azure-vm-plan-technical-configuration.md#properties) article for more information. | 2021-07-26 |

+| <a name="dst"></a>**Dst** | Recommended | String | A unique identifier of the authetication target. <br><br>This field may alias the [TargerDvcId](#targetdvcid), [TargetHostname](#targethostname), [TargetIpAddr](#targetipaddr), [TargetAppId](#targetappid), or [TargetAppName](#targetappname) fields. <br><br>Example: `192.168.12.1` |

+1. Define the `CallerContext` value as `Exclude<parser name>`, where `<parser name>` is the name of the unifying parsers you want to exclude the parser from.

+1. Define the `SourceSpecificParser` value `Exclude<parser name>`, where `<parser name>`is the name of the parser you want to exclude, without a version specifier.

+| `Exclude_Im_Dns` | `Exclude_Im_Dns_AzureFirewall` |

+| `Exclude_ASim_Dns` | `Exclude_ASim_Dns_AzureFirewall` |

+The sticky bit is a more advanced feature of a POSIX container. In the context of Data Lake Storage Gen2, it is unlikely that the sticky bit will be needed. In summary, if the sticky bit is enabled on a directory, a child item can only be deleted or renamed by the child item's owning user, the directory's owner, or the Superuser ($superuser).

+For more information on monitoring Apache Spark applications, see the [Monitor Apache Spark applications in Synapse Studio](how-to-monitor-spark-applications.md) article.

+To analyze historical queries, see [Historical query storage and analysis in Azure Synapse Analytics](../sql/query-history-storage-analysis.md).

+|  |**Fivetran**<br>Fivetran helps you centralize data from disparate sources. It features a zero maintenance, zero configuration data pipeline product with a growing list of built-in connectors to all the popular data sources. Setup takes five minutes after authenticating to data sources and target data warehouse.|[Product page](https://www.fivetran.com/partners-microsoft-azure)<br>[Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/fivetran.fivetran_data_pipelines?tab=Overview)<br> |

+|**Automatic Performance Monitoring (Preview)**|[Query Store](/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?toc=/azure/synapse-analytics/sql-data-warehouse/toc.json&bc=/azure/synapse-analytics/sql-data-warehouse/breadcrumb/toc.json&view=azure-sqldw-latest&preserve-view=true) is now available in Preview in SQL Analytics in Azure Synapse. Query Store is designed to help you with query performance troubleshooting by tracking queries, query plans, runtime statistics, and query history to help you monitor the activity and performance of your data warehouse. Query Store is a set of internal stores and Dynamic Management Views (DMVs) that allow you to:<br/><br/>&bull; &nbsp; Identify and tune top resource consuming queries<br/>&bull; &nbsp; Identify and improve unplanned workloads<br/>&bull; &nbsp; Evaluate query performance and impact to the plan by changes in statistics, indexes, or system size (DWU setting)<br/>&bull; &nbsp; See full query text for all queries executed<br/><br/>The Query Store contains three actual stores:<br/>&bull; &nbsp; A plan store for persisting the execution plan information<br/>&bull; &nbsp; A runtime stats store for persisting the execution statistics information<br/>&bull; &nbsp; A wait stats store for persisting wait stats information.<br/><br/>SQL Analytics in Azure Synapse manages these stores automatically and provides an unlimited number of queries storied over the last seven days at no additional charge. Enabling Query Store is as simple as running an ALTER DATABASE T-SQL statement: <br/>sql -ALTER DATABASE [DatabaseName] SET QUERY_STORE = ON;-For more information on Query Store, see the article, [Monitoring performance by using the Query Store](/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store), and the Query Store DMVs, such as [sys.query_store_query](/sql/relational-databases/system-catalog-views/sys-query-store-query-transact-sql?toc=/azure/synapse-analytics/sql-data-warehouse/toc.json&bc=/azure/synapse-analytics/sql-data-warehouse/breadcrumb/toc.json&view=azure-sqldw-latest&preserve-view=true). Here is the [blog post](https://azure.microsoft.com/blog/automatic-performance-monitoring-in-azure-sql-data-warehouse-with-query-store/) announcing the release. For more information on historical query analysis, see [Historical query storage and analysis in Azure Synapse Analytics](../sql/query-history-storage-analysis.md).|

+az group create --name myCentOSGroup --location eastus

+ --resource-group myCentOSGroup \

+ --name centos83 \

+ --image OpenLogic:CentOS:8_3:latest \

+ --admin-username azureuser \

+ssh azureuser@<publicIpAddress>

+ID | Command line | Date and time | Action(s) | Altered

+--

+ 3 | -y install httpd | 2022-02-18 18:30 | Install | 7

+ 2 | -y upgrade | 2022-02-18 18:23 | I, O, U | 321 EE

+ 1 | | 2021-02-04 19:20 | Install | 496 EE

+Changes to documents in the SAP on Azure workload section are listed at the [end of this article](./get-started.md#change-log). The entries in the change log are kept for around 180 days.

+- February 13, 2022: Corrected broken links to HANA hardware directory in the following documents: SAP Business One on Azure Virtual Machines, Available SKUs for HANA Large Instances, Certification of SAP HANA on Azure (Large Instances), Installation of SAP HANA on Azure virtual machines, SAP workload planning and deployment checklist, SAP HANA infrastructure configurations and operations on Azure, SAP HANA on Azure Large Instance migration to Azure Virtual Machines, Install and configure SAP HANA (Large Instances) ,on Azure, High availability of SAP HANA scale-out system on Red Hat Enterprise Linux, High availability for SAP HANA scale-out system with HSR on SUSE Linux Enterprise Server, High availability of SAP HANA on Azure VMs on SUSE Linux Enterprise Server, Deploy a SAP HANA scale-out system with standby node on Azure VMs by using Azure NetApp Files on SUSE Linux Enterprise Server, SAP workload on Azure virtual machine supported scenarios, What SAP software is supported for Azure deployments

+- January 30, 2022: Adding context about SQL Server proprotional fill and expectations that SQL Server data files should be the same size and should have the same free space in [SQL Server Azure Virtual Machines DBMS deployment for SAP NetWeaver](./dbms_guide_sqlserver.md)

+ :::image type="content" source="./media/global-hub-profile/include-exclude-1.png" alt-text="Screenshot showing how to include or exclude hub from profile." lightbox="./media/global-hub-profile/include-exclude-1.png":::

+ Title: 'How to monitor P2S connections'

+description: Learn how to set up an Azure workbook for P2S monitoring.

+# How to monitor point-to-site connections for Virtual WAN

+This section documents how to create an Azure Workbook that shows relevant data of User VPN clients connected to Azure Virtual WAN.

+## Before you begin

+To complete the steps in this article, you need to have a virtual WAN, a hub, and a User VPN Gateway. To create these resources, follow the steps in this article: [Create virtual WAN, a hub, and a gateway](virtual-wan-point-to-site-portal.md)

+## Workbook solution architecture

+When you work with Azure Virtual WAN and look at metrics, itΓÇÖs most often done from within the context of an Azure workbook. In this solution, we'll use what's already available in Azure workbook and enrich it with more details, especially about active connections.

+* **AzureDiagnostics:** These logs are received by enabling P2S Debugging through Azure Monitor debug settings and enabling the following logs: GatewayDiagnosticLog, IKEDiagnosticLog, P2SDiagnosticLog, AllMetrics. Some logs are noisy and costly regarding Log Analytics cost, specially IKEDiagnostics.

+* **Get-AzP2sVpnGatewayDetailedConnectionHealth:** This is a PowerShell command (running in a function app) to get active sessions details. This command only supports storing data in a storage account based on a SAS Key.

+The following figure shows the involved components in the suggested solution:

+ :::image type="content" source="./media/monitor-point-to-site-connections/workbook-architecture.png" alt-text="Screenshot shows workbook architecture.":::

+The VPN service is running in the Azure vWAN P2S VPN gateway. It has associated metrics and debugs settings that can be read from within an Azure workbook. To get the extra information that the PowerShell command can provide, we choose to execute this command in an Azure function app. From the function app, we store the output in an Azure storage account.

+The output stored in the storage account is fetched from within the workbook by using a special function called "externaldata".

+## Create Azure storage account

+1. In the portal, in the **Search resources** bar, type **Storage accounts**.

+1. Select **Storage accounts** from the results. On the Storage accounts page, select **+ Create** to open the **Create a storage account** page.

+1. On the **Create WAN** page, on the **Basics** tab, fill in the fields. Modify the example values to apply to your environment.

+ :::image type="content" source="./media/monitor-point-to-site-connections/storage-account-basics.png" alt-text="Screenshot shows the basics section of creating a storage account.":::

+ * **Subscription**: Select the subscription that you want to use

+ * **Resource group**: Create new or use existing

+ * **Storage account name**: Type the name you want to call your storage account

+ * **Region**: Select a region for your storage account

+ * **Performance**: Standard or Premium. **Standard** is adequate for our monitoring purposes

+ * **Redundancy**: Choose between Locally redundant storage, Geo-redundant storage, Zone-redundant storage, and Geo-zone-redundant storage

+ After you finish filling out the fields, at the bottom of the page, select **Next: Advanced>**.

+1. On the **Advanced** page, fill out the following fields.

+ :::image type="content" source="./media/monitor-point-to-site-connections/storage-account-advanced.png" alt-text="Screenshot shows advanced section of creating a storage account.":::

+ * **Require secure transfer for REST API operations**: Choose **Enabled**.

+ * **Enable blob public access**: Choose **Disabled**.

+ * **Enable storage account key access**: Choose **Enabled**.

+ * **Default to Azure Active Directory authorization in the Azure portal**: Choose **Enabled**.

+ * **Minimum TLS version**: Choose **Version 1.2**.

+1. Select **Review + create** at the bottom to run validation.

+1. Once validation passes, select **Create** to create the storage account.

+## Create container

+1. Once the deployment is complete, go to the resource.

+1. On the left panel, select **Containers** under **Data storage**.

+ :::image type="content" source="./media/monitor-point-to-site-connections/container-create.png" alt-text="Screenshot shows the initial container page." lightbox="./media/monitor-point-to-site-connections/container-create.png":::

+1. Select **+ Container** to create a new container.

+1. Type a **Name** for your container and select **Create**.

+## Create and upload blob to container

+1. On your computer, open a text editor application such as **Notepad**.

+ :::image type="content" source="./media/monitor-point-to-site-connections/notepad.png" alt-text="Screenshot shows how to open notepad.":::

+1. Leave the text file empty and select **File -> Save As**.

+1. Save the empty text file with a name of your choice followed by the **.json** extension.

+ :::image type="content" source="./media/monitor-point-to-site-connections/empty-json.png" alt-text="Screenshot shows how to save json file." lightbox="./media/monitor-point-to-site-connections/empty-json.png" :::

+1. Go back to the **Containers** section in portal.

+ :::image type="content" source="./media/monitor-point-to-site-connections/container-after.png" alt-text="Screenshot shows the container section after creating new container." lightbox="./media/monitor-point-to-site-connections/container-after.png" :::

+1. Select on the second row, which corresponds to the container you created (not $logs).

+1. If you see this red warning message saying ""**You do not have permission...**"", then select **Switch to Access key** as your authentication method. This is located right below the red warning box.

+1. Select **Upload**.

+ :::image type="content" source="./media/monitor-point-to-site-connections/specific-container.png" alt-text="Screenshot shows the specific container that was created by user." lightbox="./media/monitor-point-to-site-connections/specific-container.png" :::

+1. Select the file corresponding to your empty JSON file on your machine and select **Upload**.

+1. After the file gets uploaded, select on the JSON file and navigate to the **Generate SAS** tab.

+ :::image type="content" source="./media/monitor-point-to-site-connections/generate-sas.png" alt-text="Screenshot shows the Generate SAS field for blob." lightbox="./media/monitor-point-to-site-connections/generate-sas.png":::

+1. Under **Signing method**, choose **Account key**.

+1. Under **Permissions**, give the key the following permissions: **Read, Add, Create, and Write**.

+1. Choose an **Expiry** date and time for the key.

+1. Select **Generate SAS token and URL**.

+1. Copy down the **Blob SAS token** and **Blob SAS URL** to a secure location.

+## Create Azure function app

+1. In the portal, in the **Search resources** bar, type **Function App**.

+1. Select **Function App** from the results. On the Function App page, select **+ Create** to open the **Create Function App** page.

+1. On the **Create WAN** page, on the **Basics** tab, fill in the fields. Modify the example values to apply to your environment.

+ :::image type="content" source="./media/monitor-point-to-site-connections/function-app-basics.png" alt-text="Screenshot shows the basics tab of function app.":::

+ * **Subscription**: Select the subscription that you want to use

+ * **Resource group**: Create new or use existing

+ * **Function App name**: Choose a name for Function App

+ * **Publish**: Select **Code**

+ * **Runtime stack**: Select **PowerShell Core**

+ * **Version**: Choose 7.0 (or your preferred version)

+ * **Region**: Choose your preferred region

+1. The remaining tabs are optional to change, so you can select **Review + create** and then select **Create** when validation passes.

+1. Go to the **Function App** resource.

+1. Select on **Identity** under **Settings** in the left panel. Toggle the **Status** button to **On** for **System assigned** and select **Save**.

+ :::image type="content" source="./media/monitor-point-to-site-connections/function-app-identity.png" alt-text="Screenshot shows the identity tab of function app.":::

+1. Select on **Configuration** under **Settings** in the left panel.

+1. Select on **+ New application setting**.

+

+1. Create the following 7 entries by inputting the **Name** and **Value**, then select **OK** after each value..

+ | Name | Value|

+ |||

+ |"resourcegroup" | your resource group |

+ | "sasuri"| your resource group|

+ | "storageaccountname"| `@Microsoft.KeyVault(SecretUri=https://\<keyvaultname>.vault.azure.net/secrets/sasuri/\<version>)`-->update accordingly after keyvault is created in next section. |

+ | "storagecontainer"| your storage container name|

+ |"subscription" |your subscription ID |

+ |"tenantname" | your tenant ID |

+ | "vpngw"|This name is something like \<guid>-eastus-ps2-gw. You can get this from the vWAN HUB User VPN settings. |

+1. Select **Save**.

+1. Select on **Functions** in the left panel and select **+ Create**.

+1. Fill in the fields.

+ :::image type="content" source="./media/monitor-point-to-site-connections/creating-function.png" alt-text="Screenshot shows the page when creating a function." lightbox="./media/monitor-point-to-site-connections/creating-function.png":::

+ * **Development Environment**: Develop in portal

+ * **Template**: Timer Trigger

+ * **New Function**: Choose a name for the Function

+ * **Schedule**: Enter a cron expression of the format '{second} {minute} {hour} {day} {month} {day of the week}' to specify the schedule

+1. Select **Code + Test** in the left panel, and type the following code in the **run.ps1** file. Select **Save**.

+ ```azurepowershell-interactive

+ # Input bindings are passed in via param block.

+ param($Timer)

+ # Get the current universal time in the default string format.

+ $currentUTCtime = (Get-Date).ToUniversalTime()

+ # The 'IsPastDue' property is "true" when the current function invocation is later than scheduled.

+ if($Timer.IsPastDue){

+ Write-Host "PowerShell timer is running late!"

+ }

+ ## Write an information log with current time.

+ Write-Host "PowerShell timer trigger function ran! TIME:$currentUTCtime"

+ $tenantname = $env:appsetting_tenantname

+ $subscription = $env:appsetting_subscription

+ $resourceGroup = $env:appsetting_resourcegroup

+ $storageAccountName = $env:appsetting_storageaccountname

+ $vpnstatsfile = $env:appsetting_vpnstatsfile

+ $vpngw = $env:appsetting_vpngw

+ $sasuri = $env:appsetting_sasuri

+ connect-azaccount -tenant $tenantname -identity -subscription $subscription

+ Get-AzP2sVpnGatewayDetailedConnectionHealth -name $vpngw -ResourceGroupName $resourceGroup -OutputBlobSasUrl

+ $sasuri

+ ```

+1. Navigate back to the **Function App** page and select on **App Service Editor** in the left panel under **Development Tools**. Then, select **Go -->**.

+1. Go to **requirements.psd1** and uncomment the line beginning with **'Az'...** as shown.

+ :::image type="content" source="./media/monitor-point-to-site-connections/requirements-file.png" alt-text="Screenshot showing the requirements file for function app." lightbox="./media/monitor-point-to-site-connections/requirements-file.png" :::

+1. For the **get-AzP2sVpnGatewayDetailedConnectionHealth** command to succeed, you need to have the right permissions to the information. Navigate to your resource group and choose "Access Control (IAM)" in the left panel. This corresponds to identity and access management. Assign the **FunctionApp** read access over the resource group.

+## Create Azure Key Vault

+1. In the portal, in the **Search resources** bar, type **Key vaults**.

+1. Select **+ Create** from the results to open the **Create a key vault** page.

+1. On the **Basics** tab, fill in the fields. Modify the example values to apply to your environment.

+ :::image type="content" source="./media/monitor-point-to-site-connections/key-vault-basics.png" alt-text="Screenshot shows the basics section of creating a key vault.":::

+ * **Subscription**: Select the subscription that you want to use.

+ * **Resource group**: Create new or use existing.

+ * **Storage account name**: Type the name you want to call your key vault.

+ * **Region**: Select a region for your storage account.

+ * **Pricing tier**: Standard or Premium. **Standard** is adequate for our monitoring purposes.

+1. Select **Next: Access policy >**.

+1. Under **Permission model**, choose **Vault access policy**.

+1. Leave the options under **Resource access** as disabled.

+1. Under **Access policies**, select **+ Create**.

+ :::image type="content" source="./media/monitor-point-to-site-connections/create-access-policy-screen-1.png" alt-text="Screenshot shows first screen in creating access policy." lightbox="./media/monitor-point-to-site-connections/create-access-policy-screen-1.png" :::

+1. Select **Next** to go to the **Principal** tab. Type the name of your function app and select it.

+1. Select **Next** twice to get to the fourth tab: **Review + create** and select **Create** at the bottom.

+1. You should now see the newly created access policy under the **Access policies** section. Modifying the default values under the **Networking** tab is optional, so select **Review + create** in the bottom left corner.

+1. Go to **Secrets** under **Objects** under the left panel of the key vault resource. Select **+ Generate/Import** and add secret as follows:

+ * **Name**: sasuri

+ * **value**: \<SASURI>

+ * **Enabled**: Yes

+1. Go back to the **Configuration** tab for the Function App and modify the following entry. The value comes from the **Secret Identifier** field that appears after clicking on the secret:

+ * **Name**: "sasuri"

+ * **Value**: `@Microsoft.KeyVault(SecretUri=https://\<keyvaultname>.vault.azure.net/secrets/sasuri/\<version>)`

+## Create Azure Workbook

+The Azure workbook is now ready to be created. We'll use a mix of built-in functionality and the added session details from our function app solution.

+1. Navigate to your Virtual WAN resource and select on **Insights** under **Monitor** in the left panel. Select on **Workbooks** and then select **+ New**.

+1. Add the following query into the workbook. Replace "SASURI" with your sas uri.

+ ```

+ let P2Svpnconnections = (externaldata (resource:string, UserNameVpnConnectionHealths: dynamic) [

+ @"SASURI"

+ ] with(format="multijson"));

+ P2Svpnconnections

+ | mv-expand UserNameVpnConnectionHealths

+ | extend Username = parse_json(UserNameVpnConnectionHealths).UserName

+ | extend VpnConnectionHealths = parse_json(parse_json(UserNameVpnConnectionHealths).VpnConnectionHealths)

+ | mv-expand VpnConnectionHealths

+ | extend VpnConnectionId = parse_json(VpnConnectionHealths).VpnConnectionId, VpnConnectionDuration = parse_json(VpnConnectionHealths).VpnConnectionDuration, VpnConnectionTime = parse_json(VpnConnectionHealths).VpnConnectionTime, PublicIpAddress = parse_json(VpnConnectionHealths).PublicIpAddress, PrivateIpAddress = parse_json(VpnConnectionHealths).PrivateIpAddress, MaxBandwidth = parse_json(VpnConnectionHealths).MaxBandwidth, EgressPacketsTransferred = parse_json(VpnConnectionHealths).EgressPacketsTransferred, EgressBytesTransferred = parse_json(VpnConnectionHealths).EgressBytesTransferred, IngressPacketsTransferred = parse_json(VpnConnectionHealths).IngressPacketsTransferred, IngressBytesTransferred = parse_json(VpnConnectionHealths).IngressBytesTransferred, MaxPacketsPerSecond = parse_json(VpnConnectionHealths).MaxPacketsPerSecond

+ | extend PubIp = tostring(split(PublicIpAddress, ":").[0])

+ | project Username, VpnConnectionId, VpnConnectionDuration, VpnConnectionTime, PubIp, PublicIpAddress, PrivateIpAddress, MaxBandwidth, EgressPacketsTransferred, EgressBytesTransferred, IngressPacketsTransferred, IngressBytesTransferred, MaxPacketsPerSecond;

+ ```

+1. To see the results, select the blue button **Run Query** to see the results.

+1. If yous see the following error, then navigate back to the file (vpnstatfile.json) in the storage container's blob, and regenerate the SAS URL. Then paste the updated SAS URL in the query.

+ :::image type="content" source="./media/monitor-point-to-site-connections/workbook-error.png" alt-text="Screenshot shows error when running query in workbook.":::

+1. Save the workbook to return to it later.

+1. For the following metrics, you must enable diagnostics logging by adding diagnostic settings in Azure portal. Fill in the required fields for subscription and resource group. For resource type, type in "microsoft.network/p2svpngateways". Add a diagnostic setting (or edit the current diagnostic setting) for the point-to-site gateway you wish to monitor.

+ :::image type="content" source="./media/monitor-point-to-site-connections/final-monitoring.png" alt-text="Screenshot shows first Diagnostic settings page in Azure Monitor." lightbox="./media/monitor-point-to-site-connections/final-monitoring.png" :::

+1. Enable allLogs and allMetrics, and choose to send to "Log Analytics workspace" as the destination. Some logs are noisy and might be costly (specifically IKEDiagnosticLog). As a result, feel free to enable only specific logs you want to view instead of enabling allLogs.

+ :::image type="content" source="./media/monitor-point-to-site-connections/diagnostic-setting.png" alt-text="Screenshot shows second Diagnostic settings page in Azure Monitor." lightbox="./media/monitor-point-to-site-connections/diagnostic-setting.png":::

+## Example queries

+The following section shows example queries.

+### P2S User successful connections with IP

+### EAP (Extensible Authentication Protocol) authentication succeeded

+### P2S VPN user info

+### P2S VPN successful connections per user

+### P2S VPN connections

+### Successful P2S VPN connections

+### Failed P2S VPN connections

+### VPN connection count by P2SDiagnosticLog

+### IKEDiagnosticLog

+### Additional IKE diagnostics details

+### P2S VPN statistics

+## Next steps

+To learn more about frequently asked questions, see the [Virtual WAN FAQ](virtual-wan-faq.md) page.