Powershell ile WMI ve CIM Kullanımı – Bölüm 1

Bu yazı serisinde Powershell ile WMI ve CIM teknolojilerinin nasıl çalıştığını, kullanım methodlarını genel hatlarıyla detaylandırmaya çalışıcam. Artık Blog üzerinde genelde seriler yazmaya çalışıyorum ve bu yazı serisine başlamak için çok sabırsızdım. Bir şekilde herkes Powershell ile haşır neşir oluyor fakat bu tarz derinlemesine konulara bakmaya fırsatı olmuyor veya dokunamıyor. İşte bu yazı serisinde bu teknolojilerin öneminden bahsedeceğim.

Windows Management Instrumentation (WMI) ve Common Information Model (CIM) birbirleriyle ilgili teknolojilerdir. Her ikisi de, farklı platformlarda uygulanabilen bağımsız yönetim standartlarını tanımlayan Distributed Management Task Force (DMTF), tarafından tanımlanan endüstri standartlarını temel alır. WMI, Microsoft’un Web-Based Enterprise Management (WBEM) standardının bir uygulamasıdır. Ön standartlara ve tescilli teknolojiye dayanan eski bir teknolojidir. CIM daha yeni bir teknolojidir ve açık, Cross-platform standartlarına dayanmaktadır. WMI, Windows NT 4.0’dan bu yana Windows işletim sisteminde kullanılabilir durumdadır.

DMTF nedir diyenler bu sayfaya göz gezdirebilirler. Distributed Management Task Force (DMTF) – www.dmtf.org. 

Her iki teknoloji de ortak bilgi deposu olarak (WMI deposu olarak da bilinir) bağlanmanın bir yolunu sağlar. Bu depo içerisine sorgular gönderebilir ve yönlendirebileceğiniz yönetim bilgilerini içerir. Windows PowerShell 3.0 ve sonraki tüm sürümler her iki teknolojiyi de desteklemektedir. Windows PowerShell’in önceki sürümleri yalnızca WMI’yı desteklemektedir. Windows PowerShell 3.0 ve sonraki sürümlerinde, paralel olarak iki komut grubu, WMI veya CIM’i kullanarak görevleri gerçekleştirmenize izin verir.

Yukarıdaki resim bir bilgisayarın Repository yapısı ile iletişim kurabileceği iki yolu gösterir. Yeni yol olan Common Information Model (CIM) komutlarını kullanmaktır(Get-CIMOBject). Bu komutlar Web Services for Management (WS-MAN) protokolünü kullanarak iletişim kurar ve Windows Remote Management (WinRM) hizmetine bağlanır. Eski yol olan Windows Management Instrumentation (WMI) komutlarını kullanmaktan geçiyordu ve bu komutlar, DCOM protokolünü kullanarak iletişim kurar ve WMI hizmetine bağlanırlar. (Get-WMIObject) Distributed Component Object Model (DCOM) protokolünü merak edenler bu sayfadan detaylara erişebilirler.

CIM komutları, çok sayıda Cross-Platform ve Cross version yetenekleri sunar. Çeşitli bağlantıları desteklerler bunlar sırasıyla,

  • DCOM kullanan yerel bilgisayara bağlantı sağlarlar.
  • Web Hizmetleri Yönetimi olan (WS-MAN) protokolünü kullanan uzak bilgisayara bağlantılar sağlayabilirler. Bu protokol defaul olarak HTTP tabanlıdır.
  • DCOM veya WS-MAN kullanabilen uzaktaki bir bilgisayara oturum temelli bağlantılar sağlar.

DCOM bağlantıları, genellikle Windows işletim sisteminin bir parçası olan Windows Management Instrumentation (WMI) hizmetine yapılır. WS-MAN bağlantıları, Windows PowerShell Remote Session ayarını etkinleştiren, Windows Remote Management (WinRM) hizmetine yapılmaktadır. WinRM hizmetini aktif ederken dikkat edilmesi gereken nokta, Windows Management Framework bir parçası olduğunu ve Windows Management Framework 2.0 ( Powershell version 2.0 üstü) ve daha yeni sürümlerinde bulunmaktadır. WinRM, varsayılan olarak Windows 7, Windows 8, Windows Server® 2008 R2, Windows Server 2012R2 ve Windows Server 2016 çalıştıran bilgisayarlara kurulu olarak gelmektedir. Varsayılan olarak tüm bu işletim sistemlerine yüklenmesine rağmen, WinRM yalnızca Windows Server 2012 ve üstü işletim sistemlerinde otomatik olarak etkinleştirilmiştir.

Azure Storage – Blob-Level Tiering – Part 1

Yeni kurulumlardan büyük organizasyonlara kadar, her endüstrideki müşteriler verilerinde üstsel büyüme yaşıyorlar. Bu verinin önemli bir bölümüne nadiren erişilebilir ancak iş sürekliliği ve uyumluluk gereksinimlerini karşılamak için uzun bir süre saklanmalıdır. Örnekler arasında çalışan verileri, tıbbi kayıtlar, müşteri bilgileri, mali kayıtlar, yedekler vb. yer almaktadır. Ayrıca, yapay zeka ve veri analizinde yeni olan gelişmeler, daha önce atıl olan veya saklanması gereken verilere ihtiyaç duyuyor. Bu yüzden firmaların çoğu, bu veri setlerinden daha fazla zaman saklamak istiyor ancak bunun için ölçeklenebilir ve düşük maliyetli bir çözüme ihtiyaç duyuyorlar.

Geçen yıl içerisinde Microsoft “Azure – Cool Blob Storage” hizmetini duyurmuştu. Müşterilerin erişilen verilerini “Cool Tier” adında bir katmanda saklayarak depolama maliyetlerini azaltmalarına yardımcı oldu. Bunu malasef Azure Storage Account oluştururken tipine göre belirleyebiliyorduk. Ignite 2017 duyurulan “Archive Storage” sayesinde nadiren erişilen verileri en düşük fiyatlı katmanda saklayarak, kuruluşların depolama maliyetlerini daha da azaltmalarına yardımcı olmak için tasarlanan Archive Blob Storage hizmetini genel önizlemesini duyurdu. Ayrıca, bu katmanlardaki blob düzeyindeki verilerinizin yaşam döngüsü düzeyini kolayca yöneterek depolama maliyetlerini optimize etmenize olanak tanıyan Blob Level Tiering’in özelliğini herkese açık önizlemesini sundu.

Archive Blob Storage Nedir ?

Azure Archive Blob Storage, esnek gecikme gereksinimleri olan nadiren erişilen veriler için (belirli bir saat içinde erişemde olur dediğiniz), yüksek kullanılabilirliğe sahip ve güvenli bulut depolama alanı olanağı sağlayan düşük maliyetli bir hizmet ile kuruluşları sağlamak üzere tasarlanmıştır. Yukarıdaki resimde görüldüğü gibi artık Azure Blob Storage içerisinde : Hot,Cool ve Archive isimlerinde üç farklı seviye bulunmaktadır. Bu farklı seviyeler arasında doğal olarak fiyat farklılıkları ve erişim methodlar var. Aşağıdaki resimde Archive Blob Storage kullanıldığı senaryoları görebilirsiniz. Fiyat konusunu merak edenleriniz var biliyorum fakat henüz bir resmi bir duyuru yapılmadı.

Archive Blob Storage Nasıl Kullanılır ?

Archive Blob Storage hizmetini kullanabilmeniz için aşağıdaki adımları gerçekleştirmeniz gerekmektedir. Şimdilik hizmet, Public Preview olduğu için bu işlemleri yapmaktayız. General Available olduğu gün bu dertlerimiz olmayacak. Powershell ve Azure CLI aracılığı ile birkaç istek gönderme sürecimiz var. Talebiniz onaylandıktan (1-2 gün içinde) East US 2’de kaynaklarınız için geçerli olacaktır. Önizleme sırasında yalnızca Storage Replication tipi Locally-redundant storage (LRS) olanlar desteklenecektir, ancak General Available’ da GRS ve RA-GRS hesaplarına (yeni ve mevcut) da destek vermeyi planlıyorlar. Bu talebimiz onaylandıktan sonra artık Blob düzeyinde Archive Storage ve Access Tier özelliğine sahip olabileceğiz. Makalemizin ana konusunu barından “Blob Level Tiering” olayı sayesinde mevcut blob’larınız için katmanlama durumunu sizin belirlediğiniz aralıklara göre ( 30 gün boyunca erişmediklerim – Archive Tier seviyesine geçsin.) gibi aksiyonlar alabileceksiniz.

Yukarıda bulunan Powershell satıları içerisinde Archive Blob Storage özelliğini aktif etmek için istek gönderdik. Son satırda ise gerekli talebi yaptıktan sonra “Registered” yazısını görmeyi beklemeniz gerekmektedir.

Archive Blob Storage özelliğini açıldı. Bu sayede hem Archive Blob Storage hemde Blob Level Tiering özelliğine sahip olduk. Archive Blob ve Blob Level Tiering konusundaki erişim methodlarına yoğunlaşabiliriz.

Azure Storage – Blob-Level Tiering – Part 2

Azure Storage içerisinde bulunan Hot, Cool ve Archive detayına bir önceki yazımızda değindik. Şimdi ise Archive Blob hizmetinin işleyişine bakalım. Eğer bir blob Archive Tier seviyesine olduğu zaman okunamaz, kopyalanamaz, üzerine yazılamaz veya değiştirilemez. Ayrıca Archive Storage bulunan bir blob’un snapshot özelliğinden faydalanamazsınız. Bu operasyonlar dışında, varolan bloblarınız için silmek, listelemek, blob özelliklerini / meta verileri elde etmek veya blob’unuzun katmanını değiştirmek için ilgili özellikleri kullanabilirsiniz. Archive Blob Storage içerisindeki verileri okumak için, Blob’un Tier (katmanını hot veya cool olarak) değiştirmeniz gerekir. Bu işlem, rehydration(rehidrasyon) olarak bilinir ve 50 GB’dan daha küçük blob’lar için 15 saate kadar sürebilir. Daha büyük bloblar için ise ek süre gerekebilir.

Rehidrasyon türkçe de yeniden yapılandırma anlamına gelmektedir. Mevcut Blob için rehidrasyon işlemi sırasında katmanın değişip değişmediğini teyit etmek için “Access Tier” özelliğini kontrol edebilirsiniz. İşlem tamamlandığında “Arşiv Durumu” özelliğinden görüntüleyebilirsiniz. Access Tier özeliiğine göre aslında data erişim sıklığı için tutulan bloblar için Storage hizmetinin bedeli değişmektedir.

Yukarıda bulunan örnekte Azure Storage Account içerisinde bulunan Blob seviyesinde katmanlamayı Azure Portal üzerinden yapmış bulunuyoruz. Rehidrasyon işlemini manuel yapmak pek hoş gözükmesede programatic olarak “.NET, Phyton, Java Client Library, Node.Js Client Library ve Azure API” ile süreci yönetme şansınız var.

Yukarıdaki örnekte “.NET” ile mevcut bir blob’un Access Tier seviyesini değiştirilmesini görüyoruz. Dilerseniz yukarıdaki yazılım dilleri ile aynı süreci gerçekleştirebilirsiniz. Şimdi ise ben biraz daha işin programatic tarafı için yapılan çözümleri aktarmaya çalışacağım. Bunların başında ilk aklıma gelen Logic Apps oluyor.

Hemen Logic Apps örneğini açmaya çalışalım. Storage Account içerisinde çok fazla blob’unuz olduğunu varsayalım. Son 30 gün içerisinde erişmeyen var ise (Modified Time gibi değerlere bakarak ) “Access Tier” kısmında gerekli değişimi Logic Apps içerisindeki bir flow ile değiştiğini düşünün. Gerçekten kulağa çok hoş geliyor. Hatta biraz daha ileri gidip firma çalışanları Office 365 Forms üzerinden talep edip “Access Tier” değişimleri yönetebilsek kestirmeden nirvanaya ulaşabiliriz.

Yukarıda bulunan örnekte “Logic Apps” içerisinde Data Lifecyle Management örneği gerçekleştirilmiş. Hergün düzenli olarak çalışan bir flow sayesinde “LastModified” 30 gün önce olan tüm blob’ların “Access Tier” özelliği Archive olarak değiştirililiyor.Logic Apps bir kenara bırakıp bunu analizin yapacak ve tarafınıza “Cost Saving” gibi bir çıktı veren bir araçtan bahsetmek istiyorum. Ignite içerisinde gösterilen “Azure Storage – Blob Tier Analysis Tool” sayesinde mevcut Storage Account içerisinde bulunan Blob’lar için analiz yapıp ilgili katmanlar arasında geçişi yönetmenize destek olacaktır.

Blob Tier Analysis Tool sayesinde yukarıdaki resim içerisinde desteklenen özelliklerden yararlanabilirsiniz. Yine kısa bir görüntü ile nasıl bir çıktı verdiğini görelim.

Yukarıdaki resim içerisinde Azure Storage Account içerisinde 779 GB veri olduğu gözlenmektedir. Blob Storage Analysis Tool, Storage Account içerisinde bulunan blobları inceleyerek gerekli senaryoları bizlere çıkarttı. Bir console uygulaması olarak gözüksede güzel bir analiz yapmış gözüküyor. Dilerseniz şu sayfa üzerinden ilgili uygulamaya erişip kendiniz build ederek analiz parametrelerini belirtebilirsiniz.

Blob Storage Analysis Tool yaptığı analizler sonra aldığı aksiyonlara dahil görüntüyü yukarıdaki resim içerisinde görebilirsiniz.

Azure Functions in Practice

Evrim her yerdedir, doğanın sahip olduğu gibi Bilgi Teknoloji departmanları da buna sahiptir. Her başka bir gün nereden geldiği belli olmayan bir yenilik çıkıyor ve insanlar bunu gördüklerinde tepkileri “Wow! işte bu herşeyi değiştirir.” oluyor.
Bilgi Teknolojileri birbirleriyle ilişkisi olmayan makinelerden küçük yerel ağlara ve sonra internete evrildi. Ayrıca veri merkezlerine sahipken ardından da buluta kavuştuk. Cloud Computing, IaaS olarak başladı, sonra hayatımıza PaaS ve SaaS’a girdi.

Azure Functions ( Serverless Architecture ) nedir?

Bir hayal kuralım ve yapmak istediğiniz bir işiniz var. Örneğin dosya işlemek, resim işlemek, bildirim yapmak vs. Bu işleri yapmak için sunucu, ortam ve diğer etkenleri düşünmeden sadece görevinizi tanımlayıp çalıştırabileceğiniz sistemler olduğunu düşünün. İlk olarak şunu kesinlikle anlamamız gerekiyor. Serverless demek kesinlikle programınızın çalışması için sunuculara ihtiyacınız olmadığı anlamına gelmiyor. Serverless mimarilerde kesinlikle sunucular kullanılıyor. Fakat burada önemli olan nokta bu sunucuların yönetiminin, dolayısı ile oluşan birçok operasyonel işlerin artık bizim değil servis sağlayıcının sorunu olması.( Function as a Services ). Yani production’da bir uygulama / kodu çalıştırmanın en önemli zorluklarından olan operasyonel işleri servis sağlayıcısına tamamen teslim etmiş oluyoruz. ( Bırakınız yapsınlar, yönetsinler ! ) Kısacası siz kodunuzu upload edin gerisine karışmayın. Cloud ortamı olduğu için ise kodunuz çalıştığı zaman aralığı için ücret ödeyin.

Azure Functions desteklediği yazılım dilleri, C#, F#, Node.js, Java, Python, PHP, batch, bash, or any executable. olarak söyleyebiliriz.

Azure Functions (veya AWS Lambda) ile ilgili müthiş şey, geleneksel olarak kodu yürütmek zorunda kalacağınız altyapıyı yönetmek / korumak zorunda değilsiniz. Benim aklıma ilk takılan soru ise Azure Automation’dan farkı ne acaba diye düşündüm. Azure Automation’ı biliyorsanız, Powershell ile otomasyon sağlayabilen bir servis. Ancak, Azure Function, Automation’ın sağladığının da ötesine geçmektedir. Automation PowerShell ile sınırlıdır ve gerçekten yalnızca bir web hook veya Azure SDK (API veya CLI) tarafından tetiklenebilir.

Azure Functions içerisinde Powershell’i kullanarak basit bir kod bloğumun çalıştırılması sağlayacağım.Yazdığım kod bloğunu Azure Function içerisine upload ettim ve sadece http trigger üzerinden istediğim zaman tetikleyerek ilgili code satırlarının çalışmasını gerçekleştireceğiz. Kod bloğumuz aşağıdaki gibidir.

Kod bloğumuz upload ettikten sonra, “Get function URL” butonuna basıp http üzerinden gerekli trigger url sahip olduk. Artık Azure Functions ile http üzerinden trigger ederek Powershell script’in çalışmasını sağlayabiliriz.

Trigger işlemini görüldüğü gibi “1.adım” içerisinde yaptım. Gelen istek çok hızlı bir şekilde Powershell Script çalışmasını sağladı. Functions hizmetini Powershell ile göstermeye çalıştım. Fakat diğer diller ile yapılabilecekleri hayal edin.Kazanımlarımızı kısaca özetlemek gerekirse; Şüphesiz ilk akla geleni maliyet adına bize kazandırdıkları, Pay-as-you-go– Kullanım başına ödeme diyebiliriz. Yukarıda kısaca bahsetmeye çalıştım tekrar edecek olursak, sunucunun RAM ve İşlemci kullanımına göre ödeme yaptığımız modelden, sadece foksiyonlarınız çalıştığı zaman ücret ödeme modeline geçmiş olacağız. Yaz ve çalıştır kolaylığına eriştiniz. Ayrıca Yönetecek, server vb. bir alt yapı da olmadığı için çok daha hızlı bir geliştirme süreci sunulmaktadır. Server kurma, yönetme, ölçeklendirme, güvenlik maliyetlerinden sizi kurtarıp sadece uygulamanızı, iş mantıklarınızı kurmanıza odaklamanızı sağlar.

Azure Building Blocks – Part 2

Yazımızın ilk serisinde genel hatlarıyla Azure Resource Manager ile Building Blocks yapısını anlamamız için açıklamalarda bulunduk. Building Blocks açık kaynaklı bir yazılım olduğunu ve Resource Manager dağıtım modelinde bize daha seri bir şekilde deployment yapmamıza yardımcı olacağından bahsettik. Şimdi ise genel yapısını ve nasıl kullanabileceğimize bakalım. Öncelikle Building Blocks aracını kurmanız için bir çok yöntem karşımıza çıkıyor. Eğer mevcut bilgisayarınız içerisinden bu tool erişip gerekli dağıtımı yapmak istiyorsanız, Azure Command Line Interface ( Azure CLI ) Yönetim aracını kurmanız gerekmektedir. Burası tamamen sizin seçiminize kalmakla beraber, dilerseniz Linux Bash üzerinden Building Blocks aracını yükleme şansına sahipsiniz. Ben bu yazı serisi içerisinde Azure CLI üzerinden devam edeceğim. Alternatif olarak tool kurulum süreçleri ile uğraşmak istemiyorum diyenler Azure Cloud Shell tercih edebilir ve Web Based olarak devam edebilirler.

Bir önceki yazımızda bahsettiğimiz gibi Azure Building Blocks 2.0 versiyonu ile indirilebilir durumdadır. Open Source bir araç olduğu için ve Azure CLI üzerinden kullanabilme durumunu hesaba katıp geniş bir şekilde bir çok platformda bu aracı tercih etmenizi sağlayacağını söyleyebiliriz. Bunların başını çeken, macOS, Ubuntu, Red Hat Enterprise Linux (RHEL), Fedora, or CentOS gibi İşletim sistemleri bulunmaktadır. Windows ise zaten söylememe gerek olduğunu düşünmüyorum. Şimdi sırasıyla Azure Building Blocks için neler gerektiğine bir göz gezdirelim.

  • Azure CLI 2.0 – İşletim sisteminize şu adresten kurulum gerçekleştiriniz.
  • Node.JS – İşletim sisteminize şu adresten kurulum gerçekleştiriniz.
  • Windows için – Command Prompt – Linux için ise Bash açılması gerekmektedir.

Windows üzerinde çalışan Azure CLI üzerinden gideceğim için Command Prompt üzerine gelip, aşağıdaki Package Manager (npm) çağırıp kurulumu gerçekleştireceğim.

Yukarıda görüldüğü gibi Azure Building Blocks kurulumunu başarıyla yaptık. Şimdi, Azure Building Blocks aracına nasıl eriştiğimizi anlamaya çalışalım. Aşağıdaki resimde görülen örnekte, Powershell üzerinden “azbb” yazdığım zaman ilgili aracı çağırmış bulunmaktayım. Bu araç ile gönderebileceğimiz parametleri görmekteyim. Yazımızın ilerleyen kısımlarında bu parametleri kullanıp deployment yapmaya çalışacağız.

Azure Building Blocks kurulumunu yaptık. Yukarıda bulunan resim size şaşırtmasın, Azure Building Blocks kurduğum zaman artık “Powershell” içerisinden çağırdım. Versiyon kontrolü yapmak istersek “AZBB” aracını çağırarak parametre göndermesi gerçekleştirelim ve versiyonumuzu öğrenelim.

“azbb –version” parametresini göndererek hangi versiyonda olduğumu öğrenmiş oldum. Bir sonraki yazı içerisinde artık Azure Building Blocks için deployment ve template geliştirme sürecine başlıyor olacağız.

Azure Building Blocks – Part 3

Azure Building Blocks temelde bir adet “Settings File” ihtiyaç duyar. Bu “Settings File” içerisine, Deploy etmek istediğiniz kaynağın detayları belirtirsiniz. Bu size tanıdık gelen bir format olacak fakat Azure Resource Manager Deployment modelinde geliştirdiğinizden oldukça basit bir şekilde karşınıza çıkmaktadır. Bu kısımdaki esneklikleri anlamak için hemen boş bir “Settings File” oluşturalım ve ardından ilk örneğimizle yola çıkalım.

Yıukarıda bulunan JSON şemasını izleyen bir “Building Blocks” tanımlaması ve ardından buildingBlocks dizisini istediğiniz şekilde dolduracak bir yapı izlemektedir. Şimdi basit bir örnek ile başlayalım.

Yapmak istediğimiz ilk kısım, Azure Subscription içerisinde basit bir Virtual Network ve subnet yaratılması gerekmektedir. Sırasıyla mimari aşağıdaki yapıyı içerir.

  • 10.0.0.0/16 adres alanına sahip “msft-hub-vnet” isimli bir VNet.
  • 10.0.1.0/24 adres alanına sahip “firewall” olarak adlandırılan “msft-hub-vnet” içindeki bir alt ağ.

Her blok bir JSON içerisinde nesne olarak temsil edilebilir. Örneğimiz içerisinde, basit bir Virtual Network’ü temsil etmek için aşağıdaki JSON nesnesini kullanalım.

Yukarıdaki JSON dosyasında buildingBlocks nesnesinin içerisine gerekli tanımlamaları yaptık. Dikkat ederseniz, “Type” adında bir nesnemiz var ve onun karşınıza gerekli kaynağın modelini tanıtıyoruz. Azure Resource Manager Template gibi uzun gözüküyor. “Bunun hangi aşaması kolay ? ” dediğinizi duyar gibiyim. Bu yüzden bu aradaki farklı anlamanız için aynı mimarinin Azure Resource Manager Template ile yazmaya çalışsaydınız örneğini aşağıdaki resimde görebilirsiniz.

Resim içerisine hepsini sığdıramadım fakat, yukarıdaki sadece basit bir Virtual Network oluşturulması için yapılan adımlardı. Azure Resource Manager Template kullanarak deployment yapmak oldukça zamanımızı alabiliyor. Hızlı ve basit bir şekilde yapmak için Azure Building Blocks sizleri bekliyor. Bir sonraki yazımızda geliştirmiş olduğumuz “Virtual Network Settings File” nasıl deploy edebileceğimizi inceleyelim.

Azure Building Blocks – Part 4

Building Blocks olarak son serimiz olan bu yazımızda artık geliştirdiğimiz “Settings File” nasıl deploy edeceğimiz üzerinden konuşacağız. Öncelikle Azure CLI tarafında dağıtım yapmak istediğiniz hesap ile oturum açmanız gerekmektedir.

Azure CLI üzerine gelin, “Az Login” yazdıktan sonra size bir URL ve Access Code verecektir. Daha sonra bu bilgiler ile browser üzerinden oturum açın ve Azure CLI üzerinde başarılı bir şekilde hesaplarınızın geldiğini yukarıdaki gibi görün. Hesabım ile oturum açtım ve tüm subscriptionlarımı görmekteyim. Artık Azure Building Blocks çağıralım ve deployment sürecinin nasıl işlediğini anlayalım.

Resim içerisinde ilk deployment senaroyumuzu başarıyla yaptık. Şimdi yaptığımız adımları sırasıyla açıklayalım. Azure CLI üzerinde deployment gerçekleştirmek istediğimiz hesap ile oturum açtık. Daha sonra ise, Azure Building Blocks aracını parametreler göndererek ufak bir deployment senaryosu gerçekleştirmiş olduk. Yukarıdaki resimde parametleri görebilirsiniz ve oldukça basitlerdir. Deployment sonrası Azure paneli üzerindeki durum aşağıdaki gibidir.

Azure Building Blocks – Part 1

Azure Resource Manager şablonlarının yazılması ve deploy edilmesi size esneklik ve otomatik bir ortam sunmasını sağlarken bazı durumlarda, Azure Resource Manager şablonları kısa sürede çok karmaşık hale gelebilir. Ayrıca, Azure Infrastructure ortamınız için Microsoft’un en iyi uygulamalarının ekibiniz tarafından yazılan her şablona yansıtılması sağlamak bazı durumlarda zor olabilir. Eğer Azure Resource Manager dağıtım modeline hakim değilseniz, Azure Resource Manager makale serimi okumanızı tavsiye ederim.

Bu makale serisinde, Azure Resource Manager şablonunu geliştirirken ve dağıtımını basitleştirmeye yardımcı olan açık kaynak kodlu Azure Building Blocks ele alacağız. Microsoft içerisinde bulunan dağıtım modelleri ve uygulamalar ekibi tarafından öngörülen en iyi uygulamaları yansıtan ( IaaS, PaaS ) – benzeri olan Azure Resource Manager şablonlarını içerir. Azure Resource Manager şablonlarını kullanarak ( Template Deployment – Github) kaynak dağıtımını destekler. Azure kaynaklarını yöneten bir kişi, Resource Manager Deployment API sayesinde JSON formatında bir model kullanır ve bunu Azure Resource Manager API üzerine gönderir. Örnek olarak ortamınıza deploy etmek istediğiniz kaynakları ; Virtual Machine, Virtual Network, Storage, Network Security Group olarak belirterek gerekli dağıtımı sağlayabilirsiniz. Yine talebinize göre dağıtımı yapılmak istenilen kaynağın özelliklerinin tamamı, dağıtım yapılacak zamanda parametrik hale getirilerek özelleştirilir. Aşağıda bulunan resim içerisinde Azure Resource Manager dağıtım modelini destekleyen bir JSON dosyası bulunmaktadır.

Azure Resource Manager şablonları çok güçlü, büyük ve karmaşık mimarileri dağıtmanıza izin verirken, Azure Resource Manager hakkında geniş bilgiye ihtiyaç duyarlar. Bu durum ise bazı zamanlarda geliştirdiğiniz şablonları koruma kısmında zorluk çekmenize sebebiyet verir. Çünkü herhangi bir değişiklik, ön görülemeyen sorunlara neden olabilir. Azure Resource Manager güçlü dememin altında yatan oldukça fazla sebep var. Örneğin, bir Virtual Machine dağıtmak istediğinizi varsayalım. Deploy olurken içerisine kurabileceğiniz role, registry, gibi ucu açık bir kapı olduğunu düşünün. “Ne gerek var ?” Dediğinizi duyar gibiyim. İşte burası biraz komplike bir süreç olduğu gözükebilir ama Virtual Machine Scale Sets kullanırken zaten bunları yapmak zorunda kalıyorsunuz. Azure Building Blocks temel amacı daha basit bir şekilde deployment süreçlerinizi yapabilmenizi sağlamaktadır.

Azure Building Blocks projesi, Azure kaynaklarının kullanımını basitleştirmek için tasarlanmış bir komut satırı aracı olup, Azure Resource Manager kapsamını kullanarak bu sorunu çözer. Building Blocks, Resource Manager Deployment modelindeki gibi JSON formatı ile yazılır ve Azure Resource Manager şablonlarından yararlanarak dağıtımı gerçekleştirir. Azure Resource Manager Template olduğu gibi parametre belirtebildiğiniz gibi, Building Blocks içinde bu şansa sahipsiniz. Building Blocks JSON şeması çok basit olacak şekilde tasarlanmıştır. Azure Building Blocks 2.0 versiyonu ile şimdilik anılmaktadır.

Building Blocks şu anda aşağıdaki kaynak türlerini desteklemektedir.

  • Virtual Networks
  • Virtual Machines (including load balancers)
  • Virtual Machine Extensions
  • Route Tables
  • Network Security Groups
  • Virtual Network Gateways
  • Virtual Network Connection

Hangi Özellikler Aktif Edildiğinde Exchange Enterprise Client Access License (E-CAL) Kullanmak Gerekir

Bu yazımızda lisanslama konusunda sıklıkla soru işareti yaşanan, Exchange Server Enterprise CAL kullanımının gerekli olduğu durumlara açıklık getirmek istedik. Yazı içerisinde bu konulara ilişkin bilgiler verecek ve Enterprise CAL kullanımı konusunda lisans içerikleri ve kullanım yöntemlerini anlatmaya çalışacağız.

Exchange kurulumların da yanlış yapılan aksiyonlar sonucu on-premise kullanımlarda beklenmedik CAL & SERVER lisans maliyeti çıkmaktadır. Office 365 ile birlikte Office uygulamalarına yönelik ihtiyacınızı karşılarken aynı zamanda e-posta hizmetinizi de ek lisans maliyeti düşünmeden BT süreçlerinize çözüm sağlayabilirsiniz.

Exchange İstemci erişim lisansları (CAL) ile ilgili önemli bir noktaya değinmek isterim: Eğer Exchange Standard CAL özelliklerine sahip olmak istiyorsanız sadece Standard CAL almanız yeterli olacaktır. Ancak Exchange Enterprise CAL özelliklerine sahip olmak istiyorsanız hem Exchange Standard CAL hemde Enterprise CAL almanız gerekmektedir.

Aşağıdaki tabloda ve maddelerde Exchange Standart CAL ve Enterprise CAL kapsamında gelen özellikleri inceleyebilirsiniz:

 

Exchange Standard CAL

  • E-posta gönderip alma ve e-postaları kişisel bir posta kutusuna kaydetme, randevuları ve toplantıları planlama ve kişisel takvim oluşturma
  • E-posta ve fiziksel adresleri, telefon numaraları ve diğer kişisel bilgileri içeren bir rehber veritabanını saklama; görevleri zamanlama ve tamamlanma süreçlerini izleme
  • E-posta, takvim, kişiler ve görevler için tarayıcı tabanlı erişim (Outlook Web App üzerinden)
  • Exchange yazılımının kötü amaçlı yazılım ve spam filtreleme özellikleri, virüsleri, casus yazılımları ve istenmeyen iletileri posta yoluyla toplu halde siler.
  • Mobil aygıtın Exchange ActiveSync protokolü aracılığıyla Exchange’e erişmesini sağlayan ve verileri mobil aygıtlarla senkronize eden ve minimum mobil aygıt parolası uzunluğu gibi temel yönetim ilkelerini zorunlu kılacak şekilde temel mobil aygıt yönetimi
  • Bir grup posta kutusuna gönderilen ve bu posta kutularından gönderilen tüm iletileri arşivleyen temel günlük (bazen Günlük Veritabanı Günlüğü olarak da bilinir)
  • Varsayılan klasörlerde bulunan iletilerin ne kadar süre tutulacağı ve bir ileti alıkoyma yaşına ulaştığında sistemin ne yapması gerektiğini denetleyen temel saklama politikaları (bazen Varsayılan Saklama Politikaları olarak adlandırılır)
  • Önceki sürümlerin Çoklu Posta Kutusu Aramasını genişleten ve yetkili personelin (yasal ve uyum görevlileri gibi) e-posta, takvim, görev ve kişi öğelerinde organizasyon çapında arama yapmasını sağlayan yerinde eDiscovery.
  • Site posta kutuları, ekip üyelerinin tek bir kullanıcı arabirimi aracılığıyla bir SharePoint sitesinin belgelerine ve ilişkili e-posta iletilerine erişmesini sağlayan Exchange Server 2013’e yeni bir özellik (ve SharePoint 2013).

Exchange Enterprise CAL

  • Standard CAL tarafından sağlanan özelliklere ek olarak yasal zorunluluklara ve kamusal düzenlemelere uyma yeteneğini geliştirmek için aşağıdaki maddelerde yer alan ek özellikle Enterprise CAL ile beraber gelir. Böylece Exchange Server altyapısında daha kurumsal yetenekler aktif edilebilir.
  • Bir mobil telefonun bir PC için bir modem olarak kullanılmasını önleme gibi Exchange ActiveSync ile daha kapsamlı politika uygulanmasını sağlayan birinci sınıf mobil cihaz yönetimi
  • Günlük kaydı belirli kullanıcılara veya gruplara gönderilen e-postaya sınırlandırarak daha ayrıntılı denetimi ve dolayısıyla daha küçük dergileri sunan birinci sınıf günlük kaydı (bazen Kullanıcı Başına / Dağıtım Listesi Günlüğü olarak da bilinir)
  • Saklama ilkesinin varsayılan olmayan klasörler üzerinde (örneğin, kullanıcılar tarafından oluşturulan klasörler) ayarlanmasına ve kullanıcıların belirlediği saklama parametrelerinden önce gelen tek tek iletiler için bir saklama politikası belirlemesine izin veren, birincil Saklama politikaları (bazen Özel Saklama Politikaları). sistem yöneticisi
  • Sesli postaları metne çeviren (kullanıcılara arayan kişinin mesajının okunabilir bir önizlemesini verir) birleştirilmiş mesajlaşmaya sahip sesli posta, sesli posta ses ve metnini e-posta ve fakslar olarak aynı gelen kutusuna yerleştirir ve birleştirilmiş gelen kutusuna erişim sağlar Sesli komutları kullanarak standart bir telefondan
  • Exchange çevrimiçi koruması, kötü amaçlı yazılım ve spam gönderen e-postaları filtreleyen ve Exchange Enterprise CAL üzerinde Yazılım Güvencesi kapsamını koruyan kuruluşlara ek bir ücret ödemeyen ve Microsoft tarafından barındırılan bir hizmettir.
  • Yetkili personelin diğer tüm bilgi saklama politikalarını (süresiz veya belirli bir süre için) geçersiz kılmasını ve belirtilen posta kutularında önceden saklanan mesajların korunmasını ve bu posta kutularında önceden depolanmış iletilerin korunmasını sağlayan Yerinde Kayıt Olun (önceden Hukuk Mahfazası veya Dava Tutma adı verilir). sonraki tüm gelen ve giden iletiler korunur
  • Kuruluşlara, Outlook kişisel mağaza (PST) dosyalarının aksine yöneticiler tarafından güvenilir bir şekilde yedeklenebilen, kurumsal politika uyarınca korunan bir sunucu tabanlı e-posta arşivleme seçeneği sunan Yerinde Arşiv (önceden Kişisel Arşiv) adı verilen ve gerektiğinde arandı
  • Yöneticilerin kullanıcılara herhangi bir müdahalede bulunmadan iletileri ve ekleri koruyan kuralları tanımlamalarını sağlayan Otomatik İleti Koruması, Windows Rights Management Services’ı kullanıyor (korumalı iletileri gönderen veya alan her istemci de bir Windows Rights Management Services CAL’ıyla lisanslanmalıdır)
  • İleti içeriğini kişisel tanımlanabilir bilgiler gibi hassas bilgileri analiz eden ve iletileri filtrelemek veya sonuçları izlemek için ilkeler yapılandırmasına izin veren Veri Kaybını Önleme

    Sunucu tarafındaki lisanlama kapsamı için aşağıda güncel Exchange Server 2016 Lisanslamasını inceleyebilmeniz adına paylaşıyorum.

Exchange Server 2016 Lisanslaması

Sunucu lisansları

İki sunucu sürümü vardır

  • Standart: Küçük ve orta ölçekli kuruluşların posta kutusu ihtiyaçları için tasarlanmıştır. Ayrıca daha büyük bir Exchange dağıtımında posta kutusu olmayan roller için de uygundur. Bu sürüm 1’den 5’e kadar posta kutusu veritabanlarını destekler.
  • Kullanıcı Basına Exchange Standard Cal ile lisanslanmış olması gerekmektedir.
  • Enterprise: daha büyük sayıda posta kutusu veritabanları gerektirebilecek daha büyük kuruluşlar için tasarlanmıştır. Bu sürüm 1’den 100’e kadar posta kutusu veritabanını desteklemektedir.Enterprise CAL özelliklerini etkinleştirebilmek için kullanıcı başına Standard CAL’a ek olarak bir de Enterprise CAL ile alması gerekmektedir.


Exchange Server Standard & Enterprise özellikleri aşağıdaki gibidir
Sunucu ve Kullanıcı için Standart ya da Enterprise lisanslama yaklaşımı, tablolara ve maddelediğimiz listelerde yer alan özellikler göz önünde bulundurularak kurumsal ihtiyaçlara yönelik geliştirilmelidir.
Başka bir yazıda görüşmek dileğiyle.
 

Microsoft Connections ve Microsoft Listings: Çevrimiçi Asistanlarınızın Yardımıyla İşinizi Büyütün!

Office 365’i küçük ölçekli işletmeler için daha değerli ve verimli hale getirmek üzere, Microsoft’un Business Premium’a getirdiği üç önemli uygulama var:

  • Microsoft Connections: Kolay kullanımlı bir e-mail marketing ve pazarlama hizmeti sağlıyor.
  • Microsoft Listings: Yaptığınız işe dair bilgileri ve gelişmeleri, en popüler sitelerde kolayca ve hızlıca yayınlamanızı sağlayacak bir yol sunuyor.
  • Microsoft Invoicing: Profesyonel faturalar oluşturmanın ve ödeme süreçlerini hızlandırmanın yeni bir yöntemi olarak konumlandırılıyor.

Microsoft Invoicing, Türkiye pazarında yer almayacak, dolayısıyla onun üzerinde durmayacağız; ancak diğer iki ürünü inceleyeceğiz.

Microsoft Connections: Basit email marketing araçları ile satış süreçlerinizi destekleyin!

Email marketing, satışların artırılmasında kritik önem taşıyan bir süreçtir; ancak bu sürece başlamak ve onu yönetmek gerçekten zahmetli ve zor olabilir. Microsoft Connections sayesinde, önceden tasarlanmış bülten, duyuru, teklif ve referans şablonlarını kullanarak profesyonel görünümlü email marketing kampanyaları oluşturabilirsiniz ve daha da önemlisi, bunu gerçekten çok kolay bir şekilde yapabilirsiniz. Ek olarak, kullanıcıların ve müşterilerinizin, mailing listelerinize kolaylıkla abone olmalarını veya abonelikten çıkmalarını sağlayacak yöntemleri kullanabilirsiniz. Connections, yeni ve potansiyel müşterilerinize ulaşma, var olan müşterilerinizin memnuniyetini ve bağlılıklarını güçlendirme ve işinizi büyütme gibi konularda size yardımcı olacak, etkili bir uygulamadır.

Connections ile, mailing listeleriniz büyüdükçe, müşterilerinizi belirli özelliklerine göre, etkili ve net şekilde ayırıp gruplandırabilirsiniz. Performans grafikleri ve abonelerin aktivite güncellemeleri sayesinde, her kampanyanız için tıklamalar, yeni abonelikler, ödemeler, aboneliklerden çıkışlar gibi göstergeleri takip edebilir, böylelikle nelerin düzgün çalışıp yolunda gittiğini ve nelerin yolunda olmadığını görebilirsiniz.

Connections, Office 365 Business Premium (İş Ekstra) aboneliğine sahip kullanıcılar için, web’de ve iOS ile Android cihazlarda kullanılabilir durumdadır. Web’de Office 365 Business center panelinden, iOS veya Android cihazlarınızda ise Microsoft Connections mobil uygulaması ile erişebilirsiniz.

Connections, yakın gelecekte, tüm müşterilerin kullanımına açık bir Outlook eklentisi olarak da hayatımıza girecek.

Microsoft Listings: Firmanızın ve yaptığınız işin yeni müşterilerce keşfedilmesini sağlayın!

İşinizin ve faaliyetlerinizin çevrimiçi ortamda aktif ve takip edilebilir durumda olması, potansiyel müşteriler tarafından keşfedilebilmenin etkili bir yoludur. Bununla birlikte, çevrimiçi varlığınızı uygun şekilde düzenleyip geliştirmek, kritik sayılabilecek bilgileri güncel tutmak ve sitelerdeki performansları ayrı ayrı ölçümlemek, süreci karmaşıklaştırıp zaman alıcı bir hale getirebilir. Microsoft Listings, Facebook, Google, Bing ve Yelp gibi platformlarda, işinize ve firmanıza dair bilgileri yayınlamanız ve yönetmeniz için kolay ve ideal bir yöntem sunar.

Microsoft Listings, Office 365’i kullanmaya başlarken girdiğiniz şirket ve firma profili verilerinizi çekerek işe başlar. Bunun ardından, süreç dahilinde, Office 365 Business center panelinden ulaşacağınız Listings panonuzda iş profilinizi güncellediğinizde, bu değişiklikler, Facebook, Google ve Bing’e otomatik olarak yansır. Bu işlemleri gerçekleştirmek ve söz konusu platformlarda listelenelerek Listings’i yönetmek için, kullanıcınızın Office 365’te Genel Yönetici (Global Admin) rolüne sahip olması gerekir.

Listings, işinizle ve firmanızla ilgili yapılan derecelendirmeleri, değerlendirmeleri ve geri bildirimleri kolayca takip etmenizi sağlayacak bir web paneli de içerir. Tüm platformlardaki verileri tek seferde kontrol edebilir veya bunları ayrı ayrı gözlemleyip karşılaştırmayı da tercih edebilirsiniz.

Listings size, müşterilerinizin fikirlerini ve görüşlerini anlayıp çevrimiçi ortamdaki bilinirliğinizi güçlendirmeniz adına çok kolay ve etkili bir çözüm sunmuş olur.

Keyifli çalışmalar!