Autoren-Archiv: weed

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:

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.

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)“

Der 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.