Entra Connect Sync 30 Eylül'de Duruyor: Yükseltme Rehberi (2026)

Özet (TL;DR): Microsoft, şirket içi kullanıcı dizinini buluta taşıyan köprü yazılımı Entra Connect Sync için kesin bir tarih verdi: 30 Eylül 2026. Bu tarihte sürümü 2.5.79.0'ın altında olan tüm sunucularda senkronizasyon hizmetleri çalışmayı durduracak. Üstelik minimum sürüme çıkmak da yetmiyor; 2.5.79.0'ın kendi destek bitişi 23 Ekim 2026. Doğru hamle, en güncel sürüme (2.6.84.0) çıkmak ve ayrı bir proje olarak Cloud Sync geçişini planlamaktır. Bu rehber sürüm kontrolünden yükseltme yöntemine, Cloud Sync geçiş adımlarından Türkiye'ye özgü kontrollere kadar uygulanabilir bir plan sunuyor.

Xen Bilişim ekibi · Microsoft Bulut Çözüm Ortağı (CSP Direct Partner, 2016'dan bu yana) · MS-100 / MS-102 / AZ-104 sertifikalı danışmanlar

30 Eylül 2026'da tam olarak ne duruyor?

Önce terimleri sadeleştirelim. Active Directory, şirketinizin kendi sunucusunda duran kullanıcı ve parola dizinidir — personelin bilgisayara giriş yaptığı hesapların tutulduğu yer. Microsoft Entra ID ise bunun bulut karşılığıdır; Microsoft 365, Teams ve Azure'a girişler buradan yapılır. Entra Connect Sync (eski adıyla Azure AD Connect), bu ikisi arasında çalışan köprü yazılımıdır: şirket içinde açtığınız bir hesabı buluta kopyalar, parola değişikliğini taşır, işten ayrılan personelin kapatılan hesabını bulutta da kapatır.

Microsoft, bu köprünün arka plan servislerinde bir güvenlik sertleştirmesi yaptı ve eski istemcileri kesme tarihini ilan etti. Resmi ifade net: 2.5.79.0 sürümünün altındaki sunucularda 30 Eylül 2026 itibarıyla tüm senkronizasyon hizmetleri başarısız olacak ve yükseltme yapılana kadar başarısız olmaya devam edecek (kaynak: Microsoft Learn — Entra Connect otomatik yükseltme güvenlik sertleştirmesi, 2026-07 itibarıyla).

Bunun kurum içindeki karşılığı şudur:

• Yeni personel Microsoft 365'e giremez. Şirket içinde hesabı açılır, ama buluta hiç ulaşmaz; posta kutusu oluşmaz.
• Parola değişiklikleri buluta yansımaz. Kullanıcı şirket içinde parolasını değiştirir, Microsoft 365'te eski parolayla oturum açmaya devam eder.
• İşten ayrılan personelin erişimi kapanmaz. Bu, güvenlik ve KVKK açısından en riskli sonuçtur — şirket içinde devre dışı bırakılan hesap bulutta aktif kalır.
• Grup üyelikleri donar. Yetki değişiklikleri, dağıtım listeleri ve gruba bağlı erişim kuralları güncellenmez.

Kritik nokta şu: bu bir uyarı ekranı ya da kademeli bozulma değil. Senkronizasyon çalışmayı bırakır ve bunu genellikle ilk fark eden kişi, hesabı açılmayan yeni işe başlayan personel olur. Kimlik altyapınızın bugünkü durumunu birlikte değerlendirmek isterseniz, iletişim formumuzdan kurumsal değerlendirme talebi iletebilirsiniz; hibrit kimlik envanteri çıkarma görüşmelerimiz ön bilgi paylaşımı dışında bir taahhüt gerektirmez.

Adım 1: Hangi sürümde olduğunuzu 5 dakikada öğrenin

Bu adımı atlamayın. Sahada gördüğümüz en yaygın yanılgı, "bizde otomatik yükseltme açık, sorun yok" varsayımıdır. Microsoft'un kendi belgesi bunun neden yeterli olmadığını açıklıyor: otomatik yükseltme her sürümü dağıtmaz, yalnızca kritik düzeltmeleri iter; ayrıca her yapılandırma otomatik yükseltmeye uygun değildir ve daha önce sessizce başarısız olmuş olabilir.

Kurulu sürümü doğrulamanın Microsoft tarafından belgelenmiş yolu:

1. Senkronizasyon sunucusunda yönetici hesabıyla oturum açın.
2. Hizmetler'i açın (Başlat > Çalıştır > services.msc). Listede Microsoft Entra ID Sync hizmetinin bulunduğunu ve durumunun Çalışıyor olduğunu doğrulayın.
3. C:\Program Files\Microsoft Azure AD Connect klasörüne gidin.
4. AzureADConnect.exe dosyasına sağ tıklayın, Özellikler > Ayrıntılar sekmesini açın.
5. Ürün sürümü satırındaki numara kurulu sürümünüzdür.

Kurulumun hangi sunucuda olduğunu bilmiyorsanız — devralınan altyapılarda sık rastlanır — Microsoft Entra yönetim merkezindeki Entra Connect sayfası üzerinden hangi sunucunun senkronizasyon yaptığını görebilirsiniz. Kurulum dosyasının (.msi) artık yalnızca bu sayfadan indirilebildiğini de not edin; eski indirme merkezi bağlantıları geçersizdir.

Sürümü not ettikten sonra bir sonraki bölüme geçin — çünkü çoğu kurumun asıl sürprizi burada başlıyor.

Sürüm takvimi tuzağı: 2.5.79.0'a çıkmak yetmiyor

Microsoft'un 2.x sürümleri için yürüttüğü destek politikası şu: bir sürüm, yenisi çıktıktan 12 ay sonra destek dışına alınır. Bu politika 30 Eylül eşiğiyle birleşince, "minimum sürüme çıkayım, kurtulayım" yaklaşımı üç hafta ömürlü bir çözüm hâline geliyor.

Resmi sürüm geçmişinden alınan destek bitiş tarihleri (2026-07 itibarıyla):

• 2.4.131.0 — 26 Mayıs 2026 (destek bitti)
• 2.5.3.0 — 31 Temmuz 2026
• 2.5.76.0 — 1 Eylül 2026
• 2.5.79.0 — 23 Ekim 2026 (30 Eylül eşiğinin yalnızca üç hafta sonrası)
• 2.5.190.0 — 2 Şubat 2027
• 2.6.1.0 — 10 Mart 2027
• 2.6.3.0 — 7 Temmuz 2027
• 2.6.84.0 — en güncel sürüm, 7 Temmuz 2026'da yayımlandı

Dolayısıyla pratik tavsiye tektir: doğrudan 2.6.84.0'a çıkın. Bu sürüm güvenlik düzeltmeleri içeriyor ve Microsoft "mümkün olan en kısa sürede yükseltin" notunu düşmüş durumda. Ayrıca 2.5.79.0'ın bilinen bir kısıtı var: o sürümde Senkronizasyon Hizmeti Yöneticisi arayüzünü kullanmak, kurulum sihirbazının ve otomatik sertifika yenilemesinin bozulmasına yol açabiliyor — bu sorun 2.6.1.0 ile giderildi.

Bir uyarı daha: 1.x sürümlerinin tamamı çalışmıyor. Hâlâ 1.x üzerindeyseniz senkronizasyonunuz zaten durmuş demektir ve yerinde yükseltme desteklenmez; aşağıdaki yedek sunucu yöntemiyle temiz kurulum yapmanız gerekir.

Adım 2: Üç yükseltme yönteminden hangisi size uygun?

Microsoft üç yol tanımlıyor. Seçim, sunucu sayınıza, nesne sayınıza ve en son ne zaman yükselttiğinize bağlı:

Otomatik yükseltme

Standart (express) kurulum yapmış kurumlar için en kolay yol; elle müdahale gerektirmez. Kısıtı, dağıtılan sürümün her zaman en güncel sürüm olmamasıdır. Otomatik yükseltmeye güveniyorsanız bile sürümü elle doğrulayın.

Yerinde yükseltme

Tek senkronizasyon sunucunuz varsa ve dizininizde yaklaşık 100.000'den az nesne bulunuyorsa tercih edilen yöntem budur. Ek sunucu gerektirmez. Dezavantajı geri dönüşün olmamasıdır: yükseltme sırasında bir sorun çıkarsa eski sürüme dönemezsiniz.

Yedek sunucuyla yükseltme (swing migration)

Microsoft'un en güvenli olarak nitelediği yöntem. Yeni bir sunucu kurar, hazır hâle getirir ve ancak doğruladıktan sonra devreye alırsınız; üretim senkronizasyonu kesintiye uğramaz. Şu durumlarda bu yöntemi seçin:

• Son 12-18 aydır yükseltme yapılmamışsa (Microsoft bu durumda açıkça yedek sunucu yöntemini öneriyor)
• Sunucunun işletim sistemini de yükseltecekseniz
• Yapılandırmada esaslı bir değişiklik yapacaksanız
• 1.x veya DirSync gibi eski bir istemciden geliyorsanız (yerinde yükseltme desteklenmiyor)
• Dizininiz büyükse ve ilk tam senkronizasyon günler sürecekse

Ölçek bağımsız bir gerçek: 12 aydan uzun süredir dokunulmamış bir senkronizasyon sunucusunda sorun genellikle Entra Connect'ten değil, yıllar içinde birikmiş yamalardan ve elle yapılmış yapılandırma değişikliklerinden çıkar. Bu nedenle "eski sunucu" tarifine uyuyorsanız yerinde yükseltmeyi zorlamayın.

Adım 3: Yerinde yükseltme — adım adım

Ön gereksinimler: Sunucuda .NET Framework 4.7.2 ve TLS 1.2 etkin olmalı. Yükseltme için gereken yetkiler Microsoft'un hesaplar ve izinler belgesinde tanımlı; kurulum dosyasını Microsoft Entra yönetim merkezindeki Entra Connect sayfasından indirin.

1. Yapılandırmanızı yedekleyin. Entra Connect'in "yapılandırmayı dışa aktar" özelliğiyle mevcut ayarları dosyaya alın. Geri dönüş ihtiyacınız olursa tek dayanağınız bu dosyadır.
2. Özel senkronizasyon kurallarınızı gözden geçirin. Bu adım kritik: varsayılan (out-of-box) senkronizasyon kurallarında elle değişiklik yaptıysanız, yükseltme bu kuralları varsayılana geri döndürür. Değişiklikleriniz sessizce kaybolur. Yükseltmeden önce mevcut kuralları Senkronizasyon Kuralları Düzenleyicisi üzerinden dışa aktarıp saklayın.
3. Zamanlamayı mesai dışına alın. Varsayılan kurallarda bir değişiklik varsa yükseltmeden sonra tam içe aktarma ve tam senkronizasyon çalışır; bu, nesne sayısına bağlı olarak saatler sürebilir. Bu süre boyunca 30 dakikada bir çalışan normal senkronizasyon askıya alınır — ancak parola senkronizasyonu çalışmaya devam eder.
4. Kurulumu çalıştırın. İndirdiğiniz .msi dosyasını sunucuda başlatın; sihirbaz mevcut kurulumu algılayıp yükseltme akışına geçer.
5. Tam senkronizasyonu erteleyecekseniz, sihirbazın sonunda "Yapılandırma tamamlandığında senkronizasyon işlemini başlat" seçeneğinin işaretini kaldırın. Ardından hangi işlemlerin sıraya alındığını görün:

   Get-ADSyncSchedulerConnectorOverride | fl

   Bu işlemleri tüm bağlayıcılarda geçici olarak kaldırmak için:

   foreach ($connectorOverride in Get-ADSyncSchedulerConnectorOverride)
   {
       Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier $connectorOverride.ConnectorIdentifier.Guid -FullSyncRequired $false -FullImportRequired $false
   }

   Zamanlayıcıyı yeniden başlatmak için:

   Set-ADSyncScheduler -SyncCycleEnabled $true

   Not: Ertelediğiniz tam içe aktarma ve tam senkronizasyon adımlarını ilk uygun pencerede mutlaka çalıştırın; kalıcı olarak atlanacak işlemler değildir.
6. Standart dışı bağlayıcı kullanıyorsanız (örneğin genel LDAP veya genel SQL bağlayıcısı — yerli İK ve bordro yazılımlarıyla entegrasyonda karşımıza çıkar), yükseltmeden sonra Senkronizasyon Hizmeti Yöneticisi'nde ilgili bağlayıcı yapılandırmasını yenileyin. Aksi hâlde içe/dışa aktarma adımları hatalı çalışır ve olay günlüğünde sürüm uyuşmazlığı hatası görürsünüz.
7. Doğrulayın. Sürümü yeniden kontrol edin, bir deneme kullanıcısı açıp buluta ulaştığını, bir parola değişikliğinin yansıdığını teyit edin.

Bu adımların kurumunuzdaki karşılığını önceden görmek için 15 dakikalık bir teknik değerlendirme görüşmesi yeterli oluyor; Microsoft güvenlik ve kimlik çözümleri sayfamızdan kapsamı inceleyebilir, WhatsApp üzerinden ekibimize ulaşabilirsiniz.

Adım 4: Yedek sunucuyla (swing) yükseltme — adım adım

Bu yöntemde iki sunucu bulunur: üretimi yürüten etkin sunucu ve yeni sürümle hazırlanan hazırlık (staging) sunucusu. Hazırlık sunucusu, dizini okur ve tüm hesaplamaları yapar; ancak buluta yazma yapmaz. Hazır olduğunda roller değiştirilir.

1. Yeni sunucuya güncel sürümü kurun. Zaten iki sunucunuz varsa önce hazırlık sunucusunu yükseltin. İşletim sistemini de yenileyecekseniz Windows Server 2025 artık resmen destekleniyor.
2. Özel yapılandırmanızı taşıyın. Etkin sunucudan dışa aktardığınız ayar dosyasını yeni sunucuda içe aktarın. Tek tek oluşturduğunuz özel senkronizasyon kurallarını taşıyorsanız, kuralı Senkronizasyon Kuralları Düzenleyicisi'nde Dışa Aktar ile alın, .ps1 uzantısıyla kaydedin ve dosyadaki bağlayıcı kimliğini (GUID) yeni sunucudakiyle değiştirin — bu kimlik her sunucuda farklıdır ve değiştirilmezse kural uygulanmaz.
3. Tam içe aktarma ve tam senkronizasyonu çalıştırın ve sonucu bekleyin.
4. Farkları doğrulayın. Hazırlık sunucusunun buluta göndermeyi planladığı değişiklikleri inceleyin. Beklenmeyen bir silme ya da toplu öznitelik değişikliği görüyorsanız devreye almayın; düzeltip döngüyü tekrarlayın.
5. Rolleri değiştirin. Eski etkin sunucuyu hazırlık moduna alın, yeni sunucuyu etkin yapın.
6. Eski sunucuyu yükseltin veya tamamen kaldırın. Burada Microsoft'un özellikle vurguladığı bir risk var: ağda unutulan ya da sonradan yanlışlıkla açılan eski senkronizasyon sunucuları "başıboş sunucu" hâline gelir. Şirket içi dizine artık erişemeseler bile buluta bağlanmayı sürdürüp eski verilerle bulut kayıtlarının üzerine yazabilirler — ve bunu her senkronizasyon döngüsünde (varsayılan olarak 30 dakikada bir) tekrarlarlar. Teşhisi zor bu sorundan kaçınmak için eski sunucuyu ürün ve bileşenleriyle tamamen kaldırın ya da sanal makineyse kalıcı olarak silin.

Cloud Sync'e geçmeli misiniz? Temmuz 2026'da başlayan bildirimler

30 Eylül eşiğinin arka planında daha büyük bir yön değişikliği var. Microsoft, Nisan 2026'da Entra Connect Sync'ten bulut tarafında yönetilen Entra Cloud Sync'e geçişi başlattığını duyurdu. Cloud Sync'te ayarlar sunucuda değil bulutta tutulur; şirket içinde yalnızca hafif bir aracı (provisioning agent) çalışır.

Resmi duyuruya göre Temmuz 2026'dan itibaren Microsoft, kurumlara Microsoft 365 Mesaj Merkezi, Entra Connect Health ve doğrudan e-posta yoluyla kendi geçiş pencerelerini bildirmeye başlıyor. Geçiş dalgalar hâlinde ilerliyor: ilk dalgalar, ihtiyaçları Cloud Sync tarafından bugün tamamen karşılanan sade yapılandırmalı kurumlar. Microsoft'un ifadesiyle, gelişmiş özelliklere dayanan ya da büyük dizinlere sahip kurumlar ilk hedef gruplarda yer almayacak (kaynak: Microsoft Entra sürüm ve duyuruları — Nisan 2026).

Kurumunuzun bugün Cloud Sync'e uygun olup olmadığını, Microsoft'un yayımladığı desteklenen senaryo karşılaştırmasından okuyabilirsiniz. Cloud Sync'in bugün desteklemediği ve Connect Sync gerektiren senaryolar:

• Entra hibrit katılım — bilgisayarların hem şirket içi dizine hem buluta kayıtlı olması
• İş için Windows Hello — parolasız giriş (yüz tanıma, PIN)
• Kullanıcılar bir ormanda, posta kutuları kaynak ormanda olan Exchange topolojileri
• 250.000'den fazla nesne içeren büyük etki alanları
• Öznitelik değerine göre filtreleme — belirli bir alana göre kullanıcı ayıklama

Cloud Sync'in desteklediği, hatta Connect Sync'e üstün olduğu senaryolar: birleşme ve satın almalarda birbirine bağlı olmayan ormanların senkronizasyonu, yüksek erişilebilirlik için birden fazla aracı çalıştırma, Exchange hibrit yapı ve buluttan şirket içi dizine grup sağlama.

İki aracı aynı ormanda paralel çalıştırmak da mümkündür — kapsam filtreleri birbiriyle çakışmadığı sürece. Uygulamada birçok kurum için doğru model budur: kullanıcıların çoğunluğu Cloud Sync'e alınır, Cloud Sync'in karşılamadığı özel senaryolar Connect Sync üzerinde bırakılır.

Cloud Sync geçişi: pilot kuruluş birimiyle adım adım

Cloud Sync geçişi bir hafta sonu işi değildir; Microsoft'un belgelediği akış kademeli ilerlemeye dayanır. Özet adımlar:

1. Doğru aracı seçtiğinizi doğrulayın — yukarıdaki desteklenen senaryo listesiyle kurumunuzun ihtiyaçlarını karşılaştırın.
2. Ön koşulları ve mevcut kurulumu kontrol edin. Microsoft'un geçiş rehberi, standart (express) kurulum yapmış ve cihaz senkronizasyonu kullanmayan kurumları hedefliyor.
3. Entra Connect yapılandırmanızı yedekleyin. Geri dönüş imkânınız yalnızca bu yedek.
4. Pilot için bir kuruluş birimi (OU) belirleyin. Kuruluş birimi, Active Directory içinde kullanıcıları gruplayan klasör yapısıdır. Pilot kullanıcıları buraya taşıyın ve Connect Sync'in değişikliği görmesini bekleyin. Kullanıcı sayısını doğrulayın:

   Get-ADUser -Filter * -SearchBase "OU=Finans,OU=Kullanicilar,DC=ornek,DC=com"

5. Zamanlayıcıyı durdurun ve yeni kuralları oluşturun.
6. Özel senkronizasyon kurallarını yazın. Pilot kuruluş birimindeki kullanıcılar için cloudNoFlow özniteliğini True yapan bir gelen kural ve JoinNoFlow bağlantı türünde bir giden kural oluşturun. Bu ikili, Connect Sync'in bu kullanıcılar için buluta nesne ekleme, silme ve öznitelik güncellemesi göndermesini engeller; buna karşılık grup üyeliği ve yönetici gibi referans alanları akmaya devam eder.
7. Sağlama aracısını kurun ve Cloud Sync yapılandırmasında kapsamı bu kuruluş birimine ayarlayın.
8. Pilot kullanıcıları doğrulayın. Sayılar tutuyor mu? Bu birimde açtığınız yeni bir kullanıcı buluta gidiyor mu?
9. Zamanlayıcıyı yeniden başlatın ve kalan kullanıcıları partiler hâlinde planlayın.
10. Son geçişi yapın, Connect Sync sunucusunu bir süre kapalı ama silinmemiş hâlde tutun, sorun çıkmadığından emin olduktan sonra tamamen kaldırın.

Microsoft'un bu akışta koyu harflerle uyardığı tek nokta şudur: pilot ya da birlikte çalışma aşamasında kuruluş birimlerini, etki alanlarını, grupları veya kullanıcıları Connect Sync kapsamından çıkarmayın. Kapsamdan erken çıkarmak güvenli değildir; bulut tarafındaki referansların kopmasına ve grup üyeliklerinin silinmesi gibi istenmeyen değişikliklerin buluta gönderilmesine yol açabilir. Doğru yöntem, nesneleri kapsamda bırakıp yukarıdaki "akış yok" kurallarıyla susturmaktır.

Türkiye'deki kurumlar için üç ek kontrol

KVKK: senkronizasyonun durması bir güvenlik açığıdır

KVKK'nın 12. maddesi, veri sorumlusuna kişisel verilere hukuka aykırı erişimi önlemek için gerekli teknik tedbirleri alma yükümlülüğü getirir. Kimlik senkronizasyonu durduğunda ortaya çıkan tablo tam olarak budur: işten ayrılan personelin şirket içinde kapatılan hesabı, Microsoft 365 tarafında açık kalmaya devam eder. Personel; e-postaya, SharePoint'teki müşteri kayıtlarına ve Teams sohbetlerine erişmeyi sürdürebilir. Bu, teknik bir aksaklık değil, denetimde savunulması güç bir erişim kontrolü boşluğudur. 30 Eylül planınızı yaparken, iş çıkış süreçlerinizin senkronizasyona ne kadar bağımlı olduğunu da not edin ve senkronizasyon kesintilerinde devreye girecek elle hesap kapatma adımını yazılı hâle getirin.

Yerli İK ve bordro yazılımı entegrasyonları

Türkiye'de yaygın bir kurgu, İK yazılımının (Logo, Netsis, Mikro ailesi veya yerli personel yönetim uygulamaları) işe giriş-çıkış kayıtlarını Active Directory'ye yazması, oradan da buluta akmasıdır. Bu zincirde senkronizasyon halkası koptuğunda İK yazılımı sorunsuz çalışmaya devam eder — hata vermez, kayıt oluşturur — ama bulut tarafında hiçbir şey değişmez. Bu yüzden entegrasyon kurgunuz varsa yükseltme sonrası doğrulamayı yalnızca elle açtığınız deneme kullanıcısıyla değil, İK yazılımı üzerinden açılan gerçek bir kayıtla yapın. Ayrıca bu entegrasyonlar sıklıkla genel LDAP veya SQL bağlayıcısı kullanır; yükseltme sonrası bağlayıcı yapılandırmasını yenilemeyi unutmayın.

Türkçe karakter tuzağı

Türkçeye özgü karakterler (ç, ğ, ı, ö, ş, ü) kullanıcı adlarında ve e-posta adreslerinde eşleşme sorunları doğurabilir. Özellikle şirket içi kullanıcı adı ile bulut oturum açma adresi arasında karakter dönüşümü tutarsızsa, senkronizasyon nesneyi eşleştiremez ve yinelenen hesaplar oluşur. Yükseltme öncesi yapacağınız temizlikte, oturum açma adreslerinin ASCII karşılıklarına düzgün çevrildiğini (ör. "Şükrü Işık" için sukru.isik) ve aynı kişiye ait yinelenen kayıt bulunmadığını kontrol edin. Bu, geçiş sırasında en çok zaman kaybettiren ama önceden bakıldığında en kolay kapatılan kalemdir.

Örnek plan: tek ormanlı bir kurumda üç haftalık takvim

Aşağıdaki takvim, tek Active Directory ormanı ve tek senkronizasyon sunucusu bulunan, birkaç yüz kullanıcılı bir kurum için hazırlanmış bir planlama şablonudur; kendi ortamınızın nesne sayısına ve bakım pencerenize göre uyarlanmalıdır.

• 1. hafta — envanter: Sunucu sürümü ve işletim sistemi tespiti; varsayılan senkronizasyon kurallarında elle değişiklik yapılıp yapılmadığının kontrolü; yapılandırmanın dışa aktarılması; yinelenen ve Türkçe karakterli hesapların temizliği; Cloud Sync uygunluk kontrolü (hibrit katılım, Windows Hello, kaynak orman, nesne sayısı).
• 2. hafta — hazırlık: Yöntem kararı (yerinde ya da yedek sunucu); .NET 4.7.2 ve TLS 1.2 doğrulaması; yedek sunucu seçildiyse yeni sunucunun kurulması ve yapılandırmanın içe aktarılması; tam içe aktarma ve tam senkronizasyon sonrası fark incelemesi.
• 3. hafta — devreye alma: Mesai dışı pencerede rol değişimi veya yerinde yükseltme; deneme kullanıcısı, parola değişikliği ve İK yazılımı üzerinden gerçek kayıt testleri; eski sunucunun kapatılması; bir hafta gözlem sonrası tamamen kaldırılması.

Bu takvimin en çok atlanan kalemi ilk haftadaki "varsayılan kurallar değiştirilmiş mi" kontrolüdür. Yükseltmenin bu kuralları varsayılana döndürdüğü hatırlanmazsa, yıllar önce eklenmiş bir öznitelik eşlemesi sessizce kaybolur ve sorun haftalar sonra, ilgisiz görünen bir belirtiyle ortaya çıkar.

Yükseltmede en sık karşılaşılan hatalar

• "Microsoft Entra bağlayıcısı bulunamadı" hatası. Yükseltmenin en başında çıkar ve mevcut yapılandırmanın yükseltmeye uygun olmadığını gösterir. Doğrulamak için: Get-ADSyncConnector -Identifier b891884f-051e-4a83-95af-2544101c9083 — komut "belirtilen MA bulunamadı" hatası veriyorsa teşhis kesinleşir. Çözüm, sihirbazı kapatıp mevcut kurulumu kaldırmak ve yeni sürümü temiz kurmaktır.
• Özel kuralların kaybolması. Varsayılan kurallarda elle değişiklik yapılmışsa yükseltme bunları sıfırlar. Önlemi, değişiklikleri Microsoft'un önerdiği biçimde ayrı özel kurallar olarak tanımlamak ve yükseltme öncesi tümünü dışa aktarmaktır.
• Standart dışı bağlayıcıların yenilenmemesi. Genel LDAP veya SQL bağlayıcısı kullanıyorsanız, yükseltme sonrası yapılandırmayı yenilemezseniz içe/dışa aktarma sessizce hatalı çalışır.
• Başıboş kalan eski sunucu. Kaldırılmayan eski senkronizasyon sunucusu, sonradan açıldığında bulut verisinin üzerine eski bilgiyle yazmaya başlayabilir.
• Otomatik yükseltmeye güvenmek. Bu listedeki en pahalı varsayım; sürümü elle doğrulamadan planı kapatmayın.

Yükseltme ya da Cloud Sync geçişini kendi ekibinizle yürütecekseniz bile, bu kontrol listesini kurumunuzun ortamına uyarlanmış hâlde talep edebilirsiniz. Kimlik altyapısıyla ilgili diğer yazılarımız: Microsoft Entra ID nedir ve Koşullu Erişim politikası nasıl yapılandırılır.

Sıkça Sorulan Sorular (SSS)

30 Eylül 2026'da tam olarak ne oluyor?

Entra Connect Sync sürümü 2.5.79.0'ın altında olan sunucularda tüm senkronizasyon hizmetleri çalışmayı durduruyor. Şirket içinde açılan yeni kullanıcılar buluta gitmez, parola değişiklikleri işlenmez, işten ayrılan personelin kapatılan hesabı bulutta açık kalır.

Sadece 2.5.79.0'a yükseltmek yeterli mi?

Hayır. Microsoft bir sürümü, yenisi çıktıktan 12 ay sonra destek dışına alıyor. 2.5.79.0'ın destek bitişi 23 Ekim 2026 — yani 30 Eylül eşiğinden yalnızca üç hafta sonrası. Doğru hamle doğrudan en güncel sürüme (7 Temmuz 2026'da yayımlanan 2.6.84.0) çıkmaktır.

Hangi sürümde olduğumu nasıl öğrenirim?

Senkronizasyon sunucusunda C:\Program Files\Microsoft Azure AD Connect klasörüne gidin, AzureADConnect.exe dosyasına sağ tıklayıp Özellikler > Ayrıntılar sekmesini açın; Ürün sürümü satırındaki numara kurulu sürümünüzdür. Aynı sunucuda services.msc içinde Microsoft Entra ID Sync hizmetinin çalıştığını da doğrulayın.

Yükseltme sırasında kullanıcılar oturum açamayacak mı?

Hayır. Yükseltme yalnızca dizin senkronizasyonunu geçici olarak durdurur; kimlik doğrulama bulut tarafında yapıldığı için Microsoft 365 oturumları etkilenmez. Yükseltme süresince yeni hesap açma, parola değişikliği ve grup üyeliği güncellemeleri buluta yansımaz — bu nedenle mesai dışı bir pencere tercih edilir.

Yükseltme mi yapmalıyım, yoksa doğrudan Cloud Sync'e mi geçmeliyim?

İkisi alternatif değil, sıralı iki iştir. 30 Eylül eşiği için önce yükseltmeyi tamamlayın; Cloud Sync geçişi haftalar süren ayrı bir projedir. Ayrıca Entra hibrit katılım, İş için Windows Hello, kaynak orman posta kutuları, 250 binden fazla nesne ve öznitelik tabanlı filtreleme senaryolarını Cloud Sync bugün desteklemiyor.

Microsoft bize ne zaman Cloud Sync bildirimi gönderecek?

Microsoft, Temmuz 2026'dan itibaren kurumlara Microsoft 365 Mesaj Merkezi, Entra Connect Health ve doğrudan e-posta üzerinden geçiş pencerelerini bildirmeye başladı. İlk dalgalar, ihtiyaçları Cloud Sync ile bugün tamamen karşılanan sade yapılandırmalı kurumlara odaklanıyor.

Otomatik yükseltme açıksa bir şey yapmam gerekiyor mu?

Yine de doğrulamanız gerekir. Otomatik yükseltme her sürümü dağıtmaz, yalnızca kritik güncellemeleri iter; ayrıca her yapılandırma otomatik yükseltmeye uygun değildir ve daha önce başarısız olmuş olabilir. Sunucunun gerçek sürümünü elle kontrol edin.

Sonuç: Eylül'e kadar üç işlik bir plan

30 Eylül 2026 tarihi, hibrit kimlik altyapısı işleten her kurum için kesin bir eşik. İyi haber, işin kapsamının sınırlı ve öngörülebilir olması: sürümü tespit edin, en güncel sürüme yükseltin, sonucu gerçek bir kullanıcı kaydıyla doğrulayın. Bu üç işi bir bakım penceresine sığdırmak çoğu kurum için mümkündür — yeter ki son haftaya bırakılmasın.

İkinci karar — Cloud Sync'e geçiş — daha uzun vadeli ve daha stratejik. Microsoft'un yönü belli: bulut tarafında yönetilen senkronizasyon. Ancak Entra hibrit katılım, İş için Windows Hello ve kaynak orman gibi senaryoları kullanan kurumlar için bugün geçiş yapılabilir bir seçenek değil. Bu nedenle doğru sıralama, önce Eylül eşiğini güvenle geçmek, ardından kendi geçiş pencereniz bildirildiğinde Cloud Sync uygunluğunuzu sakin biçimde değerlendirmektir.

Yükseltme takviminizi çıkarırken sizinle aynı dönemde gündeme gelen diğer bitiş tarihlerini de birlikte planlamanız faydalı olur; Exchange Server 2016/2019 destek bitişi yazımız bu takvimin ikinci ayağını ele alıyor. Kimlik ve uçtan uca güvenlik mimarisi için Microsoft Security, üretkenlik katmanı için Microsoft 365 ve altyapı tarafı için Microsoft Azure çözüm sayfalarımızı inceleyebilirsiniz.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun hibrit kimlik altyapısında sürüm yükseltmesi, yedek sunucuyla geçiş ve Entra Cloud Sync taşıma projelerinde uçtan uca destek sağlıyoruz. Teknik değerlendirme görüşmeleri ön bilgi paylaşımı dışında bir taahhüt gerektirmez; iletişim sayfamızdan bize ulaşabilirsiniz.