Wenn ein Benutzer in mehr als 1015 Gruppen(nestedGroups) ist kann er in Outlook2007 keine Frei-Gebucht-Zeiten anderer Benutzer mehr sehen.
Um das zu beheben muss ein Registrykey:
HKCU/Software/Microsoft/Office/12.0/Outlook/Options/Calendar/UseLegacyFB
als DWORD mit dem Wert 1 gesetzt werden und Outlook 2007 neu gestartet werden.
Danach fehlt aber im Kalender / Terminplanungsassistent der Button „Räume hinzufügen…“.
starte den IIS-Manager
gehe nach Servername / Sites / Default Web Site / owa / 8.1.436.0
gehe zu „Security“ und doppelklicke „Authentification“
aktiviere „Anonymous Authentification“
starte den IIS-dienst neu( und warte ca 5 Minuten, da der JIT-Compiler sich das alles nochmal durch den Kopf gehen lassen muss)
Danach versuche, wieder auf die OWA-Webseite zu kommen.
in Windows ist bis heute (W7 64BIT) die Pfadlänge (MAX_PATH) auf 255 Zeichen begrenzt.
Man kann dann Dateien sehen, diese aber nicht öffnen.
Der Grund liegt darin, dass der Explorer die WindowsANSI-Funktionen und nicht die UNICODE-Funktionen verwendet.
Sonst wäre die maximale Pfadlänge 32k groß. Es wurde also wieder alter Mist in die „neuen“ Betriebssysteme geschoben.
Besonders bei SMB-Freigaben in großen Umgebungen tritt dieses Problem auf.
Das Problem kann umgangen werden, wenn der Einsprungpunkt für das Mapping mehrere Verzeichnisse tiefer erfolgt
oder man mountet sich das Verzeichnis an einen Linuxrechner.(siehe auch SMB / CIFS)
Dort besteht das Problem natürlich nicht (bis die Pfadlänge 4096 Zeichen überschreitet.)
unter Linux kann man wie folgt die maximale Pfadlänge ermitteln:
grep PATH_MAX /usr/src/linux/include/linux/limits.h
Um diese Daten in WIndows kopieren zu können, kann robocopy verwendet werden.
Fehler 0X80040113 wird bei Tests ausgegeben.
Lösung: die Authenticated Users
müssen rekursiv Lesezugriff auf das Verzeichnis meinExch2k7verzeichnis\ClientAccess\OAB
haben.
Ein Benutzer (Sekretärin) hat Schreibzugriff(Stufe 6-8) auf den Kalender von Chef.
Sie kann im IE auf den Kalender von Chef per https://owa.dom.ain/owa/chef@dom.ain/?cmd=contents&=kalender zugreifen und Termine ändern oder verschieben aber nicht löschen.
In Outlook funktioniert das aber.
Lösung1: Sie muss auch volle Schreibrechte auf dem Ordner Gelöschte Objekte
von Chef haben, da die Termine dorthin verschoben werden.
Lösung2: Vollzugriff auf das gesamte Postfach von Chef für Sekretärin.
im Browser erschein die Fehlermeldung: Exception message: Active Directory operation failed on domcontr1.my.dom.ain. This error is not retriable. Additional information: Insufficient access rights to perform the operation. Active directory response: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
Lösung: Gehe in dsa.msc auf den Benutzer / Sicherheit / Erweitert und schalte die Vererbung ein.
(„Berechtigungen übergeordneter Objekte auf untergeordnete Objekte, sofern anwendbar, vererben. Diese mit den hier definierten EInträgen einbeziehen.“)
Eventuell muss der Benutzer aus der Gruppe der Exchange-Admins raus.
jeder hat sich schonmal über den merkwürdigen Namen der Administrativen Gruppe Exchange Administrative Group (FYDIBOHF23SPDLT)
gewundert.
Da haben sich die Programmierer von Exchange verewigt.
Wenn man jeweils eine Buchstaben zurückgeht, erhält man aus (FYDIBOHF23SPDLT)
ein (EXCHANGE12ROCKS)
Die Installation erfordert einen freien Internetzugang um die Zertifikate der Asemblys zu überprüfen. Kann der Server das nicht, dauert die Installion von Rollups bis zu mehreren Stunden, weil er für jede Datei in ein Timeout läuft. Auf keinen Fall die Installation abbrechen!
Wenn doch geschehen, dann alle Rollups im appwiz.cpl
deinstallieren und erneut installieren, neustarten,installieren,neustarten …
Dazu wird die OriginalExchangeCD erforderlich.
Nach einer Postfachverschiebung auf einen neuen Server lassen sich einige Move-Requests nicht mehr löschen. Das Postfach (nicht das AD_Konto) wurde (wegen Abkehr) zwischenzeitlich gelöscht.
Deshalb muss auf der Powershellkonsole für den Benutzer der moverequest ausgeführt werden.
remove-moverequest "Albert Einstein" -verbose Are you sure want to perform this action? Y
Nach einem Upgrade auf Exchange 2010 SP1 funktioniert Blackberry nicht mehr.
Grund: Blackberry benötigt zwingend mindestens Exchange 2010 SP3
Warning: Failed to clean up the source mailbox after the move. Error details: MapiExceptionUnexpectedMailboxState: Unable to delete mailbox. (hr=0x80004005, ec=2634)
get-MailboxStatistics -database MB1 | Where-Object {$_.DisconnectReason -eq "disabled"}
oder
get-MailboxStatistics -database MB1 | Where-Object {$_.DisconnectReason -eq "Softdeleted"}
dann Postfach aussuchen und manuell löschen bis MS einen Patch dafür bereitgestellt hat.
remove-storemailbox -database MB2 -identity "Pitti Platsch" -mailboxstate disabled
Grund: zu wenig Festplattenplatz.
Lösung: Verschieben der Queue-Dateien.
net stop "Microsoft Exchange Transport"
ändern der Einträge QueueDatabasePath
und QueueDatabaseLoggingPath
in <ExchangePfad>\bin\EdgeTransport.exe.config auf ein anderes Laufwerk.
net start "Microsoft Exchange Transport"
danach löschen der alten Verzeichnisse.
Überprüfung:
get-publicfolders -recurse | fl replicas,name get-publicmailfolders -recurse | fl replicas,name
wenn es keine Replicas auf dem Server mehr gibt, dann:
adsiedit.msc
auf einem DC ausführen
Das Postfach weist Fehler auf.
OWA-Meldung: Problem bei der Verwendung des Postfachs.
Eventvwr-Meldungen zu „QuarantinedMailboxes“
gütliche Lösung für einen Benutzer:
New-Mailboxrepairrequest --mailbox willi.wichtig@dom.ain -CorruptionType Aggregatecounts,SearchFolder,FolderView,ProvisionedFolder
Für die gesamte Datenbank:
New-Mailboxrepairrequest -database MB2 -CorruptionType Aggregatecounts,SearchFolder,FolderView,ProvisionedFolder
Anschließend die Datenbank remounten.
Lösung auf die Harte Tour(!):
GUID des Benutzers ermitteln und Registryschlüssel auf Exchangeserver löschen:
Get_MailboxStatistics wwichtig | fl DisplayName,Identity
regedit:
HKLM\SYSTEM\CurrentControlSet\Services\MSexchangeIS\meinServer\Private-Datenbank-guid\Quarantined Mailboxes\Mailbox GUID des Benutzers
diese Mailbox GUID des Benutzers
löschen und
anschließend die Datenbank remounten.
um feste RPC-Ports(hier 60000) und Adressbuchports(hier 60001) durch Firewalls zu erlauben (diese werden eigentlich dynamisch vom Exchangeserver festgelegt), müssen zwei Regkeys gesetzt werden:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters] "RpcTcpPort"="60001" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC\ParametersSystem] "TCP/IP Port"=dword:0000ea60
Hierbei ist zu beachten dass der RpcTcpPort
ein ZeroString(SZ)und kein DWORD ist.
Anschließend muss der Dienst Microsoft Exchange Address Book
und Microsoft Exchange RPC Client Access
oder der ganze Server neu gestartet werden.
Überprüfung der verbundenen Ports auf dem Exchangeserver mit:
netstat -an -p tcp | findstr 6000
Das Cmdlet New-MailboxExportRequest wird nicht in der Powershell gefunden.
Die Exportrechte muss sich der Admin erst zuweisen mit:
New-ManagementRoleAssignment -Role "Mailbox Import Export" -User AdminvonExch
Dann die Powershell schließen.
Das Cmdlet will nur in ein Share schreiben, deshalb muss lokal auf dem server ein Share vorher für den admin freigegeben werden:
Deshalb die Powershell jetzt mit Adminrechten öffnen und:
md d:\temp net share temp=d:\temp /GRANT:AdminvonExch,FULL
Jetzt erst ausführen von:
New-MailboxExportRequest –Mailbox doedel –Filepath \\myExchsrv\temp\doedel.pst
Nach erfolgreichem Abschluss der Aktion(!) Share wieder löschen:
net share temp /delete
Alle zu sendenden Mails aus Outlook heraus landen im Postausgang.
Alle zu sendenden Mails aus OWA heraus landen im Ordner Entwürfe.
SMTP-Fehler 421 4.3.2 Service not active
Ursache: Das CU deaktiviert beim Start schonmal die Komponenten aber noch nicht die Dienste.
Ursachenforschung / Behebung:
Get-ServerComponentState -identity meinExchsrv
alle Komponenten wieder auf active
setzen (Bsp.):
Set-ServerComponentState -identity meinExchsrv -component HubTransport -state active -requester Functional
alte gelöschte Benutzer sind noch im AD-Objekt des zu berechtigenden Postfachs vorhanden.
diese müssen mit adsiedit.msc aus dem Feld „publicdelegates“ manuell gelöscht werden.
Danach noch die Exchange Mangement Console mit <F5> manuell aktualisieren.