Categories
Exchange Office Tipps & Tricks

Outlook-Suche im Exchange-Postfach für ältere Elemente schlägt fehl

Hat man den Cache-Modus in Outlook für ein Exchange-Postfach auf einen bestimmten Zeitraum begrenzt, muss die Suche für frühere Ergebnisse auf dem Server fortgesetzt werden. Dazu wird man meist in der untersten Zeile der Suchergebnisse dann aufgefordert. Fälschlicherweise kann es dann hier zu der Meldung kommen, dass der Server offline oder nicht erreichbar ist.

Server unavailable. 12 months of results shown.

Fehlermeldung auf Englisch

Ob der Server tatsächlich ein Problem hat, können Sie bei Exchange-Postfächern sehr einfach über die “Outlook Web App” prüfen. Wenn hier die Suche erfolgt, hat der Server normalerweise keine Probleme. Kommt es auch hier zu Fehlern, genügt es in den meisten Fällen, den Datenbank-Index neu aufzubauen. Das wollen wir aber in dem Fall nicht behandeln, wir gehen also davon aus, dass die Suche in OWA funktioniert.

Die Lösung, um die augenscheinliche Falschmeldung in Outlook zu beheben, ist mehr als seltsam. Bitte befolgen Sie folgende Schritte:

  • Klicken Sie per Rechtsklick links in der Ordnerübersicht auf Ihre Email-Adresse (also in der obersten Ebene)
  • Klicken Sie auf “Datendateieigenschaften….”
  • Klicken Sie auf “Ordnergröße…”
  • Wechseln Sie auf den Reiter “Serverdaten”. Hier müsste der Aufbau ein paar Sekunden benötigen.
  • Das war’s, sie können die Fenster wieder in umgekehrter Reihenfolge schließen.

Versuchen Sie im Anschluss die Suche erneut. Nun sollte die Schaltfläche wieder verfügbar sein, die es Ihnen ermöglicht, ältere Ergebnisse auf dem Server zu suchen.

Hat es Ihnen geholfen? Wir freuen uns auf Ihr Feedback!

Exchange-Postfächer in jeder Edition und Größe können Sie übrigens bei uns ganz unkompliziert buchen, schauen Sie mal vorbei unter: https://cloud4you.biz/cloud/kommunikation/hosted-exchange

Categories
Exchange

Migration der X500- / Legacy-Adressen

Viele Personen kennen diese Adressen gar nicht mehr, dabei basieren Termine und auch die gute alte Autovervollständigen-Funktion bei Eingabe einer Adresse in An:/Cc:/Bcc: noch immer auf diesen Adressen. In Folge dessen kommt es nach einer Migration oft zu Problemen bspw. beim reorganisieren von Terminen, so dass Teilnehmer nicht mehr benachrichtigt werden. Um dem entgegenzuwirken, kann man diese Adressen migrieren. Wie das geht, zeigen wir hier.

Export vom alten Domain Controller

Zunächst erstellen wir in der alten Umgebung mit Hilfe von PowerShell einen CSV-Export, der die Legacy-Adressen enthält.

Get-ADUser -SearchBase "OU=MyOffice,DC=domain,DC=int" -Filter * -Properties legacyExchangeDN  | Export-CSV C:\x500adresses.csv -NoTypeInformation

Import auf dem Ziel-Exchangeserver

Die CSV-Datei muss nun möglicherweise zu einem Server/PC kopiert werden, der auf die Exchange-Shell Zugriff hat. Dort angekommen importieren wir die Datei wieder und führen dann folgendes aus:

$Asdf = Import-CSV "C:\x500adresses.csv"
foreach ($User in $Asdf){ if ($User.legacyExchangeDN){ Get-Mailbox -Identity $User.UserPrincipalName | Set-Mailbox -EmailAddresses @{add="X500:$($User.legacyExchangeDN)"} } }

Ob die Migration erfolgreich war, kann über folgenden Befehl geprüft werden:

Get-Mailbox -ResultSize Unlimited |Select-Object DisplayName,ServerName,PrimarySmtpAddress, @{Name="EmailAddresses";Expression={$_.EmailAddresses | ForEach-Object {$_}}}
Categories
Exchange Server Windows

Terminüberschneidungen in Ressourcen-Postfächern

Ressourcen-Postfächer kann man so konfigurieren, dass Sie Termine automatisch annehmen. Geschieht die Konfiguration über das ECP oder über den simplen

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept

-Befehl, so klappt die automatische Annahme solange, bis ein Terminkonflikt entsteht. In einer Terminserie ist das dann besonders ärgerlich, da alle Serienelemente abgelehnt werden, sobald sich ein Element mit einem vorhanden Termin überschneidet. Dies kann man umgehen, in dem man weitere Parameter anpasst. Grundsätzlich zu klären wäre dabei folgende Frage: Sind Überschneidungen erlaubt?

Wenn Überschneidungen erlaubt sind, kann man die Einstellungen wie folgt überschreiben:

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept -AllowConflicts $true

Damit werden die Termine einfach parallel zu eventuell bereits bestehenden Terminen eingetragen. Das macht dann Sinn, wenn ein Raum beispielsweise doppelt belegbar ist.

Wenn man Überschneidungen vermeiden will und stattdessen wünscht, dass sich überschneidende Termine einfach abgelehnt werden ohne die ganze Serie abzulehnen, so ist folgender Befehl zu verwenden:

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept -AllowConflicts $false -ConflictPercentageAllowed 50 -MaximumConflictInstances 15

Der Parameter –ConflictPercentageAllowed gibt hierbei an, welcher Anteil an Serienelementen auf Grund von Überschneidungen abgelehnt werden darf (in Prozent, aber anzugeben ohne ‘%’-Zeichen), während -MaximumConflictInstances angibt, wie viele Serienelemente wegen Überschneidungen abgelehnt werden dürfen. Beide Werte kann man dabei natürlich utopisch hochsetzen um zu garantieren, dass jede Serie angenommen wird. Dennoch sind sicher an der ein oder anderen Stelle sinnvoll gewählte Grenzwerte nützlich.

Achtung: Solange -AllowConflicts auf $true steht, haben die für –ConflictPercentageAllowed und -MaximumConflictInstances gesetzten Werte keinen Einfluss, sie werden ignoriert.

Categories
Exchange Server Windows

Exchange-Server schließt IMAP- oder POP3-Verbindungen sofort wieder (Aktualisiert)

Szenario:
IMAP- oder POP3-Verbindungen mittels Email-Clients funktionieren einfach nicht mehr, die Verbindungen werden vom Server sofort wieder geschlossen. Bei der weiteren Recherche stellt sich raus, das man mittels Telnet auf dem Exchange-Server selbst unter Verwendung von 127.0.0.1 die Dienste noch abfragen kann. Führt man jedoch Telnet von einer anderen Maschine remote aus, so wird die Verbindung sofort wieder getrennt. Die jeweiligen Dienste sind jedoch auf dem Server aktiv.

Problem:
Wenn oben beschriebenes teilweise oder gar komplett auf Sie zutrifft, liegt es vermutlich daran, dass die Proxy-Komponente des jeweiligen Dienstes inaktiv ist. Prüfen können Sie das, indem Sie eine PowerShell-Eingabeaufforderung starten, und folgende Zeile eingeben:

Get-ServerComponentState -Identity [Servername]

Folgendes könnten Sie als Ausgabe zurückbekommen:

Server Component State
-------
[...]
[Servername] ImapProxy Inactive
[...]
[Servername] PopProxy Active
[...]

Die Ausgabe ist selbstverständlich nicht eingefärbt, dies dient nur der Veranschaulichung.

Behebung:
Sollte nun eine oder gar mehrere Komponenten als Inactive angezeigt werden, müssen wir selbige wieder aktivieren. Dies erfolgt durch folgenden PowerShell-Befehl:

Set-ServerComponentState -Identity [Servername] -Component [Komponente] -Requester HealthAPI -State Active

In unserem Beispiel würde der Befehl wie folgt aussehen:

Set-ServerComponentState -Identity SRV-EXCHANGE -Component ImapProxy -Requester HealthAPI -State Active

Damit sollten die Verbindungen wieder möglich sein. Eventuell müssen die jeweiligen Dienste noch neugestartet werden.

Ursache:
Auch nach weiterer Recherche konnte nicht herausgefunden werden, was den Server dazu trieb, die Komponente auf inaktiv zu setzen. Zwar sieht man im Eventlog, dass er es tat, aber keinen tieferen Grund. Sollte sich hier noch etwas ergeben, werde ich den Blogeintrag entsprechend erweitern.

Nachtrag:
Scheinbar führt irgendein Softwarefehler beim Exchange Server 2013 regelmäßig zum Absturz solcher Komponenten. Aus diesem Grund wurde ein Script angefertigt, das dieses Problem automatisiert behebt, falls es existent sein sollte. Dieses ist auch TaskScheduler-kompatibel, kann hier also ganz einfach eingesetzt und alle 5 Minuten gestartet werden:

#Ausführung des Remoting-Scripts, der Pfad muss bei anderen Server-Versionen abgeändert werden
. "C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1" | Out-NULL
Connect-ExchangeServer -auto | Out-NULL

$LocalHost = $env:computername

Write-Host "Checking IMAP4: " -NoNewline
$ImapState = (Get-ServerComponentState -Identity $LocalHost -Component ImapProxy).State
if($ImapState -eq "Active")
{
   Write-Host "$ImapState" -ForegroundColor Green
}
else
{
   Write-Host "$ImapState" -ForegroundColor Red
   Write-Host "Enabling Component ImapProxy: " -NoNewline
   Set-ServerComponentState -Identity $LocalHost -Component ImapProxy -Requester HealthAPI -State Active
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting IMAP4 Backend Service: " -NoNewline
   Restart-Service "MSExchangeIMAP4BE"
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting IMAP4 Service: " -NoNewline
   Restart-Service "MSExchangeImap4"
   Write-Host "done." -ForegroundColor Green
}
Write-Host ""

Write-Host "Checking POP3: " -NoNewline
$PopState = (Get-ServerComponentState -Identity $LocalHost -Component PopProxy).State
if($PopState -eq "Active")
{
   Write-Host "$PopState" -ForegroundColor Green
}
else
{
   Write-Host "$PopState" -ForegroundColor Red
   Write-Host "Enabling Component PopProxy: " -NoNewline
   Set-ServerComponentState -Identity $LocalHost -Component PopProxy -Requester HealthAPI -State Active
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting POP3 Backend Service: " -NoNewline
   Restart-Service "MSExchangePOP3BE"
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting POP3 Service: " -NoNewline
   Restart-Service "MSExchangePop3"
   Write-Host "done." -ForegroundColor Green
}
Write-Host ""

Zur besseren Veranschaulichung der Ausgabe besitzt dieses Script einige Zeilen, die im Taskscheduler natürlich unnötig sind. Diese habe ich violett markiert.

Categories
Exchange Server Windows

Exchange antwortet mit “SMTP 5.7.1 Client does not have permissions to send as this sender” für eigene Adresse

Szenario:

Über ein beliebiges Tool wird versucht, per SMTP eine Mail unter Verwendung des Exchange-Servers als Relay zu versenden. Die Authentifizierung klappte tadellos und als Absenderadresse wird die Antwortadresse des Accounts verwendet, mit dem man sich zuvor angemeldet hat. Und doch sagt der Exchange-Server:

5.7.1 Client does not have permissions to send as this sender

Grund / Lösung:

Man muss obige Fehlermeldung nur in Google eingeben, um herauszufinden, dass es so einige Ansätze zur Problemlösung gibt. Bei uns war es jedoch ein sehr unüblicher Grund: Vor zwei Tagen hatte ich die Domain, die die Mailadresse des Benutzers hinter dem @ stehen hat, als “External Relay” definiert. Damals wollte ich sicherstellen, dass der Exchange immer versucht, die Mail über das Internet zu versenden, auch wenn das Empfängerpostfach lokal vorliegt. Das oben beschriebene Szenario ist hier jedoch ein unangenehmer Nebeneffekt. Verwendet man also den Exchange-Server als Relay für andere Programme, so sollte die sendende Domain immer als “Authorative” oder “Internal Relay” eingerichtet sein.

Categories
Exchange Server Windows

Mail-enabled Public Folder doesn’t receive internal Mails

If you mail-enable a public folder, it happens sometimes, that the folder still isn’t able to receive any mails. If just external mails aren’t received, you may review this thread. If internal mails are also affected the following instructions should do the trick.

If you track those mails on your exchange server, you may receive the following line:

RecipientStatus: {[{LRT=};{LED=550 5.7.1 RESOLVER.RST.NotAuthorized; not authorized [Stage: CreateMessage]};{FQDN=};{IP=}]}

This line says, that the sender was recognized by the exchange infrastructure. And this user has no right to “create items”, because that’s the thing that is basically happening if you send a mail to a public folder. To fix this, we allow all users to “create items” who do not own an explicit right set:

Add-PublicFolderClientPermission -identity "\Folder\Subfolder” –User Default -AccessRights CreateItems

Of course you are able to allow just single users by replacing “Default” with the regarding user. “Default” stands for all those users who were not set up previously.

Categories
Exchange Scripts

OneLiner: Determine the size of a public folder (and it’s subfolder)

We recently had the request to determine the size of a public folder. Not a problem at all, this should do the trick:

[PS] C:\Windows\system32>Get-PublicFolder "\[Foldername]" | Get-PublicFolderStatistics | Select TotalItemSize

… not really. All we get is the summarized size of the items included in this specific folder. Subfolders and items in subfolders will be ignored. But there is another way which will include subfolder sizes. Here you go:

[PS] C:\Windows\system32>Get-PublicFolder "\[Foldername]" -Recurse | Get-PublicFolderStatistics | Measure TotalItemSize -sum

Optically improved version:

[PS] C:\Windows\system32>Get-PublicFolder "\[Foldername]" -Recurse | Get-PublicFolderStatistics | Measure TotalItemSize -sum | Select @{N='Anzahl der Items'; E={$_.Count}}, @{N='Speicher in Byte'; E={$_.Sum}} | fl

Please be aware that this oneliner may takes some time to complete your request.

Categories
Exchange Server Windows

Wie starte ich einen Exchange-Server in einem DAG-Cluster neu?

Anders als es der Begriff ‘Cluster’ vielleicht vermuten lässt, müssen einige Vorbereitungen getroffen werden, um einen Exchange-Server in einer “Database Availability Group” – kurz DAG – sauber neuzustarten. Macht man das nicht, so kann es gut gehen, im schlimmsten Falle fliegt einem allerdings der Datenbank-Index um die Ohren und die Suche funktioniert nicht mehr. Das wäre der schlimmste mir bekannte Fehler.

Um das zu vermeiden, machen wir folgendes:

Mittels dieses PowerShell-Befehls:

Get-MailboxDatabaseCopyStatus *

lassen wir uns alle Postfach-Datenbanken auf jedem eingehängten Server in der DAG ausgeben. Nun schauen wir nach Datenbanken, welche auf dem neuzustartenden Server den Status “Mounted” beziehungsweise “Eingehängt” haben. Sind solche Datenbanken vorhanden, muss folgender Befehl ausgeführt werden:

Move-ActiveMailboxDatabase -Server [Neuzustartender Server]

Hiermit erreichen wir, das die Datenbanken nicht mehr auf diesem Server eingehängt sind, sondern ein beliebiger anderer Server in der DAG diesen Job übernimmt.

Nun kann der Neustart durchgeführt werden. Sobald dieser durch ist, kann man mit dem ersten Befehl prüfen, ob alle Datenbanken den “Healthy”-Status haben bzw. nach kurzer Zeit wieder annehmen. Wichtig ist, dass alle Datenbanken einen solchen Status haben, bevor eine Verschiebung stattfindet. Ist dies der Fall, könnte auch mit dem nächsten Neustart fortgefahren werden.

Es wird davon abgeraten, innerhalb eines Clusters mehr als einen Server gleichzeitig neuzustarten.

 

Categories
Exchange Server Windows

OneLiner: Get all Mail-Aliases of all Users / Groups in one OU

As we had this request currently, we’ve created the following OneLiners, which i’d like to share with you:

Get all Mailbox-Aliases:

Get-Mailbox -OrganizationalUnit "[DN of OU]" | Select -Expand EmailAddresses Alias | Select SmtpAddress, Alias

Get all DistributionGroup-Aliases:

get-distributiongroup -OrganizationalUnit "[DN of OU]" | Select -Expand EmailAddresses Alias | Select SmtpAddress, Alias
Categories
Exchange Server Windows

Exchange Public Folder – Subsequent Right Management (recursive)

Often you have to add rights for a new user long after the creation of a public folder. If there’s much Data in this folder and it’s subfolders, the usual method by using the Exchange Control Panel will often result in OutOfMemory-Exceptions. To prevent this behaviour, we could use the Exchange Scripts, which were placed on your server during the installation:

  1. At first we need a new Instance of the Exchange Management Shell (EMS) or a PowerShell Console with loaded Exchange Snapins (can be done by using the command “Add-PSSnapin Microsoft.Exchange.Management.Powershell.Snapin”).This needs to be done as the provided Scripts from Microsoft won’t import those Commands again.
  2. In the Shell we will now change our Working-Directory to the Path, were the Scripts are stored. This can be done by the following command:
    cd “C:\Program Files\Microsoft\Exchange Server\V15\Scripts”
    You may replace the Folder “V15” with the Versionnumber of your Exchange-Server.
  3. Now we will execute the following command:
    .\AddUsersToPFRecursive.ps1 -TopPublicFolder “\[folder-path]” -User “[UPN of the User]” -Permission “[Permission-Set]”
    Bsp.: .\AddUsersToPFRecursive.ps1 -TopPublicFolder “\technet” -User “randomguy@c4y.biz” -Permission “Owner”
  4. After a short delay the console will show you every folder as an output-line to confirm the modification of rights.

That’s it!