Kale bèta Windows Longhorn Server vrijgegeven

Naast de bètaversie van Windows Vista is Microsoft afgelopen week ook begonnen met het vrijgeven van de bètaversie van Windows Longhorn Server. Deze testversie is verkrijgbaar in twee smaken, eentje met en eentje zonder grafische user interface (GUI). Als er gekozen wordt voor installatie zonder GUI zal het besturingssysteem via een commandprompt bediend moeten worden. Deze specifieke bètaversie van Longhorn Server bevat alle Core-functionaliteit om de meest voorkomende servertaken af te handelen, zoals het opzetten van een Active Directory of een DHCP-, file- of DNS-server. Deze kale Windows neemt slechts 500MB aan ruimte in na installatie en kan beheerd worden via de Microsoft Management Console of een Terminal Server-verbinding. Het upgraden van Longhorn Server Core naar de volledige versie is niet mogelijk, daarvoor is een herinstallatie nodig.

De volledige versie van Windows Longhorn Server, dat mogelijk Windows Server 2007 gaat heten, zal beschikken over een grafische user interface en de Server Core-functionaliteit, maar daarnaast ook over heel wat extra's. Door middel van een gewijzigd cachingsysteem, Offline Files genaamd, zullen eindgebruikers kunnen werken met bestanden op de server, ook als er geen verbinding is met de server. Verder zal het synchroniseren eenvoudiger en intelligenter zijn. Ook is Network Access Protection geïntegreerd, waarmee systeembeheerders via policy's bepaalde veiligheidsmaatregels kunnen afdwingen op computers die het netwerk binnenkomen. Daarnaast is support voor het Online Certificate Status-protocol toegevoegd en is het mogelijk gemaakt de internettoegang voor terminalservers via een firewall te laten lopen door middel van de installatie van TS Proxy.

Reacties (113)

[Scorpio9a]

Longhorn Server Core is een aparte ISO, die is namelijk maar 391MB in vergelijking met 2.39GB Longhorn Server Standard Edition, dus je kan niet tussen de twee kiezen op 1 disc.

De Core versie heeft maar heel weinig programma's, zelfs taskmgr of tasklist bestaat niet in deze versie.

Voor de gene die willen zien hoe Longhorn Server er uit ziet heb ik een paar screenshots gemaakt:

Windows Server Longhorn Core:
http://www.understorm.net/dump/longhorn/srvcore.gif

Windows Server Longhorn Standard Edition:
http://www.understorm.net/dump/longhorn/welcome.gif
http://www.understorm.net/dump/longhorn/ctrlaltdel.gif
http://www.understorm.net/dump/longhorn/srv_login.gif
http://www.understorm.net/dump/longhorn/srv_login2.gif
http://www.understorm.net/dump/longhorn/explorer.gif

Edit: @jazzy nu ook eentje van core, valt niet echt veel te zien.

[Jazzy]

Voor de gene die willen zien hoe Longhorn Server er uit ziet heb ik een paar screenshots gemaakt:

Maar dat is dus niet de Core editie waar het hier over gaat. Even voor de duidelijkheid.

[Scorpio9a]

Eerste screenshot is toch echt wel de Core editie.

[REAVER330]

Nice screenprints, wel weer heel anders dan bij de Vista

[SunnieNL]

valt mee.. de eerste alpha's van vista zagen er ook zo uit

[Anoniem: 92711]

Waarom zet je nou net je pijltje op het eerste nummer van de versie...

[Scorpio9a]

Speciaal voor jou gefixed

[Anoniem: 136952]

http://www.understorm.net/dump/longhorn/explorer.gif

Wat doet Internet Explorer daar? Wat moet je met een browser op een server?

[Anoniem: 5422]

Windows update vlak na installatie? HTTP interface van een bepaalde applicatie? Wat maakt het trouwens uit? Als je hem niet gebruikt is het toch goed?

[MetalfanBlackness]

Updates downloaden? Eerste keer is het nooit goed dus

[jiriw]

Windows Server Longhorn Core:
http://www.understorm.net/dump/longhorn/srvcore.gif

Eeek ik zie een GUI!! Leren ze het dan echt nooit af bij Microsoft?

<reactie op mjtdevries> Ik gebruik gewoon alt-1/2/3/4/etc om te switchen tussen mijn consoles. En die zijn allemaal in tekstmodus. Komt geen X of andere GUI aan te pas. En zeker niet in grafische modus. Gaat allemaal prima in 80x25. dus ik weet niet waarover je het hebt. Memoryprint van een kaal OS waarop alles vanaf de command prompt aan te roepen is: < 16 MB. Daar kan Windows echt niet tegenop.
Als je een console via XTerm bedoelt .... oke... Maar je HOEFT niet op die manier een console open te hebben... Zelfs remote (XDM) niet. Een SSH shelletje is voldoende, of als je niet zo inzit over security ken je het met telnet of rlogin al af... En dan kan je werkelijk alles hoor. Ik ben nog geen nuttig *nix server onderdeel tegengekomen waarvoor je absoluut een X-window nodig hebt...</reactie>

[mjtdevries]

Een GUI met daarin venstertjes met command prompts.
Precies wat je ook altijd bij al die Linux fanaten ziet. Die zaten er altijd over te zeuren, dus daar zullen ze het wel vanaf gekeken hebben.....

[Ghost(NL)]

Waar ik benieuwd naar ben is tot hoever de GUI support er uit is gesloopt ? Het is algemeen bekend dat Windows onderhuids om de GUI is heengebouwd, dwz alles hangt aan elkaar, bijv. het printsysteem is niks anders dan de GUI met andere output. Hoe hebben ze dit opgelost, of geven ze gewoon simpelweg geen beeld om het even simpel te stellen.

[Anoniem: 76842]

voor de ouder windows versie is Ghostriders verhaal waar maar voor de nieuwere windows versies klopt dit niet meer.... WinXP biedt al expliciet de mogelijkheid om de GUI te vervangen door een andere..cmd.exe is dus ook hier al een optie... kijk maar eens in gpedit.msc

ik gebruik zelf al ruim 2 jaar BB4WIN ipv explorer.exe als GUI op WinXp en dat bevalt mij (dus duidelijk) veel beter

@jiriw:
je hebt helemaal gelijk

[jiriw]

Explorer/BB4Win zijn desktop&window managers. De GUI is een veel groter deel. Als je explorer killt heb je nog steeds een muiscursor en vensters (de taskmanager bijvoorbeeld, of je inlogscherm; dan is explorer ook nog niet geladen. Of cmd.exe zoals je zelf al aangeeft)
Als je een alternatief hebt voor het volledige win32 subsystem ( * 786562 jiriwdan paraten we verder

[Jazzy]

De shell is simpelweg niet geïnstalleerd, net als al die andere onderdelen. De footprint is maar 500 MB, dat bereik je niet door wat functies uit te schakelen.

Nog even voor de duidelijkheid, de redenen om dit te doen zijn:
- Servicability (wat er niet in zit behoeft ook geen onderhoud)
- Managebility (hij heeft maximaal 4 rollen, veel minder te beheren dus)
- Security (wat er niet in zit kan ook niet het doelwit van een security-aanval zijn)

Het is dus heel wat anders dan een Longhorn Server Beta die standaard opstart met een commandprompt.

[Luuk1983]

Ik denk dat veel beheerders bij zullen zijn met een versie zonder GUI, daar hoor ik zo vaak klachten over: 'wat moet je nou met een GUI op een server'.

[Jazzy]

Ik denk dat veel beheerders bij zullen zijn met een versie zonder GUI, daar hoor ik zo vaak klachten over: 'wat moet je nou met een GUI op een server'.

Dat zijn geen echte klachten hoor. Dat hoor je het meeste uit de mond van Linux-beheerder-wannabees die net willen doen alsof ze uit de mainframe of Unix wereld komen. Moet je niet al te serieus nemen.

Een gemiddelde beheerder maakt dankbaar gebruik van grafische interfaces om de server te configureren en te beheren. Voor bepaalde zaken is de commandline makkelijker of zelfs noodzakelijk, maar zonder GUI maak je het jezelf onnodig moeilijk.

Tenzij je op een systeem werkt zonder GUI natuurlijk. Maar nogmaals, geen serieuze beheerder zal klagen dat hij een GUI voorgeschoteld krijgt.

[Anoniem: 49546]

Daarnaast:

Start | Run | cmd

Kan je zelfs fullscreen zetten, en dat de gui resources verbruikt: Dat valt allemaal reuze mee, als je niets doet kost het ook amper resources, een beetje geheugen that's it. Ik geloof niet dat geheugen een probleem is op de servers van tegenwoordig.

[Jazzy]

Een GUI heeft he-le-maal niets op een server te zoeken. De server bedien/beheer je vanaf je beheerdersstation, niet met de GUI op de server zelf.

Nog zo'n kreet die je vaak hoort naar die in de praktijk helemaal niet zo absoluut is als het wordt gesteld. Ik kan je uit ervaring vertellen dat er genoeg situaties zijn waarin je achter de console moet plaatsnemen. Bijvoorbeeld bij de initële inrichting, nog lang voordat je überhaubt aan het netwerk hangt. Zelfde verhaal bij software-installaties die je niet vanuit een RD sessie mag doen of zaken die je remote niet kunt doen omdat tijdens het proces de netwerkverbinding weg kan/zal vallen.

Dan nog even over die recources. Een beetje server op dit moment ligt qua specs tussen een Pentium III 1 GHz en Xeons op 3,6 Ghz. Daar komt bij dat je in de praktijk zelden processors (gemiddeld) boven de 60% belasting uit ziet komen. Recources besparen door niet lokaal in te loggen? Kom op zeg.

[jiriw]

Ik heb met verbazing de bovenstaande posts gelezen die melden dat een GUI'tje meer niet uitmaakt op een server. Opmerkingen als "Linux-beheerder-wanabees", "Start | Run | cmd" en "statisch scherm met één boxje" doen mij afvragen of de betreffende mensen weten wat de systeemresources zijn die door een "simpele" GUI worden opgeslokt. Een is er duidelijk wel genoemd: Werkgeheugen, of RAM. En ook het genoemde 128 MB is een aardig eind in de goede richting. Misschien is het iets minder als alleen het inlogscherm aanwezig is omdat dan de explorer niet is geladen. In Linux is dit vergelijkbaar met X zonder een windowmanager als Gnome, FVWM of KDE.
Echter, een GUI gebruikt ook:
-Extra Harddisk space voor de bestanden van de window manager, GUI applicaties en meer gecompliceerde drivers die nodig zijn voor in- en uitvoer m.b.v. de GUI.
-CPU cycles, interrupts en bus bandbreedte; zowel tijdens het opstarten van de server als tijdens het gebruik. Zelfs als er alleen een inlogvenster staat moet bijvoorbeeld de videokaart regelmatig updates krijgen, al is het alleen maar voor de knipperende cursor achter "Password:" Dit resource verbruik vindt je trouwens in windows niet terug op de CPU usage monitor van de taskmanager. (Het is geloof ik in werkelijkheid een paar procent op een gemiddelde desktopprocessor)

Persoonlijk hoop ik dat Windows Longhorn Server net als bij bijna alle *nix-en komt met een optioneel laadbare GUI schil over een volledig functionele kernel/core die ook geladen is als er slechts een CLI aan staat. (Eigenlijk net als Win 3.x/9x maar dan niet met MSDOS) Het liefst dan wel een volledig functionele CLI. Dit biedt een hele hoop andere voordelen dan slechts het niet meer nodig hebben van een GUI (welke echter buiten het kader van deze toch al te lange post vallen)
Als je lokaal moet beheren type je "> win[enter]" en een minuutje later heb je je GUI voor je neus. Als je klaar bent sluit je je GUI gewoon af. Alle services die je server aanbiedt blijven ondertussen rustig doordraaien.


Voorbeelden van voordelen als je geen GUI nodig hebt:
-Servers die voor hun "core business" geen lokale dataopslag nodig hebben (zoals database servers die hun tabellen in het geheugen laden vanuit een SAN) kunnen het zonder harde schijf af. (Een van de meest foutgevoelige onderdelen van een server omdat het bewegende delen bevat en continu aan staat) Booten vanaf een NVRam(CFlash o.i.d.) of het netwerk omdat het OS zo klein is dat dit toch niet uitmaakt.
-'Servers' die met rekenwerk bezig zijn (100% CPU load... Nodes in een cluster, machines die transactiedatabases doorrekenen, MMOG servers) hoeven geen onnodige cycles aan een GUI te besteden en kunnen sneller klaar zijn met hun opdracht/met minder 'lag' iedereen van de meest actuele data voorzien.

[BWzes03]

@jazzy:

Ik kan je uit ervaring vertellen dat er genoeg situaties zijn waarin je achter de console moet plaatsnemen. Bijvoorbeeld bij de initële inrichting, nog lang voordat je überhaubt aan het netwerk hangt

En ik kan je uit ervaring vertellen dat er genoeg situatie zijn dat je de server (unix) aan het netwerk hangt, laptop met seriele kabel in de console (enige vorm van comunicatie aan de server) de machine een 'boot net - install' ingeeft.
Console kabel eruit en de machine boot van netwerk, en installeerd zijn O.S. vanaf de install server.
Dat is zoals 'echte' UNIX machines werken.

Op een server zals een Sun Fire V240 zit niet eens een mogelijkheid tot het aansluiten van een videomonitor of toetsenbord/muis. Dat wil je ook niet op een server, daar heb je workstations voor.

@Maurits van Baerle

Natuurlijk beheer je een server vanaf een workstation maar er zijn situaties waar dat niet zo is. Waarom denk je anders dat er bijvoorbeeld van KVM's met ingebouwde monitoren bestaan om in racks te worden gemonteerd?

Om al die Windows bakken te beheren. Voor UNIX machines volstaat een serial console concentrator dat op het netwerk hangt. De meeste UNIX servers hebben tegenwoordig ook allemaal ingebouwde netwerk consoles, via een secure webinterface of een telnet/ssh interface.
Mocht het netwerk down zijn, kun je altijd met je laptop of via de concentrator naar het console connecteren.

[Anoniem: 74617]

Een GUI heeft he-le-maal niets op een server te zoeken. De server bedien/beheer je vanaf je beheerdersstation, niet met de GUI op de server zelf. Dat is per definitie lastig/onveilig en het kost resources die de server veel beter ergens anders aan kan spenderen.

[Maurits van Baerle]

Natuurlijk beheer je een server vanaf een workstation maar er zijn situaties waar dat niet zo is. Waarom denk je anders dat er bijvoorbeeld van KVM's met ingebouwde monitoren bestaan om in racks te worden gemonteerd? Als er iets is wat op afstand wordt beheerd is het wel een server in een rack, toch zijn er troubleshoot situaties waar het wel handig kan zijn, nog afgezien van tijdens de installatie van de server.

Resource-gebruik lijkt me overigens onmeetbaar klein. Als je een machine gewoon uitlogt is er geen sessie en staat er dus een statisch scherm met één boxje dat zegt dat je op Ctr-Alt-Del moet drukken om in te loggen.

[the_stickie]

Teznij je een geïntegreerd en compleet product wil leveren.

Daarnaast ben ik maar wat tevreden dat ik vinkjes kan zoeken en niet commando's moet gokken
ik beb ervan overtuigd dat een GUI voor het beheer zo goed als noodzakelijk is om het overzicht te bewaren; het argumet dat die even goed op een client kan zitten is waar, maar dan ga je ervan uit dat de server perfect bereikbaar is ed...
Wat resources betreft; daar kan je je server op voorzien. Hou er ook ff rekening mee dat het merendeel van de windows server waarschijnlijk in KMO's /MKB's staan en niet beheerd worden door goeroes

[Cyberdeck]

Er wordt zowel van een workstation als op de server geconfigureert afhankelijk van de situatie. Echter hoewel ik zelf niet zo'n commando gek ben ken ik een aantal mensen die inderdaad helemaal geen GUI nodig hebben aangezien ze met commando's alles tig keer zo snel configureren e.d. kunnen dan met behulp van GUI.

Het is onzin dat soort mensen "beheerders wannabee's" te noemen! Ik ben het wel eens met dat iedereen zijn eigen manier heeft om productief te zijn er niet maar 1 manier is, vandaar dat een systeem die beide en ook beide in een mix kan bieden juist zo mooi is.

[_Thanatos_]

Een GUI heeft he-le-maal niets op een server te zoeken. De server bedien/beheer je vanaf je beheerdersstation, niet met de GUI op de server zelf

Ach, of de GUI nou op de lokale console wordt gepresenteerd, of via een terminal-sessie. In het laatste geval neemt het een veelvoud aan resources in, vanwege de netwerkoverhead, encryptie, compressie, etc.

En daarbij, een server (desktopmodelletje) start niet eens op als er geen toetsenbord en geen monitor aan hangt, dus het zou zonde zijn om die niet te gebruiken

[mjtdevries]

@jiriw

Jij bent verbaasd? Nou nog niet half zo verbaasd als dat ik over jouw post bent.

128MB ram voor de GUI? Bij lange na niet. Ga maar eens serieus kijken hoeveel het inneemt. Blijkbaar kunnen de meeste mensen niet eens de diskcache onderscheiden van geheugen dat de GUI gebruikt.
Begin eens met 23MB. Peanuts dus. Iemand die daarover zit te zeuren bij een server is niet serieus te nemen. (zowiezo zou die 128MB ook al peanuts zijn)

Harddisk space voor de GUI? Waar zeur je in godsnaam over? Ik zit met servers waar per servers honderden GBs aan diskspace aan zit. Denk je nou echt dat ik me druk ga maken over een paar tientallen MBs die ik kan besparen op de GUI? Kun je nou echt niks beters verzinnen? Als het nou 10GB scheelt waardoor ik grotere systeem disks moet aanschaffen, dan is het interessant.

Gecompliceerde drivers voor een GUI? Wat dacht je van minder gecompliceerde drivers omdat ik geen rekening hoef te houden met tikfouten in configuratie filetjes? Een vinkje kan je geen tikfout in maken. Veel voorspelbaarder en dus minder risico's.

CPU cycles? Je opmerkingen daarover zijn zo diep triest dat ik er niet eens op in ga.

Je zogenaamde voordelen:
- booten vanaf flash. En dat is dan volgens jou een voordeel? Waarom? Elke serieuse server draait gewoon van een Raid1 array. (Of VRAID1 als je boot-from-san gebruikt) Dat is gewoon absoluut GEEN foutgevoelig onderdeel van een server. Totaal onzinnig om moeilijk te gaan doen om je OS daarom zo klein mogelijk te maken.
- Weer dat gedoe over cpu cycles. Je moet echt wat leren over servers. Ten eerste draaien servers zelden tot nooit 100% cpu load. Dan stop je er namelijk wat extra cpu's bij. En mochten er servers zijn die wel lange tijd op 100% cpu draaien dan maakt die 0.001% verlies aan die GUI totaal niet uit. Als dat zo erg zou zijn, dan zet je weer extra cpu's in, of koop je over 2 maand het nieuwere model cpu.

Als je aan het bepalen bent hoeveel rekenkracht een server moet hebben dan ben je niet bezig met een procentje hier en daar dan gaat het over een cpu meer of minder. Dat kruimelwerk levert niets op, en elke minuut die je daar aan spandeert kost het bedrijf gewoon geld.

Als jij een CLI plezierig vind dan is dat prima. Maar kom niet met die belachelijke argumenten waarom een GUI slecht zou zijn.

[M55]

een desktop PC hoeft echt geen monitor of keyboard te hebben om op te starten hoor, kan je gewoon uitschakelen in de BIOS.

[mjtdevries]

Secure webinterface?

Klinkt haast alsof er met die UNIX bakken ook grafische interfaces zitten? Waarom zit je anders met een webinterface te klooien ipv een telnet/ssh?..... Oeps!

[Jazzy]

En ik kan je uit ervaring vertellen dat er genoeg situatie zijn dat je de server (unix) aan het netwerk hangt, laptop met seriele kabel in de console (enige vorm van comunicatie aan de server) de machine een 'boot net - install' ingeeft.
Console kabel eruit en de machine boot van netwerk, en installeerd zijn O.S. vanaf de install server.
Dat is zoals 'echte' UNIX machines werken.

Bedankt voor de uitleg. Op deze manier beheer ik onder andere een IBM RS/6000 7025-F50, heeft ook geen videokaart. Deze machine draait AIX 4.3.3 en wordt momenteel vervangen door een Windows Server 2003 machine.

Als dat niet zo geweest was en ik had door gemoeten met AIX 5.xL dan had ik nog steeds geen behoefte gehad aan X, simpelweg omdat het in het geval van AIX niets toevoegt aan de formidabele CLI beheermogelijkheden.

Misschien is dat wel het grote verschil met Windows Servers ( en dan praat ik over 2000 Server en Server 2003). Een deel van hun kracht zit in de doordachte en zeer bruikbare GUI. Iedereen die bekend is met MMC en bijvoorbeeld GPMC zal dat beamen.

Zonder GIU valt dat voordeel weg, daarmee wil ik niet zeggen dat dit onmogelijk is maar je doet dat alleen als je daar een erg goede reden voor hebt.

Ik verzet me gewoon tegen kreten als "een GUI hoort niet op een server" of zelfs "een browser hoort niet op een server". Als je dat soort uitspraken doet, zonder nuancering dan kan ik me niet aan de indruk onttrekken dat je er gewoon geen verstand van hebt.

Over die recources heb ik al wat gezged, ik zal mezelf quoten:

Een beetje server op dit moment ligt qua specs tussen een Pentium III 1 GHz en Xeons op 3,6 Ghz. Daar komt bij dat je in de praktijk zelden processors (gemiddeld) boven de 60% belasting uit ziet komen. Recources besparen door niet lokaal in te loggen? Kom op zeg.

[silentsnake]

En ik kan je uit ervaring vertellen dat er genoeg situatie zijn dat je de server (unix) aan het netwerk hangt, laptop met seriele kabel in de console (enige vorm van comunicatie aan de server) de machine een 'boot net - install' ingeeft.
Console kabel eruit en de machine boot van netwerk, en installeerd zijn O.S. vanaf de install server.
Dat is zoals 'echte' UNIX machines werken.

+4 inzichtvol

Dit is precies de troef van een CLI. Als je geen toegang kan krijgen tot de console om wat voor reden dan ook en je netwerk interface / kabel / switch ligt op z'n gat kom je dus voor geen mogelijkheid meer bij je Windows machine.

Ik heb hier op m'n werk aan laatst een console switch aangeschaft en heb daar al de Unix machines aangehangen. Echt ideaal. En de Cisco man maakt er ook dankbaar gebruik van, want die kan natuurlijk gewoon via z'n console poortjes op de routers / switches op die manier.

Ga dat maar eens doen met je GUI.

[Abom]

@silentsnake,

Je hebt het hier over een situatie die vrij weinig voor komt, namelijk in het geval van een calamiteit. Daarbij komt dat je een groter probleem hebt wanneer je switch bijvoorbeeld niet werkt, dan ligt er waarschijnlijk meer uit dan die ene server en zal je je op die switch moeten focussen zodat je alles weer up en running krijgt. Verder zijn de meeste servers toch wel uitgerust met 2 NICs en wanneer er een stuk gaat, hoor je dat ding te vervangen.

Ik vind het vreemd waarom een console switch wel als 'professionele oplossing' word gezien, maar een KVM switch (al dan niet ingebouwd) niet. Ik wil mijn servers helemaal niet over een seriele verbinding kunnen beheren...de hele wereld werkt met TCP/IP en ik kan gewoon telnetten naar mijn servers hoor.

[BWzes03]

@mjtdevries:

Secure webinterface?

Klinkt haast alsof er met die UNIX bakken ook grafische interfaces zitten? Waarom zit je anders met een webinterface te klooien ipv een telnet/ssh?..... Oeps!

De secure webinterface waar ik het over heb, is een vinding van HP, de 'secure web console'. Een intern of een extern kastje, met een seriele kabel naar de UNIX console en een 10mbit Ethernet aansluiting aan het netwerk. Het kastje (of kaart) bevat een embedded webserver met SSL encryptie (in hardware) dat via een browser de server te beheren maakt via het console.
Er zit een Java based console applet in, waarmee de server remote te beheren is.

In deze HP en Sun Fire servers zitten ook nog enkele 'BIOS' tools, waarmee de server over deze interface remote kan worden aan/uit geschakeld. Zogenaamde 'chassis logs' kunnen worden uitgelezen, met diagnostiek als temperatuur, fan status, power status, disk status, CPU/memory status etc.
Zeer handig allemaal.

[BWzes03]

@Aborn:

Je hebt het hier over een situatie die vrij weinig voor komt, namelijk in het geval van een calamiteit. Daarbij komt dat je een groter probleem hebt wanneer je switch bijvoorbeeld niet werkt, dan ligt er waarschijnlijk meer uit dan die ene server en zal je je op die switch moeten focussen zodat je alles weer up en running krijgt.

Deze situatie komt vaker voor dan je denkt. Een switch waar een server aanhangd is niet de switch waar de console concentrator aan hangt. Als dat wel zo is, is er iets fundamenteel mis met het netwerk design. Ofwel, je kunt, ook als de switch waar de server aanhangd omvalt nog steeds de server op afstand beheren via de remote console. Niet alleen een switch kan falen, ook kan iemand tijdens het patchen van servers een kabel 'per ongeluk' raken dat de kabel breekt of niet helemaal correct meer functioneerd.

[Abom]

@SupraVentrical:
Wij hebben ook gewoon 2 NICs in elke server en beide NICs zijn op een andere switch aangesloten en als failover van mekaar geconfigureerd. Nog nooit een iets met het netwerk gehad wat of vrijwel geen impact had op de server of zo groot was dat eerst het netwerk probleem opgelost zou moeten worden.
Tenzij je mensen sucken of je netwerk triest opgezet is, zou zoiets echt niet moeten gebeuren.

Maar dan nog, LAN-KVM's kun je ook gewoon op een andere switch aansluiten, net zoals je concentrator.

@Pietervs, LAN-KVM switches werken gewoon over TCP/IP.

[Pietervs]

Een GUI heeft he-le-maal niets op een server te zoeken.
Oh nee? hoe kan ik dan patience spelen???

[Pietervs]

Ik vind het vreemd waarom een console switch wel als 'professionele oplossing' word gezien, maar een KVM switch (al dan niet ingebouwd) niet.
Het grote verschil is natuurlijk dat je met een KVM switch over het algemeen toch in de serverruimte moet gaan zitten, terwijl je met een console-switch gewoon achter je PC'tje kan blijven hangen.
Daarnaast lopen de verbindingen naar een console switch gewoon over UTP, terwijl je naar een KVM switch 3 dikke(re) kabels hebt lopen per server.

Om nou te roepen dat een consoleswitch daarom professioneler is gaat mij wat te ver. Maar niet meer in de airco van de serverruimte hoeven zitten is natuurlijk wel een genot...

[Laurens-R]

quote: Maar niet meer in de airco van de serverruimte hoeven zitten is natuurlijk wel een genot...


Behalve in de zomermaanden... Bij ons is het dan een ware veldslag wie er nu weer "lekker" in de server ruimte mag zitten

[punisher007]

Persoonlijk ben ik het hier gedeeltelijk mee eens. Het is echter natuurlijk wel handig als je de GUI in of uit kan schakelen. Zodat alleen bij gebruik de resources verloren gaan.

[punisher007]

Ben wel benieuwd wat de systeemeisen zijn als er gekozen wordt om niet gebruik te maken van een GUI. Neem aan dat dit een poging is om een van veel genoemde voordelen van linux weg te nemen.

[Olaf van der Spek]

wat de systeemeisen zijn als er gekozen wordt om niet gebruik te maken van een GUI.

Ik gok iets van 128 mb RAM minder. Maar dat is op 1+ gb niet zoveel.

[mOrPhie]

Juist wel. Dat is ruimte die gebruikt kan worden voor veel belangrijkere zaken, zoals MSSQL-Server, IIS of andere services, dan opgeslokt te worden door de GUI die er op een server niet toe doet.

[Abom]

@aartdeheus

...is dat dit de eerste Windows is die ZONDER GUI functioneert of kan functioneren, en dát bewijst Microsoft hiermee

Hoezo de eerste? Dit kan al jaren, Windows 2000 was al goed te beheren vanaf de commandline, Windows 2003 is dat helemaal. En wanneer je Monad gezien hebt, ga je twijfelen aan je unix shells. Kun je je het voorstellen, een object-georienteerde shell?

Met een CLI waar je wat mee kunt, kan ik bijvoorbeeld met m'n gsm vanaf het strand even snel een paar services wijzigen en herstarten.

Services opnieuw starten vanaf de CLI kan al sinds Windows NT4, big deal.

Bovrendien kan ik met een CLI scriptje in één ruk vijftig servers tegelijk een wijziging door laten voeren aan de configuratie, met een GUI moet dat stuk voor stuk.

Als Microsoft ergens goed in is, is het centraal beheren van je servers. Dit kan zowel vanaf de CLI, als ook m.b.v. MMC, GPO's.

Het spijt me verschrikkelijk, maar het enige wat ik uit je post kan halen is dat je helemaal geen verstand hebt van het beheren van Windows systemen.

@MonsterMind, het moest Monad zijn, de nieuwe CLI van Microsoft (aka MSH)

[Anoniem: 28659]

kan natuurlijk ook zijn dat ze hiermee verder willen gaan op clusters. Voor 1 server heeft een GUI mischien niet zo'n grote inpackt alleen als er tig hebt staan en je beheert ze toch remote heeft het een stuk grotere voordelen.

[Olaf van der Spek]

Juist wel.

128 mb RAM kost 12,50. Hoe kan dat nou veel zijn (voor een server, maar ook voor een desktop)?

[Anoniem: 399]

De prijskwestie is voor het geheugen een beetje onzinnig: zelf als je een bladerack met 30 bakken beheert is die 128 MB per server geen serieuze kostenpost: je voegt niet extra geheugen toe voor het GUI, maar normaliter gewoon omdat je server het niet trekt, en dan duw je geen 128 MB erin maar gewoon twee reepjes van 512 of 1024 MB. Overigens noemt hier iemand de kostprijs van 128 MB ram 12,50, maar volgens mij doen we in servers nog altijd registered ECC geheugen, en dat is wel een ietsiepietsie duurder. Dan nog, de prijs is een onbelangerijk argument.

Wat wél boeiend kan zijn, is dat dit de eerste Windows is die ZONDER GUI functioneert of kan functioneren, en dát bewijst Microsoft hiermee: het volledig via CLI kunnen beheren van een systeem is een giga voordeel, omdat CLI's per definitie makkelijker te scripten zijn dan GUI's.
Met een CLI waar je wat mee kunt, kan ik bijvoorbeeld met m'n gsm vanaf het strand even snel een paar services wijzigen en herstarten. Nu moet je voor allerlij dingen met een muis prutten, wat gelijk wer inhoudt dat je moet gaan k****en met VNC of Terminal Service, dat dan weer niet loopt op m'n gsm, zodat je naar de auto moet om de laptop erbij te halen. Maar die neem ik niet mee naar het strand want dan ben ik én een autoruitje én m'n laptop kwijt. Bovrendien kan ik met een CLI scriptje in één ruk vijftig servers tegelijk een wijziging door laten voeren aan de configuratie, met een GUI moet dat stuk voor stuk.

[curry684]

128 mb RAM kost 12,50. Hoe kan dat nou veel zijn (voor een server, maar ook voor een desktop)?

Totdat RAM uitbreiden door slottekort inhoudt dat je je 1Gb reepjes moet vervangen door 2Gb reepjes. Dat scheelt meteen een paar honderd euro per blade, en is met SQL Server, dat beter draait met iedere Mb die je erin legt, geen onwaarschijnlijk scenario. Hoe minder het OS dan zuipt hoe efficienter je SQL Server is.

[Anoniem: 5422]

Als je die 128MB, zal minder zijn maar ok, echt zo hard nodig hebt moet je gewoon investeren in meer Ram. Wat is op een server tegenwoordig 128MB?

Ik snap trouwens niet waarom de Gui weg moet. Als je de gui gebruikt wanneer je hem echt nodig hebt en voor de rest de server gewoon op login laat staan is er toch niets aan de hand? Ik zie het probleem niet zo. Ik zet er liever 128MB extra in dan dat ik veel meer tijd kwijt ben aan typen en leren van diverse commando's. Daarbij, hoe vaak loop de gui van een Windows 200x server vast? Bij mij nooit.

[Abom]

Ik zie het probleem helemaal niet met dat geheugen, wanneer geheugen voor een langere periode niet aangeraakt wordt, gooit Windows het toch gewoon naar de cache file?
Verder kun je al sinds Windows 2000 ervoor zorgen dat Windows maximaal resources toe moet kennen aan services ipv de Desktop/Applicaties, sterker nog, dat is standaard zo ingesteld voor de server serie.

[Olaf van der Spek]

het volledig via CLI kunnen beheren van een systeem is een giga voordeel, omdat CLI's per definitie makkelijker te scripten zijn dan GUI's.

Een systeem is meer dan een operating system.
En als software echt goed is opgezet gebruik je voor scripting geen cli en geen gui maar een api.

[MonsterMind]

@Aborn...Mag ik vragen wat je bedoel met Nomad?

[robin1979]

Zeker voor NUMA machines is dit zeker wel belangrijk!

[Anoniem: 5422]

Want? Numa staat redelijk los van het geheugengebruik of heb ik dat mis?

[Anoniem: 93692]

Ik neem aan dat dit een antwoord is op een veel voorkomende consumentenvraag.

[gridfox]

veel voorkomende consumentenvraag

Consumenten -> Longhorn Server

Als consumenten niet primair grafisch willen werken, had Linux veel eerder grip op de desktopmarkt.

[Anoniem: 17892]

Sorry, een consument is een natuurlijk persoon, niet de koper van iets. Een bedrijf kan ook dingen kopen, maar is beslist geen consument.

Maar goed, ontopic:

Het werd tijd dat MS eens iets uitbracht zonder GUI, voor een server is het een vrij nutteloze toevoeging.

[Sgreehder]

consumenten = afnemers van server software

Wie had het hier over de desktopmarkt ;-)

[mjtdevries]

Onzin. Een consument is iemand die consumeert.

Dus de afnemer van het product!
In het geval van serverproducten zijn de consumenten dus de bedrijven die die producten kopen.

Iemand die bij een consument alleen maar aan een natuurlijk persoon denkt heeft blijkbaar nog nooit bij een bedrijf zaken besteld, of verkocht aan andere bedrijven.

Voor een server is een GUI verder helemaal geen nutteloze toevoeging. Een GUI maakt het makkelijker om een stuk software te configureren en maakt de kans op vergissingen kleiner. Daarom is het ook voor serversoftware zinvol (en gewenst door kopers) en is het dus ook voor een server OS zinvol.

[keluwak]

volgens mij is het voor een bedrijf nog steeds investeren ipv consumeren..

[maratropa]

Windows zonder windows dus!

[babbaloerie]

Idd, als het helemaal commandline-based word kun je het ook geen Windows meer noemen, dan was Microsoft Server een betere naam geweest.

[familyman]

Een bewijs dat alpha-blending, wanneer ver doorgevoerd geen enkele resource hoeft te kosten.

[Parasietje]

Deze post is GRAPPIG bedoeld. Als je de alpha van de windows GUI ver doorvoert (i.e. op 0 zet), dan zie je de GUI niet meer. Dan kijk je erdoorheen, naar hetgeen wat eronder ligt.
Snap de mop!

[mOrPhie]

Alpha Blending maakt gebruik van de capaciteiten van de videokaart en zal waarschijnlijk ook wat gebruik maken van de memory en/of CPU-Cache. Maar een gui op de server is wellicht nog te verdedigen, echter, alpha blending op een server is meer dan onzinnig.

[Anoniem: 19339]

@m0rPhie:

Ik weet niet waar het onderwerp alpha-blending opeens vandaan komt, maar dat zit al sinds Windows 2000 in de gui ingebakken, alleen is er bijna geen enkel programmaatje wat iets met die alpha-blending doet.

Alpha is gewoon een extra waarde in de eigenschappen van een element, net zoals de kleur. Het zit er gewoon in, en zal niet echt veel meer of minder resources kosten.

Het enige waarin het bijna altijd wel wordt toegepast, is de schaduw achter je muisje.

[mOrPhie]

@RefriedNoodle

De alphablending van longhorn is/kan hardwarematig en heeft geen enkele overeenkomsten met wat Windows2000/XP met transparency doet. En aangezien het hier gaat over longhorn en familyman een verkeerde aanname deed, wilde ik dat even rechtzetten. Alphablending kost weldegelijk resources. Zo worden immers slim gebruikt om het alphablenden zo snel mogelijk te maken. (waarschijnlijk dmv offscreen dubble buffering)

Waarom familyman het aanhaalde is mij verder ook een raadsel hoor. Dat geef ik je toe.

[quistnet]

denk dat familyman eerder bedoeld net iets als het Alpha kanaal bij 3D, waar objecten met een alpha van 1.0 gewoon meestal niet gerendered worden in plaats van naar de videokaart gestuurd te worden

[ReLexEd]

Het feit dat er geen GUI meer nodig is op de server zou idd in de resources moeten schelen, maar of dat in de praktijk voor Longhorn ook gat gelden... dunno....

Qua stabiliteit denk ik dat het een behoorlijke stap vooruit is.... voorop gesteld dat er gebruik wordt gemaakt van private memory space (die ook daadwerkelijk doet wat het moet doen ...

En er zal een behoorlijk stukje aan de CLI-functionaliteit gedaan moeten worden.... oftewel een lading extra commando's zodat de *nix-functionaliteit binnen bereik komt...

Dan heeft het denk ik wel wat...

En laten we natuurlijk niet vergeten dat alle MS-gecertificeerden dan EINDELIJK een papiertje kunnen halen waarmee ze aan de hele wereld kunnen laten zien dat ze daadwerkelijk iets geleerd hebben, ipv weten waar er geklikt moet worden!

[Cyberamp]

Qua stabiliteit denk ik dat het een behoorlijke stap vooruit is.... voorop gesteld dat er gebruik wordt gemaakt van private memory space (die ook daadwerkelijk doet wat het moet doen ...

Nou ja, Windows Xp is niet bepaald instabiel te noemen... dus ''zoveel extra stabiliteit'' valt niet te merken denk ik. Misschien een behoorlijke stap vooruit wat betreft security leaks e.d.

[Jazzy]

Het feit dat er geen GUI meer nodig is op de server zou idd in de resources moeten schelen, maar of dat in de praktijk voor Longhorn ook gat gelden... dunno...

Waarom wel of waarom niet? Overigens is de reden van een uitgeklede versie niet zo zeer dat je zuiniger met resources om kunt gaan maar meer dat je kunt draaien op embedded systemen (er komt ook weer een embeded editie uit) en vooral dat je een kleinere installatie hebt, dus veel minder kans op security problemen.

En er zal een behoorlijk stukje aan de CLI-functionaliteit gedaan moeten worden.... oftewel een lading extra commando's zodat de *nix-functionaliteit binnen bereik komt...

Heb je je al verdiept in Monad? Ik denk het niet.

[Abom]

ReLexEd heeft onder een steen geleefd de laatste jaren? Hoe kom je erbij dat een GUI voor instabiliteit zorgt? Windows XP is al stabiel en Windows 2003 is niet stuk te krijgen, mits opgezet door iemand met de benodigde kennis (lees: MS-gecertificeerden)

[mjtdevries]

Noem eens wat stabiliteitsproblemen van windows2003 op die te maken hebben met de GUI?

Als je zulke uitspraken doet, dan moet je wel wat onderbouwing geven!

[familyman]

Door middel van een nieuw cachingsysteem, Offline Files genaamd, zullen eindgebruikers kunnen werken met bestanden op de server, ook als er geen verbinding is met de server.

Hoe ga ik werken met bestanden op een server, als ik niet op de server kan om te kijken wat voor bestanden erop staan?

[Anoniem: 5422]

Je foder wordt dan gewoon lokaal gezet. Als je weer op de zaak zit worden de files bijgewerkt. Allemaal automatisch natuurlijk.

[Anoniem: 99613]

Op het moment dat de client (workstation) inlogt download deze automatisch alle cached files (Offline Files), denk dan aan bijvoorbeeld bestanden in de Active Directory, mail accounts ivm MS Exchange.. Dit gebeurd allemaal natuurlijk VOORDAT de verbinding wegvalt..

[PowerFlower]

Door middel van een nieuw cachingsysteem, Offline Files genaamd, zullen eindgebruikers kunnen werken met bestanden op de server, ook als er geen verbinding is met de server.

Ben ik dan de enige die dat al in zijn XP Pro heeft zitten

[Anoniem: 74617]

Is jouw XP Pro een server dan

[VHware]

in Windows 2000 zelfs al...

[xAn52]

Ik denk t wel. Dit lijkt me eerder een iFolder (Novell) achtige oplossing, dan bestandjes lokaal opslaan.

[ProfPi]

Starting PC-DOS 2007...

C:\>

[90710]

of...

Starting MS-DOS.Net 2007...

Press the any key to continue...
(En nu maar wachten totdat iemand 'm snapt )

[Anoniem: 5422]

Door middel van een nieuw cachingsysteem, Offline Files genaamd, zullen eindgebruikers kunnen werken met bestanden op de server, ook als er geen verbinding is met de server.

Nieuw? Dit werkt allang met Windows 2003 en XP.

[Anoniem: 1322]

Dit is een nieuwe versie die je ook terug gaat zien in windows server 2003 R2. Deze heeft een "slimmere" bestandsoverdracht.

Stel: je veranderd een titel in een powerpoint presentatie van 20 MB. Het verschil is 20Kb. Met Windows 2003 wordt de volledige 20MB gesynced en met R2 alleen de 20Kb.

Het scheelt veel bandbreedte, vooral als je meerdere vestigingen hebt die aan filereplicatie doen.