Vorbemerkung: Für FailureRevert wird genau die gleiche Suchstrategie angewendet wie für AutoAction. Aus Gründen der Übersichtlichkeit ist im Folgenden aber nur von AutoAction die Rede.

Der Remote Service Agent versucht immer, das "beste" AutoAction-Script oder -Programm zu finden. Er startet die Suche mit speziellen Namen und arbeitet sich dann weiter vor zu den allgemeineren Namen. Das erste Programm, welches er finden kann, das führt er aus. Die Suche bricht dann ab.

Als erstes hängt er den Namen des Servers hinten an AutoAction an und schaut nach, ob es eine solche Datei gibt. In der Microsoft-Welt, wo Dateiendungen eine wichtige Rolle spielen, probiert er noch eine Liste von Endungen durch, .exe, .com, .pl und so weiter. Findet er mit dem Servernamen nichts, so probiert er es als Nächstes mit dem Betriebssystem hinten dran, also etwa AutoAction.unix, bei Microsoft wieder mit der Liste der Endungen.

Der letzte Anlauf geschieht dann einfach nur mit AutoAction, bei Windows wieder ergänzt mit der Liste der Endungen.

Wurde jetzt immer noch kein AutoAction gefunden, dann bricht die Suche ergebnislos ab. Das wird aber nicht als Fehler betrachtet, denn offensichtlich wurde dieser Job nur zum Versenden von Dateien benutzt, ohne daß weitere Maßnahmen durchgeführt werden sollten.

Diese Strategie hat den Vorteil, daß man mit einem Job unterschiedliche Plattformen behandeln kann, und daß man Sonderbehandlungen für einzelne Server, zum Beispiel interne Testserver, so maskieren kann, daß sie keinesfalls auf Kundensystemen ausgeführt werden und dabei Schaden anrichten könnten. Beispielsweise möchte man bei den eigenen Testmaschinen, die man ja möglichst oft zum Testen verwenden will, vor der Wartungsmaßnahme die vorherige Wartungsmaßnahme rückgängig machen, damit man es wiederholt ausprobieren kann. Dieses "Rückgängig" machen könnte auf einem Kundensystem höchst unerwünscht sein!