Ich habe das absichtlich in Anführungszeichen geschrieben. Ich kenne und habe auch schon mehrfach benutzt einen sog. "Virtualisierer", also ein Tool, was aus einem realen PC bzw. Laptop eine inhaltlich identische funktionierende virtuelle Maschine für VMWare oder Virtualbox macht. Nun steht ein ganz ähnliches Problem an: Ein mit viel Software und vor Allem Einstellungen und Konfigurationen laufender PC eines Buchhalters soll auf einen Terminalserver unter Windos Server 2012 R2 umziehen. Und das möglichst so, dass nicht Alles komplett neu installiert werden muss. Geht das, gibts sowas? Wenn es schon nicht möglich sein wird, installierte Software "herüberzuheben" so doch wenigstens die ganzen Einstellungen per Kopie des User-Ordners? Oder ist das so kompliziert, dass es am Ende besser ist, von Vorne anzufangen? Danke für Tips.
Hi Frank Du schreibst leider nichts über die verwendete Software (also die welche der Buchhalter verwendet). Je nach dem kann das was du möchtest möglich sein, ist aber generell eher mit "nein" zu beantworten. Wenn dabei noch ein Wechsel des OS ansteht dann wird das alles wohl recht nicht so einfach sein. Ich bin generell aber eher ein Fan von komplett neu aufgesetzten, dann auch sauber laufenden, Systemen;)
Frank schrieb: > Geht das, gibts sowas? Nein. Das ist einer der Design"vorzüge" von Windows, daß es praktisch unmöglich ist, installierte Programme von einem auf einen anderen Rechner zu übertragen, insbesondere wenn unterschiedliche Betriebssystemversionen verwendet werden. Warum soll ausgerechnet ein Terminalserver verwendet werden? Um den ganzen Kram mehrbenutzerfähig zu bekommen? Oder was ist der tiefere Hintergrund?
Frank schrieb: > Wenn es schon nicht möglich sein wird, installierte Software > "herüberzuheben" so doch wenigstens die ganzen Einstellungen per Kopie > des User-Ordners? Oder ist das so kompliziert, dass es am Ende besser > ist, von Vorne anzufangen? Danke für Tips. Die Ordner aus dem User-Profil und den richtigen "Zweige" aus der Registry (unter HKCU und HKLM)
Rufus Τ. Firefly schrieb: > Warum soll ausgerechnet ein Terminalserver verwendet werden? Um den > ganzen Kram mehrbenutzerfähig zu bekommen? Es geht nat. nicht nur um diesen einen Arbeitsplatz, sondern um ca. 15. Der eine war nur ein Beispiel. Gründe für Terminalserver? - kleine geräuschlose Rechner (lüfterlose Thin Clients, Stück 30,-) - freie (Arbeits-) Platzwahl - nur eine Installation für jede Software - zentrale Benutzerverwaltung - zentrale Updates - zentrales Backup - zentrale Virenvorsorge - trotz "fettem" Server in der Summe geringerer Stromverbrauch Risiko: Ausfall des Servers legt Alles tot. Dafür gibt es einen identischen Spiegelserver, der regelmäßig synchronisiert wird.
Windows-Programme auf andere Rechner umzuziehen, funktioniert schon bei Einzelplatzsystemen nur in sehr wenigen Ausnahmefällen. Ein Terminlaserver hat zudem gewisse Besonderheiten. Die Software muß im Installationsmodus aufgespielt werden, ansonsten funktioniert sie hinterher nicht oder nur fehlerhaft. Und das Übertragen der Userprofile geht ebenfalls nicht ohne weiteres. Zum einen unterscheidet sich die Struktur von OS zu OS und zum anderen sind die Berechtigungen von Dateien und Registry-Schlüsseln mit der SID des Benutzers verknüpft, welche wiederum an das Ursprungssystem gebunden ist. Selbst wenn es gelingen sollte, herauszufinden, welche Zweige des Profiles/der Registry migriert werden müssen, dürfte alleine der Zeitaufwand für die Analyse und Anpassung um ein Vielfaches höher sein als eine komplette und vor allem saubere Neuinstallation des Systems. Fazit: Forget about it.
Rufus Τ. Firefly schrieb: > Nein. Das ist einer der Design"vorzüge" von Windows, daß es praktisch > unmöglich ist, installierte Programme von einem auf einen anderen > Rechner zu übertragen, insbesondere wenn unterschiedliche > Betriebssystemversionen verwendet werden. wo ist denn die Design schwäche von Windows? einzelne Teile der Konfig (Registry) kann man ohne Probleme exportieren und wieder importieren. Auch wenn registriere AktivX controls vorhanden sind, kann man sie umziehen. Auch Dienste zu kopieren ist keine Problem, auch zwischen verschiedenen Windows-Versionen.
Peter II schrieb: > einzelne Teile der Konfig (Registry) kann man ohne Probleme exportieren > und wieder importieren. Sicher kann man das. Wenn man weiß, welche Teile relevant sind. Bei welcher eingekauften Software aber ist das dokumentiert? Und wer hat die Zeit, das durch Trial-and-Error herauszufinden? Und wer die Lust, herauszufinden, welche weiteren Abhängigkeiten neben irgendwelchen Registry-Einträgen bestehen? Obendrein: Ein Terminalserver verhält sich in einigen Punkten /sehr anders/ als ein normales Windows-System, was mit der Mehrbenutzerfähigkeit zu tun hat. Möchte man einen Registry-Export eines Einbenutzersystemes auf einen Terminalserver übernehmen, muss man sich dessen bewusst sein und die nötigen Anpassungen machen. Fazit: Es ist de facto unmöglich. Sinnvoller ist es, das ganze Geraffel dahingehend zu durchforsten, was wirklich benötigt wird, und das dann auf dem Terminalserver zu installieren. Das wird schon ausreichend lustige Nebeneffekte mit sich bringen, weil durchaus nicht jede Anwendung dafür taugt, auf einem Terminalserver verwendet zu werden, weil sie beispielsweise nicht dafür ausgelegt ist, auf dem gleichen Rechner mehrfach in unterschiedlichen Benutzerkonten zu laufen. Wenn Interprozesskommunikation über named pipes oder sockets verwendet wird, kann das interessante Effekte mit sich bringen.
Rufus Τ. Firefly schrieb: > Sicher kann man das. Wenn man weiß, welche Teile relevant sind. Bei > welcher eingekauften Software aber ist das dokumentiert? also ist es eine Designschwäche von Windows wenn ein Softwareanbieter keine Doku zu Konfiguration beilegt?
Deiner Logik vermag ich nicht zu folgen.
Rufus Τ. Firefly schrieb: > Deiner Logik vermag ich nicht zu folgen. du hast geschrieben: > Nein. Das ist einer der Design"vorzüge" von Windows, daß es praktisch > unmöglich ist, installierte Programme von einem auf einen anderen > Rechner zu übertragen, insbesondere wenn unterschiedliche > Betriebssystemversionen verwendet werden. und dafür würde ich gerne eine Begründung hören.
@rufus Da ich mich gerade mit der Verwendung des Terminalservers beschäftigen muss, könntest Du mehr zu den Problemen bei der Verwendung von named pipes sagen? Gibt es grundsätzliche Probleme oder meinst Du die mehrfache Verwendung identischer Endpunkte? Das wäre dann ja noch recht einfach lösbar. Danke.
@Peter II: Rufus' Bemerkung über Designvorzüge war natürlich ironisch. Die Tatsache, daß Programme überhaupt Dateien in Systemordner schreiben dürfen und daß die Einstellungen von Programmen, Benutzern und dem Betriebssystem in einer gemeinsamen Datenstruktur verwaltet werden, ist vielleicht der Hauptgrund, warum Windows-Systeme (im Vergleich zu den meisten anderen) so anfällig und mit zunehmendem Alter der Installation schlecht zu warten sind. Wahrscheinlich würde Microsoft es heute besser machen, aber diese technologische Altlast ist halt der Kompatibilität geschuldet. Um zu sehen, wie man es richtig machen kann, genügt ein Blick auf den Apple (OS X) mit seinen quasi-monolithischen Applikationen.
res schrieb: > Gibt es grundsätzliche Probleme oder meinst Du die mehrfache Verwendung > identischer Endpunkte? Letzteres. Allerdings hat MS die Anzahl gleichzeitig nutzbarer Named Pipes schon vor längerer Zeit massiv reduziert (und das praktischerweise nicht weiter dokumentiert). > Das wäre dann ja noch recht einfach lösbar. Nur, wenn man die Software anpassen kann. Peter II schrieb: > du hast geschrieben: > >> Nein. Das ist einer der Design"vorzüge" von Windows, daß es praktisch >> unmöglich ist, installierte Programme von einem auf einen anderen >> Rechner zu übertragen, insbesondere wenn unterschiedliche >> Betriebssystemversionen verwendet werden. > > und dafür würde ich gerne eine Begründung hören. Warum es praktisch unmöglich ist, habe ich bereits ausführlich beschrieben. Das ist das Design von Windows, das sind Designvorgaben von Microsoft, und keine Entscheidungen einzelner Hersteller, irgendwas nicht zu dokumentieren. MS hat mit der Einführung der Registry als zentraler Konfigurationsdatenbank den Gebrauch von separaten Konfigurationsdateien als "veraltet" und zu vermeiden beschrieben. Muss ich Dir das wirklich erklären? Oder willst Du nur herumtrollen?
Sebastian schrieb: > Rufus' Bemerkung über Designvorzüge war natürlich ironisch. Die > Tatsache, daß Programme überhaupt Dateien in Systemordner schreiben > dürfen und daß die Einstellungen von Programmen, Benutzern und dem > Betriebssystem in einer gemeinsamen Datenstruktur verwaltet werden, werden sie überhaupt nicht. Sie sind nur eine einheitliche API erreichbar. Die Registry besteht aus verschiedenen Dateien wie Software, System, Benutzer. Rufus Τ. Firefly schrieb: > Das ist das Design von Windows, das sind Designvorgaben von Microsoft, > und keine Entscheidungen einzelner Hersteller, irgendwas nicht zu > dokumentieren. Wenn sie sich die Hersteller dran halten würde, dann müsste man nicht suchen wo die Konfiguration gespeichert wird. > MS hat mit der Einführung der Registry als zentraler > Konfigurationsdatenbank den Gebrauch von separaten Konfigurationsdateien > als "veraltet" und zu vermeiden beschrieben. und wo gibt es damit ein Problem? Wenn die Software ihre Daten unter HKCU/Software/... ablegt, kann ich sie ohne Probleme auf ein anderes System kopieren. Nichts anders würde man bei ini Dateien machen. > Warum es praktisch unmöglich ist, habe ich bereits ausführlich > beschrieben. darum ging es auch nicht. es ging darum das irgendetwas am Design grundsätzlich falsch sein soll. Und diese kann ich nicht nachvollziehen.
Peter II schrieb: > Wenn die Software ihre Daten unter HKCU/Software/... ablegt, kann ich > sie ohne Probleme auf ein anderes System kopieren. Sie legt ihren Kram aber auch unter HKLM\Software ab, und natürlich auch unter HKCR ...
Richtig. Und darüber hinaus kopiert diverse Software DLL, OCX oder ähnliche Dateien in Systemordner von Windows. Das war damals design-technisch gewollt. Heute ist es eine Altlast. Natürlich besteht die Registry aus mehreren Dateien - aber gerade über die API wird sie gehandhabt, als wäre es eine Datenbank. Das Grundproblem bleibt: Keine klare Trennung zwischen System und Anwendungsprogrammen. Auch die Idee, Konfigurationsdateien in einem Ordner zu sammeln, wie bei Linux und anderen Unix-ähnlichen Systemen ist nicht problemlos, ganz klar. Deswegen habe ich ja den Apple als Beispiel angeführt: Eine Benutzerapplikation und alle ihre Hilfs- und Konfigurationsdateien gehören zusammen und haben im Betriebssystem nichts zu suchen. Und ich weiß, mit so einer Meinung outet man sich als unverbesserlicher Purist - aber die Praxis stützt diese Ansicht, wenn man Fehlerszenarien und Support-Fälle von Windows- und OSX- Systemen vergleicht.
Sebastian schrieb: > aber diese technologische Altlast ist halt der Kompatibilität > geschuldet. Das ist keineswegs eine Altlast, sondern technische Voraussetzung für die einfache zentrale Administration von Windows-Netzwerken. Dem Einzelplatzbenutzer mag sich das nicht ohne weiteres erschließen, aber das System ist wirklich gut durchdacht und macht den Admins das Leben leichter. Auch wenn hier und da vielleicht ein paar Macken lauern. Und es würde auch wunderbar funktionieren, wenn sich die Softwareschmieden an die von MS vorgegebenen Strukturen und Empfehlungen halten würden.
In Windows eingebaut gibt es noch den 'Windows Easy Transfer' der Benutzerkonten, Applikationen und den dazugehörigen Einstellungen auf einen anderen Rechner überträgt. Da die Bedienung wirklich einfach ist lohnt sich ein Versuch auf jeden Fall.
Icke ®. schrieb: > Das ist keineswegs eine Altlast, sondern technische Voraussetzung für > die einfache zentrale Administration von Windows-Netzwerken. Das zweifele ich gar nicht an, aber dieses Verfahren macht die Arbeitsstationen relativ verwundbar, und sorgt dafür, daß oft nur kleine Fehler sich zum Totalschaden auswachsen. Nur mal als Frage an den Kenner (denn ich bin bloß Ex-Servicetechniker, nicht Admin): In Unix-Netzwerken, wo auch zentral administriert wird, hat man diese windows-typischen Mechanismen ja nicht. Haben es deswegen Unix- (inkl. Linux, Solaris, etc.) Admins notwendigerweise schwerer?
Sebastian schrieb: > Haben es deswegen Unix- (inkl. > Linux, Solaris, etc.) Admins notwendigerweise schwerer? Gute Frage. Mit dem Erscheinen von Windows Server 2000 habe ich sämtliche bis dato als Domänencontroller verwendeten Linux-Server in den Ruhestand geschickt. Eben weil sich die Administration mit Active Directory wesentlich vereinfachte. Das wichtigste Werkzeug sind die Gruppenrichtlinien (GPO), mit deren Hilfe sich jede Windowsanwendung zentral steuern läßt, die ihre Einstellungen in der Registry abspeichert. Dazu muß der PC natürlich einer AD-Domäne angehören. Beim Hochfahren des Rechners bzw. bei der Anmeldung werden die durch die Gruppenrichtlinien konfigurierten Einstellungen vom Domänencontroller geholt und lokal angewendet sowie auch im Betrieb regelmäßig aktualisiert. Will ich bspw. den RDP-Zugriff aktivieren, die Proxyeinstellungen des IE ändern, dem User verbieten, bestimmte Anwendungen auszuführen, das Aussehen des Desktops beeinflussen und und und.., kann ich dies mit wenigen Mausklicks zentral erledigen, ohne ein einziges Mal an die physikalischen Rechner ranzumüssen. Mit (lokalen) Anwendungen, die ihre Config in INI-Dateien speichern, geht das leider so nicht oder nur sehr umständlich. Das ist bspw. der Grund, warum in größeren Firmennetzwerken der Firefox nicht Fuß fassen kann, weil dessen zentrale Administration nur schwierig möglich ist. Meines Wissens nach gibt es im *nix Lager kein mit Active Directory vergleichbares Instrument. Aber wenn man es nie hatte, vermißt man es vielleicht auch nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.