Für dieses Problem gibt es im Allgemeinen das Feature „Processor compatibility“ in Hyper-V (Im Deutschen als „Prozessorkompatibilitätsmodus“ bezeichnet, in der GUI heisst es dann „Zu einem physischen Computer mit einer anderen Prozessorversion migrieren“ bzw. „Migrate to physical computer with a different processor version“). Dieses Feature kann man natürlich problemlos über die GUI ein- und ausschalten:

Allerdings ergeben sich hier schnell 2 Herausforderungen:

• Das Feature lässt sich nur ändern, während die VM ausgeschaltet ist
• In einem Cluster laufen schnell mal eine 2-stellige Anzahl VMs

Das kann man natürlich wie so vieles sehr elegant per PowerShell lösen, also habe ich dafür ein passendes Skript geschrieben. Dieses kann entweder zum ein- oder ausschalten des Features benutzt werden und iteriert dabei über einen Cluster und behandelt dabei dann alle VMs im Cluster, bei denen das Feature noch nicht korrekt eingestellt ist, in dem die VMs bei Bedarf zuerst gestoppt, das Feature gesetzt und dann falls vorher laufend die VM wieder startet. Am Ende wird dann noch der Gesamtzustand ausgegeben.

Das Skript findet ihr auf meinem GitHub Repo, siehe hier:

scripts/HyperV/EnableOrDisableCPUCompatibilityOnHyperVCluster.ps1 at master · HaikoHertes/scripts (github.com)

Damit kann man nun also entweder bei unterschiedlicher Hardware die CPU-Kompatibilität für alle VMs erhöhen oder, nachdem man z.B. die CPUs überall auf den selben Stand gebracht hat, das Feature wieder deaktivieren.

Insbesondere für diese Assessments (die dann u.a. auch eine Depency Analysis erlauben) werden Gruppen in Azure Migrate benötigt. Diese kann man im Portal nur sehr rudimentär anlegen. Dabei müssen aus der Liste von erkannten on-opremises Servern die gewünschten Systeme in mehreren Listen-Seiten zu je ca. 10 Systemen, die sich weder sortieren noch (sinnvoll) filtern lässt, ausgewählt und mit Checkboxen zur Gruppe hinzugefügt werden:

Nun gibt es zwar seit Ende 2020 ein PowerShell-Modul für Azure Migrate – dieses kann aber bis heute in keinster Weise mit diesen Gruppen umgehen – weder diese Abfragen, noch anlegen oder verändern.

Aus diesem Grund – und weil es immer öfter nötig ist, aus hunderten oder tausenden erkannten on-prem Systemen nur einen Teil auszuwählen – habe ich ein passendes PowerShell-Skript erstellt, welches eine über Hostnamen gegebene Liste von Servern in eine entweder bereits vorhandene oder im Laufe des Skriptes angelegte Gruppe aufnimmt. Dazu werden verschiedene REST-Calls gegen die REST-API von Azure benutzt, um sowohl mit den Gruppen als auch den erkannten Servern umgehen zu können.

Das Skript ist auf meinem GitHub Repo zu finden:

scripts/GroupAzMigrateServers.ps1 at master · HaikoHertes/scripts (github.com)

Ich werde in den kommenden Tagen voraussichtlich noch ein paar kleine Verbesserungen vornehmen, das Skript ist aber bereits jetzt voll lauffähig.

Ihr findet diese Runbooks wie immer in meinem GitHub Repo, konkret genau hier:

VMs starten und stoppen:

https://github.com/HaikoHertes/scripts/tree/master/Azure/Automation/Snoozing

VMs deallokieren:

https://github.com/HaikoHertes/scripts/tree/master/Azure/Automation/VmDeallocation

Viel Spaß damit!

Weitere Informationen zu Azure Automation und Runbooks:

Azure Quickstart – Create an Azure Automation account | Microsoft Docs
Create an Azure Automation Run As account | Microsoft Docs
Create a standalone Azure Automation account | Microsoft Docs
Create a PowerShell Workflow runbook in Azure Automation | Microsoft Docs

Dazu gibt es eine recht simple Lösung – und natürlich hat sie mit PowerShell zu tun

Es gibt eine API, die man abfragen kann. Diese ist unter

https://prices.azure.com/api/retail/prices

zu erreichen. Sie liefert bei direkter Abfrage eine riesige Menge an Daten, so dass es sinnvoll ist, schon bei der Abfrage zu filtern. Außerdem muss man die Abfrage in mehreren Durchläufen verwenden, sonst kommt es ggf. zu Timeouts oder es kommenden nicht alle Daten zurück.

Das Code-Schnippselchen, dass das erledigt, sieht dann folgendermaßen aus:

 
$pricelistApiUrl = "https://prices.azure.com/api/retail/prices?`$filter=armRegionName eq 'westeurope' and serviceName eq 'Virtual Machines'"
$reponseSkus = @()
do
{
    $webRequest = Invoke-WebRequest -Uri $pricelistApiUrl | ConvertFrom-Json
    $pricelistApiUrl = $webRequest.NextPageLink
    $reponseSkus += $webRequest.Items
    #$pricelistApiUrl
}
while ($pricelistApiUrl -ne $null)
$vmPrices = $reponseSkus | Where-Object {($_.type -eq "Consumption") -and ($_.skuName -notlike "*Low Priority*") -and ($_.skuName -notlike "*Spot*") }|  Sort-Object armSkuName,retailPrice -Descending
$vMPrices | Export-Csv -Path "VMPrices.csv" -Encoding UTF8 -NoTypeInformation -ErrorAction SilentlyContinue # In case the CSV is still open; For German systems, use '-Delimiter ";"'

Das Ganze lässt sich natürlich auch auf beliebige andere Regionen und Services oder auch auf die anderen Attribute / Spalten filtern. Allerdings werden die Preise ausschließlich in Dollar geliefert! Mehr dazu siehe:

Azure Retail Prices REST API overview | Microsoft Docs

Es gibt noch weitere API für Preise, die teilweise auch andere Funktionen, z.B. auch Währungsumrechnung, haben. Diese sind aber erstens scheinbar nicht vollständig und zweitens auch komplizierter in der Handhabung.

Viel Spaß beim Ausprobieren und Verwenden!

In the last days, I dealt a lot with GitHub Actions to find out, how it can be used to deploy Azure ARM templates to the cloud. My last „evolution“ step now – I was working on this because of the very valuable hint of a collegue – is able to deploy ARM templates to all 4 available scope levels:

• Tenant level
• Management Group level
• Subscription level
• Resource Group level

And it also could be used, even when you don’t use GitHub Actions! But let’s start from the beginning…

A brief history of evolution

In my first appraoch, I have used a simple PowerShell script (based on a Script by Sarah Lean, https://gist.github.com/weeyin83/81e7a7bf3caf3d0bce787db5d562b47e) to just deploy something to Azure using GitHub Actions. This is fast & simple, but not very flexible.

My second approach took me to the new Azure PowerShell Action, where you can just run PowerShell code from within the GitHub Action:

https://github.com/HaikoHertes/ActionsDemo/blob/master/.github/workflows/DeployARMtoAzure.yml

So I used some small code to deploy an ARM template with its parameters file that both reside in an GitHub repo. This is even more easy to use, but still not very flexible, especially, when it comes to multiple ARM templates.

You can still find the code and stuff here:
https://github.com/HaikoHertes/ActionsDemo

Next step was to deploy just a bunch of Templates with their parameters from a repository to become more flexible. Here I wrote a PowerShell script that does the main work:
https://github.com/HaikoHertes/ActionsDemo.v2/blob/master/DeployARMtoAzure.ps1
This script is then just called from within the GitHub Action:

https://github.com/HaikoHertes/ActionsDemo.v2/blob/master/.github/workflows/DeployARMtoAzure.yml#L27

This allready does a good job, so you can fetch everything from here:
https://github.com/HaikoHertes/ActionsDemo.v2

The final solution

But then, a colleague of mine gave me an hint on some new options to not just deploy to Resource Group level, but to higher levels as well. And so I spent a day to investigate and re-write my PowerShell script. And now I can offer a script, that does the job! Let me show you…

You can pick up the script from here:
https://github.com/HaikoHertes/ActionsDemo.v3/blob/master/DeployARMtoAzure.ps1

How the script works

As it is a little more complex, I want to explain what it does and how it works. The script is divided into 5 major parts:

• Setting the variables and defining the functions
• Deploying to Tenant level
• Deploying to Management Group level
• Deploying to Subscription level
• Deploying to Resource Group level

If there are no templates for one of these levels or if their folder does not exist, it will just be skipped.

The script expects a defined folder structure:

The names of folders and files can be adjusted in the PowerShell Script:

After all the variables are set, two functions are declared: GetLocation and GetScop. They are made to fetch the location / region from a given directory’s location file or return the default location and to fetch the scope of the deployment either from a scope file or the folder name. Both functions will be used in the later deployments. All files allow the usage of comments that start with the hashtag symbol ‚#‘.

The 4 major parts for the different deployment levels are mostly very similar just with slight differences, thats why I just explain how any of them works.

They first grab all JSON files, that are not in the naming format *parameters.json in any subdirectory (so you can organize your templates by topic or something else and group them into folders). If an order file is given, it will fetch the sorting order from the file (allowing sorting by foldername and filename (default) or filename-only) or just sort by the default order. That way, you can define a deployment order by using proper names for your templates.

Now it will run through the list of templates, getting the scope and location of that templates folder, fetching the tags if any given and then trigger the deployment with any of these Cmdlets, whatever is sufficient for the scope / level:

• New-AzTenantDeployment
• New-AzManagementGroupDeployment
• New-AzSubscriptionDeployment
• New-AzResourceGroupDeployment

For a given template ABC.json , it allways expects a ABC.parameters.json file next to the template with the parameters. If no parameters are needed, just provide an empty file.

At the end, all templates in all of the 4 levels are deployed

How to use the script

The script was made to be used with GitHub Actions:

Here it is just called after repo checkout and Azure login. You can get the stuff from here:
https://github.com/HaikoHertes/ActionsDemo.v3/blob/master/.github/workflows/DeployARMtoAzure.yml
https://github.com/HaikoHertes/ActionsDemo.v3

It expects the ARM templates in a subfolder „arm“ within the same repo where the GitHub Action resides.

Be aware that as of today, you need to use ubuntu-20.04 and AzPS 4.1.0 (This is needed for the latest version of the deployment Cmdlets above, and AzPS 4.1.0 is only included in the ubuntu-20.04 container image used by GitHub Actions.

The other option would be to use the script without GitHub Actions and even without any repository. You could just run it locally with a given local folder structure containing the templates and other files. You would just need to add something like

Connect-AzAccount

to do the login. Be aware that you still need Az PS Module version 4.1.0 or higher, which you can install with

Install-Module -Name Az -AllowClobber -MinimumVersion 4.1.0

Setting the proper rights on Azure

To be able to deploy to Azure, you need a user with proper rights. Especially when using GitHub Actions, it is not recommended to use a regular named user, but service principals. In my video (German language, but it shows eveything on english UI) on YouTube, you can see how to do this:

You will need something like this:

az ad sp create-for-rbac –name „github“ –role contributor –scopes /subscriptions/YOUR_SUB_ID –sdk-auth

To be able to deploy to Tenant level, you will need the proper rights on root level. Some types of template also need owner rights, especially wheny you want to deploy role assignments or such. Either adjust the above command or (especially, when the user allready exists), extend the rights with somthing like this:

az role assignment create –role „Owner“ –assignee „[USERID]“ –scope „/“

About the different files that can be used

There is several files that can be used to control how the script works:

arm/DefaultLocation.txt

This file defines the default location for any deployment, that needs a location to be set outside the ARM template. It also includes a list of all available location names. Treat this file as mandatory.

arm/ANY_LEVEL/order.txt

This file defines the sorting order and therefor the deployment order within that given level. There is two options:

• SortByFolderName = Sorting by foldernames and then by filenames (default)
• SortByFileName = Folder names are ignored, sorting just by templates filenames

The file is optional; if no order is given through a file, the default order will be by foldername first and then by templates filename.

scope.txt next to any template JSON

By default, the deployment scope (i.e. Subscription ID) is fetched from the templates folder ANY_DEPLOYMENT. If needed (i.e. when you want to deploy multiple folders as seperate groups, but into the same scop), you can provide a scope.txt file instead. In here, give ID or name of the scope, both would work.

tags.txt next to any template JSON

You can provide a tags.txt file with the content like

KEY = VALUE

pairs to set tags right on the deployment.

location.txt next to any template JSON

Next to a template file, you can provide a location.txt file that will set the location for the deployment, if needed. If the template itself sets a location, then templates location will be used. If neither template nor location.txt provide a location, but one is needed, the defaultLocation will be used.

(The names are given as they would be with the parameters I provide with my script; they can be changed)

Copyright / legal notice

Copyright 2020 Haiko Hertes

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the „Software“), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED „AS IS“, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Man kann die für den eigenen Tenant verfügbaren Regionen recht leicht mit Hilfe der Azure CLI (z.B. über Azure CloudShell) abfragen:

az account list-locations --query "[].{Name:name, DisplayName:displayName}" -o table

Regionen und Verfügbarkeitszonen in Azure | Microsoft Docs

Nun kam von einem meiner geschätzten Kollegen zu Recht die Frage, wie man denn in dieser (ersten, im Video gezeigten) Variante mehrere ARM Templates bereitstellen kann. Und dazu möchte ich hier die passende Antwort liefern…

Eine Variante wäre sicherlich, in diesem Skript

https://github.com/HaikoHertes/ActionsDemo/blob/master/.github/workflows/DeployARMtoAzure.yml#L23

mehrfach das „az deployment group create“ aufzurufen – aber dann müssten man wissen, wie viele Templates es sind und das Skript würde auch schnell sehr lang.

Als aus meiner Sicht bessere Lösung habe ich ein PowerShell Skript geschrieben, dass in der Verzeichnisstruktur des Repositories einen Ordner „arm\“ erwartet und darin Unterordner mit den Namen der gewünschten Resource Groups. Diese werden falls nötig vom Skript angelegt. Außerdem sucht das Skript Templates im Format XYZ.json und dazugehörige Parameter-Files im Format XYZ.parameters.json. Diese Templates werden nun alphabetisch geordnet mittels ARM bereitgestellt – egal, wie viele es sind. Dabei werden aus einer Datei „tags.txt“ falls gewünscht die Tages im Format

Tag = Wert

geladen und bei der Bereitstellung der RGs und Ressourcen mit angewendet. Die zu verwendende Location (nur eine pro RG ist erlaubt, aber das entspricht weitgehend dem üblichen Vorgehen) wird ebenfalls aus einer TXT-Datei location.txt gelesen.

Im GitHub Repo müssen zwei Secrets hinterlegt werden:

Einmal ein Secret für die Credentials (wie man die anlegt zeige ich im Video ab 20:27) und einmal die Subscription ID der zu verwendenden Subscription. Ergo ist ein Repo pro Subscription nötig…

Das PowerShell Script selbst könnt ihr hier herunterladen:

https://github.com/HaikoHertes/ActionsDemo.v2/blob/master/DeployARMtoAzure.ps1

Alternativ könnt ihr gleich mein ganzes Demo Repo auf GitHub clonen:

https://github.com/HaikoHertes/ActionsDemo.v2 bzw
https://github.com/HaikoHertes/ActionsDemo.v2.git

Wichtig: Damit mit -Tag bzw. -Tags auch die tags gleich mit bereitgestellt werden können braucht man das Az Modul in Version 4.1.0 und das wiederum ist derzeit nur im Ubuntu-20.04 Image auf GitHub enthalten. Siehe dazu auch hier:

https://github.com/marketplace/actions/azure-powershell-action
https://github.com/actions/virtual-environments/blob/master/images/linux/Ubuntu2004-README.md
https://github.com/actions/virtual-environments/tree/master/images

Wie geht man nun an das Thema heran? Zunächst muss man zwei Dinge in Erfahrung bringen:

• Den Namen des Resource-Providers um den es geht
• Die Operationen auf diesem Provider, die man erlauben oder verbieten möchte

Dazu kann man sich in den Microsoft Docs informieren:

• https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-services-resource-providers – hier findet man die Resource Provider zu dein einzelnen Azure Services
• https://docs.microsoft.com/de-de/azure/role-based-access-control/resource-provider-operations – und hier die auf den jeweiligen Resource Providern möglichen Operationen

Für den Fall der Virtual Machine finden wir dazu also:

• Der Resource Provider heisst „Microsoft.Compute„
• Auf diesem sind u.a. folgende Aktionen vorgesehen:
  • Microsoft.Compute/virtualMachines/powerOff/action
    • Powers off the virtual machine. Note that the virtual machine will continue to be billed.
  • Microsoft.Compute/virtualMachines/read
    • Get the properties of a virtual machine
  • Microsoft.Compute/virtualMachines/restart/action
    • Restarts the virtual machine
  • Microsoft.Compute/virtualMachines/start/action
    • Starts the virtual machine

Die Liste der möglichen Aktionen auf einem Resource Provider kann man auch via PowerShell bekommen, z.B.:

Get-AzProviderOperation "Microsoft.Compute/*" | FT Operation, Description -AutoSize

Man muss allerdings berücksichtigen, dass es zum Starten einer VM auch erstmal nötig ist, die VM überhaupt sehen zu dürfen…

Als nächstes muss man die Rollen-Definition im JSON-Format schreiben. Dazu kann man sich auch vorab eine bereits existierende Rollendefinition herunterladen, z.B. mit

Get-AzRoleDefinition -Name "Virtual Machine Contributor" | ConvertTo-Json

Nun passt man sich das JSON so an, dass die gewünschten Aktionen abgedeckt sind. Dabei wird die „ID“ Zeile entfernt und „IsCustom“ auf „true“ gesetzt. Außerdem muss der AssignableScope gesetzt werden. In unserem Fall führt das in etwa zu dieser Definition:

{
  "Name": "Virtual Machine Starter-Stopper",
  "IsCustom": true,
  "Description": "Lets you see, start, restart and stop Virtual Machines.",
  "Actions": [
	"Microsoft.Resources/subscriptions/resourceGroups/read",
    "Microsoft.Compute/virtualMachines/read",
	"Microsoft.Compute/virtualMachines/start/action",
	"Microsoft.Compute/virtualMachines/restart/action",
	"Microsoft.Compute/virtualMachines/powerOff/action",
	"Microsoft.Compute/virtualMachines/deallocate/action"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/00000000-1234-5678-91234-000000000000"
  ]
}

Diese Definition kann man z.B. mit vi in der Azure Cloud Shell in ein File schreiben. Diese kann man dann wiederum mit

New-AzRoleDefinition -InputFile myRole.json

in eine neue Rolle schreiben lassen.

Nun kann man die Rolle bspw. über das Azure Portal zuweisen:

Und damit kann der Benutzer dann genau die definierten Rechte wahrnehmen – und nicht mehr!

Viel Spaß beim Ausprobieren!

Auf Grund vieler Nachfragen aus Community und Kunden habe ich mich dazu entschieden, dieses Thema etwas genauer zu beleuchten… Wenn man Azure in größerem Umfang nutzt, dann kommt schnell die Frage nach interner Kostenverrechnung („Innerbetriebliche Leistungsverrechnung“ / „Charge back“) oder zumindest der Möglichkeit, die Kosten den jeweiligen Verursachern zuzuordnen und transparent darzustellen. Ein wesentliches Hilfsmittel dafür ist das Tagging von Ressourcen. Klar, man könnte die Ressourcen auch nach Kostenstellen getrennt in unterschiedlichen Subscriptions unterbringen, das stößt in der Praxis aber schnell an Grenzen und auf Probleme.

Hat man nun seine Ressourcen mit den entsprechenden Tags versehen, z.B. nach Besitzer („Owner“), Kostenstelle („Cost center“) oder Abteilung („Department“), dann tauchen diese Tags leider noch nicht in der regulären Rechnung auf.

Nun kann man sich aus dem Azure Portal (oder auch aus dem EA / Enterprise Portal oder via REST API) eine Detail-Aufstellung der Kosten herunterladen. Dazu muss man zu „Cost Management + Billing“ / Billing-Scope auswählen / „Usage + Charges“ / Monat wählen / Download-Button klicken / Kurz warten / “ Usage Details Version 2″ auswählen. Diese „Usage Details“ enthalten dann auch die Tags. Allerdings: Selbst wenn man das CSV-File so umformatiert, dass Excel damit umgehen kann, ergibt sich noch ein Problem:

Die einzelnen Tags werden alle zusammen geworfen und in einer „Spalte“ vermischt. Damit ist das Suchen oder Filtern nach einzelnen Tags schon recht schwer – eine bestimmte Kombination aus Tags ist damit unmöglich zu filtern. Dazu müsste man die Tags jeweils in einzelnen Spalten ablegen. Und da kommt PowerShell und dessen Möglichkeit, mit dem JSON-Format umzugehen, ins Spiel! Ich habe eine Script geschrieben, was die Spalte in die einzelnen Tags aufteilt. Dabei werden auch gleich Zahlen und Daten in das lokale Format überführt.

# Script to expand tags from the usage details CSV provided by Azure / Microsoft
# to filter usage by tags; also converts some numbers to local format
# Download CSV file by hand first!


# This is needed for the FileOpen Dialog	
Add-Type -AssemblyName System.Windows.Forms
$FileBrowser = New-Object System.Windows.Forms.OpenFileDialog -Property @{ 
    InitialDirectory = [Environment]::GetFolderPath('Desktop') 
    Filter = 'CSV-Files (*.csv)|*.csv'
}
$null = $FileBrowser.ShowDialog() # Just to open the dialog

If($FileBrowser.FileName -eq "")
{
    Write-Verbose "No file selected - aborting."
    Break    
}

$CSV = Import-Csv $FileBrowser.FileName -Delimiter ","

for ($i=0; $i -lt $CSV.length; $i++) 
{
    # Showing progress
    Write-Progress -Activity "Expanding in Progress..." -Status "$([math]::truncate($i / $($CSV.length) * 100))% complete..." -PercentComplete $($i / $($CSV.length) * 100)
    
    # Converting dates and numbers to local format
    $CSV[$i].Date = [datetime]::ParseExact( $CSV[$i].Date, 'MM/dd/yyyy', $null).ToString("d")
    $CSV[$i].BillingPeriodStartDate = [datetime]::ParseExact( $CSV[$i].BillingPeriodStartDate, 'MM/dd/yyyy', $null).ToString("d")
    $CSV[$i].BillingPeriodEndDate = [datetime]::ParseExact( $CSV[$i].BillingPeriodEndDate, 'MM/dd/yyyy', $null).ToString("d")
    $CSV[$i].Quantity = [float]$CSV[$i].Quantity
    $CSV[$i].EffectivePrice = [float]$CSV[$i].EffectivePrice
    $CSV[$i].Cost = [float]$CSV[$i].Cost
    $CSV[$i].UnitPrice = [float]$CSV[$i].UnitPrice


    # Expand Tags
    $Tags = "{ $($CSV[$i].Tags) }" | ConvertFrom-Json # We need to add some brackets here...
    if ($Tags -ne $null) {
         $Tags.PSObject.Properties | ForEach { 
            $TagName = "Tag-$($_.Name)" 
            Add-Member -InputObject $CSV[$i] $TagName $_.Value 
            # Adding the heading - what a rhyme (; ...
            if ($CSV[0].PSObject.Properties[$TagName] -eq $null) {
                Add-Member -InputObject $CSV[0] $TagName $null -Force
            }
        }
    }

}

# Saving as Excel-readable CSV
$CSV | Export-Csv "$([System.IO.Path]::GetDirectoryName($FileBrowser.FileName))\$([io.path]::GetFileNameWithoutExtension($FileBrowser.FileName))_expanded.csv" -NoTypeInformation -Delimiter ";"

Das Script findet ihr natürlich auch auf meinem GitHub Repo:

https://github.com/HaikoHertes/scripts/blob/master/Azure/Management/Expand-AzureTagsFromUsageDetails.ps1 

Das Resultat der Umwandlung wird dann in eine neue Excel-Datei im selben Folder wie die Originaldatei abgespeichert und kann dann problemlos in Excel geöffnet werden:

Wie man hier sieht sind die Tags nun in separaten Spalten untergebracht, so dass man sehr gut danach sortieren, darauf filtern oder mehr tun kann.

Viel Spaß beim Ausprobieren bzw. Benutzen!

Um dieser Herausforderung zu begegnen gilt es zunächst, die Ressourcen, die „weg“ können, zu identifizieren. Dazu habe ich eine erste Version eines PowerShell Skriptes erstellt, welches:

• Nicht verwendete Public IPs
• Nicht verwendete NICs
• Nicht verwendete NSGs
• Nicht verwendete Managed Disks

findet und aufführt.

Über die Zeit möchte ich das Skript weiter ausbauen.

Ihr findet es in meinem GitHub Repository:

https://github.com/HaikoHertes/scripts/blob/master/Azure/CostOptimization/GetOrphanedAzureRessources.ps1

Und ja, natürlich bietet Azure mit seinen Recommendations hier auch schon einiges, allerdings eben nicht „live“…

Viel Spaß beim Ausprobieren – über Kommentare freue ich mich!