Dekommissionierte Server aus Microsoft Azure Arc entfernen

Manchmal sind Server „weg“, bevor sie ordentlich bei Azure Arc ge-offboarded wurden; das Offboarding ist nicht immer Teil eines Dekomissionierungsprozesses. Die „veralteten“ Maschinen bleiben dann Teil des Azure Arc und liefern einfach keine Daten mehr. Diese können natürlich weg.

Lösung

Leider hat Microsoft „vergessen“ im GUI die notwendigen Knöpfe einzubauen. Das wäre aber logisch, sinnvoll und einfach.

So wird man Maschienen aus Azure Arc an der PowerShell (als Aministrator) los:

# Az Modul installieren
Install-Module Az.ConnectedMachine

# Mit Azure Arc verbinden
Connect-AzAccount

# Maschine ansehen
Get-AzConnectedMachine -Name <SERVERNAME> -ResourceGroupName <RESSOURCENGRUPPE>

# Maschine entfernen
Get-AzConnectedMachine -Name <SERVERNAME> -ResourceGroupName <RESSOURCENGRUPPE>| Remove-AzConnectedMachine

Veeam B&R Upgrade auf v13 schlägt fehlt mit der Fehlermeldung „Outdated Veeam Agents“

Manchmal zeigt die B&R (noch 12) Konsole keine verwalteten Agents an, oder das Setup auf v13 beschwert sich das ein nicht aufgeführter Agent „outdated“ sei.

„Outdated Veeam Agents“ (Configuration Check)

Es gibt in der „Physical Infrastructure“ aber keine Agenten, die Liste ist leer. Oder zumindest keinen, der dem angezeigten Namen des Setups entspricht.

Lösung

In der Veeam-Datenbank spukt noch ein Agent herum, der zwar nicht angezeigt, aber trotzdem noch für „managed“ gehalten wird.

Der Agent muss manuell aus der Veeam-Datenbank entfernt werden. Am Beispiel ier wird PostgreSQL genutzt, für Microsoft SQL Datenbanken kann der Vorgang analog mit den jeweils passenden Tools ausgeführt werden.

Erstelle eine Datei .\query1.sql mit dem folgenden Inhalt:

SELECT epagents.host_id, epagents.agent_version, ephosts.display_name
FROM "public"."backup.model.epagents" AS epagents
INNER JOIN "public"."backup.model.ephosts" AS ephosts ON epagents.host_id=ephosts.id
WHERE ephosts.display_name = 'EXAMPLE-AGENTENNAME'
ORDER BY  epagents.agent_version ASC;

… und führe diese in der Veeam-Datenbank aus (Pfad zu psql entsprechend anpassen):


"C:\Program Files\PostgreSQL\15\bin\psql" -d VeeamBackup -U postgres -f .\query1.sql

Dann gibt die Konsole die entsprechenden Agenten-IDs aus.

Selbige kann man dann mit einem zweiten SQL-Script (z.B. query2.sql) entfernen:

SELECT public.deleteephost('AGENTEN-ID-HIER-EINFUEGEN');
SELECT public.deleteepagent('AGENTEN-ID-HIER-EINFUEGEN');

… und schon ist der Agent so richtig und wirklich ganz entfernt.

„Self-Service-Testversionen“ in Microsoft 365 vollständig deaktivieren

„Self-Service-Testversionen“ sind kostenlose Testphasen für Microsoft 365 Apps und Services, die Nutzer eigenständig und ohne Einbindung der IT aktivieren können.

Testversionen ermöglichen dem Nutzenden in der Regel „sofort“ Zugriff auf Premium-Funktionen, laufen in der Regel 30 oder 90 Tage und können sich, sofern Zahlungsmethoden direkt bei Microsoft hinterlegt wurden, mehr oder weniger automatisch in kostenpflichtige Abonnements umwandeln.

Im Admin-Center Einstellungen > Organisation > Testversionen

Die ablenkenden Premium-Buttons in Apps von Teams bis PowerBI stellen eine nervige Werbung dar. Außerdem kommt es manchmal auch zu „spannende“ Situationen, wenn Nutzer eines Unternehmens ungewollt an der IT-Organisation vorbei, Prozesse in einer solchen Schatten-IT erstellen. Das geschieht, so unterstellen wir, zwar oft in guter Absicht, stellt aber eine schwelende Gefahr dar.

„Self-Service-Testversionen“ für alle Produkte via PowerShell abschalten

Wie es sich für einen kundenfernen Großkonzern wie Microsoft gehört, ist die Deaktivierung der Funktion(en) (es sind mehrere) eine fummelige Kleinarbeit im GUI – oder für Admins denkbar umständlich.

PowerShell, natürlich „als Administrator“ ausführen, als Globaler Admin am m365 anmelden.

# PS Modul installieren und verbinden
Install-Module -Name MSCommerce
Import-Module -Name MSCommerce
Connect-MSCommerce

# Optional: Produkte mit Erlaubnis auflisten
Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase

# Alles abschalten
Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | Where { $_.PolicyValue -eq "Enabled"} | ForEach { Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId $_.ProductID -Enabled $false }

Selbstverständlich muss das mit jedem neu erscheinenden Produkt erneut ausgeführt werden; die Einstellung gilt pro Produkt, nicht global.

Wie werden Lizenzen in AuthLite gezählt? Kann ein User mehrere MFA Token haben?

AuthLite ist seit langem die „Go To“ Lösung für die MFA-Absicherung von ActiveDirectory Domains. Vergleichsweise Günstig, vollständig lokal (On-Prem), Pertetual (kein Abomodell), extrem flexibel, sehr sicher und mit TOTP und Yubikeys nahezu universell verwendbar.

Lizenzierung nach …. Tokens?

Nein, tatsächlich zählen ausschließlich Benutzer: Jeder Benutzer der (mindestens) ein Token zugewiesen bekommen hat, braucht eine Lizenz. Unabhängig davon, wie viele oder welche Tokens ein Benutzer bekommt. Ein Nutzer kann also drei Handys mit verschiedenen TOTPs verwenden, einen Yubikey nutzen und einen Ersatz-Yubikey im Schrank einschliessen.

Um es in den Worten der Dokumentation zu sagen:

Each user account „takes up“ only one AuthLite user license, no matter how many OTP tokens you assign to them.

Azure Update Manager für Server in Betrieb nehmen (WSUS Nachfolge) – von Null

Der Azure Update Manager ist ein Dienst, der als designierter WSUS Nachfolger Updates für Server (Windows und Linux) verwalten kann. Azure Arc ist dabei die „Brücke“ zwischen Servern und der Azure Verwaltung, der Update Manager nutzt die Arc-Verbindung für das Update Management.

Wir wurden ein einige Male gefragt, wie man nun genau zu seinem Arc-Manager kommt. Auf die Lizenzierung, Kosten und die Konfiguration von Wartungsfenstern für Server geht dieser Artikel nicht ein.

Von „Null“ zum Azure Arc Update Manager

Zuerst braucht man eine Azure Subscription. Aktuell geht das auf zwei Arten:

  1. Azure Subscription mit einer Kreditkarte einrichten. Ohne CC geht es nicht.
  2. Azure Plan über einen guten CSP-Partner einrichten lassen. Wenn Kosten entstehen (und auch nur dann), bekommt man von diesem eine Rechnung. Außerdem kann der oft bei Problemen weiterhelfen.

Wenn das geschehen ist, hat man (mehr oder weniger automatisch) einen „Mandanten“ und durch den Plan/Subscription ein „Abonnoment“.

Nun braucht man noch eine „Ressourcengruppe„.

1. Das Azure Portal öffnen, einloggen und zu Ressourcengruppen wechseln, „Erstellen“ klicken.

    2. Abonnement auswählen, Namen (ohne Leerzeichen) vergeben. Dann mit „überprüfen und erstellen“ bestätigen.

    Das war es schon. Ab jetzt kann man den „AzureConnectedMachineAgent“ einrichten und verwenden.