cubi

Jo, ich habe jetzt erst gesehen, dass udp dns-timeout unabhängig vom global udp timeout einzustellen ist - raufsetzen auf 10 Sekunden scheint das Problem bereits zu lösen. Da Du mir indirekt bestätigt hast, dass ich keinen grundsätzlichen Konfigurationsfehler habe, muss ich jetzt den Flaschenhals suchen, denn 10 Sekunden für eine DNS Anfrage ist ja nun auch nicht normal. Herzlichen Dank für die schnelle Hilfe Frank

Hi, ich habe hier ein Problem, dass bei unterschiedlichen Servern, Routern und auch Protokollen auftritt, ich scheine also ein grundsätzliches Verständnisproblem zu haben... Ein Beispielszenario: Windows 2003 DNS AD Server im internen LAN, dann ein Cisco 2621 (um den gehts), dann ein Windows 2003 DNS Server in der DMZ. Der AD DNS hat eine Weiterleitung auf den DMZ DNS konfiguriert. Dieser DMZ DNS soll Fragen des AD DNS beantworten, hat sonst mit dem nichts zu schaffen. Der Router ist so konfiguriert: ip inspect name Cbac0 udp ip inspect name Cbac1 udp interface FastEthernet0/0 description zum LAN ip access-group ACL0 in ip inspect Cbac0 in interface FastEthernet0/1 description zur DMZ ip access-group ACL1 in ip inspect Cbac1 in ip access-list extended ACL0 permit udp host AD-DNS host DMZ-DNS eq domain ip access-list extended ACL1 deny ip any any Das funktioniert alles wie erwartet, allerdings erhalte ich in den Logfiles vor allem zur Mittagszeit (alles surft...) solche Einträge mehrmals in der Minute: 27.03.2009 12:14 Router list ACL1 denied udp DMZ-DNS(53) -> AD-DNS(55943), 1 packet Wie kommt denn sowas??? Das gleiche Problem habe ich z.B. mit unserem Webproxy: Anderer Server, anderer Router, anderes Protokoll und Logfile sagt: denied tcp irgendwer(80) -> Webproxy(12345) Wie gesagt, es funktioniert alles, trotzdem wüsste ich gerne, wo diese Logeinträge herkommen. Ratlos Frank

Hm, ja, weil Daims Argumente eigentlich immer noch gültig bleiben. Naja, aber diese Software kann doch der Logik nach nur das automatisieren, was im MS kb Artikel als offizielle Lösung beschrieben ist. Am Ende hast Du wieder einen Server, der nicht von Grund auf neu mit der aktuellen Hardware installiert wurde, sondern die aktuelle Hardware wurde einem Altsystem untergeschoben. Auch wenn das x-mal bei x-verschiedenen Kunden funktioniert hat, bleibt trotzdem noch ein Restrisiko, weil MS nunmal ganz klar sagt, dass diese Vorgehensweise als dauerhafte Lösung nicht empfehlenswert ist. Und leider, leider kann man einige Dinge eben nicht testen. Beispiel Imagesicherung eines Rechners bei laufender Datenbank von irgendeiner beliebigen Software,die kein Mensch kennt. Bei unseren Tests hier ging das in mindestens 50% aller Fälle gut, das Image enthielt aber auch oft genug eine korrupte Datenbank. Sicherlich wirst Du mit der Symantec Lösung einen ganz erheblich höheren Erfolgsgrad erzielen, sonst wäre die Software nicht auf dem Markt. Trotzdem wird auch damit 100% Sicherheit nicht erreichbar sein. Da wir ja nun hier erschöpfend diskutiert haben, wie planungs- und damit kostenaufwendig eine saubere Lösung ist, kann man dieses Restrisiko selbstverständlich billigend in Kauf nehmen. Nur sollte man das Risiko eben nicht ignorieren, sondern bedenken und dann unter Kosten/Nutzen Aspekten eine Entscheidung treffen. gruss cubi

Ich glaube, ich habe Dich noch gar nicht richtig verstanden. Was dauert denn da so lange? Sowohl Festplatten als auch LTO-2 sollten 30MB/s packen, GBit LAN reicht dafür auch, damit sind 100GB in 1h weggeschrieben. 1h zu 36h, das ist heftig. Woher kommt das? rätselnd cubi

Also ich habe den kb263532 heute mal ausprobiert, das geht tatsächlich. Quelle war ein HP ProLiant ML500, Ziel war ein gewöhnlicher Client mit Intel 945G und SATA Platte. Ich habe zwar deutlich länger als 1h gebraucht, aber am Ende lief es. Wie stellt Backup Exec denn den System State wieder her? Geht das automatisch oder musst Du irgendwann im Verzeichnisdienstwiederherstellungsmodus (yeah!) booten? Was für Fehler hast Du denn im Ereignisprotokoll? Ich habe festgestellt, dass bei einem einzigen DC beim Booten immer Fehler von LsaSrv protokolliert werden (gibts auch einen kb Artikel zu), das ist aber reine Kosmetik. gruss cubi

Hola, Dann habe ich diesen Artikel nicht verstanden, denn: Das hast Du ja auch schon geschrieben, aber was bedeutet das denn? Ich habe durch mein Backup zwar die AD Informationen gerettet, aber alles andere ist auf dem neuen, sauberen DC weg und muss neu installiert werden. Die Dateifreigaben, die freigegebenen Drucker, das datenbankbasierende Programm für die Zeiterfassung, ich muss vorher ausprobiert haben, ob ich auf dem wiederhergestellten DC den Computernamen ändern kann, damit ich auf dem Neuen nicht alle UNC Pfade anpassen muss, von Exchange Postfächern verschieben, Bridgeheadserver ändern will ich gar nicht erst anfangen, und so weiter und so weiter. Aber halt, während ich das so schreibe, fällt mir auf, dass dieses Problem nichts mit dem AD zu tun hat, sondern in der Schwierigkeit liegt, ein konfiguriertes Betriebssystem auf andere Hardware zu bringen. Das ist jetzt richtig übel, denn zum einen muss ich meine bisherigen Aussagen zurücknehmen, das AD Konzept für sich genommen ist tatsächlich unschuldig und doch brauchbar (die erste Cola geht auf mich ;) ), zum anderen aber hätte ich als SBS Admin immer noch das Problem, ein Restore nur mit ganz viel Arbeit, Wissen und regelmässigen vorherigen Tests sauber durchführen zu können. Und wenn ich dann auch noch Inhaber einer EDV Bude sein sollte, der mehrere Kunden betreut, kann ich das mit den vorherigen Tests auch vergessen, denn die Aufwände bezahlt mir kein Mensch. Auch wenn Urmel und Du schlussendlich absolut recht habt, bleibt doch ein schaler Beigeschmack. Aber jetzt sind wir meines Erachtens wirklich an einem Punkt angelangt, an dem man besser persönlich diskutiert, das mit der ICE ist diesbezüglich eine feine Idee :) gruss cubi

Darfst Du, aber wie Du siehst, kriegst Du keine kompetente Antwort, musst also mit mir vorliebnehmen;) Ich würde Exchange in Ruhe lassen, daran zu drehen, endet möglicherweise in Bastelei. Ich kann Dir nur sagen, wie ich das bei anderen Firmen gesehen habe. Wenn deren Zeitfenster zu knapp wurde, haben die einen zweiten Streamer eingesetzt und dann parallel auf beiden gesichert. Wenn das aus welchen Gründen auch immer keine Option war (meistens, weil die Backup Software nicht sauber mit der Hardware zusammenspielte), haben sie nachts mit dem Backupprogramm auf eine ausreichende Anzahl verteilter Festplatten gesichert und die dann in Ruhe tagsüber auf einem Streamerband gesammelt. gruss cubi

Weh mir, Verstärkung ist eingetroffen ;) Lasst mich abschliessend nur darlegen, was ich gemeint habe. Grundsätzliche Diskussionen über Active Directory machen wenig Sinn (auch wenn ich sie selbst angezettelt habe), weil ich am Ende auf jeden Fall verlieren werde. Microsoft wird sein Konzept sicherlich eher nicht überarbeiten, nur weil ich es als überarbeitungswürdig empfinde... Ausserdem sollte man sowas von Angesicht zu Angesicht diskutieren, dann wird auch kein Glaubenskrieg draus und man kann vorher, mittendrin und hinterher zusammen ein Bier trinken... Unter SBS Umfeld verstehe ich eine Firma mit ca 10 Mitarbeitern, die 4-5 Räume in einem Bürogebäude gemietet hat, der Server steht bestenfalls in einer Besenkammer, weil es einen besonders gesicherten Raum schlichtweg nicht gibt und der Geschäftsführer nimmt jedes Wochenende ein Backup mit nach Hause. Als Anforderung gilt das, was schon NT4 konnte: Anmeldung von einem beliebigen Arbeitsplatz aus an einer zentralen Authorisierung, darauf basierend Rechtevergabe für den Zugriff auf Programme, Dateien und Drucker. Dafür gibt ein Entscheider Geld aus, alles andere ist nice to have. Das wird nun mit einer Technik realisiert, die den Anforderungen eines Grosskonzerns genügen würde - ungefähr so als wenn Du einen Lieferwagen benötigst, der Marktführer im LKW-Bau Dir aber nur 38-Tonner mit künstlich reduzierter Ladekapazität anbietet. Das nur zur Erläuterung, wie ich auf die obige Aussage kam, ob man das weiter diskutieren sollte, steht wirklich dahin. Hier aber stelle ich mich auf die Hinterbeine und weiche nicht zurück. Bis zum Eintreffen eines klugen Argumentes halte ich es für eine katastrophale konzeptionelle Schwäche, die Funktionalität eines Servers (also AD) untrennbar mit der Funktionalität der Hardwareunterstützung (also vor allem saubere Unterstützung des vorhandenen Festplattensubsystems) zu verbinden. Ihr habt ja Recht, AD mit nur einem DC ist aus vielen guten Gründen falsch. Aber wenn mir beide DCs geklaut werden, weil nun mal alles an Hardware im Büro geklaut wurde, bin ich nach meinem Wissensstand nicht in der Lage, einen garantiert funktionierenden Restore mit einem Backupmedium auf einem geeigneten, ansonsten beliebigen Rechner zu fahren. Das finde ich immer noch ungeheuerlich. Und das Szenario eines Komplettdiebstahls gehört gerade bei den oben beschriebenen Räumlichkeiten mit in einen Recovery Plan - wie soll der diesbezüglich aussehen? gruss cubi PS: Und ich weiss immer noch nicht, wie ich diese Erstsynchronisation stoppen kann:cry:

Liebes Urmel, das kann ich einfach nicht unkommentiert lassen: Seins oder das des Active Directorys unter ganz besonderer Berücksichtigung der zutiefst simplen Anforderungen an ein Client/Server Betriebssystem im SBS Umfeld??? Wenn man mal seine MS Erfahrungen beiseite schiebt und nur den gesunden Menschenverstand walten lässt, kann ich die von MS zu verantwortende Situation eigentlich nur als ungeheuerlich bezeichnen. Wenn eine Firma von Dieben komplett ausgeräumt wird und man trotz Backup im Panzerschrank (in unseren würde z.B. kein Rechner reinpassen) und schnellem Hardwarelieferanten nicht in der Lage ist, auf von MS supportetem Weg binnen weniger Stunden ein Restore hinzubekommen, dann sollte das eigentlich inakzeptabel sein. Aber was reg ich mich auf... Ich nutz es ja auch trotz allem, und die Befriedigung ist umso grösser, wenn das Mistding am Ende doch noch tut, was man will - trotz aller Unlogik, Unvermögen, Ungeheuerlichkeiten und anderen Unwörtern... gruss cubi

Hi, also einen Leitfaden hab ich nicht, bin aber gerade im Thema... Das einzige Problem besteht ja im Festplattentreiber. Egal was Du machst, sobald Du den Systemstate und damit die Registry im laufenden Betrieb wiederherstellst, fehlt Dir der Plattentreiber für die aktuelle Hardware. Da solltest Du auch unmittelbar nach dem Restore nicht drankommen, weil die wiederherzustellende Registry nicht aktiv ist. Ist dieses Problem gelöst, kriegst Du auch alles andere gelöst. Mir fallen dazu zwei Möglichkeiten ein: 1. Du kaufst einen beliebigen Billigcontroller mitsamt Festplatte, auf die C: passt. Diesen Controller steckst Du jetzt in Deinen Server und installierst ihn, damit ist sichergestellt, dass Dein OS nach dem nächsten Backup diesen Controller auf ewig kennt, auch wenn er wieder ausgebaut wird. Kommt nun ein neuer Server, kannst Du diesen Controller mitsamt Platte einstecken, darauf das Restore fahren und dann die Treiber für den neuen Server installieren. Jetzt musst Du nur noch das OS von der temporären Platte auf die richtige kopieren. Das funktioniert deutlich einfacher (nämlich ohne Controller), wenn Du sicherstellen könntest, dass der neue Server auf jeden Fall einen Standard IDE Anschluss hat - jedoch je professioneller der Server, desto unwahrscheinlicher ist das. 2. Du spielst das Backup auf den neuen Server und bekommst einene BlueScreen, weil der Plattentreiber fehlt. Dann bootest Du z.B. mit einer Bart CD und schiebst dem OS den korrekten Festplattentreiber unter. Das Unterschieben ist auf jeden Fall Bastelarbeit, mir ist das aber mit einem Promise SATA und einem Mylex SCSI Controller gelungen. Wie das geht, erfährst Du indem Du MergeIDE googelst. Die c't hat dazu vor ca. 2 Jahren einen recht ausführlichen Artikel veröffentlicht, grundsätzlich musst Du die nötigen Dateien an den richtigen Platz kopieren, die nötigen Services in die Registry einfügen, eventuell eine Class anlegen und ganz entscheidend den richtigen Eintrag in der CriticalDeviceDatabase stehen haben. Der Server wird dann zwar fürchterlich holprig hochfahren, aber er fährt hoch und Du kannst den Treiber sauber nachinstallieren - und danach auch RAID oder ähnlichen Schnickschnack einrichten. Nein, ich finde das auch nicht wirklich zufriedenstellend, wirklich nicht. gruss cubi

Hi, das sieht schon interessant genug aus, um es einmal auszuprobieren. Allerdings zweifle ich doch etwas, ob ich mit dieser Methode z.B. den Exchange Server in der Testumgebung ans Laufen bekomme. Ich weiss auch nicht, wie vollständig eine solche Kopie wirklich ist, weil die Testumgebung eigentlich nur zum Üben dienen soll, wie man einen aufgetretenen Fehler sauber repariert. Dazu muss ich diese Fehler natürlich mitkopieren. Wir hatten mal den Fall, dass ein ansonsten wirklich lieber und fähiger Kollege in den AD Berechtigungen auf der obersten Ebene den Knopf "Auf Standardberechtigungen zurücksetzen" geklickt hat. Damit waren leider sämtliche Exchange Rechte komplett weg. Wir konnten das mit einem Aufruf vom Exchange Setup wieder hinbiegen, dass ich das aber vorher in der Testumgebung mal ausprobieren konnte, fand ich extrem beruhigend... merci cubi

Hallo zusammen, ich möchte gerne ein Backup unseres DCs in einer isolierten Testumgebung wieder ans Laufen bekommen - was mir leider nicht gelingt. Die Domäne hat einen mich jetzt interessierenden DC mit W2k3SP1 (GC und Inhaber aller FSMOs) in der Zentrale und 4 weitere per WAN in 4 Niederlassungen. Ich mache jeden Abend mit ntbackup eine Sicherung des SystemStates und direkt nach Abschluss von ntbackup eine Imagesicherung des gesamten DCs mit Acronis. Weiterhin steht mir ein Reserveserver mit identischer Hardware zur Verfügung. Wenn ich nun das Acronis Backup auf den Reserveserver spiele, habe ich manchmal Glück und der Server fährt ohne zu murren hoch - nochmal betont, dieser Zustand ist und bleibt auf ewig in einer isolierten Umgebung. Oftmals ist aber das AD erwartungsgemäss inkonsistent, damit bin ich gezwungen, nach dem Acronis Restore auch den Systemstate zurückzuspielen. In der Testumgebung funktioniert das aber auch nicht, ich bekomme nach dem Start von SAM die Meldung, dass ein FSMO Inhaber nicht gefunden werden konnte. Das liegt wohl daran (so habe ich die diversen KB Artikel verstanden), dass der DC zwingend eine Erstreplizierung mit den anderen 4 DCs durchführen will, bevor er AD vollständig aktiviert. Kann natürlich nicht funktionieren. An dieser Stelle kommen die Fragen: Gibt es eine Möglichkeit, eine inkonsistente AD Datenbank hart zu reparieren? Ich würde dann den SystemState nicht zurückspielen und den mit Acronis gesicherten Stand ans Laufen kriegen. Das wär mir das liebste, Replikationsprobleme interessieren mich im Test ja gar nicht. Wenn nein, wie verhindere ich diese Erstsynchronisation? Ich habe versucht, mit ntdsutil die Rollen zu übertragen, habe aber jedes Mal die Meldung beommen, dass die Rollen bereits auf dem Server vorhanden und aktiv sind. Bei repadmin /delete verstehe ich die Syntax offensichtlich nicht, er löscht jedenfalls nix. Das harte Entfernen der anderen DCs mittels mmc hat auch nicht geholfen. Gibt es nicht irgendeine Beschreibung, wie man sowas vor allem schnell hinbekommt? Warum ich überhaupt sowas haben will? Ich hatte letztens nachts einen -1018 auf unserem Exchange Server, trotzdem hat ntbackup eine vollständige Sicherung durchgeführt und die Logfiles der priv.edb gelöscht!!! (Das kann ich zwar auch nicht verstehen, ist aber ein anderes Thema). Da in diesem Hause E-Mail als heilig angesehen wird (ja ich mache stündliche Sicherungen...) , wollte ich sämtliche notwendigen Aktionen zur Wiederherstellung erstmal im Test durchspielen, bevor ich das Heiligtum antaste. Und ohne DC läft Exchange nunmal nicht... recht ratlos cubi

Nee, mit Macs meinte ich die netten Designerkisten von Apple, die obendrein auch noch halb und halb mit OS9 und OSX laufen. Als ich letztens den OS9 Rechnern das von mir erzeugte Stammzertifikat unterjubeln musste (zum SSL Zugriff auf unseren internen Webserver), sind auch ein paar Stündchen vergangen... Gut, fresse ich mich also in die Zertifikatsvergabe rein, mal sehen, wie lange ich dafür brauche... Herzlichen Dank aber jetzt schon für Deine schnelle Hilfe! Zufrieden und arbeitswillig Cubi

Jo, ich hatte schon gehofft, das ein bisschen weniger aufwendig erschlagen zu können - zumal mir bei 802.1x die vier Macs in der Werbeabteilung wars***einlich die grössten Sorgen machen werden. Ist mein Problem denn wirklich so ungewöhnlich? Ist das allen anderen Firmen auf der Welt denn so egal? sich die Schuppen aus den Haaren schüttelnd cubi

Hi zusammen, wir haben hier ein W2K3 AD. Die 250 Clients werden bei der Anmeldung mit Logonscripts und Gruppenrichtlinien bearbeitet. Nun ist aus purem Zufall herausgekommen, dass einige User ihre privaten Notebooks in die Firma nehmen, ans Netz hängen und ohne Antivirus herumsurfen, jede beliebige Software auf ihrem Rechner installiert haben etc. Mindestens einer dieser User ist dabei besonders sorgfältig vorgegangen: Er hat sein Firmenlaptop angeschlossen, sich die IP Adresse aufgeschrieben, die auf seinem Privatrechner fest eingetragen, seinen Rechner wie den Firmenrechner genannt, die Arbeitsgruppe wie unsere Domänen genannt und obendrein seinen Rechner für die Netzwerkumgebung unsichtbar gemacht. Als Sahnehäubchen hat er sogar die MAC Adresse angepasst - das Ganze auch noch voll komfortabel per VBscript... Meine Aufgabe ist es nun, ein solches Verhalten zumindest zu entdecken (ansonsten kann ich mir jede Abmahndrohung sparen) - ich weiss nur nicht, wie. Ich habe mir zuerst die Ereignisanzeige angesehen, glaube aber nicht so recht, dass ich damit weiterkomme: Bei jedem Zugriff auf eine Dateifreigabe finde ich einen Eintrag mit Usernamen und IP Adresse des Clients. Der Client selbst generiert aber nur beim Hochfahren einen Eintrag. Wenn nun wie oben beschrieben der Firmenrechner hochfährt, vom Netz getrennt und durch den Privatrechner ersetzt wird, bekomme ich das nicht mit. Hat einer eine Idee, wie ich da weiterkomme? Wenn es sein muss, kaufe ich auch teure Zusatzsoftware, die Lösung sollte nur eben auch von einem Kollegen mit Hackerqualitäten nicht so ohne weiteres aushebelbar sein. ratlos cubi