Kısa bir süre önce sahip olduğum ve yaklaşık 3 haftadır kullandığım Toshiba/Windows ultrabook un bende oluşturmuş olduğu izlenimleri sizlerle paylaşmak, ultrabook arayanlara fikir vermek ve internet okyanusunda bir zerre içerik üretmiş olmak adına bu yazıyı hazırlıyorum.

Toshiba Portege Z10T ultrabook Windows 8 işletim sistemi ile birlikte geliyor, ürün oldukça şık ve birçok ultrabook cihaza göre oldukça hafif(Tablet + Klavye kiti ile birlikte 1.4 Kg), kısaca ultrabook cihazlar da aradığım iki temel özelliği karşılıyor.

Donanım olarak cihaza söyleyecek bir söz yok, cihaz Intel i5 işlemci, 128 GB SSD diske ve 4 GB RAM sahip, dolayısı ile oldukça hızlı, güç tuşuna dokunduğunuz anda Windows kullanıcı şifre ekranında olduğunuzu söyleyebilirim.

USB 2.0, 3.0, HDMI, VGA, Bluetooth, micro SD kart okuyucu gibi donanımlara sahip olmanın dışında birçok ultrabook da göremeyeceğiniz bir gigabit ethernet kartına sahip.

Donanım olarak benden tam puan alan bu cihazı birde işlevsellik olarak değerlendirmek istiyorum, özellikle yoğun bir iş temponuz var ise, sürekli ağır dizüstü bilgisayarları taşımaktan sıkıldıysanız, bütün gün masa başında, toplantılar da çalışmaktan yorulduysanız ve eve geldiğiniz biraz daha rahat çalışma ortamı arıyorsanız bu ultrabook kesinlikle size göre.

İşim gereği sürekli müşteri ziyaretleri ve toplantılar gerçekleştiriyorum, hali ile sürekli dolaşıyorum, elimde 3 Kg bir cihaz taşımak bir süre sonra beni yoruyor ve sağlık problemlerine neden oluyor.  Katıldığım bazı toplantılarda herkes elindeki kalemler ile tablete not alırken, benim takır tukur daktilo gibi sesler çıkartarak dizüstü bilgisayar ile not almam çok hoş olmuyor. Bu gibi durumlarda ultrabook kurtarıcı olarak devreye giriyor, cihazı klavyesin den ayırarak tablet şekline getirebiliyorum ve tableti alıp toplantıya gidiyorum. Hafif bir cihaz günün koşturmacası içersin de beni yormuyor, toplantı ortamında not almak daha kolay ve sessiz oluyor. Kısaca beni rahatsız eden ağırlık ve gereksiz gürültülerden ultrabook ile birlikte kurtuldum diyebilirim.

Standart bir Türkiye vatandaşına göre boy ortalamam normalin biraz üzerinde, hali ile bu durum beni masa başında çalışırken zorluyor, sürekli ufak bir eğim ile duruyorum. (Halk tabiri ile kambur duruyorum) Gün boyu bu şekilde çalışmak hali ile beni yoruyor ve mesai bitimine yakın yorgunluk artıyor. Fiziki yapım gereği sürekli masa başında çalışmak istemiyorum. Gün boyu masa başında çalıştıktan sonra akşamları da evde çalışma odasına geçip masaya oturmak içimden gelmiyor. Dizüstü bilgisayar kullanırken bunu mecburen yapıyordum çünkü dizüstü ile koltuğa oturup rahat bir şekilde çalışamıyorum, mecbur masanın başına geçerek çalışmaya devam ediyordum ve günün sonunda fazlası ile yorgun ve bitkin bir adam olarak yatağa gidiyordum. Şimdiler de ise elimde kahve ile koltuğuma geçiyor, rahat bir şekilde tabletim den çalışmaya devam ediyorum. Hali ile bu çalışma masa başında çalışmaya göre oldukça daha az yoruyor beni.

Gözlerim hassas olması nedeni ile birçok cihazı uzun süre kullanamıyorum, başımı ağrıtıyor, örneğin samsung TV izleyemem uzun süre veya iPad kullanamam ancak bu cihazı uzun süre kullandığımda bile en ufak bir rahatsızlık hissetmiyorum, gözü hassas olan, her cihazı kullanamayan arkadaşlar için oldukça ideal bir ürün.

Belirtmiş olduğum konuların dışında evde ve işte aynı işletim sistemini kullanıyor olmak, erişmek istediğim bir dosya için evde kaldı, ofiste kaldı derdi ile uğraşmıyor olmakta diğer bir avantajı. Bu konu ile ilgili sorunu cloud sayesinde büyük oranda aşmış olsak da zaman zaman problem yaşamıyor değiliz.

Sonuç olarak sizler de,

-           Evde tablet, işte dizüstü bilgisayar ile çalışabilmek(yani ultrabook),

-           Hızlı bir ultrabook a sahip olmak istiyorsanız,

-          Evde veya iş yerinde dosyam diğer cihazda kaldı derdi ile uğraşmak istemiyorsanız,

-          Toplantılar da daktilo kullanıyor gibi not almak istemiyorsanız,

-          Tabletinize de bilgisayarınızdaki tüm uygulamaları kurabilmek istiyorsanız Toshiba Portege Z10T cihazı ile Windows kullanmaya başlama zamanınız gelmiş demektir.

Kısaca ürünün özelliklerinden ve benim niçin bu cihaza ihtiyaç duyduğumdan bahsetmek istedim, faydalı olabilmek temennisi ile.

RemoteApp Deneyimleri makale serimizin ilk bölümünü okumaktasınız Bu makale serisi içinde RemoteApp nedir, hangi amaç için kullamılır, ilk tanışmış olduğumuz Windows Server 2008 RemoteApp deneyimlerine göre Windows Server 2012 R2 de artıları-eksileri nelerdir ve Windows Server 2012 R2 işletim sistemi RemoteApp deneyimlerini, yapılandırmasını sizlerele paylaşacağız. Makale serimize hızlı erişmek için RemoteApp etiketini kullanabilirsiniz.

Makale serimiz içinde paylaşacak olduğumuz makalelerin listesi aşağıda yer almıştır.

·         RemoteApp Deneyimleri Bolum 1 RemoteApp Nedir ve Sürümler Arası Gelişimi

·         RemoteApp Deneyimleri Bolum 2 Quick Session Collection RemoteApp Programs İncelenmesi

·         RemoteApp Deneyimleri Bolum 3 Quick Session Collection Uygulamaların Kaldırılması (Unpublish RemoteApp Programs)

·         RemoteAPP Deneyimleri Bolum 4 Uygulamaların Dagitilmasi (Publish RemoteApp Programs)

·         RemoteApp Deneyimleri Bolum 5 ShowInPortal Yapılandırılması

·         RemoteApp Deneyimleri Bolum 6 RemoteApp Program Location Belirtilmesi

·         RemoteApp Deneyimleri Bolum 7 RemoteApp Parameters Girilmesi

·         RemoteApp Deneyimleri Bolum 8 RemoteApp User Assigment Yapılandırılması

·         RemoteApp Deneyimleri Bolum 9 Visible in RD Web Access Yapılandırılması

·         RemoteApp Deneyimleri Bolum 10 RemoteApp Program Folder Yapılandırılması

·         RemoteApp Deneyimleri Bolum 11 Access RemoteApp and Desktop Connection Icin Sertifika Yapılandırılması

·         RemoteApp Deneyimleri Bolum 12 Uygulamaların Windows 8 Metro User Interface ile Dagitilmasi

·         RemoteApp Deneyimleri Bolum 13 Uygulamaların Windows 7 RemoteApp and Desktop Start Menüsüne Dağıtılması

·         RemoteApp Deneyimleri Bolum 14 Pass-Through Authentication Yapılandırılması

·         RemoteApp Deneyimleri Bolum 15 RemoteApp Publish Path' in Group Policy ile Dagitilmasi

·         RemoteApp Deneyimleri Bolum 16 File Type Associations Yapılandırılması

·         RemoteApp Deneyimleri Bolum 17 RemoteApp Uygulamalarının Guncellestirilmesi

·         RemoteApp Deneyimleri Bolum 18 Microsoft Azure RemoteApp

RemoteApp Nedir?

RemoteApp, Uzak Masaüstü Hizmetleri aracılığıyla uzaktan erişilen programların son kullanıcının yerel bilgisayarında çalışıyor gibi görünmesini sağlar. Bu programlara RemoteApp programları denir. Kullanıcıya Uzak Masaüstü Oturum Ana Bilgisayarı (RD Oturum Ana Bilgisayarı) sunucusunun masaüstünde gösterilmesi yerine, RemoteApp programı istemcinin masaüstüyle tümleştirilir. RemoteApp programı, büyüklüğü ayarlanabilir kendi penceresinde çalışır, birden çok monitör arasında sürüklenebilir ve görev çubuğunda kendi girişine sahiptir. Bir kullanıcı aynı RD Oturum Ana Bilgisayarı sunucusunda birden fazla RemoteApp programı çalıştırıyorsa, RemoteApp programı aynı Uzak Masaüstü Hizmetleri oturumunu paylaşacaktır. Technet üzerinde paylaşılanRemoteApp'a Genel Bakış makalesinde bu özet bilgi verilmektedir.

Bu genel bakışı biraz yorumlayalım.

Yukarıda görmüş olduğunuz resimde iki tane kutu bulunmaktadır. Kırmızı kutu ve Yeşil Kutu. Wiindows Server 2008 ile birlikte tanışmış olduğumuz RemoteApp teknolojisi olmadan önce Terminal Services bağlantılarımızı kırmızı kutunun içnde ki görüntüde oluyordu. Yani Full Desktops Bağlantısı. Son kullanıcılarımızın ihtiyaç duydukları ve çalıştırmak istedikleri uygulama sadece Office Word olsun yani Yeşil Kutu içindeki alan. Bu alana RemoteAPP teknolojisi demekteyiz. Özetlememiz gerekirse RemoteAPP teknolojisi, full desktop teknolojisine göre  bir masa üstü yerine sadece ihtiyaç duyulan uygulamalara erişim imlanı vermektedir.

RemoteApp Avantajları

RemoteAPP teknolojisinin eski ismi Terminal Services yeni ismi Remote Desktop Services üzerinde iki olumlu gelişimi bizlere sunmuştur. Bunlardan bir tanesi son kullanıcılarımızı kısıtlamak için güvenlik politikalarının yapılmaması ve sonrasında yöneticinin daha az efor harcamasıdır.Bir diğer avantajı ise Performans iyileştirmeleridir.

RemoteApp ile Teknolojisi ile Güvenlik Güvenlik Politikalarının yapılmaması ve yöneticilerin daha az efor harcaması.

RemoteApp teknolojisi olmadan önce son kullanıcılarımıza paylaşmış olduğumuz Full Desktoplar bir riskti. Terminal Services yöneticileri Terminal Services oturumlarını sadece uygulamaları kullanmaları için yapılandırmış olsa bile son kullanıcılara açmış oldukları arayüz bir Sunucu İşletim Sistemi arayüzüydü ve son kullanıcıların bağlanmış oldukları bu arayüz, ayrıcalıklı bir sunucuya aitdi. Yönetmiş olduğumuz ortamda meraklı kullanıclar varsa evlere şenlik olaylar bizleri bekliyordu.

Yaşanılan tecrübelerdir! Uzak bir data center içinde bulunan bir terminal server üzerinde güvenlik politikaları uygulanmamış ve bir tane son kullanıcımız yanlışlıkla oturumu kapat yerine sunucuyu kapat butonuna basıyor. Aynı Sisteme bağlı onlarca/yüzlerce kullanıcının oturumu son buluyor ve bu yapılandırma eksikliği yüzüne organizasyon çalışamaz duruma geliyor.

Bu sebepten ötürü daha sağlıklı oturumların olması için Terminal Services yöneticileri Terminal Services üzerinde bir takım güvenlik politikalarını uygulamak zorunda kalıyorlardı. Yapmış oldukları bu güvenlik politikalarına örnekler verirsek, Terminal Services oturumlarında son kullanıcıların görebilecekleri başlat menüsü üzerinde ki sunucuyu kapat, yeniden başlat butonlarının kaldırılması, güvenlik güncelleştirmeleri balonunun görülmemesi, bütün programlar menüsü, kontrol paneli vb... bölümlerin gizlenmesi işlemleri Group Policy yardımıyla gerçekleştiriliyordu. Ve bu yapılandırma sırasında farkında olmadan fazlasıyla efor harcanıyor, bazen uygulanan yanlış policyler sistemde olumsuz etkiler yapıyor ve istenilmeyen sonuçları doğuruyordu. Policyler ile daha sağlıklı ve istenilen güvenlik şablonu oluşturulana kadar çalışılıyordu. Bu güvenlik güncelleştirmeleri için standart bir şablon hazırlayalım ve her yere uygulayalım dediğiniz zaman, kurumların farklı güvenlik anlayışları ve terminal services üzerinde çalıştırılacak uygulamaların farklılıkları nedeniyle bu hazır şablonlar bir işe yaramıyor, her bir kurum için ayrı-ayrı güvenlik önlemleri alınıyordu.

RemoteApp teknolojisinden önce yapmış olduğumuz bu güvenlik güncelleştirmelerini Remove security option from Start menu (Terminal Services only)  ve Allow admin to install from Terminal Services session makaleleri ile hatırlayabilirsiniz.

RemoteAPP teknolojisi ile bu yapılandırmaları artık yapmıyoruz, çünkü kullanıcılarımıza artık yerel bir masa üstü değil sadece kullanacakları uygulamaları paylaşıyoruz ve bu avantaj ile daha az efor harcıyor ve sonucunda terminal services projelerini daha kısa süre içinde tamamlıyoruz.  

RemoteApp Teknolojisi ile Performans iyileştirilmesi

Bu bölümü iki başlık altında konuşabiliriz. Bunlardan bir tanesi Network Bandwidth bir diğeri ise Remote Desktop Serverin sahip olduğu kaynaklar. RemoteAPP teknolojisi ile birlikte bu iki kaynak kullanımında performans iyileştirilmeleri görülmüştür.

Microsoft Presentation and Hosted Desktop Virtualization Team tarafından 13 Ekim 2008 tarihinde yayınlamış olduğu Remote Desktop Protocol Performance dökümanında yapılan bir testi paylaşmak istiyorum.

Yukarıdaki tabloda 56-Kbps modem üzerinden 16-bit renk derinliğinde bir uzak masaüstü ile  RemoteApp programları için (KBps olarak) bant genişliği tüketimi karşılaştırılmştır. Yapılan testlerde Executive PPT, Simple PPT ve Typing and Scrolling çalışmalarında RemoteAPP her seferinde üstün gelmiştir.

Bandwith tarafında yaşanılan bu iyileştirmler Terminal Services yani Remote Desktop Session Host sunucular içinde paralellik göstermiştir. RemoteAPP ile sadece uygulamalarımız son kullanıcılarımıza sunulduğu için bu sunucularımız artık daha az disk alanı (kullanıcı profilleri daha az yer kaplıyor), daha az memory ve daha az işlemci ve grafik kartı kullanmaya başladılar. Aynı kaynaklara sahip sunucularımız RemoteApp ile daha fazla kullanıcıya hizmet etmeye başlamışlardır.

RemoteApp Olumsuz Tarafları

Olumlu taraflarını gördükten sonra bir çok sistem yöneticisi gibi olumsuz taraflarını görmek istemedik. Fakat bu yeni teknolojininde ilk çıkmış olduğu zamanlarda eksiklikleri vardı ve bu eksiklikler Windows Server 2008 R2, Windows Server 2012 ve son olarak Windows Server 2012 R2 ile birlikte gelişim gösterdi, eksiklikleri giderildi. RemoteApp teknolojisi Windows Server 2012 R2 ile birlikte dördüncü işletim sistemi üzerinde çalışmakta ve kullanılmaktadır.

İlk olumsuz tarafı alışkanlıktı! Bu güne kadar yerel masa üstüne alışmış olan kullanıcılarımızı artık sadece uygulama hizmeti vermemiz, kullanıcılarımıza sanki yerel bilgisayarında yüklüymüş gibi bir uygulamayı uzaktan çalıştırmamız kavram karmaşası oluşturdu. Kullanıcılarımız bazen uygulamaları uzaktan çalıştırdıklarını unuttu, kaydetmiş oldukları verileri kendi yerel bilgisayarındaki kaynaklarda aradı ve bulamayınca veri kayboldu endişesine kapıldılar. Bu yeni teknoloji alışkanlıklarımızı alt-üst etti ve açıkcası bizleride şaşırtmıştı. En büyük olumsuz yönü, YENİ olmasıydı.

Daha sonraki olumsuz tarafları ise eski uygulamalarımız, windows üzerine yüklenemeyen, kısayol (shortcuts) uygulamalarını tüm özellikleri ile desteklememesi ve özellikle yazıcı hizmetlerinde sıkıntılar oluşturması başımızı ağrıtmış ve eski uygulamalarımız yüzüne RemoteApp teknolojisini kullanmaktan vazgeçmiştik.

RemoteApp ‘ın ilk sürümünde Shadowing (uzaktan yönetim) özelliği desteklenmiyordu. RemoteApp teknolojisine bu yetenek windows server 2012 R2 ile birlikte geldi ve bu hizmet sorunsuz bir şekilde son sürümde desteklenmeye başladı. Daha detaylı bilgiye Remote Desktop Services Shadowing - Uzaktan Yonetim makalemizden edinebilirsiniz.

Sürümler arası gelişimde yenilikler oldu. Bu yenilikler bazen hoş karşılanmadı ama alışılınca vazgeçilmez oldu. İlk sürümlerine oluşturmuş olduğumuz Create .rdp file ve Windows Installer Paketleri ile farklı dağıtım senaryoları ile organizasyonumuza sunarken Windows Server 2012 ile Windows 8 Metro User Interface Entegrasyonu ve Windows 7 RemoteApp and Desktop Connection sınırlandırılması ile Winows 7 öncesi işletim sistemlerini sadece Rd Web Acces’e bağımlı bırakmış olduk. Biraz da son kullanıcı işletim sistemlerinin güncel sürüme çıkartılmasını zorladık.

Windows Server 2012 R2 ve RDP 8.1 ile birlikte sağlanan yenilikler.

Son versiyon olan Windows Server 2012 R2 ve RDP 8.1 ile birlikte eşsiz bir deneyim bizleri beklemekte.

Transparent Windows (Şeffaf Geçişler)

RemoteApp uygulamalarımızı yerel bilgisayarımızda uzaktan çalıştırırken penceremizin bir noktasından başka bir noktasına sürükle bırak yaptığımızda seffaf ve hızlı bir geçiş sağlamakta. Bu özellikle uygulamalarımızı uzaktan çalıştırma hissi tamamen ortadan kalkmakta ve bu geçişlerin hızı sayesinde ekran donmaları ortadan kalkmaktadır.

Improving the application move/resize experience

Uygulamalarımızı yerel bilgisayarımız üzerinde bir noktadan başka bir noktaya taşırken yaşadığımız deneyimin bir benzeri uygulama penceresinin boyutlarını değiştirdiğimizde de karşımıza çıkmakta. Improving the application move/resize experience yeniliği ile pencere boyutları değiştirildiği zaman yaşamış olduğumuz deneyim, uygulamanın uzaktan çalıştırıldığını hissettirmeyecek boyutta.

Live Thumbnails (Canlı Önizleme)

Windows 7 ve Windows 8 işletim sistemleri üzerinde RemoteApp uygulamalarını kullanıyorsak yerel bilgisayarımızda ki uygulamalardan bir farkı bulunmamaktadır. RemoteApp uygulamalarımızı sanki yerel bilgisyar üzerinde yüklüymüş gibi küçülttüğümüz zaman, uygulamalarımızı mouse ile üzerine geldiğimiz zaman canlı olarak göstermekte.

Yukarıda Windows 2012 R2 öncesi RemoteApp bağlantısı ve Windows 2012 R2 RemoteApp bağlantısı ile bu fark görülmektedir. Sol tarafta Canlı önizleme sağ taraftaysa dokuman bilgisini görebilmekteyiz.

RemoteApp teknolojisinin son gelmiş olduğu nokta Microsoft RemoteApp uygulamasıdır. Bu yeni teknoloji ile birlikte RemoteApp uygulaması Microsoft Azure teknolojisi ile birlikte bulur üzerinden hizmet edebilir duruma gelmiştir.

Makale serimizin bir sonraki bölümünde RemoteApp Deneyimleri Bolum 2 Quick Session Collection RemoteApp Programs İncelenmesi nı inceleyeceğiz.

RemoteApp Deneyimleri makale serimizin ilk bölümünde RemoteApp nedir, sürümler arası gelişimini özetlemiştik. Makale serimizin bu bölümünde Windows Server 2012 ile birlikte gelen Quick Session Collection kurulumunda ki RemoteApp deneyimini inceleyeceğiz ve dağıtılan RemoteApp Programslarının yapılandırma bilgilerini paylaşacağız.

Quick Session Collection özelliği Windows Server 2012 ile birilikte RDS servislerine eklenmiş ve R2 ile birlikte devam eden RDS kurulum seçimidir. Bu kurulum seçimini yaptığımız zaman RDS servislerinin temel rolleri tek bir sihirbaz ile kuruluyor, collection yapılandırılıyor ve RDS sunucusu üzerinde bulunan temel windows uygulamaları RD Web Access üzerinden yayınlanıyor. Quick Session Collection kurulumu tamamlandıktan sonra hiç bir özel yapılandırmaya ihtiyaç duymadan RemoteApp teknolojisi kullanılmak üzere hazır durumdadır. RemoteApp uygulamalarının RD web Access üzerinde görünümünü yukarıda görmektesiniz.

Quick Session Collection kurulumu sonrasında RDS servislerinin son kullanıcılarımızın kullanması için hazır duruma getirdiği temel windows uygulamalarını Remote Desktop Services yönetim arayüzünde görebilmektesiniz.

Quick Session Collection kurulumu ile dağıtılan bu uygulamaları, standart kurulumda yaptığımız gibi düzenleyebilir, değişiklikler yapaibilir ve programı kaldırabiliriz. Bu makalemizde bu işlemlerin özetini paylaşacağız ve ilerleyen makalelerimizde detay ve kullanım senaryolarını paylaşacağız.

RemoteApp Programs bölümünde görülen bir uygulamayı düzenlemek için üzerinde sağ tuş \ edit butonu ile değişiklikler yapabilmekteyiz.

Dağıtılan bir uygulamayı düzenlemek istediğimiz zaman karşımıza gelen ilk bölüm General bölümüdür. Bu bölümde RemoteApp program name bölümünde uygulamanın ismini değiştirebiliriz, Show the RemoteApp program in RD Web Access bölümünde yes ve no seçimi ile RD Web Access üzerinde görünmesini veya görünmemesini sağlayabiliriz ve en son RemoteApp program folder bölümü ile uygulamalarımızı RD Web Access üzerinde oluşturduğumuz bir klasörün içinde barınmasını sağlayabilir veya bu bölümde yeni bir klasör oluşturabiliriz.

Parameters bölümünde uygulama çalıştırıldıktan sonra uygulama ile birlik çalışacak bir script belirleyebiliriz. RemoteApp Deneyimleri Bolum 5 RemoteAPP Parameters Girilmesi makalemizde bu bölümü detaylı olarak inceleyeceğiz. Windows tabanlı olmayan bir çok özel uygulamada bu bölüm kullanılmaktadır.

User Assignment bölümünde RDS sunucumuz üzerinde dağıtmış olduğumuz uygulamalara hangi kullanıcı görebilir ve kullanabilir izinlerini verebilmekteyiz. RemoteApp Deneyimleri Bolum 7 User Assigment Yapılandırılması makalemizde bu bölümü detaylı olarak inceleyeceğiz.

File Type Associations bölümünde son kullanıcılarımızın yerel bilgisayarında barınan dosyaların RemoteApp uygulamaları ile otomatik olarak çalıştırılmasını gerçekleştirebilmekteyiz. RemoteApp Deneyimleri Bolum 16 File Type Associations Yapılandırılması makalemizde bu bölümü detaylı olarak inceleyeceğiz.

Makale serimizin bir sonraki bölümünde RemoteApp Deneyimleri Bolum 3 Quick Session Collection Uygulamaların Kaldırılması (Unpublish RemoteApp Programs) nı inceleyeceğiz.

RemoteApp Deneyimleri makale serimizin ikinci bölümü olan RemoteApp Deneyimleri Bolum 2 Quick Session Collection RemoteApp Programs İncelenmesi ni gerçekleştirmiştik.Quick Installationkurulumu ile birlikte yayınlanan temel windows uygulamalarını RemoteApp Programs bölümünde görmüştük.

Bu uygulamalar RD Web Access üzerinde barınmasının nedeni RemoteApp’ in kurulum sonrasında sağlıklı çalışıp-çalışmadığının kontrolü içindir. Bu uygulamalar varsayılan olarak bütün windows işletim sistemleri içinde olduğu için bu uygulamaları dağıtmanın bir anlamı bulunmamaktadır. Bu sebepten ötürü RemoteApp Programs içinde bulunan bu uygulamaları kaldıracağız. Bu makale içinde paylaşılan bilgiler ile ihtiyaç duymuş olduğunuz başka uygulamalarıda aynı şekilde kaldırabilirsiniz.

Remote Desktop Services yönetim arayüzümü açtığımız zaman Collection altında RemoteApp Programs bölümünü görebilmekteyiz. Bu bölümde Unpublish RemoteApp Program sihirbazını çalıştırıp, RemoteApp Programs bölümünde kaldırılması gereken uygulamalarımızı kaldırmak için sihirbazımızı başlatıyoruz.

Unpublish RemoteApp Program sihirbazı bölümünde gelen ilk bölüm RemoteApp Programs larının listelendiği, yayınlanan uygulamaların görüldüğü bölümdür. Bu bölümde kaldırmak istediğimiz uygulamaları seçiyoruz ve ilerliyoruz.

Confirmation bölümünde kaldırmak istediğimiz uygulamalar ve location bilgileri görülmekte. Eğer ihiyaç olursa ve tekrardan yayınlamak istersek bu uygulamaları tekrar yayınlamak için ihtiyaç duyulan dizin Location bölümünde görülmektedir. Uygulamalarımızı kaldırmak için Unpublish butonu ile devam ediyoru.

Unpublish bölümünde uygulamalarımızın kaldırılmakta. Bu işlem bir-iki dakika kadar sürmektedir.

Completion bölümünde dağıtımından vazgeçtiğimiz uygulamaları görebilmekteyiz. Sihirbazımızı Close butonu ile kapatıyoruz.

RemoteApp Programs bölümüne geldiğimiz zaman yayınlanan herhangi bir uygulamanın olmadığını görebilmektesiniz.

Web Access’e arayüzüne bağlandığımız zaman Quick Session Full Desktop Bağlantısını görebilmekteyiz. Bu kısayolun oluşmasının nedeni bizler RemoteApp Programlar bölümünde yayınlanan herhangi bir uygulama bırakmayarak RemoteApp bağlantısını değil Full Desktop Bağlantısını seçtiğimizi sisteme belirtmiş oluyoruz.

Quick Session Collection bağlantısı üzerinden RDS ortamımıza Remote Desktop Connection sağlayabilmekteyiz.

RD Web Access üzerinden RDS farmı içinde bulunan RDS sunucumuza yaptığımız Full Desktop Bağlantısını görebilmekteyiz.

Yapmış olduğumuz bu bağlantıyı Remote Desktop Services yönetim arayüzü üzerine Connection Bölümünden izleyebilmekteyiz.

Makale serimizin bir sonraki bölümünde RemoteAPP Deneyimleri Bolum 4 Uygulamaların Dagitilmasi (Publish RemoteApp Programs) nı inceleyeceğiz.

RemoteApp Deneyimleri makale serimizin üçüncü bölümü olan RemoteApp Deneyimleri Bolum 3 Quick Session Collection Uygulamaların Kaldırılması (Unpublish RemoteApp Programs) ni gerçekleştirmiş ve RemoteApp Programs bölümünde yayınlanan temel Windows uygulamalarının RemoteApp ile yayınlanmamasını sağlamıştık. RemoteAPP Deneyimleri Bolum 4 Uygulamaların Dagitilmasi (Publish RemoteApp Programs) makalemizde ise ihtiyacımız olan ve son kullanıcılarımızın kullanacakları uygulamaların dağıtılmasını gerçekleştireceğiz.

Remote Desktop Services yönetim arayüzünde Collection bölümüne gidiyoruz. RemoteApp Programs bölümünde yayınlanan herhangi bir uygulamamız bulunmamaktadır. Bu panelde Publish RemoteApp programs linkine tıklıyoruz ve Publish RemoteApp Programs sihirbazını çalıştırıyoruz.

Sihirbazımız ilk olarak RemoteApp Programs bölümünü çalıştırıyor. Bu bölümde RD Session Host sunucu ve aynı collection içinde bulunan RD Session Host Sunucularımız üzerinde yüklü bulunan uygulamaları tespit ediyor. RemoteApp Programs bölümünde yayınlamak istediğimiz uygulamaları seçiyoruz ve devam ediyoruz. Bu bölümde görülen dosyalar, uygulamalarımızın yürütülebilir dosyalarıdır.

Confirmation bölümünde RemoteApp Programlarımızı ve location bölümünde uygulamalarımızın barınmış olduğu dizinleri görebilmekteyiz.

Publishin işlemi tamamlandıktan sonra Completion bölümünde yayınlamış olduğumuz uygulamaların listesini görebilmekteyiz.

RemoteApp Programs bölümüne geldiğimiz zaman yayınlamış olduğumuz uygulamaları görebilmekteyiz.

Yayınlamış olduğumuz uygulamalar RD Web Access arayüzüne yerlerini aldılar ve son kullanıcılarımızın kullanmaları için hazır beklemektedirler.

Yayınlamış olduğumuz uygulamalardan Office Word uygulamasını çalıştırıyoruz.

Uygulamamız çalışabilmesi için arka tarafta profili hazırlayıp, oturumu açtıktan sonra son kullanıcımızın kullanabilmesi için hazır duruma gelmektedir.

Makale serimizin ilk bölümü olan RemoteApp Deneyimleri Bolum 1 RemoteApp Nedir ve Sürümler Arası Gelişimi adlı makalemizde Live Thumbnails (Canlı Önizleme) yeniliğinden bahsetmiştik. Gördüğünüz gibi Windows Server 2012 R2 işletim sisteminde bu özellik başarılı bir şekilde çalışmaktadır.

RDS ortamına bağlı olan kullanıcılarımızı eş zamanlı olarak görebilmekteyiz. Remote Desktop Services yönetim paneli üzerinde collection ve Connections yollarını izlediğimiz zaman aktif kullanıcılarımızı görebiliriz. Görmüş olduğumuz bu aktif kullanıcılar Full Desktop Bağlantısı bağlanan kullanıcılar olduğu gibi RemoteApp ile bağlanan kullanıcılarıda kapsamaktadır.

Makale serimizin bir sonraki bölümünde RemoteApp Deneyimleri Bolum 5 ShowInPortal Yapılandırılmasını inceleyeceğiz.

RemoteApp Deneyimleri Bolum 5 ShowInPortal Yapılandırılması

RemoteApp Deneyimleri makale serimizin dördüncü bölümü olan RemoteAPP Deneyimleri Bolum 4 Uygulamaların Dagitilmasi (Publish RemoteApp Programs) ni gerçekleştirmiş ve RemoteApp Programs bölümünde ihtiyacımız olan uygulamaların RD Web Access üzerinden dağıtılmasını sağlamaıştık. RemoteApp Deneyimleri Bolum 5 ShowInPortal Yapılandırılması makalemizde ise Bölüm 3 ve Bölüm4 makalelerinde yapmış olduğumuz işlemlerin Portal bağlantısına nasıl etki ettiğinden ve bu etkiden kurtulmanın yollarını paylaşacağız.

İlk varsayılan Quick Installation kurulumunda temel windows bileşenleri RemoteApp Program bölümünde yayınlanıyordu ve bizler RDS ortamında RemoteApp kullanacağımızı sisteme söylüyorduk.

RemoteApp Deneyimleri Bolum 3 Quick Session Collection Uygulamaların Kaldırılması (Unpublish RemoteApp Programs) makalesinde ise RDS ortamında RemoteApp kullanmayacağımızı söylemiş ve RemoteApp Program bölümünde bulunan bütün uygulamalarımızın yayınlanmasını kaldırmıştık. RDS bu kez RD Web Access üzerinde QuickSessionCollection bağlantısını aktif duruma getirmiş ve RDS ortamına bağlantı yapabilmek için bir kısa yol oluşturmuştu.

Bu sistemin çalışmasını özetlememiz gerekirse, eğer RDS ortamında RemoteApp uygulamalarını paylaşırsak (bir tane uygulama bile paylaşsak sistem bunu Full Desktop Bağlantısı kullanılmayacakmış gibi yapılandırıyor) Full Desktop için QuickSessionCollection bağlantısı-kısayolu kalkıyor, hiç bir uygulamayı RemoteApp Programs bölümünde paylaşmazsak QuickSessionCollection bağlantısı-kısayolunu RD Web Access üzerine yerleştiriyor.

RemoteApp ile uygulama dağıttığımız zaman veya mevcut uygulamaları kaldırdığımız zaman RDS Farmının yapmış olduğu işlem, RDS farmı içinde bulunan RD Connection Broker Sunucusu üzerinde

HKLM\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Terminal Server\ CentralPublishedResources\ PublishedFarms\ <collection name>\ RemoteDesktops\ <collection name>

Register yolu üzerinde bulunan ShowInPortal değerini değiştirmesidir.

RemoteApp kullanıldığı zaman bu anahtarın Value data değeri 0 (sıfır) RemoteApp kullanılmadığı zaman bu anahtarın Value data değer 1 (bir) olarak yapılandırmaktadır.

Aynı RDS ortamında hem RemoteApp hemde Full Desktop bağlantısı yapmak istersek bu value data değerini Hexadecimal 1 yapmamız yeterlidir.

ShowInPortal değerini RemoteApp kullanıldığı zaman 1 olarak değiştirdik.

RemoteApp program bölümünde Quick SessionCollection bağlantısını göremiyoruz ama RDS Web Access ‘e bağlandığımız zaman RemoteApp uygulamaları ile birlikte Full Desktop Bağlantısnıda görebilmekte ve kullanabilmekteyiz.

Aynı register yolu üzerine Name anahtarı bulunmaktadır. Bu name anahtarı Full Desktop Bağlantısının RD Web Access üzerinde görünen ismini göstermektedir ve varsayılan değeri QuickSessionCollection dur.

Bu anahtarın valu date değerini ihtiyaçlarımıza göre değiştirebilmekteyiz.

RD Web Access üzerinde görünmesini istediğimiz ismi veriyoruz ve register editör’ü kapatıyoruz.

Yapmış olduğumuz bu register değişiklikleri eş zamanlı olarak RD Web Access arayüzünde görülmektedir. RemoteApp kullanımını ve Full Desktop kullanımını RD Web Access üzerinen sağlatabilmekteyiz.

Bu değişiklikleri RD Connection Broker Sunucumuz üzerinde yaptığımızı bir kez daha hatırlatıyorum. Eğer ortamımızda birden fazla RD connection Broker sunucusu varsa bu değişikliği her bir RDCB sunucusu üzerinde yapmanız gerekmektedir.

Diğer bir hatırlarma ise RemoteApp Programs bölümünde yapacak olduğunuz her bir değişiklik, bu anahtarın sıfırlanmasına, default değerlere gelmesine neden olacaktır.

Makale serimizin bir sonraki bölümünde RemoteApp Deneyimleri Bolum 6 RemoteApp Program Location Belirtilmesi inceleyeceğiz.

RemoteApp Deneyimleri makale serimizin dördüncü bölümü olan RemoteAPP Deneyimleri Bolum 4 Uygulamaların Dagitilmasi (Publish RemoteApp Programs) ni gerçekleştirmiş ve RemoteApp Programs bölümünde ihtiyacımız olan uygulamaların RD Web Access üzerinden dağıtılmasını sağlamaıştık. Yayınlamış olduumuz bu uygulamalarda, uygulamaların özelliklerine göre bazen problemler yaşayabilmekteyiz.

Bazı prograların ise executuable dosyaları olmadığı için Publish Programs panelinde görülmemektedir. Makale serimizin  RemoteApp Deneyimleri Bolum 8 RemoteApp Program Location Belirtilmesi bölümünde Location Path’ lerin el ile gösterilmesini inceleyeceğiz.

Öncelikli olarak Bölüö4 de yayınlamış olduğumuz ve RD Web Access üzerinde problemsiz olarak yayınlanan uygulamalarımızı görebilmekteyiz. Yayınlamış olduğumuz uygulamalardan bir tanesi DNS yönetim panelidir ve bu panel üzerinde ki hatayı ve çözümü bu makale içinde gerçekleştireceğiz.

RD Web Access üzerinde DNS uygulamasını çalıştırıyoruz. Açılan RemoteApp dosyasında Path bölümüne baktığımız zaman mmc’ nin çalıştırılacağının bilgisi görülüyor. Bildiğiniz gibi DNS yönetim arayüzü MMC üzerinede çalışmaktadır.

RemoteApp çalıştırılması sonrasında MMC Console başarılı bir şekilde çalıştı. Fakat bizim istediğimiz DNS yönetim arayüzünün çalışmasıydı.

Bu problemin kaynağını incelemek için RemoteApp Programs bölümünde DNS uygulamasının özelliklerine giriyoruz.

General bölümünde görülen RemoteApp program location yolu mmc.exe’ nin yolu. Sistem aslında doğru çalışıyor. Bizler DNS uygulamasını seçmiş olsak bile sistem bunu DNS’ in çalışmuş olduğu mmc konsolunu RemoteApp arayüzüne ekliyor.

Makale serimiz içinde bulunan RemoteApp Deneyimleri Bolum 3 Quick Session Collection Uygulamaların Kaldırılması (Unpublish RemoteApp Programs) adımları izlenilerek bu uygulamayı RD Web Access arayüzünden kaldırabiliriz, çünkü bu uygulama yayınlanan bir uygulama olduğu için değişiklik hakkını bizlere vermemektedir.

RD Web Access üzerinden DNS yönetim arayüzünü sağlıklı bir şekilde yayınlayabilmemiz için DNS uygulamasının yolunu öğreniyoruz. Bu yol DNS sunucumuz üzerinde %SystemRoot%\system32\mmc.exe %SystemRoot%\system32\dnsmgmt.msc

yolu altındadır.

RemoteApp Program bölümünde TASK bölümünü açıyoruz ve Publish RemoteApp Programs sihirbazını çalıştırıyoruz.

Select RemoteApp Programs bölümünde listelenen uygulamaları seçmiyoruz. Bu bölümde Add butonu ile uygulama yolunu el-ile göstereceğiz.

Dnsmgmt.msc yolunu seçiyoruz. Bu seçmiş olduğumuz uygulama yürütülebilir bir dosyadır ve RD Web Access üzerinden rahatlıkla çalışabilecektir.

Add bölümü ile el-ile eklediğimiz uygulamamız Select RemoteApp programs bölümüne eklendi. Location bölümüne baktığımız zaman mmc yolunun değil dns yönetim bölümünün olduğunu görebilmekteyiz.

Sihirbazımız üzerinde herhangi bir değişiklik yapmadan tamamlıyoruz.

Uygulamamız başarılı bir şekilde yayınlandığını RemoteApp Programs bölümünde görebiliyoruz.

RD Web Access üzerinde uygulamalarımıza baktığımız zaman dnsmgmt uygulamasının yayınlandığını görebilmekteyiz.

Uygulamamızı çalıştırdığımız zaman RemoteApp bağlantısında Path bölümünde uygulamanın çalıştıracak olduğu executuable dosyasını görebiliyoruz.

RD Web Access üzerinden başarılı bir şekilde DNS yönetim arayüzüne bağlantı gerçekleştirdik ve yetkilerimiz çerçevesinde bütün yönetimsel işlemleri yapabilmekteyiz.

RD web Access üzerinde görülen dnsmgmt ismini, uygulamanın özelliklerine girerek General bölümünde RemoteApp Program name bölümünden değiştirebiliriz.

Değişiklikler eş zamanlı olarak RD Web Access arayüzünde algılandı.

Bu işlemin yapılma amacı daha çok executuable dosyalara sahip olmayan windows sistemi üzerine yüklenemeyen kısa yol programları (eski Eta, Link vb... muhasebe programları) örnek verilebilir. Günümüzde bir çok uygulamanın executuable dosyası bulunmakta ve RemoteApp tarafından algılanabilmektedir. Ama bu bölüm eski uygulamalar için destek verilmeye ve yayınlanmaya uygun olarak varlığını sürdürmektedir.

Lab ortamı içinde RDS ve Domain Controller Sunucusu aynı sunucu üzerinde yüklü durumdadır ve bu sebepten ötürü DNS yönetim arayüzünü problemsiz olarak çalıştırabildim.  Risk nedeniyle önermemekle birlikte Windws Server 2012 R2 işletim sistemi kullanılıyorsa Domain Controller sunucusu ile RDS sunucuları aynı işletim sistemi üzerinde barınabilmektedir.

Makale serimizin bir sonraki bölümünde RemoteApp Deneyimleri Bolum 7 RemoteApp Parameters Girilmesi inceleyeceğiz.

RemoteApp Deneyimleri makale serimizin bu bölümünde dağıtımını gerçekleştirmiş olduğumuz uygulamalara Parameters girilme adımını gerçekleştireceğiz.

Parameters kullanım alanı çalıştırmış bir uygulamanın, uygulama çalıştırıldıktan sonra çalıştırılmasını istediğimiz ek özellikler için girilmektedir. Yani bir uygulama çalıştığı zaman parelelinde çalıştırılacak komutları belirtiyoruz. Bu işlemin kullanım alanı, sahip olduğumuz uygulamaların özelliklerine göre değişmektedir.

Makalemiz içinde kullanmış olduğumuz örnekten bağızmsız bir senaryo kullanmamız gerekirse CRM uygulamasını söyleyebiliriz. Bildiğiniz gibi CRM uygulaması birden fazla modüle sahip olan bir portaldır. Tek bir executuable dosya altında çalışan birden fazla uygulaması bulunmaktadır. Parameters bölümü ile her tek bir uygulama üzerinden birden fazla modülüne erişim için bu seçenek kullanılabilinir.

Makalemizin bu bölümünde kullanmış olduğum uygulama mstsc (RDP Client’in yürütülebilir dosyası) uygulamasıdır. Mstsc dosyası üzerinde kullanabileceğimiz parameters ları yukarıda görebilmekteyiz ve makalemiz içinde bir-iki örnekle bunların nasıl kullanıldığını aktaracağım.

RemoteApp Programs bölümüne mstsc uygulamasını RemoteApp Deneyimleri Bolum 6 RemoteApp Program Location Belirtilmesi makalesinde ki adımları yerine getirerek ekledim. RemoteApp Programs bölümüne eklediğim uygulamayı düzenlemek için edit Properties özelliğini açıyorum.

Mstsc uygulaması üzerinde Parameters bölümüne giriyorum ve Always use the following command-line parameters bölümüne /v:rds01.live.local komutunu yazıyorum. Bu parameters yazııldıktan sonra sistemin çalışması ilk önce mstsc aracı çalışacak ve sonrasında /v: komutu kullanılacaktır. Mstsc içinde bulunan /v komutu uzaktan bağlantı yapılacak olan sunucuyu işaret etmektedir.

Mstsc /v: rds01.live.local komutunun tam anlamı RD web Access üzerinden mstsc aracını çalıştırma RD Web Access üzerinden rds01.live.local isimli sunucuya mstsc aracı ile bağlan dedim.

Yapmış olduğum bu değişiklikten sonra RD Web Access arayüzünde Session Deployment olarak yayınlanan bir uygulama görülmektedir. General bölümünden mstsc ismini bu şekilde değiştirdim.

Organizasyonumuz içinde bulunan ve RD Web Access ile erişilmesini istediğimiz her bir sunucu için tek-tek mstsc uygulamasını ekleyip, makale içinde belirtilen parameters ları erişilmek istenilen sunucuların IP adresi / Sunucu ismine göre düzenleyerek RD Web Access üzerinden erişimlerini mümkün kılabiliriz.

RD web Access üzerinden uygulamamızı çalıştırdığım zaman path bölümünde girmiş olduğum parametersi görebilmektesiniz.

RDS01 isimli sunucuya erişim yapabilmek için gerekli olan kullanıcı adı ve parola bilgisini giriyorum. Bu bölümde kullanıcı adı ve parola sormasının nedeni, rds01 sunucusunu bir collection olarak publish etmediğim içindir. RDS ortamı bu yayınlanan yeni uygulamanın RDS ortamından bağımsız herhangi bir sunucu olduğunu düşünmektedir. Yani organizasyonumuz içinde bulunan X kadar sunucuyu RD web Access üzerinden paremeters yardımıyla yayınlayabiliriz.

Rds01.live.local sunucusuna başarılı bir şekilde bağlantıyı gerçekleştirdik.

Girmiş olduğumuz bu parameters ları, yayınlamış olduğumuz uygulamanın desteği çerçevesinde ardaşık komutlarıda çalıştırabiliriz. Yukarıdaki örnekte /w:800 (bağlantı genişliği) ve /h:600 (bağlantı yüksekliği) nin belirli standartlarda olmasını istiyorum.

Yapmış olduğum değişiklikler eş zamanlı olarak RD Web Access tarafından algılanıyor ve bu değişiklikleri RemoteApp bölümünde path bölümünden görebilmekteyiz.

Son olarak bağlantımızı kontrol ediyoruz ve rds01.live.local sunucumuza 800x600 piksel boyutları ile bağlanmasını şart koştuk.

Tekrar CRM uygulamasından örnek vermemiz gerekirse CRM’ in her bir modülünü tek bir executuable dosya üzerinden farklı parameters lar girerek ihtiyaçlarımızı karşılayabiliriz.  

Makale serimizin bir sonraki bölümünde RemoteApp Deneyimleri Bolum 8 RemoteApp User Assigment Yapılandırılması inceleyeceğiz.

RemoteApp Deneyimleri makale serimizin bu bölümünde dağıtımını gerçekleştirmiş olduğumuz uygulamalara erişimleri kullanıcı / grup seviyesinde sınırlandıracağız.

Makale serimizin bir önce ki bölümü olan RemoteApp Deneyimleri Bolum 7 RemoteApp Parameters Girilmesi bölümünde RD Web Access üzerine birden fazla sunucuya nasıl RDP yapabileceğimizin senaryosunu çizmiştik.

RD Web Access üzerinde uygulama seviyesinde izin vermezsek Collection bölümünde izin vermiş olduğumuz bütün kullanıcılar bu uygulamaları görebilirler. Kullanabileceklerinden bahsetmiyorum.

Bizler Collection bölümünden kullanıcı erişimlerini sınırlandırabiliriz. Zaten bu işlemin yapılması gerekiyor. Bu makale içinde paylaşacak olduğumuz bilgi uygulama seviyesinde kullanıcıların uygulamaları görmesidir.

RemoteApp Programs bölümünde yayınlanan uygulamaları görebiliyoruz.

Bu uygulamaların her birisi RemoteAppUsers gurubunun üyeleri tarafından RD Web Access üzerinden görülebilir ve yetkileri varsa uygulamaları çalıştırabilmektedirler.

RD Web Access üzerinde görülen uygulamaları kullanıcı / grup seviyesinde görmeleri için Active Directory üzerinde bulunan kullanıcı / Gruplarımızı kullanmaktayız. Kullanacak olduğumuz ilk grup RemoteAppOfficeUsers grubu.

RemoteApp Programs bölümüne geliyoruz ve Excel2013 uygulaması için User Assigment değerini değiştiriyoruz. Bu bölümde All user and group that have access to the collection değerini kaldırıyoruz ve only specified users and group olarak değiştiriyoruz.

Excel2013 uygulaması için RD Web Access üzerinde görülme, yayınlama izinleri Collection seviyesinden değil uygulama seviyesinden vermiş olacağız. Users and group bölümüne Live\RemoteAppOfficeUsers grubunu ekliyoruz. Bu değişikliği RemoteApp Programs bölümünde bulunan bütün Office Uygulamaları için gerçekleştiriyorum.

Benzer değişikliği yöneticiler için ve yönetim araçları için değiştiriyorum. RD web Access üzerinde görülen bütün yönetim araçlarını Live\DomainAdmins kullanıcıları için veriyorum.

RemoteAppOfficeUsers Grubunun kullanıcıları RD Web Access’a erişim yaptıkları zaman görecek oldukları uygulamalar, izinleri vermiş olduğumuz Office uygulamalarıdır.

Domain Admins grubunun kullanıcıları RD Web Access’a erişim yaptıkları zaman görecek oldukları uygulamalar, izinleri vermiş olduğumuz yönetim araçlarıdır.

İhtiyacımıza göre, ortak kullanılan uygulamalara göre birden fazla grup ve kullanıcı atamasını gerçekleştirebiliriz. User Assigment yapılandırması sayesinde RD Web Access üzerinde, kullanıcılarımızın kullanmayacağı uygulamaları kaldırmış olduk ve kullanıcılarımız için RD web Access üzerinde ki görünümü sadeleştirmiş olduğumuz gibi RDS ortamımız içinde görsel güvenliği sağlamış olduk.

Makale serimizin bir sonraki bölümünde RemoteApp Deneyimleri Bolum 9 Visible in RD Web Access Yapılandırılması inceleyeceğiz.

RemoteApp Deneyimleri makale serimizin bu bölümünde RemoteApp Deneyimleri Bolum 9 Visible in RD Web Access Yapılandırılması nı inceleyeceğiz. Bu makale ile yapacak olduğumuz işlemler RemoteApp ile son kullanıcılarımıza yaygınlaştımış olduğumuz uygulamaların RD Web Access üzerinde görülmesini veya görülmemesini sağlayacağız.

Yapacak olduğumuz bu değişiklikler sadece Rd Web Access Arayüzüne etki edecektir. RemoteApp Deneyimleri Bolum 12 Uygulamaların Windows 8 Metro User Interface ile Dagitilmasi ve RemoteApp Deneyimleri Bolum 13 Uygulamaların Windows 7 RemoteApp and Desktop Start Menüsüne Dağıtılması konularından anlatılan yapılandırmaları etkilemediğini belirtmek isterim. Bu yapılandırma sadece RD Web Access üzerinde etki edecektir.

RemoteApp Programs bölümüne geldiğimiz zaman yayınlamış olduğumuz uygulamaların Visible in RD Web Access bölümünde yes ile görüldüğünü no ile görülemediğini görebilmekteyiz.

Örneğimizi PowerPoint 2013 uygulaması için gerçekleştireceğiz.s RD web Access üzerine geldiğimiz zaman PowerPoint 2013 uygulamasının görülebildiğini görebilmekteyiz.

PowerPoint uygulamasının özelliklerine giriyoruz ve general bölümünde Show the RemoteApp program in RD Web Access bölümünü No olarak değiştiriyoruz.

Yapmış olduğumuz değişiklik RemoteApp Programs bölümünde algılandı ve visible in RD Web Access bölümünde No olarak görüldü.

RD Web Access arayüzüne bağlandığımız zaman PowerPoint 2013 uygulamasının görülmediğini görebilmekteyiz.

Makale serimizin bir sonraki bölümünde RemoteApp Deneyimleri Bolum 10 RemoteApp Program Folder Yapılandırılması inceleyeceğiz.

RemoteApp Deneyimleri makale serimizin bu bölümünde RemoteApp Deneyimleri Bolum 10 RemoteApp Program Folder Yapılandırılması nı inceleyeceğiz. Bu makale ile yapacak olduğumuz işlemler RemoteApp ile son kullanıcılarımıza yaygınlaştımış olduğumuz uygulamaların RD Web Access üzerinde belirli klasörler altında görülmesini sağlamaktır.

RDS ortamları Windows tabanlı bütün uygulamaları yayınlayabilmektedir. Bunların bilinen en temel ürünü Office uygulamalarıdır. Office uygulamalarını bir folder altında toplayacağız ve RD Web Access üzerinde düzenli bir görünüme sahip olacağız. Eğer RDS ortamı içinde farklı firmaların farklı uygulamaları varsa benzer çözüm ile kendilerine ait olan folder lar altında listeleyebilir ve RD Web Access üzerinde ki görünümü düzenleyebiliriz.

Yapacak olduğumuz bu değişiklikler sadece Rd Web Access Arayüzüne etki edecektir. RemoteApp Deneyimleri Bolum 12 Uygulamaların Windows 8 Metro User Interface ile Dagitilmasi ve RemoteApp Deneyimleri Bolum 13 Uygulamaların Windows 7 RemoteApp and Desktop Start Menüsüne Dağıtılması konularından anlatılan yapılandırmaları etkilemediğini belirtmek isterim. Bu yapılandırma sadece RD Web Access üzerinde etki edecektir.

RD Web Access üzerine bağlantı gerçekleştirdiğimiz zaman RemoteApp Programs bölümünde yaymış olduğumz bütün uygulamaları RD Web Access ana giriş sayfasında görebilmekteyiz.

Folder altına alacak olduğumuz OneNote2013 uygulamasının özelleiklerine giriyoruz. RemoteApp program folder bölümünde RD Web Access üzerinde görülecek olan bir klasör ismi yazıyoruz ve uygula ile işlemi tamamlıyoruz.

Bu sefer word 2013 uygulamasının özelliklerine giriyoruz. OneNote2013 uygulaması ile RemoteApp program folder bölümüne girmiş olduğumuz Office2013 folder’i görülmektedir. Bu folder bilgisi RDS ortamında RD Connection Broker sunucusu üzerinde saklanmaktadır. Listeden bu folderi seçiyoruz veya başka folderları oluşturmak için ilgili satıra folder isminide yazabiliriz. Word 2013 uygulaması OneNote ile aynı türden uygulama olduğu için Office2013 folderini seçiyorum ve uyguluyorum.

Benzer seçimi diğer bütün Office 2013 uygulamaları içinde gerçekleştirmekteyim.

RD Web Access ana sayfasına girdiğim zaman Office 2013 isimli oluşturmuş olduğum folder ana sayfa üzerinde görülmektedir. Current Folder:/ ibaresi bana root dizininde olduğumuz söylemektedir.

Foldera eklemediğim Collection Full Desktop Erisim isimli uygulamamız herhangi bir folder altında olmadığı için giriş sayfasında bulunmaktadır. Office 2013 Folder içine giriş yapıyorum.

Office 2013 Folderi içine girdiğim zaman folder altına topladığım bütün office 2013 uygulamalarını bu folder altında görebiliyorum. Current Folder:/ Office2013 ibaresi bana bulunduğum folderi söylemektedir. Sol tarafta bulunan Up kısayolu ile root’a ana giriş sayfasına geri gidebilmekteyim.

Makale serimizin bir sonraki bölümünde RemoteApp Deneyimleri Bolum 11 Access RemoteApp and Desktop Connection Icin Sertifika Yapılandırılması inceleyeceğiz.

Windows Server işletim sistemindeki RDP (Remote Desktop Protocol)  servisi, Internet ortamında en çok Brute Force atak alan protokollerin başında geliyor. Zayıf parolalar, güvenlik yüzeyinin kısıtlanmaması ve yapılandırma zayıflıklarından da birçok atak başarılı olabiliyor. Hal böyle olunca sunucunuzu haberiniz olmadan başka kullanıcılarla, zararlı yazılımlarla paylaşabiliyorsunuz.

Bu makalede RDP protokolünü VPN servisi arkasına alarak Internet ortamından izole edeceğiz ve işletim sisteminin güvenlik yüzeyini azaltmış olacağız.

Windows Server 2012 R2 üzerinde VPN Servisini Kurmak

Öncelikle VPN sunucumuzu ayağa kaldıralım. Bunun için Windows Server üzerine “Remote Access” rolü altındaki Direct Access VPN özelliğini aktif hale getireceğiz. Bunun için PowerShell üzerinden aşağıdaki komutu çalıştırmanız yeterli.

Install-WindowsFeature DirectAccess-VPN, RSAT-RemoteAccess, RSAT-RemoteAccess-Mgmt, RSAT-RemoteAccess-PowerShell

Artık VPN ve yönetebileceğimiz ara yüzler sunucu üzerine yüklendi. Yönetim için “Routing and Remote Access”’i kullanacağız. Biz daha çok komut isteminden ilerleyeceğiz. Bu işlemleri yapabileceğiniz ara yüze

Başlat > Çalıştır > rrasmgmt.msc

Komutu ile ulaşabilirsiniz.

Kurulumlar tamamlandıktan sonra öncelikle RAS’ı aktif etmemiz gerekir. Aşağıdaki komut ile aktif hale getirin.

netsh ras set conf ENABLED

Ras aktif fakat Routing and Remote Service Windows yerel servislerinde Disabled olarak kaydedildiğinden çalıştırmak için auto ya almamız gerekiyor. Aşağıdaki komut auto olarak değiştiriyor.

sc config RemoteAccess start=auto

Servisi auto’ya aldıktan sonra başlatmamız için aşağıdaki komutu çalıştırın.

net start RemoteAccess

Artık bize gerekli olan servisler kurulu ve çalışır vaziyete geldi.

VPN Konfigürasyonu

VPN servisine bağlandığınızda size bir IP adresi tahsis ediliyor. Bu tahsis edilen IP aralığını belirlememiz gerekiyor. Aşağıdaki iki komutu VPN servisine bağlanan kullanıcıların 10.0.0.0 ve 10.0.0.20 arasında bir IP adresi alabileceğini belirtir.

netsh ras ip add range from=10.0.0.0 to=10.0.0.20

netsh ras ip set addrassign POOL

Buradaki örnekte 21 IP var yani VPN servisini 21 istemci bağlanabilir anlamına gelir bu. İstemci sayınıza göre arttırmak size kalmış.

VPN’e bağlanan ve belirlediğimiz havundan IP alan istemcilerin sunucunun uzak masaüstüne erişebilmesi  için  sunucuya bu havuzdan bir IP atamak gerekiyor.

Bu senaryoda 10.0.0.50 IP’sini sunucunun ethernet katına ekliyoruz. Çift ethernet kullandığınız senaryolarda ise (Local ve Public) Local interface’e VPN IP Adres aralığında belirlediğiniz ağ’dan IP’yi sunucuya atayabilirsiniz.

Bu işlemlerden sonra VPN servisine istemcilerin (client) ulaşabilmesi için Windows Firewall’ında aşağıdaki portlara izin vermek gerekiyor.

Sunucu Üzerindeki Firewall Kuralları

Bu yapıda kesinlikle Windows’un varsayılan olarak aktif gelen Firewall’ı kapatmamanız gerekir. VPN servisinin dış dünya ile haberleşebilmesi için Firewall’a aşağıdaki kuralları girmemiz gerekiyor.

netsh advfirewall firewall add rule name="VPN Servisi TCP Allow" dir=in action=allow protocol=tcp localport=1723,1701,500

netsh advfirewall firewall add rule name="VPN Servisi UDP Allow" dir=in action=allow protocol=udp localport=500

netsh advfirewall firewall add rule name="VPN Servisi GRE Allow" dir=in action=allow protocol=47

Bu ayarlardan sonra VPN servisine Internet üzerinden herhangi bir istemci kimlik doğrulayabilir ve oturum açabilir hale gelecektir.

Windows 8 Üzerinden VPN Servisine Bağlanmak

VPN servisimize gerekli ayarlamaları yaptıktan sonra Windows 8 işletim sistemi üzerinden bağlanmak için yeni bir ağ bağlantısı ayarlanması gerekiyor. Bu işlemi ara yüzden kolayca yapabileceğiniz gibi aşağıdaki komut ile de yapabilirsiniz.

Add-VpnConnection -Name "VPN MaestroPanel" -ServerAddress vpn.maestropanel.net -RememberCredential

* -ServerAddress parametresini kendi sunucunuzun host ismi veya IP adresini girmelisiniz.

VPN Üzerinden Uzak Masaüstüne Bağlanmak

Windows üzerinden VPN servisimize bağlandıktan sonra direkt Uzak Masaüstü programımızı çalıştırıp 10.0.0.50’ye bağlandığımızda artık VPN servisi üzerinden local ağdaymış gibi güvenli bir şekilde Uzak Masaüstü yapabiliyor duruma gelirsiniz.

mstsc /v 10.0.0.50

Bonus

3389 olan RDP portunuzu mutlaka değiştirmenizi tavsiye ederiz. RDP Portunuzu değiştirmek için aşağıdaki yönergeyi uygulayabilirsiniz. Aşağıdaki senaryo RDP portunuzu 3389’dan 5589’a değiştirir. Değişikliklerin aktif olması için sunucuyu yeniden başlatmanız gerekmektedir.

1. Başlat > Çalıştır > Regedit komutunu verdikten sonra aşağıdaki anahtara erişin.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber

2. PortNumber değerini 5589 yapın.
5586 TCP portuna erişmek için Firewall’da izin vermek gerekiyor. Aşağıdaki komutu çalıştırın.

netsh advfirewall firewall add rule name="Yeni RDP Portu Izni" dir=in action=allow protocol=tcp localport=5589

3. Sunucuyu Restart edin.

Yeni Port ile uzak masaüstü bağlantısı gerçekleştirmek için aşağıdaki komutu kullanabilirsiniz.

mstsc /v 10.0.0.50:5589

Merhaba, bu yazımda sizler ile Office 365 Exchange Online üzerinde ki Mail Protection Reports adımlarını ve mailbox bazında nasıl rapor alınabileceğini paylaşacağım. Exchange Online Cloud yapısı sayesinde bildiğiniz üzere entegrasyonel ve kullana bilirlik açısından hayatımızı oldukça kolaylaştırdı. Tek çatı altında toplanan platformlar artık birkaç tık ile hizmetimize sunuluyor. Yoğun olarak Exchange Online platformundan yararlanan firmaların IT departmanları, raporlama kısmında her platform üzerinde olduğu gibi Exchange tarafında ‘da kullanma ihtiyacında olacaklardır. İşlemlerime başlayalım.

Öncelikle Mail Protection kısmına nasıl erişeceğiz görelim.

Office 365 platformumuza login olup, Admin altında Office 365 linkine tıklıyoruz.

Reports altında Protection kısmını inceleyeceğiz.

Diğer Report adımlarını daha sonra ki makalelerimde sizler ile paylaşacağım.

Top Senders and Recipients

Bu adımda platformumuz üzerinde en aktif mail gönderen, alan userlarımızı görebiliriz. 7, 14, 30 ve Custom seçenekleri ile belirttiğimiz tarihler arasında rapor çekebilme özelliğini bize sunuyor. 4 adet activity raporu olmamız mümkün, top mail recipients, top mail senders, top spam recipients ve top malware recipients.

Top malware for mail

Bu adımda platformumuz üzerinde en aktif malware gönderen, alan userlarımızı görebiliriz. 7, 14, 30 ve Custom seçenekleri ile belirttiğimiz tarihler arasında rapor çekebilme özelliğini bize sunuyor.

Malware detections

Bu kısımda malware olarak gelen veya takılan mailleri görebilir, gerektiğinde View pending or completed requests submit edebilirsiniz.

Spam detections

Bu kısımda Spam olarak gelen veya takılan mailleri görebilir, gerektiğinde View pending or completed requests submit edebilirsiniz. Table olarak görebilirsiniz.

Sent and received mail

Bu kısımda giden ve gelen maillerin tablo ve grafik ara yüzünü görebiliriz. Tarih bazında yoğunluğu gözlemleyebilirsiniz.

Şimdi ise kullanıcı bazlı Mail Protection Report’ u nasıl alacağımıza göz atalım. Öncelikle minik bir tool indirmemiz gerekiyor.

Mail Protection Reports for Office 365

Download: http://www.microsoft.com/en-us/download/details.aspx?id=30716

.net 3.5 kurulu olması gerekir. İndirdiğimiz aracı hızlıca bilgisayarınıza kurabilirsiniz. Windows 7, 8, 8.1 veya server platformu fark etmez.

Lisans kısmını kabul ediyoruz.

Microsoft Exchange Online adımını seçip, next ile sonra ki adıma geçiyoruz.

Finish ile kurulumu bitirdik.

Mail Protection Reports for Office 365 isminde masa üstüne kısa yolu otomatik atıyor.

Icon’ a çift tıklayınca aşağıda ki gibi bir pencere çıkıyor karşımıza.

Görüldüğü gibi bir excel sayfası, tab kısımlarını kontrol edersek, bir çok raporun tab’ ı mevcut. Traffic, Spam, Malware, Rules, Data Loss Prevention, Spam Mail Detail, Rule Mail Detail ve DLP Mail Detail gibi..

Üst tarafta bulunan Query kısmına tıklıyoruz.

Açılan ekrana user’ ın bilgilerini giriyoruz ve login butonuna tıklıyoruz.

İstediğimiz tarih aralığını belirtiyoruz.

Kullanıcının dataları load ediliyor.

Son duruma bakalım.

Örnek bir traffic tablosu. Benim test hesabım olduğundan traffic, spam, malware kısımları dolu değil. Live ortamda olası raporları tahmin ediyorsunuzdur J Traffic Type kısmında good mailden spam’ a kadar birçok seçeneği görebiliriz.

Tab’ ların içeriği

Faydalı olması dileğiyle.

Elektronik sertifika hizmetlerinin bilgi güvenliği ve kimlik doğrulamada kullanılması aslında yeni bir olgu değil. 1990’lı yılların sonlarından itibaren dünya genelinde ülkelerin yasal düzenlemelerine giren elektronik imza ve elektronik sertifika uygulamaları, artık günümüz bilişim sistemlerinin vazgeçilmez unsurları haline gelmiş durumda. Uzunca bir süredir yüksek oranlarda kullanılan diğer bir elektronik sertifika hizmeti olan SSL teknolojisinin aksine, sahadaki uygulamaların da tam desteğini gerektiren e-imza uygulamalarının ve ilgili e-imza sertifikalarının kullanımının çok daha yavaş yaygınlaştığını görüyoruz. Avrupa Birliği müktesebatını takip eden ülkemizin bu alanda bugün geldiği seviyeninse, pek çok Avrupa ülkesinin bile önünde olduğunu vurgulamakta yarar var.

Son yıllarda internet üzerinde artan kimlik doğrulama ve hesap verebilirlik (“accountability”) gereklilikleriyle birlikte, bilgi güvenliği alanında gerek e-imza sertifikalarının gerekse güvenlik sertifikalarının kullanımında artış gözlemlenmekte. Biz de bu yazımızda konuyla ilgili pekiştirici bilgiler verecek, TÜRKTRUST’ın sunmakta olduğu elektronik sertifika temelli bilgi güvenliği çözümlerine kısaca değineceğiz.

TÜRKTRUST Elektronik Sertifika Ürünleri

• Nitelikli Elektronik Sertifikalar (NES);Güvenli elektronik imza kullanımı amaçlı (5070 sayılı Elektronik İmza Kanunu kapsamında ve hukuken geçerli e-imza).

• SSL/TLS Sertifikaları: Web üzerinde güvenli iletişim amaçlı; sunucu kimlik doğrulama ve şifreli veri paylaşımı. Yaygın internet tarayıcısı (“browser”) uyumlu (Microsoft (IE), Mozilla (Firefox), Google (Chrome), Opera, Safari ve mobil cihazlar).

• Nesne İmzalama (Code Signing) Sertifikaları: Yazılım güvenilirliğini sağlama amaçlı; çalıştırılabilir yazılım parçalarının imzalanması.      
• Güvenlik Sertifikaları: Kimlik doğrulama (“authentication”) ve şifreleme amaçlı.

Yukarıda belirtilen tüm elektronik sertifikalar, Açık Anahtarlı Altyapı (“Public Key Infrastructure – PKI”) teknolojilerine dayanan X.509 sertifikalardır

Sertifika üretimi ve yönetimi özel bir uzmanlık alanı olduğundan, bu hizmeti verebilecek olan Elektronik Sertifika Hizmet Sağlayıcıları (ESHS), yaygın tabiriyle “Certification Authorities (CA)”, özel olarak yetkilendirilirler. E-imza amaçlı NES’ler, ilgili mevzuatta tanımlanan ve uluslararası standartlara göre belgeli güvenlik özelliklerine sahip özel donanımlar olan akıllı kartlar ve bunların bilgisayarlarla bağlantısını sağlayacak olan kart okuyucular veya akıllı çubuklar (“token”) ile kullanıma sunulur.

Yine Elektronik İmza Kanunu’nda tanımlanan zaman damgası teknolojisi ise elektronik imzanın ayrılmaz bir parçası, uzun dönemli e-imza doğrulamanın temel unsurudur. Zaman damgası sayesinde sayısal verilerin ve e-imzalı bilgilerin elektronik ortamda güvenli bir şekilde arşivlenmesi mümkün olmaktadır.

SSL ve nesne imzalama sertifikaları için Türkiye’de bir yasal düzenleme bulunmamaktadır. Bu hizmetler, dünya genelinde belirlenmiş uluslararası standartlar uyarınca yürütülmektedir. Sözgelimi, SSL sertifika hizmetlerini Avrupa temelli ETSI TS 102 042 ESHS Yönetim Sistemi standardı ya da Kuzey Amerika temelli WebTrust kriterleri uyarınca belgelendirmeyen ESHS’lerin SSL sertifikalarına ait kök sertifikaları internet tarayıcıları tarafından tanınmamaktadır. Uluslararası rekabet gerektiren bu hizmetlerin denetimleri de yine uluslararası denetim kuruluşları tarafından yapılmaktadır.

Güvenlik sertifikalarıysa, yine herhangi bir yasal düzenlemeye bağlı olmadan, ilgili PKI standartları uyarınca ESHS’ler tarafından sunulabilir. Burada asıl amaç, bilişim sistemlerine erişimi daha güvenli hale getirmek ve “çift faktörlü” kimlik doğrulama yöntemleriyle, alışılagelmiş “kullanıcı adı” ve “şifre” temelli zayıf kimlik doğrulama metotlarına güçlü alternatifler yaratmaktır. Yine NES’lerde olduğu gibi akıllı kartlar üzerinde kullanılmaları durumunda, güvenlik sertifikalarıyla hem sahip olunan bir unsur (akıllı kart) hem de bilinen bir unsur (akıllı kartın erişim şifresi – PIN) ile uygulamalara erişimi çift faktörlü olarak sağlamak mümkündür. Bu senaryoların bir adım ötesinde ise, doğrulama adımına kişisel bir biyometrik verinin de eklendiği 3-faktörlü kimlik doğrulama yöntemleri mevcuttur. Bu noktada maliyet, yönetim kolaylığı ve aranılan güvenlik düzeyi gibi unsurlar dikkate alınarak çözüm tercihi yapılabilir.

Elektronik Sertifika Kullanımı Sağlayan TÜRKTRUST Yazılım Çözümleri

Günümüz bilişim sistemlerinde, elektronik sertifikaların kullanımını sağlayan ve PKI teknolojilerine dayanan pek çok yazılım çözümü yaygın olarak kullanılmaktadır. TÜRKTRUST’ın da elektronik sertifika hizmetlerini yöneten, elektronik imza entegrasyonu sağlayan, kimlik doğrulama işlevi sunan, zaman damgası kullanımına imkân tanıyan, akıllı kart ve mobil sistemlerin yönetimini sağlayan pek çok çözümü bulunmaktadır. Bunlardan birkaçını burada öne çıkaracağız:

•             ARNICA – Elektronik İmza Yazılım Kütüphanesi (Java API, COM DLL, .NET)

Elektronik İmza Kanunu uyarınca elektronik imzalı veri oluşturma ve bu veriler üzerindeki imzaların doğrulama işlemlerinin yürütülebilmesi için, ilgili yazılım bileşenlerinin mevcut uygulama yazılımlarına entegre edilerek, e-imza kullanım özelliğinin sağlanmasına imkân veren TÜRKTRUST yazılım çözümüdür.

•             CASTAN – Akıllı Kart ve E-imza ile Web Üzerinde Kimlik Doğrulama Yazılımı

Web uygulamalarında, akıllı kartlar üzerinde bulunan sertifikalar ile kimlik doğrulama ve erişim yetkilendirmesi yapılmasını sağlayan TÜRKTRUST yazılım çözümü CASTAN, Elektronik İmza Kanunu uyarınca verilen NES’ler ve X.509 v3 standartlarına uygun diğer tüm sertifikalar ile çalışabilmektedir.

•             PLATAN – Elektronik Sertifika Hizmetleri Yönetim Yazılımı

Elektronik sertifikaların üretim ve yönetimi başta olmak üzere tüm yaşam döngüsü süreçlerinin yürütülmesini sağlayan TÜRKTRUST yazılım çözümü PLATAN, hiyerarşik kök ve alt kök sertifika yapıları oluşturabilme, sertifika profilleri tanımlayabilme ve donanım güvenlik modülleriyle (“hardware security module– HSM”) entegre çalışabilme özelliğine sahiptir.

Yukarıda bahsedilen sertifika ürünleri ve yazılım uygulamaları bir arada kullanılarak, ihtiyaca göre TÜRKTRUST tarafından çeşitli bütünleşik çözümler sunulmaktadır. Örnek bir bütünleşik çözüm senaryosu aşağıdaki şemada gösterilmiştir;

Bu senaryoda, PLATAN sistemi üzerinde üretilen e-imza amaçlı NES veya güvenlik sertifikaları, ARNICA ile e-imza entegrasyonu veya PKI kullanım altyapısı sağlanmış bir kurumsal yazılım üzerinden (doküman yönetim sistemi, kurumsal kaynak planlama yazılımı, web portali vb.) e-imzalı bilgi/belge gönderimi veya kimlik doğrulama amaçlarıyla kullanılabilmektedir. Kimlik doğrulama adımında CASTAN yazılımı kullanılmakta, internet üzerinden erişilen sunucuların doğru sunucu olduğunun belirlenmesi ve şifreli veri iletişimi ise SSL sertifikasıyla sağlanmaktadır. İstenildiğinde zaman damgası kullanımına da imkân veren bu bütünleşik çözüm, hem sertifika ürünleri hem de yazılım uygulamalarının bir araya getirilmesiyle TÜRKTRUST tarafından sunulabilmektedir.

Orchestrator uygulaması ile akışlar çizebilmemizin tek yolu Aktiviteleri kullanmaktır. Bu makalemde sizlere Orchestrator kurulumu ile birlikte hazır olarak gelen Aktiviteleri anlatacağım. Orchestrator kurulumu ile birlikte gelen aktiviteler sınırlı işlemleri yapabilmemizi sağlayabilirler ancak esas faydaları System Center IP leri ya da diğer 3. Parti aktiviteler ile birlikte ortaya çıkmakta. Hazır gelen temel aktiviteleri 9 ana başlık altında toplayabiliriz. Bu aktivitelerden bazıları isimlerinden yaptıkları işler tahmin edilebilmekte. Bu nedenle ekran görüntülerini paylaşacağım aktivitelerin tamamını açıklamayacağım. Şimdi bu aktiviteleri açıklamaya başlayalım.

System: Bu bölüm içerisinde sunucu, bilgisayarlar ya da network cihazları üzerinde ki temel işlemler yapılabilmektedir.

End Process aktivitesi ile bir sunucu ya da bilgisayar üzerinde ki bir servisi durdurabiliriz.

Get SNMP Variable ile ortamımızda bulunan bir network cihazından bilgi alabilmemizi sağlar.

Monitor SNMP Trap ile ortamımızda bulunan network cihazlarında ki event leri izlememizi böylece örneğin oluşan bir sorun da farklı bir runbook u çalıştırarak operations manager üzerinde alert oluşturacak runbook u tetiklememizi sağlayabilir.

Query WMI aktivitesi ile birlikte adından da anlaşıcağı üzere belirlenen sisteme wmi sorgusu atabilmemezi sağlayabiliriz.

Restart System aktivitesi ile bir sunucu ya da bilgisayarı yeniden başlatabiliriz.

Run .Net Script aktivitesi ile farklı programlama dillerinde (örneğin c#, java ya da powershell gibi) yazılmış olan script lerin çalıştırılmasını sağlayabiliriz.

Run Program aktivitesi ile bir uygulamanın ya da komutu belirlediğimiz bir sistem üzerinde çalıştırabiliriz.

Run SSH Command aktivitesi ile birlikte bir network cihazı ya da storage a ssh ile bağlanıp gerekli olan komutları çalıştırmayı sağlayabiliriz.

Save Event Log aktivitesi ile belirlediğimiz bir sunucu üzerinde ki Application, System vb event log larını bir dosyaya kayıt edebilir, dilersek bu event log u kayıt etmeden önce içeriğini filtreleyebiliriz (sadece error ya da warning ler gibi)

Send SNMP Trap aktivitesi ile network cihazları tarafından tespit edilebilen SNMP olayları oluşturulabilir.

Set SNMP Variable aktivitesi ile bir network cihazı üzerinde tanımlı olan bir değişkenin değeri değiştirlebilir.

Start/Stop Service aktivitesi ile bir sunucu üzerinde ki belirlenen bir servise start, stop, pause ya da restart komutları gönderilebilir.

Scheduling: Bu bölüm  içerisinde iki temel işlem yapılabilmekte.

Monitor Date/Time aktivitesi ile bir runbook başlatılabilir ve böylece belirlenmiş olan tarih veya zaman geldiğinde runbook un akışı işletmesi sağlanabilir.

Check schedule aktivitesini kullanabilmemiz için öncelikle Global Settings altında bulunan Schedules içerisinde Schedule oluşturulmuş olmalıdır. Oluşturulan bu schedule ile zamanlamanın çalışacağı günler ve saatler belirlenebilmektedir. Böylece bir runbook un örneğin mesai saatleri dışında ve sadece hafta sonları çalışabilmesini sağlamış oluruz.

Monitoring: Bu bölümde aktiviteler iki ana bölümde toplanmıştır. İlki GET ile başlayan aktivitelerdir ve bunlar ile o anki durumun kontrolü yapılır. MONITOR ile başlayan aktiviteler ise bir runbook başlatmak için kullanılabilir ve belirlenen aralıklarla bu kontrol tekrarlanır. Beklenen durumun gerçekleşmesi durumunda bir runbook tetiklenebilir ya da çağrılabilir (invoke)

Get Computer/IP Status aktivitesi ile uzaktaki bir sunucu ya da bilgisayarın ayakta olup olmadığı kontrol edilebilir.

Get Disk Space Status aktivitesi ile uzak sunucu ya da bilgisayarın belirlenen diski üzerinde ki boş disk alanı kontrol edilebilir.

Get Internet Application Status aktivitesi ile bir web sitesinin (uygulamasını) ayakta olup olmadığı kontrol edilebilir.

Get Process Status aktivitesi ile uzak bir sunucu ya da bilgisayar üzerinde ki bir işlemin (çalışan uygulamalar vb)  durumu kontrol edilebilir.

Get Service Status aktivitesi ise yukarıdakinden farklı olarak uzak bir sunucu ya da bilgisayar üzerinde ki bir servisin durumu kontrol edilebilir.

Monitor Computer/IP aktivitesi ile uzak bir sunucu ya da bilgisayarın ulaşılabilir olup olmadığı belirli aralıklar ile kontrol edilebilir. Bu aktivite ile runbook başlatılabilir ve sonucuna göre runbook tetiklenebilir.

Monitor Disk Space aktivitesi ile belirtilen sunucu ya da bilgisayarın üzerinde ki bir disk alanı izlenir ve belirtilen eşik değeri geçtiğinde gerekli işlemlrt yapılabilir ya da farklı bir runbook çağrılabilir.

Monitor Event Log aktivitesi ile belirtilen sunucu ya da bilgisayarın event log ları izlenir ve filtreye uyan bir event ile karşılaşıldığında gerekli işlemler yapılabilir ya da farklı bir runbook çağrılabilir.

Monitor Internet Application aktivitesi ile uzak bir sunucu üzerinde çalışan web uygulaması izlenir ve testin başarılı olması ya da başarısız olması durumlarında gerekli işlemler yapılabilir ya da farklı bir runbook çağrılabilir.

Monitor Process aktivitesi ile belirtilen sunucu üzerinde ki bir prosesin (uygulamanın) durumu izlenir ve ilgili prosesin started ya da stopped durumlarında gerekli işlemler yapılabilir veya farklı bir runbook çağrılabilir.

Monitor WMI Query aktivitesi ile belirtilen sunucuya gönderilen wmi query nin sonucu uygun olduğunda gerekli işlemler yapılabilir veya farklı bir runbook çağrılabilir.

Monitor Service aktivitesi ile belirtilen sunucu üzerinde ki ilgili servisin durumu izlenir ve servisin durumunun started, stopped or paused olması hallerinde gerekli işlemler yapılabilir veya farklı bir runbook çağrılabilir.

Email: Bu bölümde tek bir aktivite bulunmaktadır o da Send Email aktivitesidir. Bu aktivite sayesinde örneğin runbook içerisinde ki iş akışımız tamamlandığında belirtilen alıcılara email atılarak runbook sonucu yazılı bir şekilde iletişmiş olur. Ancak bu aktivitenin çalışabilmesi için ortamda bir smtp sunucusu bulunmalıdır. Bu herhangi bir windows sunucu üzerinde etkinleştirilmiş olan SMTP Server rolü ya da ortamda bulunan bir Exchange sunucusu da olabilir. Ancak ben genel olarak Exchange IP si ile birlikte gelen mail gönderme aktivitesini kullanmayı tercih ediyorum. Çünkü hem exchange alt yapısını kullanıyor hem de çok daha fazla seçenek sunuyor.

Notification: Bu bölüm aslında her runbook içerisinde kullanılması gerekli olan log tutma işlemlerinin yapılmasını sağlayan aktiviteleri içermektedir.

Send Event Log Message aktivitesi ile çalıştırmış olduğumuz bir runbook içerisinde belirlediğimiz işlemler sonrası istenen sunucuda bulunan Application Event Log na Information, Warning ya da Error seviyelerinde log yazdırabiliriz.

Send Platform Event aktivitesi ile bir önceki makalemizde anlattığım üzere Runbook Designer içerisinde bulunan bölümde ki Events alanına belirlenen işlemler sonucunda Information, Warning ve Error tiplerinde Event yazdırabilmemizi sağlar.

Send Syslog Message aktivitesi ile runbook içerisinde ki aktivitelerin sonucunda belirtilen syslog sunucusuna log gönderilebilmesini sağlar. Örneğin active directory üzerinde bir kullanıcı oluşturulduğunda ilgili syslog sunucusu üzerinde de bir kayıt oluşturulması sağlanabilir.

Format Date/Time aktivitesi ile çalışan bir runbook içerisinde tarih saati dilediğimiz bir formata dönüştürebimemizi sağlar. Örneğin runbook çıktısı olan yyyy-MM-ddThh:mm:ss formatında ki tarihi gg/aa/yyyy olarak değiştirebiliriz.

Generate Random Text aktivitesi ile belirleyeceğimiz uzunlukta Lower-Case Characters (küçük harf), Upper-Case Characters (büyük harf), Numbers (rakamlar), Symbols (özel karakterler) karakterlerinden oluşan metinler üretebiliriz. Tahmin edeceğiniz gibi en çok bir kullanıcı için parola oluştururken kullanılmaktadır.

Get Counter Value aktivitesi ile Global Settings altında daha önceden oluşturulmuş olan bir Counter (sayaç) ın o anki değeri elde edilir.

Invoke Web Services aktivitesi ile bir web servisi runbook içerisinden çağrılabilir.

Modify Counter aktivitesi ile Global Settings altında daha önceden oluşturulmuş olan Counter ın değeri azaltılabilir, arttırılabilir ya da sıfırlanabilir.

Monitor Counter aktivitesi ile Global Settings altında daha önceden oluşturulmuş olan Counter değeri runbook içerisinde izlenebilir ve belirlenen değere geldiğinde runbook içerisinde ki farklı bir link üzerinden akışın devam ettirilmesi sağlanabilir.

Compare Values aktivitesi ile iki metin ya da sayısal değer eşit olması, farklı olması vb seçeneklere göre  karşılaştırılması sağlanabilir.

Query Database aktivitesi ile Access, SQL Server ya da Oracle üzeride ki bir veritabanına yazılan query (sorgu) gönderilebilir ve sonucu satılar olarak alınabilir.

Write To Database aktivitesi ile Access, SQL Server ya da Oracle üzeride ki bir veritabanında ki bir tabloya satır yazılabilir.

Text File Management: Bu bölümde ki aktiviteleri kullanarak metin dosyaları üzerinde satır ekleme, satır silme, metin bulma, belli bir satır numarasına ekleme, satır okuma, belirli bir metni bulup değiştirme gibi işlemleri gerçekleştirebiliriz.

Runbook Control:

Initialize Data aktivitesi ile runbook başlatabilir ve böylece başlattığımız runbook a veri gönderilmesi sağlanır.

Return Data aktivitesi ile invoke ederek çağırdığımız runbook da elde ettiğimiz veriyi invoke işlemini başlattığımız runbook a veri olarak gönderilmesi sağlanır.

Junction aktivitesi ile runbook içerisinde oluşan dallanmaların tamamının işlemlerinin bitmesinin beklenmesi sağlanır.

Invoke Runbook aktivitesi ile bir runbook içerisinden başka bir runbook çağırılabilir ve çağırılan runbook da bulunan initialize data aktivitesine çağıran runbook dan veri aktarılabilir.

Bu makalemde sizlere Orchestrator kurulumu ile birlikte hazır olarak gelen Aktiviteleri anlatmaya çalıştım.

Faydalı olması dileğiyle...

Merhaba yeni bir Microsoft Azure makalesi ile yine birlikteyiz. Bu makalemizde herkesin merak ettiği ve sorduğu bir soruya cevap bulmaya çalışacağız. Microsoft Azure nedir, nasıl kullanılır az çok bundan önceki makaleleri okuyan arkadaşlar bilgi sahibidir. Azure tarafında IAAS tarafındaki Virtual Machine servisi biz IT Pro ların çok sıklıkla kullandığı bir alandır. Burada bir galeryden hazır OS image larını yükleyebiliyoruz. Peki kendi yaratığımız ya da kullandığımız bir OS ‘ i nasıl Azure üzerinden kullanabiliriz. Bu makalede size bundan bahsetmek istiyorum.

Makalemizi üç bölüme ayırabiliriz. İlk olarak kullanmakta olduğumuz VHDX sanal sunucularımızı VHD formatına çevirmemiz gerekiyor. Çünkü VHDX disk formatını şu anda Microsoft Azure desteklemiyor. Bunu bir tane powershell komutu ile gerçekleştirebiliriz. Aşağıda bu komutu nasıl kullanacağımızı gösteriyorum. Hyper-V kurulu server üzerinde komutu çalıştırabiliriz.

PS C:\> Convert-VHD –Path c:\test\TESTVM.vhdx –DestinationPath c:\test\AZURETEST.vhd

                İkinci bölüm olarak kullandığımız Microsoft Azure hesabımızı powershell ile bağlantı ayarlarını yapmamız var. Bunun makalesini daha önceden yazmış ve yayınlamıştık fakat o makaleden sonra kurulum ufak bazı değişikliklere uğradı. Aşağıda nasıl bağlantı sağlayacağımızı anlatıyorum ;

                İlk olarak aşağıdaki linkten Web Installer 5.0 paketini indiriyoruz ve oradan yükleyeceğimiz paketleri seçiyoruz. Biz Microsoft Azure için powershell setini yüklüyoruz.

                http://go.microsoft.com/?linkid=9811175&clcid=0x409

Microsoft Azure için Poweshell komutlarını yükledikten sonra aşağıdaki komutu çalıştırıyoruz.

PS C:\> Get-AzurePublishSettingsFile

Bu komutu çalıştırdıktan sonra sistem bizi Microsoft Azure login sayfasına yönlendirir ve bizden Microsoft Azure hesap bilgilerimiz ile login olmamızı ister.

Hesap bilgilerimizi girdikten sonra otomatik olarak bizim publishsettings dosyamız oluşur ve download etmemiz gerekmektedir.

Publish settings file mızı download ettikten sonra aşağıdaki şekilde sisteme import etmemiz gerekiyor.

PS C:\> Import-AzurePublishSettingsFile <PathToFile>

Komutun sonucunda aşağıdaki gibi bir çıktı verir.

Bu şekilde artık powershell üzerinden Microsoft Azure hesabımızı kontrol edebiliriz.

Bu konfigürasyonlardan sonra yapmamız gereken localde olan bir VHD yi Microsoft Azure tarafına upload etmemiz.

Bunun için powershell komutlarını kullanıyoruz. Aşağıda nasıl yapılacağını göstermeye çalıştım. Esasında direk üçüncü çalıştırdığımız komut ilede bu işlemlerleri yapabiliriz. Fakat ben daha düzenli bir şekilde nasıl yapılacağını gösterdim. Aynı anda birden çok vhd upload etmemiz gerekirse bu şekilde çok daha kolay olabiliyor.

$sourceVHD = “C:\App\TestAzure.vhd”

$destinationVHD =“https://portalvhdsxfr2x09cnyc0r.blob.core.windows.net/vhds/TestAzure.vhd”

Add-AzureVhd -LocalFilePath $sourceVHD -Destination $destinationVHD NumberOfUploaderThreads 3

Upload işlemi başladığında aşağıdaki gibi bir ekran ile karşılaşırsınız.

Upload işlemi bittiğinde, upload olan vhd ve yerini görebilirsiniz.

VHD upload işlemi bittiğinde portal üzerinden vhd mizi kontrol edebiliriz. Bunun için storage tabı altında hangi storage account altına upload ettiysek onun içine giriyoruz.

Şekilde görüldüğü gibi upload ettiğimiz vhd storage account tumuzu altında gözüküyor. Bu VHD den bir sunucu yaratmak için bu VHD yi galery altında MY DISK tabında görmemiz gerekiyor. Bunun içinde aşağıdaki işlemleri yapmalıyız.

Yine powershell yardımı ile upload ettiğimiz VHD yi bir OS Disk haline getiyoruz.

Add-AzureDisk -DiskName 'Windows-2012-R2-Test' -MediaLocation $destinationVHD -Label 'Windows-2012-R2-Test' -OS Windows

Bu işlemlerden sonra artık upload ettiğimiz vhd den bir sanal sunucu oluşturabiliriz.

Bir Microsoft Azure makalemizin daha sonuna geldik. Başka bir makalede görüşmek üzere. Bol bulutlu günler J

Herkese merhaba yeni bir Microsoft Azure makalesi ile yeniden birlikteyiz. Bir önceki makalemizde sanal sunucuların Microsoft Azure üzerine taşınması konusuna devam ediyoruz. Bir önceki makalemizde local networkümüzde kurulu olan Hyper-V ortamımızdan Microsoft Azure üzerine nasıl taşıyabileceğimizi anlatmaya çalıştık. Şimdiki konumuz VMware ortamındaki bir sanal sunucuyu Microsoft Azure üzerine nasıl taşıyacağımızı anlatmaya çalışacağım.

Makaleyi iki bölümden oluşturmaya karar verdim. İlk bölümde Microsoft Virtual Machine Converter kurulumundan önceki ayarlardan bahsedeceğim. İkinci bölümde uygulamanın kullanımı ve bir VMware sanal sunucusunun Microsoft Azure üzerine taşınma işlemlerine bakacağız.

Esasında bu konu birkaç yöntemden oluşuyor. Ben bu makalede Microsoft’ tun bir ürünü olan Microsoft Virtual Machine Converter tool ile taşımanın nasıl yapılacağını anlatacağım. Makalenin ilerleyen kısımlarından tooldan MVMC olarak bahsedeceğim.

İlk olarak biraz araçtan bahsedicek olursak. Tool sadece VMware üzerinde çalışan sunucuları Microsoft Azure üzerine taşımıyor. Ayrıca fiziksel olarak çalışan bir sunucuyu Hyper-V üzerine convert etmemizi yani P2V yapmamızı sağlıyor. Ayrıca yine VMware ortamından sunucuları sistemlerinizde kurulu olan Hyper-V sunucular üzerinde çalışabilmesi için gerekli convert işlemlerini gerçekleştiriyor.

Uygulamayı kurmadan önce işlemlerin yapılacağı server üzerinde bir sertifika oluşturup bu sertifikayı Microsoft Azure tarafına yüklememiz gerekiyor. Bu sertifika sayesinde Microsoft Azure hesabımızda ki storage accountlara ulaşabilir duruma geleceğiz. Şimdi bu işlemleri nasıl yapacağımızı göstermeye çalışıyoruz. Makalelerimi takip edenler bilir sertifika oluşturmak için meşhur bir aracımız var makecert.exe J sertifika işlemlerini bu tool ile yapacağız. Bu exe ye ulaşabilmek için Windows Software Development Kit (SDK) for Windows 8 download edip kurmamız gerekiyor. Download etmek için şu adresi http://www.microsoft.com/click/services/Redirect2.ashx?CR_EAC=300105886 kullanabilirsiniz.

Dosyayı indirdikten sonra kurulumu başlatıyoruz. Standart kurulum adımları var bunları geçiyoruz. Daha sonra bize hangi paketleri kurmak istediğimizi soran bir ekran geliyor burada sadece Windows Software Development Kit seçeneğini seçiyoruz ve kuruluma başlıyoruz.

Kurulum standart bir Windows uygulaması gibi ilerliyor. Ekstra bir ayar yapmanıza gerek yok.

Kurulum tamamlandıktan sonra aşağıdaki ekran görüntüsündeki path e gidersek makecert.exe uygulamasının orada olduğunu görmemiz gerekiyor.

Uygulamanın kurulumunun bittiğini ve uygulamayı orada gördükten sonra bir command line (cmd) ekranı açıyoruz ve o path e gidiyoruz ve aşağıdaki komut sayesinde sertifikamızı oluşturuyoruz. Aşağıdaki komut üzerinde değiştireceğiniz tek şey yaratacağınız sertifikanın ismidir. Ben burada ekran görüntüsünde de  anlaşılacağı üzere MVMC ismini verdim. Succeeded ibaresini görüyorsanız sertifika yaratma işlemimiz başarılı bir şekilde bitmiştir. Bu komut ile yaratılan sertifika yine gittiğiniz path içinde yaratılıyor. Yani acaba sertifikam nerede diye aramayın.

makecert.exe -r -pe -n CN=SertifikaIsmi -ss my -sr localmachine -eku 1.3.6.1.5.5.7.3.2 -len 2048 -e 01/01/2016 SertifikaIsmi.cer

Sertifika yaratıldıktan sonra otomatik olarak kendisini Local Computer – Personel – Certificates altına atar. Bunu kontrol etmek içinde bir mmc penceresi açıp yukarıdaki menülerden File – Add/Remove Snap in ve açılan menüden de Certificates ‘i seçip Add diyoruz. Daha sonra Computer account şeçip next finish dedikten sonra bize local computer üzerinde sertifikaları listeliyor.

Aşağıdaki ekran görüntüsünde gördüğünüz gibi sorunsuz yarattığımız sertifika orada. Sizde bu şekilde bir kontrol ile sertifikamızın sorunsuz yaratılıp yaratılmadığını anlayabilirsiniz.

Daha sonra Local Computer – Personel altında olan sertifikamızı Current Users – Trusted Root Certification Authorities altına taşımamız gerekiyor. Çünkü MVMC uygulması buradan da sertifikaya bakıyor ve hata vermemesi için bu taşımayı yapmamız gerekiyor. Yapmamız gereken tek şey yukarıda sertifika kontrolü yaparken nasıl Computer account ile açıyorsak bu sefer My user account ile açıyoruz ve sertifikamızı Trusted Root Certification Authorities altına import ediyoruz.

Yarattığımız sertifikada bir sorun olmadığına göre sıra geldi bu yarattığımız sertifikayı Microsoft Azure üzerine upload etmeye. Bunun için Microsoft Azure portalına gidiyoruz ve login oluyoruz. Login olduktan sonra sol taraftaki menü barın en altında SETTINGS kısmına gidiyoruz buraya gittikten sonra sağ tarafta açılan menüden MANAGEMENT CERTIFICATES tabına geçiyoruz. Burada  aşağıdaki menüden UPLOAD diyoruz.

UPLOAD dedikten sonra bize localdeki sertifikamızın UPLOAD edeceğimiz bir menü geliyor. Burada sertifikayı gösterip OK diyoruz.

Ve yarattığımız sertifika Microsoft Azure hesabımıza UPLOAD oluyor.

Sertifika UPLOAD olduktan sonra aşağıdaki gibi sertifikanızı MANAGEMENT CERTIFICATES altında görüyor duruma geliyorsunuz.

Makalemizin bu kısmında Microsoft Virtual Machine Conventer kurulumundan önceki adımları göstermeye çalıştım. Bir sonraki makalede MVMC üzerindeki işlemler ile devam edeceğiz. Bundan sonraki makalede görüşmek üzere. Bu bulutlu günler J

Herkese merhaba yeni bir Microsoft Azure makalesi ile yine beraberiz. Bu makale bir devam makalesi ilk makalemizde MVMC uygulamasının kurulmadan önceki adımları göstermiştik. Bu makalede ise kurulum ve diğer adımlar bahsetmeye çalışacağım. Uygulama hakkında kısa bilgileri ilk makalemizde verdiğim için direk kuruluma ve kullanıma geçiyorum.

Kurulum için MVMC uygulamasının kurulum dosyasını indirmemiz gerekiyor. Şuanda 3.0 versiyonu mevcut indirmek için bu adresi kullanabilirsiniz: http://cozumpark/1xph4Ql . Uygulamayı indirdikten sonra çok basit bir kurulum ile uygulamayı kuruyoruz. Standart bir kurulum olduğu için herhangi bir ekran görüntüsü paylaşmıyorum.

Uygulamayı kurduktan sonra uygulamayı açtığımızda aşağıdaki gibi bir ekran bizi karşılar. Biz burada Virtual machine conversion seçerek ilerliyoruz.

Daha sonra bize nereye convert edeceğimizi soruyor. Biz burada Migrate to Microsoft Azure diyerek devam ediyoruz.

Gelen ekranda bundan önceki makalede anlattığımız sertifika upload olayını neden yaptığımız ortaya çıkıyor. Burada MVMC nin Microsoft Azure ile iletişime geçmesi için sertifika bilgilerine ihtiyaç duyuyor. Biz bu bilgileri Microsoft Azure portaldan öğrenebiliriz. Yine sertifika upload ederken gittiğimiz Management Certificates kısmına gidiyoruz ve orada yüklediğimiz sertifkanın Thumbprintini ve Subscription bilgilerini kopyalıyoruz.

Ve gelen ekranda bu bilgileri yazarak devam ediyoruz.

Bu adımdan sonra Microsoft Azure hesabımıza bağlanmış oluyoruz ve aşağıdaki ekran görüntüsünden de anlaşılacağı üzere Microsoft Azure hesabımızda yaratmış olduğumuz storage accounlarımızı görüyoruz ve burada convert edecağimiz sanal sunucumuzu nereye yükleyeceğimizi seçiyoruz. Ben test için mvmcstore adında bir storage account oluşturmuştum. Onu seçip devam ediyorum.

Gelen ekranda sizden VMware vCenter yada bağlanacağınız ESX host bilgilerini girmeniz gerekiyor. Yetkili bir kullanıcı ismi ve şifresi, gerekli ip bilgisini girdikten sonra devam ediyoruz. Burada eğer vCenter bağlantısı yapacaksanız domain\username şeklinde bağlantı kurmanız gerekiyor.

Bu ekranda convert edeceğimiz suncuyu bulup next ile devam ediyoruz.

Conneciton ekranında bize hangi kullanıcı ile bu işlemleri yapacağımızı soruyor. Bu kullanıcının convert edeceğimiz sanal sunucu üzerinde yetkili haklara sahip olması gerekiyor. Eğer sunucu domain üyesi değil ise yine sunucu üzerinde yetkili bir kullanıcı tanımlamamız gerekiyor.

Daha sonraki ekran bizden VMware üzerinden çevireceği sunucuyu ilk olarak localde bir yere atacağı yeri soruyor. Ben burada sunucu üzerinde bir yer seçiyorum.

Son ekranımızda bize kısa bir özet gösteriyor. Finish diyerek convert işlemine başlıyoruz.

Burada makalemizin sonuna geldik. Bu işlemlerden sonra sorunsuz şekilde. Sunucumuz Microsoft Azure üzerinde çalışmaya başlıyor. Bir başka makalede görüşmek üzere. Bol bulutlu günler J

Microsoft Failover Cluster ile yaşanan/karşılaşılan problemlerin büyük bir bölümü yanlış/eksik kurulumlardan dolayı olduğunu tespit etmiş bulunmaktayım. Bu nedenle siz değerli okuyucularımızın kurulum ve sonrasında olası problemlerin yaşanmaması adına Windows Server 2012R2 için detaylı olarak Cluster ortamımızın ve Node’ların hazırlanmasını içeren bu makale hazırlanmıştır.

Active Directory Üzerinde yapılacaklar:

Bu kısım Cluster kurulumunun en önemli adımlarını oluşturmakta. Eğer bu şekilde kurulum yapılmazsa etkisi olmamakla birlikte ve bilinen bir soruna neden olmamakla birlikte System Event Error Log 1196 mesajı alınabilir.

AD üzerinde obje oluşturmasına yetkili bir hesap ile “Active Directory Users and Computer”  veya kısa adıyla dsa.msc çalıştırılır. Gelen ekranda Cluster’da kullanacağımız Group ve Resource isimlerine ait Computer objelerini oluşturun.

Oluşturmuş olduğunuz objede Properties içinden Security’ye gelerek

Makine isimlerini ve kurulumu yapacak hesabı ekleyip full yetki verin.

Yetki işlemleri tamamlandığında obje üzerinde sağ tıklayıp Disable edin.

Oluşturduğunuz objelerin bulunduğu OU üzerinde sağ tıklayıp Properties’e gelin. Açılan ekranda Object sekmesine gelip “Protect object from accidental deletion” işaretleyin.

Redirection’ın Kapatılması:

Cluster sistemlerinde en çok baş ağrıtan noktalardan birisi maping işlemleridir. Bu aşamada sunucularda sistem stabilitesini sağlama adına ve olası problemlerin önlenmesi için uzak bağlantı ile gelen port ve printer yönlendirmelerinin kapatılması gerekmektedir. Server 2012 R2’de RDS role’ü kurulmadan “Remote Desktop Session Host Configuration Tools” gelmemektedir.

Bu işlem için ilk yöntem ve eğer sisteminizde 2008 / 2008R2 sunucularımız varsa, üzerinden Control Panel’inden Administrative Tools >> Terminal Services (Remote Desktop Services) >> Terminal Services Configuration’u (Remote Desktop Session Host Configuration) çalıştırın. Gelen ekranda “RD Sesion Host Configuration” üzerinde sağ tıklayıp “Connect to Remote Desktop Sesion Host Server”’ı seçin.

Gelen ekranda “Another Computer” seçmesini tıklayıp açılan alana yöneteceğiniz sunucunuzun ismini girin. Gelen ekranda RDP-Tcp üzerinde sağ ile tıklayıp Properties girin.

Açılan ekranda  “Client Setting” altında Clipboard hariç hepsini işaretleyin.

İkinci yönden ise GPO ile yapmaktır. GPO’dan yapmak için; Computer Configuration >> Policies >> Administrative Templates >> Windows Components >> Remote Desktop Services >> Remote Desktop Session Host >> Printer Redirection altındaki değerler aşağıdaki gibi yapılır.

Ayrıca Computer Configuration >> Policies >> Administrative Templates >> Windows Components >> Remote Desktop Services >> Remote Desktop Session Host >> Device and Resource Redirection altındaki değerler aşağıdaki gibi yapılır.

Açık Sesion Sürelerinin Sınırlandırılması:

Performans ve olası problemlerin önlenmesi için Sunucuya bağlanan kullanıcıların belli bir süre sonra logoff edilmesi gerekmektedir. Kendi yapınıza göre uygun süreyi belirleyebilirsiniz. Bu işlem için Remote Desktop Session Host Configuration Tools’da Session sekmesini tıklayın. Açılan pencerede;

Idle Sesion Limit: Sunucuya bağlanan kullanıcının ne kadar süre boşta kaldığında disconnect yapılacağı belirleniyor.

Override user settings: Sunucuya bağlanan kullanıcıların ne kadar süre disconnect’te kaldığında logoff edileceği belirleniyor.

When sesion limit is reached or connection is broken: Sunucuya daha önceden hesap açmış bir kullanıcı yeniden bağlanırsa ne yapılacağı soruluyor. Burada ya “disconnect from sesion” secilerek aynı oturumuna bağlanması sağlanabilir veya “end sesion” denilerek öncekini sonlandır yeni oturum aç diyebilirsiniz.

Eğer Group Policy üzerinden yapılmak istenilirse “Computer Configuration >> Policies >> Administrative Templates >> Windows Components >> Remote Desktop Services >> Remote Desktop Session Host >> Sesion Time Limits” altındaki aşağıdaki ayarlar yapılır.

Anti Virüs:

Sunucular üzerine kurulacak anti-virüs muhakkak yönetilebilir ve sunucu mimarisine uygun olmalıdır. Microsoft tarafından özel olarak oluşturulup yayınlanan Anti-Virus Exclusion Listesine bakarak servisiniz için uygulanacak exclution tanımlarını aşağıdaki linkte gösterildiği gibi yapınız.

Windows : http://support.microsoft.com/kb/822158

Cluster : http://support.microsoft.com/kb/250355

Hyper-V:http://social.technet.microsoft.com/wiki/contents/articles/2179.hyper-v-anti-virus-exclusions-for-hyper-v-hosts.aspx

Bununla birlikte sanallaştırma sistemleri için üretilmiş Deep Security yazılımları ile Host (Hyper-V) üzerine kuracağınız antivirüs ile guest (sanal sunucularınıza) antivirüs kurmadan koruma imkanınız bulunmakta. Fakat bu sistemi devreye almadan önce test edilmesi gerekmektedir.

Firewall / Güvenlik:

Benim önerim sunucu üzerinde firewall işlemi yaptırmamak. Bunun yerine sunucular ile client arasında konulacak firewall cihazı ile daha iyi ve sorunsuz hizmet alınabilir. Nedeni ise eğer Windows Firewall düzgün yapılandırmazsa tahmin edilemeyecek sorunlara neden olunabilir. Bu yüzden benim önerim Control panelinden Windows Firewall’a girilip “Turn Windows Firewall on or off” tıklandıktan sonra açılan ekranda tüm değerleri “Turn Off”’a cekin.

Cluster için firewall’dan izin verilecek port bilgileri aşağıdaki gibidir.

DEP’in Kapatılması:

Backup alma işlemlerinde en çok sorun yaşatan Data Execution Prevention değerini “Windows Programs and services” yapınız. Bu işlem için isterseniz Privilege (Run as Administrator) mode’da açılan komut penceresine “bcdedit.exe /set {current} nx OptIn” komut yazılıp enterlanır. İstersenizde “Control Panel >> System >> Advanced system settings >> Advanced >> Performans >> Settings >> Data Execution Prevention” altından ulaşabilirsiniz.

UAC’ın Kapatılması:

Backup işlemini network agent’ı üzerinden yapılıyorsa olası problemlerin yaşanmaması için önerim UAC’ın (User Account Control Settings) kapatılmasıdır. Bu işlem için “Control Panel >> System and Security >> Action Center” altındaki “Change User Account Control Settings” tıklayıp açılan pencerede çubuğu aşağı çekerek “Never Notify”’ye getirin.

Sadece buradan kapatmak yetmiyor. Windows+F tuş kombinasyonuna basarak açılan ekranda regedit yazıp “Run As Administrator” ile çalıştırın.

“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\” altındaki EnableLUA anahtarını 1 yapıp sunucuyu restart edin. Eğer EnableLUA yoksa ise EnableLUA isimli yeni bir DWORD (32 bit) oluşturup değerini 1 yapın.

Ayrıca Server Manager Tools’dan Local Security Policy’e giriniz. Açılan ekranda “Local Policies >> Security Option” veya Group Policy’den “Computer Configuration >>  Windows Setting >> Security Setting >> Local Policies >> Security Options” altındaki “User Account Control: Run all administrators in Admin Approval” değerini Disabled yapınız.

IE ESC Kapatılması

Server Manager’ın ana ekranında öncelikle “Local Server” tıklayın. Açılan pencerede “IE Enhanced Security” yanındaki ON’u tıklayın. Açılan ekranda hepsini OFF’a getirin.

NMI’ın Aktif Edilmesi

İşletim sistemi cevap veremeyip siyah ekranda kaldığında sunucu donanıma ait uzak bağlantı konsolundan memory dump alınarak restart edilmesi için OS’e gelen NMI isteklerinin kabul edilmesi sağlamak için regedit Run as Administrator ile açılıp aşağıdaki adımlar uygulanır.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl altına NMICrashDump isimli yeni bir DWORD oluşturulup değeri 1 yapılır

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WHEA\Policy altına NMICrashDump isimli yeni bir DWORD oluşturulup değeri 1 yapılır

TCP Ayarlarının Özelleştirilmesi

Hyper-V, File Server, SQL Server, Exchange, RDS ve Print Server gibi servisler yoğun TCP işlemleri yaptığından bazen OS katmanın network seviyesinde hatalara neden olabilir. Bunun çözümü olarak aşağıdaki ayarların yapılması gerekmektedir.

Administrator ile çalıştırılmış regedit ile Register’a aşağıdaki değerleri ekleyin.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

"TcpTimedWaitDelay"=dword:00000030

"MaxUserPort"=dword:0000fffe

Administrator ile çalıştırılmış komut satırından aşağıdaki komutları çalıştırın

netsh int ipv4 set dynamicport tcp start=1025 num=64510

netsh int ipv4 set dynamicport udp start=1025 num=64510

Power Option Ayarları:

Sunucu performansı için Contol Panel’den PowerOption’a girip “High Performance” a getirin.

Network Ayarları:

Klasik ve basit cluster yapısında Nodelar arasındaki cluster iletişimi için bir heartbeat dediğimiz PRIVATE network’üne birde cluster’da hizmet verdiğimiz servisin dış ortamla iletişimde bulunduğu PUBLIC network’üne ihtiyaç bulunmaktadır.

Server 2008R2 ile birlikte eğer private networkten node’lara erişemezse public interface’i üzerinden erişim denenir iletişim sağlandığında sistem down olmadan cluster verileri public üzerinden akmaya devam eder. Aslına bakıldığında tek interface cluster için yeterli fakat sağlıklı değil.

Eğer backup işlemini network üzerinden yapıyorsanız ve sunucunuzda da yeterli port varsa bu işlem için ayrı port kullanmanınız.

Eğer sunucunuzda yeterli port varsa Hyper-V’nin Live Migration işlemleri için ayrı portu kullanınız. Aşağıdaki resimde Microsoft’un Cluster sistemler için önerdiği network port sayısı ve hızları gösterilmektedir.

Cluster kurulumu yapılmadan önce tüm node’larda aşağıdaki ayarlan uygulanmalı:

* Tüm node’lardaki network interface’lerinin subnetleri ve isimleri eşit/aynı olmalı

* Private bacağında sadece “Internet Protocol Version 4 (Tcp/IPv4)” ve (Tcp/IPv6)”’nın işaretli olsun diğerlerinde işaret varsa kaldırınız. TCP/IP v6 kullanmasanız bile işaretli olması gerekmektedir. Microsoft tarafından iptal edilmesi önerilmemektedir.

* Public hariç tüm network interface’lerin DNS ve WINS register işlemi kaldırınız. Bu işlem için ip adresini girdikten sonra Advanced butonuna tıklayın. DNS tabına tıklayın. Aşağıda yer alan “Register this connection’s addresses in DNS” işaretli ise kaldırın. WINS tabına gelip “Disable Netbios over TCP/IP” seçeneği işaretli değil ise işaretleyelim.

* Sunucu network erişimindeki önceliği Public interface’ine vermek için “Control Panel > Network and Internet > Network Connections”a geldiğinizde klavyedeki ALT tuşuna basarak menü tabını çıkartıp Advanced alanı içerisindeki “Advanced Settings” e gelip Public network interface’ini yukarı taşıyın.

Server 2012 Windows NIC Teaming

Hyper-V ve SQL gibi servislerin servis sürekliliğini etkileyen en önemli etkenlerden birisi Port ve Switch yedekliliğidir. Server 2012 üzerinde Network Teaming yapılacaksa kesinlikle Windows NIC Teaming feature’ı ile yapılandırılmadır. Bunun nedeni Microsoft’a açılan network problemlerine ilişkin case’lerde eğer farklı bir üreticiye ait teaming varsa öncelikle teaming’in bozulması istendiğinden olası bir problem yaşanmaması adına Server 2012/2012R2 işletim sistemli sunucularımızda Teaming yapılandırmanızı Windows NIC Teaming feature’ı ile yapılır.

Bu işlem için Server Manager Tools’dan Local Server’a gelin. “NIC Teaming” yanındaki disable’ı tıklayarak veya lbfoadmin kısa ismini yazarak yönetim alanına gelin.

Gelen ekranda TEAMS alanı içerisinde Tasks’ı tıklayarak “New Team” secin. Açılan ekrana oluşturacağınız Team için isim girip “Member Adapters” kısmında listelenen uygun interface’leri işaretleyin.

“Additional Properties” tabını tıklayarak genişletin. Açılan ekranda “Teaming Mode” kısmında listelenen modellerden uygun olanı seçiniz.

Disk İşlemleri:

Cluster’ın temel çalışma prensibi Shared (Paylaşımlı) Disk üzerinedir. Servis sürekliliği yapılacak hizmetlerin verileri tüm node’ların gördüğü ortak bir disk alanında tutulur. Windows Server 2012 R2 ile birlikte SBM ve Guest (Sanal Makine üzerinde) Clustering destekleri gelmiştir. Aşağıda desteklenen disk tiplerinin listesi sunulmuştur.

Windows Failover Cluster yapısı aktif-pasif çalışmaktadır. Yani diskin sadece bir sahibi olur ve O okuyup yazar. Yanlız suanda sadece Hyper-V’de bir diske tüm node’ların erişimini sağlamaktadır. Bu sayede Hyper-V yük dağılımı yapılarak daha efektif kullanım sağlanırken olası bir problem anında üzerindeki sanal sistemlerin daha kısa sürede Failover olmasını gerçekleştirmektedir.

Cluster kurulumu yapılmadan önce tüm node’lar da ortak diskin gösterilmesi gerekiyor. Storage olarak kullanacağınız ortama göre bu işlem değişmektedir. Önemli olan tüm node’ların aynı boyutta ve DiskID’sin de diskin görülmesidir. Bunun kontrolü için Privilege (Run as Administrator) mode’da açılan komut penceresine diskpart yazın. Gelen ekranda “list disk” yazıp enter’layın.

Gelen ekranda cluster’a eklediğiniz diskin disk numarasını görmektesiniz. Yukarıdaki ekranda gördüğünüz gibi benim Cluster ortamı için eklenen disk1’dir. Sonra “select disk 1” diyerek işlem yapmak istediğiniz diski secin.

 İşlemin arkasından da “detail disk” diyerek diskiniz ile ilgili bilgilere erişebilirsiniz. Bu işlemi tüm node’larda uygulayıp DiskID değerini karşılaştırınız. Bu değer tüm node’larda aynı olmalı.

DiskID değerini görebilmeniz için diskin Initialize ve formatlanması gerekmektedir. Bu işlemleri için Cluster kurulumu yapılacak olan node üzerinde Server Manager’dan tools menüsünden “Computer Manager” a geliniz. Açılan ekranda “Disk Management” ı tıklayınız.

Gelen ekranda öncelikle Disk Management sağ tıklanıp rescan denir. Bu sayede değişiklikler işlenmiş olacaktır. Cluster için Storage üzerinden eklenen diskin görüldükten sonra üzerinde sağ tıklanıp önce online yapın sonra Initialize edin.

Bazı “Bare Metal” yedekleri ve bazı disk kurtarma programları GPT’yi desteklememekte. Olası problemle yaşamamak adına ve eğer disk boyutunuz 2 TB’ı geçmeyecekse önerim MBR yapmanızdır.

Initialize işlemi sonrasında diskin formatlanması gerekmektedir. Cluster sadece “Simple Volume” ve NTFS desteklemektedir.  Bu işlem için diski sağ tıklayıp “New Simple Volume” u secin. Arkasında da uygun harf ataması gerçekleştirin. Ben burada D harfini atadım.

Diskin format tipi cluster sisteminiz için çok önemli. Eğer bu disk üzerinde Hyper-V diskleri, SQL data ve log dosyası gibi büyük boyutlu blok veriler olacaksa “Allocation Unit Size” değerini 64K yapın. MS Cluster “File System” olarak sadece NTFS’i desteklemektedir.

Bu adımları tamamladıktan sonra diğer node’lar da Disk Management’ta rescan yapılarak eklenecek diskin görülmesi sağlanmalı.

Genel Yapılandırma Ayarları:

* Klavye hariç tüm Region Setting ayarlarını English (US) bırakmanız.

* Eğer sunucunuzun RAM’i 25 GB ve üstü ise pagefile’i 22528 Mb olarak set edin. Altında ise RAM kadar pagefile verilmesi önerilir fakat asla otomatikte bırakmayın.

* Eğer sunucunuzun işlemci CPU core sayısı 24’den fazla ise “Physical APIC Mode”’un enable edilmesi gerekiyor. Privilege (Run as Administrator) mode’da açılan komut penceresine aşağıdaki komut yazılıp Enter'lanır ve  sunucu restart edilir.

bcdedit /set usephysicaldestination yes

* Sunucunun saat ayarlarını kontrol ediniz. Türkiye için İstanbul seçilmeli.

* Task Scheduler üzerinden Defrag işlemi disable edilir.

Portalımızda daha önceden Hyper-V ve Cluster ile ilgili detaylı anlatımlar bulunduğundan bu makalemizde sizlere Microsoft Failover Cluster ile Hyper-V servisinin nasıl servis sürekliliğinin sağlanacağını derinlemesine inceleyeceğiz. Kurulum ve Yapılandırma olmak üzere iki bölümde anlatılacaktır.

Bu ilk bölümde Cluster kurulumu yapılacak sunucularımızın ve ortamımızın daha önceden yazılmış olunan “Windows Server 2012 R2 Cluster Ortamlarının Hazırlanması” isimli makalemizde anlatıldığı gibi gerekli adımların uygulanması sonrasında Hyper-V Cluster için özel ayarların anlatılması ve kurulumu anlatılacaktır.

1.       Kurulum ve Yapılandırma:

Server 2012 ile birlikte gelen en büyük özellik Role ve Feature’ların kurulumunun tek ekrandan ve sunucuya login olmadan başka makineden yapılmasıdır. Öncelikle Hyper-V Cluster için gerekli bileşenlerin kurulumuna başlayalım.

Full Driver ve Windows güncellemeleri yapılmış sunucularımızda (tüm Node’larda) Server Manager üzerindeki Manage menüsü altındaki “Add Roles and Features” sekmesi tıklanır.

Açılan menüde sunucumuzu seçip Next ile ilerleyip Roles sekmesi altında Hyper-V seçilir. Yönetim arabirimlerinin de yüklenmesini isteyerek kuruluma ilerleyin.  

Features sekmesinde Failover Clustering, Multipath I/O, Telnet Client, Server Backup işaretlenir. İşaretleme sırasında sorulan Yönetim arabirimlerinin de yüklenmesini kabul edip Next ile ilerleyin.

“Create Virtual Switches” ekranı opsiyoneldir. Buradan uygun portu seçip hemen oluşturabileceğiniz gibi Hyper-V kurulumu sonrasında Hyper-V Management ekranında switch oluşumunu yapabilirsiniz.

Eğer sizin sunucunuzun network port sayısı 4 ise; 1 portu Heartbeat (Private), 1 portu dış erişim (Public), 1 portu Live Migration ve 1 portu Backup için “Windows Server 2012 R2 Cluster Ortamlarının Hazırlanması” isimli makalemizde anlatıldığı gibi yapılandırınız. Eğer 4 porttan fazla portunuz varsa kalan portlarınızı Public portu için Nic Teaming yapabilirsiniz.

Benim uygulama ortamımda iki portlu network adaptörlü sunucum bulunmaktadır. 2 port olduğundan da Public portu aynı zamanda sanal makinelerin iletişim portu olacağından direk burada seçip VMSwitch oluşumunu sağlayarak ilerliyorum.

“Virtual Machine Migration” sekmesi Hyper-V’nin host’lar (Hyper-V kurulu sunucu) arasında sanal sunucuların “Live Migration” özelliği ile taşınmasında uygulanacak özelliklerin yapılandırıldığı alandır. Biz Cluster yapılandırma adımında bu işlemleri yapacağımızdan işaretlemeden geçiniz.

“Default Stores” sekmesi oluşturacağınız sanal sunucularınızın ilk olarak nerede oluşturmak isteyeceğinizin belirlendiği kısımdır. Cluster kurulumunda bu kısım değişeceğinden bir işlem yapmadan kurulumu tamamlayın.

Gelen Confirm (onaylama) ekranında kurulmasını istedikleriniz listelenir. Eğer bir eksiklik görüyorsanız Previous butonu ile geriye dönünüz. Eğer itirazınız yoksa kurulum sonrasında restart işleminin otomatik yapılması için onay ekranındaki “Restart the destination server automatically if required” alanı işaretlenip install butonuna basılır.

İlk kısım kurulum tamamlandığında sunucu restart edilecektir. Sunucu açıldığından kurulumu başlatan hesap ile login olunup Kurulum tamamlanması sağlanır.

2.       PowerShell Yapılandırması:

Kurulum tamamlandığında PowerShell üzerinden yapılandırma ve uzaktan yönetim için PowerShell üzerinde sağ tıklanıp “Run ISE as Administrator” çalıştırılır.

 Sonra aşağıdaki komutları çalıştırmanız gerekmektedir.

Set-ExecutionPolicy -ExecutionPolicy Unrestricted

Import-Module ServerManager

3.       ClusterLog yapılandırması:

Olası bir problemde hataların ve problemin incelenmesi için ClusterLog dosyası oluşturulmaktadır. Bu dosya memory’de tutulan ve restart sonrasında silinmektedir. Bu nedenle bir problemle karşılaştığınızda öncelikle Get-ClusterLog komutunu PowerShell’de yazarak enterladığınızda veriler C:\Windows\Cluster\Reports klasörü altında oluşturmaktadır.

Hyper-V Cluster sistemi çok fazla log ürettiğinde default ayarlar yeterli gelmemektedir. Bu nedenle aşağıdaki PowerShell komutları ile log seviyesini dosya boyutunu büyütmeniz gerekmektedir.

Set-ClusterLog –Level 4 {Default’u 3}

Set-ClusterLog –Size 1024 {Default’u 128}

4.       Microsoft Failover Cluster’ın Kurulumu

Server Manager’ın Tools menüsünden “Failover Cluster Manager” tıklanır.

Açılan “Failover Cluster Manager Tools” yönetim arabiriminde “Create Cluster” butonuna basılarak Cluster yapılandırması başlatılır.

“Select Server” ekranda Eğer sunucu isimlerini tam olarak biliyorsanız “Enter Server Name” alanına yazarak ADD butonuna basarak Cluster’a Node olarak ekleyin. Eğer sunucu isminden emin değil iseniz Browser butonuna basarak Cluster’ın Node’larının Active Directory üzerinden sorgulanmasını yapınız.

Browser butonuna basıldıktan sonra gelen ekranda “Enter the object names to select” kısmına sunucu isminin hatırladığınız kısmını yazıp “Check Names” butonuna basınız. Gelen sonuçlardan uygun olanları seçip OK tuşuna basarak eklemeyi gerçekleştiriniz.

Node olarak sunucuların seçimi yapıldıktan sonra Next butonu ile ilerleyiniz.

Validation ekranı Cluster’ınızın ve Node’larınızın genel kontrolünün yapıldığı ekrandır. Kurulumun sağlıklı yapılabilmesi için YES seçeneği seçilip ilerlenmelidir.

Validation raporunda warning mesajları kurulumu etkilemez çözümlenmesi sağlıklı Cluster kurulumu için önemlidir. Fakat eğer Error varsa kurulum yapılmadan hataların giderilmesi gerekmektedir.

Sunucudaki yapılandırma veya sistemsel her değişiklikte Validation yapılmadır. Eğer canlı ortamda test yapılması gerekiyorsa “Only tests I select” seçeneğini seciniz ve arkadan gelen ekranda Storage’in yanındaki işareti kaldırıp testi yapabilirsiniz.

Validation içindeki Storage testinde diskler tüm node’lar üzerine taşındığından hizmet kesintisine neden olur.

Biz burada ilk kurulum Validation testi yapacağımızda “All Test” seçilerek devam edilir.

Validation testinin sonunda success mesajını gördüyseniz veya kabul edebileceğiniz warning mesajlarınız varsa Finish butonuna basarak kuruluma devam ediniz. Gördüğünüz üzere Cluster Validation işleminde sunucu üzerinde Hyper-V kurulu olduğunu anladı ve buna göre Validation adımlarını uyguladı.

Cluster yapısının en büyük avantajı tek tek sunucular üzerindeki Hyper-V’yi değil ortak bir isimde oluşturacağımız Cluster Name’i ile Cluster’a dahil ettiğimiz tüm Hyper-V sunucularını yönetilmesidir.

“Access Point for Administering the Cluster” aşamasında Cluster yönetimi için oluşturacağımız ortak ismin yazmamızı istemektedir. Bu aşamayı yapmadan önce detaylarını “Windows Server 2012 R2 Cluster Ortamlarının Hazırlanması” isimli makalemizde anlatıldığı gibi ismi 15 karakteri geçmeyecek şekilde Active Directory üzerinde computer objesi oluşturup tüm Node’lara ve kurulumu yapacak kişiye full hak verilmesi gerekmektedir.   

Confirmation sekmesinde girişini yaptığımız bilgilerin onayı sorulmaktadır. Bu kısımda müsait olan diskleri Cluster’a ekleyebilirsiniz. Ben Quorum yapılandırması ve operasyonel işlemleri göstereceğimden “Add all eligible storage to the cluster” alanını işaretlemeden kuruluma devam ediyorum.