Windows services tool

[Pannenkoek14]

Ik ben opzoek naar een applicatie die het volgende kan:

Vanuit een GUI interface via het netwerk bepaalde windows services stoppen en in een bepaalde volgorde.

VB:

Op Server A, moet service 1 gestopt worden en service 2 en 3 mogen pas gestopt worden wanneer service 1 zeker gestopt is. Vervolgens een restart en moeten de services in omgekeerde volgorde weer gestart worden.

Ik weet dat er veel mogelijk is met powershell, maar we zijn juist opzoek naar een aapilcatie met een ovezichtelijke GUI. Volgens mij zit er zoiets in de System Center 2012 suite, maar dat is weer een beetje overkill!!


Iemand zoiets gezien?

[Verwijderd]

RSAT?

[CMD-Snake]

Pannenkoek14 schreef op vrijdag 24 april 2015 @ 15:27:
Volgens mij zit er zoiets in de System Center 2012 suite, maar dat is weer een beetje overkill!!

System Center Orchestrator 2012R2 bedoel je? Dat is althans de nieuwste versie met RTM status.

Er zijn ook andere automatiseringspakketten maar die zijn naar mijn weten niet gratis.

Er is weinig achtergrond in je startpost, wat aanbevelingen doen moeilijk maakt. Als je in het MKB werkt en voor een dubbeltje op de eerste rij moet zitten, kies PowerShell. Enterprise omgeving? SCORCH is dan een goed pakket, het is erg veelzijdig en je kan veel meer taken daarmee automatiseren.

[PROnline]

mmc?

add module, services => remote computer....

Of bouw een GUI met powershell...
http://www.drdobbs.com/wi...s-in-powershell/240049898

[ Voor 53% gewijzigd door PROnline op 24-04-2015 16:07 ]

[Pannenkoek14]

Het is voor een enterprise omgeving met alleen maar windows servers, waar het om gaat is dat wanneer er windows updates gedeployed worden en een restart noodzakelijk is dit bij een groot deel van onze servers niet automatisch kan vanwege services die netjes gestopt moeten worden. Dit proberen we dus te automatiseren, dat wanneer er een reboot pending is, de desbetreffende services in volgorde gestopt worden.
De applicatie hoeft niet perse gratis te zijn, mag wel natuurlijk.

CMD-Snake schreef op vrijdag 24 april 2015 @ 15:48:
[...]


System Center Orchestrator 2012R2 bedoel je? Dat is althans de nieuwste versie met RTM status.

Er zijn ook andere automatiseringspakketten maar die zijn naar mijn weten niet gratis.

Er is weinig achtergrond in je startpost, wat aanbevelingen doen moeilijk maakt. Als je in het MKB werkt en voor een dubbeltje op de eerste rij moet zitten, kies PowerShell. Enterprise omgeving? SCORCH is dan een goed pakket, het is erg veelzijdig en je kan veel meer taken daarmee automatiseren.

[ Voor 6% gewijzigd door Pannenkoek14 op 24-04-2015 16:39 ]

[Orion84]

Is dat dan niet vooral een kwestie van de dependencies in die services op orde brengen? Ik heb er niet veel verstand van, maar het lijkt me dat daarmee automatisch ook startup en shutdown volgorde correct zou moeten zijn.

[Pannenkoek14]

Klopt, maar dan zal je zelf nog handmatig een service moeten stoppen wanneer er een restart nodig is.
En dit willen we juist automatiseren.

Orion84 schreef op vrijdag 24 april 2015 @ 16:42:
Is dat dan niet vooral een kwestie van de dependencies in die services op orde brengen? Ik heb er niet veel verstand van, maar het lijkt me dat daarmee automatisch ook startup en shutdown volgorde correct zou moeten zijn.

[Orion84]

Die volg ik even niet (maar dat kan goed aan mij liggen). Waarom moet je handmatig services stoppen als er een restart nodig is? Onderdeel van een reboot lijkt me toch ook dat alle services gestopt worden (in de volgorde afhankelijk van de geregistreerde dependencies)?

[MAX3400]

Orion84 schreef op vrijdag 24 april 2015 @ 16:47:
Die volg ik even niet (maar dat kan goed aan mij liggen). Waarom moet je handmatig services stoppen als er een restart nodig is? Onderdeel van een reboot lijkt me toch ook dat alle services gestopt worden (in de volgorde afhankelijk van de geregistreerde dependencies)?

Kan me voorstellen dat je niet eerst SQL-services wil stoppen terwijl een of andere "exclusive locking" CRM-applicatie nog records open denkt te hebben staan. Oftewel, eerst CRM stoppen, daarna pas SQL. Een beetje domme applicatie heeft natuurlijk geen enkele dependency met overige services op de omgeving maar is er wel 100% van afhankelijk.

Ik ben het wel met anderen eens: ga lekker aan de slag met PowerShell. Kan je ook controle houden of een service gestopt is, eventueel vragen om user-input indien niet gestopt of anders de volgende service omver schoffelen.

Bij gebrek aan informatie over wat voor servers het gaat, is het lastig om een advies te geven. Je kan namelijk ook tegenwoordig fijn PowerShellen tegen een VMware host of een XenServer Putty-connectie opzetten maar daar is veel meer voor nodig dan alleen Start -> Programs -> Powershell.exe

[ Voor 5% gewijzigd door MAX3400 op 24-04-2015 16:59 ]

[Dennism]

Services horen inderdaad automatisch te stoppen bij een shutdown / restart met inachtname van de (zelf ingestelde) dependancies wanneer deze op een server staan. Gebeurt dit niet, dan zit er mogelijk wat verkeerd in de configuratie van de services, of is de service brak geprogrammeerd door de software boer.

Over meerdere servers wordt een ander verhaal, maar dat komt uit de startpost in ieder geval niet terug.

Daarnaast is natuurlijk de System Center Suite juist voor een Enterprise organisatie zoals die jij beschrijft perfect geschikt, kost alleen inderdaad wel ja, maar overkill zou ik het niet willen noemen voor een echte Enterprise omgeving, zelfs bij de wat grotere MKB's kun je er al erg veel voordeel mee hebben.

[ Voor 12% gewijzigd door Dennism op 24-04-2015 17:03 ]

[Verwijderd]

MAX3400 schreef op vrijdag 24 april 2015 @ 16:58:
[...]

Kan me voorstellen dat je niet eerst SQL-services wil stoppen terwijl een of andere "exclusive locking" CRM-applicatie nog records open denkt te hebben staan. Oftewel, eerst CRM stoppen, daarna pas SQL. Een beetje domme applicatie heeft natuurlijk geen enkele dependency met overige services op de omgeving maar is er wel 100% van afhankelijk.

Ik ben het wel met anderen eens: ga lekker aan de slag met PowerShell. Kan je ook controle houden of een service gestopt is, eventueel vragen om user-input indien niet gestopt of anders de volgende service omver schoffelen.

Bij gebrek aan informatie over wat voor servers het gaat, is het lastig om een advies te geven. Je kan namelijk ook tegenwoordig fijn PowerShellen tegen een VMware host of een XenServer Putty-connectie opzetten maar daar is veel meer voor nodig dan alleen Start -> Programs -> Powershell.exe

PS is leuk en ik ben 100% voorstander van het gebruik, maar in een ent omgeving services gaan stoppen op die manier is niet meer te doen.

Er zijn echt wel betere tools te vinden, zoals al eerder genoemd.

[MAX3400]

Verwijderd schreef op vrijdag 24 april 2015 @ 17:01:
[...]

PS is leuk en ik ben 100% voorstander van het gebruik, maar in een ent omgeving services gaan stoppen op die manier is niet meer te doen.

Er zijn echt wel betere tools te vinden, zoals al eerder genoemd.

Sorry, je weet dat bijna geheel Azure op Powershell draait? Of denk je serieus dat er een Microsoft-mannetje al jouw online input handmatig verwerkt tot VM / SQL instance / Blob?

Ik hoor graag, desnoods via DM, jouw argumenten en bronnen die aantonen dat PowerShell niet te gebruiken is voor meer dan X servers or Y users of Z sites.

[downtime]

Orchestrator is een optie maar in mijn ogen zo beperkt en omslachtig dat ik zelf net zo lief gewoon een Powershell script ervoor zou maken die je vanuit Task Scheduler aftrapt. En de Task Scheduler heeft een prima GUI

[MAX3400]

Bedenk me net dat, gezien de summiere vraagstelling en de complicaties binnen PowerShell, de topicstarter ook eens zou kunnen inlezen in DSC. Hiermee creeer je een simpeler manier van programmeren, heb je een iets centralere mogelijkheid tot management en is het mogelijk om iets uit te voeren als builtin-account.

What do I know...

[CMD-Snake]

downtime schreef op vrijdag 24 april 2015 @ 17:06:
Orchestrator is een optie maar in mijn ogen zo beperkt en omslachtig dat ik zelf net zo lief gewoon een Powershell script ervoor zou maken die je vanuit Task Scheduler aftrapt. En de Task Scheduler heeft een prima GUI

Ik werk met Orchestrator 2012R2 en moet zeggen dat ik hier niets van herken. Beperkt is het zeker niet als het aankomt op het Windows platform. Er zijn integration packs aanwezig voor alle Microsoft producten en ook nog genoeg integration packs voor pakketten van derden, denk bijvoorbeeld VMWare.

Het leren maken van goede runbooks is iets wat je even moeten oefenen en soms moet je wat creativiteit toepassen, maar als je het eenmaal in de vingers hebt werkt het goed. Maar geen van de System Center pakketten is iets wat je in een middagje meester bent.

Wat de TS wil kan je prima doen met Orchestrator. En indien TS over een goed volume licensing contract beschikt kan hij zo Orchestrator downloaden bij Microsoft. Dan kan je er even mee spelen en kijken wat het pakket kan doen.

[Remco]

Pannenkoek14 schreef op vrijdag 24 april 2015 @ 16:45:
Klopt, maar dan zal je zelf nog handmatig een service moeten stoppen wanneer er een restart nodig is.
En dit willen we juist automatiseren.
[...]

Waarom niet gewoon een batch script?
net stop servicenaam

Script schedule je dan als de server down gaat.

[MAX3400]

Remco schreef op vrijdag 24 april 2015 @ 17:33:
[...]

Waarom niet gewoon een batch script?
net stop servicenaam

Script schedule je dan als de server down gaat.

Gezien de topicstart zijn er ook services die op een bepaalde volgorde moeten opstarten. Dit ga je niet redden met batch omdat je voor de reboot eerst de services op Disabled/Manual moet zetten @ Startup.

[downtime]

MAX3400 schreef op vrijdag 24 april 2015 @ 17:38:
Dit ga je niet redden met batch omdat je voor de reboot eerst de services op Disabled/Manual moet zetten @ Startup.

Dat kan dan weer door SC vanuit die batch te gebruiken. Maar eerlijk gezegd zou ik niemand meer aanraden om iets met batch files te doen.

[Jazzy]

En zo zijn we weer terug bij PowerShell...

[technorabilia]

Ik heb zoiets gedaan met PowerShell. Relatief eenvoudig in elkaar te zetten.
Sowieso is PowerShell kennis wel goed om in te investeren mijns inziens en prima future proof.
De aanroep van de PS script kan op diverse manieren / flexibel. En zo hou je GUI en logic gescheiden.

[ Voor 7% gewijzigd door technorabilia op 24-04-2015 18:04 ]

[CMD-Snake]

Jazzy schreef op vrijdag 24 april 2015 @ 17:56:
En zo zijn we weer terug bij PowerShell...

Of Orchestrator.

Orchestrator heeft native een object om Windows services te starten/stoppen en kan ze ook aanpassen (bv opstart type veranderen). Je kan in het runbook in de goede volgorde op meerdere servers die aanpassingen doen en dit ook laten wachten tot de voorgaande wijziging in de workflow klaar is en ook geslaagd is. Orchestrator kan daarna ook de server herstarten en alles weer in de omgekeerde volgorde doen.

De Runbook Designer is ook een GUI, je hoeft in principe geen code te schrijven.

Enige nadeel, je moet een Orchestrator infrastructuur inrichten. Dat kan een horde zijn, je zal er wat tijd in moeten steken.

[Jazzy]

PowerShell is native. Orchestrator een apart product wat je moet licentieren en inderdaad inrichten. Vind het eigenlijk raar dat het überhaupt voorgesteld werd voor zo'n simpele taak.

[Killah_Priest]

Het is heel simpel : Powershell (zoals al eerder genoemd is), eventueel met een GUI erbij.
Als je als systeembeheerder anno 2015 geen PS kennis bezit dan heb je naar mijn idee het verkeerde vak gekozen.

[CMD-Snake]

Jazzy schreef op vrijdag 24 april 2015 @ 18:06:
PowerShell is native. Orchestrator een apart product wat je moet licentieren en inderdaad inrichten. Vind het eigenlijk raar dat het überhaupt voorgesteld werd voor zo'n simpele taak.

De topic start:

Pannenkoek14 schreef op vrijdag 24 april 2015 @ 15:27:
Ik ben opzoek naar een applicatie die het volgende kan:

Vanuit een GUI interface via het netwerk bepaalde windows services stoppen en in een bepaalde volgorde.

De vraag in de topic start was of er een pakket met een GUI was dat dergelijke taken kon doen. Er was ook een wens om geen PowerShell te gebruiken. Dus vandaar.

Overigens, als je Orchestrator gaat installeren moet je het echt meer gaan gebruiken vind ik. Indien je het alleen hiervoor gaat gebruiken moet je inderdaad eerder PowerShell overwegen.

[technorabilia]

Als je een GUI wilt kan dat ook vanuit PS...
http://www.drdobbs.com/wi...s-in-powershell/240049898

[MAX3400]

kraades schreef op vrijdag 24 april 2015 @ 18:18:
Als je een GUI wilt kan dat ook vanuit PS...
http://www.drdobbs.com/wi...s-in-powershell/240049898

Alles kan in een GUI. Als je maar weet hoe je iets moet programmeren, waar & hoe je de GUI aanbiedt en welke taken er moeten worden uitgevoerd.

Bij gebrek aan enige informatie over die "enterprise" omgeving, de rollen van de servers en de bijbehorende software (inclusief applicaties en OS), wordt dit topic voornamelijk prijsschieten op een ieders beste bedoelingen zonder constructieve oplossing.

[johnkeates]

Het kan ook met salt.

[Killah_Priest]

Orion zei het al : dependencies van services.

Dit kan gewoon met de MS Management Console (good old MMC).
Zolang de dependencies van de services goed ingesteld staan zou de onderste service uit de keten stoppen ook de rest moeten stoppen (dus C relied op B en B relied op A - als je A stopt zouden B en C ook moeten stoppen).
Andersom zal service C pas starten als B gestart is en B pas starten als A gestart is dus kun je ze gerust alle drie op auto zetten.

Als je dit dus goed instelt kun je met MMC (overzichtelijke GUI) service A stoppen waarna B en C ook stoppen. Na een reboot starten ze weer vanzelf.

[ Voor 6% gewijzigd door Killah_Priest op 24-04-2015 21:08 ]

[MAX3400]

johnkeates schreef op vrijdag 24 april 2015 @ 20:54:
Het kan ook met salt.

Verplicht installeren op een Linux-bak en 100% commandline-driven. Salt of Puppet zijn inderdaad ontzettend krachtige tools om een omgeving te baselinen, updaten, inrichten etc. Maar waarschijnlijk nog verder van het comfortabele huis waar de topicstarter nu in zit.

[technorabilia]

MAX3400 schreef op vrijdag 24 april 2015 @ 20:50:
[...]

Alles kan in een GUI. Als je maar weet hoe je iets moet programmeren, waar & hoe je de GUI aanbiedt en welke taken er moeten worden uitgevoerd.

Dat snap ik. Mijn punt was dat je zelfs PS niet uit hoeft.

code:

Add-Type -AssemblyName System.Windows.Forms
$form = New-Object Windows.Forms.Form
$form.Size = New-Object Drawing.Size @(200, 100)
$form.StartPosition = "CenterScreen"

$txt = New-Object System.Windows.Forms.TextBox
$txt.Location = New-Object System.Drawing.Point(10, 10)
$form.Controls.Add($txt)

$btn = New-Object System.Windows.Forms.Button
$btn.Location = New-Object System.Drawing.Point(10, 30)
$btn.add_click({Restart-Service $txt.Text})
$btn.Text = "Restart"
$form.Controls.Add($btn)

$drc = $form.ShowDialog()

function Restart-Service($service)
{
    Stop-Service -Name $service
    Start-Service -Name $service
}

[MAX3400]

kraades schreef op vrijdag 24 april 2015 @ 21:11:
[...]


Dat snap ik. Mijn punt was dat je zelfs PS niet uit hoeft.

Was ook niet mijn bedoeling om de suggestie af te vallen; de vraag is meer hoeveel GUI er nodig is, hoeveel servers er zijn (en welke verschillend moeten worden gestopt/gestart) en hoeveel tijd iemand ervoor heeft om een 100% commandline script te maken en daarna dit te combineren in 1 of meerdere windows / pop-ups / interfaces waar je lekker legacy met je muis tegen kan klikken.

Wat ik aangaf eerder; DSC lijkt me een redelijke manier om in ieder geval na een reboot de correcte services te starten. PowerShell om zaken af te sluiten alvorens een reboot. En aanverwant eraan PowerShell of WMI gebruiken om de status van services terug te melden voor de omgeving, al dan niet middels een SMTP of SMS gateway zodat je output naar een telefoon of mailbox / distributielijst kan sturen.

Ik ben weinig/geen voorstander van PowerShell als Scheduled Task; er hoeft maar 1x een credential weg te vallen of een PS-module niet te laden en je gaat voor gaas. Als het over meer dan 50 servers gaat, zou ik er al voor kiezen om een dedicated workstation/server VM in te zetten, daar je tasks/repository op te mikken en ook alleen vanaf daar het beheer te doen.

[CH4OS]

Killah_Priest schreef op vrijdag 24 april 2015 @ 18:09:
Het is heel simpel : Powershell (zoals al eerder genoemd is), eventueel met een GUI erbij.
Als je als systeembeheerder anno 2015 geen PS kennis bezit dan heb je naar mijn idee het verkeerde vak gekozen.

Offtopic, maar er is meer in de wereld van Systeembeheer dan Windows alleen.

[Killah_Priest]

CptChaos schreef op vrijdag 24 april 2015 @ 21:29:
[...]
Offtopic, maar er is meer in de wereld van Systeembeheer dan Windows alleen.

Ik doelde (aangezien dit topic Windows georiënteerd is) uiteraard op Windows systeembeheerders.
Overigens vind ik bv een linux beheerder die niet kan scripten (bestaan die überhaupt wel???) ook maar matig.

[technorabilia]

Ook offtopic:
Ik heb een behoorlijke achtergrond in Linux (incl. scripting) maar ik vind PowerShell toch wel een stuk eleganter werken mede door het object georiënteerde karakter, tooling, documentatie.

[nescafe]

Orion84 schreef op vrijdag 24 april 2015 @ 16:42:
Is dat dan niet vooral een kwestie van de dependencies in die services op orde brengen? Ik heb er niet veel verstand van, maar het lijkt me dat daarmee automatisch ook startup en shutdown volgorde correct zou moeten zijn.

TS, zou je nogmaals willen overwegen? Er worden hier 10 andere oplossingen aangedragen voor iets wat geen probleem hoeft te zijn, indien je je services op de goede wijze aan elkaar linkt (bijv. je client-applicatie afhankelijk van je DBMS).

Pannenkoek14 schreef op vrijdag 24 april 2015 @ 16:45:
Klopt, maar dan zal je zelf nog handmatig een service moeten stoppen wanneer er een restart nodig is.
En dit willen we juist automatiseren.
[...]

Microsoft heeft behoorlijk wat tijd geïnvesteerd in een goed servicemanagementsysteem, wat precies doet wat jij wilt: het automatisch starten en stoppen van services (met verscheidene time-outs) bij het afsluiten en opstarten. Enige reden om het starten/stoppen remote te automatiseren, is om meer grip te krijgen op de runtime van services, juist buiten de life-cycle van het OS.

[johnkeates]

MAX3400 schreef op vrijdag 24 april 2015 @ 21:09:
[...]

Verplicht installeren op een Linux-bak en 100% commandline-driven. Salt of Puppet zijn inderdaad ontzettend krachtige tools om een omgeving te baselinen, updaten, inrichten etc. Maar waarschijnlijk nog verder van het comfortabele huis waar de topicstarter nu in zit.

Nee hoor, kan ook gewoon op Windows. Sure, commandline driven als je iets wil uitvoeren, maar qua configuratie is het gewoon YAML. Als je je reactors opgezet hebt en je configuratie niet meer verandert hoef je nooit meer een tekst-edit of CLI commando te gebruiken. Maar ik kan inderdaad wel begrijpen dat een knopjesklikker geen tekst wil/kan/mag gebruiken. Het is gewoon een van de vele oplossingen

Killah_Priest schreef op vrijdag 24 april 2015 @ 21:06:
Orion zei het al : dependencies van services.

Dit kan gewoon met de MS Management Console (good old MMC).
Zolang de dependencies van de services goed ingesteld staan zou de onderste service uit de keten stoppen ook de rest moeten stoppen (dus C relied op B en B relied op A - als je A stopt zouden B en C ook moeten stoppen).
Andersom zal service C pas starten als B gestart is en B pas starten als A gestart is dus kun je ze gerust alle drie op auto zetten.

Als je dit dus goed instelt kun je met MMC (overzichtelijke GUI) service A stoppen waarna B en C ook stoppen. Na een reboot starten ze weer vanzelf.

Dit is dan ook de minst-invasieve GUI-based methode voor de TS. Ik denk dat als zelfs dit niet lukt het misschien een kwestie van opgeven wordt

CptChaos schreef op vrijdag 24 april 2015 @ 21:29:
[...]
Offtopic, maar er is meer in de wereld van Systeembeheer dan Windows alleen.

Precies! Natuurlijk kan je als systeembeheerder 'liever' met een 'windows gui' werken, maar er zijn zo veel overkoepelende concepten binnen systeembeheer die nou eenmaal buiten de GUI van Windows vallen dat je jezelf behoorlijk slecht in de markt zet als je je daar zo ver mogelijk vandaan probeert te houden. Als je de concepten van een CLI kan leren kan je die overal gebruiken. Microsoft gaat steeds verder richting CLI voor praktische besturing van services, sure, je hebt nog steeds wel veel GUI opties, maar dat betekent niet dat dat meteen de beste keuze is, en zeker niet voor alle gevallen.

kraades schreef op vrijdag 24 april 2015 @ 22:01:
Ook offtopic:
Ik heb een behoorlijke achtergrond in Linux (incl. scripting) maar ik vind PowerShell toch wel een stuk eleganter werken mede door het object georiënteerde karakter, tooling, documentatie.

Je zou verwachten dat je dan ook wel weet dat er niet 'een Linux shell' is? Je komt waarschijnlijk bash veel tegen, maar je kan bij Linux ook prima zonder Bash, en het is lang niet overal default. Bij Windows heb je een command.com emulator (cmd.exe) en That't It. PS is geen echte systeemshell, maar een zelfstandige shell. Net als dat je bijv. KDE op Windows zou kunnen draaien als grafische shell. Of Bash op Windows zou kunnen draaien als zelfstandige shell.

Als je op Linux en Unix (en Unix-achtigen) graag Powershellerig wil doen kan dat ook prima hoor Er zijn ten eerst diverse OO-shells, en ten tweede ook gewoon PowerShell-on-Linux opties. Er is ook een middenweg waarbij je met WS-MAN Powershell integratie van Windows naar Linux (en Unix en BSD en z/OS enz.) kan krijgen door OMI en DSC op Linux te installeren. De meest directie optie voor PS-on-Linux is denk ik Pash. Pash is precies wat het moet zijn PowerShell-met-Bash. Of eigenlijk Posh met Powershell. Posh is een re-implementatie van Bash. Kan je dus alle Bash dingen blijven gebruiken waar nodig, en Powershell waar je er maar zin in hebt. En met microsoft's aanwijzingen op TechNet kan je dus ook PowerShellen tussen Windows en non-Windows (zolang GNU's libc op het platform kan draaien).


Edit: het ging een beetje OT, maar de strekking van mijn lap tekst is ongeveer wat nescafe boven hij postte. Gebruik wat er is, wil je wat anders, doe jezelf en je CV een plezier, en leer CLI concepten.

[ Voor 3% gewijzigd door johnkeates op 25-04-2015 01:27 ]

[technorabilia]

johnkeates schreef op zaterdag 25 april 2015 @ 01:12:
Je zou verwachten dat je dan ook wel weet dat er niet 'een Linux shell' is? Je komt waarschijnlijk bash veel tegen, maar je kan bij Linux ook prima zonder Bash, en het is lang niet overal default. Bij Windows heb je een command.com emulator (cmd.exe) en That't It. PS is geen echte systeemshell, maar een zelfstandige shell. Net als dat je bijv. KDE op Windows zou kunnen draaien als grafische shell. Of Bash op Windows zou kunnen draaien als zelfstandige shell.

Als je op Linux en Unix (en Unix-achtigen) graag Powershellerig wil doen kan dat ook prima hoor Er zijn ten eerst diverse OO-shells, en ten tweede ook gewoon PowerShell-on-Linux opties. Er is ook een middenweg waarbij je met WS-MAN Powershell integratie van Windows naar Linux (en Unix en BSD en z/OS enz.) kan krijgen door OMI en DSC op Linux te installeren. De meest directie optie voor PS-on-Linux is denk ik Pash. Pash is precies wat het moet zijn PowerShell-met-Bash. Of eigenlijk Posh met Powershell. Posh is een re-implementatie van Bash. Kan je dus alle Bash dingen blijven gebruiken waar nodig, en Powershell waar je er maar zin in hebt. En met microsoft's aanwijzingen op TechNet kan je dus ook PowerShellen tussen Windows en non-Windows (zolang GNU's libc op het platform kan draaien).

Mijn advies aan de TS is: kies iets gangsbaars dat een ander ook snapt en onderhoudbaar is en bij voorkeur "onderdeel" is van het OS installatie. Wat ik tegenkom op Linux is bash, sh en soms nog ksh of ash/csh. Posh/pash/mono toepassingen nergens. Op Windows zie ik Powershell en batch.

[Killah_Priest]

kraades schreef op zaterdag 25 april 2015 @ 09:28:
[...]


Mijn advies aan de TS is: kies iets gangsbaars dat een ander ook snapt en onderhoudbaar is en bij voorkeur "onderdeel" is van het OS installatie. Wat ik tegenkom op Linux is bash, sh en soms nog ksh of ash/csh. Posh/pash/mono toepassingen nergens. Op Windows zie ik Powershell en batch.

Batch dien je op Windows eigenlijk niet meer te gebruiken ; vbscript is nog een beter alternatief.
Momenteel is het op Windows vanaf Server2008R2 / Windows 7 gewoon Powershell (en vanaf 2012/Windows 8 met Powershell 3 helemaal PS).

Het is niet voor niets zo dat MS alle GUI based tools tegenwoordig op PS baseren ; alle nieuwe relevante dingen voeren op de achtergrond PS code uit (bij Exchange 2007 en hoger is dit al heel erg duidelijk zichtbaar omdat je van zaken welke je vanuit de GUI doet je de powershell code ziet die het uitvoert).
Idem bij de Server manager in 2012 : het is allemaal PS code welke uitgevoerd wordt.

Door PS ben ik mij ook veel meer bezig gaan houden met C# ; mede omdat ik merkte dat ik in PS scripts steeds vaker rechstreeks .NET libraries begon aan te spreken (System.Timers is daar een goed voorbeeld van : new-object System.Timers.Timer om een nieuw timer object te maken voor in mijn scripts). De flexibilieit van PS is enorm : in ieder geval is het dusdanig groot dat je gewoon een enorm verschil merkt tussen Windows beheerders welke WEL PS kennis bezitten en de beheerders welke geen PS kennis bezitten. Bij mij op de afdeling (en bij klanten) zie ik dit verschil ook steeds vaker.
Je kunt gewoon efficienter werken ; omdat ik minder tijd kwijt ben aan bepaalde zaken (welke ik deels geautomatiseerd heb) hou ik een stuk meer tijd over om mij bezig te houden met andere belangrijke zaken.