When is an Azure Arc Server; not an Arc Server? A look at Azure Arc Server Resource types and the lack of feature parity between them
Walk through how to collect SQL counter using Data collection Rule and displaying the results on a workbook an Azure Dashboard.
A look into Azure Arc SQL Extension and how best practices assessment and what it can extract from an Azure Arc enabled SQL Server.
With the recent announcement of the Avanade Solution for Azure Stack that many of us have been working on, I've published an article on the Avanade Insights blog with some additional details and links to more information about the solution. https://www.avanade.com/en/blogs/avanade-insights/cloud-computing/avanade-azure-stack-isnt-like-the-others
I recently ran into an issue where an ExpressRoute had been migrated from Classis (ASM) to the new portal (ARM), however legacy Classic Virtual Networks (VNets) were still in operation. These VNets refused to be deleted by either portal or PowerShell. Disconnecting the old VNet’s Gateway through the Classic portal would show success, but it would stay connected.
There’s no option to disconnect an ASM gateway in the ARM portal, only a delete option. Gave this a shot and predictably, this was the result:
Ok, let’s go to PowerShell and look for that obstinate link. Running Get-AzureDedicatedCircuitLink resulted in the following error:
PS C:\> get-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet
get-AzureDedicatedCircuitLink : InternalError: The server encountered an internal error. Please retry the request.
At line:1 char:1
+ get-AzureDedicatedCircuitLink -ServiceKey xxxxxx-xxxx-xxxx-xxxx-xxx...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzureDedicatedCircuitLink], CloudException
+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ExpressRoute.GetAzureDedicatedCircuitLinkCommand
I couldn’t even find the link. Not only was modifying the circuit an issue, but reads were failing, too.
Turned out to be a simple setting change. When the ExpressRoute was migrated, as there were still Classic VNets, a final step of enabling the circuit for both deployment models was needed. Take a look at the culprit setting here, after running Get-AzureRMExpressRouteCircuit:
"serviceProviderProperties": {
"serviceProviderName": "equinix",
"peeringLocation": "Silicon Valley",
"bandwidthInMbps": 1000
},
"circuitProvisioningState": "Disabled",
"allowClassicOperations": false,
"gatewayManagerEtag": "",
"serviceKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"serviceProviderProvisioningState": "Provisioned"
AllowClassicOperations set to “false” blocks ASM operations from any access, including a simple “get” from the ExpressRoute circuit. Granting access is straightforward:
# Get details of the ExpressRoute circuit
$ckt = Get-AzureRmExpressRouteCircuit -Name "DemoCkt" -ResourceGroupName "DemoRG"
#Set "Allow Classic Operations" to TRUE
$ckt.AllowClassicOperations = $true
More info on this here.
But we still weren’t finished. I could now get a successful response from this:
get-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet
However this still failed:
Remove-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet
So reads worked, but no modify. Ah—I remembered the ARM portal lock feature, and sure enough, a Read-Only lock on the Resource Group was inherited by the ExpressRoute (more about those here). Once the lock was removed, voila, I could remove the stubborn VNets no problem.
# Remove the Circuit Link for the Vnet
Remove-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet
# Disconnect the gateway
Set-AzureVNetGateway -Disconnect –VnetName $Vnet –LocalNetworkSiteName <LocalNetworksitename>
# Delete the gateway
Remove-AzureVNetGateway –VNetName $Vnet
There’s still no command to remove a single Vnet, you have to use the portal (either will work) or you can use PowerShell to edit the NetworkConfig.xml file, then import it.
Once our legacy VNets were cleaned up, I re-enabled the Read-Only lock on the ExpressRoute.
In summary, nothing was “broken”, just an overlooked setting. I would recommend cleaning up your ASM/Classic Vnets before migrating your ExpressRoute, it’s so much easier and cleaner, but if you must leave some legacy virtual networks in place, remember to set the ExpressRoute setting “allowclassicoperations” setting to “True” after the migration is complete.
And don’t forget those pesky ARM Resource Group locks.
One of the advantages of the Azure Resource Management (ARM) deployment model is being able to delegate administration, something we couldn’t do under the Azure Service Management (ASM or RDFE) deployment model (see the previous posts on subscriptions and resource groups). By delegating administrative authority, we can keep the number of subscription admins low and grant access in accordance with the principle of Least Privilege. This post will walk through using Azure role-based access control (RBAC) to achieve all of this.
There are three general roles that apply to all resource types:
In addition to these general roles, there are other built-in roles that are resource-specific. Microsoft has a list of those roles, but because Azure is changing regularly it’s best to use PowerShell to query for the roles:
[powershell]
# list all of the RBAC roles in the subscription (Get-AzureRmRoleDefinition).Name
# see the actions a specific role is allowed to perform (Get-AzureRmRoleDefinition -Name '<Role Name>').Actions
# see the actions a specific role is *not* allowed to perform (Get-AzureRmRoleDefinition -Name '<Role Name>').NotActions
[/powershell]
Azure Active Directory (AD) users and groups can be assigned to any Azure RBAC role. The Azure AD tenant to which the subscription belongs is the source tenant for users and groups.
If you find that the built-in roles aren’t sufficient, you can create custom roles which will be the topic of Part 2.
There is a hierarchy to containers and resources:
Any access granted to a parent container is inherited by all children. For example, an account granted read access at the subscription level can see all resources in the subscription. By the way, there is no concept of denying access in Azure RBAC, so be very careful and deliberate about granting wide-spread access.
Back in the ASM days, to access an Azure subscription one needed to be a subscription admin (or co-admin). Those admins are automatically granted subscription owner access in ARM. However, accounts granted owner access in ARM are not automatically granted subscription co-admin access. If you have resources that you need to manage that are not yet available in ARM you will still need to manage the co-admins list. In either case the recommendation is still the same: keep the number of subscription admins (granted either through Azure RBAC or directly through subscription admins) as low as possible.
Recommendations for a resource group strategy were discussed in a previous post, so I won’t rehash that content. What I do want to talk about is how to implement your strategy.
RGs must be created by an account with subscription owner role. Once the RG is created an RG owner must be assigned to a user who is the actual owner of the RG (owner as in someone who is responsible for the resources that the RG will contain). Once that owner has been established additional roles can be added by the new owner. The advice for RGs is the same as subscriptions: keep the number of owners as low as possible – not everyone who needs access to the RG needs to be an owner of the RG – use Contributor instead.
To keep the administrative overhead as low as possible, use Azure AD groups to manage role membership. Create a group and add user accounts to the group. If you’re syncing your on-premises AD Domain Services (DS) with Azure AD create the group in AD DS and let it sync to Azure AD. Manage these groups using your existing on-premises user and group management process.
Contra much of the advice published on the Internet not every service or application should get its own VNet and not every virtual machine (VM) should get its own storage account. VNets and storage accounts for VM disks (VHDs) are infrastructure resources and need to be managed as such.
Create an RG for the VNets and place all the VNets into that RG. Create a group, name it something descriptive like Network Consumers, and grant it the Reader and Virtual Machine Contributor roles to the VNet RG. Any user account in that group will be able to attach VMs to any of the VNets in the VNet RG.
Create an RG for the VHD storage accounts and place all the VHD storage accounts into that RG. Create a group, name it something descriptive like Storage Consumers, and grant it the Reader and Virtual Machine Contributor roles to the VHD storage account RG. Any user account in that group will be able to use any of the storage accounts in the RG to store a VM’s VHDs.
Hi Folks, Normally we stick to the technical stuff here, but today we're cross posting some Avanade news: We are excited to announce that Avanade is making available access to Azure Stack Technical Preview 2 in our labs, so you can quickly test the new technology no set-up required. Microsoft Azure Stack is a new hybrid cloud platform that enables organizations to deliver Azure services from their own datacenter. We know many of you are excited to try it out, but may not be ready to commit to buying hardware to run it on yet.. With our new offering, you can run Azure Stack in the Avanade-hosted Azure Stack Labs, and we’ll take care of the planning and hardware acquisition.
We have a limited number of openings for clients to test a dedicated Azure Stack TP2 environment. These environments are hosted and supported by Avanade and are provided in lengths of four week segments. Each environment is a preconfigured dedicated instance, allowing you to immediately test advanced scenarios. “Avanade has been a key partner on the Azure Stack journey and this platform provides our joint customers a chance to test Azure Stack almost instantly,” said Mark Jewett, Senior Director of Cloud Platform Marketing at Microsoft.
To learn more or request access, contact your local Avanade sales contact or send an email to azurestackpoc@avanade.com.
More info on Avanade.com: https://www.avanade.com/en/media-center/in-the-news/test-azure-stack-in-avanade-labs
