Wolke2k4

Such mal im Froum danach, ich glaube das Thema hatten wir schon mal...

Da wir ja festgestellt hatten, dass es sich bei Deiner Lizenzierung eigentlich um per User TS CALs handelt (ich gehe mal davon aus, dass der/die TS jetzt wieder richtig eingestellt sind) ist das auch richtig so... Bei der per User Lizenzierung werden derzeit weder temporäre noch permantente TS CALs ausgestellt (siehe ältere Beiträge zu diesem Thema hier im Forum). Deine temp Device TS CALs werden also dementsprechend ablaufen aber die User werden sich trotzdem verbinden können, vorrausgesetzt die TS sind per User lizenziert...

Hmmm, wenn die Netzlaufwerke per Script für die User erstellt werden sollte dies auf dem Presentation Server auch geschehen. Somit sollten Sie auch Zugriff auf die Netzlaufwerke und dementsprechen auf die xls Datei haben. In Deinem Fall möchtest Du jedoch, dass der Nutzer zunächst lokal die Datei doppelklickt und dann die Datei bspw. mit dem freigegebenen Excel auf dem Presentation Server geöffnet wird. Mir ist ehrlich gesagt kein Weg bekannt das umzusetzen. In der Regel ist der "normale" Weg der umgekehrte (also Nutzer öffnet published Excel und öffnet dann die Datei).

Mein Post sollte in keinstern Weise irgendwie persönlich angreifend wirken, das nur vorne weg... ;) Mir war schon fast klar, dass ein Kommentar von Wegen "Trenne dies und das", "Lasse nie dies und das zusammen laufen" kommen würde. Solche designtechnischen Fragen/Ansichten sind alle gut und schön und mögen auch irgendwo ihre Berechtigungen haben (ich selber würde es nicht anders machen) nur vergessen viele dabei eines. Der Kunde (zumindest 95% unserer Kunden) hat in der Regel nie Geld (gerade was den im kommunalen Bereich betrifft muss ich das ja nicht weiter ausführen). Und in den wenigsten Fällen kann man sich wirklich eine "Traumumgebung" hinbasteln, in der jeder Server nur für einen einzigen Zweck gedacht ist (DC macht nur DC, Datenbank Server macht nur SQL, Oracle oder wie sie alle heissen, auf dem Mail Server läuft nur Exchange...). Bei uns bzw. unseren Kunden ist es sehr oft der Fall, dass wir aus einer Kiste eine "Eierlegendewollmilchsau" machen müssen. Und was meinst Du, was wir beim Kunden schon für Kisten gesehen haben, wo wir einfach nur gestaunt haben, dass die überhaupt so laufen wie sie laufen? Ich mag es auch nicht, wenn ein Server nicht sauber läuft, weil ich ganz genau weiss, dass es früher oder später den großen Knall geben wird. Und gerade bei Terminal Servern muss man immer noch ein Stück mehr vorsichtiger und vor allem sorgsamer an die Sache gehen, weil wenn die Kiste nicht läuft ist Schluss mit Lustig. Im Grundtenor des Thread ging es auch nicht darum, irgendwelche Probleme mit täglichen Reboots zu lösen. Es ging einzig und allein um die Tatsache/Frage, wie sinnvoll ein regelmäßiger Reboot eines Terminal/Citrix Servers ist. Und der regelmäßige Reboot bleibt in einer TS/Citrix Server Umgebung einfach unerlässlich und hat auch rein garnichts mit lösen/verstecken/umgehen von Problemen zu tun sondern ist wohl vielmehr ein lästiges Problem und wahrscheinlich auch "by design". :) Sorry, wenn ich ein wenig vom Thema abgewichen bin...

OK Beispiel: Ein 3-4 Jahre alter Server, mit "frisch" installiertem W2K3 (Eventlog normalerweise immer im grünen bzw. blauen Bereich ). Er ist DC, repliziert sich via VPN mit einem zweiten DC. Installiert ist außerdem noch Veritas BE 9.1, SP1 und eine Ausschreibungssoftware, die auf einem abgespeckten SQL Server läuft. Der Server lief ca. 2-3 Monate ohne Probleme. Am Tag X sicherte der Gute mit BE auf einmal nicht mehr, obwohl es vorher ohne Probleme lief. Im Eventlog steht nur, dass der Job nicht ausgeführt werden konnte... bla bla bla. Kunde soll Server neu starten, hat er gemacht. Nächsten Tag Datensicherung kontrolliert, Datensicherung lief... im Event Log alles wieder sauber. Nächstes Beispiel: Der Kunde nutzt eine, wenn auch etwas ältere und schwachbrüstigere, Maschine als Webserver. Das Maschinchen läuft seit ca. 3 Monaten ununterbrochen (eigentlich wären es 8 aber wegen eines anderen Problems wurde bereits neugestartet, um ihn als Fehlerquelle auszuschliessen) und ohne Probleme. Tag X, der Kunde ruft an weill er nicht auf die Maschine kommt. Was war? Der Rechner stand mit einem Blue Screen da und sah schön aus... Aussagen wie die obigen kann ich beim besten Willen nicht nachvollziehen, da die Erfahrung bisher immer gezeigt hat, dass jedes noch so unbedeutende und nicht erklärbare Phänomen nicht immer eine nachvollziehbare Ursache hat. Aber wenn Du mir sagen kannst, wo man z.B. bei dem Problem mit der Datensicherung ansezten kann bin ich gern für Vorschläge offen. Und um noch mal auf das eigentliche Thema zurückzukommen, nämlich Citrix bzw. Terminal Server. Auch auf die Gefahr hin mich unbeliebt zu machen aber dazu sage ich nur folgendes: Wer behauptet einen Terminal Server/Citrix Presentation Server, auf dem jeden Tag 30 - 40 Nutzer arbeiten 1 - 2 Jahre ohne Reboot am laufen zu halten hat entweder keine Ahnung von der Materie, ist selber nur Citrix/Terminal Server Anwender oder hat noch nie mehr als eine Terminal Server Umgebung administriert, auf der mehr als nur Office und Co. laufen. Wir haben Terminal Server bei Kunden im Einsatz, da laufen teilweise 10 - 15 Anwendungen drauf. Und wenn ich von Anwendungen spreche meine ich auch Anwendungen (beispielsweise kommunale Software wie MESO, CityNT, CIP oder Krankenkassensoftware und und und). Allein von der Druckproblematik (da werden Druckjobs von bis zu 1.000 bis 3.000 Seiten angeschubst) ist ein Terminal Server ohne Einsatz von Third Party Produkten nur schwer zu handlen und ohne Reboot über längere Zeit einfach nicht konstant und stabil am laufen zu halten. Was an einem automatischen Reboot :suspect: und :wink2: sein soll ist mir auch nicht ganz klar. Aber es soll ja Admins geben, die Ihre Server rund um die Uhr betreuen und diese entweder Vormittags um 10.00 Uhr starten, wenn alle Welt die Anwendungen/Datenbanken nutzt oder aber Morgens um 4.00 Uhr den Server manuell starten, nachdem die Datensicherung gelaufen ist.

Welches BIOS??

Und wie dich das weiterbringt! Denn nur der FVS kennt die entsprechenden Subnets. Ein Routing kann, wie Christoph35 bereits beschrieben hat, nur dann funktionieren, wenn der Quell Client die Pakete an ein Gateway schickt, was sich im selben IP Netz befindet wie der Client. Eine "Ausnahme" stellen VPN Verbindungen wie Deine dar, die aber eigentlich keine Ausnahme sind. Wahscheinlich wird es bei Dir so sein, dass Du über ein lokales Endgerät eine Verbindung zum Internet herstellst und Dich, wie Du ja bereits beschrieben hast, dann per VPN Software mit dem FVS Netz verbindest. Es wird Dir mit an Sicherheit grenzender Wahscheinlichkeit eine IP vom FVS verpasst, dort müsste gleichzeitig auch das Gateway für das Routing in die 53-er Subnetz hinterlegt sein. Ein ipconfig/all bei aufgebauter VPN Verbindung müsste Klarheit in die Sache bringen. Wie schaut es eigentlich mit einem tracert in die 53-er Subnets aus? Mit was für einem Endgerät stellst Du eine Verbindung zum Internet her?

Citrix hat den automatischen Neustart nicht umsonst mit eingebaut... Und das mit dem 1- 2 Jahre durchlaufen halte ich ehrlich gesagt für mehr als übertrieben. Obwohl, wenn ich Solitär und Co. mit dem Presentation Server bereitstelle erziele ich vielleicht auch solche Laufzeiten... Selbst ein normaler Windows Server zeigt spätestens nach 2-3 Monaten mal eine kleine Macke, die durch ein Reboot behoben werden kann. Am Ende kommt es immer auf die Umgebung an, wie stark werden die Server beansprucht, was für Software läuft darauf usw. Ohne einen regelmäßigen automatischen Neustart geht es meist nie.

Von was für einem Problem sprechen wir hier genau? Privater Key und Schlüssel hört sich stark nach SSL an...???

Wir hatten bei einem Kunden ein ähnliches Problem. Gleiches Szenario: Außenstelle über WLAN angebunden, in der Zentrale ein Citrix Presentation Server. Ein Firmwareupdate der AP brachte dann Besserung, die Verbindung ist seitdem stabil....

Guck mal auf dem Server unter C:\WINDOWS\system32\spool\PRINTERS, ob da noch irgendwelche Druckjobs drin hängen. Wenn ja alles rauslöschen und Server neu starten.

Ich glaube die Frage hatten wir hier schon mal, einfach mal im Forum suchen. Wenn echte Interesse besteht kann ich Dir nur empfehlen Dich mit einem Consultant in Verbindung zu setzen, die können Dir die Latte an Vorteilen/Nacheilen rauf- und runterbeten. Es kommt auch immer auf die jeweilige Umgebung und das zu erwartende Wachstum der Serverfarm an.

Normalerweise sollte die temp TS CAL bei der zweiten Anmeldung des Clients für den diese ausgestellt wurde in eine permanente umgewandelt werden... einfach mal ausprobieren.

Schau mal hier nach, am besten auf englisch... ;) Bei MS anrufen und Patch schicken lassen.

Wenn das Routing über einen Router im 53-er Netz geht muss das Routing dort auch für alle möglichen Routen bekannt gemacht werden. Die Subnetze müssen natürlich auch geroutet werden, wenn dies gewollt ist.

Mir ist kein Weg bekannt... Ansonsten musst Du halt abwarten. Wenn Du den Lizenzserver richtig eingerichtet hast werden die permanenten Lizenzen schon noch ausgestellt. An der Funktionalität ändert sich nichts. Oder gibt es einen besonderen Grund für die Verkürzung?

Die Antwort lautet: per Device, da bei der per User Lizenzierung keine temp Lizenzen ausgestellt werden. Also ran an den TS und per User Lizenzierung einstellen. Danach ist Schluss mit den Fehlermeldungen...

Ein TS sucht selbstständig nach einem Lizenzierungsserver. Ist der Lizenzierungsserver aktiviert, stellt er zunächst temporäre TS CALs aus, die 90 Tage (nicht 120) gültig sind. Die 120 Tage gelten nur, wenn der TS keinen Lizenzierungsserver finden kann (allerdings nur bei W2K3). Wie hast Du Deine TS lizenziert (User oder Device)?

Der Meinung war ich auch mal, bei W2K3 ist es jedoch egal (siehe mein Link zum TS Lizenzierungs Whitepaper). Und wenn es Probleme beim Suchen mit dem TS Lizenzierungsserver gibt hinterlegt man Ihn in der Registry des TS.

Das 162.168.0.2-er Netz muss ebenfalls mitgeteilt bekommen, wie es die 53.101.103.0-er Subnets erreichen kann. Wenn das nicht über Routing Protokolle geschieht dann halt statisch... Nur so mal nebenbei bemerkt ist diese Config nicht die "schönste", denn sämtliche Netze die Du verwendest sind öffentliche IP Netze...

Warum einfach, wenns auch kompliziert geht nicht? ;) Habe dieses interessante Szenario zwar selber noch nicht ausprobiert aber ich kann mir schon vorstellen, dass es nicht ohne weiteres umzusetzen ist. Und wieso überhaupt über RDP und nicht per ICA? Hast Du mal versucht die CMC als Anwendung zu veröffentlichen? Die andere/einfachere Alternative ist die CMC direkt am Client zu installieren...

Sprechen wir eigentlich von der Faxware oder von David? Bei David wird der Drucker während der Clientinstallation mit eingerichtet. Bei der Faxware, mit der ich bis heute leider noch nicht die Ehre hatte, kann es ja nur ähnlich laufen... Du kannst es ja noch mal mit einer Clientinstallation im Installationsmodus probieren.

Hast Du das DIC im Installationsmodus installiert? Wir haben die V8 ohne Problem auf einem TS installieren können, samt Fax Drucker...

Ein eigenständiger Server für die TS Lizenzierung macht erst bei größerer Zahl von TS wirklich Sinn, da die beanspruchten Ressourcen der Lizenzierung wirklich nur minimal sind. Im übrigen kann man den Lizenzierungsserver auch per Script zuweisen lassen (siehe hier --> termservlicensing.doc).

Einen TS Lizenzierungsserver brauchst Du in jedem Fall. Da die TS CALs des AP per User sind reicht es, wenn du den TS Lizenzierungsserver aufsetzt und deinem TS sagst wo er seinen Lizenzierungsserver finden kann, wenn er dies nicht selbstständig kann. Standardmäßig erlaubt ein W2K3 TS Anmeldungen von Clients bis zu 120 Tage auch ohne TS Lizenzierungsserver. Sinnvoll ist es aber trotzdem den Lizenzierungsserver rechtzeitig (in der Regel immer vor Installation des TS) aufzusetzen.