Batch Skripte ablösen?

[MaikHSW 13]

Hey zusammen.

Ich sitze derzeit mit einigen Kollegen bei einem Kunden.

Dort arbeiten die Kollegen zu 98 % mit Batch Skripten, welche teils einige hundert bis tausend Zeilen lang sind.

Von der Ausführung haben diese Skripte eher den Charakter ganzer Programme in der cmd.

Leider bin ich batchmäßig nur bedingt fit und kenne diverse Fallstricke nicht.

Ebenso wie es sehr leidlich ist, ein großes Skript lesen und verstehen zu müssen um es weiter zu entwickeln.

 

Daher habe ich persönlich auch mal angeregt, ob man nicht einen Wechsel in Betracht ziehen kann.

Die Kollegen haben keine Kenntnisse weiterer "Sprachen" und sind daher eher skeptisch.

Eine Umsetzung der großen Programme in "richtige" Sprachen wie C# wurde kategorisch abgelehnt.

 

Nun ist aber die Frage, ob z.B. Visual Basic Script die Lösung der Probleme werden kann.

 

Die Anforderungen:

- möglichst eine IDE oder etwas vergleichbares zum einfachen debuggen

- möglichst nicht zu kompex zu lernen

- Funktionsfähig auf Windows Server 2000 - 2008

- Übergabe von Parametern an externe Programme und entgegen nehmen von Return Codes (kann vermutlich nahezu jede Umgebung)

- direkteres Umsetzen schwieriger Aufgaben (z.B. Registry Keys lesen und neu einfügen) notwendig

 

Wie seht ihr das mit eurer Erfahrung?

Macht ein Umstieg Sinn oer ist das derzeit der beste Weg?

Wohin soll der Umstieg sein?

 

 

 

Gruß

[NorbertFe 2.034]

Die Anforderungen:

- möglichst eine IDE oder etwas vergleichbares zum einfachen debuggen

- möglichst nicht zu kompex zu lernen

- Funktionsfähig auf Windows Server 2000 - 2008

- Übergabe von Parametern an externe Programme und entgegen nehmen von Return Codes (kann vermutlich nahezu jede Umgebung)

- direkteres Umsetzen schwieriger Aufgaben (z.B. Registry Keys lesen und neu einfügen) notwendig

 

Wie seht ihr das mit eurer Erfahrung?

Macht ein Umstieg Sinn oer ist das derzeit der beste Weg?

Wohin soll der Umstieg sein?

 

Schwer zu sagen, da du wenig über die derzeitigen Aufgaben der Skripte sagst. Vieles läßt sich inzwischen sinnvoll mittels GPP in den GPOs konfigurieren und ist damit für viele "nicht Batchisten" einfacher und übersichtlicher. Wenns komplexer wird, kann man es natürlich in einer beliebigen Sprache skripten, aber warum dann nicht bei batch bleiben? ;) Nur weil du es nicht kannst, müssen sich dann deine Kollegen umstellen, oder wie? :)

Grundsätzlich ist in VBScript fast alles irgendwie möglich, aber es ist meist mehr "Skript" als Batch und vor allem von MS auch schon wieder fallengelassen. Powershell finde ich für Logonskripte etwas zu lahm, aber eventuell wäre es ne Alternative.

 

Bye

Norbert

[jarazul 10]

Wie Norbert schon sagte, wenn der einzige Grund für einen Wechsel der ist, dass du Schwierigkeiten mit der Technologie hast, wäre es wohl einfacher, dass du dich auf die Technologie anpasst und nicht umgekehrt :)

 

Wenn aber auch Performance- / Security- / Management-Faktoren eine Rolle spielen, wäre der Umstieg auf Powershell, soweit sich damit alle Anforderungen umsetzen lassen, ein guter Schritt. Blicken wir in die Zukunft, werden Batch / VBS neben Powershell / GPP nur Nebensache.

 

cheers, Daniel

bearbeitet 30. August 2011 von jarazul
typo

[MaikHSW 13]

Hey.

Also nun dachte ich alle Infos gegeben zu haben und trotz weist ihr mich auf Lücken hin :-)

@ Norbert

Wir arbeiten hier im TSM Backup Umfeld und die Skripts arbeiten da zu.

Das heißt, um z.B. Knoten zu verschieben oder Auswertungen von Remotesystemen zu holen und interaktiv darzustellen.

Einfach um mal zwei Ansätze zu nennen.

Das heißt, dass GPO rausfällt.

 

Neee, die Kollegen müssen sich nicht wegen mir umstellen.

Es waren zwei Kollegen, die die Skripte gebaut und betreut haben.

Ein Kollege ist gegangen und nur einer bleibt über.

Um das Risiko zu streuen müssen mehrere diese Skripte (enorm wichtig) verstehen und betreuen können.

Der Kollege sagt selbst, dass man viele Sachen mit Batch nur sehr umständlich lösen kann und einfachere Wege auch in seinem Interesse wären.

Von ihm kam auch der Wunsch nach einer Entwicklungsumgebung, dies würde ja weiteren Kollegen den Zugang erleichtern.

 

Powershell wäre eine Idee, aber ich meine Windows 2000 kann Powershell nicht und auf 2003 war sie auch nur optional, oder?

Da wir "nur" das Backup betreuen werden die Serverjungs uns lynchen, wenn wir nun mit solchen Wünschen ankommen.

 

@ Jarazul

Wie bereits geschrieben ging es mir darum die Sache zukunftssicher zu machen und das Gefahrenpotenzial von nur einer Person zu umgehen.

Powershell macht heute m.E. wegen der alten Systeme keinen Sinn.

Wenn ich dafür Changes beantrage und diese verteidigen muss wird das mühseliger, als jeglicher Nutzen den es bringen könnte.

 

 

Gruß

[NorbertFe 2.034]

IBM liefert doch teilweise selbst inzwischen .ps1 für TSM. Hatte ich neulich für das Backup von passiven DB-Kopien einer Exchange 2010 DAG gesehen. Insofern würde ich auch Richtung PS tendieren. Ihr bleibt ja wahrscheinlich nicht in alle Ewigkeit bei 2003. ;) 2000 ist natürlich aussen vor.

 

Bye

Norbert

[lefg 276]

Was machen denn diese Batches?

 

Vorstellbar wäre eine Neuprogrammierung in VBS oder PS, nicht ein quasi zeilenweises Umsetzen der Funktionen.

 

Das muss wohl aber jemand machen, der die Funktionen kennt und in der neuen Sprache programmieren kann. Oder die Funktionen müssen dem Programmierer eben ausreichend beschrieben werden.

 

Fall Du oder die Kollegen beim Kunden die Skripte in der neuen Sprache betreuen sollt, dann müsst ihr die Sprache erlernen, beherrschen. wohl auch andere, neue Programmkonzepte.

 

Wie schaut es denn aus mit einer Vergabe an Professionals nach drausssen?

bearbeitet 30. August 2011 von lefg

[MaikHSW 13]

Hey.

@ Norbert

Ja, IBM liefert auch derartige Skripte.

Aber die Server laufen unter Linux und wir holen uns wirklich hart die Protokolldaten.

Sprich da helfen die PS Skripte von IBM leider nicht weiter.

Naja, ich fürchte der Kunde will noch lange bei 2003 bleiben.

Er ist groß genug und hat Exklusivverträge mit MS.

Wer schließlich heute noch für Windows 2000 Support durch MS bekommt....

 

@ lefg

Es wird auf eine Neuprogrammierung hinaus laufen,

ein etappenweises Umsetzen mit mehreren Sprachen wäre zu aufwendig.

Die Funktionen kennt das Team und kann sie auch sehr genau definieren.

Darum wäre mein Ziel, eine neue Sprache die zukunftsorientiert ist für kleinere Projekte bereits zu etablieren.

Da kann dann das Team (und auch ich) sich an die Sprache gewöhnen und wachsen.

Konzepte zu lernen und zu verstehen sollte kein Thema sein, denn das geht hier recht gut mit dem Team.

Eine Vergabe von Professionals ist nicht möglich denke ich,

da der Kunde den Bedarf immer sehr schwach einstuft und derartige Skripte ja nur die Arbeit der Dienstleister treffen.

Das damit seine Umgebung überwacht und betreut wird ist zweitrangig, dafür hat er den Dienstleister schließlich gekauft.

Und das bisherige Budget gibt keine Entwickler her.

 

 

Gruß

[lefg 276]

Nun, falls die Sache nicht so dringlich, Zeit dafür vorhanden, letztendlich ja auch Geld, dann kann man ja anfangen einzelne Funktionen in Ruhe umzusetzen und daran zu wachsen.

 

Sowas wünsche ich mir mal. Für mich gab es nie die Notwendigkeit dazu.

 

Viel Erfolg, viel Freude.

[blub 115]

Powershell wäre eine Idee, aber ich meine Windows 2000 kann Powershell nicht und auf 2003 war sie auch nur optional, oder?

Da wir "nur" das Backup betreuen werden die Serverjungs uns lynchen, wenn wir nun mit solchen Wünschen ankommen.

 

 

Hi,

gibts denn dann keine Unternehmensvorgabe, welche Sprache zu verwenden ist?

 

Die Nachrüsten der Powershell auf 2003-er Server ist vollkommen problemlos (Voraussetzung: .Net 2.0 bzw. 3.0 für die IDE). Die 2000-er Skripte würde ich nicht mehr anfassen und die neueren Systeme etappenweise auf PS umstellen.

 

Aus meiner Erfahrung reduziert sich die Größe von VBS- oder Batchskripten bei der Powershell gewaltig. Codes von über 100 Zeilen habe ich mit weniger als 10 Zeilen umgesetzt. C# wäre dafür überdimensioniert.

 

Eine einfache, aber durchaus brauchbare IDE ist ab Powershell v2.0 dabei, es gibt auch einige weitere freie sowie kostenpflichtige. Unter VBS habe ich immer Primalscript zum Entwickeln benutzt, kostet aber bischen was.

 

blub

[mamamia 13]

Hi,

gibts denn dann keine Unternehmensvorgabe, welche Sprache zu verwenden ist?

 

Die Nachrüsten der Powershell auf 2003-er Server ist vollkommen problemlos (Voraussetzung: .Net 2.0 bzw. 3.0 für die IDE). Die 2000-er Skripte würde ich nicht mehr anfassen und die neueren Systeme etappenweise auf PS umstellen.

 

Aus meiner Erfahrung reduziert sich die Größe von VBS- oder Batchskripten bei der Powershell gewaltig. Codes von über 100 Zeilen habe ich mit weniger als 10 Zeilen umgesetzt. C# wäre dafür überdimensioniert.

 

Eine einfache, aber durchaus brauchbare IDE ist ab Powershell v2.0 dabei, es gibt auch einige weitere freie sowie kostenpflichtige. Unter VBS habe ich immer Primalscript zum Entwickeln benutzt, kostet aber bischen was.

 

blub

 

Ich sehe das genauso wie blub. Sicherlich ist der Aufwand am Anfang deutlich höher, aber wo ist er das nicht bei einer Umstellung. PowerShell ist nun mal derzeit das Maß aller Dinger im Windows Scripting.

 

Auch wird sich der Code verringern und die Scripte werden eine ganz andere Perfomance haben.

 

Meine favorisierte wsh-IDE ist Systemscripter und beim PS nutze ich den ScriptEditor von PowerGUI.

[MaikHSW 13]

Hey zusammen.

@ lefg

Ja, man kann sich seine Arbeit halt leichter und schneller gestalten.

Es ist halt ein gewisser Luxus, gepaart mit Notwendigkeit.

 

@ blub

Nein, keine Vorgabe.

Jeder macht es so wie er kann, also meist pro Team.

Danke für die IDE´s, die gucke ich mir mal an.

@ mamamia

Powershell wird kommen und ist mir, durch Exchange, kein Fremdwort.

Danke auch für deine Tipps.

 

Gruß