Azure Blob Storage mit PowerShell

Immer, wenn ich mit Storage in Azure arbeiten muss, hab ich mir eine einfachere Möglichkeit gewünscht, die Accounts und Container anzeigen zu können. Natürlich kann man über das Portal gehen, oder Tools wie den Azure Storage Explorer oder Cloudberry Explorer nutzen, aber direkt in PowerShell, das ist schon Tipparbeit. Da dachte ich mir, schreib doch eine kleine Funktion, die das macht, und hier ist sie. Jetzt muss man dazu sagen, dass ich kein Entwickler/Programmierer/Developer bin, von daher werden dem ein oder anderen die Haare zu Berge stehen, wenn er den Code gleich sieht, aber dafür gibt es ja auch die Kommentar-Funktion am Ende des Artikels. Ich freu mich schon, ganz viel zu lernen…

Azure Storage Accounts

Vorweg ein kurzer Ausflug zu Storage in Azure, genauer zu Blob Storage, auf den möchte ich mich erst mal beschränken. Storage in Azure ist in Storage Accounts aufgeteilt. Um eine Liste aller Storage Account zu bekommen, brauchen wir nur einzutippen:

Get-AzureStorageAccount

bzw. eine etwas übersichtlichere Liste:

Get-AzureStorageAccount |select label,location,accounttype

Das gibt dann etwas in dieser Art:

Label                   Location     AccountType
—–                   ——–     ———–
dvtest1                 North Europe Standard_LRS
dvtest2                 West Europe  Standard_LRS
portalsonstwas          North Europe Standard_GRS

Man erkennt die unterschiedlichen Locations und Typen, das gilt jeweils für alles, was unter diesem Storage Account gespeichert wird, was den Sinn von unterschiedlichen Accounts auch klar macht.

 

Storage Keys

Um auf ein solches Storage Account zugreifen zu können, benötigt man einen Schlüssel. Es gibt zwei davon, den Primary und den Secondary, wir nutzen mal den Primary (genauso gut geht auch der Secondary). Den Schlüssel erhält man mit:

Get-AzureStorageKey -StorageAccountName dvtest1

und liefert sowas (verkürzte Ausgabe)

Primary              : 1234567890qwertz..nertzuiopas12==
Secondary            : asdfghjklyxcvbnm..1234567898rwr==
StorageAccountName   : dvtest1

Mit diesen Keys hat man wie gesagt Zugriff auf das Storage Account, also klar, dass ich hier keine echten Schlüssel hinschreibe…

 

Storage Context

Hat man also den Namen des Storage Accounts und den Key, dann kann man ein Kontext-Objekt (AzureStorageContext) anlegen (den Key habe ich wiederabgekürzt):

$context = New-AzureStorageContext
               -StorageAccountName dvtest1
               –StorageAccountKey 1234567890qwertz..nertzuiopas12==

Dieser Kontext enthält jetzt also Informationen, welches Account ich meine und hat auch gleich den Schlüssel dazu (auch wenn er den nicht anzeigt). Mit diesem Kontext können wir uns endlich den Inhalt des Storage Accounts ansehen.

 

Storage Container

Die oberste Ebene bilden sogenannte Container, vergleichbar in etwa mit Ordnern in einem Filesystem. Der kleine Unterschied ist, dass es nur diese eine Ebene mit Ordnern, äh, Containern gibt, also keine Container in Container etc., ein ziemlich flaches System. Schauen wir mal, was es für Container gibt:

Get-AzureStorageContainer -context $context

Wir sehen, wir müssen nur den Kontext angeben, den wir uns oben erzeugt haben. Die Liste hier ist jetzt etwas kurz, das kann auch mal mehr sein:

Name PublicAccess LastModified
—- ———— ————
test Blob         10.12.2015 07:54:37 +00:00

Für längere Listen gibt es dann noch die Möglichkeit, mit –Prefix zu filtern oder –MaxCount zu begrenzen – und natürlich mit pipen nach where etc…

 

Container-Inhalt

Jetzt aber endlich zum Inhalt des Containers:

Get-AzureStorageBlob -Context $context -Container test

und das zeigt uns:

Name      BlobType  Length ContentType LastModified
—-      ——–  —— ———– ————
lukas.jpg BlockBlob 160719 image/jpeg  10.12.2015 08:12:34 +00:00
lea.jpg   BlockBlob 158224 image/jpeg  10.12.2015 08:15:34 +00:00

 

Die Abkürzung

Bis hierher ist es also ein langer, langer Weg. Und um das abzukürzen, hab ich mir eben eine kleine Funktion gebaut und in mein Profile eingefügt:

function blobdir {
    param(
    [parameter(Position=0, Mandatory=$false)][string]$account,
    [parameter(Position=1, Mandatory=$false)][string]$container
    )

    if (-not $account) {
    #empty call, list storage accounts
        get-azurestorageaccount |select label,location,accounttype
    } elseif (-not $container){
    #account given, list containers
        $context=New-AzureStorageContext
              
-StorageAccountName $account -StorageAccountKey
               (get-azurestoragekey -StorageAccountName $account |
                select -ExpandProperty Primary)
        get-azurestoragecontainer -context $context
    } else {
        $context=New-AzureStorageContext
              
-StorageAccountName $account -StorageAccountKey
               (get-azurestoragekey -StorageAccountName $account |
                select -ExpandProperty Primary)
        get-azurestorageblob -context $context -container $container
    }
}

(Den Script ohne die lästigen Zeilenumbrüche gibt es auch auf github unter examples…)

Die Funktion hab ich “blobdir” genannt und kann entweder mit keinem, einem oder mit zwei Argumenten aufgerufen werden.

  • Aufruf ohne Argument: Es wird eine Liste aller StorageAccounts angezeigt
  • Aufruf mit einem Argument: Angegeben wird das StorageAccount, angezeigt wird eine Liste aller Container in diesem StorageAccount
  • Aufruf mit zwei Argumenten: Das erste Argument ist der StorageAccount, das zweite der Container, und angezeigt wird der Inhalt des Containers.

Also quasi: blobdir [StorageAccount [Container]]

…und schon verkürzen sich unsere Aufrufe von oben drastisch zu:

blobdir

blobdir dvtest1

blobdir dvtest1 test

 

Aufruf

Ob man das jetzt als PowerShell-Modul lädt, oder wie ich im Profile, bleibt jedem selbst überlassen… Oder vielleicht kann ja jemand in den Kommentaren was dazu sagen?

Das Einbinden ins Profil geht übrigens einfach:

notepad.exe $PROFILE

und dann reinkopieren. Beim nächsten Starten der PowerShell kann’s losgehen.

 

Zusammenfassung

Man kann sich die Arbeit mit Storage also ein ganzes Stück einfacher machen. Wie gesagt, noch einfacher geht es mit diversen (auch frei erhältlichen) Tools. Die hier gezeigte Mini-Funktion lässt sich natürlich ausbauen und mit kleinen Gimmicks versehen, also Ändern der Hintergrundfarbe, Ausgabe von weiterem Text, Neuformatierung der Listen etc… Nur zu!

Veröffentlicht unter Uncategorized | Verschlagwortet mit | Kommentar hinterlassen

Verschieben von VMs in Azure mit PowerShell

Gerade mit der demnächst verfügbaren Microsoft Cloud in Deutschland stellt sich die Frage, wie man Storage oder virtuelle Server innerhalb Azure verschiebt. Das wollen wir uns etwas genauer ansehen, ist auch nicht ganz so einfach. Streng genommen gibt es auch kein Verschieben, sondern wir können nur Kopieren und anschließend Löschen. Ganz ehrlich ist mir das auch lieber, immer noch ein Fallback zu haben…

Das wichtigste vorweg: Letztendlich ist das Verschieben einer VM nicht wesentlich anders als das Verschieben von Storage, es sind nur ein paar Extrapunkte zu beachten. Und bevor alle am Ende enttäuscht sind: Wir konzentrieren uns hier auf das Verschieben der VM, nicht auf die Übernahme aller Details der Konfiguration. So ein paar Hinweise gebe ich zwar, aber etwas Nacharbeit kann schon nötig sein, insbesondere bei komplexen Netzwerk-Strukturen.

Hatte ich eigentlich schon erwähnt, dass wir das ganz in PowerShell machen werden? Nein? Na dann jetzt halt Smiley. Damit wir nicht immer mit Platzhaltern in den Befehlen arbeiten müssen, einigen wir uns mal auf das folgende Szenario (Variablen beginnen immer mit $source für Quellangaben und mit $dest für Zielangaben)

Quelle: $sourceName (Name der alten VM), $sourceService (Name des bisherigen Service)

Ziel: $destName (Name der Ziel-VM), $destService (Name des neuen Service)

Den gesamten Script kann man sich auch kopieren von GitHub.

Die Quelle

Wir fangen an, in dem wir erst mal alle Informationen über unsere VM sammeln:

$sourceVM = Get-AzureVM –Name $sourceName –ServiceName $sourceService

Wir speichern sicherheitshalber mal die komplette Konfiguration lokal in eine XML-Datei:

$sourceVM | Export-AzureVM –Path “c:\temp\export.xml”

Zeit, sich Informationen über die Disks zu besorgen. Azure unterscheidet zwischen OS- und Datendisks, wir holen uns natürlich beides:

$sourceOSDisk = $sourceVm.VM.OSVirtualHardDisk

$sourceDataDisks = $sourceVm.VM.DataVirtualHardDisks

…und setzen auch gleich den Storage Context. Wer jetzt grad nicht weiß, was ein Storage Context ist: Das ist ein Objekt, dass quasi die Storage-Informationen über den Namen, das Account und den Zugriffsschlüssel zusammenfasst:

$sourceStoragename = ($sourceOSDisk.MediaLink.Host -split „\.“)[0]

$sourceStorageAccount = Get-AzureStorageAccount –StorageAccountName
$sourceStorageName

$sourceStorageKey = (Get-AzureStorageKey -StorageAccountName
$sourceStorageName).Primary

$sourceContext = New-AzureStorageContext –StorageAccountName
$sourceStorageName -StorageAccountKey $sourceStorageKey

Sieht etwas komisch aus, wie wir uns den Namen des Storages besorgt haben (1. Zeile), aber der ist versteckt im Medialink, und dort der erste Teil des Hostnamens. Wir trennen also quasi den Hostnamen an den Punkten und nehmen den ersten Teil (Array-Nummerierung startet bei Null!). Wenn jemand eine bessere Art weiß, bitte melden, ich finde, das zeigt super die Mächtigkeit von PowerShell…

Auf der Quellseite sind wir fertig. Wer die abgespeicherte Konfigurationsdatei sich anschaut, findet dort alle wichtigen Angaben für unsere neue Umgebung, also insbesondere die Größe und eventuelle Endpunkte. Wer nicht in die Datei schauen möchte, der kann das auch so erfahren:

$sourceVM.VM.RoleSize

$sourceVM | Get-AzureEndpoint

So. Dann beenden wir die VM mal:

Stop-AzureVM –Name $sourceName –ServiceName $sourceService

Wir erinnern uns, dass uns – falls das die letzte VM in diesem Service ist – die IP-Adresse abhanden kommt. Das können wir verhindern, indem wir “-StayProvisioned” anfügen, dann kostet die VM aber weiterhin…

Das Ziel

Wechseln wir mal zur anderen Seite, in unsere zweite Subscription

Select-AzureSubscription –SubscriptionName “Zielsubscription”

Set-AzureSubscription –SubscriptionName “Zielsubscription”
–CurrentStorageAccountName “zielstorage”

Hinweis: Die Azure-Umgebung ist mit der Subscription verbandelt, daher ist es wichtig, Dinge wie zum Beispiel den StorageContext zu definieren, bevor man die Subscription wechselt, da eine andere Subscription eventuell eine andere Azure-Umgebung hat und damit andere Endpunkte. Wichtig wird das für die Microsoft Cloud in Deutschland, da ist das nämlich so…

Wir haben gewechselt, also alles bereit, und los geht’s wieder mit dem StorageContext, diesmal für’s Ziel:

$destStorageName=”zielstorage”

$destStorageAccount = Get-AzureStorageAccount -StorageAccountName
$destStorageName

$deststoragekey= (Get-AzureStorageKey -StorageAccountName
$destStorageName).Primary

$destContext   = New-AzureStorageContext –StorageAccountName
$destStorageName -StorageAccountKey $destStorageKey

Für die Folge gehen wir davon aus, dass wir in den Storagecontainer “vhds” speichern und dass dieser bereits existiert. Falls nicht, dann bitte anlegen mit

New-AzureStorageContainer –Context $destContext –Name vhds

Das Kopieren

Jetzt gehen wir einfach alle Disks durch, die wir haben, und kopieren sie von Alt nach Neu. Das Kommando dazu heißt Start-CopyAzureStorageBlob und braucht

  • den alten und den neuen Container,
  • den alten und den neuen Blobnamen und
  • den alten und den neuen StorageContext.

Das Kommando startet (wie der Name schon vermuten lässt) nur den Kopiervorgang, wenn wir das zurückgelieferte Objekt speichern, dann können wir über Get-AzureStorageBlobCopyState den aktuellen Status des Jobs anschauen. Übrigens: Nein, ich weiß nicht, wieso hier die Reihenfolge der Copy-Azure-Storage-Blob-Teile so unterschiedlich ist.

Der folgende Codeblock geht also durch alle Disks, startet das Kopieren, und frägt alle 10 Sekunden den Status ab:

$allDisks = @($sourceOSDisk) + $sourceDataDisks

$destDataDisks = @()

foreach($disk in $allDisks)

{

    $sourceContName = ($disk.MediaLink.Segments[1] -split „\/“)[0]

    $sourceBlobName = $disk.MediaLink.Segments[2]

    $destBlobName = $sourceBlobName

    $destBlob = Start-CopyAzureStorageBlob
–SrcContainer
$sourceContName
-SrcBlob $sourceBlobName
-DestContainer vhds
-DestBlob $destBlobName
-Context $sourceContext -DestContext $destContext
-Force

    Write-Host „Copying blob $sourceBlobName“

    $copyState = $destBlob | Get-AzureStorageBlobCopyState

    while ($copyState.Status -ne „Success“)

    {

        Write-Host „$copyState.BytesCopied von $copyState.TotalBytes“

        sleep -Seconds 10

        $copyState = $destBlob | Get-AzureStorageBlobCopyState

    }

    If ($disk -eq $sourceOSDisk)

    {

        $destOSDisk = $destBlob

    }

    Else

    {

        $destDataDisks += $destBlob

    }

}

 

Die Nacharbeit

Fast fertig. Wir haben jetzt alle Disks kopiert in unseren neuen Storage. Bisher sind das aber im Ziel nur Dateien, noch keine Disks. Das machen wir mit Add-AzureDisk, und zwar einmal für die OS-Disk und dann noch für jede Datendisk. Sieht erneut etwas wild aus, wie wir auf die Namen kommen, an dieser Stelle ein herzlicher Dank an Devon Musgrave, von dem diese Beispiele stammen!

Add-AzureDisk -OS $sourceOSDisk.OS -DiskName $sourceOSDisk.DiskName
-MediaLocation $destOSDisk.ICloudBlob.Uri

foreach($currentDataDisk in $destDataDisks)

{

    $diskName = ($sourceDataDisks | ? {$_.MediaLink.Segments[2] -eq
$currentDataDisk.Name}).DiskName

    Add-AzureDisk -DiskName $diskName
-MediaLocation $currenDataDisk.ICloudBlob.Uri

}

Und schon haben wir lauter Disks anstatt nur Blobs. Der Rest ist einfach, erfordert aber wie oben angedroht eventuell Nacharbeit. Soll aber hier jetzt nicht mein Problem sein, ich lege einfach eine neue VM mit irgendeiner InstanceSize an, nur gebe ich keinen ImageName an, sondern einen DiskName, nämlich unsere oben kopierte OS-Disk (nicht wundern, wir haben die Namen der Disk ja einfach übernommen):

$destVM=New-AzureVMConfig -name $destName -InstanceSize Small
-DiskName $sourceOSDisk.DiskName

New-AzureVM –ServiceName $destService –VMs $destVM

Jetzt wäre der Moment, um nachzuarbeiten, also Endpunkte, Netze etc., und dann muss die VM nur noch gestartet werden. Admin-User und Passwort sind übrigens ja Teil der VM und nicht der Azure-Konfiguration, das wird also alles direkt übernommen.

Die Zusammenfassung

Der Hauptteil der Arbeit liegt offensichtlich darin, alle Informationen zusammen zu bekommen, also Storagename, Diskname etc, aber wenn wir alles zusammen haben, dann geht das Kopieren mit einem einzigen Befehl. Nicht vergessen sollten wir, die alten Disks ggf. zu löschen, braucht ja keiner mehr. Es sollte jetzt eine leichte Übung sein, das Beispiel so abzuändern, dass man damit ganz einfach auch andere StorageBlobs verschieben kann: Einfach die Wandlung in Disks weglassen und das Start/Stop der VMs logischerweise.

Noch ein Wort zur Microsoft Cloud in Deutschland: Für den ein oder anderen verblüffend, aber der Mechanismus funktioniert ohne jegliche Änderung auch für das Kopieren zwischen der Public Azure Cloud und der Microsoft Cloud in Deutschland. Es dauert evtl. etwas länger, aber das macht man ja auch nicht jeden Tag. Wichtig ist nur wie oben schon erwähnt, dass man den StorageContext etc. in der jeweiligen Subscription erzeugt. Macht man das nicht, dann fügt Azure unter Umständen beispielsweise beim Erstellen einer URL (MediaLink) die falschen Suffixe hinzu. Die Unterschiede werden klarer, wenn man mal ein Get-AzureEnvironment macht…

Viel Spaß beim Kopieren!

Veröffentlicht unter Azure, PowerShell | Kommentar hinterlassen

DSC – Einführung in Desired State Configuration

Da bin ich neulich über ein (nicht nur) Azure Feature gestolpert, das klang recht interessant, nämlich DSC, ausgeschrieben Desired State Configuration. Das denke ich lohnt sich ein bisschen genauer zu betrachten. Also dann…

Weiterlesen

Veröffentlicht unter Azure, PowerShell | Verschlagwortet mit , , | Kommentar hinterlassen

Azure Backup für Windows 10

Das Azure Backup ist jetzt auch (natürlich Smiley) für Windows 10 verfügbar. Das Verfahren ist genau so, wie ich es in einem früheren Blogartikel schon beschrieben habe, also:

  • Sicherungstresor in Azure anlegen (falls nicht schon vorhanden)
  • Anmeldeinformationen herunterladen (nur 48 Stunden gültig)
  • Azure Backup Client herunterladen (Link siehe Dashboard im Azure Sicherungstresor)
  • Backup Client installieren (Anmeldeinformationen angeben, Verschlüsselungskennwort festlegen)
  • Backup Plan erstellen

Fertig. Was hat man dann? Nun, in etwa das hier:

  • zu sichernde Verzeichnisse/Dateien des lokalen Clients frei auswählbar (einschließlich Ausschlussliste)
  • Einstellbare Zeitpläne (bis zu 3 Sicherungen pro Tag)
  • Effiziente Bandbreiten-Nutzung durch inkrementelles Backup (nur die Änderungen zur vorherigen Sicherung werden übertragen). Die benutzbare Bandbreite kann auch noch manuell eingestellt werden
  • Verschlüsselung der Daten schon vor dem Verlassen des Clients
  • Aufbewahrungszeit in Azure bis zu 99 Jahren
  • Einfaches Auswählen der Verzeichnisse/Dateien für die Wiederherstellung (explorer-like), nur die ausgewählten Dateien werden übertragen
  • Wiederherstellung von Backups auf anderen Geräten (bei Kenntnis des Verschlüsselungskennworts natürlich)

Alles in allem eine runde Sache. Ich persönlich nutze ja OneDrive für die Sicherung der meisten meiner Daten. Lediglich Infos, bei denen es auf eine Historie ankommt, speichere ich in einem anderen (Extra)-Verzeichnis ab, das ich dann mit Azure Backup sichere. Auf diese Weise hab ich das Beste aus beiden Welten: die kostenlose und automatische konstante Synchronisierung mit OneDrive, und die etwas teurere Sicherung der einzelnen Versionen (sofern benötigt) mit Azure Backup.

Viel Spaß!

Veröffentlicht unter Azure | Verschlagwortet mit , | Kommentar hinterlassen

Azure PowerShell 0.9.7

Upps, das ging schneller als erwartet, mit der nächsten Version der PowerShell-Cmdlets für Azure. Aber es sind wieder jede Menge geworden, hier eine kurze Übersicht:

Am meisten hat sich bei Azure Storage getan, wer sich in diesem Bereich tummelt, der sollte sich auf jeden Fall die neue Version holen!

Im Bereich Azure Profile hat New-AzureProfile einen Parameter dazubekommen und Probleme mit AAD Authentifizierung wurden gelöst.

Beim Azure ResourceManager wurde die API für Get-AzureProviderOperation angepasst, um die Performance zu erhöhen.

Bei den Azure Compute Cmdlets gab es ein paar Fixes, genau wie bei Azure SQL, und ein paar Autoscale Cmdlets sind bei Azure Batch hinzugekommen (Enable-AzureBatchAutoScale, Disable-AzureBatchAutoScale).

Alle Infos einschließlich Download wie üblich auf der github-Seite! Enjoy!

Veröffentlicht unter Azure, PowerShell | Verschlagwortet mit , | Kommentar hinterlassen

Microsoft-Konto vs. Azure-Konto

Ich hatte mal einen Blogartikel, in dem hatte ich nebenbei von leichten Problemen geschrieben, mich per PowerShell an Azure Active Directory (AAD) anzumelden. Mittlerweile hab ich mich etwas schlau gemacht (Thanks, Philippe) und möchte euch das nicht verheimlichen. Also dann…

Das Ganze fing damals damit an, dass ich versucht habe, mit dem Azure PowerShell Modul Benutzer im AAD anzulegen. Was gar nicht geht, sondern nur mit dem Azure Active Directory PowerShell Modul (formerly known as Office365 Admin PowerShell Modul). Dieses wiederum braucht für das Sign-In noch den Microsoft Online Sign-In Assistenten. Aber selbst dann konnte ich mich nicht zum AAD verbinden, erst nachdem ich in AAD selbst über die GUI einen weiteren Azure-Amin angelegt hatte.

Wenn man sich diese beiden Benutzer mal anschaut (Azure-Portal, Verzeichnisdienst, Benutzer), dann sieht man einen Unterschied, und zwar in der Spalte “Quelle”. Der Benutzer, der nicht funktioniert hat, steht dort mit der Quelle “Microsoft-Konto”, der Benutzer, mit dem man sich anmelden kann, hat als Quelle “Microsoft Azure Active Directory”. Beide sind aber “Globaler Administrator” und mit beiden kann ich mich am Portal anmelden, aber nur mit einem der beiden per PowerShell, und zwar mit dem “Azure”-User und nicht mit dem “Microsoft”-User. Was ist jetzt aber der Unterschied?

Wenn man sich zum ersten Mal (als neuer Tenant quasi) bei Azure anmelden möchte, zum Beispiel für den kostenlosen Azure-Test-Zugang, dann steht da am unteren Ende der Webseite ein Link “Haben Sie noch kein Microsoft Konto? Jetzt registrieren”. Klickt man da drauf, dann wird ein – wie es da auch steht – Microsoft Konto angelegt, auch bekannt als Live-ID, MSA etc. Das ist zum Beispiel so etwas wie “tom@wigand.de”.  Kaum angelegt, kann man seine Azure-Subscription (im obigen Beispiel kostenfrei) testen und sich anmelden. Prima. Aber genau dieser Benutzer funktioniert nicht mit den Azure Active Directory PowerShell Modul. Weil… das ist ein Microsoft-Konto, kein Azure-AD-Konto. Und das PowerShell-Modul kann nur mit Azure-AD-Konten. Erst nachdem man einen “reinen” Azure-AD-Benutzer angelegt hat, ist der Connect möglich. Was passiert da im Hintergrund?

Azure legt den Benutzer als Microsoft-Konto (MSA) an und gleichzeitig wird eine AD-Domäne zeugt, die eine Unterdomäne (Subdomain) der Standard-Azure-AD-Domäne “onmicrosoft.com” ist. der Domänenname wird aus dem Startbenutzer hergeleitet, in unserem Beispiel wäre es wahrscheinlich so etwas wie “@tomwigand.onmicrosoft.com”.

Jetzt fragt man sich, warum dieser Umweg notwendig ist. Nun, eigentlich ist er das gar nicht. Nur der Link auf der Anmeldeseite ist “schuld” daran. Nimmt man den direkten Weg über die Azure-Anmeldung für Organisationen, dann wird keine Live-ID, äh, ich meine kein Microsoft-Konto angelegt. Mit dem dort angegebenen Benutzer kann man dann auch direkt die PowerShell-Module verwenden. Der Unterschied der beiden Wege ist, dass beim Azure Unternehmensportal etwas mehr Informationen abgefragt werden, unter anderem auch noch eine Domäne.

Hier ein Bild der Eingabemaske. Wie man leicht testen kann, baut die Website den Domänennamen zuerst mal aus Vorname und Nachname auf:

image

 

Gibt man aber einen Unternehmensnamen ein, dann wird dieser als Vorschlag angezeigt (ohne Sonderzeichen):

image

 

Man kann aber in dem Feld auch direkt seinen Lieblingsnamen eingeben… Die Folgeseiten spare ich mir, es ging ja nur um den Unterschied der beiden Benutzertypen. Da kommt nur eine Verifizierung der Mailadresse und Eingabe der Kreditkartennummer (und nein, da wird nix abgebucht. Ehrlich!)

Nochmal die Zusammenfassung:

  1. Der Link auf der (leider) weiter verbreiteten Azure-“kostenfrei-testen”-Webseite legt ein Microsoft Account an, das wiederum auf einen Azure-AD-Benutzer abgebildet wird, in dem aus der Mailadresse und “onmicrosoft.com” eine Azure-AD-Domäne automatisch konstruiert wird. Dieses Konto ist nicht für das Azure Active Directory PowerShell Modul geeignet.
  2. Der Link zur Azure-Anmeldung für Unternehmen legt direkt einen Azure-AD-User an, und der kann auch direkt für das PowerShell-Modul verwendet werden.

So. Alle Klarheiten beseitigt?

Veröffentlicht unter Active Directory, Azure | Verschlagwortet mit , | Kommentar hinterlassen

Azure PowerShell 0.9.5

Es gibt (wieder einmal) eine neue Version der Azure PowerShell. Und wieder mit einer solchen Menge an neuen Cmdlets und Kommandos, dass die Liste ziemlich lang wird. Ich fasse mal etwas zusammen:

Azure RedisCache: unter anderem für:

  • AzureApplicationGateway (New, Start, Stop, Set, Get, Remove)
  • AzureApplicationGatewayBackendAddressPool (New, Add, Set, Get, Remove)
  • AzureApplicationGatewayBackendHttpSettings (New, Add, Set, Get, Remove)
  • AzureApplicationGatewayFrontendIPConfiguration (New, Add, Set, Get, Remove)
  • AzureApplicationGatewayFrontendPort (New, Add, Set, Get, Remove)
  • AzureApplicationGatewayGatewayIPConfiguration (New, Add, Set, Get, Remove)
  • AzureApplicationGatewayHttpListener (New, Add, Set, Get, Remove)
  • AzureApplicationGatewayRequestRoutingRule (New, Add, Set, Get, Remove)
  • AzureApplicationGatewaySku (New, Set, Get)
  • AzureApplicationGatewaySslCertificate (New, Add, Set, Get, Remove)
  • AzureRouteTable (New, Set, Get, Remove)
  • AzureRouteConfig (New, Add, Set, Get, Remove)
  • Get-AzureCheckDnsAvailablity heißt jetzt Test-AzureDnsAvailability

Azure Network:

  • “-VirtualIPName” als neuer Parameter bei einigen Cmdlets

Azure Backup:

  • AzureBackupVault (New, Set, Get, Remove)
  • AzureBackupVaultCredential (Get)

Azure Traffic Manager:

  • AzureTrafficManagerProfile (Enable, Disable)
  • AzureTrafficManagerEndpoint (New, Add, Set, Get, Remove, Enable, Disable)

 

Wie üblich die Links: Web Platform Installer | Windows Standalone

Veröffentlicht unter Azure, PowerShell | Kommentar hinterlassen