Jump to content

passt

Members
  • Gesamte Inhalte

    874
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von passt

  1. Die Lösung ist gefunden. Alle Systeme laufen richtig. Die Emails waren einfach zu groß. Ich habe in BackupExec den detailiertesten Protokollierungsgrad eingeschaltet und damit habe ich Log-Dateien erzeugt, die bis zu 140MB groß wurden. Selber Schuld :(
  2. Die Zeit wann der User das Kennwort geändert hat bzw. wann sein Konto wieder entsperrt wurde bis das Konto erneut gesperrt wurde, kann ich leider nicht erkennen. Welche ID steht denn für eine Kontosperrung? Welche ID steht für das Aufheben einer Sperrung?
  3. Ja, die Anmeldeversuche werden überwacht. Im Sicherheitsprotokoll steht allerdings nichts relevantes zu 4625.
  4. Ja, klar hat ein User der GL sich schon ausgesperrt.
  5. Hier im Haus habe ich zahlreiche Probleme damit und werde deswegen auch angepfiffen! Die GL als User ist meistens die schlimmste Seuche, da sie ihre Machtposition ausspielen.
  6. Wie machen andere das denn bzgl. Iphone und Exchange. Erhält der User ein zusätzliches Konto speziell für Exchange?
  7. Das ist eine heikle Geschicht. User ist GL und wir haben Vorgaben für unsere Kennwortrichtlinie. Leider nuttz der User Ipad/Iphone, um auf Exchange zuzugreifen. Bei Kennwortwechsel muss am Ipad/Iphone auch das Kennwort geändert werden, ansonsten sperrt der User sich aus. Also, suche ich momentan nach praktikablen Wegen.
  8. Hallo allerseits, Ich habe bei einem User das "Kennwort läuft nie ab" eingestellt und im AD die Kennwortrichtlinie, dass nach x Fehlerversuchen bei Eingabe des Kennworts das Konto gesperrt wird. Diese Kennwortrichtlinie sollte weiterhin dafür sorgen können, dass der User gesperrt wird, wenn die oben genannte Regel verletzt wird oder? Da die Kennwortlrichtlinie auch direkt etwas mit Kennwortwechsel zu tun hat, bin ich in diesem Zusammenhang etwas irriert. Gruß, Peter
  9. Hallo allerseits, seit einigen Tagen habe ich ein seltsames Phänomen. Von der Datensicherungssoftware BackupExec lasse ich mir nach Auftragsabschluss eine Benachrichtigung schicken. Dieser Vorgang hatte bis dato auch ohne Probleme funktioniert. Vor zwei Wochen habe ich in Outlook eine Regel erstellt, diese Mails automatisch in einen Unterordner zu verschieben. Diese Regel habe ich aber nach kurzem wieder gelöscht. Seit dem Zeitpunkt landen diese Benachrichtungen nicht mehr in meinem Postfach. Sie werden auch nicht in den vorher gewählten Ordner oder einem anderen beliebigen Ordner verschoben. Eine Testmail von BackupExec kommt ohne Probleme bei mir an. Dagegen kommen auch keine Emails von BackupExec an, die über einen Auftragsabschluss einer Inventarisierung informieren. Der Nachrichtenverfolgungsprotokoll-Explorer zeigt mir dabei folgende Einträge an: EventID Source Subject RECEIVE SMTP BackupExec-Meldung DSN DSN Unzustellbar FAIL ROUTING BackupExec-Meldung BADMAIL DSN Unzustellbar FAIL ROUTING Unzustellbar Was ist da los? Gruß, Peter
  10. Hallo allerseits, seit einiger Zeit kann ich mich von Win7 Prof nicht mehr automatisch an unseren Terminalservern (W2003, W2008, W2008R2) anmelden. Der TSServer fordert immer zur Eingabe von Benutzername und Kennwort auf und lässt sich dann anmelden. Im geöffneten RDP-Client wird auch die Meldung "An diesen Remotecomputer werden keine Anmeldeinformationen gesendet" angezeigt. Diese Meldung erscheint unabhängig vom Zielcomputer. Wahrscheinlich wird das mit der Verwendung einer Datev Smartcard an meinem Rechner zusammenhängen. Hat jemand eine Idee wie ich das Problem lösen kann? Gruß, Peter
  11. Hallo allerseits. Windows Server 2008 R2 MSSQL 2008 R2 Backup Exec 2010 R3 SP1 mit SQL-Agent Aufgrund eines Totalausfall musste ich unseren virtualisierten Windows Datenbank Server mit MSSQL zurücksichern. Ein Disaster Recovery mit BackupExec war nicht möglich, insofern konnte ich mit einem mehrere Monate alten Snapshot und Windows Updates den Server in einen aktuellen Zustand führen. Die wichtige Anwendungsdatenbank sowie die Systemdatenbanken Master, Model und MSDB sind täglich mit BackupExec "live" gesichert worden. Die Anwendungsdatenbank sowie Master und Model konnte ich problemlos zurücksichern. Bei der MSDB erhalte ich den Fehler: Zu beiden Fehlernummern findet die Symantec Datenbank und/oder Google keine passenden Resultate. Allerdings gehe ich davon aus, dass ich nicht so ohne weiteres die Systemdb MSDB überschreiben kann. Eine Wiederherstellung der MSDB in eine leere frisch erstellte DB ist problemlos möglich. Hat jemand eine Idee wie ich diese Datenbank trotzdem wiederherstellen kann? Benötige ich diese Version der MSDB überhaupt? Wenn ich es richtig verstehe, wird diese DB verwendet, um zB. die bisherigen Sicherung-/Wartungsläufe zu registrieren. Vorschläge? Gruß, Peter
  12. Die doppelten SPNs kann ich dann ja mit "setspn -X" herausfinden. Danke
  13. Hallo allerseits. Frage zu DC mit Windows Server 2008 R2 und SPNs (Service Prinicipal Names). Bisher kannte ich nur diese Form zur Erstellung von SPNs: setspn -A InstanceName/FullyQualifiedDomainNameOfServer:Port Domain\User Andererseits kann ich auf dem W2k8R2 in der AD Verwaltung unter Ansicht die Erweiterten Features einschalten. Dadurch wird in den Eigenschaften eines AD-User (bzw. AD-Objektes) das zusätzliche Register "Attribut-Editor" angezeigt. (Ich denke, es handelt sich um die Einbettung des ADSI-Editors.) Reicht es aus, dort das Attribut servicePrincipalName in der Form InstanceName/FullyQualifiedDomainNameOfServer:Port einzutragen? Gruß, Peter
  14. So, jetzt komme ich dazu mich wieder zu melden. Die Lockoutschwelle habe ich bereits am Montag von 5 auf 10 erhöht. Der niedrige Wert ist eine Vorgabe von unseren Wirtschaftsprüfern, die ich jetzt aufgrund der Praxis erhöht habe. Heute gab es übrigens keinen Anruf! Wie kann ich denn feststellen, welcher DC die Anmeldeversuche des Users entgegen genommen hat? Idealerweise würde ich das gerne mittels XPath-Abfrage ermitteln, ohne dass ich mir einen Zeitraum von einer Woche exportieren und per ASCII-Suche finden muss. Kann hier jemand helfen? Gruß, Peter
  15. Unabhängig davon, dass ich noch die XPath-Form des Queries suche, habe ich inzwischen festgestellt, dass heute morgen bereits der erste Anmeldeversuch aufgrund von Kontosperrung gescheitert ist: Überwachung gescheitert 30.04.2012 05:49:55 Microsoft-Windows-Security-Auditing 4771 Kerberos-Authentifizierungsdienst "Fehler bei der Kerberos-Vorauthentifizierung. Kontoinformationen: Sicherheits-ID: domäne\benutzername Kontoname: benutzername Dienstinformationen: Dienstname: krbtgt/DOMÄNE Weitere Informationen: Ticketoptionen: 0x40810010 Fehlercode: 0x12 Typ vor der Authentifizierung: 0 Die letzte Meldung davor war eine erfolgreiche Abmeldung. Ich kann mir das nicht erklären was da los ist. Irgendwelche Ideen? Vielleicht muss ich anders suchen. Wird in der Ereignisanzeige angezeigt, wann ein Benutzerkonto deaktiviert wird? Peter
  16. Hallo allerseits, ich habe einen User, der mich regelmäßig zu nachtschlafender Zeit weckt, weil sein Konto gesperrt ist. Dies kann ich dann auch bestätigen. Nun versuche ich anhand des Sicherheitsprotokoll am 1st DC die Ursache hierfür zu erkennen. Ich tue mich mit dem Filtern des Logs schwer. Ich würde gerne nur die Resultate sehen, die in der Beschreibung den Benutzernamen enthalten. Kann mir jemand sagen wie den Filter im XPath-Format manuell erstellen kann, damit nach dem Benutzername in der Beschreibung gefragt wird? Gruß, Peter
  17. Wenn ich das richtig verstehe, müsste Point and Print abhängig von der Windows Version eingestellt werden. Wie kann ich den GPOs nur für Win7 oder Vista gelten lassen?
  18. Hallo allerseits, Ich habe einen Windows Server 2008 R2 als Druckerserver. Per GPO werden die Drucker für die einzelnen User verbunden. Bei einigen Arbeitsplätzen kommt es vor, dass die Installation des Druckertreibers nur mit Admin möglich ist. Ich glaube, es handelt sich dabei immer um Win7 Rechner; bei WinXP sollte es auch ohne Admin funktionieren. Wie kann ich die Anfrage nach Adminrechten für die von mir als Admin geplante Druckerverbindung unterbinden? Gruß, Peter
  19. passt

    Win7 5719 netlogon

    Hallo allerseits, ich habe in unserem Netz (W2k8R2 Server und vorwiegend Win7 Clients) festgestellt, dass wenige Win7 Rechner sporadisch die Anmeldung verweigern und behaupten "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden". Gelöst habe ich das Problem bisher, indem ich den Rechner neu mit seiner Netzwerk-ID in der Domäne registriert habe. Jetzt habe ich das Problem mit dem Ereignis Netlogon 5719 in Zusammenhang bringen können. In einem anderem Beitrag aus diesem Forum wird vorgeschlagen, die Gruppenrichtlinie Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten. Unter Gruppenrichtlinien.de wird diese Einstellung als bekanntes Problem bei WinXP genannt. Ist das unter Win7 immer noch ein sporadisches aber doch durchaus bekanntes Problem? Habe ich die Möglichkeit diese Gruppenrichtlinie auch nur für einzelne Rechner, bei denen das Problem aufgetreten ist, zu aktivieren und nicht gleich bei allen Clients in der Domäne? Allerdings ohne mich an jeden Rechner einzeln setzen zu müssen und lokal die Gruppenrichtlinie einzustellen. Gruß, Peter
  20. Nach seinem Anruf hatte ich nicht mehr geschlafen.
  21. Passend dazu: Werden ein Mathematiker, ein Physiker und ein Computeruser getrennt von einander eingeschlossen. Jeder erhält zwei Glaskugeln. Nach einer Stunde schaut man was diese Leute damit machen. Der Mathematiker sitzt dort und berechnet das Volumen und die Oberfläche der Kugeln. Der Physiker hält die Kugeln gegen das Licht und berechnet Brechzahl und Absorptionsköffizient. Als letztes schaut man beim Computerbenutzer herein und stellt fest, dass eine Kugel weg ist und das Fenster zerbrochen. Auf die Frage, was denn passiert sei, zuckt der User nur mit den Achseln und sagt: "Ich hab' nix gemacht...!"
  22. Hintergrund war, dass das Konto eines Users zweimal hintereinander morgens (als ich noch geschlafen hatte) gesperrt war, und er mich anrief. Bevor ich pauschal den User abwatsche mit "Ich weiß, du hast nichts getan!" wollte ich versuchen im Ereignisprotokoll nachzuforschen warum der Fehler passiert ist. Letzendlich hat er auch nichts getan - nämlich NICHT Num-Lock gedrückt!
  23. Ich habe aufgrund der von dir genannten EventID und dem passenden Begriff Lockout erst das Tool gefunden.
×
×
  • Neu erstellen...