Kategorien
Zabbix

Zabbix 4.0 Proxy (PostgreSQL) unter Ubuntu 18.04 LTS installieren

In dieser Anleitung wird davon ausgegangen, dass Ubuntu 18.04 bereits auf der Maschine installiert wurde. Weiter setzt die Anleitung eine funktionierende Internetverbindung auf dem Proxy voraus.

Um keine Probleme mit Berechtigungen zu bekommen, stellen Sie bitte sicher, dass Sie nun als Admin unterwegs sind:

sudo su

Zunächst laden wir uns dann das aktuelle Repository-Konfigurationspaket herunter:

wget https://repo.zabbix.com/zabbix/4.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_4.0-2+bionic_all.deb
dpkg -i zabbix-release_4.0-2+bionic_all.deb

Dann aktualisieren wir Paketinformationen:

apt-get update

Jetzt können wir das Proxy-Paket herunterladen und installieren:

apt-get install zabbix-proxy-pgsql

Anschließend aktivieren und starten wir den Proxy:

systemctl enable zabbix-proxy
systemctl start zabbix-proxy

Nun erstellen wir den PostgreSQL-Benutzer, der vom Proxy verwendet wird, um auf die lokale Datenbank zuzugreifen. Sie werden nach Eingabe der Zeile wiederholt um die Eingabe des Kennworts für den User gebeten. „zabbix“ beschreibt den Benutzernamen, der natürlich variieren kann.

sudo -u postgres createuser --pwprompt zabbix

Im nächsten Schritt erstellen wir die Datenbank für den Proxy. Wir nennen diese im Beispiel ebenfalls „zabbix“:

sudo -u postgres createdb -O zabbix -E Unicode -T template0 zabbix

Dann wenden wir das von Zabbix mitgelieferte Schema auf die Datenbank an:

zcat /usr/share/doc/zabbix-proxy-pgsql/schema.sql.gz | sudo -u zabbix psql zabbix

Im letzten Schritt passen wir die Zabbix Proxy-Konfiguration an:

nano /etc/zabbix/zabbix_proxy.conf

Folgende Parameter müssen angepasst werden:

# IP oder FQDN des Hauptservers
Server=192.168.1.20
# Hostname des Proxies
Hostname=ZBX-PROXY
# DBHost muss wirklich leer bleiben, also wie abgebildet
DBHost=
# Name der Datenbank
DBName=zabbix
# Zuvor definierter Benutzer, den der Proxy zur DB-Verbindung verwendet
DBUser=zabbix
# Zuvor definiertes Passwort, das der Proxy zur DB-Verbindung verwendet
DBPassword=*******

Im Anschluss können wir den Zabbix Proxy einmal neustarten:

service zabbix-proxy restart

Bei Bedarf können mit folgender Zeile die Logfile-Einträge des Proxys in Echtzeit ausgegeben werden:

tail -f /var/log/zabbix/zabbix_proxy.log

Damit sollte die Installation abgeschlossen sein und Sie können den Proxy in Ihrer Zabbix-Oberfläche einrichten.

Kategorien
Clients Server Windows

Remote-Computerverwaltung als anderer Benutzer durchführen

Man kann mit der Computerverwaltung nicht nur den lokalen Computer verwalten, sondern sich auch remote auf andere Rechner schalten. In unserem Fall war es nun aber so, dass wir von einem Rechner in einer ActiveDirectory-Domain (A) auf einen Rechner drauf wollten, der sich nicht in der Domain befand (B). Der User, mit dem wir uns also auf Rechner B schalten wollten, war selbigem komplett unbekannt. Somit stellte sich die Frage, wie wir uns hier mit einem anderen Benutzer authentifizieren können.

Aber der Reihe nach. Als erstes greifen wir auf die lokale Computerverwaltung zu:

Dort angekommen, können wir uns nun mit dem anderen Computer per IP-Adresse verbinden:

Dies mag sogar manchmal noch gehen, jedoch bekommt man spätestens beim Zugriff auf die Dienste o.ä. einen „Zugriff verweigert“-Fehler zurück.

Um diesen Fehler zu verhindern, gibt es einen ziemlich tollen Trick. Mittels des „net use“-Befehls kann man sich nämlich an einem fremden Rechner authentifizieren, um beispielsweise ein Netzlaufwerk zu mappen. Diese Authentifizierung gilt global, also über das Laufwerkmapping hinaus und somit auch tatsächlich für unsere Computerverwaltung.

Wir öffnen also die Kommandozeile ([Win] + [R] –> cmd) oder PowerShell und geben folgende Zeile ein:

net use \c$ /user:

Damit verbinden wir uns auf die versteckte C$-Freigabe, die auf wirklich jedem PC verfügbar sein sollte. Dabei ersetzen wir die eingefärbten Zeichenfolgen natürlich sinnvoll. Ist der Zielcomputer nicht in einer Domäne, so können Sie „“ weglassen. Statt dem Computernamen können Sie natürlich auch eine IP eintragen.

Sie bekommen dann noch eine Passwortabfrage, die Sie für den User entsprechend ausfüllen sollten. Sofern alles passt, bekommen Sie den Erfolg mit der Meldung „Der Befehl wurde erfolgreich ausgeführt.“ quittiert:

Nun können Sie sich nochmal auf den Remotecomputer schalten und diesen ohne Probleme verwalten können.

Kategorien
CRM Windows

Dynamics CRM / 365 Performance-Messung (ab 2013 SP1)

Falls Sie Perfomance-Probleme mit Ihrer Dynamics CRM / 365-Instanz haben, können Sie mit den folgenden Schritten etwas mehr ins Detail gehen, um zu sehen, an welcher Stelle es tatsächlich hängt.

Rufen Sie als erstes bitte ein Formular auf, von dem Sie denken, dass es wirklich langsam lädt. In unserem Beispiel verwenden wir das Firmenformular:

Der nächste Schritt ist Browserabhängig:
Internet Explorer: Drücken Sie [Strg] + [Shift] + [Q] zum Aufruf des Performance Centers
Chrome: Drücken Sie [Strg] + [D] und drücken Sie dann auf [Mehr …]. Als URL geben Sie folgende Zeichenfolge ein (ohne Anführungszeichen): „javascript:Mscrm.Performance.PerformanceCenter.get_instance().TogglePerformanceResultsVisibility()“ und als Namen beispielsweise „Performance Center“. Dadurch haben Sie oben nun einen Knopf in der Lesezeichenleiste, den Sie nun drücken um das Performance Center aufzurufen.
Firefox: Drücken Sie [Strg] + [B] um die Lesezeichenleiste aufzurufen. Fügen Sie hier ein neues Lesezeichen mit der URL „javascript:Mscrm.Performance.PerformanceCenter.get_instance().TogglePerformanceResultsVisibility()“ (ohne Anführungszeichen) ein und benennen Sie es treffend. Klicken Sie dieses danach an, während Sie das betroffene Formular im aktiven Tab geöffnet haben.

In allen Fällen sollten Sie nun ein Performance Center sehen. Hier drücken Sie nun nacheinander [Enable] (1) und dann [Close] (2):

Lösen Sie nun einen Reload der Seite aus. Dies kann durch drücken von [F5] oder des „Aktualisieren“-Knopfes erfolgen.

Rufen Sie anschließend wieder das Performance Center auf. Sie sehen nun den Ablauf des Seitenaufbaus (3). Mit dem Knopf [Copy All] (4) können Sie nun die Wartezeiten auch nochmal als Text herauskopieren.

Sollten Sie für unser Hosted Dynamics 365 einen Performance-Auszug machen, so würden wir Sie zum einen um den Text bitten, den Sie über den [Copy All]-Knopf heraus bekommen und zum anderen könnten Sie uns noch einen Screenshot von der Balkendiagramm-Darstellung schicken.

Kategorien
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.

Kategorien
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.

Kategorien
CRM Server Windows

Dynamics CRM / 365 – Migration (Aktualisierung) einer Instanz und mögliche Probleme

Möchte man eine Instanz in eine andere Infrastruktur migrieren (möglicherweise aufgrund einer Aktualisierung), sollten folgende Schritte beachtet werden.

  • Bevor die Instanz in der „alten Umgebung“ abgeschaltet wird, sollte der aktuelle Schlüssel für die Datenverschlüsselung kopiert werden. Diesen finden Sie ab Dynamics CRM 2011 unter Einstellungen > Datenverwaltung > Datenverschlüsselung > [X] Schlüssel anzeigen. Sie benötigen diesen nach der Migration, um die Datenverschlüsselung wieder zu aktivieren.
  • Stellen Sie zudem sicher, dass es einen CRM-User gibt, der alle der folgenden Eigenschaften besitzt.
    • Zugriffsmodus: Lesen-Schreiben (NICHT Administrator und erst recht nicht Lesezugriff)
    • Rolle: Mindestens Systemadministrator
  • Anschließend können Sie auf dem Anwendungsserver die Instanz deaktivieren und löschen. Hierbei wird die Datenbank nicht gelöscht.
  • Besagte Datenbank können Sie anschließend auf dem SQL-Server entweder im Rahmen eines Backups sichern, oder aber die Datenbank einfach aushängen.
  • In beiden Fällen können Sie die Datenbank entweder durch simples Wiedereinhängen oder durch das Wiederherstellen der Sicherung im neuen SQL-Server einhängen.
  • Auf dem neuen CRM- / Dynamics 365-Server können Sie dann die Organisation importieren. Nach der erneuten Eingabe der Namen sowie der Auswahl des Report-Servers kommen wir hier zum Benutzermapping. Dies können Sie automatisiert durchlaufen lassen, sofern die Domäne gleich bleibt. Anderenfalls müssen Sie die CRM-Benutzer manuell den AD-Benutzern zuweisen.
  • Im Falle des Fehlers „You must map your Active Directory user account to at least one enabled Microsoft Dynamics CRM user who has the System Administrator role before the organization can be imported“ sind folgende Ursachen möglich:
    • Sie führen den Import mit einem Benutzer durch, den Sie nicht gemappt haben > Sie müssen sich entweder den Import mit dem Benutzer durchführen, auf den die Anforderungen aus Schritt 2 passen, oder Ihren aktuellen Benutzer auf den besagten CRM-User mappen.
    • Sie führen den Import mit einem Benutzer durch, dessen CRM-User nur administrativen Zugriff auf das CRM hat > Führen Sie folgende Query in der Datenbank Ihrer Instanz aus:
      UPDATE SystemUserBase
      SET AccessMode = 0
      WHERE DomainName = 'DOMAIN\User'
    • Sie führen den Import mit einem Benutzer durch, dessen CRM-User deaktiviert ist > Führen Sie folgende Query in der Datenbank Ihrer Instanz aus:
      UPDATE SystemUserBase
      SET IsDisabled = 0
      WHERE DomainName = 'DOMAIN\User'

      Es kann sein, dass Sie davor einen anderen Benutzer deaktivieren müssen, um die maximale Anzahl von Benutzern nicht zu überschreiten:

      UPDATE SystemUserBase
      SET IsDisabled = 1
      WHERE DomainName = 'DOMAIN\OtherUser'
  • Danach wird der Import durchgeführt. Dies lief bei uns fehlerfrei durch. Sollten uns bei kommenden Migrationen noch gängige Fehler auffallen, werden wir diese an der Stelle ebenfalls festhalten.
  • Nach dem erfolgreichen Umzug müssen Sie bei der Verwendung von ADFS spätestens jetzt die alte Instanz löschen. Aktualisieren Sie anschließend beide Relying Party Trusts (mangels deutscher Server fehlt mir hier die Übersetzung) – die der alten Instanz und die der neuen.
  • Der A-Record muss ebenfalls auf die neue Infrastruktur zeigen.
  • Tragen Sie nach dem erfolgten Zugriff auf das neue CRM den in Schritt 1 gespeicherten Verschlüsselungskey wieder unter Einstellungen > Datenverwaltung > Datenverschlüsselung ein. Danach ist das CRM / Dynamics 365 wieder voll benutzbar.
Kategorien
Clients Server Windows

Manuell oder per GPO: „Dieser PC“ statt „Schnellzugriff“ beim Öffnen des Explorers anzeigen

Bei frisch installierten Windows 10- und Windows Server 2016-Systemen wird beim Öffnen des Explorers der „Schnellzugriff“ statt „Dieser PC“ angezeigt. Diese Änderung sorgte für viel Unmut, auch weil nicht sofort ersichtlich war, wie man das ändert.

Manuell:

  • Rechtsklicken Sie auf „Schnellzugriff“ in der linken Navigationsleiste des Explorers und gehen Sie auf „Optionen“.
  • Wählen Sie im Reiter „Allgemein“ unter der Einstellung „Datei-Explorer öffnen für:“ die Option „Dieser PC“.
  • Bestätigen Sie mit Klick auf „OK“.

Gruppenrichtlinie:

  • Erstellen Sie eine neue Gruppenrichtlinie mit einem treffenden Namen.
  • Navigieren Sie in der GPO zu folgender Einstellung: „Computer Configuration“ -> „Preferences“ -> „Windows Settings“ -> „Registry“
  • Rechtsklicken Sie in den freien Raum und wählen dann „Neu“ -> „Registry Item“
  • Füllen Sie die Maske wie folgt aus:
    Action: „Update“
    Hive: „HKEY_LOCAL_MACHINE“
    Key Path: „SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced“
    Value Name: „LaunchTo“
    Value type: „REG_DWORD“
    Value data: „1“
    Base: „Decimal“
  • Diese Eingaben per Klick auf „OK“ bestätigen.
  • Die restlichen Fenster können geschlossen werden.
Kategorien
Clients Office Windows

Outlook: Ständig wiederkehrende Passwortabfrage

In der zweiten Januarwoche ’18 häuften sich bei uns die Meldungen, dass Outlook 2016 wiederholt das Kennwort abfrägt. Dass das richtige Passwort übermittelt wurde, konnten die Benutzer zuvor über OWA sicherstellen. Teilweise war auch der Versand und Empfang von Mails dennoch möglich.

Wir suchten zuerst an unseren Servern verzweifelt nach dem Fehler, da wir in jüngster Zeit tatsächlich infrastrukturelle Veränderungen durchgeführt hatten. Wir haben dann sogar über Nacht noch das aktuellste Cumulative Update für Exchange ausgerollt. Doch alle Bemühungen waren erfolglos, die Probleme blieben.

Was wir jedoch herausfinden konnten, war, dass das Problem nur mit dem 1711er Build von Outlook bestand. Als Workaround boten wir unseren Kunden daraufhin an, updatetechnisch auf den Build 1710 zurückzugehen. Sounds good – didn’t work: Über Nacht haben sich alle Outlooks wieder aktualisiert…

Heute Morgen wurden wir dann auf einen Reddit-Post aufmerksam, der Licht ins Dunkel brachte: https://www.reddit.com/r/sysadmin/comments/7pk33j/outlook_2016_password_prompt/

Scheinbar hat eine in Outlook reingepatchte Office 365-Änderung das Problem verursacht. Mit folgendem Registry-Eintrag:

[HKEY_CURRENT_USER\Software\Microsoft\Office\X.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

… unterbinden Sie die Abfrage der Office 365-Endpunkte beim Autodiscover-Vorgang. An diesen möchte sich Outlook 2016 scheinbar seit neuestem authentifizieren, was logischerweise nicht funktioniert – haben wir doch unsere eigene Infrastruktur.

Für kurz angebundene bieten wir auch eine ZIP-Datei mit den Fixes für die Outlook-Versionen 2010 – 2016 an. Ob tatsächlich ältere Versionen betroffen sind, ist uns aber nicht bekannt. Sie können die Datei unter folgendem Link beziehen: http://c4y.eu/passfix

Kategorien
Linux CentOS Zabbix

CentOS Zabbix Proxy: Neustartskript

Wir haben mehrere CentOS-basierte Zabbix-Proxies. Damit diese auch nach dem Neustart noch ihren Zweck erfüllen und nicht irgendwie in der Luft hängen, haben sich folgende Schritte etabliert.

nano /etc/rc.d/rc.local

Hinter diesem Pfad verbirgt sich ein Startup-Script. Dieses kann schon einige Zeilen enthalten. Wir ergänzen es einfach um folgende Einträge:

# eth1 ist die NIC in unser Netzwerk. eth0 ist die NIC mit Default Gateway in das zu überwachende Netz
# Zu Beginn starten wir diese NIC einmal neu, um sicherzustellen, dass sie aktiv ist
ifdown eth1
ifup eth1

# Dann setzen wir die Route für das Netz, in dem der Zabbix-Server letztendlich steht
ip route add [MgmtNetz]/[Hostbits] via [IP des Gateways der NIC] dev eth1 proto static metric 10
# Bsp.: ip route add 192.168.1.0/24 via 172.16.1.1 dev eth1 proto static metric 10

# SELinux Konfiguration „Eine Bastion gegen Angriffe“
setsebool zabbix_can_network 1
setsebool httpd_can_connect_zabbix 1

# Sicherstellen dass die Dienste laufen
systemctl start zabbix-proxy
systemctl start zabbix-agent
systemctl start postgresql

Anschließend stellen wir sicher, dass das Script ausführbar ist:

chmod +x /etc/rc.d/rc.local

Damit sollte der Proxy künftige Neustarts überleben.

Kategorien
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.