Wolke2k4

In einer W2K3 Domain muss die TS Lizenzierung für W2K und W2K3 Terminal Server auch auf dem Domain Controller laufen! Schluckt der TS seinen Lizenzierungsserver nicht kann man diesen auch fest zuweisen (siehe ältere Threads zu diesem Thema).

Also wird doch die zweite Leitung aufgebaut? Wie sieht es mit ipconfig/all aus, wenn sich der zweite Nutzer eingewählt hat?

Was ist bei PSF sicherungstechnisch anders? Wenn ich es richtig mitbekommen habe handelt es sich lediglich um eine PST, die man in der Regel doch mitsichern kann. Wenn ich nun also vor dem folgenden Szenario stehe: 25 Nutzer, ein W2K3 Standard Server ist bereits vorhanden aber die Ausgaben für den SBS kann und möchte der Kunde nicht tätigen (würde ja schliesslich einen weiteren Server voraussetzen und natürlich auch die entsprechenden CALs, die beim SBS nicht ganz billig sind). Das Mailing wird über eine Internet Appliance abgewickelt, die sich gleichzeitig um den Virenschutz der Mails kümmert. Das ist nur ein Beispiel, wie es mir bei einem unserer Kunden sofort einfallen würde. Was spricht also wirklich für den SBS und was gegen PSF? Auf der einen Seite ist PSF sicher nicht die Power Lösung. Auf der anderen Seite werden aber nicht alle Bestandteile von Exchange benötigt. Also würde ich aus naiver Sichtweise erstmal für PSF plädieren. Gibt es wirklich DAS Killerargument bei einer Nutzerzahl größer 10?

Mich würde mal interessieren, wer von euch schon Public Sharefolder eingesetzt hat bzw. überhaupt kennt und ob es wirklich die "kleine" Alternative zum Exchange ist. Wichtig vor allem, läuft das Ganze auch in größeren Umgebungen stabil?

Acronis sichert auch im laufenden Betrieb. Ich persönlich ziehe aber ein Image mit der eigenen Boot Funktion von CD vor. Deploycenter kann es, IMHO, nicht...

Na ja ganz so einfach ist es nicht. Die Installation der Anwendung geschieht in der Regel nachdem der Server frisch ist und die Terminal Dienste installiert wurden. Sämtliche Anwendungen installiert man korrekterweise im Installationsmodus, sonst sind Probleme vorprogrammiert! Eine Deinstallation der Terminal Dienste kannst Du sicher durchführen. Die andere Frage ist, ob die Probleme bei einer erneuten Installation der TS Dienste dann nicht erst wirklich anfangen... Ich würde von der Maschine vorher ein Image ziehen.

Was bei David V8 z.B. immer der Fall ist. David Nutzer sind nichts anderes als die Domain Nutzer. Wenn sich also Nutzer Heinz an regelmässig an 10 Maschinen anmeldet bekommt er im DIC auch seine Archives... Das einzige was mir an Tobit nicht gefällt ist der Support, der mit seinen Paybits ein Griff in die Kloschüssel ist! Unter Service verstehe ich jedenfalls etwas anderes.

Für Terminal Server oder (wie in unserem Fall) Citrix MetaFrame Server sind Images oftmals der einzige Rettungsanker den man hat, wenn die Installation von Anwendungen nicht so verläuft wie sie soll. Auch vor dem Einspielen kritischer Patches macht ein Image immer Sinn. Wir haben mit Deploy Center und Acronis True Image Server sehr gute Erfahrungen gemacht. Sobal eines der Image Programme auf einem Server nicht lief konnten wir bis jetzt immer mit dem anderen ein Image erstellen... Mit einem Image kann man, meiner Meinung nach, beruhigter Schlafen. Natürlich solche man die Sache entsprechend pflegen, wenn man einmal damit angefangen hat.

Generell kann ich erstmal von der Kombi DC und TS abraten... Wenn es irgendwie geht würde ich an Deiner Stelle den bereits vorhandenen W2K3 Datenbankserver zum DC machen. Dann wird es auch auf eine In-Place Mirgation hinauslaufen. Von einer Installation der Drucker auf dem TS rate ich auch ab. Clientseitig werden alle Drucker in die Session gemappt, sodass auf dem Terminal Server lediglich die entsprechenden Treiber installiert werden müssen. Solange ein lokal am TS installierter Drucker nicht wirklich benötigt wird, sollte er auch nicht installiert werden. Wichtig bei der TS Lizenzierung ist, dass sie in einer W2K3 Domain auch auf dem DC laufen muss. Achte bei einem späteren Umzug der TS Lizenzierung darauf, dass der DC den neuen Lizenzserver auch schluckt.

Mit dem alten Aktivierungscode wirst Du nicht weiter kommen, da dieser Code mit jeder Installation neu generiert wird. Wann Du den alten Server deaktivierst sollte egal sein. Es empfiehlt sich jedoch den Server erst zu deaktivieren, nachdem der TS den neuen Lizenzserver geschluckt hat.

Installation und Einrichtung des Lizenzierungsdienstes auf dem neuen Server, Deinstallation der Lizenzierungsdienstes auf dem alten Server. Gegebenenfalls feste zuweisung des TS Lizenzierungsservers über die Registry... siehe ältere Beiträge zu diesem Thema.

Also sind sie doch ausgeblendet? ;) Wie schaut es mit Änderungungen an anderen GPOs aus, greifen die?

Bei Größenordnungen von 20 - 30 Nutzern setzen wir auch dual CPU Maschinen mit 4GB RAM ein (ebenfalls W2K3). Der Speicherriegel mehr oder weniger macht die Kiste auch nicht billiger/teurer.

Also, den eigentlichen Server, der mal Server1 (war ein Novell Server) hiess gibt es nicht mehr. Dieser wurde durch einen W2K3 Server ersetzt, der einen anderen Namen bekommen hat. Was nun also rechtpraktikabel wäre ist, dass man den Clients vorspielen kann dass der neue Server auch Server1 heisst, obwohl er eigentlich Server2 heisst. Das hat einfach etwas mit eingerichteten Verknüpfungen zu tun, die natürlich immer noch auf den alten Servernamen verweisen... Mit dem CNAME geht es nicht, da besagte Fehlermeldung erscheint. Und einfach an der Registry rumspielen ist momentan nicht möglich...

Hmmm ist aber wie bereits erwähnt für W2K. Da es mit SP3 gefixt wurde könnte man wohl annehmen, dass es für den W2K3 keinen Patch gibt. Also ist die Frage, ob es reicht, den entsprechenden Registry Value zu setzen... Jedenfalls keine "Lösung", die man mal einfach an einem produktiven Server ausprobiert... mal schauen. Wäre es per DFS auch möglich via UNC auf den DFS Stamm zuzugreifen?

Wenn ich dann unter Start --> Ausführen auf \\Server1 gehe bekomme ich die folgende Meldung: Verbindung wurde nicht hergestellt, weil ein identischer Name bereits im Netzwerk vorhanden ist. Wählen Sie "System" in der Systemsteuerung, um den Computernamen zu ändern, und versuchen Sie es erneut. Den Server1 gibt es jedoch definitiv nicht mehr... nur eben momentan über den CNAME

Da es sich bei dem Server um einen DC handelt würden wir dies nur im Falle eines Atomkrieges in Erwägung ziehen, wenn Du verstehst was ich meine.... ;)

Hallo Zusammen, ist es möglich, dass man Windows Clients irgendwie dazu bringen/zwingen kann zu glauben das der Server mit der eigentlich richtigen Bezeichnung doch anders heisst? Beispiel: Verknüpfungen die auf einen UNC Pfad des Servers (Name = Server1) verweisen funktionieren nicht mehr, wenn ich alle verknüpften Dateien auf den neuen Server (Name = Server2) kopiere, Server1 platt mache und meine Verknüpfungen (die auf den Clients liegen) starte... Logisch, da der Servername sich geändert hat und der Server1 ja garnicht mehr existiert. Gibt es trotzdem eine Möglichkeit den Clients (9x bis XP) vorzuspielen, dass Server2 eigentlich Server1 ist?

Du benötigst für den 2. Server eine Anzahl X an CALs und zusätzlich eine Anzahl X an TS CALs...

Wie sieht das forwarding aus?

Ja, ist leider so...

Das habe ich schon mitbekommen... ;) Es war auch nur ein Beispiel. Ob jetzt MetaFrame oben drauf sitzt oder nicht spielt nicht unbedingt die Rolle. Es ist halt in diesem Fall nicht gerade förderlich gewesen, da wieder ein zusätzliches Stück Software auf dem Server lief/läuft. Acronis True Image Server und Deploy Center von Powerquest (dürfte jetzt Symantec gehören). Bis jetzt hat zumindest immer eines von beiden Programmen auf den Servern funktioniert...

Einer unserer Kunden hat momentan noch diese "tolle Umgebung". Und dort lief bis vor kurzem wirklich nur dieser eine Server zusammen mit zwei alten Novell Maschinen. Dann noch Citrix MetaFrame oben drauf und perfekt ist die heisse Kiste. Der verantwortliche EDV Betreuer konnte erst dann einigermaßen schlafen als wir das erste mal ein Image von seine Kiste gezogen haben. Wie er es so lange geschaft hat das Ding am laufen zu halten ist mir zwar bis heute noch nicht ganz klar aber es ist das perfekte Beispiel dafür warum man es so nicht macht. Als wir später mal das Feature Release 3 für MetaFrame installiert haben war das Erste was wir nach dem Neustart sehen durften ein dicker fetter blue Screen, nachdem wir die CMC öffnen wollten... Das Image war unsere Rettung. Im übrigen werden auch bei VMWare die Lizenzkosten für das Serverbetriebssystem und die CALs anfallen. Von daher ist die Ersparnis minimal und die Ausfallsicherheit kein Bisschen besser...

Wenn ich es richtig mitbekommen habe haben wir hier den umgekehrten Fall, nämlich einen TS der ohne Domain arbeitet. Bei einer Nutzerzahl dieser Größenordnung sicher nicht ungewöhnlich. Aus Erfahrung kann ich meinen Vorrednern nur zustimmen. Wenn Dein Server läuft dann lass ihn laufen. Glaub mir, Du wirst Dir sonst recht schnell die Zeiten der geringen CPU Auslastung zurückwünschen... Und die CPU Auslastung wird dann Dein kleinstes Problem sein. Du hast zwei Alternativen, von denen eine nur wirklich zu empfelen ist: 1. Du machst den TS zum DC und freust Dich auf das was da kommt. Wobei Du Dir unbedingt vorher ein Image vom Server ziehen solltest, es sei denn Du hast die nächsten Tage nichts vor.... ;) 2. Du stellst Dir einen besseren PC hin, den du zum DC machst. Vergiss dann aber nicht die Terminalserverlizenzierung... die muss dann auf den neuen DC. Die erste Möglichkeit ist die mit der Du den "meisten Spass" haben wirst. Die zweite die teurere, da das Serverbetriebssystem und ggf. die Hardware angeschafft werden muss. An Deiner Stelle würde ich mir noch mal überlegen ob es nicht auch ohne DC geht...

Ich würde mich an Deiner Stelle an den ThinClient Hersteller wenden und fragen ob ein Update für die TC verfügbar ist. Aber normalerweise ist es schon ein Unding, dass die Dinger kein RDP Client mitbringen...