motzel

@goscho um für den Fall der Fälle einen 2. Weg zu haben das AD wieder herzustellen. Wie du an dieser Diskussion siehts gehen die Meinungen hier sehr weit auseinander. Ich wollte mich quasi doppelt absichern, und die Systemstate-Sicherung zusätzlich zum BESR "friest ja kein Brot" :) Viele Grüße motzel

@Nils warum habe ich mit dem Image-Restore den Server kaputt gemacht, wenn ich danach das AD ganz regulär wiederherstelle? Denn wo meine auth. oder nicht auth. AD-Wiederherstellung herkommt, ist dem DC vollkommen egal! (Die Sicherung des Systemstate via ntbackup haben wir vor der Image-Sicherung erstellt.) >>>By the way mit der Meinung stehe ich nicht so ganz alleine dar: http://www.msexchangefaq.de/verschiedenes/imagebackup.htm Auszug:"Es kann aber wohl funktionieren, wenn Sie Imagerestore und Systemstate Restore kombinieren. Für ein Restore des SystemState muss auf dem Zielsystem zuerst einmal Windows laufen. Dieses Windows muss man natürlich nicht von Hand installieren. Es kann ein kleines Windows durch ein Image oder per Remote Installation Services installiert sein. Denkbar ist auch ein Restore eines Imagebackups des gesamten Server. Sie sollten aber immer ein SystemState danach restaurieren". <<< Aber bei einem Punkt hast du recht, und da habe ich mich nicht 100% korrekt ausgedrückt, mea culpa. Für Exchange, SQL, Oracle usw. nutzt man natürlich die zugehörige Agents. Aber um die Frage zu beantworten, warum ich/wir den Aufwand betreiben? Weil in unseren "kleineren Lokationen", in Summe ca. 30 Stück, der DC auch noch DNS, Wins, DHCP, SMS- und WDS-Verteilungpunkt, WSUS, Printserver und Fileserver ist. Okay ;) Beste Grüße motzel

Servus, ich würde mal folgendes Szenario zur Diskussion vorschlagen wollen :) 1. Sicherung des Systemstate mit "Bordmitteln" z.B. ntbackup auf C:\ 2. danach Image der C:\ Partition z.B. via Image von Symantec System Recovery (inkl. des gesicherten systemstate.bkf) 3. Sicherung von D:\ z.B. File, SQL, Exchange (wobei ein Exchange nicht auf einem DC laufen sollte) via File-Backup von Symantec Backup Exec Damit geht man eigentlich jedem Problem aus dem Weg, denn eine schnelle Wiederherstellung des Servers (inkl. Bare Metal Restore) wird erreicht, eine 100% unterstützte Wiederherstellung des Active Directory (über den systemstate) ist möglich und man kann die DB's (SQL, Exchange) sauber sichern. Grüße motzel

ich kann goscho nur zustimmen! Es ist zu einfach definitiv falsch alle Image-Programme über einen Kamm zu scheren. Wenn die eingesetzte SW das VSS-API nutzt dann ist dies ein ganz offiziel von Microsoft unterstützter Weg. Was wir noch zusätzlich machen ist, dass wir vor dem Imageing den Systemstatus via NTBackup (ja, wir haben nochW2K3) auf C:\ sichern, und danach das ganze System (inkl. dem systemstate.bkf file) imagen. D.h. nach einem Desaster-Recovery auf Image-Basis kann man somit ganz normal, nach alter Väter Sitte, den Systemstate im Wiederherstellungsmodus recovern. Wohin der Systemstate gesichert wird, war Microsoft auch schon vor VSS egal ;) Gruß motzel

Hallo, ein 2. Gateway dient der Redundanz, d.h. ist das 1. GW nicht erreichbar dann und nur dann wird das 2. GW angefragt. Was aber evtl. (quasi als Nebeneffekt) von Interesse sein könnte ist die IP-Adressvergabe via DHCP. Wenn der DHCP-Server down sein sollte, und der Client in dieser Zeit z.B. neu gebootet wird, dann behält er seine IP wenn das Default-GW (1. GW oder 2. GW) erreichbar ist. Gruß motzel

Hallo, also das Imagen von DCs ist zwar umstritten siehe z.B. MSXFAQ.DE - Imagebackup als Sicherung LDAP://Yusufs.Directory.Blog/ - Images als Sicherung? oder auch hier im Board z.B. http://www.mcseboard.de/windows-forum-ms-backoffice-31/disasterrecovery-imaging-dcs-129138.html ich persönlich halte es für möglich und praktikabel (wird bei uns in der Firma auch eingesetzt), wobei ich zugeben möchte, dass wir "sicherheitshalber" zusätzlich den Systemstate auch noch (quasi zusätzlich) via ntbackup sichern um direkt nach dem Restore eines DCs via Image (via Symantec Backup Exec System Recovery, welches den Systemstate über VSS sichert und somit ähnlich wie ntbackup arbeitet! s.h. http://support.microsoft.com/kb/875495/en ) eine nicht authorisierte Wiederherstellung des AD des betroffenen DC durchführen zu können. s.h. http://www.mcseboard.de/windows-forum-ms-backoffice-31/imaging-restore-domain-controllern-geht-99963.html Für Exchange, SQL und File (Word, Excel etc.) setzen wir Symantec Backup Exec inkl. der zugehörigen Agents für Exchange, SQL und Openfile-Sicherungen ein. Auf jeden Fall sollte ein Backup (und das zugehörige Restore!!!!) getestet werden ;) Gruß motzel

Servus, evtl. hilft dir dieser Link weiter: Documentation Mit dem Wireless WiFi Connection Utility für Intel-Wlan-Module ist es möglich, dass sich der Laptop am Netz anmeldet (oder besser gesagt mit dem Netz verbindet) bevor das eigentliche User-Login erfolgt, aufgrund dessen, wahrscheinlich die Laufwerke der User verbunden werden. Gruß motzel

Hallo, zu diesem Punkt möchte ich noch kurz auf das Forum bei google verweisen: IE cannot open the Internet site www.google.com....Operation Aborted - Web Search Help Grüße motzel

Hallo, das Problem liegt def. am/im ISA2004/2006 (als Proxy für den IE). Wir haben genau das gleiche Thema und konnten es in 2 unterschiedlichen Umgebungen (d.h. 2 verschiedene Windows-Domänen mit je W2K3R2SP2 + XPSP2 + ISA2006SP1 + IE5/6/7 inkl. Hotfixe etc. und aktueller Java-Runtime 1.6.0.5 bis 13) nachstellen. Wenn der Proxy "umgangen" wird läuft der Seitenaufbau sauber, wenn der Proxy (ISA) vom Browser verwendet wird, kommt es sporadisch zu diesem Fehler. Als Test haben wir bereits den Cache auf dem ISA deaktiviert und mit verschiedenen FW-Regeln experimentiert, jedoch alles ohne Erfolg. Als work around kann man >www.google.de< (z.B. via GPO) im IE zu den unsicheren Seiten hinzufügen, damit werden die seit letzter Woche geänderten Scripte der klassischen Google-Start-Seite (z.B. Dialog für Toolbox etc.) gesperrt, welche für dieses Verhalten (in Verbindung mit dem IE + ISA) verantwortlich sind. siehe: IE öffnet Google.de nicht mehr - Nerd-Blog Wenn jemand eine endgültige Lösung (z.B. Infos über einen Patch für IE und/oder ISA) hat, dann postet dies hier Bitte. Beste Grüße motzel ps. dieses Problem tritt nicht mit dem IE8 und/oder einem anderen Proxy (z.B. Bordermanager) auf

Hallo, na ja, ich würde einen neuen Guest anlegen (also die HW Komponenten wie CPU, RAM, HD, NIC usw. festlegen), diesen Guest von der Acronis-Notfall-CD (z.B. als ISO-Image) booten und hierüber das eigentliche Acronis-Image in dem Guest wiederherstellen. Also genauso vorgehen, als wenn du bei richtiger HW ein Desaster Recovery durchführen würdest, nur dass die Ziel-HW eben der virt. Guest ist. Gruß motzel

Hallo, okay, zur Geschichte mit W2K wurde die Aussage aufgestellt, dass man keinen WINS mehr benötigt, da die Namensauflösung via DNS erfolgt. Jetzt ist es aber leider so, dass verschiedene Programme (darunter auch der Exchange 2000 und 2003) einen Teil der Funktionen über NetBios-Abfragen zur Verfügung stellen, d.h. diese Programme benötigen entweder WINS oder verursachen im LAN Broadcasts (welche ja nicht geroutet werden können!). Somit sollte in einer W2K und/oder W2K3 Umgebung zusätzlich zum DNS auch WINS installiert werden (vor allem wenn WAN-Verbindungen z.B. zwischen mehreren Lokationen genutzt werden und ein zentraler Exchange zum Einsatz kommt). Gruß motzel

Hallo, ich kann mich grizzly999 nur anschliessen, warum sollte es nicht gehen? Gruß motzel

Hallo, wirf doch mal einen Blick hier rein: Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality Gruß motzel

Hallo, ich würde sagen es ist eine Frage was man hat und was man braucht?! Siehe z.B. unser Umfeld: 100 Server (W2K3R2 SP2), 1400 Clients (XP, W2K), alle Lokationen sind via WAN mit der Zentrale verbunden. Wir haben z.B. neben den grossen Einrichtungen (bis zu 500 User) in denen jeweils: 2 bis 3x DC's mit (GC, DNS AD-integriert, WINS-Hub/Spoke) File, Print und DHCP geclustert Exchange2003, SQL2005, WSUS, SMS2003, WDS/RIS für PXE, Virenscannerverteilpunkt, TS (Citrix) usw. separat (d.h. dezitierte Maschinen) vorhanden sind, auch viele kleine Lokationen (im Schnitt 5-10 User) wo nur: 1x DC mit (GC, WINS-Hub/Spoke, DNS AD-integriert, DHCP, File, Print, WSUS, SMS2003, WDS/RIS für PXE und Virenscannerverteilpunkt) auf einer einzigen Maschine gehalten werden. Nur einen Exchange würde ich persönlich nicht auf einen DC mitlaufen lassen. Ansonsten sehe ich die Aufteilung/Zusammenlegung von Windows eigenen Diensten und Funktionen sehr abhängig von der geforderten Performance der Maschine, solange keine Applikationen z.B. ERP/CRM usw. ins Spiel kommen. Anwendungen würde ich schon aus Gründen des Supports immer auf dezitierte Systeme, z.B. in einer VMWare-ESX(i) (d.h. pro Anwendung ein eigenes System), installieren. Die Sicherung erfolgt durch eine Kombination aus NTBackup, Image und Filebackup: 1. Sicherung des Sysstate via NTBackup direkt auf die C:\ Partition 2. Sicherung via Image (inkl. dem vorher gesicherten Sysstate) von C:\ (System) auf ein NAS bzw. Backup-Server (Symantec Backup Exec System Recovery) 3. Sicherung via File-Backup von D:\ (Daten) auf ein NAS bzw. Backup-Server (Symantec Backup Exec inkl. Agents für Exchange, SQL, OpenFile etc.) Zum Thema des Imagens von DC's (USN Rollback-Problem) würde ich gerne kurz auf: MSXFAQ.DE - Imagebackup als Sicherung verweisen. Die 5 FSMO-Rollen werden bei uns auf einem einzigen DC (erster DC in der Gesamtstruktur) in der Zentrale gehalten. Viele Grüße motzel

Servus, also wir verwenden die buffalo terastation pro II. Gruß motzel

Hallo, ja, was du möchtest geht definitiv, aber wie schon gesagt wurde ist Nagios nicht ganz trivial einzurichten, weshalb ich dir für den Einstieg das Buch: >Nagios: System- und Netzwerk-Monitoring 2. überarbeitet Auflage< wirklich sehr empfehlen möchte. Amazon.de: Nagios: System- und Netzwerk-Monitoring: Wolfgang Barth: Bücher Eine kurze Einführung sprich ein HowTo kann man sich aber auch direkt von der Nagios-Site http://www.nagios.org/docs/ sowie http://nagios.sourceforge.net/docs/3_0/quickstart.html laden. Um z.B. Windows-Eventlogs abzufragen gibt es mehrere Möglichkeiten, wir nutzen das Addon >nagevlog (als Windows-Client) in Verbindung mit NSCA (Plugin für den Nagios-Server)< http://www.steveshipway.org/software/f_nagios.html da es die meisten Möglichkeiten (z.B. beim Ausschluß von Events, die nicht gemeldet werden sollen, bietet z.B. was ist ein kritischer und was ist kein kritischer Fehler?!). Einen Einblick wie sowas, sogar mit einer nachgelagerten SQL-Datenbank, realisert werden kann (soweit muss man es aber nicht unbedingt treiben) kann man sich hier verschaffen Systemmanagement von itnovum auf nagios basierend. Einen Einstieg über die verfügbaren Addons findest du direkt auf Nagios-Site Nagios: Addons sowie unter http://www.nagiosexchange.org/cgi-bin/page.cgi?d=1 Mit einer kleinen Testumgebung z.B. mit 2,3 virt. Maschinen kann man nach 3 bis 4 Tagen (hinter Zuhilfenahme einer guten Dokumentation s.h. Buch oben) ganz brauchbare Ergebnisse vorzeigen. (Bei uns in der Firma überwachen die Kollegen mit Nagios über 300 Geräte und mehr als 1400 Dienste, Eventlogs, Festplattenauslastungen, CPU-Auslastungen, Temperaturüberwachung, Raid-Controller, Netzteile aber auch Zeitstempel von Backupfiles etc. von Linux- und Windows-Maschinen sowie auch via ping die Erreichbarkeit von Routern und Switche). Gruß motzel

auch wenn man mich jetzt "steinigt" ;) ich halte Images von DC's schon für praktikabel, wenn: A. entweder die Image-Software "AD-Aware" ist z.B. Symantec Backup Exec System Recovery Server (ab W2K3 wegen dem erforderlichen VSS) oder B. nach dem Restore des Images ein aktueller Systemstatus, welcher vor der Imageerstellung via NTBackup erzeugt wurde, wieder eingespielt wird (F8 + nicht auth. Wiederherstellung) Wenn ein W2K3 mit SP1 oder später im Einsatz ist "schützt" sich der wiederhergestellte DC insofern gegen das USN-Rollback-Problem da er erkennt dass er nicht systemkonform wiederhergestellt wurde s.h. How to detect and recover from a USN rollback in Windows Server 2003 (Messages 1 - 4). @NilsK empfohlen wird es nicht, aber unter: http://www.microsoft.com/downloads/details.aspx?familyid=64db845d-f7a3-4209-8ed2-e261a117fc6b&displaylang=en findest du ein How-To: DC_VS2005.doc im Bezug auf DC's in virt. Maschinen und hier wird auf den Seiten 18-33 auch auf das USN-Rollback-Problem hingewiesen, dass z.B. eintritt wenn eine virt. C:\-Platte einfach wieder restored wird (entspricht zu 100% einem Image-Restore) und genau deshalb wird auf einen Registry-Hack eingegangen (Seite 32-33), der dem DC "vorgaugelt" es wäre eine nicht auth. Wiederherstellung des Systemstatus erfolgt, weshalb er sein AD mit einem "benachbarten" DC abgleicht. Viele Grüße motzel

Hallo, also wir geben es auf :( und werden die Logonscripte in den Userprofilen hinterlegen. Vielen herzlichen Dank an alle die versucht haben zu helfen, big thx* :) motzel

Hallo Sunny61, der Logonserver wurde gefunden (auch aus dem korrekten Subnetz), die IP-Adresse wurde vom DHCP sauber zugeordnet (die Clients und die zugehörigen DC's sind im gleichen Netz), es passt eigentlich alles ... Warum wir noch kein SP3 einsetzen, naja unser Netz besteht aus 1300 PC's da sollte so ein Roll-Out (ja, klar geht auch bei uns über den WSUS) vorher sauber verprobt werden (wegen evtl. Nebeneffekten mit div. Anwendungssoftwaren). Das Problem tritt auf ganz unterschiedlicher HW auf, so dass ich NIC-Treiber fast ausschliessen möchte. Unser workaround sieht 2 mögliche Alternativen vor: 1. ein wait für 15 Sekunden ganz am Anfang vom Logon-Script (evtl. wird ja das Script aufgerufen, aber zu diesem Zeitpunkt wegen eines "Scriptfehlers" gleich wieder beendet. Was ich damit meine ist, dass das Script zu dem Zeitpunkt eben noch nicht korrekt abgearbeitet werden kann, ein paar Sekunden später eben schon, da dann die "Umgebung" soweit steht.) 2. wir vergessen die GPO-Logon-Scripte und weisen diese, wie zu NT4.0 Zeiten, den Userprofilen direkt zu. Was mich halt stutzig macht, im WWW gibt es unzählige Beiträge in X-Foren zu diesem Thema und selbst MS sagt: Die zwei Seiten beim Verarbeiten der Gruppenrichtlinien-Skripterweiterung: Teil 1 dass es viele Gründe hierfür geben kann, nur einen 100% Weg wie man es "richtig macht" scheint es nicht zu geben :( Viele Grüße motzel

Hallo Sunny61, ja, ich hatte es heute wieder und saß direkt vor dem System. Die DC's sind sauber, replizieren, usw. auch die Überprüfung am Client (direkt nach der Anmeldung) ergab, dass die GPO's gezogen wurden. Nur hat auch diesesmal das eigentliche Hochfahren (also Übernahme der Computerkonfiguration und der Sicherheitsrichtlinie) ca. 2 bis 3 Minuten gedauert (Schätzwert). Ich bin mir fast sicher dass die Kisten, aus welchem Grund auch immer, auf einen TimeOut laufen, der nicht im Eventlog des Clients aufgezeichnet wird ... Wobei laut MS: http://support.microsoft.com/kb/328991/en-us dieses verhalten zumindest unter W2K (okay, ich habe XP SP2) "bekannt" ist. In diesem Zusammenhang habe ich noch einen sehr interessanten Link: http://www.microsoft.com/germany/technet/scriptcenter/topics/gp/extension1.mspx gefunden. Hier wird beschrieben, dass nicht die GPO's die Logon-Scripte starten, sondern der UserInit-Prozess hierfür verantwortlich zeichnet. Cool ist dieser Satz aus dem Artikel ;) Zitat: "Sie haben alles geprüft und können keinen Fehler finden. Es gibt nicht einmal USERENV-Fehlermeldungen in den Ereignisprotokollen. Sie kommen nicht weiter. ... es ist sehr gut möglich, dass die Gruppenrichtlinie zwar ordnungsgemäß ausgeführt wird, die Skripts jedoch überhaupt nicht ausgeführt werden." Viele Grüße motzel

@snoopy81 ich kann mich Squire nur anschliessen ;) Viele Grüße motzel

@Sunny61 beide Optionen sind gesetzt: Computerkonfiguration \ Administrative Vorlagen \ System \ Anmeldung "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" = aktiviert und: Computerkonfiguration \ Administrative Vorlagen \ System \ Skripts "Anmeldeskripts gleichzeitig ausführen" = aktiviert Hätte evtl. noch jemand eine Idee? Vielen Dank motzel

Hallo, um ein LTO3 oder LTO4 Tape richtig auszulasten benötigt man einen schnellen Transfer zur Bandstation. 40-50 MByte/s sollten es min sein, da sonst das Tape ständig stoppen und wieder anfahren muss, was auf die Lebenszeit geht. D.h. wenn nur ein "geringer" Datendurchsatz vorhanden ist würde ich ein Backup2Disk2Tape empfehlen. Gruß motzel

@Cybquest, ja wir haben mehrere DC's aber die Replikation läuft, um es genau zu beschreiben, wir haben eine einzige Domäne mit mehren Standorten (also mehrere C- und B-Class Netze) mit insgesamt 24 DC's (alle W2K3 R2 SP2). Und das Problem tritt auch an verschiedenen Standorten auf. Ich stimme Sunny61 zu, dass es wahrscheinlich daran liegt, dass der Client die NIC noch nicht ganz aktiviert hat, wenn er versucht die GPO's abzufragen, wobei aber wie gesagt die Eventlog's sauber sind. @XP-Fan, das Problem ist, dass definitiv im Problemfall das Script nicht ausgeführt wird (die Scripte werden sichtbar ausgeführt), habe ich selbst an meinem eigenen Rechner gesehen. Alles was ich noch sagen kann ist, dass im Problemfall das Hochfahren des Systemes "gefühlt" länger als "normal" dauert bis man sich mit User und Passwort anmelden kann. Was ich noch hätte, ist aber wahrscheinlich ein Schlag ins Wasser: Da die interne XP-FW (via GPO) deaktiviert ist, beendet sich auf den Clients der Service Computerbrowser nach 5 Minuten (s.h. Microsoft-KB889320 When you disable the Windows Firewall service on your Windows XP Service Pack 2-based computer, the Computer Browser service stops after five minutes and Event ID 7023 is logged in the Event Viewer). Viele Grüße motzel

Hallo XP-Fan, die Option "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" habe ich bereits gesetzt. Das ist ja genau mein Dilemma, ich weiß nicht wo ich noch ansetzen kann. Viele Grüße motzel