You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/application-gateway/migrate-v1-v2.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
title: Migrate from V1 to V2 - Azure Application Gateway
3
-
description: This article shows you how to migrate Azure Application Gateway and Web Application Firewall from V1 to V2
3
+
description: This article shows you how to migrate Azure Application Gateway and Web Application Firewall from V1 to V2.
4
4
services: application-gateway
5
5
author: greg-lindsay
6
6
ms.service: application-gateway
@@ -31,7 +31,7 @@ This article primarily helps with the configuration migration. Client traffic mi
31
31
* An existing Application Gateway V1 Standard.
32
32
* Make sure you have the latest PowerShell modules, or you can use Azure Cloud Shell in the portal.
33
33
* If you're running PowerShell locally, you also need to run `Connect-AzAccount` to create a connection with Azure.
34
-
* Ensure that there is no existing Application gateway with the provided AppGW V2 Name and Resource group name in V1 subscription. This will rewrite the existing resources.
34
+
* Ensure that there's no existing Application gateway with the provided AppGW V2 Name and Resource group name in V1 subscription. This will rewrite the existing resources.
35
35
* If a public IP address is provided, ensure that it's in a succeeded state. If not provided and AppGWResourceGroupName is provided ensure that public IP resource with name AppGWV2Name-IP doesn’t exist in a resource group with the name AppGWResourceGroupName in the V1 subscription.
36
36
* Ensure that no other operation is planned on the V1 gateway or any associated resources during migration.
37
37
@@ -54,7 +54,7 @@ An Azure PowerShell script is provided in this document. It performs the followi
54
54
55
55
## Downloading the script
56
56
57
-
You can download the migration script from the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureAppGWMigration).A new stable release (Version 1.0.11) of the migration script is available, which includes major updates and bug fixes. It is recommended to use this stable version.
57
+
You can download the migration script from the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureAppGWMigration).A new stable release (Version 1.0.11) of the migration script is available, which includes major updates and bug fixes. It's recommended to use this stable version.
58
58
59
59
60
60
## Using the script
@@ -82,7 +82,7 @@ This command also installs the required Az modules.
82
82
#### Install using the script directly
83
83
If you have some Azure Az modules installed and can't uninstall them (or don't want to uninstall them), you can manually download the script using the **Manual Download** tab in the script download link. The script is downloaded as a raw nupkg file. To install the script from this nupkg file, see [Manual Package Download](/powershell/gallery/how-to/working-with-packages/manual-download).
84
84
85
-
Version 1.0.11 is the new version of the migration script which includes major bug fixes. It is recommended to use this stable version.
85
+
Version 1.0.11 is the new version of the migration script which includes major bug fixes. It's recommended to use this stable version.
86
86
87
87
#### How to check the version of the downloaded script
88
88
To check the version of the downloaded script the steps are as follows:
@@ -141,7 +141,7 @@ To run the script:
141
141
* **appgwName: [String]: Optional**. This is a string you specify to use as the name for the new Standard_V2 or WAF_V2 gateway. If this parameter isn't supplied, the name of your existing V1 gateway is used with the suffix *_V2* appended.
142
142
* **AppGWResourceGroupName: [String]: Optional**. Name of resource group where you want V2 Application Gateway resources to be created (default value is `<V1-app-gw-rgname>`)
143
143
> [!NOTE]
144
-
> Ensure that there is no existing Application gateway with the provided AppGW V2 Name and Resource group name in V1 subscription. This will rewrite the existing resources.
144
+
> Ensure that there's no existing Application gateway with the provided AppGW V2 Name and Resource group name in V1 subscription. This will rewrite the existing resources.
145
145
* **sslCertificates: [PSApplicationGatewaySslCertificate]: Optional**. A comma-separated list of PSApplicationGatewaySslCertificate objects that you create to represent the TLS/SSL certs from your V1 gateway must be uploaded to the new V2 gateway. For each of your TLS/SSL certs configured for your Standard V1 or WAF V1 gateway, you can create a new PSApplicationGatewaySslCertificate object via the `New-AzApplicationGatewaySslCertificate` command shown here. You need the path to your TLS/SSL Cert file and the password.
146
146
147
147
This parameter is only optional if you don't have HTTPS listeners configured for your V1 gateway or WAF. If you have at least one HTTPS listener setup, you must specify this parameter.
@@ -194,8 +194,8 @@ To run the script:
194
194
* **publicIpResourceId: [String]: Optional**. The resourceId of existing public IP address (standard SKU) resource in your subscription that you want to allocate to the new V2 gateway. If public Ip resource name is provided, ensure that it exists in succeeded state.
195
195
If this isn't specified, the script allocates a new public IP address in the same resource group. The name is the V2 gateway's name with *-IP* appended. If AppGWResourceGroupName is provided and a public IP address is not provided, ensure that public IP resource with name AppGWV2Name-IP doesn’t exist in a resource group with the name AppGWResourceGroupName in the V1 subscription.
196
196
197
-
* **validateMigration: [switch]: Optional**. Use this parameter if you want the script to do some basic configuration comparison validations after the V2 gateway creation and the configuration copy. By default, no validation is done.
198
-
* **enableAutoScale: [switch]: Optional**. Use this parameter if you want the script to enable autoscaling on the new V2 gateway after it's created. By default, autoscaling is disabled. You can always manually enable it later on the newly created V2 gateway.
197
+
* **validateMigration: [switch]: Optional**. Use this parameter to enable the script to do some basic configuration comparison validations after the V2 gateway creation and the configuration copy. By default, no validation is done.
198
+
* **enableAutoScale: [switch]: Optional**. Use this parameter to enable the script to enable autoscaling on the new V2 gateway after it's created. By default, autoscaling is disabled. You can always manually enable it later on the newly created V2 gateway.
199
199
200
200
5. Run the script using the appropriate parameters. It may take five to seven minutes to finish.
title: Use Azure Resource Graph Explorer to query Azure Private DNS
3
+
titleSuffix: Azure DNS
4
+
description: Learn how to query Azure Private DNS zones using Azure Resource Graph Explorer
5
+
services: dns
6
+
author: greg-lindsay
7
+
ms.service: dns
8
+
ms.date: 02/26/2024
9
+
ms.author: greglin
10
+
ms.topic: how-to
11
+
---
12
+
13
+
# Private DNS information in Azure Resource Graph
14
+
15
+
[Azure Resource Graph](../governance/resource-graph/overview.md) is an Azure service that allows you to use the same KQL query language used in log queries to query your Azure resources at scale with complex filtering, grouping, and sorting by resource properties. You can use Azure Resource Graph (ARG) to provide detailed information about your private zones including the following:
16
+
17
+
- Query the type and number of DNS resource records in one or all zones.
18
+
- Query virtual network links.
19
+
- List record properties, such as TTL
20
+
21
+
To get started with Resource Graph, open **Resource Graph Explorer** in the Azure portal. Select the **Table** tab and have a look at the [microsoft.resourcehealth/availabilitystatuses](#microsoftresourcehealthavailabilitystatuses) and [microsoft.resourcehealth/resourceannotations](#microsoftresourcehealthresourceannotations) tables which are described below. Click on **healthresources** to create a simple query and then click **Run** to return the records.
22
+
23
+
:::image type="content" source="media/monitor-vm/resource-graph-explorer-healthresources.png" alt-text="Screenshot of Azure Resource Graph with simple healthresources query." lightbox="media/monitor-vm/resource-graph-explorer-healthresources.png" :::
24
+
25
+
To view the details for a record, scroll to the right and select **See details**.
There will be two types of events populated in the HealthResources table:
30
+
31
+
## microsoft.resourcehealth/availabilitystatuses
32
+
This event denotes the latest availability status of a VM, based on the [health checks](../service-health/resource-health-checks-resource-types.md#microsoftcomputevirtualmachines) performed by the underlying Azure platform. The [availability states](../service-health/resource-health-overview.md#health-status) currently emitted for VMs are as follows:
33
+
34
+
-**Available**: The VM is up and running as expected.
35
+
-**Unavailable**: A disruption to the normal functioning of the VM has been detected.
36
+
-**Unknown**: The platform is unable to accurately detect the health of the VM. Check back in a few minutes.
37
+
38
+
The availability state is in the `properties` field of the record which includes the following properties:
39
+
40
+
| Field | Description |
41
+
|:---|:---|
42
+
| targetResourceType | Type of resource for which health data is flowing |
43
+
| targetResourceId | Resource ID |
44
+
| occurredTime | Timestamp when the latest availability state is emitted by the platform |
45
+
| previousAvailabilityState | Previous availability state of the VM |
46
+
| availabilityState | Current availability state of the VM |
47
+
48
+
A sample `properties` value looks similar to the following:
This event contextualizes any changes to VM availability, by detailing necessary failure attributes to help you investigate and mitigate the disruption as needed. The full list of VM health annotations are listed at [Resource Health virtual machine Health Annotations] (../service-health/resource-health-vm-annotation.md).
62
+
63
+
These annotations can be broadly classified into the following:
64
+
65
+
-**Downtime Annotations**: Emitted when the platform detects VM availability transitioning to Unavailable. Examples include host crashes or reboot operations.
66
+
-**Informational Annotations**: Emitted during control plane activities with no impact to VM availability. Examples include VM allocation, stop, delete, start. Usually, no additional customer action is required in response.
67
+
-**Degraded Annotations**: Emitted when VM availability is detected to be at risk. Examples include when failure prediction models predict a degraded hardware component that can cause the VM to reboot at any given time. You should redeploy by the deadline specified in the annotation message to avoid any unanticipated loss of data or downtime.
68
+
69
+
| Field | Description |
70
+
|:---|:---|
71
+
| targetResourceType | Type of resource for which health data is flowing |
72
+
| targetResourceId | Resource ID |
73
+
| occurredTime | Timestamp when the latest availability state is emitted by the platform |
74
+
| annotationName | Name of the Annotation emitted |
75
+
| reason | Brief overview of the availability impact observed by the customer |
76
+
| category | Denotes whether the platform activity triggering the annotation was either planned maintenance or unplanned repair. This field is not applicable to customer/VM-initiated events.<br><br>Possible values: Planned \| Unplanned \| Not Applicable \| Null |
77
+
| context | Denotes whether the activity triggering the annotation was due to an authorized user or process (customer initiated), due to the Azure platform (platform initiated), or due to activity in the guest OS that has resulted in availability impact (VM initiated).<br><br>Possible values: Platform-Initiated \| User-initiated \| VM-initiated \| Not Applicable \| Null |
78
+
| summary | Statement detailing the cause for annotation emission, along with remediation steps that can be taken by users |
79
+
80
+
See [Azure Resource Graph sample queries by table](../governance/resource-graph/samples/samples-by-table.md?tabs=azure-cli#healthresources) for sample queries using this data.
81
+
82
+
## Next steps
83
+
84
+
## Next steps
85
+
86
+
* Learn how to [manage record sets and records](./private-dns-getstarted-cli.md) in your DNS zone.
0 commit comments