DAUjones

Willst Du wirklich das gesamte Profil synchron halten oder reichen Dir vielleicht bestimmte Daten schon aus? Es gibt vielleicht praktikablere Alternativen für Deine Wünsche. Das mit den Profilen würde ich jedenfalls auch nicht machen.

Das Problem ist wohl eher psychologischer als technischer Natur. Man muss dem guten Mann also in erster Linie vermitteln können, dass er sicher genug lebt. :)

Naja, für ein umsetzbares Konzept muss man die technischen Möglichkeiten einigermaßen kennen. Dann kann man das hochschaukeln.

Spielt das überhaupt eine solche Rolle? Die Maschine gehört so oder so glatt gebügelt und neu gemacht.

Morgen schon? 12. November war angekündigt. Ja. Für automatische Sicherungen muss es sogar ein lokal angeschlossenes Laufwerk sein, also "intern" bzw. USB. Das Medium ist dann exklusiv für Backup reserviert und im Arbeitsplatz nicht sichtbar. Manuell angestoßene Sicherungen können auch auf Netzlaufwerke bzw. auf UNC-Pfade laufen. So ist das zumindest im Server 2008. Ob der SBS da irgendwelche Neuerungen mit bringt ist mir nicht bekannt. Richtig. Dafür ist das OWA so gut, dass man Outlook nicht unbedingt vermisst.

Der Satz ist nur allgemeingültig und nicht aussagekräftig, wenn man ihn aus dem Kontext zieht.

So wie ich das lese ist da gar kein Terminalserver am Laufen sondern lediglich die VMs mit XP. Vorausgesetzt die sind korrekt lizensiert benötigt er keine weiteren Microsoft Lizenzen. Er könnte alte Clients mit einem schlanken Linux, sprich ein schlanke GUI wie XFCE z.B., verwenden. Sollte auch auf einem 800er Prozessor ausreichend gut laufen und RDP-Clientsoftware wird meist mitgeliefert oder lässt sich einfach nachinstallieren. XUBUNTU wäre eine Möglichkeit.

Es wäre wahrscheinlich hilfreich für diese Diskussion. ;) Derzeit gibt es nur zwei Domänen, wovon eine für Performancetests relativ isoliert ist. Die andere ist quasi "produktiv" wobei die Produktion der Testbetrieb ist. AD und Exchange auf 2003. Jetzt wird es an der Zeit das Ganze zu erweitern. Ex07 und Server08 müssen mit in die Gleichung in allen sinnvollen Varianten. Gleichzeitig soll das derzeitige "Jeder darf alles"-System geordnet werden. Hardwaremässig stehen hier einige Server, Clients und Backup-Appliances, teils mit VMware. Damit muss ich erstmal arbeiten. Neuanschaffungen sind in begrenztem Umfang möglich. Die Anschaffung eines leistungsfähigen Blade-Centers (für virtuelle Testdomänen) war mal im Gespräch, ist aber an den Kosten gescheitert. Vielleicht nächstes Jahr. So ist eine vollständige Virtualisierung der Umgebung nicht machbar, wobei das eh nicht 100%ig realisierbar ist. Muss ich das jetzt verstehen? Ihr habt mir ja schon einigen Input gegeben, der mir aber jetzt noch nicht reicht um das Problem zu lösen. Liegt vielleicht an noch mangelndem Verständnis von dem, was Du/Ihr mir sagen wollte. Das ist solch verwertbarer Input. Danke. Hier war ein Verständnisproblem. Ich kann den TS also so konfigurieren, dass ein bestimmter User nur bestimmte Icons (etc.) zur Verfügung und auch sonst keine weitere Macht innerhalb seiner Session hat? Geht das schon mit einem 2003er TS oder brauch ich den 2008 bzw. Zusatzprodukte? Passwörter...wir reden von insgesamt ca. 15 Leuten, die wechselnde Tests durchführen. Es würden also recht schnell einige Leute mehrere Passwörter wissen. Die sollen aber auch wieder nicht alle 3 Tage geändert werden müssen. Ich bin mir jetzt aber nicht sicher, ob das tatsächlich so relevant ist. Schonmal ein guter Ansatz. Genau deswegen habe ich ja den Thread eröffnet. Danke schonmal. – Das hat recht wenig mit meinen Wünschen zu tun. :) Klingt gut. Dieser Trunk-Port ist ein physikalischer Port der in beliebigen vLans gleichzeitig ist? So klingt das sinnvoll.

Jetzt ist das Ganze reichlich unsicher. Jeder Tester ist quasi Domänen-Admin und kann überall alles. Das soll ja geändert werden. Ähem...ja. Natürlich. Ich suche ja nach einem brauchbaren Ansatz. Naja, ich muss wissen, was technisch machbar/sinnvoll ist. Sonst wird das Grundkonzept nix. Die Tester sollen eine sichere Verbindung zum (zu den) Testnetzwerk(en) bekommen, wo sie ihre jeweiligen Aufgaben erledigen können. Wer auf welche Testdomäne zugreifen darf soll relativ flexibel aber zentral geregelt werden können. Innerhalb der jeweiligen Testdomäne wird der Tester wohl oder übel Dom-Admin-Rechte haben müssen. Ich habe leider keine Erfahrungen mit dem ISA-Server. Kann der einem User bzw. einer Gruppe RDP-Zugriff auf nur einige bestimmte Server geben? Falls ja, können diese Server in einer eigenen Domäne sein, die nichts mit der Domäne, in der sich der ISA befindet, zu tun hat ausser am gleichen Switch zu hängen bzw. im gleichen IP-Netzwerk? – Mal anders rum: Welche Details fehlen Euch denn? Hier am Standort ist quasi nur Entwicklung. Eine vollständige Virtualisierung wird nicht möglich sein. Die Software ist für Appliances...plus halt die Client-Agents. Auch sind derzeit mehr als nur ein physikalischer Server mit VMware ESX im Einsatz + einige physikalische XP-Clients. Letztere sind absichtlich alte Kisten mit "wilder" Hardware, weil nur so reale Bedingungen simuliert werden können. Reine VMs sind zu "glatt". DAS habe ich jetzt noch nicht so ganz verstanden. Der TS soll ausserhalb der Testdomänen/-netze liegen? Jede Testdomäne in einem eigene IP-Bereich? Was hindert den Tester am Öffnen einer RDP-Verbindung auf einen beliebigen Rechner im Netz? Oder meint ihr einen TS für jede Testdomäne? Schwierig so zu realisieren wegen der oben geschilderten Problematik. Die Anschaffung eines Blade-Systems wurde schon mal erwogen...bis man die Kosten sah.

Was mir gerade einfällt...wenn wir keine übergeordnete Domäne verwenden sondern lediglich Vertrauensstellungen, sollte das doch eigentlich klappen, oder? Dann sollten sich die Szenarien nicht in die Quere kommen können, aber der RDP-Zugriff kann über Gruppenzugehörigkeit geregelt werden. – Wie sonst von Indien aus? Die Hardware steht hier in D. Die Testmaschinen sind teils physikalisch, teils VM. Das mit den hinterlegten RDP-Shortcuts ist zu leicht ausgehebelt. Die Leute sind u.A. Entwickler, also keine DAUs. Genau deswegen soll die Macht ja geteilt und reglementiert werden. Zur Zeit ist das nicht der Fall. – edit: Kann nicht der ISA-Server den Remotezugriff regeln?

Problem ist, die derzeitige Umgebung ist mehr oder weniger natürlich gewachsen, sprich durch diverse Adminhände undokumentiert entstanden. Es muss also so oder so was neu gemacht werden. Dazu fehlen die 2008er-Szenarien. Wichtig wären die Regelung des Zugangs der Tester, dass eben nicht jeder überall alles darf und das möglichst zentral verwaltet. Es soll auch der eigene Internetzugang verwendet werden und nicht wie bislang der Umweg über die Mutterfirma. Die Tester klagen regelmässig über lahme Performance der Remoteverbindungen und es wird vermutet, dass es mit einem direkteren Zugang besser wird. Desweiteren gehts auch um mehr administrative Unabhängigkeit von der Mama. Nach Deiner Info zur Unumsetzbarkeit von Plan A denke ich gerade an ein Remote-Tool, das intern Berechtigungen (also wer auf welche Maschinen) regeln kann. Wollte gerade einen eigenen Thread dazu eröffnen.

Das hatte ich befürchtet. Ich bin auch für anders geartete Lösungsvorschläge bzw. -ansätze zu haben.

Hallo erstmal. Hier soll in absehbarer Zeit der Testbetrieb für unsere Softwareentwickler neu organisiert werden. Es handelt sich um Backupsoftware, die auch Exchange, SQL und Sharepoint sichert und dabei natürlich auf das AD zurück greift. Wegen der mit den jeweiligen Exchange-Versionen einhergehenden Schemaerweiterungen wird man wohl für jedes Szenario eine eigen Domäne benötigen sprich - AD 2003 mit Ex 2003 - AD 2003 mit Ex 2007 - AD 2008 mit Ex 2003 - AD 2008 mit Ex 2007 (- AD und Ex gemischt) ? Die Tester (ca. 15 Leute) sind teilweise örtlich sehr weit voneinander getrennt (Europa, Russland, Indien) und sollen über VPN-Verbindungen ihre jeweiligen Tätigkeiten erledigen können. Idealerweise werden deren Berechtigungen zentral geregelt, da die laufend geändert werden müssen. Ein Tester soll also nur auf bestimmte Szenarien zugreifen können, nicht auf alle. Derzeit wählen die sich über den VPN-Zugang der Mutterfirma auf XP-VMs ein und von dort weiter über RDP auf die jeweiligen Testmaschinen. Jeder hat Dom-Admin-Berechtigungen. Das ist eben zu chaotisch und auch von der Performance her nicht optimal. Daher mein Ausgangsüberlegung einer übergeordneten Domäne mit darunter liegenden Szenariendomänen mit Vertrauensstellungen. Tester werden über die oberste Domäne berechtigt, sprich User A soll z.B. auf Domäne 1 und 3 zugreifen können, nicht auf die restlichen. Eine Hauptfrage wäre jetzt bezüglich der "Tragweite" der Schemaänderungen, die von den jeweiligen Exchangeversionen vorgenommen werden. Können die in den untergeordneten Domänen verursachten Schemaerweiterungen die Testszenarien der anderen Domäne irgendwie beeinflussen oder muss ich mir da keine Sorgen machen? MS-SQL 2005 und 2008 sowie Sharepoint kommen auch noch mit dazu, ändern aber meines Wissen das Schema nicht weiter ab. Das reicht wohl für's Erste. :) Schonmal Danke im Voraus für Ideen, Anregungen, Kritik.

PST-Dateien über Netzwerk wird seitens Microsoft nicht unterstützt um nicht zu sagen, es wird einem davon abgeraten. Verbindungsunterbrechungen, Überlastung des hostenden Servers etc. können die PST korrumpieren.

Dann mach ich das. :D Microsoft will einfach an der "Größe" des Netzwerks mitverdienen. Mehr User bedeuten mehr Finanzkraft der Firma ergo mehr Lizenzgebühren an Microsoft. Verwirrung stiftet eigentlich nur die Trennung zwischen User-CAL und Device-CAL. Dabei verhält es sich so, dass wenn jeder User einen Rechner nutzt und alle User/Rechner gleichzeitig auf die Server zugreifen, spielt es keine Rolle welche Form der CAL man hat. Hat man mehr User als Rechner, sprich an einem Rechner arbeiten mehrere User, dann kommt man mit Device-CALs günstiger weg. Ist nur ein Bruchteil aller User immer gleichzeitig online, ist die User-CAL die günstigere Variante.

Es spielt für die Domäne keine Rolle ob 32 oder 64 bit.

Eigentlich sollte das Problem gar nicht erst bestehen. Kann es sein, dass der verwendete Treiber den TV-Out nicht unterstützt?

Schreit für mich nach einer Freigabe auf eben diesem Server, die auf den XP-Clients als Netzlaufwerk eingebunden wird. Voila.

Klar. An hochspezialisierten Fachkräften. Als einfacher Indianer will einen aber keiner...bzw. kein Geld dafür zahlen...und für selber ausbilden gibt die GF keine Mittel frei.

Man könnte auch einfach sagen, diese Konfiguration mit dem externen Server ist reichlich überkompliziert für kleine Netze. Bei fachlich sauberer Einrichtung kann man ruhig seinen Exchange "direkt" (hinter Firewall) an einem gewöhnlichen DSL-Anschluß betreiben. Die Wahrscheinlichkeit, dass Mails verloren gehen ist dadurch auch nicht höher als mit exotischeren Lösungen. Eher im Gegenteil.

Bei den Festplattenpreisen lohnt sich Blueray nicht mal. ;)

Die Clients sind also nicht in der Domäne und die Benutzer haben ihre Konten lokal auf diesen selbst erstellt...oder andersrum gefragt, es sind keine der User im Active-Directory angelegt? Hast du den Usernamen zum Zugriff auf die Freigabe auch mit Domänenname\Username angegeben oder nur den Usernamen verwendet? User auf dem Server gehören nämlich zur Domäne. Diese muss mit angegeben werden. Falls das alles so sein sollte, würde ich das aber überdenken...bzw. nicht überdenken sondern einfach auch die User im AD anlegen. Einstellungen zu den Profilen können migriert werden. Die Umgewöhnung der User hält sich in Grenzen, aber man hat gewaltige Vorteile in Sachen Administration. Ist ja schließlich der Sinn und Zweck einer Domäne und eines Verzeichnisdienstes.

Ihr habt aber eine Active-Directory-Domäne, oder? Falls ja, Abteilungsgruppen erstellen, da die entsprechenden User reinpacken, den Ordnern mit den Daten die enstprechenden NTFS-Rechte vergeben, Freigaberechte jeder alles und dann sollte das mit dem Mapping kein Problem mehr sein. edit: Verdammt! 1 Minute zu langsam. ;)

Gibt doch von Citrix auch ein Produkt, dass direkt das ganze OS auf Thinclients streamt. Haben die doch mit Ardence gekauft. YouTube - Ardence Dekstop Edition

Zuerst verkauft man ihm das NB mit dem Argument der Sicherheit bei Diebstahl... :cool: