Archiv der Kategorie: Microsoft

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.

Problem

Der Bitlocker-Assistent läuft fehlerfrei durch, legt den Recovery-Key ab bricht im letzten Schritt mit dieser Meldung ab:

Das System kann die angegebene Datei nicht finden

Lösung

Es hat wahrscheinlich bereits einen fehlgeschlagenen Verschlüsselungsversuch mit angelegtem RecoveryAgentKey gegeben. Dieser muss entfernt (oder umbenannt) werden, bevor der Assistent einen neuen erfolgreich ablegen möchte. Die Datei nennt sich ReAgent.xml.

• CMD „als Administrator“ starten

  C:\> pushd %windir%\system32\recovery

  
  

  C:\> ren ReAgent.xml ReAgent.old

Danach funktioniert der Assistent sofort wieder wie er soll.