Lösung

Installieren der SharePoint Online Management Shell

Verbindung mit SharePoint Online via PowerShell herstellen. Dazu ein PowerShell-Fenster öffnen und den nachfolgenden Befehl eingeben. Im Anmeldefenster einen Benutzer mit Administrationsrechten verwenden und anmelden

Connect-SPOService

Als nächstes muss die URL des gewünschten OneDrives des gelöschten Benutzers herausgefunden werden.

Generell setzt sich die URL aus dem Azure Tenant Namen und dem Benutzernamen zusammen

https://<tenant name>-my.sharepoint.com/personal/<user principal name> 

Diese URL fügt man nun in den nachfolgenden Befehl ein. zusätzlich wird noch ein Benutzerkonto mit Berechtigungen zum Zugriff auf das OneDrive benötigt. Der vollständigen UPN muss ebenfalls in den Befehl integriert werden. Anschließend den Befehl ausführen

Set-SPOUser -Site URLDERONEDRIVESEITE -IsSiteCollectionAdmin $true -LoginName BENUTZERMITBERECHTIGUNG

Nach absetzen des Befehls ist dem Benutzer der Zugriff auf das OneDrive erteilt und er kann über den vorher herausgesuchten Link darauf zugreifen.

Der Beitrag Auf OneDrive eines gelöschten Benutzers zugreifen erschien zuerst auf Daniel Gutermuth.

Generelle Voraussetzungen:

• Eine existierende AD-Umgebung welche korrekt mittels Azure-AD-Sync nach Azure AD synchronisiert
• Mindestens einen der Domäne beigetretenen Computer
• Regionale Verfügbarkeit des Dienstes
• Sicherheit darüber, dass Azure Files prinzipiell funktioniert. Als Test kann eine Dateifreigabe mittels Speicherkontenschlüssel erstellt und getestet werden. Diese muss funktionieren!

Der Beitrag ist extra so kurz wie möglich gehalten und beschreibt nur die wichtigsten Schritte. Weitere, sowie tiefgründigere Informationen, sind der Microsoft Dokumentation zu entnehmen.

Lösung

Vorhandenes Speicherkonto auswählen oder ein neues erstellen.

Das Archiv „AzureFilesHybrid“ von GitHub herunterladen und entpacken.

Hinweis: Dies und das Nachfolgende auf einem Computer durchführen, welcher der lokalen Domäne beigetreten ist. Außerdem sicherstellen, dass ein AD-Konto verwendet wird, welches mindestens das Recht besitzt einen Dienstbenutzer (service log on account) zu erstellen.

PowerShell-Terminal öffnen und folgende Befehle ausführen und bestätigen:

Install-Module -Name az -AllowClobber -Scope CurrentUser
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

In der PowerShell-Sitzung in den Ordner des entpackten „AzureFilesHybrid“ Archives wechseln und folgende Befehle ausführen und bestätigen:

.\CopyToPSPath.ps1
Import-Module -Name AzFilesHybrid -Verbose

Eine Verbindung mit dem Azure-Online-Dienst aufbauen. Dazu mit dem gewünschten Azure-Konto anmelden und sicherstellen, dass das korrekte Abo ausgewählt wurde. Sollte das falsche Abo vorausgewählt sein, kann es mit einem optionalen Befehl gewechselt werden.

Connect-azaccount

Optional bei falschem Abo:
Select-AzSubscription -SubscriptionId "ID"

Erstellung und Zuweisung eines Service-Benutzers zur Authentifizierung des Azure Speicherkontos. Dabei eine OU angeben unter welcher der Benutzer erstellt werden soll.

Hinweis: Darauf achten, dass das Passwort des Dienstbenutzers nicht abläuft! (Sollte „Kennwort läuft nie ab“ nicht verwendet werden)

Join-AzStorageAccountForAuth -ResourceGroupName "Ressourcengruppenname" -Name "Speicherkontoname" -Domain "lokale Domäne" -DomainAccountType ServiceLogonAccount -OrganizationalUnitDistinguishedName "Gewünschte OU"

Anschließend kann der erstellte Benutzer in der angegebenen OU des ADs gefunden werden.

Als nächstes sollte die Konfiguration überprüft werden. Dazu ggf. ein zweites PowerShell-Fenster öffnen und folgende Informationen auslesen lassen und temporär merken.

$domainInformation = Get-ADDomain
$domainGuid = $domainInformation.ObjectGUID.ToString()
$domainName = $domainInformation.DnsRoot
$domainGuid
$domainName

Die nachfolgenden Befehle in das erste PowerShell-Fenster eingeben und prüfen, ob die angezeigten Informationen passen.

$storageacccount = Get-AzStorageAccount -ResourceGroupName "Ressourcengruppenname" -Name "Speicherkontoname"
$storageacccount | Get-AzStorageAccountKey -ListKerbKey | Format-Table Keyname
# Es sollten Schlüsselnamen angezeigt werden
$storageacccount.AzureFilesIdentityBasedAuth.DirectoryServiceOptions
# Ergebnis sollte "AD" sein
$storageacccount.AzureFilesIdentityBasedAuth.ActiveDirectoryProperties
# Die informationen sollten mit denen aus dem zweiten PowerShell-Fenster übereinstimmen(DomainName und DomainGUID)

Über das Azure-Portal können, in der Konfiguration des Speicherkontos, die Freigabeberechtigungen (via IAM) vorgenommen werden. Folgende Rollen sind hierfür relevant:

Hinweis: Alternativ können Berechtigungen auch direkt über die Freigabe im Windows-Explorer (ACL) vorgenommen werden.

Zuletzt den Azure Fileshare via CMD mounten damit er über den Explorer verwendet werden kann.

net use LAUFWERKBUCHSTABE: \\SPEICHERKONTONAME.file.core.windows.net\FREIGABENAME

Hinweis: Die Eingabeaufforderung muss als „normaler“ Benutzer ausgeführt werden und nicht als Administrator!

Der Beitrag Azure Files – Hybrid AD-Authentifizierung für Azure File Shares erschien zuerst auf Daniel Gutermuth.

Welcher Migrationsansatz gewählt wird, ist vom jeweiligen Einzelfall abhängig. Bei kleinen und eher standardmäßigen Umgebungen, kann eine CutOver-Migration eine vailide Lösung sein.

Bei einer CutOver-Migration wird im Exchange Admin Center (online) ein sogenannter Migrationsbatch erstellt. Dieser stellt sicher, dass die lokalen Postfächer nach Exchange Online verschoben werden. Dabei baut Exchange Online eine Verbindung via EWS mit dem lokalen Exchange Server auf.

Damit alles ohne Fehler funktioniert, gibt es ein paar Dinge zu beachten.

Dieser Beitrag geht davon aus, dass bereits eine Anbindung an das Azure AD besteht, inkl. Azure AD Connect. Nun soll „nur“ noch der lokale Exchange Server durch Exchange Online ersetzt werden. Ein Hybrid-Modus ist nicht vorgesehen!

Hinweis: Alles auf eigene Gefahr! Dies ist keine Anleitung. Super Anleitungen sind u. a. hier zu finden.

Lösung

• EWS konfigurieren

Exchange Online holt sich Informationen über Benutzer und deren Daten direkt per EWS. So muss der lokaler Exchange Server zumindest von Exchange Online (Microsoft 365) per HTTPS erreichbar sein.

Für diese Verbindung wird zwingend ein gültiges Trusted-SSL-Zertifikat benötigt!

• Lokale SMTP-Adressen entfernen

Lokale SMTP-Adressen (z. B. benutzer@domäne.local) müssen vor der Migration entfernt werden, sonst schlägt der Migrationsbatch fehl.

Erledigt werden kann dies lokal mit PowerShell und dem Befehl:

Set-Mailbox "Benutzer Name" -EmailAddresses @{remove="BenutzerName@domäne.local"}

• onmicrosoft SMTP-Adresse hinzufügen

Jeder Microsoft 365-Tenant besitzt automatisch eine Standard onmicrosoft-Domäne.

Diese Domäne muss als SMTP-Adresse bei jedem Migrationsobjekt vor Migrationsbeginn hinzugefügt werden.

Auch hier kann PowerShell die Arbeit lokal erledigen:

Set-Mailbox "Benutzer Name" -EmailAddresses @{Add="BenutzerName@XXXXonmicrosoft.com"}

• „Hybrid“-Dienstkonto für Postfächer einrichten

Damit die Postfächer nach Exchange Online migriert und dort konfiguriert werden können, muss ein Dienstkonto erstellt werden, welches auf die Objekte Vollzugriff besitzt. Dieses Konto muss lokal, sowie in der Cloud bereitstehen.

Über PowerShell kann der Vollzugriff auf die lokalen Postfächer erteilt werden:

Add-MailboxPermission -Identity "Benutzerpostfachkonto" -User "DienstBenutzer" -AccessRights FullAccess -InheritanceType All

Nach Abschluss der Migration kann der Vollzugriff wieder entfernt werden!

• Migrationsbatch

Anschließend wird im Exchange Admin Center (online) der Migrationsbatch über den Assistenten erstellt. Hier werden u.a. der Dienstbenutzer, sowie die EWS-Verbindung benötigt.

Nach Abschluss des Assistenten, kann der Migrationsbatch gestartet und damit die Postfächer synchronisiert werden.

Hinweis: Ein Start des Batches bedeutet noch keine Cut-Over-Migration! Der Migrationsbatch kopiert alle Postfächer nach Exchange Online und synchronisiert anschließend alle 24 Stunden deren Delta. Erst wenn der Migrationsbatch explizit vom Benutzer im Exchange Admin Center (online) abgeschlossen wird, synchronisiert er zum letzten Mal das Delta und beendet die Migration anschließend.

Das ist besonders hilfreich, wenn eine hohe Datenmenge migriert werden muss, aber nur eine begrenze Internetanbindung besteht. So kann das Verschieben der Postfächer auf mehrere Tage verteilt werden, ohne dass die bestehende Exchange-Umgebung beeinträchtigt wird.

• MX-Eintrag

Sobald der Migrationsbatch explizit abgeschlossen wurde, muss natürlich noch der MX-Eintrag im DNS umgestellt werden. Ab diesem Zeitpunkt werden die E-Mails von Exchange Online verwaltet.

Tipp: Hier ist es empfehlenswert ein Wartungsfenster einzurichten und den lokalen Exchange-Server für die Benutzer zu sperren. Anschließend den Migrationsbatch beenden und ein letztes Mal synchronisieren lassen. Damit ist sichergestellt, dass die Postfächer jeweils auf einem aktuellen Stand sind.

Hinweis: Die lokalen Postfächer nach der Migration nicht löschen, da dadurch die AD-Benutzer ebenfalls gelöscht werden würden. Nur deaktivieren!

• Autodiscover

Auch der Autodiscover muss abgeändert werden. Dies gilt sowohl für lokale Ressourcen (DNS) als auch für externe Ressourcen (DNS).

Anmerkungen

Jede Exchange-Umgebung ist anders aufgebaut und somit können noch weitere Schritte anfallen.

Am Ende steht die Deprovisionierung bzw. Deinstallation des lokalen Exchange Servers. Man muss sich im Klaren sein, dass die vollständigen Deinstallation des Exchange Servers aus der Domäne fatale Folgen mit sich ziehen kann, wenn vorher nicht alles korrekt ausgeführt wurde.

Daher immer doppelt prüfen und Backups machen!

Der Beitrag Exchange Online – Was gibt es alles bei einer CutOver Migration zu beachten? erschien zuerst auf Daniel Gutermuth.

Damit solche Maschinen ihre Wiederherstellungskennwörter an das Azure AD übertragen, kann mit PowerShell nachgeholfen werden.

Lösung

Im ersten Script wird das Wiederherstellungskennwort des Systemlaufwerkes in das Azure AD gesichert. Der Mount Point bzw. der Laufwerksbuchstabe wird mit der Umgebungsvariablen $env:SystemDrive ermittelt.

Die Ausführung des Skriptes muss nicht mit den Anmeldedaten des aktuellen Benutzers erfolgen.

try{
$BLV = Get-BitLockerVolume -MountPoint $env:SystemDrive
        $KeyProtectorID=""
        foreach($keyProtector in $BLV.KeyProtector){
            if($keyProtector.KeyProtectorType -eq "RecoveryPassword"){
                $KeyProtectorID=$keyProtector.KeyProtectorId
                break;
            }
        }

       $result = BackupToAAD-BitLockerKeyProtector -MountPoint "$($env:SystemDrive)" -KeyProtectorId $KeyProtectorID
return $true
}
catch{
     return $false
}

Natürlich kann dieses Script auch in Intune eingebunden werden. Für bereits vorhandene BitLocker Bestandsmaschinen, kann damit unkompliziert der Wiederherstellungsschlüssel in das Azure AD gesichert werden.

Generell empfiehlt sich aber die Verwendung der entsprechenden BitLocker Richtlinie in Intune.

Dies wären die Einstellungen.

Eine Abwandlung des ersten Scripts ist in Script zwei zu finden. Hier wird das Wiederherstellungskennwort eines bestimmten Laufwerkes in das Azure AD gesichert.

Definiert wird das Laufwerk durch die Variable $MP (In diesem Beispiel D:)

try{
$MP = "D:"
$BLV = Get-BitLockerVolume -MountPoint $MP
        $KeyProtectorID=""
        foreach($keyProtector in $BLV.KeyProtector){
            if($keyProtector.KeyProtectorType -eq "RecoveryPassword"){
                $KeyProtectorID=$keyProtector.KeyProtectorId
                break;
            }
        }

       $result = BackupToAAD-BitLockerKeyProtector -MountPoint "$($MP)" -KeyProtectorId $KeyProtectorID
return $true
}
catch{
     return $false
}

In Intune stellt sich die Frage, warum es 41 Errors bei der Ausführung gab.

Das liegt daran, dass diese 41 Geräte kein Laufwerk D besitzen und das Script so nicht „erfolgreich“ abschließen konnte. Die Errors können daher, nach einer Verifizierung, ignoriert werden.

Auch hier die Einstellungen.

Es gibt sicherlich elegantere Methoden. Diese hier ist, wenn es um BitLocker Bestandsmaschinen geht, die ansonsten nicht Reporten wollen, bisher immer zuverlässig.

Der Beitrag BitLocker Wiederherstellungskennwort mit PowerShell in das Azure AD sichern erschien zuerst auf Daniel Gutermuth.

Azure VMs werden standardmäßig (meistens) mit einem mindestens 128GB Datenträger ausgeliefert. Für Tests oder andere Anwendungsfälle kann dies Speicherplatz sein, der zwar nicht benötigt wird, aber trotzdem bezahlt werden muss. Wird bei den VMs auch noch SSD-Speicher eingesetzt, kann dies mit erheblichen Kosten verbunden sein.

Da Azure die Verkleinerung innerhalb des Azure Portals nicht unterstützt, muss auf eine andere Methode zurückgegriffen werden.

Mit den hier gezeigten Schritten ist es möglich den Betriebssystemdatenträger zu verkleinern und so bis zu 25% an Kosten einzusparen.

Voraussetzungen

Azure: VM Contributor und Storage Account Contributor, sowie Zugriffsrechte auf Managed Disks

Hinweis: Alles auf eigene Gefahr!

Lösung

Im ersten Schritt auf die Virtuelle Azure VM aufschalten.

Über die Systemsteuerung oder Rechtsklick auf den Start-Button die Datenträgerverwaltung öffnen. In der Datenträgerverwaltung die Windows-Partition mit Rechtsklick anwählen und auf Volumen verkleinern klicken.

Im nächsten Fenster muss der zu verkleinernde Speicherplatz in MB angegeben werden.

Hier kommt es darauf an, welche Festplattengröße nach der Verkleinerung bestehen soll. In diesem Beispiel möchte ich aus einem 128GB Volumen ein maximal 32GB Volumen machen. Dazu muss der zu verkleinernde Speicherplatz mit 100000MB ( ca. 100GB) angegeben werden. Als Gesamtspeicherplatz nach der Verkleinerung werden nun 29547 MB (ca. 29GB) angegeben, was in das angestrebte 32GB Budget passt. Mit verkleinern bestätigen.

Hinweis: Für die Speicherplatzkalkulation sind auch andere Partitionen des Datenträgers wie „System reserviert“ mit anzurechnen. Der Datenträger des temporären Speichers ist nicht relevant.

Nach der Verkleinerung sollte die Windows-Partition auf die angestrebte Speichergröße verkleinert worden und ein Block mit nicht zugewiesenem Speicherplatz entstanden sein.

Hinweis: Das war es leider noch nicht. Microsoft wird immer noch die kompletten 128GB in Rechnung stellen, da uns der Speicherplatz in der Theorie bereitstehen würde. Es muss also nicht nur der Speicherplatz auf Windows-Ebene angepasst werden, sondern auch auf Azure Infrastruktur-Ebene. In diesem Fall soll aus einer physikalischen 128GB Festplatte eine 32GB Festplatte werden.

Die VM herunterfahren.

In das Azure Portal gehen und die Übersichtsseite der virtuellen Maschine öffnen.

Die VM dort beenden.

Warten bis die Zuordnung aufgehoben wurde.

Anschließend von der VM-Übersichtsseite in den Reiter Datenträger wechseln und dort auf den Betriebssystemdatenträger klicken.

In diesem Fenster in den Punkt Eigenschaften wechseln und den Link der Ressourcen-ID zwischenspeichern.

Als letzte Information wird der Abo-Name oder die Abo-ID benötigt. Beide Informationen können über Abonnements herausgefunden werden.

Nachdem alle Vorbereitungen getroffen und alle nötige Informationen zusammengetragen wurden, geht es nun an die Umsetzung. Als Hilfe dient uns hierbei ein vollautomatisches PowerShell-Script

Was macht dieses Script? :

• Erstellung eines temporären Speicherkontos
• Erstellung eines temporären Datenträgers in diesem Speicherkonto
• Kopieren des Bestandsdatenträgers in das temporäre Speicherkonto
• Speicherplatzverkleinerung des kopierten Bestandsdatenträgers
• Konvertierung zu einer Managed Disk
• Austausch des alten Bestandsdatenträgers mit dem neuen Datenträger
• Löschen des temporären Speicherkontos, sowie der darin befindlichen, temporären Datenträgern

# Variables
$DiskID = "DISKID" #Hier die Ressourcen-ID eintragen
$VMName = "VMNAME" #Hier den VM-Namen eintragen
$DiskSizeGB = 32 #Hier die gewünschte Speichergröße eintragen
$AzSubscription = "ABONAME" #Hier den Abo-Namen oder die Abo-ID eintragen
$Sku = "Standard_LRS" #Zur Auswahl: Standard_LRS (HDD), StandardSSD_LRS (SSD) Premium_LRS (Premium SSD)

# Script
# Provide your Azure admin credentials
Connect-AzAccount

#Provide the subscription Id of the subscription where snapshot is created
Select-AzSubscription -Subscription $AzSubscription

# VM to resize disk of
$VM = Get-AzVm | ? Name -eq $VMName

#Provide the name of your resource group where snapshot is created
$resourceGroupName = $VM.ResourceGroupName

# Get Disk from ID
$Disk = Get-AzDisk | ? Id -eq $DiskID

# Get VM/Disk generation from Disk
$HyperVGen = $Disk.HyperVGeneration

# Get Disk Name from Disk
$DiskName = $Disk.Name

# Get SAS URI for the Managed disk
$SAS = Grant-AzDiskAccess -ResourceGroupName $resourceGroupName -DiskName $DiskName -Access 'Read' -DurationInSecond 600000;

#Provide the managed disk name
#$managedDiskName = "yourManagedDiskName" 

#Provide Shared Access Signature (SAS) expiry duration in seconds e.g. 3600.
#$sasExpiryDuration = "3600"

#Provide storage account name where you want to copy the snapshot - the script will create a new one temporarily
$storageAccountName = "shrink" + [system.guid]::NewGuid().tostring().replace('-','').substring(1,18)

#Name of the storage container where the downloaded snapshot will be stored
$storageContainerName = $storageAccountName

#Provide the key of the storage account where you want to copy snapshot. 
#$storageAccountKey = "yourStorageAccountKey"

#Provide the name of the VHD file to which snapshot will be copied.
$destinationVHDFileName = "$($VM.StorageProfile.OsDisk.Name).vhd"

#Generate the SAS for the managed disk
#$sas = Grant-AzureRmDiskAccess -ResourceGroupName $resourceGroupName -DiskName $managedDiskName -Access Read -DurationInSecond $sasExpiryDuration

#Create the context for the storage account which will be used to copy snapshot to the storage account 
$StorageAccount = New-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName -SkuName $Sku -Location $VM.Location
$destinationContext = $StorageAccount.Context
$container = New-AzStorageContainer -Name $storageContainerName -Permission Off -Context $destinationContext

#Copy the snapshot to the storage account and wait for it to complete
Start-AzStorageBlobCopy -AbsoluteUri $SAS.AccessSAS -DestContainer $storageContainerName -DestBlob $destinationVHDFileName -DestContext $destinationContext
while(($state = Get-AzStorageBlobCopyState -Context $destinationContext -Blob $destinationVHDFileName -Container $storageContainerName).Status -ne "Success") { $state; Start-Sleep -Seconds 20 }
$state

# Revoke SAS token
Revoke-AzDiskAccess -ResourceGroupName $resourceGroupName -DiskName $DiskName

# Emtpy disk to get footer from
$emptydiskforfootername = "$($VM.StorageProfile.OsDisk.Name)-empty.vhd"

# Empty disk URI
#$EmptyDiskURI = $container.CloudBlobContainer.Uri.AbsoluteUri + "/" + $emptydiskforfooter

$diskConfig = New-AzDiskConfig `
    -Location $VM.Location `
    -CreateOption Empty `
    -DiskSizeGB $DiskSizeGB `
    -HyperVGeneration $HyperVGen

$dataDisk = New-AzDisk `
    -ResourceGroupName $resourceGroupName `
    -DiskName $emptydiskforfootername `
    -Disk $diskConfig
    

$VM = Add-AzVMDataDisk `
    -VM $VM `
    -Name $emptydiskforfootername `
    -CreateOption Attach `
    -ManagedDiskId $dataDisk.Id `
    -Lun 63

Update-AzVM -ResourceGroupName $resourceGroupName -VM $VM

$VM | Stop-AzVM -Force


# Get SAS token for the empty disk
$SAS = Grant-AzDiskAccess -ResourceGroupName $resourceGroupName -DiskName $emptydiskforfootername -Access 'Read' -DurationInSecond 600000;

# Copy the empty disk to blob storage
Start-AzStorageBlobCopy -AbsoluteUri $SAS.AccessSAS -DestContainer $storageContainerName -DestBlob $emptydiskforfootername -DestContext $destinationContext
while(($state = Get-AzStorageBlobCopyState -Context $destinationContext -Blob $emptydiskforfootername -Container $storageContainerName).Status -ne "Success") { $state; Start-Sleep -Seconds 20 }
$state

# Revoke SAS token
Revoke-AzDiskAccess -ResourceGroupName $resourceGroupName -DiskName $emptydiskforfootername

# Remove temp empty disk
Remove-AzVMDataDisk -VM $VM -DataDiskNames $emptydiskforfootername
Update-AzVM -ResourceGroupName $resourceGroupName -VM $VM

# Delete temp disk
Remove-AzDisk -ResourceGroupName $resourceGroupName -DiskName $emptydiskforfootername -Force;

# Get the blobs
$emptyDiskblob = Get-AzStorageBlob -Context $destinationContext -Container $storageContainerName -Blob $emptydiskforfootername
$osdisk = Get-AzStorageBlob -Context $destinationContext -Container $storageContainerName -Blob $destinationVHDFileName

$footer = New-Object -TypeName byte[] -ArgumentList 512
write-output "Get footer of empty disk"

$downloaded = $emptyDiskblob.ICloudBlob.DownloadRangeToByteArray($footer, 0, $emptyDiskblob.Length - 512, 512)

$osDisk.ICloudBlob.Resize($emptyDiskblob.Length)
$footerStream = New-Object -TypeName System.IO.MemoryStream -ArgumentList (,$footer)
write-output "Write footer of empty disk to OSDisk"
$osDisk.ICloudBlob.WritePages($footerStream, $emptyDiskblob.Length - 512)

Write-Output -InputObject "Removing empty disk blobs"
$emptyDiskblob | Remove-AzStorageBlob -Force


#Provide the name of the Managed Disk
$NewDiskName = "$DiskName" + "-new"

#Create the new disk with the same SKU as the current one
$accountType = $Disk.Sku.Name

# Get the new disk URI
$vhdUri = $osdisk.ICloudBlob.Uri.AbsoluteUri

# Specify the disk options
$diskConfig = New-AzDiskConfig -AccountType $accountType -Location $VM.location -DiskSizeGB $DiskSizeGB -SourceUri $vhdUri -CreateOption Import -StorageAccountId $StorageAccount.Id -HyperVGeneration $HyperVGen

#Create Managed disk
$NewManagedDisk = New-AzDisk -DiskName $NewDiskName -Disk $diskConfig -ResourceGroupName $resourceGroupName

$VM | Stop-AzVM -Force

# Set the VM configuration to point to the new disk
Set-AzVMOSDisk -VM $VM -ManagedDiskId $NewManagedDisk.Id -Name $NewManagedDisk.Name

# Update the VM with the new OS disk
Update-AzVM -ResourceGroupName $resourceGroupName -VM $VM

$VM | Start-AzVM

start-sleep 180
# Please check the VM is running before proceeding with the below tidy-up steps

# Delete old Managed Disk
Remove-AzDisk -ResourceGroupName $resourceGroupName -DiskName $DiskName -Force;

# Delete old blob storage
$osdisk | Remove-AzStorageBlob -Force

# Delete temp storage account
$StorageAccount | Remove-AzStorageAccount -Force

Das obere Script kann in das PowerShell-ISE kopiert, die entsprechenden Werte angepasst und dann ausgeführt werden. Für die Ausführung des Scripts werden spezielle PS-Module benötigt. Die Installation dieser Module mit Ja bestätigen.

Darauf achten, dass die Anmeldung bei Azure mit dem korrekten Konto erfolgt!

Je nach Umfang kann es eine Weile dauern, bis das Script fertig ist. Im besten Fall wurde es ohne Fehler durchlaufen.

Hinweis: Bei Fehlern empfiehlt es sich das Script Schritt-für-Schritt auszuführen.

Den Erfolg können wir über das Azure Portal verifizieren.

Im letzten Schritt wieder auf die VM aufschalten und in die Datenträgerverwaltung wechseln.

Dort finden wir u.u. einen kleinen Block mit nicht zugewiesenem Speicherplatz.

Dieser kann durch einen Rechtsklick auf die Windows-Partition mit Volumen erweitern dieser Partition hinzugefügt werden.

Nachdem der Assistent durchlaufen wurde, lässt ich auch in Windows verifizieren, dass aus einer 128GB Festplatte eine 32GB Festplatte gemacht wurde.

Als Basis der Microsoft Abrechnung wird nun eine 32 GB Festplatte zugrunde gelegt.

Der Beitrag Azure – Azure VM Festplatte verkleinern mit PowerShell erschien zuerst auf Daniel Gutermuth.

Dies muss gemacht werden, da Azure AD nicht mit privaten TLDs (domain.local, domain.intra) arbeiten kann.

Domäne:

• danielgutermuth.local = privat
• danielgutermuth.de = öffentlich

Benutzer:

• Benutzer@danielgutermuth.local = privat
• Benutzer@danielgutermuth.de = öffentlich

Hinweis: Es muss der Suffix verwendet werden, welcher auch in Microsoft 365 / Office 365 registriert ist und verwendet wird. Ist bei Microsoft 365 / Office 365 die Domain danielgutermuth.de registriert, dann muss der Suffix danielgutermuth.de auch lokal verwendet werden.

Lösung

Für die Umstellung des UPN-Suffixes auf dem Domänencontroller Active Directory-Domänen und -Vertrauensstellungen öffnen. Anschließend einen Rechtsklick auf Active Directory-Domänen und -Vertrauensstellungen machen und in die Eigenschaften gehen.

Im öffnenden Fenster den entsprechenden UPN-Suffix eintragen, hinzufügen und mit OK bestätigen.

Nun müssen die AD-Benutzer aktualisiert werden. Da eine manuelle Umstellung jedes einzelnen Benutzer eine sehr langwierige Aufgabe wäre, löst man es am besten mit PowerShell.

Im unteren Beispiel werden die UPN-Suffixe aller Benutzer mit dagu.local mit danielgutermuth.de ersetzt

$LocalUsers = Get-ADUser -Filter {UserPrincipalName -like '*dagu.local'} -Properties UserPrincipalName -ResultSetSize $null
$LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("dagu.local","danielgutermuth.de"); $_ | Set-ADUser -UserPrincipalName $newUpn}

Um sicher zu gehen, dass kein Benutzer mehr den alten Suffix enthält, muss der Output des nachfolgenden Scripts leer sein.

Get-ADUser -Filter {UserPrincipalName -like '*local'} | Sort-Object Name | Format-Table Name, UserPrincipalName

Der Beitrag Azure AD – UPN Suffix ändern erschien zuerst auf Daniel Gutermuth.