GerhardG

könnte es sein das eine firewall die übertragung blockiert? versuch mal die dateien von hand zu übertragen, bei windows xp ist ein tftp client dabei.

ich wüßte nicht wie eine platte den freien fall aus 1,5m aushalten soll, ein lto/ait band steckt sowas recht problemlos weg. selbst wenn das gehäuse springen sollte bleiben die daten erhalten. bei extremfällen wie feuer hast du natürlich recht. rechne 25x 200/400 lto bänder (etwa 400 euro) und 25x 300gb hdd (etwa 2000 euro). da fehlt nicht mehr viel zum lto2 laufwerk. bei der hdd brauchst du dann immer noch etwas dazu was alle platten aufnehmen kann (zb ein nas), dagegen ist ein lto schon fast geschenkt ;) ich möchte backup to disk nicht verteufeln, ganz im gegenteil. aber die meinung backup to disk ist viel billiger stimmt nur im kleineren bereich wo zb mit usb platten gearbeitet wird. klar, auch eine bandlösung kann nicht unbegrenzt (wirtschaftlich) erweitert werden. spätestens wenn ein größerer wechsler ansteht kommt man um ein vorgeschaltenes backup to disk kaum mehr herum. ein eigener brandabschnitt für einen dasi raum wäre natürlich immer optimal. das angesprochene auslagern der daten halte ich für besonders wichtig, viele vertrauen blind den feuerfesten tresor. ack. ganz meine meinung.

"nicht personalisierte" daten werden nur dann übertragen wenn DU diese funktion aktivierst. persönliche daten werden aber in keinerlei modi übertragen.

google desktop

ios feiert bald den 30iger ;) http://de.wikipedia.org/wiki/Internetwork_Operating_System http://en.wikipedia.org/wiki/CatOS http://en.wikipedia.org/wiki/Catalyst_switch

ntfsresize aus den freien ntfstools.

verglicher mit einer hdd ist ein band ja schon fast unzerstörbar. eine große festplatte hat 250-500gb, ein großes band hat 400-800gb? ein ordentliches nas ist um einiges teurer als die bandsicherung. vergleiche einfach was eine 500gb festplatte und ein 400/800gb lto band kostet. spätestens wenn man mehrere tages/wochen/monats/jahres stände halten muss, wird eine reine nas lösung extrem teuer.

eine platte fällt auf den boden => kaputt ein band fällt auf den boden => die hülle wird staubig backup auf nas ist ein recht teurer spaß, des weiteren ist es nicht so einfach das backup sicher zu lagern (brand, hochwasser,...).

warum nicht einfach ein netzlaufwerk verbinden?

mit windows boardmittel => shared storage und jede menge teures zubehör mit cluster software von dritthersteller => wie unter suse ein schneller lan link und am besten ein zusätzlicher heartbeat

http://www.cacti.net

die default config hat keine endung, das passt schon so. im prinzip schaut es schon sehr gut aus, der bootloader wird geladen und er sucht nach einer config. wird net.img vom tftp geladen, sollte tftpd32 auch anzeiten? der pxelinux.cfg ordner liegt auch im tftproot? die datei net.img liegt ebenfalls im tftproot?

die rdp session ist unabhängig von der konsole, die maximale farbtiefe usw kannst du in der terminal service configuration festlegen.

ntfs rechte entziehen, geht recht einfach mit xcals + psexec

ok, ich hab schnell eine komplett abgespeckte version für dich gebastelt. meine umgebung ist etwas komplexer da u.a. ein thinclient os für pxe boot dabei ist. ich bräuchte kurze ne email adresse, sind etwa 1,1mb. das ganze funktioniert so, entpacke mein zip in dein tftproot. im dhcp musst du statt des 3com bootloaders (mba.pxe) nun den pxelinux bootloader eintragen (pxelinux.0). wenn du nun einen client via lan startest, sollte mein beigelegtes image booten. images hinzufügen: für dos images wird ein mini bootloader namens "memdisk" verwendet, dieser liegt ebenfalls im tftproot. wenn du nun eine funktionierende bootdisk in ein pxe image umwandeln möchtest, musst du nur die diskette mit rawwrite ( http://uranus.it.swin.edu.au/~jn/linux/rawwritewin-0.7.zip ) in eine datei schreiben. dieses image legst du einfach im tftproot ab und hinterlegst den namen der datei in der "default" config datei. die "default" konfigurations datei liegt im unterordner"pxelinux.cfg". hier kannst du auch beschreibungen oder hilfetexte hinterlegen die beim starten angezeigt werden sollen. als beispiel habe ich eine kleines dos bootimage eingetragen und als image beigelegt (net.img). hier kannst du beliebige viele images hinzufügen und auswählen. beispiel config: default dos prompt 1 timeout 1000000 display pxes.msg F0 pxes.msg F1 helpopt.msg label dos kernel memdisk append initrd=net.img label biosupdate kernel memdisk append initrd=biosupdate.img

ganz so schön und einfach ist es auch wieder nicht. damit du entsprechende kurze ausfallszeiten hast brauchst du schon mehr als ein paar vm´s. ohne entsprechende hard- und software geht nichts. bei teurer hardware würde ich es mir 2x überlegen ob du den deutlich schwächeren virtual server von microsoft verwendest. alleine die hdd i/o ist je nach umgebung um etwa 15% geringer als in vmware. ganz zu schweigen das du mit virtual server anstehst und nicht einfach zu esx wechseln kannst.

du hast pm

wie gesagt, das hat mit linux überhaupt nichts zu tun. du legst wie mit mbutil die dateien am windows tftproot ab und fertig. am dhcp lebst du weiterhin das bootfile fest und der client holt sich alles notwendige via tftp. ich kann dir gerne meine thinclient umgebung zukommen lassen, weitere bootfiles sollten dann kein problem sein.

nicht vergessen, die erste beta läuft in wenigen tagen aus! der neue build 22088 kann einfach darüber installiert werden, alle settings werden übernommen. des weiteren ist die vermarktung wie angekündigt frei. ein logischer schritt, insbesondere wo lösungen wie xen den markt komplett aufrollen.

shutdown.exe aus dem resource kit + windows eigenen taskplaner.

das 3com tool ist total veraltet. am besten nimmst du pxelinux als bootmanager. trotz des namens hat dieser NICHTS mit linux zu tun, er kommt einfach aus der oss ecke. mit pxelinux + memdisk kannst du weit verzweigte menüs erstellen, bilder/hilfe/faq und wwi alles einbinden.

man kann einen dc mit fremdmittel ohne weiteres "clustern", beispielsweise mit vmware/drbd wo die nötigen ads services und datenbanken ebenfalls gespiegelt werden (cold standby). ohne zusätzlichen dc hast du aber beim umschalten min 30 sekunden bis 4-5 minuten keinen dc. des weiteren hilft der beste cluster nicht weiter wenn die partition mit den ad informationen fehlerhaft ist und dieser fehler ebenfalls gespiegelt wird.

cpu ist "unwichtig", hautpsache ram und viel platten i/o. da linux je nach konfig freien ram zum cachen verwendet, kann es hier durchaus zu spürbaren unterschieden kommen. bei richtigen servern kommt dies aber nicht mehr so stark zum tragen. hast du den debug modul deaktiviert, dieser soll in der beta etwas bremsen?

es gibt seit kurzen übrigens ne neue beta :)

sie wären nicht der erste großkonzern der komplett umstellt. aber da ibm kein reiner linux dienstleister ist, werden sie wohl weiterhin auch windows clients verwenden. aber wohl überall wo möglich, werden sie früher oder später aus kostengründen umstellen.