Microsoft’un sitesinden SharePoint 2013 yazılımını ücretsiz indirebilirisiniz. Bu sürümü 180 gün boyunca kullanabiliyorsunuz.
http://technet.microsoft.com/en-US/evalcenter/hh973397.aspx?wt.mc_id=TEC_121_1_4
Windows işletim sistemlerinde her bir kullanıcıya bir SID atanır. Bu SID her kullanıcıya özgü yaratılır ve kullanıcı kimliklerini birbirinden ayırır.
Active Directory yapısında da Local yapıda da SID kullanımı mevcuttur. Kullanıcı yaratılırken SID numarası da yaratılır ve aynı kimlik doğrulayıcı başka bir kullanıcıya verilemez.
Örneğin bir kullanıcınızın ad soyad gibi bilgilerini değiştirseniz bile Windows işletim sistemine oturum açınca aynı profil dosyasını kullandığını görürsünüz.
Hangi kullanıcının hangi profil dosyasını kullanacağına SID karar verir.
Bilgisayarını yerel ağda kullanan bir kullanıcının bilgisayarını domain e taşıdığınızda artık farklı bir profil dosyası kullanacaktır. Bu yüzden masa üstü, belgelerim, müziklerim gibi kişisel yerlerdeki dosyalarda eski profilinde kalmaktadır.
Aynı zamanda domainler arasında kullanıcı taşıma işlemlerinde de benzer durum gözükmektedir.
Bu ve benzeri durumlarda kullanıcının eski profil dosyalarını tek tek yeni profile taşıyabilirsiniz fakat bu çoğu zaman uzun süren zahmetli bir iş olabilir.
Bu tür sıkıntılı durumlarda yapabileceğiniz bir işlem olan profile atanmış SID numarasını değiştirmek birçok durumda size kolaylık sağlayacaktır.
Bizim senaryomuzda “ortac” isimli kullanıcı yerel yapıda bilgisayarını kullanmaktadır. “C:users” kabının altında “ortac” isimli bir profil dosyası vardır.
Bilgisayarınız ABC domainine alıyoruz. AD User and Computers de “ortac” isimi ile bir hesap açıyoruz.
İki isimde aynı olmasına rağmen farklı profiller olduğu için “C:users” altında ortac.ABC ismi ile yeni bir profil dosyası hazırlanmaktadır.
Ve haliyle kullanıcı eski dosyalarına erişememektedir.
Öncelikle DC üzerinde aşağıdaki komutu çalıştırarak yeni kullanıcının SID numarasına erişiyoruz.
Dsget user "cn=ortac,ou=test,dc=abc,dc=local" -sid
Daha sonra domaine aldığımız makineyi domain admin kullanıcımız ile açıyoruz.
Registry editörü açıyoruz ve aşağıdaki lokasyona geliyoruz:
HKLMSoftwareMicrosoftWindows NTCurrentVersionProfileList.
Buradan domainde yer alan kullanıcımızın SID numarasını seçiyoruz.
Sağ daki bölümden “ProfileImagePath” anahtarına geliyoruz.
Üzerine iki kez tıklıyoruz ve o bilgisayarda eskiden kullanılan yerel profili belirtiyoruz.
Bu işlemin ardından makineyi domaindeki “ortac” kullanıcı ile açarsanız eğer kullanıcı eskiden kullandığı tüm dosyalara ve ayarlara kavuşacaktır.
Bu yazı sevgili Murat Yıldırımoğlu hocamın bir yazısından esinlenerek hazırlanmıştır.
http://www.muratyildirimoglu.com/articles/ChangingProfileFolderAfterRenamingUser.htm
ADMT aracı ile daha önceki makalemizde kullanıcı hesaplarının taşınmasını görmüştük. Bu yazımızda ise bilgisayar hesaplarını nasıl taşıyacağımızı inceleyeceğiz.
ADMT aracını çalıştırıyoruz. “Active Directory Migration Tool” menüsüne sağ tıklayıp “Computer Migration Wizard” ı seçiyoruz.
İlk bölümde forest yapımızdaki DC lerimizi hazırlamıştık:
Bu bölümde ise ADMT ve PES yazılımlarını kurarak kullanıcı hesabımızı ve parolaları taşıyacağız.
Aşağıdaki bağlantıdan yer alan ADMT 3.2 ve PES yazılımını ortacdemirel.com forestını yöneten DC üzerine kuruyoruz.
https://connect.microsoft.com/site1164
Öncelikle ADMT yazılımını kuruyoruz.
Active Directory Migration Tool (ADMT) yazılımı forest ınız içerisinde farklı domainler arasında ya da iki ayrı forest arasında nesnelerin (kullanıcı, bilgisayar, group vb.) taşınmasını sağlamaktadır.
Bu araç sayesinde mevcut forest ınız içerisinde yer alan kullanıcı nesnelerini rahatlıkla yeni kuracağınız bir domain e taşıyabilirsiniz.
ADMT ve genellikle onunla birlikte kullanılan “Password Export Server (PES)” yazılımlarının Windows Server 2012 işletim sistemine uygun sürümlerini aşağıdaki bağlantıdan indirebilirsiniz.
https://connect.microsoft.com/site1164
PES de parolaların taşınmasını sağlayan bir yazılımdır. Kurulu olan sunucuda bir hizmet çalıştırarak bu işlemi yapmaktadır.
ADMT ve PES yazılımları dışında birde MS SQL Server’a ihtiyacınız vardır. Express kullanabilirsiniz. Mevcut yapınızdaki bir MS SQL Server’ı da bu iş için kullanabilirsiniz.
ADMT ve PES uygulamamızda test ortamımız şu şekildedir:
Windows Server 2012 sunucu üzerinde ortacdemirel.com ismi ile bir domain çalışmaktadır. Bu domaine bağlı birde SQL server yer almaktadır.
Gene Windows Server 2012 sunucusu üzerinden abc.local ismi ile tamamıyla ayrı bir forest yapısı mevcuttur.
Ortacdemirel.com sunucusu üzerinde yer alan “ortac” ismindeki kullanıcı hesabını abc.local içerisine taşıyacağız.
Bu uygulama iki bölümden oluşmaktadır. İlk bölümde iki ayrı forest yapısında yer alan sunucuların birbiri arasında güven ilişkisi kurmasına değineceğiz, ikinci bölümde ise ADMT ve PES araçları ile kullanıcı taşıma işlemine değineceğiz.
Öncelikle iki forest içerisinde çalışan DC ler arasında güven ilişkisi hazırlamamız gerekiyor.
Ortacdemirel.com domainine hizmet adan DC makinesinde DNS konsolunu açıyoruz.
Makine ismine sağ tıklayıp özelliklere geliyoruz.
Windows Server 2012 işletim sistemi ile birlikte Active Directory Recycle Bin özelliği ile tanıştık. Bu özellik sayesinde active directory üzerinden silinen nesneleri geri getirebiliyoruz.
Aslında bu özellik Windows Server 2000 ve sonrasındaki tüm işletim sistemlerinde mevcuttu. 2008 R2 ile powershell üzerinden gerçekleştirilen bu eylem 2012 R2 ile birlikte artık grafiksel bir ara yüzden de yapılabilmektedir.
Active directory üzerinden silinen her nesne asında “tombstone” adı verilen bir kap içerisinde tutulmaktadır. Direk içerisini göremediğimiz bu kap içerisinde nesneler belirli bir süre daha muhafaza edilmekte ve sonrasında kalıcı olarak silinmektedir.
Tombstone kabı içerisinde tutulma süreleri ise işletim sisteminin sürümüne ve güncellemesine göre değişmektedir. Örneğin Windows server 2000’de 60 gün, Windows server 2003 Sp1’de 180 gün, 2003 R2’de gene 60 gün şeklinde devam etmektedir. En son çıkan Windows Server 2012 R2’de ise bu süre 180 gündür.
İstersek bu süreyi değiştirebiliriz. Bu süre powershell komutu, ldp.exe aracı ya da adsiedit konsolu üzerinden değiştirilebilir.
Powershell üzerinden yapmak için:
Öncelikle Active Directory Module for Windows PowerShell aracını yönetici modunda açmamız gerekmektedir.
Ardından aşağıdaki komutu çalıştırabiliriz:
Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ortacdemirel,DC=local” –Partition “CN=Configuration,DC=ortacdemirel,DC=local” –Replace:@{“tombstoneLifetime” = 365}
Yukardaki komutun sonunda yazan “365” sayısı silinen nesnenin tombstone kabında saklanma süresini belirlemektedir.
Domain bölümlerini kendi yapınıza göre değiştirmeniz gerekmektedir.
Adsiedit üzerinden yapmak ise bazı kullanıcılar için daha rahat olabilir:
Öncelikle adsiedit konsolunu server manager konsolundan açıyoruz.
“Configuration” bölümüne bağlanıyoruz.
CN=configuraiton,DC=ortacdemirel,DC=com altından CN=services > CN=WindowsNT ye geliyoruz ve CN=Directory Service i buluyoruz.
Üzerine sağ tıklayıp özelliklerini açıyoruz ve “tombstoneLifeTime” attribute unu buluyoruz. Burada yazan süreyi değiştirebiliriz.
SCOM 2012 R2 sunucunuza Active Directory yönetim paketini kurduğunuzda tüm domain kontrolcüler izlenmeye başlar eğer eski DC nize ait bir kalıntı var ise aşağıdaki uyarıyı alabilirsiniz:
AD Replication Monitoring : encountered a runtime error.
Failed to obtain the InfrastructureMaster using a well known GUID.
The error returned was: ‘Failed to get the ‘fSMORoleOwner’ attribute from the object ‘LDAP://dc.ortacdemirel.com/<WKGUID=2fbac1870ade11d297c400c04fd8d5cd,DC=ForestDnsZones,DC=ecortacdemirel,DC=com>’.
The error returned was: ‘The directory property cannot be found in the cache. ‘ (0x8000500D)’ (0x8000500D)
Bu uyarı içesinde, WKGUID’de yazan kimlik numarası eski DC nize ait bir kayıttır. Yapınızdaki tüm DomainDNSZone ve ForestDNSZone bilgisine de bu yanlış kayıt gitmektedir.
Yapınızdaki doğru ismi bulup bu isim ile değiştirirseniz sorununuz çözülecektir.
Öncelikle PDC rolüne sahip DC’nin üzerinde ADSIEDIT yönetim panelini açıyoruz.
“Configuration” bölümüne bağlanıyoruz.
SCOM 2012 R2 yönetim sunucusuna Active Directory Management Pack kurduktan bir süre sonra Domain Controller lar ile ilgili “The script AD Replication Monitoring’ encountered a permissions error” uyarısı ile karşılaşabilirsiniz.
Bu hatanın açıklaması ise aşağıdaki gibidir:
The script ‘AD Replication Monitoring’ encountered a permissions error. The script failed to update this DCs monitoring object in the naming context ‘DC=DomainDnsZones,DC=ortacdemirel,DC=com’ because access was denied. Alter the permissions for this naming context so that the script can add this container, or change the parameters for this script to stop monitoring this naming context.
The error returned was: ‘General access denied error’ (0x80070005)
Bu uyarı SCOM 2012 R2 tarafından Active Directory Users ans Computers konsolunda yaratılan “OpsMgrLatencyMonitors” kabına SCOM admin kullanıcımız tarafından erişilemediği için verilmektedir.
Öncelikle Active Directory Users ans Computers yönetim konsolundan gelişmiş özellikleri açıyoruz.
Ardından “OpsMgrLatencyMonitors” kabını buluyoruz.
Üzerine sağ tıklayıp güvenlik sekmesinden SCOM yönetici hesabımızı ya da hesaplarımızı ekleyip “Full Control” yetkisi veriyoruz.
