Dienstag, 17. Januar 2012
Problem :
Benutzer bekommt bei dem Versuch eine E-Mail zu senden eine Antwort vom Exchange Server das ein versenden nicht möglich ist.
Bild Fehlermail:
Lösung :
Im Internet existieren mehrere Lösungvorschläge zu diesem Problem. In meinem Fall konnte der Fehler nur behoben werden indem ich das Standardprofil des Mailclients komplett gelöscht habe um es erneut anzulegen. In der Systemsteuerung\Benutzerkonten das Icon E-Mail anklicken dann unter Profile das Default Profil löschen. Ein Tipp der bei mir leider nicht funktioniert hatte aber bei euch vielleicht ist den Exhchange Cache Mode zu deaktivieren anschließend die OFT Dateien löschen und den Cache Mode wieder aktivieren. Dannach werden die OFT Dateien neu angelegt. Ein komplettes Neuanlegen des Windows Profiles löst das Problem auch allerdings macht man sich mehr arbeit als nötig (musste ich schreiben da es auch als Tipp im Internet unterwegs ist)
Dienstag, 17. Januar 2012
Problem :
Es können keine E-Mails zum Kunden zugestellt werden , hier bietet es sich an direkt mit dem SMTP Server zu reden um die eigene Domain zu überprüfen auch kann man überprüfen ob es den Empfänger im Zielsystem gibt.
Lösung :
Unter Windows 7 muss der Telnet-Client nachinstalliert werden , oder ein externes Tool das eine Telnetverbindung ermöglicht (z.B. Putty) . Ich werde hier das Testen mit dem Microsoft Telnet Client erklären. Um die IP-Adresse des Zielservers zu ermitteln bzw. die grundsätzliche Funktion des Servers zu checken bietet sich die MX-Toolbox an.
1.) Starten einer Eingabeaufforderung
2.) Verbindung zum Zielserver aufbauen mit telnet IP PORT z.B. telnet 0.0.0.0 25 (25 ist der Standard SMTP Port)
3.) mit dem Befehl helo DeineDomain einleiten
4.) mail from: ‹DeineEMailAdresse› wichtig ist das hier der genau Syntax eingehalten wird !
5.) rcpt to: ‹EmpfängerEMailAdresse› hier wird der Empfänger eingetragen
6.) mit data wird der Body der EMail eingeleitet
7.) nachdem man fertig ist mit dem Text Return betätigen und dann . Return , das schließt den Body und die EMail wird versendet
8.) mit QUIT wieder vom Server abmelden
Informationen zu SMTP Befehlen und Statuscodes ---> http://www.elektronik-kompendium.de/sites/net/0903081.htm
Montag, 19. Dezember 2011
Problem:
Ein Benutzer hat immer wieder das Problem, dass er folgende Fehlermeldung erhält:
Ein MAPI-Client-Fehler ist aufgetreten
Gleichzeitg wir folgendes Event auf dem Exchange Server generiert (Die Meldung kann variieren) :
Ereigniskennung: 9646
Typ: Fehler
Quelle: MSExchangeIS
Beschreibung:
Die MAPI-Sitzung "/o=Exchange Organisation/ou=Exchange Administrative Gruppe (FYDIBOHF23SPDLT)/cn=Empfänger/cn=Benutzer" hat die maximal zulässige Anzahl von 500 Objekten vom Typ "objtFolder" überschritten und wird daher beendet.
Lösung:
Das Problem tritt auf, wenn ein Client mehr Objekte, als die zulässige maximale Anzahl, öffnet.
Zuerst sollte man überprüfen, ob nicht ein Virus dieses Problem verursacht. Dazu sollte man den Client, bei dem das Problem auftritt, nach Viren scannen.
Sollte sich herausstellen, dass der Client keinen Virus hat und tatsächlich so viele Objekte öffnet, was bei einer Sekretärin mit mehreren Postfächern vorkommen kann, dann kann diese maximal zulässige Anzahl am Exchange-Server erhöht werden.
Hierzu bitte wie folgt vorgehen:
1.) REGEDIT auf dem Exchangeserver starten
2.) Öffnen Sie folgenden Key "HKEY_LOCAL_MACHINE SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem"
3.) Erstellen Sie einen neuen Schlüssel unter ParametersSystem namens "MaxObjsPerMapiSession"
4.) Erstellen Sie unter "MaxObjsPerMapiSession" einen neuen DWORD-Wert des Objekttyps (Objekttyp entnehmen Sie dem Fehlerereignis 9646 z.B. "objtFolder")
5.) Stellen Sie hier den gewünschten maximalen Wert ein (z.B. 500)
Quelle: support.microsoft.com KB925815 - Ein Exchange 2007 Server reagiert nicht mehr auf Übermittlungen von einem MAPI-Client und es wird die Ereigniskennung 9646 im Anwendungsprotokoll protokolliert
Mittwoch, 14. Dezember 2011
Welcher Administrator kennt es nicht , die Sammelwut der Benutzer. Im Laufe der Zeit sammeln sich immer mehr E-Mail mit Anhängen an und belasten das Postfach unnötig. Viele dieser Anhänge könnten gelöscht werden , nur die Nachricht soll erhalten bleiben. Diese Aufgabe übernimmt ein kleines Freewaretool von NirSoft. Dieses Tool kann hier heruntergeladen werden.
Quelle :
Outlook Attach View
Direkter DL : 32Bit Version 64Bit Version
Donnerstag, 1. Dezember 2011
Problem :
Weiterleiten der eingehenden Mails an eine Verteilerliste funktioniert nicht von extern , intern funktioniert die Weiterleitung.
Lösung :
Navigiere zu der Exchange Management Cosole zur betroffenen Verteilergruppe (Recipient Configuration -> Distribution Group)
Unter Mail Flow Settings -> Message Delivery Restrictions -> Properties die Einstellungen wie im Screenshot anpassen.
Freitag, 18. November 2011
Problem :
Exchange 2007 schreibt ständig Fehler mit folgendem Inhalt ins Application (Anwendung) Log
EventID : 3083
Category : Gatherer
Description : The protocol handler Search.Mapi2Handler.1 cannot be loaded. Error description: Class not registered
Der Fehler liegt daran das kein 64-Bit Outlook MAPI Provider verfügbar ist
Lösung :
Erstellen einer Reg Datei mit folgendem Inhalt :
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{9E175BA9-F52A-11D8-B9A5-505054503030}]
@="Search Gatherer Log File Provider"
[HKEY_CLASSES_ROOT\CLSID\{9E175BA9-F52A-11D8-B9A5-505054503030}\InprocServer32]
@=hex(2):25,00,73,00,79,00,73,00,74,00,65,00,6d,00,72,00,6f,00,6f,00,74,00,25,\
00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,73,00,\
73,00,72,00,63,00,68,00,2e,00,64,00,6c,00,6c,00,00,00
"ThreadingModel"="Both"
[HKEY_CLASSES_ROOT\CLSID\{9E175BA9-F52A-11D8-B9A5-505054503030}\ProgID]
@="Search.GathererLogFileProvider.1"
[HKEY_CLASSES_ROOT\CLSID\{9E175BA9-F52A-11D8-B9A5-505054503030}\VersionIndependentProgID]
@="Search.GathererLogFileProvider"
Dannach war der Fehler auf dem Exchange 2007 Server weg
Freitag, 11. November 2011
Problem:
Der Exchange 2007 Server meldet folgendes Event alle 5-10 Minuten:
Event Type: Error
Event Source: MSExchangeSA
Event Category: General
Event ID: 9153
Date: 29.07.2008
Time: 16:49:12
User: N/A
Computer: xxxxx
Description:
Microsoft Exchange System Attendant reported an error '0x80072020' when setting DS notification.
Lösung:
Meistens hilft es hier einfach den Exchange-Dienst "Exchange Systemaufsicht" bzw. "Microsoft Exchange SystemAttendant" neu starten und die Meldung sollte weg sein.
Quelle: .msexchange.org: Microsoft Exchange System Attendant reported an error '0x80072020' when setting DS notification.
Dienstag, 16. August 2011
Problem:
Als Admin möchte man die Rechte auf Postfächer zentral administrieren. Normalerweise ist der Benutzer selbst für die Rechtevergabe zuständig und es ist auch nicht möglich über die Verwaltungstools von Exchange die Rechte anzupassen. Ein komplexer Powershell-Befehl ab Exchnage 2007 könnte die Berechtigung setzen, aber Powershell ist manchmal etwas anstrengend
Lösung:
Man kann das Tool " PFDAVAdmin" von Microsoft verwenden. Ursprünglich wurde das Tool zum Verwalten von Öffentlichen Ordnern entwickelt, daher auch der Name. Doch man kann das Programm auch zum administrieren von Benutzerpostfächern verwenden.
Die Bedienung ist recht schlicht und einfach gehalten. Man kann sich bis zum Postfach oder Teilberich des Postfachws (z.B. Kalender etc.) durchklicken und hier die Berechtigungen anpassen - Vorraussetzung ist natürlich man hat die Anmeldedaten eines Exchange-Administrator-Kontos.
Um Zugriff auf die Benutzerpostfächer zu erhalten, muss man beim Starten nur die Option "All Mailboxes" auswählen.
Es ist KEINE Installation nötig und kann von jeder Workstation gestartet werden!!
Unterstützte Exchange-Versionen: Exchange 2000/2003/2007
Für Exchange 2010 wurde das neue Tool Exfolders entwickelt.
Ein schöne Anleitung findet man unter: Exchangeshare: FAQ: Give Calendar Read Permission on all Mailboxes – PFDavAdmin
Download PFDAVAdmin: Microsoft Download Center: Microsoft Exchange Server Public Folder DAV-based Administration Tool
Hinweis
Auf dem Rechner, auf dem PFDavAdmin gestartet wird muß .NET Framework 1.1 installiert sein. Bei Windows 7 Rechner muss dieses manuell installiert werden.
Sollte .NET Frework 1.1 nicht installiert sein, dann erhält man folgende oder ähnliche Fehlermeldung:
'Could not expand https://localhost/exadmin/admin/mydomain.com/public%20folders/ : name cannot begin with the '0' character, hexadecimal value 0x30. Line 1, position 386'
Quelle: mostlyexchange: PFDAVADMIN, Exchange 2007, and the v1.1 .NET Framework
ACHTUNG - WICHTIGER HINWEIS - UNBEDINGT LESEN!!!!
ACHTUNG: Installieren Sie AUF KEINEN FALL .NET Framework 1.1 auf einem EXCHANGE 2007 Server!!! Dies kann zum TOTALAUSFALL der Exchange-Dienste führen!!
Montag, 8. August 2011
Problem:
Die Transportregeln funktionieren plötzlich nicht mehr.
Die Regeln basieren auf eine Domänen-Angabe wie "@domain.tld"
Lösung:
Das Problem tritt erst mit der Installation des Rollup Update 9 für Exchange 2007 auf. Hier würde etwas grundlegendes in den Reglen geändert.
Die Angabe der Domäne innerhalb der Regeln MUSS OHNE @-Zeichen erfolgen.
Ändert man seine Regeln von "@domain.tld" auf " domain.tld" dann funktioniert die Regel wieder problemlos.
Quelle:
mxforum: Transport Regel funktioniert nicht auf allen CAS
Exchange Server Technet Forum: Exchange 2007 transport rule is being ignored after RU9
Freitag, 1. Juli 2011
Problem:
Nach der Installation eines RollupPacks für Exchange 2007 funktioniert OWA nicht mehr. Es erscheint keine Fehlermeldung sondern es wird nur eine leere Seite angezeigt. In der URL-Leiste wird folgendes angezeigt:
https://mail.yourdomain.com/owa/auth/logon.aspx?url=https://mail.yourdomain.com/owa/&reason=0
Alle Dienste laufen und auch der Zugriff der mobilen Geräte über Outlook Anywhere etc. funktioniert.
Lösung:
Bei der Installation des RollupPacks hat es ein Problem bei der IIS-Aktualisierung gegeben. Damit wurde die OWA-Seite nicht aktualisiert oder die Installation des RollupPacks wurde abgebrochen.
Hierfür gibt es zwei Lösungsansätze:
1.) Neuinstallation RollupPack
Man kann den Rollup-Pack einfach nochmals installieren.
WICHTIG: Die Installation des RollupPacks kann einige Zeit in Anspruch nehmen (über 30 Minuten)...die Installation NICHT abbrechen.
2.) nachträglich Powershell-Skript für OWA-Update
Man kann das OWA-Update auch manuell anstarten. Hierzu startet man die Exchange-Verwaltungs-Shell und gibt hier folgenden Befehl ein:
updateowa.ps1
Nach wenigen Sekunden ist die OWA-Seite wieder online und alles funktionier wie gewohnt.
Trotzdem würde ich den RollupPack in einer ruhigen Minute erneut installieren.
Quelle: exchangeserverpro.com: Exchange 2007 OWA stops working with “reason=0” error
|