Hangi Bug’lar Offfff Kapsamına Girer? VMware KB2136854 – CBT

03.12.2015 | 23:37 VMWare 0 Yorum

Yürüttüğümüz projelerden birinde NetScaler’lar ile balance yapıp Palo Alto’lar ile koruduğumuz Cisco UCS Blade’ler üzerine ESXi Cluster, vCenter, vCloud Director, vRealize Log Insight, Horizon gibi çeşitli VMware çözümleri konumlandırıyoruz. Bu vesileyle son dönemde VMware KB’lerini çok daha yakından takip ediyorum. Yine öyle bir gün ve ben KB okuyorum…

vmware-bug

Incremental Backup Nedir?

En temel ifadeyle bir full backup alındıktan sonraki seferlerde sadece son backup anından itibaren değişen verilerin yedeklenmesi prensibine dayanan bir yedekleme yöntemidir. Bu sayede aynı verilerin tekrar tekrar yedeklenmesinin önüne geçilirken ağ kapasitesi daha az yedekleme verisi tarafından işgal edilir, yedekleme alanı ve ilişkili diğer kaynaklar daha verimli kullanılmış olur. Ayrıca bir incremental backup process, full backup process’e göre çok daha kısa sürede tamamlanır, yani hızlıdır.

100GB’lık bir VM’i günde 1 kez yedeklemek ve 7 gün geriye dönük saklamak istediğinizi düşünelim.

Eğer her seferinde full backup alırsanız kabaca;

  • Dezavantaj: 7 x 100GB = 700GB yedekleme alanına ihtiyacınız olur.
  • Dezavantaj: Her bir full yedekleme görevi -incremental’a göre- çok daha uzun sürer.
  • Avantaj: Her bir full yedekleme anı, kendinden önceki veya sonraki yedekleme anlarından bağımsız olarak tek başına geri dönülebilir.

Eğer full backup + incremental backup’lar alırsanız kabaca;

  • Avantaj: 1 x 100GB (full) + 6 x ~5GB (incremental/temsili) = 130GB yedekleme alanına ihtiyacınız olur. Bu da yedekleme alanı kapasitesinin daha verimli kullanılması demek.
  • Avantaj: Incremental backup görevi full backup’a göre çok daha kısa sürer çünkü transfer edilecek değişen (incremental) veri boyutu daima full veri boyutuna göre daha düşüktür.
  • Dezavantaj: Her bir  incremental yedekleme anı kendinden önceki incremental anlarına ve ayrıca full backup anına bağımlıdır. Eğer bu zincirdeki herhangi bir anda sorun yaşanırsa (inconsistency veya corruption gibi) sorun yaşanan an ve sonrasını kaybedersiniz.

O zaman bir backup software‘in incremental backup alabilmesi için bilmesi gereken en temel şey nedir? Tabii ki de son backup anından sonra gerçekleşen değişikliklerdir

Devamını oku…

PowerShell ile Twitter REST API Entegrasyonu – Takipçi Listesi

26.11.2015 | 23:35 PowerShell 0 Yorum

Twitter servislerine genelde web tarayıcılar ve mobil uygulamalar üzerinden erişilir. Aynı zamanda bu servisler, bazı işlerin programatik olarak gerçekleştirilebilmesi için REST, Streaming, Ads gibi çeşitli API’lar da sunar. Örneğin yeni bir tweet yazmak, time line okumak, çeşitli bilgilerle birlikte takipçi listesini export etmek, görsel yüklemek, arama yapmak, ayarları değiştirmek, direkt mesaj göndermek gibi birçok aktiviteyi bu API’lar sayesinde kendi geliştirdiğiniz uygulamalara entegre edebilir ve hatta tamamen özelleştirilmiş bir Twitter client bile yazabilirsiniz.

Geçenlerde HTTP tabanlı API istekleri, JSON formatlı veri alışverişi ve bu sırada oluşan içeriklerin Parse edilmesi gibi birkaç konu üzerinde çalışıyordum ki aklıma Twitter REST API‘lar geldi. Bu API’lar hem istediğim deneme ortamını sağlıyor, hem de yetkilendirme için OAuth kullanıyor; bu da bakmak istediğim bir başka konuydu…

Eğer Twitter kullanıyorsanız mesela “tweet atın“, “takipçilerinizi analiz edin” veya “unfollow yapanları öğrenin” gibi çeşitli üçüncü parti servisleri görmüşsünüzdür. Tamamı yine bu gibi API’lar vasıtasıyla çalışırlar. Ancak bana göre bu tip servislerdeki en büyük sorun kullanıcının username/password bilgisiyle çalışıyor olmaları. Aslında güvensiz sayılmaz çünkü bu sırada yine Twitter tarafından sağlanan bir yöntem kullanılır ama sanırım bugüne kadar kullandığım hiçbir servisin username/password bilgisini -o servisle ilişkili olsa dahi- farklı bir servise/uygulamaya girmedim. Eğer seçeneğim yoksa da o servisi kullanmadım.

Şimdi oturup bir Twitter client yazmayacağım tabii ki ama bu gibi meselelerin üzerinde düşünmeyi severim. Maksat antrenman olsun… Eğer bir programlama dilini konuşuyor olsaydık (ki çoğu zaman hazır kütüphanelere sahiptirler) bu gibi entegrasyonlar yapmak oldukça kolay. Peki ya PowerShell ile böyle bir entegrasyon mümkün mü? Mesela PowerShell ile yazılmış bir Twitter client? Pek tabii mümkün :) Ancak UX açısından çok kullanışlı olacağını söyleyemem. Ama yine de mümkün. Geçenlerde PowerShell üzerinden tweet atmak, tweet okumak, direct message göndermek, follower’ları listelemek gibi şeyler yapan birkaç script hazırlamıştım.

powershell-tweet

Belki tamamını değil ama aralarından bir tanesini, ilham vermesi ve yol göstermesi adına bu blog post’da kaleme alıyorum.

Bu antrenman sırasında -ve tabii herhangi bir üçüncü taraf servise username/password bilgisi girmeden- ulaşmak istediğim hedef şu: Twitter hesabım için Takipçiler kim? Kim yeni takibe başladı? Kim ne zaman takip etmeyi bıraktı? gibi bilgilere sahip olmak.

Devamını oku…

Microsoft Exchange Autodiscover Servisi ve Multi-tenancy

09.11.2015 | 22:20 Exchange Server 1 Yorum

İlk kez Exchange Server 2007’de gelen autodiscover servisi, erişim için gerekli bilgilerini ve hizmet ayarlarını otomatik olarak sağlayarak kullanıcı ve mail server’ı en az input ile buluşturmayı amaçlayan kullanışlı bir servistir. Pek severiz.

Ortalama bir bir e-posta kullanıcısı genelde 2 bilgiye sahip olur: E-posta adresi ve parola. Ama mesela aynı kullanıcı sunucu adresi, bu sunucunun SSL/TLS isteyip istemediği, hangi port üzerinden yayın yapıldığı gibi diğer bilgilere genelde sahip değildir. İşte autodiscover servisinin çıkış noktası tam olarak burası. Kullanıcı mail client’a sadece e-posta adresini ve parolasını girer, mail client diğer tüm gerekli ayarları autodiscover servisi üzerinden alır, parse eder, uygular ve işler yolunda gitmişse kullanıcıyı servise ulaştırıp ilk görevini tamamlar.

Az önce ilk görevini tamamlar dedim çünkü mesela Outlook’a Exchange Autodiscover servisiyle bir hesap eklendikten sonra her yeniden açılışta ve hatta çoğu zaman açık durumdayken de belirli zaman aralıklarında autodiscover servisiyle iletişim kurularak ayarlarda bir değişiklik olup olmadığı kontrol edilir. Eğer değişiklik varsa hemen mail client’a uygulanır.

Outlook çalışma anında ansızın ortaya çıkan credentials pop-up’larının bir nedeni de hatalı yapılandırılmış Exchange Autodiscover servisleridir.

Exchange Autodiscover servisi mail client’lara aşağıdaki bilgileri/ayarları sağlar.

  • Kullanıcıya ait Display Name.
  • Sunucu adresi, authentication türü, SSL/TLS geresinimi, varsa port numarası gibi bağlantı ayarları.
  • Organizasyon içerisinde Mailbox’ın tutulduğu Mailbox Server lokasyonu.
  • Free/busy bilgisi, UM, Offline Address Book gibi çeşitli özelliklere ait endpoint URL’ler.
  • Outlook Anywhere ayarları.

Devamını oku…

Windows 25 Ekim Sabahı 1 Saat Gerideyse Yapılması Gerekenler

25.10.2015 | 10:56 Windows Server , Çözümler , Windows 5 Yorum

Muhtemelen konuyu bildiğiniz ve sorun yaşadığınız için buradasınız. Bu yüzden tekrar anlatarak zamanınızı almak istemiyorum. Eğer 25 Ekim 2015 sabahı (ve takip eden 2 hafta boyunca) ortamınızdaki Windows’lar arasında 1 saat geride olanlar varsa, büyük ihtimalle Yaz Saati Uygulaması (DST) bitiş tarihi kaynaklı sorun yaşıyorsunuz. Bu durumdaki Windows’lar için işletim sistemi sürüne göre de değişmekle birlikte yapılması gerekenleri hızlıca aşağıda toparlıyorum.

Ama öncesinde belirteyim: Ülkenin en büyük gazetelerinin teknoloji köşelerinden tutun çeşitli teknik topluluklara kadar birçok yerde çözüm olarak DST’yi otomatik ayarlayan seçeneğin kapatılması öneriliyor.

automatic-dst

Yahu bunun işe yaramayacağı belli çünkü tarih aralığı olarak DST periyodunun dışına çıkıldığında zaten bu ayarının Local Time‘a saat eklemek için dikkate alınmayacağı ortada. Hadi hepsini geçtim ortalama zekaya sahip bir insan bunu önermeden önce oturup dener dimi? Aslında bunlar bilgisizlikten falan değil ha, bunlar düşünmemekten, gördüğü şey üzerine kafa yormamaktan oluyor. Ama matematikte kopya çekmiş de olabilirler :)

Active Directory Domain Üyesi Windows’lar

Sanırım en büyük sürprizi Active Directory Domain üyesi Windows’ların saat bilgisini zaten DC’den aldıkları için Pazar sabahı geri kalmayacaklarını düşünenler yaşadı. Halbuki öyle olmadığını söylemiştim :) çünkü mesele Local Time ile ilgili.

Client’ların PDC gibi NTP tabanlı servislerden aldığı zaman bilgisi UTC‘dir. Client OS, NTP’den aldığı bu zaman bilgisi üzerine Time Zone ayarlarına bakarak meridyen (Türkiye için +2 saat) ve gerekli ise DST (+1 saat) ilave yapar. İşte bu hesaplamayla ortaya çıkan zamana Local Time denir. Bu yüzden PDC/DC saati ne olursa olsun, zamanı geldiğinde Client işletim sistemi sene başında verdiği 1 saati geri alır ve DC bu konuda baskın olamaz; Local Time‘ı yöneten DC değil Client OS’tir. Ayrıca bu durum DC/Client authentication’larını etkilemez ve Client’lar 1 saat geri kalsa dahi normal şekilde logon olabilirler çünkü Kerberos authentication için dikkate alınan zaman bilgisi Local Time değil System Time‘dır ve o da UTC‘dir; yani herhangi bir ekleme çıkartma yapılmamış salt zaman bilgisi…

Peki şu an ne yapılabilir?

1) Eğer söz konusu işletim sistemi KB3093503 numaralı hotfix tarafından destekleniyorsa, bu hotfix’i yükleyerek ve Time Zone olarak (UTC+02:00) Istanbul seçili olduğundan emin olarak sorunu hemen giderebilirsiniz. Ortamınızda bu durumdan etkilenen çok sayıda Windows varsa bu hotfix’i tek seferde topluca dağıtmak ve (UTC+02:00) Istanbul seçimini otomatik olarak yapmak için Install-DstHotfix.ps1 aracını kullanabilirsiniz.

2) Eğer söz konusu işletim sistemi KB3093503 numaralı hotfix tarafından desteklenmiyorsa, yine şu yazı içerisindeki Windows Server 2003 ve Windows XP bölümünde anlattıklarımı uygulayarak sorunu aşabilirsiniz.

Eğer çok sayıda uzak bilgisayara sahipseniz ve ortamınızdaki hangi Windows’ların saat bilgisinin geri kaldığını, hangilerinin DST ayarlarının ertelenmediğini, hangilerinde KB3093503 numaralı hotfix’in yüklü olmadığını bilmiyorsanız, bu bilgileri topluca raporlamak için kontrol aracı Get-DstInfo.ps1‘i kullanabilirsiniz. Bu aracı aynı zamanda müdahale sonrası son durumu raporlamak için de çalıştırmanızı öneririm.

Workgroup Çalışan Windows’lar

Eğer bir Windows Workgroup olarak çalışıyorsa ve siz Time Source olarak özellikle bir Time Server (ntp server) atamadıysanız (ki varsayılan durum budur), zaman bilgisini doğrudan donanım üzerinde pil ile beslenen Local CMOS (BIOS hafıza alanı diyelim) ile eşitler. Bu gibi bir Windows’a gidip saati manuel olarak ileri veya geri aldığınızda değişiklik kalıcı olarak gerçekleşir ve siz yeniden değiştirene kadar o haliyle çalışmaya devam eder. Çünkü bu senaryoda Windows’lar time bilgisini bağımsız olarak yönetir ve uygulanan değişiklik anında CMOS’a yazılır.

Peki şu an ne yapılabilir?

1) Eğer söz konusu işletim sistemi zaman bilgisi için Local CMOS‘a veya bir Time Server‘a bakıyorsa ve aynı zamanda KB3093503 numaralı hotfix tarafından destekleniyorsa, bu hotfix’i yükleyerek ve Time Zone olarak (UTC+02:00) Istanbul seçili olduğundan emin olarak sorunu giderebilirsiniz.

2) Eğer söz konusu işletim sistemi zaman bilgisi için Local CMOS‘a bakıyor ama KB3093503 numaralı hotfix tarafından desteklenmiyorsa, saat bilgisini manuel olarak 1 saat ileri alabilirsiniz. Bu arada manuel müdahale yapanlar şunu unutmasın: 8 Kasım 2015 04:00 sonrası yine ülke saatini yakalayabilmek için tekrar 1 saat geri almanız gerekiyor.

4) Eğer söz konusu işletim sistemi zaman bilgisi için bir Time Server‘a bakıyor ama KB3093503 numaralı hotfix tarafından desteklenmiyorsa,  şu yazı içerisindeki Windows Server 2003 ve Windows XP bölümünde anlattıklarımı uygulayarak sorunu aşabilirsiniz.

Windows’un zaman eşitlemesini hangi kaynak ile yaptığını öğrenmek için w32tm /query /status komutunu çalıştırabilirsiniz. Mesela bir örnek:

system-clock

Herhangi bir müdahalede bulunmadan 8 Kasım’a kadar 1 saat geride işletmek de seçeneklerden biri. Hatta bunu tercih eden birçok şirket biliyorum.

Son bir not: Hotfix yüklü ve Time Zone olarak (UTC+02:00) Istanbul seçili olduğu halede zaman bilgisi 1 saat gerideyse, sistemi yeniden başlatarak sorunu giderebilirsiniz. (NTP Server’dan doğru UTC zaman bilgisi geldiğini düşünüyorum)

Get-DstInfo | Windows Yaz Saati Uygulaması için Kontrol Aracı

8 Kasım 2015 04:00‘a ertelenen Yaz Saati Uygulaması için 25 Ekim 2015 04:00‘a kadar yüklenmesi gereken KB3093503 numaralı hotfix’i ve üzerine kontrol edilmesi gereken ayarları biliyorsunuz. Muhtemelen bu işlemleri otomatikleştirmek için hazırladığım toplu yükleme aracını da biliyorsunuz. Peki ortamınızda hala gerekli ayarları ve hotfix’i almamış bilgisayarlar olup olmadığını biliyor musunuz? Veya Pazartesi günü ofise geldiğinizde bazı bilgisayarların saatinin geri kaldığını fark ettiniz, peki ortamda başka hangi bilgisayarların saati geri kalmış olabilir?

get-dst-info

Bu iş için hazırladığım Get-DstInfo.ps1 isimli script’i kullanarak Windows XP ve Windows Server 2003’ler de dahil olmak üzere ortamdaki tüm Windows’lar için aşağıdaki bilgileri kolayca toplayabilirsiniz.

  • İşletim sistemi sürümü
  • Local Time (o anki zaman bilgisi)
  • Time Zone (seçişi olan Time Zone bilgisi)
  • DST (DST değişikliğini hangi tarihte uygulayacağı bilgisi)
  • KB3093503 (Bu hotfix’in yüklü olup olmadığı bilgisi)

Pazar sabahı öncesinde ortamdaki Windows’lar için son durumu görmek ve Pazar sabahı sonrasında beklenmedik bir durum ortaya çıkarsa hızlıca kimlerin zaman bilgisinin geri kaldığını öğrenmek için kullanabilirsiniz.

Devamını oku…

Windows DST Hotfix KB3093503 için Toplu Yükleme Aracı ve Yaz Saati Uygulaması 2015

25 Ekim 2015 04:00’da bitmesi planlanan Yaz Saati Uygulaması (gün ışığından yararlanma, dst) bu yıl resmi bir karar ile 8 Kasım 2015 04:00 tarihine ertelenmişti. 20 Ekim 2015 tarihinde ise (TR’de görünmesi 21 Ekim) Windows işletim sistemleri için DST bitişini 8 Kasım’a erteleyen KB3093503 numaralı bir hotfix yayınlandı. Ancak büyük oranda Türkiye’de yer alan belirli bir grup Windows’a hitap eden bu fix Windows Update üzerinde yer almadı ve haliyle WSUS’lara da gönderilmedi. Bunun yanı sıra Windows 10 için olan paket dışındaki hotfix paketleri Update Catalog üzerinde de yer almıyor; Yani elinizdeki WSUS’a manual import etme şansınız da yok. Bu kabul edilemez bir durum! GPO ile yükleme hayaliniz varsa üzgünüm çünkü GPO mekanizması varsayılan haliyle ancak MSI dağıtabilir. Ama hotfix MSU/CAB formatında olduğu için önce MSI’a dönüştürmeniz veya yine bir startup script basmanız gerekir. Özetle eğer elinizde merkezi bir uygulama dağıtım çözümü yoksa bu hotfix’i tüm sistemler üzerine manuel yüklemeniz ve ardından kontrol etmeniz gerekiyor. Ne güzel değil mi… Stajyer kardeşlerimiz isyanda :)

25 Ekim sabahı ve sonrasında 1 saat geri kalmış Windows’lar için yapılması gerekenleri şu yazıda toparladım.

Hotfix geçilmemiş ve DST bitiş zamanı hala 25 Ekim 2015 04:00 görünen Active Directory Domain üyesi Windows’lar saat bilgisini zaten DC’den aldıkları için Pazar sabahı geri kalmayacaklarını düşünenler varsa üzgünüm ama yanılıyorlar. Bu bir şehir efsanesi :) çünkü mesele Local Time ile ilgili.

Client’ların PDC gibi NTP tabanlı servislerden aldığı zaman bilgisi UTC‘dir. Client OS, NTP’den aldığı bu zaman bilgisi üzerine Time Zone ayarlarına bakarak meridyen (Türkiye için +2 saat) ve gerekli ise DST (+1 saat) ilave yapar. İşte bu kombinasyonla ortaya çıkan zamana Local Time denir. Bu yüzden PDC/DC saati ne olursa olsun, zamanı geldiğinde Client işletim sistemi sene başında verdiği 1 saati geri alır ve DC bu konuda baskın olamaz; çünkü Local Time‘ı yöneten DC değil Client OS’tir. Ayrıca bu durum DC/Client authentication’larını etkilemez ve Client’lar 1 saat geri kalsa dahi normal şekilde logon olabilir çünkü Kerberos auth için dikkate alınan zaman bilgisi Local Time değil System Time‘dır ve o da UTC‘dir; yani ekleme çıkartma yapılmamış salt zaman bilgisi…

Aslında bunu test etmenin yolu çok basit: Şu an Domain üyesi bir client üzerinde DST’yi disable edin, saatin anında 1 saat geri alındığını göreceksiniz. Bir süre bu şekilde bekleyin, hatta w32tm /resync falan yapın, ama DC ile aradaki 1 saat farkın asla kapanmadığını göreceksiniz. Gerçi test etmeye de gerek yok, birkaç saat sonra gerçek geçiş anı yaşanacak :)

Windows Server 2003 ve Windows XP’ler için DST ertelemesiyle ilgili bir çözüm ekledim.

Get-DstInfo.ps1 Doğrulama Aracı: Install-DstHotfix.ps1‘i yaptığı işi veya ortamınızın Yaz Saati Uygulaması bitişine hazır olup olmadığını anlamak ve topluca raporlamak için yeni bir script yayınladım: Get-DsInfo.ps1 ve kullanım kılavuzu

Sosyal ağlar üzerindeki bazı paylaşımlarda hotfix yüklemek yerine çeşitli registry kayıtlarının oluşturulmasıyla ilgili öneriler gördüm. Yapılan kayıt girişleri ile belki o an doğru Time Zone ve DST zamanına ulaşmak mümkün olabilir ama ya bir sonraki DST zamanı geldiğinde sistem nasıl davranacak? Peki bir gün sonra düzgün çalışacağının garantisini kim veriyor? Bunlar belirsiz noktalar. Eğer tüm sistemler için DST davranış değişikliği sadece bir grup registry kaydı oluşturmak ile çözülebiliyor olsaydı, bence bu yöntem mutlaka açıklanan resmi bir bilgiler arasında da yer alırdı. Yine de registry müdahaleleri çalışmaz veya kesinlikle soruna neden olur demiyorum, ama yayınlanmış bir hotfix varken risk almaya değmez diyorum. Bana soracak olursanız ve eğer DST için bir müdahalede bulunmaya kararverdiyseniz bu işin en sağlıklı ve resmi uygulama yöntemi ilgili hotfix’i yüklemektir.

Windows DST Hotfix KB3093503’ü merkezi ve topluca dağıtmak için hazırladığım aşağıdaki PowerShell script’in işinizi oldukça kolaylaştıracağına eminim.

install-dsthotfix-console

DST Değişikliğine Hazırlıklı Olmak Neden Önemli?

Sıradaki DST, saatlerin 04:00’de bir saat geri alınması ile gerçekleşecek. Bu durum 03:00-04:00 zaman aralığının o gün tüm işletim sistemleri ve yazılımlar için iki kez yaşanması demek. Yani eğer önlem alınmamış ise bu aralığa denk gelen mesela yedekleme görevleri gibi, eşitlemeler gibi envai çeşit zamanlamış görev ve çeşitli process’ler hep 2’şer kez çalışacak. Diğer taraftan sistemler ve entegrasyonlar arası uyumsuzluk, veritabanı kayıtlarının tutarsızlığı, log çakışmaları ve bu durumların gerçek hayata yansıması gibi daha da önemli riskler söz konusu. İşin doğası gereği var olan bu riskler noktasında Windows DST hotfix’ler çözüm olamıyor çünkü bu gibi durumların tespit edilmesi ve sistem/process bazlı olarak ayrıca ele alınması gerekiyor.

Devamını oku…

Exchange Server 2016 Kurulumu ve İlk Ayarlar

04.10.2015 | 19:05 Exchange Server 2 Yorum

Exchange Server 2016’nın final sürümü 1 Ekim 2015 itibariyle genel erişime açıldı. Bu yazıda, Exchange Server 2016 mimari değişiklikleri, sistem gereksinimleri ve kurulum adımlarıyla ilgili bilgiler ve yol gösterici yönergeler bulabilirsiniz. Exchange Server 2016 kurulum adımlarını mümkün olduğunca özet hale getirmeye çalıştım. Umarım gerektiğinde hızlıca sonuca ulaştırır.

Bu yazının amacı her açıdan mükemmel düzeyde planlanmış, geniş ölçekli, dağıtık ve yüksek erişilebilir mimaride çalışan bir Exchange Server 2016 topolojisi inşa etmekten ziyade, tüm rollerin aynı sunucu üzerinde toplandığı ve herhangi bir amaç için hızlıca ayağa kaldırabileceğiniz bir Exchange Server 2016 organizasyonu oluşturmak adına yol göstermektir. Bu yazı, yapı içerisinde daha önceden kurulmuş herhangi bir Exchange Server olmadığını kabul eder ve yeni bir organizasyon oluşturarak ilerler.

Exchange Server 2016 Mimarisi

Exchange Server 2016 kurulum adımlarına geçmeden önce özellikle dağıtım mimarisindeki birkaç değişikliğe dikkat çekmek isterim.

Rol dağıtımı açısından baktığımızda Exchange Server 2016 mimarisinde sadeleşmeye gidildiğini görüyoruz. Önceki sürümlerden farklı olarak Exchange Server 2016 sürümleri sadece 2 rol olarak dağıtılabiliyor: Mailbox Server ve Edge Server. Örneğin CAS (Client Access) fonksiyonları artık bir rol olarak ayrı sunucu üzerine yüklenemiyor. Bunun yerine Mailbox rolüne bağlı bir Windows service olarak geliyor. 2007’de 5 parçaya böldükleri yapıyı tekrar toparlıyorlar sanırım :) Şaka bir yana bunun asıl nedeni güçlü donanımların artık daha kolay temin edilebilmesi… Her şey tek sunucuda toplandığında gereken donanım kaynağını sağlamak, altyapıdaki limitlerin de aşılmasıyla birlikte eskiye nazaran çok daha kolay ve ucuz.

exchange-server-2016-mimarisi

Roller, Exchange Server 2007 ve 2010’da Mailbox, Client Access, Hub Transport, Unified Messaging ve Edge olmak üzere 5 farklı parçaya ayrılabiliyordu. Exchange Server 2013’te bu rol dağıtılabilirliği 3’e düştü: Mailbox, Client Access ve Edge. Exchange Server 2016’da ise sadece 2 rol var: Mailbox ve Edge.

Devamını oku…

Exchange Server 2016 Lisanslama ve Sürümler

04.10.2015 | 11:30 Exchange Server 0 Yorum

Yeni Exchange Server sürümlerinde lisanslama açısından önemli bir değişiklik yok. Tıpkı bir önceki sürüm Exchange Server 2013 lisanslamasında olduğu gibi Exchange Server 2016 sürümleri de sunucu ve istemci olmak üzere her iki açıdan lisanslanmalıdır.

exchange-server-2016-lisanslama

Exchange Server 2016 Sunucu Lisansı (Server License)

Exchange Server 2016 iki sürüme sahiptir ve özellik açısından aralarındaki tek fark destekledikleri Mailbox Database sayılarıdır. Geriye kalan tüm teknik özellikler ve yetenekler her iki sürüm için de geçerlidir.

  • Exchange Server 2016 Standard Sürüm: En fazla 5 adet Mailbox Database destekler. Bu yüzden daha çok küçük ve orta ölçekli şirketler için uygundur. Ayrıca daha büyük ölçekli yapılarda özellikle maliyet avantajı sağlamak için üzerinde Mailbox Database gerektirmeyen görevlerde de kullanılabilir; mesela Edge Server.
  • Exchange Server 2016 Enterprise Sürüm: 100 adete kadar Mailbox Databse destekler. Daha çok büyük ölçekli, kullanıcı ve organizasyon sayısı fazla şirketlere hitap eder.

Bu bilgiler doğrultusunda baktığımızda, Windows Server işletim sistemi üzerinde çalışan her Exchange Server 2016 için bir adet uygun sürüm sunucu lisansı gerekir.

Devamını oku…

Azure VM’ler için Console Output ve Screenshot Desteği

01.10.2015 | 22:54 Microsoft Azure 0 Yorum

Eylül ayı başında Azure VM’ler için 2 yeni hata ayıklama (debugging) özelliği duyurulmuş. Duyurulmuş diyorum çünkü benim bundan ancak #AzureCon’da haberim oldu ve announcement etiketli bir slayt’ta görünce de aha sonunda! gibilerinden bir tepki verdim; sonra bir an Azure’da boot olamayan imajlarımızı düzeltmek için telef olduğumuz yıllar geçti gözümün önünden… Halbuki Eylül başında zaten duyurulmuş :) Özetle konu şu: Bundan böyle Azure üzerindeki v2 VM’lerin konsol çıktılarını (console output) ve ekran görüntülerini (screenshot) Azure Preview Portal üzerinden alabiliyoruz.

Bu neden önemli?

Biz Azure üzerinde Linux tabanlı IaaS projeleri de yaptık. Özellikle müşteri ortamındaki fiziksel Linux sunucuları önce on-prem Hyper-V imajlarına convert edip daha sonra bu imajları Azure’e import ederek VM’lere bağlayıp çalıştırmak istediğimizde boot sorunları yaşadığımız sunucular oldu. Veya benzer şekilde Hyper-V Replica ile Azure Site Recovery’e yedeklediğimiz yine Linux VM’lerde yaşanan boot problemlerinde gerçekten elimiz kolumuz bağlı durumda oluyordu. Çünkü düne kadar o non-bootable state Linux VM’in konsolunda ne yazdığını görme şansımız yoktu. Bu durumda tek seçenek Azure Support’a case açmak ve bir support engineer’ın arka taraftan VM console log’u alıp bize göndermesini beklemek…

Bu gibi sorunlarda mail’ler döner, döner, döner… sonra bir support engineer size ulaşır. Bir keresinde hiç unutmam boot sorunu yaşayan bir replica Linux VM’in console output’unu alabilmek için önce support engineer’a SCVMM ve Hyper-V Replica öğretmek zorunda kalmıştık :) Uzun uğraşlar sonucu konuyu anlayınca on-prem VM’i Azure’a planned failover yaptık ve VM orada deploy olup başlamaya çalıştıktan sonra console output’u alıp bize gönderebildi. Sonra da sabrımız ve anlattıklarımız için teşekkür etti, uzmanlık alanının sadece Linux OS’ler olduğunu da ekledi :)

İşte bu gibi anlarda özellikle Linux VM console output’a ulaşmak debugging açısından oldukça hız kazandırıyor.

Devamını oku…

PowerShell Direct Nedir, Nasıl Kullanılır?

01.10.2015 | 20:23 Hyper-V , PowerShell 0 Yorum

PowerShell Direct pek tabii bir yenilik, ama özellikten ziyade VM’ler içerisinde PowerShell komutları çalıştırmak için yeni bir yol demek daha doğru olur sanırım. Windows Server 2016 Hyper-V, Windows 10 Hyper-V ve PowerShell 5.0 ile birlikte kullanılabilen PowerShell Direct yöntemi, Hyper-V Host’lar üzerinden VM’ler içerisinde PowerShell komutları çalıştırmanızı sağlayan yeni bir yol sağlıyor.

PowerShell Direct öncesinde, bir Windows VM’i ağa bağlayıp Remote Management ayarlarını yaptıktan ve Windows Firewall üzerinde gerekli kuralları aktif ettikten sonra Enter-PSSession olsun, Invoke-Command olsun çeşitli cmdlet’lerin -ComputerName parametresine ağa bağlı uzak bilgisayarı vererek üzerinde bir komut çalıştırabilir veya bir komut satırı oturumu başlatabilirsiniz. Bu modelde uzak bilgisayarın bir VM veya Physical Server olmasının da pek bir önemi yoktur çünkü iletişim ağ bağlantısı kanalıyla kurulur. Bu yüzden üzerinden ilk kural, üzerinde komut çalıştırılmak istenen uzak bilgisayarın ağa bağlı ve ulaşılabiliyor olması…

Mesela aşağıda iki örnek var. Dikkat ederseniz uzak sunucu ismi -ComputerName parametresi ile sağlanıyor.

# Server1 isimli uzak sunucuda çalışan process’lerin bir listesini alır
Invoke-Command -ComputerName Server1 -ScriptBlock{Get-Process}

# Server1 isimli uzak sunucuda bir PS oturumu başlatır
Enter-PSSession -ComputerName Server1

Powershell Direct sayesinde, PowerShell 5.0’daki bazı cmdlet’lere eklenen -VMName veya -VMGuid parametreleri ile mesela bir Hyper-V Host üzerinde çalışan ama üzerinde hiçbir Remote Management ayarı gerçekleştirilmemiş veya hiçbir şekilde ağa bağlı olmayan (hatta ağ adaptörü bile bulunmayan) bir VM’in sanal işletim sistemi içerisinde komutlar çalıştırabilirsiniz; adı gibi, direkt!

Devamını oku…