DAUjones
-
Gesamte Inhalte
430 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von DAUjones
-
-
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.
-
Hallo,
habe soeben gesehen, dass der SBS 2008 Standard ab Morgen verfügbar ist.
Morgen schon? 12. November war angekündigt.
Das alt ehrwürdige (?!) NTBackup bzw. dessen Nachfolger kann nur noch auf Disks speichern, keine Bänder mehr - das habe ich mal gelesen. Stimmts?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.
Andererseits habe ich mal gelesen, dass der SBS 2008 bzw. Exchange 2007 kein Outlook für die Clients mehr mitbringt und das nun separat erworben werden muss.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.
-
Muss ich das verstehen?
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.
Kann man so nicht sagen. Dein Problem liegt nicht auf einer technischen, sondern auf einer konzeptuellen Ebene. Dafür ist ein Forum nicht besonders geeignet.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.
Ja. Natürlich. Der TS ist Standalone oder meinethalben Mitglied der Produktionsdomäne. Die Testserver sind eigene Forests. Müssen sie ja sowieso, wegen Exchange. Vertrauensbeziehungen zwischen Produktion und Test gibt es nicht.Das ist solch verwertbarer Input. Danke.
Dass ihm der TS-Gateway nur die Icons gibt, die er sehen darf. Und dass er zu den anderen Maschinen ja nicht die Kennwörter kennen muss.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.
Wir haben dir schon ein paar Ansatzpunkte geliefert. Mein Favorit wäre, die gesamte Umgebung als VMs aufzubauen, vielleicht auch skriptgesteuert. Zu bestimmten Intervallen (oder wie auch immer) wird die Umgebung auf einen definierten Stand zurückgesetzt. Dabei ändert man dann die Kennwörter und teilt sie nur den Berechtigten mit. Dürfte schon ziemlich weit kommen.Schonmal ein guter Ansatz. Genau deswegen habe ich ja den Thread eröffnet. Danke schonmal.
–
Da du keine vollständig virtuelle Umgebung haben möchtest...Das hat recht wenig mit meinen Wünschen zu tun. :)
...würde ich meinen Ansatz der virtuellen Netze durch vLans umsetzen. Jede der Teststellungen bekommt also eine eigene VLan ID und der einzige Zugang zu dem Netz geht über den TS (dieser steht in allen VLans). Damit ist sicher gestellt, dass die Entwickler nicht aus den vorgegebenen Umgebungen raus kommen.Klingt gut.
Jup vollständig ausserhalb an einem so genannten Trunk-Port des Switches welches deine Teststellungen verwaltet.Dieser Trunk-Port ist ein physikalischer Port der in beliebigen vLans gleichzeitig ist?
Wie Nils schon gesagt hat könnte man sich überlegen den TS in die Prod Domäne aufzunehmen um die Rechteverwaltung über euer AD machen zu können. In den jeweiligen Domänen brauchen die Tester jedoch weiterhin eigene Accounts. Da die Jungs aber eh DomAdmin Rechte bekommen sollen kann das auch ein generischer account sein...So klingt das sinnvoll.
-
Erschließt sich mir nicht. Auf dem TS-Webinterface sind halt nur Applikations-Icons hinterlegt, eins pro RDP-Zugang. Das soll nur den Zugriff ohne VPN erleichtern, mehr nicht. Warum soll das weniger sicher sein als euer derzeitiger Zugang?
Jetzt ist das Ganze reichlich unsicher. Jeder Tester ist quasi Domänen-Admin und kann überall alles. Das soll ja geändert werden.
Mir scheint, dass eure Vorstellungen da bislang noch in einem sehr rudimentären Stadium sind.Ähem...ja. Natürlich. Ich suche ja nach einem brauchbaren Ansatz.
Natürlich kann er das.Genauer kann man das nicht sagen, weil dafür einfach Details und Anforderungen fehlen. Ihr solltet euch erst mal hinsetzen, eure Anforderungen spezifizieren und ein Grundkonzept entwickeln. Für technische Details ist es eindeutig noch zu früh.
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?
–
wie Nils schon gesagt hat fehlen ein paar Details.Mal anders rum: Welche Details fehlen Euch denn?
1. Umgebung vollständig virtualisieren und für jede deiner Umgebungen ein eigenes virtuelles Netz aufbauen (Entwickler gehören eh nicht in Produktion).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".
2. Zugang zu den Testnetzen NUR über einen Terminalserver der die Zugriffsrechte auf die VMs regelt in dem er die Verknüpfungen anzeigt oder eben nicht.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?
Vorteile dieses Aufbaus:1. Du kannst die Umgebung jederzeit zurück setzen und damit auf einen definierten Punkt zurück kommen.
2. Die Dev's können in Ihren Domänen weiterhin Admin sein und jammern dir nicht die Ohren voll mit Dingen die nicht mehr gehen...
3. Die Umgebungen sind nicht nur untereinander abgesichert, sie sind zudem auch aus eurem Netz raus.
4. Hat jemand via Terminalserver keinen Zugriff auf eine VM, dann hat er den Zugang auch nicht, da die einzelnen Netze untereinander nicht kommunizieren können und somit RDP Verbindungen nicht möglich sind.
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.
–
Moin,müssen denn die Tester remote arbeiten?
Wie sonst von Indien aus? Die Hardware steht hier in D.
Du könntest sie per TS-Gateway via Web auf einen Terminalserver zugreifen lassen, auf dem die verschiedenen Testmaschinen als RDP-Zugänge hinterlegt sind (nicht getestet, aber sollte gehen). Die Testmaschinen selbst könnten VMs sein, die bei Bedarf oder automatisch auf einen definierten Stand zurückgesetzt werden.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.
Welche Berechtigungen wo nötig sind, könnt ihr nur selbst definieren und einrichten. Sobald aber jemand Adminrechte hat, hat er die Sache im Griff.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.
-
Über den Sinn möchte ich mich hier nicht auslassen.
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.
-
kann ich problemlos eine neue Workstation mit Vista Business 64-bit in eine 32-bit Domäne (SBS 2003 R2 Premium mit momentan nur XP-Clients) aufnehmen und kann MS Office 2007 problemlos darauf betrieben werden?
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?
-
...dann würden die Bilder ja egal wo ich das Gerät ans Netzwerk anschließe immer auf dem gleichen Rechner landen, da sich die Ziel IP ja nicht ändert. Und der Zugriff auf den Server ist erforderlich, da das Gerät von dort seine Untersuchungsdaten bezieht.
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.
-
Hallo,
Bring mal einem Kunden bei das er sich "quasi" ein neues NB kaufen kann, nur weil er ein Passwort vergessen hat.
MfG Schotte
Zuerst verkauft man ihm das NB mit dem Argument der Sicherheit bei Diebstahl... :cool:
Benutzerprofil auf Netzlaufwerk speichern
in Windows Forum — LAN & WAN
Geschrieben
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.