Kategorie-Archiv: Allgemein

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)>

Adobe Acrobat Reader „Continous Release“ 2022.003.+ Werkzeugleiste dauerhaft ausblenden via Registry oder GPO

Veröffentlicht am von — 6 Kommentare ↓
Supernervige Werkzeugleiste

Der Reader bringt seit einer Weile eine „Werkzeugleiste“ mit. Diese nervige, unnötige und mit unprofessioneller Werbung gespickte „Seitenliste“ oder auch „Toolbar“ ist in den meisten Fällen unnötig und stört den Anzeigebereich ganz erheblich.

Man kann die Toolbar zwar mit ALT+F4 immer wieder schließen, aber das merkt sich der Reader natürlich nicht.

Man kann aber einen Haken setzen, unter: Bearbeiten > Einstellungen > Dokumente > „Aktuellen Status des Werkzeugfensters speichern“. Das funktioniert ganz gut, aber der schnelle Admin will das natürlich in einer Gruppenrichtlinie (GPO).

Lösung

Eine „fertige“ GPO als ADMX gibt es natürlich nicht (auch für Enterprise-Kunden nicht), denn sinnvolles liefert Adobe nur höchstselten. Es gibt unter admx.help aber eine brauchbare Drittlösung und vor allem eine dokumentierte Liste.

In der GPO legt man zum ausblenden diesen Registrierungsschlüssel an:

HKEY_CURRENT_USER\SOFTWARE\Adobe\Adobe Acrobat\DC\AVGeneral\ 

Name:   aDefaultRHPViewMode_L 
Typ:    REG_SZ 
Inhalt: Collapsed

IIS Anwendung und .NET Anwendungskonfiguration entfernen (Windows Server 2016/2019/2022)

Veröffentlicht am von — 1 Kommentar ↓

Neue Anwendungen im IIS sind bekanntlich schnell erstellt, über den Punkt „In Anwendung konvertieren“:

Leider gibt es bis heute keine Möglichkeit, eine Anwendung („App“) wieder zu entfernen. Das ist einem, beispielsweise, beim Wechsel von .NET zu PHP schon mal im Wege und man möchte IIS Anwendungen einfach wieder löschen.

Lösung

Am schnellsten geht das an der Kommandozeile, PowerShell oder CMD:

pushd %SystemRoot%\system32\inetsrv
.\appcmd list app
.\appcmd delete <APPNAME>

HPE Nimble Storage (jetzt „Alletra“) verschickt Alarme die es nicht mehr gibt

Veröffentlicht am von — Keine Kommentare ↓

Das HPE mit dem Kauf von Nimble einen guten Fang gemacht hat, hat sich ja mittlerweile herumgesprochen. Ein Nimble-Effekt wurde trotz fleißiger Updates aber bis heute nicht wirklich behoben: Die „toten“ Alarme, oder auch „Dead Alerts“.

Die Nimble (Alletra) verschickt in vielen Fällen auch noch weiterhin Alarme, wenn die Ursache gar nicht mehr existiert. Das gilt beispielsweise für neue vCenter-Server, abgeschaltete Array-Replikationsziele oder auch nur entfernte Volumes die „vorher“ noch offene Snapshots hatten.

Lösung: Nimble Alarme ansehen und löschen

Per SSH auf das betroffene Array verbinden und die vorhandenen Alarme ansehen:

alarm --list

Sobald man den „schuldigen“ gefunden hat, kann man den betroffenen Auslöser einfach löschen:

alarm --delete <ID>

Das betrifft natürlich auch nur berits ausgelöste Alarme, neue Ereignisse erzeugen auch wieder einen neuen Alarm.