You are browsing the archive for 2017 May.

Azure Security Center: Endpoint Protection installation failed with “Permission denied”

2:56 pm in Azure, Azure Security Center, Cloud, Endpoint Protection, Microsoft Antimalware by Wim Matthyssen

Most of you who are already familiar with Azure Security Center (ASC), know that it periodically analyzes the security state of your Azure resources. Whenever Security Center identifies a potential security vulnerability, it creates a recommendation. Last week when trying to apply the solution for such a Recommendation, namely Install Endpoint Protection, the Endpoint Protection installation failed with “Permission denied”.


The error showed that the installation failed because of an RBAC issue (permission error), However, the user used was a Subscription co-admin (Role Owner), so that could not cause the problem because he has all permissions needed.

Because Endpoint Protection is deployed as an extension and deployments of extensions are handled by the VM agent, my next troubleshoot step was to check the log of Azure VM agent on that particular VM.

The path to access this log is: “C:\WindowsAzure\Logs\WaAppAgent.log



But also no issue over here.

Therefore, after troubleshooting for some time, I finally opened a support request to Microsoft. As a response to this request, Microsoft confirmed that this error is under investigation of the product team and that there currently is a design change request in the making to get this problem fixed. For the moment, the problem only occurs in some Azure Regions. In the meantime as a temporary workaround in wait for the real fix, they suggest to install the Azure Antimalware extension from Compute or Azure PowerShell instead of with ASC.

To deploy the Azure Antimalware extension using the Azure Portal you can follow these steps:

Log in to the Azure portal

Select the VM, select Extensions and click Add on the Extensions blade


Select Microsoft Antimalware and click Create on the Microsoft Antimalware blade


To enable Antimalware with the default settings just click OK without putting in any configuration values. If you prefer you can also configure it with your own settings and values


Once the extension successfully installs, it reflects in ASC and the recommendation for that specific VM is gone. Hope this helps!

Wim Matthyssen (@wmatthyssen)

Azure PowerShell: Migrate an Azure ASM Virtual IP address (VIP) to an ARM Public IP address (PIP)

12:13 pm in ARM, ASM, Azure, Azure PowerShell, Cloud, PIP, Public Cloud, Public IP address, VIP, Virtual IP address by Wim Matthyssen

The last weeks, I am assisting some customers with the migration of their existing Azure Service Manager (ASM) VMs to the Azure Resource Manager (ARM) portal. Most of those workloads are migrated with the use of Azure Site Recovery (ASR). The only thing ASR cannot handle for the moment is the migration of the Cloud Services Virtual IP Address (VIP). This public IP address can for example used by an IIS website running on a specific IaaS virtual machine (VM) which is part of that Cloud Service. You can work around this problem, as in many of these cases, by using Azure PowerShell. Below I will wake you through this process with an example.

Overview used Azure VMs:

1) First, we need to login and prepare the ARM environment. To do so run following PowerShell commands (change variables as needed):



2) Next we need to login to the ASM environment


3) As the next step we need to reserve the public IP Address


4) Next we need to de-associate the Reserverd IP address from the Cloud Service. Press Yes when asked



5) When you now check the list of reserved IP addresses, it will show the reserved IP address as unassigned. The attribute InUse is set to False and the ServiceName and DeploymentName attributes are empty


6) Also check if the Reserved IP address is valid for migration


7) Next we need to prepare the Reserved IP address for migration


8) Now run the following PowerShell command to finalize the migration of the Reserved IP address


9) You can verify the availability of the migrated Public IP address by login in to the Azure portal. Under Public IP address, you should see the resource with the correct IP address



10) Now, you can move this resource to the correct resource group. When you do so, and your asked to Confirm the move, click Yes




11) Afterwards you can assign the public IP address to whichever resource you would like



That concludes this blog post. Hope it comes to your use.

Wim Matthyssen (@wmatthyssen)