none
Database Replication funktioniert nicht

    Question

  • Mahlzeit,

    wir haben das Problem, dass aus unerfindlichen Gründen die Database Replication nicht mehr funktioniert. Der Replication Analyzer sagt, wir sollten dem local System account mal die Rolle sysadmin in der SQL-Datenbank geben. Das Problem ist nur, dass der local System account diese Rolle bereits hat. Hat einer ne Idee, was das sonst sein kann?

    Danke & Gruß

    Thursday, August 9, 2018 10:42 AM

All replies

  • Auf die Ferne schwer zu diagnostizieren, aber vielleicht hilft ja https://support.microsoft.com/en-us/help/20033/troubleshoot-database-replication-service-in-mcm weiter …

    Torsten Meringer | http://www.mssccmfaq.de

    Thursday, August 9, 2018 11:02 AM
    Answerer
  • Ok, soweit so gut. Danke erstmal. Jetzt weiß ich, dass unser CAS im Maintenance Mode ist. Aber wieso, das weiß ich noch nicht. Wie gesagt, mich stört ein bisschen, dass der Replication Analyzer sagt, ich solle SYSTEM die sysadmin-Rolle geben, obwohl das schon so konfiguriert ist. Komm ich da irgendwie weiter oder ist das die falsche Stelle?
    Thursday, August 9, 2018 11:43 AM
  • Hast Du dir aus dem Support Artikel mal die anderen SQL Abfragen angeschaut?

    Torsten Meringer | http://www.mssccmfaq.de

    Thursday, August 9, 2018 11:48 AM
    Answerer
  • Ich bin auch schon die Anleitungen Umair Khan durchgegangen, die quasi deckungsgleich sind soweit ich das beurteilen kann. Vielleicht hab ich auch einfach was übersehen. 

    https://blogs.technet.microsoft.com/umairkhan/2014/03/24/configmgr-2012-drs-troubleshooting-faqs/

    https://blogs.technet.microsoft.com/umairkhan/2014/02/17/configmgr-2012-data-replication-service-drs-unleashed/

    Unser Status ist, dass der CAS im Maintenance Mode ist. Die Primaries aber Active. Der Link Analyzer sagt mir, dass System die sysadmin-Rolle braucht. rcmctrl.log check ich nebenbei (auf'm CAS als auch auf den Primaries), sieht aber unauffällig aus.

    • Edited by Paul Pi Thursday, August 9, 2018 12:24 PM
    Thursday, August 9, 2018 12:18 PM
  • Ohne Gewähr! Datenbankmodifikationen sind an dieser Stelle unsupportet und bergen Gefahren: https://cireson.com/blog/drs-replication-no-worky-2/

    Torsten Meringer | http://www.mssccmfaq.de

    Thursday, August 9, 2018 1:50 PM
    Answerer
  • Guter Link, wirft aber neue Fragen auf.

    Ich bin übrigens soweit, dass der Replication Analyzer nicht mehr anmäkelt, dass SYSTEM den falschen security scope hat. Falls es dich oder jemanden interessiert (oder vielleicht weißt es ja auf nen Fehler hin, man weißet ja immer nicht): Ich habe bei den Eigenschaften des Logins "NT AUTHORITY\SYSTEM" unter Securables zwei mal "Connect to SQL" und nur beim unteren ist ein Grantor eingetragen. Einfach mal aus Spaß das Häkchen darüber auch gesetzt und bestätigt.

    Mein rcmctrl.log sagt, ich möchte DRS machen, aber leider ist der CAS im Maintenance Mode, daher mach ich's nicht. Das muss doch möglich sein, dass irgendwie zurückzusetzen, oder? Hast du ne Idee?

    Ach und danke schonmal für deine Unterstützung.

    Friday, August 10, 2018 8:11 AM
  • Ok, vielleicht soviel noch dazu:

    Wenn ich SMS_Executive neustarte, dann spuckt mir rcmctrl.log aus, dass "Last BCP attempt failed and left status in the appending state. Will try to apply BCP files again." Und dann noch, dass er im bcpDirectory files for publication gefunden hat für einen der Primaries, den ich für den ganzen Schlamassal verantwortlich halte (der wurde am Dienstag aus mir und meinen zwei Kollegen unbekannten Gründen neugestartet und seit Mittwoch Morgen haben wir DRS-Probleme).

    Problem ist eben, dass er zwar DRS synchronisieren möchte, das aber nicht macht, weil der CAS im Maintenance Mode ist.

    Friday, August 10, 2018 8:44 AM
  • Mein rcmctrl.log sagt, ich möchte DRS machen, aber leider ist der CAS im Maintenance Mode, daher mach ich's nicht. Das muss doch möglich sein, dass irgendwie zurückzusetzen, oder?


    Das steht doch in dem von mir verlinkten Artikel. Aber wie gesagt: unsupportet.

    Torsten Meringer | http://www.mssccmfaq.de

    Friday, August 10, 2018 9:43 AM
    Answerer
  • Stimmt, aber ich hatte inständig gehofft, dass ich dafür nen Knopf in der SCCM console habe. Habe ich wohl nicht übersehen, gibt es einfach nicht. 

    Ok, ich bin etwas weitergekommen, mein ich.

    In meinem rcm.box-Ordner auf dem CAS liegt content. Leider kann ich die GUID nicht zuweisen. Ich mache auf dem CAS folgende SQL-Abfrage:

    select * from RCM_DrsInitializationTracking Where RequestTrackingGUID = 'GUID der Daten in rcm.box'


    .. und kriege kein Ergebnis. Dazu folgende Abfrage:

    select * from RCM_DrsInitializationTracking Where ReplicationGroup = 'General_Site_Data'

    .. was mir eine schöne Übersicht liefert. Auffällig ist, dass dort alle Gruppen entweder InitializationStatus 6 oder 7 haben. Nur eine General_Site_Data-ReplicationGroup fällt hier aus der Reihe: aus dem Standort, wo ich die Fehlerursache vermute. Dort ist eine Gruppe mit Status 5 angegeben und die InitializationPercent ist mit 59 angegeben und der TryCount mit 7. Leider stimmt die RequestTrackingGUID nicht mit der GUID der Daten unter rcm.box überein.

    Ich habe auch schon probiert ein Datei mit dem Namen "General_Site_Data-PRserver.pub" unter rcm.box anzulegen. Allerdings wird die scheinbar geflissentlich ignoriert.

    Meine nächste Idee wäre, den Status von genannter ReplicationGroup auf 7 zu setzen und die Daumen zu drücken. Vielleicht ignoriert er die angefangene ReplicationGroup und widmet sich dann den anderen? Das wäre dann ja ungefähr das, was dein link auch vorschlägt, nur betrifft es bei mir eben scheinbar nicht die ReplicationGroup 'Configuration Data' sondern 'General_Site_Data'.

    Hintergrundinfos: in besagtem Standort gab es letzte Woche Donnerstag einen Stromausfall, d.h. die Server wurden aus der Reihe heruntergefahren.

    Friday, August 10, 2018 11:44 AM
  • Dafür würde auch der zweite SQL-Befehl aus dem Treffer hier sprechen:

    SCCM 2012 : Parent Site State : Replication maintenance in Site Replication Status.


    Friday, August 10, 2018 12:10 PM
  • Gesagt, getan. InitializationStatus auf 7 gesetzt für besagte General_Site_Data ReplicationGroup. SMS_EXECUTIVE gestoppt und neugestartet. Ein bisschen was geben die Logfiles her, aber muss die Infos erstmal ordnen. In rcm.box gibt es jetzt einen neuen Ordner mit einer neuen GUID. Es gibt jetzt auch eine neue ReplicationGroup - aber die hat jetzt schon wieder Status 5 und steht bei InitializationPercent 59. x) Ich verlagere mich mal auf den Primary und schaue mir die Datenbank dort an.
    Friday, August 10, 2018 12:57 PM
  • So, kurze Rückmeldung: geht wieder. Was hat's gebracht? Ich kann's nicht genau sagen. Freitag bis 18 Uhr hier gesessen und SQL abgefragt und aktualisiert.Falls jemand auf ein ähnliches Problem trifft, hier mal ein paar links, mit denen ich gewurstelt habe.

    • auf jeden Fall den von Torsten, der ist gut. 
    • https://social.technet.microsoft.com/Forums/en-US/66bb09a0-7698-431a-9df0-44f326412046/sccm-2012-parent-site-state-replication-maintenance-in-site-replication-status?forum=configmanagergeneral
    • https://www.anoopcnair.com/sccm-sql-based-replication-guide/
    • https://blogs.msdn.microsoft.com/minfangl/2012/05/16/tips-for-troubleshooting-sc-2012-configuration-manager-data-replication-service-drs/
    • .. und die beiden oben genannten

    Folgende Kommandos hab ich benutzt:

    /*
    select * from RCM_DrsInitializationTracking Where ReplicationGroup = 'Configuration Data' and SiteRequesting = 'Prim1'
    
    Update RCM_DRSInitializationTracking Set InitializationStatus =6 Where RequestTrackingGUID = 'GUID von fehlerhafter ReplicationGroup'
    
    select * from RCM_DrsInitializationTracking Where ReplicationGroup = 'General_Site_Data' and InitializationStatus = 5 SiteFulFilling = 'Prim1'
    
    select * from  RCM_DrsInitializationTracking Where ReplicationGroup = 'General_Site_Data' and SiteFulfilling = 'Prim1'
    
    spDRSSendSubscriptionInvalid 'Prim1', 'CAS', 'General Site Data'
    
    select * from RCM_ReplicationLinkStatus where SnapshotApplied <>1
    
    select * from RCM_DrsInitializationTracking where ReplicationGroup in
    (select ReplicationGroup from vReplicationData where 'ID von ReplicationGroup'
    in
    (select ReplicationID from RCM_ReplicationLinkStatus
    where SnapshotApplied <>1))
    order by
    ReplicationGroup, CreatedTime
    
    update RCM_DrsInitializationTracking set
    InitializationStatus = 7 where ReplicationGroup in
    (select ReplicationGroup from vReplicationData where
    ReplicationPattern = 'Prim1') and SiteRequesting = 'CAS' and SiteFulFilling = 'Prim1'
    */

    Danke für die Denkanstöße, Torsten. Und viel Geduld und Ausdauer für alle anderen, die keinen Plan von MSSQL haben und deren SCCM auf'n Fehler läuft datenbankseitig. Grüße


    Monday, August 13, 2018 8:19 AM
  • Danke für die Denkanstöße, Torsten.


    Viel mehr geht bei so einem Problem leider auch nicht. Du hast gesehen: da greifen sehr viele Dinge ineinander, die man alle "verknüpfen" muss bzw einer heißen Spur hinterherjagen.

    Torsten Meringer | http://www.mssccmfaq.de

    Monday, August 13, 2018 10:55 AM
    Answerer