Veeam: Updates cannot be installed because some processes are active. Please finish all restore processes …

Bei einem Update von Veeam Backup and Replication kommt es gerne zu einem etwas verwirrenden Fehler:

Update cannot be installed, because some processes are active.
Please finish all restore processes, stop and disable all jobs, close the user interface, and try again. 
If you still get this message, restart the server and wait for a few minutes before trying again.

Es laufen aber ganz sicher keine Backup-, Restore-, oder Copy-Jobs mehr.

Lösung

Den „Veeam Backup Service“ beenden. Aus unerfindlichen Gründen schafft das Setup es nicht immer, diesen korrekt zu schliessen.

C:\> sc stop VeeamBackupSvc

Falls das nicht hilft, einmal die Backup-Maschine neu starten.

vSphere mountet Datastore nicht „Device detected to be a snapshot“

Problem

Eine LUN will sich auf einem Host nicht mehr als Datastore mounten lassen. Das /var/log/vmkernel.log sagt dazu:

cpu55:34954 opID=da111896)World: 15544: VC opID xxxx-xxxxx-xx-xx-xxxx maps to vmkernel opID daxxxxx
cpu55:34954 opID=da111896)<3>ata6.00: bad CDB len=16, scsi_op=0x9e, max=12
cpu55:34954 opID=da111896)LVM: 10084: Device naa.xxxxxxxxxxxxxx:1 detected to be a snapshot:
cpu55:34954 opID=da111896)LVM: 10091: queried disk ID: <type 2, len 22, lun 5, devType 0, scsi 0, h(id)>
cpu55:34954 opID=da111896)LVM: 10098: on-disk disk ID: <type 2, len 22, lun 5, devType 0, scsi 0, h(id)>

Lösung

Das Volume einfach manuell mounten:

[[email protected]:~] esxcfg-volume -M <DATASTORENAME>

Man kann sich die Volumen auf dem Bus auch zur Sicherheit vorher anschauen:

[[email protected]:~] esxcfg-volume -l
Scanning for VMFS-3/VMFS-5 host activity (512 bytes/HB, 2048 HBs).
VMFS UUID/label: xxxxx-xxxxxx-xxxxxxxxxxxxxx/<DATASTORENAME>
Can mount: Yes
Can resignature: No (the volume is being actively used)
Extent name: naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:1 range: 0 - 1714687 (MB)

vSphere mountet Datastore nicht, obwohl LUN und Device unter „Geräte“ sichtbar sind

Problem

Ein vSphere 6.x Host sieht einen frisch angeschlossenen VMFS Datastore nicht, der auf einem HP MSA2000fc erstellt wurde. Die VMFS-Version ist aktuell, vSphere 6 ist aktuell, die Firmware ist aktuell, aber der Datastore ist einfach nicht da. Die angeschlossenen LUNs und ihre Pfade sind in der Geräteübersicht sichtbar und werden korrekt angezeigt. Nur das/die VMFS-Volumen werden nicht gemountet.

Das /var/log/vmkernel.log sagt dazu:

2017-06-14T10:09:27.643Z cpu34:33171)ScsiUid: 273: Path 'vmhba37:C0:T0:L0' does not support VPD Device Id page.
2017-06-14T10:09:27.645Z cpu34:33171)VMWARE SCSI Id: Could not get disk id for vmhba37:C0:T0:L0
2017-06-14T10:09:27.765Z cpu8:34953 opID=81e32a6)World: 15544: VC opID 3xxxxxx-xxxxxx-xx-xx-xxxx maps to vmkernel opID xxxxxx
2017-06-14T10:09:27.765Z cpu8:34953 opID=81e32a6)WARNING: HBX: 480: 'DATASTORENAME':
ATS-only volume unable to use ATS due to host-level HardwareAcceleratedLocking configuration.

 

Lösung

Das nette VAAI Feature („VMware vSphere Storage APIs Array Integration“) nutzt eine Technik, die ATS heißt („Atomic, Test and Set“). Dabei werden einzelne Blöcke des Storages („atomic“) durch die Storage-Hardware gelockt, so daß nur ein Host diese exklusiv beschreiben kann. Ohne ATS könnte, in so einem Fall, ein einzelner Host die ganze LUN blockieren. Die MSA2000 G1/G2 Controller beherrschen dieses Feature allerdings leider nicht – um genau zu sein gar keine VAAI-Features.

ATS (pro Host) ausschalten:

Host > Konfiguration > Software/Erweiterte Einstellungen > VMFS3 > „HardwareAcceleratedLocking“ auf „0“ stellen

Mehr Informationen:

Mach mal Speisekarte Facebook

Wir stellen uns das so in etwa vor:

Chef zu Shui-Azubine: „Mach mal Karte in Facebook“

Azubine: „Ey wiiiee denn?“

Chef: „Egal, mach einfach in Facebook“

Azubine *macht Selfie von Speisekarte in Word*

Besonders gelungen finden wir die roten Office Rechtschreib-Wellenlinien. Wenn es doch nur eine Möglichkeit gäbe, von Word nach Facebook zu speichern …

Kein Scherz, das orginal ist noch immer bei „Sumo Sushi“ in Hagen zu finden.

Outlook 2013/2016 mit einer E-Mail crashen

Ein Kunde meldet sich:

Immer wenn ich diese E-Mail öffne, stürzt mein Computer ab.

Wir, als gestandene Admins, glauben natürlich erstmal nichts und schauen uns das an. Stellt sich raus: Der Kunde hat recht. Er hat eine Mail in seinem Posteingang, die seinen Outlook-Client immer crasht, wenn er die Mail anschaut. Wir leiten uns die Mail weiter (OWA ist nicht betroffen) und stellen fest: Outlook 2013 und 2016 lassen sich mit dieser Nachricht reproduzierbar und überall crashen. Unter jedem Windows. In der Voransicht (Standartmäßig eingeschaltet), beim anklicken, als MSG- oder EML-Datei, immer. Sehr schön!

Nach genauer Analyse stellt sich heraus: Es ist „nur“ der HTML-Word-Viewer. Dieser stolpert über eine einzige Zeile:

<style>table {mso-style-name:Standardowy; width:100%;}</style><br>

Wenn man also anderen Leuten das Outlook abschießen möchte verschickt einfach diese Zeile. Eine Beispiel-Crash-Mail.eml sieht zum Beispiel so aus:

From: Teleweed <[email protected]>
To: "Anonymous" <Anonymous>
Subject: This is an outlook crashing example
Date: Fri, 2 Jun 2017 2:22:22 -0200
Content-Type: text/html;

<style>table {mso-style-name:Standardowy; width:100%;}</style><br>

Leider konnten wir den Fehler nicht an Microsoft melden, weil das praktisch unmöglich ist. Weder ein MVP, unser PAM/PSX, die Social-Foren, noch das Feedback, noch die Security noch das Support-Team, noch der Partner-Support konnten oder wollten den Bug annehmen. Also liebe Welt: Happy shooting!

Vielleicht schickt ja mal jemand eine solche Mail an Rajesh Jha oder am besten gleich Satya Nadella 🙂

Update:

Mit dem Code lässt sich scheinbar auch Word an sich zum absturz bringen: Baut man folgendes in den Head eines html-Dokuments und versucht dann, selbiges mit Word zu öffnen kommt es ebenfalls zum Absturz.

<style>table {mso-style-name:Standardowy; width:100%;}</style>

Scheinbar ist das Ganze abhängig von der verwendeten Office-Sprache: Standardowy ist polnisch für „konventionell“. Ersetzt man es z.B. mit „Normale Tabelle“ (mit Anführungszeichen, wegen dem Leerzeichen) lässt es sich mit einem deutschen Word wieder Öffnen. Ein beliebige anderer String (z.B. auch „Table Normal“ aus einem englischsprachigen Word) verursacht den Absturz trotzdem.

Wichtig ist die Kombination aus „mso-style-name:<string>;“ und „width:<size>;“ -> Verwendet man z.B. „height“ gibt es keinen crash. Für <size> spielt es allerdings keine Rolle in welcher Einheit die Angabe erfolgt, Abstürzen tut Word auch mit z.B. 300px

Beispiele (proof of concept) gibt’s hier. („normale-tabelle_prozent.html“ sollte keinen Crash verursachen, der Rest allerdings schon.)

Danke @iSnackyCracky und @teleweed fürs finden und die langwierige Analyse.

Exchange 2016 OWA/ECP leere Seite nach Login

Problem:

Bei einer On-Premise Exchange Umgebung funktionieren „plötzlich“ Outlook und OWA nicht mehr. OWA und auch die ECP-Site zeigen noch den Login, danach bleibt die Seite allerdings leer.

Im System-Eventlog gibt es massenweise folgendes Event: (Source: HttpEvent; Event-ID: 15021)

Bei der Verwendung der SSL-Konfiguration für den Endpunkt 0.0.0.0:444 ist ein Fehler aufgetreten. Der Fehlerstatuscode ist in den zurückgegebenen Daten enthalten.

Lösung:

Ursache ist eine fehlende Zuordnung des SSL-Zertifikats für die Backend-Site im IIS.

Dort das SSL-Zertifikat wieder bei der korrekten Bindung auswählen, ggfs. den IIS neustarten und schon sollte der Zugriff wieder klappen:

  1. IIS Manager öffnen
  2. Sites -> Exchange Back End
  3. Im Aktionsbereich auf Bindungen
  4. Die https Bindung *:444 Bearbeiten
  5. das SSL-Zertifikat auswählen
  6. ggfs. iisreset

Trend Micro Worry-Free Business Security (WFBS) Dashboard Fehler 401/403 nach Windows-Update

Problem

Nach einem der letzten Windows-Updates und einem Serverneustart läuft das TrendMicro Dashboard vom IIS nicht mehr. Der Browser fragt ständig nach einem Benutzernamen und einem Passwort, oder zeigt sofort eine dieser Fehlermeldungen an:

  • 401.1 – Logon failed (Anmeldung fehlgeschlagen)
  • 401.3 – Unauthorized due to ACL on resource (Aufgrund von Berechtigungen …)
  • 403.1 – Execute access forbidden
  • 403.2 – Read access forbidden
  • 403.3 – Write access forbidden
  • 403.4 – Forbidden SSL required
  • 404.0 – Not Found
  • 404.1 – Web Site not accessible on the requested port
  • 404.2 – Lockdown policy prevents this request
  • 404.3 – MIME Map policy prevents this request

Lösung

Folgende Lösung hat sich bewährt, auch wenn sie etwas rigiros erscheint. Es gehen keine Einstellungen oder Daten verloren.

  1. Im IIS-Manager die Site „OfficeScan“ löschen. Ja, vollständig und restlos löschen.
  2. In einem Administrator-CMD Fenster in dieses Verzeichnis wechseln:
    %ProgramFiles(x86)%\Trend Micro\Security Server\PCCSRV
  3. Diese Befehle nacheinander ausführen:
    svrsvcsetup -install
    svrsvcsetup -setvirdir
    svrsvcsetup -setprivilege
    svrsvcsetup -enablessl

Schon fertig. Der svrsvcsetup-Manager erstellt das virtuelle Verzeichnis, Berechtigungen, Bindungen und so weiter wieder sauber neu.

Wenn man die Bindung der IIS-Site verändert hat(te), mit einem eigenen SSL-Zertifikat, anderem Port oder ähnliches, muss man diese Einstellung nun wiederholen. NUR die Bindungen verändern, mehr nicht – hier ist das Dashboard etwas empfindlich.

VMware vSphere „Der Vorgang ist im aktuellen Zustand nicht zulässig“

Problem:

Unter VMware lässt sich *auf einmal* kein Snapshot einer Maschine mehr erstellen oder löschen. Das Betrifft selbstverständlich auch Snapshot-basierte Backuplösungen.

Auch eine Migration der Maschine auf einen anderen Host oder Datastore ist nicht mehr möglich.

Es wird die Meldung „Der Vorgang ist im aktuellen Zustand nicht zulässig.“ („The operation is not allowed in the current state.“) angezeigt und auf dem zugehörigen ESX-Host findet man im hostd.log folgenden Eintrag:

error 'Vmsvc.vm:/vmfs/volumes/DATASTORE/VMNAME/VMNAME.vmx'] Invalid transition requested (VM_STATE_ON_SHUTTING_DOWN -> VM_STATE_CREATE_SCREENSHOT): Invalid state

Lösung:

Das Problem lässt sich in der Regel durch einen Neustart der Management-Agents auf dem jeweiligen ESX-Host beheben.

Dazu zunächst SSH auf dem ESX aktivieren (vSphere Client am Host anmelden -> Konfiguration -> Sicherheitsprofil)
und sicherstellen, dass die VMs nicht mit dem Host Starten/Herunterfahren (vSphere Client am Host anmelden -> Konfiguration -> VM starten/herunterfahren -> Virtuelle Maschinen mit dem System starten und beenden auf Deaktiviert stellen)

Dann per SSH auf den Host verbinden und die Management-Agents neustarten:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart