Jump to content

Daniel999

Members
  • Gesamte Inhalte

    10
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von Daniel999

Explorer

Explorer (4/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Also dass es sinnvoll wäre, dass jeder mit seinem Domänenkonto arbeitet ist mir auch klar. Leider kann ich das nicht entscheiden. Das ändert aber auch nicht daran, dass hier irgendein Problem vorliegt, wo es ganz interessant wäre die Ursache zu finden. Das mit den Diensten ist nen guter Hinweis, werde ich mir mal anschauen. Gibt es nicht auch irgendeine Möglichkeit, zu sehen, an welcher Stelle die Anmeldeversuche stattfinden und durch wen die ausgeführt werden und sowas? Bietet die Systemüberwachung und Protokollierung da evtl. irgendein Werkzeug für? Schonmal Danke für Deine Antwort!
  2. Hallo, ich habe in meiner Firma schon seit längerem ein Problem und keiner von uns hat bis jetzt eine Lösung gefunden. Ausgangsituation: Windows 2003 Domäne mit 2 DC's. Benutzer arbeiten in der Firma größtenteils mit Domänenenutzern. Vereinzelte Mitarbeiter bevorzugen es aber auch in der Firma an ihrem Notebook zu arbeiten. Diese melden sich dann lokal an ihren Notebooks an, benötigen aber beim Zugriff auf Netzwerkressourcen in der Domäne ihre Domänenaccounts. Bei 2 dieser Benutzer kommt es regelmässig zur Sperrung des Domänenbenutzerkontos. Das ist teilweise so extrem, dass das Konto bereits 5 Sekunden nachdem ich es entsperrt habe, direkt wieder dicht ist. Ich habe dann ein kleines Microsoft Tool auf dem Haupt-DC installiert (Name vergessen...) welches gezielt einen Domänenbenutzer überwachen kann und erfolgreiche/fehlgeschlagene Logins mitzählt. Außerdem wird der Status locked/unlocked angezeigt. Dabei konnte ich feststellen, dass jede Sperrung nach exakt 10 falschen Loginversuchen stattfindet. Ich kann aber beim besten Willen nicht rausfinden, an welcher Stelle diese falschen Logins entstehen. Kurios ist auch, dass es in unserer Domäne keine aktive (von der wir wüssten...) Policy gibt, die diese Sperrug mit sich bringen würde. Neuerdings passiert mir dieses Problem mit meinem Domänenbenutzer auch. Ich arbeite zwar garnicht bis sehr selten am Laptop, bin an meiner Worstation in der Firma aber auch als lokaler Admin unterwegs. Bei mir tritt das Problem erst seit ein paar Tagen auf. Ungefähr zu dieser Zeit hatte ich auch das Passwort meines Domänenbenutzers geändert. Evtl. gibt es da einen Zusammenhang. Eine Vermutung meinerseits, die ich aber noch nicht überprüfen konnte ist, dass bei den Notebookbenutzern der lokale Benutzername dem des Domänenuser entspricht. Bei mir ist das jedenfalls der Fall und mein Domänenpasswort ist bis auf ein angehangenes Sonderzeichen auch identisch mit meinem lokalen Kennwort. Sieht das evtl. irgendjemand die Lösung, die ich irgendwie die ganze Zeit vergeblich suche oder hat sonst irgendeine Idee? Das muss doch irgendwie mit dem lokalen und Domänenbenutzer zusammenhängen, dass die sich irgendwie in die Quere kommen und falsche Logins entstehen. Aber ich weiss nicht wie... Würd mich über jede Hilfe riesig freuen, zumal der 2. Notebookbenutzer, der jetzt dieses Problem kürzlich bekommen hat, der Chef meiner Firma ist oO.... € Achja, bei den Clients handelt es sich um XP Pro und Vista Rechner und wir haben auch schon alle gemappten Laufwerke, gespeicherten Netzwerkkennwörter usw. von den Systemen entfernt.
  3. Hallo, ich hab auf unserem 2003 R2 DC über die Default Domain Policy eingestellt, dass bei allen Clients, die sich an der Domäne anmelden, die Windows Firewall deaktiviert wird. Das funktioniert für alle 2000/XP Clients wunderbar. Nur Vista zeigt sich unbeindruckt davon. Kennt jemand eine Lösung für mein Problem?
  4. Problem hat sich erledigt. Lag an unserer DNS Config. Danke Euch!
  5. ne, da geht es nicht wirklich weiter. Die Lösungen da helfen mir nicht weiter.
  6. Also mein Problem besteht weiterhin. Ich hab nun eine OU erstellt. Für die OU hab ich ein Startscript per Computerrichtlinie konfiguriert. In die OU hab ich meinen Rechner verschoben. Weder die Pushprinterconnections.exe, noch die test.bat werden ausgeführt. Im Richtlinienergbnissatz steht für das Objekt Default Domain Policy (Die Default Domain Policy zieht aber, da ich hier z.B. die Windows Firewalls in der Domain deaktiviert habe und das klappt): Dienstag, 18. März 2008 10:55:55 Gruppenrichtlinieninfrastruktur ist aufgrund des unten aufgeführten Fehlers fehlgeschlagen. Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden. Hinweis: Aufgrund einer allgemeinen Schutzverletzung wurde keine der Richtlinien der anderen Gruppenrichtlinienkomponenten verarbeitet. Daher sind keine Statusinformationen für die anderen Komponenten verfügbar. Ich hab die Berechtigungen der Freigabe überprüft und kann mit meinem User auch auf den SYSVOL Freigabe und die darin enthaltenen Dateien zugreifen und diese ausführen. Hat jemand ne Idee? EDIT: Ausserdem heisst es noch: Die aktuellen Versionen der ADM-Dateien sind nicht verfügbar. Dies kann durch nicht ausreichende Berechtigungen oder nicht verfügbare Netzwerkresscourcen verursacht worden sein. Die lokale Kopie dieser ADM-Dateien wird verwendet.
  7. Args, vielen Dank Euch! Ist schon ne ganze Weile her, dass ich mich mit ADS befasst hatte und irgendwie war ich der Meinung, dass die GPOs aus der OU an die darin enthaltenen Gruppen weitergereicht werden. ****er Fehler=/
  8. Hab ich getestet. Wird nicht ausgeführt! Die Batch hab ich ins Logon und ins Script Verzeichnis gepackt und beides als Anmeldescript für meinen User ausführen lassen. Passiert aber nix. Scheinbar hab ich hier ein anderes Problem was nicht direkt mit der Printergeschichte zusammhängt. Also nochmal zum Nachvollziehen: Ich hab ne OU in der Domain erstellt. Richtlinienobjekt erstellt. Anmeldescript in der Richtline zugefügt (besagte Batch Datei) unter der Benutzerkonfig. Gruppe in der OU erstellt. Meinen Domain-User der Gruppe zugefügt. ein überflüssiges gpupdate ausgeführt. Abgemeldet, angemeldet -> nix passiert. Batch Datei hatte ich zuvor testweise ausgeführt und log.txt mit Ordnerstruktur als Inhalt wurde auf dem Server auf LW C:\ erstellt. Am Client kommt aber nix an. Ich werd nochmal im Richtlinienergebnissatz gucken, ob ich da was finde. Bin echt am verzweifeln langsam.... EDIT: Im Richtlinienergebnissatz kommt das Logonscript erwartungsgemäss nicht an...Irgendwelche aufschlussreichen Infos gibts nicht
  9. Danke für die schnelle Antwort. Also die beiden Links hab ich schon durchforstet. Aber ich finde nirgends sonst einen Beitrag, wo zu entnehmen ist, dass mein Problem durch einen Bug oder Fehler der Pushprintersgeschichte auftritt. Ich kann mich also nicht so recht mit der Aussage "ist nicht ausgereift" zufiredengeben. Ich will wissen wo es hakt. Es kann doch nicht sein, dass einfach nichts passiert. Irgendwas muss falsch laufen und ich möchte rausfinden was. Hat denn sonst niemand eine Idee. Ich würd gerne wissen, warum die Richtlinie nicht zieht. Die Pushprinterconnections.exe wird scheinbar garnicht ausgeführt, denn ansonsten hätte ich doch das Logfile auf den Clients. Hab ich evtl. irgendwo nen Denkfehler? Ich hab nun die Datei in den Startup, den Logon und den Scriptsordner kopiert und und bei pro User und pro Computer neben den Standardpfaden noch das Script im Scriptsordner hinzugefügt. Aber nichts passiert. Das kann doch nicht sein...
  10. Hallo, ich habe folgende Problemstellung: Ich möchte in unserer Firma Drucker per GPO/Anmeldescript automatisch bereitstellen lassen. Das Funktioniert aber leider nicht. Unsere beiden DCs sind Windows 2003 Server R2 Rechner und haben beide die Druckerverwaltung installiert. Entsprechend findet man den Punkt "Drucker bereitstellen" bei den Richtlinienobjekten. Ich habe also nun eine OU erstellt und mit dieser ein neues Richtlinienobjekt "Druckerzuweisung" verknüpft. In diesem Richtlinienobjekt habe ich einen Drucker der an unserem Printerserver hängt über den oben genannten Punkt bereitsgestellt. Da es sich bei uns hauptsächlich um Win 2000/XP Clients handelt, musste ich nun noch ein Anmeldescript erstellen, welches die Datei "Pushprinterconnections.exe" ausführt um den "bereitgestellten" Drucker auch tatsächlich bereitzustellen. In dieser OU habe ich nun eine neue Gruppe angelegt und mal testweise ein paar User reingepackt. Allerdings passiert garnichts. Weder bei der Bereitstellung pro User noch bei pro Computer. Da mich das wie gesagt nicht zum Erfolg gefürht hat, habe ich den anderen von MS beschriebenen Weg über die neue Druckerverwaltung mal ausprobiert. also Druckerverwaltung aufgerufen, den Drucker rausgesucht und per Rechtsklick "per Richtlinienobjekt" bereitgestellt. Ich hab also ein neues Richtlinienobjekt angelegt, welches diesen Drucker bereitstellen soll und noch die Pushprinterconnections ins Anmedescript gepackt. Der Drucker wurde dann auch laut Meldung erfolgreich bereitgestellt. Das Richtlinienobjekt hab ich dann wieder an eine OU gebunden usw. Auch hab ich das wieder pro Computer und pro User getestet. Auf den Clients wird der Drucker aber nicht eingerichtet. Füge ich der Pushprinterconnections.exe den Paramter -log hinzu, wird auf den Clients auch kein Log erstellt, so dass ich erstmal annehme, dass das Script garnicht ausgeführt wird. Die Pushprinterconnections.exe habe ich natürlich in den Logon Ordner kopiert, wo sie hingehört und wo jeder Zugruff drauf haben sollte. Ich suche jetzt schon seit 2 Tagen nach dem Fehler aber finde nichts. Auf Vista Clients funktioniert die Druckerzuweisung natürlich auch nicht. Hat jemand einen Tip? Ich bin echt am verzweifeln. Beide DCs haben die Einstellungen auch einwandfrei und sofort repliziert und andere Richtlinien die ich auf exakt diesem Wege implementiert habe funktionieren einwandfrei. Nur die Druckerzuweisung will nicht. Weiss jemand Rat?
×
×
  • Neu erstellen...