Monat: August 2018

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

Veröffentlicht am von — 4 Kommentare ↓

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 Dateien zusammen mit Click-to-Run Produkten ist offiziell nicht unterstützt. Die Mischung der Lizenzierungsformen (nicht Setup-Dateien!) funktioniert aber sehr wohl – man muss nur die passende Installation nutzen.

Dieser Trick macht die Installation möglich, ändert aber nicht die Lizenzform. Man erhält also keine Office365-typischen Updates für das Produkt. Weiterhin gibt es nur „normale“ Patches.

  1. Download des 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 (setup.exe aus dem Deployment Tool) herunterladen
  4. Anwendung mit setup /configure MEINNAME.xml (ebenfalls das Deployment Tool) installieren
  5. Anwendung starten und mit Ihrem jeweiligen Lizenzschlüssel aktivieren

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

Veröffentlicht am von — 10 Kommentare ↓

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 modernen Programmübersicht) sowie in der klassischen „Programme&Features“ Übersicht findet man diese Einträge leider nicht.

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

Veröffentlicht am von — Keine Kommentare ↓

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

Veröffentlicht am von — Keine Kommentare ↓

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