SQL Management Studio – Upgrade oder nicht Upgrader

SMSS 14 installiert und …

*kopfschüttel*

Project oder Visio aus Volumenlizenz oder Retail zusammen mit Office 365 installieren

Problem

Bei dem Versuch Visio, Project oder andere klassische Office-Tools zusammen mit einem frisch installierten Office 365 („Klick-and-Run“ Setup) zu nutzen erscheint beim Setup die Fehlermeldung:

Wir sind auf ein Problem getoßen

Beim Office Klick-und-Los-Installer ist leider ein Problem aufgetreten, weil auf Ihrem Computer die folgenden, auf dem Windows-Installer basierten Office-Programme installiert sind:

Microsoft Office Profssional Plus 2016

Klick-und-Los und Windows Installer-Editionen von Office-Programmen können in dieser Version nicht parallel installiert werden …

 

Lösung

Eine Installation von Windows Installer Produkten zusammen mit Click-to-Run Produkten ist offiziell nicht unterstützt. Die Mischung der Lizenzierungsformen aber sehr wohl – man muss also nur die passende Installation nutzen. Dieser Trick macht die Installation möglich, ändert aber nicht die Lizenz. Man erhält also keine Office365 typischen updates für das Produkt, weiterhin nur patches.

  1. Download des jeweils aktuellen Office Deployment Tools (http://go.microsoft.com/fwlink/p/?LinkID=626065)
  2. Erstellen einer für Visio/Project passenden config.xml
    1. config.xml Beispiele liegen dem Setup nach dem auspacken bei
    2. Meistens muss nur die „Produkt ID“ angepasst werden
    3. Alle möglichen Product-IDs gibt’s direkt bei Microsoft
    4. Die restliche Konfiguration enfernen
  3. Anwendung mit „setup.exe /download MEINNAME.xml“ herunterladen
  4. Anwendung mit „setup /configure MEINNAME.xml“ installieren
  5. Anwendung starten und mit Ihrem jeweiligen Lizenzschlüssel aktivieren

Setup Fehler „Office 16 Click-to-Run Extensibility Component 64-bit Registration“

Problem

Es soll ein Office-Tool in einer Retail oder Volumenlizenz auf einem Computer installiert werden, auf dem mal Office installiert war – oder sogar noch ist. Oft meint das Setup mit der Meldung, das ein Office 365 („Click-to-Run“ Setup) installiert gewesen ist. Statt dem Visio- (oder anderem Office-Tool) Setup erscheint die Fehlermeldung:

Office 16 Click-to-Run Extensibility Component 64-bit Registration

Setupfehler

Die 32-Bit-Version von Office kann nicht installiert werden, weil die folgenden 64-Bit Programme auf ihrem Computer gefunden wurden:

Office 16 Click-to-Run Extensibility Component 64-bit Registration

Bitte deinstallieren Sie zuerst alle 64-Bit-Office-Programme, und versuchen Sie dann die erneute Installation der 32-Bit-Version von Office. Wenn Sie stattdessen die 64-Bit-VErsion von Office installieren möchten, führen Sie bitte das Setupprogramm der 64-Bit-Version aus.

Lösung

Wichtig! Microsoft Office 365 (egal ob 32-Bit oder 64-Bit) und Volumen/Retail-Programme wie Vision, Project (egal ob 32-Bit oder 64-Bit) oder ähnliche Software können von Datenträgern (ISO/DVD) nicht zusammen auf einem Windows installiert werden. Es ist uns auch kein zuverlässiger Trick bekannt der dies umgeht; man muss sich für eine Installationsform (Retail/Open/VL oder Online) entscheiden. Dieser Artikel behandelt nur, wie dieser Fehler behoben wird, wenn man Office 365 (vermeintlich) vollständig deinstalliert hat.

  1. Öffne den Ordner %windir%\installer (Start>Ausführen>’installer‘)
  2. Stelle sicher das in den Ordneroptionen alle Dateien eingeblendet sind
  3. Füge die Spalte „Betreff“ im Explorer hinzu (rechte Maustatste auf die Spaltenübersicht>Weitere>Betreff)
  4. Für jede MSI-Datei sieht man in der Betreff-Spalte das Produkt. Sortiere nach dieser Spalte und suche den Namen aus deinem Fehler (z.B. „Office 16 Click-to-Run Extensibility Component“)
  5. Rechte Maustaste auf das MSI und „deinstallieren“

Unter den installierten „Apps“ (in der neuen unseligen Programmübersicht) und in der Systemsteuerung>Programme+Features findet man diese Einträge nicth einzeln.

 

VMware ESXi: mehrere VIBs auf einmal deinstallieren (remove multiple VIB)

Diesen Trick kannte ich nicht: Man kann in der Kommandozeile gleich mehrere VIBs auf einmal deinstallieren. ESXCLI kann das sowohl remote, als auch lokal auf dem Host (z.B. via SSH):

~:# esxcli software vib remove -n vibname1 -n vibname2 -n vibname3

So kann man diese fiesen alten HPE-Zugaben vor Inplace-Hostupgrades alle auf einmal schnell entfernen:

~:# esxcli software vib remove -n char-hpcru -n net-mst -n char-hpilo -n hp-ams -n hp-esxi-fc-enablement

Und schon steht demUpgrade nichts mehr im Wege 🙂

Windows Server 2016 Remotedesktop (RDS) mit RDWeb/Gateway Authentifizierungsfehler 0x607

Problem

In einer RDS Farm mit RDS Sessionhosts (RDSH), RDS Gateway und/oder RDS Broker Server(n) tritt „auf einmal“ ein Fehler bei der Verbindung mit einem RDS-Client ab Version  auf. Das fällt meistens bei der Anmeldung über das Web-Gateway auf – dort klappt die Authentifizierung, aber die RDP-Sitzung startet nicht. Der Fehler lautet:

„Ein Authentifizierungsfehler ist aufgetreten (Code: 0x607)“

RDS Authentifizierungsfehler 0x607Der Fehler tritt nicht auf, wenn man einen Windows 7 Client (RDP v7.x) verwendet.

Lösung (3 Möglichkeiten)

Schuld ist in der Regel eine Unstimmigkeit bei der Zertifikatsauswahl zwischen Client, Broker und Sitzungshost.

Möglichkeit 1: Sitzungssicherheit für die (in der Regel interne) Verbindung Gateway <-> Sitzungshost auf „niedgrig“ stellen. Dann wird der Fingerprint-Mismatch ignoriert und die Verbindung funktioniert sofort wieder.

Server-Manager > (Links) Remotedesktop-Dienste > Sammlungen/Sammlungsname > Aufgaben/Eigenschaften bearbeiten > Sicherheit > Verschlüsselungsstufe > „niedrig“

Nach einem Klick auf „ok“ klappt das sofort, das Gateway nutzt die Verbindungseinstellungen direkt.

Möglichkeit 2: Die „korrekte“ aber äußerst fummelige Lösung besteht darin, das korrekte RDS-Zertifikat das im RDS-Manager festgelegt wurde auf die RDSH zu verteilen, dort manuell (!) in das Computerkonto zu importieren und den zugehörigen Fingerprint in dem Registry-Schlüssel

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]
"SSLCertificateSHA1Hash"=hex:<fingerprint>

festzulegen. Nach einem Reboot der Hosts funktioniert die Verbindung meistens. Wie das allerdings klappen soll, wenn man auf einer LAN-Seite interne Zertifikate und auf der WAN-Seite externe nutzt konnte uns bishe rnoch niemand erklären …

Möglichkeit 3: Jemand(tm) hat auf dem Gateway die „Authentifizierung auf Netzwerkebene“ eingeschaltet. Das funktioniert sehr gut im internen Netzwerk, nicht aber wenn sich der Client außerhalb desselben befindet. Sprich: diese Sammlung funktioniert fehlerfrei für interne Nutzer, bei einer externen Anmeldung über RDWeb oder RDP am Gateway tritt der Fehler 0x607 auf.

RDS Fehler 0x607

 

Service Pack for ProLiant (SPP) Version 2018.06.0 Download Links

Wie in letzter Zeit leider üblich, verschanzt HPE das nun aktuelle SPP (2018.06.0) mal wieder hinter praktisch undurchdringlichen Support-Login-Portal-Request-Double-OptIn-Secure-Downloadbasket-PayToUpgdate-Überprüfungsklickereien. Ärgerlich wie unnötig vergrault diese Taktik leider nach und nach langjährige Kunden dieses ehemals ausgezeichneten Serverherstellers.

HPE Support-Portal – Download mit Servicevertrag oder gültiger Servergarantie: https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_465ae60442734bce83b19a5b5d

HTTP Direkter Download-Link (noch jedenfalls): http://h30537.www3.hpe.com/prdownloads/P09037_001_spp-2018.06.0-SPP2018060.2018_0618.6 …

Hir ist noch ein direkt mirror Link von einem coolen anderen Admn (thx LooP).

Torrent-Magnet Link magnet:?xt=urn:btih:E1C76DE3A0AD17A9C8822300F4A86752DD631AFC&dn=P09037_001_spp-2018.06.0-SPP2018060.2018_0618.64.iso

(Achtung, mgnet.me ist ein Klick-Forwarder für magnet-links, der blöde Spamseiten öffnet. Das ist da, weil WordPress leider immernoch keine „magnet:“ URNs unterstützt). Entschuldigt den Umstand.

 

 

vSphere storage motion „Fehler 195887250. Migration determined a failure by the VMX“

Problem

Eine VM möchte sich nicht via StorageMotion nicht auf ein VVOL verschieben lassen. Im Aktivitätsprotokoll sieht man den Fehler:

Fehler beim Warten auf Daten. Fehler 195887250. Migration determined a failure by the VMX.

und/oder

Migration determined a failure by the VMX. Storage vMotion konnte die Zielfestplatte /vmfs/volumes/vvol:0000000200004004-825d720126911b58/rfc4122.16630ae1-3756-4e47-b932-cdebf5862fd7/SERVERNAME.vmdk nicht erstellen.

und/oder

Erstellen einer oder mehrerer Zielfestplatten fehlgeschlagen. Es ist ein schwerwiegender interner Fehler aufgetreten. Weitere Details finden Sie im Protokoll der virtuellen Maschine.

Spannend zu suchen ist der Fehler 195887250. Der VMKernel meint damit „VMK_MIGRATE_VMX_FAILURE“, oder in ausgeschrieben „Migration determined a failure by the VMX“.

Lösung

Der weitaus häufigste Grund ist relativ einfach: Eine der Festplatten der betroffenen Maschine hat eine größe, die nicht durch 1Mbyte teilbar ist. VVOLs können nur vielfaches von 1Mbyte allokieren, daher schlägt das anlegen der Platte fehl.

Das sieht man auch im vmware.log der betroffenen Maschine:

2018-08-06T11:50:01.264Z| worker-2161938| I125: DISKLIB-LIB_CREATE : CREATE: Creating disk backed by 'vvol'
2018-08-06T11:50:01.265Z| worker-2161938| W115: OBJLIB-VVOLOBJ : VVolObjCheckSize: Requested size (32217052160) is not an MB multiple.
2018-08-06T11:50:01.265Z| worker-2161938| W115: OBJLIB-VVOLOBJ : VVolObjDetermineSizeInMB: Requested size (32217052160) is not a MB multiple.
2018-08-06T11:50:01.265Z| worker-2161938| W115: Mirror: scsi0:0: SVMotionLocalDiskCreate: Failed to create destination disk: The requested size is not a multiple of 1MB
2018-08-06T11:50:01.265Z| worker-2161938| W115: Mirror: scsi0:0: Failed to create disk from /vmfs/volumes/.../NAME.vmdk to /vmfs/volumes/.../NAME.vmdk.

Ärgerlicherweise behauptet die VCSA stattdessen: „No space left on device“

Der zweite Fall der ich einmal untersuchen durfte, war eine „kaputte“ Netzwerkkarte. Alles lief einwandfrei, nur storage motion auf dieser Karte nicht. NIC ausgetauscht, alles wieder fertig.