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?
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.
