reinilein

Nein, 5 Euro ins Schweinderl. :D Ist ein Krenn - Server (bis auf den Aufkleber alles Intel)

Servus! Auf einem R2 - Spielsystem habe ich mit dem NFS - Server experimentiert. Zumindest hatte ich das vor. Nachder frischen Dienstinstallation (Über Software, Microsoft Services for NFS) kommt beim Start des Dienstes "Server for NFS" im Systemlog periodisch alle paar Sekunden die Meldung: Fehler bei Initialisierung von Server für NFS auf einem Volume mit dem Laufwerkbuchstaben "¥:". Fehler-ID ist die 1066, Quelle ist der NfsSvr Die Windows - Hilfe schlägt vor, den Datenträger mit NTFS zu formatieren. Aber "format ¥:" funktioniert nicht so recht.. :shock: :) Auf einem anderen Spielserver funktioniert alles tadellos. Hat jemand eine Idee, wie ich ohne einen Call aufzumachen dem Neuaufsetzen entgehen kann?

Wegen diversen Gründen werden bei uns die TS-Profilpfade im Benutzermanager gesetzt und nicht per Policy. Aber ich werde das mal versuchen: Eine Richtlinie in der OU des Vista - Clients mit deaktivierten Profilpfad und Loopbackverarbeitung. Ich hoffe, dass die Gruppenrichtlinie dann die Einstellung im AD überschreibt... Danke für den Tipp!

Also bei XP ist es so, dass nur ein Profil vom Server geladen wird, wenn der Profilpfad in der Benutzerverwaltung im Karteireiter "Profil" eingetragen ist. Der Eintrag des Profilpfades im Karteireiter "Terminaldiensteprofil" interessiert XP überhaupt nicht, egal ob die Anmeldung per RDP oder interaktiv erfolgt. Übrigends ist das auch bei Win2003 so, zumindest wenn er sich im Remoteverwaltungsmodus befindet. Dass Benutzer per RDP mit einem Client arbeiten ist sicherlich nicht normal, aber es gibt Sonderfälle: Ich als Admin will eben hin und wieder mit "meinem Arbeitsplatz" werkeln...

Genau ds Problem hatten wir auch, vor ein paar Jahren. Zum Glück war unser Einfluss so groß, dass wir jetzt die Namen grundsätzlich ohne Titel pflegen. Auch wir sind im Gesundheitswesen. Nicht wirklich ein Tipp, ich weis....

Hi! Ich betreibe einen Testrechner mit Vista Busines in einer 2003er - Domäne. Beim Testbenutzer (mit Domadmin - Rechten...) ist ein Terminaldiensteprofil im AD definiert. Wenn man sich per RDP auf den Vista - Client setzt, zieht sich die Vista - Maschine das Terminaldiensteprofil, das eigentlich für die Terminalserverfarm gedacht ist. Wie kann ich Vista beibringen, dass es sich wie XP verhält und nicht das Terminaldiensteprofil verwendet? Ehrlichgesagt verstehe ich nicht den Sinn, warum ein Client ein Terminaldiensteprofil verwendet...

Schnellschuß: Festplatte voll?

--falsch gepostet. SORRY!

Das mit dem Windows Update Log war ein guter Tipp! DANKE Kohn! Es scheint so, als ob da netinstall irgend wie zwischen funkt.....

Szenario: 1 x WSUS auf 2k3S viele 2k Prof - Clients zum installieren genehmigtes Updaterollup 1 alles in deutsch... Problem: Die clients installieren schön das rollup1 zur angegebenen Zeit, Im Systemprotokoll steht auch positiver Eintrag diesbezüglich. Am nächsten WSUS - Updatezeitpunkt (nächster Tag, selbe Zeit, selber Ort...) wird wieder das Updaterollup 1 installiert. im Systemprotokoll steht auch wieder ein positiver Eintrag. Auf dem WSUS - Server steht bei dem betroffenen Client ein "Erforderlich" für das Rollup 1. Der Client will das Rollup 1 täglich installieren. Hab da praktisch eine Schleife drinn. Hab auch schon probiert das Rollup 1 händisch zu installieren. Ohne Erfol.... Was ist da blos faul??

Das Problem kenne ich auch. Meines Wisssens kann man nichts daran ändern. Übrigends lief bei uns bis vor kurzen TightVNC seit Anbeginn von 2k3S ohne Probleme. Nun läuft seit ein paar Wcohen UltraVNC auch ohne Probleme, bis auf das besagt Consolenproblem..... VNC auf einem Server ist recht praktisch. Vor allem wenn man mal auf einem x-beliebigen Client ohne installierten RDP - tools sitzt (es soll ja Firmen geben, die noch win3.11 im einsatz haben....). die vncviewer.exe als 0815 - User starten reicht dann vollkommen aus....

Hast wars***einlich eine Windows 2003 Domän e mit aktiver Kommunikationssignerung. Dann können nur Rechner die Mitglied der domäne sind, den Datenverkehr "entschlüsseln" Probier das mal (nur die ROTE Einstellung ändern, sonst geht so gut wie gar nix mehr): http://www.gruppenrichtlinien.de/HowTo/DOS_Clients_an_Windows_2003_Server.htm

fast richtig. wie das urmel schon sagte, lass auf dem 2. dc auch den Globalen Katalog speichern. Und dann schau, dass immer einer dieser beiden DC´s läuft. Begründug: Ein Netz ohne Server ist kein Netz mehr. ;-)

Hot stand by ist gar nicht so schwierig zu implementieren. An unseren Standorten haben wir jeweils zwei DC´s auf denen auch DNS und WINS werkelt. DHCP läuft auch auf beiden Kisten. Der Dienst läuft auch bei beiden Servenr, aber es ist immr nur einer authorisiert (geht ja gar nicht anders...) Einer der DHCP´s ist der Boss, auf dem legen wir unsere Reservierungen an (auf MAC - Basis wegen heterogener Umgebung). Dann gibt´s da ein kleines Script das per cron - Job (bzw, per at, sorry...) alle paar Stunden läuft und die Reservierungen mit der netsh exportiert und auf dem "Standby" wieder importiert. Das mit der Ausfallsicherheit der DHCP - Relay - Lösung sehe ich persönlich nun eher nicht so tragisch. Die eigentliche Anwendung für die das WAN eigentlich errichtet worden ist reagiert sicherlich kritischer auf WAN - Breaks.. ;-) -- Wundert mich eigentlich, warum es noch kein Tool gibt, dass DHCP - Konfigeinstellungen auf andere Server repliziert. (zumindest kenne ich keins...)

Klar. Bie manchen ISP ist das an der Tagesordnung....

leider geht das nicht "automatisch". Du kannst vielleicht mit einem Logonscript rumfrickeln, aber das ist alles eher was für die Computerbild.... Mach am besten gleich Nägel mit Köpfen, und schau warum das Progi nur als Hauptbenutzer arbeitet. Meistens geht es nur um den fehlenden Schreibzugriff im %programmdir%. Setz dann einfach die notwenigen NTFS - Berechtigungen (ja, händisch. geht bei den paar Rechnern in ein zwei Stunden klickerei..) Wenn du wirklich echte Hauptbenutzer haben willst, dann mach dir in Deiner Domäne eine Gruppe in der du die betreffenden Benutzer hineinsteckst. Diese Gruppe nimmst du dann bei jedem Rechner in die lokale Gruppe "Hauptbenutzer" auf. Ja, auch händisch. das ist in einer Stunde vorbei...

Die Fernbedienung ist quasi schrott. Die ist viel zu träge. Der Rest der NT - Utility´s ist net schlecht. Da ist einfach alles am rechten Fleck. Ein "Vertrag" mit der GL ist eigentlich nicht nötig. Du musst allerdings schon im Auftrag deines Arbeitgebers handeln. Der übliche Auftrag der Geschäftsleitung an dich reicht dann völlig. Wichtig ist eine Vereinbarung mit den Mitarbeitern die an den "überwachbaren" Rechnern arbeiten. Das geschieht entweder im Arbeitsvertrag der Mitrabeiter oder mit dem Betriebsrat über eine Betriebsvereinbarung.

Also probier´s mal mit dem Einrichten der DFÜ - Verbindung für nur den einen User, wie von mir beschrieben. Problem ist hald dann, dass wenn die DFÜ - Verbindung aufgebaut ist, der Terminalserver diese DFÜ - Verbindung als Standard - Gateway verwende, und nicht mehr die Verbndung zum DSL - Router. Also der komplette Internetverkehr der auf dem TermServer anfällt, wird über diese DFÜ - Verbindung abgewickelt. Wenn nun deine Terminalserver - User in einem anderen Netzwerksegment sind (bzw. sie eine IP ausserhalb des Subnets des terminalservers haben) bringt das das Routing total durcheinander und beim Aufbau der DFÜ-Verbindung fliegen sie erst mal aus ihrer Terminalsitzung. Ich würde das Ganze über einen separaten Router machen (da langt ein absolut biligler ISDN - Router für unter 50 € bei ebay zu haben) und einfach den POP3 - Server von T-Online (pop.t-online.de) mittels Hostroute am Terminalserver eintragen: route add 194.25.134.26 mask 255.255.255.255 [iP-des-Billigrouters] -p Das gleiche mit dem smtp-Server von T-Online (smtp.t-online.de): route add 194.25.134.27 mask 255.255.255.255 [iP-des-Billigrouters] -p Dann braucht sich auch nicht der User mit dem Aufbau der DFÜ - Verbindung rumschlagen. Das geht dann automatisch.

Was jetzt kommt ist rein nur theoretisch überlegt und nicht praktisch nachvollzogen. (Ich hab da nämlich ein Problem damit, Windows- Kisten per DFÜ "ins Internet" zu stellen. Ich würde sowas nur über einen separaten Router lösen) Wenn die Benutzer mit getrennten Benutzerprofilen arbeiten, müsste es funktionieren. Die DFÜ - Verbindung richtest du dann nur in den Benutzerprofilen ein, die die DFÜ - Verbindung machen dürfen sollen. Also - 1. als berechtigter Benutzer anmelden 2. Netzwerkverbindung mit dem Assistenten hinzufügen, der Assitent fragt dann für wen die Verbindung erstellt werden soll, dort wählst du "Eigene Verbindung" aus. Wenn die User alle über ein und das selbe servergestützte Profil arbeiten, schauts glaub ich schlecht aus, dass du da was drehen kannst. Und wie gesagt, ich würde aus Sicherheitsgründen einen Router nehmen und dem Mailserver beibringen da drüber die Mails abzuholen und dem User zuzustellen.

wenn du dir die themplates auf einer 2000er - Kiste installierst. kannst du auch mit der die GPO´s für den SP2 verwalten ;-)

Versuch mal die Gruppenrichtlinie von einer XP - Maschine mit installiertem SP2 aus zu pflegen. Auf einem 2k3 - Server sind die zugehörigen Templates nicht drauf.

Vielleicht liegt das ja an einer total trivialen Sache. Schau doch mal in der Windows - Hilfe nach "change user" mit den Optionen /install ; /execute und /query Vielleicht kommst Du dann drauf.

Wir nehmen auch die Dreckup Exe in der 9er Version. Funzt eigentlich schon so wie es soll. Hin und wieder hatten wir aber auch schon diverse Problemchen. Server komplett neu aufsetzen, und dann war´s gut.

Hi! es ist verflixt... Wenn ich als Domänenadmin am Domänencontroller angemeldet bin und z.B per Explorer mich mit einer Administrative Freigabe eines Rechners verbinden will (\\rechner\c$) bekomme ich die Fehlermeldung "Mit diesem Konto kann man sich nicht von diesem Computer aus anmelden". Der Rechner ist in der selben Domäne wie der Domänencontroller. Wenn ich das selbe Spielchen von einem normalen Rechner aus mache, fuktionierts einwandfrei. Also ich bin auf einem normalen Memberrechner mit dem Domänenadministrator angemeldet und kann mich dann auch auf die Freigaben anderer Rechner verbinden. Das Ganze verhält sich so mit allen Memberrechnern, komischerweise kann ich mich aber auf die Freigaben anderer DC´s ohne Probleme zugreifen (also \\domaenencontroller2\c$) Habe auch schon mal einen neuen frisch aufgesetzten DC in die Domäne gehängt, aber das kommt sich dann auf Selbe drauf raus... Mir kommt ds so vor, als wäre da irgend eine komische Policy drinnen. Aber ich finde da nix. Weder in der Default DC - Policy, noch in den anderen.... Hat einer von Euch eine Idee, was da faul ist?