Describe the bug

ERGW-2 - Use Zone-redundant gateway SKUs is returning the wrong recommendation ID from the query. See line in query:
| project recommendationId = "ergw-1", name, id, tags, ...

To Reproduce

Steps to reproduce the behaviour:

NA

Expected behaviour

Return ID ERGW-2

Screenshots 📷

NA

Additional context

NA

Describe the bug

AGW-9 is returning the wrong recommendation ID. See the following from the ARG query:

| project recommendationID = "agw-8", name, id, tags, ...

To Reproduce

NA

Expected behaviour

Return ID agw-9

Screenshots 📷

NA.

Additional context

NA

Question/Feedback

1. All queries should project the same columns: recommendationid, name, id, param1, param2, param3, param4, param5

2. All queries should have comments specifying what query results are provided. Example below:
   

3. All queries should have standardized syntax and formatting

Possible Answers/Solutions?

Helps with standardization across the different service recommendations as well as allows for easier incorporation of automation.

Describe the bug

The App-5 query return incorrect recommendationid "asp-5". This should be "app-5" which is the same as the id.

To Reproduce

Create a 'microsoft.web/sites' or "microsoft.web/sites/slots' resource and execute app-5.kql.

Expected behaviour

The returned recommendationid value should be 'app-5'

Screenshots 📷

Describe the solution you'd like

APRL has automation standards for Azure Resource Graph queries. However, there are no standards for PowerShell scripts.

PowerShell script-based recommendations are necessary because some APRL recommendations are difficult to cover by ARG queries. So, we need automation standards for PowerShell scripts.

Describe alternatives you've considered

The following is my proposal for the automation standards for PowerShell scripts.

Automation Standards for PowerShell scripts

1. All PowerShell scripts should have two comments at the top of the script, one comment stating Azure PowerShell script and another comment providing a description of the script results returned. For example:

   // Azure PowerShell script
   // Provides a list of Azure Container Registry resources that do not have soft delete enabled
   

2. Scripts should only return resources that do not adhere to the APRL recommendation. For example, if the recommendation is to enable soft delete for Azure Container Registries, the associated scripts should only return Azure Container Registry resources that do not have soft delete enabled.

3. Scripts should only include codes to return resources that do not adhere to the APRL recommendation. Scripts should not include the support code such as sign-in to Azure (Connect-AzAccount, Login-AzAccount), subscription selection (Set-AzContext, Select-AzSubscription), etc. Those codes should be executed outside of the APRL recommendation PowerShell script.

4. The script should returned the result as an array of PSCustomObject data type, and each result object should only include the following properties:

   Property Name	Data Type	Required	Information Returned (Example)	Description
   recommendationId	string	Yes	aks-1	The acronym of the Azure service that the query is returning results for, followed by the APRL recommendation number.
   name	string	Yes	test-aks	The resource name of the Azure resource that does not adher to the APRL recommendation.
   id	string	Yes	/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/test-resource-group/providers/Microsoft.ContainerService/managedClusters/test-aks	The resource ID of the Azure resource that does not adhere to the APRL recommendation.
   tags	PSCustomObject	No	{"Environment":"Test","Department":"IT"}	Any relevant tags associated to the resource that does not adhere to the APRL recommendation. The data type should match the data type of tags in the result of ARG queries by Search-AzGraph. If not set tags, set $null.
   param1	string	No	networkProfile:kubenet	Any additional information that is necessary to provide clarification for the APRL recommendation.
   param2	string	No	networkProfile:kubenet	Any additional information that is necessary to provide clarification for the APRL recommendation.
   param3	string	No	networkProfile:kubenet	Any additional information that is necessary to provide clarification for the APRL recommendation.
   param4	string	No	networkProfile:kubenet	Any additional information that is necessary to provide clarification for the APRL recommendation.
   param5	string	No	networkProfile:kubenet	Any additional information that is necessary to provide clarification for the APRL recommendation.

   [PSCustomObject] @{
       recommendationId = 'aks-1'
       name             = $resource.Name
       id               = $resource.Id
       tags             = if ($resource.Tags) { [PSCustomObject] ([Hashtable] $resource.Tags) } else { $null }
       param1           = 'networkProfile:kubenet'
       param2           = 'networkProfile:kubenet'
       param3           = 'networkProfile:kubenet'
       param4           = 'networkProfile:kubenet'
       param5           = 'networkProfile:kubenet'
   }

Additional context

I'm creating helper scripts for APRL that allow batch execution of the APRL's queries and PowerShell scripts together. Hard to implement unified automation if not defined automation standards for APRL PowerShell scripts. Probably, not only me that facing the similar situation.

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behaviour:

1. Fill
2. Me
3. In

Expected behaviour

A clear and concise description of what you expected to happen without this bug 🙂

Screenshots 📷

If applicable, add screenshots to help explain your problem. Please feel free to blur/cover any sensitive information.

Additional context

Anything else we should know to help us troubleshoot this bug?

Describe the bug

In this file, it says

{{< code lang="sql" file="code/evg-1/evg-1.ps1" >}} {{< /code >}}

instead of

{{< code lang="powershell" file="code/evg-1/evg-1.ps1" >}} {{< /code >}}

both for evg-1.ps1 and evg-2.ps1.

Expected behaviour

My parser would work 😜

Describe the bug

ST-1 has two KQL files then one of two files has the non-standard file name format that has .fix suffix.

• st-1.kql

  • https://github.com/Azure/Azure-Proactive-Resiliency-Library/blob/main/docs/content/services/storage/storage-Account/code/st-1/st-1.kql

• st-1.kql.fix

  • https://github.com/Azure/Azure-Proactive-Resiliency-Library/blob/main/docs/content/services/storage/storage-Account/code/st-1/st-1.kql.fix

To Reproduce

• n/a

Expected behaviour

• Align to the standard file name format like st-1.kql.

Screenshots 📷

None

Additional context

None

Describe the bug

Traffic Manager is no longer visible in the list of services and when going to the App GW page, the ARG queries no longer show.

To Reproduce

Steps to reproduce the behaviour:

1. Go to https://azure.github.io/Azure-Proactive-Resiliency-Library/services/networking/
2. Traffic Manager is not listed.
3. Go to https://azure.github.io/Azure-Proactive-Resiliency-Library/services/networking/application-gateway/
4. Queries are missing

Expected behaviour

Traffic Manager listed and App gateway queries available.

Screenshots 📷

Additional context

Anything else we should know to help us troubleshoot this bug?

Describe the bug

If you create a new ANF volume with no zone, it will put the following in the resource JSON:
"zones": []

If you populate or specify the zone then it will put something like the following in the resource JSON:
"zones": [
"3"
]

I am also seeing situations where the zone is not referenced at all anywhere in the JSON. I am unsure the cause of this situation. However, this means the query is not catching these volumes with no zones because the query does the following check:
| where zones == "[]"

I suggest changing this query to check the following conditions instead:
| where array_length(zones) == 0 or isnull(zones)

That should catch both scenarios where no zone has been set.

To Reproduce

Not sure how this situation of zone field not populated into resource JSON occurs.

Expected behaviour

The recommendation should catch all volumes without zones.

Screenshots 📷

NA

Additional context

NA

Feedback

In the VNET-2 guidance explains DDoS IP Protection NOT available in East US 2 and West Europe regions. But DDoS IP Protection is available in those regions currently.

• https://azure.github.io/Azure-Proactive-Resiliency-Library/services/networking/virtual-networks/#vnet-2---use-azure-ddos-standard-protection-plans-to-protect-all-public-endpoints-hosted-within-customer-virtual-networks

  P.S. DDoS IP Protection is currently not available in East US 2 and West Europe regions.

The pricing is available in East US 2 and West Europe regions.

• Azure DDoS Protection pricing

Also, it could be configured.

East US 2:

West Europe:

Possible Solutions?

Remove the following sentence from the guidance of VNET-2.

P.S. DDoS IP Protection is currently not available in East US 2 and West Europe regions.

Describe the bug

The acronym for ExpressRoute gateway is ergw in the CAF documentation. However, APRL uses erg as an acronym for ExpressRoute gateway.

Example: https://github.com/Azure/Azure-Proactive-Resiliency-Library/blob/main/docs/content/services/networking/expressroute-gateway/code/erg-1/erg-1.kql

Also, mismatching the acronym between the file name and query result because the KQL query returns the correct acronym ergw even if file name erg-1.kql.

To Reproduce

n/a

Expected behaviour

The file and directory name align to CAF acronyms, also those matches with the query result.

Screenshots 📷

n/a

Additional context

n/a

Describe the bug

This appears to be an issue when having read access to the resources. When you run the query with read access, all virtual machines will show up as having replication not enabled. However, when actually looking at the resources with additional privileges, the query will return the correct results of the ASR replication status.

As an additional note, when looking at the virtual machine's replication configuration status within the VM's blade, the VMs will also show up as not having replication enabled here as well.

To Reproduce

Steps to reproduce the behaviour:

1. Run the query with read access to the relevant ASR and VM resources.

OR

1. View the replication status within the VM blade.
   

Expected behaviour

This query returns incorrect results with read-access.

Screenshots 📷

If applicable, add screenshots to help explain your problem. Please feel free to blur/cover any sensitive information.

Additional context

Anything else we should know to help us troubleshoot this bug?

Describe the bug

The child page default order appears to be sorted by weight\time creation rather than alphabetically. Adding a new category such as "Monitoring" puts the menu item in the side navigation at the bottom and puts the item at the bottom of the Azure Services page category list rather than sorting alphabetically. See screen shot.

To Reproduce

Steps to reproduce the behaviour:

1. Create a new service category
2. See category at bottom of list

Expected behaviour

1. New category should be shown alphabetically

Screenshots 📷

Additional context

Anything else we should know to help us troubleshoot this bug?

Feedback

The policy name as param1 of the result of the VM-18 is not helpful because it is difficult to find the actual policy from the value in param1.

Possible Answers/Solutions?

Set a searchable value in Azure portal to param1.

Describe the bug

ST-1 - Ensure that Storage Accounts are Zone or Region redundant does not include "Premium_LRS" as part of the condition in the ARG query. The following line in the query:

| where sku.name =~'Standard_LRS'

Should also check for 'Premium_LRS'

To Reproduce

NA

Expected behaviour

Query should capture all LRS storage accounts whether standard or premium.

Screenshots 📷

NA

Additional context

NA

Question/Feedback

What is the naming convention used by APRL?

Also, rule code / name are in the format: <service abbreviation>-digit. This causes issues if you want to print an ordered list of rules from tools such as Azure Quick Review (i.e. FW-10 will come on top of FW-1).

Possible Answers/Solutions?

Use the service abbreviation that we recommend as part of CAF here as the new naming convention.

Rule code / name should follow the format: <service abbreviation>-\d{3}$. The samples below show some rule names for Azure Firewall:

• AFW-001
• AFW-010
• AFW-101

Describe the bug

KQL does not produce any correct result because zone is not specified under VM's properties.hardwareProfile.

To Reproduce

Steps to reproduce the behaviour:

1. Run KQL. It will list all VMs in the sub even for zonal VMs because the condition would always evaluate to true.

Expected behaviour

List all non-zonal VMs in ARG Explorer.

Screenshots 📷

If applicable, add screenshots to help explain your problem. Please feel free to blur/cover any sensitive information.

Additional context

Anything else we should know to help us troubleshoot this bug?
Nothing, I will submit a PR to fix this bug.

Describe the solution you'd like

Add query to find key vaults without diagnostics settings configured.

Describe alternatives you've considered

N/A

Additional context

n/a

Describe the bug

ERC-3 is returning the wrong recommendation ID. See the following from the ARG query:

| project recommendationId = "erc-1", name, id, tags, ...

To Reproduce

NA

Expected behaviour

Return recommendation ID erc-3

Screenshots 📷

NA

Additional context

NA

Feedback

The tags column in the result of the VM-18 query came from policy state resources, not VM resources. In general, cannot assign tags to policy state resources, so, the tags column in the query result is always null.

Possible Answers/Solutions?

Retrieve tags column from VM resources.

Describe the bug

The VM-11 Cannot be validated with ARGs. Let's remove the ARG file and/or develop Powershell (for Windows)/shell for Linux scripts to capture that from the OS.

To Reproduce

Steps to reproduce the behavior:

1. Running this query does not generate guest OS information, only Azure platform information.

Expected behavior

The VM-11 Cannot be validated with ARGs.

Screenshots 📷

n/a

Additional context

The VM-11 Cannot be validated with ARGs.

Describe the bug

The VM-20 query returns incorrect result. Because the VM extension installation state does not represent VM insights enabled, or not.

To Reproduce

Steps to reproduce the behavior:

1. Deploy an Azure Windows VM.
2. Install AzureMonitorWindowsAgent extension to the deployed Azure Windows VM.

The query result does not have the deployed Azure Windows VM even though VM insights is not enabled.

Expected behavior

The query returns the correct result.

Screenshots 📷

1. Not enabled VM insights on vm6, and it have the AzureMonitorWindowsAgent VM extension.

   

   

   

   

2. The query result does not have vm6 even though VM insights is not enabled. (The result should include vm6 because VM insights is not enabled on the VM)

   

Additional context

None

Describe the bug

GatewaySubnet should be excluded as applying NSG on it is not supported.

To Reproduce

1. Create a VNet and a "GatewaySubnet" subnet in it.
2. Run vnet-1.kql
3. The output shows the GatewaySubnet as a recommendation item.

Expected behaviour

KQL should ignore GatewaySubnet in where clause.

Screenshots 📷

N/A

Additional context

N/A

Question/Feedback

KQL files under the general-networking and network-watcher have the same ID. Is this expected?

• nw-1 in general-networking

  • https://github.com/Azure/Azure-Proactive-Resiliency-Library/blob/main/docs/content/services/networking/general-networking/code/nw-1/nw-1.kql

• nw-1 in network-watcher

  • https://github.com/Azure/Azure-Proactive-Resiliency-Library/blob/main/docs/content/services/networking/network-watcher/code/nw-1/nw-1.kql

Possible Answers/Solutions?

I'm guessing each query file has a unique ID for easy identification.

Describe the bug

The Resource Graph Query cannot return whether the diagnostic setting is enabled.
Since properties.diagnosticSettings does not exist on Key Vault, the query always returns all Key Vaults even if diagnostic logs are set.

To Reproduce

Steps to reproduce the behaviour:

1. Run KQL. It will list all Key Vaults even if diagnostic logs are set because the following condition would always evaluate to true.

| where Diag = (isempty (properties.diagnosticSettings))

Expected behaviour

The query should return a list of Key Vaults that do not have diagnostic settings enabled.

Screenshots 📷

If applicable, add screenshots to help explain your problem. Please feel free to blur/cover any sensitive information.

Additional context

There seems to be no way to return desired results by KQL at present. In order to avoid confusion, it would be better to remove the query until the feature is available.

Describe the bug

Using hugoIf multiple KQL queries contain exactly the same code, the code snippet in _index.md will show/hide all of the KQL code sections when any of the corresponding Show/Hide Query/Script buttons are used.

For example, when WAF-1, WAF-2, WAF-4 and WAF-5 all have the same code (in separate files) of "// cannot-be-validated-with-arg", then any of the Show/Hide Query/Script buttons will toggle showing/hiding all of the code sections for WAF-1, WAF-2, WAF-4, WAF-5.

Live example:
https://azure.github.io/Azure-Proactive-Resiliency-Library/services/networking/firewall/

Toggle any of AFW-2, AFW-4 or AFW-7 to show/hide all 3 at the same time.

To Reproduce

Steps to reproduce the behaviour:

1. Create KQL code files with the same content
2. Using either hugo or the live site with the updated code, toggle the corresponding sections
3. Note if all affected sections can toggle the state of all other affected sections.

Expected behaviour

A section's Show/Hide Query/Script toggle button should only show/hide that particular section's code.

Screenshots 📷

Additional context

Anything else we should know to help us troubleshoot this bug?

Describe the solution you'd like

Add query to list subscriptions without service health alerts (ala-1)

Describe alternatives you've considered

N/A

Additional context

N/A

Describe the bug

I have an ExpressRoute Gateway with connections to circuits from two different peering locations, but the query is still capturing it as part of the conditions for the query.

To Reproduce

Expected behaviour

If the gateway has 2 connections from 2 separate peering locations it should not be caught by the query.

Screenshots 📷

Additional context

@ejhenry

Describe the bug

All Service Recommendations Pages should have a column within the Summary of Recommendations called Category. The Category should also be listed within the individual Recommendations Details as well. To name a few services that are missing Category (either within the Summary of Recommendations table or the Recommendations Details) include the following list:

• Azure Databricks
• Azure Site Recovery
• Compute Gallery
• Image Templates
• VMSS
• Virtual Machines
• AKS
• Container Registry
• SQL DB
• Cosmos DB
• API Management
• Automation Account
• Management Groups
• Log analytics
• Resource Health Alerts
• App Gateway
• Express Route Gateway
• Firewall
• Front Door
• Load Balancer
• Public IP (also missing Impact column)
• Traffic Manager
• Virtual Networks (also missing Impact column)
• VPN Gateway
• WAF
• Key Vault
• AVD (Design area column should be renamed to Category in table)
• AVS (Design area column should be renamed to Category in table)
• Storage Account
• App Service Plan
• Web App

To Reproduce

Steps to reproduce the behaviour:

1. Go to the following service pages listed above and you will see that there is either no Category column in the table or in the recommendation details.

Expected behaviour

Please correct by adjusting service recommendation pages in accordance with the following template

Screenshots 📷

Incorrect (missing Category in both table and recommendation details):

Correct:

Additional context

Anything else we should know to help us troubleshoot this bug?

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behaviour:

1. For VM-7, the query returns incorrect results by returning virtual machines that are protected by Azure backup.

Note: I've noticed that with Read Access, the backup status within the VM capabilities view shows as in an Error state:

In order to determine whether a virtual machine is being backed up, I have been using the Backup Center feature within the Azure Portal.

Expected behaviour

The query should return a list of virtual machines that have backups configured even if the person running the query has read-only access.

Screenshots 📷

If applicable, add screenshots to help explain your problem. Please feel free to blur/cover any sensitive information.

Additional context

Anything else we should know to help us troubleshoot this bug?

Describe the bug

KQL query for ST-3 flags Premium storage accounts for lack of the access tier while there is no access tier setting available for Premium storage accounts and therefore I consider it to be a bug.

To Reproduce

Steps to reproduce the behaviour:

Run KQL query gains Azure Storage Account - Premium tier.

resources
| where type =~'microsoft.storage/storageaccounts'
| where isnull(properties.accessTier)
| project recommendationId = 'st-3', name, id, param1="not defined - GeneralPurpose V1"

Expected behaviour

Only STs of displayed tier without access tier specified (GPv1) should be displayed.

Question/Feedback

NSG-1 talk about NSGs or all Azure resources?

https://azure.github.io/Azure-Proactive-Resiliency-Library/services/networking/network-security-group/#nsg-1---configure-diagnostic-settings-for-all-azure-resources

NSG-1 - Configure Diagnostic Settings for all Azure Resources

Possible Answers/Solutions?

If NSG-1 is about NSG, it needs to fix the title to NSG-1 - Configure Diagnostic Settings for all network security groups.
If NSG-1 talk about all Azure resources, this recommendation should move to another category. General is better, I think.

Describe the solution you'd like

Guidance to help customers migrate from legacy Azure Databrick workspaces.

Additional context

Azure Databricks shares control plane across multiple regions. As these regions launch their own control plane, we need to help customers migrate their workspaces so that they can benefit from in-region control plane and don't have an indirect dependency on outages from another region.

Question/Feedback

All recommendations should have a folder and KQL file, even if it is still under development.

Possible Answers/Solutions?

Helps with standardization and lets people know that queries are being actively developed.

Describe the bug

The VM-10 query returns false positive result in the following situation because the query is matched NICs by the name. It should use resource ID instead of name to get stabilized result.

There are NICs that have the same name and they are in different resource groups:

• rg1
  • nic5678: Accelerated networking Off
• rg2
  • nic5678: Accelerated networking On

To Reproduce

1. Setup to the following situation.

   • rg1
     • nic5678: Accelerated networking Off
   • rg2
     • nic5678: Accelerated networking On

2. Run the VM-10 query.

Expected behavior

• VM-10 query returns correct result.
  • The query should use the resource ID of NIC instead of name to match.

Screenshots 📷

There are two NICs that have the same name and they are in different resource groups. The first NIC's accelerated networking is disabled, the second NIC's accelerated networking is enabled.

The VM-10 query returns both NICs as disabled accelerated networking even though one is enabled.

Additional context

• None

Describe the solution you'd like

Guidance for customers to select multiple VM SKUs for their Databricks jobs.

Additional context

Databricks uses regional VMs when launching job clusters. These clusters can be impacted when there are capacity constraints in a region or availability zone. To ensure customers can run their Databricks jobs consistently, they should plan and verify their VM SKUs so that they can quickly switch between them if there is capacity constraints.