Hosted Microsoft Yazılımlarında En Sık Yapılan Lisanslama Hataları

Kısaca

Hosted Microsoft yazılımlarında lisanslama hatalarının çoğu ürün bilgisinden değil, deployment modelinin yanlış sınıflandırılmasından çıkar. Aynı Windows Server, RDS veya SQL Server workload'u; on-premises, dedicated hosting, shared Authorized Outsourcer, SPLA veya Authorized Mobility Partner ortamında farklı kullanım haklarına tabi olabilir. Bu nedenle doğru yaklaşım “hangi lisans var?” sorusuyla değil, “workload nerede, kim işletiyor, hangi program altında lisanslanıyor?” sorularıyla başlamaktır.

Hosted Microsoft lisanslamada neden hata yapılır?

Microsoft lisanslama kuralları yalnız ürün adına göre çalışmaz. Aynı yazılım için şu değişkenler sonucu değiştirebilir:

• lisans programı
• Software Assurance veya subscription durumu
• dedicated veya shared altyapı
• provider'ın statüsü
• fiziksel veya sanal deployment
• kullanıcı ve cihaz erişim modeli
• RDS veya SQL Server gibi ek ürünler
• SPLA veya BYOL kullanımı

Bu nedenle tek bir lisans tablosu bütün hosted senaryoları açıklamaz.

Hata 1 — On-prem lisans hakkını cloud'a otomatik taşınabilir sanmak

Bir şirketin elinde geçerli Windows Server veya SQL Server lisansı bulunması, bu lisansın her üçüncü taraf cloud ortamında kullanılabileceği anlamına gelmez.

Kontrol edilmesi gerekenler:

• lisans hangi kanaldan alındı?
• perpetual mı subscription mı?
• Software Assurance aktif mi?
• altyapı dedicated mı shared mı?
• provider Authorized Outsourcer mı?
• ürün License Mobility kapsamına giriyor mu?

Doğru yaklaşım, mevcut lisans envanterini hedef deployment modeliyle eşleştirmektir.

Hata 2 — Windows Server'ı License Mobility ürünü sanmak

Windows Server işletim sistemi klasik License Mobility through Software Assurance kapsamındaki server application ürünlerinden değildir.

Bu hak daha çok SQL Server gibi belirli server application ürünlerinde karşımıza çıkar.

Windows Server tarafında third-party hosting için farklı haklar değerlendirilmelidir:

• outsourcing rights
• Flexible Virtualization Benefit
• subscription veya aktif Software Assurance
• provider'ın Authorized Outsourcer statüsü

Bu kavramların birbirinin yerine kullanılması lisanslama hatasına yol açabilir.

Hata 3 — Shared ve dedicated hosting'i aynı kabul etmek

Dedicated server ile shared cloud aynı lisans koşullarına sahip olmayabilir.

Dedicated altyapıda fiziksel sunucu tek müşteriye ayrılırken shared altyapıda aynı fiziksel kaynak birden fazla müşteriye hizmet verir.

Özellikle müşterinin kendi Windows Server lisansını kullanmak istediği senaryolarda shared ortam için ek subscription veya Software Assurance koşulları gündeme gelebilir.

Bu nedenle BYOL kararı verirken ilk sorulardan biri altyapının shared mı dedicated mı olduğudur.

Hata 4 — Provider'ın SPLA kullandığı ortamda müşteri lisanslarını da aynı kabul etmek

SPLA ve müşteri BYOL hakları iki ayrı lisans kaynağıdır.

Provider SPLA ile Windows Server veya başka bir Microsoft ürünü sağlıyorsa lisanslama provider'ın SPLA sözleşmesi ve aylık raporlaması üzerinden yürür.

Müşterinin kendi Commercial Licensing haklarını kullandığı instance'lar ise ayrı envanterlenmelidir.

Aynı ortamda iki model teknik olarak bulunabilir; ancak hangi workload'un hangi lisans kaynağıyla kapsandığı açık olmalıdır.

Hata 5 — SPLA lisansını müşterinin kalıcı lisansı sanmak

SPLA kapsamında kullanılan lisans provider hizmetinin bir parçasıdır.

Müşteri:

• kalıcı lisans sahibi olmaz
• hizmet sona erdiğinde lisansı yanında götüremez
• provider'ın SPLA kullanım hakkını kendi lisans envanterine ekleyemez

Bu fark teklif ve sözleşme aşamasında açıkça belirtilmelidir.

Hata 6 — CAL ile SAL'i aynı şey sanmak

CAL ve SAL benzer görünse de farklı lisans programlarına aittir.

Commercial Licensing tarafında:

• Windows Server CAL
• RDS CAL

kullanılır.

SPLA tarafında ise belirli ürün ve işlevler için SAL modeli bulunabilir.

Hosted RDS senaryosunda provider SPLA kullanıyorsa RDS SAL, müşteri kendi Commercial Licensing haklarını kullanıyorsa RDS CAL tarafı değerlendirilir.

RDS CAL mı, SAL mı? rehberi bu ayrımı ayrıntılı açıklar.

Hata 7 — RDS'nin Windows Server lisansına dahil olduğunu sanmak

Windows Server işletim sistemi lisansı Remote Desktop Services kullanım hakkını otomatik olarak kapsamaz.

RDS deployment'ında ayrıca erişim lisansları değerlendirilmelidir.

Commercial Licensing modelinde:

• Windows Server CAL
• RDS CAL

gerekebilir.

SPLA modelinde ise ilgili RDS SAL metriği uygulanır.

Bu kalemin teklif dışında bırakılması gerçek maliyetin eksik hesaplanmasına yol açar.

Hata 8 — SQL Server'da edition ile lisans modelini birbirine karıştırmak

SQL Server Standard ve Enterprise yalnız teknik özellik açısından değil, lisans modeli açısından da farklı değerlendirilebilir.

SQL Server 2025 tarafında:

• Enterprise → Per Core
• Standard → Per Core veya Server + CAL

Commercial Licensing seçenekleri bulunur.

SPLA tarafında ise ürün listesi ayrıca kontrol edilmelidir.

Edition kararı ve lisans metriği iki ayrı karardır.

SQL Server Standard vs Enterprise rehberi bu ayrımı detaylandırır.

Hata 9 — SQL Server License Mobility sürecini eksik uygulamak

SQL Server uygun Software Assurance ile License Mobility through Software Assurance kapsamında Authorized Mobility Partner ortamına taşınabilir.

Ancak yalnız teknik migration yapmak yeterli değildir.

Microsoft License Verification süreci de tamamlanmalıdır.

Microsoft guidance'a göre deployment sonrasında belirlenen süre içinde License Verification Form ile doğrulama yapılması gerekir.

Bu idari adımın atlanması teknik olarak çalışan bir workload'u lisanslama açısından eksik bırakabilir.

Hata 10 — Flexible Virtualization Benefit ile License Mobility'yi aynı sanmak

Bu iki hak birbirinden farklıdır.

License Mobility through Software Assurance belirli server application ürünleri için kullanılabilir.

Flexible Virtualization Benefit ise uygun subscription veya aktif Software Assurance bulunan lisansların Authorized Outsourcer altyapısında daha esnek kullanılmasını sağlayan ayrı bir haktır.

Ürün ve provider bazında hangisinin uygulanabileceği ayrıca kontrol edilmelidir.

Hata 11 — Eski perpetual CAL'lerin shared outsourcing için yeterli olduğunu varsaymak

Shared Authorized Outsourcer senaryolarında Windows Server erişimi için yalnız mevcut eski CAL envanterine güvenmek doğru olmayabilir.

Flexible Virtualization Benefit kapsamında erişen kullanıcı veya cihazların uygun subscription CAL ya da aktif Software Assurance bulunan CAL'lere sahip olması gerekebilir.

Dedicated outsourcing senaryoları ayrı değerlendirilmelidir.

Hata 12 — Windows Server Standard sanallaştırma haklarını yanlış saymak

Windows Server Standard fiziksel core bazlı lisanslamada her tam core lisans seti için belirli sayıda OSE hakkı sağlar.

Ek VM'ler için aynı fiziksel core setinin tekrar lisanslanması gerekebilir.

Bu stacking mantığı hesaba katılmadığında Standard ilk bakışta daha ucuz görünürken toplam maliyet hızla artabilir.

Windows Server Standard vs Datacenter rehberi bu hesabı örneklerle açıklar.

Hata 13 — VM bazlı Windows Server lisanslamayı herkese açık sanmak

VM bazlı Windows Server lisanslama için uygun subscription veya aktif Software Assurance şartları bulunabilir.

Perpetual lisansın tek başına VM bazlı kullanım hakkı sağladığını varsaymak doğru değildir.

Bu nedenle önce lisans hakkı, sonra vCore hesabı yapılmalıdır.

Hata 14 — SQL Server DR ve passive failover haklarını otomatik varsaymak

SQL Server disaster recovery ve passive failover kullanım hakları lisans programı, Software Assurance/subscription ve deployment yapısına bağlı olabilir.

Bir secondary instance'ın “pasif” olması onu otomatik olarak lisanssız çalıştırılabilir hale getirmez.

Gerçek kullanım rolü ve güncel SQL Server licensing guidance kontrol edilmelidir.

Hata 15 — Eski Microsoft lisanslama bloglarını güncel kural sanmak

Microsoft ürün hakları ve licensing programları zaman içinde değişebilir.

Örneğin:

• edition özellikleri değişebilir
• Software Assurance hakları güncellenebilir
• Flexible Virtualization Benefit gibi yeni haklar eklenebilir
• SPLA ürün metrikleri değişebilir

Bu nedenle eski bir blog yazısının doğru olması bugün de doğru olduğu anlamına gelmez.

Kaynak önceliği şu olmalıdır:

1. Microsoft Product Terms
2. Microsoft Licensing Guidance
3. SPLA için güncel SPUR
4. sözleşme ve reseller/provider doğrulaması

Hata 16 — Lisans sayısını teknik envanterden bağımsız hesaplamak

Lisans hesabı ancak teknik envanter doğruysa doğrudur.

En az şu veriler çıkarılmalıdır:

• fiziksel host sayısı
• fiziksel core
• VM sayısı
• vCore
• edition
• kullanıcı ve cihaz sayısı
• RDS kullanımı
• SQL Server instance'ları
• HA/DR topolojisi
• shared/dedicated altyapı
• Software Assurance/subscription durumu

Eksik envanter, doğru formülle bile yanlış sonuç üretir.

Hata 17 — Kullanıcı sayısını sadece eşzamanlı oturum sayısı olarak almak

CAL veya SAL modelleri çoğu senaryoda yalnız concurrent user sayısına dayanmaz.

Önemli olan ilgili lisans metriğinde kimlerin veya hangi cihazların erişim yetkisine sahip olduğudur.

Özellikle RDS ortamlarında concurrent session sayısını lisans sayısı olarak kullanmak hatalı olabilir.

Hata 18 — Lisanslama ile teknik aktivasyonu aynı şey sanmak

Bir Windows Server veya SQL Server kurulumu teknik olarak aktive olmuş olabilir.

Bu, deployment'ın lisans kurallarına uygun olduğu anlamına gelmez.

Activation:

• ürünün teknik olarak çalışmasını sağlar

Licensing:

• kullanım hakkının sözleşmeye uygunluğunu belirler

Bu iki kavram ayrı değerlendirilmelidir.

Hata 19 — Provider sözleşmesinde lisans kapsamını yazmamak

Hosted hizmet teklifinde şu maddeler açık olmalıdır:

• hangi Microsoft ürünleri dahil
• hangi edition kullanılıyor
• SPLA mı BYOL mı
• RDS dahil mi
• SQL Server dahil mi
• ek kullanıcı veya core maliyeti nasıl hesaplanıyor
• migration sonrası lisans sorumluluğu kimde

Bu bilgiler yoksa iki hizmet teklifini fiyat açısından karşılaştırmak yanıltıcı olabilir.

Hata 20 — Compliance'i yalnız denetim riski olarak görmek

Lisans uyumluluğunun amacı yalnız audit riskini azaltmak değildir.

Doğru lisans modeli aynı zamanda:

• gereksiz lisans harcamasını azaltabilir
• büyüme maliyetini öngörülebilir hale getirebilir
• migration sürecini kolaylaştırabilir
• provider değişimini sadeleştirebilir
• operasyonel sorumlulukları netleştirebilir

Bu nedenle lisanslama, satın alma sonunda kontrol edilen bir kalem değil, altyapı tasarımının parçası olmalıdır.

Hosted Microsoft lisanslama kontrol listesi

Yeni bir deployment veya migration öncesinde şu listeyi kullanabilirsiniz:

Ürün

• Hangi Microsoft ürünleri çalışacak?
• Hangi version ve edition?

Lisans kaynağı

• Provider SPLA mı sağlıyor?
• Müşteri BYOL mı kullanacak?

Altyapı

• Dedicated mı shared mı?
• Provider Authorized Outsourcer mı?
• Authorized Mobility Partner gerekiyor mu?

Lisans hakları

• Software Assurance aktif mi?
• Subscription lisansı var mı?
• License Mobility uygulanıyor mu?
• Flexible Virtualization Benefit uygulanıyor mu?

Erişim

• Kaç kullanıcı veya cihaz?
• RDS kullanılıyor mu?
• CAL veya SAL gerekiyor mu?

SQL Server

• Standard mı Enterprise mı?
• Per Core mu Server + CAL mı?
• DR/passive failover yapısı nedir?

Raporlama

• SPLA aylık kullanım kim tarafından raporlanacak?
• BYOL envanteri kim tarafından tutulacak?

Dynamis'te lisanslama kontrolünü nasıl yapıyoruz?

Dynamis'te lisans kontrolüne ürün listesinden değil deployment mimarisinden başlıyoruz.

Önce:

• mevcut lisans sözleşmeleri
• workload'lar
• core ve VM yapısı
• kullanıcı erişimi
• RDS ve SQL Server
• hosting modeli
• provider statüsü
• Software Assurance/subscription hakları

çıkarılır.

Ardından her ürün için uygun Microsoft kullanım hakkı kontrol edilir.

Amaç mümkün olduğunca çok lisans satmak değil; eksik lisans kadar gereksiz lisanslamayı da önlemektir.

Sırada ne var

• Hosted Windows Server lisanslama: SPLA ve BYOL modellerini karşılaştırın.
• SPLA SAL ve Core lisanslama: SPLA metriklerini anlayın.
• Microsoft SPLA nedir?: provider lisanslama modelini inceleyin.
• SQL Server Standard vs Enterprise: SQL Server edition ve lisans modelini değerlendirin.
• Lisanslama hizmetini inceleyin: mevcut yapınız için lisans kontrolü yapın.

Kaynaklar

• Microsoft Product Terms
• Microsoft Licensing Guidance
• Microsoft Services Provider Use Rights (SPUR)
• Microsoft License Mobility through Software Assurance guidance