In my last post, I demonstrated how to generate Azure AD oAuth tokens using my AzureServicePrincipalAccount PowerShell module. Although personally, I pretty much use Azure Resource Manager REST API for everything – this is where the oAuth token come in play, but often, I have seen colleagues and customers use a mixture of both ARM REST APIs calls and AzureRM modules within same PowerShell scripts. This could potentially be troublesome because in order to use AzureRM modules, you will need to sign-in to Azure using Add-AzureRMAccount (or it’s alias Login-AzureRMAccount). Luckily, Add-AzureRMAccount also supports signing in using an existing AAD
Recently in a project that I’m currently working on, myself and other colleagues have been spending a lot of time dealing with Azure AD oAuth tokens when developing code for Azure. There are so many scenarios and variations when trying to generate the token, and you have probably seen a lot of samples on the Internet already. I have spent a lot of time trying to develop a common method that the project team can use in all the scenarios. To summarise, you can generate oAuth tokens for the following security principals (and different configurations): Azure AD Application Service Principals
Azure Resource Providers registration dictates what types of resources you allow users to provision within your Azure subscription. Although by default, some resource providers are automatically registered, the user must have required permission to register resource providers (https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-supported-services). I had to create a script to bulk-register resource providers for a subscription because normal users have not been given the permissions to do so. In the following sample script, I am using regular expressions to match the resource provider names, and it is registering all Microsoft resource providers except for the classic (ASM) resource types. View the code on Gist. This
If you have worked on ARM templates, you have probably already faced challenges when you need to use GUIDs within the templates. Currently there are several ways to generate GUID that I can find on the Internet: Generating GUIDs in PowerShell and then pass them into the ARM templates Using a nested template to generate GUID – https://github.com/davidjrh/azurerm-newguid Using an Azure Function app – https://geeks.ms/davidjrh/2017/08/01/providing-a-guid-function-in-azure-resource-manager-templates-with-azure-functions/ Few weeks ago, I was working on an ARM template, where I need to generate 100+ Azure Automation runbook job schedules. For each job schedule, the ‘name’ property is a GUID, which needed to be
Background Back in September 2017, Microsoft has announced Virtual Network Service Endpoints for Azure Storage and Azure SQL at Ignite. This feature prevents Storage Accounts and Azure SQL Databases from being accessed from the public Internet. A customer had a requirement to enforce all storage accounts to be attached to VNets as part of their security policies. The Azure Resource Policy seems to be the logical solution for this requirement. In order to make this possible, I have contacted the Azure Policy product team, and thanks for their prompt response, this is now possible – although at the time of
It has been a long time since my last post. I was very busy right until the Christmas eve, and it my to-be-blogged list is getting longer and longer. I had a very good break during the holiday period. My partner and I took our daughter to Sydney on the Christmas day and spent 5 days up there. When we were in Sydney, I visited Hard Rock Cafe for the first time in my life, and also spent 2 days with my buddy and MVP colleague Alex Verkinderen. Now that I’m somewhat recharged, I will start working on the backlog
Savision and NiCE are getting together and delivering a webinar on Office 365 monitoring and dashboard next week. The webinar is taking place on Wednesday 13th December on 16:00 Central European Time / 10:00 Eastern Standard Time. You can find the details registration form here: https://www.savision.com/webinars/online-session-office365-monitoring-scom
One of the big challenges when working with OpsMgr is finding all the good community management packs. Although Microsoft has provided a “Partner Solutions” section in the OpsMgr console to publish 3rd party management packs, it was designed to advertise commercial MPs developed by partner ISVs. From what I learned, the bar is too high to get your MP listed there, and for my community MPs, I don’t see myself spending time and effort to try get my MPs listed there since they are free and I don’t make any $$$ from these MPs. Squared Up has recently released a
Currently Microsoft is in the process of upgrading all OMS Log Analytics workspaces to the new query language (named Kusto). Once your workspace has been upgraded, you will no longer able to invoke search queries using the Get-AzureRmOperationalInsightsSearchResults cmdlet from the AzureRM.OperationalInsights PowerShell module. Kusto comes with a new set of REST APIs, you can find the documentation site here: https://dev.int.loganalytics.io. According to the documentation, this REST API has the following limitations: Queries cannot return more than 500,000 rows Queries cannot return more than 64,000,000 bytes (~61 MiB total data) Quries cannot run longer than 10 minutes by default. From
I needed to find a way to restrict ALL Azure Service Manager (ASM, aka Classic) resources on the subscription level. Azure Resource Policy seems to be a logical choice. So I quickly developed a very simple Policy Definition: View the code on Gist. Once I have deployed the definition and assigned it to the subscription level (using PowerShell commands listed below), I could no longer deploy ASM resources:
#Set the Subscription ID
$subscriptionId = '7c6bd10f-ab0d-4a8b-9c32-548589e1142b'
Select-AzureRmSubscription -Subscription $subscriptionId
$definition = New-AzureRmPolicyDefinition -Name "restrict-all-asm-resources" -DisplayName "Restrict All ASM Resources" -description "This policy enables you to restrict ALL Azure Service Manager (ASM, aka Classic) resources." -Policy '.\Restrict-ALL-ASM-Resources.json' -Mode All
$assignment = New-AzureRMPolicyAssignment -Name 'Restrict All ASM Resources' -PolicyDefinition $definition -Scope "/subscriptions/$subscriptionId"
i.e. when I tried to create a classic VNet, I could not pass the validation: