Exchange Server 2010 SP2 Microsoft download sayfasında yayınlandı. Daha önce SP2 ile birlikte gelecek yenilikler hakkında bilgi sahibi olmuştuk. Artık bunları PROD ortamlarımızda kullanabilir durumdayız.

Bana göre en önemli özelliklerden birisi farklı sitelardaki bulunan CAS sunucuları arasındaki silent redirection mekanizmasındaki gerçekleştirilen geliştirme.

Exchange 2007 ve SP2 öncesi 2010 ile birlikte birden fazla active directory site’ına sahip bir organizasyonda redirection mekanizması aşağıdaki gibi çalışmaktaydı;

Exchange 2010 organizasyonunda iki farklı internet facing CAS sunucusunun iki farklı active directory site’ında yer aldığını düşünelim.

Yukarıdaki gibi bir senaryoda iki farklı datacenter üzerinde bulunan CAS sunucular internet facing şekilde konfigure edilmiştir. Yani kullanıcı mail.datacenter1.com adresine girdiğinde ilk site üzerindeki CAS sunucusu kendisini karşılayacak, mail.datacenter2.com adresine girdiğinde ise ikinci site üzerindeki CAS sunucusu karşılama gerçekleştirecektir. Yapının bu şekilde çalışması için CAS sunucular için external url konfigurasyonlarının doğru yapılması gerekiyor.

Ancak eğer mail.datacenter2.com owa adresine bağlantı gerçekleştiren ancak mailbox’ı site 1 üzerinde tutulan bir kullanıcı için redirection mekanizması devreye girmektedir.

• Eğer site1 üzerindeki CAS sunucu için bir external URL adresi belirtilmediyse site2’deki CAS sunucusu istemciyi proxy ederek site1’e gönderecektir. Eğer site1 CAS IIS dizinleri için integrated authentication konfigurasyonu gerçekleştirildiyse kullanıcı SSO şekilde tek auth bilgisi girerek doğru site’a yönlendirilecektir.
• Ancak site1 üzerindeki CAS sunucuda external URL değeri null olarak konfigure edildiyse site2 CAS sunucusu istemciyi proxy yerine redirect mekanizması ile yönlendirecektir. Bu şekilde bir yönlendirmede kullanıcıya aşağıdaki gibi bir ekran çıktısı gösterilir.

Ancak bu şekilde bir yönledirmede ne yazıkki SSO mekanizması devreye girmeyecek ve istemciden bir kez daha auth bilgileri doğru CAS site için istenecektir.

SP2 ile gelen yenilikte ise bu şekilde bir senaryoda FBA auth mekanizması kullanılsa dahi (integrated dışında SSO desteklenmiyordu) SSO ile silent redirection’ın desteklendiğidir.

PowerShell içerisinde SAPI.SpVoice nesnesini oluşturarak çok rahatlıkla istediğiniz metni sesli olarak işitebilirsiniz.

Örneğin sabahları RSS feedlerinizi powershell ile dinleyebilir ya da indirdiğiniz bir dokumanı PowerShell’e okutabilirsiniz.

Aşağıda hazırladığım ufak örnekte powershell makine üzerindeki spooler servisini dinliyor ve durduğunu fark ettiği anda sizi sesli uyarıyor.

$Status = 0
$sunucuismi = hostname
Do {
 
$Servis = get-service “spooler”
 
if ($Servis.status -eq “Running”) {
 
Write-Host “”
 
} else {
 
$ses= new-object -com SAPI.SpVoice
$ses.Speak( "Hey Admin……. spooler service has stopped", 1 )
 
}
 
Start-Sleep 10
 
} Until ($Status -eq 1)

Lync Server 2010 topolojisi içerisinde Archieve sunucusu konumlandırdığınızda hazırladığınız policylere göre internal yada external IM trafiğini belirlediğini SQL Store üzerine arşivleyebiliyorsunuz.

Ancak arşivlenmiş  bu içeriği görüntülemek istediğinizde Lync Management Shell üzerinde aşağıdaki komutları çalıştırmanız gerekiyor;

Export-CSArchivingData -DBInstance lyncsql.domain.local\Default -StartDate 1/1/2011 -EndDate 10/10/2011 -OutputFolder “C:\ArchivingExports”

Export-CSArchivingData -DBInstance lyncsql.domain.local\Default -StartDate 1/1/2011 -EndDate 10/10/2011 -OutputFolder “C:\ArchivingExports” -UserURI “anilerduran@domain.local”

Görüldüğü gibi –DBInstance parametresi ile Lync Server 2010 topolojisindeki Back End sunucuya connection açılıyor. Bu noktada Topology Builder içerisindeki değerleri kullanmanız gerekiyor.

-StartDate ve –EndDate parametreleri ile export edilmek istenen arşivlenmiş içerik için tarih aralığı verebilirsiniz.

Output folder parametresi ile ise belirlediğiniz kriterlere göre export edilecek content için bir dizin belirliyorsunuz.

Eğer useruri parametresi belirtilmez ise var olan tüm kullanıcılar için arşivlenmiş içerik dışarı aktarılacaktır. Ancak bu parametre ile yalnızca spesifik bir kullanıcı için arşivlenmiş IM mesajlarına ulaşılabilir.

Lync Management Shell üzerinde çalıştırılan bu komut ile session bazlı içerikler dışarıya export edilecektir.

Ancak görülüğü gibi export edilen content .eml uzantılıdır. Internet Explorer üzerinde sorunsuzca bu içeriği görüntülemek için uzantıları .mht olarak değiştirmemiz gerekiyor.

Görüldüğü gibi arşivlenmiş bir içeriği tüm kullanıcılar yada spesifik bir kullanıcı için export etmek için bir kaç adımın ardarda gerçekleştirilmesi gerekiyor.

Bu noktada Lync Server 2010 ve arşiv yapısı kullanan organizasyonlarda kullanılmak üzere PowerShell ve Saphien PrimalForms kullanarak aşağıdaki gibi GUI tabanlı bir script geliştirdim. Tam araştırma imkanım olmadı fakat sanırım bu tip bir tool henüz internet üzerinde yok.

Tool basitçe seçtiğiniz tarih aralığında istediğiniz yada tüm kullanıcılar için contentleri getiriyor.

Select Lync Users menusune tıkladığınızda Get-CsUser bazı parametreler ile çalışarak ortamınızda bulunan ve Lync Enable edilmiş tüm kullanıcıları getiriyor. Herhangi bir kullanıcı seçtiğinizde ve Start Exporting tıkladığınızda alt bölümdeki pencereye export edilen ve localde kaydedilen tüm arşivlenmiş içerik listelenecektir.

Aynı zamanda bu dizindeki tüm .eml uzantıları .mht olarak değiştirilecektir.

Bu pencere üzerindeki herhangi bir satıra tıkladığınızda ilgili arşiv dosyası internet explorer üzerinde açılacaktır.

Aynı şekilde “Get Archieved Content for All Users” butonuna tıklarsanız girilen tarih aralığındaki tüm contenti getirecektir.

Herhangi bir user için eğer content yok ise status bar üzerinde bu size bildirilecektir.

Programı çalıştırmak için alt kısımda sunduğum ps1 uzantılı script içerisinde $LyncArchieveServer değişkeni içerisine ortamınızdaki lync arşiv sunucusunu yazmanız yeterlidir.

ps1 uzantılı dosyanızı Lync Management Shell içerisinden çağırmanız yeterli olacaktır.

Script ile ilgili tüm sorularınızı ve geliştirme isteklerinizi bana iletebilirsiniz.

www.anilerduran.com/scripts/Lync_Archive_Viewer.ps1

Lync Server ile organizasyonlar var olan voice altyapılarını Lync ile entegre hale çok daha kolay getirebiliyorlar. Ayrıca Lync Server 2010 ile birlikte önceki sürümlerde var olmayan bazı voice deployment geliştirmeleri bulunuyor. Bunları kısaca inceleyecek olursak;

Media Bypass

Lync Server 2010 ile birlikte Lync istemcisi mediation server ihtiyacı olmadan direk G.711 codec kullanarak IP PBX yada media gateway ile iletişime geçebiliyor. Bildiğiniz gibi mediation G.711 güncel codec bilgisini RTAudio’ya convert ederek Lync üzerine gönderebiliyordu. Buda totalde ses kalitesini arttırırken gecikme sürelerini azaltacaktır. Yükün azalması sebebiyle mediation sunucuyu front end ile collocate çalıştırabilir ve topolojide sunucu sayısında azalmaya gidilebilir.

Lync istemcisi sip sinyalini aynı şekilde mediation sunucuya gönderirken yalnızca media gönderimini direk gerçekleştirebiliyor. Özellikle sip protokolünü desteklemeyen pbx altyapınız var ise mediation rolü Lync ile pbx arasındaki çevrimi gerçekleştiriyordu.

Böylece Lync istemcileri SRTP üzerinden G.711 codec kullanabileceklerdir.

Routing

Eğer ortamınızda birden fazla IP PBX sunucusu yada Media Gateway’I var ise, önceki sürümlerde her bir endpoint için bir adet mediation sunucu rolünü dedice etmemiz gerekiyordu. Lync Server 2010 ile birlikte bu mimaride geliştirme gerçekleştirildi. Artık tek bir mediation sunucuyu birden fazla gateway yada ip-pbx ile konuşturabiliyoruz. Böylece topoloji içerisindeki mediation sunucu rolümüzü bir adet olarak tutabiliriz.

Survivable Branch Appliance

Uzak ofislerdeki Lync Enterprise Voice özelliğini kullanan istemciler, eğer WAN trafiğinde bir kesinti olursa, voice özelliklerini kullanamayacaklardır. Lync istemcileri disconnect olacak ve telefon aramalarını gerçekleştiremeyeceklerdir. Lync Server 2010 ile birlikte third-party media gaterway üreticilerinin sundukları box çözüm SBA, PSTN bağlı olarak çalışacak ve WAN hattında çıkan sorunlardan istemcilerin bağlı kalmalarını ve telefon aramalarını gerçekleştirebilmelerini sağlayacaktır.

Lync Server 2010 kurulu bir ortamda Lync Client kullanan istemcilerin domainde oturum açtıklarında istemcileri üzerinden otomatik logon olması tercih edilen bir senaryodur. Bu otomatik oturum açma senaryosunda, Lync Client sign-in adresinde yer alan domain ismi için belirlenen dns sunucularına bir SRV sorgusu gönderir. Siz ortamınızdaki DNS sunucularında 5061 TCP portunu kullanan ve Enterprise Pool isminiz / Standart Front End Sunucu FQDN’nizi point eden host ( A ) kaydını point edersiniz. Böylece lync istemci srv sorgusu sonucunda gerekli olan lync sunucu adresini öğrenerek single-signon ile oturum açma işlemini tamamlar.

Ancak kullanıcıların oturum açmak için kullandıkları sip uri leri (ör: mail adresi domain uzantıları) iç ortamda kullandığınız domain isminizle aynı olmayabilir. Örneğin domain ortamınızda kullandığınız domain ismi domain.local konfigure edilmişken, mail adresleri domain.com olarak ayarlanmıi, bu sebeple lync sign-in adresleride domain.com olarak enable edilmiş olabilir.

Bu noktada Lync istemcisi domain.com adresi için srv kaydına bir sorgu gerçekleştirecek ve başarısız olacaktır. Bu noktada otomatik oturum açma işleminin aynı şekilde devam edebilmesi için domain.com external adresini iç dnslerinizde de çözebilmeniz gerekiyor. Split-Brain DNS yapısı olarak adlandırılan bu senaryoda iç DNS üzerinde domain.com isimli bir zone açmalı ve ilgili SRV kayıtlarını bu zone altında tanımlamalısınız. Dikkat edilmesi gereken nokta, DNS üzerindeki herhangi bir domain ismi için zone açıldığında bu dns’in bu domain için artık authorative olacağıdır. Yani içerideki istemcileriniz www.domain.com gibi bir adrese gitmek istediklerinde asla dış dnslerde cevap aramayacak, iç dns’inizde bu isimde bir zone olduğu için EVET yada HAYIR cevabını bu dns’den talep edecektir. Bu sebeple public tarafta da kullanılacak kayıtların iç dnsde oluşturulan zone altında tanımlanması gerekiyor.

Benzer senaryo birden fazla sip domain kullanılacak ise de uygulanabilir. Örneğin organizasyonunuzda mail adreslerinde birden fazla domain kullanıyor olabilirsiniz. Exchange Server üzerinde oluşturduğunuz adres poliçeleri ile farklı kullanıcı yada departmanlara domain1.com domain2.com gibi adresler dağıtıyor olabilirsiniz. Kullanıcıların Lync istemcilerine eynı adres ile otomatik sign olabilmesi için;

1) Lync Server pool özelliklerinde additional sip domain eklenmesi gerekli;

2) DNS üzerinde her bir sip domain için zone açılmalı ve srv kayıtlarının düzenlenmesi gerekli.

Bu iki işlemden sonra her bir sip domain için başarılı otomatik oturum açma işlemleri gerçekleşecektir.

Birden fazla domain controller olan organizasyonlarda, herhangi bir dc üzerinden restore işlemi gerçekleştirildiyse yada P2V ile fiziksel ortamdan sanal ortama bir taşıma gerçekleştirilirse, NTFRS source içerisinde olay görüntüleyecisine 13559 hata kodlu ve aşağıdaki uyarıyı içeren bir olay düşebilir.

The File Replication Service has detected that the replica root path has changed from "c:\winnt\sysvol\domain" to "c:\winnt\sysvol\domain". If this is an intentional move then a file with the name NTFRS_CMD_FILE_MOVE_ROOT needs to be created under the new root path. This was detected for the following replica set: "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" Changing the replica root path is a two step process which is triggered by the creation of the NTFRS_CMD_FILE_MOVE_ROOT file. [1] At the first poll which will occur in 5 minutes this computer will be deleted from the replica set. [2] At the poll following the deletion this computer will be re-added to the replica set with the new root path. This re-addition will trigger a full tree sync for the replica set. At the end of the sync all the files will be at the new location. The files may or may not be deleted from the old location depending on whether they are needed or not.

Bu spesifik domain controller üzerinde görüldüğü gibi sysvol replikasyonu çalışmamaktadır. Bu işlemi tetiklemek için yapılması gereken oldukça basit.

Sorunlu olan domain controller üzerinde c:\windows\sysvol klasörü altına inerek NTFRS_CMD_FILE_MOVE_ROOT isimli uzantısız bir klasör oluşturulur.

Bu domain controller üzerindeki file distribution servisini yeniden başlattığınızda bu dosya otomatik olarak silinecek ve replikasyon tetiklenecektir. 5 dakika içerisinde replikasyonun durumunu içeren olaylar olay görüntüleyicisine düşmeye başlayacaktır.

Lync 2010 Client üzerinde adres defteri güncelleştirmeleri sırasında Sync problemleri yaşıyor olabilirsiniz. Sorun çözümü için Lync üzerindeki adres defteri senkronizasyonları hakkında kısa bilgilendirmeler yapalım.

• Active Directory üzerinde kullanıcı objeleri üzerinde gerçekleştirilen değişiklikler otomatik olarak 60 saniyede bir LS User Replicator tarafından senkronize edilir. Bu bilgiler otomatik olarka back-end SQL veritabanına yazılarak pool için assign edilir.
• Her 24 saatte bir LS Address Book Server en güncel bilgiyi SQL veritabanından çekmek için gerekli aksiyonu gerçekleştirir ve bu bilgileri adred defteri dosyalarına yazar.
• Lync Client random bir aralıkta Lync Server üzerinde bulunan pool paylaşımından download ederler. Böylece istemcilerin kendi profilleri içerisinde bulunan GalContacts.db cache dosyası güncellenir.

Bu noktada sorun gidermek adına temel iki bilgiyi çekmeniz gerekmektedir. Bunlardan birincisi replikasyon bilgisini gösterirken ikincisi Address Book konfigurasyon bilgisini gösterecektir.

Get-UserReplicatorConfiguration

Get-CsAddressBookConfiguration

Komut çıktılarında varsayılan olarak 01:30 AM ‘de replikasyonun çalıştığını görebilirsiniz.

Eğer yukarıda bahsettiğim gibi her 60 saniyede bir otomatik gerçekleşen replikasyon gerçekleşmez ise manuel bir tetikleme uygulayabilirsiniz.

Update-CsAddressBook

BU komut çalıştırıldıktan 5 dakika sonra Event Viewer içerisinde Source = LS Address Book Server tanımlı ve adres defteri güncelleştirmelerinin görüntülendiği bilgi uyarıları düşecektir. Bu uyarılar içerisinde update edilen contact objeleri detaylı şekilde yer alacaktır.

Istemcilerin Update Edilmesi:

Sunucu tarafında gerçekleştirilen güncelleştime sonrasında istemci tarafında halen adres defteri güncelleştirmelerinde problem yaşanıyorsa, local lync client üzerinde de bazı aksiyonlar alabilirsiniz.

Lync Client tarafında adres defterinin download edilmesi random bir aralıkta gerçekleştirilir. 1dk ile 60dk arasındaki bu aralık test için sıkıntı yaratabilir. Bu takdirde download işlemini tetiklemek için HKLM\Software\Policies\Microsoft\Communicator altında GalDownloadInitialDelay isminde bir REG_DWORD anahtarı oluşturularak değeri 0 atanır.

Bunun dışında %userprofile%\App Data\Local\Microsoft\Communicator\sip<kullaniciismi> altında bulunan GalContacts.db ve GalContacts.db.idx dosyaları silinir.

Lync Client yeniden açıldığında adres defterini download ederek bu dosyaları yeniden oluşturacaktır.

Internal – External URL kontrolleri

Lync Server 2010 IIS üzerinde Default Web Site altında bulunan External ve Internal directoryler aracılığı ile internal ve external istemcilere adres defterini dağıtmaktadır. BU noktada ilgili directory izinlerini kontrol edebilirsiniz. Problem çözümü için Lync Topology Builder içerisinde pool özelliklerinde internal ve external URL’lerinizi kontrol etmenizde faydalı olacaktır.

internal tarafta 80 – 443 ‘den, External tarafta ise 8080-4443’den erişilen bu dizinlerde var olan sertifikanın yüklü olması ve valid olarak gözükmesi önemlidir. Adres defterinde yaşanan problemlerin bir çoğunda doğru planlanmamış sertifika altyapısı görülmektedir.

Dün akşam saatlerinde MVP Global programından aldığım mail ile 2011 yılında da , bir önceki yılda gerçekleştirdiğim çalışmalarımdan ötürü Microsoft tarafından System Center Configuration Manager alanında MVP ( Most Valuable Professional) seçildiğimi öğrendim.

Bu kadar önemli bir ünvanı kazanmayı ikinci kere hak etmek oldukça gurur verici. Destekleyen herkese, özellikle kardelenime teşekkürler.

Türkiye’deki ilk System Center Configuration Manager 2012 eğitimi!

Beta 2′si download’a sunulan ve yıl sonunda RTM sürümünün çıkması beklenen System Center Configuration Manager 2012 ürünü için Türkiye’deki ilk dünyada ise sayılı sunulan bu eğitim fırsatını kaçırmayın, ilk SCCM 2012 uzmanları siz olun.

Çok uluslu bir çok Enterprise yapıda System Center Configuration Manager projesi gerçekleştiren ve EMEA bölgesinde sayılı SCCM MVP’lerinden Anıl ERDURAN tarafından gerçekleştirilecek bu eğitim ile hem System Center Configuration Manager altyapısı saha proje deneyimleri aktarılarak detaylı bir şekilde incelenecek, hem de 2012 versiyonu ile birlikte sunulan önemli yenilikler uygulamalı anlatılacaktır.

Laboratuvar ortamında sanal makineler üzerinde gerçekleştirilecek bu iki günlük eğitimin son bölümünde SCCM 2007 / SCCM 2012 migration projesi gerçekleştirilecektir.

Sizde kaydınızı yaptırın, Türkiye’deki ilk SCCM 2012 uzmanları olun!

Sınırlı sayıda kontenjan bulunmaktadır.

Site hiyerarşisindeki yenilikler ( Single / Multi Site mimarileri)

- SCCM 2012 sunucu rolleri

- SCCM 2012 kurulumu

- Configuration Manager 2012 konsolu

- Role-Based Administration

- Application Catalog ve Software Center

- Client Operations

- Operating System Deployment

- Mobile Device Management

- Software Distribution

- Reporting

- SCCM 2007 / SCCM 2012 Migration işlemi

Eğitmen öz geçmişi:

İstanbul doğumlu olan Anıl Erduran üniversite eğitimi ile birlikte sektörde çeşitli kurumlarda sistem uzmanı/mühendisi pozisyonlarında görev yapmıştır.

Bilge Adam Kurumsal bünyesinde Sistem ve Platform biriminde Danışman ve teknik eğitmen olarak görev aldıktan sonra şu anda Data Market bünyesinde Kurumsal Sistemler Danışmanlık Birim Yöneticisi olarak görev yapmaktadır. Deneyimli bir danışman kadrosu ile birlikte Microsoft Altyapı ürünleri ile ilgili tüm proje fazlarından sorumludur.

Boş zamanlarını sıkıntısı çekilen Türkçe kaynak eksikliğini gidermek adına kullanan Anıl ERDURAN www.anilerduran.com adresinde 600’den fazla teknik yazı, Türkiye’deki ilk SCCM 2012 webcast ve makalelerini yayınlamıştır. Bu blogla birlikte çeşitli toplululuklarda yazılar/makaleler yazmakta, seminerler vermekte ve Mshowto.org bilişim portalında editörlük görevine devam etmektedir.

Aynı zamanda 2010 yılı içerisinde System Center Configuration Manager alanında gerçekleştirdiği paylaşımlar,mshowto.org ile birlikte hazrlanan makale,webcast serilerinin sonucunda Microsoft tarafından SCCM alanında Türkiye’deki En Değerli Profesyonel ( MVP) unvanına layık görülmüştür. https://mvp.support.microsoft.com/default.aspx/profile/anıl

Anıl ERDURAN aşağıdaki sertifikalara sahiptir;

Microsoft Certified Systems Engineer: Messaging
Microsoft Certified Systems Administrator: Messaging
Microsoft Certified Systems Administrator: Security
Microsoft Certified Systems Engineer: Security
Microsoft Certified Systems Engineer
Microsoft Certified Systems Administrator
Microsoft Certified Professional
MCTS System Center Configuration Manager, Configuration
MCTS Windows Server Virtualization, Configuration
MCTS Microsoft Exchange Server 2007: Configuration
MCTS Microsoft Windows Vista: Configuration
MCTS Windows Server 2008 Active Directory: Configuration
MCTS Windows Server 2008 Network Infrastructure: Configuration
MCTS Windows Server 2008 Applications Infrastructure: Configuration
MCTS Microsoft Internet Security and Acceleration (ISA) Server 2006, Configuration
MCTS Microsoft Forefront Client and Server: Configuration
MCITP Enterprise Administrator
MCITP Server Administrator
MCT Microsoft Certified Trainer
CCNA Cisco Certified Network Associate
JNCIA-ER Juniper Networks Certified Internet Associate

MVP | System Center Configuration Manager

Sanallaştırma furyası sonrasında son günlerin popüler konularından bulut bilişim. Her yerde yazılanlar çizilinler, karar verici noktalarda bulunanlar için toz ve buluttan oluşmuş bir beyin fırtınasını andırıyor.

Bu noktada var olan IT organizasyonun uçtan uca kavranması, süreçlerin analizi ve tüm bu mantıksal yapılarında bulut bilişim ile kombine olduğunda getireceklerini iyi kavramak gerekiyor.

Kısaca “Neden bulut bilişim tercih edilmeli ?” gibi bir soruya verebileceğimiz cevapları listeleyelim.

- Günümüzdeki geleneksel IT modellerinde ihtiyaç duyulan altyapı ve teknolojiler için belirli bütçelerin ayrılması gerekiyor. Bu konuda yaşanan sıkıntı aylık, yıllık yada kullanıcı başına olması yerine yeni teknoloji ya da altyapı başına harcamaların gerçekleştirilmesi. Bulut tarafında ise herhangi bir altyapıya yada ürüne ödeme yapılmamaktadır. Bunun yerine aylık, kullanıcı başına operasyonel bütçelerin dışında tutabileceğiniz aplikasyonlarınızı çalıştırabilirsiniz.

- Sürekli online olabilme, mobilite bulut bilişim tercihinde göz önünde bulundurulması gereken bir nokta. Mobil kullanıcılarınız ofis bağlantılarını kopardıklarında dahi mobil cihazları ile buluta sürekli bağlı kalabilmekte, verinin iletimi daha kesintisiz yaşanabilmektedir. Windows Phone tarafındaki full entegrasyon özellikleri bulut servislerinin kullanımını çok daha efektif kılmaktadır.

- İş risklerinin minimize edilmesi. Bulut servislerine erişebilirlik seviyesinde bulut servis sağlayıcı tarafında sunulanlara bağlı olarak günümüzle karşılaştırıldığında önemli geliştirmeler bulunuyor. Devasa farmlar üzerinde, yüksek erişilebilirlik çözümleri ile donatılmış bir altyapıya sahip olan sağlayıcı tarafında erişilebilirlik seviyesinde risklerin ne kadar azalacağını tahmin edebilirsiniz. Aynı durum veri kaybedilmesi noktasında da göz ardı edilemez seviyededir. Birden fazla replike edilmiş ve bütünlüğü garanti edilmiş verileriniz sayesinde, kendi içinizde gerekli altyapıya sahip olmadan faydalanma imkanına sahipsiniz.

- Dinamik büyüme. IT organizasyonlarının neredeyse hepsi ihtiyaçları karşılamak için IT altyapılarını büyütmek zorunda kalmaktadırlar. Bu noktada hizmet verilecek kullanıcı sayısı, sunucu sayıları, kullanım oranları gibi birçok parametre devreye girer. Tüm bu analizlerden sonra her teknoloji yükseltme projesinde ayrı kapasite planlamaları yapılıp sancılı geçişlerin gerçekleştirilmesi gerekir. Bulut bilişimde ise yapılması gereken sadece ihtiyacın iletilmesi. Bulut servislerinde dinamik olarak büyüme ne kadar kolay ise, ihtiyaç fazlası servislerinde devre dışı bırakılması o kadar kolaydır.

Operations Manager 2007 yedekleme stratejisinin en önemli noktalarından birisi Root Management Server anahtarının başarılı bir şekilde yedeklenmesidir. Özellikle Run As hesaplarında yapılan değişikliklerden sonra bu yedekleme işleminin tekrarlanması önerilir. Bildiğimiz gibi Management Group içerisindeki Run As hesapları bu anahtar içerisinde saklanmaktadır. GUI tabanlı yedekleme dışında komut satırı kullanılarak da hızlıca yedekleme işlemi gerçekleştirilebilir.

C:\Program Files\System Center Operations Manager 2007 > securestoragebackup backup D:\RMSBackup\01-01-2011\Backup.bin

Bu komut satırı sonrasında koruma parolası girilerek işlem tamamlanır.

Herhangi bir fiziksel sunucu birden fazla CPU barındırsa dahi rahatlıkla bir virtualization host görevi görebilir. Bu sunucu üzerinde Hyper-V rolünü sıkıntı olmadan aktif edebilmeniz gerekmektedir.

Ancak gerçekleştirdiğim bir Hyper-V kurulumunda Hyper-v’nin bir hassasiyetini öğrenmiş bulundum.

Bir sunucu üzerinde iki farklı Intel işlemciniz var olduğunda, bunların Ghz’lerine kadar tüm değerleri esiş olsa dahi Hyper-V rolünün kurulumundan sonra boot ekranı geçemediğinizi farkedebilirsiniz.

Bunun sebebi bu CPU’ların revision numaralarınında aynı olması zorunluluğu. WMI querylerini kullanarak

Select * from win32_processor sorgusunu gerçekleştirdiğinizde bu bilgiyi rahatlıkla edinebilirsiniz.

Kendi makinemdeki powershell üzerinde ilgili wmi sorgusunun çıktısı ve revision değeri:

SCOM üzerindeki unseal management packlerinizi, üzerlerinde customization gerçekleştirmek için export etmek isteyebilirsiniz. Bu durumda Operations Manager Shell yani PowerShell cmdletlerini kullanarak tüm export işlemini tek bir script ile gerçekleştirme imkanınız bulunuyor.

Aşağıdakine benzer bir script işimizi görecektir.

$all = Get-ManagementPack | where-object {$._Sealed –eq $false}

foreach ($mp in $all)

{

Export-ManagementPack –managementpack $mp –path “c:\MyMps”

}

Aşağıdaki rastlanan problemi dikkate alarak CU4 paketini geçmeyi unutmayın.

***Caution: There is a known issue documented in the KB article where applying this CU4 on existing OpsMgr agents can cause an unexpected restart of several non-OpsMgr services. This is caused by the Server 2008 Windows Installer RestartManager trying to suppress a reboot as we attempt to update a locked file. This can potentially cause application outages as the services for other Microsoft core OS components and some 3rd party application services might be restarted. This only affects agents running Windows 2008 and Windows 2008 R2. For this reason, you might consider skipping this update and waiting for CU5. Or, consider applying this update ONLY to your OpsMgr server roles, and rejecting any agent updates until the next CU. Here is the actual text from the KB:

Restart of non-Operations Manager services
In certain cases, non-Operations Manager services may be restarted when the Operations Manager agent is updated. This issue only affects computers that are running Windows Server 2008 or Windows Server 2008 R2. We recommend that you update agents at a time when a service restart or a server restart is acceptable. Or, only update agents that are experiencing one or more of the agent-related issues that are mentioned in the list of resolved issues. This issue will be addressed in an upcoming cumulative update. </LI>

Lync Server Product Team’in bildirdiğine göre Lync 2010 ile birlikte monitoring, archiving ve front-end sunucularda veritabanı olarak SQL Server 2008 R2 kullanılabilir durumdadır. Yalnızda Group Chat veritabanı için henüz destek duyurusu yapılmamıştır.

SCCM 2007 ile OSD projelerimin birisinde rastladığım ilginç bir problem.

SCCM içerisindeki OSD yeteneklerini kullanarak sunucu işletim sistemi kurulumlarını otomatize ederken, belirli tipteki sunucular üzerinde Task Sequences’ın belirli bir adımında aksiyon alarak Hyper-V rolünün yüklenmesi gibi bir istek geldi.

Özellikle Hyper-V sanallaştırma mimarisi kullanan bir datacenter için gerçekleştirilecek OSD projelerinde sıklıkla gelebilecek bir talep.

Bu noktad eminim ki sizinde akınıza benimle benzer yöntemler gelmiştir.

• ServerManagerCmd komut satırını kullanarak rolün kurulması
• PowerShell cmdlet lerin kullanılarak rolün kurulması

OSD’den bağımsız düşündüğümüzde iki yöntem ile de gayet sıkıntısız biçimde istediğini rolleri otomatize edilmiş şekilde kurabiliyorsunuz. İlginç olan ise SCCM Task Sequence ekranın powershell yada command prompt çağırılarak ilgili komutlar çalıştırıldığında ne yazık ki başarılı olunamaması.

Sebebini uzunca süre araştırmama rağmen kesin bir sonuç elde edemedim. Bu problemi yaşayan bir başka SCCM MVP’lerine de rastlayınca başka bir metod bulunması gerektiğini karar verdim.

Bu noktada işimizi şimdilik görebilecek tek yol DISM.exe yani Windows Servicing tool.

OSD task sequence içerisine aşağıdaki komut satırını post-installation kısmına eklediğiniz takdirde rol başarılı bir şekilde yüklenecektir.

cmd /c Dism.exe /image:%OSDTargetDrive%\ /Enable-Feature /FeatureName:Microsoft-Hyper-V /LogPath:%_SMSTSLogPath%\Hyper-V.log

Bildiğiniz gibi SCCM ürününün en güçlü yanlarından birisi işletim sistemi dağıtımı. 2012 mimarisinde buda dair önemli geliştirmeler bulunuyor.

• Artık wim imajlarınıza Component Based Servicing ile Windows updatelerini uygulayabiliyorsunuz. Bu imajların dağıtım için library’de durması buna asla engel teşkil etmiyor.

• Task Sequence sihirbazı, prestart komut dosyaları eklenmesi için ayrı stepler barındırıyor.

• Aynı Task Sequence medyasını kullanarak, hiyerarşi içerisindeki tüm bilgisayarlara işletim sistemi dağıtımını gerçekleştirebilirsiniz.

• USMT 4.0 desteklenmektedir.

• PXE Service Point ve içerisindeki tüm konfigurasyon verileri artık Distribution Point üzerinde yer almaktadır.

Mobile cihazların yönetimine SCCM 2012’de daha fazla ağırlık verildiğini rahatlıkla söyleyebiliriz. Bu bağlamda native olarak iki yeni site rolü bulunuyor.

Mobile Device Enrollment Proxy Point

Mobile Device AMT Enrollment Point

Configuration Manager’ın bir cihazı enroll etmesi için Management Point, Distribution Point, AMT ve Mobile Pointler üzerinde IIS ‘in konfigure edilmesi ve ilgili sertifikanın bu rolleri barındıran sunuculara import edilmesi gerekmektedir. Önceki postlarımdan hatırlayacağınız üzere internet üzerinden istemci yönetiminde ve mobile istemcilerin yönetiminde mutlaka https üzerinden iletişim sağlama zorumluluğu SCCM 2012’de bulunmaktadır.

Aynı şekilde bu noktada istemcilerin kendi mobile cihazları, oluşturulan bir web sertifikası ile wipe etmeleri sağlanabilir.

Automatic Discovery için dns içerisinde oluşturulan kayırları ve Management Point ve Distribution Point üzerinde gerçekleştirilenkonfigurasyonlar ile mobile cihazların enrollment processleri oldukça kolaylaştırılmıştır.

Exchange Server Connector

2012 içerisinde yer alan Exchange Server Connector ile birlikte Exchange Server ‘a bağlanmış mobile cihazları otomatik olarak discover edip manage edebilme şansına sahipsiniz. bu noktada arka planda tamamiyle Active Sync protokolü kullanılmaktadır. Özellikle Configuration Manager istemcisinin yüklenemediği mobile cihazlar için oldukça faydalı bir özellik. Tabii bu noktada istemciler hem Exchange mimarisi üzerinde hem de Configuration Manager mimarisi üzerinden cihazlarını wipe edebilme şansına sahip olacaklardır.

SCCM 2012 tarafında istemci deployment ve operasyonlarında var olan değişikliklerden bahsedecek olursa;

Client Operations

Artık istemciler mixed mode yada native mode bir site sunucuya bağlanmak yerine PKI sertifikaları ile istenilen site server rolüne HTTPS bağlantısı gerçekleştirebiliyor. SCCM 2007’de olduğu gibi kurulum sırasında site sistem modunu seçme zorunluluğunuz bulunmuyor. Client özelliklerinde konfigur edebileceğiniz bu yöntem sayesinde istemciler en uygun iletişim metodunu kendileri otomatik olarak seçmektedirler.

Tabii ki artol mixed mode ya da Native Mode olmadığı için client kurulumlarında kullanılan /native parametreside aynı şekilde kullanılabilir değildir. Bunun yerine /UsePKICert parametresi kullanılarak eğer istemci gereksinimleri sağlıyorsa sertifika tabanlı https üzerinden site sistem rolleri ile haberleşmesi sağlanabiliyor. Eğer bu parametre kullanılmaz ise istemci varsayılan olarak http üzerinden haberleşme sağlayacaktır.

Tabii ki bir PKI altyapısından söz ediyorsak CRL publishing durumlarınıda kontrol etmeniz gerekmektedir. Eğer istemci, sertifika otoritesi için crl check gerçekleştiremez ise https üzerinden bağlantı sağlayamayacaktır. Bu takdirde isterseniz /NoCRLCheck parametresini kullanarak bu kontrol aşamasını atlayabilirsiniz.

Client Assigment

SCCM 2007’de eğer istemci bir boundary içerisine dahil değilse, otomatik site assigment işlemi bu istemci için başarısızlıkla sonuçlanıyordu. SCCM 2012’de eğer bir fallback site konfigure ederseniz, istemci boundary içerisinde yer almasa dahi otomatik olarak assign edilecektir.

Collections

Collection tarafında iki yeni node’unuz bulunuyor. User ve Device isimli bu collectionlar sebebi ile artık hem kullanıcı kaynaklarını hem de cihaz kaynaklarını aynı collection içerisinde barındırma şansınız bulunmuyor.

Collection tarafında rastladığım diğer bir yenilik ise artık sub collectionların oluşturulamaması. Bunun sebebi ise collection hiyerarşisi içerisindeki folder mimarisi. Artık Collectionları barındırmak için hiyerarşi tepesinde klasör oluşturma şansınız bulunuyor.Bu collectionlar içerisinde de 2012’de tanıtılan include ve exclude kurallarını kullanarak content bazlı filtreleme yapabilme imkanına sahipsiniz.

Power Management

SCCM 2007 R3 ile birlikte gelen  ve SCCM 2012’yle birlikte daha da geliştirilen Power Management özelliği sayesinde organizasyon dahilinde güç planları oluşturularak önemli ölçüde elektrik tasarrufu sağlayabiliyorsunuz. Bununla ilgili gerçekleştirdiğim webcast ve yazdığım makalelerde de bahsettiğim gibi, bir süre var olan raporlar ile analizler gerçekleştirilip ardından güç planlarınızı SCCM istemcilerinize publish edebiliyorsunuz.

SCCM 2012’de Power Management tarafında bazı artılar var.

İzin verildiği takdirde artık istemcileriniz, Power Management özelliğini kullanmamaları için kendi cihazlarını exclude edebilme şansına sahipler.

Aynı şekilde siz de ortamda bulunan sanal makineleriniz native olarak exclude edebiliyorsunuz.

SCCM 2012 ile birlikte hiyerarşi tarafındaki yenilikleri incelemeye devam edelim.

SCCM 2012 organizasyonunda daha öncede bahsettiğimiz gibi, secondary site kurulumlarını kurulum sihirbazı yerine SCCM konsolu içerisinden gerçekleştirebiliyorsunuz. Bunun dışında SCCM 2007 ‘den aşina olduğumuz Default Management Point kavramıda kaldırılmış bulunuyor.

Artık organizasyon içerisinde, aynı sitelarda dahi, birden fazla Management Point kurulumunu gerçekleştirdiğiniz takdirde, istemciler network lokasyonlarına göre yada HTTP / HTTPS kullanımlarına göre en uygun Management Point seçimini gerçekleştirebilirler. Böylece tek bir site içerisinde yüksek sayıda istemci yönetimi kolaylıkla sağlanabilir. Eğer istemciler üzerinde önceden tanımlanmış bir sertifika yok ise otomatik olarak bu gereksinimi duymayana Management Pointlere bağlantı gerçekleştirirler.

Kaynakların discover edilmesiyle birlikte oluşan DDR kayıtları organizasyon içerisindeki tüm sitelara veritabanı replikasyonu ile gönderilmektedir.

Benzer yenilikler backup ve recovery teknolojilerinde de bulunuyor. Artık recovery işlemleri sırasında birçok opsiyon seçebilme şansına sahipsiniz. Örneğin recover işlemi sırasında yalnızca site server’ı , yalnızca SQL Server’ı yada her ikisini birden recover edebilme imkanınız bulunuyor. Böylece SQL Server’ı destekleyen yeni bir sunucuya var olan SQL veritabanını recover edebiliyorsunuz.

Recovery işlemlerinde de kurulumda olduğu gibi unattended bir installation script oluşturulabilir bilir ve setuo  komutunda /script parametresi kullanılarak katılımsız recovery işlemleri gerçekleştirilebilir.

SCCM 2012 ile birlikte SCCM 2007’deki site hiyerarşisi oldukça değişti. Önceki postlarımda bahsettiğim gibi aşina olduğumuz Primary Site ve Secondary Site dışında Central Administration Site ismini verdiğimiz bir site tipimiz daha mevcut. Site tipleri postunda bununla ilgili ayrıntılı bilgileri edinebilirsiniz.Bu post içerisinde değişen hiyerarşiden birazcık bahsetmek istiyorum.

CAS kurulumları özellikle büyük ölçekli yapılar için Microsoft’un düşündüğü bir site tipi.Eğer kurulum sırasında bir CAS kurulacağını belirtirseniz, ileride bu site aracılığı ile birden fazla primary site açabilme şansına sahip oluyorsunuz.

Eğer kurulum sırasında CAS kurmaz iseniz, o zaman ortama kattığınız ilk siteınız primary site oluyor ve bunun dışında bir primary site kurabilme imkanınız bulunmuyor.

Bu noktada CAS’ın temel görevi hiyerarşinin en tepesinde yer alarak tüm yönetim ve raporlama faaliyetlerinden sorumlu olmaktır. Dikkat edilmesi gereken önemli bir nokta , CAS’ın asla istemci assigmentlarını kabul etmemesi hatta istemciler ile direct bir iletişime geçmemesidir.

Tabii ki kısıtlı görevleri olduğu için üzerinde de yalnızca belirli rolleri barındırmaktadır.

Hiyerarşi tarafında sitelar arasındaki iletişimde iki yenilik bulunuyor.

1. Site-To-Site iletişimlerde file-based  replikasyona ek olarak aynı zamanda database replikasyonu da kullanılmaktadır. Secondary sitelar için de gereksinim olarak sunulan SQL ihtiyacı sebebi ile artık her site altında tüm hiyerarşi ile ilgili verileriniz database replication ile güvenli bir şekilde bulunmaktadır.
2. Artık Configuration Manager 2012, site bilgisini trusted diğer forestlar içerisine de publish edebiliyor. Özellikle SCCM 2007’de diğer forestlardaki istemcilerin yönetilmesinde yaşanan sıkıntılar 2012 sürümünde publishing teknolojisi sayesinde problemsiz gerçekleşebiliyor.

Son olarak site sistem rollerinden bahsetmemiz gerekiyor. SCCM 2012 ile birlikte artık kullanılmayacak rollerimiz mevcut. Bunlardan ilki Reporting Point. Reporting point tüm fonksiyonalitesini Reporting Services Point ‘e aktararak SQL Reporting Services ile daha entegre bir raporlama mekanizmasını bize sunuyor. Emekliye ayrılan bir diğer rol ise PXE Service Point.

Özellikle işletim sistemi dağıtım senoryalarının olmazsa olmazı PXE Service Point rolü, network üzerinde PXE destekli istemcilerin network üzerinden boot edilerek ilgili imajlara bağlanmasını sağlıyordu.SCCM 2012 ile birlikte bu rolün tüm görevleri artık distribution point üzerinde bulunuyor.

Emekliye ayrılan rollerin dışında yeni eklenen roller de mevcut.

Application Catalog Website Point: IIS gerektiren bu roller istemcilerin aplikasyonları edindiği yeni özellik olan Software Center’ı desteklemektedir.

Mobile Device Proxy Enrollment Point : Aynı şekilde IIS gereksinimi duyan bu rol ise mobil cihazlardan gelen enrollment isteklerinin cevaplanması ve bu processlerin tamamlanmasını sağlamaktadır.

SCCM 2012 tarafındaki yenilikleri adım adım incelemeye devam edelim.

Configuration Manager 2012 konsolu içerisinde de önemli değişiklikler bulunuyor.

• Artık Administration, Software Library Monitoring gibi workspacelerin içerisinde mantıksal gruplandırmalar gerçekleştirebilirsiniz.

• Role-Based Administration sayesinde ilgili kullanıcı konsol içerisinde yalnızca kendisine atanan izinler dahilindeki objeleri görebilmektedir.

• Geliştirilmiş arama fonksiyonları ile konsol içerisinde istediğiniz objelerin aranması çok daha kolay ve hızlı bir şekilde gerçekleşmektedir.

• Aynı zamanda otomatik oluşturulan geçici nodelar ile aksiyonları çok daha hızlı alabilirsiniz ve konsolu kapadığınızda ilgili nodelar ve altındaki bilgiler de otomatik olarak tekrardan görüntülenmemek üzere silinecektir.

SCCM 2012 ile birlikte gelen yenilikleri incelemeye devam ediyoruz.

SCCM ile birlikte daha setup aşamasındayken önemli yenilikleri farkedebiliyoruz.Setup ekranında karşımıza çıkan yeni özellikler ile SCCM 2012 hiyerarşisini düzenleme şansına sahip oluyoruz. Bunlardan ilki Central Administration Site. İleride hiyerarşi tarafındaki yeniliklerden bahsederken değineceğimiz bu site tipi artık primary secondary dışında ayrı bir opsioyon olarak karşınızda. Çok temel olarak üst seviyede yer alarak primary sitelar arasındaki replikasyonu sağlıyor.

Aynı zamanda setup sırasında lokalde veya remote bir sunucuda kullanılmak üzere management point ve distribution point rolleri kurulabiliyor.

Bana göre en önemli yenilik secondary site kurulumu sırasında.SCCM 2007’de uzak ofislerdeki istemcilerin yönetimini sağlamak için gereksinim duyulabilen secondary siteların kurulumu için , ilgili sunucu üzerinde SCCM setuo uygulamasının çalıştırılması gerekliydi.SCCM 2012 ile birlikte secondary site kurulumları SCCM konsolu içerisinde var olan bir link ile çok daha hızlı ve kolay bir şekilde sağlanabiliyor.

Ayrıca konsol kurulumu için ve kurulum öncesini ihtiyac duyulan dosyaların indirilmesi için iki farklı standalone aplikasyonumuz bulunuyor. Bunun için SCCM setup’ını ilgili makinede çalıştırma ihtiyacı ortadan kalkmış bulunuyor.

Configuration Manager 2012 ile birlikte site hiyerarşisinde de önemli değişiklikler bulunuyor. Bunların en önemlisi Central Administration Site’ın sunulması ve primary / secondary sitelar üzerinde gerçekleştirilen yenilikler.

Bir diğer yenilik site site-to-site iletişimde artık database replication’ın kullanılması ve site bilgilerinin trusted forestlara publish edilebilmesidir.

Site tiplerinin özelliklerini incelersek;

Central Administration Site

Hiyerarşi içerisinde intersite data replikasyonunu yöneten site’dır. Bunun için arka planda çalışan database replikasyon teknolojisini kullanır. Tüm raporlama ve yönetim aksiyonları için kullanılabilir. Site hiyerarşisinin en tepesinde yer alır.

Configuration Manager 2007’de olduğu gibi;

- İstemci datalarını process etmez

- Client Assigmentlarını kabul etmez

- Tüm site sistem rollerini desteklemez

- Database replication kullanır.

Primary Site

Yüksek hızlı bağlı istemcilerin yönetilmesi için kullanılır. Client agent ayarlarında boundary olarak kullanılamaz. Aynı şekilde veriabanı replikasyonunu kullanır.

Secondary Site

Limitli bant genişliğine sahip uzak ofislerdeki istemcilerin yönetilmesi için kullanılır. SCCM 2007’den farkı artık bir SQL Server yada Express ihtiyacının olmasıdır. Aynı şekilde eskiden opsiyonel olarak Proxy Management Point ve Distribution Point , seocndary site kurulumları sırasında otomatik olarak yüklenmektedir. Aynı şekilde veriabanı replikasyonunu kullanır.

Geçen hafta ilkini gerçekleştirdiğimiz Sistem Yöneticileri için PowerShell konulu webcastimizin ikinci bölümü  15.04.2011 Cuma akşama 21:00’da!

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032484728&Culture=TR-TR

Yıl sonunda SCOM 2012’ye kavuşacağız. Bu noktada var olan SCOM 2007 R2 mimarisinden farklı olarak iki önemli yenilik bulunuyor.

RMS TARİHE KARIŞIYOR

SCOM 2007 R2 organizasyonunda SDK servisinin çalışabildiği özelleştirilmiş tek bir Management Sunucunuzun olması gerekiyordu. Bu sunucumuza Root Management Server ismini veriyorduk. SDK servisini ve core bileşenleri üzerinde barındırması sebebiyle SCOM’un kalbi olan RMS sunucusunda yaşanan herhangi bir sıkıntı halinde, web konsolu dahil hiçbir konsolun açılmaması, Notification Subscriptionlarının çalışmaması, admin tasklarının gerçekleştirilmemesi gibi oldukça kritik sorunlar ortaya çıkıyordu.

SCOM 2012’de RMS mimarisi kaldırılıyor. Artık var olan tüm Management Serverlar aynı Management Pool içerisinde yer alarak herhangi bir cluster çözümüne ihtiyaç duymadan yüksek erişebilir seviyede hizmet verebilecekler.

Manuel herhangi bir aksiyon almadan pool içerisine dilendiği gibi Management Server ekleme yada kaldırma yapılabilir çünkü MS’ler kendi arasında otomatik failover desteklemektedirler.

Aynı mantık yük dağılımı noktasında da tamamen otomatize şekilde devam etmektedir.

NETWORK MONITORING ÖZELLİĞİ

SCOM 2007 tarafında eksikliği en çok hissedilen özellik Network Monitoring tarafında zayıf kalınmasıydı. Third Party Management Packler ile SNMP trapler sayesinde bir nebze olsun check edilebilen network cihazları, SCOM 2012 ile Native şekilde izlenebiliyor. Artık varola networkünüzün bir haritasını çıkarabilir, IPv6 monitoring gerçekleştirebilir, Snmp V3 cihazları discover edebilirsiniz. Aynı şekilde VLAN yada HSRP sağlık bilgileri gibi çok hoş yeni özellikler de mevcut.

Lync 2010 içerisinde GUI tabanlı gerçekleştirilen neredeyse tüm aksiyonlar, PowerShell scriptleri ile de otomatize edilerek gerçekleştirilebilir. Kısaca Lync 2010 olan bir organizasyonda sıklıkla kullanılabilecek PowerShell komutlarını inceleyelim;

Lync 2010 için var olan PowerShell cmdlet lerini içeren konsolumuz Lync Server Management Shell’dir.

• PowerShell konsolunda yardım amaçlı kullanılan Get-Help komutunu aynı şekilde kullanabilirsiniz.

Get-Help <cmdlet> –full

Get-Help <cmdlet> –examples

• Lync 2010 ile birlikte kullanabileceğiniz komutların listesini almak için

Get-Command – Module Lync

• Lync Userlarını çekmek için

Get-CSUser

• Federation enable edilmiş tüm kullanıcıları çekmek için

Get-CsUser | Where-Object {$_.EnabledForFederation}

• Spesifik bir kullanıcı için Pool bilgisinin alınması

GetCsUserPoolInfo anilerduran@domain.com

• Active Directory kullanıcısını Lync Enabled yapmak için

Enable-CsUser -Identity User01@example.com -RegistrarPool `Pool01.example.com -SipAddress sip:User01@example.com

• Address Book’un manuel olarak update edilmesi

Update-CsAddressBook

• Specific roller için Lync sunucu konfigürasyonlarının alınması

Get-CsService –<service role>

• Belli bir OU altındaki tüm kullanıcılara Voice Policy assign etmek için

Get-CsUser –OU “ou=finans,dc=domain,dc=com” | grant-CsVoicePolicy –PolicyName Policy1

• Mediation sunucu üzerindeki inbound ve outbound aktif aramaları göstermek için

Get-CsWindowsService -Name RTCMEDSRV -ComputerName `MedServer01 | Format-List -Property ActivityLevel

• Lync topolojisinin test edilmesi

Test-CsTopology

• İsmi A ile başlayan tüm Lync kullanıcıların çekilmesi

Get-CsUser A*

Opalis Integration Server 6.3 için gelen add-in ile sanal makinelerinizin ve hostlarınızın DPM ile koruma altına alınması gibi aksiyonları otomatize edebilirsiniz.

Bu integration pack içerisindeki objeler sayesinde aşağıdaki workflowlar oluşturulabilir;

• Automated virtual machine protection and recovery
• Automated SharePoint Farm protection and recovery
• Automated system state protection
• Ad hoc backups

Bu IP ile object konsoluna aşağıdaki objeler eklenmektedir;

• Create Recovery Point
• Get Data Source
• Get DPM Server Capacity
• Get Recovery Point
• Protect Data Source
• Recover Sharepoint
• Recover SQL
• Recover VM

SCOM ile oluşturulan alert mesajlarını Sms, E-mail yada IM olarak gönderebilme imkanınız bulunuyor. Özellikle IM tarafında OCS – Lync üzerinden notification gönderme noktasında, eğer konfigurasyon düzgün gerçekleştirilmez ise sorunlar yaşanabiliyor.

Adım adım yapılması gerekenleri özet halinde inceleyecek olursak;

• Active Directory üzerinde bir account oluşturulur ve bu account için sip adresi ve OCS pool name bilgileri girilir.
• Oluşturulan bu hesap için bir adet Run As Account oluşturularak RMS’e target edilir.
• Bir önceki adımda oluşturulan Run As Account, var olan Notification Account Run As Profile içerisine eklenir. Target olarak Class Alert Notification Subscription seçilir.
• Bir adet IM channel oluşturulur ve Return Address olarak Notification Account için var olan SIP adresi girilir.
• OCS üzerinde Front End özelliklerinde SCOM RMS sunucusu Authorized Host içerisine eklenir.
• İletişim için TCP yada TCP over TLS kullanabilir. Eğer TCP kullanılacak ise OCS üzerinde varsayılanda kapalı geldiği için aktif edilmelidir.Telnet ile 5060 ve 5061 portları kontrol edilebilir.
• Bu aşamadan sonra bir adet notification oluşturulur ve hiçbir kriter seçilmez.Bu sayede her alert hareketinde IM göndermeye başlayacaktır.

Yukarıdaki adımlara rağmen halen sıkıntı yaşayanlar yaşadıkları sıkıntıları yorum ile gönderebilirler.