Server Management Tools Overview – Part 2

Gateway Servisinin kurulumu için “WS2016-S1” isimli sunucuya bağlanıp ilgili kurulum paketlerini indirip başlayabiliriz. Kurulum dosyası içerisinde iki adet dosya gözükmektedir.

  • GatewayInstall.MSI – Gateway hizmetinin dosyaları
  • Profile.Json – Gateway hizmetinin Azure ile register olmasını sağlanayan detayları barındırır.

Kurulum başarıyla tamamlandıktan sonra, “Services” konsolu üzerinde iki adet servisin durumunu görebiliriz. Bu servislerin “Running” durumunda olduğuna dikkat edilmesi gereklidir. Bununla beraber devamlılığın sağlanması şart, bütün süreçler Azure Portal ile yönetmek istediğiniz sunucular arasındaki tüm trafik Gateway sunucusu üzerinden geçiyor.

  • Server Management Tools Gateway
  • Server Managemet Tools Gateway Updater

Eğer servislerde herhangi bir sorun gözükmüyor ise Azure Portal içerisinden Gateway Resource kısmında sunucunun “Register” işleminin başarı bir şekilde gözüktüğünü görebilirsiniz.

“GatewayAzure” detaylarına bakıldığında “WS2016-S1” isimli Gateway sunucumuzun başarıyla tanımladığını görmekteyiz. Artık yönetmek istediğimiz sunucuları ekleyebiliriz. Kısa bir bilgi ekleyelim, Gateway Server Windows Server 2012 R2 üzerinde çalışan bir sunucu olsaydı, yukarda yapıldığı şekilde “GatewayInstall.MSI” paketi ve Powershell 5.0 kurulumu ( Windows Management Framework 5.0) yapıldıktan sonra SelfSigned sertifika üretmeniz gerekiyor olacaktı. Windows Server 2016 olarak belirlediğim Gateway sunucumunda bunların hepsi otomatik bir şekilde olmaktadır.

“RG-ServerManagement” adlı Resource Gruop içine girip hizmeti yaratırken yönetmek istediğim sunucumun “Server Management Tools” kısmını girip bir hesap belirtip yönetime başlayalım.

“WS2016-TP5” isimli makinemi yönetmek için eklemiş olduğum “Server Management Tools” hizmetinin içerisine girdiğimizde bize ilgili sunucunun tüm kaynaklarını yönetmek için yetkili bir hesap detayları istenecektir.

Yukarıda görüldüğü gibi sunucuyu yönetebilmek için bir defalığına mahsus yetkili bir hesap belirtmeniz gerekiyor. “Manage As” butonuna bastığınız zaman Credentials bilgisi girmeniz bu sunucuyu Azure Portal’ı üzerinden yönetmenize izin verecektir. Girmiş olduğunuz “Credentials” bilgisi Gateway sunucuya gönderilecek ve Gateway sunucusu hizmeti oluştururken girilen “ComputerName” adıyla birlikte erişim sağlayıp tüm veriyi Azure Portal içerisinde göstermeye çalışacaktır. Portal üzerinde yapacağınız tüm sorgular ve yönetim hepsi Powershell üzerinden sağlanmaktadır.

“Manage As” butonuna bastıp gerekli yetkili hesapları girelim. Ortamımızda “Domain Services” olduğu için “Domain Admin” hesabı belirttim. Eğer şifre bilgilerinizin doğruluğu test edildikten sonra yönetim ile ilgili alanların aktif olduğunu göreceksiniz.

Yukarıdaki ekran içerisinde gördüğünüz “Tools” kısmında yönetmek istediğiniz sunucuya Azure Portal üzerinden kolayca aksiyon almanızı sağlıyor. Artık sunucuya neredeyse Uzak Masaüstü gibi yöntemler ile bağlanmanıza gerek kalmayacak. Azure Portal’ına erişebildiğiniz heryerden sunucularınızı kolay bir şekilde yönetmenizi mümkün kılıyor.

Görüldüğü gibi, Performance değerlerini anlık takip edebildiğim ve günlük sistem yöneticilerinin “Remote Desktop” yöntemiyle yapmakta olduğu bir çok işi Azure Portal’ı üzerinden çok hızlı bir şekilde yapabilmekteyiz. Aşağıda görüldüğü yönetmekte olduğumuz sunucunun Network ayarlarını Azure Portal’ı üzerinden kolay bir şekilde değiştirebiliyorum.

Yine başka bir örnekte Powershell Console erişmiş bulunmaktayım. Tabi konu Powershell’e geldiği için yapabildikleriniz ve yapacaklarınız neredeyse sınırsız oluyor. Bu ekran içerisinde isterseniz elinizdeki “.Ps1” uzantılı dosyalarınızı gösterebilir, Powershell Modülleri kurabilir veya Powershell Desired State Configuration yönetimi için ayarlarınızı buradan yapabilirsiniz.

Bir sonraki yazımızda “Windows Server 2012 & 2012R2” sunucularınızın nasıl yönetildiği ve Domain Services ortamında olmayan sunucularımız için “Server Management Tools” hizmetinin kullanımına parmak basacağız.

Office 365 Import Services (PST Import)

Office 365 üzerinde yeni bir hizmet olan Office 365 Import Servisi inceliyor olacağız. Bir çok firma Office 365 geçişlerinde Exchange sunucusunun olmaması durumunda mailleri manuel olarak import etmek zorunda kalmaktadır bu sebeple her kullanıcının bilgisayarlarında PST’lerin tek tek import edilmesi bir iş yükü getirmekte ve kontrol edilmesini güçleştirmektedir.

Office 365 tarafında bulunan Import Service adlı özellik sayesinde elimizde bulunan PST datalarını 2 şekilde Office 365 üzerindeki hesaplarımıza import edebilmekteyiz.

  • Harici disk ile Microsoft Datacenter’a PST dosyalarının gönderilmesi

Şirket içerisindeki internet hızının yavaş olması veya çok büyük sayıda PST dosyası bulunması durumunda tercih edilmektedir.
Daha fazla bilgi için ;https://technet.microsoft.com/tr-tr/library/ms.o365.cc.ingestionhelp.aspx#bk_inthisdoc

  • PST dosyalarının şirket içerisinden upload yöntemi ile Microsoft Storage’lerine upload edilmesi

PST dosyalarının merkezi bir sunucu veya bilgisayarda toplanarak upload edilmesi ile gerçekleştirilmektedir.
Biz bu bölümde PST dosyalarının şirket içerisinden upload yöntemi ile gönderilmesi kısmını inceliyeceğiz.
Neden PST Import servisini kullanmalıyız ?
-Merkezi Upload
-Hızlı , Basit , Yönetimi kolay
-Kullanıcının bilgisayarındaki dataların kaybolmasına karşın dataların bulutta durması
1-Office 365 Mail Import Export yetkisi verilmesi
Office 365 üzerinde Import Servisini kullanabilmemiz adına Exchange Yönetim panelinden “Mailbox Import Export” yetkisi vermemiz gerekmektedir.
Exchange Admin CenterPermissionsAdmin Roles kısımına gelip Compliance Management’a çift tıklıyoruz.

Compliance Management’a aşağıdaki role bölümünden Mailbox Import Export yetkisi veriyoruz.

Son olarak Members kısmından upload işlemini yapacak olan kullanıcımızı Members bölümüne ekliyoruz. Bu kısımda ben Office 365 Admin kullanıcımızı tanıtıyorum. Kaydet seçeneği ile bu kısmı tamamlıyoruz.

2-Network Upload tool’unun kurulması
Upload edeceğimiz PST dosyaları için Azure AzCopy adlı tool bulunmaktadır aşağıdaki yönergeleri takip ederek bu tool’un kurulumunu gerçekleştiriyoruz.






Kurulum sonrası Microsoft Azure Storage Toolunu çalıştırıyoruz.

İlgili tool üzerinde PST dosyalarını güvenli bir şekilde upload yapabilmemiz adına Office 365 Import Service bölümünden Storage Account Key almamız gerekmektedir.
Show Key bölümüne tıklayalım.

Storage keyimiz ortalama 5 dakika içinde hazır olcaktır. Daha key altındaki “Show URL for PST fles” kısmına basınız.

Storage keyimiz üretildikten sonra aşağıdaki keyleri kopyalıyoruz ve resmin aşağısında paylaşmış olduğum upload scriptyinde ilgili alana yapıştırıyoruz.

Aşağıdaki Scripti kendisinize göre düzenlemeniz gerekmektedir.
AzCopy.exe /Source:SERVERNAMEPSTFiles /Dest:https://4a6524979xxxxxxxxxx85a0.blob.core.windows.net/ingestiondata/PSTFiles /Destkey:bVs/IufoC0Ge2DZ7Y+FO5xxxxxxNvcjNCKHSMrV6wcpEoYZ8/ZKFhz3wL6f57DQcwKxUKi8WU61tJBerHj3Gg== /S /V:SERVERNAMEPSTFilesUploadlogNew.log
1-SERVERNAMEPSTFiles = PST dosyalarınızı Upload yapacağınız PC üzerinde C:PSTFiles adlı klasör açarak PST dosyalarınızı atınız ve daha sonra ilgili klasörü paylaşıma açınız.
2-
https://f6b5a2xxxxxxxxxxxxxxx72.blob.core.windows.net/ingestiondata/
kısmını yukarıdaki Network Upload URL kısmındaki URL ile değiştiriniz.
3- uVv0dj9saqAv5mTNzZaO7M7CqcuMu89e1LO49DALxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxpW1tJJMGBw== kısmını yukarıdaki Storage Account Key ile değiştiriniz.
4-
SERVERNAMEPSTFiles
upload işlemi ile ilgili logların hangi klasöre yazılacağını belirliyoruz.
Kullanıcımıza ait PST dosyalarını upload yapacağımız klasöre kopyalıyoruz ve hangi PST dosyası hangi kullanıcıya ait olacak ise email adresi olarak isimlerini ayarlıyoruz.

Not : Elinizdeki PST dosyalarının içlerindeki klasörlerin (Gelen Kutusu , Gönderilmiş Öğeler ) dilleri Türkçe ise Office 365 üzerindeki Mailboxunızında dilinin türkçe olması gerekmektedir. Aksi taktirde upload edeceğiniz dosyalar aynı klasör içerisinde eşleşmeyecektir.
En başta hazırlamış olduğumuz Scripti aşağıdaki Azure Storage Tool üzerine yapıştırıyoruz ve komutu enter ile çalıştırıyoruz.PST dosyalarının Upload işlemi aşağıda gördüğünüz üzere başarıyla tamamlanmıştır. Herhangi bir hata almanız durumudna log dosyalarını kontrol ederek hata mesajını görüntüleyebilirsiniz.

Yukarıdaki işlemlerde elimizdeki PST dosyalarını Azure Storage üzerinde upload işlemini gerçekleştirmiş olduk. Şimdi sıra gönderdiğimiz dosyaları kullanıcılara Office 365 üzerinden aktarılmasını sağlayacağız.
Aaşağıdaki tablolara sahip bir Excel CSV dosyası yarattıktan sonra aşağıdaki sütunları kendinize göre düzenlemeniz gerekmektedir.
Örnek CSV tablosunu indirmek için tıklayınız.

Yukarıdaki CSV tablomuzu kaydettitkten sonra aşağıdaki 2 seçeneği işaretleyip NEXT diyoruz.

Upload işlemi için bir isim veriyoruz ve ilerliyoruz.

Bir sonraki ekranda hazırlamış olduğumuz CSV dosyasını ekleyip Validate butonuna basarak CSV’yi doğruluyoruz ve finish diyerek işlemi tamamlıyoruz.

Oluştuduğumuz Job’ın kontrolünü aşağıdaki gibi sağlamaktayız.


Aşağıda görüldüğü PST’lerin aktarım durumlarını görebilmekteyiz.

User3 kullanıcımızı kontrol ettiğimde eski PST üzerindeki dosyalarımın import edildiğini görmekteyim.

Azure Resource Explorer Nedir ?

Microsoft Azure yeni deployment modeli olan Resource Manager kendine özel yeni bir API bizlere sunmaktadır. Azure Resource Explorer developer olan kişiler tarafından bu yeni modeli keşfetmeleri için çok faydalı bir araç. Resource Explorer erişmemizin birden fazla yöntemi bulunmaktadır. Bunların en temeli olan Azure New (Ibıza) Portal üzerinden erişebiliyorsunuz. Mevcut Azure hesabınız ile oturum açtıktan sonra, Resouce Explorer tıkladığınız zaman Resource Manager API bizlere verdiğini Provider kullanarak “GET”,”PUT”,”DELETE”,”POST” methodlarını API içerisine gönderip aksiyonlar alabilir veya veriler çağırabiliriz. Aşağıdaki örnekte Azure New (Ibıza) Portal içerisinde Resouce Explorer sayfasına erişebiliriz.

Resource Explorer bölümüne Azure Portal içerisinde eriştiğiniz zaman JSON formatında olarak kaynaklarımızın detaylarınızı keşfedebilirsiniz.

Bununla beraber dilerseniz, https://resources.azure.com sayfası üzerinden Azure Credentials ile oturum açtığımız zaman karşınıza yukarıdaki gibi bir sayfa gelecektir. Fakat bu sayfa şuan Preview olup bahsetmiş olduğumuz Resource Manager API ile “GET”,”PUT”,”DELETE”,”POST” methodlarını Web sayfası üzerinden gönderme şansımız bulunmaktadır. Biraz daha detaylandırırsak dilerseniz, oluşturulan Resource Group kaynaklarınızı silebilir veya Resource Grouplar arasında geçişler sağlayabiliriz. Resource Manager modelini ile ve sizde danışmanlık süreçlerinizde herhangi bir hizmeti deployment ederken zaman kazanmak istiyorsanız Resource Manager Template yapısını kullanarak çok hızlı bir şekilde provisioning işlemlerinizi gerçekleştirebilirsiniz. Resource Manager ile deployment yaparken arka tarafta bir JSON formatında kullanmak istediğiniz kaynaklarınızı detaylandırmanız gerekiyor. JSON formatının belirli bir syntax ile yazılmış olması ve bu JSON dosyasını Azure Powershell ( Resouce Manager) Modeli ile deployment sürecini başlatma şansınız var.

Bu tarz deployment süreçlerini diğer yazılarımda detaylarına iniyor olacağım. Fakat bu yapının nasıl çalıştığını anlamak için dilerseniz, GitHub üzerinden merakınızı gidebilirsiniz. Eğer biraz daha kestirmeden nirvanaya ulaşmak istiyorsanız aşağıdaki sayfa üzerinden tüm Deployment Template erişebilirsiniz. Hemen bu süreci anlamak adına https://azure.microsoft.com/en-us/ sayfasına girdiğiniz zaman, “Resources” sekmesiden “Templates kısmına tıklayalım ve karşımıza tüm publish edilen Resource Manager için geliştirilmiş template örneklerini bakalım.

“Templates” sekmesini tıkladıktan sonra karşımıza geliştirilen ve paylaşılan bütün Resource Manager Template örnekleri gelecektir. Aşağıdaki örnek üzerinde herhangi bir template tıklayıp deployment sürecinin nasıl işlediğini anlayalım.

Örnek olarak “Join a VM to an existing domain” yazısının üzerine tıklayarak Developer tarafından geliştirip ve publish konumda olan Resource Manager modeli ile hazırlanmış Deployment Template kullanmaya başlayalım.

Yukarıda görüldüğü gibi, “Deploy to Azure” butonu ile sizi Azure New Portal içerisine yönlendirecek ve geliştirilen Deployment Template içerisine tanımlanan JSON dosyasının içerisindeki parametreleri göndererek provisioning sürecine başlıyor olacaksınız. Resource Manager deployment modelini kullanarak sizde basit bir JSON dosyasına oluşturmak istediğiniz kaynaklarınızın detaylarını belirtip zaman kazanabilirsiniz.

Server Management Tools Overview – Part 3

Hizmetin geneline baktığımız zaman, şimdilik “Windows Server 2012 & R2 ” , “Windows Server 2016” ve “Nano Server” desteklenen sunucular olarak belirtilmektedir. Bu kısımda aslında başından beri söylediğimiz tüm sorguların Powershell ile yapılmasından kaynaklı kısıtlamalar ve İşletim Sisteminin tüm referanslarının alındığı WMI detaylarına işaret ediliyor. Temel nokta Windows Management Framework 5.0 destekleyen server işletim sistemlerinin yönetimi sağlanır.Bildiğiniz üzere “Windows Server 2012 R2 ” kurulduğu zaman Windows Management Framework 4.0 ile gelmektedir. “Server Management Tools” hizmeti için WMF 5.0 geçiş yapmanız gerekiyor olacak.

Azure Portal üzerinden hızlı bir şekilde “Server Management Tools” oluşturup yönetmek istediğim “Windows Server 2012 R2” sunucumu ve Gateway Server detaylarını belirttim.Kaynağın içerisine girdikten sonra “Manage as” kısmından Credentials bilgilerini tanımladıktan sonra, hemen karşımıza Windows Management Framework 5.0 ile ilgili uyarılar gelecektir. Portal üzerinden Install butonunu tıklayıp ve re-start işleminden sonra artık Windows Server 2012 R2 sunucunuz yönetime hazır olacaktır.

Windows Server 2012 R2 sunucumuzun başarıyla eklendiğini gördük. Senaryomuz gereği herşey oldukça kolay ilerledi. Aşağıda bu hizmet için oluşturduğumuz Resource Group içerisindeki kaynakların son görünümü bulunmaktadır. Unutamayalım, her sunucu için “Server Management Tools” hizmetini oluşturup erişebileceği Gateway Server’ı belirtmeniz sizden sadece bekleniyor.

Konumuzu biraz daha derinleştirelim. Ortamda “Domain Services” olmayan veya domain ortamına dahil olmayan sunucularınız (Workgroup) olacaktır. İsteğe bağlı olarak onlarında Azure Portal üzerinden bu hizmet ile yönetilmesi gerekebilir. Gateway Server ile Workgroup sunucunun haberleşiyor olmaları gerekiyor. Gateway Server üzerinden Powershell ile sorgular kontrol edildiği için sunucular arasında Powershell Remoting (HTTPS – 5986) portunun açık olması gereklidir. Aksi taktirde Gateway Server bağlantı sağlanamaz. Domain ortamının bize avantajı aslında bu noktada ortaya çıkmaktadır. Powershell Remoting özelliği Kerberos ortamlarda Credentials delegasyonu yaptığı için çok kolay ve esnek davranabilmekteyiz.Workgroup makineleri yönetirken aşağıdaki adımlara dikkat edilmelidir.

  • Gateway Server ve yönetilmek istenilen Server (non-Domainjoin) ile aynı network içerisinde olması
  • Gateway Server ile yönetilmek istenilen sunucunun PS Remoting HTTPS ( 5986) port’un açık olması.
  • Windows Firewall veya third party araçlar için ilgili PS Remoting portu için istisna kurallarının yazılması
  • Web-Server Management(WS-MAN) protokolünün kullandığı TrustedHost dosyasına Gateway ve Server için karşılıklı izin tanımlamaları yapılmalıdır.
  • Local Account ile erişim olacağından dolayı ilgili registry kayıtlarının girilmesi gerekiyor.

Şimdi sırasıyla yapılması gerekenleri adımlarını detaylandıralım.

Gateway Server üzerinde yapılacak işlemler

WorkGroup ortamındaki sunucu(ları) yönetmek istediğinizde Gateway Server üzerinde “winRM” ile ilgili bir takım komutlar çalıştırmamız gerekiyor. Yukarıda detayını bahsettiğimiz bu madde TrustedHost olarak geçmektedir. Aşağıdaki komutlardan birini Gateway Server üzerinde çalıştırmanız yeterlidir.

Yönetilmek istenen Server (WorkGroup) üzerinde yapılacak işlemler

Gateway Server Powershell Remoting protokolü ile Workgroup’ta hizmet veren sunucuya erişirken Local hesaplar ile erişim sağlanacağı için aşağıdaki registry kayıdını girmeniz gerekiyor. PowerShell ile aşağıdaki komutu çalıştırarak hedef makinede ilkeyi etkinleştirmemiz gereklidir.

Windows Firewall açık ise kuralı oluşturmak için hedef makinede yönetici olarak PowerShell veya Komut İstemi aşağıdaki komutu çalıştırın.

Yukarıdaki işlemlerden sonra başarılı bir şekilde “non-DomainJoin” sunucularınızın yönetimini gerçekleştireceksiniz.

Powershell ile PowerBI kullanarak Real Time Dashboard yaratılması – Part 4

Artık Powershell ile PowerBI REST API kullanmak için ClientId veToken alma işlemlerini gerçekleştirebiliriz. PowerBIPS ( PowerBI Powershell Modül) içerisindeki “Get-PBIAuthToken” cmdlet bizlere authentication için yardımcı olup ilgili token almamızı sağlayacaktır.

PowerBI ile üyelik aldığımız kullanıcı adı ve şifresini girerek token alma işlemini gerçekleştirelim. Eğer “Get-PBIAuthToken” komutunu direk çalıştırırsanız sizi “Sign-in” sayfasına gönderecek ve o kısımda gereken kullanıcı ve şifre bilgilerini dolurup token alma işlemini tamamlayabiliriz.

Hatırlarsanız, yazımızın ikinci bölümünde PowerBI Powershell modulü ile ilgili cmdlet açıklamalarını görebilirsiniz. Powershell ile herhangi bir cmdlet ile aldığımız sonuçlarımızı Json formatında göndermemiz gerekiyor ve aldığımız cevaplar yine JSON formatında geliyor. Tüm aradaki iletişim HTTP methodları ile sağlanıyor.Bu sayede anlık olarak veri kümeleri oluşturup, Dashboard yaratıp anlık olarak heryerden erişebilme şansımız bulunmaktadır.

Microsoft’un sunduğu şu sayfayı kullanarak, PowerBI REST API ile aklınıza takılan herşeyi test edebilirsiniz.

http://docs.powerbi.apiary.io/#

Şimdi Powershell üzerinden aldığımız bi sonucu PowerBI içerisine gönderelim. Başlangıç olarak “Get-Process” ile başlayalım. “Get-Process” çıkan sutünlardan sadece Process Adı ve Kullanılan Memory bilgisini getirelim ve çıkan sonuçtan, ilk 5 Process bilgilerini gösterelim.

# Bilgisayarınızda çalışan en fazla memory kullanan ilk 5 process

Get-Process , Sort WS -Descending , Select-Object Name,WS -First 5

Yukarıdaki “Get-Process” cmdlet sayesinde karşımıza listelenen Process Bilgilerini pipeline sürecine dahil ettikten sonra, Sort ve Select komutları ile istediğimiz sonucu elde ediyoruz. Artık yapmamız gereken sadece karşımıza gelen verileri PowerBI içerisine göndermek.

PowerBI Modülü içerisinde bulunan Out-PowerBI cmdlet sayesinde, PowerBI içerisinden aldığımız sonuçları, arka tarafta JSON formatına dönüştürüp ve veri kümesi (DataSets) olarak gönderebiliyor. Bu cmdlet bizim işimizi oldukça kolaylaştırıyor. JSON formatını hazırlamanıza gerek kalmadan gelen veriyi kendisini dönüştürüp veri kümesi(DataSet) ve tabloyu yaratabiliyor.

Kullanımını hemen inceleyelim.

# Out-PowerBI cmdlet ile beraber PowerBI içerisine gönderme

Get-Process , Sort WS -Descending , Select-Object Name,WS -First 5 , Out-PowerBI -Verbose

Yukarıda yazdığımız satırda “Get-Process” ile alınan sonuçlar pipeline süreci ile “Out-PowerBI” cmdlet içerisine gönderiyor. Cmdlet kullanırken “–Verbose” parametresini aktif hale getirerek çalışırken detayları görmek açısından oldukça faydalıdır. “Out-PowerBI” yazımızın başında aldığımız token(Get-PBIAuthToken) kullanarak, “Get-Process” cmdlet içerisinden gelen veriler için bir veri kümesi(dateset) ve bu veri kümelerinin içinde tablo(table) oluşturma işlemini gerçekleştirip, verileri ekliyor.

PowerBI sayfası üzerinden baktığım zaman, “Veri Kümeleri(DataSets)” altında “PowerBIPS_20150519” adında başlayan yeni bir veri kümesi eklendiğini görmekteyim. Veri kümesinin(DataSet) adını komut satırını çalıştırdığınız yerel bilgisayardaki tarih ve saat bilgilerini alarak belirlemektedir.

“Out-PowerBI” içerisine parametreler göndererek, Dataset ve TableName değerlerini biz belirtme şansımız var.

# Out-PowerBI cmdlet ile beraber PowerBI içerisine gönderme

$ProcessTable = Get-Process , Sort WS -Descending , Select-Object Name,WS -First 5

# Out-PowerBI içerisine data,DateSetName ve TableName parametlerini kullanımı

Out-PowerBI -data $ProcessTable -dataSetName “processDataSet” -tableName “processTable” -Verbose

Yukarıdaki örnekte ise, “Get-Process” kullanarak Sort ve Select yaptıktan sonra sonucu bir “ProcessTable” adında bir değişkene atadık. Bu değişkeni daha sonra, “Out-PowerBI” içerisinde “-data” parametresi içerisine gönderdim. Bu kısımda “-datasetName” ve “tableName” parametlerine belirtmek istediğimiz veri kümesi ve tablo adını yazmış bulunmaktayım. İlgili satırları çalıştırdıktan sonra, PowerBI tarafında oluşan veri kümesine bir göz gezdirelim.

PowerBI arayüzden Veri Kümeleri kısmına baktığım zaman “Out-PowerBI” içerisine göndermiş olduğumuz parametre değerleri ile veri kümesi ismini almış gözükmektedir. Serimizin diğer yazısında Veri kümelerini kullanıp, DashBoard yaratma süreçlerine bakıyor olacağız.

Office 365 Mailbox PST Download

Office 365 üzerindeki kullanıcıların işten ayrılması durumunda ilgili mail dosyalarını PST olarak download edebilmektesiniz.

Kullanıcının maillerine daha sonradan portal üzerinden erişebilmemiz için Office 365 yönetici kullanıcımıza aşağıdaki hakları vermemiz gerekmektedir.

Aşağıda Member kısmına eklediğim kullanıcı portal üzerinde yöneticisine yetkisine sahip kullanıcıdır.


Yukarıdaki benzer işlemleri farklı bir grup içinde gerçekleştiriyoruz.


Not: İlgili hakları verdikten sonra 48 saat beklemeniz gerekmektedir.

Son aşamada ise 48 saat bekledikten sonra Litigation özelliğini aktif ettiğiniz kullanıcı ile ilgili maillere ulaşıp ulaşamadığımızın testini gerçekleştirebiliriz.


Karşımıza çıkan seçenekte sadece 1 kullanıcının maillerine ulaşmak istediğimiz için “Specify mailbox to search” seçeneğini seçerek hangi kullanıcının maillerine ulaşacaksak ilgili kullanıcıyı aşağıdaki gibi ekliyoruz.


Bir sonraki seçenekte aşağıda bize ilgili kullanıcının tüm maillerine mi yoksa sadece arama kriterlerine göre mi maillerini çekeceğini sormaktadır.

Arama Kriterleri ; Şu kişiden gelen mailler , Şu kişilere göndereilmiş mailler , Şu tarih aralığı gibi seçenekleri belirtebilirsiniz.

Ben tüm datayı görmek istediğim için aşağıdaki seçeneği seçerek ilerliyorum.


Finish diyerek kuralımızı tamamlıyoruz.


Panel üzerinden aşağıdaki gibi ilgili kullanıcının mailbox boyutuna göre kurtarılan maillerin indirilmeye hazır hale gelmesini beklemeniz gerekmektedir. Status kısmındaki “Estimate Succeeded” onayını aldıktan sonra maillerimizi bilgisayarımıza PST olarak indirebilmekteyiz.


PST’yi indirdikten sonra Outlook’a eklediğimizde kullanıcının tüm maillerine ulaşabileceğiz.

Comparing Azure and Amazon EC2 Virtual Machines – Part 2

Yazımızın ilk bölümünde Azure ve Amazon EC2 Virtual Machines yapısının genel hatlarına ve dağıtım modellerinin detaylarını inceledik. Bu yazıda ise öncelikli olarak Datacenter yapısına göz gezdirelim.

  • Azure’da bir bölge tek Datacenter anlamına gelmektedir.(Örnek: West Europe). Bunun anlamı tüm verilerin ve hizmetlerin aynı tesiste yer aldığı anlamına gelmektedir.
  • “Availability Zone” (AZ) ile birlikte Amazon aynı bölgedeki hizmetlerin “geo-distribution” özelliği için izin verir.
  • “Availability Zone” (AZ) hizmetlere ve veriye aynı bölgenin parçası olabilmesi için izin verir. Fakat aynı fiziksel tesiste geçerli değildir. Azure’da bunu yapmanın tek yöntemi farklı iki Region kullanmaktan geçer.
  • Birden fazla Region kullanmak Amazon ( AWS) içerisinde önerilir. Bu yöntem gayet olağan bir durumdur. Burada önemli fark ise AWS Datacenterlar arası network trafiğini Internet üzerinden gitmektedir. Azure’un bölgeler arasındaki ağ trafiği ise Microsoft backbone yapısını kullanmaktadır.Yukarıdaki tabloda Datacenter sayılarını bulabilirsiniz.

Amazon ve Azure kendi yapılarında GovCloud ( Kamu ) isimli bir program başlattırırlar. Yukarıdaki Amazon ( AWS) ve Azure için GovCloud programında desteklenen hizmetleri bulabilirsiniz. ABD devlet kurumlarının ve iş ortaklarının görev açısından kritik iş yüklerini buluta dönüştürmelerini sağlayan, güvenebileceğiniz bir kamu-topluluk bulutudur. Fiziksel ve mantıksal ağdan yalıtılmış bir Azure ve Amazon örneği olan ve özel izinli ABD personeli tarafından çalıştırılan Azure ve Amazon GovCloud, ABD devlet kurumlarının ve iş ortaklarının ihtiyaçlarını karşılamak için özel olarak tasarlanmıştır. GovCloud Azure Resource Manager, Premium Depolama ve sadece A-Serisi VM’ler desteği vermez . Microsoft’un, 2016 yılında GovCloud için çok ciddi planlarının olduğunu söylemekte fayda var.


Tablo içerisinde bulunan tüm Azure kaynakları Resource Manager Dağıtım modeline ait olmaktadır, Amazon Web Services – EC2 karşılıklarını görebilirsiniz. Bu noktada temel amaç sizlere yardımcı olmaktır. Bunlardan bazıları kendi içerisinde işlevsellik açısından farklılık gösterebilir. Örneğin : Availability Sets ( Azure ) kavramı ile Amazon’da ise Availability Zones birbirlerinden çok farklılıkları vardır.

Virtual Machine kaynakları olarak Networking planlaması büyük önem taşır. Yukarıdaki tablo içerisinde Amazon ve Amazon (EC2) sanal sunucuları için kullanılan kaynakların karşılaştırma tablosunu bulabilirsiniz. Açıklamamız gereken bir kaç nokta var. Bunların başında Amazon içerisinde Load Balancer olarak kullanılan kaynak olan “Elastic Load Balancer” Azure tarafında “Load Balancer ve Application Gateway” kaynaklarına denk gelmektedir. Azure tarafında farklı olarak adlandırılan bu kaynakların yaptığı işi Amazon ise “Elastic Load Balancer” ile yapabiliyor. Bununla beraber, yine Azure DNS hizmeti yakın zamanda hayatımıza girmiş bulunmakta fakat henüz “Preview” olarak kullanılmaya devam etmektedir. Amazon da ise “Route 53” bir süredir kullanılan bir hizmet olduğunu söylemekte fayda var.

Microsoft Azure’un ve Amazon’un yaklaşımları Depolama açısından oldukça benzer fakat bazı diğer alanlarda da farklı olduğunu söylemekte fayda var. Bunların başında hemen “S3” Storage hizmetini inceleyelim. Amazon S3 Storage; güvenilir ölçeklenebilir, obje tabanlı depolama hizmeti sunan AWS servisidir. Kullandığınız miktar kadar ödersiniz. S3 üzerinde tutulan verileriniz, AWS içinde Availability Zones olarak adlandırılan merkezlere replicate edilerek hata toleransı azalır. Tabloda görüldüğü gibi S3 Storage, Azure Standart Storage hizmetine denk gelmektedir. Azure Storage ve S3 REST API yaklaşımı bakımından aynı modeldir.

Microsoft son dönemde Hybrid Storage adı altında firmaların kullandığı StorSimple hizmeti, Amazon tarafında karşılık buluyor. Amazon Storage Gateway hizmeti ile StorSimple arasında farklar var. StorSimple kullanmak isteyen firmaların kendi Datacenter içerisinde fiziksel bir storage barındırmaları anlamına gelmektedir. Amazon Storage Gateway ise bu durumu tamamen bir Virtual Appliance devrederek daha fazla esneklik sağladığını söyleyebiliriz.

Amazon tarafında karşılık bulamayan bir hizmet var. Azure Site Recovery ile beraber firmaların hizmet vermekte olduğunu sanal sunucuları veya fiziksel ayrımı olmaksızın çoğaltılmasını ve herhangi bir felaket senaryosunda uygulamalarınızın kurtarılmasını sağlamaktadır. Site Recovery şu sıralar oldukça popüler olmasının diğer bir sebebi ise firmalar herhangi bir “Olağan Üstü Kurtarma Merkezi” maliyetine katlamadan çok kısa sürelerde mevcut altyapıları için Felaket Kurtarma çözümünü uygulayabilmekteler.

Amazon Glacier ise veri arşivleme ve online yedekleme için oldukça düşük maliyetli ve güvenli depolama hizmetini sunan bir hizmet olarak karşımıza çıkmaktadır. Müşteriler çok ufak ücretler ile çok nadir eriştikleri dataları bu hizmet içerisinde saklayabilirler. Azure tarafında ise bu hizmete karşılık gelen kısmın “Cool Storage” olduğunu söyleyelim.

Office 365 Journaling

Merhaba , bugünkü makalemizde Office 365 üzerinde bulunan Journaling özelliğinin nasıl kullanılacağını inceliyeceğiz.

Office 365 Journaling özelliği organizasyonunuzdaki gelen ve giden tüm mail trafiğinin bir kopyasının belirlediğiniz bir mailbox’ta tutulmasını sağlamaktadır. Bu da şirketler açısından tüm mail trafiğinin takibi veya arşivlenmesi konusunda fayda sağlamaktadır.

Office 365 üzerindeki journaling özelliğini aşağıdaki gibi aktif hale getirebilirsiniz.

Exchange admin centerCompliance managementJournal rules

Senaryomuzda organizasyonumuzda bulunan gelen ve giden mail trafiğinin bir kopyası hknmrngz91@gmail.com adresine gönderilecektir.

Not : Exchange Online üzerinde bulunan Journal Rules ile sadece external adreslere mailinizin bir kopyası iletilmektedir. Şirket içerisindeki bir mailboxınıza gelen ve giden tüm trafiğin iletilmesini istiyorsanız makalenin son bölümünü incelemenizi rica ederim.

İlk olarak resimde bulunan 3 numaralı bölümde journal olarak tanımlayacağımız mail adresine ulaşılamayacağı durumlarda gelen ve giden tüm maillerinin bir kopyasının alternatif olarak belirteceğimiz adrese gönderilmesini sağlayacağız.


“Select Address” seçeneğini seçtikten sonra bu kısımda şirket içi bir adres belirtebilirsiniz.


Yukarıdaki adresi belirttikten sonra asıl gelen ve giden mail trafiğinin bir kopyasını ileteceğimiz adresi ayarlıyoruz.

Bu kısımda şirket içerisindeki tüm kullanıcıları belirtebileceğiniz gibi sadece belirli kullanıcılar içinde journalı aktif edip o kullanıcıların gelen giden trafiğinin bir kopyasını alabilirsiniz.


İlgili kuralımız aktif olmuş durumdadır.


Gmail hesabını kontrol ettiğimde artık gelen giden tüm trafiğin gmail adresime geldiğini görmekteyim.


Şirket içerisindeki bir kullanıcıyı Journal olarak ayarlamak ;

Exchange Admin CenterMail FlowRulesCreate a new rule


Senaryomuzda organizasyonumuzda bulunan gelen ve giden mail trafiğinin bir kopyası Exchange Online üzerinde yeni açmış olduğumuz journal@hakanmarangoz.net adresine gönderilecektir.

Not : “Add Exception” seçeneği ile belirleyeceğiniz kullanıcıları journal dışında bırakabilirsiniz.


Kaydet seçeneğinden sonra aşağıda gördüğünüz gibi kuralımız aktif hale gelecektir.


Journal adlı postamızı kontrol ettiğimizde aşağıdaki gibi artık tüm trafiğin bir kopyası ilgili posta adresine düşmektedir.


Ayrıca aşağıdaki bölümde spesific olarak bir veya birden fazla kullanıcıyı belirterekte journaling işlemini gerçekleştirebilirsiniz.

Örnek olarak sadece sekreterya@hakanmarangoz.net adlı kullanıcımın maillerinin gelen ve giden trafiğinin bir kopyasını journal@hakanmarangoz.net adresine göndermekteyim.


Journaling işlemini yukarıda belirtildiği şekilde gerçekleştirebilirsiniz.

Powershell ile PowerBI kullanarak Real Time Dashboard yaratılması – Part 5

Powershell ile aldığımız sonuçları PowerBI içerisine gönderirken neler yapmamız gerektiğinden bahsettik. Şimdi ise gönderdiğimiz veri kümeleri ( DataSet) içerisinde bulunan tabloları yayınlama kısmına geldik. PowerBI içerisinde Dashboard kısmına geldiğimiz zaman boş olarak gözükmektedir. Yeni bir Dashboard ekleyerek daha sonra mevcut veri kümeleriniz(DataSets) içerisinde tabloları kullanıp raporlar oluşturabilir veya raporlar yaratabilirsiniz.

PowerBI portal içerisinde Dashboard bölümünden hemen yeni bir DashBoard yaratıyorum.

Dashboard(Panolar) kısmında artı(+) işaretine bastıktan sonra oluşturmak istediğim Dashboard bir isim veriyorum. Ben makale serimizin başlığındaki gibi “Real Time Dashboard” ismini veriyorum. İsteğinize göre birden fazla Dashboard yaratılabilir. Oluşturduğum Dashboard işleminden sonra, Veri kümeleri(DataSets) üzerine gittiğim zaman bana ilgili veri kümesi içindeki tabloları(Table) listeyelecek ve istediğim field göre raporlar oluşturabileceğim. Biz örnek olarak “Get-Process” cmdlet kullanarak sonuçları PowerBI içerisine göndermiştik.

Oluşturmak istediğimiz veri kümesinin(Data Set) üzerine geldikten sonra, karşımıza tasarım ekranı gelmektedir. Bu kısımda, Veri Kümesi içerisindeki tablolar gözükmektedir. “processTable” içerisinde iki adet sutünüm var. Yukarıdaki resimde mümkün oldukça adımların sırası ve butonların ne işe yaradığını açıkladım.

Rapor tasarımını bitirdikten sonra, Dashboard kısmında “Real Time Dashboard” içerisine girdiğim zaman mevcut raporumu görebilmekteyim.

Real Time Dashboard için Powershell ile alınan sonuçların anlık olarak gönderilebilmesi için dikkat edilmesi gerekenler

  • Powershell ile oluşturulan query düzenli bir şekilde PowerBI içerisindeki veri kümelerini güncellemelidir.
  • İsteğe bağlı olarak yazılan Powershell query herhangi bir service yöntemine bağlanarak çalıştırılır.
  • Cloud-Base bir veri tabanı kullanarak Powershell sorgularını kaydedebilir ve PowerBI eşitlemesini gerçekleştirebilirsiniz.

Yazımızın son kısmında Mobile Phone ile erişimi gerçekleştirelim. IOS işletim sistemi ile App Store indirdiğimiz “PowerBI” uygulamamız ile oturum açalım.

Oturum açıktan sonra, oluşturduğumuz Dashboard sayfalarımızı ve Pinned ettiğimiz raporlarımızı görebiliriz.

Azure Automation – Part 0:Giriş

Azure Automation, Infrastructure as a service (IaaS) ve Platform as a service (PaaS) gibi aldığınız hizmetlerin Azure içerisinde uzun çalışan, hata eğilimi olan ve sık sık tekrarlanan görevleri düzenli olarak gerçekleştiren bir servistir. Bu makale serisi içerisinde Azure Automation hakkında sık sorulan sorulara cevap vermeye ve genel alt yapısını incelemeye çalışacağız. Makale serisine başlamadan önce size Anıl Erduran’ın ” Microsoft Automation Dün Bugün ve Yarın” adlı yazısını okumanızı şiddetle tavsiye ederim. Şimdi ise yarını detaylandırmaya başlayabiliriz.

Bu servisi kullananlar zaman, maliyet avantajı ve iş güçü kazanır. Bulut ortamlarında düzenli olarak gerçekleştirdiğiniz görevler için, (Provisioning ve Scale VM, Web Sites, Test Environment vb.) hiçbir insan müdahalesi olmadan hatasız, istenilen veya belirli aralıklarla gerçekleşmesini sağlar.

Azure Automation Windows Powershell Workflow söz dizimine uygun olarak yazılmış Runbook aktiviteleri kullanır. İhtiyacımızdan dolayı Workflow yazıldığı zaman bunu arka tarafta Windows Workflow Foundation (WWF) tarafından yürütüldüğünü söylemekte fayda var. Service Management Automation (SMA) ile Azure Automation benzerlik göstermektedir. İkisi de Windows Powershell Workflow ile geliştirilen Runbook aktivite biçimini kullanırlar. Azure Automation içerisindeki Runbook aktiviteleri Public Cloud Resource ve Azure ile ilgili powershell cmdlets ailesine erişim sağlarken, Service Management Automation (SMA) üzerinde bulunan Runbook’lar Windows Azure Pack’in parçalarına ve Azure Pack cmdlet’lere ihtiyaç duyar. Makalemiz içerisin de geliştireceğimiz Runbook aktiviteleri sayesinde, Azure Automation ihtiyaç duyulan zamanlar içerisinde ilgili sunucuların hizmet vermesini sağlayarak aldığımız hizmetin maliyetlerini azaltacak. Kaba bir matematik ile bunlara çok basit örnekler verelim.

Azure, Virtual Machine hizmetini aylık olarak kullanıcılarına sunmakta. Ancak bu hizmetin maliyet hesaplaması gizli bir sır barındırıyor. Maliyet kullanıcılara stabil olarak değil, kullandıkları kadar yansıyor. Geliştirdiğimiz Runbook sayesinde bu sırrı ortaya çıkartacağız. Örnek olarak A3 tipinde bir Virtual Machine alındığında, aylık maliyeti yaklaşık olarak 270($) dolardır. Bir ayda 720 saat olduğunu düşünürsek, bu hizmetin saatlik masrafı kabaca 0,375($) dolara denk gelmektedir. Saatlik masrafı gözünüzde küçük gözükebilir ancak birazdan geçeceğimiz derin hesaplar sonucu maliyetin küçük olmadığını göreceksiniz.(Yaptığımız veya bir sonraki yapacağım hesaplamalarda ay 30 gün olarak alınmıştır.) Örnek aldığımız sanal makinenin şirket içerisinde hizmet verdiği saatlerinin 09:00 – 18:00 arasında olduğunu varsayalım. Kullanılan sanal makinenin günün sadece 9 saati çalışmasına karşın, şirket sanal makineyi Azure üzerinde tüm gün hizmet olarak alıyor, saat ayrımı yapmıyor. Bu sebepten dolayı ödeyeceği 3,375 ($) dolar miktarı, 9 ($) dolara yükseliyor ve bu hesap ise sadece günlük kısmı. Aylık olarak hesaplamada ise, normal ödenmesi gereken miktar 101($) dolardır. Arada oluşan 169($) dolar farkı, yıllık olarak bakıldığında 2.028($) dolara yükseliyor. Geliştireceğimiz Runbook sayesinde, sanal makinenin sadece çalışması gerektiği saatler içerisinde çalışarak, maliyetten tasarruf etmemizi sağlayacaktır.

Azure Automation içerisinde oluşturduğumuz Runbook’lar ile On-Premises Datacenter yönetmeniz mümkün değil. Şimdiler de ismini çok sıklıkla duyduğumuz Operation Management Suite ile beraber artık Hybrid Runbook Server kavramı hayatımıza girmiş durumdadır. Azure Automation içerisin de buluanan Runbook’lar ile artık On-premises içerisin de Hybrid Runbook Worker olarak belirlenen sunucu tarafından uygulanabilir durumdadır. Operation Management Suite olması şartıyla, yüklenen bir Agent sayesinde gösterdiğiniz sunucuyu Hybrid Runbook Worker olarak belirtebilirsiniz. Aşağıdaki resim ile bu senaryonun kafamızda kısa süreliğine de olsa gerçekleşmesini istiyorum.

Azure Atuomation serisine aşağıdaki linklerden ulaşabilirsiniz.

  • Azure Automation – Part 1 – Automation Account Oluşturulması
  • Azure Automation – Part 2 – Assets Kullanımı
  • Azure Automation – Part 3 – Runbook Kullanımı
  • Azure Automation – Part 3.1 – Runbook Kullanımı
  • Azure Automation – Part 3.2 – Runbook Kullanımı