+- Global Administrators can create, delete, and view a Temporary Access Pass on any user (except themselves)

+- Privileged Authentication Administrators can create, delete, and view a Temporary Access Pass on admins and members (except themselves)

+- Authentication Administrators can create, delete, and view a Temporary Access Pass on members (except themselves)

+## September 2022

+### New articles

+- [Configure a user-assigned managed identity to trust an external identity provider (preview)](workload-identity-federation-create-trust-user-assigned-managed-identity.md)

+- [Important considerations and restrictions for federated identity credentials](workload-identity-federation-considerations.md)

+### Updated articles

+- [How to use Continuous Access Evaluation enabled APIs in your applications](app-resilience-continuous-access-evaluation.md)

+- [Run automated integration tests](test-automate-integration-testing.md)

+- [Tutorial: Sign in users and call the Microsoft Graph API from a JavaScript single-page application (SPA)](tutorial-v2-javascript-spa.md)

+| **Operating Systems** | Windows 10 or newer, iOS, Android, macOS, Ubuntu 20.04/22.04 |

+| | Linux - Intune Agent |

+When technology projects fail, they typically do because of mismatched expectations on impact, outcomes, and responsibilities. To avoid these pitfalls, [ensure that you're engaging the right stakeholders,](../fundamentals/active-directory-deployment-plans.md) and that stakeholder roles in the project are well understood.

+| Linux Desktop - Ubuntu 20.04/22.04 |  | | |

+* [Linux Desktop - Ubuntu 20.04/22.04](/mem/intune/user-help/enroll-device-linux)

+ deviceTrustType | AzureAD, ServerAD, Workplace | device.deviceTrustType -eq "AzureAD"

+>

+>The enhanced group writeback feature is enabled on the tenant and not per Azure AD Connect client instance. Please be sure that all Azure AD Connect client instances are updated to a minimal build version of 1.6.4.0 or later.

+The new version is enabled on the tenant and not per Azure AD Connect client instance. Make sure that all Azure AD Connect client instances are updated to a minimal build of [Azure AD Connect version 2.0 or later](https://www.microsoft.com/download/details.aspx?id=47594) if group writeback is currently enabled on the client instance.

+## September 2022

+### New articles

+- [Tutorial: Configure Datawiza to enable Azure Active Directory Multi-Factor Authentication and single sign-on to Oracle PeopleSoft](datawiza-azure-ad-sso-oracle-peoplesoft.md)

+- [SAML Request Signature Verification (Preview)](howto-enforce-signed-saml-authentication.md)

+### Updated articles

+- [Manage app consent policies](manage-app-consent-policies.md)

+- [Unexpected consent prompt when signing in to an application](application-sign-in-unexpected-user-consent-prompt.md)

+```kusto

+```bash

+To further help improve cluster resource utilization and free up CPU and memory for other pods, see [Vertical Pod Autoscaler][vertical-pod-autoscaler].

+[vertical-pod-autoscaler]: vertical-pod-autoscaler.md

+| neighborhood.host | DNS name used to resolve all instances of a self-hosted gateway deployment for cross-instance synchronization. In Kubernetes, this can be achieved by using a headless Service. | No | N/A |

+| neighborhood.heartbeat.port | UDP port used for instances of a self-hosted gateway deployment to send heartbeats to other instances. | No | 4291 |

+| policy.rate-limit.sync.port | UDP port used for self-hosted gateway instances to synchronize rate limiting across multiple instances. | No | 4290 |

+> **Http Server Errors** only records requests that reach the backend service (the worker(s) hosting the app). If the requests are failing at the FrontEnd, they are not recorded as Http Server Errors. The [Health Check feature](./monitor-instances-health-check.md) / Application Insights availability tests can be used for outside in monitoring.

+ TOKEN=$(kubectl get secret demo-user-secret -o jsonpath='{$.data.token}' | base64 -d | sed 's/$/\n/g')

+1. If prompted, sign-in to the SCM site with your Azure credentials.

+[Azure Monitor Agent (AMA)](./agents-overview.md) replaces the Log Analytics agent (also known as MMA and OMS) for both Windows and Linux machines, in both Azure and non-Azure (on-premises and 3rd party clouds) environments. It introduces a simplified, flexible method of configuring collection configuration called [Data Collection Rules (DCRs)](../essentials/data-collection-rule-overview.md). This article outlines the benefits of migrating to Azure Monitor Agent (AMA) and provides guidance on how to implement a successful migration.

+Review the [prerequisites](./azure-monitor-agent-manage.md#prerequisites) for use Azure Monitor Agent. For non-Azure servers, [installing the Azure Arc agent](/azure/azure-arc/servers/agent-overview) is an important prerequisite that then helps to install the agent extension and other required extensions. Using Arc for this purpose comes at no added cost, and it's not mandatory to use Arc for server management overall (i.e. you can continue using your existing non-Azure management solutions). Once Arc agent is installed, you can follow the same guidance below across Azure and non-Azure for migration.

+We recommend using [Azure Policy](../../governance/policy/overview.md) to migrate a large number of agents. Start by analyzing your current monitoring setup with the Log Analytics agent using the [AMA Migration Helper](./azure-monitor-agent-migration-tools.md#using-ama-migration-helper-preview) to find sources, such as virtual machines, virtual machine scale sets, and non-Azure servers.

+ |Aggregation granularity| Select the interval that is used to group the data points using the aggregation type function. Choose an **Aggregation granularity** (Period) that's greater than the **Frequency of evaluation** to reduce the likelihood of missing the first evaluation period of an added time series.|

+ |Frequency of evaluation|Select how often the alert rule is be run. Select a frequency that is smaller than the aggregation granularity to generate a sliding window for the evaluation.|

+To create an alert rule, you need to have:

+ - Read permission on any action group associated with the alert rule (if applicable)

+ - **Monitoring contributor**: can create alerts and use resources within their scope

+ - **Monitoring reader**: can view alerts and read resources within their scope

+If the target action group or rule location is in a different scope than the two built-in roles, you need to create a user with the appropriate permissions.

+Certain work item types can use templates that you define in ServiceNow. When you use templates, you can define fields that will be automatically populated by using constant values defined in ServiceNow (not values from the payload). The templates are synced with Azure. You can define which template you want to use as a part of the definition of an action group. For information about how to create templates, see the [ServiceNow documentation](https://docs.servicenow.com/en-US/bundle/tokyo-platform-administration/page/administer/form-administration/task/t_CreateATemplateUsingTheTmplForm.html).

+[Troubleshoot problems in ITSMC](./itsmc-resync-servicenow.md)

+When metric counts are presented in the portal, they're renormalized to take into account sampling. Doing so minimizes any effect on the statistics.

+## When to use sampling

+In general, for most small and medium size applications you don't need sampling. The most useful diagnostic information and most accurate statistics are obtained by collecting data on all your user activities.

+The main advantages of sampling are:

+* Application Insights service drops ("throttles") data points when your app sends a very high rate of telemetry in a short time interval. Sampling reduces the likelihood that your application will see throttling occur.

+* To keep within the [quota](../logs/daily-cap.md) of data points for your pricing tier.

+* To reduce network traffic from the collection of telemetry.

+## How sampling works

+The sampling algorithm decides which telemetry items to drop, and which ones to keep. This is true whether sampling is done by the SDK or in the Application Insights service. The sampling decision is based on several rules that aim to preserve all interrelated data points intact, maintaining a diagnostic experience in Application Insights that is actionable and reliable even with a reduced data set. For example, if your app has a failed request included in a sample, the additional telemetry items (such as exception and traces logged for this request) will be retained. Sampling either keeps or drops them all together. As a result, when you look at the request details in Application Insights, you can always see the request along with its associated telemetry items.

+The sampling decision is based on the operation ID of the request, which means that all telemetry items belonging to a particular operation is either preserved or dropped. For the telemetry items that do not have an operation ID set (such as telemetry items reported from asynchronous threads with no HTTP context) sampling simply captures a percentage of telemetry items of each type.

+When presenting telemetry back to you, the Application Insights service adjusts the metrics by the same sampling percentage that was used at the time of collection, to compensate for the missing data points. Hence, when looking at the telemetry in Application Insights, the users are seeing statistically correct approximations that are very close to the real numbers.

+The accuracy of the approximation largely depends on the configured sampling percentage. Also, the accuracy increases for applications that handle a large volume of generally similar requests from lots of users. On the other hand, for applications that don't work with a significant load, sampling is not needed as these applications can usually send all their telemetry while staying within the quota, without causing data loss from throttling.

+| Storage account | It is not recommended to use an existing storage account that has other, non-monitoring data stored in it so that you can better control access to the data. If you're archiving the activity log and resource logs together, you might choose to use the same storage account to keep all monitoring data in a central location.<br><br>To send the data to immutable storage, set the immutable policy for the storage account as described in [Set and manage immutability policies for Azure Blob Storage](../../storage/blobs/immutable-policy-configure-version-scope.md). You must follow all steps in this linked article including enabling protected append blobs writes.<br><br>The storage account needs to be in the same region as the resource being monitored if the resource is regional.<br><br> Diagnostic settings can't access storage accounts when virtual networks are enabled. You must enable **Allow trusted Microsoft services** to bypass this firewall setting in storage accounts so that the Azure Monitor diagnostic settings service is granted access to your storage account.|

+- [Azure NetApp Files with Azure VMware Solution](netapp-files-with-azure-vmware-solution.md) - You can use Azure NetApp Files to migrate and run the most demanding enterprise file-workloads in the cloud: databases, and general purpose computing applications, with no code changes. Azure NetApp Files volumes can be attached to virtual machines, and as [datastores](/azure/azure-vmware/attach-azure-netapp-files-to-azure-vmware-solution-hosts) to extend the vSAN datastore capacity without adding more nodes.

+ Title: Deploy vSAN stretched clusters (Preview)

+# Deploy vSAN stretched clusters (Preview)

+The following diagram depicts a vSAN cluster stretched across two AZs.

+ - Despite various layers of redundancy built into the fabric, if an inter-AZ failure results in the partitioning of the secondary site, vSphere HA starts powering off the workload VMs on the secondary site.

+

+ The following diagram shows the secondary site partitioning scenario.

+ - If the secondary site partitioning progressed into the failure of the primary site instead, or resulted in a complete partitioning, vSphere HA would attempt to restart the workload VMs on the secondary site. If vSphere HA attempted to restart the workload VMs on the secondary site, it would put the workload VMs in an unsteady state.

+

+ The following diagram shows the preferred site failure or complete partitioning scenario.

+It should be noted that these types of failures, although rare, fall outside the scope of the protection offered by a stretched cluster private cloud. Because of those types of rare failures, a stretched cluster solution should be regarded as a multi-AZ high availability solution reliant upon vSphere HA. It's important you understand that a stretched cluster solution isn't meant to replace a comprehensive multi-region Disaster Recovery strategy that can be employed to ensure application availability. The reason is because a Disaster Recovery solution typically has separate management and control planes in separate Azure regions. Azure VMware Solution stretched clusters have a single management and control plane stretched across two availability zones within the same Azure region. For example, one vCenter Server, one NSX-T Manager cluster, one NSX-T Data Center Edge VM pair.

+Currently, Azure VMware Solution stretched clusters is in the (preview) phase. While in the (preview) phase, you must contact Microsoft to request and qualify for support.

+### What kind of SLA does Azure VMware Solution provide with the stretched clusters (preview) release?

+- Preview and recent GA features for standard private cloud environments aren't supported in a stretched cluster environment.

+vSAN stretched clusters operate within a 5-milliseconds round trip time (RTT) and 10 Gb/s or greater bandwidth between the AZs that host the workload VMs. The Azure VMware Solution stretched cluster deployment follows that guiding principle. Consider that information when deploying applications (with SFTT of dual site mirroring, which uses synchronous writes) that have stringent latency requirements.

+No. While in (preview), customers won't see a charge for the witness node and the inter-AZ traffic. The witness node is entirely service managed, and Azure VMware Solution provides the required lifecycle management of the witness node. As the entire solution is service managed, the customer only needs to identify the appropriate SPBM policy to set for the workload virtual machines. The rest is managed by Microsoft.

+|UDP/SRTP|Media Processor|SBC|49152ΓÇô53247|Defined on the SBC|

+|UDP/SRTP|SBC|Media Processor|Defined on the SBC|49152ΓÇô53247|

+| **Maximum # of outgoing local streams that can be sent simultaneously** | 1 video and 1 screen sharing | 1 video + 1 screen sharing |

+Use the Sample Builder to customize the consumer experience. You can reach the Sampler Builder using this [link](https://aka.ms/acs-sample-builder) or navigating to the page within the Azure Communication Services resource in the Azure portal. Step through the Sample Builder wizard: select Industry template, configure the call experience (Chat or Screen Sharing availability), change themes and text to match your application style and get valuable feedback through post-call survey options. You can preview your configuration live from the page in both Desktop and Mobile browser form-factors.

+Enter the application url followed by "/visit" in the "Deployed App URL" field in https://outlook.office.com/bookings/businessinformation.

+An alias is used for simple substitution of a user-defined string instead of the subscription GUID. In other words, you can use it as a shortcut. You can learn more about alias at [Alias - Create](/rest/api/subscription/2021-10-01/alias/create). In the following examples, `sampleAlias` is created but you can use any string you like.

+PUT https://management.azure.com/providers/Microsoft.Subscription/aliases/sampleAlias?api-version=2021-10-01

+GET https://management.azure.com/providers/Microsoft.Subscription/aliases/sampleAlias?api-version=2021-10-01

+ "apiVersion": "2021-10-01",

+resource subscriptionAlias 'Microsoft.Subscription/aliases@2021-10-01' = {

+PUT https://management.azure.com/providers/Microsoft.Subscription/aliases/sampleAlias?api-version=2021-10-01

+GET https://management.azure.com/providers/Microsoft.Subscription/aliases/sampleAlias?api-version=2021-10-01

+ "apiVersion": "2021-10-01",

+resource subscriptionAlias 'Microsoft.Subscription/aliases@2021-10-01' = {

+PUT https://management.azure.com/providers/Microsoft.Subscription/aliases/sampleAlias?api-version=2021-10-01

+GET https://management.azure.com/providers/Microsoft.Subscription/aliases/sampleAlias?api-version=2021-10-01

+ "apiVersion": "2021-10-01",

+resource subscriptionAlias 'Microsoft.Subscription/aliases@2021-10-01' = {

+| Title | Description | Severity | Category |

+|--|--|--|--|

+| Beckhoff Software Changed | Firmware was updated on a source device. This may be authorized activity, for example a planned maintenance procedure. | Major | Firmware Change |

+| Database Login Failed | A failed sign-in attempt was detected from a source device to a destination server. This might be the result of human error, but could also indicate a malicious attempt to compromise the server or data on it. | Major | Authentication |

+| Emerson ROC Firmware Version Changed | Firmware was updated on a source device. This may be authorized activity, for example a planned maintenance procedure. | Major | Firmware Change |

+| External address within the network communicated with Internet | A source device defined as part of your network is communicating with Internet addresses. The source isn't authorized to communicate with Internet addresses. | Critical | Internet Access |

+| Field Device Discovered Unexpectedly | A new source device was detected on the network but hasn't been authorized. | Major | Discovery |

+| Firmware Change Detected | Firmware was updated on a source device. This may be authorized activity, for example a planned maintenance procedure. | Major | Firmware Change |

+| Firmware Version Changed | Firmware was updated on a source device. This may be authorized activity, for example a planned maintenance procedure. | Major | Firmware Change |

+| Foxboro I/A Unauthorized Operation | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| FTP Login Failed | A failed sign-in attempt was detected from a source device to a destination server. This alert might be the result of human error, but could also indicate a malicious attempt to compromise the server or data on it. | Major | Authentication |

+| Function Code Raised Unauthorized Exception | A source device (secondary) returned an exception to a destination device (primary). | Major | Command Failures |

+| GOOSE Message Type Settings | Message (identified by protocol ID) settings were changed on a source device. | Warning | Unauthorized Communication Behavior |

+| Honeywell Firmware Version Changed | Firmware was updated on a source device. This may be authorized activity, for example a planned maintenance procedure. | Major | Firmware Change |

+| * Illegal HTTP Communication | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Abnormal HTTP Communication Behavior |

+| Internet Access Detected | A source device defined as part of your network is communicating with Internet addresses. The source isn't authorized to communicate with Internet addresses. | Major | Internet Access |

+| Mitsubishi Firmware Version Changed | Firmware was updated on a source device. This may be authorized activity, for example a planned maintenance procedure. | Major | Firmware Change |

+| Modbus Address Range Violation | A primary device requested access to a new secondary memory address. | Major | Unauthorized Communication Behavior |

+| Modbus Firmware Version Changed | Firmware was updated on a source device. This may be authorized activity, for example a planned maintenance procedure. | Major | Firmware Change |

+| New Activity Detected - CIP Class | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - CIP Class Service | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - CIP PCCC Command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - CIP Symbol | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - EtherNet/IP I/O Connection | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - EtherNet/IP Protocol Command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - GSM Message Code | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - LonTalk Command Codes | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Port Discovery | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Warning | Discovery |

+| New Activity Detected - LonTalk Network Variable | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - Ovation Data Request | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - Read/Write Command (AMS Index Group) | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Configuration Changes |

+| New Activity Detected - Read/Write Command (AMS Index Offset) | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Configuration Changes |

+| New Activity Detected - Unauthorized DeltaV Message Type | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - Unauthorized DeltaV ROC Operation | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - Unauthorized RPC Message Type | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - Using AMS Protocol Command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - Using Siemens SICAM Command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - Using Suitelink Protocol command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - Using Suitelink Protocol sessions | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Activity Detected - Using Yokogawa VNetIP Command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| New Asset Detected | A new source device was detected on the network but hasn't been authorized. <br><br>This alert applies to devices discovered in OT subnets. New devices discovered in IT subnets don't trigger an alert.| Major | Discovery |

+| New LLDP Device Configuration | A new source device was detected on the network but hasn't been authorized. | Major | Configuration Changes |

+| Omron FINS Unauthorized Command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| S7 Plus PLC Firmware Changed | Firmware was updated on a source device. This may be authorized activity, for example a planned maintenance procedure. | Major | Firmware Change |

+| Sampled Values Message Type Settings | Message (identified by protocol ID) settings were changed on a source device. | Warning | Unauthorized Communication Behavior |

+| Suspicion of Illegal Integrity Scan | A scan was detected on a DNP3 source device (outstation). This scan wasn't authorized as learned traffic on your network. | Major | Scan |

+| Toshiba Computer Link Unauthorized Command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Minor | Unauthorized Communication Behavior |

+| Unauthorized ABB Totalflow File Operation | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized ABB Totalflow Register Operation | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized Access to Siemens S7 Data Block | A source device attempted to access a resource on another device. An access attempt to this resource between these two devices hasn't been authorized as learned traffic on your network. | Warning | Unauthorized Communication Behavior |

+| Unauthorized Access to Siemens S7 Plus Object | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized Access to Wonderware Tag | A source device attempted to access a resource on another device. An access attempt to this resource between these two devices hasn't been authorized as learned traffic on your network. | Major | Unauthorized Communication Behavior |

+| Unauthorized BACNet Object Access | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized BACNet Route | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized Database Login | A sign-in attempt between a source client and destination server was detected. Communication between these devices hasn't been authorized as learned traffic on your network. | Major | Authentication |

+| Unauthorized Database Operation | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Abnormal Communication Behavior |

+| Unauthorized Emerson ROC Operation | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized GE SRTP File Access | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized GE SRTP Protocol Command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized GE SRTP System Memory Operation | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized HTTP Activity | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Abnormal HTTP Communication Behavior |

+| * Unauthorized HTTP SOAP Action | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Abnormal HTTP Communication Behavior |

+| * Unauthorized HTTP User Agent | An unauthorized application was detected on a source device. The application hasn't been authorized as a learned application on your network. | Major | Abnormal HTTP Communication Behavior |

+| Unauthorized Internet Connectivity Detected | A source device defined as part of your network is communicating with Internet addresses. The source isn't authorized to communicate with Internet addresses. | Critical | Internet Access |

+| Unauthorized Mitsubishi MELSEC Command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized MMS Program Access | A source device attempted to access a resource on another device. An access attempt to this resource between these two devices hasn't been authorized as learned traffic on your network. | Major | Programming |

+| Unauthorized MMS Service | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized Multicast/Broadcast Connection | A Multicast/Broadcast connection was detected between a source device and other devices. Multicast/Broadcast communication isn't authorized. | Critical | Abnormal Communication Behavior |

+| Unauthorized Name Query | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Abnormal Communication Behavior |

+| Unauthorized OPC UA Activity | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized OPC UA Request/Response | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized Operation was detected by a User Defined Rule | Traffic was detected between two devices. This activity is unauthorized based on a Custom Alert Rule defined by a user. | Major | Custom Alerts |

+| Unauthorized PLC Configuration Read | The source device isn't defined as a programming device but performed a read/write operation on a destination controller. Programming changes should only be performed by programming devices. A programming application may have been installed on this device. | Warning | Configuration Changes |

+| Unauthorized PLC Configuration Write | The source device sent a command to read/write the program of a destination controller. This activity wasn't previously seen. | Major | Configuration Changes |

+| Unauthorized PLC Program Upload | The source device sent a command to read/write the program of a destination controller. This activity wasn't previously seen. | Major | Programming |

+| Unauthorized PLC Programming | The source device isn't defined as a programming device but performed a read/write operation on a destination controller. Programming changes should only be performed by programming devices. A programming application may have been installed on this device. | Critical | Programming |

+| Unauthorized Profinet Frame Type | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized SAIA S-Bus Command | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized Siemens S7 Execution of Control Function | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized Siemens S7 Execution of User Defined Function | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized Siemens S7 Plus Block Access | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized Siemens S7 Plus Operation | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unauthorized SMB Login | A sign-in attempt between a source client and destination server was detected. Communication between these devices hasn't been authorized as learned traffic on your network. | Major | Authentication |

+| Unauthorized SNMP Operation | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Abnormal Communication Behavior |

+| Unauthorized SSH Access | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Remote Access |

+| Unauthorized Windows Process | An unauthorized application was detected on a source device. The application hasn't been authorized as a learned application on your network. | Major | Abnormal Communication Behavior |

+| Unauthorized Windows Service | An unauthorized application was detected on a source device. The application hasn't been authorized as a learned application on your network. | Major | Abnormal Communication Behavior |

+| Unpermitted Modbus Schneider Electric Extension | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unpermitted Usage of ASDU Types | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unpermitted Usage of DNP3 Function Code | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Unpermitted Usage of Internal Indication (IIN) | A DNP3 source device (outstation) reported an internal indication (IIN) that hasn't authorized as learned traffic on your network. | Major | Illegal Commands |

+| Unpermitted Usage of Modbus Function Code | New traffic parameters were detected. This parameter combination hasn't been authorized as learned traffic on your network. The following combination is unauthorized. | Major | Unauthorized Communication Behavior |

+| Title | Description | Severity | Category |

+|--|--|--|--|

+| Abnormal Exception Pattern in Slave | An excessive number of errors were detected on a source device. This alert may be the result of an operational issue. | Minor | Abnormal Communication Behavior |

+| * Abnormal HTTP Header Length | The source device sent an abnormal message. This alert may indicate an attempt to attack the destination device. | Critical | Abnormal HTTP Communication Behavior |

+| * Abnormal Number of Parameters in HTTP Header | The source device sent an abnormal message. This alert may indicate an attempt to attack the destination device. | Critical | Abnormal HTTP Communication Behavior |

+| Abnormal Periodic Behavior In Communication Channel | A change in the frequency of communication between the source and destination devices was detected. | Minor | Abnormal Communication Behavior |

+| Abnormal Termination of Applications | An excessive number of stop commands were detected on a source device. This alert may be the result of an operational issue or an attempt to manipulate the device. | Major | Abnormal Communication Behavior |

+| Abnormal Traffic Bandwidth | Abnormal bandwidth was detected on a channel. Bandwidth appears to be lower/higher than previously detected. For details, work with the Total Bandwidth widget. | Warning | Bandwidth Anomalies |

+| Abnormal Traffic Bandwidth Between Devices | Abnormal bandwidth was detected on a channel. Bandwidth appears to be lower/higher than previously detected. For details, work with the Total Bandwidth widget. | Warning | Bandwidth Anomalies |

+| Address Scan Detected | A source device was detected scanning network devices. This device hasn't been authorized as a network scanning device. | Critical | Scan |

+| ARP Address Scan Detected | A source device was detected scanning network devices using Address Resolution Protocol (ARP). This device address hasn't been authorized as valid ARP scanning address. | Critical | Scan |

+| ARP Spoofing | An abnormal quantity of packets was detected in the network. This alert could indicate an attack, for example, an ARP spoofing or ICMP flooding attack. | Warning | Abnormal Communication Behavior |

+| Excessive Login Attempts | A source device was seen performing excessive sign-in attempts to a destination server. This alert may indicate a brute force attack. The server may be compromised by a malicious actor. | Critical | Authentication |

+| Excessive Number of Sessions | A source device was seen performing excessive sign-in attempts to a destination server. This may indicate a brute force attack. The server may be compromised by a malicious actor. | Critical | Abnormal Communication Behavior |

+| Excessive Restart Rate of an Outstation | An excessive number of restart commands were detected on a source device. These alerts may be the result of an operational issue or an attempt to manipulate the device. | Major | Restart/ Stop Commands |

+| Excessive SMB login attempts | A source device was seen performing excessive sign-in attempts to a destination server. This may indicate a brute force attack. The server may be compromised by a malicious actor. | Critical | Authentication |

+| ICMP Flooding | An abnormal quantity of packets was detected in the network. This alert could indicate an attack, for example, an ARP spoofing or ICMP flooding attack. | Warning | Abnormal Communication Behavior |

+|* Illegal HTTP Header Content | The source device initiated an invalid request. | Critical | Abnormal HTTP Communication Behavior |

+| Inactive Communication Channel | A communication channel between two devices was inactive during a period in which activity is usually observed. This might indicate that the program generating this traffic was changed, or the program might be unavailable. It's recommended to review the configuration of installed program and verify that it's configured properly. | Warning | Unresponsive |

+| Long Duration Address Scan Detected | A source device was detected scanning network devices. This device hasn't been authorized as a network scanning device. | Critical | Scan |

+| Password Guessing Attempt Detected | A source device was seen performing excessive sign-in attempts to a destination server. This may indicate a brute force attack. The server may be compromised by a malicious actor. | Critical | Authentication |

+| PLC Scan Detected | A source device was detected scanning network devices. This device hasn't been authorized as a network scanning device. | Critical | Scan |

+| Port Scan Detected | A source device was detected scanning network devices. This device hasn't been authorized as a network scanning device. | Critical | Scan |

+| Unexpected message length | The source device sent an abnormal message. This alert may indicate an attempt to attack the destination device. | Critical | Abnormal Communication Behavior |

+| Unexpected Traffic for Standard Port | Traffic was detected on a device using a port reserved for another protocol. | Major | Abnormal Communication Behavior |

+| Title | Description | Severity | Category |

+|--|--|--|--|

+| Excessive Malformed Packets In a Single Session | An abnormal number of malformed packets sent from the source device to the destination device. This alert might indicate erroneous communications, or an attempt to manipulate the targeted device. | Major | Illegal Commands |

+| Firmware Update | A source device sent a command to update firmware on a destination device. Verify that recent programming, configuration and firmware upgrades made to the destination device are valid. | Warning | Firmware Change |

+| Function Code Not Supported by Outstation | The destination device received an invalid request. | Major | Illegal Commands |

+| Illegal BACNet message | The source device initiated an invalid request. | Major | Illegal Commands |

+| Illegal Connection Attempt on Port 0 | A source device attempted to connect to destination device on port number zero (0). For TCP, port 0 is reserved and canΓÇÖt be used. For UDP, the port is optional and a value of 0 means no port. There's usually no service on a system that listens on port 0. This event may indicate an attempt to attack the destination device, or indicate that an application was programmed incorrectly. | Minor | Illegal Commands |

+| Illegal DNP3 Operation | The source device initiated an invalid request. | Major | Illegal Commands |

+| Illegal MODBUS Operation (Exception Raised by Master) | The source device initiated an invalid request. | Major | Illegal Commands |

+| Illegal MODBUS Operation (Function Code Zero) | The source device initiated an invalid request. | Major | Illegal Commands |

+| Illegal Protocol Version | The source device initiated an invalid request. | Major | Illegal Commands |

+| Incorrect Parameter Sent to Outstation | The destination device received an invalid request. | Major | Illegal Commands |

+| Initiation of an Obsolete Function Code (Initialize Data) | The source device initiated an invalid request. | Minor | Illegal Commands |

+| Initiation of an Obsolete Function Code (Save Config) | The source device initiated an invalid request. | Minor | Illegal Commands |

+| Master Requested an Application Layer Confirmation | The source device initiated an invalid request. | Warning | Illegal Commands |

+| Modbus Exception | A source device (secondary) returned an exception to a destination device (primary). | Major | Illegal Commands |

+| Slave Device Received Illegal ASDU Type | The destination device received an invalid request. | Major | Illegal Commands |

+| Slave Device Received Illegal Command Cause of Transmission | The destination device received an invalid request. | Major | Illegal Commands |

+| Slave Device Received Illegal Common Address | The destination device received an invalid request. | Major | Illegal Commands |

+| Slave Device Received Illegal Data Address Parameter | The destination device received an invalid request. | Major | Illegal Commands |

+| Slave Device Received Illegal Data Value Parameter | The destination device received an invalid request. | Major | Illegal Commands |

+| Slave Device Received Illegal Function Code | The destination device received an invalid request. | Major | Illegal Commands |

+| Slave Device Received Illegal Information Object Address | The destination device received an invalid request. | Major | Illegal Commands |

+| Unknown Object Sent to Outstation | The destination device received an invalid request. | Major | Illegal Commands |

+| Usage of a Reserved Function Code | The source device initiated an invalid request. | Major | Illegal Commands |

+| Usage of Improper Formatting by Outstation | The source device initiated an invalid request. | Warning | Illegal Commands |

+| Usage of Reserved Status Flags (IIN) | A DNP3 source device (outstation) used the reserved Internal Indicator 2.6. It's recommended to check the device's configuration. | Warning | Illegal Commands |

+| Title | Description| Severity | Category |

+|--|--|--|--|

+| Connection Attempt to Known Malicious IP | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Major | Suspicion of Malicious Activity |

+| Invalid SMB Message (DoublePulsar Backdoor Implant) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Malicious Domain Name Request | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Major | Suspicion of Malicious Activity |

+| Malware Test File Detected - EICAR AV Success | An EICAR AV test file was detected in traffic between two devices (over any transport - TCP or UDP). The file isn't malware. It's used to confirm that the antivirus software is installed correctly. Demonstrate what happens when a virus is found, and check internal procedures and reactions when a virus is found. Antivirus software should detect EICAR as if it were a real virus. | Major | Suspicion of Malicious Activity |

+| Suspicion of Conficker Malware | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Major | Suspicion of Malware |

+| Suspicion of Denial Of Service Attack | A source device attempted to initiate an excessive number of new connections to a destination device. This may indicate a Denial Of Service (DOS) attack against the destination device, and might interrupt device functionality, affect performance and service availability, or cause unrecoverable errors. | Critical | Suspicion of Malicious Activity |

+| Suspicion of Malicious Activity | Suspicious network activity was detected. This activity may be associated with an attack that triggered known 'Indicators of Compromise' (IOCs). Alert metadata should be reviewed by the security team. | Major | Suspicion of Malicious Activity |

+| Suspicion of Malicious Activity (BlackEnergy) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Malicious Activity (DarkComet) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Malicious Activity (Duqu) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Malicious Activity (Flame) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Malicious Activity (Havex) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Malicious Activity (Karagany) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Malicious Activity (LightsOut) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Malicious Activity (Name Queries) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Major | Suspicion of Malicious Activity |

+| Suspicion of Malicious Activity (Poison Ivy) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Malicious Activity (Regin) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Malicious Activity (Stuxnet) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Malicious Activity (WannaCry) | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Major | Suspicion of Malware |

+| Suspicion of NotPetya Malware - Illegal SMB Parameters Detected | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of NotPetya Malware - Illegal SMB Transaction Detected | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malware |

+| Suspicion of Remote Code Execution with PsExec | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Major | Suspicion of Malicious Activity |

+| Suspicion of Remote Windows Service Management | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Major | Suspicion of Malicious Activity |

+| Suspicious Executable File Detected on Endpoint | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Major | Suspicion of Malicious Activity |

+| Suspicious Traffic Detected | Suspicious network activity was detected. This activity may be associated with an attack that triggered known 'Indicators of Compromise' (IOCs). Alert metadata should be reviewed by the security team | Critical | Suspicion of Malicious Activity |

+| Backup Activity with Antivirus Signatures | Traffic detected between the source device and the destination backup server triggered this alert. The traffic includes backup of antivirus software that might contain malware signatures. This is most likely legitimate backup activity. | Warning | Backup

+| Title | Description | Severity | Category |

+|--|--|--|--|

+| An S7 Stop PLC Command was Sent | The source device sent a stop command to a destination controller. The controller will stop operating until a start command is sent. | Warning | Restart/ Stop Commands |

+| BACNet Operation Failed | A server returned an error code. This alert indicates a server error or an invalid request by a client. | Major | Command Failures |

+| Bad MMS Device State | An MMS Virtual Manufacturing Device (VMD) sent a status message. The message indicates that the server may not be configured correctly, partially operational, or not operational at all. | Major | Operational Issues |

+| Change of Device Configuration | A configuration change was detected on a source device. | Minor | Configuration Changes |

+| Continuous Event Buffer Overflow at Outstation | A buffer overflow event was detected on a source device. The event may cause data corruption, program crashes, or execution of malicious code. | Major | Buffer Overflow |

+| Controller Reset | A source device sent a reset command to a destination controller. The controller stopped operating temporarily and started again automatically. | Warning | Restart/ Stop Commands |

+| Controller Stop | The source device sent a stop command to a destination controller. The controller will stop operating until a start command is sent. | Warning | Restart/ Stop Commands |

+| Device Failed to Receive a Dynamic IP Address | The source device is configured to receive a dynamic IP address from a DHCP server but didn't receive an address. This indicates a configuration error on the device, or an operational error in the DHCP server. It's recommended to notify the network administrator of the incident | Major | Command Failures |

+| Device is Suspected to be Disconnected (Unresponsive) | A source device didn't respond to a command sent to it. It may have been disconnected when the command was sent. | Major | Unresponsive |

+| EtherNet/IP CIP Service Request Failed | A server returned an error code. This indicates a server error or an invalid request by a client. | Major | Command Failures |

+| EtherNet/IP Encapsulation Protocol Command Failed | A server returned an error code. This indicates a server error or an invalid request by a client. | Major | Command Failures |

+| Event Buffer Overflow in Outstation | A buffer overflow event was detected on a source device. The event may cause data corruption, program crashes, or execution of malicious code. | Major | Buffer Overflow |

+| Expected Backup Operation Did Not Occur | Expected backup/file transfer activity didn't occur between two devices. This alert may indicate errors in the backup / file transfer process. | Major | Backup |

+| GE SRTP Command Failure | A server returned an error code. This alert indicates a server error or an invalid request by a client. | Major | Command Failures |

+| GE SRTP Stop PLC Command was Sent | The source device sent a stop command to a destination controller. The controller will stop operating until a start command is sent. | Warning | Restart/ Stop Commands |

+| GOOSE Control Block Requires Further Configuration | A source device sent a GOOSE message indicating that the device needs commissioning. This means that the GOOSE control block requires further configuration and GOOSE messages are partially or completely non-operational. | Major | Configuration Changes |

+| GOOSE Dataset Configuration was Changed | A message (identified by protocol ID) dataset was changed on a source device. This means the device will report a different dataset for this message. | Warning | Configuration Changes |

+| Honeywell Controller Unexpected Status | A Honeywell Controller sent an unexpected diagnostic message indicating a status change. | Warning | Operational Issues |

+|* HTTP Client Error | The source device initiated an invalid request. | Warning | Abnormal HTTP Communication Behavior |

+| Illegal IP Address | System detected traffic between a source device and an IP address that is an invalid address. This may indicate wrong configuration or an attempt to generate illegal traffic. | Minor | Abnormal Communication Behavior |

+| Master-Slave Authentication Error | The authentication process between a DNP3 source device (primary) and a destination device (outstation) failed. | Minor | Authentication |

+| MMS Service Request Failed | A server returned an error code. This indicates a server error or an invalid request by a client. | Major | Command Failures |

+| No Traffic Detected on Sensor Interface | A sensor stopped detecting network traffic on a network interface. | Critical | Sensor Traffic |

+| OPC UA Server Raised an Event That Requires User's Attention | An OPC UA server sent an event notification to a client. This type of event requires user attention | Major | Operational Issues |

+| OPC UA Service Request Failed | A server returned an error code. This indicates a server error or an invalid request by a client. | Major | Command Failures |

+| Outstation Restarted | A cold restart was detected on a source device. This means the device was physically turned off and back on again. | Warning | Restart/ Stop Commands |

+| Outstation Restarts Frequently | An excessive number of cold restarts were detected on a source device. This means the device was physically turned off and back on again an excessive number of times. | Minor | Restart/ Stop Commands |

+| Outstation's Configuration Changed | A configuration change was detected on a source device. | Major | Configuration Changes |

+| Outstation's Corrupted Configuration Detected | This DNP3 source device (outstation) reported a corrupted configuration. | Major | Configuration Changes |

+| Profinet DCP Command Failed | A server returned an error code. This indicates a server error or an invalid request by a client. | Major | Command Failures |

+| Profinet Device Factory Reset | A source device sent a factory reset command to a Profinet destination device. The reset command clears Profinet device configurations and stops its operation. | Warning | Restart/ Stop Commands |

+| * RPC Operation Failed | A server returned an error code. This alert indicates a server error or an invalid request by a client. | Major | Command Failures |

+| Sampled Values Message Dataset Configuration was Changed | A message (identified by protocol ID) dataset was changed on a source device. This means the device will report a different dataset for this message. | Warning | Configuration Changes |

+| Slave Device Unrecoverable Failure | An unrecoverable condition error was detected on a source device. This kind of error usually indicates a hardware failure or failure to perform a specific command. | Major | Command Failures |

+| Suspicion of Hardware Problems in Outstation | An unrecoverable condition error was detected on a source device. This kind of error usually indicates a hardware failure or failure to perform a specific command. | Major | Operational Issues |

+| Suspicion of Unresponsive MODBUS Device | A source device didn't respond to a command sent to it. It may have been disconnected when the command was sent. | Minor | Unresponsive |

+| Traffic Detected on Sensor Interface | A sensor resumed detecting network traffic on a network interface. | Warning | Sensor Traffic |

+This article describes the **HPE ProLiant DL360** appliance for OT sensors, customized for use with Microsoft Defender for IoT.

+The following image describes the hardware elements on the HPE ProLiant DL360 back panel that are used by Defender for IoT:

+- Scale in

+### Scale in

+Azure Firewall scales in/out based on throughput and CPU usage. Scale in is performed by putting the VM instance in drain mode for 90 seconds before recycling the VM instance. Any long running connections remaining on the VM instance after 90 seconds will be disconnected.

+ Title: Deploy the MedTech service with a QuickStart template - Azure Health Data Services

+description: In this article, you'll learn how to deploy the MedTech service in the Azure portal using a QuickStart template.

+# Deploy the MedTech service with an Azure Resource Manager QuickStart template

+In this article, you'll learn how to deploy the MedTech service in the Azure portal using an Azure Resource Manager (ARM) Quickstart template. This template will be used with the **Deploy to Azure** button to make it easy to provide the information you need to automatically set up the infrastructure and configuration of your deployment. For more information about Azure ARM templates, see [What are ARM templates?](../../azure-resource-manager/templates/overview.md).

+If you need to see a diagram with information on the MedTech service deployment, there is an architecture overview at [Choose a deployment method](deploy-iot-connector-in-azure.md#deployment-architecture-overview). This diagram shows the data flow steps of deployment and how MedTech service processes data into a Fast Healthcare Interoperability Resource (FHIR) Observation.

+There are four simple tasks you need to complete in order to deploy MedTech service with the ARM template **Deploy to Azure** button. They are:

+## Prerequisites

+In order to begin deployment, you need to have the following prerequisites:

+- An active Azure subscription account. If you don't have an Azure subscription, see [Subscription decision guide](/azure/cloud-adoption-framework/decision-guides/subscriptions/).

+- Two resource providers registered with your Azure subscription: **Microsoft.HealthcareApis** and **Microsoft.EventHub**. To learn more about registering resource providers, see [Azure resource providers and types](../../azure-resource-manager/management/resource-providers-and-types.md).

+When you've fulfilled these two prerequisites, you are ready to begin the second task.

+## Deploy to Azure button

+Next, you need to select the ARM template **Deploy to Azure** button here:

+ [](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-quickstart-templates%2Fmaster%2Fquickstarts%2Fmicrosoft.healthcareapis%2Fworkspaces%2Fiotconnectors%2Fazuredeploy.json).

+This button will call a template from the Azure ARM QuickStart template library to get information from your Azure subscription environment and begin deploying the MedTech service.

+After you select the **Deploy to Azure** button, it may take a few minutes to implement the following resources and roles:

+- An Azure Event Hubs Namespace and device message Azure event hub. In this example, the event hub is named **devicedata**.

+- An Azure event hub consumer group. In this example, the consumer group is named **$Default**.

+- An Azure event hub sender role. In this example, the sender role is named **devicedatasender**.

+- An Azure Health Data Services workspace.

+- An Azure Health Data Services FHIR service.

+- An Azure Health Data Services MedTech service instance, including the necessary [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) roles to the device message event hub (named **Azure Events Hubs Receiver**) and FHIR service (named **FHIR Data Writer**).

+After these resources and roles have completed their implementation, the Azure portal will be launched.

+## Provide configuration details

+When the Azure portal screen appears, your next task is to fill out five fields that provide specific details of your deployment configuration.

+### Use these values to fill out the five fields

+- **Subscription** - Choose the Azure subscription you want to use for the deployment.

+- **Resource Group** - Choose an existing Resource Group or create a new Resource Group.

+- **Region** - The Azure region of the Resource Group used for the deployment. This field will auto-fill, based on the Resource Group region.

+- **Basename** - This value will be appended to the name of the Azure resources and services to be deployed.

+- **Location** - Use the drop-down list to select a supported Azure region for the Azure Health Data Services (the value could be the same or different region than your Resource Group).

+### When completed, do the following

+Don't change the **Device Mapping** and **Destination Mapping** default values at this time.

+Select the **Review + create** button after all the fields are filled out. This will review your input and check to see if all your values are valid.

+When the validation is successful, select the **Create** button to begin the deployment. After a brief wait, a message will appear telling you that your deployment is complete.

+## Required post-deployment tasks

+Now that the MedTech service is successfully deployed, there are three post-deployment tasks that need to be completed before MedTech is fully functional and ready for use:

+1. First, you must provide a working device mapping. For more information, see [How to use device mappings](how-to-use-device-mappings.md).

+2. Second, you need to ensure that you have a working FHIR destination mapping. For more information, see [How to use FHIR destination mappings](how-to-use-fhir-mappings.md).

+3. Third, you must use a Shared access policies (SAS) key (named **devicedatasender**) to connect your device or application to the MedTech service device message event hub (named **devicedata**). For more information, see [Connection string for a specific event hub in a namespace](../../event-hubs/event-hubs-get-connection-string.md#connection-string-for-a-specific-event-hub-in-a-namespace).

+> [!IMPORTANT]

+>

+> If you're going to allow access from multiple services to the device message event hub, it is highly recommended that each service has its own event hub consumer group. Consumer groups enable multiple consuming applications to each have a separate view of the event stream, and to read the stream independently at their own pace and with their own offsets. For more information, see [Consumer groups](../../event-hubs/event-hubs-features.md#consumer-groups).

+>

+> **Examples:**

+>

+> - Two MedTech services accessing the same device message event hub.

+> - A MedTech service and a storage writer application accessing the same device message event hub.

+## Next steps

+In this article, you learned how to deploy the MedTech service in the Azure portal using a Quickstart ARM template with a **Deploy to Azure** button. To learn more about other methods of deployment, see

+>[!div class="nextstepaction"]

+>[Choosing a method of deployment for MedTech service in Azure](deploy-iot-connector-in-azure.md)

+>[!div class="nextstepaction"]

+>[How to manually deploy MedTech service with Azure portal](deploy-03-new-manual.md)

+>[!div class="nextstepaction"]

+>[How to deploy MedTech service using an ARM template and Azure PowerShell or Azure CLI](deploy-08-new-ps-cli.md)

+FHIR&#174; is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.

+ Title: Overview of manually deploying the MedTech service using the Azure portal - Azure Health Data Services

+description: In this article, you'll see an overview of how to manually deploy the MedTech service in the Azure portal.

+# How to manually deploy MedTech service using the Azure portal

+You may prefer to manually deploy MedTech service if you need to track every step of the developmental process. This might be necessary if you have to customize or troubleshoot your deployment. Manual deployment will help you by providing all the details for implementing each task.

+The explanation of MedTech service manual deployment using the Azure portal is divided into three parts that cover each of key tasks required:

+- Prerequisites (see Prerequisites below)

+- Configuration (see [Configure for manual deployment](./deploy-05-new-config.md))

+- Deployment and Post Deployment (see [Manual deployment and post-deployment](./deploy-06-new-deploy.md))

+If you need a diagram with information on the MedTech service deployment, there is an architecture overview at [Choose a deployment method](deploy-iot-connector-in-azure.md#deployment-architecture-overview). This diagram shows the data flow steps of deployment and how MedTech service processes data into a Fast Healthcare Interoperability Resource (FHIR) Observation.

+## Prerequisites

+Before you can begin configuring to deploy MedTech services, you need to have the following five prerequisites:

+- A valid Azure subscription

+- A resource group deployed in the Azure portal

+- A workspace deployed in Azure Health Data Services

+- An event hub deployed in a namespace

+- FHIR service deployed in Azure Health Data Services

+## Open your Azure account

+The first thing you need to do is determine if you have a valid Azure subscription. If you don't have an Azure subscription, see [Subscription decision guide](/azure/cloud-adoption-framework/decision-guides/subscriptions/).

+## Deploy a resource group in the Azure portal

+When you log in to your Azure account, go to Azure portal and select the Create a resource button. Then enter "Azure Health Data Services" in the "Search services and marketplace" box. This should take you to the Azure Health Data Services page.

+## Deploy a workspace in Azure Health Data Services

+The first resource you must create is a workspace to contain your Azure Health Data Services resources. Start by selecting Create from the Azure Health Data Services resource page. This will take you to the first page of Create Azure Health Data Services workspace, when you need to do the following 8 steps:

+1. Fill in the resource group you want to use or create a new one.

+2. Give the workspace a unique name.

+3. Select the region you want to use.

+4. Select the Networking button at the bottom to continue.

+5. Choose whether you want a public or private endpoint.

+6. Create tags if you want to use them. They are optional.

+7. When you are ready to continue, select the Review + create tab.

+8. Select the Create button to deploy your workspace.

+After a short delay, you will start to see information about your new workspace. Make sure you wait until all parts of the screen are displayed. If your initial deployment was successful, you should see:

+- "Your deployment is complete"

+- Deployment name

+- Subscription name

+- Resource group name

+## Deploy an event hub in the Azure portal using a namespace

+An event hub is the next prerequisite you need to create. It is important because it receives the data flow from a medical device and stores it there until MedTech can pick up the data and translate it into a FHIR service Observation resource. Because Internet propagation times are indeterminate, the event hub is needed to buffer the data and store it for as much as 24 hours before expiring.

+Before you can create an event hub, you must create a namespace in Azure portal to contain it. For more information on how To create a namespace and an event hub, see [Azure Event Hubs namespace and event hub deployed in the Azure portal](../../event-hubs/event-hubs-create.md).

+## Deploy the FHIR service

+The last prerequisite you need to do before you can configure and deploy MedTech service, is to deploy the FHIR service.

+There are three ways to deploy FHIR service:

+1. Using portal. See [Deploy a FHIR service within Azure Health Data Services - using portal](../fhir/fhir-portal-quickstart.md).

+2. Using Bicep. See [Deploy a FHIR service within Azure Health Data Services using Bicep](../fhir/fhir-service-bicep.md).

+3. Using an ARM template. See [Deploy a FHIR service within Azure Health Data Services - using ARM template](../fhir/fhir-service-resource-manager-template.md).

+After you have deployed FHIR service, it will be ready to receive the data processed by MedTech and persist it as a FHIR service Observation.

+## Next steps

+In this article, you learned about the prerequisites needed to deploy the MedTech service manually. When you have completed all the prerequisite requirements and your FHIR service is deployed, you are ready for the next step of manual deployment, see

+>[!div class="nextstepaction"]

+>[Configure the MedTech service for manual deployment using the Azure portal](deploy-05-new-config.md)

+FHIR&#174; is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.

+ Title: Prerequisites for deploying the MedTech service manually using the Azure portal - Azure Health Data Services

+description: In this article, you'll learn the prerequisites for manually deploying the MedTech service in the Azure portal.

+# Prerequisites for manually deploying the MedTech service using the Azure portal

+Before you can configure or deploy MedTech services, you need to have the following five prerequisites:

+- A valid Azure subscription

+- A resource group deployed in the Azure portal

+- A workspace deployed in Azure Health Data Services

+- An event hub deployed in a namespace

+- FHIR service deployed in Azure Health Data Services

+## Open your Azure account

+The first thing you need to do is determine if you have a valid Azure subscription. If you don't have an Azure subscription, see [Subscription decision guide](/azure/cloud-adoption-framework/decision-guides/subscriptions/).

+## Deploy a resource group in the Azure portal

+When you log in to your Azure account, go to Azure portal and select the Create a resource button. Then enter "Azure Health Data Services" in the "Search services and marketplace" box. You should take you to the Azure Health Data Services blade.

+## Deploy a workspace in Azure Health Data Services

+The first resource you must create is a workspace to contain your Azure Health Data Services resources.

+Start by selecting Create from the Azure Health Data Services resource page. This will take you to the first page of Create Azure Health Data Services workspace, when you need to do the following 8 steps:

+1. Fill in the resource group you want to use or create a new one.

+2. Give the workspace a unique name.

+3. Select the region you want to use.

+4. Select the Networking button at the bottom to continue.

+5. Choose whether you want a public or private endpoint.

+6. Create tags if you want to use them.

+7. When you are ready to move forward, select the Review + create tab.

+8. Select the Create button to deploy your workspace.

+After a short delay, you will start to see information about your new workspace. Make sure you wait until all parts of the screen are displayed. If your initial deployment was successful, you should see:

+- "Your deployment is complete"

+- Deployment name

+- Subscription name

+- Resource group name

+## Deploy an event hub in the Azure portal using a namespace

+An event hub is the next prerequisite you need to create. It is important because it receives the data flow from a medical device and stores it there until MedTech can pick up the data and translate it into a FHIR service Observation resource. Because Internet propagation times are indeterminate, the event hub is needed to buffer the data and store it for as much as 24 hours before expiring.

+Before you can create an event hub, you must create a namespace in Azure portal to contain it. For more information on how To create a namespace and an event hub, see [Azure Event Hubs namespace and event hub deployed in the Azure portal](../../event-hubs/event-hubs-create.md).

+## Deploy the FHIR service

+The last thing you need to do before you can configure and deploy MedTech service is to deploy the FHIR service.

+There are three ways to deploy FHIR service:

+1. Using portal. See [Deploy a FHIR service within Azure Health Data Services - using portal](../fhir/fhir-portal-quickstart.md).

+2. Using Bicep. See [Deploy a FHIR service within Azure Health Data Services using Bicep](../fhir/fhir-service-bicep.md).

+3. Using an ARM template. See [Deploy a FHIR service within Azure Health Data Services - using ARM template](../fhir/fhir-service-resource-manager-template.md).

+After you have deployed FHIR service, it will be ready to take the data processed by MedTech and persist it as a FHIR service Observation.

+## Next steps

+In this article, you learned about the prerequisites needed to deploy the MedTech service manually. When you have completed all the prerequisite requirements and your FHIR service is deployed, you are ready for the next step of manual deployment, see

+>[!div class="nextstepaction"]

+>[Configure the MedTech service for manual deployment using the Azure portal](deploy-05-new-config.md)

+FHIR&#174; is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.

+ Title: Configuring the MedTech service for deployment using the Azure portal - Azure Health Data Services

+description: In this article, you'll learn how to configure the MedTech service for manual deployment using the Azure portal.

+# Configure the MedTech service for manual deployment using the Azure portal

+Before you can manually deploy the MedTech service, you must complete the following configuration tasks:

+## Set up the MedTech service configuration

+Start with these three steps to begin configuring the MedTech service so it will be ready to accept your tabbed configuration input:

+1. Start by going to the Health Data Services workspace you created in the manual deployment [Prerequisites](deploy-03-new-manual.md#prerequisites) section. Select the Create MedTech service box.

+2. This will take you to the Add MedTech service button. Select the button.

+3. This will take you to the Create MedTech service page. This page has five tabs you need to fill out:

+- Basics

+- Device mapping

+- Destination mapping

+- Tags (optional)

+- Review + create

+## Configure the Basics tab

+Follow these six steps to fill in the Basics tab configuration:

+1. Enter the **MedTech service name**.

+ The **MedTech service name** is a friendly, unique name for your MedTech service. For this example, we'll name the MedTech service `mt-azuredocsdemo`.

+2. Enter the **Event Hubs Namespace**.

+ The Event Hubs Namespace is the name of the **Event Hubs Namespace** that you previously deployed. For this example, we'll use `eh-azuredocsdemo` with our MedTech service device messages.

+ > [!TIP]

+ >

+ > For information about deploying an Azure Event Hubs Namespace, see [Create an Event Hubs Namespace](../../event-hubs/event-hubs-create.md#create-an-event-hubs-namespace).

+ >

+ > For more information about Azure Event Hubs Namespaces, see [Namespace](../../event-hubs/event-hubs-features.md?WT.mc_id=Portal-Microsoft_Healthcare_APIs#namespace) in the Features and terminology in Azure Event Hubs document.

+3. Enter the **Events Hubs name**.

+ The Event Hubs name is the name of the event hub that you previously deployed within the Event Hubs Namespace. For this example, we'll use `devicedata` with our MedTech service device messages.

+ > [!TIP]

+ >

+ > For information about deploying an Azure event hub, see [Create an event hub](../../event-hubs/event-hubs-create.md#create-an-event-hub).

+4. Enter the **Consumer group**.

+ The Consumer group name is located by going to the **Overview** page of the Event Hubs Namespace and selecting the event hub to be used for the MedTech service device messages. In this example, the event hub is named `devicedata`.

+5. When you're inside the event hub, select the **Consumer groups** button under **Entities** to display the name of the consumer group to be used by your MedTech service.

+6. By default, a consumer group named **$Default** is created during the deployment of an event hub. Use this consumer group for your MedTech service deployment.

+ > [!IMPORTANT]

+ >

+ > If you're going to allow access from multiple services to the device message event hub, it is highly recommended that each service has its own event hub consumer group.

+ >

+ > Consumer groups enable multiple consuming applications to have a separate view of the event stream, and to read the stream independently at their own pace and with their own offsets. For more information, see [Consumer groups](../../event-hubs/event-hubs-features.md#consumer-groups).

+ >

+ > Examples:

+ > - Two MedTech services accessing the same device message event hub.

+ > - A MedTech service and a storage writer application accessing the same device message event hub.

+The Basics tab should now look like this after you have filled it out:

+ :::image type="content" source="media\iot-deploy-manual-in-portal\select-device-mapping-button.png" alt-text="Screenshot of Basics tab filled out correctly." lightbox="media\iot-deploy-manual-in-portal\select-device-mapping-button.png":::

+You are now ready to select the Device mapping tab and begin setting up the connection from the medical device to MedTech service.

+## Configure the Device mapping tab

+You need to configure device mapping so that your instance of MedTech service can connect to the device you want to receive data from. This means that the data will be first sent to your event hub instance and then picked up by the MedTech service.

+The easiest way to configure the Device mapping tab is to use the Internet of Medical Things (IoMT) Connector Data Mapper tool to visualize, edit, and test your device mapping. This open source tool is available from [IoMT Connector Data Mapper](https://github.com/microsoft/iomt-fhir/tree/master/tools/data-mapper).

+To begin configuring the device mapping tab, go to the Create MedTech service page and select the **Device mapping** tab. Then follow these two steps:

+1. Go to the IoMT Connector Data Mapper and get the appropriate JSON code.

+2. Return to the Create MedTech service page. Enter the JSON code for the template you want to use into the **Device mapping** tab. After you enter the template code, the Device mapping code will be displayed on the screen.

+3. If the Device code is correct, select the **Next: Destination >** tab to enter the destination properties you want to use with your MedTech service. Note that your device configuration data will be saved for this session.

+For more information regarding device mappings, see the relevant GitHub open source documentation at [Device Content Mapping](https://github.com/microsoft/iomt-fhir/blob/master/docs/Configuration.md#device-content-mapping).

+For Azure docs information about device mapping, see [How to use Device mappings](how-to-use-device-mappings.md).

+## Configure the Destination tab

+In order to configure the destination mapping tab, you can use the IoMT Connector Data Mapper tool to visualize, edit, and test the destination mapping. This open source tool is available from [IoMT Connector Data Mapper](https://github.com/microsoft/iomt-fhir/tree/master/tools/data-mapper). You need to configure destination mapping so that your instance of MedTech service can send and receive data to and from the FHIR service.

+To begin configuring destination mapping, go to the Create MedTech service page and select the **Destination mapping** tab. There are two parts of the tab you must fill out:

+ 1. Destination properties

+ 2. JSON template request

+### Destination properties

+Under the **Destination** tab, use these values to enter the destination properties for your MedTech service instance:

+- First, enter the name of your **FHIR server** using the following four steps:

+ 1. The **FHIR Server** name (also known as the **FHIR service**) can be located by using the **Search** bar at the top of the screen.

+ 1. To connect to your FHIR service instance, enter the name of the FHIR service you used in the manual deploy configuration article at [Deploy the FHIR service](deploy-04-new-prereq.md#deploy-the-fhir-service).

+ 1. Then select the **Properties** button.

+ 1. Next, Copy and paste the **Name** string into the **FHIR Server** text field. In this example, the **FHIR Server** name is `fs-azuredocsdemo`.

+- Next, enter the **Destination Name**.

+ The **Destination Name** is a friendly name for the destination. Enter a unique name for your destination. In this example, the **Destination Name** is

+ `fs-azuredocsdemo`.

+- Then, select the **Resolution Type**.

+ **Resolution Type** specifies how MedTech service will resolve missing data when reading from the FHIR service. MedTech reads device and patient resources from the FHIR service using [device identifiers](https://www.hl7.org/fhir/device-definitions.html#Device.identifier) and [patient identifiers](https://www.hl7.org/fhir/patient-definitions.html#Patient.identifier).

+ Missing data can be resolved by choosing a **Resolution Type** of **Create** and **Lookup**:

+ - **Create**

+ If you selected **Create**, and device or patient resources are missing when you are reading data, new resources will be created, containing just the identifier.

+ - **Lookup**

+

+ If you selected **Lookup**, and device or patient resources are missing, an error will occur, and the data won't be processed. The errors **DeviceNotFoundException** and/or a **PatientNotFoundException** error will be generated, depending on the type of resource not found.

+For more information regarding destination mapping, see the FHIR service GitHub documentation at [FHIR mapping](https://github.com/microsoft/iomt-fhir/blob/master/docs/Configuration.md#fhir-mapping).

+For Azure docs information about destination mapping, see [How to use FHIR destination mappings](how-to-use-fhir-mappings.md).

+### JSON template request

+Before you can complete the FHIR destination mapping, you must get a FHIR destination mapping code. Follow these four steps:

+1. Go to the [IoMT Connector Data Mapper Tool](https://github.com/microsoft/iomt-fhir/tree/master/tools/data-mapper) and get the JSON template for your FHIR destination.

+1. Go back to the Destination tab of the Create MedTech service page.

+1. Go to the large box below the boxes for FHIR server name, Destination name, and Resolution type. Enter the JSON template request in that box.

+1. You will then receive the FHIR Destination mapping code which will be saved as part of your configuration.

+## Configure the Tags tab (optional)

+Before you complete your configuration in the **Review + create** tab, you may want to configure tabs. You can do this by selecting the **Next: Tags >** tabs.

+Tags are name and value pairs used for categorizing resources. This an optional step you may have a lot of resources and want to sort them. For more information about tags, see [Use tags to organize your Azure resources and management hierarchy](../../azure-resource-manager/management/tag-resources.md).

+Follow these steps if you want to create tags:

+1. Under the **Tags** tab, enter the tag properties associated with the MedTech service.

+ - Enter a **Name**.

+ - Enter a **Value**.

+2. Once you've entered your tag(s), you are ready to do the last step of your configuration.

+## Select the Review + create tab to validate your deployment request

+To begin the validation process of your MedTech service deployment, select the **Review + create** tab. There will be a short delay and then you should see a screen that displays a **Validation success** message. Below the message, you should see the following values for your deployment.

+**Basics**

+- MedTech service name

+- Event Hubs name

+- Consumer group

+- Event Hubs namespace

+**Destination**

+- FHIR server

+- Destination name

+- Resolution type

+Your validation screen should look something like this:

+ :::image type="content" source="media\iot-deploy-manual-in-portal\validate-and-review-medtech-service.png" alt-text="Screenshot of validation success with details displayed." lightbox="media\iot-deploy-manual-in-portal\validate-and-review-medtech-service.png":::

+If your MedTech service didn't validate, review the validation failure message, and troubleshoot the issue. Check all properties under each MedTech service tab that you've configured. Go back and try again.

+If your deployment request was successful, you are ready to go on the next step, where you will deploy your MedTech service instance.

+## Next steps

+In this article, you were shown how to configure MedTech service in preparation for deployment and ensure that everything has been validated. To learn about deploying a validated MedTech service instance, see

+>[!div class="nextstepaction"]

+>[Manual deployment and post-deployment of MedTech service](deploy-06-new-deploy.md)

+FHIR&#174; is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.

+ Title: Manual deployment and post-deployment of the MedTech service using the Azure portal - Azure Health Data Services

+description: In this article, you'll learn how to manually create a deployment and post-deployment of the MedTech service in the Azure portal.

+# Manual Deployment and Post-deployment of MedTech service

+When you are satisfied with your configuration and it has been successfully validated, you can complete the deployment and post-deployment process.

+## Create your manual deployment

+1. Select the **Create** button to begin the deployment.

+2. The deployment process may take several minutes. The screen will display a message saying that your deployment is in progress.

+3. When Azure has finished deploying, a message will appear will say, "Your Deployment is complete" and will also display the following information:

+- Deployment name

+- Subscription

+- Resource group

+- Deployment details

+Your screen should look something like this:

+ :::image type="content" source="media\iot-deploy-manual-in-portal\created-medtech-service.png" alt-text="Screenshot of the MedTech service deployment completion." lightbox="media\iot-deploy-manual-in-portal\created-medtech-service.png":::

+## Manual Post-deployment requirements

+There are two post-deployment steps you must perform or the MedTech service can't read device data from the device message event hub, and it also can't read or write to the FHIR service. These steps are:

+1. Grant access to the device message event hub.

+2. Grant access to the FHIR service.

+These two additional steps are needed because MedTech service uses [Azure role-based access control (Azure RBAC)](../../role-based-access-control/overview.md) and a [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) for extra security and control of your MedTech service assets.

+### Grant access to the device message event hub

+Follow these steps to grant access to the device message event hub:

+1. In the **Search** bar at the top center of the Azure portal, enter and select the name of your **Event Hubs Namespace** that was previously created for your MedTech service device messages.

+2. Select the **Event Hubs** button under **Entities**.

+3. Select the event hub that will be used for your MedTech service device messages. For this example, the device message event hub is named `devicedata'.

+4. Select the **Access control (IAM)** button.

+5. Select the **Add role assignment** button.

+6. On the **Add role assignment** page, select the **View** button directly across from the **Azure Event Hubs Data Receiver** role. The Azure Event Hubs Data Receiver role allows the MedTech service to receive device message data from this event hub. For more information about application roles, see [Authentication & Authorization for Azure Health Data Services](.././authentication-authorization.md).

+7. Select the **Select role** button.

+8. Select the **Next** button.

+9. In the **Add role assignment** page, select **Managed identity** next to **Assign access to** and **+ Select members** next to **Members**.

+10. When the **Select managed identities** box opens, under the **Managed identity** box, select **MedTech service,** and find your MedTech service system-assigned managed identity under the **Select** box. Once the system-assigned managed identity for your MedTech service is found, select it, and then select the **Select** button.

+ The system-assigned managed identify name for your MedTech service is a concatenation of the workspace name and the name of your MedTech service, using the format: **"your workspace name"/"your MedTech service name"** or **"your workspace name"/iotconnectors/"your MedTech service name"**. For example: **azuredocsdemo/mt-azuredocsdemo** or **azuredocsdemo/iotconnectors/mt-azuredocsdemo**.

+11. On the **Add role assignment** page, select the **Review + assign** button.

+12. On the **Add role assignment** confirmation page, select the **Review + assign** button.

+13. After the role assignment has been successfully added to the event hub, a notification will display on your screen with a green check mark. This notification indicates that your MedTech service can now read from your device message event hub. It should look like this:

+ :::image type="content" source="media\iot-deploy-manual-in-portal\validate-medtech-service-managed-identity-added-to-event-hub.png" alt-text="Screenshot of the MedTech service system-assigned managed identity being successfully granted access to the event hub with a red box around the message." lightbox="media\iot-deploy-manual-in-portal\validate-medtech-service-managed-identity-added-to-event-hub.png":::

+For more information about authorizing access to Event Hubs resources, see [Authorize access with Azure Active Directory](../../event-hubs/authorize-access-azure-active-directory.md).

+### Grant access to the FHIR service

+The process for granting your MedTech service system-assigned managed identity access to your FHIR service requires the same 13 steps that you used to grant access to your device message event hub. The only exception will be a change to step 6. Your MedTech service system-assigned managed identity will require you to select the **View** button directly across from **FHIR Data Writer** access instead of the button across from **Azure Event Hubs Data Receiver**.

+The **FHIR Data Writer** role provides read and write access to your FHIR service, which your MedTech service uses to access or persist data. Because the MedTech service is deployed as a separate resource, the FHIR service will receive requests from the MedTech service. If the FHIR service doesnΓÇÖt know who's making the request, it will deny the request as unauthorized.

+For more information about assigning roles to the FHIR service, see [Configure Azure Role-based Access Control (RBAC)](.././configure-azure-rbac.md).

+For more information about application roles, see [Authentication & Authorization for Azure Health Data Services](.././authentication-authorization.md).

+Now that you have granted access to the device message event hub and the FHIR service, your manual deployment is complete and MedTech service is ready to receive data from a medical device and process it into a FHIR Observation resource.

+## Next steps

+In this article, you learned how to perform the manual deployment and post-deployment steps to implement your MedTech service. To learn more about other methods of deployment, see

+>[!div class="nextstepaction"]

+>[Choosing a method of deployment for MedTech service in Azure](deploy-iot-connector-in-azure.md)

+>[!div class="nextstepaction"]

+>[Deploy the MedTech service with a QuickStart template](deploy-02-new-button.md)

+>[!div class="nextstepaction"]

+>[Using Azure PowerShell and Azure CLI to deploy the MedTech service using Azure Resource Manager templates](deploy-08-new-ps-cli.md)

+FHIR&#174; is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.

+ Title: Post-deployment granting MedTech service access to the device message event hub and FHIR service

+description: In this article, you'll learn how to grant the MedTech service access to the device message event hub and the FHIR service.

+# Post-Deployment: Granting the MedTech service access to the device message event hub and FHIR service

+There are two final post-deployment steps you must make before the MedTech service can operate fully:

+1. Grant access to the device message event hub.

+2. Grant access to the FHIR service.

+## Granting the MedTech service access to the device message event hub and FHIR service

+MedTech service uses [Azure role-based access control (Azure RBAC)](../../role-based-access-control/overview.md) and a [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) for extra security and control of your MedTech service assets. Once the MedTech service is deployed, it needs to use system-assigned managed identity to access your device message event hub and your instance of the FHIR service. Without these steps, MedTech service can't read device data from the device message event hub, and it also can't read or write to the FHIR service.

+### Granting access to the device message event hub

+Follow these steps to grant access to the device message event hub:

+1. In the **Search** bar at the top center of the Azure portal, enter and select the name of your **Event Hubs Namespace** that was previously created for your MedTech service device messages.

+2. Select the **Event Hubs** button under **Entities**.

+3. Select the event hub that will be used for your MedTech service device messages. For this example, the device message event hub is named `devicedata'.

+4. Select the **Access control (IAM)** button.

+5. Select the **Add role assignment** button.

+6. On the **Add role assignment** page, select the **View** button directly across from the **Azure Event Hubs Data Receiver** role.

+ The Azure Event Hubs Data Receiver role allows the MedTech service that's being assigned this role to receive device message data from this event hub.

+ > [!TIP]

+ >

+ > For more information about application roles, see [Authentication & Authorization for Azure Health Data Services](.././authentication-authorization.md).

+7. Select the **Select role** button.

+8. Select the **Next** button.

+9. In the **Add role assignment** page, select **Managed identity** next to **Assign access to** and **+ Select members** next to **Members**.

+10. When the **Select managed identities** box opens, under the **Managed identity** box, select **MedTech service,** and find your MedTech service system-assigned managed identity under the **Select** box. Once the system-assigned managed identity for your MedTech service is found, select it, and then select the **Select** button.

+ > [!TIP]

+ >

+ > The system-assigned managed identify name for your MedTech service is a concatenation of the workspace name and the name of your MedTech service.

+ >

+ > **"your workspace name"/"your MedTech service name"** or **"your workspace name"/iotconnectors/"your MedTech service name"**

+ >

+ > For example:

+ >

+ > **azuredocsdemo/mt-azuredocsdemo** or **azuredocsdemo/iotconnectors/mt-azuredocsdemo**

+11. On the **Add role assignment** page, select the **Review + assign** button.

+12. On the **Add role assignment** confirmation page, select the **Review + assign** button.

+13. After the role assignment has been successfully added to the event hub, a notification will display on your screen with a green check mark. This notification indicates that your MedTech service can now read from your device message event hub.

+ :::image type="content" source="media\iot-deploy-manual-in-portal\validate-medtech-service-managed-identity-added-to-event-hub.png" alt-text="Screenshot of the MedTech service system-assigned managed identity being successfully granted access to the event hub with a red box around the message." lightbox="media\iot-deploy-manual-in-portal\validate-medtech-service-managed-identity-added-to-event-hub.png":::

+ > [!TIP]

+ >

+ > For more information about authorizing access to Event Hubs resources, see [Authorize access with Azure Active Directory](../../event-hubs/authorize-access-azure-active-directory.md).

+### Granting access to the FHIR service

+The steps for granting your MedTech service system-assigned managed identity access to your FHIR service are the same steps that you took to grant access to your device message event hub. The only exception will be that your MedTech service system-assigned managed identity will require **FHIR Data Writer** access versus **Azure Event Hubs Data Receiver**.

+The **FHIR Data Writer** role provides read and write access to your FHIR service, which your MedTech service uses to access or persist data. Because the MedTech service is deployed as a separate resource, the FHIR service will receive requests from the MedTech service. If the FHIR service doesnΓÇÖt know who's making the request, it will deny the request as unauthorized.

+> [!TIP]

+>

+> For more information about assigning roles to the FHIR service, see [Configure Azure Role-based Access Control (RBAC)](.././configure-azure-rbac.md)

+>

+> For more information about application roles, see [Authentication & Authorization for Azure Health Data Services](.././authentication-authorization.md).

+## Next steps

+In this article, you learned how to perform post-deployment steps to make the MedTech service work properly. To learn more about other methods of deployment, see

+>[!div class="nextstepaction"]

+>[How to manually deploy MedTech service with Azure portal](deploy-03-new-manual.md)

+>[!div class="nextstepaction"]

+>[Deploy the MedTech service with a QuickStart template](deploy-02-new-button.md)

+To learn about choosing a deployment method for the MedTech service, see

+>[!div class="nextstepaction"]

+>[Choosing a method of deployment for MedTech service in Azure](deploy-iot-connector-in-azure.md)

+FHIR&#174; is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.

+ Title: Using Azure PowerShell and Azure CLI to deploy the MedTech service with Azure Resource Manager templates - Azure Health Data Services

+description: In this article, you'll learn how to use Azure PowerShell and Azure CLI to deploy the MedTech service using an Azure Resource Manager template.

+# Using Azure PowerShell and Azure CLI to deploy the MedTech service with Azure Resource Manager templates

+In this quickstart article, you'll learn how to use Azure PowerShell and Azure CLI to deploy the MedTech service using an Azure Resource Manager (ARM) template. When you call the template from PowerShell or CLI, it provides automation that enables you to distribute your deployment to large numbers of developers. Using PowerShell or CLI allows for modifiable automation capabilities that will speed up your deployment configuration in enterprise environments. For more information about ARM templates, see [What are ARM templates?](./../../azure-resource-manager/templates/overview.md).

+## Resources provided by the ARM template

+The ARM template will help you automatically configure and deploy the following resources. Each one can be modified to meet your deployment requirements.

+- Azure Event Hubs namespace and device message event hub (the device message event hub is named: **devicedata**).

+- Azure event hub consumer group (named **$Default**).

+- Azure event hub sender role (named **devicedatasender**).

+- Azure Health Data Services workspace.

+- Azure Health Data Services Fast Healthcare Interoperability Resources (FHIR&#174;) service.

+- Azure Health Data Services MedTech service. This resource includes setup for:

+ - [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) access roles needed to read from the device message event hub (named **Azure Events Hubs Receiver**)

+ - system-assigned managed identity access roles needed to read and write to the FHIR service (named **FHIR Data Writer**)

+- An output file containing the ARM template deployment results (named **medtech_service_ARM_template_deployment_results.txt**). The file is located in the directory from which you ran the script.

+The ARM template used in this article is available from the [Azure Quickstart Templates](https://azure.microsoft.com/resources/templates/iotconnectors/) site using the **azuredeploy.json** file located on [GitHub](https://github.com/Azure/azure-quickstart-templates/blob/master/quickstarts/microsoft.healthcareapis/workspaces/iotconnectors/azuredeploy.json).

+If you need to see a diagram with information on the MedTech service deployment, there is an architecture overview at [Choose a deployment method](deploy-iot-connector-in-azure.md#deployment-architecture-overview). This diagram shows the data flow steps of deployment and how MedTech service processes data into a Fast Healthcare Interoperability Resource (FHIR) Observation.

+## Azure PowerShell prerequisites

+Before you can begin, you need to have the following prerequisites if you're using Azure PowerShell:

+- An Azure account with an active subscription. If you don't have an Azure subscription, see [Subscription decision guide](/azure/cloud-adoption-framework/decision-guides/subscriptions/).

+- If you want to run the code locally, use [Azure PowerShell](/powershell/azure/install-az-ps).

+## Azure CLI prerequisites

+Before you can begin, you need to have the following prerequisites if you're using Azure CLI:

+- An Azure account with an active subscription. If you don't have an Azure subscription, see [Subscription decision guide](/azure/cloud-adoption-framework/decision-guides/subscriptions/).

+- If you want to run the code locally:

+ - Use a Bash shell (such as Git Bash, which is included in [Git for Windows](https://gitforwindows.org).

+ - Use [Azure CLI](/cli/azure/install-azure-cli).

+## Deploy MedTech service with the ARM template and Azure PowerShell

+Complete the following five steps to deploy the MedTech service using Azure PowerShell:

+1. First you need to confirm the region you want to deploy in. See the [Products available by region](https://azure.microsoft.com/global-infrastructure/services/?products=health-data-services) site for the current Azure regions where the Azure Health Data Services is supported.

+ You can also review the **location** section of the **azuredeploy.json** file on [GitHub](https://github.com/Azure/azure-quickstart-templates/blob/master/quickstarts/microsoft.healthcareapis/workspaces/iotconnectors/azuredeploy.json) for Azure regions where the Azure Health Data Services is publicly available. If you need a list of the Azure regions location names, you can use this code to display a list:

+ ```azurepowershell

+ Get-AzLocation | Format-Table -Property DisplayName,Location

+ ```

+2. If the `Microsoft.EventHub` resource provider isn't already registered with your subscription, you can use this code to register it:

+ ```azurepowershell

+ Register-AzResourceProvider -ProviderNamespace Microsoft.EventHub

+ ```

+3. If the `Microsoft.HealthcareApis` resource provider isn't already registered with your subscription, you can use this code to register it:

+ ```azurepowershell

+ Register-AzResourceProvider -ProviderNamespace Microsoft.HealthcareApis

+ ```

+4. If you don't already have a resource group created for this quickstart, you can use this code to create one:

+ ```azurepowershell

+ New-AzResourceGroup -name <ResourceGroupName> -location <AzureRegion>

+ ```

+ For example: `New-AzResourceGroup -name ArmTestDeployment -location southcentralus`

+ > [!IMPORTANT]

+ >

+ > For a successful deployment of the MedTech service, you'll need to use numbers and lowercase letters for the basename of your resources. The minimum basename requirement is three characters with a maximum of 16 characters.

+5. Use the following code to deploy the MedTech service using the ARM template:

+ ```azurepowershell

+ New-AzResourceGroupDeployment -ResourceGroupName <ResourceGroupName> -TemplateUri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.healthcareapis/workspaces/iotconnectors/azuredeploy.json -basename <BaseName> -location <AzureRegion> | Out-File medtech_service_ARM_template_deployment_results.txt

+ ```

+ For example: `New-AzResourceGroupDeployment -ResourceGroupName ArmTestDeployment -TemplateUri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.healthcareapis/workspaces/iotconnectors/azuredeploy.json -basename abc123 -location southcentralus | Out-File medtech_service_ARM_template_deployment_results.txt`

+> [!NOTE]

+> If you want to run the Azure PowerShell commands locally, first enter `Connect-AzAccount` into your PowerShell command-line shell and enter your Azure credentials.

+## Deploy MedTech service with the ARM template and Azure CLI

+Complete the following five steps to deploy the MedTech service using Azure CLI:

+1. First you need to confirm the region you want to deploy in. See the [Products available by region](https://azure.microsoft.com/global-infrastructure/services/?products=health-data-services) site for the current Azure regions where the Azure Health Data Services is supported.

+ You can also review the **location** section of the **azuredeploy.json** file on [GitHub](https://github.com/Azure/azure-quickstart-templates/blob/master/quickstarts/microsoft.healthcareapis/workspaces/iotconnectors/azuredeploy.json) for Azure regions where the Azure Health Data Services is publicly available. If you need a list of the Azure regions location names, you can use this code to display a list:

+ ```azurecli

+ az account list-locations -o table

+ ```

+2. If the `Microsoft.EventHub` resource provider isn't already registered with your subscription, you can use this code to register it:

+ ```azurecli

+ az provider register --name Microsoft.EventHub

+ ```

+3. If the `Microsoft.HealthcareApis` resource provider isn't already registered with your subscription, you can use this code to register it:

+ ```azurecli

+ az provider register --name Microsoft.HealthcareApis

+ ```

+4. If you don't already have a resource group created for this quickstart, you can use this code to create one:

+ ```azurecli

+ az group create --resource-group <ResourceGroupName> --location <AzureRegion>

+ ```

+ For example: `az group create --resource-group ArmTestDeployment --location southcentralus`

+ > [!IMPORTANT]

+ >

+ > For a successful deployment of the MedTech service, you'll need to use numbers and lowercase letters for the basename of your resources.

+5. Use the following code to deploy the MedTech service using the ARM template:

+ ```azurecli

+ az deployment group create --resource-group <ResourceGroupName> --template-uri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.healthcareapis/workspaces/iotconnectors/azuredeploy.json --parameters basename=<YourBaseName> location=<AzureRegion | Out-File medtech_service_ARM_template_deployment_results.txt

+ ```

+ For example: `az deployment group create --resource-group ArmTestDeployment --template-uri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.healthcareapis/workspaces/iotconnectors/azuredeploy.json --parameters basename=abc123 location=southcentralus | Out-File medtech_service_ARM_template_deployment_results.txt`

+> [!NOTE]

+> If you want to run the Azure CLI scripts commands locally, first enter `az login` into your PowerShell command-line shell and enter your Azure credentials.

+## Deployment completion

+The deployment takes a few minutes to complete. You can check the status of your deployment by reading the **medtech_service_ARM_template_deployment_results.txt** file to find out the results of the ARM template deployment.

+## Post-deployment mapping

+After you successfully deploy the MedTech service, you still need to provide valid device mapping and FHIR destination mapping. The device mapping will connect the device message event hub to MedTech service and the FHIR destination mapping will connect FHIR service to MedTech service. You must provide device mapping or the MedTech service can't read device data from the device message event hub. You also must provide FHIR destination mapping or MedTech can't read or write to the FHIR service.

+To learn more about providing device mapping, see [How to use device mappings](how-to-use-device-mappings.md).

+To learn more about providing FHIR destination mapping, see [How to use the FHIR destination mappings](how-to-use-fhir-mappings.md).

+## Clean up Azure PowerShell resources

+When your resource group and deployed ARM template resources are no longer needed, delete the resource group, which deletes the resources in the resource group. Delete them with this code:

+```azurepowershell

+Remove-AzResourceGroup -Name <ResourceGroupName>

+ ```

+For example: `Remove-AzResourceGroup -Name ArmTestDeployment`

+## Clean up Azure CLI resources

+When your resource group and deployed ARM template resources are no longer needed, delete the resource group, which deletes the resources in the resource group. Delete them with this code:

+```azurecli

+az group delete --name <ResourceGroupName>

+```

+For example: `az group delete --resource-group ArmTestDeployment`

+> [!TIP]

+>

+> For a step-by-step tutorial that guides you through the process of creating an ARM template, see [Tutorial: Create and deploy your first ARM template](../../azure-resource-manager/templates/template-tutorial-create-first-template.md).

+## Next steps

+In this article, you learned how to use Azure PowerShell and Azure CLI to deploy the MedTech service using an Azure Resource Manager (ARM) template. To learn more about other methods of deployment, see

+>[!div class="nextstepaction"]

+>[Choosing a method of deployment for MedTech service in Azure](deploy-iot-connector-in-azure.md)

+>[!div class="nextstepaction"]

+>[How to deploy the MedTech service with a Azure ARM QuickStart template](deploy-03-new-manual.md)

+>[!div class="nextstepaction"]

+>[How to manually deploy MedTech service with Azure portal](deploy-03-new-manual.md)

+FHIR&#174; is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.

+ Title: Choosing a method of deployment for MedTech service in Azure - Azure Health Data Services

+description: In this article, you'll learn how to choose a method to deploy the MedTech service in Azure.

+# Choose a deployment method

+MedTech service provides multiple methods for deploying it into an Azure Platform as a service (PaaS) configuration. Each method has different advantages that will allow you to customize your development environment to suit your needs.

+The different deployment methods are:

+- Azure ARM Quickstart template with Deploy to Azure button

+- Azure PowerShell and Azure CLI automation

+- Manual deployment

+## Azure ARM QuickStart template with Deploy to Azure button

+Using a Quickstart template with Azure portal is the easiest and fastest deployment method because it automates most of your configuration with the touch of a **Deploy to Azure** button. This button automatically generates the following configurations and resources: managed identity RBAC roles, a provisioned workspace and namespace, an Event Hubs instance, a FHIR service instance, and a MedTech service instance. All you need to add are post-deployment device mapping, destination mapping, and a shared access policy key. This method simplifies your deployment, but does not allow for much customization.

+For more information about the Quickstart template and the Deploy to Azure button, see [Deploy the MedTech service with a QuickStart template](deploy-02-new-button.md).

+## Azure PowerShell and Azure CLI automation

+Azure provides Azure PowerShell and Azure CLI to speed up your configurations when used in enterprise environments. Deploying MedTech service with Azure PowerShell or Azure CLI can be useful for adding automation so that you can scale your deployment for a large number of developers. This method is more detailed but provides extra speed and efficiency because it allows you to automate your deployment.

+For more information about Using an ARM template with Azure PowerShell and Azure CLI, see [Using Azure PowerShell and Azure CLI to deploy the MedTech service using Azure Resource Manager templates](/deploy-08-new-ps-cli.md).

+## Manual deployment

+The manual deployment method uses Azure portal to implement each deployment task individually. There are no shortcuts. Because you will be able to see all the details of how to complete the sequence of each task, this procedure can be beneficial if you need to customize or troubleshoot your deployment process. This is the most complex method, but it provides valuable technical information and developmental options that will enable you to fine-tune your deployment very precisely.

+For more information about manual deployment with portal, see [Overview of how to manually deploy the MedTech service using the Azure portal](/deploy-03-new-manual.md).

+## Deployment architecture overview

+The following data-flow diagram outlines the basic steps of MedTech service deployment and shows how these steps fit together with its data processing procedures. This may help you analyze the options and determine which deployment method is best for you.

+There are six different steps of the MedTech service PaaS. Only the first four apply to deployment. All the methods of deployment will implement each of these four steps. However, the QuickStart template method will automatically implement part of step 1 and all of step 2. The other two methods will have to implement all of the steps individually. Here is a summary of each of the four deployment steps:

+### Step 1: Prerequisites

+- Have an Azure subscription

+- Create RBAC roles contributor and user access administrator or owner. This feature is automatically done in the QuickStart template method with the Deploy to Azure button, but it is not included in manual or PowerShell/CLI method and need to be implemented individually.

+### Step 2: Provision

+The QuickStart template method with the Deploy to Azure button automatically provides all these steps, but they are not included in the manual or the PowerShell/CLI method and must be completed individually.

+- Create a resource group and workspace for Event Hubs, FHIR, and MedTech services.

+- Provision an Event Hubs instance to a namespace.

+- Provision a FHIR service instance to the same workspace.

+- Provision a MedTech service instance in the same workspace.

+### Step 3: Configure

+Each method needs to provide **all** these configuration details. They include:

+- Configure MedTech service to ingest data from an event hub.

+- Configure device mapping properties.

+- Configure destination mappings to an Observation resource in the FHIR service.

+- When the prerequisites, provisioning, and configuration are complete, create and deploy MedTech service.

+### Step 4: Post-Deployment

+Each method must add **all** these post-deployment tasks:

+- Connect to services using device and destination mapping.

+- Use managed identity to grant access to the device message event hub.

+- Use managed identity to grant access to the FHIR service, enabling FHIR to receive data from the MedTech service.

+- Note: only the ARM QuickStart method requires a shared access key for post-deployment.

+For information about granting access to the device message event hub, see [Granting access to the device message event hub](deploy-07-new-post-deploy.md#granting-access-to-the-device-message-event-hub).

+For information about granting access to the FHIR service, see [Granting access to the FHIR service](deploy-07-new-post-deploy.md#granting-access-to-the-fhir-service).

+In this article, you learned about the different types of deployment for MedTech service. To learn more about MedTech service, see

+>[!div class="nextstepaction"]

+>[What is MedTech service?](/iot-connector-overview.md).

+MedTech service must be configured to ingest data it will receive from an event hub. First you must begin the official deployment process at the Azure portal. For more information about deploying MedTech service using the Azure portal, see [Overview of how to manually deploy the MedTech service using the Azure portal

+](deploy-03-new-manual.md) and [Prerequisites for manually deploying the MedTech service using the Azure portal](deploy-04-new-prereq.md).

+Once you have starting using the portal and added MedTech service to your workspace, you must then configure MedTech service to ingest data from an event hub. For more information about configuring MedTech service to ingest data, see [Configure the MedTech service to ingest data](deploy-05-new-config.md).

+- When you are deploying MedTech service, you must set specific device mapping properties. For more information on device mapping properties, see [Configure the Device mapping properties](deploy-05-new-config.md).

+For step-by-step destination property mapping, see [Configure destination properties](deploy-05-new-config.md).

+If you have completed the prerequisites, provisioning, and configuration, you are now ready to deploy the MedTech service. Create and deploy your MedTech service by following the procedures at [Create your MedTech service](deploy-06-new-deploy.md).

+When you complete the final [deployment procedure](deploy-06-new-deploy.md) and don't get any errors, you must link MedTech service to an Event Hubs and the FHIR service. This will enable a connection from MedTech service to an Event Hubs instance and the FHIR service, so that data can flow smoothly from device to FHIR Observation. In order to do this, the Event Hubs instance for device message flow must be granted access via role assignment, so MedTech service can receive Event Hubs data. You must also grant access to The FHIR service via role assignments in order for MedTech to receive the data. There are two parts of the process to connect to required services.

+For more information about granting access via role assignments, see [Granting the MedTech service access to the device message event hub and FHIR service](deploy-07-new-post-deploy.md#granting-the-medtech-service-access-to-the-device-message-event-hub-and-fhir-service).

+When the device data has been loaded into Event Hubs service, MedTech service can then process it in five stages to convert the data into a unified FHIR format.

+2. **Normalize** - After the data has been ingested, MedTech service uses device mapping to streamline and translate it into a normalized schema format.

+1. Use the **iotedgedev solution init** command to create a solution and set up your Azure IoT Hub. Use the following command to create an IoT Edge solution for a specified development language.

+ iotedgedev solution init --template c

+ iotedgedev solution init --template csharp

+ iotedgedev solution init --template csharpfunction

+ iotedgedev solution init --template java

+ iotedgedev solution init --template nodejs

+ iotedgedev solution init --template python

+The *iotedgedev solution init* script prompts you to complete several steps including:

+- Learn how to [Set up automated regression testing with CI/CD](./tutorial-identify-performance-regression-with-cicd.md).

+- Learn how to [configure automated performance testing](./tutorial-identify-performance-regression-with-cicd.md).

+- Learn more about [configuring automated performance testing with CI/CD](./tutorial-identify-performance-regression-with-cicd.md).

+For more information about running a load test in a CI/CD workflow, see the [Automated regression testing tutorial](./tutorial-identify-performance-regression-with-cicd.md).

+- [Set up automated load testing with CI/CD](./tutorial-identify-performance-regression-with-cicd.md)

+- To learn about performance test automation, see [Configure automated performance testing](./tutorial-identify-performance-regression-with-cicd.md).

+- To learn about performance test automation, see [Configure automated performance testing](./tutorial-identify-performance-regression-with-cicd.md).

+- To learn about performance test automation, see [Configure automated performance testing](./tutorial-identify-performance-regression-with-cicd.md).

+- Learn how to [configure automated performance testing](./tutorial-identify-performance-regression-with-cicd.md).

+- To learn about performance test automation, see [Configure automated performance testing](./tutorial-identify-performance-regression-with-cicd.md).

+If you run a load test within your CI/CD workflow, you can add a CSV file to the test configuration YAML file. For more information about running a load test in a CI/CD workflow, see the [Automated regression testing tutorial](./tutorial-identify-performance-regression-with-cicd.md).

+- To learn about performance test automation, see [Configure automated performance testing](./tutorial-identify-performance-regression-with-cicd.md).

+ > [!IMPORTANT]

+ > Make sure you have sufficient permissions for managing virtual networks. You require the [Network Contributor](/azure/role-based-access-control/built-in-roles#network-contributor) role.

+1. Review or fill the load test information. Follow these steps to [create or manage a test](./how-to-create-manage-test.md).

+ > [!IMPORTANT]

+ > Make sure you have sufficient permissions for managing virtual networks. You require the [Network Contributor](/azure/role-based-access-control/built-in-roles#network-contributor) role.

+### Creating or updating the load test fails with `Subnet ID passed is invalid`

+To configure a load test in a virtual network, you must have sufficient permissions for managing virtual networks. You require the [Network Contributor](/azure/role-based-access-control/built-in-roles#network-contributor) role, or a parent of this role, on the virtual network. See [Check access for a user to Azure resources](/azure/role-based-access-control/check-access) to verify your permissions.

+Get started with [adding load testing to your CI/CD workflow](./tutorial-identify-performance-regression-with-cicd.md) to quickly identify performance degradation of your application under load.

+- [Tutorial: Set up automated load testing](./tutorial-identify-performance-regression-with-cicd.md).

+- Learn how to build [automated regression testing in your CI/CD workflow](./tutorial-identify-performance-regression-with-cicd.md).

+- Learn how to [configure automated performance testing](./tutorial-identify-performance-regression-with-cicd.md).

+ :::image type="content" source="./media/tutorial-identify-bottlenecks-azure-portal/1200-ru-scaling-for-cosmos-db.png" alt-text="Screenshot that shows the updated Azure Cosmos DB scale settings.":::

+ :::image type="content" source="./media/tutorial-identify-bottlenecks-azure-portal/cosmos-db-metrics-post-run.png" alt-text="Screenshot that shows the Azure Cosmos DB client-side metrics after update of the scale settings.":::

+> [Set up automated regression testing](./tutorial-identify-performance-regression-with-cicd.md)

+ Title: 'Tutorial: Automate regression tests with CI/CD'

+description: 'In this tutorial, you learn how to automate regression testing by using Azure Load Testing and CI/CD workflows. Quickly identify performance degradation for applications under high load.'

+#Customer intent: As an Azure user, I want to learn how to automatically test builds for performance regressions on every merge request and/or deployment by using Azure Pipelines.

+# Tutorial: Identify performance regressions by automating load tests with CI/CD

+This tutorial describes how to quickly identify performance regressions by using Azure Load Testing Preview and CI/CD tools. Quickly identify when your application experiences degraded performance under load by running load tests in Azure Pipelines or GitHub Actions.

+In this tutorial, you'll set up a CI/CD pipeline that runs a load test for a sample application on Azure. You'll verify the application behavior under load directly from the CI/CD dashboard. You'll then use load test fail criteria to get alerted when the application doesn't meet your quality requirements.

+In this tutorial, you'll use a sample Node.js application and JMeter script. The tutorial doesn't require any coding or Apache JMeter skills.

+You'll learn how to:

+> [!div class="checklist"]

+> * Set up the sample application GitHub repository.

+> * Configure service authentication for your CI/CD workflow.

+> * Configure the CI/CD workflow to run a load test.

+> * View the load test results in the CI/CD dashboard.

+> * Define load test fail criteria to identify performance regressions.

+> [!NOTE]

+> Azure Pipelines has a 60-minute timeout on jobs that are running on Microsoft-hosted agents for private projects. If your load test is running for more than 60 minutes, you'll need to pay for [additional capacity](/azure/devops/pipelines/agents/hosted?tabs=yaml#capabilities-and-limitations). If not, the pipeline will time out without waiting for the test results. You can view the status of the load test in the Azure portal.

+> [!IMPORTANT]

+> Azure Load Testing is currently in preview. For legal terms that apply to Azure features that are in beta, in preview, or otherwise not yet released into general availability, see the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

+## Prerequisites

+* An Azure account with an active subscription. If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

+* If you're using Azure Pipelines, an Azure DevOps organization and project. If you don't have an Azure DevOps organization, you can [create one for free](/azure/devops/pipelines/get-started/pipelines-sign-up?view=azure-devops&preserve-view=true). If you need help with getting started with Azure Pipelines, see [Create your first pipeline](/azure/devops/pipelines/create-first-pipeline?preserve-view=true&view=azure-devops&tabs=java%2Ctfs-2018-2%2Cbrowser).

+* A GitHub account, where you can create a repository. If you don't have one, you can [create one for free](https://github.com/).

+## Set up the sample application repository

+To get started with this tutorial, you first need to set up a sample Node.js web application. The sample application contains an Azure Pipelines definition to deploy the application on Azure and trigger a load test.

+## Configure service authentication

+Before you configure the CI/CD pipeline to run a load test, you'll grant the CI/CD workflow the permissions to access your Azure load testing resource.

+# [Azure Pipelines](#tab/pipelines)

+To access your Azure Load Testing resource from the Azure Pipelines workflow, you first create a service connection in your Azure DevOps project. The service connection creates an Azure Active Directory [service principal](/active-directory/develop/app-objects-and-service-principals#service-principal-object). This service principal represents your Azure Pipelines workflow in Azure Active Directory.

+Next, you grant permissions to this service principal to create and run a load test with your Azure Load Testing resource.

+### Create a service connection in Azure Pipelines

+Create a service connection in Azure Pipelines so that your CI/CD workflow has access to your Azure subscription. In a next step, you'll then grant permissions to create and run load tests.

+1. Sign in to your Azure DevOps organization (`https://dev.azure.com/<your-organization>`), and select your project.

+1. Select **Project settings** > **Service connections**.

+1. Select **+ New service connection**, select the **Azure Resource Manager** service connection, and then select **Next**.

+1. Select the **Service Principal (automatic)** authentication method, and then select **Next**.

+1. Enter the service connection information, and then select **Save** to create the service connection.

+ | Field | Value |

+ | -- | -- |

+ | **Scope level** | *Subscription*. |

+ | **Subscription** | Select the Azure subscription that will host your load testing resource. |

+ | **Resource group** | Leave empty. The pipeline creates a new resource group for the Azure Load Testing resource. |

+ | **Service connection name** | Enter a unique name for the service connection. You'll use this name later, to configure the pipeline definition. |

+ | **Grant access permission to all pipelines** | Checked. |

+1. Select the service connection that you created from the list, and then select **Manage Service Principal**.

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/manage-service-principal.png" alt-text="Screenshot that shows selections for managing a service principal.":::

+1. In the Azure portal, copy the **Application (Client) ID** value.

+### Grant access to Azure Load Testing

+To grant access to your Azure Load Testing resource, assign the Load Test Contributor role to the service principal. This role grants the service principal access to create and run load tests with your Azure Load Testing service. Learn more about [managing users and roles in Azure Load Testing](./how-to-assign-roles.md).

+1. Retrieve the ID of the service principal object using the Azure CLI. Replace the text placeholder `<application-client-id>` with the value you copied.

+ ```azurecli-interactive

+ object_id=$(az ad sp show --id "<application-client-id>" --query "id" -o tsv)

+ echo $object_id

+ ```

+

+1. Assign the `Load Test Contributor` role to the service principal:

+ ```azurecli-interactive

+ subscription=$(az account show --query "id" -o tsv)

+ echo $subscription

+ az role assignment create --assignee $object_id \

+ --role "Load Test Contributor" \

+ --scope /subscriptions/$subscription \

+ --subscription $subscription

+ ```

+# [GitHub Actions](#tab/github)

+To access your Azure Load Testing resource from the GitHub Actions workflow, you first create an Azure Active Directory [service principal](/active-directory/develop/app-objects-and-service-principals#service-principal-object). This service principal represents your GitHub Actions workflow in Azure Active Directory.

+Next, you grant permissions to the service principal to create and run a load test with your Azure Load Testing resource.

+### Create a service principal

+Create a service principal in the Azure subscription and assign the Contributor role so that your GitHub Actions workflow has access to your Azure subscription. In a next step, you'll then grant permissions to create and run load tests.

+1. Create a service principal and assign the `Contributor` role:

+ ```azurecli-interactive

+ subscription=$(az account show --query "id" -o tsv)

+ echo $subscription

+ az ad sp create-for-rbac --name "my-load-test-cicd" --role contributor \

+ --scopes /subscriptions/$subscription \

+ --sdk-auth

+ ```

+ The output is a JSON object that represents the service principal. You'll use this information to authenticate with Azure in the GitHub Actions workflow.

+ ```output

+ Creating 'contributor' role assignment under scope '/subscriptions/123abc45-6789-0abc-def1-234567890abc'

+ {

+ "clientId": "00000000-0000-0000-0000-000000000000",

+ "clientSecret": "00000000-0000-0000-0000-000000000000",

+ "subscriptionId": "00000000-0000-0000-0000-000000000000",

+ "tenantId": "00000000-0000-0000-0000-000000000000",

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

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

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

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

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

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

+ }

+ ```

+ > [!NOTE]

+ > You might get a `--sdk-auth` deprecation warning when you run this command. Alternatively, you can use OpenID Connect (OIDC) based authentication for authenticating GitHub with Azure. Learn how to [use the Azure login action with OpenID Connect](/azure/developer/github/connect-from-azure#use-the-azure-login-action-with-openid-connect).

+1. Copy the output JSON object.

+1. Add a GitHub secret **AZURE_CREDENTIALS** to your repository to store the service principal you created earlier. The `azure/login` action in the GitHub Actions workflow uses this secret to authenticate with Azure.

+ > [!NOTE]

+ > If you're using OpenID Connect to authenticate with Azure, you don't have to pass the service principal object in the Azure login action. Learn how to [use the Azure login action with OpenID Connect](/azure/developer/github/connect-from-azure#use-the-azure-login-action-with-openid-connect).

+

+ 1. In [GitHub](https://github.com), browse to your forked repository, and select **Settings** > **Secrets** > **Actions** > **New repository secret**.

+

+ 1. Enter the new secret information, and then select **Add secret** to create a new secret.

+ | Field | Value |

+ | -- | -- |

+ | **Name** | *AZURE_CREDENTIALS* |

+ | **Secret** | Paste the JSON role assignment credentials you copied earlier. |

+### Grant access to Azure Load Testing

+To grant access to your Azure Load Testing resource, assign the Load Test Contributor role to the service principal. This role grants the service principal access to create and run load tests with your Azure Load Testing service. Learn more about [managing users and roles in Azure Load Testing](./how-to-assign-roles.md).

+1. Retrieve the ID of the service principal object:

+ ```azurecli-interactive

+ object_id=$(az ad sp list --filter "displayname eq 'my-load-test-cicd'" --query "[0].id" -o tsv)

+ echo $object_id

+ ```

+1. Assign the `Load Test Contributor` role to the service principal:

+ ```azurecli-interactive

+ az role assignment create --assignee $object_id \

+ --role "Load Test Contributor" \

+ --scope /subscriptions/$subscription \

+ --subscription $subscription

+ ```

+## Configure the CI/CD workflow to run a load test

+You'll now create a CI/CD workflow to create and run a load test for the sample application. The sample application repository already contains a CI/CD workflow definition that first deploys the application to Azure, and then creates a load test based on JMeter test script (*SampleApp.jmx*). You'll update the sample workflow definition file to specify the Azure subscription and application details.

+On the first CI/CD workflow run, it creates a new Azure Load Testing resource in your Azure subscription by using the *ARMTemplate/template.json* Azure Resource Manager (ARM) template. Learn more about ARM templates [here](/azure-resource-manager/templates/overview).

+# [Azure Pipelines](#tab/pipelines)

+You'll create a new Azure pipeline that is linked to your fork of the sample application repository. This repository contains the following items:

+- The sample application source code.

+- The *azure-pipelines.yml* pipeline definition file.

+- The *SampleApp.jmx* JMeter test script.

+- The *SampleApp.yaml* Azure Load Testing configuration file.

+To create and run the load test, the Azure Pipelines definition uses the [Azure Load Testing task](/azure/devops/pipelines/tasks/test/azure-load-testing) extension from the Azure DevOps Marketplace.

+1. Open the [Azure Load Testing task extension](https://marketplace.visualstudio.com/items?itemName=AzloadTest.AzloadTesting) in the Azure DevOps Marketplace, and select **Get it free**.

+1. Select your Azure DevOps organization, and then select **Install** to install the extension.

+ If you don't have administrator privileges for the selected Azure DevOps organization, select **Request** to request an administrator to install the extension.

+1. In your Azure DevOps project, select **Pipelines** in the left navigation, and then select **Create pipeline**.

+1. On the **Connect** tab, select **GitHub**.

+1. Select **Authorize Azure Pipelines** to allow Azure Pipelines to access your GitHub account for triggering workflows.

+1. On the **Select** tab, select the sample application's forked repository.

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/create-pipeline-select-repo.png" alt-text="Screenshot that shows how to select the sample application's GitHub repository.":::

+ Azure Pipelines automatically detects the *azure-pipelines.yml* pipeline definition file.

+1. Notice that the pipeline definition contains the `LoadTest` stage, which has two tasks.

+ The `AzureResourceManagerTemplateDeployment` task deploys a new Azure load testing resource in your Azure subscription.

+ Next, the `AzureLoadTest` [Azure Load Testing task](/azure/devops/pipelines/tasks/test/azure-load-testing) creates and starts a load test. This task uses the `SampleApp.yaml` [load test configuration file](./reference-test-config-yaml.md), which contains the configuration parameters for the load test, such as the number of parallel test engines.

+ ```yml

+ - task: AzureLoadTest@1

+ inputs:

+ azureSubscription: $(serviceConnection)

+ loadTestConfigFile: 'SampleApp.yaml'

+ resourceGroup: $(loadTestResourceGroup)

+ loadTestResource: $(loadTestResource)

+ env: |

+ [

+ {

+ "name": "webapp",

+ "value": "$(webAppName).azurewebsites.net"

+ }

+ ]

+ ```

+ If a load test already exists, the `AzureLoadTest` task won't create a new load test, but will add a test run to this load test. To identify regressions over time, you can then [compare multiple test runs](./how-to-compare-multiple-test-runs.md).

+1. On the **Review** tab, replace the following placeholder text at the beginning of the pipeline definition:

+ These variables are used to configure the deployment of the sample application, and to create the load test.

+ |Placeholder |Value |

+ |||

+ | `<Name of your webapp>` | The name of the Azure App Service web app. |

+ | `<Name of your webARM Service connection>` | The name of the service connection that you created in the previous section. |

+ | `<Azure subscriptionId>` | Your Azure subscription ID. |

+ | `<Name of your load test resource>` | The name of your Azure Load Testing resource. |

+ | `<Name of your load test resource group>` | The name of the resource group that contains the Azure Load Testing resource. |

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/create-pipeline-review.png" alt-text="Screenshot that shows the Azure Pipelines Review tab when you're creating a pipeline.":::

+1. Select **Save and run**, enter text for **Commit message**, and then select **Save and run**.

+ Azure Pipelines now runs the CI/CD workflow and will deploy the sample application and create the load test.

+1. Select **Pipelines** in the left navigation, and then select new pipeline run from the list to monitor the status.

+ You can view the detailed run log by selecting the pipeline job.

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/create-pipeline-status.png" alt-text="Screenshot that shows how to view pipeline job details.":::

+# [GitHub Actions](#tab/github)

+You'll create a GitHub Actions workflow in your fork of the sample application repository. This repository contains the following items:

+- The sample application source code.

+- The *.github/workflows/workflow.yml* GitHub Actions workflow.

+- The *SampleApp.jmx* JMeter test script.

+- The *SampleApp.yaml* Azure Load Testing configuration file.

+To create and run the load test, the GitHub Actions workflow uses the [Azure Load Testing Action](https://github.com/marketplace/actions/azure-load-testing) from the GitHub Actions Marketplace.

+The sample application repository already contains a sample workflow file *.github/workflows/workflow.yml*. The GitHub Actions workflow performs the following steps for every update to the main branch:

+- Invoke Azure Load Testing by using the [Azure Load Testing Action](https://github.com/marketplace/actions/azure-load-testing) and the sample Apache JMeter script *SampleApp.jmx* and the load test configuration file *SampleApp.yaml*.

+1. Open the *.github/workflows/workflow.yml* GitHub Actions workflow file in your sample application's repository.

+1. Notice the `loadTest` job, which creates and runs the load test:

+ - The `azure/login` action authenticates with Azure, by using the `AZURE_CREDENTIALS` secret to pass the service principal credentials.

+ ```yml

+ - name: Login to Azure

+ uses: azure/login@v1

+ continue-on-error: false

+ with:

+ creds: ${{ secrets.AZURE_CREDENTIALS }}

+ ```

+ - The `azure/arm-deploy` action deploys a new Azure load testing resource in your Azure subscription.

+ ```yml

+ - name: Create Azure Load Testing resource

+ uses: azure/arm-deploy@v1

+ with:

+ resourceGroupName: ${{ env.LOAD_TEST_RESOURCE_GROUP }}

+ template: ./ARMTemplate/template.json

+ parameters: ./ARMTemplate/parameters.json name=${{ env.LOAD_TEST_RESOURCE }} location="${{ env.LOCATION }}"

+ ```

+ - The `azure/load-testing` [Azure Load Testing Action](https://github.com/marketplace/actions/azure-load-testing) creates and starts a load test. This action uses the `SampleApp.yaml` [load test configuration file](./reference-test-config-yaml.md), which contains the configuration parameters for the load test, such as the number of parallel test engines.

+ ```yml

+ - name: 'Azure Load Testing'

+ uses: azure/load-testing@v1

+ with:

+ loadTestConfigFile: 'SampleApp.yaml'

+ loadTestResource: ${{ env.LOAD_TEST_RESOURCE }}

+ resourceGroup: ${{ env.LOAD_TEST_RESOURCE_GROUP }}

+ env: |

+ [

+ {

+ "name": "webapp",

+ "value": "${{ env.AZURE_WEBAPP_NAME }}.azurewebsites.net"

+ }

+ ]

+ ```

+ If a load test already exists, the `azure/load-testing` action won't create a new load test, but will add a test run to this load test. To identify regressions over time, you can then [compare multiple test runs](./how-to-compare-multiple-test-runs.md).

+

+1. Replace the following placeholder text at the beginning of the workflow definition file:

+ These variables are used to configure the deployment of the sample application, and to create the load test.

+ |Placeholder |Value |

+ |||

+ |`<Name of your webapp>` | The name of the Azure App Service web app. |

+ |`<Name of your load test resource>` | The name of your Azure Load Testing resource. |

+ |`<Name of your load test resource group>` | The name of the resource group that contains the Azure Load Testing resource. |

+ ```yaml

+ env:

+ AZURE_WEBAPP_NAME: "<Name of your webapp>" # set this to your application's name

+ LOAD_TEST_RESOURCE: "<Name of your load test resource>"

+ LOAD_TEST_RESOURCE_GROUP: "<Name of your load test resource group>"

+ ```

+1. Commit your changes to the main branch.

+ The commit will trigger the GitHub Actions workflow in your repository. Verify that the workflow is running by going to the **Actions** tab.

+## View load test results

+Azure Load Testing enables you to view the results of the load test run directly in the CI/CD workflow output. The CI/CD log contains the following client-side metrics:

+- Response time metrics: average, minimum, median, maximum, and 90-95-99 percentiles.

+- Number of requests per second.

+- Total number of requests.

+- Total number of errors.

+- Error rate.

+In addition, the [load test results file](./how-to-export-test-results.md) is available as a workflow run artifact, which you can download for further reporting.

+# [Azure Pipelines](#tab/pipelines)

+1. In your Azure DevOps project, select **Pipelines**, and then select your pipeline definition from the list.

+1. Select the pipeline run to view the run summary.

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/create-pipeline-run-summary.png" alt-text="Screenshot that shows the pipeline run summary.":::

+1. Select **Load Test** in the **Jobs** section to view the pipeline log.

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/create-pipeline-log.png" alt-text="Screenshot that shows the Azure Pipelines run log.":::

+ After the load test finishes, you can view the test summary information and the client-side metrics in the pipeline log. The log also shows the URL to go to the Azure Load Testing dashboard for this load test.

+1. In the pipeline log view, select **Load Test**, and then select **1 artifact produced** to download the result files for the load test.

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/create-pipeline-download-results.png" alt-text="Screenshot that shows how to download the load test results.":::

+# [GitHub Actions](#tab/github)

+1. Select the **Actions** tab in your GitHub repository to view the list of workflow runs.

+

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/github-actions-workflow-run-list.png" alt-text="Screenshot that shows the list of GitHub Actions workflow runs.":::

+

+1. Select the workflow run from the list to open the run details and logging information.

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/github-actions-workflow-completed.png" alt-text="Screenshot that shows the workflow logging information.":::

+ After the load test finishes, you can view the test summary information and the client-side metrics in the workflow log. The log also shows the steps to go to the Azure Load Testing dashboard for this load test.

+1. On the screen that shows the workflow run's details, select the **loadTestResults** artifact to download the result files for the load test.

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/github-actions-artifacts.png" alt-text="Screenshot that shows artifacts of the workflow run.":::

+## Define test fail criteria

+Azure Load Testing enables you to define load test fail criteria. These criteria determine when a load test should pass or fail. For example, your load test should fail when the average response time is greater than a specific value, or when too many errors occur.

+When you run a load test as part of a CI/CD pipeline, the status of the pipeline run will reflect the status of the load test. This approach allows you to quickly identify performance regressions, or degraded application behavior when the application is experiencing high load.

+In this section, you'll configure test fail criteria based on the average response time and the error rate.

+You can specify load test fail criteria for Azure Load Testing in the test configuration YAML file. Learn more about [configuring load test fail criteria](./how-to-define-test-criteria.md).

+1. Edit the *SampleApp.yml* file in your fork of the sample application GitHub repository.

+1. Add the following snippet at the end of the file:

+ ```yaml

+ failureCriteria:

+ - avg(response_time_ms) > 100

+ - percentage(error) > 20

+ ```

+ You've now specified pass/fail criteria for your load test. The test will fail if at least one of these conditions is met:

+

+ - The aggregate average response time is greater than 100 ms.

+ - The aggregate percentage of errors is greater than 20%.

+1. Commit and push the changes to the main branch of the repository.

+

+ The changes will trigger the CI/CD workflow.

+1. After the test finishes, notice that the CI/CD pipeline run has failed.

+ In the CI/CD output log, you find that the test failed because one of the fail criteria was met. The load test average response time was higher than the value that you specified in the pass/fail criteria.

+ :::image type="content" source="./media/tutorial-identify-performance-regression-with-cicd/test-criteria-failed.png" alt-text="Screenshot that shows pipeline logs after failed test criteria.":::

+ The Azure Load Testing service evaluates the criteria during the test run. If any of these conditions fails, Azure Load Testing service returns a nonzero exit code. This code informs the CI/CD workflow that the test has failed.

+1. Edit the *SampleApp.yml* file and change the test's pass/fail criteria to increase the criterion for average response time:

+ ```yaml

+ failureCriteria:

+     - avg(response_time_ms) > 5000

+     - percentage(error) > 20

+ ```

+

+1. Commit the changes to trigger the CI/CD workflow again.

+ After the test finishes, you notice that the load test and the CI/CD workflow run complete successfully.

+## Clean up resources

+## Next steps

+You've now created a CI/CD workflow that uses Azure Load Testing to automate running load tests. By using load test fail criteria, you can set the status of the CI/CD workflow and quickly identify performance and application behavior degradations.

+* Learn more about [Configuring server-side monitoring](./how-to-monitor-server-side-metrics.md).

+* Learn more about [Comparing results across multiple test runs](./how-to-compare-multiple-test-runs.md).

+* Learn more about [Parameterizing a load test](./how-to-parameterize-load-tests.md).

+* Learn more about [Defining test pass/fail criteria](./how-to-define-test-criteria.md).

+| `Workflows.CustomHostName` | None | Sets the host name to use for workflow and input-output URLs, for example, "logic.contoso.com". For information to configure a custom DNS name, see [Map an existing custom DNS name to Azure App Service](../app-service/app-service-web-tutorial-custom-domain.md) and [Secure a custom DNS name with a TLS/SSL binding in Azure App Service](../app-service/configure-ssl-bindings.md). |

+ | **Client secret** | Optional, but recommended | <*client-secret*> | The secret value that the app uses to prove its identity when requesting a token. The client secret is created and stored in your app's configuration as a slot-sticky [application setting](../app-service/configure-common.md#configure-app-settings) named **MICROSOFT_PROVIDER_AUTHENTICATION_SECRET**. To manage the secret in Azure Key Vault instead, you can update this setting later to use [Key Vault references](../app-service/app-service-key-vault-references.md). <br><br>- If you provide a client secret value, sign-in operations use the hybrid flow, returning both access and refresh tokens. <br><br>- If you don't provide a client secret, sign-in operations use the OAuth 2.0 implicit grant flow, returning only an ID token. <br><br>These tokens are sent by the provider and stored in the EasyAuth token store. |

+You can provision the workspace to use user-assigned managed identity, and grant the managed identity additional roles, for example to access your own Azure Container Registry for base Docker images. You can also configure managed identities for use with Azure Machine Learning compute cluster. This managed identity is independent of workspace managed identity. With a compute cluster, the managed identity is used to access resources such as secured datastores that the user running the training job may not have access to. For more information, see [Use managed identities for access control](how-to-identity-based-service-authentication.md).

+* [MLOps on Azure](https://github.com/Azure/mlops-v2)

+> If you need to access data from outside Azure Machine Learning, such as using Azure Storage Explorer, *user* identity is probably what is used. Consult the documentation for the tool or service you are using for specific information. For more information on how Azure Machine Learning works with data, see [Setup authentication between AzureML and other services](how-to-identity-based-service-authentication.md).

+Schedules can also be defined for [create on behalf of](#create-on-behalf-of-preview) compute instances. You can create a schedule that creates the compute instance in a stopped state. Stopped compute instances are useful when you create a compute instance on behalf of another user.

+You can assign a system- or user-assigned [managed identity](/azure/active-directory/managed-identities-azure-resources/overview) to a compute instance, to authenticate against other Azure resources such as storage. Using managed identities for authentication helps improve workspace security and management. For example, you can allow users to access training data only when logged in to a compute instance. Or use a common user-assigned managed identity to permit access to a specific storage account.

+Once the managed identity is created, enable [identity-based data access enabled](how-to-datastore.md) to your storage accounts for that identity. Then, when you work on the compute instance, the managed identity is used automatically to authenticate against data stores.

+You can also use the managed identity manually to authenticate against other Azure resources. The following example shows how to use it to get an Azure Resource Manager access token:

+ For more information on how data access is authenticated, see the [Data administration](how-to-administrate-data-authentication.md) article. For information on configuring identity based access to data, see [Create datastores](how-to-datastore.md).

+* Learn about [data administration](how-to-administrate-data-authentication.md)

+### Using pre-labeled training data from local machine

+If you have previously labeled data that you would like to use to train your model, you will first need to upload the images to the default Azure Blob Storage of your Azure ML Workspace and register it as a [data asset](how-to-create-data-assets.md).

+The following script uploads the image data on your local machine at path "./data/odFridgeObjects" to datastore in Azure Blob Storage. It then creates a new data asset with the name "fridge-items-images-object-detection" in your Azure ML Workspace.

+If there already exists a data asset with the name "fridge-items-images-object-detection" in your Azure ML Workspace, it will update the version number of the data asset and point it to the new location where the image data uploaded.

+If you already have your data present in an existing datastore and want to create a data asset out of it, you can do so by providing the path to the data in the datastore, instead of providing the path of your local machine. Update the code [above](how-to-prepare-datasets-for-automl-images.md#using-pre-labeled-training-data-from-local-machine) with the following snippet.

+# [Azure CLI](#tab/cli)

+Create a .yml file with the following configuration.

+```yml

+$schema: https://azuremlschemas.azureedge.net/latest/data.schema.json

+name: fridge-items-images-object-detection

+description: Fridge-items images Object detection

+path: azureml://subscriptions/<my-subscription-id>/resourcegroups/<my-resource-group>/workspaces/<my-workspace>/datastores/<my-datastore>/paths/<path_to_image_data_folder>

+type: uri_folder

+```

+# [Python SDK](#tab/python)

+

+```Python

+my_data = Data(

+ path="azureml://subscriptions/<my-subscription-id>/resourcegroups/<my-resource-group>/workspaces/<my-workspace>/datastores/<my-datastore>/paths/<path_to_image_data_folder>",

+ type=AssetTypes.URI_FOLDER,

+ description="Fridge-items images Object detection",

+ name="fridge-items-images-object-detection",

+)

+```

+### Using pre-labeled training data from Azure Blob storage

+If you have your labeled training data present in a container in Azure Blob storage, then you can access it directly from there by [creating a datastore referring to that container](how-to-datastore.md#create-an-azure-blob-datastore).

+## Create MLTable

+* [Tutorial: Train an object detection model (preview) with AutoML and Python](tutorial-auto-train-image-models.md).

+- [AzureML authentication to other services](how-to-identity-based-service-authentication.md).

+- [Create datastores](how-to-datastore.md)

+### With our [upgrade tool](https://github.com/Azure/azureml-examples/tree/main/cli/endpoints/online/managed/migration) (preview)

+4. Clone [the repository](https://github.com/Azure/azureml-examples/tree/main/cli/endpoints/online/managed/migration) to your local env. For example, `git clone https://github.com/Azure/azureml-examples`.

+Explore the [AzureML-Examples](https://github.com/Azure/azureml-examples) repository to discover what Azure Machine Learning can do.

+For more examples of MLOps, see [https://github.com/Azure/mlops-v2](https://github.com/Azure/mlops-v2).

+ Title: How to transition to using the grafana.azure.com domain

+description: Learn how to verify that your Azure Managed Grafana workspace is using the correct domain for its endpoint

+

+# Transition to using the grafana.azure.com domain

+If you have an Azure Managed Grafana instance that was created on or before April 17 2022, your workspace is accessible through two URLs: one ending in azgrafana.io and one ending in grafana.azure.com. Both links point to the same workspace.

+URLs ending in azgrafana.io will be deprecated in favor of the URL ending in grafana.azure.com. To avoid losing access to your Grafana workspace, youΓÇÖll need to verify that you can access your workspace through the grafana.azure.com endpoint, and that any links you may have that point to your workspace are using this endpoint as well.

+Azure Managed Grafana workspaces created on or after 18 April 2022 only have a grafana.azure.com URL, so no action is needed to transition those workspaces.

+## Verify the transition

+Verify that you are set to use the grafana.azure.com domain:

+1. In the Azure portal, go to your Azure Managed Grafana resource.

+1. At the top of the **Overview** page, in **Essentials**, look for the endpoint of your Grafana workspace. Verify that the URL ends in grafana.azure.com and that clicking the link takes you to your Grafana endpoint.

+ :::image type="content" source="media/grafana-endpoint/grafana-domain-view-endpoint.png" alt-text="Screenshot of the Azure platform showing the Grafana endpoint URL.":::

+1. If you have any bookmarks or links in your own documentation to your Grafana workspace, make sure that they point to the URL ending in grafana.azure.com listed in the Azure portal.

+## Next steps

+> [!div class="nextstepaction"]

+> [Service reliability](./high-availability.md)

+| South Africa North | :heavy_check_mark: | :heavy_check_mark: ** | :x: |

+ Title: Provision access by data owner for Azure SQL Database (preview)

+description: Step-by-step guide on how data owners can configure access for Azure SQL Database through Microsoft Purview access policies.

+# Provision access by data owner for Azure SQL Database (preview)

+ 1. Navigate to **Security + networking > Networking**.

+1. Select the **Continue** button and traverse the hierarchy to select and underlying data-object (for example: folder, file, etc.). Select **Recursive** to apply the policy from that point in the hierarchy down to any child data-objects. Then select the **Add** button. This will take you back to the policy editor.

+> [Enable Microsoft Purview data owner policies on all data sources in a subscription or a resource group](./how-to-policies-data-owner-resource-group.md)

+| <a name="srcfilepath"></a>**SrcFilePath**| Recommended |String |The full, normalized path of the source file, including the folder or location, the file name, and the extension. <br><br>For more information, see [Path structure](#path-structure).<br><br>Example: `/etc/init.d/networking` |

+|**SrcFilePathType** | Recommended | Enumerated| The type of [SrcFilePath](#srcfilepath). For more information, see [Path structure](#path-structure).|

+| Microsoft | - AAD<br> - Azure Firewall<br> - Azure Blob Storage<br> - Azure File Storage<br> - Azure NSG flows<br> - Azure Queue Storage<br> - Azure Table Storage <br> - DNS Server<br> - Microsoft 365 Defender for Endpoint<br> - Microsoft Defender for IoT<br> - Security Events<br> - Sharepoint 365<br>- Sysmon<br> - Sysmon for Linux<br> - VMConnection<br> - Windows Firewall<br> - WireData <br>

+- An Azure account with an active subscription. Your access role within the subscription must be "Contributor" or "Owner". [Create an account for free](https://azure.microsoft.com/free).

+ - **Cache storage**: Site Recovery needs extra storage account called cache storage in the source region. All the changes happening on the source VMs are tracked and sent to cache storage account before replicating them to the target location. This storage account should be Standard.

+ 1. By default, the recursive flag is true and sync copies all subdirectories. Sync copies only the top-level files inside a directory if the recursive flag is false.

+| Other/protocol transactions | | <ul><li>`AbortCopyFile`</li><li>`Cancel`</li><li>`ChangeNotify`</li><li>`Close`</li><li>`Echo`</li><li>`Ioctl`</li><li>`Lock`</li><li>`Logoff`</li><li>`Negotiate`</li><li>`OplockBreak`</li><li>`SessionSetup`</li><li>`TreeConnect`</li><li>`TreeDisconnect`</li><li>`CloseHandles`</li><li>`AcquireFileLease`</li><li>`BreakFileLease`</li><li>`ChangeFileLease`</li><li>`ReleaseFileLease`</li><li>`BreakShareLease`</li><li>`RenewShareLease`</li><li>`ChangeShareLease`</li></ul> |

+ - **Azure-orchestrated** - Patch orchestration set to Azure-orchestrated for an Azure VM (not applicable for Arc-enabled server) has two different implications depending on whether customer [schedule](../update-center/scheduled-patching.md#) is attached to it or not.

+

+ | Patch orchestration type | Description

+ |-|-|

+ |Azure-orchestrated with no schedule attached | Machine is enabled for [automatic VM guest patching](../virtual-machines/automatic-vm-guest-patching.md). It implies that the available Critical and Security patches are downloaded and applied automatically on the Azure VM. This process kicks off automatically every month when new patches are released. Patch assessment and installation are automatic, and the process includes rebooting the VM as required.|

+ |Azure-orchestrated with schedule attached | Patching will happen according to the schedule and [automatic VM guest patching](../virtual-machines/automatic-vm-guest-patching.md) will not take effect on the machine. Patch orchestration set to Azure-orchestrated is a necessary pre-condition for enabling schedules. You cannot enable a machine for custom schedule unless you set Patch orchestration to Azure-orchestrated. |

+ - Available *Critical* and *Security* patches are downloaded and applied automatically on the Azure VM using [automatic VM guest patching](../virtual-machines/automatic-vm-guest-patching.md). This process kicks off automatically every month when new patches are released. Patch assessment and installation are automatic, and the process includes rebooting the VM as required.

+> [!NOTE]

+> Patch orchestration set to Azure-orchestrated is a pre-condition to enable schedule patching on Azure VM. For more information, see the [list of prerequisites](../update-center/scheduled-patching.md#prerequisites-for-scheduled-patching)

+description: This article describes FSLogix profile containers within Azure Virtual Desktop and Azure Files.

+> RDP Shortpath doesn't support Symmetric NAT, which is the mapping of a single private source *IP:Port* to a unique public destination *IP:Port*. This is because RDP Shortpath needs to reuse the same external port (or NAT binding) used in the initial connection. Where multiple paths are used, for example a highly available firewall pair, external port reuse cannot be guaranteed. Azure Firewall and Azure NAT Gateway use Symmetric NAT. For more information about NAT with Azure virtual networks, see [Source Network Address Translation with virtual networks](../virtual-network/nat-gateway/nat-gateway-resource.md#source-network-address-translation).

+Listing the run commands or showing the details of a command requires the `Microsoft.Compute/locations/runCommands/read` permission on Subscription level. The built-in [Reader](../../role-based-access-control/built-in-roles.md#reader) role and higher levels have this permission.

+ Title: 'About user groups and IP address pools for point-to-site User VPN'

+description: Learn about using user groups to assign IP addresses from specific address pools based on identity or authentication credentials.

+# About user groups and IP address pools for P2S User VPNs (preview)

+You can configure P2S User VPNs to assign users IP addresses from specific address pools based on their identity or authentication credentials by creating **User Groups**. This article describes the different configurations and parameters the Virtual WAN P2S VPN gateway uses to determine user groups and assign IP addresses.

+## Use cases

+Contoso corporation is composed of multiple functional departments, such as Finance, Human Resources and Engineering. Contoso uses Virtual WAN to allow remote workers (users) to connect to Azure Virtual WAN and access resources hosted on-premises or in a Virtual Network connected to the Virtual WAN hub.

+However, Contoso has internal security policies where users from the Finance department can only access certain databases and Virtual Machines and users from Human Resources have access to other sensitive applications.

+Contoso can configure different user groups for each of their functional departments. This will ensure users from each department are assigned IP addresses from a department-level pre-defined address pool.

+Contoso's network administrator can then configure Firewall rules, network security groups (NSG) or access control lists (ACLs) to allow or deny certain users access to resources based on their IP addresses.

+## Server configuration concepts

+The following sections explain the common terms and values used for server configuration.

+### User Groups (policy groups)

+A **User Group** or policy group is a logical representation of a group of users that should be assigned IP addresses from the same address pool.

+### Group members (policy members)

+User groups consist of members. Members don't correspond to individual users but rather define the criteria used to determine which group a connecting user is a part of. A single group can have multiple members. If a connecting user matches the criteria specified for one of the group's members, the user is considered to be part of that group and can be assigned an appropriate IP address.

+The types of member parameters that are available depend on the authentication methods specified in the VPN server configuration. For a full list of available criteria, see the [Available group settings](#available-group-settings) section of this article.

+### Default user/policy group

+For every P2S VPN server configuration, one group must be selected as default. Users who present credentials that don't match any group settings are considered to be part of the default group. Once a group is created, the default setting of that group can't be changed.

+### Group priority

+Each group is also assigned a numerical priority. Groups with lower priority are evaluated first. This means that if a user presents credentials that match the settings of multiple groups, they'll be considered part of the group with the lowest priority. For example, if user A presents a credential that corresponds to the IT Group (priority 3) and Finance Group (priority 4), user A will be considered part of the IT Group for purposes of assigning IP addresses.

+### Available group settings

+The following section describes the different parameters that can be used to define which groups members are a part of. The available parameters vary based on selected authentication methods.

+The table below summarizes the available setting types and acceptable values. For more detailed information on each type of Member Value, view the section corresponding to your authentication type.

+|Authentication type|Member type |Member values|Example member value|

+|||||

+Azure Active Directory|AADGroupID|Azure Active Directory Group Object ID |0cf484f2-238e-440b-8c73-7bf232b248dc|

+|RADIUS|AzureRADIUSGroupID|Vendor-specific Attribute Value (hexadecimal) (must begin with 6ad1bd)|6ad1bd23|

+|Certificate|AzureCertificateID|Certificate Common Name domain name (CN=user@red.com)|red|

+#### Azure Active Directory authentication (OpenVPN only)

+Gateways using Azure Active Directory authentication can use **Azure Active Directory Group Object IDs** to determine which user group a user belongs to. If a user is part of multiple Azure Active Directory groups, they're considered to be part of the Virtual WAN user group that has the lowest numerical priority.

+#### Azure Certificate (OpenVPN and IKEv2)

+Gateways that use Certificate-based authentication use the **domain name** of user certificate Common Names (CN) to determine which group a connecting user is in. Common Names must be in one of the following formats:

+* domain/username

+* username@domain.com

+Make sure that the **domain** is the input as a group member.

+#### RADIUS server (OpenVPN and IKEv2)

+Gateways that use RADIUS-based authentication use a new **Vendor-Specific Attribute (VSA)** to determine VPN user groups.

+When RADIUS-based authentication is configured on the P2S gateway, the gateway serves as a Network Policy Server (NPS) proxy. This means that the P2S VPN gateway serves as a client to authenticate users with your RADIUS server using the RADIUS protocol.

+After your RADIUS server has successfully verified the user's credentials, the RADIUS server can be configured to send a new Vendor-Specific Attribute (VSA) as part of Access-Accept packets. The P2S VPN gateway processes the VSA in the Access-Accept packets and assigns specific IP addresses to users based on the value of the VSAs.

+Therefore, RADIUS servers should be configured to send a VSA with the same value for all users that are part of the same group.

+>[!NOTE]

+> The value of the VSA must be an octet hexadecimal string on the RADIUS server and the Azure. This octet string must begin with **6ad1bd**. The last two hexadecimal digits may be configured freely. For example, 6ad1bd98 is valid but 6ad12323 and 6a1bd2 would not be valid.

+>

+The new VSA is **MS-Azure-Policy-ID**.

+The MS-Azure-Policy-ID VSA is used by the RADIUS server to send an identifier that is used by P2S VPN server to match an authenticated RADIUS user policy configured on Azure side. This policy is used to select the IP/ Routing configuration (assigned IP address) for the user.

+The fields of MS-Azure-Policy-ID MUST be set as follows:

+* **Vendor-Type:** An 8-bit unsigned integer that MUST be set to 0x41 (integer: 65).

+* **Vendor-Length:** An 8-bit unsigned integer that MUST be set to the length of the octet string in the Attribute-Specific Value plus 2.

+* **Attribute-Specific Value:** An octet string containing Policy ID configured on Azure Point to Site VPN server.

+For configuration information, see [RADIUS - configure NPS for vendor-specific attributes](user-groups-radius.md).

+## Gateway concepts

+When a Virtual WAN P2S VPN gateway is assigned a VPN server configuration that uses user/policy groups, you can create multiple P2S VPN connection configurations on the gateway.

+Each connection configuration can contain one or more VPN server configuration user groups. Each connection configuration is then mapped to one or more IP address pools. Users who connect to this gateway are assigned an IP address based on their identity, credentials, default group, and priority.

+In this example, the VPN server configuration has the following groups configured:

+|Default|Priority|Group name|Authentication type|Member value|

+||||||

+|Yes|0|Engineering|Azure Active Directory|groupObjectId1|

+|No|1|Finance|Azure Active Directory|groupObjectId2|

+|No|2|PM|Azure Active Directory|groupObjectId3|

+This VPN server configuration can be assigned to a P2S VPN gateway in Virtual WAN with:

+|Configuration|Groups|Address pools|

+||||

+|Config0|Engineering, PM|x.x.x.x/yy|

+|Config1|Finance|a.a.a.a/bb|

+The following result is:

+* Users who are connecting to this P2S VPN gateway will be assigned an address from x.x.x.x/yy if they're part of the Engineering or PM Azure Active Directory groups.

+* Users who are part of Finance Azure Active Directory group are assigned IP addresses from a.a.a.a/bb.

+* Because Engineering is the default group, users who aren't part of any configured group are assumed to be part of Engineering and assigned an IP address from x.x.x.x/yy.

+## Configuration considerations

+## Next steps

+* To create User Groups, see [Create User Groups for P2S User VPN](user-groups-create.md).

+ Title: 'Configure user groups and IP address pools for point-to-site User VPNs'

+description: Learn how to configure user groups and assign IP addresses from specific address pools based on identity or authentication credentials.

+# Configure user groups and IP address pools for P2S User VPNs (preview)

+You can configure P2S User VPNs to assign users IP addresses from specific address pools based on their identity or authentication credentials by creating **User Groups**. This article helps you configure user groups, group members, and prioritize groups. For more information about working with user groups, see [About user groups](user-groups-about.md).

+## Configuration considerations

+### Additional configuration information

+#### Azure Active Directory groups

+To create and manage Active Directory groups, see [Manage Azure Active Directory groups and group membership](../active-directory/fundamentals/how-to-manage-groups.md).

+* The Azure Active Directory group object ID (and not the group name) needs to be specified as part of the Virtual WAN point-to-site User VPN configuration.

+* Azure Active Directory users can be assigned to be part of multiple Active Directory groups, but Virtual WAN considers users to be part of the Virtual WAN user/policy group that has the lowest numerical priority.

+#### RADIUS - NPS vendor-specific attributes

+For Network Policy Server (NPS) vendor-specific attributes configuration information, see [RADIUS - configure NPS for vendor-specific attributes](user-groups-radius.md).

+#### Generating self-signed certificates

+To generate self-signed certificates, see [Generate and export certificates for User VPN P2S connections: PowerShell](certificates-point-to-site.md). To generate a certificate with a specific Common Name, change the **Subject** parameter to the appropriate value (example, xx@domain.com) when running the `New-SelfSignedCertificate` PowerShell command.

+## Prerequisites

+Before beginning, make sure you've configured a virtual WAN that uses one or more authentication methods. For steps, see [Tutorial: Create a Virtual WAN User VPN P2S connection](virtual-wan-point-to-site-portal.md).

+## Create a user group

+1. In the Azure portal, go to your **Virtual WAN -> User VPN configurations** page.

+1. On the **User VPN configurations** page, select the User VPN Configuration that you want to edit, then click **Edit configuration**.

+1. On the **Edit User VPN configuration** page, open the **User Groups** tab.

+ :::image type="content" source="./media/user-groups-create/enable-user-groups.png" alt-text="Screenshot of enabling User Groups." lightbox="./media/user-groups-create/enable-user-groups.png":::

+1. Select **Yes** to enable user groups. When this server configuration is assigned to a P2S VPN gateway, users who are part of the same user groups are assigned IP addresses from the same address pools. Users who are part of different groups are assigned IP addresses from different groups. When you use this feature, you must select **Default** group for one of the groups that you create.

+1. To begin creating a new User Group, fill out the name parameter with the name of the first group.

+1. Next to the **Group Name**, click **Configure Group** to open the **Configure Group Settings** page.

+ :::image type="content" source="./media/user-groups-create/new-group.png" alt-text="Screenshot of creating a new group." lightbox="./media/user-groups-create/new-group.png":::

+1. On the **Configure Group Settings** page, fill in the values for each member that you want to include in this group. A group can contain multiple group members.

+ * Create a new member by filling in the **Name** field.

+ * Select the **Authentication: Setting Type** from the dropdown. The dropdown is automatically populated based on the selected authentication methods for the User VPN configuration.

+ * Type the **Value**. For valid values, see [About user groups](user-groups-about.md).

+ :::image type="content" source="./media/user-groups-create/group-members.png" alt-text="Screenshot of configuring values for User Group members." lightbox="./media/user-groups-create/group-members.png":::

+1. When you're finished creating the settings for the group, click **Add** and **Okay**.

+1. Create any additional groups.

+1. Select at least one group as default. Users who aren't part of any group specified on a gateway will be assigned to the default group on the gateway. Also note that you can't modify the "default" status of a group after the group has been created.

+ :::image type="content" source="./media/user-groups-create/select-default.png" alt-text="Screenshot of selecting the default group." lightbox="./media/user-groups-create/select-default.png":::

+1. Click the arrows to adjust the group priority order.

+ :::image type="content" source="./media/user-groups-create/adjust-order.png" alt-text="Screenshot of adjusting the priority order." lightbox="./media/user-groups-create/adjust-order.png":::

+1. Click **Review + create** to create and configure. After you create the User VPN configuration, configure the gateway server configuration settings to use the user groups feature.

+## Configure gateway settings

+1. In the portal, go to your virtual hub and click **User VPN (Point to site)**.

+1. On the point to site page, click the **Gateway scale units** link to open the **Edit User VPN gateway**. Adjust the **Gateway scale units** value from the dropdown to determine gateway throughput.

+1. For **Point to site server configuration**, select the User VPN configuration that you configured for user groups. If you haven't yet configured these settings, see [Create user groups](user-groups-create.md).

+1. Create a new point to site configuration by typing a new **Configuration Name**.

+1. Select one or more groups to be associated with this configuration. All the users who are part of groups that are associated with this configuration will be assigned IP addresses from the same IP address pools.

+ Across all configurations for this gateway, you must have exactly one default user group selected.

+ :::image type="content" source="./media/user-groups-create/select-groups.png" alt-text="Screenshot of Edit User VPN gateway page with groups selected." lightbox="./media/user-groups-create/select-groups.png":::

+1. For **Address Pools**, click **Configure** to open the **Specify Address Pools** page. On this page, associate new address pools with this configuration. Users who are members of groups associated to this configuration will be assigned IP addresses from the specified pools. Based on the number of **Gateway Scale Units** associated to the gateway, you may need to specify more than one address pool. Click **Add** and **Okay** to save your address pools.

+ :::image type="content" source="./media/user-groups-create/address-pools.png" alt-text="Screenshot of Specify Address Pools page." lightbox="./media/user-groups-create/address-pools.png":::

+1. You'll need one configuration for each set of groups that should be assigned IP addresses from different address pools. Repeat the steps to create more configurations. See [Configuration considerations](#configuration-considerations) for requirements and limitations regarding address pools and groups.

+1. After you've created the configurations that you need, click **Edit**, and then **Confirm** to save your settings.

+ :::image type="content" source="./media/user-groups-create/confirm.png" alt-text="Screenshot of Confirm settings." lightbox="./media/user-groups-create/confirm.png":::

+## Troubleshooting

+1. Wireshark or another packet capture can be run in NPS mode and decrypt packets using shared key. You can validate packets are being sent from your RADIUS server to the point-to-site VPN gateway with the right RADIUS VSA configured.

+1. Set up and check NPS Event logging for authentication whether or not users are matching policies.

+1. Every address pool specified on the gateway. Address pools are split into two address pools and assigned to each active-active instance in a point-to-site VPN gateway pair. These split addresses should show up in the effective route table. For example, if you specify 10.0.0.0/24, you should see two /25 routes in the effective route table. If this isn't the case, try changing the address pools defined on the gateway.

+1. Make sure all point-to-site VPN connection configurations are associated to the defaultRouteTable and propagate to the same set of route tables. This should be configured automatically if you're using portal, but if you're using REST, PowerShell or CLI, make sure all propagations and associations are set appropriately.

+1. If you're using the Azure VPN client, make sure the Azure VPN client installed on user devices are the latest version.

+## Next steps

+* For more information about user groups, see [About user groups and IP address pools for P2S User VPNs](user-groups-about.md).

+ Title: 'Configure vender-specific attributes for P2S User Groups - RADIUS'

+description: Learn how to configure RADIUS/NPS for user groups to assign IP addresses from specific address pools based on identity or authentication credentials.

+# RADIUS - Configure NPS for vendor-specific attributes - P2S user groups (preview)

+The following section describes how to configure Windows Server Network Policy Server (NPS) to authenticate users to respond to Access-Request messages with the Vendor Specific Attribute (VSA) used for user group support in Virtual WAN point-to-site-VPN. The following steps assume that your Network Policy Server is already registered to Active Directory. The steps may vary depending on the vendor/version of your NPS server.

+The following steps describe setting up single Network Policy on the NPS server. The NPS server will reply with the specified VSA for all users who match this policy, and the value of this VSA can be used on your point-to-site VPN gateway in Virtual WAN.

+## Configure

+1. Open the **Network Policy Server** management console, and right click **Network Policies -> New** to create a new Network Policy.

+ :::image type="content" source="./media/user-groups-radius/network-policy-server.png" alt-text="Screenshot of new network policy." lightbox="./media/user-groups-radius/network-policy-server.png":::

+1. In the wizard, select **Access granted** to ensure your RADIUS server can send Access-Accept messages after authentication users. Then, click **Next**.

+1. Name the policy and select **Remote Access Server (VPN-Dial up)** as the network access server type. Then, click **Next**.

+ :::image type="content" source="./media/user-groups-radius/policy-name.png" alt-text="Screenshot of policy name field." lightbox="./media/user-groups-radius/policy-name.png":::

+1. On the **Specify Conditions** page, click **Add** to select a condition. Then, select **User Groups** as the condition and click **Add**. You may also use other Network Policy conditions that are supported by your RADIUS server vendor.

+ :::image type="content" source="./media/user-groups-radius/specify.png" alt-text="Screenshot of specifying conditions for User Groups." lightbox="./media/user-groups-radius/specify.png":::

+1. On the **User Groups** page, click **Add Groups** and select the Active Directory groups that will use this policy. Then, click **OK** and **OK** again. You'll see the groups you've added in the **User Groups** window. Click **OK** to return to the **Specify Conditions** page and click **Next**.

+1. On the **Specify Access Permission** page, select **Access granted** to ensure your RADIUS server can send Access-Accept messages after authenticating users. Then, click **Next**.

+ :::image type="content" source="./media/user-groups-radius/specify-access.png" alt-text="Screenshot of the Specify Access Permission page." lightbox="./media/user-groups-radius/specify-access.png":::

+1. For **Configuration Authentication Methods**, make any necessary changes, then click **Next**.

+1. For **Configure Constraints** select any necessary settings. Then, click **Next**.

+1. On the **Configure Settings** page, for **RADIUS Attributes**, highlight **Vendor Specific** and click **Add**.

+ :::image type="content" source="./media/user-groups-radius/configure-settings.png" alt-text="Screenshot of the Configure Settings page." lightbox="./media/user-groups-radius/configure-settings.png":::

+ 1. On the **Add Vendor Specific Attribute** page, scroll to select **Vendor-Specific**.

+ :::image type="content" source="./media/user-groups-radius/vendor-specific.png" alt-text="Screenshot of the Add Vendor Specific Attribute page with Vendor-Specific selected." lightbox="./media/user-groups-radius/vendor-specific.png":::

+1. Click **Add** to open the **Attribute Information** page. Then, click **Add** to open the **Vendor-Specific Attribute Information** page. Select **Select from list** and select **Microsoft**. Select **Yes. It conforms**. Then, click **Configure Attribute**.

+ :::image type="content" source="./media/user-groups-radius/attribute-information.png" alt-text="Screenshot of the Attribute Information page." lightbox="./media/user-groups-radius/attribute-information.png":::

+1. On the **Configure VSA (RFC Compliant)** page, select the following values:

+ * **Vendor-assigned attribute number**: 65

+ * **Attribute format**: Hexadecimal

+ * **Attribute value**: Set this to the VSA value you have configured on your VPN server configuration, such as 6a1bd08. The VSA value should begin with **6ad1bd**.

+1. Click **OK** and **OK** again to close the windows. On the **Attribute Information** page, you'll see the Vendor and Value listed that you just input. Click **OK** to close the window. Then, click **Close** to return to the **Configure Settings** page.

+1. The **Configure Settings** now looks similar to the following screenshot:

+ :::image type="content" source="./media/user-groups-radius/vendor-value.png" alt-text="Screenshot of the Configure Settings page with Vendor Specific attributes." lightbox="./media/user-groups-radius/vendor-value.png":::

+1. Click **Next** and then **Finish**. You can create multiple network policies on your RADIUS server to send different Access-Accept messages to the Virtual WAN point-to-site VPN gateway based on Active Directory group membership or any other mechanism you would like to support.

+## Next steps

+* For more information about user groups, see [About user groups and IP address pools for P2S User VPNs](user-groups-about.md).

+* To configure user groups, see [Configure user groups and IP address pools for P2S User VPNs](user-groups-create.md).

+* The following ExpressRoute circuit SKUs can be connected to the hub gateway: Local, Standard, and Premium

+ * **Virtual network** - Select the virtual network you want to connect to this hub. The virtual network can't have an already existing virtual network gateway (neither VPN nor ExpressRoute).

+* ExpressRoute Standard or Premium circuits that are in ExpressRoute Global Reach-supported locations can connect to a Virtual WAN ExpressRoute gateway and enjoy all Virtual WAN transit capabilities (VPN-to-VPN, VPN-to-ExpressRoute, and ExpressRoute-to-ExpressRoute transit).