-MSAL.js supports both **v1.0** and **v2.0** endpoints. The **v2.0** endpoint employs a *scope-centric* model to access resources. Thus, when you request an access token for a resource, you also need to specify the scope for that resource:

-The v2.0 endpoint employs a *scope-centric* model to access resources. Thus, when you request an access token for a resource, you also need to specify the scope for that resource:

-Typically, when a request is approved, entitlement management will provision the user with the necessary access. If the user isn't already in your directory, entitlement management will first invite the user. When the user is invited, Azure AD will automatically create a B2B guest account for them but won't send the user an email. An administrator may have previously limited which organizations are allowed for collaboration, by setting a [B2B allow or blocklist](../external-identities/allow-deny-list.md) to allow or block invites to other organization's domains. If the user's domain isn't allowed by those lists, then they won't be invited and can't be assigned access until the lists are updated.

-Since you don't want the external user's access to last forever, you specify an expiration date in the policy, such as 180 days. After 180 days, if their access isn't extended, entitlement management will remove all access associated with that access package. By default, if the user who was invited through entitlement management has no other access package assignments, then when they lose their last assignment, their guest account will be blocked from signing in for 30 days, and later removed. This prevents the proliferation of unnecessary accounts. As described in the following sections, these settings are configurable.

-1. An approver [approves the request](entitlement-management-request-approve.md) (or the request is auto-approved).

-1. Using the B2B invite process, a guest user account is created in your directory (**Requestor A (Guest)** in this example). If an [allowlist or a blocklist](../external-identities/allow-deny-list.md) is defined, the list setting will be applied.

-### Review your Conditional Access policies

-authSettings=$(echo "$authSettings" | jq '.properties' | jq '.identityProviders.azureActiveDirectory.login += {"loginParameters":["scope=openid profile email offline_access api://<back-end-client-id>/user_impersonation"]}')

-### Configuration file example

-The example below highlights a couple key requirements for Arc resource bridge when creating the configuration files. The IPs for `k8snodeippoolstart` and `k8snodeippoolend` reside in the subnet range designated in `ipaddressprefix`. The `ipaddressprefix` is provided in the format of the subnet's IP address range for the virtual network and subnet mask (IP Mask) in CIDR notation.

-```

-azurestackhciprovider:

-virtualnetwork:

-name: "mgmtvnet

-vswitchname: "Default Switch

-type: "Transparent"

-macpoolname

-vlanid: 0

-ipaddressprefix: 172.16.0.0/16

-gateway: 17.16.1.1

-dnsservers: 17.16.0.1

-vippoolstart: 172.16.250.0

-vippoolend: 172.16.250.254

-k8snodeippoolstart: 172.16.30.0

-k8snodeippoolend: 172.16.30.254

-```

-Use import to bring Redis compatible RDB files from any Redis server running in any cloud or environment, including Redis running on Linux, Windows, or any cloud provider such as Amazon Web Services and others. Importing data is an easy way to create a cache with pre-populated data. During the import process, Azure Cache for Redis loads the RDB files from Azure storage into memory and then inserts the keys into the cache.

-Yes, and you can import/export between a clustered cache and a non-clustered cache. Since Redis cluster [only supports database 0](cache-how-to-premium-clustering.md#do-i-need-to-make-any-changes-to-my-client-application-to-use-clustering), any data in databases other than 0 isn't imported. When clustered cache data is imported, the keys are redistributed among the shards of the cluster.

-For information about pricing for supported countries/regions, see [Azure Monitor pricing](https://azure.microsoft.com/pricing/details/monitor/).

->

-> The only country code that action groups currently support for voice notification is +1 for the United States.

-Date list was last updated: 03/01/2023.

-|Data Disk Bandwidth Consumed Percentage |Yes |Data Disk Bandwidth Consumed Percentage |Percent |Average |Percentage of data disk bandwidth consumed per minute |LUN |

-|Data Disk IOPS Consumed Percentage |Yes |Data Disk IOPS Consumed Percentage |Percent |Average |Percentage of data disk I/Os consumed per minute |LUN |

-|OS Disk Bandwidth Consumed Percentage |Yes |OS Disk Bandwidth Consumed Percentage |Percent |Average |Percentage of operating system disk bandwidth consumed per minute |LUN |

-|OS Disk IOPS Consumed Percentage |Yes |OS Disk IOPS Consumed Percentage |Percent |Average |Percentage of operating system disk I/Os consumed per minute |LUN |

-|VM Cached Bandwidth Consumed Percentage |Yes |VM Cached Bandwidth Consumed Percentage |Percent |Average |Percentage of cached disk bandwidth consumed by the VM |No Dimensions |

-|VM Cached IOPS Consumed Percentage |Yes |VM Cached IOPS Consumed Percentage |Percent |Average |Percentage of cached disk IOPS consumed by the VM |No Dimensions |

-|VM Uncached Bandwidth Consumed Percentage |Yes |VM Uncached Bandwidth Consumed Percentage |Percent |Average |Percentage of uncached disk bandwidth consumed by the VM |No Dimensions |

-|VM Uncached IOPS Consumed Percentage |Yes |VM Uncached IOPS Consumed Percentage |Percent |Average |Percentage of uncached disk IOPS consumed by the VM |No Dimensions |

-|TotalRequestsPreview |No |Total Requests (Preview) |Count |Count |Number of requests |DatabaseName, CollectionName, Region, StatusCode, OperationType, Status, IsExternal |

-|TotalRequestUnits |Yes |Total Request Units |Count |Total |Request Units consumed |DatabaseName, CollectionName, Region, StatusCode, OperationType, Status, CapacityType |

-|AnalyticsConnectorTotalErrors |Yes |Analytics Connector Total Error Count |Count |Sum |The total number of errors logged by the analytics connector |ErrorType, Operation |

-|TransformationErrors |Yes |Transformation Errors |Count |Count |The number of rows, where the execution of KQL transformation led to an error, KQL transformation service limit exceeds. |InputStreamId, ErrorType |

-|TransformationErrors_Count |Yes |Transformation Errors |Count |Count |The number of rows, where the execution of KQL transformation led to an error like KQL transformation service limit exceeds. |InputStreamId, ErrorType |

-|TransformationRuntime_DurationMs |Yes |Transformation Runtime Duration |Count |Count |Total time taken in miliseconds to transform given set of records. |InputStreamId |

-<!--Gen Date: Wed Mar 01 2023 10:07:05 GMT+0200 (Israel Standard Time)-->

- - url: 'http://localhost:8081/api/v1/write'

- - name: prom-remotewrite

- image: <CONTAINER-IMAGE-VERSION>

- imagePullPolicy: Always

- ports:

- - name: rw-port

- containerPort: 8081

- livenessProbe:

- httpGet:

- path: /health

- port: rw-port

- initialDelaySeconds: 10

- timeoutSeconds: 10

- readinessProbe:

- httpGet:

- path: /ready

- port: rw-port

- initialDelaySeconds: 10

- timeoutSeconds: 10

- env:

- - name: INGESTION_URL

- value: <INGESTION_URL>

- - name: LISTENING_PORT

- value: '8081'

- - name: IDENTITY_TYPE

- value: userAssigned

- - name: AZURE_CLIENT_ID

- value: <MANAGED-IDENTITY-CLIENT-ID>

- # Optional parameter

- - name: CLUSTER

- value: <CLUSTER-NAME>

-<!--Gen Date: Wed Mar 01 2023 10:07:05 GMT+0200 (Israel Standard Time)-->

- "transformKql": "source | extend jsonContext = parse_json(AdditionalContext) | project TimeGenerated = Time, Computer, AdditionalContext = jsonContext, CounterName=tostring(jsonContext.CounterName), CounterValue=jsonContext.CounterValue",

-Instead of directly configuring the schema of the table, you can use the portal to upload sample data so that Azure Monitor can determine the schema. The sample is expected to be a JSON file that contains one or multiple log records structured in the same way they'll be sent in the body of an HTTP request of the logs ingestion API call.

-# Quickstart: Explore and analyze costs with cost analysis

-Before you can properly control and optimize your Azure costs, you need to understand where costs originated within your organization. It's also useful to know how much money your services cost, and in support of which environments and systems. Visibility into the full spectrum of costs is critical to accurately understand organizational spending patterns. You can use spending patterns to enforce cost control mechanisms, like budgets.

-In this quickstart, you use cost analysis to explore and analyze your organizational costs. You can view aggregated costs or break them down to understand where costs occur over time and identify spending trends. You can view accumulated costs over time to estimate monthly, quarterly, or even yearly cost trends against a budget. You can use budgets to get notified as cost exceeds specific thresholds.

-In this quickstart, you learn how to:

-Cost analysis supports different kinds of Azure account types. To view the full list of supported account types, see [Understand Cost Management data](understand-cost-mgt-data.md). To view cost data, you need at least read access for your Azure account.

-If you have a new subscription, you can't immediately use Cost Management features. It might take up to 48 hours before you can use all Cost Management features.

-## Sign in to Azure

-## Get started in Cost analysis

-To review your costs in cost analysis, open the scope in the Azure portal and select **Cost analysis** in the menu. For example, go to **Subscriptions**, select a subscription from the list, and then select **Cost analysis** in the menu.

-Use the **Scope** pill to switch to a different scope in cost analysis.

-The scope you select is used throughout Cost Management to provide data consolidation and control access to cost information. When you use scopes, you don't multi-select them. Instead, you select a larger scope, which others roll up to, and then filter down to the nested scopes you need. This approach is important to understand because some people may not have access to a single parent scope, which covers multiple nested scopes.

->[!VIDEO https://www.youtube.com/embed/mfxysF-kTFA]

-The initial cost analysis view includes the following areas:

-**Currently selected view**: Represents the predefined cost analysis view configuration. Each view includes date range, granularity, group by, and filter settings. The default view shows a running total of your costs for the current billing period with the Accumulated costs view, but you can select other built-in views from the menu. The view menu is between the scope pill and the date selector. For details about saved views, see [Save and share customized views](save-share-views.md).

-**Filters**: Allow you to limit the results to a subset of your total charges. Filters apply to all summarized totals and charts.

-**Cost**: Shows the total usage and purchase costs for the selected period, as they're accrued and will show on your bill. Costs are shown in your billing currency by default. If you have charges in multiple currencies, cost will automatically be converted to USD.

-**Forecast**: Shows the total forecasted costs the selected period.

-**Budget (if selected)**: Shows the current budget amount for the selected scope, if already defined.

-**Granularity**: Indicates how to show data over time. Select **Daily** or **Monthly** to view costs broken down by day or month. Select **Accumulated** to view the running total for the period. Select **None** to view the total cost for the period, with no breakdown.

-**Pivot (donut) charts**: Provide dynamic pivots, breaking down the total cost by a common set of standard properties. They show the largest to smallest costs for the current month.

-

-### Understand forecast

-Based on your recent usage, cost forecasts show a projection of your estimated costs for the selected time period. If a budget is set up in Cost analysis, you can view when forecasted spend is likely to exceed budget threshold. The forecast model can predict future costs for up to a year. Select filters to view the granular forecasted cost for your selected dimension.

-## Select a cost view

-Cost analysis has many built-in views, optimized for the most common goals:

-View | Answer questions like

- |

-Accumulated cost | How much have I spent so far this month? Will I stay within my budget?

-Daily cost | Have there been any increases in the costs per day for the last 30 days?

-Cost by service | How has my monthly usage vary over the past three invoices?

-Cost by resource | Which resources cost the most so far this month?

-Invoice details | What charges did I have on my last invoice?

-Resources (preview) | Which resources cost the most so far this month? Are there any subscription cost anomalies?

-Resource groups (preview) | Which resource groups cost the most so far this month?

-Subscriptions (preview) | Which subscriptions cost the most so far this month?

-Services (preview) | Which services cost the most so far this month?

-Reservations (preview) | How much are reservations being used? Which resources are utilizing reservations?

-The Cost by resource and Resources views are only available for subscriptions and resource groups.

-

-For more information about views, see:

-## View costs

-Cost analysis shows **accumulated** costs by default. Accumulated costs include all costs for each day plus the previous days, for a constantly growing view of your daily aggregate costs. This view is optimized to show how you're trending against a budget for the selected time range.

-Use the forecast chart view to identify potential budget breaches. When there's a potential budget breach, projected overspending is shown in red. An indicator symbol is also shown in the chart. Hovering over the symbol shows the estimated date of the budget breach.

-

-There's also the **daily** view that shows costs for each day. The daily view doesn't show a growth trend. The view is designed to show irregularities as cost spikes or dips from day to day. If you've selected a budget, the daily view also shows an estimate of your daily budget.

-Here's a daily view of recent spending with spending forecast turned on.

-

-When the forecast is disabled, you won't see projected spending for future dates. Also, when you look at costs for past time periods, cost forecast doesn't show costs.

-Generally, you can expect to see data or notifications for consumed resources within 24 to 48 hours.

-Forecasted alerts provide advanced notification that your spending trends are likely to exceed your budget. The alerts use [forecasted cost predictions](quick-acm-cost-analysis.md#understand-forecast). Alerts are generated when the forecasted cost projection exceeds the set threshold. You can configure a forecasted threshold (% of budget). When a forecasted budget threshold is met, notifications are normally sent within an hour of the evaluation.

-Azure customers can view their current usage levels in Cost Management. For more information about viewing your current Azure costs, see [View costs](../costs/quick-acm-cost-analysis.md#view-costs).

-Even though Defender for Cloud's default security initiative is based on industry best practices and standards, there are scenarios in which the built-in recommendations listed below might not completely fit your organization. It's sometimes necessary to adjust the default initiative - without compromising security - to ensure it's aligned with your organization's own policies, industry standards, regulatory standards, and benchmarks.<br><br>

-| [Multiple changes to identity recommendations](#multiple-changes-to-identity-recommendations) | August 2023 |

-**Estimated date for change: August 2023**

-description: This article provides a reference of all alerts that are generated by Microsoft Defender for IoT network sensors, inclduing a list of all alert types and descriptions.

-| **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. <br><br>Triggered by both OT and Enterprise IoT network sensors. | Critical | Suspicion of Malicious Activity | **Tactics:** <br> - Initial Access <br> - Command And Control <br><br> **Techniques:** <br> - T0883: Internet Accessible Device <br> - T0884: Connection Proxy |

-| **Malicious Domain Name Request** | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. <br><br>Triggered by both OT and Enterprise IoT network sensors. | Critical | Suspicion of Malicious Activity | **Tactics:** <br> - Initial Access <br> - Command And Control <br><br> **Techniques:** <br> - T0883: Internet Accessible Device <br> - T0884: Connection Proxy |

-| **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. | Critical | Suspicion of Malicious Activity | **Tactics:** <br> - Lateral Movement <br><br> **Techniques:** <br> - T0867: Lateral Tool Transfer |

-| **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. <br><br> Threshold: 25 name queries in 1 minute | Critical | Suspicion of Malicious Activity | **Tactics:** <br> - Command And Control <br><br> **Techniques:** <br> - T0884: Connection Proxy |

-| **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. | Critical | Suspicion of Malicious Activity | **Tactics:** <br> - Lateral Movement <br> - Initial Access <br><br> **Techniques:** <br> - T0866: Exploitation of Remote Services |

-| **Suspicion of Remote Windows Service Management [*](#ot-alerts-turned-off-by-default)** | Suspicious network activity was detected. This activity may be associated with an attack exploiting a method used by known malware. | Critical | Suspicion of Malicious Activity | **Tactics:** <br> - Initial Access <br><br> **Techniques:** <br> - T0822: NetworkExternal Remote Services |

-| **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. | Critical | Suspicion of Malicious Activity | **Tactics:** <br> - Evasion <br> - Inhibit Response Function <br><br> **Techniques:** <br> - T0851: Rootkit |

-A *transient* device type indicates a device that was detected for only a short time. We recommend investigating these devices carefully to understand their impact on your network.

-## Allow internet connections on an OT network

-Decrease the number of unauthorized internet alerts by creating an allowlist of domain names on your OT sensor. When a DNS allowlist is configured, the sensor checks each unauthorized internet connectivity attempt against the list before triggering an alert. If the domain's FQDN is included in the allowlist, the sensor doesnΓÇÖt trigger the alert and allows the traffic automatically.

-All OT sensor users can view a currently configured list of domains in a [data mining report](how-to-create-data-mining-queries.md), including the FQDNs, resolved IP addresses, and the last resolution time.

-**To define a DNS allowlist:**

-1. Sign into your OT sensor as the *support* user and select the **Support** page.

-1. In the search box, search for **DNS** and then locate the engine with the **Internet Domain Allowlist** description.

-1. Select **Edit** :::image type="icon" source="media/how-to-generate-reports/manage-icon.png" border="false"::: for the **Internet Domain Allowlist** row. For example:

- :::image type="content" source="media/how-to-accelerate-alert-incident-response/dns-edit-configuration.png" alt-text="Screenshot of how to edit configurations for DNS in the sensor console." lightbox="media/how-to-accelerate-alert-incident-response/dns-edit-configuration.png":::

-1. In the **Edit configuration** pane > **Fqdn allowlist** field, enter one or more domain names. Separate multiple domain names with commas. Your sensor won't generate alerts for unauthorized internet connectivity attempts on the configured domains.

-1. Select **Submit** to save your changes.

-**To view the current allowlist in a data mining report:**

-When selecting a category in your [custom data mining report](how-to-create-data-mining-queries.md#create-an-ot-sensor-custom-data-mining-report), make sure to select **Internet Domain Allowlist** under the **DNS** category.

-For example:

-The generated data mining report shows a list of the allowed domains and each IP address thatΓÇÖs being resolved for those domains. The report also includes the TTL, in seconds, during which those IP addresses won't trigger an internet connectivity alert. For example:

-|**Cloud-connected and locally-managed sensors** | Cloud-connected and locally-managed sensors remain activated for as long as your Azure subscription with your Defender for IoT plan is active. <br><br>If you're [updating an OT sensor from a legacy version](update-ot-software.md#update-legacy-ot-sensor-software), you'll need to re-activate your updated sensor. |

-After activating a sensor, cloud-connected and locally-managed sensors remain activated for as long as your Azure subscription with your Defender for IoT plan is active.

-If you're updating an OT sensor from a legacy version, you'll need to re-activate your updated sensor. For more information, see [Update legacy OT sensor software](update-ot-software.md#update-legacy-ot-sensor-software).

- | **Choose category** | Select the categories to include in your report. <br><br> For example, select **Internet Domain Allowlist** under **DNS** to create a report of the allowed internet domains and their resolved IP addresses. |

- Select **Use CRL (Certificate Revocation List) to check certificate status** to validate the certificate against a [CRL server](#verify-crl-server-access). The certificate is checked once during the import process.

- :::image type="content" source="media/how-to-deploy-certificates/recommended-ssl.png" alt-text="Screenshot of importing a trusted CA certificate." lightbox="media/how-to-deploy-certificates/recommended-ssl.png":::

-

-1. In the **Validation for on-premises management console certificates** area, select **Required** if SSL/TLS certificate validation is required. Otherwise, select **None**.

-1. Select a device in the grid, and then select **Edit** in the toolbar at the top of the page.

-1. In the **Edit** pane on the right, modify the device fields as needed, and then select **Save** when you're done.

-You can also open the edit pane from the device details page:

-**To delete one or more devices**:

-1. In the **Device inventory** page, select the device or devices you want to delete, and then select **Delete** :::image type="icon" source="media/how-to-manage-device-inventory-on-the-cloud/delete-device.png" border="false"::: in the toolbar at the top of the page.

-1. At the prompt, select **Confirm** to confirm that you want to delete the device from Defender for IoT.

-You'll need to upload a new activation file to your senor if you want to switch sensor management modes, such as moving from a locally-managed sensor to a cloud-connected sensor. Uploading a new activation file to your sensor includes deleting your sensor from the Azure portal and onboarding it again.

- |**Edit properties** | Opens the edit pane where you can edit device properties, such as authorization, name, description, OS platform, device type, Purdue level and if it is a scanner or programming device. |

- |**View properties** | Opens the device's details page. |

- | **Delete** |Deletes the device from the inventory. |

-> [!NOTE]

-> Selected notifications are automatically resolved if they aren't dismissed or otherwise handled within 14 days. For more information, see the action indicated in the **Auto-resolve** column in the table [below](#device-notification-responses).

->

-| Type | Description | Available responses | Auto-resolve|

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

-| **New IP detected** | A new IP address is associated with the device. This may occur in the following scenarios: <br><br>- A new or additional IP address was associated with a device already detected, with an existing MAC address.<br><br> - A new IP address was detected for a device that's using a NetBIOS name. <br /><br /> - An IP address was detected as the management interface for a device associated with a MAC address. <br /><br /> - A new IP address was detected for a device that's using a virtual IP address. | - **Set Additional IP to Device**: Merge the devices <br />- **Replace Existing IP**: Replaces any existing IP address with the new address <br /> - **Dismiss**: Remove the notification. |**Dismiss** |

-| **No subnets configured** | No subnets are currently configured in your network. <br /><br /> We recommend configuring subnets for the ability to differentiate between OT and IT devices on the map. | - **Open Subnets Configuration** and [configure subnets](how-to-control-what-traffic-is-monitored.md#configure-subnets). <br />- **Dismiss**: Remove the notification. |**Dismiss** |

-| **Operating system changes** | One or more new operating systems have been associated with the device. | - Select the name of the new OS that you want to associate with the device.<br /> - **Dismiss**: Remove the notification. |No automatic handling|

-| **New subnets** | New subnets were discovered. |- **Learn**: Automatically add the subnet.<br />- **Open Subnet Configuration**: Add all missing subnet information.<br />- **Dismiss**<br />Remove the notification. |**Dismiss** |

-| **Device type changes** | A new device type has been associated with the device. | - **Set as {…}**: Associate the new type with the device.<br />- **Dismiss**: Remove the notification. |No automatic handling|

-| **OT network sensor** | 90 days from the date of the **Last activity** value. <br><br> For more information, see [Manage your OT device inventory from a sensor console](how-to-investigate-sensor-detections-in-a-device-inventory.md). |

-| **On-premises management console** | 90 days from the date of the **Last activity** value. <br><br> For more information, see [Manage your OT device inventory from an on-premises management console](how-to-investigate-all-enterprise-sensor-detections-in-a-device-inventory.md). |

- echo "$(terraform output resource_group_name)"

- echo "$(terraform output lab_name)"

- az lab vm list --resource-group <resource_group_name> --lab-name <lab_name>

-This article will walk you through how to create a lab, add students to that lab and verify that the lab has been created.

-Call the above API with the body similar to the one below. Include your details for what the display name will be and how much budget you will allocate for this lab.

-## Add students to the lab

-Now that the lab has been successfully created, you can begin to add students to the lab.

-Call the endpoint below and make sure to replace the sections that are surrounded by <>.

-```json

-PUT https://management.azure.com/providers/Microsoft.Billing/billingAccounts/<BillingAccountID>/billingProfiles/<BillingProfileID>/invoiceSections/<InvoiceSectionID>/providers/Microsoft.Education/labs/default/students/<StudentID>?api-version=2021-12-01-preview

-```

-Call the above API with a body similar to the one below. Change the body to include details of the student you want to add to the lab.

-```json

-{

- "properties": {

- "firstName": "string",

- "lastName": "string",

- "email": "string",

- "role": "Student",

- "budget": {

- "currency": "string",

- "value": 0

- },

- "expirationDate": "2021-12-21T23:01:41.943Z",

- "subscriptionAlias": "string",

- "subscriptionInviteLastSentDate": "string"

- }

-}

-```

-The API response returns details of the newly added student.

-```json

-{

- "id": "string",

- "name": "string",

- "type": "string",

- "systemData": {

- "createdBy": "string",

- "createdByType": "User",

- "createdAt": "2021-12-21T23:02:20.163Z",

- "lastModifiedBy": "string",

- "lastModifiedByType": "User",

- "lastModifiedAt": "2021-12-21T23:02:20.163Z"

- },

- "properties": {

- "firstName": "string",

- "lastName": "string",

- "email": "string",

- "role": "Student",

- "budget": {

- "currency": "string",

- "value": 0

- },

- "subscriptionId": "string",

- "expirationDate": "2021-12-21T23:02:20.163Z",

- "status": "Active",

- "effectiveDate": "2021-12-21T23:02:20.163Z",

- "subscriptionAlias": "string",

- "subscriptionInviteLastSentDate": "string"

- }

-}

-```

-Now that the lab has been created and a student has been added to the lab, let's get the details for the lab. Getting the lab details will provide you with meta data like when the lab was created and how much budget it has. It will not include information about students in the lab.

-The API response will include information about the lab and budget information (if the include budget flag is set to true)

-## Check the details of the students in a lab

-Calling this API will allow us to see all of the students that are in the specified lab.

-```json

-GET https://management.azure.com/providers/Microsoft.Billing/billingAccounts/<BillingAccountID/billingProfiles/<BillingProfileID>/invoiceSections/<InvoiceSectionID>/providers/Microsoft.Education/labs/default/students?includeDeleted=true&api-version=2021-12-01-preview

-```

-The API response will include information about the students in the lab and will even show student that have been deleted from the lab (if the includeDeleted flag is set to true)

-```json

-{

- "value": [

- {

- "id": "string",

- "name": "string",

- "type": "string",

- "systemData": {

- "createdBy": "string",

- "createdByType": "User",

- "createdAt": "2021-12-21T23:15:45.430Z",

- "lastModifiedBy": "string",

- "lastModifiedByType": "User",

- "lastModifiedAt": "2021-12-21T23:15:45.430Z"

- },

- "properties": {

- "firstName": "string",

- "lastName": "string",

- "email": "string",

- "role": "Student",

- "budget": {

- "currency": "string",

- "value": 0

- },

- "subscriptionId": "string",

- "expirationDate": "2021-12-21T23:15:45.430Z",

- "status": "Active",

- "effectiveDate": "2021-12-21T23:15:45.430Z",

- "subscriptionAlias": "string",

- "subscriptionInviteLastSentDate": "string"

- }

- }

- ],

- "nextLink": "string"

-}

-```

-An Event Grid topic provides an endpoint where the source sends events. The publisher creates the Event Grid topic, and decides whether an event source needs one topic or more than one topic. A topic is used for a collection of related events. To respond to certain types of events, subscribers decide which topics to subscribe to.

-**Custom topics** are application and third-party topics. When you create or are assigned access to a custom topic, you see that custom topic in your subscription.

-Azure Front Door's certificates are issued by our partner certification authority, DigiCert.

-To implement infrastructure as code for your Azure solutions, use Azure Resource Manager templates (ARM templates). The template is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for your project. The template uses declarative syntax, which lets you state what you intend to deploy without having to write the sequence of programming commands to create it. In the template, you specify the resources to deploy and the properties for those resources.

-> [!div class="checklist"]

-> - Open an ARM template in the Azure portal.

-> - Configure the ARM template for your deployment.

-> - Deploy the ARM template.

- - **Region** - The Azure region of the resource group that's used for the deployment. Region auto-fills by using the resource group region.

-Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. In a Bicep file, you define the infrastructure you want to deploy to Azure, and then use that file throughout the development lifecycle to repeatedly deploy your infrastructure. Your resources are deployed in a consistent manner.

-Bicep provides concise syntax, reliable type safety, and support for code reuse. Bicep offers a first-class authoring experience for your infrastructure-as-code solutions in Azure.

-In this quickstart, you'll learn how to:

-> [!div class="checklist"]

-> - Use Azure PowerShell or the Azure CLI to deploy an instance of the MedTech service using a Bicep file.

-> [!div class="checklist"]

-> - Azure Resource Manager template (ARM template) including an Azure Iot Hub using the **Deploy to Azure** button.

-> - ARM template using the **Deploy to Azure** button.

-> - ARM template using Azure PowerShell or the Azure CLI.

-> - Manually in the Azure portal.

-To learn more about the MedTech service, see

-In this quickstart, you'll learn how to:

-> [!div class="checklist"]

-> - Use Azure PowerShell or the Azure CLI to deploy an instance of the MedTech service using an Azure Resource Manager template (ARM template).

-description: This article describes how to get started with the MedTech service in Azure Health Data Services.

-# Get started with the MedTech service in the Azure Health Data Services

-This article will show you how to get started with the Azure MedTech service in the [Azure Health Data Services](../healthcare-apis-overview.md). There are six steps you need to follow to be able to deploy and process MedTech service to ingest data from a device using Azure Event Hubs service, persist the data to Azure FHIR service as Observation resources, and link FHIR service Observations to user and device resources. This article provides an architecture overview to help you follow the six steps of the implementation process.

-## Architecture overview of the MedTech service

-The following diagram outlines the basic architectural path that enables the MedTech service to receive data from a device and send it to the FHIR service. This diagram shows how the six-step implementation process is divided into three key development stages: deployment, post-deployment, and data processing.

-### Configuring device mappings

-You must configure the MedTech service to map it to the device you want to receive data from. Each device has unique settings that the MedTech service must use. For more information on how to use device mappings, see [How to use device mappings](how-to-configure-device-mappings.md).

-### Configuring destination mappings

-Once your device's data is properly mapped to your device's data format, you must then map it to an Observation in the FHIR service. For an overview of FHIR destination mappings, see [How to use the FHIR destination mappings](how-to-configure-fhir-mappings.md).

-The family of the host OS must always match the family of the guest OS used inside a module's container.

-IoT Edge for Linux on Windows uses IoT Edge in a Linux virtual machine running on a Windows host. In this way, you can run Linux modules on a Windows device.

-Flexible server provides features that protect data and mitigates downtime for your mission critical databases in the event of planned and unplanned downtime events. Built on top of the Azure infrastructure that already offers robust resiliency and availability, flexible server has business continuity features that provide another fault-protection, address recovery time requirements, and reduce data loss exposure. As you architect your applications, you should consider the downtime tolerance - which is the recovery time objective (RTO) and data loss exposure - which is the recovery point objective (RPO). For example, your business-critical database requires stricter uptime requirements compared to a test database.

- * **Azure Portal Banner**

- :::image type="content" source="./media/business-continuity/notification-service-issue-example.png" alt-text=" Screenshot showing notifications in Azure Portal.":::

-| **Scenario** | **Recovery process** <br> [Servers configured without zone-redundant HA] | **Recovery process** <br> [Servers configured with Zone-redundant HA] |

-The **Max Physical Replication Lag** metric shows the lag in bytes between the primary and the most-lagging replica. This metric is applicable and available on the primary server only, and will be available only if at least one of the read replicas is connected to the primary. The lag information is present also when the replica is in the process of catching up with the primary, during replica creation, or when replication becomes inactive. The lag information will not be available in case replication switches from using streaming replication to the archive recovery mode using archived files from primary.

-This article explains the Azure Database for PostgreSQL connectivity architecture as well as how the traffic is directed to your Azure Database for PostgreSQL database instance from clients both within and outside Azure.

-As client connects to the database, the connection string to the server resolves to the gateway IP address. The gateway listens on the IP address on port 5432. Inside the database cluster, traffic is forwarded to appropriate Azure Database for PostgreSQL. Therefore, in order to connect to your server, such as from corporate networks, it is necessary to open up the **client-side firewall to allow outbound traffic to be able to reach our gateways**. Below you can find a complete list of the IP addresses used by our gateways per region.

-The gateway service is hosted on group of stateless compute nodes sitting behind an IP address, which your client would reach first when trying to connect to an Azure Database for PostgreSQL server.

-As part of ongoing service maintenance, we'll periodically refresh compute hardware hosting the gateways to ensure we provide the most secure and performant connectivity experience. When the gateway hardware is refreshed, a new ring of the compute nodes is built out first. This new ring serves the traffic for all the newly created Azure Database for PostgreSQL servers and it will have a different IP address from older gateway rings in the same region to differentiate the traffic. The older gateway hardware continues serving existing servers but are planned for decommissioning in future. Before decommissioning a gateway hardware, customers running their servers and connecting to older gateway rings will be notified via email and in the Azure portal, three months in advance before decommissioning. The decommissioning of gateways can impact the connectivity to your servers if

-* You do not update the newer gateway IP addresses in the client-side firewall to allow outbound traffic to be able to reach our new gateway rings.

-* **Gateway IP addresses:** This column lists the current IP addresses of the gateways hosted on the latest generation of hardware. If you are provisioning a new server, we recommend that you open the client-side firewall to allow outbound traffic for the IP addresses listed in this column.

-* **Gateway IP addresses (decommissioning):** This column lists the IP addresses of the gateways hosted on an older generation of hardware that is being decommissioned right now. If you are provisioning a new server, you can ignore these IP addresses. If you have an existing server, continue to retain the outbound rule for the firewall for these IP addresses as we have not decommissioned it yet. If you drop the firewall rules for these IP addresses, you may get connectivity errors. Instead, you are expected to proactively add the new IP addresses listed in Gateway IP addresses column to the outbound firewall rule as soon as you receive the notification for decommissioning. This will ensure when your server is migrated to latest gateway hardware, there is no interruptions in connectivity to your server.

-* **Gateway IP addresses (decommissioned):** This column lists the IP addresses of the gateway rings, which are decommissioned and are no longer in operations. You can safely remove these IP addresses from your outbound firewall rule.

-| **Region name** | **Gateway IP addresses** |**Gateway IP addresses (decommissioning)** | **Gateway IP addresses (decommissioned)** |

-|:-|:-|:-|:|

-| Australia Central| 20.36.105.0 | | |

-| Australia Central2 | 20.36.113.0 | | |

-| Australia East | 13.75.149.87, 40.79.161.1 | | |

-| Australia South East |13.77.48.10, 13.77.49.32, 13.73.109.251 | | |

-| Brazil South |191.233.201.8, 191.233.200.16 | | 104.41.11.5|

-| Canada Central |40.85.224.249, 52.228.35.221 | | |

-| Canada East | 40.86.226.166, 52.242.30.154 | | |

-| Central US | 23.99.160.139, 52.182.136.37, 52.182.136.38 | 13.67.215.62 | |

-| China East | 139.219.130.35 | | |

-| China East 2 | 40.73.82.1, 52.130.120.89 |

-| China East 3 | 52.131.155.192 |

-| China North | 139.219.15.17 | | |

-| China North 2 | 40.73.50.0 | | |

-| China North 3 | 52.131.27.192 | | |

-| East Asia | 13.75.33.20, 52.175.33.150, 13.75.33.20, 13.75.33.21 | | |

-| East US |40.71.8.203, 40.71.83.113 |40.121.158.30|191.238.6.43 |

-| East US 2 | 40.70.144.38, 52.167.105.38 | 52.177.185.181 | |

-| France Central | 40.79.137.0, 40.79.129.1 | | |

-| France South | 40.79.177.0 | | |

-| Germany Central | 51.4.144.100 | | |

-| Germany North | 51.116.56.0 | |

-| Germany North East | 51.5.144.179 | | |

-| Germany West Central | 51.116.152.0 | |

-| India Central | 104.211.96.159 | | |

-| India South | 104.211.224.146 | | |

-| India West | 104.211.160.80 | | |

-| Japan East | 40.79.192.23, 40.79.184.8 | 13.78.61.196 | |

-| Japan West | 104.214.148.156, 40.74.96.6, 40.74.96.7 | 104.214.148.156 | |

-| Korea Central | 52.231.17.13 | 52.231.32.42 | |

-| Korea South | 52.231.145.3 | 52.231.151.97 | |

-| North Central US | 52.162.104.35, 52.162.104.36 | 23.96.178.199 | |

-| North Europe | 52.138.224.6, 52.138.224.7 | 40.113.93.91 |191.235.193.75 |

-| South Africa North | 102.133.152.0 | | |

-| South Africa West | 102.133.24.0 | | |

-| South Central US |104.214.16.39, 20.45.120.0 |13.66.62.124 |23.98.162.75 |

-| South East Asia | 40.78.233.2, 23.98.80.12 | 104.43.15.0 | |

-| Switzerland North | 51.107.56.0 ||

-| Switzerland West | 51.107.152.0| ||

-| UAE Central | 20.37.72.64 | | |

-| UAE North | 65.52.248.0 | | |

-| UK South | 51.140.184.11, 51.140.144.32, 51.105.64.0 | | |

-| UK West | 51.141.8.11 | | |

-| West Central US | 13.78.145.25, 52.161.100.158 | | |

-| West Europe |13.69.105.208, 104.40.169.187 | 40.68.37.158 | 191.237.232.75 |

-| West US |13.86.216.212, 13.86.217.212 |104.42.238.205 | 23.99.34.75|

-| West US 2 | 13.66.226.202, 13.66.136.192,13.66.136.195 | | |

-| West US 3 | 20.150.184.2 | | |

-This is a DNS change only which makes it transparent to clients. While the IP address for FQDN is changed in the DNS server, the local DNS cache will be refreshed within 5 minutes, and it is automatically done by the operating systems. After the local DNS refresh, all the new connections will connect to the new IP address, all existing connections will remain connected to the old IP address with no interruption until the old IP addresses are fully decommissioned. The old IP address will roughly take three to four weeks before getting decommissioned; therefore, it should have no effect on the client applications.

-Only Gateway nodes will be decommissioned. When users connect to their servers, the first stop of the connection is to gateway node, before connection is forwarded to server. We are decommissioning old gateway rings (not tenant rings where the server is running) refer to the [connectivity architecture](#connectivity-architecture) for more clarification.

-Ping your server's FQDN, for example ``ping xxx.postgres.database.azure.com``. If the returned IP address is one of the IPs listed under Gateway IP addresses (decommissioning) in the document above, it means your connection is going through the old gateway. Contrarily, if the returned Ip address is one of the IPs listed under Gateway IP addresses, it means your connection is going through the new gateway.

-You will receive an email to inform you when we'll start the maintenance work. The maintenance can take up to one month depending on the number of servers we need to migrate in al regions. Please prepare your client to connect to the database server using the FQDN or using the new IP address from the table above.

-This maintenance is just a DNS change, so it is transparent to the client. Once the DNS cache is refreshed in the client (automatically done by operation system), all the new connections will connect to the new IP address and all the existing connections will still be working fine until the old IP address gets fully decommissioned, which is usually several weeks later. And the retry logic is not required for this case, but it is good to see the application have retry logic configured. Please either use FQDN to connect to the database server or enable list the new 'Gateway IP addresses' in your application connection string.

-## Mapping of popular DMVs/DMFs

-* Blog: [Microsoft Purview DevOps policies enter General Availability](https://techcommunity.microsoft.com/t5/security-compliance-and-identity/microsoft-purview-devops-policies-enter-ga-simplify-access/ba-p/3674057)

-* Blog: [Inexpensive solution for managing access to SQL health, performance and security information](https://techcommunity.microsoft.com/t5/security-compliance-and-identity/inexpensive-solution-for-managing-access-to-sql-health/ba-p/3750512)

-* Blog: [Enable IT personnel to monitor SQL health and performance while reducing the insider risk](https://techcommunity.microsoft.com/t5/security-compliance-and-identity/enable-it-personnel-to-monitor-sql-health-and-performance-while/ba-p/3740363)

-* Video: [DevOps policies quick overview](https://aka.ms/Microsoft-Purview-DevOps-Policies-Video)

-* Video: [DevOps policies deep dive](https://youtu.be/UvClpdIb-6g)

-* Doc: [Microsoft Purview DevOps policies on Azure Arc-enabled SQL Server](./how-to-policies-devops-arc-sql-server.md)

-* Doc: [Microsoft Purview DevOps policies on Azure SQL DB](./how-to-policies-devops-azure-sql-db.md)

-* Doc: [Microsoft Purview DevOps policies on resource groups and subscriptions](./how-to-policies-devops-resource-group.md)

-* Blog: [New granular permissions for SQL Server 2022 and Azure SQL to help PoLP](https://techcommunity.microsoft.com/t5/sql-server-blog/new-granular-permissions-for-sql-server-2022-and-azure-sql-to/ba-p/3607507)

-After creating the policy, any of the Azure AD users in the Subject should now be able to connect to the data sources in the scope of the policy. To test, use SSMS or any SQL client and try to query some DMVs/DMFs. We list here some examples. For more, you can consult the [Microsoft Purview DevOps policies concept guide](/azure/purview/concept-policies-devops.md#mapping-of-popular-dmvsdmfs)

-* Doc: [Microsoft Purview DevOps policies on entire resource groups or subscriptions](./how-to-policies-devops-resource-group.md)

-|[Install Service Fabric Runtime for Windows](https://download.microsoft.com/download/b/8/a/b8a2fb98-0ec1-41e5-be98-9d8b5abf7856/MicrosoftServiceFabric.9.1.1436.9590.exe) | 9.1.1436 |

-|[Install Service Fabric SDK](https://download.microsoft.com/download/b/8/a/b8a2fb98-0ec1-41e5-be98-9d8b5abf7856/MicrosoftServiceFabricSDK.6.1.1436.msi) | 6.1.1436 |

-|Required infrastructure|Minimum share size 1 GiB|Minimum capacity pool 4 TiB, min volume size 100 GiB|Two VMs on Azure IaaS (+ Cloud Witness) or at least three VMs without and costs for disks|

-Ultra disks don't have an extra charge for each VM that they're mounted to. They're billed on the total IOPS and MBps that the disk is configured for. Normally, an ultra disk has two performance throttles that determine its total IOPS/MBps. However, when configured as a shared ultra disk, two more performance throttles are exposed, for a total of four. These two additional throttles allow for increased performance at an extra expense and each meter has a default value, which raises the performance and cost of the disk.

-The four performance throttles a shared ultra disk has are diskMBpsReadWrite, diskIOPSReadOnly and diskMBpsReadOnly. Each performance throttle can be configured to change the performance of your disk. The performance for shared ultra disk is calculated in the following ways: total provisioned IOPS (diskIOPSReadWrite + diskIOPSReadOnly) and for total provisioned throughput MBps (diskMBpsReadWrite + diskMBpsReadOnly).

-|DiskMBpsReadWrite (Read/write disk throughput) |The total throughput (MB/s) allowed across all VMs mounting the shared disk with write access. |

-|DiskMBpsReadOnly* (Read-only disk throughput) |The total throughput (MB/s) allowed across all VMs mounting the shared disk as `ReadOnly`. |

- - The minium throughput (MB/s) of this attribute is determined by your IOPS, the formula is 4 KiB per second per IOPS. So if you had 101 IOPS, the minium MB/s you can set is 1.

- - The minimum throughput (MB/s) for this attribute is 1. For DiskMBpsReadOnly, the baseline doesn't increase with IOPS.

-Both shared Ultra Disks and shared Premium SSD v2 managed disks are priced based on provisioned capacity, total provisioned IOPS (diskIOPSReadWrite + diskIOPSReadOnly) and total provisioned Throughput MBps (diskMBpsReadWrite + diskMBpsReadOnly). There's no extra charge for each additional VM mount. For example, a shared Ultra Disk with the following configuration (diskSizeGB: 1024, DiskIOPSReadWrite: 10000, DiskMBpsReadWrite: 600, DiskIOPSReadOnly: 100, DiskMBpsReadOnly: 1) is charged with 1024 GiB, 10100 IOPS, and 601 MBps regardless of whether it is mounted to two VMs or five VMs.

-| **Max disk size** | 65,536 gibibyte (GiB) | 65,536 GiB |32,767 GiB | 32,767 GiB | 32,767 GiB |

-|Disk Size (GiB) |IOPS Cap |Throughput Cap (MBps) |

-The throughput limit of a single ultra disk is 256-KiB/s for each provisioned IOPS, up to a maximum of 4000 MBps per disk (where MBps = 10^6 Bytes per second). The minimum guaranteed throughput per disk is 4KiB/s for each provisioned IOPS, with an overall baseline minimum of 1 MBps.