These days, Lots of people want to use Terraform which is from Hashi Corp. In this article, I'm going to be writing about Terraform and Azure. The Terraform is an open source software. As a tool for building, changing, versioning infrastructure. Terraform within configuration files I can explain to Terraform the components need to run, I could say single application or multiple application. As you know, when you heard Terraform, you suppose it which was working with only Cloud Provider. However, Terraform works with Cloud Providers such as Amazon, Cloudfare DigitalOcean, or Azure etc. also works with On-Premises resources like Vmware. The Main idea is Infrastructure as Code.

Terraform manages different type of components. The components can be low-level or high-level resources. I can give an example of components. As Low-Level Resource "Storage, Network" or As High-Level Resource like "DNS Enter record or change rule on Load Balancer". Moreover, we know all that, we have used different types of tool to deploy resource on Azure. I mean, we have used Azure Resource Manager in the typical case or use Azure Portal or Azure Software Development Kit or maybe REST API something like that. We know, if you've used Amazon Web Services, Amazon Web Services do same. Therefore, DevOps Engineer loves using YAML or JSON so the Problem space is here. The Terraform which is starting to solve this problem has magic tricks. The tool is doing create a common structure or well-known format. That allow developers or DevOps Engineer for get used to the same format. DevOps Engineer will have described their resources and they will use their code on Azure or Azure. Conclusion, it allows people to develop, manage their infrastructure as code. It's enthusing. Briefing for Terraform has completely written in GO.

Firstly, we have need to setup Terraform access to your Azure Services. We have used the shared account in this demonstration. I will demonstrate in Azure CLI.

#Firstly, login to the Azure CLI using:

az login

The Subscription which will be going to demonstration.

az account set --subscription="3b40246b-ffa0-43df-a51e-0c2317b4afc3"

Next, create separate credentials for Terraform.

az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/3b40246b-ffa0-43df-a51e-0c2317b4afc3"

Now you see your AppId, DisplayName, Password, tenant.

Now, I have created Azure Service Principal for managing our Azure Resource with Terraform. The Service Principal will have used by Terraform. After, We are going to use our Service Principal Account because we need to authenticate within Service Principal Account. We have to use those lines for authenticating in Visual Studio Code. The previous picture as you can see our Service Principal Details like AppId, DisplayName, Name, Password. You have learned details in the previous picture our Service Principal Details like App Id, DisplayName, Name, Password. Now, I'm going to authenticate with them.

Now, We are ready to use Terraform. Almost we are done. Let's learn to Terraform. Do not forget, I have created a project in the Visual Studio Code, therefore, I have installed the necessary extension and client application on my computer. I will be trying to create a few resources within Terraform. When I wrote this article, I was using Visual Studio code. If you are interested in this editor, you should be able to check my personal blog. You can check this heading on the web site. "How to use Visual Studio Code".

I have written a few lines in Visual Studio Code before I'm calling Terraform Application for Azure CLI. It is not a complicated process. You must write "Terraform init" for initializing this application. After All, I have called Terraform. Let's see.

Now, I think, We are good to go. I'm going to show you our Terraform structure. As you know, It has a common structure and quite easily. You could see our Terraform structure below.

Now we can push to our code into the Terraform client application. As you can see top of the code block, I have indicated provider to "Azurerm". If you want to change it for your provider, you can have a look this website. I deployed that code block into the Terraform with parameter. The "Apply" parameter will deploy your defined-code on Azure.

provider "azurerm" {

If you want to add your Azure Service Pricipal Account details, you can manifest here.

As you know I did add before.

#subscription_id = "REPLACE-WITH-YOUR-SUBSCRIPTION-ID" #client_id = "REPLACE-WITH-YOUR-CLIENT-ID" #client_secret = "REPLACE-WITH-YOUR-CLIENT-SECRET" #tenant_id = "REPLACE-WITH-YOUR-TENANT-ID" }

Create a resource group

Create a resource group

resource "azurerm_resource_group" "network" { name = "terraform-RG" location = "West US" }

Create a virtual network within the resource group

resource "azurerm_virtual_network" "network" { name = "terraform-vNET" address_space = ["10.0.0.0/16"] location = "${azurerm_resource_group.network.location}" resource_group_name = "${azurerm_resource_group.network.name}"

subnet { name = "terraForm-VNET" address_prefix = "10.0.1.0/24" } }

Conclusion, It was successfully when we had deployed our resources on Azure Portal. The best ways for Terraform, DevOps Engineer does not need to focus which one is the best YAML or JSON. I hope so, they will have focused their business.

I did post one years ago "Azure Server Management Tools". The Post explained "How to use Azure Server Management" and it also has three different part. But, I'm willing to give you details for Windows Admin Center. Actually, Microsoft has announced this product "Project Honolulu". But İt has changed to "Windows Admin Center". I'm keen to work with this product because it's working with agentless. Indeed, Windows Admin Center is browser based management your Windows Servers without Azure or Cloud dependency. Also, Windows admin center is the future of remote server management designed to modernize and simplify the IT administrator experience. if you want to perform a management task on a machine there are almost twenty different tools. Perhaps we've consolidated all these tools into a single machine. Maybe we called it "Admin Management Server". We have almost deployed all tools

Windows admin Center think of it as the evolution of traditional inbox management tools like MMC it's great for administrators that need a lightweight management solution for smaller scale deployments or ad hoc management for large scale deployments.

How does Windows Admin Center Work?​

Basically, IT Administrator runs in a Web Browsers and manages only these type of VMs.

• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows 10

Also, The Windows Admin Centers has particularly roles. These are called to "Web Server" and "Gateway". You can install Windows Admin Center to Windows Server 2016 and Windows 10. As a matter of fact, It is quite beautiful to have a chance to install Windows 10. According to me if you are planning install that services, you should try to Windows Server 2016. I'm going to explain roles.

Gateway : The gateway administers servers by using Remote PowerShell and WMI over Windows Remote Management. Also, The gateway is included with Windows Admin Center in setup package.

Web Server : I could say, The Web Server is included same package with Gateway. In other words, Windows Admin Center in a single basic "msi" package that you can download it.

Let's have a look that picture.

Windows Admin Center defines your management environment​

Integration existing solutions, The Admin Center works with Microsoft products like System Center and Azure Operation Management Suite. It gives you "Manage your Infrastructure Single Management Console". In the other hand, Windows Admin Center contains many of the familiar tools you currently use to manage Windows Servers and clients so you don't need lost your time for adaption. In Fact, it is installed easy and you will use familiar functionality to manage your servers like "Microsoft Management Console – MMC". However, if you are implementing your firewall and DNS server, you will be able to access your Windows Admin Center on the Internet. Windows Admin Center has a lot of points of integration with Azure services, including Azure Activity Directory, Azure Backup, Azure Site Recovery, and more.

I'm quite excited to huge features Extensibility for Windows Admin Center. Microsoft and 3rd party developers to build tools and solutions beyond the current offerings. Microsoft offers an SDK that enables developers to build their own tools for Windows Admin Center. If you are excited like me, you can look at this page. Windows Admin Center- SDK

Next Article, I will be writing for "Install Windows Admin Center".

If you provide web services with clients spread across multiple locations, you must be able to run your apps in a load-balanced manner across many datacenters. Azure Load Balancer gives you to scale your applications and create high availability for your services. Azure Load Balancer can use Internal and Outbound scenarios. It will be providing low latency, high throughput, and scales up to millions of flows for all TCP and UDP applications. To give an example, I would say "Azure Load Balancer supports TCP/UDP-based protocols such as HTTP, HTTPS, and SMTP, and protocols used for real-time voice and video messaging applications." There are two different types of Tier. We generally announce it "Basic and Standard."

Why Do I use the Azure Load Balancer?​

Azure Load Balancer ought use to for that services

• Companies that have incoming internet traffic to virtual machines. This scenario is called as a Public Load Balancer in Azure
• Companies that have traffic between virtual machines inside a virtual network. You can besides communication a Load Balancer frontend from an on-premises network in a scenario. This scenario is called as a Internal Load Balancer in Azure
• When we have special cases, sometimes we have to use Port Address Translation. Port Forward traffic to a specific port on specific virtual machines with inbound NAT rules.
• Load-balanced gives you a chance to manage your IPv6 Internet connectivity all the way to native IPv6 endpoints on your Azure virtual machines.

In this article, you will learn how to configure and use Azure Load Balancer to improve responsiveness and availability of Azure Services.

What is Load Balancer?

A Load Balancer Resource can consist as either a Public Load Balancer or an Internal Load Balancer. The Load Balancer resource properties are explicit as a frontend, a rule, a health probe, and a backend pool definition. Virtual machines are always placed into the backend pool by specifying the backend pool from the virtual machine. You can use an Azure Load Balancer to enhance availability and scalability of virtual machines by configuring them as a load-balanced set. Azure Load Balancer provides functionality similar to hardware load balancers by eliminating single points of failure (application or hardware), increasing uptime during planned maintenance or upgrades, and distributing workloads across multiple, identically configured compute nodes. Azure Load Balancer can handle traffic originating from within the same Azure virtual network, from any directly connected network, or from the internet. In addition, it provides the network address translation (NAT) capability, facilitating connections to individual virtual machines in the load balanced set.

Overview Load Balancer features

You can load balance traffic that targets specific IP addresses and specific TCP or UDP ports. The Basic Azure Load Balancer is free of charge. The Standard Azure Load Balancer has a charge related with it. If you are using the Standard Azure Load Balancer, it will come a few different features like Azure Availability Zones, HA Ports, Up to 1000 instances. You can have to look that picture to understand structure.

Both load balancers control the flow of traffic targeting an IP address and a port assigned to their frontend configuration across a set of virtual machines residing within a virtual network. Incoming traffic is subject to load balancer rules and inbound NAT rules that you define. The outcome of rule processing determines which virtual machine behind the load balancer becomes the recipient of that traffic

To configure a load balancer in Azure Resource Manager, provide the following details:

• Front-end IP configuration : Identifies one or more IP addresses that are accepting incoming traffic that needs to be load balanced.
• Back-end address pool : Designates the virtual machines that receive network traffic from the load balancer.
• Load-balancing rules : Determine how to distribute incoming traffic across virtual machines in the back-end address pool.
• Probes : Verify the health and availability of virtual machines in the back-end pool.
• Inbound NAT rules : Determine the types of traffic that should be redirected to individual VMs in the back-end pool rather than being distributed across the VMs.

You can use the Azure portal, Azure PowerShell, Azure CLI, Azure Resource Manager templates, or REST API to create a load balancer. For example, to create a virtual network, a virtual network subnet, and an public load balancer that will balance incoming network traffic on port 5590 and provide connectivity on port 3389 to two back-end VMs, you would use the following procedure.

Create Azure Load Balancer with

I will demonstrate you "How to create Public Azure Load Balancer with Powershell". You can also use Azure Portal. Before we start, you have to open Azure PowerShell, and then sign in to your Azure Resource Manager Subscription

# Login Azure RM

Login-AzureRmAccount

Create Resource Group for Load Balancer Infrastrıcte

New-AzureRMResourceGroup –Name RG-4sysops –Location “WestEurope”

Create a new VNet named "Sysops-VNET", assign an address space (in this example 10.10.10.0/24), and store a reference to the new virtual network in the $vnet variable

# Create Virtual Network $vnet1 = New-AzureRmVirtualNetwork –ResourceGroupName "RG-4sysops" ` –Name Sysops-VNET ` -AddressPrefix 10.10.0.0/24 ` –Location westeurope

Now, if you may want, you can create additional subnet in same Virtual Network. I have just created subnet in the "Sysops-VNET"

# Create Additional Subnet $BackendSubnet = Add-AzureRmVirtualNetworkSubnetConfig -Name BackEndPool ` -VirtualNetwork $vnet1 ` -AddressPrefix 10.10.0.0/26

You have to update configuration when you create additional subnets in VNET. We will be use "Set-AzureRMVirtualNetwork" for update process.

# Update Virtual Network Set-AzureRMVirtualNetwork –VirtualNetwork $vnet1

Create an Azure Public IP address resource named "sysops-IP", to be used by a front-end IP pool

# Create Public IP $publicIP = New-AzureRmPublicIpAddress -Name sysopsIP ` -ResourceGroupName "RG-4sysops" ` -Location "WestEurope" ` –AllocationMethod Static ` -DomainNameLabel "sysopslb"

Create a front-end IP configuration named LB-Frontend, that uses the Public IP address, and the store the value in the variable $frontendIPAddress

# Set frontendIPAddress $frontendIPAddress = New-AzureRmLoadBalancerFrontendIpConfig -Name LB-Frontend ` -PublicIpAddress $publicIP

Create a back-end address pool named sysopsLB-backend, and then store the value in the variable

# Backend Address Pool Config $BackEndIPPool = New-AzureRmLoadBalancerBackendAddressPoolConfig -Name sysopsLB-backend

Create the NAT rules that will redirect all incoming traffic on port 3441 and 3442 to port 3389 on back-end VMs.

# Inbound Rule $inNATRule1 = New-AzureRmLoadBalancerInboundNatRuleConfig -Name RDP1 ` -FrontendIpConfiguration $frontendIPAddress ` -Protocol TCP ` -FrontendPort 3441 ` -BackendPort 3389

$inNATRule2= New-AzureRmLoadBalancerInboundNatRuleConfig -Name RDP2 ` -FrontendIpConfiguration $frontendIPAddress ` -Protocol TCP ` -FrontendPort 3442 ` -BackendPort 3389

Create a health probe that will check the health status on a page named HealthDemo.aspx:

# Probe Rule

$healthProbe = New-AzureRmLoadBalancerProbeConfig -Name HealthProbe ` -RequestPath 'HealthDemo.aspx' ` -Protocol http ` -Port 80 ` -IntervalInSeconds 15 ` -ProbeCount 2

Create the load-balancer rule to balance all incoming traffic on port 443 to the back-end port 443 on the addresses in the back-end pool

# Load Balancer Rule

$sysopsLBRule = New-AzureRmLoadBalancerRuleConfig -Name HTTPS -FrontendIpConfiguration $frontendIPAddress ` -BackendAddressPool $BackEndIPPool -Probe $healthProbe ` -Protocol Tcp -FrontendPort 443 -BackendPort 443

Create load balancer named sysopsLB that will use previously configured rules

# Create LoadBalancer Object

$LoadBalancer = New-AzureRmLoadBalancer -ResourceGroupName "RG-4sysops" -Name 4sysops-LB ` -Location "WestEurope" -FrontendIpConfiguration $frontendIPAddress ` -InboundNatRule $inNATRule1,$inNATRule2 -LoadBalancingRule $sysopsLBRule ` -BackendAddressPool $BackEndIPPool -Probe $healthProbe

 We are now creating NICs and configure a back-end IP address pool.

# Create Network Interface for VMs

$backEndInterface1 = New-AzureRmNetworkInterface -ResourceGroupName "RG-4sysops" -Name NIC01 ` -Location "WestEurope" -PrivateIpAddress "10.10.0.10" ` -Subnet (Get-AzureRmVirtualNetwork -Name "Sysops-VNET" -ResourceGroupName "RG-4sysops").Subnets[0] ` -LoadBalancerBackendAddressPool $LoadBalancer.BackendAddressPools[0] ` -LoadBalancerInboundNatRule $LoadBalancer.InboundNatRules[0]

$backEndInterface2 = New-AzureRmNetworkInterface -ResourceGroupName "RG-4sysops" -Name NIC02 ` -Location "WestEurope" -PrivateIpAddress "10.10.0.11" ` -Subnet (Get-AzureRmVirtualNetwork -Name "Sysops-VNET" -ResourceGroupName "RG-4sysops").Subnets[0] ` -LoadBalancerBackendAddressPool $LoadBalancer.BackendAddressPools[0] ` -LoadBalancerInboundNatRule $LoadBalancer.InboundNatRules[1]

Now, you can see your resources in Resource Group on the Azure Portal what we have created.

As you know, We learned Azure Stack Identity and authentication ways before on this blog. At the present time, I thought we should have to learn Azure Stack Multi-Tenancy structure. Before we start, we should be understanding "Why we need Azure Stack Multi-Tenancy Infrastructure".

Basically, If you want to give service to your customers, you have to configure Multi-Tenancy in Azure Stack. This authentication is an imperative requirement when Azure Stack does not use AD FS and the customers of Azure Stack are from a different Azure AD from the one used for Azure Stack administration.

As a matter of fact, If you choose to use Active Directory FS-based identity and authentication, then you can not activate multi-tenancy in Azure Stack. As you know, When you installed Azure Stack on your Infrastructure, you can see an Active Directory Domain Services for Azure Stack Infrastructure but it is not sufficient for your customers. Thus Azure Stack will be able to use either Azure AD or AD FS for identity and authentication of cloud operators, cloud administrators, and DevOps.

When using Azure Stack with Azure Active Directory for identity and authentication of cloud operators, cloud administrators, and DevOps, you can enable Azure Stack to authenticate cloud administrators and DevOps from Azure AD instances that are different to the instance used by the cloud operator.

Important Note: If you still deployed and customized Azure Stack on your Infrastructure, you should have to use one of the two identity providers, Azure AD or AD FS, you cannot change the identity provider!

After you have decided to use Multi-Tenant Infrastructure, you ought to use Azure Stack Tools for executing the command line.

You can find - Azure Stack Tools

# Download the tools archive Set-Location C:\Users\HasanGural\.vscode

Invoke-WebRequest https://github.com/Azure/AzureStack-Tools/archive/master.zip -OutFile master.zip

Set-Location C:\Users\HasanGural\AzureStack-Tools-master

Expand the downloaded files

After you have downloaded and extracted the tools, you must configure the Azure Resource Manager instance in Azure Stack to publish the Azure AD applications

Set-Location C:\Users\HasanGural\AzureStack-Tools-master

#Importing to Module Import-Module .\Connect\AzureStack.Connect.psm1 Import-Module .\Identity\AzureStack.Identity.psm1

$adminARMEndpoint = "https://adminmanagement.local.azurestack.external"

$azureStackDirectoryTenant = "hasangural.onmicrosoft.com"

Publish-AzureStackApplicationsToARM -AdminResourceManagerEndpoint $adminARMEndpoint ` -DirectoryTenantName $azureStackDirectoryTenant

Within the System Resource Group, in the Default Provider Subscription, there are a lots of new application registrations was been created.

• AzureBridge.Azure Bridge
• AzurePackConnector.Azure Pack Connector
• CRP.AzureStack Compute Provider
• Deployment.Deployment Application
• KeyVault.AzureStack KeyVault
• Monitoring.AzureStack Monitoring Service
• Policy.AzureStack Policy Service
• Portal.Microsoft Azure Stack
• ResourceManager.Azure Stack

After you have been executed that script lines, Now Azure Stack is ready to be used in a multi-tenancy capacity.

There are few questions how to understand Azure Stack Platform Manages Identity and Security. In this article, You will learn about Azure Stack Identity ways. For instance, when your customer logging into the Azure Stack Portal, they should have accessed to their resources. For this reason, you must understand how identity and authentication work in Azure Stack.

Identity Providers accessible in Azure Stack

Azure Stack generally uses well-known Identity Providers to authenticate an end-user or client. Azure Stack passes a security token to the Identity Providers, which end users can use to access resources for which they have been granted permissions. After Azure Stack will have trusted the supplier of the security token

Some of them are ( Identity Providers List )

• Windows Live ID
• WS-Federation
• Yahoo
• Google
• Facebook

As you can see, Both Azure and Azure Stack use the Access Control Service (ACS) to manage the authentication process. To help understand this process, review the following Access Control Service architecture diagram.

Presently, Azure Stack is supporting the following Identity Providers:

1. Active Directory Federation Services (AD FS)
2. Azure Active Directory (Azure AD)

If you installed an Azure Stack, you will see an Active Directory domain is installed as part of your Azure Stack Environment. This Active Directory can use to provide authentication to the hosts and virtual machines that make up the Azure Stack infrastructure. Nevertheless, authentication with this domain does not provide access to the Azure Stack Portals from either a cloud operator or user perspective. To obtain access to Azure Stack, you must have an identity in the trusted identity management solution. However, just having an identity does not necessarily give you access to resources. For example, your account "hasan@hasangural.com" is an Azure AD account, and this Azure AD account is associated with an Azure Stack subscription. Unless your account has been given access to a subscription, you will not be able to access any resources.

If I want to use these services, what will happen?

Active Directory Federation Services​

Firstly, This Lovely Service used to a lot of services including the third party. If you need to authenticate to the Azure Stack infrastructure using your organization's Active Directory identities, you have to configure AD FS between your organization's AD DS and Azure Stacks Active Directory. As you know, It will be an extra cost. ( Cert, Maintenance, Monitoring. Etc ). One of the benefits of using AD FS is that your organization's infrastructure engineers can use their existing credentials to sign in and manage the Azure Stack environment. They should configure their AD FS Services. An AD FS relying on party trust between the AD in Azure Stack and the AD DS in your organization is used to handle the authentication process. However, using AD FS gives you no permissions to access the Azure Stack Infrastructure AD domain. Anyway, It should not be forgotten that "Azure Stack requires Windows Server 2016 AD FS."

Azure Active Directory Services

As you know, Azure AD is the cloud-based identity management solution provided by Microsoft and is hosted in Azure. However, If you used to Office 365, you have an experience that services. It can have identities that have been solely created in the Azure AD or have identities synchronized from the traditional AD domain.

By using Azure AD identities that have been synchronized from an AD domain, you can choose how to authenticate the users:

• Same Sign-On: Using Azure AD Connect, which synchronizes the identities from AD Domain Services to Azure AD, you can choose to additionally synchronize identity passwords too. This allows users to use the same username and password to authenticate with Azure AD as they do with AD DS.
• Single Sign-On: Instead of using the same password to authenticate users, this option enables the authentication of the identity to occur either through an AD FS infrastructure associated with Azure AD and AD DS or with pass-through authentication.

Multi-Factor Authentication

If you need to configure Multi-Factor authentication, you can do this. You will configure AD FS and Azure AD to utilize Multi-Factor Authentication. The Claims Provider, which could be either AD FS or Azure AD, handles Multi-Factor Authentication outside of the Azure Stack environment.

The following each section, I want to explain.

• Internet connectivity required: For Azure AD-based authentication, Azure Stack requires access to the Internet to authenticate an identity with Azure AD. The Azure AD authentication process then commences either through Same Sign-On or Single Sign-on. AD FS does not require Internet access, provided the Claims Provider can be contacted without having to traverse the Internet. With AD FS, it is the responsibility of the Claims Provider to provide the authentication token to Azure Stack.
• Multi-Tenant: When you configure Azure Stack to use Azure AD for authentication, the cloud operator identity is authenticated with a single Azure AD instance. However, tenant identities can be authenticated from several different Azure AD instances if required. Using AD FS-based identity management, only a single tenant domain can be used as the relying party trust and can only be configured to use a single AD FS Claims Provider
• Fully disconnected: Because Azure AD-based authentication requires Internet access to authenticate identities, you cannot use Azure AD-based authentication in a fully disconnected scenario. AD FS does not require Internet access
• Marketplace Syndication: Regardless of which identity management option you choose, you can use marketplace syndication. However, in an AD FS scenario, the Azure Stack deployment cannot be operating in a fully disconnected scenario.
• Multi-Factor Authentication: You can choose whether or not to use Multi-Factor Authentication outside of Azure Stack. You can configure the identity management solution, irrespective of whether it is Azure AD or AD FS, to utilize Multi-Factor Authentication if required

In sum up, If you are Azure Stack Operator and Cloud Engineer, you should think deeply. Because, you know customers might get you interesting request.

MSHOWTO olarak "MsHowto Tech Summit 1" etkinliğini Microsoft ofisinde gerçekleştirdik. Konuşmacı olarak yer aldığım seminerde Azure Resource Manager isimli sunum ile katıldım. Keyifli bir organizasyon oldu. Katılım gösteren tüm herkese teşekkür ediyorum.

CIM ve WMI tarafından kullanılan repository, farklı namepsace yapısı içerisinde düzenlenmiştir. Bir namespace alanı temelde bir klasör gibi düşünülebilir ve farklı yönetim amaçlarıyla ilgili öğeleri gruplamak için kullanılır. Namespace alanları kendine içinde class(sınıflar) içerir. Bir class, yönetilebilir bir yazılım veya donanım bileşenini temsil edebilir. Örneğin, Windows işletim sistemi, işlemciler, disk sürücüleri, hizmetler, kullanıcı hesapları vb. Için class yapısı bizlere sağlar. Network ortamında bulunan her bilgisayar, farklı işletim sistemlerine sahip olacağından dolayı farklı namespace alanları ve class yapısına sahip olabilir.

Farklı namespace ve class yapısına hızlı bir örnek verecek olursak, Örneğin Active Directory rolüne sahip bir bilgisayar ile Windows Client arasında namespace ve class yapısı doğal olarak farklılık gösterecektir. Gelelim bu repository içerisinde nasıl aramalar yapılır bu namespace ve class nasıl erişeceğim dediğiniz duyar gibiyim. İşte bu kısımda yardımımıza önereceğim araçlar yetişiyor olacak ve işimiz çokta kolaylaştıracak.

Ama bunun öncesinde bir WMI ve CIM class çağırıldığı zaman bunların bir takım özellikleri bulunuyor ve bunları aşağıda inceleyelim.

• Methods: Method yapısı kullanılarak aksiyonlar aldırabiliriz. ( Uzak bilgisayara Re-start, servis-start-stop)​

• Properties: Çağırdınız class içerisinden alınabilecek bilgilerdir. Nitelik.​

• Events: WMI veya CIM class'ını izleyip gerçekleştiklerinde harekete geçebilecekleri eylemlerdir.( Trigger)​

Şu anda WMI için namespace ve class yapısını keşfedebileceğiniz birkaç GUI aracı var, bu yüzden bir kez Namespace, Class, Properties veya event yapısı ile çalışmak istediğiniz zaman karar verebilirsiniz. Birçok sistem yöneticisi tarafından WMI'yi keşfetmek için en sevdiğim araçlardan biri, SAPHIEN firmasının WMIExplorer diyebilirim. Bu araçlar oldukça kolaylık sağlıyor. Powershell ile Namespace, class, properties ve method aramaları gerçekleştirebilirsiniz ama oldukça zor olabiliyor siz isterseniz bunun için aşağıdaki örneklere dikkat edin.

Bilgisayarınızdaki veya remote bir bilgisayardaki tüm namespace alanlarını listelemek için Windows PowerShell'i kullanabilirsiniz.

Yukarıdaki örnekte Powershell ile bilgisayarınız üzerinde bulunan tüm "Namespace" isimlerini listemiş bulunuyoruz. Namespace içerisinde "Class" detaylarını nasıl incelendiğine bakalım. Windows PowerShell, belirli bir namespace alanındaki tüm class'ları listeleyebilir. Örneğin, "root \CIMv2" namespace alanındaki tüm sınıfları listelemek için aşağıdaki komutlardan birini çalıştırabilirsiniz.

Yukarıdaki görüldüğü gibi Powershell içerisinden ilgili NameSpace adını yazıp, tüm WMI ve CIM Classlarini listelenmesini sağladık. Class isimlerine dikkatinizi çekmek istiyorum. "Win32_*" ile başlayanlar WMI temsil ediyorlar, bu classları kullandığınız zaman isimlerinden göründüğü gibi bilgileri elde edebiliyoruz. Mesela, "Win32_Volume" Class'ını Powershell içerisinden çağırıp sorgulama yaptığım zaman, sorgulama yaptığım işletim sistemleri üzerinde Volume bilgilerini alabileceğimiz detaylar gözüküyor olacak. Burası gerçekten çok fazla detay gerektiren ve zamanla kavranabilecek bir yer. SCCM, SpiceWorks, diğer Inventory Management yapan tüm yazılımlar aslında OS üzerindeki bu class yapısına sorgular yaparak bilgileri topluyor. Bir sonraki yazımızda bu class yapısının özelliklerini inceleyelim.

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.

CIM komutlarını iki şekilde kullanabilirsiniz. İlk yöntem olan bağlanmak istediğiniz uzaktaki bilgisayarın WinRM'yi yüklenmesi ( işletim sistemi versiyonu detayını unutmayalım) ve aktifleştirmenizi gerektirir. Bu süreç genellikle, Windows Management Framework 3.0'ın yüklenmesini ve Windows PowerShell Remote Session özelliğinin aktif hale getirilmesi durumudur. CIM komutlarını kullanmanın ikinci yöntemi ise, komutu eski hali olan WMI teknolojisini kullanması durumudur. Bu sayede, WMI komutlarıyla aynı sorgulara cevaplar alabilir ve Windows Management Framework uzak bilgisayarda kurulmasını ve aktifleştirilmesi gibi süreçler ile uğraşılmaz.

Windows Management Instrumentation (WMI) komutları ve teknolojisinin detayları

WMI komutları ile CIM komutları aynı havuzu kullanırlar. Aralarındaki tek fark, WMI komutlarının uzak bir bilgisayara nasıl bağlandığının detayıdır. WMI komutları session tabanlı bağlantıları desteklemez. Komutlar, yalnızca geçici bağlantıları DCOM üzerinden destekler. WMI veya CIM komutlarıyla kullanıldığında, DCOM bazı durumlarda kullanımı zor olabilir. DCOM, Remote Procedure Call (RPC) protokolünü kullanır. Bu protokol doğru çalışması için güvenlik duvarı istisnaları gerektirir.

WMI komutları, WMI servisiyle iletişim kurar. Uzak bilgisayarda herhangi bir WMI sorgusu yaptığınız zaman Windows Management Framework herhangi bir sürümünün detayı aranmaz ve Windows PowerShell Remote Session özelliğinin etkinleştirilmesi ile uğraşılmaz. Bağlanılacak uzak bilgisayarda Windows Güvenlik Duvarı özelliği etkinleştirilmişse ve third-party bir hizmet aktif ise, WMI sorguları için uzak bilgisayarda güvenlik duvarı tarafında kuralları WMI servisi için kurallar yazılması gereklidir. CIM komutları DCOM'u da kullanabileceğinden, WMI komutları session olarak sorgulama yapmadığı için (ad-hoc connection model) WinRM'in uzak bilgisayarda aktif edilmesi aranmaz. CIM ve WMI özetine baktığımız zaman, WMI ile sorgular yaparken herhangi bir servisin aktif edilmesi ile uğraşılmasına gerek kalmaz sadece Firewall tarafında bir takım kurallar yazılması gereklidir.

WMI işletim sisteminin farklı bölümlerine erişim sağlayan nesne topluluğu olarak bakabiliriz. PowerShell'de nesnelerinde sahip olduğumuz gibi her biri için properties, method ve event'lar var. Bu nesnelerin her biri "System32\wbem" dosyasında ".mof" uzantısıyla kaydedilen MOF (Management Object Framework) adlı dosyalar tarafından tanımlanır.

WMI veya CIM hangisi tercih edilmeli?

Öncelikle çoğu zaman, WMI cmdlet'lerinin yerine CIM cmdlet'lerini kullanmanız gerekir. Bunun birden fazla sebebi var aslında.

• CIM cmdlet'leri uzak bilgisayarlara yapılan bağlantılar için WS-MAN'ı kullanır.​

• CIM cmdlet'leri, uzak bilgisayara oturum temelli bağlantılar için DCOM veya WS-MAN kullanabilir.​

WMI cmdlet'leri ile sorgulamalar yaparken, Windows Management Framework 2.0 veya daha yeni bir sürümü yüklü olmayan bir bilgisayara veya Windows Management Framework 2.0 yüklü ancak Windows PowerShell Remote Session sistemine sahip olmayan bir bilgisayara geçici bir bağlantı oluşturmanız gerektiğinde bu gereksinimlere ihtiyacınız yoktur.

CIM tarafında ise oldukça farklı durumlar mevcut yazımızın başında dediğim gibi cross platform desteği olması, ortamda bulunan bir switch cihazına CIM session üzerinden komutlar gönderme şansınız var. CIM cross platform ve cross versiyon olayında oldukça önde olduğunu tekrar hatırlatalım.

WMI ve CIM teknolojilerinin detaylarını anlattıktan sonra artık cmdlet mimarisine geçelim. Kendine ait ama çok benzer bir yapıya sahipler. "Get-Command" cmdlet yardımı ile "WMI" cmdlet hepsini listeleyelim.

Yukarıdaki bulunan resimde WMI ailesine ait tüm cmdlet listesi bulunmaktadır. Şimdi ise CIM cmdlet ailesine göz gezdirelim.

CIM cmdlet ailesi WMI'dan fazla görünüyor. Yeni teknoloji olan CIM modeli oldukça işimizi kolaylaştıran cmdletere sahip. Çok kısa bir örnek ile bunun detayına değinmek istiyorum. WMI ve CIM işletim sisteminin repository olarak düşünmeyi asla unutmuyoruz. Ortamınızda bulunan bilgisayarlarda SCCM, Intune, SpiceWorks ve diğer Varlık yönetimi yapan tüm uygulamalar arka tarafta WMI veya CIM kullanarak bizlere raporlar sunmaktadır. Bir sonraki yazımızda Repository kullanımının detayına bakalım.

MSHowto Ekibi olarak, 24 Şubat 2018 Cumartesi günü Microsoft İstanbul Ofisi Jupiter 2 salonunda benim de konuşmacı olarak yer alacağım "MSHOWTO ile Tech Summit -1" etkinliğimize davetlisiniz. Sınırlı katılımcı sayısından dolayı kayıt işlemini hemen yapmanızı öneririz. Etkinlik içeriğine ve kayıt formuna aşağıdaki linkten ulaşabilirsiniz.

Kayıt olmak için tıklayın.​