Categories
Exchange Server Windows

Mail-enabled Public Folder doesn’t receive external Mails

Since SP1 for Exchange 2013 it could be possible, that just mail-enabling a Public Folder isn’t enough to make this Folder receiving external Mails. This is caused by a missing permission for external Senders (which appear as “Anonymous”) to “create” items in this specific folder.

If you track an external message, you may receive the following error:

RecipientStatus: {[{LRT=};{LED=550 5.7.1 RESOLVER.RST.AuthRequired; authentication required [Stage: CreateMessage]};{FQDN=};{IP=}]}

To resolve this issue, you have to drop the following command within the Exchange Management Shell:

Add-PublicFolderClientPermission –identity “\Folder\Subfolder” –User Anonymous –AccessRights CreateItems

This should resolve your problem.

Categories
Exchange Server Windows

Script: Grant “SendAs”-Permission for all Groupmembers in a Distribution Group

 

This Script will go through all Distribution Groups and grants SendAs-Permissions for all Groupmembers by using the Group itself instead of each User:

Grant-SendAs-To-Group

Categories
Certificates Exchange Server Windows

Exchange 2007-2013: Umstellen der internen URLs auf die externen Namen

Um den vollen Funktionsumfang aller Exchange-Dienste ausnutzen zu können, müssen alle Namen, sowohl intern als auch extern, mit einem oder mehreren Zertifikaten abgedeckt werden. Nun hat man zwei Möglichkeiten, das ganze zu bewerkstelligen:

  1. Verwendung von zwei unterschiedlichen Zertifikaten: Eins ausgestellt von der internen CA zur Abdeckung aller internen URLs und eins ausgestellt von einem Zertifikatsanbieter Ihrer Wahl zur Abdeckung der externen URLs.
  2. Umstellung der internen URLs auf die externen, um anschließend im internen DNS die öffentlichen URLs zusätzlich zu pflegen, allerdings unter Verwendung von internen IPs. Hier wird dann nur ein Zertifikat benötigt.

Die bisherige dritte Möglichkeit, nämlich sowohl lokale als auch öffentliche URLs in ein Zertifikat zu packen, wird ab dem 1. November 2015 nicht mehr unterstützt. Für mehr Informationen hierzu klicken Sie bitte auf folgenden Link: https://www.icann.org/en/system/files/files/sac-057-en.pdf

Die zweite Möglichkeit werden wir nun durchführen. Hierfür müssen wir allerdings einige Befehle in der Exchange Management Shell absetzen. Diese lauten wie folgt:

Set-ClientAccessServer -Identity <HostName> -AutodiscoverServiceInternalUri https://mail.example.de/autodiscover/autodiscover.xml

Set-WebServicesVirtualDirectory -Identity "<HostName>\EWS (Default Web Site)" -InternalUrl https://mail.example.de/ews/exchange.asmx

Set-OABVirtualDirectory -Identity "<HostName>\oab (Default Web Site)" -InternalUrl https://mail.example.de/oab

Set-ActiveSyncVirtualDirectory -Identity "<HostName>\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https://mail.example.de/Microsoft-Server-ActiveSync

Set-OWAVirtualDirectory -Identity "<HostName>\owa (Default Web Site)" -InternalUrl https://mail.example.de/owa

Set-ECPVirtualDirectory -Identity "<HostName>\ecp (Default Web Site)" -InternalUrl https://mail.example.de/ecp

Optional (kann zuvor über Get-OutlookAnywhere getestet werden):

Set-OutlookAnywhere -Identity "<HostName>\Rpc (Default Web Site)" -InternalHostname  -InternalClientsRequireSsl $true

Im Anschluss daran muss man den IIS Application Pool recyclen, damit die Änderungen wirksam werden. Hierfür muss der IIS Manager geöffnet werden. Darin angekommen, klicken wir unter Application Pools auf den MSExchangeAutodiscoverAppPool und anschließend auf Recycle. Sobald dies erledigt ist, sind die Einstellungen übernommen und die Clients ziehen sich bei der nächsten Autodiscover-Abfrage die neuen URLs.

Categories
Exchange

SMTP Tarpitting – Sinn und Unsinn

Was ist das?

SMTP Tarpitting ist ein pro Empfangskonnektor setzbarer Parameter. Dieser sorgt dafür, dass beim Versand über den jeweiligen Konnektor an eine dem Exchange nicht unmittelbar bekannte Adresse (sprich extern oder nicht vergebene Aliase) eine definierte Verzögerung eintritt.

Macht das Sinn?

Ja und nein. Es macht Sinn für meistens genau einen Konnektor, nämlich den, der Mails von extern empfängt. Wenn man nun versucht, den Exchange-Server mit Spam zu überschütten, wird die ein oder andere falsche Adresse dabei sein, was immer zu einer Verzögerung führt. Vielen Spammern wird das dann letztendlich zu blöd, da sie diese Zeit sinnvoller nützen können.
Keinen Sinn macht es jedoch für interne Relays, die meist zügig die Mails nach außen schieben sollen. Hier wird so manche externe Adresse dabei sein, die diese Verzögerung bewirkt. Viele einfach programmierte SMTP-Konnektoren werden bis die Response kommt sogar komplett freezen. Daher macht dies intern wirklich keinerlei Sinn.

Konfigurieren der Konnektoren

Standardmäßig sind 5sek. pro Konnektor gesetzt. Um beim erstgenannten Empfangskonnektor für Mails aus dem www die Zeit sogar noch zu erhöhen, kann folgender Befehl ausgeführt werden: 

Set-ReceiveConnector “FromInternet” -tarpitinterval 00:00:10

Um z.B. für interne Relays die Tarpitting komlett abzuschalten, ist stattdessen dieser Befehl hier nötig: 
Set-ReceiveConnector “Internal” -tarpitinterval 00:00:00

Categories
Exchange

PST-Export auf dem Exchange-Server (ab 2010)

Um ein PST-File von einem Postfach direkt auf dem Exchange-Server zu exportieren, muss folgendes getan werden:

Als erstes müssen wir uns an einem ClientAccess-Server anmelden. Der User mit dem wir uns dort anmelden, benötigt dann noch Rechte für den Export. Das ganze funktioniert über eine Rollenzuweisung. Dies ist absolut notwendig, auch als Administrator hat man diese Rolle normalerweise nicht. Jedoch ist der Schritt nur einmal pro User notwendig, da die Rollenzuweisungen permanent sind.

Hier die Rollenzuweisung:  

New-ManagementRoleAssignment –Role "Mailbox Import Export" –User domainuser

Anschließend muss man die Exchange-Shell nochmal schließen und neu öffnen. Dieser Schritt ist nötig, da die Shell beim Start die erlaubten Befehle bekommt. Starten wir Sie nicht neu, so weiß sie nicht, dass nun neue Befehle möglich sind.

Nach dem Neustart kann der Befehl mit den notwendigen Anpassungen abgesetzt werden: 

New-MailboxExportRequest -Mailbox user@domain.tld –FilePath "localhostc$pstusername.pst"

Damit ist der Request abgesetzt. Wann dieser bearbeitet wird, entscheidet ganz alleine der Exchange-Server durch Abwägung verschiedener Einflüsse wie Auslastung usw.

Der aktuelle Status lässt sich abrufen, in dem folgender Befehl abgesendet wird:

Get-MailboxExportRequest

Sobald der Request dann igendwann abgeschlossen ist, kann man ihn wieder löschen über folgenden Befehl:

Get-MailboxExportRequest | Remove-MailboxExportRequest

Hierbei muss nur beachtet werden, dass mit diesem Befehl alle Requests beendet werden. Also nur abfeuern, wenn auch alle Requests durch sind. Das wars auch schon.

Categories
Exchange

Verwaiste und alte Exchange 2000/2003-Einträge manuell aus dem Active Directory entfernen

Letzte Woche wurde bei einem Kunden von uns lokal ein neuer Exchange-Server parallel zu einer 2007er Installation hochgezogen, um anschließend die Postfächer zu migrieren.

Beim Check, welcher vor der Installation durchgeführt wird, bemängelte das Setup noch vorhandene Exchange 2000/2003-Einträge im AD. Diese(n) Server gibt es allerdings schon seit geraumer Zeit nicht mehr. Somit mussten wir die Einträge manuell entfernen – Zeit für den ADSI-Editor.

Wir verbinden uns also per ADSI Edit auf die betroffene Domain. Als “bekannten Namenskontext” wählen wir Konfiguration aus. Dann bitte folgenden Pfad befolgen:

  • Konfiguration [Domain.local]
    • CN=Configuration,DC=Domain,DC=local
      • CN=Services
        • CN=Microsoft Exchange
          • CN=[Organisationsname]
            • CN=Administrative Groups
              • CN=Erste administrative Gruppe
                • CN=Servers

Unter diesem Container finden wir nun alle verwaisten Servereinträge. Aus diesem Grund kann man alle Container innerhalb des CN=Servers entfernen. Auf keinen Fall aber irgendetwas anderes. Durch das Löschen dieser Server sollte die Meldung weggehen.

Categories
Exchange

Exchange 2013 komplett von Hand aus der Domäne entfernen

Wenn man einen Exchange-Server komplett aus der Domäne entfernen möchte, sollte als erstes immer die Deinstallation über die Systemsteuerung versucht werden. Sollte dies fehlschlagen, so kann folgende Anleitung befolgt werden:

+++ NUR FÜR EINZELSERVERINSTALLATIONEN +++

  1. Öffnen Sie auf einem Domain Controller das Tool “ADSI Edit”
  2. Wählen Sie als erstes “Konfiguration” um dann zu folgendem Pfad zu navigieren:
    CN=Configuration > CN=Services
    Löschen Sie folgende Ordner:
    CN=Microsoft Exchange & CN=Microsoft Exchange Autodiscover
  3. Erstellen Sie eine neue Verbindung und wählen dieses Mal “Default Naming Context”. Dort bitte folgende Ordner löschen:
    CN=Microsoft Exchange Security Groups & CN=Microsoft Exchange Security Objects
  4. Jetzt kann man das normale AD öffnen und in der OU “Users” folgende User noch löschen:
    – DiscoverySearch Mailbox{GUID}
    – Exchange Online-ApplicationAccount
    – FederatedEmail.GUID
    – Migration.GUID
    – SystemMailbox{GUID}
    – HealthMailboxGUID

Wenn der Server anschließend neu aufgesetzt wird, so wäre hiermit die Deinstallation abgeschlossen. Soll auf das bestehende Betriebssystem weiterverwendet werden, so wäre folgendes noch zu tun:

  1. Über den Explorer folgenden Pfad löschen: C:\Programme\Microsoft\Exchange Server
  2. Im IIS sämtliche Exchange-Sites entfernen
  3. In der Registry folgende Keys entfernen:
    – ExchangeServer unter HK_L_M\Software\Microsoft
    – MSExchange[…] unter HK_L_M\CurrentControlSet\Services

Hiermit sollte alles endgültig abgeschlossen sein.

Categories
Exchange

Event ID 1677 – Unified Messaging kann nicht für einen Benutzer aktiviert werden

Wenn sich ein bestimmter User nicht für Unified Messaging aktivieren lässt und Sie folgende Fehlermeldung bekommen, dann haben wir hier die Lösung:

Error occurred during execution of UM Mailbox Cmdlet for user “/o=XXX/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=929fc9a62f634c198ea7f630a2593615-XXX”, Error: “Microsoft.Exchange.UM.UMCommon.UmUserException: Access to Active Directory failed.
at Microsoft.Exchange.UM.UMCommon.UmPasswordManager.CommitPasswordAndUpdateChecksum()
at Microsoft.Exchange.UM.UMCommon.UmPasswordManager.SetPassword(EncryptedBuffer digits, Boolean isExpired, LockOutResetMode lockoutResetMode)
at Microsoft.Exchange.UM.UMCommon.Utils.SetUserPassword(MailboxSession mbxSession, UMMailboxPolicy umMbxPolicy, ADUser adUser, String pin, Boolean expired, Boolean lockedOut)
at Microsoft.Exchange.UM.UMCommon.CrossServerMailboxAccess.XSOUMUserMailboxAccessor.<>c__DisplayClassa.<SaveUMPin>b__9()
at Microsoft.Exchange.UM.UMCommon.CrossServerMailboxAccess.XSOUMUserMailboxAccessor.ExecuteXSOOperation(Action function)”

Ursache: Diese typisch nichtssagende Meldung bekommen wir dann, wenn das Postfach aus irgendeinem Grund nicht in den (in der Address Book Policy festgelegten) Adresslisten eingetragen ist.

Behebung: Im ersten Schritt sollte man sich die Address Book Policy anschauen und feststellen, in welche Adresslisten das Postfach gehören sollte. Anschließend schauen wir uns das Postfach an und überprüfen, in welchen Listen es auch eingetragen ist. Im dritten Schritt überprüfen wir die Aufnahmeregeln der Listen, in denen das Postfach nicht ist aber sein sollte und führen dementsprechende Anpassungen durch.

Categories
Exchange

Exchange Postfach – Nachträgliche Rechtevergabe auf Ordner (und deren Unterordner)

Ein Szenario, welches viele wohl so oder so ähnlich schon kennen: Sie haben ein Exchange Postfach vor sich, höchst ordentlich verschachtelt und organisiert mit zwei- oder gar dreistelligen Zahlen von Ordnern und Unterordnern.
Und nun plötzlich benötigt der Kollege am anderen Schreibtisch Zugriff auf einen dieser Ordner. An für sich nicht schwer denken Sie sich eventuell nun, einfach dem Benutzer Rechte vergeben auf den Ordner und die Sache ist erledigt.
Soweit richtig, doch wie sieht das ganze bei diversen Unterordnern aus? Um es kurz zu machen, äußerst bescheiden. Sie müssten für jeden Unterordner explizit nochmal die Rechte vergeben, eine Vererbung wird nicht auf bereits bestehende Ordner angewendet.

Doch wir schaffen Abhilfe! Führen Sie Add-Inheritet-Rights.ps1 auf Ihrem Exchange-Server aus, und Sie können bequem vererbte Rechte vergeben. Für technisch interessierte oder vorsichtige Leute auch hier nochmal das Script im Klartext:

<#
.SYNOPSIS
    Mit Hilfe dieses Scripts können im Nachhinein Rechte auf bestimmte Ordner UND Unterordner in Outlook vergeben werden.
.PARAMETER AffectedMailbox
    Hier das Postfach bestimmen, aus welchem Ordnerrechte geändert werden sollen. Format: (user@domain.de) 
.PARAMETER UserWhoGetsRights
    Benutzer/Mailbox definieren, die nun Rechte bekommt auf das bestimmte Postfach. Format: (user@domain.de)
.PARAMETER PathOfTheFolder
    Pfad des bestimmten Ordners (Format: /Posteingang/Ordner/Unterordner)
.EXAMPLES
    ohne Parameter: ".\Add-Inheritet-Rights.ps1"
    mit  Parameter: ".\Add-Inheritet-Rights.ps1 -AffectedMailbox="a@b.com" -UserWhoGetsRights="d@e.com" -PathOfTheFolfer="/Inbox"
#>

Param
(
    [string]$AffectedMailbox,
    [string]$UserWhoGetsRights,
    [string]$PathOfTheFolder
)


Write-Host "Exchange Snapin Loading...."
Add-PSSnapin Microsoft.Exchange.Management.Powershell.Snapin
Write-Host "Exchange Snapin Loaded."
Write-Host ""
Write-Host "=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-"
Write-Host "Script für Vererbbare Rechte - (c) by cloud4you.biz  -=-=-=-=-=-=-=-=-=-=-=-"
Write-Host "=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-"
Write-Host ""
If ($AffectedMailbox -eq "")
{
    $AffectedMailbox = Read-Host "Auf welchem Postfach werden neue Rechte hinzugefügt? (Format: user@domain.de)"
}
Write-Host ""
$GetMailbox = Get-Mailbox $AffectedMailbox
Write-Host "Zutreffende Postfächer:" $GetMailbox.Length
Write-Host ""
If ($GetMailbox.Length -eq 1)
{
    If ($UserWhoGetsRights-eq "")
    {
        $UserWhoGetsRights = Read-Host "Welcher Benutzer bekommt in dem Postfach Rechte? (Format: user@domain.de)"
    }
	Write-Host ""
	$GetMailbox = Get-Mailbox $UserWhoGetsRights
	Write-Host "Zutreffende Postfächer:" $GetMailbox.Length
	Write-Host ""
	If ($GetMailbox.Length -eq 1)
	{
		If ($PathOfTheFolder -eq "")
        {
            $PathOfTheFolder = Read-Host "Und nun benötige ich den Pfad (Format: /Posteingang/Ordner/Unterordner)"
        }
		$GetFolders = Get-MailboxFolderStatistics -identity $AffectedMailbox | WHERE {$_.FolderPath.Contains($PathOfTheFolder) -eq $true}
		If ($GetFolders.Length -gt 0)
		{
			ForEach($folder in (Get-MailboxFolderStatistics -identity $AffectedMailbox | WHERE {$_.FolderPath.Contains($PathOfTheFolder) -eq $true} ) )
			{
				$foldername = $AffectedMailbox + “:” + $folder.FolderPath.Replace(“/”,”\”);
				Add-MailboxFolderPermission $foldername -User $UserWhoGetsRights -AccessRights PublishingEditor
			}
			Write-Host ""
			Write-Host $GetFolders.Length "Ordner wurden bearbeitet"
		}
		Else
		{
			Write-Host ""
			Write-Host "Es wurden keine Ordner unter diesem Pfad gefunden."
		}
	}
	Else
	{
		Write-Host ""
		Write-Host "Der Benutzer wurde nicht gefunden oder war nicht eindeutig."
	}
}
Else
{
	Write-Host ""
	Write-Host "Das Postfach wurde nicht gefunden oder war nicht eindeutig."
}
Write-Host ""
$Unnoetig = Read-Host "Drück Eingabe"