Dr.Verpeilung

tach zusammen! habe dasselbe Problem mit IBM xSeries 365er Maschinen und nem RAID 5 bzw. 10... nach 3 stunden rum****eln und ca. 10 tassen kaffee, hab ich mich dann kurzerhand entschlossen nen ris-server aufzusetzen und nen riprep image zu erstellen und das funzt wunderbar... ich kann selber net sagen warum das nicht funktioniert. sogar mit ghost und dem ghost cast image server klappt das nicht...

das selbe problem hatte ich auch mal. da hat mir der artikel aber leider nicht geholfen. bisher habe ich auch noch keine lösung gefunden... na ja, dann fehlt die lan-verbindung halt... man kann die ip/dns/gateway/wins-adressen ja per netsh konfigurieren.

also ich habs hingekriegt palm handhelds über ne terminalsitzung zu synchronisieren. dazu musste aber auf jeden fall die software auf dem lokalen client installiert werden. wie willste denn auch sonst das gerät ansteuern? usb geht über rdp eh nicht und rs232 ist so ne sache...

das frag ich mich jetzt aber auch...

was sind denn für berechtigungen auf die UsrClass.dat Datei gesetzt?

wie siehts denn aus mit zugriff auf das laufwerk per dateidialogfeld... also über beispielsweise start ==> ausführen => p: ???

oder lege einfach einen neuen Benutzer im AD an und vergib dort die Einstellungen für das TS-Userprofil (natürlich eins welches es noch nicht gibt). Dann meld dich mit dem neuen Benutzer am Terminalserver an und wieder ab. Damit dürfte es ja dann keine Probleme geben. Anschliessend schau nach, welche Berechtigungen auf das neue Profil vergeben worden sind und vergleiche Sie mit denen der anderen, nicht funktionierenden Profile. Ich meine es hätte mal irgendeine Einschränkung gegeben, daß auf ein servergespeichertes Userprofil nur der Besitzer und Domänenadmins zugreifen dürfen... oder ich vertu' mich da jetzt ganz gewaltig...

aaaah! das meinst du... gibts aber auch auf deutsch http://www.microsoft.com/germany/ms/technetdatenbank/showArticle.asp?siteid=600295

mmmmh. hört sich aber doch eher nach nem berechtigungsproblem an... was allerdings wiederum dagegen spricht, ist die tatsache, daß auf einem anderen t-server die anmeldung korrekt abläuft. der fehlermeldung ist zu entnehmen, daß die sicherheitseinstellungen des ordners auf dem lokalen server nicht richtig sind. haste mal nachgeschaut ob die lokale kopie die richtigen berechtigungen hat... also in c:\dokumente und einstellungen\%username% mal nachsehen wer auf den betroffenen ordner zugriff hat. dasselbe auch nochmal sicherheitshalber bei den servergespeicherten profile überprüfen...

sind in dem angegeben profilpfad die userprofile denn da???

hab ich gefunden. iss auch nen nettes tool. leider kann man trotzdem noch über das dateidialogfeld (word starten ==> datei öffnen ==> und im feld dateinamen den laufwerksbuchstaben eintippen) auf die laufwerke zugreifen. aber da muss der standarduser erstmal drauf kommen...

hi whitewater! kannste mir mal nen link schicken wo man dieses whitepaper bekommt??? :)

ist doch ganz klar warum das nicht funktioniert... gre verwendet nicht tcp als protokoll sondern ip... also tippe erstmal no access-list outside-acl permit tcp any any eq 47 no access-list inside-acl permit tcp any any eq 47 um die falschen access-listen zu löschen... dann tippe access-list outside-acl permit ip any any eq 47 access-list inside-acl permit ip any any eq 47 um die neuen access listen hinzuzufügen... dann sollte es laufen. der rest ist auf jeden fall korrekt eingerichtet... port 389 und 464 kann auch raus...

das ist ne wirklich gute frage... hab ich mir auch schon gestellt und suche immernoch nach ner antwort... da bin ich mal gespannt...

aaaah! ok! biste dir denn sicher, daß neue bzw. geänderte dateien nicht auch in dieser "pseudo"-auslagerungsdatei liegen??? wär ja nur sinnvoll. ausserdem sind die user dann dazu angehalten die daten auf nem netzlaufwerk abzulegen...

ist dieser Dr. Kaiser kram nicht dasselbe wie der HDD-Sheriff? Ich meine es würden nämlich auch Änderungen auf der Festplatte rückgängig gemacht werden... leider habe ich bis jetzt nicht wirklich erfahrung mit dem pc-wächter gemacht, sondern nur mit der reborn card von signal-computer. bei der ist es aber wirklich so, daß auch die festplatte geschützt wird...

hi sachsenjunge, also nen neustart ist nix anderes als nen gpupdate. gpupdate ersetzt ja lediglich secedit und ist dafür gut das standardmässige gruppenrichtlinienintervall zu ignorieren und sich sofort abzugleichen. zwecks der profile würd ich sagen, daß diese überhaupt nicht korrekt übernommen werden. servergespeicherte profile werden ja bei jedem anmelden erst mal auf die lokale platte gespeichert, welche dann wiederum von dr. kaiser geschützt ist. greetz verpeilo

hi dummy. man kann doch den zugriff auf jede beliebige ou über die sicherheitseinstellungen einschränken. dazu müssen die user die diese ou nicht sehen sollen allerdings zu einer sicherheitsgruppe gehören der die leseberechtigung darauf entzogen wird. verpeilo

naja. in bezug auf den speicher schliess ich mich an, aber die cpu sollte ausreichen. der sql kommt eh nur in stress wenn irgendwer irgendwelche umfangreichen suchen oder global-änderungen startet und der terminalserver ist bei 5 usern auch eher gelangweilt. ausserdem hängt das ja auch immernoch nen bisschen von der anzahl und grösse der datenbanken ab. eher habe ich bedenken bei deinem s-ata raid 1. ms empfiehlt für die sql datendateien min. nen raid 5 und ausserdem sollte an nem raid controller mit entsprechendem cache nicht gespart werden... aber hier mal ein sql-server beispiel so wie wir ihn für 300 user einsetzen: 2x intel xeon 3,06ghz 4gb ram u320 10000rpm scsi platten im raid 5 und damit hatten wir von seiten der cpu noch keine performance schwierigkeiten. der speicher wird dann und wann mal nen bisschen eng, aber auch nur wenn mal wieder irgendjemand 50.000 adressen selektiert.... greetz verpeilo

ich schliess mich da an... auslagerungsdatei leeren ohne system neu starten ist nicht... wieso willste das teil denn nicht runterfahren???

hi wirtnix... sieht fast so aus als kämst du an nem backup exec mit sql-agent nicht vorbei. glaubst du nicht, daß du die geschäftsleitung nicht davon überzeugen kannst daß das notwendig ist??? immerhin gehts hier um datensicherheit....

na ja, kontingente sind natürlich da, nur müssen auch da ne menge ressourcen vorgehalten werden. man kann ja nicht nem verkäufer sagen: nö, lass das mal mit dem rechnungen schreiben... dein kontingent ist überschritten. dann doch lieber 800-1000 euro in ne 140gb festplatte stecken und nen jahr ruhe haben... ausserdem ist die zentrale speicherung die einizige möglichkeit sämtliche unternehmenskritischen daten zu sichern. wenn sich jeder frei bewegen könnte, ist man ständig in der ungewissheit ob denn auch alles mitgesichert wird... und wirklich wichtige daten sind ja wohl höherwertig als 2000 euro für'n autoloader falls das dat-tape mal zu klein wird.... greetz verpeilo

mmmmh. kann ich mir nicht vorstellen, daß es danach zu Problemen führt. Auf AD und die GPOs kannst du natürlich jederzeit zugreifen. Standardmässig haben authentifizierte Benutzer Lesezugriff.

äääh? ich versteh nur bahnhof was ist denn dein ziel und was sind es für DCs? sind es zusätzliche DCs oder eigenständige für neue Domänen???

Hi haeckle, also wir haben ein ähnliches Szenario: 2x SQL-Server (einer davon Backup-Server mit Veritas Backup Exec 9.1) 2x Domänencontroller 2x Fileserver 10x Terminalserver alles sind IBM X-Series 365er Kisten mit Raid 5 bzw 10 für SQL. Auf den Terminalservern haben wir einfach für alle Benutzer die lokalen Festplatten ausgeblendet. Auf den Fileserver gibts dann jeweils Home-Verzeichnisse für jeden User. Das Home-Laufwerk ist das einzige welches für jeden Benutzer sichtbar ist. Alles andere ist tabu. Dann ist auf einem der DCs RIS installiert und von den Terminalservern (alles dieselbe Hardware) steht dort ein RIPREP-Abbild mit allen Programmen, Anwendungen etc. zur Verfügung. Dadurch muss nur der DC, die SQL-Server und die beiden Fileserver gesichert werden. Wenn ein Terminalserver abschmiert... völlig egal. Das Ding ist in kürzester Zeit per RIS wiederhergestellt. Aber um mal auf deine eigentliche Frage zurück zu kommen: nööö... die Rücksicherung eines Terminalservers mit installierten Programmen ist bei weitem mehr Aufwand. Bedenke, dass jede Anwendung die Registry erweitert und auch ne Menge Dateien ins System32 Verzeichnis kopiert. Das alles einwandfrei zurück zu lesen ist unglaublich schwierig. Es sei denn es geht dir nur um die abgelegten Dateien wie Word-Dokumente, Excel Sheets etc. Dann ist eine Rücksicherung natürlich nicht so das Problem. greetz verpeilo