Microsoft Exchange

Office 365 Öffentliche Ordner können von extern keine Mails empfangen

Manchmal kommt es vor, dass bei neu eingerichteten Office 365 Umgebungen mit Öffentlichen Ordnern (Public Folders), diese keine Mails von extern empfangen können, obwohl augenscheinlich alles richtig eingestellt ist. Die Absender bekommen dann eine Unzustellbarkeitsnachricht zurück ( 550 5.4.1 [xxx@xxx.de]: Recipient address rejected: Access denied ).

In dem Fall sollte überprüft werden, ob in der EAC vom Admin-Center die Domäne als „internes Relay“ eingerichet ist.

Sollte diese Einstellung immer noch nicht ausreichen, so muss über die Powershell folgendes Kommando ausgeführt werden:

$UserCredential = Get-Credential

Es sollte ein Fenster erscheinen, in dem die Anmeldedaten für den jeweiligen O 365 Account eingetragen werden müssen.

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session -DisableNameChecking

get-publicfolder -recurse | Add-PublicFolderClientPermission -User Anonymous -AccessRights CreateItems

Remove-PSSession $Session

Loading

Von |2020-03-19T12:14:46+01:00Dezember 13th, 2018|Microsoft Exchange|0 Kommentare

Outlook aus freigegebenem Postfach (oder per Vollzugriff verbundenem Postfach) gesendete e-mails landen im falschen gesendete Elemente Ordner

Wenn ein Outlook-Benutzer weitere verbundene Konten (per Vollzugriff oder freigegebene Postfächer hat) und unter diesen Konten E-Mails verschickt (senden als), dann landen die gesendeten Mails im eigenen Ordner „gesendete Objekte / Elemente“.

Das macht ggf. keinen Sinn, da weitere Personen, die mit diesem freigegebenen Postfach arbeiten, nicht nachvollziehen können, dass Mails bereits beantwortet wurden, etc.

Dieses Verhalten kann per Registry Fix verändert werden:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Preferences]
„DelegateSentItemsStyle“=dword:00000001

Die 15.0 steht für die Office-Version, allgemein gelten hier folgende Werte:

  • 13.0 = 2007
  • 14.0 = 2010
  • 15.0 = 2013
  • 16.0 = 2016 / 365

Loading

Von |2020-03-19T12:15:39+01:00November 18th, 2018|Microsoft Exchange|0 Kommentare

Exchange 2013: Adressbuch wird im Outlook Cached Mode bei externen Clients nicht heruntergeladen

Es war nicht möglich, das Offlineadressbuch herunterzuladen. Outlook hing beim herunterladen, es erschien keine Fehlermeldung.

Bei Clients, die sich in der Domäne befanden, funktionierte es hingegen. Also konnten wir davon ausgehen, dass die Adressbücher grundsätzlich korrekt funktionierten.

Es stellte sich heraus, dass Exchange 2013, anders als 2010, das virtuelle Verzeichnis „OAB“ im IIS nicht mit Basic Authentication $true (Standardauthentifizierung) angelegt hatte.

Dieses bitte NICHT im IIS ändern, Exchange würde es wieder überschreiben.

Der korrekte Befehl für die Powershell lautet:
Set-OabVirtualDirectory -Identity „EXCHANGE2013\oab (Default Web Site)“ -BasicAuthentication $true

Loading

Von |2020-03-19T12:15:05+01:00Januar 14th, 2014|Microsoft Exchange|Kommentare deaktiviert für Exchange 2013: Adressbuch wird im Outlook Cached Mode bei externen Clients nicht heruntergeladen

Exchange 2013: Öffentliche Ordner werden in Outlook nicht angezeigt

Nach der Migration unserer Öffentlichen Ordner vom Exchange 2010 auf Exchange 2013 wurden die Öffentlichen Ordner in Outlook 2013 nicht mehr angezeigt.

Wobei hier noch zu differenzieren ist:

Bei Domänen-PCs funktionierte in allen Outlook-Versionen alles korrekt.

Bei PCs ausserhalb der Domain, wurden die Öffentlichen Ordner in Outlook 2007, 2010, Outlook for Mac 2011 und WebApp zwar angezeigt, man konnte jedoch nicht auf sie zugreifen. Fehlermeldung in etwa:
„Der Ordner kann nicht erweitert werden. Microsoft Exchange ist nicht verfügbar. Es bestehen Netzwerkprobleme, oder der Servercomputer mit Exchange wurde für Wartungsarbeiten heruntergefahren.“

Bei Outlook 2013 wurden die Öffentlichen Ordner erst gar nicht eingeblendet. Fehlermeldungen erschienen nicht. Patch-Stand war überall der aktuellste.

Es stellte sich nach tagelanger Fehlersuche heraus, dass mal wieder ein Autodiscover-Problem vorlag.

Hier muss kurz noch etwas zum Hintergrund der neuen „modernen“ Öffentlichen Ordner von Exchange 2013 gesagt werden: diese funktionieren nun als Postfächer in der normalen Mailbox-Database. Es gibt keine eigene Öffentliche-Ordner Datenbank mehr.

Der Fehler entstand dadurch, dass die Standardadresserstellungsrichtlinie das Öffentliche-Ordner Postfach mit der primären SMTP-Adresse @Domain.local angelegt hatte. Autodiscover versucht nun „publicfoldermailbox@domain.local“ zu öffnen, was natürlich fehlschlägt, da DNS @Domain.local natürlich nicht funktioniert. Daher können die Öffentlichen Ordner, bzw. das dazugehörige Postfach, nicht korrekt hinzugefügt werden.

Abhilfe:
http://support.microsoft.com/kb/2788136

Kurz gesagt: Ändern der primären SMTP-Adresse des Öffentlichen-Ordner Postfaches auf eine über Autodiscover erreichbare Domain, optimalerweise natürlich wie die restlichen E-Mail-Adressen der Domain. Alternativ ändern der Standardadresserstellungsrichtlinie auf die Domain, die man auch extern nutzt (@Domain.de). Wir hatten das deshalb nicht gemacht, weil wir auch Hosting betreiben und daher als „Standarddomain“ unsere @local nutzen.

Ändern der primären SMTP-Adresse der PublicFolder Mailbox:
Set-Mailbox -publicfolder „Mailbox-Name“ -PrimarySMTPAddress mailboxname@domain.com -EmailAddressPolicyEnabled $false

Über:
Get-Mailbox -publicfolder | fl Name,*primary*
kann man sich die Adresse(n) auch anzeigen lassen.

Es dauert ca. eine Stunde, bis Active-Directory die Autodiscover.XML wieder überall veröffentlicht hat. Anschließend blenden sich die Öffentlichen Ordner von alleine bei den Outlooks ein.
Vorausgesetzt natürlich immer, dass Autodiscover vernünftig funktioniert. Dabei spielt es auch keine Rolle, ob die PCs sich im internen Netzwerk oder im Internet befinden. Nur Domänen-PCs nutzen noch die Service-URI im AD, so dass Autodiscover hier ggf. umgangen wird.

Loading

Von |2020-03-19T12:15:13+01:00Januar 12th, 2014|Microsoft Exchange|3 Kommentare
Nach oben