Monat: März 2014

„Cannot run upgrade script on host“ beim vSphere Upgrade

Veröffentlicht am von — Keine Kommentare ↓

Problem

Das In-Place-Upgrade eines ESXi5.1 Hosts auf 5.5 schlägt mit der Meldung „Cannot run upgrade script on host“ fehl. Das selbe passiert beim Update über den Update Manager. Der Host bootet nach der Fehlermeldung das alte vSphere 5.1 neu.

Lösung

In /var/log/vua.log auf dem Updateserver (oder lokal) ist folgende Fehler protokolliert:

VUA exiting
Alert:WARNING: This application is not using QuickExit(). The exit code will be set to 0.@ ~/vim/lib/vmacore/main/service.cpp:147

Es gibt offenbar zwei Lösungen die hier helfen können

  1. HA-Agent komplett (!) neu installieren („Neu konfigurieren“ reicht nicht:
    1. Host aus dem Cluster entfernen und herunterfahren (!)
    2. Nach einem reboot auf dem betroffenen Host den Agenten lokal über eine Kopie des uninstall-Script deinstallieren: 
      cp /opt/vmware/uninstallers/VMware-fdm-uninstall.sh /tmp
chmod +x /tmp/VMware-fdm-uninstall.sh & /tmp/VMware-fdm-uninstall.sh
    3. Host rebooten, neu zum Cluster hinzufügen, fertig. Jetzt läuft das Update durch. (Quelle)
  2. Bei der Meldung „Remediation failed due to non mmode failure“ ist das Verzeichnis /bootbank/state.* nicht leer.
    1. Im vua.log findet sich die ID der Maschine; die passende state-file einfach entfernen und erneut versuchen.(Quelle)

Skype Werbung entfernen

Veröffentlicht am von — 13 Kommentare ↓

skype-werbung-ausblendenWie entfernt man die lästige Werbung aus Skype? Jede neue Microsoft Skype Version bring ganz offensichtlich neue und noch nervigere herumzappelnde Werbebanner mit. Diese übermäßige Verseuchung lässt sich zum Glück (noch) recht gut abschalten, indem man die Werbe-Quellserver aussperrt.

Ob das in der persönlichen Lieblingsfirewall oder lokal geschieht ist egal, ich bevorzuge die Änderungen in der Hosts-Datei:

%systemroot%\system32\drivers\etc\hosts

Diese Datei sollte hinter das hier enthalten (Stand: Mai 2014):

# SKYPE ads
127.0.0.1 rad.msn.com
127.0.0.1 live.rads.msn.com
127.0.0.1 ads1.msn.com
127.0.0.1 static.2mdn.net
127.0.0.1 g.msn.com
127.0.0.1 a.ads2.msads.net
127.0.0.1 b.ads2.msads.net
127.0.0.1 ac3.msn.com
127.0.0.1 e4593.g.akamaiedge.net
127.0.0.1 apps.skype.com
127.0.0.1 48005751.r.msn.com
127.0.0.1 db3aqu.atdmt.com
127.0.0.1 cds26.ams9.msecn.net
127.0.0.1 sO.2mdn.net
127.0.0.1 aka-cdn-ns.adtech.de
127.0.0.1 secure.flashtalking.com
127.0.0.1 adnexus.net
127.0.0.1 adnxs.com
127.0.0.1 msntest.serving-sys.com
127.0.0.1 bs.serving-sys.com
127.0.0.1 flex.msn.com
127.0.0.1 ec.atdmt.com
127.0.0.1 cdn.atdmt.com

Ich hoffe es kommen nicht allzu schnell neue Werbeformen hinzu.

Es gibt ein zusätzliches UPDATE zu diesem Artikel HIER »

vmware Aufruf von „HostServiceSystem.Stop“ für Objekt „serviceSystem-8145“ ist fehlgeschlagen

Veröffentlicht am von — Keine Kommentare ↓

Problem

Der SSH-Dienst lässt sich auf einem vSphere Host nicht beenden. Zudem wird die Warnung „SSH wurde für diesen Host aktiviert“ auf dem Übersicht-Tab angezeigt und der Host wird in der Übersicht nur noch it einem gelben Warnsymbol angezeigt.
hostservicesystem-stop-ssh-fehlgeschlagen

Aufruf von "HostServiceSystem.Stop" für Objekt "serviceSystem-8145" auf vCenter Server "vcenter" ist fehlgeschlagen.

Lösung

  1. SSH-Sitzung zu dem betroffenen Host öffnen
  2. Backup der services.xml anlegen: 
    cp /etc/vmware/service/service.xml /etc/vmware/service/service.backup
  3. Die 
    sshServer

    Zeile aus der Datei service.xml löschen, speichern, schliessen

  4. Firewall/Servicemanager die Konfiguration neu einlesen lassen (oder Host rebooten) 
    esxcli network firewall refresh

Das wars, jetzt klappt das Starten und Stoppen des SSH-Dienstes auch wieder via vSphere Client. Update: Es gibt sogar einen offiziellen KB der dieses vorgehen suported.

Lösung 2: Aber ich will doch SSH verwenden!

Die Warnung lässt sich auch generell pro Host abschalten.

  1. Den betreffenden Host auswählen -> Konfiguration -> Erweiterte Einstellungen
  2. Ganz nach unten zu „UserVars“ scrollen und den Wert „UserVars.SuppressShellWarning“ auf „1“ stellen.

Dann ist die Warnung sofort verscheunden und kommt auch nicht wieder.

Scanner senden keine E-Mails über Windows IIS-SMTP-Relay (Logfile: „BDAT“)

Veröffentlicht am von — Keine Kommentare ↓

Problem

windows-iis-smtp-log-BDATEin Flur-Scanner (wir nennen diese Dinger intern gerne „Raumschiff“) versendet „auf einmal“ keine (größeren) Dokumente mehr per E-Mail. Kleine Dokumente funktionieren fehlerfrei – die Meldung am Display des Gerätes dazu lautet „Die Festplatte des Servers ist voll“. Es wird über ein Windows IIS-SMTP-Relay an Office365 gemailt. Der Fehler tritt bei Geräten von Develop (Beispiel ineo+ 220) auf, andere Geräte verschicken mit der Meldung „Message size too big“ überhaupt nichts. Der Server hat selbstverständlich ausreichend Platz.

Lösung

Der Scanner versendet keine größen eingescannten Dokumente mehr, weil die Nachrichtengröße überschritten ist und der Scanner zu dem erweiterten SMTP-Befehl BDAT wechselt. Das funktioniert so nicht richtig, weil die IIS-Metabase zwar die verwendung von BDAT zulässt, die Verbindung aber (ohne Fehlermeldung) beim erreichen der maximalen Nachrichtengröße beendet. Das sieht man sehr schnell und eindrucksvoll in den zugehörigen IIS SMTP LogFiles (\inetpub\LogFiles\SMTPSVC*). Anstell des DATA-Commands folgt da ein auf den ersten blick verwirrender Stapel Binärdaten. Dieser Stapel bricht irgendwann kommentarlos ab.

Zwei Möglichkeiten zur Fehlerbehebung:

  1. Maximal Nachrichtengröße erhöhen (IIS 6.0 Manager > SMTP Virtual Server > Eigenschaften > Nachrichten > „Nachrichtengröße beschränken“ anpassen
  2. In der IIS6 Metabase den SmtpInboundCommandSupportOptions Integer anpassen (/LM/SmtpSvc/<id>/) um das BDAT-Verb zu verbieten.

iis6-smtp-metabase-explorer