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)

Outlook 2011/2016 für Mac fragt immer wieder nach Benutzername und Passwort

Problem

Microsoft Outlook für Mac 2011 und Outlook für Mac 2016 fragen bei der Anbindung an einen lokalen Exchange-Server (Exchange 2007/2010/2013/2016) immer wieder nach Name und Kennwort („Benutzernam eoder Kennwort falsch), obwohl die Eingabe ganz ganz ganz sicher richtig ist. Egal ob man sich mit „benutzername“ oder „domäne\benutzername“ oder „domä.ne\benutzername“ anmeldet – es wir immer wieder nachgefragt. Spannenderweise kann das Adressbuch aber mit den selben Daten problemlos synchronisiert werden.

Lösung

MacOSX hat seit 93 Äonen einen Bug im Keyring, der dafür sorgt das alle Benutzerdaten vor dem „\“ (Slash) entfernt werden. Man fügt also einen zusätzlichen slash ganz an am anfang des Namens hinzu und schon läuft wieder alles ..

\Domä.ne\Benutzername

Diesen Slash einfach hinzufügen.

Outlook 2010/2013 „Diese Ordnergruppe kann nicht geöffnet werden. Fehler bei der Anmeldung an Microsoft Exchange“

Problem

Ein Outlook-Client möchte freigegebene oder „gemeinsam genutzte“ Mailboxen („Gemeinsame Ordner“) von einem Exchange Server 2010/2013 nicht mehr freiwillig öffnen. Das passiert bei Exchange 2013 nach der Installation von CU5 (oder höher) aber auch sporadisch. Die Ordner werden zwar weiterhin per Automapping ins Outlook eingebaut und sind dort sichtbar, können aber nicht geöffnet werden. Manchmal sind die Ordnernamen dort auch nicht mehr korrekt, sondern es wird nur noch ein Name mehrfach hintereinander angezeigt.

Achtung: Die selben Symptome treten auch auf, wenn eine PST-Datei mit Outlook verbunden ist, die nicht richtig glesen werden kann. Bei wiederspenstigen PST-Files hilft aber SCANPST („%ProgramFiles(x86)%\microsoft office\officeNN“) schnell und zuverlässig weiter.

Lösung

Es gibt da einen „Effekt“ bei der Anwendung der Exchange-Updates (CU5/CU6/CU7 bisher). Was genau die Ursache ist wissen wir nicht und betrachten es auch nicht als unsere Aufgabe, den Fehler zu suchen. Fakt ist, das die Automapping-Services tatsächlich falsche Daten an einge Outlook-Clients übergeben. In der XML-Datei sind tatsächlich doppelte Ordnernamen und falsche IDs enthalten.

Der Fehler kann manuell schnell (wir sind ja hier bei ugg.li) behoben werden, durch die Umgehung der AutoMapping-Funktion:

  1. Rechte auf dem betroffenen Postfach erst entfernen
    Remove-MailboxPermission -Identity GEMINSAMESPOSTFACH -user USERNAME -AccessRights FullAccess -InheritanceType All
  2. Dann die Rechte wieder hinzufügen, ohne Automapping
    Add-MailboxPermission -Identity GEMEINSAMESPOSTFACH -user USERNAME -AccessRights FullAccess -InheritanceType All -AutoMapping $false
  3. Gemeinsam genutze Postfächer manuell im Outlook-Profil verbinden (Profil Ändern > Erweiterte Einstellungen > Tab „Erweitert“ > hinzufügen). Dann klappts auch wieder mit dem Zugriff.