verbinde-MX (PowerShell-Funktion)

Die Idee

Ich arbeite viel mit Exchange Servern. Dabei benutze ich sehr gerne die PowerShell ISE statt der Exchange Management Shell – gerade auch wegen der Remoting-Funktionalität: Denn so muss ich nicht immer erst auf meinen Exchange Server mit RDP springen.

Für den Verbindungaufbau sind nur 2 Zeilen erforderlich:

Danach steht dann die Verbindung und vor allem die vielen Exchange-cmdlets zur Verfügung:

verbinde-MX (PowerShell-Funktion)

Das bietet sich auch in Scriptdateien an. Aber es gibt ein Problem: Der ConnectionURI muss einen existierenden und erreichbaren Exchange Server enthalten. Und das gibt 2 mögliche Probleme:

  1. Der Server wird in Scriptdateien statisch hinterlegt. Ersetzt ein neuer Exchange Server den alten, der im URI benannt wird, dann läuft das Script nicht mehr. Bei einer Vielzahl von Scripten bedeutet dies viel Arbeit durch nachträgliche Anpassungen.
  2. Nicht selten sind mehrere Exchange Server vorhanden. Es kann aber im ConnectionURI nur einer hinterlegt werden. Bei einem Ausfall-Szenario oder einer geplanten Wartung würden gespeicherte Scripte keine Verbindung mehr zum Exchange Server aufbauen können.

So kam mir die Idee zu einer einfach aufrufbaren Funktion, welche im Hintergrund alle möglichen Exchange Server ermittelt und dann der Reihe nach durchprobiert.

Von der Idee zum Code

Die Exchange Server tragen sich in der Configuration-Partition im Active Directory ein. Diese kann mit einfachen LDAP-Befehlen direkt aus der PowerShell heraus abgefragt werden – Ohne die Notwendigkeit des PS-Modules „ActiveDirectory“. Hier sind die gewünschten Informationen im ADSIedit sichtbar:

verbinde-MX (PowerShell-Funktion)

Und mit diesen Zeilen kann man sehr einfach nach der ObjectClass msExchPowerShellVirtualDirectory suchen:

Das Ergebnis ist ein Array aller PowerShell-VirtualDirectories mit den URI’s:

verbinde-MX (PowerShell-Funktion)

Leider erhalten nur Administratoren der Exchange Server die URI-Liste angezeigt. Alle anderen Benutzer ohne besondere Rechte (aber mit einem Postfach) gehen leer aus:

verbinde-MX (PowerShell-Funktion)

Eine Alternative zur Abfrage wäre daher die Ermittlung der Exchange-Servernamen und daraus abgeleitete URIs:

verbinde-MX (PowerShell-Funktion)

Der Rest der Funktionslogik war dann recht einfach.

Das fertige Script

Das fertige Script habe ich zur besseren Strukturierung in einzelne Regionen unterteilt. Damit kann man relativ einfach durch die Anweisungen navigieren:

verbinde-MX (PowerShell-Funktion)

Zuerst werden bestehende Verbindungen zu einem Exchange Server ermittelt. Sind diese vorhanden, dann wird die Funktion beendet. Alternativ kann mit einem Parameter -NewSession auch ein Beenden der bestehenden Verbindungen erfolgen, bevor eine neue Verbindung aufgebaut wird. Dann sucht die Funktion nach URIs. Dabei wird zuerst der „AdminMode“ verwendet. Nur, wenn dieser keine Ergebnisse liefert, werden die URIS aus den Servernamen generiert. Dann wird die URI-Liste durchprobiert, bis eine erfolgreiche Verbindung aufgebaut wurde oder die Liste kene weiteren Einträge enthält. Zuletzt gibt es noch einen Ausgabebereich.

Das ist nun der finale Code:

Mögliche Aufrufe

Und so könnten die Szenarien der Verwendung aussehen. Der klassische Aufruf erfolgt ohne Parameter:

verbinde-MX (PowerShell-Funktion)
Verbindungsaufbau: Das Laden der Remotebefehle.
verbinde-MX (PowerShell-Funktion)
Die RemoteSession zum Exchange Server
verbinde-MX (PowerShell-Funktion)
Erneute Verbindungen werden vermieden.

Alternativ lässt sich der Aufruf auch in Bedingungen verwenden:

verbinde-MX (PowerShell-Funktion)

Und bestehende Verbindungen können erneuert werden:

verbinde-MX (PowerShell-Funktion)

Zusammenfassung

Die Funktion ist fertig und ich kann sie in meine Exchange Scripte integrieren. Und hier gibt das Script noch als zip-Archiv .

Stay tuned!

Kommentar hinterlassen