-|**Retrieved documents** | Specifies the number of top-scoring documents from your data index used to generate responses. You might want to increase the value when you have short documents or want to provide more context. The default value is 3. |

-| `retrieved_documents` | number | Optional | 3 | Specifies the number of top-scoring documents from your data index used to generate responses. You might want to increase the value when you have short documents or want to provide more context. |

-| `strictness` | number | Optional | 3 | Sets the threshold to categorize documents as relevant to your queries. Raising the value means a higher threshold for relevance and filters out more less-relevant documents for responses. Setting this value too high might cause the model to fail to generate responses due to limited available documents. |

-| `topNDocuments` | number | Optional | 5 | Number of documents that need to be fetched for document augmentation. |

- Reserved CPU is dependent on node type and cluster configuration, which may cause less allocatable CPU due to running additional features.

- | CPU cores on host | 1 | 2 | 4 | 8 | 16 | 32|64|

- |||||||||

- |Kube-reserved (millicores)|60|100|140|180|260|420|740|

- Memory utilized by AKS includes the sum of two values.

- 1. **`kubelet` daemon**

- The `kubelet` daemon is installed on all Kubernetes agent nodes to manage container creation and termination.

-

- By default on AKS, `kubelet` daemon has the *memory.available<750Mi* eviction rule, ensuring a node must always have at least 750Mi allocatable at all times. When a host is below that available memory threshold, the `kubelet` will trigger to terminate one of the running pods and free up memory on the host machine.

- 2. **A regressive rate of memory reservations** for the kubelet daemon to properly function (*kube-reserved*).

- - 25% of the first 4 GB of memory

- - 20% of the next 4 GB of memory (up to 8 GB)

- - 10% of the next 8 GB of memory (up to 16 GB)

- - 6% of the next 112 GB of memory (up to 128 GB)

- - 2% of any memory above 128 GB

-> - Deployments before 1st May 2023: These deployments will continue to have the default domain names like <label>.cloudapp.net mapped to the application gateway's Public IP address.

-A backend can have NICs, virtual machine scale sets, public IP addresses, internal IP addresses, fully qualified domain names (FQDN), and multi-tenant backends like Azure App Service. In this example, you create two virtual machines to use as backend servers for the application gateway. You also install NGINX on the virtual machines to test the application gateway.

-The backend pool is used to route requests to the backend servers that serve the request. Backend pools can be composed of NICs, Virtual Machine Scale Sets, public IP addresses, internal IP addresses, fully qualified domain names (FQDN), and multi-tenant backends like Azure App Service. In this example, you'll create an empty backend pool with your application gateway and then add backend targets to the backend pool.

-Review the settings on the **Review + create** tab, and then select **Create** to create the virtual network, the public IP address, and the application gateway. It may take several minutes for Azure to create the application gateway. Wait until the deployment finishes successfully before moving on to the next section.

-Now that you have created the Application Gateway, create the backend virtual machines which will host the websites. A backend can be composed of NICs, virtual machine scale sets, public IP address, internal IP address, fully qualified domain names (FQDN), and multi-tenant backends like Azure App Service.

-When reading a compressed file, either as a zip or a KMZ, it's unzipped and scanned for the first valid file. For example, doc.kml, or a file with other valid extension, such as: .kml, .xml, geojson, .json, .csv, .tsv, or .txt. Then, images referenced in KML and GeoRSS files are preloaded to ensure they're accessible. Inaccessible image data may load an alternative fallback image or removed from the styles. Images extracted from KMZ files are converted to data URIs.

-The result from the read function is a `SpatialDataSet` object. This object extends the GeoJSON FeatureCollection class. It can easily be passed into a `DataSource` as-is to render its features on a map. The `SpatialDataSet` not only contains feature information, but it may also include KML ground overlays, processing metrics, and other details as outlined in the following table.

-You may optionally provide a proxy service for accessing cross domain assets that may not have CORS enabled. The read function tries to access files on another domain using CORS first. After the first time it fails to access any resource on another domain using CORS it only requests more files if a proxy service has been provided. The read function appends the file URL to the end of the proxy URL provided. This snippet of code shows how to pass a proxy service into the read function:

-You may optionally provide a proxy service for accessing cross domain assets that may not have CORS enabled. This snippet of code shows you could incorporate a proxy service:

-GML is a spatial XML file specification that's often used as an extension to other XML specifications. GeoJSON data can be written as XML with GML tags using the `atlas.io.core.GmlWriter.write` function. The XML that contains GML can be read using the `atlas.io.core.GmlReader.read` function. The read function has two options:

- :::image type="content" source="./media/tutorial-route-location/basic-map.png" alt-text="A screenshot showing the most basic map that you can make by calling `atlas.Map` using your Azure Maps account key.":::

- * To define how the route line is rendered, a line layer is created and attached to the data source. To ensure that the route line doesn't cover up the road labels, we've passed a second parameter with the value of `'labels'`.

- :::image type="content" source="./media/tutorial-route-location/map-pins.png" alt-text="A screenshot showing a map with a route containing a blue teardrop pin marking the start point at Microsoft in Redmond Washington and a blue round pin marking the end point at a gas station in Seattle.":::

- :::image type="content" source="./media/tutorial-route-location/map-route.png" alt-text="A screenshot showing a map that demonstrates the Azure Map control and Route service.":::

-| Service or feature | Migration recommendation | Other extensions installed | More information |

-| [VM insights](../vm/vminsights-overview.md) | Generally Available | Dependency Agent extension, if youΓÇÖre using the Map Services feature | [Enable VM Insights](../vm/vminsights-enable-overview.md) |

-| [Container insights](../containers/container-insights-overview.md) | Public preview | Containerized Azure Monitor agent | [Enable Container Insights](../containers/container-insights-onboard.md) |

-| [Microsoft Defender for Cloud](../../security-center/security-center-introduction.md) | Moving to an agentless solution | | Many features available now all will be available by April 2024|

-| [Microsoft Sentinel](../../sentinel/overview.md) | <ul><li>Windows Security Events: [GA](../../sentinel/connect-windows-security-events.md?tabs=AMA)</li><li>Windows Forwarding Event (WEF): [GA](../../sentinel/data-connectors/windows-forwarded-events.md)</li><li>Windows DNS logs: [Public preview](../../sentinel/connect-dns-ama.md)</li><li>Linux Syslog CEF: [Public preview](../../sentinel/connect-cef-ama.md#set-up-the-common-event-format-cef-via-ama-connector)</li></ul> | Sentinel DNS extension, if youΓÇÖre collecting DNS logs. For all other data types, you just need the Azure Monitor Agent extension. | See [Gap analysis for Microsoft Sentinel](../../sentinel/ama-migrate.md#gap-analysis-between-agents) for a comparison of the extra data collected by Microsoft Sentinel. |

-| [Change Tracking and Inventory Management](../../automation/change-tracking/overview.md) | Moving to an agentless solution | | Available November 2023 |

-| [Network Watcher](../../network-watcher/network-watcher-monitoring-overview.md) | New service called Connection Monitor: Public preview with Azure Monitor Agent | Azure NetworkWatcher extension | [Monitor network connectivity by using Azure Monitor Agent](../../network-watcher/azure-monitor-agent-with-connection-monitor.md) |

-| Azure Stack HCI Insights | Private preview | | [Sign up here](https://aka.ms/amadcr-privatepreviews) |

-| Azure Virtual Desktop (AVD) Insights | Generally Available | | |

-| Service | Migration recommendation | Other extensions installed | More information |

-| [Update Management](../../automation/update-management/overview.md) | Update Manager - Public preview (no dependency on Log Analytics agents or Azure Monitor Agent) | None | [Update Manager (Public preview with Azure Monitor Agent) documentation](../../update-center/index.yml) |

-| [Automation Hybrid Runbook Worker overview](../../automation/automation-hybrid-runbook-worker.md) | Automation Hybrid Worker Extension - Generally available (no dependency on Log Analytics agents or Azure Monitor Agent) | None | [Migrate an existing Agent based to Extension based Hybrid Workers](../../automation/extension-based-hybrid-runbook-worker-install.md#migrate-an-existing-agent-based-to-extension-based-hybrid-workers) |

- |Frequency of evaluation|How often the query is run. Can be set from a minute to a day.|

- > One-minute alert rule frequency is supported only for queries that can pass an internal optimization manipulation. When you will write the query you will contain the following error message: “Couldn’t optimize the query because …”.

- > The following are the main reasons why a query will not be supported for one-minute frequency:

- > * The query contains the search, ΓÇ£union *ΓÇ¥ or ΓÇ£takeΓÇ¥ (limit)

- > * The query contains the ingestion_time() function

- > * The query uses the adx pattern

- > * The query calls a function that calls other tablesΓÇ¥

-[:::image type="content" source="https://img.shields.io/nuget/vpre/Microsoft.Extensions.Logging.ApplicationInsights.svg" alt-text="NuGet iLogger banner":::

-[:::image type="content" source="https://img.shields.io/nuget/vpre/Microsoft.ApplicationInsights.NLogTarget.svg" alt-text="NuGet NLog banner":::

-[:::image type="content" source="https://img.shields.io/nuget/vpre/Microsoft.ApplicationInsights.Log4NetAppender.svg" alt-text="NuGet Log4Net banner":::

-[:::image type="content" source="https://img.shields.io/nuget/vpre/Microsoft.ApplicationInsights.TraceListener.svg" alt-text="NuGet System.Diagnostics banner":::

-[:::image type="content" source="https://img.shields.io/nuget/vpre/Microsoft.ApplicationInsights.DiagnosticSourceListener.svg" alt-text="NuGet Diagnostic Source Listener banner":::

-[:::image type="content" source="https://img.shields.io/nuget/vpre/Microsoft.ApplicationInsights.EtwCollector.svg" alt-text="NuGet Etw Collector banner":::

-[:::image type="content" source="https://img.shields.io/nuget/vpre/Microsoft.ApplicationInsights.EventSourceListener.svg" alt-text="NuGet Event Source Listener banner":::

-[:::image type="content" source="../logs/media/data-platform-logs/logs-structure-ai.png" lightbox="../logs/media/data-platform-logs/logs-structure-ai.png" alt-text="Diagram that shows the Azure Monitor Logs structure for Application Insights.":::

-The Node.js client library can automatically monitor incoming and outgoing HTTP requests, exceptions, and some system metrics. Beginning in version 0.20, the client library also can monitor some common [third-party packages](https://github.com/microsoft/node-diagnostic-channel/tree/master/src/diagnostic-channel-publishers#currently-supported-modules), like MongoDB, MySQL, and Redis. All events related to an incoming HTTP request are correlated for faster troubleshooting.

-

-

-

-

-

-

-

-

-

- 

- 

- 

-

-

-

- 

-5. Ensure that you change override value to **True** for the **Enabled** parameter value.<br><br> 

-4. Change the **Interval** parameter value to your desired interval value. In the example below, the value is set to 1440 minutes (one day).<br><br> <br>

- If the value is set to less than 1440 minutes, then the rule runs on a one day interval. In this example, the rule ignores the interval value and runs at a frequency of one day.

-6. On any of the focus area pages, you can view the prioritized recommendations made for your environment. Click a recommendation under **Affected Objects** to view details about why the recommendation is made.<br><br> <br>

- Here's a screenshot showing the Log Search query:<br><br> <br>

-

-

-

-

-

-

-[](media/vminsights-change-analysis/investigate-changes-screenshot-zoom.png#lightbox)

-[](media/vminsights-change-analysis/change-details-screenshot.png#lightbox)

-[](media/vminsights-configure-workspace/log-analytics-workspaces.png#lightbox)

- [](../vm/media/vminsights-enable-policy/configure-workspace.png#lightbox)

- [](../vm/media/vminsights-enable-policy/workspace-configuration.png#lightbox)

- [](../vm/media/vminsights-enable-portal/enable-vminsights-vm-portal.png#lightbox)

- [](media/vminsights-enable-policy/assign-initiative.png#lightbox)

- [](media/vminsights-enable-policy/assignment-workspace.png#lightbox)

- [](media/vminsights-enable-policy/manage-policy-page-01.png#lightbox)

- [](media/vminsights-enable-policy/view-compliance.png#lightbox)

- [](./media/vminsights-enable-policy/policy-view-compliance.png#lightbox)

- [](media/vminsights-enable-policy/compliance-details.png#lightbox)

- [](media/vminsights-enable-policy/policy-compliance-details.png#lightbox)

- [](media/vminsights-enable-policy/new-remediation-task.png#lightbox)

-[](media/vminsights-enable-policy/remediation.png#lightbox)

-

-

-

-

-

-

-

-

-

-

- 

-

-

-

-

-

-

-

-

-

- :::image type="content" source="media/vminsights-workbooks/workbook-dropdown-gallery-01.png" lightbox="media/vminsights-workbooks/workbook-dropdown-gallery-01.png" alt-text="Screenshot that shows a workbook dropdown list in V M insights.":::

-

-

-Each section has its own advanced settings, which are accessible via the settings  icon located to the right of **Add parameters**.

-

-

-

-

-

-

-

-

-description: Learn how to create a Calling Widget widget experience with the Azure Communication Services CallComposite to facilitate click to call.

-# Get started with a click to call experience using Azure Communication Services

-

-This project aims to guide developers on creating a seamless click to call experience using the Azure Communication UI Library.

-As per your requirements, you may need to offer your customers an easy way to reach out to you without any complex setup.

-Click to call is a simple yet effective concept that facilitates instant interaction with, customer support, financial advisor, and other customer-facing teams. The goal of this tutorial is to assist you in making interactions with your customers just a click away.

-If you wish to try it out, you can download the code from [GitHub](https://github.com/Azure-Samples/communication-services-javascript-quickstarts/tree/main/ui-library-click-to-call).

-Following this tutorial will:

-This tutorial is broken down into three parts:

-## Prerequisites

-### Set up the project

-Only use this step if you are creating a new application.

-To set up the react App, we use the `create-react-app` command line tool. This tool

-creates an easy to run TypeScript application powered by React. This command will create a simple react application using TypeScript.

-```bash

-# Create an Azure Communication Services App powered by React.

-npx create-react-app ui-library-click-to-call-app --template typescript

-# Change to the directory of the newly created App.

-cd ui-library-click-to-call-app

-```

-### Get your dependencies

-Then you need to update the dependency array in the `package.json` to include some beta and alpha packages from Azure Communication Services for this to work:

-```json

-"@azure/communication-calling": "1.14.1-beta.1",

-"@azure/communication-chat": "1.3.2-beta.2",

-"@azure/communication-react": "1.7.0-beta.1",

-"@azure/communication-calling-effects": "1.0.1",

-"@fluentui/react-icons": "~2.0.203",

-"@fluentui/react": "~8.98.3",

-```

-Once you run these commands, youΓÇÖre all set to start working on your new project. In this tutorial, we are modifying the files in the `src` directory.

-## Initial app setup

-To get started, we replace the provided `App.tsx` content with a main page that will:

-`src/App.tsx`

-```ts

-// imports needed

-import { CallAdapterLocator } from '@azure/communication-react';

-import './App.css';

-import { useEffect, useMemo, useState } from 'react';

-import { CommunicationIdentifier, CommunicationUserIdentifier } from '@azure/communication-common';

-import { Spinner, Stack, initializeIcons, registerIcons } from '@fluentui/react';

-import { CallAdd20Regular, Dismiss20Regular } from '@fluentui/react-icons';

-```

-```ts

-type AppPages = "calling-widget" | "new-window-call";

-registerIcons({

- icons: { dismiss: <Dismiss20Regular />, callAdd: <CallAdd20Regular /> },

-});

-initializeIcons();

-function App() {

- const [page, setPage] = useState<AppPages>("calling-widget");

- /**

- * Token for local user.

- */

- const token = "<Enter your Azure Communication Services token here>";

- /**

- * User identifier for local user.

- */

- const userId: CommunicationIdentifier = {

- communicationUserId: "<Enter your user Id>",

- };

- /**

- * This decides where the call will be going. This supports many different calling modalities in the Call Composite.

- *

- * - Teams meeting locator: {meetingLink: 'url to join link for a meeting'}

- * - Azure Communication Services group call: {groupId: 'GUID that defines the call'}

- * - Azure Communication Services Rooms call: {roomId: 'guid that represents a rooms call'}

- * - Teams adhoc, Azure communications 1:n, PSTN calls all take a participants locator: {participantIds: ['Array of participant id's to call']}

- *

- * You can call teams voice apps like a Call queue with the participants locator.

- */

- const locator: CallAdapterLocator = {

- participantIds: ["<Enter Participant Id's here>"],

- };

- /**

- * The phone number needed from your Azure Communication Services resource to start a PSTN call. Can be created under the phone numbers.

- *

- * For more information on phone numbers and Azure Communication Services go to this link: https://learn.microsoft.com/en-us/azure/communication-services/concepts/telephony/plan-solution

- *

- * This can be left alone if not making a PSTN call.

- */

- const alternateCallerId = "<Enter your alternate CallerId here>";

- switch (page) {

- case "calling-widget": {

- return (

- <Stack verticalAlign='center' style={{ height: "100%", width: "100%" }}>

- <Spinner

- label={"Getting user credentials from server"}

- ariaLive="assertive"

- labelPosition="top"

- />

- </Stack>

- );

- }

- case "new-window-call": {

- return (

- <Stack verticalAlign='center' style={{ height: "100%", width: "100%" }}>

- <Spinner

- label={"Getting user credentials from server"}

- ariaLive="assertive"

- labelPosition="top"

- />

- </Stack>

- );

- }

- default: {

- return <>Something went wrong!</>

- }

- }

-}

-export default App;

-```

-In this snippet we register two new icons `<Dismiss20Regular/>` and `<CallAdd20Regular>`. These new icons are used inside the widget component that we are creating later.

-### Running the app

-We can then test to see that the basic application is working by running:

-```bash

-# Install the newe dependencies

-npm install

-# run the React app

-npm run start

-```

-Once the app is running, you can see it on `http://localhost:3000` in your browser. You should see a little spinner saying: `getting credentials from server` as

-a test message.

-## Next steps

-> [!div class="nextstepaction"]

-> [Part 1: Creating your widget](./calling-widget-tutorial-part-1-creating-your-widget.md)

-description: Learn how to construct your own custom widget for your click to call experience - Part 1.

-# Part 1 creating your widget

-To begin, we're going to make a new component. This component will serve as the widget for initiating the click to call experience.

-We are using our own widget setup for this tutorial but you can expand the functionality to suit your needs. For us, we have the widget perform the following actions:

-First step will be to create a new directory called `src/components`. Within this directory, we're going to create a new file named `CallingWidgetComponent.tsx`. We'll then proceed to set up the widget component with the following imports:

-`CallingWidgetComponent.tsx`

-```ts

-// imports needed

-import { IconButton, PrimaryButton, Stack, TextField, useTheme, Checkbox, Icon } from '@fluentui/react';

-import React, { useEffect, useState } from 'react';

-```

-Now let's introduce an interface containing the props that the component uses.

-`CallingWidgetComponent.tsx`

-```ts

-export interface clickToCallComponentProps {

- /**

- * Handler to start a new call.

- */

- onRenderStartCall: () => void;

- /**

- * Custom render function for displaying logo.

- * @returns

- */

- onRenderLogo?: () => JSX.Element;

- /**

- * Handler to set displayName for the user in the call.

- * @param displayName

- * @returns

- */

- onSetDisplayName?: (displayName: string | undefined) => void;

- /**

- * Handler to set whether to use video in the call.

- */

- onSetUseVideo?: (useVideo: boolean) => void;

-}

-```

-Each callback controls different behaviors for the calling experience.

-Finally, we add the body of the component.

-`src/views/CallingWidgetComponent.tsx`

-```ts

-/**

- * Widget for Calling Widget

- * @param props

- */

-export const CallingWidgetComponent = (

- props: clickToCallComponentProps

-): JSX.Element => {

- const { onRenderStartCall, onRenderLogo, onSetDisplayName, onSetUseVideo } =

- props;

- const [widgetState, setWidgetState] = useState<"new" | "setup">();

- const [displayName, setDisplayName] = useState<string>();

- const [consentToData, setConsentToData] = useState<boolean>(false);

- const theme = useTheme();

- useEffect(() => {

- if (widgetState === "new" && onSetUseVideo) {

- onSetUseVideo(false);

- }

- }, [widgetState, onSetUseVideo]);

- /** widget template for when widget is open, put any fields here for user information desired */

- if (widgetState === "setup" && onSetDisplayName && onSetUseVideo) {

- return (

- <Stack

- styles={clicktoCallSetupContainerStyles(theme)}

- tokens={{ childrenGap: "1rem" }}

- >

- <IconButton

- styles={collapseButtonStyles}

- iconProps={{ iconName: "Dismiss" }}

- onClick={() => setWidgetState("new")}

- />

- <Stack tokens={{ childrenGap: "1rem" }} styles={logoContainerStyles}>

- <Stack style={{ transform: "scale(1.8)" }}>

- {onRenderLogo && onRenderLogo()}

- </Stack>

- </Stack>

- <TextField

- label={"Name"}

- required={true}

- placeholder={"Enter your name"}

- onChange={(_, newValue) => {

- setDisplayName(newValue);

- }}

- />

- <Checkbox

- styles={checkboxStyles(theme)}

- label={

- "Use video - Checking this box will enable camera controls and screen sharing"

- }

- onChange={(_, checked?: boolean | undefined) => {

- onSetUseVideo(!!checked);

- }}

- ></Checkbox>

- <Checkbox

- required={true}

- styles={checkboxStyles(theme)}

- label={

- "By checking this box you are consenting that we collect data from the call for customer support reasons"

- }

- onChange={(_, checked?: boolean | undefined) => {

- setConsentToData(!!checked);

- }}

- ></Checkbox>

- <PrimaryButton

- styles={startCallButtonStyles(theme)}

- onClick={() => {

- if (displayName && consentToData) {

- onSetDisplayName(displayName);

- onRenderStartCall();

- }

- }}

- >

- StartCall

- </PrimaryButton>

- </Stack>

- );

- }

- /** default waiting state for the widget */

- return (

- <Stack

- horizontalAlign="center"

- verticalAlign="center"

- styles={clickToCallContainerStyles(theme)}

- onClick={() => {

- setWidgetState("setup");

- }}

- >

- <Stack

- horizontalAlign="center"

- verticalAlign="center"

- style={{

- height: "4rem",

- width: "4rem",

- borderRadius: "50%",

- background: theme.palette.themePrimary,

- }}

- >

- <Icon iconName="callAdd" styles={callIconStyles(theme)} />

- </Stack>

- </Stack>

- );

-};

-```

-### Time for some styles

-Once you have your component, you need some styles to give it a visually appealing look. For this, we'll create a new folder named `src/styles`. Within this folder we'll create a new file called `CallingWidgetComponent.styles.ts` and add the following styles.

-`src/styles/CallingWidgetComponent.styles.ts`

-```ts

-// needed imports

-import { IButtonStyles, ICheckboxStyles, IIconStyles, IStackStyles, Theme } from '@fluentui/react';

-```

-`CallingWidgetComponent.styles.ts`

-```ts

-export const checkboxStyles = (theme: Theme): ICheckboxStyles => {

- return {

- label: {

- color: theme.palette.neutralPrimary,

- },

- };

-};

-export const clickToCallContainerStyles = (theme: Theme): IStackStyles => {

- return {

- root: {

- width: "5rem",

- height: "5rem",

- padding: "0.5rem",

- boxShadow: theme.effects.elevation16,

- borderRadius: "50%",

- bottom: "1rem",

- right: "1rem",

- position: "absolute",

- overflow: "hidden",

- cursor: "pointer",

- ":hover": {

- boxShadow: theme.effects.elevation64,

- },

- },

- };

-};

-export const clicktoCallSetupContainerStyles = (theme: Theme): IStackStyles => {

- return {

- root: {

- width: "18rem",

- minHeight: "20rem",

- maxHeight: "25rem",

- padding: "0.5rem",

- boxShadow: theme.effects.elevation16,

- borderRadius: theme.effects.roundedCorner6,

- bottom: 0,

- right: "1rem",

- position: "absolute",

- overflow: "hidden",

- cursor: "pointer",

- },

- };

-};

-export const callIconStyles = (theme: Theme): IIconStyles => {

- return {

- root: {

- paddingTop: "0.2rem",

- color: theme.palette.white,

- transform: "scale(1.6)",

- },

- };

-};

-export const startCallButtonStyles = (theme: Theme): IButtonStyles => {

- return {

- root: {

- background: theme.palette.themePrimary,

- borderRadius: theme.effects.roundedCorner6,

- borderColor: theme.palette.themePrimary,

- },

- textContainer: {

- color: theme.palette.white,

- },

- };

-};

-export const logoContainerStyles: IStackStyles = {

- root: {

- margin: "auto",

- padding: "0.2rem",

- height: "5rem",

- width: "10rem",

- zIndex: 0,

- },

-};

-export const collapseButtonStyles: IButtonStyles = {

- root: {

- position: "absolute",

- top: "0.2rem",

- right: "0.2rem",

- zIndex: 1,

- },

-};

-```

-These styles should already be added to the widget as seen in the snippet earlier. If you added the snippet as is, these styles just need importing into the `CallingWidgetComponent.tsx` file.

-`CallingWidgetComponent.tsx`

-```ts

-// add to other imports

-import {

- clicktoCallSetupContainerStyles,

- checkboxStyles,

- startCallButtonStyles,

- clickToCallContainerStyles,

- callIconStyles,

- logoContainerStyles,

- collapseButtonStyles

-} from '../styles/CallingWidgetComponent.styles';

-```

-### Adding the widget to the app

-Now we create a new folder `src/views` and add a new file for one of our pages `CallingWidgetScreen.tsx`. This screen acts as our home page for the app where the user can start a new call.

-We want to add the following props to the page:

-`CallingWidgetScreen.tsx`

-```ts

-export interface CallingWidgetPageProps {

- token: string;

- userId:

- | CommunicationUserIdentifier

- | MicrosoftTeamsUserIdentifier;

- callLocator: CallAdapterLocator;

- alternateCallerId?: string;

-}

-```

-These properties are fed by the values that we set in `App.tsx`. We'll use these props to make post messages to the app when we want to start a call in a new window (More on this later).

-Next, lets add the page content:

-`CallingWidgetScreen.tsx`

-```ts

-// imports needed

-import { CommunicationUserIdentifier, MicrosoftTeamsUserIdentifier } from '@azure/communication-common';

-import { Stack, Text } from '@fluentui/react';

-import React, { useCallback, useEffect, useMemo, useState } from 'react';

-import { CallingWidgetComponent } from '../components/CallingWidgetComponent';

-import { CallAdapterLocator } from '@azure/communication-react';

-import hero from '../hero.svg';

-```

-```ts

-export const CallingWidgetScreen = (props: CallingWidgetPageProps): JSX.Element => {

- const { token, userId, callLocator, alternateCallerId } = props;

- const [userDisplayName, setUserDisplayName] = useState<string>();

- const [useVideo, setUseVideo] = useState<boolean>(false);

- // we also want to make this memoized version of the args for the new window.

- const adapterParams = useMemo(() => {

- const args = {

- userId: userId as CommunicationUserIdentifier,

- displayName: userDisplayName ?? "",

- token,

- locator: callLocator,

- alternateCallerId,

- };

- return args;

- }, [userId, userDisplayName, token, callLocator, alternateCallerId]);

- return (

- <Stack

- style={{ height: "100%", width: "100%", padding: "3rem" }}

- tokens={{ childrenGap: "1.5rem" }}

- >

- <Stack style={{ margin: "auto" }}>

- <Stack

- style={{ padding: "3rem" }}

- horizontal

- tokens={{ childrenGap: "2rem" }}

- >

- <Text style={{ marginTop: "auto" }} variant="xLarge">

- Welcome to a Calling Widget sample

- </Text>

- <img

- style={{ width: "7rem", height: "auto" }}

- src={hero}

- alt="kcup logo"

- />

- </Stack>

- <Text>

- Welcome to a Calling Widget sample for the Azure Communication Services UI

- Library. Sample has the ability to:

- </Text>

- <ul>

- <li>

- Adhoc call teams users with a tenant set that allows for external

- calls

- </li>

- <li>Joining Teams interop meetings as a Azure Communication Services user</li>

- <li>Make a calling Widget PSTN call to a help phone line</li>

- <li>Join a Azure Communication Services group call</li>

- </ul>

- <Text>

- As a user all you need to do is click the widget below, enter your

- display name for the call - this will act as your caller id, and

- action the <b>start call</b> button.

- </Text>

- </Stack>

- <Stack

- horizontal

- tokens={{ childrenGap: "1.5rem" }}

- style={{ overflow: "hidden", margin: "auto" }}

- >

- <CallingWidgetComponent

- onRenderStartCall={() => {}}

- onRenderLogo={() => {

- return (

- <img

- style={{ height: "4rem", width: "4rem", margin: "auto" }}

- src={hero}

- alt="logo"

- />

- );

- }}

- onSetDisplayName={setUserDisplayName}

- onSetUseVideo={setUseVideo}

- />

- </Stack>

- </Stack>

- );

-};

-```

-This page provides general information on the current capabilities of our calling experiences, along with the addition of our previously created widget component.

-To integrate the widget screen, we simply update the existing `'calling-widget'` case in the root of the app `App.tsx`, by adding the new view.

-`App.tsx`

-```ts

-// add this with the other imports

-import { CallingWidgetScreen } from './views/CallingWidgetScreen';

-```

-```ts

-

- case 'calling-widget': {

- if (!token || !userId || !locator) {

- return (

- <Stack verticalAlign='center' style={{height: '100%', width: '100%'}}>

- <Spinner label={'Getting user credentials from server'} ariaLive="assertive" labelPosition="top" />;

- </Stack>

- )

- }

- return <CallingWidgetScreen token={token} userId={userId} callLocator={locator} alternateCallerId={alternateCallerId}/>;

-}

-

-```

-Once you have set the arguments defined in `App.tsx`, run the app with `npm run start` to see the changes:

-

-Then when you action the widget button, you should see:

-

-Yay! We have made the control surface for the widget! Next, we'll discuss what we need to add to make this widget start a call in a new window.

-> [!div class="nextstepaction"]

-> [Part 2: Creating a new window calling experience](./calling-widget-tutorial-part-2-creating-new-window-experience.md)

-description: Learn how to deal with post messaging and React to create a new window calling experience with the CallComposite - Part 2.

-# Part 2 creating a new window calling experience

-Now that we have a running application with our widget on the home page, we'll talk about starting the calling experience for your users with a new window. This scenario allows you to give your customer the ability to browse while still seeing your call in a new window. This can be useful in situations similar to when your users use video and screen sharing.

-To begin, we'll create a new view in the `src/views` folder called `NewWindowCallScreen.tsx`. This new screen will be used by the `App.tsx` file to go into a new call with the arguments provided to it using our `CallComposite`. If desired, the `CallComposite` can be swapped with a stateful client and UI component experience if desired as well, but that won't be covered in this tutorial. For more information see our [storybook documentation](https://azure.github.io/communication-ui-library/?path=/docs/quickstarts-statefulcallclient--page) about the stateful client.

-`src/views/NewWindowCallScreen.tsx`

-```ts

-// imports needed

-import { CommunicationUserIdentifier, AzureCommunicationTokenCredential } from '@azure/communication-common';

-import {

- CallAdapter,

- CallAdapterLocator,

- CallComposite,

- useAzureCommunicationCallAdapter

-} from '@azure/communication-react';

-import { Spinner, Stack } from '@fluentui/react';

-import React, { useMemo } from 'react';

-```

-```ts

-export const NewWindowCallScreen = (props: {

- adapterArgs: {

- userId: CommunicationUserIdentifier;

- displayName: string;

- token: string;

- locator: CallAdapterLocator;

- alternateCallerId?: string;

- };

- useVideo: boolean;

-}): JSX.Element => {

- const { adapterArgs, useVideo } = props;

- const credential = useMemo(() => {

- try {

- return new AzureCommunicationTokenCredential(adapterArgs.token);

- } catch {

- console.error("Failed to construct token credential");

- return undefined;

- }

- }, [adapterArgs.token]);

- const args = useMemo(() => {

- return {

- userId: adapterArgs.userId,

- displayName: adapterArgs.displayName,

- credential,

- token: adapterArgs.token,

- locator: adapterArgs.locator,

- alternateCallerId: adapterArgs.alternateCallerId,

- };

- }, [

- adapterArgs.userId,

- adapterArgs.displayName,

- credential,

- adapterArgs.token,

- adapterArgs.locator,

- adapterArgs.alternateCallerId,

- ]);

- const afterCreate = (adapter: CallAdapter): Promise<CallAdapter> => {

- adapter.on("callEnded", () => {

- adapter.dispose();

- window.close();

- });

- adapter.joinCall(true);

- return new Promise((resolve, reject) => resolve(adapter));

- };

- const adapter = useAzureCommunicationCallAdapter(args, afterCreate);

- if (!adapter) {

- return (

- <Stack

- verticalAlign="center"

- styles={{ root: { height: "100vh", width: "100vw" } }}

- >

- <Spinner

- label={"Creating adapter"}

- ariaLive="assertive"

- labelPosition="top"

- />

- </Stack>

- );

- }

- return (

- <Stack styles={{ root: { height: "100vh", width: "100vw" } }}>

- <CallComposite

- options={{

- callControls: {

- cameraButton: useVideo,

- screenShareButton: useVideo,

- moreButton: false,

- peopleButton: false,

- displayType: "compact",

- },

- localVideoTileOptions: {

- position: !useVideo ? "hidden" : "floating",

- },

- }}

- adapter={adapter}

- />

- </Stack>

- );

-};

-```

-To configure our `CallComposite` to fit in the Calling Widget, we need to make some changes. Depending on your use case, we have a number of customizations that can change the user experience. This sample chooses to hide the local video tile, camera, and screen sharing controls if the user opts out of video for their call. In addition to these configurations on the `CallComposite`, we use the `afterCreate` function defined in the snippet to automatically join the call. This bypasses the configuration screen and drop the user into the call with their mic live, as well auto close the window when the call ends. Just remove the call to `adapter.join(true);` from the `afterCreate` function and the configuration screen shows as normal. Next let's talk about how to get this screen the information once we have our `CallComposite` configured.

-To make sure we are passing around data correctly, let's create some handlers to send post messages between the parent window and child window to signal that we want some information. See diagram:

-

-This flow illustrates that if the child window has spawned, it needs to ask for the arguments. This behavior has to do with React and that if the parent window just sends a message right after creation, the call adapter arguments needed are lost before the application mounts. The adapter arguments are lost because in the new window the listener is not set yet until after a render pass completes. More on where these event handlers are made to come.

-Now we want to update the splash screen we created earlier. First we add a reference to the new child window that we create.

-`CallingWidgetScreen.tsx`

-```ts

-

- const [userDisplayName, setUserDisplayName] = useState<string>();

- const newWindowRef = useRef<Window | null>(null);

- const [useVideo, setUseVideo] = useState<boolean>(false);

-

-```

-Next we create a handler that we pass to our widget that creates a new window that starts the process of sending the post messages.

-`CallingWidgetScreen.tsx`

-```ts

-

- const startNewWindow = useCallback(() => {

- const startNewSessionString = 'newSession=true';

- newWindowRef.current = window.open(

- window.origin + `/?${startNewSessionString}`,

- 'call screen',

- 'width=500, height=450'

- );

- }, []);

-

-```

-This handler starts a new window position and place a new query arg in the window URL so that the main application knows that it's time to start a new call. The path that you give the window can be a new path in your application where your calling experience exists. For us this will be the `NewWindowCallScreen.tsx` file but this can also be a React app on its own.

-Next we add a `useEffect` hook that is creating an event handler listening for new post messages from the child window.

-`CallingWidgetScreen.tsx`

-```ts

-

- useEffect(() => {

- window.addEventListener('message', (event) => {

- if (event.origin !== window.origin) {

- return;

- }

- if (event.data === 'args please') {

- const data = {

- userId: adapterParams.userId,

- displayName: adapterParams.displayName,

- token: adapterParams.token,

- locator: adapterParams.locator,

- alternateCallerId: adapterParams.alternateCallerId,

- useVideo: useVideo

- };

- console.log(data);

- newWindowRef.current?.postMessage(data, window.origin);

- }

- });

- }, [adapterParams, adapterParams.locator, adapterParams.displayName, useVideo]);

-

-```

-This handler listens for events from the child window. (**NOTE: make sure that if the origin of the message is not from your app then return**) If the child window asks for arguments, we send it with the arguments needed to construct a `AzureCommunicationsCallAdapter`.

-Finally on this screen, let's add the `startNewWindow` handler to the widget so that it knows to create the new window. We do this by adding the property to the template of the widget screen like below.

-`CallingWidgetScreen.tsx`

-```ts

-

- <Stack horizontal tokens={{ childrenGap: '1.5rem' }} style={{ overflow: 'hidden', margin: 'auto' }}>

- <CallingWidgetComponent

- onRenderStartCall={startNewWindow}

- onRenderLogo={() => {

- return (

- <img

- style={{ height: '4rem', width: '4rem', margin: 'auto' }}

- src={hero}

- alt="logo"

- />

- );

- }}

- onSetDisplayName={setUserDisplayName}

- onSetUseVideo={setUseVideo}

- />

- </Stack>

-

-```

-Next, we need to make sure that our application can listen for and ask for the messages from what would be the parent window. First to start, you might recall that we added a new query parameter to the URL of the application `newSession=true`. To use this and have our app look for that in the URL, we need to create a utility function to parse out that parameter. Once we do that, we'll use it to make our application behave differently when it's received.

-To do that, let's add a new folder `src/utils` and in this folder, we add the file `AppUtils.ts`. In this file let's put the following function:

-`AppUtils.ts`

-```ts

-/**

- * get go ahead to request for adapter args from url

- * @returns

- */

-export const getStartSessionFromURL = (): boolean | undefined => {

- const urlParams = new URLSearchParams(window.location.search);

- return urlParams.get("newSession") === "true";

-};

-```

-This function will look into our application's URL and see if the parameters we're looking for are there. If desired, you can also stick some other parameters in there to extend other functionality for your application.

-As well, we'll want to add a new type in here to track the different pieces needed to create a `AzureCommunicationCallAdapter`. This type can also be simplified if you are using our calling stateful client, this approach won't be covered in this tutorial though.

-`AppUtils.ts`

-```ts

-/**

- * Properties needed to create a call screen for a Azure Communication Services CallComposite.

- */

-export type AdapterArgs = {

- token: string;

- userId: CommunicationIdentifier;

- locator: CallAdapterLocator;

- displayName?: string;

- alternateCallerId?: string;

-};

-```

-Once we have added these two things, we can go back to the `App.tsx` file to make some more updates.

-First thing we want to do is update `App.tsx` to use that new utility function that we created in `AppUtils.ts`. We want to use a `useMemo` hook for the `startSession` parameter so that it's fetched exactly once and not at every render. The fetch of `startSession` is done like so:

-`App.tsx`

-```ts

-// you will need to add these imports

-import { useMemo } from 'react';

-import { AdapterArgs, getStartSessionFromURL } from './utils/AppUtils';

-```

-```ts

- const startSession = useMemo(() => {

- return getStartSessionFromURL();

- }, []);

-```

-Following this, we want to add some state to make sure that we're tracking the new arguments for the adapter. We pass these arguments to the `NewWindowCallScreen.tsx` view that we made earlier so it can construct an adapter. As well state to track whether the user wants to use video controls or not.

-`App.tsx`

-```ts

-/**

- * Properties needed to start an Azure Communication Services CallAdapter. When these are set the app will go to the Call screen for the

- * click to call scenario. Call screen should create the credential that will be used in the call for the user.

- */

- const [adapterArgs, setAdapterArgs] = useState<AdapterArgs | undefined>();

- const [useVideo, setUseVideo] = useState<boolean>(false);

-```

-We now want to add an event listener to `App.tsx` to listen for post messages. Insert a `useEffect` hook with an empty dependency array so that we add the listener only once on the initial render.

-`App.tsx`

-```ts

-import { CallAdapterLocator } from "@azure/communication-react";

-import { CommunicationIdentifier } from '@azure/communication-common';

-```

-```ts

- useEffect(() => {

- window.addEventListener('message', (event) => {

- if (event.origin !== window.location.origin) {

- return;

- }

- if ((event.data as AdapterArgs).userId && (event.data as AdapterArgs).displayName !== '') {

- console.log(event.data);

- setAdapterArgs({

- userId: (event.data as AdapterArgs).userId as CommunicationUserIdentifier,

- displayName: (event.data as AdapterArgs).displayName,

- token: (event.data as AdapterArgs).token,

- locator: (event.data as AdapterArgs).locator,

- alternateCallerId: (event.data as AdapterArgs).alternateCallerId

- });

- setUseVideo(!!event.data.useVideo);

- }

- });

- }, []);

-```

-Next, we want to add two more `useEffect` hooks to `App.tsx`. These two hooks will:

-`App.tsx`

-```ts

- useEffect(() => {

- if (startSession) {

- console.log('asking for args');

- if (window.opener) {

- window.opener.postMessage('args please', window.opener.origin);

- }

- }

- }, [startSession]);

- useEffect(() => {

- if (adapterArgs) {

- console.log('starting session');

- setPage('new-window-call');

- }

- }, [adapterArgs]);

-```

-Finally, once we have done that, we want to add the new screen that we made earlier to the template as well. We also want to make sure that we do not show the Calling widget screen if the `startSession` parameter is found. Using this parameter this way avoids a flash for the user.

-`App.tsx`

-```ts

-// add with other imports

-import { NewWindowCallScreen } from './views/NewWindowCallScreen';

-```

-```ts

- switch (page) {

- case 'calling-widget': {

- if (!token || !userId || !locator || startSession !== false) {

- return (

- <Stack verticalAlign='center' style={{height: '100%', width: '100%'}}>

- <Spinner label={'Getting user credentials from server'} ariaLive="assertive" labelPosition="top" />;

- </Stack>

- )

-

- }

- return <CallingWidgetScreen token={token} userId={userId} callLocator={locator} alternateCallerId={alternateCallerId}/>;

- }

- case 'new-window-call': {

- if (!adapterArgs) {

- return (

- <Stack verticalAlign='center' style={{ height: '100%', width: '100%' }}>

- <Spinner label={'Getting user credentials from server'} ariaLive="assertive" labelPosition="top" />;

- </Stack>

- )

- }

- return (

- <NewWindowCallScreen

- adapterArgs={{

- userId: adapterArgs.userId as CommunicationUserIdentifier,

- displayName: adapterArgs.displayName ?? '',

- token: adapterArgs.token,

- locator: adapterArgs.locator,

- alternateCallerId: adapterArgs.alternateCallerId

- }}

- useVideo={useVideo}

- />

- );

- }

- }

-```

-Now, when the application runs in a new window, it sees that it's supposed to start a call so it will:

-Now when you pass in the arguments, set your `displayName`, and click `Start Call` you should see the following screens:

-

-With this new window experience, your users are able to:

-This concludes the tutorial for click to call with a new window experience. Next will be an optional step to embed the calling surface into the widget itself keeping your users on their current page.

-If you would like to learn more about the Azure Communication Services UI library, check out our [storybook documentation](https://azure.github.io/communication-ui-library/?path=/story/overview--page).

-> [!div class="nextstepaction"]

-> [Part 3: Embedding your calling experience](./calling-widget-tutorial-part-3-embedding-your-calling-experience.md)

-description: Learn how to embed a calling experience inside your new widget - Part 3.

-# Part 3 (optional) embedding your calling experience

-Finally in this optional section of the tutorial we'll talk about making an embedded version of the Calling surface. We'll continue from where we left off in the last section and make some modifications to our existing screens.

-To start, let's take a look at the props for the `CallingWidgetComponent.tsx` props, these will need to be updated to have the widget hold the Calling surface. We'll make two changes.

-`CallingWidgetComponent.tsx`

-```ts

-export interface CallingWidgetComponentProps {

- /**

- * arguments for creating an AzureCommunicationCallAdapter for your Calling experience

- */

- adapterArgs: AdapterArgs;

- /**

- * if provided, will be used to create a new window for call experience. if not provided

- * will use the current window.

- */

- onRenderStartCall?: () => void;

- /**

- * Custom render function for displaying logo.

- * @returns

- */

- onRenderLogo?: () => JSX.Element;

- /**

- * Handler to set displayName for the user in the call.

- * @param displayName

- * @returns

- */

- onSetDisplayName?: (displayName: string | undefined) => void;

- /**

- * Handler to set whether to use video in the call.

- */

- onSetUseVideo?: (useVideo: boolean) => void;

-}

-```

-Now, we'll need to introduce some logic to use these arguments to make sure that we're starting a call appropriately. This will include adding state to create an `AzureCommunicationCallAdapter` inside the widget itself so it will look a lot like the logic in `NewWindowCallScreen.tsx` adding the adapter to the widget will look something like this:

-`CallingWidgetComponent.tsx`

-```ts

-// add this to the other imports

-import { CommunicationUserIdentifier, AzureCommunicationTokenCredential } from '@azure/communication-common';

-import {

- CallAdapter,

- CallAdapterLocator,

- CallComposite,

- useAzureCommunicationCallAdapter,

- AzureCommunicationCallAdapterArgs

-} from '@azure/communication-react';

-import { AdapterArgs } from '../utils/AppUtils';

-// lets update our react imports as well

-import React, { useCallback, useEffect, useMemo, useState } from 'react';

-```

-```ts

- const credential = useMemo(() => {

- try {

- return new AzureCommunicationTokenCredential(adapterArgs.token);

- } catch {

- console.error('Failed to construct token credential');

- return undefined;

- }

- }, [adapterArgs.token]);

- const callAdapterArgs = useMemo(() => {

- return {

- userId:adapterArgs.userId,

- credential: credential,

- locator: adapterArgs.locator,

- displayName: displayName,

- alternateCallerId: adapterArgs.alternateCallerId

- }

- },[adapterArgs.locator, adapterArgs.userId, credential, displayName])

- const adapter = useAzureCommunicationCallAdapter(callAdapterArgs as AzureCommunicationCallAdapterArgs);

-```

-Let's also add a `afterCreate` function like before, to do a few things with our adapter once it's constructed. Since we're now interacting with state in the widget we'll want to use a React `useCallback` just to make sure we're not defining this function every time we do a render pass. In our case, our function will reset the widget to the `'new'` state when the call ends and clear the user's `displayName` so they can start a new session. You can however return it to the `'setup'` state with the old displayName so that the app can easily call again as well.

-`CallingWidgetComponent.tsx`

-```ts

- const afterCreate = useCallback(async (adapter: CallAdapter): Promise<CallAdapter> => {

- adapter.on('callEnded',() => {

- setDisplayName(undefined);

- setWidgetState('new');

- adapter.dispose();

- });

- return adapter;

- },[])

- const adapter = useAzureCommunicationCallAdapter(callAdapterArgs as AzureCommunicationCallAdapterArgs, afterCreate);

-```

-Once we again have an adapter we'll need to update the template to account for a new widget state, so on that note we'll also need to add to the different modes that the widget itself can hold. We'll add a new `'inCall'` state like so:

-`CallingWidgetComponent.tsx`

-```ts

-const [widgetState, setWidgetState] = useState<'new' | 'setup' | 'inCall'>('new');

-```

-Next, we'll need to add a new logic to our Start Call button in the widget that will check to see which mode it will start the call, new window or embedded. That logic is as follows:

-`CallingWidgetComponent.tsx`

-```ts

- <PrimaryButton

- styles={startCallButtonStyles(theme)}

- onClick={() => {

- if (displayName && consentToData && onRenderStartCall) {

- onSetDisplayName(displayName);

- onRenderStartCall();

- } else if (displayName && consentToData && adapter) {

- setWidgetState('inCall');

- adapter?.joinCall();

- }

- }}

- >

- StartCall

- </PrimaryButton>

-```

-We'll also want to introduce some internal state to the widget about the local user's video controls.

-`CallingWidgetComponent.tsx`

-```ts

-const [useLocalVideo, setUseLocalVideo] = useState<boolean>(false);

-```

-Next, lets go back to our style sheet for the widget. We'll need to add new styles to allow the `CallComposite` to grow to its minimum size.

-`CallingWidgetComponent.styles.ts`

-```ts

-export const clickToCallInCallContainerStyles = (theme: Theme): IStackStyles => {

- return {

- root: {

- width: '35rem',

- height: '25rem',

- padding: '0.5rem',

- boxShadow: theme.effects.elevation16,

- borderRadius: theme.effects.roundedCorner6,

- bottom: 0,

- right: '1rem',

- position: 'absolute',

- overflow: 'hidden',

- cursor: 'pointer',

- background: theme.semanticColors.bodyBackground

- }

- }

-}

-```

-Finally, in the widget we'll need to add a section to the template that is when the widget is in the `'inCall'` state that we added earlier. So now we should have our template looking as follows:

-`CallingWidgetComponent.tsx`

-```ts

-if (widgetState === 'setup' && onSetDisplayName && onSetUseVideo) {

- return (

- <Stack styles={clicktoCallSetupContainerStyles(theme)} tokens={{ childrenGap: '1rem' }}>

- <IconButton

- styles={collapseButtonStyles}

- iconProps={{ iconName: 'Dismiss' }}

- onClick={() => setWidgetState('new')}

- />

- <Stack tokens={{ childrenGap: '1rem' }} styles={logoContainerStyles}>

- <Stack style={{ transform: 'scale(1.8)' }}>{onRenderLogo && onRenderLogo()}</Stack>

- </Stack>

- <TextField

- label={'Name'}

- required={true}

- placeholder={'Enter your name'}

- onChange={(_, newValue) => {

- setDisplayName(newValue);

- }}

- />

- <Checkbox

- styles={checkboxStyles(theme)}

- label={'Use video - Checking this box will enable camera controls and screen sharing'}

- onChange={(_, checked?: boolean | undefined) => {

- onSetUseVideo(!!checked);

- setUseLocalVideo(true);

- }}

- ></Checkbox>

- <Checkbox

- required={true}

- styles={checkboxStyles(theme)}

- label={

- 'By checking this box, you are consenting that we'll collect data from the call for customer support reasons'

- }

- onChange={(_, checked?: boolean | undefined) => {

- setConsentToData(!!checked);

- }}

- ></Checkbox>

- <PrimaryButton

- styles={startCallButtonStyles(theme)}

- onClick={() => {

- if (displayName && consentToData && onRenderStartCall) {

- onSetDisplayName(displayName);

- onRenderStartCall();

- } else if (displayName && consentToData && adapter) {

- setWidgetState('inCall');

- adapter?.joinCall();

- }

- }}

- >

- StartCall

- </PrimaryButton>

- </Stack>

- );

- }

- if(widgetState === 'inCall' && adapter){

- return(

- <Stack styles={clickToCallInCallContainerStyles(theme)}>

- <CallComposite adapter={adapter} options={{

- callControls: {

- cameraButton: useLocalVideo,

- screenShareButton: useLocalVideo,

- moreButton: false,

- peopleButton: false,

- displayType: 'compact'

- },

- localVideoTileOptions: { position: !useLocalVideo ? 'hidden' : 'floating' }

- }}></CallComposite>

- </Stack>

- )

- }

- return (

- <Stack

- horizontalAlign="center"

- verticalAlign="center"

- styles={clickToCallContainerStyles(theme)}

- onClick={() => {

- setWidgetState('setup');

- }}

- >

- <Stack

- horizontalAlign="center"

- verticalAlign="center"

- style={{ height: '4rem', width: '4rem', borderRadius: '50%', background: theme.palette.themePrimary }}

- >

- <Icon iconName="callAdd" styles={callIconStyles(theme)} />

- </Stack>

- </Stack>

- );

-```

-Now that we have updated our widget to be more versatile, we'll want to take another look at the `CallingWidgetScreen.tsx` to make some adjustments to how we're calling the widget. We'll turn on the new embedded experience do two things:

-That looks like this:

-`CallingWidgetScreen.tsx`

-```ts

- <Stack horizontal tokens={{ childrenGap: '1.5rem' }} style={{ overflow: 'hidden', margin: 'auto' }}>

- <CallingWidgetComponent

- adapterArgs={adapterParams}

- onRenderLogo={() => {

- return (

- <img

- style={{ height: '4rem', width: '4rem', margin: 'auto' }}

- src={hero}

- alt="logo"

- />

- );

- }}

- onSetDisplayName={setUserDisplayName}

- onSetUseVideo={setUseVideo}

- />

- </Stack>

-```

-Now that we have made these changes we can start our app again if it's shut down with `npm run start`. If we go through the start call process like we did before we should see the following when starting the call:

-

-Like before, this is a call starting with the video controls enabled.

-Thanks for following the different tutorials here. This concludes the quickstart guide for click to call with the Azure Communication Services UI Library.

-| TCP | Your client IPs | \* | Your container app's subnet¹ | `443`, `30,000-32,676`² | Allow your Client IPs to access Azure Container Apps. |

-| TCP | AzureLoadBalancer | \* | Your container app's subnet | `30,000-32,676`² | Allow Azure Load Balancer to probe backend pools. |

-| TCP | Your client IPs | \* | Your container app's subnet¹ | `443` | Allow your Client IPs to access Azure Container Apps. |

-| TCP | Your client IPs | \* | The `staticIP` of your container app environment | `443` | Allow your Client IPs to access Azure Container Apps. |

-| TCP | AzureLoadBalancer | \* | Your container app's subnet | `30,000-32,676`² | Allow Azure Load Balancer to probe backend pools. |

-Change feed items come in the order of their modification time. This sort order is guaranteed per physical partition, and there's no guaranteed order across the partition key values.

-description: Learn how Azure Cosmos DB provides encryption of data at rest and how it is implemented.

-# Data encryption in Azure Cosmos DB

-Encryption at rest is a phrase that commonly refers to the encryption of data on nonvolatile storage devices, such as solid state drives (SSDs) and hard disk drives (HDDs). Azure Cosmos DB stores its primary databases on SSDs. Its media attachments and backups are stored in Azure Blob storage, which is generally backed up by HDDs. With the release of encryption at rest for Azure Cosmos DB, all your databases, media attachments, and backups are encrypted. Your data is now encrypted in transit (over the network) and at rest (nonvolatile storage), giving you end-to-end encryption.

-As a PaaS service, Azure Cosmos DB is very easy to use. Because all user data stored in Azure Cosmos DB is encrypted at rest and in transport, you don't have to take any action. Another way to put this is that encryption at rest is "on" by default. There are no controls to turn it off or on. Azure Cosmos DB uses AES-256 encryption on all regions where the account is running. We provide this feature while we continue to meet our [availability and performance SLAs](https://azure.microsoft.com/support/legal/sl) article.

-Encryption at rest is implemented by using a number of security technologies, including secure key storage systems, encrypted networks, and cryptographic APIs. Systems that decrypt and process data have to communicate with systems that manage keys. The diagram shows how storage of encrypted data and the management of keys is separated.

-The basic flow of a user request is as follows:

-### Q: How much more does Azure Storage cost if Storage Service Encryption is enabled?

-A: There is no additional cost.

-### Q: Who manages the encryption keys?

-A: Data stored in your Azure Cosmos DB account is automatically and seamlessly encrypted with keys managed by Microsoft using service-managed keys. Optionally, you can choose to add a second layer of encryption with keys you manage using [customer-managed keys or CMK](how-to-setup-cmk.md).

-### Q: How often are encryption keys rotated?

-A: Microsoft has a set of internal guidelines for encryption key rotation, which Azure Cosmos DB follows. The specific guidelines are not published. Microsoft does publish the [Security Development Lifecycle (SDL)](https://www.microsoft.com/sdl/default.aspx), which is seen as a subset of internal guidance and has useful best practices for developers.

-### Q: Can I use my own encryption keys?

-A: Yes, this feature is now available for new Azure Cosmos DB accounts and this should be done at the time of account creation. Please go through [Customer-managed Keys](./how-to-setup-cmk.md) document for more information.

-> The following field names are reserved on Cassandra API tables in accounts using Customer-managed Keys:

-> When Customer-managed Keys are not enabled, only field names beginning with `__sys_` are reserved.

-### Q: What regions have encryption turned on?

-A: All Azure Cosmos DB regions have encryption turned on for all user data.

-### Q: Does encryption affect the performance latency and throughput SLAs?

-A: There is no impact or changes to the performance SLAs now that encryption at rest is enabled for all existing and new accounts. You can read more on the [SLA for Azure Cosmos DB](https://azure.microsoft.com/support/legal/sla/cosmos-db) page to see the latest guarantees.

-### Q: Does the local emulator support encryption at rest?

-A: The emulator is a standalone dev/test tool and does not use the key management services that the managed Azure Cosmos DB service uses. Our recommendation is to enable BitLocker on drives where you are storing sensitive emulator test data. The [emulator supports changing the default data directory](emulator.md) as well as using a well-known location.

-* You can choose to add a second layer of encryption with your own keys, to learn more, see the [customer-managed keys](how-to-setup-cmk.md) article.

-## What's new in Azure Cosmos DB security

-Encryption at rest is now available for documents and backups stored in Azure Cosmos DB in all Azure regions. Encryption at rest is applied automatically for both new and existing customers in these regions. There's no need to configure anything. You get the same great latency, throughput, availability, and functionality as before with the benefit of knowing your data is safe and secure with encryption at rest. Data stored in your Azure Cosmos DB account is automatically and seamlessly encrypted with keys managed by Microsoft using service-managed keys. Optionally, you can choose to add a second layer of encryption with keys you manage using [customer-managed keys or CMK](how-to-setup-cmk.md).

-## How do I secure my database

-Data security is a shared responsibility between you, the customer, and your database provider. Depending on the database provider you choose, the amount of responsibility you carry can vary. If you choose an on-premises solution, you need to provide everything from end-point protection to physical security of your hardware - which is no easy task. If you choose a PaaS cloud database provider such as Azure Cosmos DB, your area of concern shrinks considerably. The following image, borrowed from Microsoft's [Shared Responsibilities for Cloud Computing](https://azure.microsoft.com/resources/shared-responsibilities-for-cloud-computing/) white paper, shows how your responsibility decreases with a PaaS provider like Azure Cosmos DB.

-The preceding diagram shows high-level cloud security components, but what items do you need to worry about specifically for your database solution? And how can you compare solutions to each other?

-And although it may seem obvious, recent [large-scale database breaches](https://thehackernews.com/2017/01/mongodb-database-security.html) remind us of the simple but critical importance of the following requirements:

-## How does Azure Cosmos DB secure my database

-Let's look back at the preceding list - how many of those security requirements does Azure Cosmos DB provide? Every single one.

-Let's dig into each one in detail.

-|Network security|Using an IP firewall is the first layer of protection to secure your database. Azure Cosmos DB supports policy driven IP-based access controls for inbound firewall support. The IP-based access controls are similar to the firewall rules used by traditional database systems. However, they're expanded so that an Azure Cosmos DB database account is only accessible from an approved set of machines or cloud services. Learn more in [Azure Cosmos DB firewall support](how-to-configure-firewall.md) article.<br><br>Azure Cosmos DB enables you to enable a specific IP address (168.61.48.0), an IP range (168.61.48.0/8), and combinations of IPs and ranges. <br><br>All requests originating from machines outside this allowed list are blocked by Azure Cosmos DB. Requests from approved machines and cloud services then must complete the authentication process to be given access control to the resources.<br><br> You can use [virtual network service tags](../virtual-network/service-tags-overview.md) to achieve network isolation and protect your Azure Cosmos DB resources from the general Internet. Use service tags in place of specific IP addresses when you create security rules. By specifying the service tag name (for example, AzureCosmosDB) in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service.|

-|Authorization|Azure Cosmos DB uses hash-based message authentication code (HMAC) for authorization. <br><br>Each request is hashed using the secret account key, and the subsequent base-64 encoded hash is sent with each call to Azure Cosmos DB. To validate the request, the Azure Cosmos DB service uses the correct secret key and properties to generate a hash, then it compares the value with the one in the request. If the two values match, the operation is authorized successfully, and the request is processed. If they don't match, there's an authorization failure and the request is rejected.<br><br>You can use either a [primary key](#primary-keys), or a [resource token](secure-access-to-data.md#resource-tokens) allowing fine-grained access to a resource such as a document.<br><br>Learn more in [Securing access to Azure Cosmos DB resources](secure-access-to-data.md).|

-|Users and permissions|Using the primary key for the account, you can create user resources and permission resources per database. A resource token is associated with a permission in a database and determines whether the user has access (read-write, read-only, or no access) to an application resource in the database. Application resources include container, documents, attachments, stored procedures, triggers, and UDFs. The resource token is then used during authentication to provide or deny access to the resource.<br><br>Learn more in [Securing access to Azure Cosmos DB resources](secure-access-to-data.md).|

-|Active directory integration (Azure role-based access control)| You can also provide or restrict access to the Azure Cosmos DB account, database, container, and offers (throughput) using Access control (IAM) in the Azure portal. IAM provides role-based access control and integrates with Active Directory. You can use built in roles or custom roles for individuals and groups. For more information, see [Active Directory integration](role-based-access-control.md).|

-|Global replication|Azure Cosmos DB offers turnkey global distribution, which enables you to replicate your data to any one of Azure's world-wide datacenters in a turnkey way. Global replication lets you scale globally and provide low-latency access to your data around the world.<br><br>In the context of security, global replication ensures data protection against regional failures.<br><br>Learn more in [Distribute data globally](distribute-data-globally.md).|

-|Regional failovers|If you've replicated your data in more than one data center, Azure Cosmos DB automatically rolls over your operations should a regional data center go offline. You can create a prioritized list of failover regions using the regions in which your data is replicated. <br><br>Learn more in [Regional Failovers in Azure Cosmos DB](high-availability.md).|

-|Local replication|Even within a single data center, Azure Cosmos DB automatically replicates data for high availability giving you the choice of [consistency levels](consistency-levels.md). This replication guarantees a 99.99% [availability SLA](https://azure.microsoft.com/support/legal/sla/cosmos-db) for all single region accounts and all multi-region accounts with relaxed consistency, and 99.999% read availability on all multi-region database accounts.|

-|Automated online backups|Azure Cosmos DB databases are backed up regularly and stored in a geo redundant store. <br><br>Learn more in [Automatic online backup and restore with Azure Cosmos DB](online-backup-and-restore.md).|

-|Restore deleted data|The automated online backups can be used to recover data you may have accidentally deleted up to ~30 days after the event. <br><br>Learn more in [Automatic online backup and restore with Azure Cosmos DB](online-backup-and-restore.md)|

-|Protect and isolate sensitive data|All data in the regions listed in What's new? is now encrypted at rest.<br><br>Personal data and other confidential data can be isolated to specific container and read-write, or read-only access can be limited to specific users.|

-|Monitor for attacks|By using [audit logging and activity logs](./monitor.md), you can monitor your account for normal and abnormal activity. You can view what operations were performed on your resources. This data includes; who initiated the operation, when the operation occurred, the status of the operation, and much more.|

-|Respond to attacks|Once you have contacted Azure support to report a potential attack, a five-step incident response process is kicked off. The goal of the five-step process is to restore normal service security and operations. The five-step process restores services as quickly as possible after an issue is detected and an investigation is started.<br><br>Learn more in [Microsoft Azure Security Response in the Cloud](https://azure.microsoft.com/resources/shared-responsibilities-for-cloud-computing/).|

-|Geo-fencing|Azure Cosmos DB ensures data governance for sovereign regions (for example, Germany, China, US Gov).|

-|Protected facilities|Data in Azure Cosmos DB is stored on SSDs in Azure's protected data centers.<br><br>Learn more in [Microsoft global datacenters](https://www.microsoft.com/en-us/cloud-platform/global-datacenters)|

-|HTTPS/SSL/TLS encryption|All connections to Azure Cosmos DB support HTTPS. Azure Cosmos DB supports TLS levels up to 1.2 (included).<br>It's possible to enforce a minimum TLS level on server-side. To do so, refer to self service guide [Self-serve minimum TLS version enforcement in Azure Cosmos DB](./self-serve-minimum-tls-enforcement.md).|

-|Encryption at rest|All data stored into Azure Cosmos DB is encrypted at rest. Learn more in [Azure Cosmos DB encryption at rest](./database-encryption-at-rest.md)|

-|Patched servers|As a managed database, Azure Cosmos DB eliminates the need to manage and patch servers, that's done for you, automatically.|

-|Administrative accounts with strong passwords|It's hard to believe we even need to mention this requirement, but unlike some of our competitors, it's impossible to have an administrative account with no password in Azure Cosmos DB.<br><br> Security via TLS and HMAC secret based authentication is baked in by default.|

-|Security and data protection certifications| For the most up-to-date list of certifications, see [Azure compliance](https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings) and the latest [Azure compliance document](https://azure.microsoft.com/mediahandler/files/resourcefiles/microsoft-azure-compliance-offerings/Microsoft%20Azure%20Compliance%20Offerings.pdf) with all Azure certifications including Azure Cosmos DB.

-The following screenshot shows how you can use audit logging and activity logs to monitor your account:

-Each account consists of two keys: a primary key and secondary key. The purpose of dual keys is so that you can regenerate, or roll keys, providing continuous access to your account and data.

-Primary/secondary keys come in two versions: read-write and read-only. The read-only keys only allow read operations on the account, but don't provide access to read permissions resources.

-The process of key rotation and regeneration is simple. First, make sure that **your application is consistently using either the primary key or the secondary key** to access your Azure Cosmos DB account. Then, follow the steps outlined below. To monitor your account for key updates and key regeneration, see [monitor key updates with metrics and alerts](monitor-account-key-updates.md) article.

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Keys** from the left menu, then select **Regenerate Secondary Key** from the ellipsis on the right of your secondary key.

- :::image type="content" source="./media/database-security/regenerate-secondary-key.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-primary-key.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Keys** from the left menu, then select **Regenerate Primary Key** from the ellipsis on the right of your primary key.

- :::image type="content" source="./media/database-security/regenerate-primary-key.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-secondary-key.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Connection String** from the left menu, then select **Regenerate Password** from the ellipsis on the right of your secondary password.

- :::image type="content" source="./media/database-security/regenerate-secondary-key-mongo.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-primary-key-mongo.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Connection String** from the left menu, then select **Regenerate Password** from the ellipsis on the right of your primary password.

- :::image type="content" source="./media/database-security/regenerate-primary-key-mongo.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-secondary-key-mongo.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Connection String** from the left menu, then select **Regenerate Secondary Read-Write Password** from the ellipsis on the right of your secondary password.

- :::image type="content" source="./media/database-security/regenerate-secondary-key-cassandra.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-primary-key-cassandra.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Connection String** from the left menu, then select **Regenerate Primary Read-Write Password** from the ellipsis on the right of your primary password.

- :::image type="content" source="./media/database-security/regenerate-primary-key-cassandra.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-secondary-key-cassandra.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Keys** from the left menu, then select **Regenerate Secondary Key** from the ellipsis on the right of your secondary key.

- :::image type="content" source="./media/database-security/regenerate-secondary-key-gremlin.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-primary-key-gremlin.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Keys** from the left menu, then select **Regenerate Primary Key** from the ellipsis on the right of your primary key.

- :::image type="content" source="./media/database-security/regenerate-primary-key-gremlin.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-secondary-key-gremlin.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Connection String** from the left menu, then select **Regenerate Secondary Key** from the ellipsis on the right of your secondary key.

- :::image type="content" source="./media/database-security/regenerate-secondary-key-table.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-primary-key-table.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Connection String** from the left menu, then select **Regenerate Primary Key** from the ellipsis on the right of your primary key.

- :::image type="content" source="./media/database-security/regenerate-primary-key-table.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-secondary-key-table.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

-After you rotate or regenerate a key, you can track its status from the Activity log. Use the following steps to track the status:

-1. Sign in to the [Azure portal](https://portal.azure.com) and navigate to your Azure Cosmos DB account.

- :::image type="content" source="./media/database-security/track-key-regeneration-status.png" alt-text="Screenshot of status of key regeneration from Activity log." border="true":::

- Microsoft recommends regenerating the keys at least once every 60 days. If your last regeneration was more than 60 days ago, you will see a warning icon. Also, you could see that your key was not recorded. If this is the case, your account was created before 2022-06-18 and the dates were not registered. However, you should be able to regenerate and see your new last regeneration date for the new key.

-1. You should see the key regeneration events along with its status, time at which the operation was issued, details of the user who initiated key regeneration. The key generation operation initiates with **Accepted** status, it then changes to **Started** and then to **Succeeded** when the operation completes.

-For more information about primary keys and resource tokens, see [Securing access to Azure Cosmos DB data](secure-access-to-data.md).

-For more information about audit logging, see [Azure Cosmos DB diagnostic logging](./monitor.md).

-For more information about Microsoft certifications, see [Azure Trust Center](https://azure.microsoft.com/support/trust-center/).

-description: With TTL, Microsoft Azure Cosmos DB provides the ability to have documents automatically purged from the system after a period of time.

-With **Time to Live** or TTL, Azure Cosmos DB provides the ability to delete items automatically from a container after a certain time period. By default, you can set time to live at the container level and override the value on a per-item basis. After you set the TTL at a container or at an item level, Azure Cosmos DB will automatically remove these items after the time period, since the time they were last modified. Time to live value is configured in seconds. When you configure TTL, the system will automatically delete the expired items based on the TTL value, without needing a delete operation that is explicitly issued by the client application. The maximum value for TTL is 2147483647 seconds, the approximate equivalent of 24,855 days or 68 years.

-Deletion of expired items is a background task that consumes left-over [Request Units](../request-units.md), that is Request Units that haven't been consumed by user requests. Even after the TTL has expired, if the container is overloaded with requests and if there aren't enough RU's available, the data deletion is delayed. Data is deleted once there are enough RUs available to perform the delete operation. Though the data deletion is delayed, data is not returned by any queries (by any API) after the TTL has expired.

-The time to live value is set in seconds, and it is interpreted as a delta from the time that an item was last modified. You can set time to live on a container or an item within the container:

- - If missing (or set to null), items are not expired automatically.

- - If present and the value is set to "-1", it is equal to infinity, and items donΓÇÖt expire by default.

- - If present and the value is set to some *non-zero* number *"n"* ΓÇô items will expire *"n"* seconds after their last modified time.

- - This Property is applicable only if `DefaultTimeToLive` is present and it is not set to null for the parent container.

-|ttl = null|TTL is disabled. The item will never expire (default).|

-|ttl = null|TTL is enabled. The item will never expire (default).|

-|ttl = null|TTL is enabled. The item will expire after 1000 seconds (default).|

-| [Role-based access control](#rbac) | Fine-grained, role-based permission model using Microsoft Entra identities for authentication. |

-Primary/secondary keys provide access to all the administrative resources for the database account. Each account consists of two keys: a primary key and secondary key. The purpose of dual keys is to let you regenerate, or roll keys, providing continuous access to your account and data. To learn more about primary/secondary keys, see the [Database security](database-security.md#primary-keys) article.

-To see your account keys, navigate to Keys from the left menu. Then, click on the ΓÇ£viewΓÇ¥ icon at the right of each key. Click on the copy button to copy the selected key. You can hide them afterwards by clicking the same icon per key, which will be updated as a ΓÇ£hideΓÇ¥ button.

-> To monitor your account for key updates and key regeneration, see [monitor key updates with metrics and alerts](monitor-account-key-updates.md) article.

-The process of key rotation and regeneration is simple. First, make sure that **your application is consistently using either the primary key or the secondary key** to access your Azure Cosmos DB account. Then, follow the steps outlined below.

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Keys** from the left menu, then select **Regenerate Secondary Key** from the ellipsis on the right of your secondary key.

- :::image type="content" source="./media/database-security/regenerate-secondary-key.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-primary-key.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

-1. Navigate to your Azure Cosmos DB account on the Azure portal.

-1. Select **Keys** from the left menu, then select **Regenerate Primary Key** from the ellipsis on the right of your primary key.

- :::image type="content" source="./media/database-security/regenerate-primary-key.png" alt-text="Screenshot of the Azure portal showing how to regenerate the primary key." border="true":::

- :::image type="content" source="./media/database-security/regenerate-secondary-key.png" alt-text="Screenshot of the Azure portal showing how to regenerate the secondary key." border="true":::

-The following code sample illustrates how to use an Azure Cosmos DB account endpoint and primary key to instantiate a CosmosClient:

-Azure Cosmos DB exposes a built-in role-based access control (RBAC) system that lets you:

-See [Configure role-based access control for your Azure Cosmos DB account](how-to-setup-rbac.md) to learn more about Azure Cosmos DB RBAC.

-You can use a resource token (by creating Azure Cosmos DB users and permissions) when you want to provide access to resources in your Azure Cosmos DB account to a client that cannot be trusted with the primary key.

-Azure Cosmos DB resource tokens provide a safe alternative that enables clients to read, write, and delete resources in your Azure Cosmos DB account according to the permissions you've granted, and without need for either a primary or read only key.

-Here is a typical design pattern whereby resource tokens may be requested, generated, and delivered to clients:

-2. The mid-tier service possesses the primary key of the Azure Cosmos DB account.

-3. The photo app is installed on end-user mobile devices.

-4. On login, the photo app establishes the identity of the user with the mid-tier service. This mechanism of identity establishment is purely up to the application.

-5. Once the identity is established, the mid-tier service requests permissions based on the identity.

-6. The mid-tier service sends a resource token back to the phone app.

-7. The phone app can continue to use the resource token to directly access Azure Cosmos DB resources with the permissions defined by the resource token and for the interval allowed by the resource token.

-8. When the resource token expires, subsequent requests receive a 401 unauthorized exception. At this point, the phone app re-establishes the identity and requests a new resource token.

- :::image type="content" source="./media/secure-access-to-data/resourcekeyworkflow.png" alt-text="Azure Cosmos DB resource tokens workflow" border="false":::

-Resource token generation and management are handled by the native Azure Cosmos DB client libraries; however, if you use REST you must construct the request/authentication headers. For more information on creating authentication headers for REST, see [Access Control on Azure Cosmos DB Resources](/rest/api/cosmos-db/access-control-on-cosmosdb-resources) or the source code for our [.NET SDK](https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/Microsoft.Azure.Cosmos/src/Authorization/AuthorizationHelper.cs) or [Node.js SDK](https://github.com/Azure/azure-cosmos-js/blob/master/src/auth.ts).

-For an example of a middle tier service used to generate or broker resource tokens, see the [ResourceTokenBroker app](https://github.com/Azure/azure-cosmos-dotnet-v2/tree/master/samples/xamarin/UserItems/ResourceTokenBroker/ResourceTokenBroker/Controllers).

-Azure Cosmos DB users are associated with an Azure Cosmos DB database. Each database can contain zero or more Azure Cosmos DB users. The following code sample shows how to create an Azure Cosmos DB user using the [Azure Cosmos DB .NET SDK v3](https://github.com/Azure/azure-cosmos-dotnet-v3/tree/master/Microsoft.Azure.Cosmos.Samples/Usage/UserManagement).

-> Each Azure Cosmos DB user has a ReadAsync() method that can be used to retrieve the list of [permissions](#permissions) associated with the user.

-A permission resource is associated with a user and assigned to a specific resource. Each user may contain zero or more permissions. A permission resource provides access to a security token that the user needs when trying to access a specific container or data in a specific partition key. There are two available access levels that may be provided by a permission resource:

-> In order to run stored procedures the user must have the All permission on the container in which the stored procedure will be run.

-* **resourceTokenPermissionId** - This property indicates the resource token permission ID that you have specified.

-* **resourceTokenPermissionMode** - This property indicates the permission mode that you have set when creating the resource token. The permission mode can have values such as "all" or "read".

-The following code sample shows how to create a permission resource, read the resource token of the permission resource, and associate the permissions with the [user](#users) created above.

-The following code snippet shows how to retrieve the permission associated with the user created above and instantiate a new CosmosClient on behalf of the user, scoped to a single partition key.

-| Authentication | With Microsoft Entra ID. | Based on the native Azure Cosmos DB users<br>Integrating resource tokens with Microsoft Entra ID requires extra work to bridge Microsoft Entra identities and Azure Cosmos DB users. |

-| Authorization | Role-based: role definitions map allowed actions and can be assigned to multiple identities. | Permission-based: for each Azure Cosmos DB user, you need to assign data access permissions. |

-| Token scope | A Microsoft Entra token carries the identity of the requester. This identity is matched against all assigned role definitions to perform authorization. | A resource token carries the permission granted to a specific Azure Cosmos DB user on a specific Azure Cosmos DB resource. Authorization requests on different resources may require different tokens. |

-| Token refresh | The Microsoft Entra token is automatically refreshed by the Azure Cosmos DB SDKs when it expires. | Resource token refresh is not supported. When a resource token expires, a new one needs to be issued. |

-1. Open the Azure portal, and select your Azure Cosmos DB account.

-1. Assign the following role. For detailed steps, see [Assign Azure roles using the Azure portal](../role-based-access-control/role-assignments-portal.md).

- | Role | Cosmos DB Account Reader |

- | Assign access to | User, group, or service principal |

- | Members | The user, group, or application in your directory to which you wish to grant access. |

- 

-As a database service, Azure Cosmos DB enables you to search, select, modify and delete any data located in your database or containers. It is however your responsibility to use the provided APIs and define logic required to find and erase any personal data if needed. Each multi-model API (SQL, MongoDB, Gremlin, Cassandra, Table) provides different language SDKs that contain methods to search and delete data based on custom predicates. You can also enable the [time to live (TTL)](time-to-live.md) feature to delete data automatically after a specified period, without incurring any additional cost.

-r

-| Internet exposed SQL on VM has a user account with commonly used username and allows code execution on the VM (Preview) | SQL on VM is reachable from the internet, has a local user account with a commonly used username (which is prone to brute force attacks), and has vulnerabilities allowing code execution and lateral movement to the underlying VM. <br/> Prerequisite: [Enable Microsoft Defender for SQL servers on machines](defender-for-sql-usage.md) |

-| Internet exposed SQL on VM has a user account with commonly used username and known vulnerabilities (Preview) | SQL on VM is reachable from the internet, has a local user account with a commonly used username (which is prone to brute force attacks), and has known vulnerabilities (CVEs). <br/> Prerequisite: [Enable Microsoft Defender for SQL servers on machines](defender-for-sql-usage.md) |

-| SQL on VM has a user account with commonly used username and allows code execution on the VM (Preview) | SQL on VM has a local user account with a commonly used username (which is prone to brute force attacks), and has vulnerabilities allowing code execution and lateral movement to the underlying VM. <br/> Prerequisite: [Enable Microsoft Defender for SQL servers on machines](defender-for-sql-usage.md)|

-| SQL on VM has a user account with commonly used username and known vulnerabilities (Preview) | SQL on VM has a local user account with a commonly used username (which is prone to brute force attacks), and has known vulnerabilities (CVEs). <br/> Prerequisite: [Enable Microsoft Defender for SQL servers on machines](defender-for-sql-usage.md)|

-| Managed database with excessive internet exposure allows basic (local user/password) authentication (Preview) | The database can be accessed through the internet from any public IP and allows authentication using username and password (basic authentication mechanism) which exposes the DB to brute force attacks. |

-|Internet exposed SQL on EC2 instance has a user account with commonly used username and allows code execution on the underlying compute (Preview) | Internet exposed SQL on EC2 instance has a user account with commonly used username and allows code execution on the underlying compute. <br/> Prerequisite:ΓÇ»[Enable Microsoft Defender for SQL servers on machines](defender-for-sql-usage.md). |

-|Internet exposed SQL on EC2 instance has a user account with commonly used username and known vulnerabilities (Preview) | SQL on EC2 instance is reachable from the internet, has a local user account with a commonly used username (which is prone to brute force attacks), and has known vulnerabilities (CVEs). <br/> Prerequisite:ΓÇ»[Enable Microsoft Defender for SQL servers on machines](defender-for-sql-usage.md) |

-|SQL on EC2 instance has a user account with commonly used username and allows code execution on the underlying compute (Preview) | SQL on EC2 instance has a local user account with commonly used username (which is prone to brute force attacks), and has vulnerabilities allowing code execution and lateral movement to the underlying compute. <br/> Prerequisite:ΓÇ»[Enable Microsoft Defender for SQL servers on machines](defender-for-sql-usage.md) |

-| SQL on EC2 instance has a user account with commonly used username and known vulnerabilities (Preview) |SQL on EC2 instance [EC2Name] has a local user account with commonly used username (which is prone to brute force attacks), and has known vulnerabilities (CVEs). <br/> Prerequisite:ΓÇ»[Enable Microsoft Defender for SQL servers on machines](defender-for-sql-usage.md) |

-| Managed database with excessive internet exposure allows basic (local user/password) authentication (Preview) | The database can be accessed through the internet from any public IP and allows authentication using username and password (basic authentication mechanism) which exposes the DB to brute force attacks. |

- Optionally, select **Management account** to create a connector to a management account. Connectors are created for each member account discovered under the provided management account. Auto-provisioning is enabled for all of the newly onboarded accounts.

- Optionally, select **Configure** to edit the configuration as required. We recommend that you leave it set to the default configuration.

-1. Select **Next: Configure access**.

-1. On the **Configure access** tab, select **Click to download the CloudFormation template** to download the CloudFormation template.

- :::image type="content" source="media/quickstart-onboard-aws/download-cloudformation-template.png" alt-text="Screenshot that shows the button to download the CloudFormation template." lightbox="media/quickstart-onboard-aws/download-cloudformation-template.png":::

-1. Continue to configure access by making the following selections:

- a. Choose a deployment type:

- b. Choose a deployment method: **AWS CloudFormation** or **Terraform**.

- :::image type="content" source="media/quickstart-onboard-aws/aws-configure-access.png" alt-text="Screenshot that shows deployment options and instructions for configuring access.":::

- :::image type="content" source="media/quickstart-onboard-gcp/google-cloud.png" alt-text="Screenshot that shows selections for adding Google Cloud Platform as a connector." lightbox="media/quickstart-onboard-gcp/google-cloud.png":::

- :::image type="content" source="media/quickstart-onboard-gcp/create-connector.png" alt-text="Screenshot of the pane for creating a GCP connector." lightbox="media/quickstart-onboard-gcp/create-connector.png":::

-1. Select **Next: Configure access**.

- 1. Choose the deployment type:

- 1. Choose the deployment method: **GCP Cloud Shell** or **Terraform**.

-1. Select **Copy**.

- :::image type="content" source="media/quickstart-onboard-gcp/copy-button.png" alt-text="Screenshot that shows the location of the copy button.":::

- > [!NOTE]

- > For the discovery of GCP resources and for the authentication process, you must enable the following APIs: `iam.googleapis.com`, `sts.googleapis.com`, `cloudresourcemanager.googleapis.com`, `iamcredentials.googleapis.com`, and `compute.googleapis.com`. If you don't enable these APIs, we'll enable them during the onboarding process by running the GCloud script.

-1. Select **GCP Cloud Shell >**. The GCP Cloud Shell opens.

-1. Paste the script into the GCP Cloud Shell terminal and run it.

-1. Ensure that you created the following resources for Microsoft Defender Cloud Security Posture Management (CSPM) and Defender for Containers:

- | CSPM | Defender for Containers|

- |--|--|

- | CSPM service account reader role <br><br> Microsoft Defender for Cloud identity federation <br><br> CSPM identity pool <br><br>Microsoft Defender for Servers service account (when the servers plan is enabled) <br><br>*Azure Arc for servers onboarding* service account (when Azure Arc for servers autoprovisioning is enabled) | Microsoft Defender for Containers service account role <br><br> Microsoft Defender Data Collector service account role <br><br> Microsoft Defender for Cloud identity pool |

-| October 30 | [Changing adaptive application controlΓÇÖs security alert's severity](#changing-adaptive-application-controls-security-alerts-severity)

-## Changing adaptive application controls security alert's severity

-## Offline Azure API Management revisions removed from Defender for APIs

-## DevOps security posture management recommendations available in public preview

-1. Select the **Subscription** blade in the Azure portal, and then choose your subscription by clicking on it.

-1. Select the resource group you created, select **Create**, select **Networking** from the list of categories, and then next to **Virtual network**, select **Create**.

-2. On the **Basics** tab, enter a name for the new virtual network and select the **Region** that is the same as your resource group.

-3. On the **IP Addresses** tab, modify the **IPv4 address space** to be 10.0.0.0/8.

-4. Select **Add subnet** and enter the subnet name and address range:

- - Subnet name: snet-inbound

- - Subnet address range: 10.0.0.0/28

- - Select **Add** to add the new subnet.

-5. Select **Add subnet** and configure the outbound endpoint subnet:

- - Subnet name: snet-outbound

- - Subnet address range: 10.1.1.0/28

- - Select **Add** to add this subnet.

-6. Select **Review + create** and then select **Create**.

-1. Open the Azure portal and search for **DNS Private Resolvers**.

-4. Next to **Subnet**, select the inbound endpoint subnet you created (ex: snet-inbound, 10.0.0.0/28) and then select **Save**.

-> [!NOTE]

-> You can choose a static or dynamic IP address for the inbound endpoint. A dynamic IP address is used by default. Typically the first available [non-reserved](../virtual-network/virtual-networks-faq.md#are-there-any-restrictions-on-using-ip-addresses-within-these-subnets) IP address is assigned (example: 10.0.0.4). This dynamic IP address does not change unless the endpoint is deleted and reprovisioned (for example using a different subnet). To specify a static address, select **Static** and enter a non-reserved IP address in the subnet.

- - Endpoints: Select the outbound endpoint that you created (ex: myoutboundendpoint).

- - Select **Add a destination** and enter a desired destination IPv4 address (ex: 11.0.1.4).

- This example has only one conditional forwarding rule, but you can create many. Edit the rules to enable or disable them as needed.

- 

- After selecting **Create**, the new DNS resolver will begin deployment. This process might take a minute or two. The status of each component is displayed during deployment.

-5. Select the **IP Addresses** tab and edit the default IP address space. Replace the address space with a simulated on-premises address space (ex: 12.0.0.0/8).

-6. Select **Add subnet** and enter the following:

- - Subnet name: backendsubnet

- - Subnet address range: 12.2.0.0/24

-7. Select **Add**, select **Review + create**, and then select **Create**.

- 

-2. Select **Virtual Network Links**, select **Add**, choose **myvnet2** and use the default Link Name **myvnet2-link**.

-1. Search for **Dns Forwarding Rulesets** in the Azure Services list and select it.

-2. Select the ruleset you previously configured (ex: **myruleset**) and then select **Rules**.

-1. On the **myruleset | Rules** page, click **Add**, and enter the following rule data:

-2. Under **Destination IP address** enter 10.0.0.4, and then click **Add**.

-3. On the **myruleset | Rules** page, click **Add**, and enter the following rule data:

-4. Under **Destination IP address** enter 192.168.1.2, and then click **Add**.

-5. On the **myruleset | Rules** page, click **Add**, and enter the following rule data:

-6. Under **Destination IP address** enter 10.5.5.5, and then click **Add**.

-If multiple subscriptions are present, the first subscription ID will be used. To specify a different subscription ID, use the following command.

-New-AzVirtualNetwork -Name myvnet -ResourceGroupName myresourcegroup -Location westcentralus -AddressPrefix "10.0.0.0/8"

-> If the endpoint IP address is specified as dynamic, the address does not change unless the endpoint is deleted and reprovisioned. Typically the same IP address will be assigned again during reprovisioning.<br>

-$vnet2 = New-AzVirtualNetwork -Name myvnet2 -ResourceGroupName myresourcegroup -Location westcentralus -AddressPrefix "12.0.0.0/8"

-**Requirement**: You must create a virtual network link in the zone to the virtual network where you deploy your Azure DNS Private Resolver. In the following example, the private zone is linked to two vnets: **myeastvnet** and **mywestvnet**. At least one link is required.

-To use the DICOMweb Standard APIs, you need an instance of the DICOM service deployed. If you haven't already deployed an instance of the DICOM service, see [Deploy DICOM service using the Azure portal](deploy-dicom-services-in-azure.md).

-After you deploy your DICOM service, you create a DicomWebClient. Run the code snippet to create DicomWebClient, which you use for the rest of this tutorial. Ensure you have both NuGet packages installed. If you haven't already obtained a token, see [Get access token for the DICOM service using Azure CLI](dicom-get-access-token-azure-cli.md).

-Using the DicomWebClient that we've created, we can now store DICOM files.

-All three of the dcm files that we've uploaded previously are part of the same study, so the response should return all three instances. Validate that the response has a status code of OK and that all three instances are returned.

-All three of the dcm files that we've uploaded previously are part of the same study, so the response should return the metadata for all three instances. Validate that the response has a status code of OK and that all the metadata is returned.

-To use the DICOM Standard APIs, you must have an instance of the DICOM service deployed. If you haven't already deployed an instance of the DICOM service, see [Deploy DICOM service using the Azure portal](deploy-dicom-services-in-azure.md).

-Once you've deployed an instance of the DICOM service, retrieve the URL for your App service:

-4. If you haven't already obtained a token, see [Get access token for the DICOM service using Azure CLI](dicom-get-access-token-azure-cli.md).

-Some programming languages and tools behave differently. For instance, some require you to define your own boundary. For those tools, you might need to use a slightly modified Content-Type header. The following have been used successfully.

-Some programming languages and tools behave differently. For instance, some require you to define your own boundary. For those languages and tools, you might need to use a slightly modified Content-Type header. The following have been used successfully.

-Delete isn't part of the DICOM standard, but it's been added for convenience.

-Delete isn't part of the DICOM standard, but it's been added for convenience.

-Delete isn't part of the DICOM standard, but it has been added for convenience.

-To use the DICOMweb Standard APIs, you must have an instance of the DICOM service deployed. If you haven't already deployed the DICOM service, see [Deploy DICOM service using the Azure portal](deploy-dicom-services-in-azure.md).

-2. If you haven't already obtained a token, see [Get access token for the DICOM service using Azure CLI](dicom-get-access-token-azure-cli.md).

-We've chosen to implement this example using the synchronous `requests` library. For asynchronous support, consider using `httpx` or another async library. Additionally, we're importing two supporting functions from `urllib3` to support working with `multipart/related` requests.

-`DefaultAzureCredential` allows us to use various ways to get tokens to log into the service. In this example, use the `AzureCliCredential` to get a token to log into the service. There are other credential providers such as `ManagedIdentityCredential` and `EnvironmentCredential` that are also possible to use. In order to use the AzureCliCredential, you must have logged into Azure from the CLI prior to running this code. (For more information, see [Get access token for the DICOM service using Azure CLI](dicom-get-access-token-azure-cli.md).) Alternatively, you can copy and paste the token retrieved while logging in from the CLI.

-Some programming languages and tools behave differently. For example, some require you to define your own boundary. For those languages and tools, you might need to use a slightly modified Content-Type header. The following have been used successfully.

-A 204 response code is returned when the deletion is successful. A 404 response code is returned if the item(s) has never existed or it's already been deleted.

-2. Select the **Activity log** blade, and then select **Diagnostic settings**.

- * **Send to Log Analytics workspace** in the Azure Monitor. YouΓÇÖll need to create your Logs Analytics workspace before you can select this option. For more information about the platform logs, see [Overview of Azure platform logs](../../azure-monitor/essentials/platform-logs-overview.md).

- * **Stream to an event hub** for ingestion by a third-party service or custom analytic solution. YouΓÇÖll need to create an event hub namespace and event hub policy before you can configure this step.

-The log schema used differs based on the destination. Log Analytics has a schema that will differ from other destinations. Each log type will also have a schema that differs.

-The DICOM service returns the following fields in the audit log in Log Analytics:

-|resultDescription|String|Description of the log entry. An example here is a diagnostic log with a validation warning message when storing a file.

-The DICOM service returns the following fields in the audit log in Log Analytics:

-|Message|String|Description of the log entry. An example here is a diagnostic log with a validation warning message when storing a file.

-Below are a few basic Application Insights queries you can use to explore your log data.

-The DICOM&reg; service provides the ability to easily export DICOM data in a file format. The service simplifies the process of using medical imaging in external workflows, such as AI and machine learning. You can use the export API to export DICOM studies, series, and instances in bulk to an [Azure Blob Storage account](../../storage/blobs/storage-blobs-introduction.md). DICOM data that's exported to a storage account is exported as a `.dcm` file in a folder structure that organizes instances by `StudyInstanceID` and `SeriesInstanceID`.

-Given a *source*, the set of data to be exported, and a *destination*, the location to which data will be exported, the endpoint returns a reference to a new, long-running export operation. The duration of this operation depends on the volume of data to be exported. For more information about monitoring progress of export operations, see the [Operation status](#operation-status) section.

-Poll the preceding `href` URL for the current status of the export operation until completion. After the job has reached a terminal state, the API returns a 200 status code instead of 202. The value of its status property is updated accordingly.

-Before you get started, ensure that you've done the following steps:

-After you've created the shortcuts, expand a table to show the names and types of the columns.

-The DICOM service is secured by a Microsoft Entra ID that can't be disabled. To access the service API, you must create a client application that's also referred to as a service principal in Microsoft Entra ID and grant it with the right permissions.

-You can delete a client application. Before doing that, ensure that it's not used in production, dev, test, or quality assurance environments.

-* [Azure DICOM service with OHIF viewer](https://github.com/microsoft/dicom-ohif): The [OHIF viewer](https://ohif.org/) is an open-source, non-diagnostic DICOM viewer that uses DICOMweb APIs to find and render DICOM images. This project provides the guidance and sample templates for deploying the OHIF viewer and configuring it to integrate with the DICOM service.

-The Azure Machine Learning glossary is a short dictionary of terminology for the Azure Machine Learning platform. For the general Azure terminology, see also:

-* [Cloud computing terms](https://azure.microsoft.com/overview/cloud-computing-dictionary/) - General industry cloud terms.

-* [Azure fundamental concepts](/azure/cloud-adoption-framework/ready/considerations/fundamental-concepts) - Microsoft Cloud Adoption Framework for Azure.

-An Azure Machine Learning [component](concept-component.md) is a self-contained piece of code that does one step in a machine learning pipeline. Components are the building blocks of advanced machine learning pipelines. Components can do tasks such as data processing, model training, model scoring, and so on. A component is analogous to a function - it has a name, parameters, expects input, and returns output.

-A compute is a designated compute resource where you run your job or host your endpoint. Azure Machine Learning supports the following types of compute:

-* **Compute cluster** - a managed-compute infrastructure that allows you to easily create a cluster of CPU or GPU compute nodes in the cloud.

-* **Compute instance** - a fully configured and managed development environment in the cloud. You can use the instance as a training or inference compute for development and testing. It's similar to a virtual machine on the cloud.

-* **Kubernetes cluster** - used to deploy trained machine learning models to Azure Kubernetes Service. You can create an Azure Kubernetes Service (AKS) cluster from your Azure Machine Learning workspace, or attach an existing AKS cluster.

-* **Attached compute** - You can attach your own compute resources to your workspace and use them for training and inference.

-Azure Machine Learning allows you to work with different types of data:

-* URIs (a location in local/cloud storage)

-* Tables (a tabular data abstraction)

-* Primitives

-For most scenarios, you'll use URIs (`uri_folder` and `uri_file`) - a location in storage that can be easily mapped to the filesystem of a compute node in a job by either mounting or downloading the storage to the node.

-`mltable` is an abstraction for tabular data that is to be used for AutoML Jobs, Parallel Jobs, and some advanced scenarios. If you're just starting to use Azure Machine Learning and aren't using AutoML, we strongly encourage you to begin with URIs.

-Azure Machine Learning datastores securely keep the connection information to your data storage on Azure, so you don't have to code it in your scripts. You can register and create a datastore to easily connect to your storage account, and access the data in your underlying storage service. The CLI v2 and SDK v2 support the following types of cloud-based storage

-* Azure Blob Container

-* Azure File Share

-* Azure Data Lake

-* Azure Data Lake Gen2

-Azure Machine Learning environments are an encapsulation of the environment where your machine learning task happens. They specify the software packages, environment variables, and software settings around your training and scoring scripts. The environments are managed and versioned entities within your Machine Learning workspace. Environments enable reproducible, auditable, and portable machine learning workflows across various computes.

-Azure Machine Learning supports two types of environments: curated and custom.

-Curated environments are provided by Azure Machine Learning and are available in your workspace by default. Intended to be used as is, they contain collections of Python packages and settings to help you get started with various machine learning frameworks. These pre-created environments also allow for faster deployment time. For a full list, see the [curated environments article](resource-curated-environments.md).

-In custom environments, you're responsible for setting up your environment. Make sure to install the packages and any other dependencies that your training or scoring script needs on the compute. Azure Machine Learning allows you to create your own environment using

-* A docker image

-* A base docker image with a conda YAML to customize further

-* A docker build context

-Azure machine learning models consist of the binary file(s) that represent a machine learning model and any corresponding metadata. Models can be created from a local or remote file or directory. For remote locations `https`, `wasbs` and `azureml` locations are supported. The created model will be tracked in the workspace under the specified name and version. Azure Machine Learning supports three types of storage format for models:

-The workspace is the top-level resource for Azure Machine Learning, providing a centralized place to work with all the artifacts you create when you use Azure Machine Learning. The workspace keeps a history of all jobs, including logs, metrics, output, and a snapshot of your scripts. The workspace stores references to resources like datastores and compute. It also holds all assets like models, environments, components and data asset.

-Azure Machine Learning is a cloud service for accelerating and managing the machine learning project lifecycle. Machine learning professionals, data scientists, and engineers can use it in their day-to-day workflows: Train and deploy models, and manage MLOps.

-You can create a model in Azure Machine Learning or use a model built from an open-source platform, such as Pytorch, TensorFlow, or scikit-learn. MLOps tools help you monitor, retrain, and redeploy models.

-> **Free trial!** If you don't have an Azure subscription, create a free account before you begin. [Try the free or paid version of Azure Machine Learning](https://azure.microsoft.com/free/machine-learning/search/). You get credits to spend on Azure services. After they're used up, you can keep the account and use [free Azure services](https://azure.microsoft.com/free/). Your credit card is never charged unless you explicitly change your settings and ask to be charged.

-Azure Machine Learning is for individuals and teams implementing MLOps within their organization to bring machine learning models into production in a secure and auditable production environment.

-Data scientists and ML engineers will find tools to accelerate and automate their day-to-day workflows. Application developers will find tools for integrating models into applications or services. Platform developers will find a robust set of tools, backed by durable Azure Resource Manager APIs, for building advanced ML tooling.

-Enterprises working in the Microsoft Azure cloud will find familiar security and role-based access control (RBAC) for infrastructure. You can set up a project to deny access to protected data and select operations.

-Machine learning projects often require a team with varied skill set to build and maintain. Azure Machine Learning has tools that help enable you to:

-* Collaborate with your team via shared notebooks, compute resources, [serverless compute (preview)](how-to-use-serverless-compute.md), data, and environments

-* Develop models for fairness and explainability, tracking and auditability to fulfill lineage and audit compliance requirements

-* Deploy ML models quickly and easily at scale, and manage and govern them efficiently with MLOps

-* Run machine learning workloads anywhere with built-in governance, security, and compliance

-* [CLI (v2)](how-to-configure-cli.md))

-* [Azure Resource Manager REST APIs ](/rest/api/azureml/)

-As you're refining the model and collaborating with others throughout the rest of Machine Learning development cycle, you can share and find assets, resources, and metrics for your projects on the Azure Machine Learning studio UI.

-The [Azure Machine Learning studio](https://ml.azure.com) offers multiple authoring experiences depending on the type of project and the level of your past ML experience, without having to install anything.

-* Notebooks: write and run your own code in managed Jupyter Notebook servers that are directly integrated in the studio.

-* Visualize run metrics: analyze and optimize your experiments with visualization.

- :::image type="content" source="media/overview-what-is-azure-machine-learning/metrics.png" alt-text="Screenshot of metrics for a training run.":::

-* Azure Machine Learning designer: use the designer to train and deploy machine learning models without writing any code. Drag and drop datasets and components to create ML pipelines.

-* Automated machine learning UI: Learn how to create [automated ML experiments](tutorial-first-experiment-automated-ml.md) with an easy-to-use interface.

-* Data labeling: Use Azure Machine Learning data labeling to efficiently coordinate [image labeling](how-to-create-image-labeling-projects.md) or [text labeling](how-to-create-text-labeling-projects.md) projects.

-Azure Machine Learning integrates with the Azure cloud platform to add security to ML projects.

-* Azure Virtual Networks (VNets) with network security groups

-* Azure Key Vault where you can save security secrets, such as access information for storage accounts

-* Azure Container Registry set up behind a VNet

-See [Tutorial: Set up a secure workspace](tutorial-create-secure-workspace.md).

-Other integrations with Azure services support a machine learning project from end-to-end. They include:

-* Azure Synapse Analytics to process and stream data with Spark

-* Azure Arc, where you can run Azure services in a Kubernetes environment

-* Storage and database options, such as Azure SQL Database, Azure Storage Blobs, and so on

-* Azure App Service allowing you to deploy and manage ML-powered apps

-* [Microsoft Purview allows you to discover and catalog data assets across your organization](../purview/register-scan-azure-machine-learning.md)

-> Azure Machine Learning doesn't store or process your data outside of the region where you deploy.

->

-Typically models are developed as part of a project with an objective and goals. Projects often involve more than one person. When experimenting with data, algorithms, and models, development is iterative.

-While the project lifecycle can vary by project, it will often look like this:

-

-A workspace organizes a project and allows for collaboration for many users all working toward a common objective. Users in a workspace can easily share the results of their runs from experimentation in the studio user interface or use versioned assets for jobs like environments and storage references.

-When a project is ready for operationalization, users' work can be automated in a machine learning pipeline and triggered on a schedule or HTTPS request.

-Models can be deployed to the managed inferencing solution, for both real-time and batch deployments, abstracting away the infrastructure management typically required for deploying models.

-In Azure Machine Learning, you can run your training script in the cloud or build a model from scratch. Customers often bring models they've built and trained in open-source frameworks, so they can operationalize them in the cloud.

-Data scientists can use models in Azure Machine Learning that they've created in common Python frameworks, such as:

-Other languages and frameworks are supported as well, including:

-See [Open-source integration with Azure Machine Learning](concept-open-source.md).

-### Automated featurization and algorithm selection (AutoML)

-In a repetitive, time-consuming process, in classical machine learning data scientists use prior experience and intuition to select the right data featurization and algorithm for training. Automated ML (AutoML) speeds this process and can be used through the studio UI or Python SDK.

-See [What is automated machine learning?](concept-automated-ml.md)

-Hyperparameter optimization, or hyperparameter tuning, can be a tedious task. Azure Machine Learning can automate this task for arbitrary parameterized commands with little modification to your job definition. Results are visualized in the studio.

-See [How to tune hyperparameters](how-to-tune-hyperparameters.md).

-Efficiency of training for deep learning and sometimes classical machine learning training jobs can be drastically improved via multinode distributed training. Azure Machine Learning compute clusters and [serverless compute (preview)](how-to-use-serverless-compute.md) offer the latest GPU options.

-Supported via Azure Machine Learning Kubernetes, Azure Machine Learning compute clusters, and [serverless compute (preview)](how-to-use-serverless-compute.md):

-The MPI distribution can be used for Horovod or custom multinode logic. Additionally, Apache Spark is supported via [serverless Spark compute and attached Synapse Spark pool](apache-spark-azure-ml-concepts.md) that leverage Azure Synapse Analytics Spark clusters.

-See [Distributed training with Azure Machine Learning](concept-distributed-training.md).

-Scaling a machine learning project may require scaling embarrassingly parallel model training. This pattern is common for scenarios like forecasting demand, where a model may be trained for many stores.

-To bring a model into production, it's deployed. Azure Machine Learning's managed endpoints abstract the required infrastructure for both batch or real-time (online) model scoring (inferencing).

-*Real-time scoring*, or *online inferencing*, involves invoking an endpoint with one or more model deployments and receiving a response in near-real-time via HTTPs. Traffic can be split across multiple deployments, allowing for testing new model versions by diverting some amount of traffic initially and increasing once confidence in the new model is established.

-See:

- * [Deploy a model with a real-time managed endpoint](how-to-deploy-online-endpoints.md)

- * [Use batch endpoints for scoring](batch-inference/how-to-use-batch-endpoint.md)

-## MLOps: DevOps for machine learning

-DevOps for machine learning models, often called MLOps, is a process for developing models for production. A model's lifecycle from training to deployment must be auditable if not reproducible.

-### ML model lifecycle

-

-Azure Machine Learning is built with the model lifecycle in mind. You can audit the model lifecycle down to a specific commit and environment.

-* `git` integration

-* MLflow integration

-* Machine learning pipeline scheduling

-* Azure Event Grid integration for custom triggers

-* Easy to use with CI/CD tools like GitHub Actions or Azure DevOps

-Also, Azure Machine Learning includes features for monitoring and auditing:

-* Job artifacts, such as code snapshots, logs, and other outputs

-* Lineage between jobs and assets, such as containers, data, and compute resources

-| Single to Flexible Server (Azure portal) | Database Migration Service (classic) and the Azure portal | [Tutorial: DMS (classic) with the Azure portal (offline)](../../dms/tutorial-mysql-azure-single-to-flex-offline-portal.md) | Recommended |

-| Single to Flexible Server (Azure CLI) | [Custom shell script](https://github.com/Azure/azure-mysql/tree/master/azuremysqltomysqlmigrate) | [Migrate from Azure Database for MySQL - Single Server to Flexible Server in five easy steps!](https://techcommunity.microsoft.com/t5/azure-database-for-mysql/migrate-from-azure-database-for-mysql-single-server-to-flexible/ba-p/2674057) | The [script](https://github.com/Azure/azure-mysql/tree/master/azuremysqltomysqlmigrate) also moves other server components such as security settings and server parameter configurations. |

-| MySQL databases (< 1 TB) to Azure Database for MySQL | Database Migration Service (classic) and the Azure portal | [Migrate MySQL databases to Azure Database for MySQL using DMS (classic)](../../dms/tutorial-mysql-azure-mysql-offline-portal.md) | If network bandwidth between source and target is good (e.g: High-speed express route), use Azure DMS (database migration service) |

-| Amazon RDS for MySQL databases (< 1 TB) to Azure Database for MySQL | MySQL Workbench | [Migrate Amazon RDS for MySQL databases ( < 1 TB) to Azure Database for MySQL using MySQL Workbench](../single-server/how-to-migrate-rds-mysql-workbench.md) | If you have low network bandwidth between source and Azure, use **Mydumper/Myloader + High compute VM** to take advantage of compression settings to efficiently move data over low speed networks |

-| Import and export MySQL databases (< 1 TB) in Azure Database for MySQL | mysqldump or MySQL Workbench Import/Export utility | [Import and export - Azure Database for MySQL](../single-server/concepts-migrate-import-export.md) | Use the **mysqldump** and **MySQL Workbench Export/Import** utility tool to perform offline migrations for smaller databases. |

-| Single to Flexible Server | Mydumper/Myloader with Data-in replication | [Migrate Azure Database for MySQL ΓÇô Single Server to Azure Database for MySQL ΓÇô Flexible Server with open-source tools](how-to-migrate-single-flexible-minimum-downtime.md) | N/A |

-description: Learn how to migrate to Connection Monitor from Network Performance Monitor.

-#Customer intent: I need to migrate from Network Performance Monitor to Connection Monitor.

-# Migrate to Connection Monitor from Network Performance Monitor

-> [!IMPORTANT]

-> Starting 1 July 2021, you'll not be able to add new tests in an existing workspace or enable a new workspace with Network Performance Monitor. You can continue to use the tests created prior to 1 July 2021. To minimize service disruption to your current workloads, migrate your tests from Network Performance Monitor to the new Connection Monitor in Azure Network Watcher before 29 February 2024.

-You can migrate tests from Network Performance Monitor to new, improved Connection Monitor with a single click and with zero downtime. To learn more about the benefits, see [Connection Monitor](./connection-monitor-overview.md).

-* On-premises agents and firewall settings work as is. No changes are required. Log Analytics agents that are installed on Azure virtual machines need to be replaced with the [Network Watcher extension](../virtual-machines/extensions/network-watcher-windows.md).

-* Existing tests are mapped to Connection Monitor > Test Group > Test format. By selecting **Edit**, you can view and modify the properties of the new Connection Monitor, download a template to make changes to it, and submit the template via Azure Resource Manager.

-* Agents send data to both the Log Analytics workspace and the metrics.

-* Data monitoring:

- * **Data in Log Analytics**: Before migration, the data remains in the workspace in which Network Performance Monitor is configured in the NetworkMonitoring table. After the migration, the data goes to the NetworkMonitoring table, NWConnectionMonitorTestResult table and NWConnectionMonitorPathResult table in the same workspace. After the tests are disabled in Network Performance Monitor, the data is stored only in the NWConnectionMonitorTestResult table and NWConnectionMonitorPathResult table.

- * **Log-based alerts, dashboards, and integrations**: You must manually edit the queries based on the new NWConnectionMonitorTestResult table and NWConnectionMonitorPathResult table. To re-create the alerts in metrics, see [Network connectivity monitoring with Connection Monitor](./connection-monitor-overview.md#metrics-in-azure-monitor).

-* For ExpressRoute Monitoring:

- * **End to end loss and latency**: Connection Monitor will power this, and it will be easier than Network Performance Monitor, as users don't need to configure which circuits and peerings to monitor. Circuits in the path will automatically be discovered, data will be available in metrics (faster than LA, which was where Network Performance Monitor stored the results). Topology will work as is as well.

- * **Bandwidth measurements**: With the launch of bandwidth related metrics, Network Performance MonitorΓÇÖs log analytics based approach wasn't effective in bandwidth monitoring for ExpressRoute customers. This capability is now not available in Connection Monitor.

-* Ensure that Network Watcher is enabled in your subscription and the region of the Log Analytics workspace. If not done, you'll see an error stating "Before you attempt migrate, enable Network watcher extension in selection subscription and location of LA workspace selected."

-* In case Azure VM belonging to a different region/subscription than that of Log Analytics workspace is used as an endpoint, make sure Network Watcher is enabled for that subscription and region.

-* Azure virtual machines with Log Analytics agents installed must be enabled with the Network Watcher extension.

-To migrate the tests from Network Performance Monitor to Connection Monitor, do the following:

- :::image type="content" source="./media/connection-monitor-2-preview/migrate-netpm-to-cm-preview.png" alt-text="Migrate tests from Network Performance Monitor to Connection Monitor" lightbox="./media/connection-monitor-2-preview/migrate-netpm-to-cm-preview.png":::

-1. In the drop-down lists, select your subscription and workspace, and then select the Network Performance Monitor feature you want to migrate.

-* If Network Performance Monitor isn't enabled on the workspace, you'll see an error stating "No valid NPM config found".

-* If no tests exist in the feature you chose in step2, you'll see an error stating "Workspace selected doesn't have \<feature\> config".

-* If there are no valid tests, you'll see an error stating "Workspace selected does not have valid tests"

-* Your tests may contain agents that are no longer active, but may have been active in the past. You'll see an error stating "Few tests contain agents that are no longer active. List of inactive agents - {0}. These agents may be running in the past but are shut down/not running anymore. Enable agents and migrate to Connection Monitor. Select continue to migrate the tests that do not contain agents that are not active."

-* A new connection monitor resource is created.

- * One connection monitor per region and subscription is created. For tests with on-premises agents, the new connection monitor name is formatted as `<workspaceName>_"workspace_region_name"`. For tests with Azure agents, the new connection monitor name is formatted as `<workspaceName>_<Azure_region_name>`.

- * Monitoring data is now stored in the same Log Analytics workspace in which Network Performance Monitor is enabled, in new tables called NWConnectionMonitorTestResult table and NWConnectionMonitorPathResult table.

- * The test name is carried forward as the test group name. The test description isn't migrated.

- * Source and destination endpoints are created and used in the new test group. For on-premises agents, the endpoints are formatted as `<workspaceName>_<FQDN of on-premises machine>`. The Agent description isn't migrated.

- * Destination port and probing interval are moved to a test configuration called `TC_<protocol>_<port>` and `TC_<protocol>_<port>_AppThresholds`. The protocol is set based on the port values. For ICMP, the test configurations are named as `TC_<protocol>` and `TC_<protocol>_AppThresholds`. Success thresholds and other optional properties if set, are migrated, otherwise are left blank.

- * If the migrating tests contain agents that aren't running, you need to enable the agents and migrate again.

-* Network Performance Monitor isn't disabled, so the migrated tests can continue to send data to the NetworkMonitoring table, NWConnectionMonitorTestResult table and NWConnectionMonitorPathResult table. This approach ensures that existing log-based alerts and integrations are unaffected.

-* The newly created connection monitor is visible in Connection Monitor.

-* Manually disable the tests in Network Performance Monitor. Until you do so, you'll continue to be charged for them.

-* While you're disabling Network Performance Monitor, re-create your alerts on the NWConnectionMonitorTestResult and NWConnectionMonitorPathResult tables or use metrics.

-* Migrate any external integrations to the NWConnectionMonitorTestResult and NWConnectionMonitorPathResult tables. Examples of external integrations are dashboards in Power BI and Grafana, and integrations with Security Information and Event Management (SIEM) systems.

-Below are some common errors faced during the migration:

-| Error | Reason |

-|||

-| No valid NPM config found. Go to NPM UI to check config | This error occurs when User is selecting Import Tests from Network Performance Monitor to migrate the tests but Network Performance Monitor isn't enabled in the workspace. |

-|Workspace selected does not have 'Service Connectivity Monitor' config | This error occurs when User is migrating tests from Network Performance MonitorΓÇÖs Service Connectivity Monitor to Connection Monitor but there are no tests configured in Service Connectivity Monitor. |

-|Workspace selected does not have 'ExpressRoute Monitor' config | This error occurs when User is migrating tests from Network Performance MonitorΓÇÖs ExpressRoute Monitor to Connection Monitor but there are no tests configured in ExpressRoute Monitor. |

-|Workspace selected does not have 'Performance Monitor' config | This error occurs when User is migrating tests from Network Performance MonitorΓÇÖs Performance Monitor to Connection Monitor but there are no tests configured in Performance Monitor. |

-|Workspace selected does not have valid '{0}' tests | This error occurs when User is migrating tests from Network Performance Monitor to Connection Monitor but there are no valid tests present in the feature chosen by User to migrate. |

-|Before you attempt migrate, enable Network watcher extension in selection subscription and location of LA workspace selected | This error occurs when User is migrating tests from Network Performance Monitor to Connection Monitor and Network Watcher Extension isn't enabled in the LA workspace selected. User needs to enable NW Extension before migrating tests. |

-|Few {1} tests contain agents that are no longer active. List of inactive agents - {0}. These agents may be running in the past but are shut down/not running anymore. Enable agents and migrate to Connection Monitor. Select continue to migrate the tests that do not contain agents that are not active. | This error occurs when User is migrating tests from Network Performance Monitor to Connection Monitor and some selected tests contain inactive Network Watcher Agents or such NW Agents, which are no longer active but used to be active in the past and have been shut down. User can deselect these tests and continue to select and migrate the tests, which don't contain any such inactive agents. |

-|Your {1} tests contain agents that are no longer active. List of inactive agents - {0}. These agents may be running in the past but are shut down/not running anymore. Enable agents and migrate to Connection Monitor | This error occurs when User is migrating tests from Network Performance Monitor to Connection Monitor and selected tests contain inactive Network Watcher Agents or such NW Agents, which are no longer active but used to be active in the past and have been shut down. User needs to enable the agents and then continue to migrate these tests to Connection Monitor. |

-|An error occurred while importing tests to connection monitor | This error occurs when the User is trying to migrate tests from Network Performance Monitor to CM but the migration isn't successful due to errors. |

-## Next steps

-To learn more about Connection Monitor, see:

-* [Migrate from Connection Monitor (classic) to Connection Monitor](./migrate-to-connection-monitor-from-connection-monitor-classic.md)

-* [Create Connection Monitor by using the Azure portal](./connection-monitor-create-using-portal.md)

-or servers with more than 1 TiB of provisioned storage, the storage autogrow mechanism activates when the available space falls to less than 10% of the total capacity or 64 GiB of free space, whichever of the two values is smaller. Conversely, for servers with storage under 1 TB, this threshold is adjusted to 20% of the available free space or 64 GiB, depending on which of these values is smaller.

-If you set an environment variable by using the command line, that variable will be readable in your command line history. Consider clearing variables that contain credentials from your command line history. To keep variables from appearing in your history, you can use a script to prompt the user for their credentials, and to set the environment variable.

-Download all the versions of a blob from Azure Storage to local directory. Ensure that source is a valid blob, destination is a local folder and `versionidsFile` which takes in a path to the file where each version is written on a separate line. All the specified versions will get downloaded in the destination folder specified.

-`--preserve-permissions` False by default. Preserves ACLs between aware resources (Windows and Azure Files, or Azure Data Lake Storage Gen2 to Azure Data Lake Storage Gen2). For Hierarchical Namespace accounts, you'll need a container SAS or OAuth token with Modify Ownership and Modify Permissions permissions. For downloads, you'll also need the `--backup` flag to restore permissions where the new Owner won't be the user running AzCopy. This flag applies to both files and folders, unless a file-only filter is specified (for example, include-pattern).

-## Disk IO, throughput and queue depth metrics

-The following metrics are available to get insight on VM and Disk IO, throughput, and queue depth performance: