Outlook 2010 – Nicht abgeschlossene Zeichenfolgenkonstante

Beim Markieren einer Nachricht in Outlook 2010 erhaltet ihr unter Umständen folgende Fehlermeldung:

 

In dem Skript auf dieser Seite ist ein Fehler aufgetreten.

Zeile: 1733

Zeichen: 231

Fehler: Nicht abgeschlossene Zeichenfolgenkonstante

Code: 0

URL: file:///C:/Users/Max%20C.%20Mustermann/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/%7B006F22AF-A9C2-444A-A203-51056DF0F8EF%7D/%7B632B521A-44DC-42BD-A527-DDA9B25E2583%7D.html

Möchten Sie, dass Scripts auf dieser Seite weiterhin ausgeführt werden?

 

Schuld daran ist das Add-In „Microsoft Outlook Connector für soziale Netzwerke“.

Daher bitte wie folgt vorgehen um das Problem zu beheben:

1. Outlook öffnen
2. Klicke auf Datei, dann auf Optionen und dann auf Add-Ins.
3. Wähle ganz unten bitte COM-Add-Ins und klicke auf Gehe zu.
4. Deaktiviere bitte das Add-In Microsoft Outlook Connector für soziale Netzwerke und klicke auf OK.
5. Starte bitte Outlook neu
6. Der Fehler sollte nun Geschichte sein

Windows7 – Bootschleife durch KB2778069

Der ein oder andere PC hat nach der Installation des Patches KB2778069 eventuell ein Problem, dass dieser in einer Bootschleife steckt und nur durch eine Systemwiederherstellung zu retten ist. Das Positive ist natürlich, dass bei einer Systemwiederherstellung sämtliche Daten unangetastet bleiben.

Nach erfolgreicher Wiederherstellung des Systems mit Hilfe der „Systemwiederherstellung“ einfach den Patch „KB2887069“ über Windows Update deaktivieren bzw. ausblenden.

Ein anderer Lösungsweg außer Neuinstallation des Sytems ist mir bisher noch nicht untergekommen.

Office 2007 – ServicePack deinstallieren – Kommandozeile / oarpman.exe

office2007

 

Manchmal kann es von Nöten sein ein bereits installiertes ServicePack einer OfficeSuite wieder zu deinstallieren. Unter „Programme und Funktionen“ taucht das ServicePack allerdings leider nicht auf – sonst würde ich das wohl auch nicht schreiben ;-).

1) Runterladen des Tools (KB954914) von Microsoft unter:

http://www.microsoft.com/de-de/download/details.aspx?id=14313

2) Entpacken des Tools an einen beliebigen Ort (in meinem Fall liegt das Tool (oarpman.exe) unter „C:\Service\“

3) Öffnen der Kommandozeile (Windows+R –> cmd) –> zum Pfad von oarpman.exe navigieren

4) Auflistung der bereits installieren Updates anzeigen und zugleich in einer „.log“ speichern; der Befehl hierfür lautet:

oarpman /report /log c:\service\log.log

„Erstellt einen Report aller installieren Updates und speichert ihn auf dem lokalen Datenträger…“

5) Eine mögliche Ausgabe könnten folgende sein:

office2007installedpatches

 

6) Demnach sind auf dem System 15 Patches installiert und gehören zu dem Release O12SP3 (ServicePack3 von Office 2007)

7) Zum Entfernen der Patches benötigt man folgenden Befehl:

oarpman /remove O12SP3 /log c:\service\uninstall.log

Hierbei wird wiederum eine Logdatei angelegt….

office2007uninstalllog

8) Zur Kontrolle ob auch wirklich alle Patches erfolgreich deinstalliert wurden könnten man den Befehl von Punkt 4 erneut ausführen. Das Ergebnis müsste wie folgt aussehen:

controllinstalledpatchesafteruninstall

 

Terminalserver – Standarddrucker per Registry ändern

drucker

 

1) Öffnen der Registry –> Windows-Taste + “R” –> regedit

Wenn man den Drucker für den momentan eingeloggten User ändern möchte navigiert man zu folgendem Pfad:

printer_regedit1

 

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

Hier editiert man den Wert „Device“. Dieser Pfad bzw. Wert ist auch interessant wenn man nicht weiss, was für Werte für andere Benutzer eingetragen werden sollen!

Um den Drucker bei anderen Usern auf dem System zu ändern (Terminalserver) navigiert man in der Registry zu „seinem Pfad“

Für jeden Benutzer wird in der Registry unter „HKEY_USERS“ ein eigener „Baum angelegt“. In diesem navigiert man wiederum zu oben genanntem Pfad:

printer_regedit2

 

Auch hier wird dann der Wert „Device“ angepasst:

printer_regedit3

 

HKEY_USERS\xxxxxxxxx\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

Exchange 2010 – Der WinRM-Client kann die Anforderung nicht verarbeiten

exchange2010

 

Es erscheint folgende Fehlermeldung und die Exchange-Verwaltungskonsole lässt sich nicht öffnen:

Beim Verbinden mit dem Remoteserver ist folgender Fehler aufgetreten: Der WinRM-Client kann die Anforderung nicht verarbeiten. Der Inhaltstyp der HTTP-Antwort vom Zielcomputer kann nicht ermittelt werden. Der Inhaltstyp fehlt oder ist ungültig. Weitere Informationen finden Sie im Hilfethema „about_Remote_Troubleshooting“.

Die Lösung für das Problem habe ich im TechNet:

1) Öffnen der IIS-Konsole (Internetinformationsdienstemanager)

2) Navigiere zur Default Web Site (auswählen) und dann wähle in der Mitte „Module“

3) Entferne hier das Modul „kerbauth“ (Rechtsklick, Entfernen)

4) Gehe jetzt auf das virtuelle Verzeichnis „Powershell“ dann wieder in der Mitte auf „Module“

5) Überprüfe unter Module ob „kerbauth“ gelistet ist; mit dem Modultyp „Systemeigen“ und Eintragstyp „Lokal“

6) Wenn „kerbauth“ nicht gelistet ist, klicke rechts oben bei „Aktionen“ auf „Systemeigene Module konfigurieren“ und setze den Haken bei „kerbauth“

7) führe jetzt einen IIS-Neustart durch – Kommandozeile : IISRESET /noforce

Ich musste den „iisreset“ ohne den Parameter „/noforce“ durchführen um zum gewünschten Ergebnis zu kommen.

Danach lief die Exchange-Verwaltungskonsole wieder problemlos!

Exchange 2010 – 550 5.7.1 RESOLVER.RST.AuthRequired; authentication required

exchange2010

 

Beim Senden an eine Verteilergruppe im Exchange 2010 erhaltet ihr folgenden Fehler:

550 5.7.1 RESOLVER.RST.AuthRequired; authentication required

Abhilfe schafft hier:

1) Exchange-Verwaltungskonsole

2) Eigenschaften der betroffenen Verteilergruppe öffnen

3) Reiter „Nachrichtenübermittlungseinstellungen“ wählen

4) Öffnen von „Einschränkungen für die Nachrichtenübermittlung“

5) Haken entfernen bei „Authentifizierung aller Absender anfordern“

 

Exchange 2010 – Mitglieder einer Verteilergruppe empfangen keine E-Mails

exchange2010

 

Nach einer durchgeführten Migration von Exchange 2003 zu Exchange 2010 stößt man eventuell auf folgendes Problem:

DIe Mail an eine Verteilergruppe wird ohne Weiteres versendet und man denkt die Empfänger bekommen diese auch; doch weit gefehlt… die Mails landen im Exchange in der Warteschlange unter „unreachable“… die Nachrichtenverfolgung wirft folgenden Fehler aus:

„Zurzeit ist keine Route zum Server für die Aufgliederung der Verteilergruppen vorhanden“

Nach Öffnen der Exchange-Verwaltungskonsole navigiert man zu Empfängerkonfiguration –> Verteilergruppe !

In der betroffenen Verteilergruppe gilt es nun über Eigenschaften –> Exchange – Erweitert den neuen Exchange-Server einzutragen; in meinem Fall stand hier noch der alte Exchange 2003!

verteilergruppe

Nach Angabe des neuen Exchange-Servers funktionierte der Versand bzw. Empfang wieder problemlos.

Exchange 2010 – Benutzerpostfach löschen

exchange2010

 

Das Löschen eines Postfaches in der Exchange Management Konsole führt dazu, dass auch der Benutzer im Active-Directory gelöscht wird.

Um dies zu vermeiden ist es nötig das Prozedere via Shell zu lösen.

Der Befehl hierfür lautet:

Disable-Mailbox -Identity Username -Permanent $true

Der Befehl löscht das Postfach, behält aber den User im AD bei.

 

Ersetzt man obigen Befehl durch:

Remove-Mailbox -Identity Username -Permanent $true

wird nebst dem Postfach auch das Active-Directory-Objekt gelöscht.

KIS 2013 – Tastatur und Maus ohne Funktion nach Deinstallation

kis2013

 

Deinstallieren wir mal den Virenschutz!! Sollte doch ohne Probleme möglich sein? Nur dass die Tastatur bzw. Maus danach ohne Funktion sind, wird wohl kaum einer denken.

Nach erfolgreicher Deinstallation von Kaspersky Internet Security 2013 starten wir den Rechner neu und wundern uns, dass Maus / Tastatur ohne Funktion sind (zumindest in Windows; im BIOS funktioniert die Tastatur ohne Probleme). Da hat wohl der Uninstaller von Kaspersky ein bisschen mehr als gründlich aufgeräumt oder aber eben nicht…. Wie dem auch sei! Wir können die Systemwiederherstellung von Windows bemühen!? Klar! Aber danach ist der Virenschutz ja wieder drauf!

Ein Lösungsweg erfordert den Eingriff in die Registry von Windows:

1) Start –> Ausführen (alternativ: Windows-Taste+R) –> regedit –> Enter

1.1) Navigieren zum Pfad: HKLM –> SYSTEM –> CurrentControlSet –> Control –> Class –> {4D36E96B-E325-11CE-BFC1-08002BE10318}

2) Löschen des gezeigten Schlüssels mit anschließender Neuanlage (wer auf Nummer sichern gehen will, exportiert vorher den Registry-Key per Rechtsklick auf den Ordner auf der linken Seite)

kis2013registry

 

2.1) Nach Löschen des Schlüssels „UpperFilters“ wird dieser erneut angelegt:

–> Neu –> Wert der mehrteiligen Zeichenfolge

–> Name für den Neuen Wert auf „UpperFilters“ festlegen

–> Rechtsklick auf „UpperFilters“ –> Ändern –> im Feld Wert folgendes eintragen: kbdclass

3) Nach einem Neustart funktioniert die Tastatur wieder

4) Sollte auch die Maus betroffen sein, gibt es an anderer Stelle einen Registry-Key:

4.1) Navigieren zum Pfad: HKLM –> SYSTEM –> CurrentControlSet –> Control –> Class –> {4D36E96F-E325-11CE-BFC1-08002BE10318}

5) Löschen des Schlüssels „UpperFilters“

6) Neuanlage des Schlüssels „UpperFilters“

–> Neu –> Wert der mehrteiligen Zeichenfolge

–> Name für den Neuen Wert auf „UpperFilters“ festlegen

–> Rechtsklick auf „UpperFilters“ –> Ändern –> im Feld Wert folgendes eintragen: mouclass

Exchange 2010 – OWA-Fehler HTTP 500 (interner Serverfehler)

exchange2010

Nach der Eingabe von den Anmeldedaten am Outlook Web Access erscheint ein HTTP-Fehler mit Fehler-Code 500 (interner Serverfehler).

Dieser erscheint, weil der Dienst „Formularbasierter Microsoft Exchange-Authentifizierungsdienst“ nicht gestartet ist.

Entweder per GUI starten (und auf „Automatisch (verzögert) stellen) oder aber per cmd „net start msexchangefba“ eingeben.

Meist kommt es nach einer Migration zu diesem Effekt!