Microsoft stelt eerste versie shellomgeving beschikbaar

Microsoft is een bètatest begonnen voor de Microsoft Shell (MSH), het product dat op termijn de command shell in Windows moet gaan vervangen. MSH zal echter qua features en mogelijkheden een rijker programma zijn dan het huidige cmd.exe en zal daardoor nadrukkelijker als tegenhanger van Bash en andere *nix-shells gepositioneerd worden. Zo zal het via MSH mogelijk worden om een netwerk of Windows-computer volledig te beheren, zonder dat er gebruikgemaakt hoeft te worden van grafische tools. MSH zal de basis vormen voor de beheersfuncties in Exchange 12, dat gepland staat voor release in de tweede helft van 2006. De GUI in Exchange 12 zal niet meer zijn dan een grafische schil voor een groot aantal MSH-scripts. Verwacht wordt dat meer Microsoft Management Console-plugins omgebouwd zullen worden om in de achtergrond gebruik te maken van MSH-scripts.

De verwachting is dat MSH niet aanwezig zal zijn in de clientversie van Windows Longhorn, die gepland staat voor het einde van 2006. Mogelijk dat Microsoft Shell, codenaam Monad, wel in de serverversie van Longhorn zal zitten; deze versie zal waarschijnlijk in 2007 op de markt komen. Microsofts MSH-medewerkers hebben namelijk laten weten dat MSH niet gebonden is aan releaseschema's van Windows-producten. De nu vrijgegeven versie van MSH kan gebruikt worden op Windows XP en Windows Server 2003. De testversie van Microsoft Shell is beschikbaar op de Microsoft Beta-site, alwaar ingelogd kan worden met het guest ID 'mshPDC'. Na enkele dagen krijgen testers de mogelijkheid om het .NET Framework 2.0 en de MSH Preview-versie te downloaden. In de Channel9 Wiki is meer informatie te vinden over de syntax, functies en features van MSH.

Reacties (56)

Ben ik het niet mee eens, juist door die wizzard aanpak is/lijkt het beheer van een windows server zoveel gemakkelijker. Hoeveel startende beheerders ik niet heb horen zuchten als ze voor het eerst achter een *nix machine moeten gaan zitten. Nu heb je juist het gemak van eenvoud, en als de beheerder (ster) er aan toe is, en iets complexers wil dan kan dat ook.

Neemt natuurlijk niet weg dat het eigelijk wel eerder gemaakt had mogen worden..

IMHO is er niet zoiets als een 'startende beheerder'. Je wordt niet zomaar systeembeheerder door een cursusje MCSE, net zomin je timmerman wordt door een cursus 'kruiskopschroeven en hun schroevendraaiers'.

Dit lijkt mij juist in de praktijk een van de grote problemen met MS-only systeembeheerders: ze weten te weinig van systeembeheer en problemen oplossen. *nix systeembeheerders zijn (juist vanwege ksh, csh, bash, etc) af en toe halve programmeurs die veel beter in staat zijn te analyseren en taakgericht problemen op te lossen.

Je wordt ook niet zomaar ff een goede beheerder door het OS wat je kiest. Het is niet zo dat een *nix beheerder een halve programmeur is, per definitie. Net zoals het niet zo is dat een MS beheerder alleen kan klikken.

Tenslotte, een halve programmeur werkt tegen dat soort mensen: ik heb brouwsels in bash gezien waar de honden geen brood van lusten, en wat een fatsoenlijke (Perl) programmeur beter, in minder tijd etc had kunnen maken.

Wat wel meehelpt is als je een OS gebruikt wat je forceert dieper in de materie in te gaan.

Waar je bij windows een programma aangeeft die gefirewalled moet worden (geen idee wat er dan gebeurt) moet je bij linux de poorten gaan analyseren en per protocol een keten van acties opgeven. Hierdoor snap je veel meer van de werking van een firewall.

Hetzelfde voor een (P)DC. Onder windows ken je een rol PDC toe, je geeft gebruikers op, je zit naar een lullige animatie te kijken van een boekje dat vol wordt geschreven (hoe kun je jezelf dan nog serieus nemen) en klaar. Wat is er nu gebeurd? Geen idee.

Als je hetzelfde wilt doen onder linux; een samba 3 server icm een LDAP user database, je snapt gelijk wat er gebeurt. Je snapt welk proces wel doel serveert en je snapt ook hoe het geheel in z'n werk gaat. Je kan op deze manier dus op bepaalde situaties anticiperen. (trouwens, wat windows gebruikt is ook gewoon LDAP, hoor. Ze geven er alleen een hele moeilijke naam aan.).

Exchange server. Nog zo'n ramp.
Klik klik en er gebeurt iets met mail. Ik heb een paar adresjes opgegeven en de mail gaat goed. Ik weet alleen niet wat er nu eigenlijk echt gebeurt.
Onder linux: weer LDAP (adresboek) + calenderd (speciale daemon voor de outlook kalender) + Fetchmail/IMAP, je snapt wat er met je email gebeurt. Leuker nog, je snapt ook gelijk de koppeling tussen gebruikers en adresboek (allebei ldap).

Iemand die windows gebruikt voor systeembeheer en NIET snapt wat er gebeurt, vindt ik geen systeembeheerder. Dat is een windows gebruiker.
(Let dus even wel op: dit is dus GEEN kritiek op mensen die wel weten wat er onder de motorkap gebeurt. Die weten waar ze over praten.)

Bovenstaande tekst is een mening, dus geen reden tot flame.

-R-

Ik hoor juist vaak op linux forums die ik vaak bezoek dat het installeren en draaien van een grafische omgeving (zoals de X server in *NIX systemen) op servers een onnodige verspilling is van "resources". Dat soort uitspraken wordt wel vaak voorafgegaan door de uitdrukking "IMHO", maar toch.

Het spijt me dit te moeten zeggen, maar het beheren van computers/computernetwerken (en alles wat je je er maar bij bedenken kunt) is meer dan zomaar een wizzard afwerken door op volgende te klikken, EULA "accepteren" (heb je de EULA überhaubt ooit wel eens gelezen!?), nog 3x op volgende te klikken, en op sluiten klikken. Het nadeel van wizzards (vind ik dan) dat je er veel te makkelijk doorheen rost. Geef mij liever een prompt waar ik allerhande parameters moet invullen omdat het proggeltje anders gewoon niet geinstalleerd wordt. Dat houdt mij scherp omdat ik veel bewuster voor bepaalde moet zaken kiezen. Dit geeft vaak weer een voorsprong bij het traceren en analyseren van problemen.

Wat dat betreft ben ik het met LeoMekenkamp eens dat veel (???) beheerders te weinig weten van problemen oplossen. (en dan met name het analyseren van de problemen) En volgens mij is dat vaak toch weer terug te leiden naar het verminderde bewustzijn bij installaties van proggels of (zelfs) OS.

Verder vind ik het erg jammer dat configuraties meestal niet aan te passen zijn in een gewoon tekstbestandje. (hoewel een centraal register ook wel een paar voordelen heeft)

De muis gebruik ik eigenlijk vrij weinig. Eigenlijk vrijwel alleen voor programma's die gewoon niet te besturen zijn vanaf het toetsenbord. Voor de rest gebruik ik het toetsenbord erg veel. Als je de juiste sneltoetsen weet, kun je eigenlijk vrijwel alles wat ook met de muis kan, en vaak ook nog veel sneller. Om het zaakje dan helemaal compleet te maken, bestaan er ook unixutils die geport zijn naar Win32. Het voordeel hiervan is dat je geen emulator nodig hebt, zoals cygwin, maar heel eenvoudig wat basic utils als grep e.d. gebruiken kan.

Al met al kan ik deze zet toejuichen. Nog even en ik hoef geen muis meer aan te sluiten aan m'n PC'tje

klinkt goed, heb al meer dan eens me afgevraagd of ik niet gewoon zaken kon intikken ipv klikken overal. maakt het beheer van windows machines absoluut makkelijker voor de gevorderde beheerder IMHO.

Een gevorderde beheerder weet ook wel waar hij moet klikken, dus dat maakt niets uit.

voor het echte beheer had je per product ook resourcekit uitility's waarin de echte beheerder ook niet meer hoefde te klikken. Zo kun je b.v. via "Adduser.exe" al hele grote hoeveelheden gebruikers aanmaken. Met Xacls.exe rechten op directory's laten aanmaken e.d. zonder te klikken.

Zo nieuw is dit verhaal dus niet alleen dan dat dit min of meer gestandaardiseerd gaat worden voor de andere MS server software e.d.

Geen "awk" maar wel "grep" bijvoorbeeld:
http://www.tburke.net/info/reskittools/topics/posix.htm

En de license waaronder dat valt is wellicht geinig (gezien de recente uitspraken van oa de heer Balmer):

"The files for the POSIX Utilities are the only files in the Windows 2000 Resource Kits covered by the GNU Library General Public License. "

Verder zit bv "perl" ook in de resource kit, alleen draait dat onder het Win32 subsysteem:
http://www.tburke.net/info/reskittools/topics/azlist.htm

Inderdaad niet nieuw. Wel nieuw is de uitgebreide scripttaal die je wordt geboden.

Geef toe, de scripting mogelijkheden in cmd.exe zijn minimaal en vb-script is overkill op een commandline. Het gaat er juist om dat de beheerder eenvoudig zelf nieuwe oplossingen cq commando's kan schrijven. Juist dat maakt een uitgebreide scripttaal in een shell zo handig. Het maakt een OS flexibel, iets wat Microsoft altijd gemist heeft.

Ik vind de scripttaal er echter minder elegant uitzien dan bijvoorbeeld bash of ksh.

Nu nog wat GNU tools als sed, awk, grep en dergelijken erbij en Windows is bijna compleet.

@TheAnimaL
install cygwin...dan heb je al die leuke speeltjes

Van een aardig lijstje Gnu utilitys is ook een Win32 port:
http://unxutils.sourceforge.net/

CygWin levert je een bash shell, maar da's volstrekt nutteloos voor beheer taken. Je zou cygwin eerst op alle systemen moeten installeren (en onderhouden...)

De nieuwigheid is dat je toegang hebt tot beheersfuncties vanuit een script taal in plaats van een GUI of een "echt" programma. Veel van die CLI functies zitten nu verstopt en zijn slecht gedocumenteerd of onderhouden (zoals de vele NET commando's).

Shellscripts zijn onder Windows (en DOS ook) nooit een success geworden omdat het schrijven van een executable (in C, pascal, whatever) meestal eenvoudiger is.

Als ik bijvoorbeeld de rechten op een berg files moet aanpassen, of iets van dien aard, dan grijp ik altijd naar Delphi of Visual.

Dat tikken kun je automatiseren en in 1 keer op 100 servers doen, probeer dat eens met klikken

Dat is een onzinargument, want zaken remote of geautomatiseerd doen kan net zo makkelijk met een GUI, het hangt puur af van de mogelijkheden van de software in kwestie, niet van de gebruikersinterface die erop zit.

Kijk eens in dit topic:
http://gathering.tweakers.net/forum/list_messages/1045891/
en vraag je eens af hoe makkelijk je dit met "klikken" had kunnen doen.

het hangt puur af van de mogelijkheden van de software in kwestie

Daar zit het hem nu juist, als je met shell scripts die afhankelijkheid kan wegnemen, dan kan een sysadmin makkelijk zelf vlug stukken automatiseren zonder dat het expliciet in zijn software pakket moet zitten.
Eens je scripts gewoon bent wil je zeker niet meer terug naar een GUI, want deze is echt lomp en tijdrovend tov. een goed geschreven script. Buiten sysadmins is het bij ontwikkeling van software ook bijzonder handig, de oude command prompt is echt een piece of sh*t als je daar eens deftig in moet werken!

Eens je scripts gewoon bent wil je zeker niet meer terug naar een GUI, want deze is echt lomp en tijdrovend tov. een goed geschreven script.

Dat heeft dus puur met de scripting omgeving te maken en niet met zogenaamde fundamentele verschillen tussen commandline tools, scripting omgevingen en grafische user interfaces.

@JeroenB

Vanuit het perspectief van een GUI gebruikende onwikkelaar en/of beheerder (behalve FVWM gebruikers lijkt me) heeft u waarschijnlijk gelijk, hoewel die veelal ook niet al te blij zullen worden van het _nog_ een omgeving - taal, API, etc - te moeten leren.

Echter vanuit het perspectief van een CLI gebuikende beheerder en/of ondwikkelaar heeft u dat waarschijnlijk niet. Zij tiepen namelijk dagenlijks al (shell) commandos. Waardoor een script "schrijven" meer iets is van "commandos op een rijtje zetten" voor hen... In het geval van niet-interactive batches - zoals "cron" of "at" taken - hoeven ze alleen wat checks toe te voegen. (Mischien dat het resultaat nog naar een log geschreven moet, er ergens op gewacht moet worden, ofzo. indien iets niet lukt, nog eens te probeeren, of opgeven - met een hoop herrie, dat soort dingen.)

Inderdaad. Ik ben zo'n beheerder die de hele dag zit te typen. (Ik draai welliswaar een XFCE omgeving, maar toch altijd een terminal).
Ik zou er niet aan moeten denken dat ik allemaal zou moeten klikken. Wachten tot eindelijk dat menutje eens geopend is, of dat eindelijk het schermpje eens is getekend. Lekker werken vanaf een linux bak met trusted SSH relaties met alle servers, er is niets snellers dan dat. En scripting is niets anders dan het opgeven van wat commando's met wat kale taal elementen als IF constructies.

Ik heb van nood een tijdje een win2003 bak moeten gebruiken. Vreselijk. Als je al die tijd CLI gewend bent, snap je echt he-le-maal niets van een gui.

Ben benieuwd wat de mogelijkheden van dat MSH zullen zijn, niet dat ik het ooit ga gebruiken, want tenslotte is windows niet meer dan een leuk werkstationnetje. (wahaa... die laatste zin is laaaaag ;p)

edit:

Microsoft hamert er nu trouwens op dat unix een te steile leercurve heeft t.o.v. windows. Maar stijgt de leercurve door dit geintje ook niet enorm en is linux daardoor niet weer een goedkopere oplossing?
In beide gevallen moet je ermee om leren gaan, dus waarom niet gelijk kiezen voor linux?

-R-

't Hangt er vanaf of je van muizen houdt hee Maar volgens mij kun je nog altijd macro opnames maken met speciale software , dus dat je met klikken niets kunt automatiseren is ook niet waar...

Toch kon je al erg veel via de command-prompt verrichten, al vanaf NT4. Services starten/stoppen via net.exe, NTFS-ACL permissions veranderen via cacls.exe, en zo zijn er nog meer talloze commandline tools beschikbaar die ik al jaren gebruik voor veel voorkomende taken. Er is bijna geen één GUI taak die je niet via de commandline ook kan verrichten, al zijn voor sommige taken wel SDK of 3rd party tools nodig.

Eerst via simpele .bat batch bestanden, toen kwam de Windows Scripting shell optie via .vbs bestanden en nu dus MHS met nog meer geavanceerde opties.

Het zal dus steeds gemakkelijker worden voor de geavanceerde admin, maar een hoop was dus al wel mogelijk. Dit zal dus wel zo'n project zijn dat zich snel zal moeten bewijzen of Microsoft nu goed over security heeft nagedacht, want anders krijgen virussen er natuurlijk weer een gemakkelijke optie bij om ons leven zuur te maken.

ik moet geen externe pc overnemen via command line, ik wil mijn localhost in command line besturen, zonder daar iets van vensters te zien, het grootste probleem aan windows is dat als je windows crashed je het niet in command line kan booten voor terug te repareren, tenzij je de cd er bij haalt.

en ja je kan via f8 command line booten, maar kijk een goed rond, je hebt gewoon een windows open staan en cmd als app uitgevoerd.

So? Dat windows nou toevallig net altijd grafisch is maakt toch geen ruk uit? Of is het daarom een nep command line?

Vanaf XP/w2k3 kan dat wel. Alleen dan via de serial-console (te benaderen over een null-modem kabel naar een andere machine, of terminal-server.)
http://home.earthlink.net/~rlively/MANUALS/COMMANDS/B/BOOTCFGE.HTM

Wat t.o.v. "echte" server systeemen (nog) mist is zoiets als "klogd" wat belanrijke messages naar de console stuurt. Kunnen dan weer opgevangen door Conserver die weer een Dnotify scriptje trickered, bv.

MS-Windows NT kan wel geheugendumps voor debuging over de seriele poort stuuren, maar daar heeft niemand (behalven beta testers en M$ medewerkers wellicht) wat aan.

Op oudere (voor XP zegmaar) versies van NT kun je "agetty" onder Cygwin draaien voor out-of-band "console" toegang maar dat start dan pas weer later in de bootstrap procedures, en je hebt nogsteeds belanrijke "eventlog" zooi niet ... maar zoiets:
http://wand.net.nz/~bcj3/log/index.php?p=136

De 9x versies van MS-Windows hebben geen serial-console mogenlijkheid behalve dat de MS-DOS command.com "device com1:" (ofzo) list, zover ik weet.

En dan nog een SSH server erbij en die Telnet server eruit gooien, en alles is compleet.

Nog wel even snel de naam van Lonhorn naar Xenix veranderen voordat het gedrukte de deur uit gaat...

Winnix dan...

Gepost door mxcreep:

> Winnix dan...

Eh, nee:
http://en.wikipedia.org/wiki/Xenix

Die naam (een zamenvoeging van "xenophobia" en Unix) past(e) goed:
http://thesaurus.reference.com/search?q=xenophobia
http://dictionary.reference.com/search?q=Unix

(Waarschijnlijk is de Xenix naam momenteel bij SCO in de uitverkoop ... )

Tja, met vb script kan je ook al een heleboel doen hoor. Zeker in omgevingen waar je een paar honderd servers hebt draaien. En deze shell hadden ze jaren geleden verder moeten ontwikkelen.

hmmm, denk dat de IT industrie er ondertussen al wel uit is dat investeren & doorontwikkelen van VB based toepassingen gelijk staat aan geld in een bodemloze put gooien.

Het mooie van die shell is dat je gewoon rechtstreeks kunt communiceren met .NET objecten die je maakt. Dat geeft wel krachtige mogelijkheden. De interface met MMC is natuurlijk ook mooi om geautomatiseerde taken uit te voeren (bijvoorbeeld in login scripts)

Je mist vanuit het huidige systeem alleen de communicatie met bijvoorbeeld het .NET platform. De loginscripts zijn allang super handig te beheren, het ligt dan wel even aan je eigen kennis van DOS icm AD+GPO's.

Opzich mis ik nou nog niets binnen Windows, zeker niet kwa scripting. Ik krijg tot nu toe alles voor elkaar met batch en VB scripts. Als het daarmee echt niet lukt dan kan je ook nog gebruik maken van PHP. Dat werkt ook perfect, dus wat dat betreft

Vanuit een batch:
php.exe loginscript.php

En je kan veel meer doen (ook icm exec enzo) dan je via DOS kan doen. Dit gebruik ik zelf alleen om een MySQL db te updaten @ login en een plaatje te genereren in de plattegrond.

Ik wil geen flame windows vs linux starten.... Maarre dit heeft ms toch slim afgekeken van de llinux/unix systemen..

Ik snap alleen niet waarom ze het niet tzt voor alle windows versies uitgeven...

...toch slim afgekeken van de llinux/unix systemen..

Ook van python, zo lijkt me na het bestuderen van de syntax, die leek er vaag wel een beetje op (veel programmeertalen zullen er trouwens op lijken, maar python ken ik toevallig).
In de syntax zat echter wel een hoop zooi die je niet in standaard-bash hebt geloof ik, vandaar ook de vergelijking met python.
Na .NET weer een nieuwe taal die de MS-lui moeten leren. Benieuwd wat die er van vinden.

zo lijkt me na het bestuderen van de syntax, die leek er vaag wel een beetje op

Qua syntax lijken bijna alle programeertalen op de twee belangrijkste basis talen, te weten C en Basic.

C heeft vergelijkbare syntax met: C++, C#.NET, PHP, Java, JavaScript, JScript, etc.

Basic met: Quick Basic, GWBasic, Visual Basic, VB.NET, etc.

Er zijn andere basis talen, maar C en Basic zijn de meest bekenste.

Python is echter zo'n moderne taal, die er een beetje tussenligt. Bijvoorbeeld de If..Then..Else syntax is bijna een combinatie van C en Basic.

C = if (a && b || c) {...;} else {....;}
Basic = If (a AND b OR c) Then .... Else ... End If
Python = if (a and b or c): .... else: ...

Als programmeur in vele talen, wordt je er soms niet blij van, vele syntaxen lijken veel op elkaar, maar net met dat kleine verschil. Ik heb dus vaak dat als ik veel VB.NET code hebt gedaan en dan een javascript of C#.NET project moet doen, dat je wel eens een ; vergeet, of een AND gebruikt i.p.v. &&, en soms staar je jezelf dan wel eens blind als de compiler een fout aangeeft.

Omdat het anders geen zin heeft om een nieuwe versie van Windows te kopen. Het lijkt me dat een commercieel bedrijf toch streeft naar zo veel mogelijk verkopen en als je nieuwe features in oude produkten gaat bouwen, koopt niemand de nieuwe.

Als ze dat niet doen misschien ook niet meer

ik denk juist dat het hierdoor ook eigenlijk komt
een tijdje terug was er een post over MS plannen had om cluster-software uit te brengen. dit via GUI zou zware overkill zijn maar als je via de shell meer kan misschien zelfs volleidg shell based een cluster client kan bouwen maakt het wel weer interessanter om MS software te gebruiken.
echter loopt MS niet achter de feiten aan.. eens waren ze trend zetters met leuke GUI's/tools enz. maar nu... tabs komen later, shells komen later, nieuwere gui's (zie longhorn) komen later, search engine komt later.. zo'n beetje alles is nu een aftreksel van. juist door MS's overmacht kunnen ze dit presteren maar ik ben benieuwd of MS dit ook op de lange termijn nog kan proberen

Tjah het lijkt me toch een beetje lastig om het grootste bedrijf ter wereld (op soms GE na en Cisco doet het ook niet slecht) niet serieus te nemen.

Misschien is dan de vraag of je iemand wel serieus kunt nemen, maar ik kan je vertellen: Alles bij Microsoft is serieus.

Bij een dermate groot bedrijf heb je altijd mensen die hun acties dom vinden en mensen die hun acties goed vinden. Het enige wat Microsoft hoeft te doen is zorgen dat het deel wat de acties goed vind groter is als het deel wat de acties dom vind, dan maken zij namelijk winst.

Microsoft hangt voor een groot deel in elkaar met marketing, als ze dus jaren iets roepen en vervolgens iets anders uitbrengen zal de marketing daar zeker ook wel op aangepast worden.

Daarnaast als Microsoft als company vind dat shell interfaces achterhaald zijn maar er is toch vraag vanuit de klanten dan zullen ze het zeker wel gaan leveren. Zo werken alle bedrijven namelijk.

Het is niet zo vreemd om een bedrijf dat kennelijk bereid is zijn positie ten opzichte van bepaalde standpunten te wijzigen indien daar voldoende aanleiding toe is, serieus te nemen. Zeker als de omgevingsvariabelen veranderen is het wel fijn om te weten dat een bedrijf daar kennelijk ruimte voor heeft.

Een beetje verwarende naam 'shell':

Eerst had je DOS, en daarvoor kwamen een aantal 'shells' met grafische weergave zoals Windows, DOSShell en QuickMenu, en nu iedereen een grafische shell gebruikt gaan ze de term 'shell' voor een command line extensie gebruiken?

Op de Microsoft-pagina staat:
MSH – Microsoft Shell

Juist dáárdoor bedacht ik me dat je het ook als Microsoft Hell kan omzetten

Nee, dat kan niet, die naam was al bezet voor de rest van het OS.