Jump to content

Michael777

Members
  • Gesamte Inhalte

    17
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Michael777

  1. Hallo, > Nimm also die Verbindung zwischen den Außenstellen raus, wenn die gar nicht existiert. Hab ich gemacht. Die automtisch generierte Verbindung zwischen den AS habe ich auch gelöscht. Das hat aber auch nichts geholfen. Eine Stunde später war sie wieder da. Wenn das Bridging an wäre würde ich ja verstehen, wo die plötzlich wieder her kommt, so ist das überhaupt nicht nachvollziehbar. Hast Du evtl. noch eine Idee dazu? Grüße, Michael
  2. Hallo, > Sites und Sitelinks sind richtig? Bei dem einen Sitelink bin ich mir nicht sicher. Das ist der wzischen den beiden AS. Diese Verbindung ist aber nur durch das Routing über das HQ möglich. Durch das Abschalten des Bridging, sollte sowas doch eigentlich unterbunden werden? > Subnets sind korrekt zugeordnet? Ja. > IP-Adressen der DCs passen zu den Sites und Subnets? Ja. > Automatic Bridging ist aus? Ja. Grüße, Michael
  3. Hallo, das hat sich seit gestern noch mal geändert. Jetzt ist es so: Der DC in der ersten Aussenstelle (AS1) hat eine Verbindung zu Aussenstelle 2 (AS2). AS2 hat je eine Verbindung zu HQ1 und der wiederum hat noch eine zu HQ2. Die Kosten der Verbindungen zwischen den Sites sind übrigens alle gleich. Kann ich die ganzen automatisch generierten Verbindungen gefahrlos löschen und KCC das noch mal neu auswürfeln lassen? Grüße, Michael
  4. Hallo, > Routing richtig konfigurieren, Site Links passend setzen, Bridging aus, manuelle Replikationsverbindungen löschen, abwarten. So hab ich jetzt gemacht, zusätzlich unter IP die durch das Routing ermöglichte Verbindung zwischen den beiden Aussenstellen angelegt. KCC hat die Verbindungen neu generiert, aber so richtig schlau werde ich daraus nicht. Ich hätte eine Art Ring erwartet, damit die Replikation gesichert ist im Falle eines Ausfalls. Stattdessen hat jetzt eine Aussenstelle gar keine Verbindung ins HQ und die anderen hat zu jedem DC im HQ eine. Immerhin meldet "repadmin.exe /showrepl" dass alles OK ist. Danke nochmal & Grüße, Michael
  5. Danke für die schnelle Antwort! Die Aussenstandorte sind über VPN-Verbindungen angebundenen auf denen praktisch kein Traffic reglementiert oder unterbunden wird. Es ist nur so dass diese nichts von einander wissen. Ich denke mit statischen Routen käme man auch von Aussenstandort A in den Aussenstandort B und umgekehrt. Wäre es nicht am saubersten, diese Routen zu setzen, die manuell gesetzen Seitenverküpfungen zu löschen und KCC seinen Job machen zu lassen? Grüße, Michael
  6. Hallo, kann mir jemand sagen, wie man bei einer Sternförmigen Topologie die Replikation richtig konfiguriert? Folgendes Szenario: 2 DCs im HQ Je 1 DC in 2 Aussenstandorten. Standorte, Sitelinks und Subnetze sind richtig konfiguriert Die beiden DCs im HQ replizieren sich gegenseitig, je einer davon soll sich mit einem DC in den Aussenstandorten replizieren. Dafür haben wir z. T. die automatisch erstellten Standortverbindungen gelöscht und neue händisch angelegt. Die KCC(?) erstellt jetzt aber nach 15 Minuten automatisch eine Verbindug zwischen den beiden Aussenstandorten. Das funktioniert natürlich nicht und führt zu entsprechenden Fehlern im dcdiag. Muss man, damit das funktioniert, statische Routen auf den DCs in den Aussenstandorten setzen? Hab auch gelesen, dass man nach Möglichkeit nicht in die Replikation eingreifen soll, es sei denn man hat ein sehr exotisches Setup. Hätten wir die automatisch erstellten Verbindungen belassen sollen? Eine sternförmige Topologie ist ja nun nicht gerade exotisch... Danke für Antworten! Michael
  7. Ich hab in der Zwischenzeit die AV-Exclusions anhand des Links von testperson (Danke!) für alle Server eingerichtet. Das Problem ist seit dem nicht mehr aufgetreten. Kann das ein Admin als "Gelöst" markieren? Oder muss ich das machen? Danke für Eure Hilfe! Michael
  8. Unsere VM mit dem DC hing heute morgen schon wieder und ich musste sie hart abschalten. Die Exclusions hatte ich natürlich auch definiert, hat aber anscheinend nichts gebracht. Das GData Administratortool behauptet zwar die neuen Einstellungen wären auf die betroffenen Maschinen durchgesickert, aber man weiss ja nie. Ich werd am WE mal den Hyper-V Host durchstarten. Vieleicht bringts ja was. Grüße, Michael
  9. Bei uns hat es heute Nacht einen DC in einer 2008R2 VM erwischt. Die Integration Services sind aktuell. Interessant ist, dass auf den bei uns betroffenen VMs auch der GData AV läuft. > Leider läuft nur Powershell1.0, so das ich die Version der Clients wegen der fehlenden Hyper-V Module nicht abfragen kann... Geräte-Manager -> Treiberdetails von Systemgeräte/Hyper-V-* > dann prüf mal die Exclusions deines Virenscanners. Was meinnst Du denn, was man da exkludieren müsste? Mir fällt da nur vmms.exe ein, die läuft aber doch auf dem Host. Grüße, Michael
  10. Ja, sieht ganz danach aus. Nach Update der Integration Services und einem Neustart Donnerstag letzte Woche, ist das Problem nicht mehr aufgetreten. Danke nochmal Floho! Viele Grüße, Michael
  11. Danke für den Hinweis! Die waren natürlich nicht auf dem aktuellen Stand... Ich hab sie jetzt aktualisiert. Mal gucken ob es jetzt besser läuft.
  12. Den 2008er brauchen wir noch wegen einer historischen Altlast die sich nicht in den 2012er SQL-Server migrieren lässt. Ist auch nur eine Übergangslösung... (hoffentlich...)
  13. Hallo, ich habe hier ein Problem mit einer unserer HyperV VMs. Seit dem Patchday letzte Woche friert die VM sporadisch ein und kann nur über Ausschalten/Starten wiederbelebt werden. In der VM läuft Server 2008R2 mit SQL Server 2008 und SQL Server 2012. Die VM hat alle aktuellen Updates installiert und in der Ereignisanzeige findet sich zu dem Problem nichts. Der HyperV Host ist auch Server 2008R2 mit allen Updates. Der Host macht nichts ausser HyperV. Hat jemand ähnliches seit letzter Woche beobachten können, oder hat vielleicht eine Idee dazu? Danke & viele Grüße, Michael
  14. Hm, ich habe in meiner Naivität angenommen, dass das OK ist wenn das Betriebssystem selbst 'rund' läuft und im Gerrätemanager alle Treiber installiert sind. Ein Kollege der das Ganze in einer HyperV VM versucht hat aber auch die gleichen Probleme. dcdiag auf den Produktiv-DCs bringt übrigens keine Probleme mal abgesehen von fehlenden Druckertreibern und dem unkritischen "Test NCSecDesc nicth bestanden". Viele Grüße, Michael
  15. Hallo, Dass das eigentlich so hätte funktionieren müssen, wie ich mir das vorgestellt hatte, beruhigt mich jetzt. Bin doch nicht verblödet :) Merkwürdig ist das ganze aber trotzdem. Gesichert haben wir mit wbadmin mit -systemState. Der Dc2 ist eine HyperV VM, zurück gesichert habe ich in aber in eine Xen VM. Das dürfte aber eigentlich egal sein. Das Problem mit dem öffentlichen Profil im Netzwerk hab ich auch. Das lässt sich auch maximal nur auf Arbeitsplatznetzwerk stellen. Ist aber klar, wenn er die Domäne nicht findet, wird das da auch kein Domänennetzwerk. Ich hab sogar die MAC der NIC geändert, geholfen hat es nicht. Die NIC des Routers konnte ich leider nicht ändern. Möglicherweise erkennt der ja einfach nur sein Netz nicht wieder... Wie auch immer, ich verfolge das jetzt nicht weiter. Ich klopfe lieber mal unsere beiden Produktiv-DCs mit dcdiag ab. Die funktionieren zwar wunderbar, aber man weiss ja nie. Nicht dass da noch was im Busch ist... Danke für Eure Hilfe & viele Grüße, Michael
  16. Danke für die Antwort! Nach dem seizen der Rollen und dem Metadata Cleanup scheint es jetzt zu funktionieren. Zumindest lassen sich die Snap-Ins starten. Ich bin ein wenig überrascht, dass der DC erst funktioniert, nachdem ich das gemacht habe. Wenn mir mein echter Betriebsmaster mal abschmiert, z. B. wegen Netzteildefekt, und ich dann die Rollen auf den DC2 seizen muss, kann ich die DC Installation auf dem Betriebsmaster vergessen. Das kann doch so nicht richtig sein?? Danke & viele Grüße, Michael
  17. Hallo, ich habe hier ein Problem mit einem zuückgesicherten DC. Zwecks Aufbau eine Testumgebung in einem separaten Netz, habe ich unseren zweiten DC (DC2) aus dem Backup zurückgesichert. Leider funktioniert der in seiner neuen Umgebung überhaupt nicht. Beim Aufrufen vom ADUC Snap-In kommt nur: "Es konnte Aufgrund des folgenden Problems keine Namensinfomationen gefunden werden: Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden." Der Server hat keine FSMO Rollen, ist aber DNS Server und hält den GC. Als DNS-Server ist der Server selbst eingestellt und ich kann auch keine Probleme im DNS finden. dcdiag /test:dns gibt auch keine Fehler aus, mal abgesehen von 2 fehlenden AAAA-Records. Wir haben aber IPv6 auf allen NICs deaktiviert, so dass ich nicht glaube dass das ein Problem ist. Ich weiss natürlich, dass man einen DC nicht aus einem Image wiederherstellen soll. Wenn man das aber in ein separates Netz macht, sollte das doch eigentlich funktionieren? Hab ich hier ein Verständnisproblem? Muss ich dem DC2 die FSMO Rollen erst zuweisen (Seize) bevor der nutzbar ist? Edit: Ganz vergessen: Server ist 2008R2. Funktionsebene von Gesamtstruktur und Domäne ist auch 2008R2. Würde mich sehr freuen wenn mir jemand weiterhelfen könnte. Danke & viele Grüße, Michael
×
×
  • Neu erstellen...