Monitor disable parameters

docs/content/patterns/alz/Disabling-Policies.md

@@ -92,11 +92,15 @@ The PolicyEffect parameter is used for the configuration of the effect of the Po
 
 ## MonitorDisable parameter
 
-It´s also possible to exclude certain resources from being monitored. You may not want to monitor pre-production or dev environments. The MonitorDisable parameter contains the Tag name to determine whether a resource should be included. By default, creating the tag MonitorDisable with value "true" will prevent deployment of alert rules on those resources. This is easily adjusted to use existing tags, for example you could configure the parameter with the tag name "Environment" and tell it to deploy only if the tag value equals "prod", or when the tag isnt equal to "dev". Currently only the tag name is a parameter, other changes require minor changes in the code.
+It´s also possible to exclude certain resources from being monitored. You may not want to monitor pre-production or dev environments. The MonitorDisable parameter contains the tag name and tag value to determine whether a resource should be included. By default, creating the tag MonitorDisable with value "true" will prevent deployment of alert rules on those resources. This can be easily adjusted to use existing tags and tag values. For example you could configure the parameters with the tag name ***Environment*** and tag value of ***Production*** or ***Test*** or ***Sandbox*** or all of them to exclude resources in these environments (see the sample parameter screenshot).
+
+![MonitorDisable* parameters](../media/MonitorDisableParams.png)
+
+This will deploy policy definitions which will only be evaluated and remediated if the tag value(s) are not included in the list you provided.
 
 ### How it works
 
-The policyRule only continues if "allOff" is true. Meaning, the deployment will continue as long as the MonitorDisable tag doesn't exist or doesn't hold the value "true". When the tag holds "true", the "allOff" will return "false" as "notEquals": "true" is no longer satisfied, causing the deployment to stop
+The policyRule only continues if "allOff" is true. Meaning, the deployment will continue as long as the MonitorDisableTagName tag doesn't exist or doesn't hold the any of the values listed in the MonitorDisableTagValues parameter. When the tag holds one of the configured values, the "allOff" will return "false" as *"notIn": "[[parameters('MonitorDisableTagValues')]"* is no longer satisfied, causing the evaluation and hence the remediation to stop.
 
 ```json
     "policyRule": {
@@ -107,9 +111,14 @@ The policyRule only continues if "allOff" is true. Meaning, the deployment will
             "equals": "Microsoft.Automation/automationAccounts"
           },
           {
-            "field": "[[concat('tags[', parameters('MonitorDisable'), ']')]",
-            "notEquals": "true"
+            "field": "[[concat('tags[', parameters('MonitorDisableTagName'), ']')]",
+            "notIn": "[[parameters('MonitorDisableTagValues')]"
           }
         ]
-      }
+      },
 ```
+
+Given the different resource scope that this method can be applied to, we made it working a little bit different when it comes to log-based alerts. For instance, the virtual machine alerts are scoped to subscription and tagging the subcription would result in disabling all the policies targeted at it.
+For this reason, and thanks to the new **Bring Your Own User Assigned Managed Identity (BYO UAMI)*** included in the [2024-06-05](../../Whats-New#2024-06-05) release and to the ability to query Azure resource Graph using Azure Monitor (see [Quickstart: Create alerts with Azure Resource Graph and Log Analytics](https://learn.microsoft.com/en-us/azure/governance/resource-graph/alerts-query-quickstart?tabs=azure-resource-graph)), it is now possible to disable individual alerts for both Azure and hybrid virtual machines after they are created. We got requests to stop alerting fro virtual machines that were off for maintenance and this enhancement came up just in time.
+
+Should you need to disable the alerts for your virtual machines after they are created, just make sure you tag the relevant resources accordingly. The alert queries have been modified to look at resource properties in [Azure Resource Graph](https://learn.microsoft.com/en-us/azure/governance/resource-graph/overview). If the resource contains the given tag name and tag value, it is made part of an exclusion list, so alerts will not be generated for them. This behavior allows you to dinamically and rapidly exclude the necessary resources from being alerted without the need of deleteing the alert, tag the resource and run the remediation again.

docs/content/patterns/alz/Monitoring-and-Alerting.md

@@ -16,7 +16,7 @@ With a **centralized** approach to alerting a central Action Group is used for a
 
 Metric alerts are deployed with resources (same resource group) and platform alerts like Service Health / Activity are created in a dedicated resource group, in a subscription typically located in the Management platform management group. A single Alert Action Group in a subscription in the Management platform management group is configured with a central alerting email address, and Alert Processing Rules enabling filters and connecting alerts to the Alert Action Group.
 
-As an example in the context of ALZ, a single centralized action group is deployed in the "AlzMonitoring-RG" resource group in a subscription in the Management platform management group.
+As an example in the context of ALZ, a single centralized action group is deployed in the "rg-amba-monitoring-001" resource group in a subscription in the Management platform management group.
 
 ### Decentralized
 

docs/content/patterns/alz/UpdateToNewReleases/Update_from_release_2024-06-05.md

@@ -0,0 +1,55 @@
+---
+title: Updating from release 2024-06-05
+geekdocCollapseSection: true
+weight: 97
+---
+{{< hint type=Important >}}
+***Updating to release from release [2024-06-05](../../Whats-New#2024-06-05) or from previous releases, contains a breaking change. To perform the update, it's required to remove previously deployed policy definitions, policy set definitions, policy assignments and role assignments. As part of this release we made a script available to clean all the necessary items. <ins>***It's strongly recommended that you test the script thoroughly before running on production environment. It isn't necessary to remove alert definitions that will continue to work in the meantime.***</ins>
+{{< /hint >}}
+
+# Pre update actions
+
+Before updating to release [2024-06-30](../../Whats-New#2024-06-30), it's required to remove existing policy definitions, policy set definitions, policy assignments and role assignments. This action is required because of a breaking change caused by the redefinition of some parameters, which allows for more flexibility in disabling the policy remediation or, in some cases, the alerts. Unfortunately not all the alerts can be disabled after creation; only log-based alerts can be. Even if disabling the effect of policy was already possible in AMBA-ALZ, with this release we made sure that all the policies will honor both the ***PolicyEffect*** and the ***MonitorDisable*** parameters.
+
+In particular, the *MonitorDisable* feature has been redesigned to allow customer to specify they own existing tag and tag value instead of forcing a hard coded one. Given the ALZ guidance and the best practice of having a consistent tagging definition, it's only allowed to one parameter name fo r the entire deployment. Instead, parameter value can be different. You can specify an array of values assigned to the same parameter. For instance, you have the ```Environment``` tag name consistently applied to several environments, saying ```Production```, ```Test```, ```Sandbox```, and so on and you want to disable alerts for resources, which are in both ```Test``` and ```Sandbox```. Now it's possible by just configuring the parameters for tag name and tag values as reported in the sample screenshot (these are the default values) below:
+
+![MonitorDisable* parameters](../../media/MonitorDisableParams.png)
+
+Complete description of this new/redesigned feature can be found in the [MonitorDisable parameter](../../Disabling-Policies#monitordisable-parameter) paragraph inside the [Disabling Policies](../../Disabling-Policies) page.
+
+Once the policy definitions, policy set definitions, policy assignments and role assignments are removed and the deployment is completed, the execution of [Policy remediation](../../deploy/Remediate-Policies) will ensure that the new alerts will be created accordingly.
+
+To run the script, complete the following steps:
+
+  1. Open PowerShell
+  2. Install the **Az.ResourceGraph** module: `Install-Module Az.ResourceGraph` (if not present)
+  3. Change directories to the location of the **Start-AMBAPolicyInitiativesAndAssignmentsCleanup.ps1** script
+  4. Configure the ***$pseudoRootManagementGroup*** variable using the following command:
+
+  ```powershell
+  $pseudoRootManagementGroup = "The pseudo root management group id parenting the identity, management and connectivity management groups"
+  ```
+
+  1. Sign in to the Azure with the `Connect-AzAccount` command. The account you sign in as needs to have permissions to remove policy definitions, policy set definitions, policy assignments and role assignments at the desired Management Group scope.
+
+  2. Execute the script using one of the following options:
+
+  {{% include "PowerShell-ExecutionPolicy.md" %}}
+
+  **Generate a list of policy definitions, policy set definitions, policy assignments and role assignments resources which would be deleted by this script:**
+
+  ```powershell
+  ./Start-AMBAPolicyInitiativesAndAssignmentsCleanup.ps1 -pseudoRootManagementGroup $pseudoRootManagementGroup -ReportOnly
+  ```
+
+  **Show output of what would happen if deletes executed:**
+
+  ```powershell
+  ./Start-AMBAPolicyInitiativesAndAssignmentsCleanup.ps1 -pseudoRootManagementGroup $pseudoRootManagementGroup -WhatIf
+  ```
+
+  **Delete policy definitions, policy set definitions, policy assignments and role assignments resources deployed by the AMBA-ALZ pattern without prompting for confirmation:**
+
+  ```powershell
+  ./Start-AMBAPolicyInitiativesAndAssignmentsCleanup.ps1 -pseudoRootManagementGroup $pseudoRootManagementGroup -Force
+  ```