Kategorie-Archiv: Allgemein

Bilder an der PowerShell mit Guetzli komprimieren (rekursiv)

Veröffentlicht am von — Keine Kommentare ↓

Mit der Kompression von JPGs mit dem Guetzli-Algorithmus spart man ganz ordentlich Platz auf der Platte, ohne Qualität zu verlieren.

Je nach Bild (und Quelle) sind gut und gerne 30-60% Ersparniss drin. Manche (Handy-)Kamera legt JPGs nämlich quasi unkomprimiert ab.

Ein kleines Bulk-Kompress-Script für die bash shell hatten wir hier ja schon. Aus aktuellem Anlass, hier die schnelle PowerShell-Variante (ohne Parameterfehler):

mach-huetzli.ps1 <Ordner>

param (
    [string]$path = (split-path -parent $MyInvocation.MyCommand.Definition)
)

# PFAD zum Guetzli Binary
$guetzli = "C:\PFAD ZU GUETZLI\guetzli_windows_x86-64.exe"

Get-ChildItem -Path $path -recurse -Include @("*.png","*.jpeg","*.jpg") | % {
    $in = $_.FullName
    $out = $in.Replace($_.Extension, '.compressed.jpg')
    write-host "Processing $out" -ForegroundColor Green

    & $guetzli --quality 85 `"$in`" `"$out`"
}

PowerShell: Computer nach Betriebssystem aus dem Active Directory auflisten

Veröffentlicht am von — Keine Kommentare ↓
Server nach Betriebssystem auflisten

Und wieder ein schneller PowerShell Schnipsel, den man als Admin häufiger mal brauchen kann.

Alle aktiven Computer nach Betriebssystem auflisten, oder auch nur alle Maschienen mit einer bestimmten Version ausgeben:

Get-ADComputer -Filter 'operatingsystem -like "Windows Server 2022*" -and enabled -eq "true"' -Properties Name,Operatingsystem,OperatingSystemVersion,IPv4Addres
s | ft Na*,Op*,IPv4*

Die ft Pipe am Ende sorgt nur für eine lesbare Ausgabe, weil Get-ADComputer sonst immer den vollständigen DN ausgibt.

Die Abfrage kann man so sehr schnell anpassen. Zum Beispiel für eine Ausgaben von ausschliesslich Client-PCs (-notlike "*server*"):

Get-ADComputer -Filter 'operatingsystem -notlike "*server*" -and enabled -eq "true"' -Properties Name,Operatingsystem,OperatingSystemVersion,IPv4Addres
s | ft Na*,Op*,IPv4*

PIN zurücksetzen Fehler“CAA2000B“ auf AzureAD „registered“ Geräten nach Office 365 Installation

Veröffentlicht am von — Keine Kommentare ↓

Man registriert sein Windows-Gerät, auch den Home-PC, automatisch ins Microsot 365 AzureAD eines Unternehmens, indem man nach einer Office 365 Installation den Haken bei „Verwaltung meines Gerätes durch meine Organisation zulassen“ nicht entfernt. Alternativ kann man auch links unten auf den „unsichtbaren“ Button „Nein, nur bei dieser App anmelden“ klicken.

Wenn man sein Gerät registiert hat taucht es auch nach wenigen Cloudmomenten im AzureAD Device Manager auf:

Und bekommt von dort einige Richtlinien. Vor allem die Sicherheitsrichtlinien greifen dann auf dem Gerät – machmal ist das bei „Privat-PCs“ etwas überraschend.

Fehler CAA2000B (AADSTS500014)

Standardmäßig tritt beim zurücksetzen der Windows-Hello PIN auf dem PC nach dem Azure AD Registrierungsvorgang dieser Fehler auf:

Es ist ein Problem aufgetreten

wir konnten sie nicht anmelden. Falls dieser Fehler weiterhin besteht, wenden Sie sich an den Systemadministrator, und geben Sie den Fehlercode an: CAA2000B.

Das liegt daran, das der Administrator die „App“ die die Zugangs-PIN ändern will erst zu „seinem“ Azure AD hinzufügen und bestötigen muss.

Lösung

1. Die PIN-Reset Web-App „Service“ aufrufen und als Globaler Administrator anmelden. Am einfachten mit GENAU diesem Link:

https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent

2. Die PIN-Reset Web-App „Client“ aufrufen und als Globaler Administrator anmelden. Am einfachten mit GENAU diesem Link:

https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent

2. Im folgenden Assistenten in BEIDEN Fällen die App „Microsoft Pin Reset Service Production“ (Client und Service) bestätigen:

„Microsoft PIN Reste Service Production“ für Windows Hello erlauben

Ob das geklappt hat kann man danach sofort im Microsoft Entra Admin Center überprüfen:

  1. Ins AzureAD einloggen via https://entra.microsoft.com/
  2. Azure Active Directory > Anwendungen > Unternehmensanwendungen > Alle Anwendungen > „PIN“ suchen

Es sollten dort nun zwei Apps auftauchen:

Und schon (nach dem nächsten Neustart mit Internet) funktioniert das PIN-Ändern wieder wie vorher.

Wenn der Vorgang trotzdem noch fehlschlägt, hilft oft ein Blick in das Cloud App Security Dashboard für Anwendungen; möglicherweise hat hier anderer Admin das OAUTH dieser Apps vielleicht blockiert …

Veeam Job Fail [Error Unhandled exception was thrown during licensing process]

Veröffentlicht am von — Keine Kommentare ↓

Jeden Tag laufen eine Menge Backup-Jobs. Einer nicht – oder besser, einige Maschinen darin nicht. Der Fehler im Veeam Backup & Replication Protokoll lautet:

[Error Unhandled exception was thrown during licensing process]

Die Lizenzierung wurde natürlich geprüft und alle Hosts und vCenter waren mit korrkten Lizenen ausgestatte. Es wurden auch keine Instanzen separat lizenziert oder ähnliches.

Lösung

Es stellte sich heraus, dass selbiges kein Lizenzproblem ist. Der genutzte vCenter-Server war einfach nicht erreichbar (502 nach Neustart). Der selbe Fehler tritt auch auf, wenn man das Passwort des Benutzers, der für die Verbindung mit VMware vCenter verwendet wird, ändert.

Als der vCenter wieder da war (respektive das Kennwort angepasst), läuft auch alles wieder einwandfrei.

Veeam „Active snapshots limit reached for datastore“ bei Pending VMs

Veröffentlicht am von — Keine Kommentare ↓

Letzten hatten wir einen „Fehler“ bei einem Sicherungsjob, der mehrere brandneue Proxy- und Repository-Server verwendete. Kein anderer Job verwendete die neuen Komponenten.

Trotzdem verarbeitete Veeam nur 4 VMs gleichzeitig; alle anderen hatten den Status „Pending“. Aber die Meldung war ergänzt um diese hilfreiche Aussage:

Resource not ready: Active snapshots limit reached for datastore

Nach kurzer Untersuchung fanden wir heraus, dass sich alle VMs auf einem VVOL befanden. Ein VVOL wird scheinbar wie ein einziges VMFS behandelt und das per-datastore Limit angewendet.

Lösung

Glücklicherweise gibt es eine einfache Lösung für diese Einschränkung. Man kann einen Registrierungsschlüssel auf dem VBR-Server (VBR, nicht Proxy!) erstellen, um das Limit aktiver Snapshots pro Datenspeicher zu erhöhen:

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication

MaxSnapshotsPerDatastore   REG_DWORD   <Anzahl (dezimal)>