removing contracted forms

docs/content/patterns/alz/Cleaning-up-a-Deployment.md

@@ -15,17 +15,17 @@ In some scenarios, it might be necessary to remove everything deployed by the AM
 - Action Groups
 - Alert Processing Rules
 
-All resources deployed as part of the initial AMBA-ALZ deployment and the resources created dynamically by 'deploy if not exist' policies are either tagged, marked in metadata, or in description (depending on what the resource supports) with the value `_deployed_by_amba` or `_deployed_by_amba=True`. This metadata is used to execute the cleanup of deployed resources; _if it has been removed or modified the cleanup script won't include those resources_.
+All resources deployed as part of the initial AMBA-ALZ deployment and the resources created dynamically by 'deploy if not exist' policies are either tagged, marked in metadata, or in description (depending on what the resource supports) with the value `_deployed_by_amba` or `_deployed_by_amba=True`. This metadata is used to execute the cleanup of deployed resources; _if it has been removed or modified the cleanup script will not include those resources_.
 
 ## Cleanup Script Execution
 
 {{< hint type=Important >}}
-It's highly recommended to **thoroughly** test the script before running on production environments. The sample scripts aren't supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
+It is highly recommended to **thoroughly** test the script before running on production environments. The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
 {{< /hint >}}
 
 ### Download the script file
 
-Execute the following instructions to download the cleanup script file. Alternatively, clone the repo from GitHub and ensure you're working from the latest version of the file by fetching the latest `main` branch.
+Execute the following instructions to download the cleanup script file. Alternatively, clone the repo from GitHub and ensure you are working from the latest version of the file by fetching the latest `main` branch.
 
 1. Navigate the AMBA [project in GitHub](https://github.com/Azure/azure-monitor-baseline-alerts)
 2. In the folder structure, browse to the `patterns/alz/scripts` directory

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

@@ -12,7 +12,7 @@ The policies included in AMBA-ALZ provide multiple methods to enable or disable
 
 ## AlertState parameter
 
-Recognizing that it isn't always possible to test alerts in a dev/test environment, we have introduced the AlertState parameter for all metric alerts (in the initiatives and the example parameter file the parameter is named combining {resourceType}, {metricName} and AlertState, for example VnetGwTunnelIngressAlertState). This is to address a scenario where an alert storm occurs and it's necessary to disable one or more alerts deployed via policies through a controlled process. This could be considered for a roll-back process as part of a change request.
+Recognizing that it is not always possible to test alerts in a dev/test environment, we have introduced the AlertState parameter for all metric alerts (in the initiatives and the example parameter file the parameter is named combining {resourceType}, {metricName} and AlertState, for example VnetGwTunnelIngressAlertState). This is to address a scenario where an alert storm occurs and it is necessary to disable one or more alerts deployed via policies through a controlled process. This could be considered for a roll-back process as part of a change request.
 
 ### Allowed values
 
@@ -46,7 +46,7 @@ The AlertState parameter is used for both compliance evaluation and configuratio
 }
 ```
 
-If "allOf" evaluates to true, the effect is satisfied and doesn't trigger the deployment. If you have implemented the alert rules before and want to disable an alert rule you can change the Alert State to "false", this will cause "allOf" to evaluate as false, which will trigger the deployment that changes the "enabled" property of the alert rule to false.
+If "allOf" evaluates to true, the effect is satisfied and does not trigger the deployment. If you have implemented the alert rules before and want to disable an alert rule you can change the Alert State to "false", this will cause "allOf" to evaluate as false, which will trigger the deployment that changes the "enabled" property of the alert rule to false.
 
 ### Deployment steps
 
@@ -56,7 +56,7 @@ These are the high-level steps that would need to take place:
 2. Deploy the policies and assignments as described previously.
 3. Once the deployment is completed successfully and the policy evaluation is finished, there will be many non-compliant policies and resources depending on which alerts were to be disabled. These non-compliant resources need to be remediated which can be done either through the portal, on a policy-by-policy basis or you can run the script found in [patterns/alz/scripts/Start-AMBARemediation](https://github.com/Azure/azure-monitor-baseline-alerts/blob/main/patterns/alz/scripts/Start-AMBARemediation.ps1) to remediate all ALZ-Monitor policies in scope as defined by management group pre-fix.
 
-Note that the preceding approach won't delete the alerts objects in Azure, merely disable them. To delete the alerts, you will have to do so manually. Also note that while you can engage the PolicyEffect to avoid deploying new alerts, you shouldn't do so until you have successfully remediated what was mentioned earlier. Otherwise the policy will be disabled, and you won't be able to turn off alerts via policy until that is changed back.
+Note that the preceding approach will not delete the alerts objects in Azure, merely disable them. To delete the alerts, you will have to do so manually. Also note that while you can engage the PolicyEffect to avoid deploying new alerts, you should not do so until you have successfully remediated what was mentioned earlier. Otherwise the policy will be disabled, and you will not be able to turn off alerts via policy until that is changed back.
 
 ## PolicyEffect parameter
 
@@ -66,7 +66,7 @@ The default is intended to provide a well-balanced baseline. However you may wan
 ### Allowed values
 
 - "deployIfNotExists" - Policy will deploy the alert rule if the conditions are met. (Default for most Policies)
-- "disabled" - The policy itself will be created but won't create the corresponding Alert rule.
+- "disabled" - The policy itself will be created but will not create the corresponding Alert rule.
 
 ### How it works
 
@@ -96,11 +96,11 @@ It´s also possible to exclude certain resources from being monitored. You may n
 
 ![MonitorDisable* parameters](../media/MonitorDisableParams.png)
 
-This will deploy policy definitions which will only be evaluated and remediated if the tag value(s) aren't included in the list you provided.
+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 MonitorDisableTagName tag doesn't exist or doesn't hold 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.
+The policyRule only continues if "allOff" is true. Meaning, the deployment will continue as long as the MonitorDisableTagName tag does not exist or does not hold 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": {
@@ -119,6 +119,6 @@ The policyRule only continues if "allOff" is true. Meaning, the deployment will
 ```
 
 Given the different resource scope that this method can be applied to, we made it working slightly different when it comes to log-based alerts. For instance, the virtual machine alerts are scoped to subscription and tagging the subscription 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's now possible to disable individual alerts for both Azure and hybrid virtual machines after they're created. We got requests to stop alerting fro virtual machines that were off for maintenance and this enhancement came up just in time.
+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 from 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're 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's made part of an exclusion list, so alerts won't be generated for them. This behavior allows you to dynamically and rapidly exclude the necessary resources from being alerted without the need of deleting the alert, tag the resource and run the remediation again.
+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 dynamically and rapidly exclude the necessary resources from being alerted without the need of deleting the alert, tag the resource and run the remediation again.

docs/content/patterns/alz/deploy/Remediate-Policies.md

@@ -3,8 +3,8 @@ title: Remediate Policies
 weight: 80
 ---
 
-The policies are all deploy-if-not-exists, by default, meaning that any new deployments will be influenced by them. Therefore, if you're deploying in a green field scenario and will afterwards be deploying any of the covered resource types, including subscriptions, then the policies will take effect and the relevant alert rules, action groups and alert processing rules will be created.
-If you are in a brownfield scenario on the other hand, policies will be reporting non-compliance for resources in scope, but to remediate non-compliant resources you'll need to initiate remediation. This can be done either through the portal, on a policy-by-policy basis or you can run the *Start-AMBARemediation.ps1* script located in the *.\patterns\alz\scripts* folder to remediate all AMBA-ALZ policies in scope as defined by management group pre-fix.
+The policies are all deploy-if-not-exists, by default, meaning that any new deployments will be influenced by them. Therefore, if you are deploying in a green field scenario and will afterwards be deploying any of the covered resource types, including subscriptions, then the policies will take effect and the relevant alert rules, action groups and alert processing rules will be created.
+If you are in a brownfield scenario on the other hand, policies will be reporting non-compliance for resources in scope, but to remediate non-compliant resources you will need to initiate remediation. This can be done either through the portal, on a policy-by-policy basis or you can run the *Start-AMBARemediation.ps1* script located in the *.\patterns\alz\scripts* folder to remediate all AMBA-ALZ policies in scope as defined by management group pre-fix.
 
 {{< hint type=Important >}}
 This script requires PowerShell 7.0 or higher and the following PowerShell modules: