Active Directory taşıma hizmeti: geçiş ve teklif

Active Directory taşıma hizmeti hangi ihtiyacı karşılar?

Active Directory taşıma hizmeti, şirketinizin kullanıcı ve bilgisayar kimlik altyapısını mevcut durumdan hedef yapıya planlı biçimde geçirmek için değerlendirilir. Eski sunucuyu değiştirmek, desteklenen bir Windows Server ortamına geçmek veya farklı etki alanlarını yeniden düzenlemek istiyorsanız önce geçişin türü belirlenmelidir. İz Medya’nın Active Directory yönetim hizmeti üzerinden mevcut etki alanınız için ön inceleme ve taşıma kapsamı değerlendirmesi isteyebilirsiniz. Hedef, yalnız yeni sunucuyu açmak değil, çalışanların gerekli kaynakları kullanabildiğini doğrulamaktır.

Bu yazı, sıfırdan Active Directory kurulumu anlatımından farklı olarak çalışan bir kimlik altyapısındaki bağımlılıkları ve geçiş kabulünü ele alır. Etki alanı denetleyicisini yenilemekle kullanıcıları başka bir etki alanına taşımak aynı işlem değildir. Kullanıcı profilleri, dosya yetkileri ve uygulama bağlantıları farklı etkilenebilir. Teklifte başlangıç ortamı, hedef durum, korunacak işlevler ve kapsam dışında kalan sistemler ayrı yazılmalıdır. Ortam görülmeden bütün geçişin kesintisiz olacağı vaat edilmemelidir.

Sunucu yenileme mi, başka domain’e geçiş mi?

Aynı etki alanı içinde yeni bir denetleyici devreye almak, kurumun kimlik yapısını tümden değiştirmeyi gerektirmeyebilir. Başka bir forest veya domaine geçiş ise farklı planlama gerektirebilir. İşletmenin talebinde bu ayrım açık değilse ilk iş mimariyi çıkarmaktır. Kaç domain bulunduğu, hangi sunucuların kimlik hizmeti verdiği ve hangi uygulamaların bunlara bağlandığı belirlenmelidir. “Eski sunucuyu yenisine taşıyalım” cümlesi tek başına uygulanabilir kapsam oluşturmaz.

Microsoft’un etki alanı denetleyicilerini yükseltme dokümanı, yeni denetleyici ekleme ve eski yapıyı kaldırma dahil farklı değerlendirmeleri açıklar. Seçilecek yol mevcut sürümler, işlev düzeyleri ve ön koşullarla doğrulanmalıdır. Kurumlar arası birleşme veya yeni domain ihtiyacı varsa bunu ayrıca belirtin. Üreticinin desteklediği bir sunucu yenileme sürecini her türlü kimlik taşıma projesine eşitlemek, iş yükünü ve riski eksik tanımlar.

Taşıma öncesi sağlık kontrolü neden gerekir?

Mevcut ortamda zaten bulunan DNS veya çoğaltma sorunları, yeni sunucu eklenince kendiliğinden düzelmiş sayılmaz. Ön incelemede etki alanı denetleyicileri, olay kayıtları, servis durumu ve zaman eşitleme yapısı değerlendirilmelidir. Hataların hangilerinin geçiş öncesinde giderileceği yazılmalıdır. İnceleme raporu yalnız sorun listesinden oluşmamalı; uygulamayı etkileyen koşullar ve gerekli sorumlular da belirtilmelidir. Böylece taşıma günü beklenmeyen temel altyapı sorunlarıyla karşılaşma ihtimali azaltılabilir.

Ön kontrol çıktıları güvenli biçimde saklanmalı ve değişiklik öncesi durum için referans olmalıdır. Yönetici hesaplarının kimde olduğu, acil erişimin nasıl sağlanacağı ve mevcut yedeklerin kullanılabilirliği de değerlendirilir. Bütün sistemlerde aynı araçların ve adımların uygulanacağı varsayılmaz. Yetki sınırı ve üretim ortamına etkisi önceden açıklanmalıdır. Sağlık kontrolü yapılmadan verilen sabit süreli teklif, bilinmeyen sorunların kimin sorumluluğunda olduğunu belirsiz bırakabilir.

DNS, DHCP ve uygulama bağımlılıkları

Çalışanların oturum açabilmesi, kimlik altyapısının yalnız bir bölümüdür. İstemcilerin hangi DNS sunucusunu kullandığı, ağ cihazlarının hangi adreslere başvurduğu ve uygulamaların eski sunucu adına bağlı olup olmadığı araştırılmalıdır. DHCP aynı sunucuda çalışıyorsa bunun geçişi ayrıca planlanabilir. Dosya paylaşımı, yazdırma veya sertifika hizmetlerinin varlığı da sorulmalıdır. Bu görevlerin etki alanı denetleyicisiyle aynı makinede bulunması hepsinin tek adımda taşındığı anlamına gelmez.

Uygulama sağlayıcılarından bilgi almak gerekebilir. Örneğin kullanıcı doğrulaması için belirli sunucu adresine bağlanan bir yazılımın hedefi güncellenmelidir. Teknik ekip erişebildiği ayarlarla başka sağlayıcının değiştirmesi gereken ayarları ayırmalıdır. Test listesinde uygulama sorumluları bulunmalı. Bir sunucunun kapatılması kararı verilmeden önce ona başvuran sistemler incelenmelidir. Sadece kullanıcının masaüstüne ulaşması, arka plandaki bütün iş uygulamalarının yeni düzene uyum sağladığını göstermez.

Kullanıcı profilleri ve dosya yetkileri

Geçiş başka bir kimlik alanına yapılacaksa kullanıcıların bilgisayardaki profilleri ve kaynak yetkileri özellikle değerlendirilmelidir. Kullanıcı adı aynı görünse bile alttaki kimlik ilişkileri aynı olmayabilir. Bu nedenle “isimler değişmiyor, her şey olduğu gibi çalışır” şeklinde varsayım kurulmaz. Mevcut kullanıcı grupları, paylaşımlar ve uygulama izinleri envantere alınmalıdır. Hangi verinin taşınacağı ve hangi erişimin yeniden tanımlanacağı teklifin önemli bir parçasıdır.

Pilot kullanıcı seçerken yalnız yönetici hesabı kullanılmamalıdır. Günlük işini yapan sınırlı yetkili çalışan, gerekli dosyayı açabiliyor mu, doğru yazıcıyı görüyor mu ve uygulamasına girebiliyor mu denenmelidir. Yetkisiz klasörlere erişemediği de kontrol edilir. Genel arka plan için dosya paylaşım yönetimi rehberi incelenebilir. Taşıma projesi, bu erişimlerin yeni düzende nasıl korunacağını somut kabul senaryolarına dönüştürmelidir.

GPO ve güvenlik ayarları nasıl doğrulanır?

Group Policy, kullanıcı ve bilgisayar ayarlarının merkezi uygulanmasında kullanılır. Geçişte yalnız politika dosyalarının bulunması yeterli kabul edilmemeli; hangi gruplara ve bilgisayarlara uygulandığı incelenmelidir. Oturum betikleri, paylaşılan yollar ve eski sunucu adları içeren ayarlar özellikle değerlendirilir. Kullanılmayan politikaları otomatik taşımak yerine kurumun onayıyla gözden geçirmek yararlı olabilir. Ancak geçiş projesi içinde kapsamı belirsiz bir güvenlik dönüşümü başlatılmamalıdır.

Taşınacak politikaların listesi ve test edilecek sonuçları yazılmalıdır. Bir bilgisayarda beklenen ayarın uygulanması, bütün organizasyon birimlerinin doğrulandığı anlamına gelmez. Farklı kullanıcı grupları için örnekler seçilebilir. Değiştirilen güvenlik ayarları uygulamaları etkileyebileceği için iş birimi sorumlularının kabulü gerekir. Active Directory kurulum ve kontrol rehberi temel hazırlığı açıklar; bu yazı ise mevcut ayarların geçiş sonrası davranışına odaklanır. Böylece içerikler aynı ihtiyacı tekrar etmez.

Yedekleme ve geri dönüş planı

Geçişten önce hangi yedeklerin bulunduğu ve bunların neyi kurtarabildiği doğrulanmalıdır. Kimlik altyapısı için uygun kurtarma yöntemi, genel bir dosya kopyalama işleminden farklı olabilir. Sanal makine görüntüsü veya snapshot bulunduğu için her koşulda güvenli geri dönüş yapılabileceği varsayılmaz. Desteklenen süreçler mevcut sistem özellikleriyle birlikte incelenmelidir. Kurtarma sorumlusu, erişilecek kayıtlar ve uygulamayı durdurma koşulları yazılı olmalıdır.

Planın yalnız “sorun olursa eskiye döneriz” cümlesinden oluşması yeterli değildir. Hangi aşamaya kadar, hangi koşulda ve hangi onayla geri dönüş yapılacağı belirlenmelidir. Kullanıcılar yeni düzende çalışmaya başladıktan sonra oluşan değişiklikler de değerlendirmeyi etkileyebilir. Üretim ortamında denenecek kurtarma işlemleri ayrıca onaylanmalı. Geri dönüş hazırlığının bulunması bütün risklerin yok olduğu anlamına gelmez; amacı beklenmeyen durumda kullanılabilecek karar yolunu önceden anlaşılır hale getirmektir.

Taşıma günü ve eski sunucunun devreden çıkarılması

Uygulama penceresi, etkilenecek kullanıcılar ve iletişim sorumluları önceden belirlenmelidir. Çalışanların hangi saatte hangi işlevde değişiklik bekleyeceği açıklanır. Teknik işlemler aşamalı ilerliyorsa her aşamanın kontrol sonucu kaydedilmelidir. Kimlik doğrulama, DNS, uygulama erişimi ve politika testleri tamamlanmadan eski sunucunun görevinin bittiği varsayılmamalıdır. Sistemin kullanımına göre ek gözlem süresi veya başka sağlayıcıların doğrulaması gerekebilir.

Eski denetleyiciyi devreden çıkarma, üreticinin desteklediği süreçle ve bağımlılıklar kontrol edilerek ele alınmalıdır. Donanımı kapatmakla kimlik altyapısından düzgün kaldırmak aynı işlem değildir. Teslim raporunda kalan sunucular, roller, DNS değişiklikleri ve açık işler bulunmalı. Kullanıcı verilerine ilişkin gizli bilgiler rapora gereksiz eklenmemelidir. Kurumun yöneticisi yeni yapının sorumlularını ve yardım isteyeceği kanalı bilmelidir. Taşıma sonrası izleme hizmeti isteniyorsa bunun kapsamı ayrı belirtilmelidir.

İş birimleriyle kabul listesini tamamlama

Geçiş öncesinde her kritik iş biriminden bir temsilci belirlemek yararlıdır. Muhasebe, insan kaynakları ve operasyon ekipleri farklı uygulamalar kullanıyor olabilir. Teknik ekip bütün iş akışlarını kendiliğinden bilemez. Temsilciler, geçişten sonra yapılacak gerçek işlemleri önceden listeler. Örneğin dosyaya erişmek, uygulamada oturum açmak ve çıktı almak ayrı kontrol maddeleri olabilir. Testin tarihini, kullanıcı grubunu ve sonucunu kaydetmek eksiklerin görünmesini sağlar. Bir uygulama doğrulanamadıysa nedeninin erişim, lisans veya sağlayıcı bekleyişi olduğu açıklanmalıdır. Bu liste, eski sunucunun devreden çıkarılması kararına da somut dayanak oluşturur.

Active Directory taşıma fiyatı ve teklif hazırlığı

Fiyat; kullanıcı ve bilgisayar sayısı, domain yapısı, sunucu rolleri, mevcut hatalar, uygulama bağımlılıkları ve hedef mimariye göre değişir. Aynı domain içinde denetleyici yenilemeyle farklı domain’e geçişi yalnız kullanıcı sayısıyla karşılaştırmak yanıltıcı olabilir. Saha çalışması, kullanıcı profilleri ve uygulama sağlayıcılarıyla koordinasyon ayrı iş yükleri oluşturabilir. Kesin bedel, ön inceleme ve kabul senaryoları belirlendikten sonra netleşir.

Active Directory taşıma teklifi isterken mevcut sunucu sürümlerini, yaklaşık kullanıcı ve bilgisayar sayısını, domain sayısını ve hedefinizi paylaşın. “Eski sunucuyu yenilemek” veya “başka domain’e geçmek” istediğinizi açıkça yazın. Hassas yapılandırma ve yönetici bilgilerini ilk başvuruda göndermeniz gerekmez. Teklifte sağlık kontrolü, pilot kullanıcı, yedekleme hazırlığı, geçiş planı ve teslim raporu bulunmasını istemek, hizmeti yalnız yeni sunucu açılması üzerinden değerlendirme hatasını önler.

Sık Sorulan Sorular