+# Quickstart: Sign in users and call Microsoft Graph in a Windows desktop app

+> ## Quickstart: Acquire a token and call the Microsoft Graph API from a Windows desktop application

+>

+- [Outlook](/mem/intune/apps/app-configuration-policies-outlook) (in Public Preview)

+> [!IMPORTANT]

+Because mobile devices running iOS or Android were designed for single users, most applications optimize their experience for use by a single user. Part of this optimized experience means enabling single sign-on (SSO) across applications and keeping users signed in on their device. When a user removes their account from an application, the app typically doesn't consider it a security-related event. Many apps even keep a user's credentials around for quick sign-in. You may even have experienced this yourself when you've deleted an application from your mobile device and then reinstalled it, only to discover you're still signed in.

+To allow an organization's employees to use its apps across a pool of devices shared by those employees, developers need to enable the opposite experience. Employees should be able to pick a device from the pool and perform a single gesture to "make it theirs" during their shift. At the end of their shift, they should be able to perform another gesture to sign out globally on the device, with all their personal and company information removed so they can return it to the device pool. Furthermore, if an employee forgets to sign out, the device should be automatically signed out at the end of their shift and/or after a period of inactivity.

+Azure AD enables these scenarios with a feature called **shared device mode**.

+As mentioned, shared device mode is a feature of Azure AD that enables you to:

+- Build applications that support frontline workers

+- Deploy devices to frontline workers with apps that support shared device mode.

+You can support frontline workers in your applications by using the Microsoft Authentication Library (MSAL) and [Microsoft Authenticator app](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc) to enable a device state called _shared device mode_. When a device is in shared device mode, Microsoft provides your application with information to allow it to modify its behavior based on the state of the user on the device, protecting user data.

+- **Sign in a user device-wide** through any supported application.

+- **Sign out a user device-wide** through any supported application.

+- **Query the state of the device** to determine if your application is on a device that's in shared device mode.

+- **Query the device state of the user** on the device to determine if anything has changed since the last time your application was used.

+Your users depend on you to ensure their data isn't leaked to another user. Share Device Mode provides helpful signals to indicate to your application that a change you should manage has occurred. Your application is responsible for checking the state of the user on the device every time the app is used, clearing the previous user's data. This includes if it's reloaded from the background in multi-tasking. On a user change, you should ensure both the previous user's data is cleared and that any cached data being displayed in your application is removed.

+An organization's device administrators are able to deploy their devices and your applications to their stores and workplaces through a mobile device management (MDM) solution like Microsoft Intune. Part of the provisioning process is marking the device as a _Shared Device_. Administrators configure shared device mode by deploying the [Microsoft Authenticator app](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc) and setting shared device mode through configuration parameters. After performing these steps, all applications that support shared device mode will use the Microsoft Authenticator application to manage its user state and provide security features for the device and organization.

+When setting up App protection policies for shared devices, we recommend using [level 2 enterprise enhanced data protection](/mem/intune/apps/app-protection-framework#level-2-enterprise-enhanced-data-protection). With level 2 data protection, you can restrict data transfer scenarios that may cause data to move to parts of the device that aren't cleared with shared device mode.

+We support iOS and Android platforms for shared device mode. For more information, see:

+- [Supporting shared device mode for iOS](msal-ios-shared-devices.md)

+- [Supporting shared device mode for Android](msal-android-shared-devices.md)

+# Governing Azure Active Directory service accounts

+There are three types of service accounts in Azure Active Directory (Azure AD): managed identities, service principals, and user accounts employed as service accounts. When you create service accounts for automated use, they're granted permissions to access resources in Azure and Azure AD. Resources can include Microsoft 365 services, software as a service (SaaS) applications, custom applications, databases, HR systems, and so on. Governing Azure AD service account is managing creation, permissions, and lifecycle to ensure security and continuity.

+Learn more:

+* [Securing managed identities](service-accounts-managed-identities.md)

+* [Securing service principals](service-accounts-principal.md)

+> [!NOTE]

+> We do not recommend user accounts as service accounts because they are less secure. This includes on-premises service accounts synced to Azure AD, because they aren't converted to service principals. Instead, we recommend managed identities, or service principals, and the use of Conditional Access.

+[What is Conditional Access?](../conditional-access/overview.md)

+Before creating a service account, or registering an application, document the service account key information. Use the information to monitor and govern the account. We recommend collecting the following data and tracking it in your centralized Configuration Management Database (CMDB).

+| Owner| User or group accountable for managing and monitoring the service account| Grant the owner permissions to monitor the account and implement a way to mitigate issues. Issue mitigation is done by the owner, or by request to an IT team. |

+| Purpose| How the account is used| Map the service account to a service, application, or script. Avoid creating multi-use service accounts. |

+| Permissions (Scopes)| Anticipated set of permissions| Document the resources it accesses and permissions for those resources |

+| CMDB Link| Link to the accessed resources, and scripts in which the service account is used| Document the resource and script owners to communicate the effects of change |

+| Risk assessment| Risk and business effect, if the account is compromised|Use the information to narrow the scope of permissions and determine access to information |

+| Period for review| The cadence of service account reviews, by the owner| Review communications and reviews. Document what happens if a review is performed after the scheduled review period. |

+| Lifetime| Anticipated maximum account lifetime| Use this measurement to schedule communications to the owner, disable, and then delete the accounts. Set an expiration date for credentials that prevents them from rolling over automatically. |

+| Name| Standardized account name| Create a naming convention for service accounts to search, sort, and filter them |

+## Principle of least privileges

+Grant the service account permissions needed to perform tasks, and no more. If a service account needs high-level permissions, for example a Global Administrator, evaluate why and try to reduce permissions.

+### Permissions

+* Don't assign built-in roles to service accounts

+ * Instead, use the [OAuth2 permission grant model for Microsoft Graph](/graph/api/resources/oauth2permissiongrant)

+* The service principal is assigned a privileged role

+ * [Create and assign a custom role in Azure Active Directory](../roles/custom-create.md)

+* Don't include service accounts as members of any groups with elevated permissions

+* [Use PowerShell to enumerate members of privileged roles](/powershell/module/azuread/get-azureaddirectoryrolemember):

+

+>`Get-AzureADDirectoryRoleMember`, and filter for objectType "Service Principal", or use</br>

+>`Get-AzureADServicePrincipal | % { Get-AzureADServiceAppRoleAssignment -ObjectId $_ }`

+* [Use OAuth 2.0 scopes](../develop/v2-permissions-and-consent.md) to limit the functionality a service account can access on a resource

+* Service principals and managed identities can use OAuth 2.0 scopes in a delegated context impersonating a signed-on user, or as service account in the application context. In the application context, no one is signed in.

+* Confirm the scopes service accounts request for resources

+ * If an account requests Files.ReadWrite.All, evaluate if it needs File.Read.All

+ * [Overview of Microsoft Graph permissions](/graph/permissions-reference)

+* Ensure you trust the application developer, or API, with the requested access

+### Duration

+* Limit service account credentials (client secret, certificate) to an anticipated usage period

+* Schedule periodic reviews of service account usage and purpose

+ * Ensure reviews occur prior to account expiration

+After you understand the purpose, scope, and permissions, create your service account, use the instructions in the following articles.

+* [How to use managed identities for App Service and Azure Functions](../../app-service/overview-managed-identity.md?tabs=dotnet)

+* [Create an Azure Active Directory application and service principal that can access resources](../develop/howto-create-service-principal-portal.md)

+Use a managed identity when possible. If you can't use a managed identity, use a service principal. If you can't use a service principal, then use an Azure AD user account.

+A service account lifecycle starts with planning, and ends with permanent deletion. The following sections cover how you monitor, review permissions, determine continued account usage, and ultimately deprovision the account.

+Monitor your service accounts to ensure usage patterns are correct, and that the service account is used.

+#### Collect and monitor service account sign-ins

+Use one of the following monitoring methods:

+* Azure AD Sign-In Logs in the Azure AD portal

+* Export the Azure AD Sign-In Logs to

+ * [Azure Storage](../../storage/index.yml)

+ * [Azure Event Hubs](../../event-hubs/index.yml), or

+ * [Azure Monitor Logs overview](../../azure-monitor/logs/data-platform-logs.md)

+Use the following screenshot to see service principal sign-ins.

+

+#### Sign-in log details

+Look for the following details in sign-in logs.

+* Service accounts not signed in to the tenant

+* Changes in sign-in service account patterns

+We recommend you export Azure AD sign-in logs, and then import them into a security information and event management (SIEM) tool, such as Microsoft Sentinel. Use the SIEM tool to build alerts and dashboards.

+Regularly review service account permissions and accessed scopes to see if they can be reduced or eliminated.

+* Use [PowerShell](/powershell/module/azuread/get-azureadserviceprincipaloauth2permissiongrant) to [build automation to check and document](https://gist.github.com/psignoret/41793f8c6211d2df5051d77ca3728c09) scopes for service account

+* Use PowerShell to [review service principal credentials](https://github.com/AzureAD/AzureADAssessment) and confirm validity

+* Don't set service principal credentials to **Never expire**

+* Use certificates or credentials stored in Azure Key Vault, when possible

+ * [what is Azure Key Vault?](../../key-vault/general/basic-concepts.md)

+The free PowerShell sample collects service principal OAuth2 grants and credential information, records them in a comma-separated values (CSV) file, and a Power BI sample dashboard. For more information, see [Microsoft Azure AD Assessment, Assessor Guide](https://github.com/AzureAD/AzureADAssessment).

+Establish a regular review process to ensure service accounts are regularly reviewed by owners, security team, or IT team.

+The process includes:

+* Determine service account review cycle, and document it in your CMDB

+* Communications to owner, security team, IT team, before a review

+* Determine warning communications, and their timing, if the review is missed

+* Instructions if owners fail to review or respond

+ * Disable, but don't delete, the account until the review is complete

+* Instructions to determine dependencies. Notify resource owners of effects

+The review includes the owner and an IT partner, and they certify:

+* Account is necessary

+* Permissions to the account are adequate and necessary, or a change is requested

+* Access to the account, and its credentials, are controlled

+* Account credentials are accurate: credential type and lifetime

+* Account risk score hasn't changed since the previous recertification

+* Update the expected account lifetime, and the next recertification date

+Deprovision service accounts under the following circumstances:

+* Account script or application is retired

+* Account script or application function is retired. For example, access to a resource.

+* Service account is replaced by another service account

+* Credentials expired, or the account is non-functional, and there arenΓÇÖt complaints

+Deprovisioning includes the following tasks:

+After the associated application or script is deprovisioned:

+* [Monitor sign-ins](../reports-monitoring/concept-sign-ins.md) and resource access by the service account

+ * If the account is active, determine how it's being used before continuing

+* For a managed service identity, disable service account sign-in, but don't remove it from the directory

+* Revoke service account role assignments and OAuth2 consent grants

+* After a defined period, and warning to owners, delete the service account from the directory

+* [Securing cloud-based service accounts](service-accounts-introduction-azure.md)

+* [Securing managed identities](service-accounts-managed-identities.md)

+* [Securing service principal](service-accounts-principal.md)

+ Title: Secure group managed service accounts

+description: A guide to securing group managed service accounts (gMSAs)

+Group managed service accounts (gMSAs) are domain accounts to help secure services. gMSAs can run on one server, or in a server farm, such as systems behind a network load balancing or Internet Information Services (IIS) server. After you configure your services to use a gMSA principal, account password management is handled by the Windows operating system (OS).

+## Benefits of gMSAs

+gMSAs are an identity solution with greater security that help reduce administrative overhead:

+* **Set strong passwords** - 240-byte, randomly generated passwords: the complexity and length of gMSA passwords minimizes the likelihood of compromise by brute force or dictionary attacks

+* **Cycle passwords regularly** - password management goes to the Windows OS, which changes the password every 30 days. Service and domain administrators don't need to schedule password changes, or manage service outages.

+* **Support deployment to server farms** - deploy gMSAs to multiple servers to support load balanced solutions where multiple hosts run the same service

+* **Support simplified service principal name (SPN) management** - set up an SPN with PowerShell, when you create an account.

+ * In addition, services that support automatic SPN registrations might do so against the gMSA, if the gMSA permissions are set correctly.

+## Using gMSAs

+Use gMSAs as the account type for on-premises services unless a service, such as failover clustering, doesn't support it.

+> Test your service with gMSAs before it goes to production. Set up a test environment to ensure the application uses the gMSA, then accesses resources. For more information, see [Support for group managed service accounts](/system-center/scom/support-group-managed-service-accounts?view=sc-om-2022&preserve-view=true).

+If a service doesn't support gMSAs, you can use a standalone managed service account (sMSA). An sMSA has the same functionality, but is intended for deployment on a single server.

+If you can't use a gMSA or sMSA supported by your service, configure the service to run as a standard user account. Service and domain administrators are required to observe strong password management processes to help keep the account secure.

+## Assess gSMA security posture

+gMSAs are more secure than standard user accounts, which require ongoing password management. However, consider gMSA scope of access in relation to security posture. Potential security issues and mitigations for using gMSAs are shown in the following table:

+| gMSA is a member of privileged groups | <li>Review your group memberships. Create a PowerShell script to enumerate group memberships. Filter the resultant CSV file by gMSA file names.<li>Remove the gMSA from privileged groups.<li>Grant the gMSA rights and permissions it requires to run its service. See your service vendor.

+| gMSA has read/write access to sensitive resources | <li>Audit access to sensitive resources.<li>Archive audit logs to a SIEM, such as Azure Log Analytics or Microsoft Sentinel, for analysis.<li>Remove unnecessary resource permissions if there's an unnecessary access level. |

+Your organization might have gMSAs. To retrieve these accounts, run the following PowerShell cmdlets:

+### Managed Service Accounts container

+To work effectively, gMSAs must be in the Managed Service Accounts container.

+

+

+To find service MSAs not in the list, run the following commands:

+# This PowerShell cmdlet returns managed service accounts (gMSAs and sMSAs). Differentiate by examining the ObjectClass attribute on returned accounts.

+To manage gMSAs, use the following Active Directory PowerShell cmdlets:

+> In Windows Server 2012, and later versions, the *-ADServiceAccount cmdlets work with gMSAs. Learn more: [Get started with group managed service accounts](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).

+gMSAs are a secure service account type for on-premises. It's recommended you use gMSAs, if possible. In addition, consider moving your services to Azure and your service accounts to Azure Active Directory.

+

+To move to a gMSA:

+1. Ensure the [Key Distribution Service (KDS) root key](/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key) is deployed in the forest. This is a one-time operation.

+2. [Create a new gMSA](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).

+3. Install the new gMSA on hosts that run the service.

+

+ > Before configuring your service to use the gMSA, see [Get started with group managed service accounts](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj128431(v=ws.11)).

+4. Change your service identity to gMSA.

+5. Specify a blank password.

+6. Validate your service is working under the new gMSA identity.

+7. Delete the old service account identity.

+* [Secure computer accounts with Active Directory](service-accounts-computer.md)

+* [Secure user-based service accounts in Active Directory](service-accounts-user-on-premises.md)

+|Functionality, feature, or service|Change|Change date |

+|||:|

+|Microsoft Authenticator app [Number matching](../authentication/how-to-mfa-number-match.md)|Feature change|Feb 27, 2023|

+|Azure AD DS [virtual network deployments](../../active-directory-domain-services/migrate-from-classic-vnet.md)|Retirement|Mar 1, 2023|

+|[License management API, PowerShell](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/migrate-your-apps-to-access-the-license-managements-apis-from/ba-p/2464366)|Retirement|*Mar 31, 2023|

+|[Azure AD Authentication Library (ADAL)](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-september-2022-train/ba-p/2967454)|Retirement|Jun 30, 2023|

+|[Azure AD Graph API](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-september-2022-train/ba-p/2967454)|Deprecation|Jun 30, 2023|

+|[Azure AD PowerShell and MSOnline PowerShell](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-september-2022-train/ba-p/2967454)|Deprecation|Jun 30, 2023|

+|[Azure AD MFA Server](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-september-2022-train/ba-p/2967454)|Retirement|Sep 30, 2024|

+\* The legacy license management API and PowerShell cmdlets will not work for **new tenants** created after Nov 1, 2022.

+1. Find the role you need. You can use the search box or **Add filters** to filter the roles.

+1. Select the role name to open the role. Don't add a check mark next to the role.

+ 

+1. Find the role you need. You can use the search box or **Add filters** to filter the roles.

+1. Select the role name to open the role and see its eligible, active, and expired role assignments. Don't add a check mark next to the role.

+ 

+docker tag /azure-vote-front:v1 /azure-vote-front:v2

+* To configure the policy with one or more OpenID configuration endpoints for use with a self-hosted gateway, the OpenID configuration endpoints URLs must also be reachable by the cloud gateway.

+If you use a smaller subnet, be aware of the following limitations:

+For your app to receive traffic, ensure that inbound network security group (NSG) rules allow the App Service Environment subnet to receive traffic from the required ports. In addition to any ports you'd like to receive traffic on, you should ensure that Azure Load Balancer is able to connect to the subnet on port 80. This port is used for health checks of the internal virtual machine. You can still control port 80 traffic from the virtual network to your subnet.

+Application dependencies include endpoints that your app needs during runtime. Besides APIs and services the app is calling, dependencies could also be derived endpoints like certificate revocation list (CRL) check endpoints and identity/authentication endpoint, for example Azure Active Directory. If you're using [continuous deployment in App Service](../deploy-continuous-deployment.md), you might also need to allow endpoints depending on type and language. Specifically for [Linux continuous deployment](https://github.com/microsoft/Oryx/blob/main/doc/hosts/appservice.md#network-dependencies), you'll need to allow `oryx-cdn.microsoft.io:443`.

+> Outbound SMTP connectivity (port 25) is supported for App Service Environment v3. The supportability is determined by a setting on the subscription where the virtual network is deployed. For virtual networks/subnets created before 1. August 2022 you need to initiate a temporary configuration change to the virtual network/subnet for the setting to be synchronized from the subscription. An example could be to add a temporary subnet, associate/dissociate an NSG temporarily or configure a service endpoint temporarily. For more information and troubleshooting, see [Troubleshoot outbound SMTP connectivity problems in Azure](../../virtual-network/troubleshoot-outbound-smtp-connectivity.md).

+You can activate it through the Azure portal. In the App Service Environment configuration pane, turn **on** the setting `Allow new private endpoints`.

+The following sections describe the DNS considerations and configuration that apply inbound to and outbound from your App Service Environment. The examples use the domain suffix `appserviceenvironment.net` from Azure Public Cloud. If you're using other clouds like Azure Government, you'll need to use their respective domain suffix.

+In addition to the default domain provided when an app is created, you can also add a custom domain to your app. You can set a custom domain name without any validation on your apps. If you're using custom domains, you need to ensure they have DNS records configured. You can follow the preceding guidance to configure DNS zones and records for a custom domain name (replace the default domain name with the custom domain name). The custom domain name works for app requests, but doesn't work for the `scm` site. The `scm` site is only available at *&lt;appname&gt;.scm.&lt;asename&gt;.appserviceenvironment.net*.

+In addition to setting up DNS, you also need to enable it in the [App Service Environment configuration](./configure-network-settings.md#ftp-access) and at the [app level](../deploy-ftp.md?tabs=cli#enforce-ftps).

+The apps in your App Service Environment will use the DNS that your virtual network is configured with. If you want some apps to use a different DNS server, you can manually set it on a per app basis, with the app settings `WEBSITE_DNS_SERVER` and `WEBSITE_DNS_ALT_SERVER`. `WEBSITE_DNS_ALT_SERVER` configures the secondary DNS server. The secondary DNS server is only used when there's no response from the primary DNS server.

+Before you stream logs in real time, enable the log type that you want. Any information written to the conosle output or files ending in .txt, .log, or .htm that are stored in the */home/LogFiles* directory (D:\home\LogFiles) is streamed by App Service.

+## Start-AzAutomationRunbook fails with "runbookName does not match expected pattern" error message

+### Issue

+When you run `Start-AzAutomationRunbook` to start specific runbooks:

+```powershell

+start-azautomationRunbook -Name "Test_2" -AutomationAccountName "AutomationParent" -ResourceGroupName "AutomationAccount"

+```

+It fails with the following error:

+

+`Start-AzAutomationRunbook: "runbookname" does not match expected pattern '^[a-zA-Z]*-*[a-zA-Z0-9]*$'`

+

+### Cause

+Code that was introduced in [1.9.0 version](https://www.powershellgallery.com/packages/Az.Automation/1.9.0) of the Az.Automation module verifies the names of the runbooks to start and incorrectly flags runbooks with multiple "-" characters or with an "_" character in the name as invalid.

+### Workaround

+We recommend that you revert to [1.8.0 version](https://www.powershellgallery.com/packages/Az.Automation/1.8.0) of the module.

+### Resolution

+Currently, we are working to deploy a fix to address this issue.

+> Creating a recurring profile with no end time is only supported via the portal and ARM templates. For more information on creating recurring profiles with ARM templates, see [Add a recurring profile using ARM templates](./autoscale-multiprofile.md?tabs=templates#add-a-recurring-profile-using-arm-templates).

+## Add a recurring profile using ARM templates

+The example below shows how to create two recurring profiles. One profile for weekends from 00:01 on Saturday morning and a second Weekday profile starting on Mondays at 04:00. That means that the weekend profile will start on Saturday morning at one minute passed midnight and end on Monday morning at 04:00. The Weekday profile will start at 4am on Monday and end just after midnight on Saturday morning.

+ The default log data plan is Analytics, which lets you take advantage of Azure Monitor's rich monitoring and analytics capabilities.

+| [InstallDependencyAgent-Windows.exe](https://aka.ms/dependencyagentwindows) | Windows | 9.10.16.22650 | BE537D4396625ADD93B8C1D5AF098AE9D9472D8A20B2682B32920C5517F1C041 |

+| [InstallDependencyAgent-Linux64.bin](https://aka.ms/dependencyagentlinux) | Linux | 9.10.16.22650 | FF86D821BA845833C9FE5F6D5C8A5F7A60617D3AD7D84C75143F3E244ABAAB74 |

+* [DB2 Installation Guide on Azure NetApp Files](https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/db2-installation-guide-on-anf/ba-p/3709437)

+* [Disaster protection for JFrog Artifactory in AKS with Astra Control Service and Azure NetApp Files](https://techcommunity.microsoft.com/t5/azure-architecture-blog/disaster-protection-for-jfrog-artifactory-in-aks-with-astra/ba-p/3701501)

+This article describes the lambda functions to use in Bicep. [Lambda expressions (or lambda functions)](/dotnet/csharp/language-reference/operators/lambda-expressions) are essentially blocks of code that can be passed as an argument. They can take multiple parameters, but are restricted to a single line of code. In Bicep, lambda expression is in this format:

+ Title: Template functions - lambda

+description: Describes the lambda functions to use in an Azure Resource Manager template (ARM template)

+# Lambda functions for ARM templates

+This article describes the lambda functions to use in ARM templates. [Lambda expressions (or lambda functions)](/dotnet/csharp/language-reference/operators/lambda-expressions) are essentially blocks of code that can be passed as an argument. They can take multiple parameters, but are restricted to a single line of code. In ARM templates, lambda expression is in this format:

+```json

+<lambda variable> => <expression>

+```

+> [!TIP]

+> We recommend [Bicep](../bicep/overview.md) because it offers the same capabilities as ARM templates and the syntax is easier to use. To learn more, see [deployment](../bicep/bicep-functions-deployment.md) functions.

+## Limitations

+ARM template lambda function has these limitations:

+- Lambda expression can only be specified directly as function arguments in these functions: [`filter()`](#filter), [`map()`](#map), [`reduce()`](#reduce), and [`sort()`](#sort).

+- Using lambda variables (the temporary variables used in the lambda expressions) inside resource or module array access isn't currently supported.

+- Using lambda variables inside the [`listKeys`](./template-functions-resource.md#list) function isn't currently supported.

+- Using lambda variables inside the [reference](./template-functions-resource.md#reference) function isn't currently supported.

+## filter

+`filter(inputArray, lambda expression)`

+Filters an array with a custom filtering function.

+In Bicep, use the [filter](../bicep/bicep-functions-lambda.md#filter) function.

+### Parameters

+| Parameter | Required | Type | Description |

+|: |: |: |: |

+| inputArray |Yes |array |The array to filter.|

+| lambda expression |Yes |expression |The lambda expression applied to each input array element. If false, the item will be filtered out of the output array.|

+### Return value

+An array.

+### Examples

+The following examples show how to use the filter function.

+```json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "variables": {

+ "dogs": [

+ {

+ "name": "Evie",

+ "age": 5,

+ "interests": [

+ "Ball",

+ "Frisbee"

+ ]

+ },

+ {

+ "name": "Casper",

+ "age": 3,

+ "interests": [

+ "Other dogs"

+ ]

+ },

+ {

+ "name": "Indy",

+ "age": 2,

+ "interests": [

+ "Butter"

+ ]

+ },

+ {

+ "name": "Kira",

+ "age": 8,

+ "interests": [

+ "Rubs"

+ ]

+ }

+ ]

+ },

+ "resources": {},

+ "outputs": {

+ "oldDogs": {

+ "type": "array",

+ "value": "[filter(variables('dogs'), lambda('dog', greaterOrEquals(lambdaVariables('dog').age, 5)))]"

+ }

+ }

+}

+```

+The output from the preceding example shows the dogs that are five or older:

+| Name | Type | Value |

+| - | - | -- |

+| oldDogs | Array | [{"name":"Evie","age":5,"interests":["Ball","Frisbee"]},{"name":"Kira","age":8,"interests":["Rubs"]}] |

+```json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "variables": {

+ "copy": [

+ {

+ "name": "itemForLoop",

+ "count": "[length(range(0, 10))]",

+ "input": "[range(0, 10)[copyIndex('itemForLoop')]]"

+ }

+ ]

+ },

+ "resources": {},

+ "outputs": {

+ "filteredLoop": {

+ "type": "array",

+ "value": "[filter(variables('itemForLoop'), lambda('i', greater(lambdaVariables('i'), 5)))]"

+ },

+ "isEven": {

+ "type": "array",

+ "value": "[filter(range(0, 10), lambda('i', equals(0, mod(lambdaVariables('i'), 2))))]"

+ }

+ }

+}

+```

+The output from the preceding example:

+| Name | Type | Value |

+| - | - | -- |

+| filteredLoop | Array | [6, 7, 8, 9] |

+| isEven | Array | [0, 2, 4, 6, 8] |

+**filterdLoop** shows the numbers in an array that are greater than 5; and **isEven** shows the even numbers in the array.

+## map

+`map(inputArray, lambda expression)`

+Applies a custom mapping function to each element of an array.

+In Bicep, use the [map](../bicep/bicep-functions-lambda.md#map) function.

+### Parameters

+| Parameter | Required | Type | Description |

+|: |: |: |: |

+| inputArray |Yes |array |The array to map.|

+| lambda expression |Yes |expression |The lambda expression applied to each input array element, in order to generate the output array.|

+### Return value

+An array.

+### Example

+The following example shows how to use the map function.

+```json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "variables": {

+ "dogs": [

+ {

+ "name": "Evie",

+ "age": 5,

+ "interests": [

+ "Ball",

+ "Frisbee"

+ ]

+ },

+ {

+ "name": "Casper",

+ "age": 3,

+ "interests": [

+ "Other dogs"

+ ]

+ },

+ {

+ "name": "Indy",

+ "age": 2,

+ "interests": [

+ "Butter"

+ ]

+ },

+ {

+ "name": "Kira",

+ "age": 8,

+ "interests": [

+ "Rubs"

+ ]

+ }

+ ]

+ },

+ "resources": {},

+ "outputs": {

+ "dogNames": {

+ "type": "array",

+ "value": "[map(variables('dogs'), lambda('dog', lambdaVariables('dog').name))]"

+ },

+ "sayHi": {

+ "type": "array",

+ "value": "[map(variables('dogs'), lambda('dog', format('Hello {0}!', lambdaVariables('dog').name)))]"

+ },

+ "mapObject": {

+ "type": "array",

+ "value": "[map(range(0, length(variables('dogs'))), lambda('i', createObject('i', lambdaVariables('i'), 'dog', variables('dogs')[lambdaVariables('i')].name, 'greeting', format('Ahoy, {0}!', variables('dogs')[lambdaVariables('i')].name))))]"

+ }

+ }

+}

+```

+The output from the preceding example is:

+| Name | Type | Value |

+| - | - | -- |

+| dogNames | Array | ["Evie","Casper","Indy","Kira"] |

+| sayHi | Array | ["Hello Evie!","Hello Casper!","Hello Indy!","Hello Kira!"] |

+| mapObject | Array | [{"i":0,"dog":"Evie","greeting":"Ahoy, Evie!"},{"i":1,"dog":"Casper","greeting":"Ahoy, Casper!"},{"i":2,"dog":"Indy","greeting":"Ahoy, Indy!"},{"i":3,"dog":"Kira","greeting":"Ahoy, Kira!"}] |

+**dogNames** shows the dog names from the array of objects; **sayHi** concatenates "Hello" and each of the dog names; and **mapObject** creates another array of objects.

+## reduce

+`reduce(inputArray, initialValue, lambda expression)`

+Reduces an array with a custom reduce function.

+In Bicep, use the [reduce](../bicep/bicep-functions-lambda.md#reduce) function.

+### Parameters

+| Parameter | Required | Type | Description |

+|: |: |: |: |

+| inputArray |Yes |array |The array to reduce.|

+| initialValue |No |any |Initial value.|

+| lambda expression |Yes |expression |The lambda expression used to aggregate the current value and the next value.|

+### Return value

+Any.

+### Example

+The following examples show how to use the reduce function.

+```json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "variables": {

+ "dogs": [

+ {

+ "name": "Evie",

+ "age": 5,

+ "interests": [

+ "Ball",

+ "Frisbee"

+ ]

+ },

+ {

+ "name": "Casper",

+ "age": 3,

+ "interests": [

+ "Other dogs"

+ ]

+ },

+ {

+ "name": "Indy",

+ "age": 2,

+ "interests": [

+ "Butter"

+ ]

+ },

+ {

+ "name": "Kira",

+ "age": 8,

+ "interests": [

+ "Rubs"

+ ]

+ }

+ ],

+ "ages": "[map(variables('dogs'), lambda('dog', lambdaVariables('dog').age))]"

+ },

+ "resources": {},

+ "outputs": {

+ "totalAge": {

+ "type": "int",

+ "value": "[reduce(variables('ages'), 0, lambda('cur', 'next', add(lambdaVariables('cur'), lambdaVariables('next'))))]"

+ },

+ "totalAgeAdd1": {

+ "type": "int",

+ "value": "[reduce(variables('ages'), 1, lambda('cur', 'next', add(lambdaVariables('cur'), lambdaVariables('next'))))]"

+ }

+ }

+}

+```

+The output from the preceding example is:

+| Name | Type | Value |

+| - | - | -- |

+| totalAge | int | 18 |

+| totalAgeAdd1 | int | 19 |

+**totalAge** sums the ages of the dogs; **totalAgeAdd1** has an initial value of 1, and adds all the dog ages to the initial values.

+```json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "resources": {},

+ "outputs": {

+ "reduceObjectUnion": {

+ "type": "object",

+ "value": "[reduce(createArray(createObject('foo', 123), createObject('bar', 456), createObject('baz', 789)), createObject(), lambda('cur', 'next', union(lambdaVariables('cur'), lambdaVariables('next'))))]"

+ }

+ }

+}

+```

+The output from the preceding example is:

+| Name | Type | Value |

+| - | - | -- |

+| reduceObjectUnion | object | {"foo":123,"bar":456,"baz":789} |

+The [union](./template-functions-object.md#union) function returns a single object with all elements from the parameters. The function call unionizes the key value pairs of the objects into a new object.

+## sort

+`sort(inputArray, lambda expression)`

+Sorts an array with a custom sort function.

+In Bicep, use the [sort](../bicep/bicep-functions-lambda.md#sort) function.

+### Parameters

+| Parameter | Required | Type | Description |

+|: |: |: |: |

+| inputArray |Yes |array |The array to sort.|

+| lambda expression |Yes |expression |The lambda expression used to compare two array elements for ordering. If true, the second element will be ordered after the first in the output array.|

+### Return value

+An array.

+### Example

+The following example shows how to use the sort function.

+```json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "variables": {

+ "dogs": [

+ {

+ "name": "Evie",

+ "age": 5,

+ "interests": [

+ "Ball",

+ "Frisbee"

+ ]

+ },

+ {

+ "name": "Casper",

+ "age": 3,

+ "interests": [

+ "Other dogs"

+ ]

+ },

+ {

+ "name": "Indy",

+ "age": 2,

+ "interests": [

+ "Butter"

+ ]

+ },

+ {

+ "name": "Kira",

+ "age": 8,

+ "interests": [

+ "Rubs"

+ ]

+ }

+ ]

+ },

+ "resources": {},

+ "outputs": {

+ "dogsByAge": {

+ "type": "array",

+ "value": "[sort(variables('dogs'), lambda('a', 'b', less(lambdaVariables('a').age, lambdaVariables('b').age)))]"

+ }

+ }

+}

+```

+The output from the preceding example sorts the dog objects from the youngest to the oldest:

+| Name | Type | Value |

+| - | - | -- |

+| dogsByAge | Array | [{"name":"Indy","age":2,"interests":["Butter"]},{"name":"Casper","age":3,"interests":["Other dogs"]},{"name":"Evie","age":5,"interests":["Ball","Frisbee"]},{"name":"Kira","age":8,"interests":["Rubs"]}] |

+## Next steps

+- See [Template functions - arrays](./template-functions-array.md) for additional array related template functions.

+- Work with your Microsoft representative to ensure that the Azure VMware Solution private cloud and the Azure NetApp Files volumes are deployed within the same [availability zone](../availability-zones/az-overview.md#availability-zones). Open a support request and ask that the NetApp account be pinned to the availability zone where AVS is deployed.

+### <a name="dns"></a>Does Azure Bastion support Private Link?

+ Title: Predictive maintenance architecture for using the Anomaly Detector Multivariate API

+- [Best Practices](../concepts/best-practices-multivariate.md): This article is about recommended patterns to use with the multivariate APIs.

+> Usage of pronunciation assessment costs the same as standard Speech to Text pay-as-you-go [pricing](https://azure.microsoft.com/pricing/details/cognitive-services/speech-services). Pronunciation assessment doesn't yet support commitment tier pricing.

+> Usage of pronunciation assessment costs the same as standard Speech to Text pay-as-you-go [pricing](https://azure.microsoft.com/pricing/details/cognitive-services/speech-services). Pronunciation assessment doesn't yet support commitment tier pricing.

+ Title: Security for communication as Teams external user

+description: This article describes security for communication as a Teams external user with Azure Communication Services.

+## Microsoft Purview

+Microsoft Purview provides robust data security features to protect sensitive information. One of the key features of Purview is [data loss prevention (DLP)](/microsoft-365/compliance/dlp-microsoft-teams), which helps organizations to prevent accidental or unauthorized sharing of sensitive data. Developers can use [Communication Services UI library](../../ui-library/ui-library-overview.md) or follow [how-to guide](../../../how-tos/chat-sdk/data-loss-prevention.md) to support data loss prevention in Teams meetings. In addition, Purview offers [Customer Key](/microsoft-365/compliance/customer-key-overview), which allows customers to manage the encryption keys used to protect their data fully. Chat messages sent by Teams external users are encrypted at rest with the Customer Key provided in Purview. These features help customers meet compliance requirements.

+# Emergency Calling concepts

+Calls to 911 are routed over the Microsoft network. Microsoft assigns a temporary phone number as the Call Line Identity (CLI) when 911 calls from the US & Puerto Rico are placed. Microsoft temporarily maintains a mapping of the phone number to the caller's identity. If there's a call-back from the PSAP, we route the call directly to the originating 911 caller. The caller can accept incoming PSAP call even if inbound calling is disabled.

+Emergency dialing is automatically enabled for all users of the Azure Communication Client Calling SDK with an acquired Microsoft telephone number that is enabled for outbound dialing in the Azure resource. To use E911 with Microsoft phone numbers, follow the steps:

+ 1. If the country code isn't provided to the SDK, the IP address is used to determine the country of the caller

+ 1. If the IP address can't provide reliable geo-location, for example the user is on a Virtual Private Network, it's required to set the ISO Code of the calling country using the API in the Azure Communication Services Calling SDK. See example in the E911 quick start

+ 1. If users are dialing from a US territory (for example Guam, US Virgin Islands, Northern Marianas, or American Samoa), it's required to set the ISO code to the US

+ 1. If the caller is outside of the US and Puerto Rico, the call to 911 won't be permitted

+1. When testing your application dial 933 instead of 911. 933 is enabled for testing purposes; the recorded message will confirm the phone number the emergency call originates from. You should hear a temporary number assigned by Microsoft, which isn't the `alternateCallerId` provided by the application

+Emergency call is a regular call from a direct routing perspective. If you want to implement emergency calling with Azure Communication Services direct routing, you need to make sure that there's a routing rule for your emergency number (911, 112, etc.). You also need to make sure that your carrier processes emergency calls properly.

+There's also an option to use purchased number as a caller ID for direct routing calls. In such case, if there's no voice routing rule for emergency number, the call will fall back to Microsoft network, and we'll treat it as a regular emergency call. Learn more about [voice routing fall back](./direct-routing-provisioning.md#outbound-voice-routing-considerations).

+ Title: Quickstart - Add raw media access to your app

+description: In this quickstart, you'll learn how to add raw media access calling capabilities to your app by using Azure Communication Services.

+# Quickstart: Add raw media access to your app

+- Check out the [calling hero sample](../../samples/calling-hero-sample.md).

+- Get started with the [UI Library](https://aka.ms/acsstorybook).

+- Learn about [Calling SDK capabilities](./getting-started-with-calling.md?pivots=platform-web).

+- Learn more about [how calling works](../../concepts/voice-video-calling/about-call-types.md).

+We strongly recommend that you have a support plan that includes technical support, such as [Microsoft Unified Support](https://www.microsoft.com/en-us/unifiedsupport/overview) or [Premier Support](https://www.microsoft.com/en-us/unifiedsupport/premier).

+Azure provides unlimited support for subscription management, which includes billing, quota adjustments, and account transfers. For technical support, you need a support plan, such as [Microsoft Unified Support](https://www.microsoft.com/en-us/unifiedsupport/overview) or [Premier Support](https://www.microsoft.com/en-us/unifiedsupport/premier).

+In single revision mode, Container Apps automatically ensures your app does not experience downtime when creating a new revision. The existing active revision is not deactivated until the new revision is ready. If ingress is enabled, the existing revision will continue to receive 100% of the traffic until the new revision is ready.

+[pricing page](https://azure.microsoft.com/pricing/details/cosmos-db/postgresql/).

+[Azure portal](https://portal.azure.com/#create/Microsoft.DocumentDB)

+A reservation doesn't cover software, networking, or storage charges associated with the clusters. At the end of the reservation term, the billing benefit expires, and the clusters are billed at the pay-as-you go price. Reservations don't autorenew. For pricing information, see the [Azure Cosmos DB for PostgreSQL reserved capacity offering](https://azure.microsoft.com/pricing/details/cosmos-db/postgresql/).

+- Manage a cloud workload and its related resources.

+- Responsible for implementing and maintaining protections in accordance with company security policy.

+- Responsible for all aspects of security for the company.

+- Wants to understand the company's security posture across cloud workloads.

+- Needs to be informed of major attacks and risks.

+- Sets company security policies to ensure the appropriate protections are in place.

+- Monitors compliance with policies.

+- Generates reports for leadership or auditors.

+- Monitors and responds to security alerts at any time.

+- Escalates to Cloud Workload Owner or IT Security Analyst.

+- Investigate attacks.

+- Work with Cloud Workload Owner to apply remediation.

+Defender for Cloud uses [Azure role-based access control (Azure Role-based access control)](../role-based-access-control/role-assignments-portal.md), which provides [built-in roles](../role-based-access-control/built-in-roles.md) that can be assigned to users, groups, and services in Azure. When a user opens Defender for Cloud, they only see information related to resources they have access to. Which means the user is assigned the role of Owner, Contributor, or Reader to the subscription or resource group that a resource belongs to. In addition to these roles, there are two roles specific to Defender for Cloud:

+The personas explained in the previous diagram need these Azure Role-based access control roles:

+- Access to the workspace may be required.

+When planning access control using Azure Role-based access control for Defender for Cloud, make sure you understand who in your organization needs access to Defender for Cloud the tasks they'll perform. Then you can configure Azure Role-based access control properly.

+When automatic provisioning is enabled in the security policy, the [data collection agent](monitoring-components.md) is installed on all supported Azure VMs and any new supported VMs that are created. If the VM or computer already has the Log Analytics agent installed, Defender for Cloud uses the current installed agent. The agent's process is designed to be non-invasive and have minimal effect on VM performance.

+ Title: Configure OT sensor settings from the Azure portal - Microsoft Defender for IoT

+description: Learn how to configure settings for OT network sensors from Microsoft Defender for IoT on the Azure portal.

+# Configure OT sensor settings from the Azure portal (Public preview)

+After [onboarding](onboard-sensors.md) a new OT network sensor to Microsoft Defender for IoT, you may want to define several settings directly on the OT sensor console, such as [adding local users](manage-users-sensor.md) or [connecting to an on-premises management console](how-to-manage-individual-sensors.md#connect-a-sensor-to-the-management-console).

+Selected OT sensor settings, listed below, are also available directly from the Azure portal, and can be applied in bulk across multiple cloud-connected OT sensors at a time, or across all OT sensors in a specific site or zone. This article describes how to view and configure view OT network sensor settings from the Azure portal.

+> [!NOTE]

+> The **Sensor settings** page in Defender for IoT is in PREVIEW. The [Azure Preview Supplemental Terms](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) include other legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

+>

+## Prerequisites

+To define OT sensor settings, make sure that you have the following:

+- **An Azure subscription onboarded to Defender for IoT**. If you need to, [sign up for a free account](https://azure.microsoft.com/free/) and then use the [Quickstart: Get started with Defender for IoT](getting-started.md) to onboard.

+- **Permissions**:

+ - To view settings that others have defined, sign in with a [Security Reader](../../role-based-access-control/built-in-roles.md#security-reader), [Security admin](/azure/role-based-access-control/built-in-roles#security-admin), [Contributor](/azure/role-based-access-control/built-in-roles#contributor), or [Owner](/azure/role-based-access-control/built-in-roles#owner) role for the subscription.

+ - To define or update settings, sign in with [Security admin](/azure/role-based-access-control/built-in-roles#security-admin), [Contributor](/azure/role-based-access-control/built-in-roles#contributor), or [Owner](/azure/role-based-access-control/built-in-roles#owner) role.

+ For more information, see [Azure user roles and permissions for Defender for IoT](roles-azure.md).

+- **One or more cloud-connected OT network sensors**. For more information, see [Onboard OT sensors to Defender for IoT](onboard-sensors.md).

+## Define a new sensor setting

+Define a new setting whenever you want to define a specific configuration for one or more OT network sensors. For example, you might want to define bandwidth caps for all OT sensors in a specific site or zone, or for a single OT sensor at a specific location in your network.

+**To define a new setting**:

+1. In Defender for IoT on the Azure portal, select **Sites and sensors** > **Sensor settings (Preview)**.

+1. On the **Sensor settings (Preview)** page, select **+ Add**, and then use the wizard to define the following values for your setting. Select **Next** when you're done with each tab in the wizard to move to the next step.

+ |Tab name |Description |

+ |||

+ |**Basics** | Select the subscription where you want to apply your setting, and your [setting type](#sensor-setting-reference). <br><br>Enter a meaningful name and an optional description for your setting. |

+ |**Setting** | Define the values for your selected setting type.<br>For details about the options available for each setting type, find your selected setting type in the [Sensor setting reference](#sensor-setting-reference) below. |

+ |**Apply** | Use the **Select sites**, **Select zones**, and **Select sensors** dropdown menus to define where you want to apply your setting. <br><br>**Important**: Selecting a site or zone applies the setting to all connected OT sensors, including any OT sensors added to the site or zone later on. <br>If you select to apply your settings to an entire site, you don't also need to select its zones or sensors. |

+ |**Review and create** | Check the selections you've made for your setting. <br><br>If your new setting replaces an existing setting, a :::image type="icon" source="media/how-to-manage-individual-sensors/warning-icon.png" border="false"::: warning is shown to indicate the existing setting.<br><br>When you're satisfied with the setting's configuration, select **Create**. |

+Your new setting is now listed on the **Sensor settings (Preview)** page under its setting type, and on the sensor details page for any related OT sensor. Sensor settings are shown as read-only on the sensor details page. For example:

+> [!TIP]

+> You may want to configure exceptions to your settings for a specific OT sensor or zone. In such cases, create an extra setting for the exception.

+>

+> Settings override eachother in a hierarchical manner, so that if your setting is applied to a specific OT sensor, it overrides any related settings that are applied to the entire zone or site. To create an exception for an entire zone, add a setting for that zone to override any related settings applied to the entire site.

+>

+## View and edit current OT sensor settings

+**To view the current settings already defined for your subscription**:

+1. In Defender for IoT on the Azure portal, select **Sites and sensors** > **Sensor settings (Preview)**

+ The **Sensor settings (Preview)** page shows any settings already defined for your subscriptions, listed by setting type. Expand or collapse each type to view detailed configurations. For example:

+ :::image type="content" source="media/configure-sensor-settings-portal/view-settings.png" alt-text="Screenshot of OT sensor settings on the Azure portal.":::

+1. Select a specific setting to view its exact configuration and the site, zones, or individual sensors where the setting is applied.

+1. To edit the setting's configuration, select **Edit** and then use the same wizard you used to create the setting to make the updates you need. When you're done, select **Apply** to save your changes.

+### Delete an existing OT sensor setting

+To delete an OT sensor setting altogether:

+1. On the **Sensor settings (Preview)** page, locate the setting you want to delete.

+1. Select the **...** options menu at the top-right corner of the setting's card and then select **Delete**.

+For example:

+## Edit settings for disconnected OT sensors

+This procedure describes how to edit OT sensor settings if your OT sensor is currently disconnected from Azure, such as during an ongoing security incident.

+By default, if you've configured any settings from the Azure portal, all settings that are configurable from both the Azure portal and the OT sensor are set to read-only on the OT sensor itself. For example, if you've configured a VLAN from the Azure portal, then bandwidth cap, subnet, and VLAN settings are *all* set to read-only, and blocked from modifications on the OT sensor.

+If you're in a situation where the OT sensor is disconnected from Azure, and you need to modify one of these settings, you'll first need to gain write access to those settings.

+**To gain write access to blocked OT sensor settings**:

+1. On the Azure portal, in the **Sensor settings (Preview)** page, locate the setting you want to edit and open it for editing. For more information, see [View and edit current OT sensor settings](#view-and-edit-current-ot-sensor-settings) above.

+ Edit the scope of the setting so that it no longer includes the OT sensor, and any changes you make while the OT sensor is disconnected aren't overwritten when you connect it back to Azure.

+ > [!IMPORTANT]

+ > Settings defined on the Azure portal always override settings defined on the OT sensor.

+1. Sign into the affected OT sensor console, and select **Settings > Advanced configurations** > **Azure Remote Config**.

+1. In the code box, modify the `block_local_config` value from `1` to `0`, and select **Close**. For example:

+ :::image type="content" source="media/how-to-manage-individual-sensors/remote-config-sensor.png" alt-text="Screenshot of the Azure Remote Config option." lightbox="media/how-to-manage-individual-sensors/remote-config-sensor.png":::

+Continue by updating the relevant setting directly on the OT network sensor. For more information, see [Manage individual sensors](how-to-manage-individual-sensors.md).

+## Sensor setting reference

+Use the following sections to learn more about the individual OT sensor settings available from the Azure portal:

+### Bandwidth cap

+For a bandwidth cap, define the maximum bandwidth you want the sensor to use for outgoing communication from the sensor to the cloud, either in Kbps or Mbps.

+**Default**: 1500 Kbps

+**Minimum required for a stable connection to Azure** 350 Kbps. At this minimum setting, connections to the sensor console may be slower than usual.

+### Subnet

+To define your sensor's subnets do any of the following:

+- Select **Import subnets** to import a comma-separated list of subnet IP addresses and masks. Select **Export subnets** to export a list of currently configured data, or **Clear all** to start from scratch.

+- Enter values in the **IP Address**, **Mask**,l and **Name** fields to add subnet details manually. Select **Add subnet** to add additional subnets as needed.

+### VLAN naming

+To define a VLAN for your OT sensor, enter the VLAN ID and a meaningful name.

+Select **Add VLAN** to add more VLANs as needed.

+## Next steps

+> [!div class="nextstepaction"]

+> [Manage sensors from the Azure portal](how-to-manage-sensors-on-the-cloud.md)

+> [!div class="nextstepaction"]

+> [Manage OT sensors from the sensor console](how-to-manage-individual-sensors.md)

+To view detected devices in the **Device Inventory** page in an on-premises management console, sign-in to your on-premises management console, and then select **Device Inventory**.

+- [Device data retention periods](references-data-retention.md#device-data-retention-periods).

+>

+For example, if you merge two devices, each with an IP address, both IP addresses will appear as separate interfaces in the Device Properties window.

+You may want to view devices in your network that have been inactive and delete them.

+- [Device data retention periods](references-data-retention.md#device-data-retention-periods)

+- If you have an [Enterprise IoT plan](eiot-defender-for-endpoint.md) with Microsoft Defender for Endpoint, alerts for Enterprise IoT devices detected by Microsoft Defender for Endpoint are available in Defender for Endpoint only.

+ - Select one or more learnable alerts in the grid and then select :::image type="icon" source="media/how-to-manage-sensors-on-the-cloud/learn-icon.png" border="false"::: **Learn** in the toolbar.

+ - On an alert details page for a learnable alert, in the **Take Action** tab, select **Learn**.

+> [Microsoft Defender for IoT alerts](alerts.md)

+> [!div class="nextstepaction"]

+> [Data retention across Microsoft Defender for IoT](references-data-retention.md)

+- [Device data retention periods](references-data-retention.md#device-data-retention-periods).

+System backup is performed automatically at 3:00 AM daily. The data is saved on a different disk in the sensor. The default location is `/var/cyberx/backups`. You can automatically transfer this file to the internal network.

+For more information, see [On-premises backup file capacity](references-data-retention.md#on-premises-backup-file-capacity).

+Each type of data has a different retention period and maximum capacity. For more information see [Create data mining queries](how-to-create-data-mining-queries.md) and [Data retention across Microsoft Defender for IoT](references-data-retention.md).

+Each type of data has a different retention period and maximum capacity. For more information see [Create data mining queries](how-to-create-data-mining-queries.md) and [Data retention across Microsoft Defender for IoT](references-data-retention.md).

+| **Define OT network sensor settings** (Preview) | Define selected sensor settings for one or more cloud-connected OT network sensors. For more information, see [Define and view OT sensor settings from the Azure portal (Public preview)](configure-sensor-settings-portal.md). <br><br>Other settings are also available directly from the [OT sensor console](how-to-manage-individual-sensors.md), or the [on-premises management console](how-to-manage-sensors-from-the-on-premises-management-console.md).|

+Each type of data has a different retention period and maximum capacity. For more information see [Visualize Microsoft Defender for IoT data with Azure Monitor workbooks](workbooks.md) and [Data retention across Microsoft Defender for IoT](references-data-retention.md).

+> [!div class="nextstepaction"]

+> [Manage OT sensors from the sensor console](how-to-manage-individual-sensors.md)

+> [!div class="nextstepaction"]

+> [Define and view OT sensor settings from the Azure portal (Public preview)](configure-sensor-settings-portal.md)

+> [!div class="nextstepaction"]

+> [View and manage alerts on the Defender for IoT portal (Preview)](how-to-manage-cloud-alerts.md)

+The event timeline provides a chronological view of events. Use the timeline during investigations, to understand and analyze the chain of events that preceded and followed an attack or incident.

+1. In the **Create Event** dialog, specify the event type (Info, Notice, or Alert)

+For more information, see:

+- [View alerts](how-to-view-alerts.md).

+- [OT event timeline retention](references-data-retention.md#ot-event-timeline-retention).

+ - Select one or more learnable alerts in the grid and then select :::image type="icon" source="media/how-to-manage-sensors-on-the-cloud/learn-icon.png" border="false"::: **Learn** in the toolbar.

+ - On an alert details page, in the **Take Action** tab, select **Learn**.

+> [Microsoft Defender for IoT alerts](alerts.md)

+> [!div class="nextstepaction"]

+> [Data retention across Microsoft Defender for IoT](references-data-retention.md)

+> [Microsoft Defender for IoT alerts](alerts.md)

+> [!div class="nextstepaction"]

+> [Data retention across Microsoft Defender for IoT](references-data-retention.md)

+ Title: Data retention across Microsoft Defender for IoT

+description: Learn about the data retention periods and capacities for Microsoft Defender for IoT data stored in Azure, the OT sensor, and on-premises management console.

+# Data retention across Microsoft Defender for IoT

+Microsoft Defender for IoT stores data in the Azure portal, on OT network sensors, and on-premises management consoles.

+Each storage location affords a certain storage capacity and retention times. This article describes how much and how long each type of data is stored in each location before it's either deleted or overridden.

+## Device data retention periods

+The following table lists how long device data is stored in each Defender for IoT location.

+| Storage type | Details |

+|||

+| **Azure portal** | 90 days from the date of the **Last activity** value. <br><br> For more information, see [Manage your device inventory from the Azure portal](how-to-manage-device-inventory-for-organizations.md). |

+| **OT network sensor** | The retention of device inventory data isn't limited by time. <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** | The retention of device inventory data isn't limited by time. <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). |

+## Alert data retention

+The following table lists how long alert data is stored in each Defender for IoT location. Alert data is stored as listed, regardless of the alert's status, or whether it's been learned or muted.

+| Storage type | Details |

+|||

+| **Azure portal** | 90 days from the date in the **First detection** value. <br><br> For more information, see [View and manage alerts from the Azure portal](how-to-manage-cloud-alerts.md). |

+| **OT network sensor** | 90 days from the date in the **First detection** value.<br><br> For more information, see [View alerts on your sensor](how-to-view-alerts.md). |

+| **On-premises management console** | 90 days from the date in the **First detection** value.<br><br> For more information, see [Work with alerts on the on-premises management console](how-to-work-with-alerts-on-premises-management-console.md). |

+### OT alert PCAP data retention

+The following table lists how long PCAP data is stored in each Defender for IoT location.

+| Storage type | Details |

+|||

+| **Azure portal** | PCAP files are available for download from the Azure portal for as long as the OT network sensor stores them. <br><br> Once downloaded, the files are cached on the Azure portal for 48 hours. <br><br> For more information, see [Access alert PCAP data](how-to-manage-cloud-alerts.md#access-alert-pcap-data). |

+| **OT network sensor** | Dependent on the sensor's storage capacity allocated for PCAP files, which is determined by its [hardware profile](ot-appliance-sizing.md): <br><br>- **C5600**: 130 GB <br>- **E1800**: 130 GB <br>- **E1000** : 78 GB<br>- **E500**: 78 GB <br>- **L500**: 7 GB <br>- **L100**: 2.5 GB<br>- **L60**: 2.5 GB <br><br> If a sensor exceeds its maximum storage capacity, the oldest PCAP file is deleted to accommodate the new one. <br><br> For more information, see [Access alert PCAP data](how-to-view-alerts.md#access-alert-pcap-data) and [Pre-configured physical appliances for OT monitoring](ot-pre-configured-appliances.md). |

+| **On-premises management console** | PCAP files aren't stored on the on-premises management console and are only accessed from the on-premises management console via a direct link to the OT sensor. |

+The usage of available PCAP storage space depends on factors such as the number of alerts, the type of the alert, and the network bandwidth, all of which affect the size of the PCAP file.

+> [!TIP]

+> To avoid being dependent on the sensor's storage capacity, use external storage to back up your PCAP data.

+## Security recommendation retention

+Defender for IoT security recommendations are stored only on the Azure portal, for 90 days from when the recommendation is first detected.

+For more information, see [Enhance security posture with security recommendations](recommendations.md).

+## OT event timeline retention

+OT event timeline data is stored on OT network sensors only, and the storage capacity differs depending on the sensor's [hardware profile](ot-appliance-sizing.md).

+The retention of event timeline data isn't limited by time. However, assuming a frequency of 500 events per day, all hardware profiles will be able to retain the events for at least **90 day**s.

+If a sensor exceeds its maximum storage size, the oldest event timeline data file is deleted to accommodate the new one.

+The following table lists the maximum number of events that can be stored for each hardware profile:

+| Hardware profile | Number of events |

+|||

+| **C5600** | 10M events |

+| **E1800** | 10M events |

+| **E1000** | 6M events |

+| **E500** | 6M events |

+| **L500** | 3M events |

+| **L100** | 500-K events |

+| **L60** | 500-K events |

+For more information, see [Track sensor activity](how-to-track-sensor-activity.md) and [Pre-configured physical appliances for OT monitoring](ot-pre-configured-appliances.md).

+## OT log file retention

+Service and processing log files are stored on the Azure portal for 30 days from their creation date.

+Other OT monitoring log files are stored only on the OT network sensor and the on-premises management console.

+For more information, see:

+- [Troubleshoot the sensor and on-premises management console](how-to-troubleshoot-the-sensor-and-on-premises-management-console.md)

+- [Download a diagnostics log for support](how-to-manage-individual-sensors.md#download-a-diagnostics-log-for-support)

+## On-premises backup file capacity

+Both the OT network sensor and the on-premises management console have automated backups running daily.

+On both the OT sensor and the on-premises management console, older backup files are overridden when the configured storage capacity has reached its maximum.

+For more information, see:

+- [Set up backup and restore files](how-to-manage-individual-sensors.md#set-up-backup-and-restore-files)

+- [Configure backup settings for an OT network sensor](how-to-manage-individual-sensors.md#set-up-backup-and-restore-files)

+- [Configure OT sensor backup settings from an on-premises management console](how-to-manage-sensors-from-the-on-premises-management-console.md#backup-storage-for-sensors)

+- [Configure backup settings for an on-premises management console](how-to-manage-the-on-premises-management-console.md#define-backup-and-restore-settings)

+### Backups on the OT network sensor

+The retention of backup files depends on the sensor's architecture, as each hardware profile has a set amount of hard disk space allocated for backup history:

+| Hardware profile | Allocated hard disk space |

+|||

+| **L60** | Backups are not supported |

+| **L100** | Backups are not supported |

+| **L500** | 20 GB |

+| **E1000** | 60 GB |

+| **E1800** | 100 GB |

+| **C5600** | 100 GB |

+If the device doesn't have allocated hard disk space, then only the last backup will be saved on the on-premises management console.

+### Backups on the on-premises management console

+Allocated hard disk space for on-premises management console backup files is limited to 10 GB and to only 20 backups.

+If you're using an on-premises management console, each connected OT sensor also has its own, extra backup directory on the on-premises management console:

+- A single sensor backup file is limited to a maximum of 40 GB. A file exceeding that size won't be sent to the on-premises management console.

+- Total hard disk space allocated to sensor backup from all sensors on the on-premises management console is 100 GB.

+## Next steps

+For more information, see:

+- [Manage individual OT network sensors](how-to-manage-individual-sensors.md)

+- [Manage OT network sensors from an on-premises management console](how-to-manage-sensors-from-the-on-premises-management-console.md)

+- [Manage an on-premises management console](how-to-manage-the-on-premises-management-console.md)

+- [Define and view OT sensor settings from the Azure portal](configure-sensor-settings-portal.md)

+| **[View Defender for IoT settings](configure-sensor-settings-portal.md)** <br>Apply per subscription | Γ£ö | Γ£ö |Γ£ö | Γ£ö |

+| **[Configure Defender for IoT settings](configure-sensor-settings-portal.md)** <br>Apply per subscription | - | Γ£ö |Γ£ö | Γ£ö |

+| **OT networks** | **Cloud features**: [Alerts page GA in the Azure portal](#alerts-ga-in-the-azure-portal) <br><br> **Sensor version 22.2.3**: [Configure OT sensor settings from the Azure portal (Public preview)](#configure-ot-sensor-settings-from-the-azure-portal-public-preview) |

+| **Enterprise IoT networks** | **Cloud features**: [Alerts page GA in the Azure portal](#alerts-ga-in-the-azure-portal) |

+### Configure OT sensor settings from the Azure portal (Public preview)

+For sensor versions 22.2.3 and higher, you can now configure selected settings for cloud-connected sensors using the new **Sensor settings (Preview)** page, accessed via the Azure portal's **Sites and sensors** page. For example:

+For more information, see [Define and view OT sensor settings from the Azure portal (Public preview)](configure-sensor-settings-portal.md).

+|**OT networks** |**Sensor version 22.3.4**: [Azure connectivity status shown on OT sensors](#azure-connectivity-status-shown-on-ot-sensors)<br><br>**Sensor version 22.2.3**: [Update sensor software from the Azure portal](#update-sensor-software-from-the-azure-portal-public-preview) |

+You can view the full language specs for DTDL in GitHub: [Digital Twins Definition Language (DTDL) - Version 2 Reference](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md). This page includes detailed DTDL reference and examples to help you get started writing your own DTDL models.

+| `@id` | A [Digital Twin Model Identifier (DTMI)](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#digital-twin-model-identifier) for the model. Must be in the format `dtmi:<domain>:<unique-model-identifier>;<model-version-number>`. |

+> The [spec for DTDL](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) also defines *Commands*, which are methods that can be executed on a digital twin (like a reset command, or a command to switch a fan on or off). However, commands are not currently supported in Azure Digital Twins.

+For comprehensive information about the fields that may appear as part of a property, see [Property in the DTDL V2 Reference](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#property). For comprehensive information about the fields that may appear as part of telemetry, see [Telemetry in the DTDL V2 Reference](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#telemetry).

+Semantic types make it possible to express a value with a unit. Properties and telemetry can be represented with any of the semantic types that are supported by DTDL. For more information on semantic types in DTDL and what values are supported, see [Semantic types in the DTDL V2 Reference](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#semantic-type).

+For a comprehensive list of the fields that may appear as part of a relationship, see [Relationship in the DTDL V2 Reference](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#relationship).

+For a comprehensive list of the fields that may appear as part of a component, see [Component in the DTDL V2 Reference](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#component).

+There's a sample application available that converts an RDF-based model file to [DTDL (version 2)](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) for use by the Azure Digital Twins service. It has been validated for the [Brick](https://brickschema.org/ontology/) schema, and can be extended for other schemas in the building industry (such as [Building Topology Ontology (BOT)](https://w3c-lbd-cg.github.io/bot/), [Semantic Sensor Network](https://www.w3.org/TR/vocab-ssn/), or [buildingSmart Industry Foundation Classes (IFC)](https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/)).

+Because models in Azure Digital Twins are represented in [Digital Twins Definition Language (DTDL)](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md), ontologies for use with Azure Digital Twins are also written in DTDL.

+The table below shows the possible data types and their corresponding icons. The table also contains links from each data type to its schema description in the [DTDL spec](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#schema).

+|  |

+|  |

+|  |

+|  |

+|  |

+|  |

+|  |

+|  |

+|  |

+|  |

+|  |

+Marker tags are modeled as a [DTDL](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) Map from `string` to `boolean`. The boolean `mapValue` is ignored, as the presence of the tag is all that's important.

+Value tags are modeled as a [DTDL](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) Map from `string` to `string`. Both the `mapKey` and the `mapValue` are significant.

+You can think of these model definitions as a specialized vocabulary to describe your business. For a building management solution, for example, you might define a model that defines a Building type, a Floor type, and an Elevator type. Models are defined in a JSON-like language called [Digital Twins Definition Language (DTDL)](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md), and they describe types of entities according to their state properties, telemetry events, commands, components, and relationships. You can design your own model sets from scratch, or get started with a pre-existing set of [DTDL industry ontologies](concepts-ontologies.md) based on common vocabulary for your industry.

+ Title: Troubleshoot manifest ingestion in Microsoft Energy Data Services Preview #Required; this page title is displayed in search results; Always include the word "troubleshoot" in this line.

+description: Find out how to troubleshoot manifest ingestion using Airflow task logs #Required; this article description is displayed in search results.

+# Troubleshoot manifest ingestion issues using Airflow task logs

+This article helps you troubleshoot manifest ingestion workflow issues in Microsoft Energy Data Services Preview instance using the Airflow task logs.

+## Manifest ingestion DAG workflow types

+The Manifest ingestion workflow is of two types:

+- Single manifest

+- Batch upload

+### Single manifest

+One single manifest file is used to trigger the manifest ingestion workflow.

+|DagTaskName |Description |

+|||

+|**Update_status_running_task** | Calls Workflow service and marks the status of DAG as running in the database |

+|**Check_payload_type** | Validates whether the ingestion is of batch type or single manifest|

+|**Validate_manifest_schema_task** | Ensures all the schema kinds mentioned in the manifest are present and there's referential schema integrity. All invalid values will be evicted from the manifest |

+|**Provide_manifest_intergrity_task** | Validates references inside the OSDU&trade; R3 manifest and removes invalid entities. This operator is responsible for parent-child validation. All orphan-like entities will be logged and excluded from the validated manifest. Any external referenced records will be searched and in case not found, the manifest entity will be dropped. All surrogate key references are also resolved |

+|**Process_single_manifest_file_task** | Performs ingestion of the final obtained manifest entities from the previous step, data records will be ingested via the storage service |

+|**Update_status_finished_task** | Calls workflow service and marks the status of DAG as `finished` or `failed` in the database |

+### Batch upload

+Multiple manifest files are part of the same workflow service request, that is, the manifest section in the request payload is a list instead of a dictionary of items.

+|DagTaskName |Description |

+|||

+|**Update_status_running_task** | Calls Workflow service and marks the status of DAG as running in the database |

+|**Check_payload_type** | Validates whether the ingestion is of batch type or single manifest|

+|**Batch_upload** | List of manifests are divided into three batches to be processed in parallel (no task logs are emitted) |

+|**Process_manifest_task_(1 / 2 / 3)** | List of manifests is divided into groups of three and processed by these tasks. All the steps performed in Validate_manifest_schema_task, Provide_manifest_intergrity_task, Process_single_manifest_file_task are condensed and performed sequentially in these tasks |

+|**Update_status_finished_task** | Calls workflow service and marks the status of DAG as `finished` or `failed` in the database |

+

+Based on the payload type (single or batch), `check_payload_type` task will pick the appropriate branch and the tasks in the other branch will be skipped.

+## Prerequisites

+You should have integrated airflow task logs with Azure monitor. See [Integrate airflow logs with Azure Monitor](how-to-integrate-airflow-logs-with-azure-monitor.md)

+Following columns are exposed in Airflow Task Logs for you to debug the issue:

+|Parameter Name |Description |

+|||

+|**Run Id** | Unique run ID of the DAG run, which was triggered |

+|**Correlation ID** | Unique correlation ID of the DAG run (same as run ID) |

+|**DagName** | DAG workflow name. For instance, `Osdu_ingest` for manifest ingestion |

+|**DagTaskName** | DAG workflow task name. For instance, `Update_status_running_task` for manifest ingestion |

+|**Content** | Contains error log messages (errors/exceptions) emitted by Airflow during the task execution|

+|**LogTimeStamp** | Captures the time interval of DAG runs |

+|**LogLevel** | DEBUG/INFO/WARNING/ERROR. Mostly all exception and error messages can be seen by filtering at ERROR level |

+## Cause 1: A DAG run has failed in the Update_status_running_task or Update_status_finished_task

+The workflow run has failed and the data records weren't ingested.

+**Possible reasons**

+* Provided incorrect data partition ID

+* Provided incorrect key name in the execution context of the request body

+* Workflow service isn't running or throwing 5xx errors

+**Workflow status**

+* Workflow status is marked as `failed`.

+### Solution: Check the airflow task logs for `update_status_running_task` or `update_status_finished_task`. Fix the payload (pass the correct data partition ID or key name)

+**Sample Kusto query**

+```kusto

+ AirflowTaskLogs

+ | where DagName == "Osdu_ingest"

+ | where DagTaskName == "update_status_running_task"

+ | where LogLevel == "ERROR" // ERROR/DEBUG/INFO/WARNING

+ | where RunID == '<run_id>'

+```

+**Sample trace output**

+```md

+ [2023-02-05, 12:21:54 IST] {taskinstance.py:1703} ERROR - Task failed with exception

+ Traceback (most recent call last):

+ File "/home/airflow/.local/lib/python3.8/site-packages/osdu_ingestion/libs/context.py", line 50, in populate

+ data_partition_id = ctx_payload['data-partition-id']

+ KeyError: 'data-partition-id'

+

+ requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: https://it1672283875.oep.ppe.azure-int.net/api/workflow/v1/workflow/Osdu_ingest/workflowRun/e9a815f2-84f5-4513-9825-4d37ab291264

+```

+## Cause 2: Schema validation failures

+Records weren't ingested due to schema validation failures.

+**Possible reasons**

+* Schema not found errors

+* Manifest body not conforming to the schema kind

+* Incorrect schema references

+* Schema service throwing 5xx errors

+

+**Workflow Status**

+* Workflow status is marked as `finished`. No failure in the workflow status will be observed because the invalid entities are skipped and the ingestion is continued.

+### Solution: Check the airflow task logs for `validate_manifest_schema_task` or `process_manifest_task`. Fix the payload (pass the correct data partition ID or key name)

+**Sample Kusto query**

+```kusto

+ AirflowTaskLogs

+ | where DagName has "Osdu_ingest"

+ | where DagTaskName == "validate_manifest_schema_task" or DagTaskName has "process_manifest_task"

+ | where LogLevel == "ERROR"

+ | where RunID == "<run_id>"

+ | order by ['time'] asc

+```

+**Sample trace output**

+```md

+ Error traces to look out for

+ [2023-02-05, 14:55:37 IST] {connectionpool.py:452} DEBUG - https://it1672283875.oep.ppe.azure-int.net:443 "GET /api/schema-service/v1/schema/osdu:wks:work-product-component--WellLog:2.2.0 HTTP/1.1" 404 None

+ [2023-02-05, 14:55:37 IST] {authorization.py:137} ERROR - {"error":{"code":404,"message":"Schema is not present","errors":[{"domain":"global","reason":"notFound","message":"Schema is not present"}]}}

+ [2023-02-05, 14:55:37 IST] {validate_schema.py:170} ERROR - Error on getting schema of kind 'osdu:wks:work-product-component--WellLog:2.2.0'

+ [2023-02-05, 14:55:37 IST] {validate_schema.py:171} ERROR - 404 Client Error: Not Found for url: https://it1672283875.oep.ppe.azure-int.net/api/schema-service/v1/schema/osdu:wks:work-product-component--WellLog:2.2.0

+ [2023-02-05, 14:55:37 IST] {validate_schema.py:314} WARNING - osdu:wks:work-product-component--WellLog:2.2.0 is not present in Schema service.

+ [2023-02-05, 15:01:23 IST] {validate_schema.py:322} ERROR - Schema validation error. Data field.

+ [2023-02-05, 15:01:23 IST] {validate_schema.py:323} ERROR - Manifest kind: osdu:wks:work-product-component--WellLog:1.1.0

+ [2023-02-05, 15:01:23 IST] {validate_schema.py:324} ERROR - Error: 'string-value' is not of type 'number'

+

+ Failed validating 'type' in schema['properties']['data']['allOf'][3]['properties']['SamplingStop']:

+ {'description': 'The stop value/last value of the ReferenceCurveID, '

+ 'typically the end depth of the logging.',

+ 'example': 7500,

+ 'title': 'Sampling Stop',

+ 'type': 'number',

+ 'x-osdu-frame-of-reference': 'UOM'}

+

+ On instance['data']['SamplingStop']:

+ 'string-value'

+```

+## Cause 3: Failed reference checks

+Records weren't ingested due to failed reference checks.

+**Possible reasons**

+* Failed to find referenced records

+* Parent records not found

+* Search service throwing 5xx errors

+

+**Workflow Status**

+* Workflow status is marked as `finished`. No failure in the workflow status will be observed because the invalid entities are skipped and the ingestion is continued.

+### Solution: Check the airflow task logs for `provide_manifest_integrity_task` or `process_manifest_task`.

+**Sample Kusto query**

+```kusto

+ AirflowTaskLogs

+ | where DagName has "Osdu_ingest"

+ | where DagTaskName == "provide_manifest_integrity_task" or DagTaskName has "process_manifest_task"

+ | where Content has 'Search query "'or Content has 'response ids: ['

+ | where RunID has "<run_id>"

+```

+**Sample trace output**

+Since there are no such error logs specifically for referential integrity tasks, you should watch out for the debug log statements to see whether all external records were fetched using the search service.

+For instance, the output shows record queried using the Search service for referential integrity

+```md

+ [2023-02-05, 19:14:40 IST] {search_record_ids.py:75} DEBUG - Search query "it1672283875-dp1:work-product-component--WellLog:5ab388ae0e140838c297f0e6559" OR "it1672283875-dp1:work-product-component--WellLog:5ab388ae0e1b40838c297f0e6559" OR "it1672283875-dp1:work-product-component--WellLog:5ab388ae0e1b40838c297f0e6559758a"

+```

+The records that were retrieved and were in the system are shown in the output. The related manifest object that referenced a record would be dropped and no longer be ingested if we noticed that some of the records weren't present.

+```md

+ [2023-02-05, 19:14:40 IST] {search_record_ids.py:141} DEBUG - response ids: ['it1672283875-dp1:work-product-component--WellLog:5ab388ae0e1b40838c297f0e6559758a:1675590506723615', 'it1672283875-dp1:work-product-component--WellLog:5ab388ae0e1b40838c297f0e6559758a ']

+```

+In the coming release, we plan to enhance the logs by appropriately logging skipped records with reasons

+## Cause 4: Invalid Legal Tags/ACLs in manifest

+Records weren't ingested due to invalid legal tags or ACLs present in the manifest.

+**Possible reasons**

+* Incorrect ACLs

+* Incorrect legal tags

+* Storage service throws 5xx errors

+

+**Workflow Status**

+* Workflow status is marked as `finished`. No failure in the workflow status will be observed.

+### Solution: Check the airflow task logs for `process_single_manifest_file_task` or `process_manifest_task`.

+**Sample Kusto query**

+```kusto

+ AirflowTaskLogs

+ | where DagName has "Osdu_ingest"

+ | where DagTaskName == "process_single_manifest_file_task" or DagTaskName has "process_manifest_task"

+ | where LogLevel == "ERROR"

+ | where RunID has "<run_id>"

+ | order by ['time'] asc

+```

+**Sample trace output**

+```md

+ "PUT /api/storage/v2/records HTTP/1.1" 400 None

+ [2023-02-05, 16:57:05 IST] {authorization.py:137} ERROR - {"code":400,"reason":"Invalid legal tags","message":"Invalid legal tags: it1672283875-dp1-R3FullManifest-Legal-Tag-Test779759112"}

+

+```

+and the output indicates records that were retrieved. Manifest entity records corresponding to missing search records will get dropped and not ingested.

+```md

+ "PUT /api/storage/v2/records HTTP/1.1" 400 None

+ [2023-02-05, 16:58:46 IST] {authorization.py:137} ERROR - {"code":400,"reason":"Validation error.","message":"createOrUpdateRecords.records[0].acl: Invalid group name 'data1.default.viewers@it1672283875-dp1.dataservices.energy'"}

+ [2023-02-05, 16:58:46 IST] {single_manifest_processor.py:83} WARNING - Can't process entity SRN: surrogate-key:0ef20853-f26a-456f-b874-3f2f5f35b6fb

+```

+## Known issues

+- Exception traces weren't exporting with Airflow Task Logs due to a known problem in the logs; the patch has been submitted and will be included in the February release.

+- Since there are no specific error logs for referential integrity tasks, you must manually search for the debug log statements to see whether all external records were retrieved via the search service. We intend to improve the logs in the upcoming release by properly logging skipped data with justifications.

+## Next steps

+Advance to the manifest ingestion tutorial and learn how to perform a manifest-based file ingestion

+> [!div class="nextstepaction"]

+> [Tutorial: Sample steps to perform a manifest-based file ingestion](tutorial-manifest-ingestion.md)

+## Reference

+- [Manifest-based ingestion concepts](concepts-manifest-ingestion.md)

+- [Ingestion DAGs](https://community.opengroup.org/osdu/platform/data-flow/ingestion/ingestion-dags/-/blob/master/README.md#operators-description)

+6. Some aspects of the management plane for the secondary namespace become read-only while geo-recovery pairing is active.

+7. The data plane of the secondary namespace will be read-only while geo-recovery pairing is active. The data plane of the secondary namespace will accept GET requests to enable validation of client connectivity and access controls.

+For more information about Azure Firewall Availability Zones, see [Azure Firewall Standard features](features.md#availability-zones).

+There's no extra cost for a firewall deployed in more than one Availability Zone. However, there are added costs for inbound and outbound data transfers associated with Availability Zones. For more information, see [Bandwidth pricing details](https://azure.microsoft.com/pricing/details/bandwidth/).

+As the firewall scales, it creates instances in the zones it's in. So, if the firewall is in Zone 1 only, new instances are created in Zone 1. If the firewall is in all three zones, then it creates instances across the three zones as it scales.

+The specified FQDNs in your rule collections are translated to IP addresses based on your firewall DNS settings. This capability allows you to filter outbound traffic using FQDNs with any TCP/UDP protocol (including NTP, SSH, RDP, and more). As this capability is based on DNS resolution, it's highly recommended you enable the DNS proxy to ensure name resolution is consistent with your protected virtual machines and firewall.

+In such cases, you can deploy Azure Firewall in Forced Tunnel mode. This configuration creates a management NIC that is used by Azure Firewall for its operations. The Tenant Datapath network can be configured without a public IP address, and Internet traffic can be forced tunneled to another firewall or completely blocked.

+Forced Tunnel mode can't be configured at run time. You can either redeploy the Firewall or use the stop and start facility to reconfigure an existing Azure Firewall in Forced Tunnel mode. Firewalls deployed in Secure Hubs are always deployed in Forced Tunnel mode.

+All events are integrated with Azure Monitor, allowing you to archive logs to a storage account, stream events to your event hub, or send them to Azure Monitor logs. For Azure Monitor log samples, see [Azure Monitor logs for Azure Firewall](./firewall-workbook.md).

+You can define allowlists so threat intelligence won't filter traffic to any of the listed FQDNs, IP addresses, ranges, or subnets.

+For a batch operation, you can upload a CSV file with list of IP addresses, ranges, and subnets.

+- **Inbound testing** - You can expect to see alerts on incoming traffic if DNAT rules are configured on the firewall. You'll see alerts even if only specific sources are allowed on the DNAT rule and traffic is otherwise denied. Azure Firewall doesn't alert on all known port scanners; only on scanners that are known to also engage in malicious activity.

+| Queries not providing consistent result counts after appended with `_sort` operator. For more information, see [#2680](https://github.com/microsoft/fhir-server/pull/2680). | July 2022 | No workaround|August 2022 Resolved |

+## **December 2022**

+#### Azure Health Data Services

+#### DICOM service

+## **November 2022**

+#### FHIR service

+#### Toolkit and Samples Open Source

+## **October 2022**

+#### MedTech service

+## **September 2022**

+#### Azure Health Data Services

+**Fixed issue where Querying with :not operator was returning more results than expected**

+The issue is now fixed and querying with :not operator should provide correct results. For more information, see [#2790](https://github.com/microsoft/fhir-server/pull/2785). |

+#### FHIR Service

+**Provided an Error message for failure in export resulting from long time span**

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

+**Fixed issue in a query sort, where functionality throws an error when chained search is performed with same field value.**

+The functionality now returns a response. For more information, see [#2794](https://github.com/microsoft/fhir-server/pull/2794).

+**Fixed issue where Server doesn't indicate `_text` not supported**

+ When passed as URL parameter,`_text` returns an error in response when using the `Prefer` heading with `value handling=strict`. For more information, see [#2779](https://github.com/microsoft/fhir-server/pull/2779).

+**Added a Verbose error message for invalid resource type**

+Verbose error message is added when resource type is invalid or empty for `_include` and `_revinclude` searches. For more information, see [#2776](https://github.com/microsoft/fhir-server/pull/2776).

+#### DICOM service

+**Export is Generally Available (GA)**

+The export feature for the DICOM service is now generally available. Export enables a user-supplied list of studies, series, and/or instances to be exported in bulk to an Azure Storage account. Learn more about the [export feature](dicom/export-dicom-files.md).

+**Improved deployment performance**

+Performance improvements have cut the time to deploy new instances of the DICOM service by more than 55% at the 50th percentile.

+**Reduced strictness when validating STOW requests**

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

+The service will now accept the following:

+* DICOM UIDs that contain trailing whitespace

+* IS, DS, SV, and UV VRs that are not valid numbers

+* Invalid private creator tags

+#### Toolkit and Samples Open Source

+**The [Azure Health Data Services Toolkit](https://github.com/microsoft/azure-health-data-services-toolkit) is now in the public preview.**

+The toolkit is open-source and allows to easily customize and extend the functionality of their Azure Health Data Services implementations.

+## **August 2022**

+#### FHIR service

+**Azure Health Data services availability expands to new regions**

+ Azure Health Data services is now available in the following regions: Central India, Korea Central, and Sweden Central.

+

+**`$import` is Generally Available.**

+ `$import` API is now generally available in Azure Health Data Services API version 2022-06-01. See [Executing the import](./../healthcare-apis/fhir/import-data.md) by invoking the `$import` operation on FHIR service in Azure Health Data Services.

+**`$convert-data` updated by adding STU3-R4 support.**

+`$convert-data` added support for FHIR STU3-R4 conversion. See [Data conversion for Azure API for FHIR](./../healthcare-apis/azure-api-for-fhir/convert-data.md).

+

+**Analytics pipeline now supports data filtering.**

+ Data filtering is now supported in FHIR to data lake pipeline. See [FHIR-Analytics-Pipelines_Filter FHIR data](https://github.com/microsoft/FHIR-Analytics-Pipelines/blob/main/FhirToDataLake/docs/Filter%20FHIR%20data%20in%20pipeline.md) microsoft/FHIR-Analytics-Pipelines github.com.

+**Analytics pipeline now supports FHIR extensions.**

+Analytics pipeline can process FHIR extensions to generate parquet data. See [FHIR-Analytics-Pipelines_Process](https://github.com/microsoft/FHIR-Analytics-Pipelines/blob/main/FhirToDataLake/docs/Process%20FHIR%20extensions.md) in pipeline.md at main.

+**Fixed issue related to History bundles being sorted with the oldest version first.**

+We've recently identified an issue with the sorting order of history bundles on FHIR® server. History bundles were sorted with the oldest version first. Per FHIR specification, the sorting of versions defaults to the oldest version last.This bug fix, addresses FHIR server behavior for sorting history bundle. <br><br>We understand if you would like to keep the sorting per existing behavior (oldest version first). To support existing behavior, we recommend you append `_sort=_lastUpdated` to the HTTP GET command utilized for retrieving history. <br><br>For example: `<server URL>/_history?_sort=_lastUpdated` <br><br>For more information, see [#2689](https://github.com/microsoft/fhir-server/pull/2689).

+**Fixed issue where Queries were not providing consistent result count after appended with `_sort` operator.**

+The issue is now fixed and queries should provide consistent result count, with and without sort operator.

+#### MedTech service

+**Added New Metric Chart**

+Customers can now see predefined metrics graphs in the MedTech landing page, complete with alerts to ease customers' burden of monitoring their MedTech service.

+**Availability of Diagnostic Logs**

+There are now pre-defined queries with relevant logs for common issues so that customers can easily debug and diagnose issues in their MedTech service.

+#### DICOM service

+**Modality worklists (UPS-RS) is Generally Available (GA)**.

+The modality worklists (UPS-RS) service is now generally available. Learn more about the [worklists service](./../healthcare-apis/dicom/dicom-services-conformance-statement.md).

+## July 2022

+#### FHIR service

+**(Open Source) History bundles were sorted with the oldest version first.**

+We've recently identified an issue with the sorting order of history bundles on FHIR® server. History bundles were sorted with the oldest version first. Per [FHIR specification](https://hl7.org/fhir/http.html#history), the sorting of versions defaults to the oldest version last. This bug fix, addresses FHIR server behavior for sorting history bundle.<br /><br />We understand if you would like to keep the sorting per existing behavior (oldest version first). To support existing behavior, we recommend you append `_sort=_lastUpdated` to the HTTP `GET` command utilized for retrieving history. <br /><br />For example: `<server URL>/_history?_sort=_lastUpdated` <br /><br />For more information, see [#2689](https://github.com/microsoft/fhir-server/pull/2689).

+**Improvements to documentations for Events and MedTech and availability zones.**

+Tested and enhanced usability and functionality. Added new documents to enable customers to better take advantage of the new improvements. See [Consume Events with Logic Apps](./../healthcare-apis/events/events-deploy-portal.md) and [Deploy Events Using the Azure portal](./../healthcare-apis/events/events-deploy-portal.md).

+**One touch launch Azure MedTech deploy.**

+[Deploy the MedTech Service in the Azure portal](./../healthcare-apis/iot/deploy-iot-connector-in-azure.md)

+#### DICOM service

+**DICOM Service availability expands to new regions.**

+The DICOM Service is now available in the following [regions](https://azure.microsoft.com/global-infrastructure/services/): Southeast Asia, Central India, Korea Central, and Switzerland North.

+**Fast retrieval of individual DICOM frames**

+For DICOM images containing multiple frames, performance improvements have been made to enable fast retrieval of individual frames (60 KB frames as fast as 60 MS). These improved performance characteristics enable workflows such as [viewing digital pathology images](https://microsofthealth.visualstudio.com/DefaultCollection/Health/_git/marketing-azure-docs?version=GBmain&path=%2Fimaging%2Fdigital-pathology%2FDigital%20Pathology%20using%20Azure%20DICOM%20service.md&_a=preview), which require rapid retrieval of individual frames.

+#### FHIR service

+**Fixed issue with Export Job not being queued for execution.**

+Fixes issue with export job not being queued due to duplicate job definition caused due to reference to container URL. For more information, see [#2648](https://github.com/microsoft/fhir-server/pull/2648).

+**Fixed issue related to Queries not providing consistent result count after appended with the `_sort` operator.**

+Fixes the issue with the help of distinct operator to resolve inconsistency and record duplication in response. For more information, see [#2680](https://github.com/microsoft/fhir-server/pull/2680).

+#### FHIR service

+**Removes SQL retry on upsert**

+Removes retry on SQL command for upsert. The error still occurs, but data is saved correctly in success cases. For more information, see [#2571](https://github.com/microsoft/fhir-server/pull/2571).

+**Added handling for SqlTruncate errors**

+Added a check for SqlTruncate exceptions and tests. In particular, exceptions and tests will catch SqlTruncate exceptions for Decimal type based on the specified precision and scale. For more information, see [#2553](https://github.com/microsoft/fhir-server/pull/2553).

+#### DICOM service

+**DICOM service supports cross-origin resource sharing (CORS)**

+DICOM service now supports [CORS](./../healthcare-apis/dicom/configure-cross-origin-resource-sharing.md). CORS allows you to configure settings so that applications from one domain (origin) can access resources from a different domain, known as a cross-domain request.

+**DICOMcast supports Private Link**

+DICOMcast has been updated to support Azure Health Data Services workspaces that have been configured to use [Private Link](./../healthcare-apis/healthcare-apis-configure-private-link.md).

+**UPS-RS supports Change and Retrieve work item**

+Modality worklist (UPS-RS) endpoints have been added to support Change and Retrieve operations for work items.

+**API version is now required as part of the URI**

+All REST API requests to the DICOM service must now include the API version in the URI. For more information, see [API versioning for DICOM service](./../healthcare-apis/dicom/api-versioning-dicom-service.md).

+**Index the first value for DICOM tags that incorrectly specify multiple values**

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

+#### FHIR service

+** Added FHIRPath Patch**

+FHIRPath Patch was added as a feature to both the Azure API for FHIR. This implements FHIRPath Patch as defined on the [HL7](http://hl7.org/fhir/fhirpatch.html) website.

+**Handles invalid header on versioned update**

+ When the versioning policy is set to "versioned-update", we required that the most recent version of the resource is provided in the request's if-match header on an update. The specified version must be in ETag format. Previously, a 500 would be returned if the version was invalid or in an incorrect format. This update now returns a 400 Bad Request. For more information, see [PR #2467](https://github.com/microsoft/fhir-server/pull/2467).

+**Bulk import in public preview**

+The bulk-import feature enables importing FHIR data to the FHIR server at high throughput using the $import operation. It's designed for initial data load into the FHIR server. For more information, see [Bulk-import FHIR data (Preview)](./../healthcare-apis/fhir/import-data.md).

+**Added back the core to resource path**

+ Part of the path to a string resource was accidentally removed in the versioning policy. This fix adds it back in. For more information, see [PR #2470](https://github.com/microsoft/fhir-server/pull/2470).

+#### DICOM service

+**Reduced the strictness of validation applied to incoming DICOM files**

+When value representation (VR) is a decimal string (DS)/ integer string (IS), `fo-dicom` serialization treats value as a number. Customer DICOM files could be old and contains invalid numbers. Our service blocks such file upload due to the serialization exception. For more information, see [PR #1450](https://github.com/microsoft/dicom-server/pull/1450).

+**Correctly parse a range of input in the content negotiation headers**

+Currently, WADO with Accept: multipart/related; type=application/dicom will throw an error. It will accept Accept: multipart/related; type="application/dicom", but they should be equivalent. For more information, see [PR #1462](https://github.com/microsoft/dicom-server/pull/1462).

+**Fixed an issue where parallel upload of images in a study could fail under certain circumstances**

+Handle race conditions during parallel instance inserts in the same study. For more information, see [PR #1491](https://github.com/microsoft/dicom-server/pull/1491) and [PR #1496](https://github.com/microsoft/dicom-server/pull/1496).

+## March 2022

+#### Azure Health Data Services

+**Private Link is now available**

+With Private Link, you can access Azure Health Data Services securely from your VNet as a first-party service without having to go through a public Domain Name System (DNS). For more information, see [Configure Private Link for Azure Health Data Services](./../healthcare-apis/healthcare-apis-configure-private-link.md).

+**FHIRPath Patch operation available**

+|This new feature enables you to use the FHIRPath Patch operation on FHIR resources. For more information, see [FHIR REST API capabilities for Azure Health Data Services FHIR service](./../healthcare-apis/fhir/fhir-rest-api-capabilities.md).

+**SQL timeout that returns 408 status code**

+Previously, a SQL timeout would return a 500. Now a timeout in SQL will return a FHIR OperationOutcome with a 408 status code. For more information, see [PR #2497](https://github.com/microsoft/fhir-server/pull/2497).

+**Fixed issue related to duplicate resources in search with `_include`**

+Fixed issue where a single resource can be returned twice in a search that has `_include`. For more information, see [PR #2448](https://github.com/microsoft/fhir-server/pull/2448).

+**Fixed issue PUT creates on versioned update**

+Fixed issue where creates with PUT resulted in an error when the versioning policy is configured to `versioned-update`. For more information, see [PR #2457](https://github.com/microsoft/fhir-server/pull/2457).

+**Invalid header handling on versioned update**

+ Fixed issue where invalid `if-match` header would result in an HTTP 500 error. Now an HTTP Bad Request is returned instead. For more information, see [PR #2467](https://github.com/microsoft/fhir-server/pull/2467).

+#### MedTech service

+**The Events feature within Health Data Services is now generally available (GA).**

+ The Events feature allows customers to receive notifications and triggers when FHIR observations are created, updated, or deleted. For more information, see [Events message structure](./../healthcare-apis/events/events-message-structure.md) and [What are events?](./../healthcare-apis/events/events-overview.md).

+**Events documentation for Azure Health Data Services**

+Updated docs to allow for better understanding, knowledge, and help for Events as it went GA. Updated troubleshooting for ease of use for the customer.

+**One touch deploy button for MedTech service launch in the portal**

+Enables easier deployment and use of MedTech service for customers without the need to go back and forth between pages or interfaces.

+**Export FHIR data behind firewalls**

+This new feature enables exporting FHIR data to storage accounts behind firewalls. For more information, see [Configure export settings and set up a storage account](./././fhir/configure-export-data.md).

+**Deploy Azure Health Data Services with Azure Bicep**

+This new feature enables you to deploy Azure Health Data Services using Azure Bicep. For more information, see [Deploy Azure Health Data Services using Azure Bicep](deploy-healthcare-apis-using-bicep.md).

+#### DICOM service

+**Customers can define their own query tags using the Extended Query Tags feature**

+With Extended Query Tags feature, customers now efficiently query non-DICOM metadata for capabilities like multi-tenancy and cohorts. It's available for all customers in Azure Health Data Services.

+#### Azure Health Data Services

+**Quota details for support requests**

+We've updated the quota details for customer support requests with the latest information.

+**Local RBAC documentation updated **

+We've updated the local RBAC documentation to clarify the use of the secondary tenant and the steps to disable it.

+**Deploy and configure Azure Health Data Services using scripts**

+We've started the process of providing PowerShell, CLI scripts, and ARM templates to configure app registration and role assignments. Scripts for deploying Azure Health Data Services will be available after GA.

+#### FHIR service

+**Added Publisher to `CapabilityStatement.name`**

+You can now find the publisher in the capability statement at `CapabilityStatement.name`. [#2319](https://github.com/microsoft/fhir-server/pull/2319)

+**Log `FhirOperation` linked to anonymous calls to Request metrics**

+ We weren't logging operations that didnΓÇÖt require authentication. We extended the ability to get `FhirOperation` type in `RequestMetrics` for anonymous calls. [#2295](https://github.com/microsoft/fhir-server/pull/2295)

+**Fixed 500 error when `SearchParameter` Code is null**

+Fixed an issue with `SearchParameter` if it had a null value for Code, the result would be a 500. Now it will result in an `InvalidResourceException` like the other values do. [#2343](https://github.com/microsoft/fhir-server/pull/2343)

+

+**Returned `BadRequestException` with valid message when input JSON body is invalid**

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

+**Handled SQL Timeout issue**

+If SQL Server timed out, the PUT `/resource{id}` returned a 500 error. Now we handle the 500 error and return a timeout exception with an operation outcome. [#2290](https://github.com/microsoft/fhir-server/pull/2290)

+#### FHIR service

+**Process Patient-everything links**

+We've expanded the Patient-everything capabilities to process patient links [#2305](https://github.com/microsoft/fhir-server/pull/2305). For more information, see [Patient-everything in FHIR](./../healthcare-apis/fhir/patient-everything.md#processing-patient-links) documentation.

+**Added software name and version to capability statement.**

+In the capability statement, the software name now distinguishes if you're using Azure API for FHIR or Azure Health Data Services. The software version will now specify which open-source [release package](https://github.com/microsoft/fhir-server/releases) is live in the managed service [#2294](https://github.com/microsoft/fhir-server/pull/2294). Addresses: [#1778](https://github.com/microsoft/fhir-server/issues/1778) and [#2241](https://github.com/microsoft/fhir-server/issues/2241)

+**Compress continuation tokens**

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

+**FHIR service autoscale**

+The [FHIR service autoscale](./fhir/fhir-service-autoscale.md) is designed to provide optimized service scalability automatically to meet customer demands when they perform data transactions in consistent or various workloads at any time. It's available in all [regions](https://azure.microsoft.com/global-infrastructure/services/) where the FHIR service is supported.

+**Resolved 500 error when the date was passed with a time zone.**

+This fix addresses a 500 error when a date with a time zone was passed into a datetime field [#2270](https://github.com/microsoft/fhir-server/pull/2270).

+**Resolved issue when posting a bundle with incorrect Media Type returned a 500 error.**

+Previously when posting a search with a key that contains certain characters, a 500 error is returned. This fixes issue [#2264](https://github.com/microsoft/fhir-server/pull/2264) and addresses [#2148](https://github.com/microsoft/fhir-server/issues/2148).

+#### DICOM service

+**Content-Type header now includes transfer-syntax.**

+This enhancement enables the user to know which transfer syntax is used in case multiple accept headers are being supplied.

+#### Azure Health Data Services

+**Test Data Generator tool**

+We've updated Azure Health Data Services GitHub samples repo to include a [Test Data Generator tool](https://github.com/microsoft/healthcare-apis-samples/blob/main/docs/HowToRunPerformanceTest.md) using Synthea data. This tool is an improvement to the open source [public test projects](https://github.com/ShadowPic/PublicTestProjects), based on Apache JMeter that can be deployed to Azure AKS for performance tests.

+#### FHIR service

+**Added support for [_sort](././../healthcare-apis/fhir/overview-of-search.md#search-result-parameters) on strings and dateTime.**

+[#2169](https://github.com/microsoft/fhir-server/pull/2169)

+**Fixed issue where [Conditional Delete](././../healthcare-apis/fhir/fhir-rest-api-capabilities.md#conditional-delete) could result in an infinite loop.**[#2269](https://github.com/microsoft/fhir-server/pull/2269)

+**Resolved 500 error possibly caused by a malformed transaction body in a bundle POST.** We've added a check that the URL is populated in the [transaction bundle](././..//healthcare-apis/fhir/fhir-features-supported.md#rest-api) requests.**[#2255](https://github.com/microsoft/fhir-server/pull/2255)

+#### **DICOM service**

+**Regions**

+**South Brazil and Central Canada.** For more information about Azure regions and availability zones, see [Azure services that support availability zones](https://azure.microsoft.com/global-infrastructure/services/).

+**Extended Query tags**

+DateTime (DT) and Time (TM) Value Representation (VR) types

+**Implemented fix to workspace names.**

+Enabled DICOM service to work with workspaces that have names beginning with a letter.

+#### FHIR service

+|Enhancements | |

+|Allow JSON patch in bundles | |

+| Running a reindex job | |

+|Bug fixes | |

+|Custom search bugs | |

+|Resolved SQL batch reindex if one resource fails | |

+|GitHub issues closed | |

+#### **DICOM service**

+**Implemented fix to resolve QIDO paging-ordering issues** | [#989](https://github.com/microsoft/dicom-server/pull/989) |

+#### **MedTech service**

+**MedTech service normalized improvements with calculations to support and enhance health data standardization.**

+See [Use Device mappings](./../healthcare-apis/iot/how-to-use-device-mappings.md) and [Calculated Content Templates](./../healthcare-apis/iot/how-to-use-calculatedcontenttemplate-mappings.md)

+A device model is defined by using the [DTDL V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) modeling language. This language lets you define:

+The JSON file that defines the device model uses the [Digital Twin Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md). IoT Central expects the JSON file to contain the device model with the interfaces defined inline, rather than in separate files. To learn more, see [IoT Plug and Play modeling guide](../../iot-develop/concepts-modeling-guide.md).

+- The device must be an IoT Plug and Play device that uses a [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) model. IoT Central requires all devices to have a DTDL model. These models simplify the interoperability between an IoT PaaS solution and IoT Central.

+The JSON file that defines the device model uses the [Digital Twin Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md).

+To learn more about the DTDL telemetry naming rules, see [DTDL > Telemetry](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#telemetry). You can't start a telemetry name using the `_` character.

+> The **geopoint** schema type is not part of the [Digital Twins Definition Language specification](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md). IoT Central currently supports the **geopoint** schema type and the **location** semantic type for backwards compatibility.

+To learn more about the DTDL property naming rules, see [DTDL > Property](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#property). You can't start a property name using the `_` character.

+> The **geopoint** schema type is not part of the [Digital Twins Definition Language specification](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md). IoT Central currently supports the **geopoint** schema type and the **location** semantic type for backwards compatibility.

+To learn more about the DTDL command naming rules, see [DTDL > Command](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#command). You can't start a command name using the `_` character.

+- Azure IoT Central V3 connector aligns with the generally available [1.0 REST API](/rest/api/iotcentral/) surface. All of the connector actions support the [DTDLv2 format](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) and support for DTDLv1 based models is being deprecated. For the latest information and details of recent updates, see the [Release notes](/connectors/azureiotcentral/#release-notes) for the current connector version.

+`dashboardId` - A unique [DTMI](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#digital-twin-model-identifier) identifier for the dashboard.

+The device model section of a device template specifies the capabilities of a device you want to connect to your application. Capabilities include telemetry, properties, and commands. The model is defined using [DTDL V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md).

+>Device template IDs follow the [DTDL](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#digital-twin-model-identifier) naming convention, for example: `dtmi:contoso:mythermostattemplate;1`

+- Author a device model using the [Digital Twin Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md). Manually import the device model into your IoT Central application. Then add the cloud properties and views your IoT Central application needs.

+For reference, the [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) definitions for these capabilities look like the following snippet:

+> The **geopoint** schema type is not part of the [DTDL specification](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md). IoT Central currently supports the **geopoint** schema type and the **location** semantic type for backwards compatibility.

+The [model repository](./concepts-model-repository.md) is a store for model and interface definitions. You define models and interfaces using the [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md).

+You describe the telemetry, properties, and commands that an IoT Plug and Play device implements with a [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) _model_. There are two types of model referred to in this article:

+- [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md)

+1. Create a [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) model to describe your device. To learn more, see [Understand components in IoT Plug and Play models](concepts-modeling-guide.md).

+- [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md)

+- [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md)

+An IoT Plug and Play device implements a model described by the [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) schema. A model describes the set of components, properties, commands, and telemetry messages that a particular device can have.

+IoT Plug and Play uses DTDL version 2. For more information about this version, see the [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) specification on GitHub.

+The Digital Twins Definition Language (DTDL) is described in the [DTDL Specification V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md). Users can use the _Digital Twins Model Parser_ NuGet package to validate and query a DTDL model. The DTDL model may be defined in multiple files.

+The device models repository (DMR) enables device builders to manage and share IoT Plug and Play device models. The device models are JSON LD documents defined using the [Digital Twins Modeling Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md).

+Every IoT Plug and Play device has a model that describes the features and capabilities of the device. The model uses the [Digital Twin Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md) to describe the device capabilities.

+The value must be a valid [DTDL V2 Property](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#property).

+All primitive types are supported. Within complex types, enums, maps, and objects are supported. To learn more, see [DTDL V2 Schemas](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md#schema).

+To make IoT Plug and Play work with [Azure Digital Twins](../digital-twins/overview.md), you define models and interfaces using the [Digital Twins Definition Language (DTDL) V2](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/DTDL.v2.md). IoT Plug and Play and the DTDL are open to the community, and Microsoft welcomes collaboration with customers, partners, and industry. Both are based on open W3C standards such as JSON-LD and RDF, which enables easier adoption across services and tooling.

+## (Optional) Manual verification of root certificate

+If you didn't choose to automatically verify the certificate during upload, you manually prove possession:

+1. Select the new CA certificate.

+1. Select Generate Verification Code in the Certificate Details dialog.

+1. Create a certificate that contains the verification code. For example, if you're using the Bash script supplied by Microsoft, run `./certGen.sh create_verification_certificate "<verification code>"` to create a certificate named `verification-code.cert.pem`, replacing `<verification code>` with the previously generated verification code. For more information, you can download the [files](https://github.com/Azure/azure-iot-sdk-c/tree/main/tools/CACertificates) relevant to your system to a working folder and follow the instructions in the [Managing CA certificates readme](https://github.com/Azure/azure-iot-sdk-c/blob/main/tools/CACertificates/CACertificateOverview.md) to perform proof-of-possession on a CA certificate.

+

+1. Upload `verification-code.cert.pem` to your provisioning service in the Certificate Details dialog.

+1. Select Verify.

+ "scope": "{ hub | device | module }",

+To learn more about the fields that make up an X.509 certificate, see [X.509 certificates](reference-x509-certificates.md).

+ Title: X.509 certificates | Microsoft Docs

+description: Reference documentation containing information about X.509 certificates, including certificate fields, certificate extensions, and certificate formats.

+#Customer intent: As a developer, I want to be able to use X.509 certificates to authenticate devices to an IoT hub, and I need to know what file formats, fields, and other details are supported by Azure IoT Hub.

+# X.509 certificates

+X.509 certificates are digital documents that represent a user, computer, service, or device. They're issued by a certification authority (CA), subordinate CA, or registration authority and contain the public key of the certificate subject. They don't contain the subject's private key, which must be stored securely. Public key certificates are documented by [RFC 5280](https://tools.ietf.org/html/rfc5280). They're digitally signed and, in general, contain the following information:

+* Information about the certificate subject

+* The public key that corresponds to the subject's private key

+* Information about the issuing CA

+* The supported encryption and/or digital signing algorithms

+* Information to determine the revocation and validity status of the certificate

+## Certificate fields

+There are three incremental versions of the X.509 certificate standard, and each subsequent version added certificate fields to the standard:

+* Version 1 (v1), published in 1988, follows the initial X.509 standard for certificates.

+* Version 2 (v2), published in 1993, adds two fields to the fields included in Version 1.

+* Version 3 (v3), published in 2008, represents the current version of the X.509 standard. This version adds support for certificate extensions.

+This section is meant as a general reference for the certificate fields and certificate extensions available in X.509 certificates. For more information about certificate fields and certificate extensions, including data types, constraints, and other details, see the [RFC 5280](https://tools.ietf.org/html/rfc5280) specification.

+### Version 1 fields

+The following table describes Version 1 certificate fields for X.509 certificates. All of the fields included in this table are available in subsequent X.509 certificate versions.

+| Name | Description |

+| | |

+| [Version](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.1) | An integer that identifies the version number of the certificate.|

+| [Serial Number](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.2) | An integer that represents the unique number for each certificate issued by a certificate authority (CA). |

+| [Signature](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.3) | The identifier for the cryptographic algorithm used by the CA to sign the certificate. The value includes both the identifier of the algorithm and any optional parameters used by that algorithm, if applicable. |

+| [Issuer](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.4) | The distinguished name (DN) of the certificate's issuing CA. |

+| [Validity](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.5) | The inclusive time period for which the certificate is considered valid. |

+| [Subject](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.6) | The distinguished name (DN) of the certificate subject. |

+| [Subject Public Key Info](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.7) | The public key owned by the certificate subject. |

+### Version 2 fields

+The following table describes the fields added for Version 2, containing information about the certificate issuer. These fields are, however, rarely used. All of the fields included in this table are available in subsequent X.509 certificate versions.

+| Name | Description |

+| | |

+| [Issuer Unique ID](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.8) | A unique identifier that represents the issuing CA, as defined by the issuing CA. |

+| [Subject Unique ID](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.8) | A unique identifier that represents the certificate subject, as defined by the issuing CA. |

+### Version 3 fields

+The following table describes the field added for Version 3, representing a collection of X.509 certificate extensions.

+| Name | Description |

+| | |

+| [Extensions](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.9) | A collection of standard and Internet-specific certificate extensions. For more information about the certificate extensions available to X.509 v3 certificates, see [Certificate extensions](#certificate-extensions). |

+## Certificate extensions

+Certificate extensions, introduced with Version 3, provide methods for associating more attributes with users or public keys and for managing relationships between certificate authorities. For more information about certificate extensions, see the [Certificate Extensions](https://www.rfc-editor.org/rfc/rfc5280#section-4.2) section of the [RFC 5280](https://tools.ietf.org/html/rfc5280) specification.

+### Standard extensions

+The extensions included in this section are defined as part of the X.509 standard, for use in the Internet public key infrastructure (PKI).

+| Name | Description |

+| | |

+| [Authority Key Identifier](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) | An identifier that represents either the certificate subject and the serial number of the CA certificate that issued this certificate, or a hash of the public key of the issuing CA. |

+| [Subject Key Identifier](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.2) | A hash of the current certificate's public key. |

+| [Key Usage](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3) | A bitmapped value that defines the services for which a certificate can be used. |

+| [Private Key Usage Period](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3) | The validity period for the private key portion of a key pair. |

+| [Certificate Policies](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.4) | A collection of policy information, used to validate the certificate subject. |

+| [Policy Mappings](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.5) | A collection of policy mappings, each of which maps a policy in one organization to policy in another organization. |

+| [Subject Alternative Name](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.6) | A collection of alternate names for the subject. |

+| [Issuer Alternative Name](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.7) | A collection of alternate names for the issuing CA. |

+| [Subject Directory Attributes](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.8) | A collection of attributes from an X.500 or LDAP directory. |

+| [Basic Constraints](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.9) | A collection of constraints that allow the certificate to designate whether it's issued to a CA, or to a user, computer, device, or service. This extension also includes a path length constraint that limits the number of subordinate CAs that can exist. |

+| [Name Constraints](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10) | A collection of constraints that designate which namespaces are allowed in a CA-issued certificate. |

+| [Policy Constraints](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.11) | A collection of constraints that can be used to prohibit policy mappings between CAs. |

+| [Extended Key Usage](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12) | A collection of key purpose values that indicate how a certificate's public key can be used, beyond the purposes identified in the **Key Usage** extension. |

+| [CRL Distribution Points](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.13) | A collection of URLs where the base certificate revocation list (CRL) is published. |

+| [Inhibit anyPolicy](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.14) | Inhibits the use of the **All Issuance Policies** OID (2.5.29.32.0) in subordinate CA certificates

+| [Freshest CRL](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.15) | This extension, also known as the **Delta CRL Distribution Point**, contains one or more URLs where the issuing CA's delta CRL is published. |

+### Private Internet extensions

+The extensions included in this section are similar to standard extensions, and may be used to direct applications to online information about the issuing CA or certificate subject.

+| Name | Description |

+| | |

+| [Authority Information Access](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.2.1) | A collection of entries that describe the format and location of additional information provided by the issuing CA. |

+| [Subject Information Access](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.2.2) | A collection of entries that describe the format and location of additional information provided by the certificate subject. |

+## Certificate formats

+Certificates can be saved in various formats. Azure IoT Hub authentication typically uses the Privacy-Enhanced Mail (PEM) and Personal Information Exchange (PFX) formats. The following table describes commonly used files and formats used to represent certificates.

+| Format | Description |

+| | |

+| Binary certificate | A raw form binary certificate using Distinguished Encoding Rules (DER) ASN.1 encoding. |

+| ASCII PEM format | A PEM certificate (.pem) file contains a Base64-encoded certificate beginning with `--BEGIN CERTIFICATE--` and ending with `--END CERTIFICATE--`. One of the most common formats for X.509 certificates, PEM format is required by IoT Hub when uploading certain certificates, such as device certificates. |

+| ASCII PEM key | Contains a Base64-encoded DER key, optionally with more metadata about the algorithm used for password protection. |

+| PKCS #7 certificate | A format designed for the transport of signed or encrypted data. It can include the entire certificate chain. It's defined by [RFC 2315](https://tools.ietf.org/html/rfc2315). |

+| PKCS #8 key | The format for a private key store. It's defined by [RFC 5208](https://tools.ietf.org/html/rfc5208). |

+| PKCS #12 key and certificate | A complex format that can store and protect a key and the entire certificate chain. It's commonly used with a .p12 or .pfx extension. PKCS #12 is synonymous with the PFX format. It's defined by [RFC 7292](https://tools.ietf.org/html/rfc7292). |

+## For more information

+For more information about X.509 certificates and how they're used in IoT Hub, see the following articles:

+* [The laymanΓÇÖs guide to X.509 certificate jargon](https://techcommunity.microsoft.com/t5/internet-of-things/the-layman-s-guide-to-x-509-certificate-jargon/ba-p/2203540)

+* [Understand how X.509 CA certificates are used in IoT](./iot-hub-x509ca-concept.md)

+- For a quick review of the fields that can be present in an X.509 certificate, see the [Certificate fields](reference-x509-certificates.md#certificate-fields) section of [Understand X.509 public key certificates](reference-x509-certificates.md).

+To learn more about the fields that make up an X.509 certificate, see [X.509 certificates](reference-x509-certificates.md).

+| Degraded | Your standard load balancer has platform or user initiated events impacting performance. The Datapath Availability metric has reported less than 90% but greater than 25% health for at least two minutes. You'll experience moderate to severe performance impact.

+| Unavailable | Your standard load balancer resource isn't healthy. The Datapath Availability metric has reported less the 25% health for at least two minutes. You'll experience significant performance impact or lack of availability for inbound connectivity. There may be user or platform events causing unavailability. |

+| Unknown | Resource health status for your standard load balancer resource hasn't been updated yet or hasn't received Data Path availability information for the last 10 minutes. This state should be transient and will reflect correct status as soon as data is received. |

+The two metrics to be used are *Data path availability* and *Health probe status* and it's important to understand their meaning to derive correct insights.

+The data path availability metric is generated by a TCP ping every 25 seconds on all frontend ports that have load-balancing and inbound NAT rules configured. This TCP ping will then be routed to any of the healthy (probed up) backend instances. If the service receives a response to the ping, it's considered a success and the sum of the metric will be iterated once, if it fails it won't. The count of this metric is 1/100 of the total TCP pings per sample period. Thus, we want to consider the average, which will show the average of sum/count for the time period. The data path availability metric aggregated by average thus gives us a percentage success rate for TCP pings on your frontend IP:port for each of your load-balancing and inbound NAT rules.

+The health probe status metric is generated by a ping of the protocol defined in the health probe. This ping is sent to each instance in the backend pool and on the port defined in the health probe. For HTTP and HTTPS probes, a successful ping requires an HTTP 200 OK response whereas with TCP probes any response is considered successful. The consecutive successes or failures of each probe determine the health of the backend instance and whether the assigned backend pool is able to receive traffic. Similar to data path availability we use the average aggregation, which tells us the average successful/total pings during the sampling interval. This health probe status value indicates the backend health in isolation from your load balancer by probing your backend instances without sending traffic through the frontend.

+First, we go to the detailed metrics view of our load balancer insights page in the Azure portal. You can do this via your load balancer resource page or the link in your resource health message. Next we navigate to the Frontend and Backend availability tab and review a thirty-minute window of the time period when the degraded or unavailable state occurred. If we see our data path availability has been 0%, we know there's an issue preventing traffic for all of our load-balancing and inbound NAT rules and can see how long this impact has lasted.

+The next place we need to look is our health probe status metric to determine whether our data path is unavailable is because we have no healthy backend instances to serve traffic. If we have at least one healthy backend instance for all of our load-balancing and inbound rules, we know it isn't our configuration causing our data paths to be unavailable. This scenario indicates an Azure platform issue. While platform issues are rare, an automated alert is sent to our team to rapidly resolve all platform issues.

+* Check the CPU utilization for your resources to determine if they are under high load.

+ * You can check this by viewing the resource's Percentage CPU metric via the Metrics page. Learn how to [Troubleshoot high-CPU issues for Azure virtual machines](/troubleshoot/azure/virtual-machines/troubleshoot-high-cpu-issues-azure-windows-vm).

+ * Validate application is functional by directly accessing the applications through the private IP address or instance-level public IP address associated with your backend instance

+* Check your OS. Ensure your VMs are listening on the probe port and review their OS firewall rules to ensure they aren't blocking the probe traffic originating from IP address `168.63.129.16`

+With AzureML CLI/Python SDK v1, you can deploy models on AKS using AksCompute target. Both KubernetesCompute target and AksCompute target support AKS integration, however they support it differently. The following table shows their key differences:

+With these key differences and overall AzureML evolution to use SDK/CLI v2, AzureML recommends you to use Kubernetes compute target to deploy models if you decide to use AKS for model deployment.

+* Explore model deployment with online endpoint samples with SDK v2 -[https://github.com/Azure/azureml-examples/tree/main/sdk/python/endpoints/online/kubernetes](https://github.com/Azure/azureml-examples/tree/main/sdk/python/endpoints/online/kubernetes)

+For example, when you launch the server followed the [end-to-end example](#end-to-end-example):

+> If you have been using compute instances or compute clusters configured for no public IP without opting-in to the preview, you will need to delete and recreate them after January 20, 2023 (when the feature is generally available).

+

+ Title: "Quickstart: Interactive Data Wrangling with Apache Spark (preview)"

+description: Learn how to perform interactive data wrangling with Apache Spark in Azure Machine Learning

+#Customer intent: As a Full Stack ML Pro, I want to perform interactive data wrangling in Azure Machine Learning, with Apache Spark.

+# Quickstart: Interactive Data Wrangling with Apache Spark in Azure Machine Learning (preview)

+To handle interactive Azure Machine Learning notebook data wrangling, Azure Machine Learning integration, with Azure Synapse Analytics (preview), provides easy access to the Apache Spark framework. This access allows for Azure Machine Learning Notebook interactive data wrangling.

+In this quickstart guide, you'll learn how to perform interactive data wrangling using Azure Machine Learning Managed (Automatic) Synapse Spark compute, Azure Data Lake Storage (ADLS) Gen 2 storage account, and user identity passthrough.

+## Prerequisites

+- An Azure subscription; if you don't have an Azure subscription, [create a free account](https://azure.microsoft.com/free) before you begin.

+- An Azure Machine Learning workspace. See [Create workspace resources](./quickstart-create-resources.md).

+- An Azure Data Lake Storage (ADLS) Gen 2 storage account. See [Create an Azure Data Lake Storage (ADLS) Gen 2 storage account](../storage/blobs/create-data-lake-storage-account.md).

+- To enable this feature:

+ 1. Navigate to the Azure Machine Learning studio UI

+ 2. In the icon section at the top right of the screen, select **Manage preview features** (megaphone icon)

+ 3. In the **Managed preview feature** panel, toggle the **Run notebooks and jobs on managed Spark** feature to **on**

+ :::image type="content" source="media/quickstart-spark-data-wrangling/how-to-enable-managed-spark-preview.png" lightbox="media/quickstart-spark-data-wrangling/how-to-enable-managed-spark-preview.png" alt-text="Screenshot showing the option to enable the Managed Spark preview.":::

+## Add role assignments in Azure storage accounts

+We must ensure that the input and output data paths are accessible, before we start interactive data wrangling. To enable read and write access, assign **Contributor** and **Storage Blob Data Contributor** roles to the user identity of the logged-in user.

+To assign appropriate roles to the user identity:

+1. In the Microsoft Azure portal, navigate to the Azure Data Lake Storage (ADLS) Gen 2 storage account page

+1. Select **Access Control (IAM)** from the left panel

+1. Select **Add role assignment**

+ :::image type="content" source="media/quickstart-spark-data-wrangling/storage-account-add-role-assignment.png" lightbox="media/quickstart-spark-data-wrangling/storage-account-add-role-assignment.png" alt-text="Screenshot showing the Azure access keys screen.":::

+1. Find and select role **Storage Blob Data Contributor**

+1. Select **Next**

+ :::image type="content" source="media/quickstart-spark-data-wrangling/add-role-assignment-choose-role.png" lightbox="media/quickstart-spark-data-wrangling/add-role-assignment-choose-role.png" alt-text="Screenshot showing the Azure add role assignment screen.":::

+1. Select **User, group, or service principal**.

+1. Select **+ Select members**.

+1. Search for the user identity below **Select**

+1. Select the user identity from the list, so that it shows under **Selected members**

+1. Select the appropriate user identity

+1. Select **Next**

+ :::image type="content" source="media/quickstart-spark-data-wrangling/add-role-assignment-choose-members.png" lightbox="media/quickstart-spark-data-wrangling/add-role-assignment-choose-members.png" alt-text="Screenshot showing the Azure add role assignment screen Members tab.":::

+1. Select **Review + Assign**

+ :::image type="content" source="media/quickstart-spark-data-wrangling/add-role-assignment-review-and-assign.png" lightbox="media/quickstart-spark-data-wrangling/add-role-assignment-review-and-assign.png" alt-text="Screenshot showing the Azure add role assignment screen review and assign tab.":::

+1. Repeat steps 2-13 for **Contributor** role assignment.

+Once the user identity has the appropriate roles assigned, data in the Azure storage account should become accessible.

+## Managed (Automatic) Spark compute in Azure Machine Learning Notebooks

+A Managed (Automatic) Spark compute is available in Azure Machine Learning Notebooks by default. To access it in a notebook, start in the **Compute** selection menu, and select **AzureML Spark Compute** under **Azure Machine Learning Spark**.

+## Interactive data wrangling with Titanic data

+> [!TIP]

+> Data wrangling with a Managed (Automatic) Spark compute, and user identity passthrough for data access in a Azure Data Lake Storage (ADLS) Gen 2 storage account, both require the lowest number of configuration steps.

+The data wrangling code shown here uses the `titanic.csv` file, available [here](https://github.com/Azure/azureml-examples/blob/main/sdk/python/jobs/spark/data/titanic.csv). Upload this file to a container created in the Azure Data Lake Storage (ADLS) Gen 2 storage account. This Python code snippet shows interactive data wrangling with an Azure Machine Learning Managed (Automatic) Spark compute, user identity passthrough, and an input/output data URI, in format `abfss://<FILE_SYSTEM_NAME>@<STORAGE_ACCOUNT_NAME>.dfs.core.windows.net/<PATH_TO_DATA>`:

+```python

+import pyspark.pandas as pd

+from pyspark.ml.feature import Imputer

+df = pd.read_csv(

+ "abfss://<FILE_SYSTEM_NAME>@<STORAGE_ACCOUNT_NAME>.dfs.core.windows.net/data/titanic.csv",

+ index_col="PassengerId",

+)

+imputer = Imputer(inputCols=["Age"], outputCol="Age").setStrategy(

+ "mean"

+) # Replace missing values in Age column with the mean value

+df.fillna(

+ value={"Cabin": "None"}, inplace=True

+) # Fill Cabin column with value "None" if missing

+df.dropna(inplace=True) # Drop the rows which still have any missing value

+df.to_csv(

+ "abfss://<FILE_SYSTEM_NAME>@<STORAGE_ACCOUNT_NAME>.dfs.core.windows.net/data/wrangled",

+ index_col="PassengerId",

+)

+```

+> [!NOTE]

+> Only the Spark runtime version 3.2 supports `pyspark.pandas`, used in this Python code sample.

+## Next steps

+- [Apache Spark in Azure Machine Learning (preview)](./apache-spark-azure-ml-concepts.md)

+- [Attach and manage a Synapse Spark pool in Azure Machine Learning (preview)](./how-to-manage-synapse-spark-pool.md)

+- [Interactive Data Wrangling with Apache Spark in Azure Machine Learning (preview)](./interactive-data-wrangling-with-apache-spark-azure-ml.md)

+- [Submit Spark jobs in Azure Machine Learning (preview)](./how-to-submit-spark-jobs.md)

+- [Code samples for Spark jobs using Azure Machine Learning CLI](https://github.com/Azure/azureml-examples/tree/main/cli/jobs/spark)

+- [Code samples for Spark jobs using Azure Machine Learning Python SDK](https://github.com/Azure/azureml-examples/tree/main/sdk/python/jobs/spark)

+> If you have been using compute instances or compute clusters configured for no public IP without opting-in to the preview, you will need to delete and recreate them after January 20, 2023 (when the feature is generally available).

+> The Marketo connector has been restored. Update your configurations to receive leads as shown in this article.

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/marketo-1.png" alt-text="Screenshot showing Marketo Design Studio.":::

+1. Select **New Form**.

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/marketo-2.png" alt-text="Screenshot showing Marketo Design Studio New Form.":::

+1. Fill in the required fields in the **New Form** dialog box, and then select **Create**.

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/marketo-3.png" alt-text="Screenshot showing Marketo Design Studio New Form creation.":::

+

+1. Ensure that the fields mappings are setup correctly. Here are the list of fields that the connector needs to be setup on the form.

+ > [!NOTE]

+ > The field with name "Lead Source" is expected to be configured in the form. It can be mapped to the **SourceSystemName** system field in Marketo or a custom field.

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/marketo-field-details.png" alt-text="Screenshot showing Marketo new form details.":::

+1. On the **Field Details** page, select **Finish**.

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/marketo-4.png" alt-text="Screenshot showing finishing the Marketo creation form.":::

+1. Approve and close.

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/marketo-6.png" alt-text="Screenshot showing the Marketo Embed Code form.":::

+ ```html

+ <form id="mktoForm_1179"></form>

+ <script>MktoForms2.loadForm("("//app-ys12.marketo.com", "123-PQR-789", 1179);</script>

+ ```

+ - Munchkin ID = **123-PQR-789**

+ - Form ID = **1179**

+ The following is another way to figure out these values:

+ - Get your subscription's Munchkin ID by going to your **Admin** > **Munchkin** menu in the **Munchkin Account ID** field, or from the first part of your Marketo REST API host subdomain: `https://{Munchkin ID}.mktorest.com`.

+ - Form ID is the ID of the Embed Code form you created in step 7 to route leads from the marketplace.

+## Obtain a API access from your Marketo Admin

+1. See this [Marketo article on getting API access](https://aka.ms/marketo-api), specifically a **ClientID** and **Client Secret** needed for the new Marketo configuration. Follow the step-by-step guide to create an API-only user and a Launchpoint connection for the Partner Center lead management service.

+1. Ensure that the **Custom service created** indicates Partner Center as shown below.

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/marketo-new-service.png" alt-text="Screenshot showing Marketo API new service form":::

+1. Once you click the View details link for the new service created, you can copy the **Client ID** and **Client secret** for use in the Partner center connector configuration.

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/marketo-admin-installed-services.png" alt-text="Screenshot showing the Marketo admin installed services.":::

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/marketo-api-access-details.png" alt-text="Screenshot showing the Marketo API access details.":::

+1. Sign in to [Partner Center](https://partner.microsoft.com/dashboard/home) and select **Marketplace offers**.

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/customer-leads.png" alt-text="Screenshot showing the Partner Center customer leads page.":::

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/choose-lead-destination.png" alt-text="Screenshot showing the Partner Center customer lead destination.":::

+1. Provide the **Munchkin ID**, **Form ID**, **Client ID** and **Client Secret** fields.

+ > [!NOTE]

+ > You must finish configuring the rest of the offer and publish it before you can receive leads for the offer.

+ :::image type="content" source="./media/commercial-marketplace-lead-management-instructions-marketo/marketo-connection-details.png" alt-text="Screenshot showing the Partner Center connection details.":::

+**vCenter Server/ESXi host** | You need a server running vCenter Server version 7.0, 6.7, 6.5, 6.0, or 5.5.<br /><br /> Servers must be hosted on an ESXi host running version 5.5 or later.<br /><br /> On the vCenter Server, allow inbound connections on TCP port 443 so that the appliance can collect configuration and performance metadata.<br /><br /> The appliance connects to vCenter Server on port 443 by default. If the server running vCenter Server listens on a different port, you can modify the port when you provide the vCenter Server details in the appliance configuration manager.<br /><br /> On the ESXi hosts, make sure that inbound access is allowed on TCP port 443 for discovery of installed applications and for agentless dependency analysis on servers.

+The minimum IOPS is 360 across all compute sizes and the maximum IOPS is determined by the selected compute size. To learn more about the maximum IOPS per compute size refer to the [table](#service-tiers-size-and-server-types).

+- Learn about [service limitations](concepts-limitations.md).

+Red Hat OpenShift Container Platform uses semantic versioning. Semantic versioning uses different levels of version numbers to specify different levels of versioning. The following table illustrates the different parts of a semantic version number, in this case using the example version number 4.10.3.

+|4|10|3|

+Customers should aim to run the latest minor release of the major version they're running. For example, if your production cluster is on 4.9, and 4.10 is the latest generally available minor version for the 4 series, you should upgrade to 4.10 as soon as you can.

+Upgrade channels are tied to a minor version of Red Hat OpenShift Container Platform (OCP). For instance, OCP 4.9 upgrade channels will never include an upgrade to a 4.10 release. Upgrade channels control only release selection and don't impact the version of the cluster.

+Azure Red Hat OpenShift 4 supports stable channels only. For example: stable-4.9.

+You can use the stable-4.10 channel to upgrade from a previous minor version of Azure Red Hat OpenShift. Clusters upgraded using fast, prerelease, and candidate channels won't be supported.

+For example, if Azure Red Hat OpenShift introduces 4.10.z today, support is provided for the following versions:

+|4.10.z|4.10.z, 4.9.z|

+".z" is representative of patch versions. If available in a stable upgrade channel, customers may also upgrade to 4.9.z.

+When a new minor version is introduced, the oldest minor version is deprecated and removed. For example, say the current supported version list is 4.10.z and 4.9.z. When Azure Red Hat OpenShift releases 4.11.z, the 4.9.z release will be removed and will be out of support within 30 days.

+When you deploy an Azure Red Hat OpenShift cluster in the portal or with the Azure CLI, the cluster is defaulted to the latest (N) minor version and latest critical patch. For example, if Azure Red Hat OpenShift supports 4.10.z and 4.9.z, the default version for new installations is 4.10.z. Customers that wish to use the latest upstream OCP minor version (N+1, N+2) can upgrade their cluster at any time to any release available in the stable upgrade channels.

+* If the oldest supported Azure Red Hat OpenShift version is 4.9.z and you are on 4.8.z or older, you are outside of support.

+* When the upgrade from 4.8.z to 4.9.z or higher succeeds, you're back within our support policies.

+##### Activity

+|Display Name |Metric ID |Unit |Description |Dimension |Default enabled |

+||-|-||||

+##### Database

+##### Logical Replication

+##### Replication

+##### Saturation

+##### Traffic

+## Autovacuum metrics

+Autovaccum metrics can be used to monitor and tune autovaccum performance for Azure database for postgres flexible server. Each metric is emitted at a **30 minute** frequency, and has up to **93 days** of retention. Customers can configure alerts on the metrics and can also access the new metrics dimensions, to split and filter the metrics data on database name.

+#### Enabling Autovacuum metrics

+* Autovacuum metrics are disabled by default

+* To enable these metrics, please turn ON the server parameter `metrics.autovacuum_diagnostics`.

+ * This parameter is dynamic, hence will not require instance restart.

+#### Autovacuum metrics

+|Display Name |Metric ID |Unit |Description |Dimension |Default enabled|

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

+|**Analyze Counter User Tables** (Preview) |analyze_count_user_tables |Count|Number of times user only tables have been manually analyzed in this database |DatabaseName|No |

+|**AutoAnalyze Counter User Tables** (Preview) |autoanalyze_count_user_tables |Count|Number of times user only tables have been analyzed by the autovacuum daemon in this database |DatabaseName|No |

+|**AutoVacuum Counter User Tables** (Preview) |autovacuum_count_user_tables |Count|Number of times user only tables have been vacuumed by the autovacuum daemon in this database |DatabaseName|No |

+|**Estimated Dead Rows User Tables** (Preview) |n_dead_tup_user_tables |Count|Estimated number of dead rows for user only tables in this database |DatabaseName|No |

+|**Estimated Live Rows User Tables** (Preview) |n_live_tup_user_tables |Count|Estimated number of live rows for user only tables in this database |DatabaseName|No |

+|**Estimated Modifications User Tables** (Preview)|n_mod_since_analyze_user_tables|Count|Estimated number of rows modified since user only tables were last analyzed |DatabaseName|No |

+|**User Tables Analyzed** (Preview) |tables_analyzed_user_tables |Count|Number of user only tables that have been analyzed in this database |DatabaseName|No |

+|**User Tables AutoAnalyzed** (Preview) |tables_autoanalyzed_user_tables|Count|Number of user only tables that have been analyzed by the autovacuum daemon in this database |DatabaseName|No |

+|**User Tables AutoVacuumed** (Preview) |tables_autovacuumed_user_tables|Count|Number of user only tables that have been vacuumed by the autovacuum daemon in this database |DatabaseName|No |

+|**User Tables Counter** (Preview) |tables_counter_user_tables |Count|Number of user only tables in this database |DatabaseName|No |

+|**User Tables Vacuumed** (Preview) |tables_vacuumed_user_tables |Count|Number of user only tables that have been vacuumed in this database |DatabaseName|No |

+|**Vacuum Counter User Tables** (Preview) |vacuum_count_user_tables |Count|Number of times user only tables have been manually vacuumed in this database (not counting VACUUM FULL)|DatabaseName|No |

+#### Applying filters and splitting on metrics with dimension

+|| [Oracle](register-scan-oracle-source.md) | [Yes](register-scan-oracle-source.md#register)| [Yes](register-scan-oracle-source.md#scan) | [Yes*](register-scan-oracle-source.md#lineage) | No| No |

+|| [Snowflake](register-scan-snowflake.md) | [Yes](register-scan-snowflake.md#register) | [Yes](register-scan-snowflake.md#scan) | [Yes](register-scan-snowflake.md#lineage) | No | No |

+| [Yes](#register)| [Yes](#scan)| No | [Yes](#scan) | [Yes](#scan) | No| [Yes](#lineage) | No|

+1. Select a **scan rule set** for classification. You can choose between the system default, existing custom rule sets, or [create a new rule set](create-a-scan-rule-set.md) inline. Check the [Classification](apply-classifications.md) article to learn more.

+When you configure to be zone redundant, the platform automatically spreads the instances of the Azure App Service plan across three zones in the selected region. This means that the minimum App Service Plan instance count will always be three. If you specify a capacity larger than three, and the number of instances is divisible by three, the instances are spread evenly. Otherwise, instance counts beyond 3*N are spread across the remaining one or two zones.

+Applications that are deployed in an App Service Environment that has availability zones enabled will continue to run and serve traffic if a single zone becomes unavailable. However it's possible that non-runtime behaviors including App Service plan scaling, application creation, application configuration, and application publishing may still be impacted from an outage in other Availability Zones. Zone redundancy for App Service Environments only ensures continued uptime for deployed applications.

+> [Azure services and regions that support availability zones](availability-zones-service-support.md)

+* `generateCollisionMesh` - If you need support for [spatial queries](../../overview/features/spatial-queries.md) on a model, this option has to be enabled. Collision mesh generation does not add any extra conversion time and also does not increase the output file size. Furthermore, the loading time and runtime cost of a model with collision meshes is only insignificantly higher.

+Accordingly this flag can be left to default (enabled) unless there are strong reasons to exclude a model from spatial queries.

+* `axis` - To override coordinate system unit-vectors. Default values are `["+x", "+y", "+z"]`. In theory, the FBX format has a header where those vectors are defined and the conversion uses that information to transform the scene. The glTF format also defines a fixed coordinate system. In practice, some assets either have incorrect information in their header or were saved with a different coordinate system convention. This option allows you to override the coordinate system to compensate. For example: `"axis" : ["+x", "+z", "-y"]` will exchange the Z-axis and the Y-axis and keep coordinate system handed-ness by inverting the Y-axis direction.

+By default the converter has to assume that you may want to use PBR materials on a model at some time, so it will generate `normal`, `tangent`, and `binormal` data for you. So, the per vertex memory usage is `position` (12 bytes) + `texcoord0` (8 bytes) + `normal` (4 bytes) + `tangent` (4 bytes) + `binormal` (4 byte) = 32 bytes. Larger models of this type can easily have many millions of :::no-loc text="vertices"::: resulting in models that can take up multiple gigabytes of memory. Such large amounts of data will affect performance and you may even run out of memory.

+* `generateCollisionMesh` - similar to triangular meshes, this flag needs to be enabled to support [spatial queries](../../overview/features/spatial-queries.md).

+All spatial queries are evaluated on the server. Accordingly, the queries are asynchronous operations and results will arrive with a delay that depends on your network latency.

+Although doing hundreds of ray casts each frame is computationally feasible on the server side, each query also generates network traffic, so the number of queries per frame should be kept as low as possible.

+* **`HitType`:** What was hit by the ray: `TriangleFrontFace`, `TriangleBackFace` or `Point`. By default, [ARR renders double sided](single-sided-rendering.md#prerequisites) so the triangles the user sees aren't necessarily front facing. If you want to differentiate between `TriangleFrontFace` and `TriangleBackFace` in your code, make sure your models are authored with correct face directions first.

+A *spatial query* allows for the runtime to check which [MeshComponents](../../concepts/meshes.md#meshcomponent) intersect with a user defined volume. This check is performant as the individual check is performed based on each mesh part's bounds in the scene, not on an individual triangle basis. As an optimization, a maximum number of hit mesh components can be provided.\

+While such a query can be run manually on the client side, for large scenes it can be orders of magnitude faster for the server to compute this.

+The following example code shows how to do queries against an axis aligned bounding box (AABB). Variants of the query also allow for oriented bounding box volumes (`SpatialQueryObbAsync`) and sphere volumes (`SpatialQuerySphereAsync`).

+ SpatialQueryAabb query = new SpatialQueryAabb();

+ SpatialQueryResult result = await session.Connection.SpatialQueryAabbAsync(query);

+ SpatialQueryAabb query;

+ session->Connection()->SpatialQueryAabbAsync(query, [](Status status, ApiHandle<SpatialQueryResult> result)

+* [C# RenderingConnection.RayCastQueryAabbAsync()](/dotnet/api/microsoft.azure.remoterendering.renderingconnection.raycastqueryaabbasync)

+* [C# RenderingConnection.RayCastQueryObbAsync()](/dotnet/api/microsoft.azure.remoterendering.renderingconnection.raycastqueryobbasync)

+* [C# RenderingConnection.RayCastQuerySphereAsync()](/dotnet/api/microsoft.azure.remoterendering.renderingconnection.raycastquerysphereasync)

+* [C++ RenderingConnection::RayCastQueryAabbAsync()](/cpp/api/remote-rendering/renderingconnection#raycastqueryaabbasync)

+* [C++ RenderingConnection::RayCastQueryObbAsync()](/cpp/api/remote-rendering/renderingconnection#raycastqueryobbasync)

+* [C++ RenderingConnection::RayCastQuerySphereAsync()](/cpp/api/remote-rendering/renderingconnection#raycastquerysphereasync)

+| [**Azure Machine Learning (AML) skill**](cognitive-search-aml-skill.md) | AI enrichment (skills) | A new skill type to integrate an inferencing endpoint from Azure Machine Learning. | Use [Search Preview REST API](/rest/api/searchservice/), API versions 2021-04-30-Preview, 2020-06-30-Preview, or 2019-05-06-Preview. Also available in the portal, in skillset design, assuming Cognitive Search and Azure ML services are deployed in the same subscription. |

+1. Under **Configuration**, select **Connect Azure Information Protection logs**.

+1. Select the configured workspace and select **Ok**.

+- [Use workbooks](monitor-your-data.md) to monitor your data.

+ - **Trigger an alert for each event**. The rule generates a unique alert for each event returned by the query. This is useful if you want events to be displayed individually, or if you want to group them by certain parameters&mdash;by user, hostname, or something else. You can define these parameters in the query.

+ >

+ > **Up to 150 alerts** can be grouped into a single incident.

+ > - The incident will only be created after all the alerts have been generated. All of the alerts will be added to the incident immediately upon its creation.

+ >

+ > - If more than 150 alerts are generated by a rule that groups them into a single incident, a new incident will be generated with the same incident details as the original, and the excess alerts will be grouped into the new incident.

+In the **Automated responses** tab, you can use [automation rules](automate-incident-handling-with-automation-rules.md) to set automated responses to occur at any of three types of occasions:

+- When an alert is generated by this analytics rule.

+- When an incident is created with alerts generated by this analytics rule.

+- When an incident is updated with alerts generated by this analytics rule.

+

+The grid displayed under **Automation rules** shows the automation rules that already apply to this analytics rule (by virtue of it meeting the conditions defined in those rules). You can edit any of these by selecting the ellipsis at the end of each row. Or, you can [create a new automation rule](create-manage-use-automation-rules.md).

+Use automation rules to perform basic triage, assignment, [workflow](incident-tasks.md), and closing of incidents.

+Automate more complex tasks and invoke responses from remote systems to remediate threats by calling playbooks from these automation rules. You can do this for incidents as well as for individual alerts.

+- For more information and instructions on creating playbooks and automation rules, see [Automate threat responses](tutorial-respond-threats-playbook.md#automate-threat-responses).

+- For more information about when to use the **incident created trigger**, the **incident updated trigger**, or the **alert created trigger**, see [Use triggers and actions in Microsoft Sentinel playbooks](playbook-triggers-actions.md#microsoft-sentinel-triggers-summary).

+- Under **Alert automation (classic)** at the bottom of the screen, you'll see any playbooks you've configured to run automatically when an alert is generated using the old method. If you still have any of these, you should instead create an automation rule based on the **alert created trigger** and invoke the playbook from there.

+Select **Review and create** to review all the settings for your new analytics rule. When the "Validation passed" message appears, select **Create**.

+| **Microsoft Sentinel incident (Preview)** | Recommended for most incident automation scenarios.<br><br>The playbook receives incident objects, including entities and alerts. Using this trigger allows the playbook to be attached to an **Automation rule**, so it can be triggered when an incident is created (and now, updated as well) in Microsoft Sentinel, and all the [benefits of automation rules](./automate-incident-handling-with-automation-rules.md) can be applied to the incident. | Playbooks with this trigger do not support alert grouping, meaning they will receive only the first alert sent with each incident.<br><br>**UPDATE**: As of February 2023, alert grouping is supported for this trigger.

+- [New behavior for alert grouping in analytics rules](#new-behavior-for-alert-grouping-in-analytics-rules) (in [Announcements](#announcements) section below)

+- [New behavior for alert grouping in analytics rules](#new-behavior-for-alert-grouping-in-analytics-rules)

+### New behavior for alert grouping in analytics rules

+Starting **February 6, 2023** and continuing through the end of February, Microsoft Sentinel is rolling out a change in the way that incidents are created from analytics rules with certain event and alert grouping settings, and also the way that such incidents are updated by automation rules. This change is being made in order to produce incidents with more complete information and to simplify automation triggered by the creating and updating of incidents.

+The affected analytics rules are those with both of the following two settings:

+- **Event grouping** is set to **Trigger an alert for each event** (sometimes referred to as "alert per row" or "alert per result").

+- **Alert grouping** is enabled, in any one of the [three possible configurations](detect-threats-custom.md#alert-grouping).

+#### The problem

+Rules with these two settings generate unique alerts for each event (result) returned by the query. These alerts are then all grouped together into a single incident (or a small number of incidents, depending on the alert grouping configuration choice).

+The problem is that the incident is created as soon as the first alert is generated, so at that point the incident contains only the first alert. The remaining alerts are joined to the incident, one after the other, as they are generated. So you end up with a *single running of an analytics rule* resulting in:

+- One incident creation event *and*

+- Up to 149 incident update events

+These circumstances result in unpredictable behavior when evaluating the conditions defined in automation rules or populating the incident schema in playbooks:

+- **Incorrect evaluation of an incident's conditions by automation rules:**

+ Automation rules on this incident will run immediately on its creation, even with just the one alert included. So the automation rule will only consider the incident's status as containing the first alert, even though other alerts are being created nearly simultaneously (by the same running of the analytics rule) and will continue being added while the automation rule is running. So you end up with a situation where the automation rule's evaluation of the incident is incomplete and likely incorrect.

+ If there are automation rules defined to run when the incident is *updated*, they will run again and again as each subsequent alert is added to the incident (even though the alerts were all generated by the same running of the analytics rule). So you'll have alerts being added and automation rules running, each time possibly incorrectly evaluating the conditions of the incident.

+ Automation rules' conditions might ignore entities that only later become part of the incident but weren't included in the first alert/creation of the incident.

+ In these cases, incorrect evaluation of an incident's condition may cause automation rules to run when they shouldn't, or not to run when they should. The result of this would be that the wrong actions would be taken on an incident, or that the right actions would not be taken.

+- **Information in later alerts being unavailable to playbooks run on the incident:**

+ When an automation rule calls a playbook, it passes the incident's detailed information to the playbook. Because of the behavior mentioned above, a playbook might only receive the details (entities, custom details, and so on) of the first alert in an incident, but not those from subsequent alerts. This means that the playbook's actions would not have access to all the information in the incident.

+#### The solution

+Going forward, instead of creating the incident as soon as the first alert is generated, Microsoft Sentinel will wait until a single running of an analytics rule has generated all of its alerts, and then create the incident, adding all the alerts to it at once. So instead of an incident creation event and a whole bunch of incident update events, you have only the incident creation event.

+Now, automation rules that run on the creation of an incident can evaluate the complete incident with all of its alerts (as well as entities and custom details) and its most updated properties, and any playbooks that run will similarly have the complete details of the incident.

+The following table describes the change in the incident creation and automation behaviors:

+| When incident created/updated with multiple alerts | Before the change | After the change |

+| -- | -- | -- |

+| **Automation rule** conditions are evaluated based on... | The first alert generated by the current running of the analytics rule. | All alerts and entities resulting from the current running of the analytics rule. |

+| **Playbook input** includes... | - Alerts list containing only the first alert of the incident.<br>- Entities list containing only entities from the first alert of the incident. | - Alerts list containing all the alerts triggered by this rule execution and grouped to this incident.<br>- Entities list containing the entities from all the alerts triggered by this rule execution and grouped to this incident. |

+| **SecurityIncident** table in Log Analytics shows... | -&nbsp;One&nbsp;row&nbsp;for&nbsp;*incident&nbsp;created*&nbsp;with&nbsp;one&nbsp;alert.<br>- Multiple&nbsp;events&nbsp;of&nbsp;*alert&nbsp;added*. | One row for *incident created* only after all alerts triggered by this rule execution have been added and grouped to this incident. |

+- [Best practices for using blob access tiers](access-tiers-best-practices.md)

+- [Best practices for using blob access tiers](access-tiers-best-practices.md)

+## Resources

+To learn more about creating a container using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for creating a container use the following REST API operation:

+- [Create Container](/rest/api/storageservices/create-container) (REST API)

+### Code samples

+- [View code samples from this article (GitHub)](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/create-container.js)

+## Resources

+To learn more about creating a container using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for creating a container use the following REST API operation:

+- [Create Container](/rest/api/storageservices/create-container) (REST API)

+## Resources

+To learn more about deleting a container using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for deleting or restoring a container use the following REST API operations:

+- [Delete Container](/rest/api/storageservices/delete-container) (REST API)

+- [Restore Container](/rest/api/storageservices/restore-container) (REST API)

+### Code samples

+- [View code samples from this article (GitHub)](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/delete-containers.js)

+### See also

+## Resources

+To learn more about deleting a container using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for deleting or restoring a container use the following REST API operations:

+- [Delete Container](/rest/api/storageservices/delete-container) (REST API)

+- [Restore Container](/rest/api/storageservices/restore-container) (REST API)

+### See also

+## Resources

+To learn more about setting and retrieving container properties and metadata using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for setting and retrieving properties and metadata use the following REST API operations:

+- [Get Container Properties](/rest/api/storageservices/get-container-properties) (REST API)

+- [Set Container Metadata](/rest/api/storageservices/set-container-metadata) (REST API)

+- [Get Container Metadata](/rest/api/storageservices/get-container-metadata) (REST API)

+The `getProperties` method retrieves container properties and metadata by calling both the [Get Blob Properties](/rest/api/storageservices/get-blob-properties) operation and the [Get Blob Metadata](/rest/api/storageservices/get-blob-metadata) operation.

+### Code samples

+- [View code samples from this article (GitHub)](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/container-set-properties-and-metadata.js)

+## Resources

+To learn more about setting and retrieving container properties and metadata using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for setting and retrieving properties and metadata use the following REST API operations:

+- [Get Container Properties](/rest/api/storageservices/get-container-properties) (REST API)

+- [Set Container Metadata](/rest/api/storageservices/set-container-metadata) (REST API)

+- [Get Container Metadata](/rest/api/storageservices/get-container-metadata) (REST API)

+The `GetProperties` and `GetPropertiesAsync` methods retrieve container properties and metadata by calling both the [Get Blob Properties](/rest/api/storageservices/get-blob-properties) operation and the [Get Blob Metadata](/rest/api/storageservices/get-blob-metadata) operation.

+## Resources

+To learn more about listing containers using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for listing containers use the following REST API operation:

+- [List Containers](/rest/api/storageservices/list-containers2) (REST API)

+### Code samples

+- [View code samples from this article (GitHub)](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/list-containers.js)

+## Resources

+To learn more about listing containers using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for listing containers use the following REST API operation:

+- [List Containers](/rest/api/storageservices/list-containers2) (REST API)

+## Resources

+To learn more about copying blobs using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for copying blobs use the following REST API operations:

+- [Copy Blob](/rest/api/storageservices/copy-blob) (REST API)

+- [Copy Blob From URL](/rest/api/storageservices/copy-blob-from-url) (REST API)

+- [Abort Copy Blob](/rest/api/storageservices/abort-copy-blob) (REST API)

+### Code samples

+- [View code samples from this article (GitHub)](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/copy-blob.js)

+## Resources

+To learn more about copying blobs using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for copying blobs use the following REST API operations:

+- [Copy Blob](/rest/api/storageservices/copy-blob) (REST API)

+- [Copy Blob From URL](/rest/api/storageservices/copy-blob-from-url) (REST API)

+- [Abort Copy Blob](/rest/api/storageservices/abort-copy-blob) (REST API)

+## Resources

+To learn more about how to delete blobs and restore deleted blobs using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for deleting blobs and restoring deleted blobs use the following REST API operations:

+### Code samples

+- [View code samples from this article (GitHub)](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/delete-blob.js)

+### See also

+- [Soft delete for blobs](soft-delete-blob-overview.md)

+- [Blob versioning](versioning-overview.md)

+## Resources

+To learn more about how to delete blobs and restore deleted blobs using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for deleting blobs and restoring deleted blobs use the following REST API operations:

+### See also

+- [Soft delete for blobs](soft-delete-blob-overview.md)

+- [Blob versioning](versioning-overview.md)

+## Resources

+To learn more about how to download blobs using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for downloading blobs use the following REST API operation:

+### Code samples

+View code samples from this article (GitHub):

+- [Download to file](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/download-blob-to-file.js)

+- [Download to stream](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/download-blob-to-stream.js)

+- [Download to string](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/download-blob-to-string.js)

+## Resources

+To learn more about how to download blobs using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for downloading blobs use the following REST API operation:

+## Resources

+To learn more about how to manage system properties and user-defined metadata using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for managing system properties and user-defined metadata use the following REST API operations:

+- [Set Blob Properties](/rest/api/storageservices/set-blob-properties) (REST API)

+- [Get Blob Properties](/rest/api/storageservices/get-blob-properties) (REST API)

+- [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata) (REST API)

+- [Get Blob Metadata](/rest/api/storageservices/get-blob-metadata) (REST API)

+### Code samples

+- [View code samples from this article (GitHub)](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/blob-set-properties-and-metadata.js)

+## Resources

+To learn more about how to manage system properties and user-defined metadata using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for managing system properties and user-defined metadata use the following REST API operations:

+- [Set Blob Properties](/rest/api/storageservices/set-blob-properties) (REST API)

+- [Get Blob Properties](/rest/api/storageservices/get-blob-properties) (REST API)

+- [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata) (REST API)

+- [Get Blob Metadata](/rest/api/storageservices/get-blob-metadata) (REST API)

+## Resources

+To learn more about how to use index tags to manage and find data using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for managing and using blob index tags use the following REST API operations:

+- [Set Blob Tags](/rest/api/storageservices/set-blob-tags) (REST API)

+### Code samples

+- [View code samples from this article (GitHub)](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/set-and-retrieve-blob-tags.js)

+### See also

+- [Manage and find Azure Blob data with blob index tags](storage-manage-find-blobs.md)

+- [Use blob index tags to manage and find data on Azure Blob Storage](storage-blob-index-how-to.md)

+## Resources

+To learn more about how to use index tags to manage and find data using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for managing and using blob index tags use the following REST API operations:

+- [Set Blob Tags](/rest/api/storageservices/set-blob-tags) (REST API)

+### See also

+- [Manage and find Azure Blob data with blob index tags](storage-manage-find-blobs.md)

+- [Use blob index tags to manage and find data on Azure Blob Storage](storage-blob-index-how-to.md)

+## Resources

+To learn more about uploading blobs using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for uploading blobs use the following REST API operations:

+### Code samples

+View code samples from this article (GitHub):

+- [Upload from local file path](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/upload-blob-from-local-file-path.js)

+- [Upload from buffer](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/upload-blob-from-buffer.js)

+- [Upload from stream](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/upload-blob-from-stream.js)

+- [Upload from string](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/upload-blob-from-string.js)

+### See also

+- [Manage and find Azure Blob data with blob index tags](storage-manage-find-blobs.md)

+- [Use blob index tags to manage and find data on Azure Blob Storage](storage-blob-index-how-to.md)

+## Resources

+To learn more about uploading blobs using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for uploading blobs use the following REST API operations:

+### See also

+- [Manage and find Azure Blob data with blob index tags](storage-manage-find-blobs.md)

+- [Use blob index tags to manage and find data on Azure Blob Storage](storage-blob-index-how-to.md)

+## Resources

+To learn more about how to list blobs using the Azure Blob Storage client library for JavaScript, see the following resources.

+### REST API operations

+The Azure SDK for JavaScript contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar JavaScript paradigms. The client library methods for listing blobs use the following REST API operation:

+- [List Blobs](/rest/api/storageservices/list-blobs) (REST API)

+### Code samples

+- [View code samples from this article (GitHub)](https://github.com/Azure-Samples/AzureStorageSnippets/blob/master/blobs/howto/JavaScript/NodeJS-v12/dev-guide/list-blobs.js)

+### See also

+## Resources

+To learn more about how to list blobs using the Azure Blob Storage client library for .NET, see the following resources.

+### REST API operations

+The Azure SDK for .NET contains libraries that build on top of the Azure REST API, allowing you to interact with REST API operations through familiar .NET paradigms. The client library methods for listing blobs use the following REST API operation:

+- [List Blobs](/rest/api/storageservices/list-blobs) (REST API)

+### See also

+## Support

+ > NFS shares can only be accessed from trusted networks.

+- Either [create a private endpoint](storage-files-networking-endpoints.md#create-a-private-endpoint) (recommended) or [restrict access to your public endpoint](storage-files-networking-endpoints.md#restrict-public-endpoint-access).

+- To enable hybrid access to an NFS Azure file share, use one of the following networking solutions:

+For information on defining CDM documents using CDM 1.2 see. [What is CDM and how to use it](/common-data-model/).

+* Parallel writes are not supported. It is not recommended. There is no locking mechanism at the storage layer.

+Spark 2.4, 3.1, and 3.2 are supported.

+## Samples

+Checkout the [sample code and CDM files](https://github.com/Azure/spark-cdm-connector/tree/spark3.2/samples) for a quick start.

+| sasToken |The sastoken to access the relative storageAccount with the correct permissions | \<token\>|

+ .option("entityDefinitionPath", "core/applicationCommon/TeamMembership.cdm.json/TeamMembership")

+# Create reports in update management center (preview)

+| project lastTime, id, OS, updateRollupCount, featurePackCount, servicePackCount, definitionCount, securityCount, criticalCount, updatesCount, toolsCount, otherCount

+## January 2023

+Here's what changed in January 2023:

+### Watermarking for Azure Virtual Desktop now in public preview

+Watermarking for Azure Virtual Desktop is now in public preview for the Windows Desktop client. This feature protects sensitive information from being captured on client endpoints by adding watermarks to remote desktops. For more information, see [our blog post](https://techcommunity.microsoft.com/t5/azure-virtual-desktop-blog/announcing-public-preview-for-watermarking-on-azure-virtual/ba-p/3730264) or [Watermarking in Azure Virtual Desktop](watermarking.md).

+

+### Give or Take Control for macOS Teams on Azure Virtual Desktop now generally available

+Version 1.31.2211.15001 of the WebRTC Redirector service includes support for Give or Take Control for macOS users. This version includes performance improvements for Give or Take Control on Windows. For more information, see [Updates for version 1.31.2211.15001](whats-new-webrtc.md#updates-for-version-131221115001).

+### Microsoft Teams application window sharing on Azure Virtual Desktop now generally available

+Previously, users could only share their full desktop windows or a Microsoft PowerPoint Live presentation during Teams calls. With application window sharing, users can now choose a specific window to share from their desktop screen and help reduce the risk of displaying sensitive content during meetings or calls. For more information, see [our blog post](https://techcommunity.microsoft.com/t5/azure-virtual-desktop-blog/microsoft-teams-application-window-sharing-is-now-generally/ba-p/3719595).

+### Windows 7 End of Support

+Starting January 10, 2023, Azure Virtual Desktop no longer supports Windows 7 as a client or host. We recommend upgrading to a supported Windows release. For more information, see [our blog post](https://techcommunity.microsoft.com/t5/azure-virtual-desktop/avd-support-for-windows-7-ended-on-january-10th-2023/m-p/3715785).

+### Restrictions

+Double encryption at rest isn't currently supported with either Ultra Disks or Premium SSD v2 disks.

+## Restrictions

+Double encryption at rest isn't currently supported with either Ultra Disks or Premium SSD v2 disks.

+## Restrictions

+Double encryption at rest isn't currently supported with either Ultra Disks or Premium SSD v2 disks.

+For more details of cloud-init logging, see the [cloud-init documentation](https://cloudinit.readthedocs.io/en/latest/development/logging.html)

+## Restrictions

+Double encryption at rest isn't currently supported with either Ultra Disks or Premium SSD v2 disks.

+| **Marketplace** | Represents the entire suite of Azure 'Commercial Marketplace Experiences' services. | Both | No | Yes |