Autoren-Archiv: weed

„We are not allowed to believe that, sorry“

Veröffentlicht am von — Keine Kommentare ↓

Ein Support-Fall mit dem größten Software-Anbieter der Welt. Es gibt ein (offensichtliches) Cloud-Problem seitens des Anbieters (ebenfalls offensichtlich). Der Fehler ist vom Anbieter als solcher dokumentiert und nur via Case lösbar. Okay.

Der (überaus freundliche!) Support-Dude sagt, nachdem ich zum dritten mal Step-by-Step angeleitet werde auf etwas zu klicken: „Hey, you already did that!“. Die Anwort fällt zugegeben etwas passiv-agressiv aus, aber nach mehreren Monaten Support-Ping-Pong mit der immer gleichen (nicht funktionierenden) Anleitung: „Yes, like I told you three times in this call, wrote in multiple emails and sent screenshots last week -just like you requested“.

Er sagt: „We are not allowed to believe customers, sorry“.

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.