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