Jump to content

Wolke2k4

Members
  • Gesamte Inhalte

    2.235
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Wolke2k4

  1. Durch entsprechende GPO Settings und durch eine lokale Anmeldung am TS, mehr fällt mir erstmal nicht ein...
  2. Normalerweise hat ein TS User mit Defaultberechtigungen nicht die möglichkeit sich irgendwelche Sessions zu krallen. Es irritiert zwar viele, dass man im Kontextmenü die entsprechenden Punkte auswählen kann jedoch gibt es beim Linksklick eine entsprechende Access Denied Meldung... Mit welchen Berechtigungen arbeitet ihr denn auf dem TS?
  3. Schade, dass Du nicht verstehen willst... Mir ist klar, dass Du von Deinem Standpunkt nicht abkannst, schon aus Prinzip und Charakterfrage nicht. Aber für das Forum und die Qualität des Selbigen ist es echt schade.
  4. Was für ein Benutzer soll er schon sein? Wenn er nicht in der Lage ist das Office zu starten wird er weder zu dem einen noch zu dem anderen oder nicht? Was er dann für ein Nutzer ist steht nicht in den PURs, wahrscheinlich auch deswegen, weil es nicht relevant ist. An dieser Stelle verlässt er "den Zug der zum Ort Lizenzierungspflicht" fährt. Der kausale Zusammenhang zwischen: "Gerät wird erst lizenzpflichtig, wenn ein Nutzer im Sinne der PUR Haupt- bzw. Nicht-Hauptnutzer ist." ist doch (eigentlich) offensichtlich. Anderes Beispiel: Du hast 10 PCs. Ein TS spielt hier keine Rolle, den gibt es in diesem Beispiel nicht. 5 PCs installierst Du mit dem Office, da Du 5 Office Lizenzen gekauft hast. Soweit wäre dies zu 100% lizenzkonform, richtig? Wir haben insgesamt 10 Nutzer, von denen zunächsteinmal 5 Hauptnutzer wären, richtig? Die anderen 5 Nutzer sind weder Haupt- noch Nicht-Hauptbenutzer im Sinne der Office PUR, richtig? Einer der "5 Nicht Office Nutzer" (sie arbeiten mit Open Office) muss sich über Remotezugriff auf einen der Office PCs schalten, weil er dort mit einer Anwendung arbeiten, die in keiner Weise mit dem Office zu tun hat. Zusätzlich hat der Administrator die lokale Berechtigungsstruktur auf dem PC so angepasst, dass auf alle Unterordner von C:\programme (hier befindet sich auch das Office) kein Zugriff von Nutzern außer dem Nutzer möglich ist, der auch gleichzeitig Hauptnutzer des PCs ist. Warum er dies getan hat sei einfach mal dahingestellt, der Fakt steht einfach. Logischerweise hat nun der zugreifende Nutzer zwar die Möglichkeit die Anwendung (die nichts mit dem Office zu tun hat), die er über Remotezugriff benötigt zu starten. Er kann nur diese Anwendung starten, nichts weiter. Jetzt komme ich und Frage Dich: Wird trotzdem eine Office Lizenz für das Gerät des zugreifenden Nutzers (der das Office garnicht benutzen kann) fällig? Und komm mir jetzt bitte nicht mit der Antwort: "Das spielt keine Rolle, denn das zugreifende Gerät ist lizenzpflichtig..."
  5. Hmmm... das wird ein langer Thread... Also 2 Situationen: 1. Ein Nutzer kann das Office starten, folglich ist er entweder Hauptnutzer oder Nicht-Hauptnutzer 2. Ein Nutzer kann das Office nicht starten, folglich ist er weder Haupt noch Nicht-Hauptnutzer. Nur ein Hauptnutzer oder ein Nicht-Hauptnutzer kann/darf von einem Gerät aus zugreifen, dass lizenzpflichtig ist? Stimmen wir da beide überein?
  6. Niemand maximal der Admin, der aber, logischerweise, nicht am TS arbeitet. Daher wären Nicht-Hauptbenutzer alle Nutzer, denen ein Zugriff auf das Office möglich ist. Alle Nutzer, die keinen Office Zugriff haben, weil er technisch verhindert wird sind keine Nicht-Hauptbenutzer im Sinne der PURs. Daher unterliegt deren Gerät nicht den PURs für das Office... Das ist die logische Schlussfolgerung auch aus Deinen Ausführungen. Das ist aber auch das, was ich schon seit mehreren Posts herunterbete.... Aber ich bin auf Deine weiteren Ausführungen gespannt, denn bisher habe ich nichts Neues gelesen...
  7. Vollkommen...
  8. An der Verknüpfung kann es auch nicht liegen, denn die ist immer gleich, egal ob mit oder ohne Domain Admin Rechten. Das es über RDP/ICA nicht gehen soll ist mit nahezu 100% auszuschließen da: 1. Die Anwendung auch als Domain Admin über ICA/RDP läuft 2. Die Anwendung für die Nutzer schon mal im TS Betrieb lief. Leider weiss vor Ort niemand mehr, warum und wie es damals ging und warum es heute nicht mehr geht. Ich lasse es aber trotzdem noch mal im Client-Server Betrieb testen, man weiss ja nie. Ansonsten wäre einzig die Datenbank noch ein Ansatzpunkt. Wenn diese in einem anderen als den Programmverzeichnis Pfad liegt wäre das zur prüfen. Update: Mit der Andwendungsexe werden auf dem Server, auf dem das Programmverzeichnis liegt zwei Exen gestartet. Eine Exe ist für die Phoenix Datenbank, die andere für... was weiss ich... Ich denke, dass hier der Hund begraben liegt, denn normalerweise hat man als normaler User auf einem Server/Domain Controller nicht das recht einfach so Exe Dateien auszuführen, würde ich mal vermuten. Eine Option wäre vielleicht auch das Programmverzeichnis einfach mal auf den TS zu kopieren und von dort auszuführen. Mal schauen, was man da kaputtspielen kann... :D
  9. OK, dann erkläre mir das: :confused: Hmmm, sei so nett und und schreibe kurz die Seite der PURs auf, auf der dieses geschrieben steht, denn ich muss es irgendwie übersehen haben... Wie gesagt, beim Exchange habe ich auch die Möglichkeit von jedem Gerät aus auf den Exchange Server zuzugreifen... Gerade so und mit viel Anstrengung :o
  10. Kommentiere es oder lasse es sein. Fakt ist folgendes im Terminal Server Betrieb des Office: 1. Jeder TS benötigt eine Office Lizenz, da das Office auf diesem Gerät installiert ist. 2. Ein über Remtote zugreifendes Gerät kann erst dann lizenzpflichtig werden, wenn über dieses der Zugriff auf das Office möglich ist. Dabei ist es unerheblich, wie der Zugriff möglich bzw. nicht möglich ist. Sobald das Office von diesem Gerät genutzt wird, wird das zugreifende Gerät lizenzpflichtig! Damit die Verwirrung perfekt ist, sagt Microsoft (wohlgemerkt nicht ich), dass das Gerät erst dann lizenzpflichtig ist, wenn ein Nicht-Hauptbenutzer das Office benutzt. Es handelt sich hierbei um einen kausalen Zusammenhang, denn kein Gerät kann im TS Office Betrieb lizenzpflichtig werden, wenn es nicht von einem Nutzer benutzt wird, der auch tatsächlich Office nutzt. Wäre dies nicht so, müsste pauschal jede XP Maschine, jedes Gerät, das einen Citrix/einen RDP Client installiert hat Office, lizenzpflichtig werden, da ja (theoretisch gesprochen) von jedem dieser Geräte eine Office Nutzung auf dem Terminal Server möglich ist. In den Produktnutzungsrechten steht jedoch explizit, dass ein Gerät nur dann eine gesonderte Lizenz benötigt, wenn ein Nicht-Hauptbenutzer das Office über einen Remotezugriff benutzt. Kann ein Nutzer dieses nicht, weil ihm die Berechtigungen dazu fehlen wird sein zugreifendes Gerät folglich nicht lizenzpflichtig. Das wäre es erst dann, wenn sich ein Nutzer mit Office Zugriff darauf anmelden würde. Verhindere ich dies nun durch eine Dienstanweisung scheint dem PUR damit genüge getan, denn die Vorraussetzung, dass das Gerät nicht lizenzpflichtig ist ist damit gegeben. Unabhängig davon ist es natürlich mein Problem, wenn meine Nutzer die Dienstanweisung nicht einhalten. Selbstverständlich wird dann das Gerät wieder lizenzpflichtig. Ich verdeutliche es gern noch mal anhand anderer MS Lizenzen: Beispiel Exchange, ebenfalls pro Gerät lizenziert: Jedes Gerät von dem aus auf den Exchange zugegriffen wird, ist lizenzpflichtig. Nun gibt es aber noch PCs, von denen aus nicht auf einen Exchange Server zugegriffen wird. Outlook ist zwar installiert, aber kein Exchange Konto hinterlegt, die E-Mails werden vom Provider direkt abgeholt. Hier sagt auch niemand, dass ich auch technisch sicherstellen muss, dass die Geräte, die keine Lizenz haben, sich nicht auf den Exchange verbinden dürfen... Praktisch möglich wäre der Zugriff auf den Exchange jedoch von allen PCs. Trotzdem muss ich eben nicht alle PCs mit Exchange Lizenzen ausstatten... Beispiel Terminalserverzugriff, per User, per Device Lizenzierung: Auch in diesem Fall ist von jedem PC, mit jedem Nutzer der Zugriff auf den Terminalserver möglich, theoretisch. Trotzdem wird nur das Gerät, der User lizenziert, dass auch tatsächlich einen Zugriff auf den TS hat. Hier hat Microsoft sogar einen technischen Mechanismus eingebaut, der das Lizenzrecht klar reglementiert, ohne Wenn und Aber. Und Microsoft hat sogar ein "kleines Bonbon" eingebaut und sagt nicht gleich: "Sobald Du (Gerät oder User) dich zum TS verbindest bist du lizenzpflichtig. Nein du bekommst erst bei der zweiten Anmeldung am TS eine TS CAL (temporär oder permanent, je nach Umgebung und TS CAL Token Verfügbarkeit). Nun erkläre mir noch jemand, was ich da falsch verstehe oder falsch sehe. Kann ja sein, dass ich etwas übersehen oder falsch verstanden habe. Nobody is perfect. Wenn ich einen Fehler gemacht habe stehe ich dazu...
  11. Wolke2k4

    HP Thin Client

    Reicht vollkommen aus, wenn Du keine Killerapps über RDP nutzt, die Deinen Bildschirm in Sachen Grafik explodieren lassen. Wenn Du einen DHCP Server im Netz hast kannst Du Dir diesen Punkt schon mal sparen. Neben den Einstellungen des Connection Administrators musst Du noch einige Feinheiten anpassen, ist aber alles nicht der Hit. Das macht man zwei, drei Mal und kann es dann im Schlaf.
  12. Hallo und Danke für die Antworten. Das Programmverzeichnis wie auch die Freigabe des selbigen auf dem Server ist mit den richtigen Berechtigungen ausgestattet. Ich habe die Rechte extra noch mal bis nach unten vererben lassen, ohne Erfolg. Regmon und Co. habe ich jeweils in der TS Session gestartet. Alle drei Programme (Filemon, Regmon, DPW) habe ich mit administrativen Rechten ausgeführt (geht ja auch nicht anders) leider auch ohne den "Feind" erkennen zu können. Und ich denke schon, dass ich da sehr genau war. Die Idee mit dem Filemon und Regmon auf dem Programm Server ist einen Test wert. Ich dachte eigentlich immer, dass beide Tools den Zugriff entsprechend mittracen würden, wenn er auch auf das Zielsystem notwendig wäre. Aber wenn es ein Unterschied ist teste ich das gern. Probleme mit den Berechtigungen auf die Registry des Terminalservers schließe ich aus den von mir und Userle genannten Gründen aus. Wenn der User lokale Admin Rechte hat sollte er auch in die Registry schreiben können. Da sich das Programm auf einem DC befindet schliessen sich Tests mit lokalen Nutzerrechten auf der Maschine aus. Der DPW zeigt, interessanterweise, nur Abhängigkeiten der Exe zu Files, die im Windows Verzeichnis (Winnt) liegen an. Auch hier habe ich die Rechte entsprechend mit "Jeder Vollzugriff" zum Test angepasst, leider negativ. Die Anwendung nutzt, wenn ich den Kunden richtig verstanden habe, eine Phoenix Datenbank und greift irgendwie über COM auf den Programmserver zu. Vielleicht fällt euch dazu noch was ein?
  13. Schade, wenn es "eng" wird kommt immer das Schlagwort Polemik. Dabei habe ich nur Deine Aussagen weitergesponnen nichts weiter. Wenn Du das als polemisch ansiehst... Na dann wäre das doch geklärt, das ist doch was ich wissen wollte. Wenn ich das Office per NTFS so hinbiege, dass es bestimmten Nutzern nicht möglich ist damit zu arbeiten und ich per Dienstanweisung ausgebe, dass an den PCs 350 bis 400 niemand arbeiten darf der Office Zugriff hat, bin ich doch aus dem Schneider und benötige lediglich 349 + die Anzahl der Terminal Server Lizenzen. Nach Deiner Argumentation hörte es sich teilweise so an, als ob man dazu gezwungen ist Third Party Hilfsmittel einzusetzen um dieses zu realisieren. Tut mir leid für Dich. Mir hat es in einigen Punkten Klarheit verschafft. Das ich die Regeln verstanden habe hast selbst Du bestätigt. Ich tu mich nur schwer mit Behauptungen, die so nirgends in den "Regeln" stehen. Wenn man dann auf Nachfragen zu diesen Behauptungen mit Totschlagargumenten abgespeist wird, ist das dem Thema irgendwie nicht dienlich. Ich bin nicht wie andere Leute, die alles als Gottgegeben hinnehmen. Ich will die Dinge verstehen und hinterfrage warum sie so sind wie sie sind. Diese Eigenschaft hat durchaus seine Vorteile... Zu diesem polemischen Kommentar sage ich jetzt mal nichts... :p
  14. Ok...? Hier tut sich mir ein gedankliches Fragezeichen auf, denn von derartigen Maßnahmen ist in den PUR nicht die Rede. Es wird an keiner Stelle erwähnt, was man unternehmen muss, damit man nicht lizenzpflichtig ist. Es steht lediglich geschrieben, was passiert bzw. notwendig ist, wenn ein Benutzer (hier der Nicht-Hauptbenutzer) von einem Gerät über eine Remotesitzung auf die Software zugreift. Da nicht explizit geschrieben steht, was zu unternehmen ist, damit ein Benutzer/ein Gerät nicht lizenzpflichtig ist, sehe ich hier vielmehr Spielraum für Auslegungen. Was mich noch viel mehr verwundert ist, dass mit einmal der Lizenznehmer eine Third Party Software einsetzen soll, um auch technisch sicherzustellen, dass er nicht gegen das Produktnutzungsrecht verstößt. Zum Einen steht dies, wie bereits erwähnt, nirgends geschrieben, zum Anderen wäre es sehr fragwürdig, warum ausgerechnet Unternehmen mit Terminalserverumgebungen diesen Schritt unternehmen sollten und nicht auch Unternehmen mit der klassischen Client Server Umgebung. Denn auch in Letzterer ist es technisch möglich das Office auf mehreren PCs zu installieren und zu nutzen, ohne dafür extra bezahlen zu müssen. Und richtig einfach wird es, wenn das Produkt nichtmal online aktiviert werden muss... Eine MAC kann relativ einfach geändert werden, das steht ausser Zweifel. Gleichwohl wird sich wohl kaum jemand die Mühe machen ein solches Vorhaben in die Tat umzusetzen, weil es einfach Schwachsinn ist. Die eigentliche Frage, die sich mir stellt ist die nach dem: Wird ein Gerät in jedem Fall Office lizenzpflichtig oder nicht, wenn ich nicht auch technisch sicherstelle, dass nur die Geräte, die es sollen einen Office Zugriff erhalten dürfen. Der Lizenzgeber würde somit verlangen, dass ich ein Investition in ein Third Party Produkt tätige um sicherzustellen, dass sein eigenes Produkt korrekt lizenziert ist. Wenn ich dieses nicht täte, könnte ich nicht absolut sicherstellen, dass nur von einer gewollten Anzahl an Geräten die Office Nutzung möglich ist und müsste somit theoretisch jedes Gerät in meinem Unternehmen, welches eine RDP Session aufbauen und damit eine Office Nutzung möglich machen kann, mit einer entsprechenden Lizenz ausstatten.... Das wäre ja so, als wenn ich mir einen Auto ohne Fahrzeuggestellnummer kaufe und mein Autohändler mir sagt: Gehen Sie mal zur Polizei, legen Sie 300 Euro auf den Tisch und lassen Sie sich die Fahrzeuggestellnummer einstanzen, damit der Wagen auch zugelassen werden kann....
  15. Hallo, ich sitze hier an einem Problem, das eine einzige Anwendung betrifft. Die Anwendung wird über ein Netzlaufwerk mit einer Verknüpfung zur Exe gestartet. Der Nutzer arbeitet auf einem W2K Terminal Server und startet über eine ICA/RDP Session die Anwendung Das Problem ist, dass man als normaler Nutzer mit den "einfachen Berechtigungen" die Anwendung nicht starten kann. Das heisst, in gewissem Maße startet sie schon, denn das Anmeldefenster der Anwendung erscheint. Bei der Anmeldung an der Anwendung gibt es jedoch einen "Zugriff verweigert" Fehler. Mit Domain Administratorrechten und Organisations-Admin Rechten lässt sich die Anwendung komplett starten... Lokale Administrator Rechte für den Nutzer auf dem TS reichen nicht aus, es gibt weiterhin einen "Zugriff verweiter" Fehler. Dies lässt vermuten, dass der Nutzer erhöhte Rechte innerhalb des Netzes bzw. auf dem Server wo sich das Programm befindet, benötigt. Ich habe schon Filemon, Regmon und den Dependencywalker rangezogen um zu schauen, an wecher Stelle es haken könnte, leider ohne Erfolg. Hat sonst noch jemand eine Idee, was man in diesem Fall zum Tracing benutzen könnte? Support gibt es leider nicht mehr auf die Anwendung, der Kunde hat den Wartungsvertrag mit der Firma gekündigt...
  16. Dem stimme ich zu und würde aufgrund der bisherigen Informationen zu einer zentralisierten Lösung hinarbeiten. Den administrativen Aufwand in den Außenstellen kann man sich mit einem zweiten TS in Dland ersparen. Alles was in den Außenstellen bleibt sind PCs die auf die Serverfarm zugreifen. Idealerwiese ist der Einsatz von Thin Clients möglich, das erhöht noch mal die Sicherheit. Risiko und überdenkenswert ist natürlich die Abhängigkeit der Standorte in Bezug auf den Zugriff zur TS Farm. Hier sollte abgewogen werden, was höher zu bewerten ist. Die Vorteile der Zentralisierung oder die Nachteile/Arbeitsausfall bei Leitungsausfall. Auf der anderen Seite ist auch bei dezentraler Serverhaltung ein Ausfall nie ausgeschlossen. Die Probleme sind die gleichen, sie verlagern sich nur (standorttechnisch gesehen). Die Farm wird durch mindestens zwei TS redundant gehalten, die Problemkinder sind somit eigentlich nur die DSL Leitungen. Mit Citrix sollten alle angegebenen Leitungen für die Anwendungen ausreichen. Mir fallen spontan zig andere Hersteller ein, die solche Sachen auch bieten... ;)
  17. Korrekterweise müsste man eigentlich bei einem Szenario von 5 Terminal Servern und 400 zu erwartenden Office TS Sessions 405 Office Lizenzen kaufen, da neben den zugreifenden Geräten die Terminal Server als zu lizenzierenden Geräte ebenfalls eine Lizenz zugewiesen bekommen müssen. Soweit um das ganze zu veranschaulichen. Wenn ich im TS Betrieb beigehe und 50 von 400 Usern den Office Zugriff garnicht gestatte werden die von ihnen verwendeten Geräte auch nicht Office Lizenzpflichtig unter der Vorraussetzung, dass von diesen Geräten keiner derjenigen Nutzer eine TS Session aufbaut der/die das Office nutzen kann...
  18. Weil er 50 von den 400 Nutzer den Office Zugriff garnicht erst ermöglicht und dementsprechend garnicht erst in die Situation kommt die mehr als 350 Lizenzen kaufen zu müssen. Die Vorraussetzungen dafür hatte ich bereits beschrieben. Eindeutig und klar können die Bestimmungen garnicht sein, weil sie die Praxis garnicht abdecken (können). Würde man dies wollen wären die Produktnutzungsrechte 1000 Seiten lang und selbst dann gibt es immer noch ein Könnte/würde. Das ist wie bei Versicherungsbedingungen. Den Rahmen schaffen die Bedingungen wenns aber an das eingemachte geht ist jeder Pups auslegungssache, egal was in den Produktnutzungsrechten oder den Versicherungsbedingungen geht. Ich weiss, dass Du das anders siehst aber ich bin fest davon überzeugt, dass auch Du schon in Deinem Leben eine Sache anders ausgelegt hast als sie jemand anderes meinte ausgelegt haben zu wollen. Aber es geht auch garnicht so sehr darum sondern vielmehr um die Lücken und Möglichkeiten, die man sich selber schaffen und suchen muss. Moment... Du sprichst von PCs auf denen man das Office installiert hat. Hier ist, logischerwiese, jedes Gerät mit einer Office Lizenz auszustatten, da, wie in den Produktnutzungsrechten beschrieben, es sich hierbei um das zu lizenzierende Gerät handelt. Es ist einfach Gottgegeben, dass ein PC auf dem ein Office installiert ist auch eine Office Lizenz für dieses Gerät benötigt, da, wie wir ja in den Produktnutzungsrechten lesen können, einem Gerät die Lizenz zugewiesen wird. Beim Terminal Serverbetrieb verschiebt sich der Sachverhalt jedoch. Ich veranschauliche das mal mit einem Beispiel: Lizenzierung des Office im typischen Client Server Szenario: 400 PCs auf denen das Office lokal installiert ist erfordern 400 Office Lizenzen, da das Office Gerätebasierend lizenziert wird. Lizenzierung des Office im Server Based Computing: 5 Terminal Server auf denen das Office installiert ist erfordern zunächsteinmal 5 Office Lizenzen. Laut Produktnutzungsrecht sind die Terminal Server die zu lizenzierenden Geräte undabhängig davon ob nun ein Nutzer vor den Kisten sitzt und mit dem Office arbeitet oder eben nicht. Siehe dazu auch Produktnutzungsrecht auf Seite 15 römisch I a). Jetzt kommt das Remotezugriffszenario ins Spiel. Demnach wären neben den Terminal Server noch diejenigen Geräte zu lizenzieren von denen aus auf den Terminal Servern auf das Office zugegriffen werden kann. Der Lizenzzwang besteht hier einzig und allein in dem Remotezugriff des Nicht-Hauptnutzers, nicht jedoch, weil das Gerät von dem aus auf eine Office TS Session zugegriffen wird selber das zu lizenzierende Gerät ist. Dies könnte es auch niemals sein, wenn es sich bspw. um einen Thin Client oder um einen Handheld handel. Es ist praktisch unmöglich aus einem Handheld ein zu lizenzierendes Gerät zu machen, wenn man zunächst nach Produktnutzungsrecht auf Seite 15 römisch I a) geht. Das Gerät wird ausschließlich dadurch lizenzpflichtig, weil von diesem Gerät aus auf eine Office TS Session zugegriffen wird. Die 5 Terminal Server und die 400 PCs (im Client-Server Betrieb) oben sind allein schon deswegen Lizenzpflichtig, weil auf ihnen die Software installiert ist.
  19. Demnach müsste janusmail für alle 400 Thin Clients Office Lizenzen kaufen, da, nach dieser "einfachen Logik", prinzipiell ersteinmal von jedem Gerät aus der Zugriff auf das Office möglich ist. Biegt er es jedoch organisatorisch und technisch so hin, dass eben nur von 350 dieser TCs ein Zugriff auf das Office möglich ist, muss er folglich nur 350 Lizenzen kaufen. Die Lizenzen sind natürlich weiterhin geräteabhängig. Das eigentliche Problem ist jedoch, dass er nur auf Nutzerebene dem Ganzen technisch einen Riegel vorschieben kann. Auf Gerätebasis hat er eigentlich kaum eine Chance den Zugriff technisch sauber zu verhindern. Deshalb mein Verweis auf die Produktnutzungsrechte, ab Seite 15. Im Übrigen hast Du den entsprechenden Absatz selber in Deinem How-To zitiert. Von daher verstehe ich nicht ganz, wieso sich Dir dieses Thema bzw. diese Wörter nicht erschließen... In einem gewissen Maß ist die Lizenzbestimmung ein Paradoxon in sich. Denn ein Office wird erst dann für ein Gerät lizenzpflichtig, wenn ich einem Nutzer der dieses Gerät benutzt technisch den Zugriff auf das Office gestatte. Grundvorraussetzung ist also der erlaubte Nutzerzugriff, den ich realisieren muss.
  20. Was ist BDP? Oder meinst Du BDC? Sprechen wir dann von einem NT BDC? Seit W2K gibt es keinen BDC oder PDC mehr, sind alles DCs. Wenns ein NT BDC ist/war schmeiss ihn raus und teile dem AD mit, dass der Server irreparabel aus dem Netz genommen werden muss. Danach sollte es gehen. Schöner wäre es gewesen, wenn Du den alten richtig aus der Domain genommen hättest. Aber hätte liegt jetzt im Bette... :)
  21. Sobald Du technisch verhinderst, dass ein Nutzer die Office Anwendungen auf einem TS nutzen kann, ist er werder der "Hauptnutzer" noch "Nicht-Hauptnutzer" dieser Software. Die Nutzer haben in diesem Fall keinen Zugriff auf die zu lizenzierende Software. Dementsprechend können sie den Lizenzbestimmungen nicht unterliegen. Folglich besitzen Sie kein Gerät, welchem die entsprechende Lizenz des Office zugewiesen werden müsste, da auch von dem Gerät kein Zugriff auf ein Office der Terminal Server möglich ist. Das Gerät würde jedoch eine Lizenz benötigen, wenn sich ein Nutzer an diesem anmeldet und das Office auf dem TS nutzt. Denn spätestens unterliegt das Gerät den Lizenzbestimmungen und der angemeldete Nutzer wird zum "Nicht-Hauptbenutzer", unabhängig davon ob an diesem Gerät auch ein Nutzer arbeitet der das Office nicht nutzt. Du könntest also durchaus das Office auf allen TS installieren, musst jedoch sicherstellen, dass die zugreifenden Nutzer weder Hauptnutzer noch Nicht-Hauptnutzer sind und nicht auf einem Gerät arbeiten, an welchem sich Nutzer anmelden, die Haupt- oder Nicht-Hauptnutzer im Sinne der Produktnutzungsrechte sind. Siehe dazu Seite 15 ff. der Produktnutzungsrechte vom Oktober 07. Am Ende musst Du also genau schauen, wieviel Endgeräte Du hast von denen ein Officezugriff auf den TS möglich ist. Hast Du bspw. 400 Thin Clients und von 50 wird niemals ein Zugriff auf das Office der TS möglich sein, benötigst Du 350 Office Lizenzen... Der Zugriff von möglichen Heimarbeitsplätzen sollte ebenfalls bedacht werden...
  22. Garantie ist nicht gleich Garantie. Ich vermute auch eher, dass es Gewährleistung ist, was Dir der EBay Händler da gibt. Dazu ist er, wenn ich richtig informiert bin, auch verpflichtet. Das Problem ist nur, dass Du nach 6 Monaten die A-Karte ziehst und dem Hänlder nachweisen musst, dass der Mangel schon beim Kauf bestand. Davon ab wird Dir kein EBay Händler einen Vor Ort Servicetechniker schicken. Dieser Service ist am Ende wahrscheinlich teurer als die ganze Maschine. Meine persönlich Meinung und Empfehlung an unsere Kunden lautet immer neue Maschinen mit entsprechendem Servicelevel zu kaufen. Es ist eine ganz einfache Milchmädchenrechnung: 1. Gebe ich mehr Geld für eine neue Maschine aus, auf die ich 3 oder 4 Jahre VOS habe und bekomme im Notfall binnen weniger Stunden Ersatz ist meine Downtime auf ein Minimum reduziert 2. Spare ich am Anfang freut sich der Chef. Fällt meine Hardware dann aus (angenommen in den ersten 6 Monaten) darf ich die defekte Hardware einschicken. Wenn ich Glück habe schickt mir der Händler das Ersatzteil noch per Vorabtausch, jedoch nur als normale Lieferung, Express kostet extra. Dann warte ich erstmal zwei Tage, weil irgendwer beim Händler vergessen hat Deinen Fall rechtzeitig weiterzuleiten und am dritten Tag habe ich die Hardware. Beim einbauen merke ich, dass die Hardware garnicht passt, es ist das falsche Teil... Das Spiel beginnt von vorn. Der Chef wird ins Krankenhaus eingeliefert weil er durch die Nichtverfügbarkeit seines Outlooks/seiner E-Mails zu viel Kaffe getrunken und einen "Koffeinanschlag" erlitten hat. Die Downtime kostete schon jetzt mehr als ein neuer Server, weil eine ganz wichtige Auftragsbestätigung nicht rausgeschickt werden konnte. Ein Kunde ist deswegen abgesprungen... Na ja usw. und so fort.... :) Ich sag Dir mal, was Maxdata beim letzten Kunden gemacht hat. Ein Terminal Server hatte ein Problem beim Serverboot. Der Server hing beim booten mit ein paar roten Schriftzeilen die am Ende den Exitus einer CPU mitteilten (ist eine Dual CPU Maschine). Was macht Maxdata? Die schicken einen Techniker mit Mainboard und zwei CPUs und tauschen den ganzen Kram. Der Server hatte max. zwei Stunden Downtime. Der Kunde berichtet mir dieses und meint noch so: "Da merkt man erstmal wie sich so ein Service bezahlt macht." Auch wenn mein erster Absatz etwas blumig und fantasievoll übertrieben ist kommt er der Realität schon ziemlich nahe. Das Problem ist halt nur, dass ein Service wie dieser, wenn auch am Anfang teuer, keinen merklichen Mehrgewinn bringt... man kann ihn nicht sehen, nicht anfassen, das ist das eigentliche Problem. Ich weiss ja nicht wo Du alles angefragt hast aber es ist heute eigentlich kein Problem einen Server ohne Software zu bekommen. Ob es HP, FSC oder Maxdata ist. Alle basteln Dir auch Server zusammen, die Du ohne Lizenzen bekommst. Zu Dell kann ich nichts Genaues sagen, die verkaufen/kaufen wir nicht. Ich kann mir aber auch nicht vorstellen, dass die nur Kisten mit Software verkaufen. Ob Du in diesem Fall beim EBay Händler wirklich besser fährst bleibt zu hinterfragen... Klar die Handybude um die Ecke bringt dich auch nicht wirklich weiter...
  23. Du hast ja keinen Terminal Server, also stimmt die Aussage nicht ganz... Der SBS kann die ersten beiden Funktionen anbieten die letzte Option (wie bereits erwähnt) jedoch nicht. Es gibt jetzt zwei Alternativen: 1. Einen günstigen Server mit 2GB RAM kaufen und diesen zum TS machen. 2. Einen WinXP PC einsetzen, auf dem aber natürlich nur jeweils ein Nutzer arbeiten kann. Siehe Suche im Forum zu diesem Thema. Sprich es nicht zu laut aus, die Rache kommt hinterher... ;) Edit: Da war der XP-Fan etwas schneller... :D
  24. Boah ey was'n Durcheinander.... hat Dir schon mal jemand gesagt, dass das was die Chefs sagen in der Regel Unsinn ist? ;) Mir scheint, dass Dir grundlegende Sache zum Thema Terminalserver fehlen, daher ist es auch nicht ganz einfach zu erklären. Wir können hier aber auch keine Abhandlung über die Einrichtung eines TS halten, weil wir dann Morgen noch nicht fertig sind. Meine Empfehlung daher: 1. Schaue, was Du in der Testumgebung genau erreichen willst und definiere dementsprechende Ziele. 2. Befolge die Ratschläge meiner Vorredner und richte die Umgebung dementsprechend ein. 3. Tiefergehende Fragen beantworten wir gern aber bitte nicht immer die selben Fragen, wenn Sie schon mehrmals beantwortet wurden. Zum Thema lokal oder AD gesteuert kann ich ebenfalls nur empfehlen die AD Variante zu nutzen. Ich habe mal einen TS mit Citrix von einem Kunden übernommen. Das Gewurschtel war immer Umständlich und gerade mit Citrix wurde es nicht einfacher, im Gegenteil. Übrigens ist die Gültigkeitsdauer für temporäre TS CALs beim W2K3 weiterhin 90 Tage. 120 Tage ist der Zeitraum in dem ein TS Verbindugen annimmt, wenn er keinen Lizenzserver findet...
  25. Wolke2k4

    TFT fllimmert

    Unser Kunde hat einfach vom Kopierer ein Netzwerkkabel zu einem anderen EDV Anschluss legen lassen. Das Problem/die Ursache ist somit zwar nicht behoben aber umgangen...
×
×
  • Neu erstellen...