ActiveSync - "Accountinformationen konnten nicht überprüft werden" oder "Benutzername/Passwort falsch"

Wir sind mitten in der Umstellung von Exchange 2010 auf Exchange 2016.
Da wir ja nicht alle Postfächer gleichzeitig auf Exchange 2016 verschieben können, müssen beide System parallel laufen.

Zum Testen kaufen wir uns ein Zertifikat für mail1.domain.de und spielten es ein.
Im OWA erfolgreich getestet. Sobald man auf mail1.domain.de gint, wurde der Anmeldescreen von Office 2016 gezeigt und die Weiterleitung an Office 2010 erfolgte nach erfolgreicher Anmeldung.

Haben sich nun aber die User den Server im Smartphone/Tablet eingetragen, dann erhielten einige

"Accountinformationen konnten nicht überprüft werden" oder "Benutzername/Passwort falsch". 

Also machten wir mit einigen Usern über

https://testconnectivity.microsoft.com

den ActiveSync-Test.

Die Fehlermeldung war:

Eine unerwartet Weiterleitung.

Und siehe da. Die User, bei denen die Fehlermeldung erhielten wurden auf einen anderen CAS-Server geleitet als bei den Usern, wo es funktioniert hat.

Somit ging ich die Einstellungen durch, und fand im IIS des betreffenden CAS-Servers (Exchange 2010) unter

Default Web Site - Microsoft-Server-ActiveSync-Proxy - HTTP-Umleitung den Haken "Anforderungen zu diesen Ziel umleiten"

Nachdem ich dem Haken entfernt habe und die IIS neugestartet habe, konnten sich nun alle User anmelden und die Migration auf Exchange 2016 kann nun weiter gehen.

Öffentliche Ordner 2010 im Postfach Exchange 2016 kein Zugriff

Wie viele anderen es aktuell auch machen, sind wir bei der Migration von Exchange 2010 auf Exchange 2016.
Und natürlich brauchen wir auch die Öffentlichen Ordner.
Sobald das Postfach von Exchange 2010 auf Exchange 2016 migriert wurde, sieht man im Outlook die Öffentlichen Ordner nicht mehr.

Dafür einfach eine neue Datenbank für die ProxyMailbox anlegen. Am einfachsten geht es mit dem Powershellbefehl auf dem Exchange 2010

New-MailboxDatabase -Server <Servername vom Exchange 2010> -Name <Name der neuen Datenbank> -IsExcludedFromProvisioning $true

Nun die Proxymailbox anlegen. Dafür diesen Befehl auf dem Exchange 2010 ausführen.

New-Mailbox -Name <Name des Proxy-Postfaches> -Database <Name der neuen Datenbank> -UserPrincipalName <Name des Proxy-Postfaches>@domain.local

Als nächstes blenden wir das das neue Postfach aus der Adressliste aus.

Set-Mailbox -Identity <Name des Postfaches> -HiddenFromAddressListsEnabled $true

Zum Schluss verbinden wir uns mit unserem Exchange 2016 und starten dort die Exchange Powershell.
Mit folgenden Befehl schalten wir den Zugriff für diese Datenbank ein.

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes <Name des Proxy-Postfaches>

Nach kurzer Zeit erscheinen die Öffentlichen Ordner im Postfach des migrierten Benutzers.

Nun war es bei uns aber so, dass wir keinen Zugriff drauf bekommen haben, obwohl alle Berechtigungen richtig gesetzt waren.

Nach langem suchen im Internet fanden wir dann den Hinweis, dass die Postfachrolle und CAS-Rolle auf dem Exchange 2010 auf demselben Server laufen. Also auf dem CAS-Server haben wir die Postfachrolle installiert und die Datenbanken dort erneut erstellt.

Trotz nächtlichem Warten hatten wir immer noch keinen Zugriff.
Also weiter geforscht und zwei weitere Befehle gefunden, die auf dem Exchange 2016 eingegeben werden mussten.

Set-Mailbox <Name des migrierten Postfaches> -DefaultPublicFolderMailbox <Name des Proxy-Postfaches>

Und der zweite Befehl lautet:

Set-MailboxDatabase (Get-Mailbox <Name des migrierten Postfaches>).Database -PublicFolderDatabase (Get-MailboxDatabase (Get-Mailbox <Name des Proxy-Postfaches>).Database.PublicFolderDatabase

Nun noch die Dienste neustarten.

Restart-Service MSExchangeRPC

Und schon können Benutzer, die ihr Postfach auf dem Exchange 2016 haben auf die Öffentlichen Ordner von 2010 zugreifen.

Exchange 2010 - Arbeitsspeicher der store.exe begrenzen

Unser alter Mailserver sollte wenigstens noch so lange Arbeiten, bis der neue Mailserver erfolgreich getestet und alle Postfächer migiriert wurden.

Aber irgendwann wurde er so langsam, dass ein Arbeiten mit ihm nicht mehr möglich war. Selbst seine Wiedergabewarteschlange konnte er nicht mehr arbeiten.

Ursache war, dass die Store.exe den RAM blockiert hat.

Um das zu verhindern, haben wir einfach im ADSI-Editor eine Beschränkung gesetzt.

Dafür musst du einfach zu folgenden Punkt navigieren.
Dann natürlich deinen Mailserver auswählen (bei mir ist es MX01) und mit der rechten Maustaste auf Eigenschaften vom InformationStore gehen.

Nun in den Feldern ExchESEParamCacheSizeMin und ExchESEParamCacheSizeMax euren Wert eintragen.

Bei mir sind es 20GB. Berechnet wird es wie folgt:

20GB*1024*1024/32 = 655360

Durch 32 muss es geteilt werden, weil die Blockgröße vom Exchange ab 2010 32 ist.

Gruppenrichtlinien-Cache zurücksetzen

Wenn sich ein Computer nicht mehr mit den Domänencontrollern synchronisiert oder GPO-Fehler in den Ereignisprotokollen auftreten, dann kann es nützlich sein den Cache zu leeren.

Der Cache liegt auf dem Computer unter und kann gelöscht werden

"%ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History\*.*"

danach noch ein gpupdate /force

ausführen und schon ist alles wieder synchronisiert.

Das ganze geht natürlich auch mittels Script

DEL /S /F /Q "%ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History\*.*"
gpupdate /force

Kopie im Ordner "Gesendete Objekte"

Sobald man als Benutzer die Berechtigungen hat, Mails im Auftrag von oder mit Senden als zu verschicken, dauert es nicht lang bis der Wunsch auf kommt, dass man diese gesendeten Mails zusätzlich im Ordner "Gesendete Objekte" des Urspungspostfachs haben möchte und nicht nur in seinem eigenen.

Auch das geht wunderbar mit der Powershell.

Wenn der Benutzer Senden als Berechtigungen hat.

Set-MailboxSendItemsConfiguration BenutzerB -SendAsItemsCopiedTo SenderAndFrom

Und für Im Auftrag von Senden

Set-MailboxSendItemsConfiguration BenutzerB -SendOnBehalfItemsCopiedTo SenderAndFrom

Ab Exchange 2013 CU9 sieht der Befehl etwas anders aus

Get-Mailbox SharedMailboxAlias | Set-Mailbox -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true

 Will man nun überprüfen, ob alles richtig eingestellt ist, geht das einfach mit

Get-MailboxSentItemsConfiguration BenutzerB

Senden Als und Senden im Auftrag von

Seit Exchange 2010 ist es sehr einfach Benutzern das Recht zu geben Mails für ein anderes Postfach zu senden.
Es gibt einmal die Option "Senden als", wo die Mails so aussehen, als ob sie direkt vom Absender kommen und es gibt die Option "Senden im Auftrag von", wo klar erkennbar ist, dass Sender A im Auftrag von Sender B die Mail gesendet hat.

Über die Powershell geht es sehr schnell. Dafür einfach folgendes ausführen.

Für senden als

Add-ADPermission BenutzerB -User BenutzerA -Extendedrights "Send As“

Für Senden im Auftrag von

Set-Mailbox BenutzerB -GrantSendonBehalfTo BenutzerA

Für Verteilergruppen geht es natürlich genauso. Die Befehle dafür lauten

für senden als

Add-AdPermission "MeinVerteiler" –ExtendedRights "Send As" -User BenutzerA

Für Senden im Auftrag von

Set-DistributionGroup MeinVerteiler -GrantSendonBehalfTo BenutzerA

Exchange 2010 - Fehlermeldung ProxyWebRequest - ID 4002 MSExchange Availability

Ich habe auf einem Mailserver immer mal wieder im Eventlog die Fehlermeldung 4002 gesehen.

Prozess '4448': Fehler bei 'ProxyWebRequest CrossSite from S-1-1-0 to https://CAS-SERVER:443/ews/exchange.asmx'. Anrufer-SIDs: NetworkCredentials. Die zurückgegebene Ausnahme ist 'Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Net.WebException: Die Anfrage wurde abgebrochen: Die Anfrage wurde abgebrochen..
   bei System.Web.Services.Protocols.WebClientAsyncResult.WaitForResponse()
   bei System.Web.Services.Protocols.WebClientProtocol.EndSend(IAsyncResult asyncResult, Object& internalAsyncState, Stream& responseStream)
   bei System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
   bei Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)
   bei Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)
   bei 
   --- Ende der internen Ausnahmestapelüberwachung ---
. Name of the server where exception originated: MAILSERVER'. Stellen Sie sicher, dass der Active Directory-Standort/die Active Directory-Gesamtstruktur mit dem Benutzerpostfach mindestens einen lokalen Exchange 2010-Server aufweist, der den Verfügbarkeitsdienst ausführt. Aktivieren Sie die Protokollierung für den Verfügbarkeitsdienst, und prüfen Sie die grundlegende Netzwerkkonnektivität. 

Die Ursache ist ein Berechtigungsproblem, das man mit Powershell schnell lösen kann.

Get-ClientAccessServer | Add-ADPermission -AccessRights ExtendedRight -ExtendedRights "ms-Exch-EPI-Token-Serialization" -User "MyDomain.com\Exchange Servers"

Exchange Datenbankverteilung der Clientzugriffsserver

Einige Benutzer klagen über Verbindungsabbrüche von Outlook.

Mit einer Abfrage von

Get-MailboxDatabase | 
Select Name, RpcClientAccessServer, Server | 
Sort RpcClientAccessServer


sah ich, dass fast alle Datenbank auf einem CAS lagen.
Da wir kein CAS-Array im Einsatz haben, habe ich die Datenbankenzuordnung manuell mit

set-MailboxDatabase -id Datenbankname -RpcClientAccessServer 'CAS-Servername'

verschoben.

Und siehe da, keine Verbindungsabbrüche mehr.

Welches Postfach ist mit Automapping beim User eingebunden

Wir hatten immer die Probleme, dass einige Admins die Postfächer mit Automapping konfiguriert hatten. Sobald aber die zusätzlichen Postfächer größer und größer wurden um so schlimmer wurden die Probleme mit Outlook.
Und da nun kein Mensch der Welt bei 3000 Usern in jedes Outlook gucken wollte, habe ich ein kleines Powershell-Script geschrieben, dass und die Informationen zeigt, welches Postfach mit welchem Outlook per Automapping verbunden ist. Die Ergebnisse werden in einer CSV abgelegt.

Get-ADUser -Filter * -Properties msexchdelegatelistlink |
where {$_.msexchdelegatelistlink -ne ""} |
Select-Object name,{$_.msexchdelegatelistlink} |
export-csv c:\temp\AutoMapping.csv

MSExchange Web Services Event ID 5,6,7

Mein Eventlog auf dem Cas-Server war voll mit folgender Fehlermeldung

Nach 5 erfolglosen Versuchen, eine Benachrichtigung für Abonnement [GQBrYmJ2bS1rYmJjYXMwMS5rYmIuaW50ZXJuEAAAAC/hS9ooXFpLgVRDzl0kBVzpzB/pPH3WCA==] an Endpunkt [https://push-ews.aqua-mail.com/ews/v2/6dcf07ba47be847e58363766766da458a591403b/00000033/f773a4742cedebb26993c6b8418bc1a050d1406a/7f6606000536a0cda7f0502b14f48cf4c313615e] zu senden, wurde das Abonnement entfernt. Details: WebException: Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden.. Status: SendFailure    bei System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   bei Microsoft.Exchange.Services.Core.NotificationServiceClient.HandleResponse(IAsyncResult responseAsyncResult)





Die Lösung des Problem ist ganz einfach.

Den IIS-Manager starten und zu EWS navigieren.

Dort dann bei Authentifizierung, die Windows-Authentifizierung aktivieren.

Active Directory Felder abgleichen

Bei uns wurden die AD-Felder nicht richtig gepflegt und so kam es vor, dass mal der Jobtitel in der Beschreibung zu finden war und mal bei der Position.
Wir einigten uns darauf, dass nun nur noch das Feld "Beschreibung" richtig ist und somit mussten alle Informationen von Beschreibung in Position überführt werden.

Das gibt einfach mit einem Powershell-Script.

get-aduser -filter * -properties * | select-object samaccountname,GivenName,sn,title,description| export-csv C:\temp\export-user-all.csv -notypeinformation -delimiter ";" -encoding utf8;


Damit habe ich mir erstmal die aktuellen Einstellungen gesichert, falls es zu Problemen kommen sollte.
Und nun wird das Feld Position einfach mit den Werten aus Beschreibung überschrieben.

$Users = Import-Csv C:\temp\export-user-all.csv -Delimiter ';'

ForEach ($User in $Users){
Set-AdUser -Identity $User.sn -title $User.Description
}


Ordnerberechtigungen auslesen

Natürlich kann man auch mit Powershell sich Ordnerberechtigungen anzeigen lassen.

Das geht mit einer simplen Zeile


(get-acl 'ORDERPFAD').Access | Select-Object -ExpandProperty IdentityReference



Exchange Automapping deaktivieren/aktivieren

Manchmal kommt es vor, dass man das Automapping von Postfächern nicht haben möchte.

Um das zu deaktivieren muss man einfach folgenden Befehl im Powershell ausführen. Zugleich bekommt der Admin Vollzugriff.

Add-PSSnapin -Name Microsoft.Exchange.Management.PowerShell.E2010
Get-Module ActiveDirectory

Add-MailboxPermission -Identity USERNAME -User Administrator -AccessRights Fullaccess -AutoMapping:$false

Um nun wieder wieder Automapping zu aktivieren einfach das $false gegen ein $true austauschen

Add-PSSnapin -Name Microsoft.Exchange.Management.PowerShell.E2010
Get-Module ActiveDirectory

Add-MailboxPermission -Identity USERNAME -User Administrator -AccessRights Fullaccess -AutoMapping:$true