💡
You can choose your own names, but in such case, you will have to modify parameters when calling my Export-VariableToStorage and Import-VariableFromStorage functions
### Grant Runbook Managed Identity permissions to the Azure Storage Account container
Grant our Managed Identity `Storage Blob Data Contributor` IAM role over Storage Account container created in the previous step. So it can modify files in this container.
## Create Azure KeyVault for storing SendGrid API key
For sending emails via SendGrid I am using my function `Send-EmailViaSendGrid`. This function supports retrieval of the SendGrid API key directly from Azure KeyVault, which is an ideal solution for Azure Automations.
The only thing you have to do is to create such a secret in the existing KeyVault (or some newly created one) and set `$sendGridParam` hashtable values accordingly in your Runbook code.
### Grant Runbook Managed Identity permissions to read stored SendGrid token
Grant our Managed Identity `Key Vault Secrets User` IAM role over the created secret to allow it to read it.
---
# Gotchas
* Defender vulnerability report doesn't have to be 100% accurate, because if app is incorrectly uninstalled therefore some registry keys or files remain on the device disk, Defender can still detect it even though the app isn't installed. In such rare cases, you need to manually remove some leftovers.
* If you use MDT for software installation, apps are installed under a built-in administrator account, which can lead to situations where the vulnerable app is detected in the built-in administrator profile/registry! This can be a significant problem for your users because it can be hard for them to remove such leftover data.
* This can be solved by removing the built-in admin profile (not the account, just the profile data). For example, using Intune remediation script and PSH code
```powershell
Get-CimInstance -Class Win32_UserProfile | ? { $_.SID -like "*-500" } | Remove-CimInstance
```
---
# Tips
* **Inform your users** about those notifications beforehand! So they don't consider them as a scam 😀
* You can **exclude the specific application** from this notification automation, for example, because it is the last existing version, so your users cannot update it anyway
* Just update the `$exclusionList` variable in the automation code
```powershell
<#
- 'CveId' and/or 'ProductName' property/ies (string) have to be defined
- 'ProductVersion' (string) is optional
- property values can be extracted from $vulnerabilityPerMachine.vulnswdata
- 'ValidUntil' (datetime) is optional (since this date, exclustion will be ignored)
- BEWARE that in Azure pipeline EN date has to be used a.k.a. month.day.year!!!
#>
$exclusionList = @(
[PSCustomObject]@{
CveId = 'CVE-2024-32002'
ProductName = 'visual_studio_2022'
ValidUntil = (Get-Date 8.1.2024) # M.d.yyyy
}
)
```
* Check [this article](https://doitpshway.com/gradual-update-of-all-applications-using-winget-and-custom-azure-ring-groups) if you want to update all installed applications gradually using Winget
* exceptions can be made
* If your helpdesk interactively logs in to employees' computers, you can avoid identifying such accounts as device owners by altering the following line of code in the runbook
* ```powershell
$user = Get-M365DefenderMachineUser -header $header -machineId $machineId | ? { $_.logonTypes -like '*Interactive*' -and $_.accountName -ne "administrator" }
```