Dela via

Felsöka replikering av gemensamma mappar för Exchange Server

  • Artikel
  • Gäller för:
    Exchange Server 2010 Enterprise, Exchange Server 2010 Standard, Exchange Server 2010 Service Pack 3, Exchange Server 2007, Exchange Server 2003 Service Pack 2

Ursprungligt KB-nummer: 10042

Sammanfattning

Vi börjar med att be dig att aktivera diagnostikloggning och meddelandespårning som en förutsättning. Sedan tar vi dig igenom en serie steg för att lösa problem med replikering av gemensamma mappar.

Beräknad tidsåtgång:
45-60 minuter.

Om du vill felsöka replikering av gemensamma mappar för Exchange Server måste du först aktivera diagnostikloggning och meddelandespårning.

Vad vill du göra?

Aktivera diagnostikloggning

Du måste aktivera diagnostikloggning på alla servrar som du kommer att arbeta med. Stegen för olika Exchange-versioner kan vara olika och välj din Exchange-version:

För Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Shell.

  2. Kör följande cmdlet för att kontrollera aktuella loggningsnivåer:

    Get-EventLogLevel | ? { $_.EventLevel -ne "Low" -AND $_.EventLevel -ne "Lowest" }

  3. Aktivera loggning genom att köra följande cmdletar på alla gemensamma mappservrar som du arbetar med:

    Set-EventLogLevel -Identity "MSExchangeIS\9001 Public\Replication DS Updates" -Level Expert
Set-EventLogLevel -Identity "MSExchangeIS\9001 Public\Replication Incoming Messages" -Level Expert
Set-EventLogLevel -Identity "MSExchangeIS\9001 Public\Replication Outgoing Messages" -Level Expert
Set-EventLogLevel -Identity "MSExchangeIS\9001 Public\Replication NDRs" -Level Expert
Set-EventLogLevel -Identity "MSExchangeIS\9001 Public\Replication Backfill" -Level Expert
Set-EventLogLevel -Identity "MSExchangeIS\9001 Public\Replication General" -Level Expert
Set-EventLogLevel -Identity "MSExchangeIS\9001 Public\Replication Errors" -Level Medium

  4. Öka transportloggningen på målservern genom att köra följande cmdletar:

    Set-EventLogLevel -Identity "MSExchangeTransport\SmtpReceive" -Level 'Medium'
Set-EventLogLevel -Identity "MSExchangeTransport\SmtpSend" -Level 'Medium'

  5. Så här återställer du loggningsnivåer:

    1. Öppna Exchange Management Console.
    2. I konsolträdet går du till Serverkonfigurationspostlåda>.
    3. I fönstret Åtgärder väljer du Hantera egenskaper för diagnostikloggning.
    4. På sidan Hantera egenskaper för diagnostikloggning väljer du den Exchange-tjänst som du vill ändra loggningsnivån för.
    5. Välj den loggningsnivå som du vill använda och välj sedan Konfigurera. Om du vill återställa standardinställningarna väljer du Återställ alla tjänster till standardloggningsnivåer och väljer sedan Konfigurera.
    6. På sidan Slutförande bekräftar du att processen har slutförts. Aktiviteter visar statusen Slutförd eller Misslyckad. Om uppgiften misslyckades granskar du sammanfattningen för en förklaring och väljer sedan Tillbaka för att göra nödvändiga konfigurationsändringar.
    7. Välj Slutför för att slutföra guiden Hantera diagnostikloggningsnivå .

För Exchange Server 2003

  1. Starta Exchange System Manager och visa sedan egenskaperna för den server som du vill aktivera diagnostikloggning på.
  2. Välj fliken Diagnostikloggning och expandera sedan MSExchangeIS i listan Tjänster .
  3. Välj Gemensam mapp, tryck och håll ned Ctrl och välj sedan vart och ett av följande objekt för att markera dem alla:
    • Replikering av AD-Uppdateringar
    • Replikering av inkommande meddelanden
    • Utgående replikeringsmeddelanden
    • Rapporter om utebliven leverans
    • Återfyllnad av replikering
    • Allmän replikering
  4. Välj Max>använd.
  5. Välj Replikeringsfel>Medel>tillämpa>OK.
  6. Öka loggningen på målservern för MSExchangeTransport-tjänsten och ange SMTP-nivån till Medel:
    1. Expandera Servrar, högerklicka på Ditt servernamn och välj sedan Egenskaper.
    2. Välj fliken Diagnostikloggning och välj sedan MSExchangeTransport under Tjänster.
    3. Under Kategorier väljer du SMTP.
    4. Under Loggningsnivå väljer du Medel.

Vad vill du göra härnäst?

Aktivera meddelandespårning

Om du vill aktivera meddelandespårning på alla servrar kommer du att arbeta med. Stegen för olika Exchange-versioner kan vara olika och välj din Exchange-version:

För Exchange Server 2007 och Exchange Server 2010

  1. Kontrollera att meddelandespårning pågår genom att gå till Exchange Management Shell och köra följande cmdlet:

    Get-MailboxServer $env:computername | fl MessageTracking*

  2. Du bör se utdata som liknar följande:

    Skärmbild av cmdleten som körs för att verifiera att meddelandespårning är aktiverat.

  3. Kontrollera att båda MessageTrackingLogEnabled och MessageTrackingLogSubjectLoggingEnabled är inställda på Sant.

  4. Se till att du antecknar MessageTrackingLogPath för loggplatsen.

För Exchange Server 2003

  1. Starta Exchange System Manager och visa sedan egenskaperna för den server där du vill aktivera meddelandespårning. Meddelandespårning samlar in data som Till, Från och Datum skickat.
  2. På fliken Allmänt markerar du kryssrutan Aktivera meddelandespårning .
  3. Markera kryssrutan Aktivera ämnesloggning och visa .

Vad vill du göra?

Felsöka replikering av gemensamma mappar

Välj en mapp som innehåller data på en server men inte på en annan server och gör just den mappen till fokus för felsökningsarbetet. I följande steg kallas servern som innehåller data för källservern . den server som inte innehåller data kallas målservern .

Exchange Server 2007 och Exchange Server 2010

  1. I Exchange Management Console väljer du Hanteringskonsol för gemensamma mappar under Verktygslåda.
  2. Högerklicka på Gemensamma mappar och välj sedan Anslut till.
  3. Välj den server som du vill ansluta till.

Exchange Server 2003

  1. Öppna Exchange System Manager.
  2. Gå till hierarkiobjektet för den gemensamma mappen.
  3. Högerklicka på Gemensamma mappar och välj sedan Anslut till.
  4. Välj den server som du vill ansluta till.

Visas mappen som du letar efter nu i hierarkin på båda servrarna?

Replikera Always Interval; Händelse-ID för programlogg 3018

Replikera alltid intervall

Kontrollera att värdet Replikera alltid intervall är inställt på 15 eller färre minuter på källservern. Justera inställningen om det behövs. Välj din Exchange-version för att kontrollera stegen:

Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.

  2. Kör följande cmdletar och kontrollera att ReplicationPeriod, ReplicationScheduleoch ReplicationMessageSize har angetts:

    Get-PublicFolderDatabase -Server $env:computername| fl Replication*

    Skärmbild av körning av Get-PublicFolderDatabase för att verifiera att parametrar har angetts.

  3. Kontrollera att alla offentliga f-databaser har samma ReplicationMessageSize.

Kontrollera sedan att mappen i fråga är konfigurerad för att använda butiksschemat. Gör så här:

  1. Starta Exchange Management Console.

  2. Kör följande cmdlet och verifiera Replicas och UseDatabaseReplicationSchedule är inställda:

    Get-PublicFolder | fl *Replica*

    Skärmbild av körning av Get-PublicFolder för att verifiera att parametrar har angetts.

  3. Om UseDatabaseReplicationSchedule är inställt på Falskt kontrollerar du att ReplicationSchedule har angetts.

Exchange Server 2003
  1. Starta Exchange System Manager.
  2. Expandera containern Administrativa grupper och välj sedan den administrativa grupp som innehåller den gemensamma mappservern.
  3. Expandera containern Servrar , välj databasen för den gemensamma mappen och välj sedan Egenskaper.
  4. På fliken Replikering (princip) noterar du värdet i rutan Replikeringsintervall för alltid (minuter).
  5. Om värdet inte är 15 skriver du 15 i rutan Replikeringsintervall för alltid (minuter).
  6. Välj Använd och välj sedan OK.

Kontrollera sedan att mappen du felsöker är konfigurerad för att använda butiksschemat:

  1. Expandera Gemensamma mappar och högerklicka sedan på mappen som du felsöker.
  2. Välj Egenskaper.
  3. På fliken Replikering väljer du Använd offentligt lagringsschema i listan Replikeringsintervall för gemensamma mappar .

Händelse-ID för programlogg 3018

Skapa en ny mapp i hierarkin på källservern och ge sedan den nya mappen ett unikt namn som du kan komma ihåg.

Vi använder Test 1 som namn på vår mapp i det här exemplet. Titta på programloggen på källservern för händelse-ID 3018, som anger meddelandetypen 0x2 och innehåller namnet på den mapp som du skapade. Du kan behöva vänta i upp till 15 minuter innan händelsen loggas.

Händelsetyp Information
Händelsekälla: OFFENTLIG MSExchangeIS-lagringsplats
Händelsekategori: Utgående replikeringsmeddelanden
Händelse-ID: 3018
Meddelande: Ett utgående replikeringsmeddelande har utfärdats.
Typ: 0x2
Meddelande-ID: <MessageID@Server.Domain.com>
Databasen "Storage Group\Public Folder"
CN min: 1-100, CN max: 1-200
RFI:er:
1) FID: 1-1234, PFID: 1-1, offset: 28
IPM_SUBTREE\Test 1

Ser du händelse-ID 3018?

Felsöka källservern

Källservern genererar inte utgående hierarkireplikeringsmeddelanden för nya ändringar. Vi fokuserar först på felsökning på källservern.

Händelse-ID 3079 när databasen för den gemensamma mappen är monterad

När databasen för den gemensamma mappen är monterad registreras händelse-ID 3079 i programloggen på källservern. Granska programloggen på källservern.

Händelsetyp Information
Händelsekälla OFFENTLIG MSExchangeIS-lagringsplats
Händelsekategori Replikeringsfel
Händelse-ID 3079
Meddelande Oväntat replikeringstrådsfel i databasens "<namn>".
1) FID: 1-1234, PFID: 1-1, offset: 28
IPM_SUBTREE\Test 1

Ser du händelse-ID 3079?

  • Om ja, se EcReplStartup.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Om du kontaktar supporten om det här problemet meddelar du dem att källservern inte genererar utgående hierarkireplikeringsmeddelanden och att det inte finns någon 3079-händelse när databasen monteras.

EcReplStartup

Granska händelse-ID 3079 för texten: EcReplStartup.

Innehåller händelse-ID 3079 EcReplStartup?

  • Om ja, se Händelse-ID för programlogg 9528.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Om du kontaktar supporten för det här problemet kan du berätta för dem att källservern inte genererar utgående hierarkireplikeringsmeddelanden. Det finns en 3079-händelse när databasen monteras, men händelsen innehåller inte EcReplStartup.

Händelse-ID 9528 för programlogg

Om händelse-ID 3079 innehåller EcReplStartup indikerar detta att replikeringstråden håller på att dö vid start. Kontrollera sedan om händelse-ID 9528 registreras i programloggen för källservern.

Händelsetyp Information
Händelsekälla MSExchangeIS
Händelsekategori Allmän
Händelse-ID 9528
Meddelande SID S-1-5-32-544 hittades på 2 användare i DS, så arkivet kan inte mappa detta SID till en unik användare.
De berörda användarna är:
/DC=com/DC=domain/DC=na/OU=Migrated/CN=John, Woods
/DC=com/DC=domain/DC=ad/DC=corp/OU=EUC/OU=AMER/OU=Jersey City/OU=Harborside/OU=Users/CN=John, Woods

Ser du händelse-ID 9528?

  • Om ja, se Ta bort dubblettkonton.
  • Om nej, tyvärr, Vi kan inte lösa oidentifierade problem med den här guiden. Om du vill ha mer hjälp med att lösa det här problemet kontaktar du Microsoft Exchange Server support och berättar att när databasen monteras loggas en 3079-händelse.

Spåra meddelandet i meddelandespårning; Levererades meddelandet till målservern?

Spåra meddelandet i meddelandespårning

På källservern använder du meddelande-ID:t från beskrivningen av händelse-ID 3018 för att spåra meddelandet i meddelandespårningen.

Händelsetyp Information
Händelsekälla OFFENTLIG MSExchangeIS-lagringsplats
Händelsekategori Utgående replikeringsmeddelande
Händelse-ID 3018
Meddelande Ett utgående replikeringsmeddelande har utfärdats.
Typ: 0x2
Meddelande-ID: <MessageID@Server.Domain.com>
Databasen "Storage Group\Public Folder"

Levererades meddelandet till målservern?

I beskrivningen av Händelse-ID 3018 noterar du meddelande-ID:t och använder sedan meddelandespårning för att avgöra om meddelandet levererades till målservern. Följande utdrag för meddelandespårning innehåller till exempel följande text:

"Meddelande som överförs till via SMTP".

Meddelandehistorik

SMTP Store Driver: Message Submitted From Store
SMTP: Message Submitted to Advanced Queuing
SMTP: Started Message Submission to Advanced Queue
SMTP: Message Submitted to Categorizer
SMTP: Message Categorized and Queued For Routing
SMTP: Message Routed and Queued For Remote Delivery
SMTP: Started Outbound Transfer of Message Message transferred to through SMTP

Indikerar meddelandespårning att meddelandet levererades till målservern?

Transportproblem; Visas meddelandet i meddelandespårning?

Transportproblem

Meddelandet levererades inte till målservern, vilket indikerar att ett transportproblem orsakar problemet. Därefter ska vi felsöka transportprocessen.

Visas meddelandet i meddelandespårningen?

Gå till källservern och leta upp det utgående meddelande-ID:t. Gå sedan till målservern och kör meddelandespårning för att se om meddelandet har tagits emot. Välj din Exchange-version för att kontrollera stegen för att köra meddelandespårning.

För Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.

  2. Kör följande cmdlet:

    Get-MessageTrackingLog -MessageId
För Exchange Server 2003
  1. Starta Exchange System Manager.
  2. I konsolträdet expanderar du Verktyg och väljer sedan Meddelandespårningscenter.
  3. I rutan Server skriver du namnet på den server som kör Exchange Server 2003.

Om du vill bläddra i en lista över tillgängliga servrar väljer du Server, väljer en server och sedan Lägg till. Du kan söka efter ett meddelande som har skickats från eller levererats till en viss server. Du behöver bara ange servernamnet.

Fick den meddelandet?

Händelse-ID 3028 på målservern

På målservern undersöker du programloggen för händelse-ID 3028, som innehåller samma meddelande-ID som du antecknade i beskrivningen av händelse-ID 3018.

Händelsetyp Information
Händelsekälla OFFENTLIG MSExchangeIS-lagringsplats
Händelsekategori Replikering av inkommande meddelanden
Händelse-ID 3028
Meddelande Ett inkommande replikeringsmeddelande har utfärdats.
Typ: 0x2
Meddelande-ID: <MessageID@Server.Domain.com>
Databasen "Storage Group\Public Folder"
CN min: 5-100 CN max: 5-200
RFI:er: 1
1) FID: 5-1234, PFID: 1-1, Offset: 28
IPM_SUBTREE\Test 1

Visar målserverns programlogg händelse-ID 3028 och innehåller den här händelsen samma meddelande-ID som händelse-ID 3018?

Händelse-ID 7004 och händelse-ID 7010 på målservern

På målservern undersöker du programloggen i Loggboken efter händelser som liknar följande händelser.

Händelsetyp Fel
Händelsekälla MSExchangeTransport
Händelsekategori SMTP-protokoll
Händelse-ID 7004
Datum Datum
Tid Tid
Användare Inte tillgängligt
Dator Computer_Name
Beskrivning Det här är en SMTP-protokollfellogg för virtuell server-ID 1, anslutning nr 29. Fjärrvärden E2k3server1.contoso.comsvarade på SMTP-kommandot "xexch50" med "504 Need to authenticate first ". Det fullständiga kommandot som skickades var "XEXCH50 2336 3 ". Detta kommer förmodligen att orsaka att anslutningen misslyckas.
Händelsetyp Fel
Händelsekälla MSExchangeTransport
Händelsekategori SMTP-protokoll
Händelse-ID 7010
Datum Datum
Tid Tid
Användare Inte tillgängligt
Dator Computer_Name
Beskrivning: Det här är en SMTP-protokolllogg för virtuell server-ID 1, anslutning nr 30. Klienten på "6.5.2.4" skickade ett "xexch50"-kommando, och SMTP-servern svarade med "504 Need to authenticate first ". Det fullständiga kommandot som skickades var "xexch50 1092 2". Detta kommer förmodligen att orsaka att anslutningen misslyckas. Dessa händelser indikerar att XEXCH50 protokollmottagare utlöstes, men utbytet av blobarna misslyckades mellan de servrar som anges i händelserna.

Ser du händelse-ID 7004 och händelse-ID 7010 på målservern?

Lösa problem med kommandot XEXCH50

Problemet kan bero på ett XEXCH50 kommandoproblem.

Så här löser du XEXCH50 kommandoproblem

  1. Kontrollera att Integrerad Windows-autentisering är aktiverat på de virtuella SMTP-servrarna på de datorer som kör Exchange Server i din organisation. Om integrerad Windows-autentisering inte är aktiverat:

    1. I Exchange System Manager expanderar du Administrativa grupper, expanderar Servrar, expanderar Exchange Server Namn, expanderar Protokoll och expanderar sedan SMTP.
    2. Högerklicka på den virtuella SMTP-servern.
    3. Välj Egenskaper, välj fliken Åtkomst och välj sedan Autentisering. Kontrollera att kryssrutan Integrerad Windows-autentisering är markerad.

  2. Om integrerad Windows-autentisering är aktiverat, men händelserna kvarstår, kan den sändande servern i 7004-händelsen eller i 7010-händelsen sakna eller nekas sendas-rätten på den mottagande servern. Om den sändande servern och den mottagande servern upplever dessa händelser kan servrarna sakna SendAs-rättigheter för varandra. SendAs-rättigheten anges inte uttryckligen. SendAs-rättigheten ärvs vanligtvis genom medlemskap i gruppen Exchange Domain Servers (EDS). Om EDS inte har den här åtkomstkontrollposten (ACE) kan den berörda servern vara kapslad i en annan grupp som har DENY ACE, eller så kan EDS vara kapslad i vissa andra grupper som har DENY ACE. För att kunna köras måste kommandot XEXCH50 ha SendAs rätt för servrar i Exchange-organisationen.

  3. Avgör om du använder TLS (Transport Layer Security) och en säkerhetskanal mellan servrar i Exchange-organisationen. I det här scenariot inträffar STARTTLS-transporthändelsen före AUTH-kommandot. Kommandot XEXCH50 misslyckas senare i sessionen eftersom kommandot AUTH saknas.

  4. Om autentisering med Exchange Protocol Security (EXPS) inte fungerar korrekt mellan servrar fungerar inte XEXCH50-kommandot . Händelser 1704 och 1706 indikerar EXPS-autentiseringsfel i programloggen.

    Händelsetyp Varning
    Händelsekälla MSExchangeTransport-händelse
    Händelsekategori MTP-protokoll
    Händelse-ID 1706
    Beskrivning: EXPS kan tillfälligt inte tillhandahålla protokollsäkerhet med ".. com". "CSessionContext::OnEXPSInNegotiate" med namnet "HrServerNegotiateAuth" som misslyckades med felkoden 0x8009030c ( i:\transmt\src\smtpsink\exps\expslib\context.cpp@1462 ). Data: 0000: 0c 03 09 80 ...?

    Obs!

    Beskrivningen i Händelse-ID 1706 innehåller felkod 0x8009030c.
    Felkod 0x8009030c är värdet SEC_E_LOGON_DENIED Hresult. Den här koden anger att kontot inte kunde loggas in.
    Dessa problem kan vara svåra att felsöka eftersom Microsoft Windows-autentiseringsuppgifterna för EXPS krävs för att klara det här AUTH-kommandot . Du kan använda olika verktyg för att felsöka kombinationen av händelse-ID 7004 och 7010; detta inkluderar VERKTYGET NLTEST och NETDOM-verktyget. Felsökningsstegen kan omfatta återställning av lösenord för datorkonton.
    Om du har en kombination av händelse-ID 7004 och 7010 i programloggen enligt beskrivningen ovan, och du inte kan identifiera orsaken till problemet med hjälp av EXPS-autentisering, kontaktar du Microsoft Support Services.
    Om du inte har kombinationen av Händelse-ID 7004 och Händelse-ID 7010 i programloggen går du till steg 5.

  5. Kontrollera om det finns en brandvägg eller en antivirusvägg mellan servrar i Exchange-organisationen. Om en brandvägg körs mellan servrar i organisationen inaktiverar du tillfälligt brandväggen för att avgöra om den orsakar problemet.

Löste inaktivering av brandväggen problemet?

Kör isinteg -fix -test ReplState på målservern; Tombstone på grund av en borttagning

Kör isinteg – åtgärda – testa ReplState på målservern

Välj din Exchange-version för att verifiera och justera inställningen ReplState med följande steg:

För Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.

  2. Använd cmdleten New-PublicFolderDatabaseRepairRequest för att identifiera och åtgärda replikeringsproblem i databasen för den gemensamma mappen. Gemensamma mappar i databasen för gemensamma mappar kan fortfarande nås medan begäran körs. Den gemensamma mapp som repareras är dock inte tillgänglig. När du har påbörjat reparationsbegäran kan den inte stoppas om du inte demonterar databasen.

  3. Kör följande cmdlet:

    New-PublicFolderDatabaseRepairRequest -Database -CorruptionType ReplState
För Exchange Server 2003

  1. Installera snabbkorrigeringen KB925253 på målservern.

  2. När snabbkorrigeringen har installerats demonterar du databasen för den gemensamma mappen på servern och kör sedan följande kommando i en kommandotolk:

    cd C:\Program Files\Exchsrvr\bin
Isinteg -s -fix -test ReplState

Kör sedan ett test för att avgöra om problemet är löst.

Tombstone på grund av en borttagning

Detta anger att mappen är en gravsten på grund av en tidigare borttagning som inte replikerade. Gå tillbaka till källservern och kopiera mappen för att skapa en ny mapp med samma innehåll och börja sedan om.

Synlighet för ny mapp

Visas den nya mappen i hierarkin på målservern?

Felsöka ifyllning av hierarki

Nu har vi kontrollerat att ändringar i hierarkin replikeras korrekt. Nu kan vi felsöka återfyllnad av hierarki. Det gör du genom att köra Synkronisera hierarki på målservern. Synkronisera hierarki gör att händelse-ID 3017 inträffar. Händelse-ID 3017 visar att en begäran om hierarkistatus (typ 0x20) skickades till källservern.

För Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.
  2. Kör cmdleten Update-PublicFolderHierarchy -Server .
  3. När du har kört Synkronisera hierarki på målservern undersöker du programloggen på källservern för händelsen 3027 och för begäran om inkommande status.

För Exchange Server 2003

  1. Starta Exchange System Manager.
  2. Om du vill köra Synkronisera hierarki expanderar du Mappar, högerklickar på objektcontainern Gemensamma mappar och väljer sedan Synkronisera hierarki.
  3. När du har kört Synkronisera hierarki på målservern undersöker du programloggen på källservern för händelse 3027 och för begäran om inkommande status.

Finns händelse 3027 i programloggen på källservern?

Hämta meddelande-ID:t och spåra meddelandet

Leta upp händelse-ID 3017 på källservern och notera meddelande-ID:t. Använd meddelandespårning för att spåra meddelande-ID:t för att avgöra om meddelandet levererades till källservern.

Står det att meddelandet levererades till källservern?

Fastställa om arkivet för gemensamma mappar på källservern har en e-postadress

Om du vill ta reda på om det gemensamma mapparkivet på källservern har en tilldelad proxyadress undersöker du värdet för proxyAddresses attributet i Active Directory-katalogtjänsten.

Så här undersöker du värdet

Varning

Om du använder Active Directory Service Interface (ADSI) Redigera snapin-modulen, LDP-verktyget eller någon annan LDAP version 3-klient, och du felaktigt ändrar attributen för Active Directory-objekt, kan du orsaka allvarliga problem. Dessa problem kan kräva att du installerar om Microsoft Windows 2000 Server, Windows Server 2003, Microsoft Exchange Server 2000, Microsoft Exchange Server 2003 eller både Windows Server och Exchange Server. Microsoft kan inte garantera att problem som uppstår om du felaktigt ändrar Active Directory-objektattribut kan lösas. Ändra dessa attribut på egen risk.

Obs!

Beroende på din version av Microsoft Windows kan följande steg skilja sig åt på datorn. I så fall hittar du anvisningar i produktdokumentationen.

  1. Starta ADSI-redigeringsverktyget genom att välja Starta>körning, skriva adsiedit.msc i rutan Öppna och sedan välja OK.

    Obs!

    ADSI-redigering ingår i Supportverktyg för Microsoft Windows 2000 Server och Windows Server 2003 Support Tools. Om du vill installera Windows 2000 Support Tools dubbelklickar du på Setup.exe i mappen Support\Tools på Windows 2000 CD. Om du vill installera Windows Server 2003 Support Tools dubbelklickar du på Suptools.msi i mappen Support\Tools på Windows Server 2003 CD.

  2. Anslut till en domänkontrollant om du inte redan är ansluten.

    Obs!

    I det här steget contoso.com är en platshållare för ditt domännamn. Andra ord i kursiv stil är platshållare för de angivna namnen. Expandera Konfigurationscontainern [computername.contoso.com], expandera CN=Configuration, DC=contoso, DC=com, expandera CN=Services, expandera CN=Microsoft Exchange, expandera CN=OrganizationName, expandera CN=Administrative Groups, expandera CN=AdministrativeGroupName, expandera CN=Servers, expandera CN=ExchangeServerName, expandera CN=InformationStore och välj sedan CN=First Storage Group.

  3. Högerklicka på CN=Public Folder Store (EXCHANGESERVERNAME) i den högra rutan och välj sedan Egenskaper.

  4. I listan Välj vilka egenskaper som ska visas väljer du båda.

  5. I listan Välj en egenskap att visa väljer du proxyAddresses.

  6. I rutan Värde avgör du om en e-postadress har tilldelats. Vanligtvis har arkivet för gemensamma mappar en SMTP-adressstämpel (Simple Mail Transfer Protocol) som liknar: SMTP:ExchangeServerName-IS@contoso.com.

  7. I listan Välj en egenskap att visa väljer du e-post.

  8. I rutan Värde kontrollerar du att SMTP-adressen är samma som SMTP-adressen som visas i steg 7.

Har det offentliga källarkivet en e-postadress?

  • Om ja, tyvärr, kan vi inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.
  • Om nej, se Händelse-ID för programlogg 3018.

Händelse-ID 3017 på källservern

I programloggen på källservern, omedelbart före händelse-ID 3027, letar du upp händelse-ID 3017 för samma mapp, som har typen 0x10.

Ser du händelse-ID 3017 och skriver 0x10 för samma mapp?

Händelse-ID 3027 på målservern

Händelse-ID 3027 är statussvaret på källservern. Leta upp händelse-ID 3027 i programloggen på målservern för att undersöka statussvaret.

Ser du händelse-ID 3027 på målservern?

  • Om ja, se Felsöka återfyllnad.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.

Felsöka återfyllnad

Nu vet vi att målservern är medveten om att data saknas. Nu fokuserar vi på att felsöka själva hierarkins återfyllnad.

På målservern kör du Synkronisera hierarki igen och kontrollerar sedan programloggen på målservern för Händelse-ID 3014, som har typen 0x8. Händelse-ID 3014 är en utgående begäran om återfyllnad för hierarkin.

Ser du händelse-ID 3014 och skriver 0x8 på målservern?

  • Om ja, se Händelse-ID 3024 på källservern.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.

Händelse-ID 3024 på källservern

Händelse-ID 3024 är begäran om återfyllnad av inkommande hierarki.

Ser du händelse-ID 3024 på källservern?

Händelse-ID 3019 på källservern

Händelse-ID 3019, som har typen 0x80000002, är svaret på utgående hierarkins återfyllnad på källservern. Granska programloggen på källservern för händelse-ID 3019.

Finns händelse-ID 3019 i programloggen på källservern?

  • Om ja, se Händelse-ID 3029.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.

Händelse-ID 3029

Händelse-ID 3029 är det inkommande hierarkins återfyllnadssvar på målservern.

Ser du händelse-ID 3029 i programloggen på målservern?

Leta efter mappen i hierarkin

Leta efter mappen i hierarkin på målservern.

Ser du mappen i hierarkin på målservern nu?

  • Om ja, grattis! Problemet med replikering av gemensamma mappar för Exchange Server 2003 har lösts.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.

Spåra meddelande-ID från händelse-ID 3014

På målservern undersöker du händelse-ID 3014 för att hämta meddelande-ID:t. Använd meddelandespårning för att spåra meddelande-ID:t.

Indikerar meddelandespårning att meddelandet levererades till källservern?

Spåra meddelande-ID:t från händelse-ID 3019

Leta upp händelse-ID 3019 på källservern och notera meddelande-ID:t i händelsen. Använd meddelandespårning för att spåra meddelande-ID:t.

Indikerar meddelandespårning att meddelandet levererades till målservern?

Fokusera på innehåll; Replikera Always Interval och Schedule; Skapa ett nytt objekt på källservern

Fokusera på innehåll

Eftersom mappen visas i hierarkin på båda servrarna är detta förmodligen inte ett problem med hierarkireplikering. Därför fokuserar vi på att felsöka innehåll.

Replikera Always Interval och Schema

Kontrollera att värdet Replikera alltid intervall är inställt på 15 minuter eller färre på källservern.

Verifiera och justera inställningen på Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.

  2. Kör följande cmdlet och verifiera ReplicationPeriod, ReplicationScheduleoch ReplicationMessageSize har angetts:

    Get-PublicFolderDatabase -Server $env:computername| fl Replication*

    Skärmbild av hur du använder Get-PublicFolderDatabase för att verifiera att parametrar har angetts.

  3. Kontrollera att alla gemensamma mappdatabaser har samma ReplicationMessageSize.

Kontrollera sedan att mappen i fråga är konfigurerad för att använda butiksschemat. Gör så här:

  1. Starta Exchange Management Console.

  2. Kör följande cmdlet och verifiera Replicas och UseDatabaseReplicationSchedule är inställda:

    Get-PublicFolder | fl *Replica*

    Skärmbild av hur du använder Get-PublicFolder för att verifiera att parametrar har angetts.

  3. Om UseDatabaseReplicationSchedule är inställt på Falskt kontrollerar du att är ReplicationSchedule inställt.

Verifiera och justera inställningen på Exchange Server 2003
  1. Starta Exchange System Manager.
  2. Expandera containern Administrativa grupper och välj sedan den administrativa grupp som innehåller den gemensamma mappservern.
  3. Expandera containern Servrar, expandera källservern, välj databasen för den gemensamma mappen och välj sedan Egenskaper.
  4. På fliken Replikering (princip) skriver du 15 i rutan Replikeringsintervall för alltid (minuter).
  5. Välj Använd och välj sedan OK.

Kontrollera sedan att mappen som du arbetar med är konfigurerad för att använda butiksschemat. Gör så här:

  1. Expandera Gemensamma mappar och högerklicka sedan på mappen som du arbetar med.
  2. Välj Egenskaper.
  3. På fliken Replikering väljer du Använd offentligt lagringsschema i listan Replikeringsintervall för gemensamma mappar .

Skapa ett nytt objekt på källservern

Skapa ett nytt objekt i den gemensamma mappen på källservern och watch sedan programloggen för händelse-ID 3020.

Ser du händelse-ID 3020 och innehåller det namnet på mappen som du testar och namnet på det objekt som vi skapade?

Händelse-ID 3030

Granska programloggen för händelse-ID 3030 på målservern.

Innehåller målserverns programlogg händelse-ID 3030 för samma mapp och objekt?

Källservern genererar inte utgående innehållsmeddelanden för den mappen. Händelse-ID 3079 när databasen för den gemensamma mappen är monterad

Källservern genererar inte utgående innehållsmeddelanden för den mappen

Källservern genererar inte utgående innehållsmeddelanden för den mappen. Vi fokuserar vår felsökning på källservern.

Händelse-ID 3079 när databasen för den gemensamma mappen är monterad

Granska programloggen för händelse-ID 3079 på källservern. Händelse-ID 3079 inträffar när databasen är monterad och bör innehålla texten: EcReplStartup. Händelse-ID 3079 bör till exempel likna följande tabell.

Händelsetyp Information
Händelsekälla
OFFENTLIG MSExchangeIS-lagringsplats
Händelsekategori Replikeringsfel
Händelse-ID 3079
Meddelande Oväntat replikeringstrådsfel 0x3f0.
EcGetReplMsg
EcReplStartup
FReplAgent

Ser du händelse-ID 3079 och innehåller det EcReplStartup när databasen är monterad?

Kör isinteg -fix -test ReplState; Händelse-ID 3020

Kör isinteg – åtgärda – testa ReplState på målservern

Välj din Exchange-version för att verifiera och justera inställningen ReplState med följande steg:

För Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.

  2. Använd cmdleten New-PublicFolderDatabaseRepairRequest för att identifiera och åtgärda replikeringsproblem i databasen för den gemensamma mappen. Gemensamma mappar i databasen för gemensamma mappar kan fortfarande nås medan begäran körs. Den gemensamma mapp som repareras är dock inte tillgänglig. När du har påbörjat reparationsbegäran kan den inte stoppas om du inte demonterar databasen.

  3. Kör följande cmdlet:

    New-PublicFolderDatabaseRepairRequest -Database -CorruptionType ReplState
För Exchange Server 2003

  1. Installera snabbkorrigeringen KB925253 som släpptes den 24 januari 2013 på målservern.

  2. När snabbkorrigeringen har installerats demonterar du databasen för den gemensamma mappen på servern och kör sedan följande kommando i en kommandotolk:

    cd C:\Program Files\Exchsrvr\bin
Isinteg -s -fix -test ReplState

Händelse-ID 3020

Skapa ett nytt objekt i den gemensamma mappen på källservern och granska sedan programloggen för händelse-ID 3020.

Ser du händelse-ID 3020 och innehåller det namnet på mappen som du testar och namnet på det objekt som du skapade?

  • Om ja, se Händelse-ID 3030.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Om du kontaktar supporten för det här problemet kan du berätta för dem att källservern inte genererar utgående hierarkireplikeringsmeddelanden. Det finns en 3079-händelse när databasen monteras, men händelsen innehåller inte EcReplStartup.

Kontrollera att objektet finns i källmappen på målservern

Leta efter objektet som du skapade på källservern på målservern och kontrollera att det finns i målmappen.

Ser du objektet i mappen på målservern?

Felsöka återfyllnad av innehåll

Vi har kontrollerat att ändringar i innehållet replikeras. Nu ska vi felsöka återfyllnad av innehåll.

Det gör du genom att köra Synkronisera innehåll på målservern. Detta bör göra att målservern ber källservern om saknade data.

Så här kör du Synkronisera innehåll i Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.

  2. Kör följande kommando:

    Update-PublicFolder -Server <DestinationServer>

  3. När du har kört Synkronisera hierarki på målservern undersöker du programloggen på källservern för händelse 3027 och för begäran om inkommande status.

Så här kör du Synkronisera innehåll i Exchange Server 2003

  1. Expandera Gemensamma mappar och välj sedan målmappen.
  2. I den högra rutan väljer du fliken Status .
  3. Högerklicka på målservern och välj sedan Synkronisera innehåll.

När du har kört Synkronisera innehåll på målservern granskar du programloggen för händelse-ID 3017 för begäran om utgående status.

Är händelse-ID 3017 i programloggen på målservern

Kör isinteg -fix -test ReplState (om händelse-ID 3017 inte loggas)

Välj din Exchange-version för att verifiera och justera inställningen ReplState med följande steg:

För Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.

  2. Använd cmdleten New-PublicFolderDatabaseRepairRequest för att identifiera och åtgärda replikeringsproblem i databasen för den gemensamma mappen. Gemensamma mappar i databasen för gemensamma mappar kan fortfarande nås medan begäran körs, men du kan inte komma åt den gemensamma mapp som för närvarande repareras. När du har påbörjat reparationsbegäran kan den inte stoppas om du inte demonterar databasen.

  3. Kör följande cmdlet:

    New-PublicFolderDatabaseRepairRequest -Database -CorruptionType ReplState

För Exchange Server 2003

  1. Installera snabbkorrigeringen KB925253 på målservern.

  2. När snabbkorrigeringen har installerats demonterar du databasen för den gemensamma mappen på servern och kör sedan följande kommando i en kommandotolk:

     cd C:\Program Files\Exchsrvr\bin
Isinteg -s -fix -test ReplState

  3. När isinteg-processen är klar ändrar du repliklistan i den gemensamma mappen på källservern. Det gör du genom att antingen lägga till en replik till eller ta bort en replik från valfri server. Välj Använd, ändra den ändring som du precis har gjort och välj sedan Använd igen.

  4. Kör Synkronisera innehåll på målservern igen för samma mapp.

  5. Granska programloggen för händelse-ID 3017 för begäran om utgående status.

Finns händelse-ID 3017 i programloggen på målservern?

  • Om ja, se Händelse-ID 3027.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.

Händelse-ID 3027

På källservern undersöker du programloggen för händelse-ID 3027 som har typen 0x20.

Ser du händelse-ID 3027 och har den typ 0x20 på källservern?

Händelse-ID 3017 på källservern

I programloggen på källservern, omedelbart före händelse-ID 3027, letar du upp händelse-ID 3017 som har typen 0x10 för samma mapp.

Ser du händelse-ID 3017 och har den typen 0x10 för samma mapp?

Har servrarna olika åldersgränser?

Om källservern inte genererar något statussvar innebär det vanligtvis att källservern inte har några data som den andra servern inte heller har.

En situation där servrar kan synkroniseras utan att ha identiskt innehåll är om de har olika åldersgränser. Om målservern redan har upphört att gälla kommer objekten i fråga inte att fyllas i igen.

Se till att kontrollera och se till att servrarna inte har olika åldersgränser. Det finns flera typer av gränser:

Lagringskvoter

Använd standardvärden för databaskvoter

Markera den här kryssrutan om du vill använda kvotgränserna för den gemensamma mappens databas som den gemensamma mappen finns i. Om du inte väljer standardvärdena blir kryssrutorna Problemvarning på (KB), Förhindra inlägg vid (KB)och Maximal objektstorlek (KB) tillgängliga.

Varning om problem på (KB)

Markera den här kryssrutan om du automatiskt vill varna ägare av gemensamma mappar om att den gemensamma mappen närmar sig lagringsgränsen. Om du vill ange den här gränsen markerar du kryssrutan och anger sedan storleken på den gemensamma mappen i kilobyte (KB) där du vill förbjuda bokföring. Du kan ange ett värde mellan 0 kB och 2 147 483 647 kB (2,1 terabyte).

Förhindra inlägg på (KB)

Markera den här kryssrutan om du vill förhindra publicering till den gemensamma mappen när storleken på mappen når den angivna gränsen. Om du vill ange den här gränsen markerar du kryssrutan och anger sedan storleken på den gemensamma mappen i KB där du vill förbjuda bokföring. Du kan ange ett värde mellan 0 kB och 2 147 483 647 kB (2,1 terabyte).

Maximal objektstorlek (KB)

Markera den här kryssrutan om du vill begränsa den maximala storleken på objekt som användare kan publicera i den gemensamma mappen. Om du vill ange storleken markerar du kryssrutan och anger sedan den maximala storleken på objekt i kB som användarna kan publicera i de gemensamma mapparna. Du kan ange ett värde mellan 0 kB och 2 097 151 KB.

Kvarhållning av borttaget objekt

Använd standardinställningar för databaskvarhållning

Markera den här kryssrutan om du vill använda kvarhållningsgränserna för gemensamma mappar för databasobjekt på den server där den gemensamma mappen finns. Om du inte markerar den här kryssrutan blir kryssrutan Behåll borttagna objekt i (dagar) tillgänglig.

Behåll borttagna objekt i (dagar)

Markera den här kryssrutan om du vill ange hur många dagar borttagna objekt ska behållas i en gemensam mapp. Du kan ange ett värde mellan 0 och 24 855 dagar.

Åldersgränser

Använd standardvärden för databasålder

Markera den här kryssrutan om du vill använda databasens åldersgränser för den server där den gemensamma mappen finns. Om du inte markerar den här kryssrutan blir kryssrutan Åldersgräns för repliker (dagar) tillgänglig.

Åldersgräns för repliker (dagar)

Markera den här kryssrutan om du vill begränsa åldern för den gemensamma mappen. Använd motsvarande textruta för att ange åldersgränsen i dagar. Repliker av den här gemensamma mappen tas bort automatiskt när åldersgränsen överskrids. Du kan ange ett värde mellan 0 och 24 855 dagar.

Har servrarna olika åldersgränser?

  • Om svaret är ja är innehållsskillnaden avsiktligt. Du behöver inte fortsätta felsökningen. Du kan kringgå problemet genom att kopiera objekten så att de blir nya objekt i en ny mapp.
  • Om svaret är nej har ett okänt fel inträffat.

Händelse-ID 3027 som har typ 0x10 på målservern

På målservern undersöker du programloggen för händelse-ID 3027-händelsen som har typen 0x10.

Ser du händelse-ID 3027 och har den typen 0x10?

  • Om ja, se Fokusera på återfyllnad.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Om du kontaktar supporten för det här problemet kan du berätta för dem att källservern inte genererar utgående hierarkireplikeringsmeddelanden. Det finns en 3079-händelse när databasen monteras, men händelsen innehåller inte EcReplStartup.

Fokusera på återfyllnad

Nu har målservern beräknat att vissa data saknas. Därför kommer vi att fokusera på återfyllnad.

På målservern kör du Synkronisera innehåll igen i målmappen. När du har kört Synkronisera innehåll registreras händelse-ID 3016 i programloggen. Händelse-ID 3016 har meddelandetyp 0x8 som innehåller namnet på mappen.

Ser du händelse-ID 3016 på målservern och har den meddelandetypen 0x8 som innehåller namnet på mappen?

Händelse-ID 3026 på källservern

Som svar på händelse-ID 3016 på målservern bör du se händelse-ID 3026 i programloggen på källservern.

Ser du händelse-ID 3026 på källservern?

Händelse-ID 3021 på källservern

I programloggen på källservern, omedelbart efter händelse-ID 3026, bör du se en eller flera incidenter med händelse-ID 3021 som innehåller meddelandetyp 0x80000004 för mappen.

Ser du minst ett händelse-ID 3021 som innehåller meddelandetypen 0x80000004 för mappen?

Jämför antalet händelse-ID 3021 med antalet händelse-ID 3031

Räkna antalet incidenter i händelse-ID 3021 som finns i programloggen på källservern. Räkna sedan antalet incidenter i händelse-ID 3031 som har meddelandetypen 0x80000004 för mappen och som finns i programloggen på målservern.

Finns det lika många händelse-ID 3021-incidenter och händelse-ID 3031-incidenter mellan servrarna?

Leta upp innehållet i mappen på målservern

Leta efter det innehåll som synkroniserades från källservern till samma mapp på målservern på målservern.

Hittade du innehållet i samma mapp på målservern?

  • Om ja, grattis! Problemet med replikering av gemensamma mappar för Exchange Server 2003 har lösts.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.

Meddelandet kan ha skickats till en annan källserver

Granska händelse-ID 3016 för att kontrollera att meddelandet skickades till den förväntade källservern. På målservern undersöker du händelse-ID 3016 för att avgöra vilken källserver som ska ha tagit emot meddelandet. Om en annan källserver tog emot meddelandet använder du den servern som ny källserver och undersöker sedan programloggen på den nya källservern för händelse-ID 3016.

Händelsetyp Information
Händelsekälla OFFENTLIG MSExchangeIS-lagringsplats
Händelsekategori Utgående replikeringsmeddelanden
Händelse-ID 3016
Meddelande Värde för typ av <utgående meddelande>
Meddelande-ID: <ID>
Mapp: <mappnamn>
Databasens "<namn>".
CNSET: <värde>
CNSET(FAI): <värde>
Server: <servernamn>

Identifieras den förväntade källservern i händelse-ID 3016?

  • Om ja, se Händelse-ID 3021 på källservern.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.

Utestående gräns för återfyllnad

Som standard kan arkivet Gemensamma mappar innehålla upp till 50 utestående återfyllnadsbegäranden samtidigt. Detta kallas för OBL (Outstanding Backfill Limit). När 50 begäranden om återfyllnad finns i lagringsmatrisen görs dessa begäranden upprepade gånger tills de är uppfyllda. inga ytterligare nya begäranden kan göras förrän minst en begäran har slutförts.

Varje gång en begäran om återfyllnad uppfylls sker en öppning i OBL och en ny uppsättning data kan begäras. Men om alla 50 begäranden upplever problem och inte kan uppfyllas sker inga nya öppningar, inga nya begäranden kan göras och replikeringen kan inte fortsätta.

För att avgöra om en utestående återfyllnadsgräns är orsaken till problemet, öka OBL-gränsen med en (1) på målservern och granska sedan programloggen i minst fem minuter för en instans av händelse-ID 3016.

Öka OBL-gränsen med en (1) på målservern

  1. Öppna registret Editor genom att välja Starta>körning, skriv regedit och välj sedan OK.

  2. Expandera följande undernyckel:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<Server_Name>\Public-<GUID>

  3. Högerklicka på Public-GUID<>, peka på Nytt och välj sedan DWORD-värde.

  4. Skriv Replikeringsgränsen för utestående återfyllnad och tryck sedan på Retur för att namnge den nya -undernyckeln.

  5. Högerklicka på Replikeringsgränsen för utestående återfyllnad och välj sedan Ändra.

  6. I rutan Värdedata skriver du 51 och väljer sedan OK.

  7. Stäng Editor.

  8. Starta om Microsoft Exchange Information Store-tjänsten den Exchange Server 2003. Gör så här:

    • Välj Start, peka på Administrationsverktyg och välj sedan Tjänster.
    • I listan Tjänster väljer du Microsoft Exchange Information Store och sedan Starta om.

Om händelse-ID 3016 registreras för någon annan mapp kan du felsöka med den mappen i stället.

Ser du händelse-ID 3016 för någon annan mapp?

  • Om ja, se Felsöka återfyllnad av innehåll.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.

Spåra meddelandet som identifieras i händelse-ID 3020

På källservern använder du meddelandespårning för att spåra att meddelandet identifieras i händelse-ID 3020.

Indikerar meddelandespårning att meddelandet levererades till målservern?

Felsöka kommandot XEXCH50

Om du vill felsöka kommandot XEXCH50 ökar du loggningen på målservern för MSExchangeTransport-tjänsten och anger SMTP-protokollnivån till medel.

Om du vill verifiera och justera inställningen för SMTP-protokollnivå väljer du din Exchange-version för att kontrollera stegen:

För Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.
  2. Set-EventLogLevel -Identity "MSExchangeTransport\SmtpReceive" -Level 'Medium' Använd cmdletarna och Set-EventLogLevel -Identity "MSExchangeTransport\SmtpSend" -Level 'Medium' för att aktivera händelseloggning för SMTP.
  3. Använd cmdleten Resume-PublicFolderReplication för att starta replikering av gemensamma mappar för hela organisationen.

För Exchange Server 2003

Granska sedan programloggen i Loggboken efter händelser som liknar följande:

Händelsetyp Fel
Händelsekälla MSExchangeTransport
Händelsekategori SMTP-protokoll
Händelse-ID 7004
Datum: Datum
Tid Tid
Användare Inte tillgängligt
Dator Computer_Name
Beskrivning Det här är en SMTP-protokollfellogg för virtuell server-ID 1, anslutning nr 29. Fjärrvärden E2k3server1.contoso.com svarade på SMTP-kommandot "xexch50" med "504 Need to authenticate first". "Det fullständiga kommandot som skickades var "XEXCH50 2336 3". Detta kommer förmodligen att orsaka att anslutningen misslyckas.
Händelsetyp: Fel
Händelsekälla MSExchangeTransport
Händelsekategori SMTP-protokoll
Händelse-ID 7010
Datum Datum
Tid Tid
Användare Inte tillgängligt
Dator: Computer_Name
Beskrivning: Det här är en SMTP-protokolllogg för virtuell server-ID 1, anslutning nr 30. Klienten på "6.5.2.4" skickade ett "xexch50"-kommando och SMTP-servern svarade med "504 Måste autentiseras först". Det fullständiga kommandot som skickades var "xexch50 1092 2". Detta kommer förmodligen att orsaka att anslutningen misslyckas. Dessa händelser indikerar att XEXCH50 protokollmottagare utlöstes, men utbytet av blobarna misslyckades mellan de servrar som anges i händelserna.

Ser du händelse-ID 7004 och händelse-ID 7010 på målservern?

Kör isinteg -fix -test ReplState (om inte se händelse-IE 7004 och 7010)

Välj din Exchange-version för att verifiera och justera inställningen ReplState med följande steg:

För Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.

  2. Använd cmdleten New-PublicFolderDatabaseRepairRequest för att identifiera och åtgärda replikeringsproblem i databasen för den gemensamma mappen. Gemensamma mappar i databasen för gemensamma mappar kan fortfarande nås medan begäran körs, men du kan inte komma åt den gemensamma mapp som för närvarande repareras. När du har påbörjat reparationsbegäran kan den inte stoppas om du inte demonterar databasen.

  3. Kör följande cmdlet:

    New-PublicFolderDatabaseRepairRequest -Database -CorruptionType ReplState

För Exchange Server 2003

  1. Installera snabbkorrigeringen KB925253 på målservern.

  2. När snabbkorrigeringen har installerats demonterar du databasen för den gemensamma mappen på servern och kör sedan följande kommando i en kommandotolk:

    cd C:\Program Files\Exchsrvr\bin
Isinteg -s -fix -test ReplState

  3. När isinteg-processen är klar:

    1. Ändra repliklistan i den gemensamma mappen på målservern. Det gör du genom att lägga till en replik i eller ta bort en replik från valfri server. Välj Använd, ändra den ändring som du precis har gjort och välj sedan Använd igen.
    2. Skapa ett nytt objekt på källservern.
    3. Granska programloggen på källservern för händelse-ID 3020.
    4. Granska programloggen på målservern för händelse-ID 3030.

Ser du händelse-ID 3030 i programloggen på målservern?

  • Om ja, grattis! Problemet med replikering av gemensamma mappar för Exchange Server 2003 har lösts.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Om du kontaktar supporten för det här problemet kan du berätta för dem att källservern inte genererar utgående hierarkireplikeringsmeddelanden. Det finns en 3079-händelse när databasen monteras, men händelsen innehåller inte EcReplStartup.

Replikering får köstorlek i prestandaövervakaren

Replikeringsmeddelanden för gemensamma mappar tas emot av SMTP, kategoriseras och överlämnas till den lokala SMTP-kön. Meddelandena skickas sedan till arkivet för gemensamma mappar. När meddelanden har skickats till arkivet för gemensamma mappar placeras de i replikeringskön för mottagning. Meddelandena i replikeringskön för mottagning bearbetas sedan och ändringar utförs i lämplig gemensam mapp. Prestandaräknaren Replication Receive Queue Size anger antalet replikeringsmeddelanden för gemensamma mappar som väntar på att bearbetas.

Ju större replikeringskön blir, desto mer osynkronisering kan innehållet i mapparna bli. När replikeringsköerna växer ökar belastningen på resurser allt eftersom meddelandena i replikeringskön bearbetas. Dessutom indikerar växande replikeringsköer att innehållet i den gemensamma mappen på servern är inaktuellt.

Ingen åtgärd krävs i de två instanser där tillväxten i replikeringskön för mottagning förväntas och kan planeras för:

  • På en nyligen introducerad server för gemensamma mappar kan tillväxten i replikeringens mottagningskö orsakas av den förväntade inledande återfyllnadsreplikeringen.
  • Om webbplatskonsolidering eller andra större ändringar i Exchange-topologin sker förväntas det finnas massor av replikering när innehållet flyttas.

För befintliga servrar med stabilt tillstånd där gemensamma mapprepliker inte ändras i grupp kan det här felet tyda på följande:

  • Flaskhalsar för serverresursprestanda, till exempel disk, CPU, nätverk eller minne. Om det finns en resursflaskhals på servern kommer den Store.exe processen inte att kunna bearbeta replikeringsmeddelanden tillräckligt snabbt och en kö växer.
  • Replikeringsintervallet för gemensamma mappar är för kort för att replikeringen ska slutföras innan nästa replikeringscykel startar.

Så här löser du det här felet:

  • Övervaka MSExchangeIS Public\Replication Receive Queue Size (MsExchangeIS Public\Replication Receive Queue Size) tills replikeringen har slutförts innan nästa replikeringscykel startar.
  • Överväg att minska det totala antalet repliker i Exchange-organisationen för att minska mängden replikeringstrafik som krävs.

Om du har en hög kö kan du läsa Pausa replikering.

Om du har en låg kö kan du läsa Möjliga replState-problem.

Pausa replikering

Pausa replikeringen av gemensamma mappar och låt köerna tömmas eller anropa support.

Så här pausar du replikeringen

  1. Starta Exchange Management Console.
  2. Använd cmdleten Suspend-PublicFolderReplication för att stoppa replikeringen av gemensamma mappar för hela organisationen.
  3. Övervaka transportköerna genom att köra Get-TransportServer | Get-Queue. När kön har reducerats kan du återuppta replikeringen.
  4. Använd cmdleten Resume-PublicFolderReplication för att starta om replikering av gemensamma mappar för hela organisationen.

Det går inte att lösa ett oidentifierat problem med hjälp av den här guiden. Om du kontaktar supporten om det här problemet kan du berätta för dem att Replikeringen är pausad och att du väntar på att köerna ska minska.

Letar du efter mapp-ID (FID) (Isolera?)

Visar händelse-ID 3028-händelsen FID men inte mappens namn?

  • Om ja, se Tombstone på grund av en borttagning.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.

Tombstone på grund av en borttagning (händelse-ID 3028-händelsen visar FID)

Detta anger att mappen är en gravsten på grund av en tidigare borttagning som inte replikerade. Gå tillbaka till källservern och kopiera mappen för att skapa en ny mapp med samma innehåll och börja sedan om.

Är den här informationen användbar?

  • Om ja, se Ta bort dubblettkonton.
  • Om nej, tyvärr, Vi kan inte lösa oidentifierade problem med den här guiden. Om du vill ha mer hjälp med att lösa det här problemet kontaktar du Microsoft Exchange Server support och berättar att när databasen monteras loggas en 3079-händelse.

Visar prestandaövervakaren ett stort antal meddelanden i kö för överföring?

Öppna Prestandaövervakaren.

Lägg till counter MSExchangeIS Public\Replication Receive Queue och övervaka storleken på kön.

Om du behöver veta mer om prestandaövervakaren kan du gå hit: Komma igång guide för prestandaövervakning.

Visar prestandaövervakaren ett stort antal meddelanden i kö för överföring?

  • Om ja, se Kontrollera tjänster.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Om du kontaktar supporten för det här problemet kan du berätta för dem att servern genererar utgående hierarkimeddelanden, men att dessa meddelanden inte visas i meddelandespårningen och att ingenting köas för insändning.

Kontrollera tjänster

  1. Klicka på Start>Kör.
  2. Skriv services.msc i rutan.
  3. Hitta MSExchangeTransport och kontrollera att det har startats

Om du har PowerShell öppnar du det och kör följande cmdlet:

Get-Service MSExchangeTransport

Körs transporttjänsten?

  • Om ja, se Felsöka replikering av gemensamma mappar.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Om du kontaktar supporten för det här problemet kan du berätta för dem att servern genererar utgående hierarkimeddelanden, men att dessa meddelanden inte visas i meddelandespårningen och att ingenting köas för insändning.

Visar 3030-händelsen meddelandets ID (MID) för objektet, men inte ämnet

Visar händelsen 3030 objektets MITT, men inte ämnet?

  • Om ja, se Tombstone.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Om du kontaktar supporten för det här problemet kan du berätta för dem att källservern inte genererar utgående hierarkireplikeringsmeddelanden och att det inte finns någon 3079-händelse när databasen monteras.

Tombstone

Detta är vanligtvis resultatet av en tombstone på grund av en meddelandeborttagning som inte har replikerats. Du kan kopiera meddelandena i mappen för att skapa nya meddelanden eller kopiera hela mappen.

Är den här informationen användbar?

  • Om ja, se Ta bort dubblettkonton.
  • Om nej, tyvärr, kan vi inte lösa oidentifierade problem med den här guiden. Om du vill ha mer hjälp med att lösa det här problemet kontaktar du Microsoft Exchange Server support och berättar att när databasen monteras loggas en 3079-händelse.

Spåra händelse-ID 3027

Spåra 3027 för att se hur långt det kom. Om den inte lämnade källservern kontrollerar du prestandaräknaren Meddelanden i kö för överföring under MSExchangeIS Public för att se om de utgående meddelandena har fastnat i det offentliga arkivet.

Är den här informationen användbar?

  • Om ja, se Ta bort dubblettkonton.
  • Om nej, tyvärr, kan vi inte lösa oidentifierade problem med den här guiden. Om du vill ha mer hjälp med att lösa det här problemet kontaktar du Microsoft Exchange Server support och berättar att när databasen monteras loggas en 3079-händelse.

Möjligt replstate-problem

Det är möjligt att det här problemet kan vara ett XEXCH50 problem eller ett ReplState-problem. Innan vi fortsätter kontrollerar vi att SMTP-loggning är aktiverat.

Välj din Exchange-version för att verifiera och justera inställningen ReplState med följande steg:

För Exchange Server 2007 och Exchange Server 2010

  1. Starta Exchange Management Console.
  2. Set-EventLogLevel -Identity "MSExchangeTransport\SmtpReceive" -Level 'Medium' Använd cmdletarna och Set-EventLogLevel -Identity "MSExchangeTransport\SmtpSend" -Level 'Medium' för att aktivera händelseloggning på SMTP.
  3. Använd cmdleten Resume-PublicFolderReplication för att starta replikering av gemensamma mappar för hela organisationen.

För Exchange Server 2003

  1. Starta Exchange System Manager.
  2. Expandera Servrar, högerklicka på Your_ Servernamn och välj sedan Egenskaper.
  3. Välj fliken Diagnostikloggning och välj sedan MSExchangeTransport under Tjänster.
  4. Under Kategorier väljer du SMTP.
  5. Under Loggningsnivå väljer du Medel.

Vilken Exchange-version har du?

Ett eller flera av meddelandena gick förlorade i transporten

Om antalet 3 031 händelser på målservern är färre än antalet 3 021 händelser på källservern förlorades ett eller flera meddelanden under transporten. Om du vill felsöka meddelandeförlusten identifierar du meddelande-ID:t för de meddelanden som inte har replikerats.

Det gör du genom att granska programloggen på källservern. Använd sedan meddelandespårning för att spåra meddelandena och felsöka problemet.

Finns det några Exchange Server 2007- eller 2010-servrar i sökvägen till det meddelandet?

Löste det problemet?

Är problemet löst nu?

  • Om ja, grattis! Problemet med replikering av gemensamma mappar för Exchange Server 2003 har lösts.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.

Exchange Server 2007 och Exchange Server 2010 i sökvägen

Den vanligaste orsaken till ett återfyllnadssvar för förlorat innehåll den Exchange Server 2007 eller Exchange Server 2010 är ett fel på butiksdrivrutinen. Till exempel skickas ett återfyllnadssvar till en Exchange Server 2007-server, men om du tittar på programloggen på 2007-sidan ser du aldrig den inkommande replikeringshändelsen. Meddelandespårning visar att replikeringsmeddelandet kom till hubbens transportserver och sedan misslyckades i butiksdrivrutinen.

Det första steget för felsökning är att spåra meddelandet och se var det misslyckades.

Vanligtvis loggar hubbtransportservern en händelse 1020 som beskriver problemet med just det innehållet. När du har spårat meddelandet och fastställt vilken hubbtransportserver som det misslyckades på kontrollerar du händelsen 1020 med MSExchange Store-källdrivrutinen på hubbens transportserver.

Ser du en 1020-händelse med källans MSExchange Store-drivrutin på hubbtransportservern?

Exchange Server 2007 och Exchange Server 2010 i sökvägen (meddelandeinnehållet har skadats)

Det här meddelandet beror vanligtvis på en skadad TNEF. Om det här är en hybridmiljö använder du Exchange 2013 CU6 för att förhindra nya skadade meddelanden och tar bort de gamla. Om du vill identifiera de skadade objekten fortsätter du med stegen nedan.

Så här identifierar du vilka objekt som är skadade:

  1. Minska storleken på replikeringsmeddelandet till 1k på källservern.
  2. På målet framtvingar du en annan återfyllnadsbegäran med Synkronisera innehåll eller Update-PublicFolder.
  3. Nu visas ett återfyllnadssvar (händelse 3021) per objekt i mappen på källservern. Programloggen kan fyllas med svar på återfyllnad om mappen innehåller många objekt. När 3021-aktiviteten har lugnat ner sig rensar du programloggen på källservern och tvingar fram en ny begäran om återfyllnad. Eftersom alla bra objekt som redan har replikerats i den sista omgången av återfyllnad, bör de enda nya objekten som du bör se i den nya händelsen 3021 vara de skadade objekten.

Nu bör du ha ett återfyllnadssvar (3021) för varje skadat objekt i programloggen på källservern och en 1 020-händelse för varje skadat objekt i programloggen på hubbens transportserver. Eftersom du nu vet vilka objekt som är skadade (eftersom du kan läsa objektämnena i 3021-händelserna) kan du ta bort dessa objekt eller försöka åtgärda dem.

Mer information finns i Åtgärda replikeringsfel för gemensamma mappar från Exchange Server 2003 till Exchange Server 2007 eller 2010.

Löste det problemet?

Exchange Server 2007 och Exchange Server 2010 i sökvägen (se händelsen 1020 men inget av ovanstående felmeddelande)

Det här är någon annan typ av skadat objekt. Så här identifierar du vilka objekt som är skadade:

  1. Minska storleken på replikeringsmeddelandet till 1k på källservern.
  2. På målet framtvingar du en annan återfyllnadsbegäran med synkroniserat innehåll eller Uppdatera gemensam mapp.
  3. Nu visas ett återfyllnadssvar (händelse 3021) per objekt i mappen på källservern. Programloggen kan fyllas med svar på återfyllnad om mappen innehåller många objekt. När 3021-aktiviteten har lugnat ner sig rensar du programloggen på källservern och tvingar fram en ny begäran om återfyllnad. Eftersom alla bra objekt som redan har replikerats i den sista omgången med återfyllnad, bör de enda nya objekten som du bör se i den nya händelsen 3021 vara de skadade objekten.

Nu bör du ha ett återfyllnadssvar (3021-händelse) för varje skadat objekt i programloggen på källservern och en 1020-händelse för varje skadat objekt i programloggen på hubbens transportserver. Eftersom du nu vet vilka objekt som är skadade (eftersom du kan läsa objektämnena i 3021-händelserna) kan du ta bort dem eller försöka åtgärda dem.

Mer information finns i Åtgärda replikeringsfel för gemensamma mappar från Exchange Server 2003 till Exchange Server 2007 eller 2010.

Är problemet löst nu?

Ta bort dubblettkonton

Ta bort de duplicerade konton som nämns i händelsen eller ta bort en av användarna, så att SID kan matchas för en enskild användare i DS.

Är den här informationen användbar?

  • Om ja, grattis! Problemet med replikering av gemensamma mappar för Exchange Server har lösts.
  • Om nej kan vi tyvärr inte lösa ett oidentifierat problem med hjälp av den här guiden. Kontakta Microsoft Exchange Server support om du vill ha mer hjälp med att lösa problemet.