E-Mails die in Outlook von einem gemeinsamen Postfach aus versendet werden, landen nicht im gemeinsamen „Gesendete Objekte“ Ordner

Seit Office 2010 ist die Standarteinstellung von Outlook-Ablageobjekten nicht immer optimal. Neue Nachrichten, die von einem gemeinsamen (ob fremdgeöffnet oder als shared Mailbox angelegt ist egal) Postfach gesendet werden, werden nicht im Ordner „Gesendete Objekte“ des freigegebenen Postfachs abgelegt, sondern im Postfach des absendenden Benutzers. Das sorgt oft für Verwirrung.

Das liegt daran, das in Exchange 2010+ und Office 365 freigegebene Postfächer keine Lizenz mehr benötigen und man Outlook nicht mehr als „unabhängiges“ Postfach verbinden kann. In so einem Fall meldet man sich konsequenterweise aber beim eigenen Postfach an und öffnen das freigegebene Postfach zusätzlich. Beim Senden nimmt Outlook dann standartmäßig das Konto des Absenders. Daher werden Nachrichten – im Prinzip folgerichtig – auch immer im Ordner „Gesendete Objekte“ das Postfach des Absenders (also angemeldeten Nutzers) gespeichert.

Dieses Verhalten ist reine Outlook-Sache (nicht Exchange) und lässt sich schnell in der Registry anpassen:

HKCU\Software\Microsoft\Office\<VERSION>\Outlook\Preferences
DWORD: DelegateSentItemsStyle
Wert: 1 (für Ablage in geöffnetem Postfach)
Wert: 0 (für Ablage in eigenem Postfach, Standart)

certutil 0x80090005 (-2146893819 NTE_BAD_DATA)

Wenn man unter Windows mit dem MMC Zertifikats-SnapIn einen frischen CSR erstellt („REQ“ im Windows-Jargon), wird standartmäßig der aktuelle „Microsoft Strong Crytographic Provider“ als Kryptoanbieter ausgewählt. Das ist im Prinzip auch gut so, denn das ist der aktuellste und vom Umfang her größte CSP (Certificate Storage Provider) den Windows mitbringt. Die meisten Windows-Features können damit auch problemlos umgehen – der IIS, der SMTP, RDS und so weiter.

Nicht jedoch Exchange (bis einschliesslich 2016 CU3). Exchange FBA unterstütz keine CNG Zertifikate. Nutzt man diese doch, kommt es zu dem berüchtigten Exchange OWA und Exchange EAC Anmeldeloop.

Folgt man dem im Blog angegebenen Anweisungen zum austausch der Zertifikates und erstellt ein neues passendes Zertifikat, kommt es beim Import der neuen Zertifikate (ob CER oder PFX spielt keine Rolle) oftmal zu dem Fehler

certutil 0x80090005 (-2146893819 NTE_BAD_DATA)

Ursache hierfür ist, das der im CSR angegebene CSP nicht korrekt ist. Wenn man den CSR unter Windows erstellt, versteckt sich das zugehörige Häkchen unter Neue Anforderung erstellen > Eigenschaften > Privater Schlüssel > Kryptografiedienstanbieter. Der für den CSR ausgewählte CSP lässt sich mit certutil an der Kommandozeile selbstverständlich nicht nachschauen …

Exchnage 2007/2010/2013/2016: „Vorangegangener Installationsfehler beim Ausführen der Aktion Install/Uninstall“

Problem

Das Exchange 2016 Setup hakt an so manchen stellen. Ganz besonders häufig treten Fehler bei der Deinstalation einer Rolle auf, oder bei einem CU-Update. Fehler wie dieser:

Vorangegangener Installationsfehler beim Ausführen der Aktion „Install“ [oder auch "uninstall", je nachdem]. Die Installation kann nicht fortgesetzt werden.

Lösung

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15

  1. In  allen Schlüssel hierunter nach der Zeichenfolge „Action“ suchen, welcher den Wert „Install“ (oder Uninstall, je nachdem) beinhaltet.
  2. Den ganzen Eintrag löschen

Danach läuft das Setup wieder. Zwar im Recovery-Modus, aber normalerweise damit auch erfolgreich.

Outlook 2016 gegen Exchange 2016 fragt immer wieder nach Kennwort („MAPI Virtual Directory Bug in Exchange 2016 CU2“)

Problem

Outlook 2016 verbindet sich nicht zu Exchange 2016. OWA geht. Die wichtigen URLs sind alle richtig konfiguriert:

Get-ClientAccessServer | fl autodiscover*
Get-ActiveSyncVirtualDirectory | fl *url*
Get-OutlookAnywhere | fl *hostname
Get-WebServicesVirtualDirectory | fl *url*
Get-OwaVirtualDirectory | fl *url*
Get-OabVirtualDirectory | fl *url*

Outlook 2013 funktioniert einwandfrei. Bei Outlook 2016 schlägt allerdings schon das hinzufügen eines Profils in der Systemsteuerung fehl – Man wird immer wieder nach Name und Kennwort gefragt.

Lösung

No+MAPI+AuthenticationExchange 2016 CU2 bringt einen (bisher ungefixten) ziemlich fiesen und schwer zu jagenden Bug mit. Wenn man im GUI (ECP) das virtuelle Verzeichnis „mapi“ (für die RPC/HTTP von Outlook 2016) bearbeitet, wird beim Speichern immer die IIS-Authentifizierung zurückgesetzt. Immer. Auf nichts. Leer. Egal ob man auf der Seite etwas macht oder nicht, egal was man macht.

Fix für alle mapi-Verzeichnisse

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate,OAuth

Vielen Dank Microsoft für erfüllte neun (!) Stunden Fehlersuche mit viel Haare raufen. Vor allem vielen Dank für die absolute Abstinenz jeglicher Outlook-Discovery debugging-Werkzeuge (nein, dieser Server war nicht extern erreichbar).

Exchange 2013/2016 alle PST-Dateien aus einem Verzeichnis auf einmal importieren (bulk)

Nach einer „kalten“ Migration, nach einem Desaster oder einer anderen PST-Export-Orgie liegen in einem Ordner oft viele wichtige PST-Dateien, deren Inhalt wieder den Weg in die Mailboxen der passenden Benutzer finden soll.

Die Waffe der Wahl dazu heisst „New-MailboxImportRequest„. Wenn das CMDlet noch nicht eingeschaltet ist ( … nicht gefunden …) oder für diesen Benutzer aus magischen RBAC-Gründen nicht zur Verfügung steht, hilft ein:

New-ManagementRoleAssignment -Name "Import Export PST" -SecurityGroup "Organization Management" -Role "Mailbox Import Export"

In der Active Directory-Gruppe „Organization Management“ ist der erste Domänen-Administrator (und der schlaue Zweit-Admin) selbstverständlich Mitglied. Wenn nicht, ändern und neu anmelden. Gruppenmitgliedschaften werden nur beim anmelden übergeben!

Alle PST-Dateien aus einem Verzeichnis in die selben Ordner importieren:

dir \\SERVER\FREIGABE\*.pst | %{ New-MailboxImportRequest -Mailbox $_.BaseName -FilePath $_.FullName -TargetRootFolder /}

Exchange 2016: „Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container.“

Problem

Das Setup von Exchange 2013/2016 brit untätig mit dieser Fehlermeldung ab:

Setup encountered a problem while validating the state of Active Directory:
Couldn't find the Enterprise Organization container

Das Exchange Setup Logfile (C:\ExchangeSetupLogs\ExchangeSetup.log) liefert ähnlich genau Details:

[11/08/2016 05:36:10.0207] [1] Failed [Rule:AdInitErrorRule] [Message:Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container. See the Exchange setup log for more information on this error.]
[11/08/2016 05:36:10.0223] [1] [RECOMENDED] Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2007 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2007 servers.
[11/08/2016 05:36:10.0223] [1] [RECOMENDED] Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2010 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2010 servers.
[11/08/2016 05:36:10.0223] [1] [REQUIRED] Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container. See the Exchange setup log for more information on this error.
[11/08/2016 05:36:10.0223] [1] Help URL: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.AdInitErrorRule.aspx
[11/08/2016 05:36:10.0238] [1] Ending processing test-SetupPrerequisites

Lösung

In dieser Domäne wurde ein Exchange 2007 oder Exchange 2010 Server deinstalliert. Im letzten Schritt entfernt das Exchange Setup nämlich die „Erste Organisation“ aus dem ActiveDirectory, aber hinterlässt die Microsoft Exchange System Objects. Das verwirrt das 2013’er Setup. Vermutlich wurde dieser Fall bei Microsoft nicht getestet (wer will auch Exchange deinstallieren?).

Das Setup von Exchange 2007 (SP3+) oder Exchange 2010 einfach nochmal aufrufen:

C:\THINGS\ex2007> setup /preparead /on:"<ORGANISATIONSNAME>"

Die Installation ist nicht notwenig, nur das PrepareAD. Das Setup baut die entsprechenden Contain wieder ein und das Exchange 2013/2016 Setuo läuft problemlos durch.

Exchange 2013 internes Relay nach „RCPT TO:“ sehr langsam

exchange-delay-after-rcpttoProblem

Ein Exchange 2013 Receive Connector reagiert nach dem RCPT-Kommando extrem langsam. so langsam, das verschiedene SMTP-Clients sogar mit einem timeout reagieren. Die Zustellung klappt aber in den meisten Fällen.

Lösung

Der Empfangsconnector umgeht warscheinlich die Anti-Spam Agents nicht. In der Standarteinstellung hat eine Anonyme Verbindung (wie es bei einem Relay meistens der Fall ist) auf einem Connector nicht das Recht, die lokalen Filter zu umgehen. Daher kommt es zu (RBL und Tarpitting) Wartezeiten.

Umgehen der filter für Anonyme Verbindunge erlauben:

[PS] C:\> Get-ReceiveConnector -Identity "SERVER\Connectorname" | Add-ADPermission -user "NT-Autorität\Anonymous-Anmeldung" -ExtendedRights Ms-Exch-Bypass-Anti-Spam

In der Englischen Version eines Active Directory ist die (in UTF-8 geschriebene) „NT-Autorität\Anonymous-Anmeldung“ durch das entsprechende Prinzipal eines EN Active Directory zu ersetzen: „NT AUTHORITY\ANONYMOUS LOGON“.

In einen sehr guten Artikel zu dem Thema Connectoren“ hat der Zach schon vor einer Weile die wichtigen eigenschaften und das Schema zusammengefasst: http://www.the-little-things.net/blog/2014/07/06/exchange-receive-connector-tango-part-1/

Office 365 Powershell Download/Setup/Installation

Die Windows PowerShell für Office 365 ist ein sehr leistungsfähiges Tool. Erweiterbar wie ein IBM Universal  Business Adapter und in etwa auch so komplex. Es gibt einen Punkt in der Lernkurve, an dem Anfänger häufig den Faden verlieren; dies passiert in der Regel nach dem Erlernen der einfachsten Cmdlets und bevor die Erstellung nützlicher Lösungen vollständig verstanden worden ist. Es ist eine einfache Sache „Get-Process“ auszuführen, aber eine andere eine Reihe von Cmdlets in eine Pipeline für einen Remotecomputer einzureihen, um eine Aktion remote auszuführen. Grade Office 365 ist beispielsweise nicht vollständig in die „Ausliefershell“ integriert und benötigt einige zusätzliche Module und die Initialisierung der Remote-Shell.

So gehts auf in die Office 365 Powershell

  1. Betriebssysteme unter Windows7/2008R2 brauchen WinRM2.0 mit der Powershell 2.0
  2. Download und Installation Microsoft Online Services Sign-in Assistant
  3. Download und Installation Azure Active Directory (AD) Module (x64, eine 32-bit-VErsion gibt es noch, wird aber nicht mehr supported)
  4. Optional: „SharePoint Online Module“ (Zur Sharepoint-Verwaltung)
  5. Optional: „Skype for Business Online Module“ (Zur Lync Skype for Business Verwaltung)

Verbindung zur Office 365 Powershell

$credential = get-credential
Import-Module MSOnline
Connect-MsolService -Credential $credential

Verbindung zur Skype for Business Powershell

Import-Module LyncOnlineConnector
$lyncSession = New-CsOnlineSession -Credential $credential
Import-PSSession $lyncSession

Verbindung zur Sharepoint Powershell

Import-Module Microsoft.Online.Sharepoint.PowerShell
Connect-SPOService -url https://contoso-admin.sharepoint.com -Credential $credential

Verbindung zur Exchange Powershell

$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $credential -Authentication "Basic" -AllowRedirection
Import-PSSession $ExchangeSession

Verbindung zu den Office 365 Onlinediensten via Poweshell-Function

function Connect-O365 {
<#
.Synopsis
 Connects powershell to Office 365
.DESCRIPTION
 Use this to connect powershell to Office 365. You will be prompted for credentials.
.EXAMPLE
 Connect-O365
#>
 Set-ExecutionPolicy RemoteSigned
 $Cred = Get-Credential
 $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $Cred -Authentication Basic -AllowRedirection
 Import-Module (Import-PSSession $Session -Allowclobber) -Global
 Connect-MsolService -Credential $Cred
}

(Danke Alex)