colinardo
Goto Top

Exchange - Nutzung der Cmdlet Extension Agents (Scripte automatisch bei Ereignissen ausführen lassen)

back-to-topEinleitung

Viele von euch kennen vermutlich folgende Situation:
Wir müssen z.B. bei neu angelegten Mailboxen im Exchange bestimmte Berechtigungen setzen oder das ein oder andere Feature in der Mailbox deaktivieren, und und und. Dies lässt sich nun auf der einen Seite mit Scripten realisieren die wir dann aber ausschließlich für das Erstellen von Mailboxen benutzen können, da ansonsten eine Anlage über die EMC nachträgliche Arbeiten erfordern würde.

Eine interessante Alternative dazu ist ein Feature, dass viele aber nicht kennen, und ab Exchange Server 2010 verfügbar ist: Die Cmdlet Extension Agents springen bei bei jedem Aufruf eines Powershell-CMDLets (z.B. "new-mailbox" / "remove-mailbox" etc.) in die Bresche und können automatisch Scripte aufrufen welche die zusätzlich nötigen Aufgaben im Hintergrund erledigen. Die Admins können dann also die gewohnten Tools wie die EMC und EMS zur Useranlage nutzen, und im Hintergrund wird dann der Rest automatisch vorgenommen.

Wie man die Cmdlet Extension Agents aktiviert und wie man sie nutzt, erfahrt Ihr in dieser Anleitung.

back-to-top1. Erstellen der Konfigurationsdatei

Wir erstellen folgende Konfigurationsdatei mit dem Namen ScriptingAgentConfig.xml. Dieser Name darf nicht verändert werden !
<?xml version="1.0" encoding="utf-8" ?>
<Configuration version="1.0">
 <Feature Name="MeineMailboxAktionen" Cmdlets="new-mailbox">
  <ApiCall Name="OnComplete">
   if($succeeded)    {
    $newmailbox = $provisioningHandler.UserSpecifiedParameters["Name"]
    set-casmailbox $newmailbox -ImapEnabled $false
   }
  </ApiCall>
 </Feature>
</Configuration>
Die XML-Datei legen wir dann in folgendem Exchange-Ordner ab:
C:\Program Files\Microsoft\Exchange Server\V14\Bin\CmdletExtensionAgents\
Dort befindet sich auch eine Beispiel-Konfigurationsdatei anhand derer man die weiteren Möglichkeiten abschauen kann.

Was macht die Konfigurationsdatei nun genau ?

Betrachten wir die folgende Zeile: <Feature Name="MeineMailboxAktionen" Cmdlets="new-mailbox">. Der Parameter "Cmdlets" gibt an welche Cmdlets unsere benutzerdefinierte Aktion auslösen. In diesem Fall, wenn eine neue Mailbox angelegt wird. Hier können wir auch mehrere CMDlets definieren, indem wir sie mit einem Komma voneinander trennen. Den Name-Parameter können wir frei wählen. In der XML-Datei können auch mehrere solcher Feature-Abschnitte für unterschiedliche CMDLets angelegt werden.

Die nächste Zeile <ApiCall Name="OnComplete"> legt fest wann unsere benutzerdefinierte Aktion ausgelöst wird. Im Beispiel ist es das OnComplete-Event welches ausgelöst wird, sobald der Befehl beendet wurde. Hier können wir auch das Validate-Event benutzen welches noch vor dem Eigentlichen CMDLet-Befehl ausgelöst wird. Dies kann z.B. dazu genutzt werden um eine Mailbox bevor sie entfernt wird, noch vorher via "New-MailboxExportRequest" als PST-Datei zu sichern.

Im obigen Beispiel wird bei jeder Neuanlage einer Mailbox, in dieser das IMAP-Feature deaktiviert. Um den Namen der betroffenen Mailbox zu erhalten, wird diese Zeile genutzt:
$newmailbox = $provisioningHandler.UserSpecifiedParameters["Name"]
Hier kann man auch auf alle an das CMD-Let übergebenen Parameter zugreifen und entsprechend reagieren.

back-to-top2. Aktivieren der Cmdlet Extension Agents

Um die Agents zu aktivieren müssen wir noch folgenden Befehl in einer Exchange Management Shell absetzen:
Enable-CmdletExtensionAgent "Scripting Agent"
Wenn man nun in der EMC oder der EMS eine neue Mailbox angelegt (diese nutzen im Hintergrund auch die Powershell-CMDLets), wird in dieser Mailbox automatisch das IMAP-Feature deaktiviert. Praktisch oder !?

back-to-top3. Nutzung von externen Scripten

Natürlich kann man in der obigen XML-Datei auch ein externes Script aufrufen das die entsprechenden Befehle enthält, und Ihm mit einem Parameter das entsprechend betroffene Objekt mit übergeben.
c:\scripts\new-mailbox-script.ps1 -name $newmailbox
Ein kleiner Nachteil ist, das bei der Nutzung von mehreren Exchange-Servern die XML-Datei auf alle Server verteilt werden muss.

Aber im Großen und Ganzen ein sehr nützliches Feature, das es wert ist mal erwähnt zu werden face-smile

Grüße @colinardo

Content-ID: 231958

Url: https://administrator.de/contentid/231958

Ausgedruckt am: 25.11.2024 um 22:11 Uhr

Belloci
Belloci 16.04.2014 aktualisiert um 13:10:34 Uhr
Goto Top
Hallo @colinardo,

danke für den super Beitrag. Ich habe mich mal an die Sache gewagt und zwar so wie du es in deiner Anleitung beschrieben hattest. Selbstverständlich habe ich das auf meine Bedürfnisse (OWA & ActiveSync disablen) angepasst.

Meine XML sah dann so aus:

<?xml version="1.0" encoding="utf-8" ?>   

<Configuration version="1.0">   

 <Feature Name="OWAActiveSyncOff" Cmdlets="new-mailbox">   

  <ApiCall Name="OnComplete">   

   if($succeeded)    { 

    $newmailbox = $provisioningHandler.UserSpecifiedParameters["Name"]   

    set-casmailbox $newmailbox -OWAEnabled $false 
    set-casmailbox $newmailbox -ActiveSyncEnabled $false 

   } 

  </ApiCall> 

 </Feature> 

</Configuration>

Ich habe das so verstanden, dass im Featurename alles drin stehen darf, daher irrelevant. Dann habe ich im nächsten step die XML OWAActiveSyncOff.xml benannt und Enable-CmdletExtensionAgent "Scripting Agent" - das gab eine dicke Fehlermeldung nachdem ich die EMC gestartet habe face-wink. Also schwupps, die Datei in ScriptingAgentConfig.xml umbenannt und schon war die böse Meldung weg. Problem: Nach Neuanlage eines Postfachs waren sowohl ActiveSync als auch OWA enabled...

Ich gehe mal davon aus, dass meine XML falsch ist, kannst du das bestätigen?! Danke dir im Voraus für deine Mühe!

Gruß
B
colinardo
colinardo 16.04.2014 aktualisiert um 13:35:07 Uhr
Goto Top
Hallo Belloci,
kann ich nicht bestätigen, hier geht es problemlos, prüfe mal ob der "Scripting Agent" überhaupt auf deinem System exisitiert:
Get-CmdletExtensionAgent | %{$_.Name}
Wenn er vorhanden ist, könntest du mal schrittweise die Priorität des Agents erhöhen (0 ist die dabei die höchste Priorität):
Set-CmdletExtensionAgent "Scripting Agent" -Priority 3
Standardmäßig steht diese auf 6. Wenn nämlich ein anderer Agent nach dem Scripting Agent die selbe Eigenschaft verändert, greift dein Script natürlich nicht weil die Eigenschaft durch den anderen Agent überschrieben wird.

Grüße Uwe
Belloci
Belloci 16.04.2014 um 14:05:43 Uhr
Goto Top
Hi Colinardo,

Ersteres geprüft, war vorhanden und wurde demnach angezeigt. Prioriät habe ich dann auf 3 erhöht und ein neues Postfach angelegt - leider kein Erfolg. Sehr komisch. In meiner Konstellation habe ich 2 Exchange Server - auf beiden die XML abgelegt... Kann mir auch nicht vorstellen, dass ein anderer Agent dieses überschreibt...

Gruß
Belloci
colinardo
colinardo 16.04.2014 aktualisiert um 14:16:21 Uhr
Goto Top
Zitat von @Belloci:
Ersteres geprüft, war vorhanden und wurde demnach angezeigt. Prioriät habe ich dann auf 3 erhöht und ein neues
Postfach angelegt - leider kein Erfolg. Sehr komisch. In meiner Konstellation habe ich 2 Exchange Server - auf beiden die XML
abgelegt... Kann mir auch nicht vorstellen, dass ein anderer Agent dieses überschreibt...
In dieser Konstellation musst du natürlich auch auf beiden Servern den Agent aktivieren.
Und erhöhe die Priorität auch mal bis auf 0.

Dann teste doch erst mal ob der Agent überhaupt ausgeführt wird.
dazu kannst du auch mal einfach nur folgenden Powershell-Command in die XML-Datei schreiben:
if($succeeded){ 
    echo "Test, hat funktioniert" | out-file C:\test.txt  
} 
und dann checken ob die Datei nach dem Erzeugen der Mailbox vorhanden ist.

Grüße Uwe
Belloci
Belloci 16.04.2014 aktualisiert um 14:18:22 Uhr
Goto Top
Da scheint der Hase begraben zu sein... Kein Output File...

Habe nach der Einrichtung des Agenten keinen Neustart gemacht, eventuell ist der von Nöten?
colinardo
colinardo 16.04.2014 aktualisiert um 14:30:45 Uhr
Goto Top
Poste mal die Ausgabe von:
Get-CmdletExtensionAgent | ?{$_.Name -eq "Scripting Agent"}
Habe nach der Einrichtung des Agenten keinen Neustart gemacht, eventuell ist der von Nöten?
normalerweise nicht, kann aber nicht schaden.

Welches Servicepack hat der Exchange ?

Zitat von http://technet.microsoft.com/de-DE/library/dd297951%28v=exchg.141%29.as ...
Der Agent wird auch nicht auf Exchange-Servern ausgeführt, auf denen die Edge-Transport-Serverrolle ausgeführt wird, da diese Serverrolle keine Cmdlet-Erweiterungs-Agents unterstützt. 
Belloci
Belloci 16.04.2014 aktualisiert um 14:49:07 Uhr
Goto Top
Hi,

hier die Ausgabe:

RunspaceId        : 3e2d5bd7-dfcd-...
Assembly          : Microsoft.Exchange.ProvisioningAgent.dll
ClassFactory      : Microsoft.Exchange.ProvisioningAgent.ScriptingAgentClassFactory
Enabled           : True
Priority          : 1
IsSystem          : False
AdminDisplayName  : 
ExchangeVersion   : 4.0 (14.1.166.0)
Name              : Scripting Agent
DistinguishedName : CN=Scripting Agent,CN=CmdletExtensionAgent Settings,CN=Global Settings,CN=ABCD,CN=Mic
                    rosoft Exchange,CN=Services,CN=Configuration,DC=xxx,DC=local
Identity          : Scripting Agent
Guid              : 941284d0-4731-4e0c....
ObjectCategory    : xxx.local/Configuration/Schema/ms-Exch-Cmdlet-Extension-Agent
ObjectClass       : {top, configuration, msExchCmdletExtensionAgent}
WhenChanged       : 16.04.2014 14:06:24
WhenCreated       : 01.12.2011 16:50:53
WhenChangedUTC    : 16.04.2014 12:06:24
WhenCreatedUTC    : 01.12.2011 15:50:53
OrganizationId    : 
OriginatingServer : xxx.local
IsValid           : True

Exchange hat den aktuellen Patchstand!
colinardo
colinardo 16.04.2014 aktualisiert um 15:02:10 Uhr
Goto Top
Hat einer dein Server die Edge-Transport-Rolle installiert ?
Get-ExchangeServer | select ServerRole
wenn ja dann laufen die Agents dort nicht s. letzter Kommentar.

Ansonsten bin ich jetzt mit meinem Latein bei dir am Ende. Entweder machst du irgendwas falsch das ich hier nicht sehe, oder etwas stimmt an deinem System nicht ganz.
Belloci
Belloci 16.04.2014 um 15:04:29 Uhr
Goto Top
Hey,

also habe ich gerade schon überpfüft, leider negativ also EDGE-Transport ist nicht installiert.

Ich werde die Systeme mal neu starten und danach erneut probieren - halte die Geschichte hier auf den neusten Stand!

Gruß
B

Und danke für deine Unterstützung!
Belloci
Belloci 16.04.2014 um 20:26:51 Uhr
Goto Top
Guten Abend nochmal!

Habe jetzt die ganzen Einstellungen erneut geprüft und einen Neustart gemacht, leider ohne Erfolg - dies nur zur Info.

Schönen Abend und Gruß
Belloci
colinardo
colinardo 16.04.2014 aktualisiert um 22:12:02 Uhr
Goto Top
dann Check nochmal alle Logs, normal ist das auf jeden Fall nicht, da es hier auf mindestens 10 Servern ohne Probleme läuft. Vielleicht läuft irgendein Dienst bei dir nicht. Hmm, da werde ich nochmal genauer Hinschauen und die Abhängigkeiten mal checken.

Überprüfe auch ob die Powershell Execution Policy auf dem Server das Ausführen von Scripts erlaubt.
Set-ExecutionPolicy RemoteSigned
Ebenso schönen Abend
Grüße Uwe