Aracılığıyla paylaş

Exchange Server için ortak klasör çoğaltma sorunlarını giderme

  • Şunlara uygulanır: Exchange Server 2010 Enterprise, Exchange Server 2010 Standard, Exchange Server 2010 Service Pack 3, Exchange Server 2007, Exchange Server 2003 Service Pack 2

Özgün KB numarası: 10042

Özet

Ön koşul olarak tanılama günlüğünü ve ileti izlemeyi etkinleştirmenizi isteyerek başlıyoruz. Ardından, ortak klasör çoğaltma sorunlarınızı çözmeniz için bir dizi adımdan geçeriz.

Tahmini tamamlanma süresi:
45-60 dakika.

Exchange Server'da ortak klasör çoğaltma sorunlarını gidermek için öncelikle tanılama günlüğünü ve ileti izlemeyi etkinleştirmeniz gerekir.

Ne yapmak istiyorsunuz?

Tanılama günlüğünü etkinleştir

Çalıştığınız tüm sunucularda tanılama günlüğünü açmanız gerekir. Farklı Exchange sürümü için adımlar farklı olabilir. Exchange sürümünüzü seçin:

Exchange Server 2007 ve Exchange Server 2010 için

  1. Exchange Management Shell'i başlatın.

  2. Geçerli günlük düzeylerini denetlemek için aşağıdaki cmdlet'i çalıştırın:

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

  3. Günlüğü açmak için, çalıştığınız tüm ortak klasör sunucularında aşağıdaki cmdlet'leri çalıştırın:

    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. Hedef Sunucuda, şu cmdlet'leri çalıştırarak Aktarım Günlüğünü artırın:

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

  5. Günlük düzeylerini sıfırlamak için:

    1. Exchange Yönetim Konsolu açın.
    2. Konsol ağacında Sunucu Yapılandırma>Posta Kutusu'na gidin.
    3. Eylemler bölmesinde Tanılama Günlüğü Özelliklerini Yönet'i seçin.
    4. Tanılama Günlüğü Özelliklerini Yönet sayfasında, günlük düzeyini değiştirmek istediğiniz Exchange hizmetini seçin.
    5. İstediğiniz günlük düzeyini seçin ve ardından Yapılandır'ı seçin. Varsayılanları geri yüklemek istiyorsanız Tüm hizmetleri varsayılan günlük düzeylerine sıfırla'yı ve ardından Yapılandır'ı seçin.
    6. Tamamlama sayfasında, işlemin başarıyla tamamlandığını onaylayın. Görevler Tamamlandı veya Başarısız durumunu gösterir. Görev başarısız olduysa, açıklamanın özetini gözden geçirin ve ardından gerekli yapılandırma değişikliklerini yapmak için Geri'yi seçin.
    7. Tanılama Günlüğü Düzeyini Yönet sihirbazını tamamlamak için Son'u seçin.

Exchange Server 2003 için

  1. Exchange Sistem Yöneticisi başlatın ve tanılama günlüğünü etkinleştirmek istediğiniz sunucunun özelliklerini görüntüleyin.
  2. Tanılama Günlüğü sekmesini seçin ve hizmetler listesinde MSExchangeIS'i genişletin.
  3. Ortak Klasör'e tıklayın, Ctrl tuşunu basılı tutun ve ardından aşağıdaki öğelerin her birini seçerek tümünü seçin:
    • Çoğaltma AD Güncelleştirmeleri
    • Gelen İletileri Çoğaltma
    • Giden İletileri Çoğaltma
    • Teslim Edilmedi Raporları
    • Çoğaltma Dolgusu
    • Çoğaltma Genel
  4. En Fazla>Uygula'yı seçin.
  5. Çoğaltma Hataları>Orta>Uygula>Tamam'ı seçin.
  6. MSExchangeTransport hizmetinin hedef sunucusunda günlüğe kaydetmeyi artırmak ve SMTP düzeyini Orta olarak ayarlamak için:
    1. Sunucular'ı genişletin, Sunucu Adınız'a sağ tıklayın ve özellikler'i seçin.
    2. Tanılama Günlüğü sekmesini ve ardından Hizmetler'in altında MSExchangeTransport'u seçin.
    3. Kategoriler'in altında SMTP'yi seçin.
    4. Günlük Düzeyi'nin altında Orta'yı seçin.

Bundan sonra ne yapmak istiyorsunuz?

İleti izlemeyi etkinleştirme

Üzerinde çalıştığınız tüm sunucularda İleti İzleme'yi açmak için farklı Exchange sürümüne yönelik adımlar farklı olabilir. Exchange sürümünüzü seçin:

Exchange Server 2007 ve Exchange Server 2010 için

  1. Exchange Yönetim Kabuğu'na gidip aşağıdaki cmdlet'i çalıştırarak ileti izlemenin açık olduğunu doğrulayın:

    Get-MailboxServer $env:computername | fl MessageTracking*

  2. Şuna benzer bir çıktı görmeniz gerekir:

    İleti izlemenin açık olduğunu doğrulamak için çalışan cmdlet'in ekran görüntüsü.

  3. her ikisinin de MessageTrackingLogEnabled MessageTrackingLogSubjectLoggingEnabled True olarak ayarlandığından emin olun.

  4. Günlük Konumu için öğesini MessageTrackingLogPath not edin.

Exchange Server 2003 için

  1. Exchange Sistem Yöneticisi başlatın ve ardından ileti izlemeyi etkinleştirmek istediğiniz sunucunun özelliklerini görüntüleyin. İleti izleme Kime, Kimden ve Gönderme Tarihi gibi verileri toplar.
  2. Genel sekmesinde İleti izlemeyi etkinleştir onay kutusunu seçin.
  3. Konu günlüğünü ve görüntülemeyi etkinleştir onay kutusunu seçin.

Ne yapmak istiyorsunuz?

Ortak Klasör Çoğaltma sorunlarını giderme

Bir sunucudaki verileri içeren ancak başka bir sunucuda bulunmayan bir klasör seçin ve yalnızca bu klasörü sorun giderme çalışmalarınızın odağı haline getirin. Aşağıdaki adımlarda, verileri içeren sunucu kaynak sunucu olarak adlandırılır; verileri içermeyen sunucu hedef sunucu olarak adlandırılır.

Exchange Server 2007 ve Exchange Server 2010

  1. Exchange Yönetim Konsolu'de, Araç Kutusu altında Ortak Klasör Yönetim Konsolu'nu seçin.
  2. Ortak Klasörler'e sağ tıklayın ve bağlan'ı seçin.
  3. Bağlanmak istediğiniz sunucuyu seçin.

Exchange Server 2003

  1. Exchange Sistem Yöneticisi açın.
  2. Ortak Klasör Hiyerarşi nesnesine gidin.
  3. Ortak Klasörler'e sağ tıklayın ve bağlan'ı seçin.
  4. Bağlanmak istediğiniz sunucuyu seçin.

Aradığınız klasör şimdi her iki sunucudaki hiyerarşide görünüyor mu?

Her Zaman Aralığını Çoğalt; Uygulama günlüğü Olay Kimliği 3018

Her Zaman Aralığını Çoğalt

Kaynak sunucuda Her Zaman Aralığını Çoğalt değerinin 15 veya daha az dakika olarak ayarlandığını doğrulayın. Gerekirse ayarı ayarlayın. Adımları denetlemek için Exchange sürümünüzü seçin:

Exchange Server 2007 ve Exchange Server 2010

  1. Exchange Yönetim Konsolu'ı başlatın.

  2. Aşağıdaki cmdlet'leri çalıştırın ve , ReplicationScheduleve ReplicationMessageSize değerlerinin ayarlandığını ReplicationPerioddoğrulayın:

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

    Parametrelerin ayarlandığını doğrulamak için Get-PublicFolderDatabase komutunu çalıştırmanın ekran görüntüsü.

  3. Tüm genel f veritabanlarının aynı ReplicationMessageSizeolduğundan emin olun.

Ardından, söz konusu klasörün depo zamanlamasını kullanacak şekilde yapılandırıldığını doğrulayın. Bunu yapmak için:

  1. Exchange Yönetim Konsolu'ı başlatın.

  2. Aşağıdaki cmdlet'i çalıştırın ve doğrulayın Replicas ve UseDatabaseReplicationSchedule ayarlandı:

    Get-PublicFolder | fl *Replica*

    Parametrelerin ayarlandığını doğrulamak için Get-PublicFolder çalıştırmanın ekran görüntüsü.

  3. False olarak ayarlandıysa UseDatabaseReplicationSchedule ayarlandığından emin olunReplicationSchedule.

Exchange Server 2003
  1. Exchange Sistem Yöneticisi başlayın.
  2. Yönetim Grupları kapsayıcınızı genişletin ve ardından ortak klasör sunucusunu içeren yönetim grubunu seçin.
  3. Sunucular kapsayıcısını genişletin, ortak klasör veritabanını ve ardından Özellikler'i seçin.
  4. Çoğaltma (İlke) sekmesinde, Her zaman (dakika) için Çoğaltma aralığı kutusundaki değeri not alın.
  5. Değer 15 değilse, Her zaman için çoğaltma aralığı (dakika) kutusuna 15 yazın.
  6. Uygula’yı ve sonra Tamam’ı seçin.

Ardından, sorun giderdiğiniz klasörün depo zamanlamasını kullanacak şekilde yapılandırıldığını doğrulayın:

  1. Ortak Klasörler'i genişletin ve sorun gidermekte olduğunuz klasöre sağ tıklayın.
  2. Özellikleri'i seçin.
  3. Çoğaltma sekmesinde, Ortak klasör çoğaltma aralığı listesinde Ortak depo zamanlamasını kullan'ı seçin.

Uygulama günlüğü Olay Kimliği 3018

Kaynak sunucudaki hiyerarşide yeni bir klasör oluşturun ve yeni klasöre anımsayabileceğiniz benzersiz bir ad verin.

Bu örnekte klasörümüzün adı olarak Test 1'i kullanıyoruz. 0x2 ileti türünü gösteren ve oluşturduğunuz klasörün adını içeren Olay Kimliği 3018 için kaynak sunucuda uygulama günlüğünü izleyin. Olayın günlüğe kaydedilmesi için 15 dakikaya kadar beklemeniz gerekebilir.

Olay Türü Bilgiler
Olay Kaynağı: MSExchangeIS Genel Deposu
Olay Kategorisi: Giden İletileri Çoğaltma
Olay Kimliği: 3018
İleti: Giden çoğaltma iletisi verildi.
Tür: 0x2
İleti Kimliği: <MessageID@Server.Domain.com>
Veritabanı "Depolama Grubu\Ortak Klasör"
CN dk: 1-100, maksimum CN: 1-200
RFI'ler:
1) FID: 1-1234, PFID: 1-1, Uzaklık: 28
IPM_SUBTREE\Test 1

Olay Kimliği 3018'i görüyor musunuz?

Kaynak sunucuda sorun giderme

Kaynak sunucu, yeni değişiklikler için giden hiyerarşi çoğaltma iletileri oluşturmuyor. İlk olarak kaynak sunucuda sorun gidermeye odaklanacağız.

Ortak klasör veritabanı bağlandığında Olay Kimliği 3079

Ortak klasör veritabanı bağlandığında, Olay Kimliği 3079 kaynak sunucudaki Uygulama günlüğüne kaydedilir. Kaynak sunucuda Uygulama günlüğünü inceleyin.

Olay Türü Bilgiler
Olay Kaynağı MSExchangeIS Genel Deposu
Olay Kategorisi Çoğaltma Hataları
Olay Kodu 3079
İleti "<name>" veritabanında beklenmeyen çoğaltma iş parçacığı hatası.
1) FID: 1-1234, PFID: 1-1, Uzaklık: 28
IPM_SUBTREE\Test 1

Olay Kimliği 3079'ı görüyor musunuz?

  • Evet ise bkz . EcReplStartup.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorun hakkında desteğe başvurursanız, kaynak sunucunun giden hiyerarşi çoğaltma iletileri oluşturmadığını ve veritabanı bağlandığında 3079 olayı olmadığını söyleyin.

EcReplStartup

Şu metin için Olay Kimliği 3079'a bakın: EcReplStartup.

Olay Kimliği 3079 EcReplStartup içeriyor mu?

  • Evet ise bkz . Uygulama günlüğü Olay Kimliği 9528.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunla ilgili desteğe başvurursanız, kaynak sunucunun giden hiyerarşi çoğaltma iletileri oluşturmadığını söyleyin. Veritabanı bağlandığında bir 3079 olayı vardır, ancak olay EcReplStartup içermez.

Uygulama günlüğü Olay Kimliği 9528

Olay Kimliği 3079 EcReplStartup içeriyorsa bu, çoğaltma iş parçacığının başlangıçta ölmekte olduğunu gösterir. Ardından, Olay Kimliği 9528'in kaynak sunucunun Uygulama günlüğüne kaydedilip kaydedilmediğini denetleyin.

Olay Türü Bilgiler
Olay Kaynağı MSExchangeIS
Olay Kategorisi Genel
Olay Kodu 9528
İleti SID S-1-5-32-544, DS'deki 2 kullanıcıda bulundu, bu nedenle depo bu SID'yi benzersiz bir kullanıcıyla eşleyemez.
İlgili kullanıcılar şunlardı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

Olay Kimliği 9528'i görüyor musunuz?

  • Evet ise, bkz . Yinelenen hesapları kaldırma.
  • Hayır, üzgünüz, bu kılavuzla tanımlanamayan sorunları çözemiyoruz. Bu sorunu çözme konusunda daha fazla yardım için Microsoft Exchange Server desteğine başvurun ve veritabanı bağlandığında bir 3079 olayının günlüğe kaydedildiğini söyleyin.

İleti izlemede iletiyi izleme; İleti hedef sunucuya teslim edildi mi?

İleti izlemede iletiyi izleme

Kaynak sunucuda, ileti izlemedeki iletiyi izlemek için Olay Kimliği 3018'in açıklamasındaki ileti kimliğini kullanın.

Olay Türü Bilgiler
Olay Kaynağı MSExchangeIS Genel Deposu
Olay Kategorisi Çoğaltma Giden İletisi
Olay Kodu 3018
İleti Giden çoğaltma iletisi verildi.
Tür: 0x2
İleti Kimliği: <MessageID@Server.Domain.com>
Veritabanı "Depolama Grubu\Ortak Klasör"

İleti hedef sunucuya teslim edildi mi?

Olay Kimliği 3018'in açıklamasında ileti kimliğini not edin ve ardından iletinin hedef sunucuya teslim edilip edilmediğini belirlemek için ileti izlemeyi kullanın. Örneğin, aşağıdaki ileti izleme alıntısı aşağıdaki metni içerir:

"İleti SMTP aracılığıyla aktarıldı".

İleti Geçmişi

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

İleti izleme, iletinin hedef sunucuya teslim edildiğine işaret ediyor mu?

Taşıma sorunu; İleti, ileti izlemede görünüyor mu?

Taşıma sorunu

İleti hedef sunucuya teslim edilmedi ve bu da soruna bir aktarım sorununun neden olduğunu gösterir. Ardından, aktarım işleminin sorunlarını giderin.

İleti, ileti izlemede görünüyor mu?

Kaynak sunucuya gidin ve giden İleti Kimliğini bulun. Ardından Hedef sunucuya gidin ve iletinin alınıp alınmadığını görmek için ileti izlemeyi çalıştırın. İleti izlemeyi çalıştırma adımlarını denetlemek için Exchange sürümünüzü seçin.

Exchange Server 2007 ve Exchange Server 2010 için

  1. Exchange Yönetim Konsolu'ı başlatın.

  2. Aşağıdaki cmdlet'i çalıştırın:

    Get-MessageTrackingLog -MessageId
Exchange Server 2003 için
  1. Exchange Sistem Yöneticisi başlayın.
  2. Konsol ağacında Araçlar'ı genişletin ve ardından İleti İzleme Merkezi'ni seçin.
  3. Sunucu kutusuna Exchange Server 2003 çalıştıran sunucunun adını yazın.

Kullanılabilir sunucuların listesine göz atmak için Sunucu'ya tıklayın, bir sunucu seçin ve ardından Ekle'ye tıklayın. Belirli bir sunucudan gönderilen veya belirli bir sunucuya teslim edilen bir iletiyi arayabilirsiniz. Yalnızca sunucu adını belirtmeniz gerekir.

İletiyi aldı mı?

Hedef sunucuda Olay Kimliği 3028

Hedef sunucuda, Olay Kimliği 3018'in açıklamasında not ettiğiniz ileti kimliğini içeren Olay Kimliği 3028 için Uygulama günlüğünü inceleyin.

Olay Türü Bilgiler
Olay Kaynağı MSExchangeIS Genel Deposu
Olay Kategorisi Gelen İletileri Çoğaltma
Olay Kodu 3028
İleti Gelen çoğaltma iletisi verildi.
Tür: 0x2
İleti Kimliği: <MessageID@Server.Domain.com>
Veritabanı "Depolama Grubu\Ortak Klasör"
CN dk: 5-100 CN maksimum: 5-200
RFI'ler: 1
1) FID: 5-1234, PFID: 1-1, Uzaklık: 28
IPM_SUBTREE\Test 1

Hedef sunucu Uygulama günlüğü Olay Kimliği 3028'i gösteriyor mu ve bu olay Olay Kimliği 3018 ile aynı ileti kimliğini içeriyor mu?

Hedef sunucuda Olay Kimliği 7004 ve Olay Kimliği 7010

Hedef sunucuda, aşağıdaki olaylara benzeyen olaylar için Olay Görüntüleyicisi Uygulama günlüğü'nü inceleyin.

Olay Türü Hata
Olay Kaynağı MSExchangeTransport
Olay Kategorisi SMTP Protokolü
Olay Kodu 7004
Tarih Tarih
Saat Saat
Kullanıcılar Kullanılamaz
Bilgisayar Computer_Name
Açıklama Bu, 1. sanal sunucu kimliği, bağlantı #29 için bir SMTP protokolü hata günlüğüdür. Uzak ana bilgisayar E2k3server1.contoso.com, "xexch50" SMTP komutuna "504 Önce kimlik doğrulaması gerekiyor" ile yanıt verdi. Gönderilen komutun tamamı "XEXCH50 2336 3 " şeklindeydi. Bu büyük olasılıkla bağlantının başarısız olmasına neden olur.
Olay Türü Hata
Olay Kaynağı MSExchangeTransport
Olay Kategorisi SMTP Protokolü
Olay Kodu 7010
Tarih Tarih
Saat Saat
User Kullanılamaz
Bilgisayar Computer_Name
Açıklama: Bu, 1. sanal sunucu kimliği, bağlantı #30 için bir SMTP protokol günlüğüdür. "6.5.2.4" konumundaki istemci bir "xexch50" komutu gönderdi ve SMTP sunucusu "504 Önce kimlik doğrulaması gerekiyor" yanıtını verdi. Gönderilen tam komut "xexch50 1092 2" idi. Bu büyük olasılıkla bağlantının başarısız olmasına neden olur. Bu olaylar, XEXCH50 protokol havuzu tetiklendiğini, ancak blob değişiminin olaylarda listelenen sunucular arasında başarısız olduğunu gösterir.

Hedef sunucuda Olay Kimliği 7004 ve Olay Kimliği 7010'ı görüyor musunuz?

XEXCH50 komutuyla ilgili sorunu çözme

Karşılaştığınız sorun bir XEXCH50 komut sorunundan kaynaklanıyor olabilir.

XEXCH50 komut sorununu çözmek için

  1. Kuruluşunuzda Exchange Server çalıştıran bilgisayarlardaki SMTP sanal sunucularında Tümleşik Windows Kimlik Doğrulaması'nın etkinleştirildiğini doğrulayın. Tümleşik Windows Kimlik Doğrulaması etkin değilse:

    1. Exchange Sistem Yöneticisi,Yönetim Grupları'nu genişletin, Sunucular'ı genişletin, Exchange Server Adı'yı genişletin, Protokoller'i ve ardından SMTP'yi genişletin.
    2. SMTP sanal sunucusuna sağ tıklayın.
    3. Özellikler'i seçin, Erişim sekmesini ve ardından Kimlik Doğrulaması'nı seçin. Tümleşik Windows Kimlik Doğrulaması onay kutusunun seçili olduğundan emin olun.

  2. Tümleşik Windows Kimlik Doğrulaması etkinse ancak olaylar devam ederse, 7004 olayında veya 7010 olayında gönderen sunucu, alıcı sunucuda gönderildiğinde eksik olabilir veya reddedilebilir. Gönderen sunucu ve alıcı sunucu bu olaylarla karşılaşıyorsa, sunucularda birbirleri için SendAs hakları olmayabilir. SendAs hakkı açıkça ayarlanmadı. SendAs hakkı genellikle Exchange Etki Alanı Sunucuları (EDS) grubu üyeliği aracılığıyla devralınır. EDS'de bu REDDETME erişim denetimi girdisi (ACE) yoksa, etkilenen sunucu DENY ACE'sine sahip başka bir grupta iç içe geçmiş olabilir veya EDS, DENY ACE'sine sahip diğer bazı gruplarda iç içe geçmiş olabilir. Başarılı bir şekilde çalıştırmak için, XEXCH50 komutunun Exchange kuruluşundaki sunucular için SendAs hakkına sahip olması gerekir.

  3. Exchange kuruluşundaki sunucular arasında Aktarım Katmanı Güvenliği (TLS) ve güvenlik kanalı kullanıp kullanmadığınızı belirleyin. Bu senaryoda, STARTTLS aktarım olayı havuzları AUTH komutundan önce gerçekleşir. XEXCH50 komutu oturumda daha sonra başarısız olur çünkü AUTH komutu eksiktir.

  4. Exchange Protokolü Güvenliği (EXPS) kimlik doğrulaması sunucular arasında düzgün çalışmıyorsa, XEXCH50 komutu çalışmaz. 1704 ve 1706 olayları, Uygulama günlüğünde EXPS kimlik doğrulaması hatalarını gösterir.

    Olay Türü Uyarı
    Olay Kaynağı MSExchangeTransport Olayı
    Olay Kategorisi MTP Protokolü
    Olay Kodu 1706
    Açıklama: EXPS geçici olarak ".. com" yazın. "CSessionContext::OnEXPSInNegotiate" adlı ve 0x8009030c hata koduyla başarısız olan "HrServerNegotiateAuth" ( i:\transmt\src\smtpsink\exps\expslib\context.cpp@1462 ). Veri: 0000: 0c 03 09 80 ...?

    Not

    Olay Kimliği 1706'daki açıklama, hata kodu 0x8009030c içerir.
    Hata kodu 0x8009030c SEC_E_LOGON_DENIED Hresult değeridir. Bu kod hesabın oturum açılamadığını gösterir.
    Bu AUTH komutunu geçirmek için EXPS'nin Microsoft Windows kimlik bilgileri gerektiğinden bu sorunları gidermek zor olabilir. Olay Kimliği 7004 ve 7010 birleşiminde sorun gidermek için çeşitli araçları kullanabilirsiniz; Bu, NLTEST aracını ve NETDOM aracını içerir. Sorun giderme adımları bilgisayar hesabı parolalarını sıfırlamayı içerebilir.
    Uygulama günlüğünde daha önce açıklandığı gibi Olay Kimliği 7004 ve 7010'un birleşimine sahipseniz ve EXPS kimlik doğrulamasını kullanarak sorunun kaynağını bulamıyorsanız, Microsoft Desteği Hizmetleri'ne başvurun.
    Uygulama günlüğünde Olay Kimliği 7004 ve Olay Kimliği 7010 birleşimine sahip değilseniz 5. adıma gidin.

  5. Exchange kuruluşundaki sunucular arasında güvenlik duvarı veya virüsten koruma duvarı olup olmadığını denetleyin. Kuruluştaki sunucular arasında çalışan bir güvenlik duvarı varsa, soruna neden olup olmadığını belirlemek için güvenlik duvarını geçici olarak devre dışı bırakın.

Güvenlik duvarı devre dışı bırakıldıktan sonra sorun çözüldü mü?

Isinteg -fix -test ReplState'i hedef sunucuda çalıştırın; Silme işlemi nedeniyle kaldırılma işareti

Isinteg –fix –test ReplState'i hedef sunucuda çalıştırma

Aşağıdaki adımlarla ReplState ayarını doğrulamak ve ayarlamak için Exchange sürümünüzü seçin:

Exchange Server 2007 ve Exchange Server 2010 için

  1. Exchange Yönetim Konsolu'ı başlatın.

  2. Ortak klasör veritabanındaki New-PublicFolderDatabaseRepairRequest çoğaltma sorunlarını algılamak ve düzeltmek için cmdlet'ini kullanın. İstek çalışırken ortak klasör veritabanındaki ortak klasörlere yine erişilebilir. Ancak, şu anda onarılmakta olan ortak klasör kullanılamıyor. Onarım isteğine başladıktan sonra, veritabanını çıkarmadığınız sürece durdurulamaz.

  3. Aşağıdaki cmdlet'i çalıştırın:

    New-PublicFolderDatabaseRepairRequest -Database -CorruptionType ReplState
Exchange Server 2003 için

  1. Hedef sunucuda düzeltme KB925253 yükleyin.

  2. Düzeltme yüklendikten sonra, sunucudaki ortak klasör veritabanını kaldırın ve komut isteminde aşağıdaki komutu çalıştırın:

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

Ardından, sorunun çözülmüş olup olmadığını belirlemek için bir test çalıştırın.

Silme işlemi nedeniyle kaldırılma işareti

Bu, çoğaltılmamış önceki silme işleminden dolayı klasörün bir silinmiş öğe olduğunu gösterir. Kaynak sunucuya dönün ve klasörü kopyalayarak aynı içeriğe sahip yeni bir klasör oluşturun ve yeniden başlayın.

Yeni klasör görünürlüğü

Yeni klasör hedef sunucudaki hiyerarşide görünür mü?

Hiyerarşi geri doldurma sorunlarını giderme

Bu noktada, hiyerarşideki değişikliklerin doğru çoğaltıldığını doğruladık. Artık hiyerarşi geri doldurma sorunlarını giderebiliriz. Bunu yapmak için hedef sunucuda Hiyerarşiyi Eşitle'yi çalıştırın. Hiyerarşiyi Eşitle, Olay Kimliği 3017'nin oluşmasına neden olur. Olay Kimliği 3017, kaynak sunucuya bir hiyerarşi durum isteğinin (tür 0x20) gönderildiğini gösterir.

Exchange Server 2007 ve Exchange Server 2010 için

  1. Exchange Yönetim Konsolu'ı başlatın.
  2. cmdlet'ini Update-PublicFolderHierarchy -Server çalıştırın.
  3. Hedef sunucuda Hiyerarşiyi Eşitle'yi çalıştırdıktan sonra, 3027 olayı ve gelen durum isteği için kaynak sunucudaki Uygulama günlüğünü inceleyin.

Exchange Server 2003 için

  1. Exchange Sistem Yöneticisi başlayın.
  2. Hiyerarşiyi Eşitle'yi çalıştırmak için Klasörler'i genişletin, Ortak Klasörler nesne kapsayıcısına sağ tıklayın ve Hiyerarşiyi Eşitle'yi seçin.
  3. Hedef sunucuda Hiyerarşiyi Eşitle'yi çalıştırdıktan sonra, olay 3027 ve gelen durum isteği için kaynak sunucudaki Uygulama günlüğünü inceleyin.

Olay 3027, kaynak sunucudaki Uygulama günlüğünde mi?

İleti kimliğini alma ve iletiyi izleme

Kaynak sunucuda Olay Kimliği 3017'yi bulun ve ileti kimliğini not edin. İletinin kaynak sunucuya teslim edilip edilmediğini belirlemek üzere ileti kimliğini izlemek için ileti izlemeyi kullanın.

İleti izleme, iletinin kaynak sunucuya teslim edildiği söylüyor mu?

Kaynak sunucudaki ortak klasör deposunun bir e-posta adresine sahip olup olmadığını belirleme

Kaynak sunucudaki ortak klasör deposunun atanmış bir ara sunucu adresi olup olmadığını belirlemek için, Active Directory dizin hizmetindeki özniteliğin proxyAddresses değerini inceleyin.

Değeri incelemek için

Uyarı

Active Directory Hizmet Arabirimi (ADSI) Düzenleme ek bileşenini, LDP yardımcı programını veya başka bir LDAP sürüm 3 istemcisini kullanırsanız ve Active Directory nesnelerinin özniteliklerini yanlış değiştirirseniz ciddi sorunlara neden olabilirsiniz. Bu sorunlar Microsoft Windows 2000 Server, Windows Server 2003, Microsoft Exchange Server 2000, Microsoft Exchange Server 2003 veya hem Windows Server hem de Exchange Server'ı yeniden yüklemenizi gerektirebilir. Microsoft, Active Directory nesne özniteliklerini yanlış değiştirirseniz oluşan sorunların çözülebileceğini garantileyemez. Bu öznitelikleri kendi riskinizle değiştirin.

Not

Microsoft Windows sürümünüze bağlı olarak, aşağıdaki adımlar bilgisayarınızda farklı olabilir. Adımlar farklıysa, bu adımları tamamlamak için ürün belgenize göz atın.

  1. Çalıştır'ı Başlat'ı> seçip Aç kutusuna adsiedit.msc yazıp Tamam'ı seçerek ADSI Düzenleme aracını başlatın.

    Not

    ADSI Düzenleme, Microsoft Windows 2000 Server Destek Araçları ve Windows Server 2003 Destek Araçları ile birlikte sağlanır. Windows 2000 Destek Araçları'nı yüklemek için Windows 2000 CD'sindeki Support\Tools klasöründeki Setup.exe çift tıklayın. Windows Server 2003 Destek Araçları'nı yüklemek için Windows Server 2003 CD'sindeki Support\Tools klasöründeki Suptools.msi çift tıklayın.

  2. Henüz bağlı değilseniz bir etki alanı denetleyicisine bağlanın.

    Not

    Bu adımda, contoso.com etki alanı adınız için bir yer tutucudur; italik diğer sözcükler belirtilen adlar için yer tutuculardır. Yapılandırma Kapsayıcısı'nı genişletin [computername.contoso.com], CN=Yapılandırma, DC=contoso, DC=com, CN=Hizmetler'i genişletin, CN=Microsoft Exchange'i genişletin, CN=KuruluşAdı'nı genişletin, CN=Yönetim Grupları'nı genişletin, CN=YönetimselGrupAdı'nı genişletin, CN=Sunucular'ı genişletin, CN=ExchangeServerName'i genişletin, CN=InformationStore'u genişletin ve ardından CN=İlk Depolama'yı seçin Grupla'ya tıklayın.

  3. Sağ bölmede, CN=Ortak Klasör Deposu 'na (EXCHANGESERVERNAME) sağ tıklayın ve özellikler'i seçin.

  4. Görüntülenecek özellikleri seçin listesinde her ikisini de seçin.

  5. Görüntülenecek özellik seçin listesinde proxyAddresses'i seçin.

  6. Değerler kutusunda, bir e-posta adresinin atanıp atanmadığını belirleyin. Genel olarak, ortak klasör deposunda şuna benzer bir Basit Posta Aktarım Protokolü (SMTP) adres damgası vardır: SMTP:ExchangeServerName-IS@contoso.com.

  7. Görüntülenecek özellik seçin listesinde posta'yı seçin.

  8. Değerler kutusunda, SMTP adresinin 7. adımda görüntülenen SMTP adresiyle aynı olduğunu doğrulayın.

Kaynak ortak deponun e-posta adresi var mı?

  • Evet ise, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.
  • Hayır ise bkz . Uygulama günlüğü Olay Kimliği 3018.

Kaynak sunucuda Olay Kimliği 3017

Kaynak sunucudaki Uygulama günlüğünde, Olay Kimliği 3027'nin hemen öncesinde, 0x10 türündeki aynı klasör için Olay Kimliği 3017'yi bulun.

Olay Kimliği 3017'yi görüyor ve aynı klasör için 0x10 mi yazacaksınız?

Hedef sunucuda Olay Kimliği 3027

Olay Kimliği 3027, kaynak sunucudaki durum yanıtıdır. Durum yanıtını incelemek için hedef sunucudaki Uygulama günlüğünde Olay Kimliği 3027'yi bulun.

Hedef sunucuda Olay Kimliği 3027'yi görüyor musunuz?

  • Evet ise bkz . Geri doldurma sorunlarını giderme.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

Geri doldurma sorunlarını giderme

Bu noktada, hedef sunucunun verilerin eksik olduğunun farkında olduğunu biliyoruz. Şimdi hiyerarşinin kendisini doldurma sorunlarını gidermeye odaklanıyoruz.

Hedef sunucuda Hiyerarşiyi Eşitle'yi yeniden çalıştırın ve ardından hedef sunucudaki Uygulama günlüğünü 0x8 türündeki Olay Kimliği 3014 için denetleyin. Olay Kimliği 3014, hiyerarşi için giden bir geri doldurma isteğidir.

Olay Kimliği 3014'i görüyor ve hedef sunucuda 0x8 mi yazacaksınız?

  • Evet ise, kaynak sunucuda Olay Kimliği 3024'e bakın.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

Kaynak sunucuda Olay Kimliği 3024

Olay Kimliği 3024, gelen hiyerarşi geri doldurma isteğidir.

Kaynak sunucuda Olay Kimliği 3024'i görüyor musunuz?

Kaynak sunucuda Olay Kimliği 3019

Tür 0x80000002 olan Olay Kimliği 3019, kaynak sunucudaki giden hiyerarşi geri doldurma yanıtıdır. Olay Kimliği 3019 için kaynak sunucuda Uygulama günlüğünü inceleyin.

Olay Kimliği 3019, kaynak sunucudaki Uygulama günlüğünde mi?

  • Evet ise bkz . Olay Kimliği 3029.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

Olay Kimliği 3029

Olay Kimliği 3029, hedef sunucuda gelen hiyerarşi geri doldurma yanıtıdır.

Hedef sunucudaki Uygulama günlüğünde Olay Kimliği 3029'ı görüyor musunuz?

Hiyerarşide klasörü arayın

Hedef sunucuda, hiyerarşideki klasörü arayın.

Şimdi hedef sunucudaki hiyerarşide klasörü görüyor musunuz?

  • Evet ise tebrikler! Exchange Server 2003 için Ortak Klasör Çoğaltma sorununuz çözüldü.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

Olay Kimliği 3014'ten ileti kimliğini izleme

İleti kimliğini almak için hedef sunucuda Olay Kimliği 3014'e bakın. İleti kimliğini izlemek için ileti izlemeyi kullanın.

İleti izleme, iletinin kaynak sunucuya teslim edildiğine işaret ediyor mu?

Olay Kimliği 3019'dan ileti kimliğini izleme

Kaynak sunucuda Olay Kimliği 3019'u bulun ve olaydaki ileti kimliğini not edin. İleti kimliğini izlemek için ileti izlemeyi kullanın.

İleti izleme, iletinin hedef sunucuya teslim edildiğine işaret ediyor mu?

  • Yanıt evet ise bkz. Performans İzleyicisi Çoğaltma Alma Kuyruğu Boyutu.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

İçeriğe odaklanın; Always Interval ve Schedule çoğaltma; Kaynak sunucuda yeni öğe oluşturma

İçeriğe odaklanma

Klasör her iki sunucudaki hiyerarşide göründüğünden, bu büyük olasılıkla bir hiyerarşi çoğaltma sorunu değildir. Bu nedenle, içerik sorunlarını gidermeye odaklanın.

Always Interval ve Schedule Çoğaltma

Kaynak sunucuda Her Zaman Aralığını Çoğalt değerinin 15 dakika veya daha az olarak ayarlandığını doğrulayın.

Exchange Server 2007 ve Exchange Server 2010'da ayarı doğrulamak ve ayarlamak için

  1. Exchange Yönetim Konsolu'ı başlatın.

  2. Aşağıdaki cmdlet'i çalıştırın ve , ReplicationScheduleve ReplicationMessageSize ayarlarını doğrulayınReplicationPeriod:

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

    Parametrelerin ayarlandığını doğrulamak için Get-PublicFolderDatabase kullanmanın ekran görüntüsü.

  3. Tüm ortak klasör veritabanlarının aynı ReplicationMessageSizeolduğundan emin olun.

Ardından, söz konusu klasörün depo zamanlamasını kullanacak şekilde yapılandırıldığını doğrulayın:

  1. Exchange Yönetim Konsolu'ı başlatın.

  2. Aşağıdaki cmdlet'i çalıştırın ve doğrulayın Replicas ve UseDatabaseReplicationSchedule ayarlandı:

    Get-PublicFolder | fl *Replica*

    Parametrelerin ayarlandığını doğrulamak için Get-PublicFolder kullanmanın ekran görüntüsü.

  3. False olarak ayarlandıysaUseDatabaseReplicationSchedule, ayarlandığından ReplicationSchedule emin olun.

Exchange Server 2003'te ayarı doğrulamak ve ayarlamak için
  1. Exchange Sistem Yöneticisi başlayın.
  2. Yönetim Grupları kapsayıcınızı genişletin ve ardından ortak klasör sunucusunu içeren yönetim grubunu seçin.
  3. Sunucular kapsayıcısını genişletin, kaynak sunucuyu genişletin, ortak klasör veritabanını seçin ve ardından Özellikler'i seçin.
  4. Çoğaltma (İlke) sekmesinde, Her zaman (dakika) için Çoğaltma aralığı kutusuna 15 yazın.
  5. Uygula’yı ve sonra Tamam’ı seçin.

Ardından, üzerinde çalıştığınız klasörün depo zamanlamasını kullanacak şekilde yapılandırıldığını doğrulayın. Bunu yapmak için:

  1. Ortak Klasörler'i genişletin ve üzerinde çalıştığınız klasöre sağ tıklayın.
  2. Özellikleri'i seçin.
  3. Çoğaltma sekmesinde, Ortak klasör çoğaltma aralığı listesinde Ortak depo zamanlamasını kullan'ı seçin.

Kaynak sunucuda yeni öğe oluşturma

Kaynak sunucudaki ortak klasörde yeni bir öğe oluşturun ve ardından Olay Kimliği 3020 için Uygulama günlüğünü izleyin.

Olay Kimliği 3020'yi görüyor musunuz ve test ettiğiniz klasörün adını ve oluşturduğumuz öğenin adını içeriyor mu?

Olay Kimliği 3030

Hedef sunucuda, Olay Kimliği 3030 için Uygulama günlüğünü inceleyin.

Hedef sunucu Uygulama günlüğü aynı klasör ve öğe için Olay Kimliği 3030 içeriyor mu?

Kaynak sunucu bu klasör için giden içerik iletileri oluşturmuyor; Ortak klasör veritabanı bağlandığında Olay Kimliği 3079

Kaynak sunucu bu klasör için giden içerik iletileri oluşturmuyor

Kaynak sunucu bu klasör için giden içerik iletileri oluşturmuyor. Sorun giderme konumuzu kaynak sunucuya odaklayacağız.

Ortak klasör veritabanı bağlandığında Olay Kimliği 3079

Kaynak sunucuda, Olay Kimliği 3079 için Uygulama günlüğünü inceleyin. Veritabanı bağlandığında olay kimliği 3079 oluşur ve şu metni içermelidir: EcReplStartup. Örneğin, Olay Kimliği 3079 aşağıdaki tabloya benzemelidir.

Olay Türü Bilgiler
Olay Kaynağı
MSExchangeIS Genel Deposu
Olay Kategorisi Çoğaltma Hataları
Olay Kodu 3079
İleti Beklenmeyen çoğaltma iş parçacığı hatası 0x3f0.
EcGetReplMsg
EcReplStartup
FReplAgent

Olay Kimliği 3079'ı görüyor musunuz ve veritabanı bağlandığında EcReplStartup içeriyor mu?

isinteg -fix -test ReplState komutunu çalıştırın; Olay Kimliği 3020

Isinteg –fix –test ReplState'i hedef sunucuda çalıştırma

Aşağıdaki adımlarla ReplState ayarını doğrulamak ve ayarlamak için Exchange sürümünüzü seçin:

Exchange Server 2007 ve Exchange Server 2010 için

  1. Exchange Yönetim Konsolu'ı başlatın.

  2. Ortak klasör veritabanındaki New-PublicFolderDatabaseRepairRequest çoğaltma sorunlarını algılamak ve düzeltmek için cmdlet'ini kullanın. İstek çalışırken ortak klasör veritabanındaki ortak klasörlere yine erişilebilir. Ancak, şu anda onarılmakta olan ortak klasör kullanılamıyor. Onarım isteğine başladıktan sonra, veritabanını çıkarmadığınız sürece durdurulamaz.

  3. Aşağıdaki cmdlet'i çalıştırın:

    New-PublicFolderDatabaseRepairRequest -Database -CorruptionType ReplState
Exchange Server 2003 için

  1. Hedef sunucuda, 24 Ocak 2013'te yayımlanan düzeltme KB925253 yükleyin.

  2. Düzeltme yüklendikten sonra, sunucudaki ortak klasör veritabanını kaldırın ve komut isteminde aşağıdaki komutu çalıştırın:

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

Olay Kimliği 3020

Kaynak sunucudaki ortak klasörde yeni bir öğe oluşturun ve ardından Olay Kimliği 3020 için Uygulama günlüğünü inceleyin.

Olay Kimliği 3020'yi görüyor ve test ettiğiniz klasörün adını ve oluşturduğunuz öğenin adını içeriyor mu?

  • Evet ise bkz . Olay Kimliği 3030.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunla ilgili desteğe başvurursanız, kaynak sunucunun giden hiyerarşi çoğaltma iletileri oluşturmadığını söyleyin. Veritabanı bağlandığında bir 3079 olayı vardır, ancak olay EcReplStartup içermez.

Öğenin hedef sunucudaki kaynak klasörde olduğunu doğrulayın

Hedef sunucuda, kaynak sunucuda oluşturduğunuz öğeyi arayın ve hedef klasörde olduğundan emin olun.

Öğeyi hedef sunucudaki klasörde görüyor musunuz?

İçerik doldurma sorunlarını giderme

İçerikte yapılan değişikliklerin çoğaltıldığını doğruladık. Ardından, içerik doldurma sorunlarını giderin.

Bunu yapmak için hedef sunucuda İçeriği Eşitle'yi çalıştırın. Bu, hedef sunucunun eksik verileri kaynak sunucudan istemesine neden olmalıdır.

Exchange Server 2007 ve Exchange Server 2010'da İçeriği Eşitle'yi çalıştırmak için

  1. Exchange Yönetim Konsolu'ı başlatın.

  2. Şu komutu çalıştırın:

    Update-PublicFolder -Server <DestinationServer>

  3. Hedef sunucuda Hiyerarşiyi Eşitle'yi çalıştırdıktan sonra, olay 3027 ve gelen durum isteği için kaynak sunucudaki Uygulama günlüğünü inceleyin.

Exchange Server 2003'te İçeriği Eşitle'yi çalıştırmak için

  1. Ortak Klasörler'i genişletin ve hedef klasörü seçin.
  2. Sağ bölmede Durum sekmesini seçin.
  3. Hedef sunucuya sağ tıklayın ve ardından İçeriği Eşitle'yi seçin.

Hedef sunucuda İçeriği Eşitle'yi çalıştırdıktan sonra, giden durum isteği için Olay Kimliği 3017 için Uygulama günlüğünü inceleyin.

Hedef sunucudaki Uygulama günlüğünde Olay Kimliği 3017 mi?

isinteg -fix -test ReplState komutunu çalıştırın (Olay Kimliği 3017 günlüğe kaydedilmediyse)

Aşağıdaki adımlarla ReplState ayarını doğrulamak ve ayarlamak için Exchange sürümünüzü seçin:

Exchange Server 2007 ve Exchange Server 2010 için

  1. Exchange Yönetim Konsolu'ı başlatın.

  2. Ortak klasör veritabanındaki New-PublicFolderDatabaseRepairRequest çoğaltma sorunlarını algılamak ve düzeltmek için cmdlet'ini kullanın. ortak klasör veritabanındaki ortak klasörlere istek çalışırken de erişilebilir, ancak şu anda onarılmakta olan ortak klasöre erişemezsiniz. Onarım isteğine başladıktan sonra, veritabanını çıkarmadığınız sürece durdurulamaz.

  3. Aşağıdaki cmdlet'i çalıştırın:

    New-PublicFolderDatabaseRepairRequest -Database -CorruptionType ReplState

Exchange Server 2003 için

  1. Hedef sunucuda düzeltme KB925253 yükleyin.

  2. Düzeltme yüklendikten sonra, sunucudaki ortak klasör veritabanını kaldırın ve komut isteminde aşağıdaki komutu çalıştırın:

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

  3. Isinteg işlemi tamamlandıktan sonra, kaynak sunucudaki ortak klasördeki çoğaltma listesini değiştirin. Bunu yapmak için, çoğaltmayı herhangi bir sunucuya ekleyin veya herhangi bir sunucudan kaldırın. Uygula'yı seçin, az önce yaptığınız değişikliği tersine çevirin ve sonra yeniden Uygula'yı seçin.

  4. Aynı klasör için hedef sunucuda İçeriği Eşitle'yi yeniden çalıştırın.

  5. Giden durum isteği için Olay Kimliği 3017 için Uygulama günlüğünü inceleyin.

Olay Kimliği 3017, hedef sunucudaki Uygulama günlüğünde mi?

  • Evet ise bkz . Olay Kimliği 3027.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

Olay Kimliği 3027

Kaynak sunucuda, tür 0x20 olan Olay Kimliği 3027 için Uygulama günlüğünü inceleyin.

Olay Kimliği 3027'yi görüyor musunuz ve kaynak sunucuda tür 0x20 var mı?

Kaynak sunucuda Olay Kimliği 3017

Kaynak sunucudaki Uygulama günlüğünde, Olay Kimliği 3027'nin hemen öncesinde, aynı klasör için tür 0x10 olan Olay Kimliği 3017'yi bulun.

Olay Kimliği 3017'yi görüyor musunuz ve aynı klasör için tür 0x10 var mı?

Sunucuların farklı yaş sınırları var mı?

Genellikle, kaynak sunucu bir durum yanıtı oluşturmazsa, kaynak sunucuda diğer sunucunun da sahip olmadığı veriler olmadığı anlamına gelir.

Sunucuların aynı içeriğe sahip olmadan eşitlenmesi durumundan biri, farklı yaş sınırlarına sahip olmalarıdır. Hedef sunucunun söz konusu öğelerin süresi zaten dolduysa, öğeleri yeniden doldurmaz.

Sunucuların farklı yaş sınırları olmadığından emin olun. Çeşitli sınır türleri vardır:

Depolama Kotaları

Veritabanı kotası varsayılanlarını kullanma

Ortak klasörün bulunduğu ortak klasör veritabanı kota sınırlarını kullanmak için bu onay kutusunu seçin. Varsayılanları seçmezseniz, (KB), Gönderiyi (KB) yasakla ve En fazla öğe boyutu (KB) onay kutuları kullanılabilir duruma gelir.

(KB) konumunda sorun uyarısı

Ortak klasör sahiplerini ortak klasörün depolama sınırına yaklaştığı konusunda otomatik olarak uyarmak için bu onay kutusunu seçin. Bu sınırı belirtmek için, onay kutusunu seçin ve sonra göndermeyi yasaklamak istediğiniz ortak klasörün boyutunu kilobayt (KB) olarak belirtin. 0 KB ile 2.147.483.647 KB (2,1 terabayt) arasında bir değer girebilirsiniz.

Gönderiyi yasakla ( KB)

Klasörün boyutu belirtilen sınıra ulaştıktan sonra ortak klasöre göndermeyi önlemek için bu onay kutusunu seçin. Bu sınırı belirtmek için onay kutusunu seçin ve sonra postayı yasaklamak istediğiniz ortak klasörün boyutunu KB olarak belirtin. 0 KB ile 2.147.483.647 KB (2,1 terabayt) arasında bir değer girebilirsiniz.

En büyük öğe boyutu (KB)

Kullanıcıların ortak klasöre gönderebileceği en büyük öğe boyutunu sınırlamak için bu onay kutusunu seçin. Boyutu belirtmek için onay kutusunu seçin ve sonra kullanıcıların ortak klasörlere gönderebileceği en büyük öğe boyutunu KB olarak belirtin. 0 KB ile 2.097.151 KB arasında bir değer girebilirsiniz.

Silinmiş Öğe Saklama

Veritabanı bekletme varsayılanlarını kullanma

Bu ortak klasörün bulunduğu sunucuda ortak klasör veritabanı öğesi saklama sınırlarını kullanmak için bu onay kutusunu seçin. Bu onay kutusunu işaretlemezseniz, Silinen öğeleri (gün) boyunca koru onay kutusu kullanılabilir duruma gelir.

Silinen öğeleri (gün) saklama

Silinen öğelerin ortak klasörde tutulacak gün sayısını ayarlamak için bu onay kutusunu seçin. 0 ile 24.855 gün arasında bir değer girebilirsiniz.

Yaş Sınırları

Veritabanı yaşı varsayılanlarını kullanma

Bu ortak klasörün bulunduğu sunucunun ortak klasör veritabanı yaş sınırlarını kullanmak için bu onay kutusunu seçin. Bu onay kutusunu seçmezseniz, Çoğaltmalar için yaş sınırı (gün) onay kutusu kullanılabilir duruma gelir.

Çoğaltmalar için yaş sınırı (gün)

Ortak klasörün yaşını sınırlamak için bu onay kutusunu seçin. Gün olarak yaş sınırını belirtmek için ilgili metin kutusunu kullanın. Yaş sınırı aşıldığında bu ortak klasörün çoğaltmaları otomatik olarak silinir. 0 ile 24.855 gün arasında bir değer girebilirsiniz.

Sunucuların yaş sınırları farklı mı?

  • Yanıt evet ise, içerik farkı tasarım gereğidir. Sorun gidermeye devam etmek zorunda değilsiniz. Öğeleri kopyalayarak yeni bir klasörde yeni öğeler haline gelmeleri için sorunu çözebilirsiniz.
  • Yanıt hayır ise bilinmeyen bir hata oluştu.

Hedef sunucuda tür 0x10 olan Olay Kimliği 3027

Hedef sunucuda, tür 0x10 olan Olay Kimliği 3027 olayının Uygulama günlüğünü inceleyin.

Olay Kimliği 3027'yi görüyor ve tür 0x10 var mı?

  • Evet ise bkz . Backfill'e odaklanma.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunla ilgili desteğe başvurursanız, kaynak sunucunun giden hiyerarşi çoğaltma iletileri oluşturmadığını söyleyin. Veritabanı bağlandığında bir 3079 olayı vardır, ancak olay EcReplStartup içermez.

Arka doldurmaya odaklanma

Bu noktada, hedef sunucu bazı verilerin eksik olduğunu hesaplamıştır. Bu nedenle, geri doldurmaya odaklanın.

Hedef sunucuda, hedef klasörde İçeriği Eşitle'yi yeniden çalıştırın. İçeriği Eşitle'yi çalıştırdıktan sonra, Olay Kimliği 3016 Uygulama günlüğüne kaydedilir. Olay Kimliği 3016, klasörün adını içeren 0x8 ileti türüne sahiptir.

Hedef sunucuda Olay Kimliği 3016'yı görüyor musunuz ve klasörün adını içeren ileti türü 0x8 var mı?

Kaynak sunucuda Olay Kimliği 3026

Hedef sunucudaki Olay Kimliği 3016'ya yanıt olarak, kaynak sunucudaki Uygulama günlüğünde Olay Kimliği 3026'yı görmeniz gerekir.

Kaynak sunucuda Olay Kimliği 3026'yı görüyor musunuz?

Kaynak sunucuda Olay Kimliği 3021

Kaynak sunucudaki Uygulama günlüğünde, Olay Kimliği 3026'dan hemen sonra, klasör için ileti türü 0x80000004 içeren bir veya daha fazla Olay Kimliği 3021 olayı görmeniz gerekir.

Klasör için ileti türü 0x80000004 içeren en az bir Olay Kimliği 3021 görüyor musunuz?

  • Evet ise, bkz . Olay Kimliği 3021 sayısını Olay Kimliği 3031 ile karşılaştırma.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

Olay Kimliği 3021 sayısını Olay Kimliği 3031 sayısıyla karşılaştırın

Kaynak sunucudaki Uygulama günlüğünde bulunan Olay Kimliği 3021 olaylarının sayısını sayın. Ardından, klasör için ileti türü 0x80000004 olan ve hedef sunucudaki Uygulama günlüğünde bulunan Olay Kimliği 3031 olaylarının sayısını sayın.

Sunucular arasında eşit sayıda Olay Kimliği 3021 olayı ve Olay Kimliği 3031 olayı var mı?

Hedef sunucudaki klasördeki içeriği bulma

Hedef sunucuda, kaynak sunucudan hedef sunucudaki aynı klasöre eşitlenmiş içeriği arayın.

İçeriği hedef sunucuda aynı klasörde mi buldunuz?

  • Evet ise tebrikler! Exchange Server 2003 için Ortak Klasör Çoğaltma sorununuz çözüldü.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

İleti farklı bir kaynak sunucuya gönderilmiş olabilir

İletinin beklenen kaynak sunucuya gönderildiğini doğrulamak için Olay Kimliği 3016'yı inceleyin. Hedef sunucuda, iletiyi hangi kaynak sunucunun almış olması gerektiğini belirlemek için Olay Kimliği 3016'yı inceleyin. İletiyi farklı bir kaynak sunucu aldıysa, bu sunucuyu yeni kaynak sunucu olarak kullanın ve ardından Olay Kimliği 3016 için yeni kaynak sunucuda Uygulama günlüğünü inceleyin.

Olay Türü Bilgiler
Olay Kaynağı MSExchangeIS Genel Deposu
Olay Kategorisi Giden İletileri Çoğaltma
Olay Kodu 3016
İleti Giden ileti türü <değeri>
İleti Kimliği: <kimlik>
Klasör: <klasör adı>
Veritabanı "<adı>".
CNSET: <değer>
CNSET(FAI): <değer>
Sunucu: <sunucu adı>

Beklenen kaynak sunucu Olay Kimliği 3016'da tanımlanıyor mu?

  • Evet ise, kaynak sunucuda Olay Kimliği 3021'e bakın.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

Bekleyen dolum sınırı

Varsayılan olarak, Ortak Klasörler deposu aynı anda en fazla 50 bekleyen geri doldurma isteği tutabilir. Bu, Bekleyen Geri Doldurma Sınırı (OBL) olarak bilinir. Depo dizisinde 50 geri doldurma isteği olduğunda, bu istekler karşılanana kadar tekrar tekrar yapılır; en az bir istek tamamlanana kadar başka yeni istek yapılamaz.

Bir geri doldurma isteği her karşılandığında, OBL'de bir açma gerçekleşir ve yeni bir veri kümesi istenebilir. Ancak, 50 isteğin tümü sorunlarla karşılaşırsa ve karşılanamazsa, yeni bir açılış gerçekleşmez, yeni istek yapılamaz ve çoğaltma devam ettiremez.

Sorunun nedeninin Bekleyen Geri Doldurma Sınırı olup olmadığını belirlemek için, hedef sunucuda OBL sınırını bir (1) artırın ve ardından Olay Kimliği 3016 örneği için Uygulama günlüğünü en az beş dakika boyunca inceleyin.

Hedef sunucuda OBL sınırını bir (1) artırmak için

  1. Çalıştırmayı Başlat'ı>seçerek Kayıt Defteri Düzenleyicisi'ni açın, regedit yazın ve ardından Tamam'ı seçin.

  2. Aşağıdaki alt anahtarı genişletin:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<Server_Name>\Public-<GUID>

  3. Genel GUID'ye sağ tıklayın, Yeni'nin üzerine gelin ve DWORD Değeri'ni seçin.<>

  4. Çoğaltma Bekleyen Geri Doldurma Sınırı yazın ve enter tuşuna basarak yeni -alt anahtarı adlandırın.

  5. Çoğaltma Bekleyen Geri Doldurma Sınırı'ne sağ tıklayın ve değiştir'i seçin.

  6. Değer verileri kutusuna 51 yazın ve Tamam'ı seçin.

  7. Kayıt Defteri Düzenleyicisi'ni kapatın.

  8. Exchange Server 2003'te Microsoft Exchange Information Store hizmetini yeniden başlatın. Bunu yapmak için:

    • Başlat'ı seçin, Yönetim Araçları'nın üzerine gelin ve hizmetler'i seçin.
    • Hizmetler listesinde Microsoft Exchange Information Store'u ve ardından Yeniden Başlat'ı seçin.

Olay Kimliği 3016 başka bir klasör için kaydedilmişse, bunun yerine bu klasörü kullanarak sorun giderin.

Başka bir klasör için Olay Kimliği 3016'yı görüyor musunuz?

  • Evet ise bkz . İçerik doldurma sorunlarını giderme.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

Olay Kimliği 3020'de tanımlanan iletiyi izleme

Kaynak sunucuda, olay kimliği 3020'de tanımlanan iletiyi izlemek için ileti izlemeyi kullanın.

İleti izleme, iletinin hedef sunucuya teslim edildiğine işaret ediyor mu?

XEXCH50 komutunun sorunlarını giderme

XEXCH50 komutunun sorunlarını gidermek için MSExchangeTransport hizmetinin hedef sunucusunda günlüğe kaydetmeyi artırın ve SMTP protokol düzeyini orta olarak ayarlayın.

SMTP protokolü düzeyi ayarını doğrulamak ve ayarlamak için Exchange sürümünüzü seçerek adımları denetleyin:

Exchange Server 2007 ve Exchange Server 2010 için

  1. Exchange Yönetim Konsolu'ı başlatın.
  2. SMTP için Set-EventLogLevel -Identity "MSExchangeTransport\SmtpReceive" -Level 'Medium' olay günlüğünü açmak için ve Set-EventLogLevel -Identity "MSExchangeTransport\SmtpSend" -Level 'Medium' cmdlet'lerini kullanın.
  3. Resume-PublicFolderReplication Tüm kuruluş için ortak klasör çoğaltmasını başlatmak için cmdlet'ini kullanın.

Exchange Server 2003 için

Ardından, aşağıdakine benzer olaylar için Olay Görüntüleyicisi Uygulama günlüğünü inceleyin:

Olay Türü Hata
Olay Kaynağı MSExchangeTransport
Olay Kategorisi SMTP Protokolü
Olay Kodu 7004
Tarih: Tarih
Saat Saat
User Kullanılamaz
Bilgisayar Computer_Name
Açıklama Bu, 1. sanal sunucu kimliği, bağlantı #29 için bir SMTP protokolü hata günlüğüdür. Uzak ana bilgisayar E2k3server1.contoso.com "xexch50" SMTP komutuna "504 Önce kimlik doğrulaması gerekiyor" yanıtını verdi. "Gönderilen tam komut "XEXCH50 2336 3" idi. Bu büyük olasılıkla bağlantının başarısız olmasına neden olur.
Olayı türü: Hata
Olay Kaynağı MSExchangeTransport
Olay Kategorisi SMTP Protokolü
Olay Kodu 7010
Tarih Tarih
Saat Saat
User Kullanılamaz
Bilgisayar: Computer_Name
Açıklama: Bu, 1. sanal sunucu kimliği, bağlantı #30 için bir SMTP protokol günlüğüdür. "6.5.2.4" konumundaki istemci bir "xexch50" komutu gönderdi ve SMTP sunucusu "Önce kimlik doğrulaması gerekiyor" yanıtını verdi. Gönderilen tam komut "xexch50 1092 2" idi. Bu büyük olasılıkla bağlantının başarısız olmasına neden olur. Bu olaylar, XEXCH50 protokol havuzu tetiklendiğini, ancak blob değişiminin olaylarda listelenen sunucular arasında başarısız olduğunu gösterir.

Hedef sunucuda Olay Kimliği 7004 ve Olay Kimliği 7010'ı görüyor musunuz?

isinteg -fix -test ReplState komutunu çalıştırın (Event IE 7004 ve 7010'u görmüyorsanız)

Aşağıdaki adımlarla ReplState ayarını doğrulamak ve ayarlamak için Exchange sürümünüzü seçin:

Exchange Server 2007 ve Exchange Server 2010 için

  1. Exchange Yönetim Konsolu'ı başlatın.

  2. Ortak klasör veritabanındaki New-PublicFolderDatabaseRepairRequest çoğaltma sorunlarını algılamak ve düzeltmek için cmdlet'ini kullanın. ortak klasör veritabanındaki ortak klasörlere istek çalışırken de erişilebilir, ancak şu anda onarılmakta olan ortak klasöre erişemezsiniz. Onarım isteğine başladıktan sonra, veritabanını çıkarmadığınız sürece durdurulamaz.

  3. Aşağıdaki cmdlet'i çalıştırın:

    New-PublicFolderDatabaseRepairRequest -Database -CorruptionType ReplState

Exchange Server 2003 için

  1. Hedef sunucuda düzeltme KB925253 yükleyin.

  2. Düzeltme yüklendikten sonra, sunucudaki ortak klasör veritabanını kaldırın ve komut isteminde aşağıdaki komutu çalıştırın:

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

  3. isinteg işlemi tamamlandıktan sonra:

    1. Hedef sunucudaki ortak klasördeki çoğaltma listesini değiştirin. Bunu yapmak için çoğaltmayı herhangi bir sunucuya ekleyin veya sunucudan kaldırın. Uygula'yı seçin, az önce yaptığınız değişikliği tersine çevirin ve sonra yeniden Uygula'yı seçin.
    2. Kaynak sunucuda yeni bir öğe oluşturun.
    3. Olay Kimliği 3020 için kaynak sunucuda Uygulama günlüğünü inceleyin.
    4. Olay Kimliği 3030 için hedef sunucuda Uygulama günlüğünü inceleyin.

Hedef sunucudaki Uygulama günlüğünde Olay Kimliği 3030'ı görüyor musunuz?

  • Evet ise tebrikler! Exchange Server 2003 için Ortak Klasör Çoğaltma sorununuz çözüldü.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunla ilgili desteğe başvurursanız, kaynak sunucunun giden hiyerarşi çoğaltma iletileri oluşturmadığını söyleyin. Veritabanı bağlandığında bir 3079 olayı vardır, ancak olay EcReplStartup içermez.

Performans İzleyicisi Çoğaltma Alma Kuyruğu Boyutu

Ortak klasör çoğaltma iletileri SMTP tarafından alınır, kategorilere ayrılmıştır ve yerel SMTP kuyruğuna iletilir. İletiler daha sonra Ortak Klasör deposuna gönderilir. İletiler Ortak Klasör deposuna gönderildikten sonra Çoğaltma Alma Kuyruğuna konur. Çoğaltma Alma Kuyruğundaki iletiler daha sonra işlenir ve değişiklikler uygun ortak klasörde gerçekleştirilir. Çoğaltma Alma Sırası Boyutu performans sayacı, işlenmeyi bekleyen ortak klasör çoğaltma iletilerinin sayısını gösterir.

Çoğaltma kuyruğu ne kadar büyük olursa, klasörlerdeki içerik o kadar fazla eşitlenebilir. Çoğaltma kuyrukları büyüdükçe, çoğaltma kuyruğundaki iletiler işlendiğinde kaynaklarda artan bir yük olur. Ayrıca, artan çoğaltma kuyrukları sunucudaki ortak klasör içeriğinin güncel olmadığını gösterir.

Çoğaltma Alma Kuyruğunda büyümenin beklendiği ve planlanabileceği iki örnekte herhangi bir eylem gerekmez:

  • Yeni tanıtılan bir ortak klasör sunucusunda, Çoğaltma Alma Kuyruğundaki büyüme beklenen ilk yedekleme çoğaltması nedeniyle oluşabilir.
  • Exchange topolojisinde site birleştirme veya diğer önemli değişiklikler meydana geliyorsa, içerik taşındıktan sonra çok fazla çoğaltma olması beklenir.

Ortak klasör çoğaltmalarının toplu olarak değiştirilmediği mevcut, kararlı durum sunucuları için bu hata şunları gösterebilir:

  • Disk, CPU, ağ veya bellek gibi sunucu kaynağı performans sorunları. Sunucuda bir kaynak sorunu varsa, Store.exe işlemi çoğaltma iletilerini yeterince hızlı işleyemeyecek ve bir kuyruk büyüyecek.
  • Ortak klasör çoğaltma aralığı, bir sonraki çoğaltma döngüsü başlamadan önce çoğaltmanın tamamlanması için çok kısa.

Bu hatayı düzeltmek için:

  • Sonraki çoğaltma döngüsü başlamadan önce çoğaltmanın tamamlandığını gösterene kadar MSExchangeIS Genel\Çoğaltma Alma Kuyruğu Boyutunu izleyin.
  • Gerekli çoğaltma trafiğinin hacmini azaltmak için Exchange kuruluşundaki toplam çoğaltma sayısını azaltmayı göz önünde bulundurun.

Yüksek Kuyruğunuz varsa bkz . Çoğaltmayı duraklatma.

Düşük Kuyruğunuz varsa bkz . Olası ReplState sorunu.

Çoğaltmayı duraklatma

Ortak klasörlerin çoğaltmasını duraklatın ve kuyrukların boşaltılıp destek çağrısı yapmasına izin verin.

Çoğaltmayı duraklatmak için

  1. Exchange Yönetim Konsolu'ı başlatın.
  2. Suspend-PublicFolderReplication Tüm kuruluş için ortak klasör çoğaltmasını durdurmak için cmdlet'ini kullanın.
  3. komutunu çalıştırarak Get-TransportServer | Get-QueueAktarım Kuyruklarını izleyin. Kuyruk azaltıldıktan sonra çoğaltmayı sürdürebilirsiniz.
  4. Resume-PublicFolderReplication Tüm kuruluş için ortak klasör çoğaltmasını yeniden başlatmak için cmdlet'ini kullanın.

Ne yazık ki, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorun hakkında desteğe başvuruyorsanız, çoğaltmanın Duraklatıldığını ve kuyrukların azaltılmasını beklediğinizi söyleyin.

Klasör kimliği (FID) aranıyor (Yalıtın mı?)

Olay Kimliği 3028 olayı FID'yi gösteriyor ancak klasörün adını göstermiyor mu?

  • Evet ise bkz . Silme işlemi nedeniyle kaldırılma taşı.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

Silme nedeniyle kaldırıldı (Olay Kimliği 3028 olayı FID'yi gösterir)

Bu, çoğaltılmamış önceki silme işleminden dolayı klasörün bir silinmiş öğe olduğunu gösterir. Kaynak sunucuya dönün ve klasörü kopyalayarak aynı içeriğe sahip yeni bir klasör oluşturun ve yeniden başlayın.

Bu bilgiler yararlı mı?

  • Evet ise, bkz . Yinelenen hesapları kaldırma.
  • Hayır, üzgünüz, bu kılavuzla tanımlanamayan sorunları çözemiyoruz. Bu sorunu çözme konusunda daha fazla yardım için Microsoft Exchange Server desteğine başvurun ve veritabanı bağlandığında bir 3079 olayının günlüğe kaydedildiğini söyleyin.

Performans izleyicisi gönderim için kuyruğa alınmış çok sayıda ileti gösteriyor mu?

Performans İzleyicisi'i açın.

Sayaç MSExchangeIS Genel\Çoğaltma Alma Kuyruğu ekleyin ve kuyruğun boyutunu izleyin.

Performans izleyicisi hakkında daha fazla bilgi edinmeniz gerekiyorsa buraya gidebilirsiniz: Başlarken Kılavuzu'nu Performans İzleyicisi.

Performans izleyicisi gönderilmek üzere kuyruğa alınmış çok sayıda ileti gösteriyor mu?

  • Evet ise bkz . Hizmetleri denetleme.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorun hakkında desteğe başvuruyorsanız, sunucunun giden hiyerarşi iletileri oluşturduğunu, ancak bu iletilerin ileti izlemede görünmediğini ve hiçbir şeyin gönderilmek üzere kuyruğa alınmadığını söyleyin.

Hizmetleri denetleme

  1. Başlat>Çalıştır'ı seçin.
  2. Kutuya services.msc yazın.
  3. MSExchangeTransport'u bulun ve başlatıldığından emin olun

PowerShell'iniz varsa açın ve aşağıdaki cmdlet'i çalıştırın:

Get-Service MSExchangeTransport

Aktarım Hizmeti Çalışıyor mu?

  • Evet ise bkz . Ortak Klasör Çoğaltma sorunlarını giderme.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorun hakkında desteğe başvuruyorsanız, sunucunun giden hiyerarşi iletileri oluşturduğunu, ancak bu iletilerin ileti izlemede görünmediğini ve hiçbir şeyin gönderilmek üzere kuyruğa alınmadığını söyleyin.

3030 olayı öğenin ileti kimliğini (MID) gösteriyor ancak konuyu göstermiyor mu?

3030 olayı öğenin MID'sini gösteriyor ancak konuyu göstermiyor mu?

  • Evet ise bkz . Tombstone.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorun hakkında desteğe başvurursanız, kaynak sunucunun giden hiyerarşi çoğaltma iletileri oluşturmadığını ve veritabanı bağlandığında 3079 olayı olmadığını söyleyin.

Mezar taşı

Bu genellikle, çoğaltılmayan bir ileti silme işlemi nedeniyle kaldırılmış bir taşın sonucudur. Klasör içindeki iletileri kopyalayarak yeni iletiler oluşturabilir veya klasörün tamamını kopyalayabilirsiniz.

Bu bilgiler yararlı mı?

  • Evet ise, bkz . Yinelenen hesapları kaldırma.
  • Hayır ise, üzgünüz, bu kılavuzla tanımlanamayan sorunları çözemiyoruz. Bu sorunu çözme konusunda daha fazla yardım için Microsoft Exchange Server desteğine başvurun ve veritabanı bağlandığında bir 3079 olayının günlüğe kaydedildiğini söyleyin.

Olay Kimliği 3027'yi izleme

Ne kadar ilerlediğini görmek için 3027'yi izleyin. Kaynak sunucudan ayrılmadıysa, giden iletilerin genel depoda takılıp takılmadığını görmek için MSExchangeIS Public altındaki Gönderim için Kuyruğa Alınan İletiler performans sayacını denetleyin.

Bu bilgiler yararlı mı?

  • Evet ise, bkz . Yinelenen hesapları kaldırma.
  • Hayır ise, üzgünüz, bu kılavuzla tanımlanamayan sorunları çözemiyoruz. Bu sorunu çözme konusunda daha fazla yardım için Microsoft Exchange Server desteğine başvurun ve veritabanı bağlandığında bir 3079 olayının günlüğe kaydedildiğini söyleyin.

Olası ReplState sorunu

Bu sorun XEXCH50 bir sorun veya ReplState sorunu olabilir. Devam etmeden önce SMTP günlüğünün etkinleştirildiğini doğrulayalım.

Aşağıdaki adımlarla ReplState ayarını doğrulamak ve ayarlamak için Exchange sürümünüzü seçin:

Exchange Server 2007 ve Exchange Server 2010 için

  1. Exchange Yönetim Konsolu'ı başlatın.
  2. SMTP'de Set-EventLogLevel -Identity "MSExchangeTransport\SmtpReceive" -Level 'Medium' olay günlüğünü açmak için ve Set-EventLogLevel -Identity "MSExchangeTransport\SmtpSend" -Level 'Medium' cmdlet'lerini kullanın.
  3. Resume-PublicFolderReplication Tüm kuruluş için ortak klasör çoğaltmasını başlatmak için cmdlet'ini kullanın.

Exchange Server 2003 için

  1. Exchange Sistem Yöneticisi başlayın.
  2. Sunucular'ı genişletin, sunucu adı Your_ sağ tıklayın ve özellikler'i seçin.
  3. Tanılama Günlüğü sekmesini ve ardından Hizmetler'in altında MSExchangeTransport'u seçin.
  4. Kategoriler'in altında SMTP'yi seçin.
  5. Günlük Düzeyi'nin altında Orta'yı seçin.

Exchange sürümünüz nedir?

İletilerden biri veya daha fazlası aktarımda kayboldu

Hedef sunucudaki 3031 olay sayısı kaynak sunucudaki 3021 olay sayısından azsa, iletilerden biri veya daha fazlası aktarımda kayboldu. İleti kaybını gidermek için çoğaltılmayan iletilerin ileti kimliğini belirleyin.

Bunu yapmak için kaynak sunucudaki Uygulama günlüğünü inceleyin. Ardından iletileri izlemek ve sorunu gidermek için ileti izlemeyi kullanın.

Bu iletinin yolunda herhangi bir Exchange Server 2007 veya 2010 sunucusu var mı?

Bu, sorunu çözdü mü?

Sorununuz çözüldü mü?

  • Evet ise tebrikler! Exchange Server 2003 için Ortak Klasör Çoğaltma sorununuz çözüldü.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.

Yolda Exchange Server 2007 ve Exchange Server 2010

Exchange Server 2007 veya Exchange Server 2010'da kayıp içerik geri doldurma yanıtının en yaygın nedeni bir depo sürücüsü hatasıdır. Örneğin, bir Exchange Server 2007 sunucusuna bir geri doldurma yanıtı gönderilir, ancak 2007 tarafındaki uygulama günlüğüne bakarsanız, gelen çoğaltma olayını hiçbir zaman görmezsiniz. İleti izleme, çoğaltma iletisinin hub aktarım sunucusuna geldiğini ve ardından depo sürücüsünde başarısız olduğunu gösterir.

Sorun gidermenin ilk adımı iletiyi izlemek ve nerede başarısız olduğunu görmektir.

Genellikle, hub aktarım sunucusu söz konusu içerikle ilgili sorunu açıklayan bir olay 1020'yi günlüğe kaydeder. İletiyi takip ettikten ve hangi hub aktarım sunucusunda başarısız olduğunu belirledikten sonra, bu hub aktarım sunucusunda kaynak MSExchange Store Sürücüsü ile 1020 olayını denetleyin.

Bu hub aktarım sunucusunda kaynak MSExchange Store Sürücüsüne sahip bir 1020 olayı görüyor musunuz?

  • Evet ise, 1020 olayını görürsünüz ve Active Directory kullanıcısı bulunamadı hatasını içerirsiniz. Ortak klasör içeriğini Exchange Server 2010'a çoğaltma başarısız oldu başlığında verilen yönergeleri izleyin. Bu sorun hakkında desteğe başvurursanız, onlara Boş Sunucular Kapsayıcısı olduğunu söyleyin.

    Bu bilgiler yararlı mı?

    • Evet ise, bkz . Yinelenen hesapları kaldırma.
    • Hayır, üzgünüz, bu kılavuzla tanımlanamayan sorunları çözemiyoruz. Bu sorunu çözme konusunda daha fazla yardım için Microsoft Exchange Server desteğine başvurun ve veritabanı bağlandığında bir 3079 olayının günlüğe kaydedildiğini söyleyin.

  • Evet ise, 1020 olayını görürsünüz ve ileti içeriği bozuldu hatasını içerirsiniz. Yoldaki Exchange Server 2007 ve Exchange Server 2010 (İleti içeriği bozuldu) bölümüne bakın.

  • Evet ise, 1020 olayını ancak yukarıdaki hata iletisinin hiçbirini görmüyorsanız, yolda Exchange Server 2007 ve Exchange Server 2010'a bakın (bkz. 1020 olayı ama yukarıdaki hata iletisinden hiçbiri).

  • Hayır ise kaynak MSExchange Store Sürücüsü ile 1020 olayını görmüyorsanız, ne yazık ki bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorun hakkında desteğe başvuruyorsanız, sunucunun giden hiyerarşi iletileri oluşturduğunu, ancak bu iletilerin ileti izlemede görünmediğini ve hiçbir şeyin gönderilmek üzere kuyruğa alınmadığını söyleyin.

Yolda Exchange Server 2007 ve Exchange Server 2010 (İleti içeriği bozuldu)

Bu ileti genellikle bozuk TNEF nedeniyledir. Bu karma bir ortamsa, yeni bozuk iletileri önlemek için Exchange 2013 CU6'yı uygulayın ve eskilerini silin. Bozuk öğeleri tanımlamak için aşağıdaki adımlarla devam edin.

Hangi öğelerin bozuk olduğunu belirlemek için:

  1. Çoğaltma iletisi boyutunu kaynak sunucuda 1k olarak küçültün.
  2. Hedefte, İçeriği Eşitle veya Update-PublicFolder ile başka bir geri doldurma isteğine zorla.
  3. Artık kaynak sunucudaki klasörde öğe başına bir geri doldurma yanıtı (olay 3021) görürsünüz. Klasörde çok sayıda öğe varsa, uygulama günlüğü geri doldurma yanıtları ile doldurulabilir. 3021 etkinliği sakinleşdikten sonra, kaynak sunucudaki uygulama günlüğünü temizleyin ve başka bir geri doldurma isteğine zorlayın. Geri doldurmaların son turunda tüm iyi öğeler zaten çoğaltıldığından, yeni olay 3021'de görmeniz gereken tek yeni öğeler bozuk öğeler olmalıdır.

Artık kaynak sunucudaki uygulama günlüğündeki bozuk her öğe için bir geri doldurma yanıtı (3021) ve hub aktarım sunucusundaki uygulama günlüğündeki bozuk her öğe için bir 1020 olayına sahip olmanız gerekir. Artık hangi öğelerin bozuk olduğunu bildiğinizden (3021 olaylarındaki öğe konularını okuyabildiğiniz için), bu öğeleri silebilir veya düzeltmeyi deneyebilirsiniz.

Daha fazla bilgi için bkz . Exchange Server 2003'ten Exchange Server 2007 veya 2010'a Ortak Klasör Çoğaltma Hatalarını Düzeltme.

Bu sorun çözüldü mü?

Yolda Exchange Server 2007 ve Exchange Server 2010 (bkz. 1020 olayı ama yukarıdaki hata iletisinden hiçbiri)

Bu başka bir bozuk öğe türüdür. Hangi öğelerin bozuk olduğunu belirlemek için:

  1. Çoğaltma iletisi boyutunu kaynak sunucuda 1k olarak küçültün.
  2. Hedefte, içeriği eşitle veya Ortak Klasörü Güncelleştir ile başka bir geri doldurma isteğine zorla.
  3. Artık kaynak sunucudaki klasörde öğe başına bir geri doldurma yanıtı (olay 3021) görürsünüz. Klasörde çok sayıda öğe varsa, uygulama günlüğü geri doldurma yanıtları ile doldurulabilir. 3021 etkinliği sakinleşdikten sonra, kaynak sunucudaki uygulama günlüğünü temizleyin ve başka bir geri doldurma isteğine zorlayın. Geri doldurmaların son turunda tüm iyi öğeler zaten çoğaltıldığından, yeni olay 3021'de görmeniz gereken tek yeni öğeler bozuk öğeler olmalıdır.

Artık kaynak sunucudaki uygulama günlüğündeki bozuk her öğe için bir geri doldurma yanıtı (3021 olayı) ve hub aktarım sunucusundaki uygulama günlüğündeki bozuk her öğe için bir 1020 olayına sahip olmanız gerekir. Artık hangi öğelerin bozuk olduğunu bildiğinizden (3021 olaylarındaki öğe konularını okuyabildiğiniz için), bunları silebilir veya düzeltmeyi deneyebilirsiniz.

Daha fazla bilgi için bkz . Exchange Server 2003'ten Exchange Server 2007 veya 2010'a Ortak Klasör Çoğaltma Hatalarını Düzeltme.

Sorununuz çözüldü mü?

Yinelenen hesapları kaldırma

Olayda belirtilen yinelenen hesapları kaldırın veya kullanıcılardan birini silin; böylece SID, DS'deki tek bir kullanıcı için çözümlenebilir.

Bu bilgiler yararlı mı?

  • Evet ise tebrikler! Exchange Server için Ortak Klasör Çoğaltma sorununuz çözüldü.
  • Hayır, üzgünüz, bu kılavuzu kullanarak tanımlanamayan bir sorunu çözemiyoruz. Bu sorunu çözmek için daha fazla yardım için Microsoft Exchange Server desteğine başvurun.