Marco31

Also, ich würde dann

1. defekten DC herunterstufen mit dcpromo

2. Computerkonto de defekten DC in AD Benutzer und Computer löschen (und damit auch die FSMO-Rollen übertragen)

3. Metadata Cleanup falls noch "Reste" des alten da sind.

 

Tut mir leide dass ich hier alles dreimal wiederhole, aber ich möchte Fehler vermeiden... ;)

Ok. Der defekte DC ist 2008 R2, der funktionierende DC ein 2016er. Mache ich zuerst Metadata Cleanup mit NTDSUTIL wie in https://support.microsoft.com/de-de/help/216498/how-to-remove-data-in-active-directory-after-an-unsuccessful-domain-co oder lösche ich zuerst das Konto des DC's in AD Benutzer und Computer?

Müsste ich vorher die FSMO-Rollen auf den noch laufenden DC übertragen oder sollte das automatisch laufen?

Hallo liebe Forengemeinde,

 

ich musste heute morgen einen meiner DC's (VM) abschalten nachdem eines des Updates von letzter Woche seit gestern in einer unendlich-Installation hing. Leider werden mir nach Neustart des Servers Replikationsprobleme angezeigt:

 

Verzeichnisserverdiagnose

Anfangssetup wird ausgefhrt:

   Der Homeserver wird gesucht...

   Homeserver = VMDOMCON1

   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgefhrt.

  
   Server wird getestet: Standardname-des-ersten-Standorts\VMDOMCON1

      Starting test: Connectivity

         ......................... VMDOMCON1 hat den Test Connectivity

         bestanden.

 

Prim„rtests werden ausgefhrt.

  
   Server wird getestet: Standardname-des-ersten-Standorts\VMDOMCON1

      Starting test: Advertising

         ......................... VMDOMCON1 hat den Test Advertising

         bestanden.

      Starting test: FrsEvent

         ......................... VMDOMCON1 hat den Test FrsEvent bestanden.

      Starting test: DFSREvent

         Fr den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind

         Warnungen oder Fehlerereignisse vorhanden. Fehler bei der

         SYSVOL-Replikation k”nnen Probleme mit der Gruppenrichtlinie zur Folge

         haben.
         ......................... VMDOMCON1 hat den Test DFSREvent bestanden.

      Starting test: SysVolCheck

         ......................... VMDOMCON1 hat den Test SysVolCheck

         bestanden.

      Starting test: KccEvent

         ......................... VMDOMCON1 hat den Test KccEvent bestanden.

      Starting test: KnowsOfRoleHolders

         ......................... VMDOMCON1 hat den Test KnowsOfRoleHolders

         bestanden.

      Starting test: MachineAccount

         ......................... VMDOMCON1 hat den Test MachineAccount

         bestanden.

      Starting test: NCSecDesc

         Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine

            Replicating Directory Changes In Filtered Set
         Zugriffsrechte fr den Namenskontext:

         DC=ForestDnsZones,DC=domain,DC=lokal
         Fehler: NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION besitzt keine

            Replicating Directory Changes In Filtered Set
         Zugriffsrechte fr den Namenskontext:

         DC=DomainDnsZones,DC=domain,DC=lokal
         ......................... VMDOMCON1 hat den Test NCSecDesc nicht

         bestanden.

      Starting test: NetLogons

         ......................... VMDOMCON1 hat den Test NetLogons bestanden.

      Starting test: ObjectsReplicated

         ......................... VMDOMCON1 hat den Test ObjectsReplicated

         bestanden.

      Starting test: Replications

         ......................... VMDOMCON1 hat den Test Replications

         bestanden.

      Starting test: RidManager

         ......................... VMDOMCON1 hat den Test RidManager bestanden.

      Starting test: Services

         ......................... VMDOMCON1 hat den Test Services bestanden.

      Starting test: SystemLog

         Fehler. Ereignis-ID: 0x80001778

            Erstellungszeitpunkt: 11/20/2017   07:50:51

            Ereigniszeichenfolge:

            Das System wurde zuvor am 20.11.2017 um 07:48:50 unerwartet heruntergefahren.

         Fehler. Ereignis-ID: 0x00000029

            Erstellungszeitpunkt: 11/20/2017   07:50:39

            Ereigniszeichenfolge:

            Das System wurde neu gestartet, ohne dass es zuvor ordnungsgem„á heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestrzt ist oder die Stromzufuhr unerwartet unterbrochen wurde.

         Warnung. Ereignis-ID: 0x8000001D

            Erstellungszeitpunkt: 11/20/2017   07:50:58

            Ereigniszeichenfolge:

            Vom Schlsselverteilungscenter (Key Distribution Center, KDC) kann kein passendes Zertifikat fr Smartcard-Anmeldungen gefunden werden, oder das KDC-Zertifikat konnte nicht verifiziert werden. Das Anmelden per Smartcard funktioniert m”glicherweise nicht ordnungsgem„á, so lange dieses Problem nicht behoben wurde. Verifizieren Sie zum Beheben dieses Problems entweder das vorhandene KDC-Zertifikat mithilfe von "certutil.exe", oder registrieren Sie sich fr ein neues KDC-Zertifikat.

         Fehler. Ereignis-ID: 0xC00110F1

            Erstellungszeitpunkt: 11/20/2017   07:51:36

            Ereigniszeichenfolge:

            Der WINS-Server konnte die Sicherheitseinstellung fr schreibgeschtzte Vorg„nge nicht initialisieren.

         Warnung. Ereignis-ID: 0x8000001D

            Erstellungszeitpunkt: 11/20/2017   07:53:00

            Ereigniszeichenfolge:

            Vom Schlsselverteilungscenter (Key Distribution Center, KDC) kann kein passendes Zertifikat fr Smartcard-Anmeldungen gefunden werden, oder das KDC-Zertifikat konnte nicht verifiziert werden. Das Anmelden per Smartcard funktioniert m”glicherweise nicht ordnungsgem„á, so lange dieses Problem nicht behoben wurde. Verifizieren Sie zum Beheben dieses Problems entweder das vorhandene KDC-Zertifikat mithilfe von "certutil.exe", oder registrieren Sie sich fr ein neues KDC-Zertifikat.

         Fehler. Ereignis-ID: 0xC00110F1

            Erstellungszeitpunkt: 11/20/2017   07:53:37

            Ereigniszeichenfolge:

            Der WINS-Server konnte die Sicherheitseinstellung fr schreibgeschtzte Vorg„nge nicht initialisieren.

         Warnung. Ereignis-ID: 0x80000434

            Erstellungszeitpunkt: 11/20/2017   07:54:23

            Ereigniszeichenfolge:

            Der vom Benutzer domain\domadmin1 angegebene Grund fr das unerwartete Herunterfahren des Computers: Anderer Grund (nicht geplant)

         Warnung. Ereignis-ID: 0x8000001D

            Erstellungszeitpunkt: 11/20/2017   08:11:50

            Ereigniszeichenfolge:

            Vom Schlsselverteilungscenter (Key Distribution Center, KDC) kann kein passendes Zertifikat fr Smartcard-Anmeldungen gefunden werden, oder das KDC-Zertifikat konnte nicht verifiziert werden. Das Anmelden per Smartcard funktioniert m”glicherweise nicht ordnungsgem„á, so lange dieses Problem nicht behoben wurde. Verifizieren Sie zum Beheben dieses Problems entweder das vorhandene KDC-Zertifikat mithilfe von "certutil.exe", oder registrieren Sie sich fr ein neues KDC-Zertifikat.

         Fehler. Ereignis-ID: 0xC00110F1

            Erstellungszeitpunkt: 11/20/2017   08:12:28

            Ereigniszeichenfolge:

            Der WINS-Server konnte die Sicherheitseinstellung fr schreibgeschtzte Vorg„nge nicht initialisieren.

         ......................... VMDOMCON1 hat den Test SystemLog nicht

         bestanden.

      Starting test: VerifyReferences

         ......................... VMDOMCON1 hat den Test VerifyReferences

         bestanden.

  
  
   Partitionstests werden ausgefhrt auf: ForestDnsZones

      Starting test: CheckSDRefDom

         ......................... ForestDnsZones hat den Test CheckSDRefDom

         bestanden.

      Starting test: CrossRefValidation

         ......................... ForestDnsZones hat den Test

         CrossRefValidation bestanden.

  
   Partitionstests werden ausgefhrt auf: DomainDnsZones

      Starting test: CheckSDRefDom

         ......................... DomainDnsZones hat den Test CheckSDRefDom

         bestanden.

      Starting test: CrossRefValidation

         ......................... DomainDnsZones hat den Test

         CrossRefValidation bestanden.

  
   Partitionstests werden ausgefhrt auf: Schema

      Starting test: CheckSDRefDom

         ......................... Schema hat den Test CheckSDRefDom bestanden.

      Starting test: CrossRefValidation

         ......................... Schema hat den Test CrossRefValidation

         bestanden.

  
   Partitionstests werden ausgefhrt auf: Configuration

      Starting test: CheckSDRefDom

         ......................... Configuration hat den Test CheckSDRefDom

         bestanden.

      Starting test: CrossRefValidation

         ......................... Configuration hat den Test

         CrossRefValidation bestanden.

  
   Partitionstests werden ausgefhrt auf: domain

      Starting test: CheckSDRefDom

         ......................... niederaula hat den Test CheckSDRefDom

         bestanden.

      Starting test: CrossRefValidation

         ......................... niederaula hat den Test CrossRefValidation

         bestanden.

  
   Unternehmenstests werden ausgefhrt auf: domain.local

      Starting test: LocatorCheck

         ......................... domain.local hat den Test LocatorCheck

         bestanden.

      Starting test: Intersite

         ......................... domain.local hat den Test Intersite

         bestanden.

 

Der fehlerhafte DC hat die FSMO-Rollen. Wie wäre jetzt die beste Vorgehensweise? DC demoten und neu hochstufen oder komplett entsorgen?

Oder welche Möglichkeiten habe ich das evtl zu reparieren?

Vielen Dank für den Tip mit BITS begrenzen, werde ich mir bei Gelegenheit anschauen. Automatische Update-Genehmigung ist aber nicht mein Ding, genehmige eh immer nur die benötigten Updates.

Ihr glücklichen. Hier werden für 20 Mbit 590 € fällig...

Es gibt für alles einen "Würgaround" ;)

Hast du da mal einen Link?

 

 

Ok, nochmal nachgeschaut. Es hier tatsächlich nur um QoS, also Priorisierung innerhalb des Anschlusses.

https://geschaeftskunden.telekom.de/startseite/festnetz-internet/tarife/internet-telefonie/289950/deutschlandlan-connect-ip-internetanschluss-fuer-firmenkunden.html

Also mit der Traffic-Priorisierung werben manche Anbieter sogar, z.B. Telekom, Vodafone...

Die Verfügbarkeit muss schon entsprechend hoch sein wegen der Rechenzentrum-Anbindung. Es geht niemand pleite wenn die Leitung mal ein paar Stunden oder gar nen Tag nicht läuft, aber macht natürlich nen miesen Eindruck gegenüber Bürgern/Kunden. Und die Mitarbeiter drehen Däumchen.

Tja, die benötigte Bandbreite. Für das "Tagesgeschäft" würden ca. 4-6 Mbit durchaus genügen. Wenn dann aber der monatliche Patchday oder ein anderer Download im Bereich von mehreren GB ansteht reicht das dann halt nicht mehr wirklich...

@Testperson: Hört sich nicht schlecht an mit der Leitungs-Teilung. WSUS haben wir schon im Einsatz, ist aber trotzdem jedes mal der ganze Vormittag Download-Zeit

Bei der bisherigen Leitung sind größere Downloads (ISO's, Patchday, etc.) das Problem. Die Kollegen mit den Rechenzentrums-Anwendungen beschweren sich eh schon dass es teilweise recht langsam läuft, bei großen Downloads meinerseits wird's dann noch schlimmer. Und bei 4-6 GB jeden Patchday ist jedes mal die Leitung für den ganzen Vormittag "dicht".

Ja, bis vor einiger Zeit hat es gereicht. Es wurde aber seitens des Rechenzentrums vor zwei Jahren eine neue Anwendung eingeführt, die braucht mehr Bandbreite als die alte. Und die Downloads für den Patchday sind seit Windows 10 auf das doppelte bis dreifache angestiegen.

Die 2Mbit-Leitung ist natürlich auch ne symmetrische Standleitung.

Hallo liebes Forum,

 

bei uns steht die Erweiterung der Internet-Leitung an von derzeit 2 MBit auf 10-20 Mbit. Die derzeitige Standleitung wird für die Verbindung mit einem Rechenzentrum  (Email-Frontend, Anwendungen über Citrix) sowie für den Internet-Zugang genutzt.

 

Da derzeit bei uns Glasfaser (sozusagen direkt vor der Haustür) ausgebaut wird, bietet sich die Aufrüstung der Leitung an. Jetzt ist aber das Problem, dass Business-Leitungen ("Standleitungen") ja nunmal preislich in einer anderen Liga spielen als der heimische DSL-Anschluss... Darum habe ich jetzt die dankbare Aufgabe, dem Entscheidungsgremium (Gemeindegremium von denen niemand auch nur im Ansatz was mit der Materie zu tun hat) klar zu machen, warum der 40 € Heim-DSL für den Business-Einsatz NICHT reicht.

 

Als Argumente habe ich bis jetzt folgendes:

- Symmetrische Leitung mit vollen 10 bzw 20 Mbit im Up- UND Download

- Garantierte Bandbreite

- Traffic-Priorisierung gegenüber anderen Anschlüssen/Tarifen

- Feste IP-Adresse(n) und keine Zwangstrennung

- Höhere Verfügbarkeit

 

Wenn ich hier falsch liege oder es noch andere Argumente gibt wäre ich dankbar für jede Antwort :-)

Schau mal auf der veeam Homepage, da gibt's entsprechende Infos was welche Version kann.

Bitte auch bei Veeam beachten was du ggf zurücksichern musst. Beim SQL (und exchange) ist die essentials eingeschränkt.

Wir sichern unsere VM's unter VMWare auch mit veeam. Ist einfach Top!

Ich würde auch nicht unbedingt meinen USB-Stick beim Kunden einstöpseln und dann wieder an Rechnern im eigenen Netz anschließen...

Unser WSUS ist ein 2012 (ohne R2) und verteilt problemlos alle Updates auf die Win10 Clients, durchgängig von 1511 bis 1703. Sollte also nicht am 2012er liegen...

Was ich hier nicht ganz verstehe; warum installiert man ein Update, welches voraussichtlich einen Neustart erfordert, OHNE den Server danach neu zu starten? Klingt für mich ehrlich gesagt nicht so wirklich sinnvoll.

Wartungszeit einplanen, Patch installieren, Neustart, fertig.

Gelöscht, war Mist, sorry.

Ich kann auch bestätigen dass Netzlaufwerke unter Windows 10 problemlos funktionieren. Wird bei uns per GPO verbunden. Sollte also eher an eurer Konfiguration liegen...

Gehen tun die schon, nur die Schrift ist halt teilweise "anders"  :D 

Ich bin kein Dienstleister, aber ich hoffe einfach mal dass nicht du das dem Kunden verkauft hast...

Moment, kurze Frage noch. Auf dem "alten" SQL ist SharePoint in einer separaten Instanz. Muss ich dann beim Alias setzen für den Namen des "alten" Servers auch die Instanz angeben à la vmsql\SharePoint? Das würde erklären warum der Alias nicht funktioniert.

 

Scheint die Angabe der Instanz beim Alias für den "alten" Server gewesen zu sein, jetzt läuft's. Eigentlich ziemlich logisch wenn ich so drüber nachdenke... :shock:

Es sind halt manchmal die einfachsten Dinge.

So, kleine Rückmeldung. Die Sache mit dem Konfigurationsassistenten war eigene Dummheit... Der Account mit dem ich mich eingeloggt hatte war nicht entsprechend berechtigt, mit dem SharePoint Setup-Account funktioniert der Assi.

Maxdop=1 war für die neue SP-Instanz nicht gesetzt, habe das jetzt nachgeholt und werde testen ob der Umzug nach Änderung der Einstellung funktioniert.

Leider hatte der Umzug auch mit aktiviertem maxdop=1 keinen Erfolg. Ich bekomme nach starten der SharePoint-Dienste statt der SharePoint-Seite nur folgenden Fehler angezeigt (Bild1)

Auf Bild2 und Bild3 habe ich mal die Einstellungen am SQL für die Instanz und am SharePoint für den Alias angehängt... Sollte eigentlich richtig sein.

Fällt noch jemandem was dazu ein?

Ok, das ist ein guter Anhaltspunkt. Werde ich probieren, vielen dank schonmal!

Ja, hatte ich eben mal gegoogelt. Wenn ich's richtig verstanden habe verursacht Maxdop ungleich 1, dass die DB's nicht richtig angelegt werden. In meinem Fall wurden die Datenbanken aber aus einer Sicherung wiederhergestellt.

Die Sharepoint Farm wurde erst vor ca. zwei Wochen auf den aktuellsten Patch-Stand gebracht. Maxdop dürfte NICHT auf 1 stehen (kann ich erst morgen nachschauen), aber die DB's sind ja eigentlich schon vorhanden da wiederhergestellt...? Oder verstehe ich da was falsch?