Windows Defender Exploit Guard should be enabled on machines

There are recommendations for improving security inside Microsoft Defender for Cloud for cloud. There is a list of tasks in the regulatory compliance area.

One of them is "Windows Defender Exploit Guard should be enabled on machines" which is advised to be resolved by the "Trigger logic app". That offer is the biggest SCAM Microsoft did to me in a long time.

 

The app must be manually created as consumption-based and I couldn't even find documentation, so I created a ticket to MS support. Both Security and LogicApp teams provided me with the answer that it's not their responsibility. That answer took like a week. The final suggestion is that if I want to do it with the logic app I must configure it fully by myself.

 

 

The only valid answer I was able to get was to look in detail for section "Remediation steps, Manual remediation: 1. Enable controlled folder access.".

 

Thank you for false advices!

Azure Windows Server 2022 image name

It was surprisingly complicated to find the correct version of the Windows Server 2022 image name or so call offer ID.

The version of Windows Server 2022 for use in Azure has id:

MicrosoftWindowsServer:WindowsServer:2022-datacenter-azure-edition:latest

The version of Windows Server 2022 with SQL 2022 has id:

MicrosoftSQLServer:sql2022-ws2022:standard-gen2:latest

The version of Windows Server 2022 with SQL 2019 has id:

MicrosoftSQLServer:sql2019-ws2022:standard:latest

 

How to find more codes of Offer / Publisher / Sku / Urn / UrnAliasidentification? Answer is via Azure CloudShell by an az-cli command

az vm image list --location <location> --subscription <subscriptionId> -o table --publisher MicrosoftWindowsServer --all > allMs.txt

az vm image list --location <location> --subscription <subscriptionId> -o table --publisher microsoftsqlserver --all > allMsSql.txt

Note: you can't see WS2022 in default view of az vm image list without "-all" so far (1/2022).

And the tricky part is you can also deploy the new WS2022 via Azure Portal where you can find deployment URN in Template.json. Those look similar but aren't the same.

MicrosoftWindowsServer.WindowsServer2022-datacenter-azure-edition:latest

MicrosoftSQLServer.sql2019-ws2022sqldev:latest

Using MarketPlaceOfferId in Az-cli (az vm create command) will cause following error message

ERROR: (ResourceNotFound) The Resource 'Microsoft.Compute/images/microsoftsqlserver.sql2019-ws2022sqldev' under resource group '<resourceGroup>' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix

Figure this out took me an unnecessarily long, so hopefully, you can be faster with my help.

Azure vm set tempdb location

It is possible to configure location for temporary databases internally used by SQL server to specified location during server deployment imperatively via Az cli. I realized that not all newly created VMs have that item available in JSON representation even GUI of Azure Portal is reporting some value.

Read query

az vm show --name <VMname> --resource-group <RG> --query resources[0].settings.ServerConfigurationsManagementSettings.SQLStorageUpdateSettingsV2.SQLTempDbSettings.DefaultFilePath -o tsv

Write command

az sql vm update --name <VMname> --resource-group <RG> --set resources[0].settings.ServerConfigurationsManagementSettings.SQLStorageUpdateSettingsV2.SQLTempDbSettings='{"DefaultFilePath":"D:\\SQLTemp"}' -o none

Some more configuration option

• SQLStorageSettings
• diskConfigurationType:"NEW"
• SQLTempDbSettings
• .defaultFilePath:"<path>"
• .storageWorkloadType:"OLTP"
• SQLLogSettings
• .defaultFilePath
• .luns
• SQLDataSettings
• .defaultFilePath:"F:\\data"
• .luns

I spotted that some VMs created from the image is not having the option available for reading TempDB location under ServerConfigurationsManagementSettings. It was possible to change basic SQLDataSettings and SQLLogSettings via RDP or SMSS tool but even that configuration didn't propagate to Azure. That happened because pre-prerequisites are not met.

 

Conditions to fulfill: There is an installed VM extension SqlIaasExtension and its state is deployed (visible via Portal). The second crucial condition isis that local user NT service\SQLIaasExtension has granted admin rights within the host. Last but not least the target location where is placed the defaultFilePath must be accessible for read/write/modify for a non-admin account or granted these rights for NT Service\MSSQLSERVER or granted local admin to that user as a whole.

 

It is easy to break SqlIaasExtension agent installation to get stuck in "provisioning" and then "failed" state. I have to discover the solution still to finish this tutorial.

Failed to connect to Windows Admin Center

I have additional troubles with connection to Windows Admin Center (preview) in Azure Portal from IIS webserver since the error message keeps following.

Failed to connect to Windows Admin Center.

What I was diagnosing? Here is a list of steps to analyze. You might be still unsuccessful as same as me.

• Extenstion "Microsoft.AdminCenter.AdminCenter" installed
• Network security group opening in Azure Portal "PortForWAC"
  
• from my IP address
• from Any IP address (or ServiceTag Internet) for diagnose
  
• use "Connection troubleshoot" available in Azure
  
• Azure VM window tab "Support + troubleshooting "
  
• Local Firewall opening on the target virtual machine
• disabling the whole firewall 
• More network tests
  
• Invoke-RestMethod -Method GET -Uri https://wac.azure.com
• Test-NetConnection -Port 6516 -ComputerName localhost -InformationLevel Detailed
  
• Testing availability on https://localhost:6516 on the target VM via web browser
  
• skip certitificate error (reason)
• Message: Please use the Azure portal. Windows Admin Center for Azure virtual machines must be accessed through the Azure portal. 
• Check running service DisplayName "Windows Admin Center" and name SmeExperience
  
• Testing  availability on https://<publicIp>:6516
• check similar guide
  
• Check local machine eventvwr
• Event Viewer => Applications and Services Logs => Microsoft-ServerManagementExperience
  
• Azure VM Extension "Microsoft.AdminCenter.AdminCenter"
  
• check link "View detailed status" after clicking to AdminCenter
  
• Reinstalling Azure extension Microsoft.AdminCenter.AdminCenter
• I even tried to install normal WAC, but installator reported that "A newer version of Windows Admin Center is already installed"
• target machine has not WinRm configured for listening on port 6516
•  list with command: winrm enum winrm/config/listener

So all operation are blocked on that failure from Azure side to connect without additional information. Since feature is in a preview there is no option to really complain about the service. 

There is also question how much is result affected by my "custom image"  which was reported to me.

It looks like your VM is running from a custom image. Thus, we cannot guarantee that Windows Admin Center will work on your particular VM. Windows Admin Center supports VMs running Windows Server 2016 or higher.

At that point, server was installed as Microsoft Hyper-V Server 2016 Version 1607 (Build 14393.4651), so technically quite old version even with old updates.

I think the reason for the failure might be that server is IIS so a port of WAC service is not listening on the public interface or so.

Registry settings “\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManagementGateway”

• CorsOrigins
• https://ms.portal.azure.com,
• https://portal.azure.com,
• https://preview.portal.azure.com,
• https://waconazure.com
• CSPFrameAncestors
• https://*.hosting.portal.azure.net,
• https://localhost:1340,
• https://ms.portal.azure.com,
• https://portal.azure.com,
• https://preview.portal.azure.com
  

Microsoft manuals

• troubleshooting guide

Here is not ready answer for making the service work, but it might to help you with the troubleshooting. I will appreciate new ideas in comments too.

Azure VM agent is missing or not responding

I realized that one of my virtual machines is not correctly added to Microsoft Azure Automation Account Update Management. There was some problem with former membership to different WorkspaceId which prevented Portal wizard to add that machine update list. What to do? 

First the original error message

Error message in Updates(loganalytics) | Virtual machines
VM agent is missing or not responding. 

In this case, I knew what is the source of the problem since the original connected LogAnalytics object was deleted without unregistering the MicrosoftMonitoringAgent used on the virtual machine.

Second step check what configuration you have in your target VM 

az vm show --name <VMname> -g <ResourceGroupName> --query resources[].settings

Let's be more exast about value we are looing. Here you can extract path of Log Analytics Id

az vm show --name <VMname> -g <ResourceGroupName> --query resources[].settings.workspaceId

There I was able to see Id which was not correct. Do a cross-check with some properly configured Virtual machine to find the right value. 

Thirds step: We are going to replace that Id with a new one. VM is still operational during the action.
I realized that replacing the value removed the whole section resources from VM configuration which was not working anyway.

az vm update --name <VMname> -g <ResourceGroupName> --set resources[0].settings.workspaceId='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

Result check:
az vm show --name <VMname> -g <ResourceGroupName>

Forth step: Navigate in Azure Portal to Solution object which is called Updates(<Log Analytics Workspace Name>) click in the right column on the option Workspace Data Sources => Virtual machines, click on affected VM, and click to "Connect". All troubles should be resolved by that.

Result check:
az vm show --name <VMname> -g <ResourceGroupName> --query resources[].settings

You might also experience the error message "Agent has a problem" which I have still under investigation, but a general solution might require a reboot or even deallocation of the server. TBC...

Workaround to keep data collection working even when there is a problem with Agent: Install "desktop" software tool for Windows called Microsof Monitoring Agent (MMA) and link it with keys to LogAnalytics. Available also for linux.

Azure Application Gateway change subnet

It is possible to change subnet in which is azure application gateway running without need to delete the whole instance and do all configuration from the beggining. It would be faster with recreation than going via process described below. This require quite long service break. I had reserved 2 hours and with little bit of trial-and-fix I managed to fit in.

  

Web UI way

Step 1 set application gateway to be manually scaled.

Step 2 stop application gateway via console command "az network application-gateway stop"

wait to proceeed

Step 3 open appgw page in portal.azure.com

modify URL from

https://portal.azure.com/#@CUSTOMER.onmicrosoft.com/resource/subscriptions/SUBSCRIPTIONID/resourceGroups/RESOURCEGROUP/providers/Microsoft.Network/applicationGateways/APPLICATIONGATEWAY/overview

modify URL to

https://resources.azure.com/#@CUSTOMER.onmicrosoft.com/resource/subscriptions/SUBSCRIPTIONID/resourceGroups/RESOURCEGROUP/providers/Microsoft.Network/applicationGateways/APPLICATIONGATEWAY

Step 4 open modified page

Step 5 click get and search in page "subnet". We are going to modify this value only.

Step 6 switch to read/write mode on top of the page

Step 7 click on button edit

Step 8 find again "subnet" and modify name or path to subnet which you want to use

Step 9 click press PUT and wait for green tick on the screen

Step 10 if there is an orange warning, scroll to bottom of the page and there is additional text area explaining what is causing problem. Fix it and repeat.

Step 11 wait till update is done. There is no need to start application gateway again, because update will start it.

Azure Cloud Shell

Alternatively it's possible to do it with commands via Azure cloud shell or similar.

Check settings

az network application-gateway show --subscription <SUBSCRIPTIONID> --resource-group <RESOURCEGROUP> --name <APPLICATIONGATEWAY> --query gatewayIpConfigurations

Stop AppGw

az network application-gateway stop --subscription <SUBSCRIPTIONID> --resource-group <RESOURCEGROUP> --name <APPLICATIONGATEWAY>

Get JSON 

az network application-gateway show --subscription <SUBSCRIPTIONID> --resource-group <RESOURCEGROUP> --name <APPLICATIONGATEWAY> --output json

Prepare JSON by modify the value of subnet. Next stop shrink it to one line (visual studio code and shift+tab) and put as one liner. 

Post it

az network application-gateway update --subscription <SUBSCRIPTIONID> --resource-group <RESOURCEGROUP> --name  <APPLICATIONGATEWAY> --set gatewayIpConfigurations[0].subnet.id='[{"id": "/subscriptions/<SUBSCRIPTIONID>/resourceGroups/<RESOURCEGROUP>/providers/Microsoft.Network/applicationGateways/ <APPLICATIONGATEWAY>/gatewayIPConfigurations/appGatewayFrontendIP","name": "appGatewayFrontendIP","provisioningState": "Succeeded","resourceGroup": "<RESOURCEGROUP>","subnet": {"id": "/subscriptions/<SUBSCRIPTIONID>/resourceGroups/<RESOURCEGROUP>/providers/Microsoft.Network/virtualNetworks/<VNET>/subnets/<SUBNET>","resourceGroup": "<RESOURCEGROUP>"},"type": "Microsoft.Network/applicationGateways/gatewayIPConfigurations"}]'

Start

az network application-gateway start --subscription <SUBSCRIPTIONID> --resource-group <RESOURCEGROUP> --name <APPLICATIONGATEWAY>

Beware

There is some leftover network device after application gateway migration, so you cannot easily delete subnet you used for migration. See output of trial of deleting that subnet:

az network vnet subnet delete --ids /subscriptions/<SUBSCRIPTIONID>/resourceGroups/<RESOURCEGROUP>/providers/Microsoft.Network/virtualNetworks/<VNET>/subnets/<SUBNET>

(InUseSubnetCannotBeDeleted) Subnet <SUBNET> is in use by subscriptions/<SUBSCRIPTIONID>/resourceGroups/<WEIRDRESOURCEGROUPARMRG>/providers/Microsoft.Network/networkInterfaces/|providers|Microsoft.Compute|virtualMachineScaleSets|appgw|virtualMachines|1|networkInterfaces|custnic and cannot be deleted. In order to delete the subnet, delete all the resources within the subnet. See aka.ms/deletesubnet.

This I could resolve without help of Microsoft Support, so I created a ticket. Here is solution summary:

It was due to an error i.e. when the App GW was moved to other subnet from these subnet it was not completely removed in the backend due to which you were not able to delete the subnet   

• Initially I informed you that all the delegations and the service endpoints need to be removed before proceeding with the deletion of the subnet.
• You confirmed that you removed all the delegations and the service endpoints and I could see the same from my end that they got removed.
• I suggested you to try the deletion again but the deletion still kept failing.
• I asked for the error messages that you were receiving for reference.
• Upon further troubleshooting we could see that the traces of Network Interface card of the AppGW that was previously present in those subnet were not deleted properly in the backend.
• We engaged the backend team to do a manual cleanup of the traces left.
• PG team completed the manual cleanup after which I requested you to try the deletion again and you confirmed that the deletion was successful.
• You informed us that the ticket can be archived. 

It was quite exhausing process in the end, but thankfully working even it took several days to close it.

Azure WAF set Custom rule Header name

WAF_v2 in Azure's Application Gateway is quite strong tool how to work with incoming traffic on web app. I had to do some exception on traffic filtering based on HTTP headers and use AZ CLI for that.

Structure of work is following: Application Gateway WAF policy set Match variable RequestHeaders correct Header name. There is no direct command under creation sequence of az network application-gateway waf-policy custom-rule create AND az network application-gateway waf-policy custom-rule match-condition add.

You can check existing settings with get command:

az network application-gateway waf-policy custom-rule show --name <RULE_NAME> --policy-name <WAF_NAME> -g <RG> --query matchConditions[].matchVariables -o tsv

To do a change you need to use following set command:

az network application-gateway waf-policy custom-rule update --name <RULE_NAME> --policy-name <WAF_NAME> --set matchConditions[0].matchVariables[0].selector=Referer

After that review the change again and that's all.

Azure VM start failure KeyVault does not exist

Long time ago I migrated Azure virtual machine from classic model to ARM and later cleaned leftover items like machine specific Key Vault object. I didn't notify reference in current configuration, so one day I deallocated the VM I got error message.

Start VM 'Failed' - Provisioning Failed, Key Vault Does Not Exist

I couldn't recognize the problem, so I went to resources.azure.com and there under osProfile found reference to my deleted keyvault. 

My first (and wrong) idea was to change that value to some random and existing keyvault, so I collect original values by command

az vm show -g <RG> --name <VM> --query osProfile.secrets[].sourceVault.id -o tsv
az vm show -g <RG> --name <VM> --query osProfile.secrets[].vaultCertificates[].certificateUrl -o tsv

I tried to update them by calling

az vm update -g <RG> --name <VM> --set osProfile.secrets[0].vaultCertificates[0].certificateUrl=https://<VAULTNAME>.vault.azure.net/secrets/<NAME>/<ID>

but then I got error "Failed to start virtual machine. Error: The data retrieved from is not deserializable into JSON." I guess because the page itself was showing "{"error":{"code":"Unauthorized","message":"AKV10000: Request is missing a Bearer or PoP token."}}"

So this was a wrong way. I found correct command to remove those messages after some browsing on internet and it was:

Get-AzureRmVM -ResourceGroupName "<RG>" -Name "<VM>" | Remove-AzureRmVMSecret | Update-AzureRmVM

My virtual machine was able to start again after the mentioned steps. Note: there was also invalid value in osProfile.windowsConfiguration.winRm.listeners[].certificateUrl but this one has no problem for virtual machine start and just blocking WinRM functionality I guess.

I hope it helped a bit.

Azure Site2Site VPN (ARM to Classic)

Issue:

Unable to get the new connection from classic to ARM VPN Gateway connected

Cause:

Authentication failure

Resolution:

Use the below commands to get the existing pre-shared key on the classic VPN gateway and then try to update the same on either sides.

Get-AzureVNetGatewayKey

   -VNetName <String>

   -LocalNetworkSiteName <String>

   [-Profile <AzureSMProfile>]

   [<CommonParameters>]

More Information:

PowerShell installation to use classic commands:

Install-Module -Name PowerShellGet -Force

Install-Module Azure

Install-Module Azure -AllowClobber

Import-Module Azure

Note:

While trying to use the classic subscription via PowerShell, you might have not seen the subscription listed from the below commands:

Add-AzureAccount

Get-AzureSubscription

To see your classic subscription here, you would have to add yourself as a co-administrator for the Classic Account which is what you did in this case.

Documentations for future references:

https://www.powershellgallery.com/packages/PowerShellGet/2.2.1

https://docs.microsoft.com/en-us/powershell/azure/servicemanagement/install-azure-ps?view=azuresmps-4.0.0#how-to-get-powershellget

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-create-udr-classic-ps

Azure Classic Select-AzureSubscription Error

No default subscription has been designated. Use Select-AzureSubscription -Default <subscriptionName> to set the default subscription.

Select-AzureSubscription : The subscription id doesn't exist.
Select-AzureSubscription : The subscription name doesn't exist.
Select-AzureSubscription : Parameter set cannot be resolved using the specified named parameters.

Add-AzureAccount : No subscriptions are associated with the logged in account in Azure Service Management (RDFE). This means that the logged in user is not an administrator or co-administrator for any account

Add-AzureAccount : AADSTS50074: Strong Authentication is required.

I had the following problems with Setting the default subscription because of two reasons. For this you need to have set co-administrator rights

Solution: Add classic administrator role inside AAD for user you are using to log in. Azure Portal > subscriptions > subscription - Access control (IAM) > Classic administrators > Add > Add co-administrator and try again!

Non responding Azure VM

It might happen to your virtual machine in Azure Cloud too. It gets stuck without responding to enabled services like SSH, HTTP even pings; in Microsoft words "VM was not responding to any means of communication".

Symptoms: There is no answer from the public IP range as same as from a private network from a machine on the same VNET and subnet. A tricky part is a machine in the portal looks up and running, stopping, and restarting. 

I opened the M$ support case because it was another occasion of the same behavior and I wanted to know the answer. We went through a classic scenario: Restart, deallocation, and redeploy via the portal. The extra task was the restart VM's from the serial console but the serial console did not come up even after a reboot.

Short answer: one of the disks was incorrectly mounted. One of the logs was containing crucial information as "Reached target Emergency Mode" followed by

Failed to mount /var/lib/docker. See 'systemctl status var-lib-docker.mount' for details. Dependency failed for Local File Systems.

That failed mount is preventing VM to boot, it needs to be fixed as described below. We had to create a rescue VM for which we used the OS disk of the impacted VM to create a new VM and it worked.

Solution: add to mount point /etc/fstab an item -nofail. Save and exit. Detach drive and do OS swap for the machine. The reboot should be OK and the machine should be online.

How to rescue the VM

• Take the snapshot of OS disk - a full snapshot 
• In disks – Created new disk using source path as a snapshot.
• Verify the size of the disk and the type of disk used and used the same size and type to create a new disk.
• Attach the disk to an existing Redhat VM, swap the disk, and mount it.

These few hints might help you to get rid of the troubles.