Organizasyon yapısı, kullanıcı sayısı fark etmeksizin irili ufaklı bütün şirketlerde hem yazılı bir kanıt hem de resmi olarak da somut delil niteliği taşıdığı için mail uygulamaları çok yoğun bir şekilde kullanılmaktadır. Mail sistemi bu kadar önemli olunca da günlük mail alış-verişimizde ciddi boyutlara ulaşabilmektedir. Peki, gün içerisinde gelen yüzlerce maili nasıl Önemli-Önemsiz diye ayırabiliriz ya da Mail kuralları bu durum için ne kadar yeterlidir.

Office 365 bizler için bu konuda ciddi bir kolaylık sunmaktadır. Office 365 Clutter özelliği ile birlikte arka planda “Office Graph”  teknolojisini kullanarak akıllı bir içerik filtreleme yapmaktadır yani gelen maillerin hangisi Önemli hangisi Önemsiz sizin için sizin kendi alışkanlıklarınızdan bakarak karar vermektedir. Burada önemli olan nokta şu, programın ilk zamanlar vereceği kararlar çok doğru olmayabilir ama sizi tanıdıkça yani siz servisi kullandıkça daha isabetli kararlar verebilmektedir.

Clutter özelliğini Anti Spam filtreye benzetebiliriz, az önemli ya da sizler için sıradan olan mailleri Clutter isimli bir klasör oluşturarak içerisine taşır aynı zamanda kullanıcı kendisi de manuel olarak gelen mailleri bu klasöre taşıyabilmektedir.

Aşağıdaki 3 grup gönderici için Clutter aksiyon almayacaktır,

-        Eğer gönderici siz iseniz,

-        Yöneticilerinizden gönderilen mailler,

-        Size Doğrudan rapor verenler (Astlarınız),

Bir mailin Clutter olarak belirlenmesi için aşağıdaki kriterlere bakılmaktadır,

-        Gönderici bilgisi,

-        Mail içerisindeki Alıcı sayısı, eğer siz tek alıcı iseniz gelen mailin Clutter klasörüne düşme ihtimali yüksektir,

-        Mail önemlilik durumu,

-        Sizin aynı “Kişi” yada “Konu” dan gelen önceki mailleri okuyup-okumamanız,

Clutter özelliği varsayılan olarak kapalı gelmektedir, Şimdilik (umarım en kısa sürede Exchange Portaldan da bu özelliği merkezi olarak yönetebileceğiz) bu özelliği organizasyon bazlı tanımlayamıyoruz, Clutter özelliğini kullanmak isteyen her kullanıcı Owa ekranına (Webmail) girerek devreye alabilmektedir ve ne zaman istenirse de devreden çıkartılabilmektedir. Outlook programından bu özellik aktif edilememektedir ama kullanılabilmektedir, öncelikle Owa ekranından aktif edilmesi gerekmektedir.

Eğer Outlook programında tanımlanmış kurallar var ise kurallardaki mailler için herhangi bir müdahale yapmamaktadır yani çakışma durumunda Mail kuralı baskın durumdadır.

Peki, Clutter özelliği nasıl aktif ediliyor, bu özelliği açmadan önce Owa ekranımız aşağıdaki gibi görünmektedir,

Özelliği açmak için Owa ekranında sağ üstteki Ayarlar kısmından Options’ a girelim,

Seçenekler ekranına girdikten sonra ekranın sol kısmında Clutter seçeneği görülecektir ve varsayılan olarak kapalı geldiğini söylemiştik, Separate items identified as clutter seçeneğini seçerek, sonrasında da Save butonuna tıklayarak özelliği aktif yapıyoruz,

Özelliği aktif ettikten sonra tekrar Mail ekranımızda döndüğümüzde (birkaç kez sayfayı yenilemek gerekebilir) aşağıdaki gibi sol tarafta Inbox altında Clutter isimli bir klasör görülecektir.

Clutter özelliği aktif edildikten sonra sizin alışkanlıklarınızı öğrenmesi için birkaç gün ya da hafta geçmesi gerekmektedir ama siz de bu sürece yardımcı olabilmek için gelen maillerden istediğinize sağ tıklayarak da Clutter klasörüne taşıma yapabilirsiniz,

Clutter klasörüne taşınmış mailler için herhangi bir silme işlemi uygulanmamaktadır, siz istediğiniz kadar mailler bu klasörde kalabilir ve istenildiğinde mailler tekrar diğer klasörlere taşınabilmektedir.

Umarım faydalı olmuştur,

SharePoint geliştirme seçenekleri arasında yer alan Event Receiver konusuna daha önce ufakta olsa bir girişte bulunmuştum. Bu yazımızda daha geniş kapsamlı olarak Event Receiver içerisinde bulunan Tiplere, sınıflara ve diğer özelliklere göz atacağız.

Bu yazımızda;

1)      SharePoint Event Receiver Tiplerine

2)      Event Receiver Sınıflarına

a)      Site Seviyesi Olaylarına

b)      List Seviyesi Olaylarına

c)       İtem Seviyesi Olaylarına

d)      Feature Eventlere

e)      Email Olaylarına

Konularına değineceğiz

1 - SharePoint Event Receiver Tipleri

Temel olarak basit bağlamda iki tip Event Receiver bulunmaktadır. Bunlar Senkron ve Asenkrondur. Senkron Event Receiver olaylardan “Önce” çalışan olarak bilinmektedir. Bunlar bir olay gerçekleşmeden önce bazı eylemleri gerçekleştirmek için kullanılırlar. Koşul yerine gelmediğinde iptal edilebilirler.

Asenkron Event Receiver ise olaylardan “ Sonra” çalışan olarak bilinmektedir. Olay gerçekleştirildikten sonra herhangi bir özel eylemi gerçekleştirmek için kullanılır. Asenkron olduğundan olayın hemen ardından gerçekleşmesi gerekmez.

2 - Event Receiever Sınıfları

SharePoint 2007 ile beraber Olay algılayıcılarına 5 (beş) adet sınıf dâhil edilmiştir ve temelde bu sınıflar üzerinden olay algılayıcıları ilerlemektedir. Bunlar;

Microsoft.SharePoint.SPEmailEventReceiver

E-Posta özelliği etkin edilmiş bir liste üzerinde kullanıcının o liste üzerinde dönen olayları e-posta ile yakalamasını sağlar.

Microsoft.SharePoint.SPFeatureReceiver

SharePoint özellikleri üzerindeki olayları algılamak için kullanılır.

Microsoft.SharePoint.SPItemEventReceiver

Bir liste öğesi üzerinde olan olayları algılamak için kullanılan sınıftır. Liste öğesi üzerinde oluşan tüm olaylar bu sınıf ile kontrol edilir.

Microsoft.SharePoint.SPListEventReceiver

Bir liste üzerinde liste tanımı düzenleme, mevcut sütünları değiştirme, sütün silme gibi işlemler olduğunda SPListEventReceiver sınfı ile kontrol edilir veya algılanır.

Microsoft.SharePoint.SPWebEventReceiver

Bir site koleksiyonu silinmesi, taşınması veya bu site koleksiyonu ile ilgili herhangi bir değişim işlemi yapıldığını algılayan sınıftır.

Bu sınıfların her birisi için kullanılabilecek methodlar bulunmaktadır. Aşağıda bu methodlara dair bilgilerde sunmaya çalışacağım.

A– Site Seviyesi Event Receiver

SPWebEventReceiver’in site seviyesinde işlemlerini algılamak için kullanılan yöntemler aşağıda bulunmaktadır.

·         Site Deleted

Site silme işleminden önce oluşan olay algılama methodudur.

·         SiteDeleting

Site silme işleminden sonra oluşan olay algılama methodudur.

·         Web Deleted

Bir web sitesi tamamen silindikten sonra oluşur. (Asenkron bir işlemdir)

·         Web Deleting

Bir Web sitesini silmeden önce oluşur. Senkron bir işlemdir.

·         Web Moved

Mevcut varolan bvir web sitesi taşındıktan sonra oluşan işlemdir. Asenkron bir işlemdir.

·         Web Moving

Mevcut web sitesini taşımandan önce oluşan işlem / olaydır. Senkron bir işlemdir.

B – List Seviyesi Event Receiver

·         Field Added

Bir Field Listeye eklendikten sonra oluşan algılayıcı methodudur.

·         Field Adding

Bir Field İçerik tipine eklendiğinde ( Content Type) çalışır.

·         Field Deleted

Field Listeden silindiğinde oluşur.

·         Field Deleting

Bir field listeden silinmesi başlangıcında oluşur.

·         Field Updated

Bir Field’in listede güncellenmesinden sonra oluşur.

·         Field Updating

Bir field’in listede güncellenmesine başlandığında oluşur.

C –Item Seviyesi Event Receiver

·         ItemAdded

Listeye yeni bir item eklendiğinde oluşur ve asenkrondur.

·         ItemAdding

Listeye bir öğe eklenmeden önce oluşur. Senkrondur.

·         ItemAttachmentAdded

Bir liste öğesine ek ekledikten sonra oluşur. Asenkron bir olaydır.

·         ItemAttachmentAdding

Bir liste öğesine ek eklenme anında oluşur.

·         ItemAttachmentDeleted

Liste öğesindeki ek kaldırıldıktan sonra oluşan olaydır.

·         ItemAttachmentDeleting

Liste öğesinden ekin silinme esnasında oluşan olaydır.

·         ItemCheckedIn

Öğe kontrol edildikten sonra kullanılır.

·         ItemCheckedOut

Öğe sunucuya teslim edildildikten sonra kullanılan olaydır.

·         ItemCheckingIn

Öğenin listeye teslim edilme(kontrol) anında oluşur.

·         ItemCheckingOut

Bir öğe teslim edilirken oluşur.

·         ItemDeleted

Öğe listeden silindikten sonra oluşur.

·         ItemDeleting

Öğe listeden silinirken oluşur.

·         ItemFileConverted

Bir dosya türünün değiştiğinde oluşan olaydır.

·         ItemFileMoved

Dosyanın taşıma işlemi sonrası çalışan olaydır.

·         ItemFileMoving

Dosyanın taşınma işlemi sırasında oluşur.

·         ItemUncheckedOut

Bir öğenin kontrol iptali gerçekleştikten sonra oluşur.

·         ItemUncheckingOut

Bir öğenin kontrolünün iptal edilmesi sırasında oluşan olaydır.

·         ItemUpdated

Öğe Güncellendikten sonra oluşur.

·         ItemUpdating

Öğe güncellenmesi sırasında oluşur.

D – Feature Event

·         FeatureActivated

Özelliğin aktif edildikten sonra oluşur.

·         FeatureDeactivating

Bir özellik devre dışı bırakılırken oluşur.

·         FeatureInstalled

Bir özellik yüklendikten sonra oluşur.

·         FeatureUninstalling

Bir özellik kaldırılırken ( uninstall) oluşur.

E – E-Posta Olayları

EmailReceived, Bir e-posta mesajı e-posta özelliği etkileştirilmiş bir listeye geldikten sonra EmailReceived olayı oluşur.

Yukarıdaki kısaca özetlemelerinden ve ne işe yaradıklarından bahsetmiş olduğumuz method ve sınıflar Visual Studio ile geliştirme yapan ve Olay algılayıcıları içerisinde gördükleri methodların ne anlama geldikleri konusunda sıkıntı çeken arkadaşlarımıza kolay referans olması açısından SharePoint kaynakları arasından sadeleştirilmiştir.

Event Receiver methodları SharePoint versiyonları arasında farklılık gösterebilir. Yukarıda anlatılan Method ve Sınıflar SharePoint 2007 den beri gelen temel method ve sınıflardır.

Umarım tüm SharePoint geliştiricisi arkadaşlarımıza ya da SharePoint geliştiricisi olmak isteyen arkadaşlarımıza faydalı olur.

IMC yazılımında neler yapabiliriz işimize en çok ne yarar nelerden faydalanabiliriz bölümler halinde anlatmaya çalışacağım.

IMC yazılımının nasıl kurulduğunu sizler ile portal üzerinden paylaşmıştım. İsterseniz aşağıdaki link üzerinden bu makaleme ulaşabilirsiniz.

http://www.cozumpark.com/blogs/hewlett-packard/archive/2013/06/09/hp-network-imc-yazilimi-kurulumu-ve-network-analizi.aspx

Bu bölümde

1-Yazılım üzerine switch nasıl eklenir eklenmesi için neler yapılmalıdır

2-Switch üzerinde vlan nasıl oluşur

3-Oluşan vlan’a nasıl ip verilir

4-Belirli portlar vlan için nasıl access ve trunk yapılır

5-Yapılan ayarların yedekleri nasıl alınır ve görüntülenir

Konularını anlatmaya çalışacağım.

Öncelikle switch eklemesi yaparak başlayalım.

Web tarayıcısı üzerine öncelikle IMC ip adresimizi yazıyoruz ve port olarak 800 portunu ekliyoruz.

Sonrasında karşımıza aşağıdaki gibi ip ekran gelmektedir IMC yazılımın Default de gelen kullanıcı adı admin şifresi admin şeklinde gelmektedir.

Login işleminden sonra IMC yazılımın üst menüleri aşağıdaki gibidir.

Switch ekleme işlemi aşağıdaki ekran görüldüğü üzere menüleri takip ederek Add Device menüsüne tıklıyoruz.

Daha sonra karşımıza aşağıdaki gibi ekran gelmektedir.

Yukarıdaki ekranda sorulan bilgileri doldurmadan önce switch üzerinde SNMP ayarları ve telnet ayarları kontrol edilmelidir.

Öncelikle IMC makinesini host olarak eklememiz gerekecek

Yukarıda görüldüğü gibi SNMP host olarak IMC makinesini ekledik Community olarakta Default da gelen public key ’ini yazdık.

Aynı şekilde yukarıdaki komutu da yürütüyoruz. Ben şuanda snmpv2 kullandım isteyen kullanıcılar Snmpv3 te kullanabilirler.

Aşağıdaki ekranda switch ip adresi ve maskını yazıyoruz.

Daha sonra switch’e vermiş olduğumuz SNMP bilgilerini bu kısma yazıyoruz.

Daha sonra switch’in telnet kullanıcı adı ve şifresini ekliyoruz. Bu kısımda da SSH bağlantısında kullanabilir. Ben telnet olarak devam ediyorum bu işlemlerden sonra

Alt kısımda bulunan ok menüsüne tıklayarak ekleme işlemini gerçekleştiriyoruz. Ekle işleminden sonra cihazın yazılım üzerinde gelip gelmediğini kontrol etmemiz gerekmektedir. Bu işlem aşağıdaki menüler takip edilerek kontrol edilebilir.

Yukarıda görüldüğü üzere cihaz listesini açıyoruz.

 Yukarıda görüldüğü üzere eklenen switchlerin listesi bulunmaktadır bu liste üzerinde cihazların ip adreslerini modellerini switch isimlerini görmeniz mümkündür.

Kısaca değinmek isterim Bu device listesi network topoloji olarakta görülebilir. Bunu da aşağıdaki menüler takip edilerek yapılabilir.

Açılan ekrandan My Network View diyerek devam edelim.

Görüldüğü üzere switchler network üzerinde görüntülenmekte buradan kısaca bahsetmek istedim 3 ya da 4 bölümde tüm menüler bittikten sonra daha ayrıntılı anlatıyor olacağım.

 Devam edelim kaldığımız yerden Aşağıdaki menüleri de kullanmanız mümkündür.

Küçük bir örnek verecek olursak aşağıdaki gibi ilgili switch’in web ara yüzünü açmanız mümkün. İlgili menüler kullanılarak ping, traceroute, telnet, ssh gibi işlemleri de bu kısım üzerinden yapmanız mümkündür.

Artık switch üzerinde çalışma başlayalım bunun için öncelikle switch içine girmemiz gerekecek Device label yazan kısımdaki isim üzerine tıklayarak giriş yapıyoruz.

Karsımıza aşağıdaki gibi ekran gelmektedir.

Yukarıdaki ekran üzerinde switch üzerinde dilediğiniz her şeyi yapmanız mümkün.

Ben bu bölümde yapacağım işlemleri yazayım.

1-Vlan oluşturma

2-Vlan’a ip adresi verme

3-Portları ilgili vlan’a atama

4–Yapılan işlerin yedeğini alma

Öncelikle cihaz üzerinde kendimize özgü bir vlan yaratalım.

Sol menüde bulunan VLAN Management menüsü altında device vlan menüsüne giriyoruz.

Aşağıdaki ekranda görüldüğü üzere cihaz üzerinde şuanda aktif olarak çalışan vlanları görmekteyiz.

Yeni bir vlan eklemesi yapalım

Ekran da Add Menüsüne tıklayarak devam ediyoruz ve karşımıza aşağıdaki gibi ekran gelmektedir.

Yukarıda görüldüğü üzere vlan ID Vlan Name kısımlarını yazarak OK diyoruz.

Yukarıda Eklemiş olduğumuz vlan ’nın geldiğini görmekteyiz. Vlan oluşturduğumuza göre artık vlan’a ip adresi verebiliriz. İp verme işlemi Vlan interface kısmından yapılmaktadır.

Menüleri takip ederek .

Add dedikten sonra karşımıza aşağıdaki gibi ekran gelmektedir bu kısımda ilgili ip adresi yazılarak devam edebilirsiniz.

Aşağıdaki gibi ipler yazılarak OK denir.

Verdiğimiz ip adresinin geldiği görüyoruz.

Vlan oluşturduk ilgili vlan’a ip adresi verdik artık bu Van’ı belirli portlara üye etme zamanı geldi.

Bu işlemi Access Port kısımdan yapıyoruz. Aşağıda görüldüğü üzere portların hangi vlan da access olduğu görülmektedir

Ben 18 nolu portu vlan 1000 grubuna üye edeceğim

Aşağıda görüldüğü üzere sol menüde bulunan modify bölümüne giriyoruz.

Aşağıda görüldüğü üzere ilgili 18 nolu port için vlan 1000 access olarak seçtik.

Aynı menü kullanılarak ilgili port Trunk olarak seçilebilir.

Yukarıda görüldüğü üzere port trunk olarakta konfigüre edebildik.

Bu işlemlerin sonunda artık yaptığımız ayarların yediğini zamanlı ya da manuel olarak almak kaldı.

Backup almak için aşağıdaki menüleri takip ediniz.

 Karşınıza network üzerinde bulunan switchler gelecektir.

Yukarıda görüldüğü üzere yedek alınacak olan switch seçilir ve üst menüde bulunan Backup Configuration tıklanır.

Backup alma işlemi yukarıdaki gibi başlar ve devam eder

Yukarıda görüldüğü üzere alınan yedeğin başarılı olduğu görülür.

Alınan yedekler aşağıdaki menüler kullanılarak görüntülenebilir.

Aşağıda görüldüğü üzere yedekler alınmış durumdadır.

Bu bölümde makalemizin sonuna geldik umarım yararlı olmuştur.

Service Manager ın en güzel özelliklerinden birisi de diğer Microsoft ürünleri ile rahatlıkla bağlantı kurabilmesi ve buradan CMDB (Configuration Management Database) içerisine verileri aktarabilmesidir. Service Manager veri aktarma işlemlerini oluşturulan connector ler vasıtasıyla yapmaktadır. Bu makalemde sizlere Service Manager üzerinde Active Directory Connector oluşturulmasını anlatamaya çalışacağım.

Öncelikle Service Manager konsolu üzerinde Administration bölümüne gelelim ve buradan Connectors seçeneğine tıklayalım. Sağ tarafta bulunan Tasks bölümünden Create Connector seçeneğine tıklayıp açılan menüden Active Directory connectorü seçelim.

Açılan karşılama ekranını Next diyerek geçelim ve General bölümünde connector için bir isim belirleyelim. Aynı zamanda alt bölümde bulunan Enable Connector seçeneğinin de işaretli olduğundan emin olalım. Ben isim olarak Active Directory Users Connector olarak belirledim. Bunda ki amacım sadece belirli bir OU da bulunan ve yine sadece etkin kullanıcı hesaplarını aktarmaktır. Bunun sebebini makalenin ilerleyen kısmında açıklayacağım.

Next diyerek ilerlediğimizde karşımıza connector ün Active Directory üzerinde bulunan nesnelerin hangilerinin alınacağını belirlediğimiz ekran gelecektir. Server Information bölümünde eğer Use the domain mhclabs.com u seçersek senkronizasyonun domain nin root undan yapılacağı anlamına gelir. Ancak bu genelde tavsiye ettiğim bir durum değildir. Örneğin hesaplarını devre dışı bıraktığınız kullanıcıları AyrılanKullanıcılar isimli bir OU da saklıyorsanız ve ilk seçeneği seçtiyseniz tüm devre dışı olan kullanıcı hesap bilgileri de CMDB ye aktarılacaktı ki biz bunu istemiyoruz. Dolayısıyla senkronizasyonun belirli bir OU dan yapılmasını sağlamak amacıyla Let me choose the domain or OU seçeneğini seçiyoruz ve Browse a tıklayarak hangi OU içerisinden aktarma yapacağımızı belirliyoruz.

Not:İmport etme işlemine eğer var ise Active Directory içerisinde bulunan Contact hesapları da dahildir.

Not: Active Directory de bulunan gruplar CMDB ye aktarılırken grup üyeleri alınmaz.

Not: Eğer ortamınızda SCCM var ise bilgisayar hesaplarını CMDB ye akmanız gerekmeyecektir. Çünkü etki alanı ortamında ki bilgisayar bilgileri (marka bilgileri, model numaraları, işletim sistemi bilgileri, donanım bilgileri, üzerinde ki yazılım bilgileri) çok daha detaylı şekilde Sccm Connector vasıtasıyla CMDB ye aktarılabilmektedir. Eğer Active Directory connector ile bilgisayar hesapları CMDB ye aktarıldı ise SCCM Connector SCCM den çekilen verileri ve Active Directory Connector den çekilen verileri birleştirecektir.

Not: Sadece hesapları etkin olan kullanıcıların bilgilerini CMDB ye aktarmak için bir diğer yöntem de LDAP query si ile işlemi gerçekleştirmektir. LDAP Query hazırlamak için Active Directory Users and Computers konsolunda bulunan Saved Queries bölümü kullanılabilir.

Credentials bölümünde de Run as account oluşturmak için New e tıklayalım ve karşımıza gelen ekranda Active Directory üzerinde okuma yetkisi olan bir kullanıcıyı seçerek Run As Account u oluşturalım. Oluşturduğumuz kullanıcıyı Test Connection a tıklayarak da test etmeyi ihmal etmeyelim.

Next diyerek ilerlediğimizde karşımıza sisteme eklenecek olan kullanıcı, grup ve bilgisayar seçimini yapabileceğimiz ekran gelecektir. Burada üç farklı seçenek bizlere sunulmaktadır. Bunlar,

·        All computers, printers, users and user groups: Bu seçenek ile bir önceki ekranda belirlediğimiz alanda (tüm domain ya da belirli bir ou) bulunan tüm kullanıcı, grup, bilgisayar ve yazıcı bilgileri çekilecektir.

·        Select individual computers, printers, users or user groups: Bu seçenek ile çekilecek olan kullanıcı, grup, bilgisayar ya da yazıcıları tek tek belirleyebiliriz.

·        Provide LDAP query filters for computers, printers, users or user groups: Bu seçenek ile bilgisayar, yazıcı, kullanıcı ya da grupların belirtilecek LDAP sorgularına göre çekilmesini sağlayabiliriz.

·        Biz daha önceden belirlemiş olduğumuz OU içerisinde ki tüm kullanıcıların sisteme eklenmesini sağlamak için ilk seçenek olan All computers, printers, users and user groups seçeneğini seçiyoruz. Alt bölümde iki seçenek daha dikkatinizi çekecektir. Bunlar,

·        Automatically add users AD Groups imported by this connector: Eğer Active Directory içerisinde oluşturmuş olduğumuz bir Security Grubu Service Manager içerisinde ki bir User Role ile eşleştirmeyi düşünüyor isek bu seçeneği seçebiliriz. Böylece AD içerisinde ilgili Security grubuna üye olan kullanıcılar otomatik olarak Service Manager içerisinde grubun atanmış olduğu User Role e sahip olurlar.

·        Do not write null values for properties that are not set in Active Directory: Bu seçenek ile Active Directory den import edilen objelerin boş olan attribute ları için CMDB tarafında NULL verisi yazılmayacaktır.

Not: Buraya kadar olan bölümde yapılan düzenlemeler connector oluşturulduktan sonra değiştirilemeyecektir.

Next diyerek ilerleyelim ve son olarak da Create e tıklayarak connector ü oluşturalım. Oluşturduğumuz connector ü çalıştırmak için connector seçili iken Tasks bölümünden Synchronize Now linkine tıklamamız yeterli olacaktır.

Senkronizasyon işlemi tamamlandığında Active Directory den aktarılan kullanıcıları Service Manager konsolunda Configruation Itemsà Users bölümünde görebiliriz.

Not: Eğer oluşturulan bir Active Directory Connector silinir ise bu connector ile import edilmiş olan tüm verilerde silinecektir.

Bu makalemde sizlere Service Manager üzerinde Active Directory Connector oluşturulmasını anlatamaya çalıştım.

Faydalı olması dileğiyle…

Yammer, Organizasyonunuzdaki çalışanların her zaman, her yerden Web tarayıcı ve Mobile cihazlar üzerinden kendi aralarında hızlı bir iletişim kurmalarını sağlayan ve aynı zamanda tek merkezden içerik ve business data paylaşımı özelliği bulunan Kurumsal sosyal ağdır. Yammer ile ağınızdaki çalışanlarınıza ve bilgiye çok kolay bir şekilde erişebilir, takım üyeleriyle iş birliği yaparak yüksek verim elde edebilirsiniz.  Şuanda tüm dünyada 200,000 ‘ den fazla şirket Yammer kullanmaktadır ve diğer iş uygulamalarıyla kolay bir şekilde entegrasyon yapılabilmektedir. Yammer’ daki bilgiler ve iletişimler sadece şirket içerisinde görülebilmektedir ve şirket dışından hiçbir şekilde görülememektedir.

Yammer, 2008 yılında kurulmuş ve 2012 yılında Microsoft tarafından satın alınarak Office 365 içerisine entegre edilmiştir ama henüz Office 365’ le tam olarak türleştirilmemiştir. Yammer hizmetini Office 365 portal sayfasından başlattığımızda, bizi yammer.com sitesine yönlendirmektedir.

Sadece Standalone Yammer lisansı alıp kullanabileceğiniz gibi eğer Office 365 içerisinde aşağıdaki Lisans paketlerine sahipseniz Yammer’ ı çok kolay bir şekilde aktif ederek kullanabilirsiniz.

Peki, nasıl yapılandırılır ve nasıl kullanılır inceleyelim,

Varsayılan olarak Yammer hizmeti kapalı gelmektedir, Aşağıdaki ekranda standart E3 lisansına sahip admin paneli bulunmakta ve Yammer uygulaması görünmemektedir.

Uygulamayı devreye almak için önce Dashboard, sonrada Included Services yazısına tıklayalım, sonrasında ekranın sağ tarafında Yes, activate Yammer Enterprise for my network  ‘ e tıklayalım.

Office 365 içerisinde daha önceden tanımladığım ve doğrulatma işlemi tamamlanmış ismailkizilirmak.com domainim için Yammer hizmetini aktif edileceği belirtiliyor, eğer domain tanımınız yoksa Yammer kullanamıyoruz. Activate Yammer Enterprise butonunu seçerek ilerliyoruz.

Kısa bir beklemeden sonra Aktif edildiğine dair mesajı görüyoruz,

Office 365 portaldan baktığımızda artık Yammer’ ı da görebiliyoruz, tıkladığımızda bizi https://www.yammer.com/ismailkizilirmak.com/ adresine yönlendiriyor, Yammer kullanmak için Office 365 portala da giriş yapmak zorunda değiliz,

Yammer’ a giriş yapacak kullanıcımızın mail adresini yazıyoruz ve Sign up butonuna tıklıyoruz,

Sing up butonuna tıkladıktan sonra mail adresimize doğrulama linki gelecektir, linke tıkladıktan sonra kişisel bilgilerimizi girmemiz gerekecektir,

Bu ekranda kimlerle çalıştığımız, takım arkadaşlarımız varsa bunları yazabiliriz, bu bilgiler ilerisi için İçerik ve Data paylaşımında kolaylıklar sunacaktır, boş bırakarak da ilerleyebilirsiniz,

Varsayılan olarak her Yammer kullanıcısı All Company grubuna üyedir, isterseniz diğer gruplara da kullanıcı ekleyebilirsiniz,

Profilinize resim de ekleyebilirsiniz,

Son olarak Yammer görüntüsü aşağıdaki gibi ve aynı ekranda maillerimizi de görebilmekteyiz, gayet kolay ve anlaşılabilir bir ekrandır, Yammer kullanıcıları kendi aralarında anlık mesajlaşmada yapabilir ve gelen mesajların anlık olarak sizi haberdar etmesi için Yammer Notifier kurabilirsiniz (https://about.yammer.com/product/desktop-application/ ).

Umarım faydalı olmuştur.

App Model, belki de SharePoint 2013 ile birlikte gelen en majör ve ilginç değişikliklerden birisidir. Bu yazı dizisinde SharePoint 2013 App modeli detaylıca anlatmayı planlıyoruz.

SharePoint 2013 App model ile uygulama geliştiriciler bir çok yenilikler ve esneklikler kazanmıştır. Bunlara başlamadan önce  dünden bugüne devam eden uygulama geliştirme yöntemlerini ve bunların avantaj ve dezavantajlarından söz edelim.

SharePoint Farm Solution

SharePoint  Farm Solutionlar, uygulama geliştiricilere SharePoint üzerinde  geliştirecekleri uygulama için güçlü bir yöntem sunar. Fakat bununla beraber yapılan geliştirmeler server seviyesinde olduğu için solution paketinin fiziksel server üzerinde ve admin yetkisi ile deploy edilmesi gerekmektedir. Bu deploment esnasında tüm serverlar etkilendiği için kesintilere neden olmaktadır. Yoğun kullanımlı ortamlar için bu bazen kabul edilemez bir durum olabilmektedir.

Bir farm solution' da yaşanabilecek en kritik sorunlardan biriside hatalı kodlama nedeni ile yaşanabilecek performans sorununun sadece deploy edildiği uygulamayı değil tüm farmı ve üzerindeki site'ları etkilemesidir. Örneğin geliştirmesini yapığımız bir uygulamada oluşabilecek bir memory leak aynı farm'ı kullanan web sitelar da yavaşlık ve erişim problemleri olarak karşımıza çıkacaktır.  Bir çok geliştiricinin ve uygulamanın olduğu kurumlarda bu tür problemlerin kaynağını bulmak ve çözmek zor ve maliyetlidir.

Bir diğer konuda farm solutionların cloud hosting için uygun olmamasıdır.  Bunun içinde sandboxed solutionlar tercih edilmektedir.

Sandboxed Solution

Sandboxed solutionlar yukarıda değindiğimiz sorunların bir çözümü olarak ortaya çıkmış bir geliştirme yöntemidir.  Sandboxed solutionlar, Farm solution'ların aksine tüm farmı etkilemezler ve oldukça korumacı bir mantığı vardır. İlgili uygulama sadece ilgili Site Collection'ı ilgilendirir ve deployment sırasında bir kesintiye neden olmaz. Fakat korumacı yapısı nedeni ile bir çok limitasyonu vardır ve bu limitlerle güçlü bir uygulama geliştirmek çok güçtür.  Ayrıca Microsoft Sandboxed solutionları da uzun süre desteklemeyeceğini duyurmuştur. (http://tinyurl.com/legufzs)

SharePoint 2013 App Model

App model yukarıda anlattığımız Farm Solution ve Sandboxed solutiondan tamamen farklı olarak geliştirilmiş bir kavramdır.  SharePoint 2013 Application Model cloud hosting için dizayn edilmiş bir teknolojidir. App model server site code barındırmaz. Sadece JavaScript, Jquery gibi clinet site scripting kodlar içerir.  App'lar SharePoint üzerinde host edilerek çalıştırılabileceği gibi başka sunucular üzerinde ve/veya cloud üzerinde de host edilebilir.

Microsoft ayrıca App larınızı yayınlayabilmeniz ve satabilmeniz için bir App store oluşturmuştur. Bu sayede uygulamalarınız Android market'de ki gibi dünya çapında müşterilerinizle buluşturabilirsiniz.

Yeni sharePoint App modelinde üç tür App türü vardır;

·        SharePoint-hosted app

·        Provider-Hosted app

·        Autohosted app.

Şimdi bu App türlerini tek tek inceleyelim.

SharePoint-Hosted App

SharePoint-hosted app ile uygulama dosyaları da dahil olmak üzere her şey SharePoint içerisinde saklanır. Bir uygulama app kataloğundan bir siteye yüklenmek istenildiğinde, uygulama için bir alt site ( alt - web) uygulaması oluşturularak uygulama dosyaları burada saklanır. Bu genellikle Appweb olarak isimlendirilir. Appweb'ler için sharepoint uniq bir uygulama adı ve application domaini ile bir URL oluşturacaktır.

Uygulama dosyaları App Web üzerinde konumlandırılır.  App Web ve Host Web (SharePoint Web Site) aynı Site Collection üzerindedir. App Web kurulumu tamamlandığında  SharePoint bu uygulama için uniq bir isim ve bir app domain ile URL üretecektir. Örnegin ;

http://Apps-12345678ABCDEF.Contoso-Apps.com/sites/SiteName/App1Name/Pages/Home.aspx

Uniq App Adı :  12345678ABCDEF

App Domain:Contoso-Apps.com

SharePoint Farmınız da nasıl App domain oluşturulacağını ilerleyen konularda detaylıca anlatacağız.

Provider-Hosted App

Provided-Hosted App, SharePoint dışında barındırılan bir uygulamadır. Örneğin kurum içerisndek ayrı bir IIS sunucunuz bir uygulamanızı barındırabilir. Buna remote web adı verilir. Bu tür uygulamalar daha hybrid uygulamalardır yanı hem client site kod hem de server site kod barındırabilirler. Bu yapıyı tanımlarken Facebook üzerinde canvas uygulama geliştirirken kullanılan tekniğe benzemektedir. Bu modelin avantajlı yönü her çeşit platform ve hardware üzerinde uygulama barındırabilmektir. Uygulamalarınızı kurum içinde bir IIS serverda, azure da veya herhangi bir uzak web sunucusunda barındırabilirsiniz. Uygulama provizyonu yapıldığında SharePoint ve remote app birbirlerine güvenir ve birlikte çalışırlar.

Auto-Hosted App

Auto-Hosted App, windows azure üzerinde hsot edilmek üzere özelleşmiş bir çeşit Provider-Hosted App dir. Auto-Hosted App üzerinde çok uzun durmayacağız çünkü Microsoft Auto-Hosted App leri desteklemeyeceğini duyurmuştur. (16 May 2014 Microsoft Announced: Autohosted apps Preview Program will end on June 30, 2014)

Bu şu anlama geliyor. Daha önceden windows azure üzerinde oluşturulmuş autohosted appler yaşamaya devam edecek ve bir kesinti olmayacak fakat bu tarihten sonra windows azure üzerinde Autohosted app oluşturulamayacak anlamına geliyor.

DNS Üzerinde Domain Name Konfigürasyonu

Bu bölümde App Domain için DNS'in nasıl konfigüre edileceğini inceleyeceğiz.

APP URL

Bir App, SharePoint Site'a deploy edildiğinde özel ve tekil bir URL üretilir. Bu URL, Farmınızın bağlı olduğu domain adı, uygulamaın deploy edildiği Site ve özel bir prefix den oluşur. Şöyleki ;

http://app-123456abcdef.domainAdiniz.com/sites/sharepoitSite/AppName

Burada app özel bir prefix'dir ve SharePoint Central Admin üzerinden değiştirilebilir. 123456abcdef App in deploy edildiği sırada sharepoint tarafından özel olarak üretilir ve uniq dir. domainAdıniz.com ise SharePoint Farmınzın kurulu olduğu Domain adını göstermektedir. sites/sharepointSite ise hosted web'inizin SiteCollection Path'ini belirtir.

Ana SharePoint site URL'i

SharePoint App Model ve DNS ile ilgili bilmemiz gereken ip uçları şunlardır;

·        App'lerin erişilebilir olması için bir wilcard DNS kaydına ihtiyacımız vardır.

·        App'lerin ne olacağına bizim karar veremeyiz veya değiştiremeyiz.

·        Farm üzerinde Subscription Settings Service'in çalışır durumda olması gereklidir.

o   Appler için Sub Domainleri oluşturur.

o   App ler için uniq App ID üretir.

·        Farm üzerinde App Management Service 'nin çalışır durumda olması gereklidir.

o   App yetkilerinden sorumlu servistir. (Permissions)

o   Lisans Bilgileri

Yeni Bir Zone Oluşturma

Yeni bir DNZ Zone oluşturmak için öncelikle DNS Manager'ı açalım. Forward Lookup Zone'a sağ tuşla tıklayıp New Zone'u seçelim.

Bu aşamada New Zone Wizard ekranı gelecektir. Next tuşuna basarak zone type ekranına geçelim.

Zone Type ekranında default olarak primary zone seçilidir ve Store the zone in active Directory check durumda iken next tuşuna basalım.

Aynı şekilde Active Directory Replication Scope ekranını da default olarak bırakıp Next tuşuna basalım.

Zone Name ekranında app'larımız için oluşturduğumuz domain adını yazalım. Örnekte ben constoso-apps.com ismini verdim.  Next tuşuna basalım.

Dynamic Update ekranında Do not allow Dynamic updates seçerek next tuşuna basalım.

Finish butonuna basarak işlemi tamamlayalım.

Bu şekilde yeni zone oluşturma işlemini tamamlamış olduk. Forward Lookup Zones altında oluşturduğumuz contoso-apps.com' u görebilirsiniz.

Yeni Alias (CNAME) Oluşturma

DNZ Manager, Forward Lookup zone altında oluşturduğumuz contoso-apps.com ' a sağ tuşla basarak Add New Alias (CNAME) 'i tıklayınız.

App'lerin erişilebilir olması için wilcard tanımlanması gerekir demiştik. Bu nedenle Alias name için "*" kullandık.  Otomatik olarak *.contoso-apps.com Full qualified domain name alanı oluşmuştur.  Full qualifed domain name (FQDN) for target host kısmına Browse butonuna basarak SharePoint server'ımızı seçiyoruz.

Şimdi domain name ve wildcard'ın çalıştığını test etmek için command prompt açalım ve test edelim.

1234abcd adında bir DNS kaydı oluşturmadık. Fakat Alias tanımladığımı için  sonunda .contoso-apps.com olan tüm testler için aynı sonucu alacağız.   Bir SharePoint app provisyon edildiğinde SharePoint  Subscription Settings Service tarafından app'a bir ID üretilir demiştik. Alias tanımlayarak üretilecek her ID ve URL için erişilebilir bir ortam sağlamış olduk.

Subscription Settings Service Application Konfigürasyonu

SharePoint 2013 App 'ların farmınızda çalışabilmesi için Subscription Settings Service Application' nın kurulu ve çalışır olması gerekmektedir. Bu servis application app'ler için gerekli olan sub domainlerin oluşturulması ve applicationlar için uniq ID  üretilmesi için gereklidir. Subscription servisin' in kurulması için aşağıdaki adımları takip ediniz.

1.      SharePoint 2013 Central Administration' dan System Settings 'i tıklayın.

2.      System Settings Sayfasında yer alan Manage Services on Server 'ı tıklayın.

3.      Services on Server sayfasındaMicrosoft SharePoint Foundation Subscription Settings Service 'i bularak Start' a basın.

4.      SharePoint 2013 Central Administration' dan Application Management 'i tıklayın.

1. Application Management sayfasından Manage Service Application' a tıklayın.
2. Açılan sayfada Subscription Service Application'nın kurulu olup olmadığını kontrol edelim. Kurulu değil ise bir sonraki adımdan devam ediniz.
3. Sol üst köşe de new ribbon'una tıklayalım.

Subscription Settings Service application kurulumu için Central Admin'de olmadığı için kurulum işlemini PowerShell ile yapacagız.

# Create a new Subscription service and proxy

$account = Get-SPManagedAccount contoso\SP_Farm

$appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account

$appSubSvc = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPoolSubSvc -Name "Subscripction Settings Service" -DatabaseName SP_SubSettings

$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $appSubSvc

8.      SharePoint 2013 Management Shell'I sağ tuşla basarak run as administrator ile açarak aşağıdaki scripti çalıştırın.

9.      SharePoint 2013 Central Administration' dan Application Management 'i tıklayın.

1. Application Management sayfasından Manage Service Application' a tıklayın.
2. Açılan sayfada Subscription Service Application'nın kurulduğundan emin olun.

App Managemet Service Kurulumu

App Management Service, App güveneliği, Lisanslar, Satın alma durumları ve katolog gibi görevleri yürüten servis application'dır.  Bu servis application kurulumunu yapmak için aşağıdaki adımları takip ediniz.

1.      SharePoint 2013 Central Administration' dan System Settings 'i tıklayın.

2.      System Settings Sayfasında yer alan Manage Services on Server 'ı tıklayın.

3.      Services on Server sayfasında App Management Service 'I bularak Start' a basın.

4.      SharePoint 2013 Management Shell'I sağ tuşla basarak run as administrator ile açarak aşağıdaki scripti çalıştırın.

# Create a new Application Management Service and Proxy

$account = Get-SPManagedAccount contoso\SP_Farm

$appPoolSubSvc = New-SPServiceApplicationPool -Name AppServiceAppPool-Account $account

$appSubSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolSubSvc -Name AppServiceApp -DatabaseName SP_AppService

$proxySubSvc = New-SPAppManagemetServiceApplicationProxy -ServiceApplication $appSubSvc

1. SharePoint 2013 Central Administration' dan Application Management 'i tıklayın.

1. Application Management sayfasından Manage Service Application' a tıklayın.

13.   App Management Service' in ve servis prox'nin kurulmuş olduğundan emin olun.

App Katalog Web Site'ı Oluşturmak.

App kataloglarını ve lisanları yönetebilmek için bir Site ve site collection oluşturmamız gerekiyor. Burada dikkat edilmesi gereken şey web site oluşturulurken header girilmemesidir. Adım Adım yapılması gerekenleri aşağıda çıkarıyoruz.

1. SharePoint 2013 Central Administration' dan Application Management' ı tıklayın.
2. Application Management Sayfasında, Manage Web Application'a tıklayın ve açılan ekranada sol üst köşedeki New' e tıklayın.
3. Create a new IIS web site Name kısmına Contoso Apps giriniz.
4. Port Kısmına 443 yazınız.
5. Host Header kısmını boş bırakın.
6. Use Secure Sockets Layer (SSL) 'ı Yes olarak işaretleyin.
7. Public URL bölümünde URL kısmına, https://ct.contoso-apps.com:443 yazınız.
8. Create new application pool Application pool name kısmına Contoso App Pool yazınız.
9. Database Name' e bir isim veriniz. (SP_Contoso_Apps gibi)
10. OK' a basarak Web Application'nın tamamlanasını bekleyin.
11. Contoso Apps Web Site'ı oluştuktan sonra Contoso apss seçili iken ribbon' dan Managed Paths' e tıklayınız.
12. Add new path bölümüne apps yazınız ve type olarak Wildcard inclusion olarak seçli bırakın.

1. Add Path' e tıkladıktan sonra OK ile Managed Path'I kapatınız.

Sertifika Ürettirmek

1.      internet Explorrer'dan http://www.cert-depot.com/ adresine gidiniz.

2.      Common Name kısmına *.contoso-apps.com yazınız ve Get-Certificate butonuna basınız.

1. Please fill certificate information (optional) alanlarını dilerseniz doldurun ve Subbit' e basınız.
2. Download PFX butonuna basarak certifikanızı indirin.

NOT: Bu tür certifika üretimini production ortamları için planlamayınız. Bu işlemi daha çok geliştirme ve test ortamları için yapıyoruz.

Sertifikanın Kurulması

Download ettiğiniz sertifikanızı bulun ve üzerine çift tıklayın. Bu aşamada Sertifika Import sihirbazı gelecektir.

1.      Açılan Sihirbazda Local Machine'ı tıklayın ve Next Tuşuna basınız.

2.      File Import ekranında Next tuşuna basınız. Çünkü biz certifika file'ına çift tıkladığımız için ayrıca dosya göstermek durumunda değiliz.

3.      Sertifikanızı oluştururken bir password girdiyseniz (opsiyonel ekranında) bunu şimdi girin ve Next' e tıklayın.

4.      Store Certificate bölümünde alttaki kısmı secerek browse butonuna basın ve Trusted Root Certification Authorites seçip OK'a basın.

5.      Next tuşuna basınız.

6.      Finish tuşuna basınız.

7.      Sertifika dosyanıza tekrar çift tıklayınız ve 3. adıma kadar tekrar geliniz.

8.      Automatically select the certificate 'i seçerek Next' e basınız.

9.      Finish'e basarak işlemi bitirin.

10.   IIS Manager'ı açın ve Contoso App'ı tıklayın.

11.   Sag taraf da yer alan Bindings' e tıklayın

12.   Açılan ekranda https, 443 'ü tıklayarak Edit' e basın.

13.   Host Name' e * girin ve SSL sertificatet'i şekildeki gibi seçerek Ok'a basın.

14.   Close'a basarak işlemi tamamlayın.

SSL Bir SharePoint Site Oluşturma

SharePoint' de SSL bir Site oluşturmak için aşağıdaki adımları takip ediniz.

1.      SharePoint 2013 Central Admin' den Application Management'I tıklayın.

2.      Application Management sayfasından Manage Web Application'ı tıklayın.

3.      New Ribbon'a tıklayın ve Name kısmına Contoso Portal yazınız.

4.      Port olarak 443 yazınız.

5.      Host Header kısmına portal.contoso.com yazınız.

6.      Use Secure Soce 'ı yes seçiniz.

7.      Database ismi verin ve OK' a basın.

8.      Web site'ın oluşturulması tamamlandığında. Create Site Collection linkine tıklayın.

9.      Team Site türünde bir site collection seçin ve Site collection adminleri belirleyin ve OK'a basın.

10.   IIS Manager dan Portal Contoso'yu seçin ve Sertifikanızı Binding kısmından seçin

11.   Require Server Name'I secerek OK' a basın.

Manage Features

App site'ımızı ve portalimizi oluşturduk. Şimdi Portalimizin internet üzerinden store il işlem yapabilmesi için Apps that require accessible intranet facing entpoint feature'ını aktif etmemiz gerekiyor. Bunun için aşağıdaki adımları takip edelim.

1.      SharePoint 2013 Central Admin' den Application Management'I tıklayın.

2.      Application Management sayfasından Manage Web Application'ı tıklayın.

3.      Portal Contoso ' u seçerek Manage Features ribbon'ına tıklayın.

4.      açılan sayfada  Apps that require accessible intranet facing entpoint feature'ı aktif edin.

5.      IIS reset yapın.

APP URL Konfigürasyonu

APP ULR konfigrasyonu için aşağıdaki adımları takip ediniz.

1.      SharePoint 2013 Central Admin 'den Apps'ı tıklayınız.

2.      Apps sayfasından Configure APP URLs linkini tıklayınız.

3.      App domain kısmına contoso-apps.com yazınız.

4.      App Prefix kısmına App yazınız ve OK' a basınız.

Yüklenen ve aktive edilen her application bundan sonra app prefix'I le başlayıp uniq bir ID ile devam ettikten sonra app domain oalrak belirtiğimiz contoso-apps.com ile devam edecektir.

Manage App Catalog

sharePoint 2013'de bir app catalog oluşturmak için bir kaç bölüm önce oluşturdugumuz ct.contoso-apps.com web site'ı na bir Site collection tanımlamamız gerekmektedir. Bunu yapmak için;

1.      SharePoint 2013 Central Admin 'den Apps'ı tıklayınız.

2.      Apps sayfasından Manage App Catalog' u linkini tıklayınız.

3.      Açılan sayfada sağ üst köşede ct.contoso-apps.com'un seçili olduğundan emin olunuz.

1. Create a new app catalog site' ı seçerek OK' basınız.
2. Title kısmına Contoso Apps Catalogue yazınız.
3. URL kısmında Sites'ı Apps olarak değiştiriniz ve CTapps yazınız.(Bir kaç bölüm önce oluşturduğumuz Wildcard inclusions path)
4. Primary Site Collection Administrator 'u Farm Edmin olarak girin.
5. End Users kısmına everyone yazarak  check edin.
6. OK' a basarak SharePoint'in işlemi tamamlamasını bekleyin.

1. İşlem tamamlandığında SharePoint hhtps://ct.contoso-apps.com/CTapps şeklinde bir site collection oluşturacaktır. Bu URL tıklandığında Tüm farmınızda kullanacağınız APP Catalog uygulamasını görecektisniz.

SharePoint Site'a SharePoint Store'dan Apps Nasıl Yüklerim ?

SharePoint Apps konfigürasyonu ile ilgili yapacağımız tüm işlemler tamamlandı. Şimdi SharePoint portalimizi açalım ve bir SharePoint Store Apps ekleyelim.

Bunun için öncelikle portalimizde Site Collection Admin yetisinde bir kullanıcı ile login olalım. (Farm Admin ile login olursanız Apps yüklemede bir hata vermektedir.)

Ben kendi portalimde contoso\kkaradag ile login oldum. Şimdi bir App nasıl eklenir adım adım devam edelim.

1.      Portalinizde Setting bölümünden Add an app' i tıklayınız.

2.      SharePoint Store Link'ine tıklayınız.

3.      SharePoint store'da bir çok uygulama görebilirsiniz. Sol tarafta kategorilere göre ayrılmış yüzlerce uygulamadan kurumunuz için ihtiyaç olanı bulup sisteminize keleyebilirsiniz. Biz sağ üst köşede yer alan Find kutusundan free bir uygulama bularak portalimize ekleyelim.

4.      Fınd kutusunasurvey yazarak aratalım.  Sonuç sayfasında OneBit Quick Pool uygulamasını tıklayın.

5.      ADD IT butonuna basınız. Microsoft Accountunuzu ve passwordunuzu giriniz.

1. Confirm that you wish to add the app ekranında Confirmation tıklayın.

1. App store işlemini tamamladığında portalinize dönmeniz için bir ekran çıkaracaktır.

1. Return to site butonuna tıkladığınızda aşağıdaki uyarı gelecektir. Bu uyarıda Trust it' e tıklayınız. Bu sayede uygulamaya Farmınız güvenecektir. Bu kısım çok önemli.

1. Trut It butonuna bastığınızda uygulama otomatik olarak indirilecek ve install edilecektir.

1. portal Ana Sayfasına geri döünün ve settings 'den add a Page' e tıklayın ve Surey sayfasını oluşturun.
2. Insert ribbon'dan App Part'a tıklayın ve yeni uygulamanızı seçerek OK' a basın.

1. App Partınızın konfigrasyonlarını yapın ve Sayfayı Save' ederek çıkın.

1. Portalinizde artık bir Surrvey uygulaması var. Tabiki Cevap Beşiktaş :)

Bu yazımız da SharePoint 2013 ile birlikte gelen App modeli btün detayları ile incelemeye çalıştık. İşlemler biraz çok ve kopleks olmak ile birlikte sağladığı faydalar bakımından bu işlemlere değer buluyorum. Bir sonraki yazımızda kendimiz SharePoint- hosted app geliştirip SharePoint 2013 FARM'imizda yayınlamayı göreceğiz.

Birleşik iletişim (anlık mesajlaşma, görüntülü ve sesli konferans, Voip) alanında %84 lük çok yüksek bir payla Türkiye’de pazar lideri olan Lync 2013 yerini Skype for Business 2015’e bırakıyor. Bu anlamda Skype for Business Server 2015, 1 Mayıs 2015 tarihi itibariyle kullanılabilir hale geldi. Microsoft’un Skype satın almasından sonra Skype- Lync entegrasyonu gelmiş ardından Skype Translator Preview ile yeni bir oluşum olan dil bariyerlerinin ortadan kaldırılması hedeflenmiştir.

Skype for Business Server 2015 ile gelen yenilikler makalemiz yayına hazırlanmaktadır.

14 Nisan 2015 tarihinde Office 2013 ile birlikte gelen Lync 2013 client yazılımı Skype for Business Client olarak güncellenmişti.

Bu makalemizde Skype4B standart server 2015 kurulumunu yapıyor olacağız.  Öncelikle VLSC sayfanızdan veya MSDN download sayfasından Skype for Business Server 2015 (x64) DVD (1.5 GB) indirmeniz gereklidir.

Donanım gereksinimleri: 64 bit CPU 2.26 Ghz ve üzeri, Önerilen 32 GB RAM, 72 GB HDD

Sistem gereksinimleri: Server 2012 Standart ve üzeri işletim sistemi,

Domain Gereksinimleri: Active Directory (Forest FL 2003 ve üzeri), DNS, Fileshare ve CA (Certification Authority)

NOT: Skype4B Server domain kontrol sunucusu üzerine kurulamaz. Kendi lab yapımda BS4BDC (DC, DNS, DHCP, CA) Server 2012 R2 (192.168.0.4) ve BS4BFE (S4B Server) Server 2012 R2 (192.168.0.5) olarak iki adet sunucum bulunmaktadır.

Skype4B server kurulumu için planlamamız aşağıdaki gibidir.

1-     Install Prerequisites: Bu adımda S4B server üzerinde öngereksinimleri kuruyor olacağız. Bunun için S4B sunucusunda Powershell içerisinde aşağıdaki komutu yapıştırıyoruz. (D: sürücüsünde Windows Server 2012 R2 Iso DVD bulunmalıdır)

Add-WindowsFeature NET-Framework-Core, RSAT-ADDS, Windows-Identity-Foundation, Web-Server, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Dir-Browsing, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Client-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, NET-WCF-HTTP-Activation45, Web-Asp-Net45, Web-Mgmt-Tools, Web-Scripting-Tools, Web-Mgmt-Compat, Server-Media-Foundation, BITS -Source D:\sources\sxs

Bu kurulum tamamlandıktan sonra sunucumuzu yeniden başlatıyoruz ve ikinci adıma geçiyoruz.

2-     Create a File Share: Kendi yapımda DC üzerinde “S4Bshare” isimli bir dosya oluşturuyorum ve Sharing \Advanced Sharing bölümünde Share This Folder – Permissions tabında Everyone Full Access bir share oluşturuyoruz.

3-     Install Administrative Tools: Bu bölümde S4B Server DVD üzerinde setup.exe çalıştırıyoruz. “Connect to ..” seçeneğiyle varsa güncelleştirmeleri indirmesini saglıyoruz.

Lisans sözleşmesini kabul edip OK ile devam ediyoruz.

Welcome to Skype For Business 2015 deployment ekranında “Install Administrative Tools” tıklıyoruz. Görüldüğü üzere Lync 2013 kurulumundan pek bir farkı yoktur. Bu sebepten bütün adımların ekran görüntülerini makaleye almıyorum.

Aşağıdaki ekranda next tuşuna tıklayıp kurulumu başlatıyoruz.

Administrative Tools kurulumu tamamlandı. Finish tusuna tıklayıp ekranı kapatıyoruz. Bu adımla birlikte aşağıdaki yazılımlar yüklenecektir.

·        Skype for Business Server 2015 Topology Builder: 

·        Skype for Business Server 2015 Control Panel

·        Skype for Business Server 2015 Deployment Wizard

·        Skype for Business Server 2015 Management Shell

4-     Prepare Active Directory: Bu adımda Active Directory yapımızı Skype4B server kurulumuna hazırlayacagız. Öncelikli olarak AD Schema genişleteceğiz.

Bu işlem için Skype4B 2015 Deployment wizard penceresinde “Prepare Active Directory” bölümüne tıklıyoruz.

Step 1: Prepare Schema bölümünün karşısındaki Run butonuna tıklayıp işlemi başlatıyoruz.

Birinci adım tamamlandıktan sonra yanında greencheck gelecektir ve Run butonu disable olacaktır.

Yaptıgımız işlemin kontrolunu büyük AD ve Site yapılarında yapmamız gereklidir. Bunun için Start – Run  - adsiedit.msc üzerinden Connection Settings altında Select a well known Naming Context, den Schema seçilir. Burada CN=ms-RTC-SIP-SchemaVersion anahtarı bulunur ve properties açılır. RangeUpper değerinin 1150 oldugu gözlemlenir.

NOT: Eger bu degeri göremiyorsanız işlemi tekrar başlatınız veya AD replikasyon işlemlerinin tamamlanmasını bekleyiniz.

Step 3: Prepare Forest adımında Run butonuna tıklıyoruz ve işleme devam ediyoruz.

İşlem tamamlandıktan sonra kontrolu için Skype For Business Management Shell üzerinden aşağıdaki komutu yürütünüz. Aşağıdaki gibi bir çıktı almanız gereklidir.

“Get-CSAdForest”

Step 5: Prepare Current Domain adımında Run butonuna tıklıyoruz ve Universal Group Location bölümünde tek bir Forest / domain yapısında oldugumuz için Local Domain seçimini yapıyoruz.

İşlem tamamlandıktan sonra kontrolu için dsa.msc Active Directory Users and Computers adımında Users tabına gidilip CS ile başlayan grupların oluşturuldugu gözlemlenir.

Step 7: adımında Administrator kullanıcısını CSAdministrator grubuna üye yapıyoruz.

Bu işlemlerden sonra sunucuyu yeniden başlatmanızı öneririm.

Sunucumuzu yeniden başlattıktan sonra Skype4B deployment Wizard ekranında artık Prepare Active Directory adımının Complete oldugunu görebilirsiniz.

Standart Edition kurulumu yapacagımız için Deployment Wizard ekranında Prepare single Standart Edition Server seçeneğiyle devam ediyoruz.

SQL Express kurulumundan sonra Skype Server topology Builder üzerinden ilk topolojimizi olusturmaya başlıyoruz.

New Topology adımını seçiyoruz ve topoloji dosyamızı kaydediyoruz.

SIP domain ekranında mail adresinizin uzantısını yazabilirsiniz (@domain.com da domain.com gibi)

Yine exchange deki gibi Accepted domain yapısında kullanıyorsanız burada Additional SIP domainlerinizi ekleyebilirsiniz.

Define the first site ekranında şirketinize ait site bilgilerini girebilirsiniz.

Open the New Front End wizard kutucugu işaretlenerek devam ediyoruz.

Skype4B serverin Enterprise mi yoksa Standart mi olacagi seçimi buradan yapılmaktadır. SQL Express kurulumundan sonra Standart server devam edeceğimiz için seçimimizi yapıyoruz ve Skype4B sunucusunun FQDN bilgisini giriyoruz.

Select features bölümünde lisanslamanıza göre istediginiz özellikleri ekleyebilirsiniz.

Standart Edition kurulumundan solayı Mediation server da Front End sunucusu üzerinde bulunsun istiyoruz ve kuruluma devam ediyoruz.

Enable an Edge Pool … seçiminde herhangi bir değişiklik yapmadan bir sonraki ekrana geçiyoruz.

SQL Express RTC database üzerinde CMS kurulumunu gerçekleştireceğimizden dolayı herhangi bir seçim yapmadan ilerliyoruz.

Define a new file store ekranında DFS veya Fileserver üzerinde oluşturdugunuz paylaşıma açık dosyayı seçiyoruz.

External web servisleri için kullanacağımız URL adresini giriyoruz.

Bu kurulumda Office Web App server kullanmayacağımız için seçeneği kaldırıp Finish butonuna tıklıyoruz.

Organization name üzerinde sağ tıklayıp Edit Properties dedikten sonra Administrative Access URL ve CMS seçimlerini yapıyoruz.

Bu işlemden sonra topolojimizi SQL üzerinde yazdırmak için Publish topology adımına geçiyoruz.

Central management Server in tutulacağı sunucu ve database seçimini yapıyoruz ve next tıklıyoruz.

Topolojimiz başarıyla publish edildi bu aşamadan sonra yapılacaklar open to-do-list tıklayıp görebilirsiniz.

Topoloji publish işleminden sonra artık Skype4B sunucumuzun componentlerini kurabiliriz. Skype4B Deployment Wizard ekranında Install or Update Skype for Business Server System seçimini yapıyoruz ve Step 1: Install Local Configuration Store seçeneğiyle ilerliyoruz.

Retrieve directly from… Seçeneğiyle CMS erişimini sağlıyoruz venext tıklıyoruz.

Step 2: Setup or Remove Skype for Business Server Components adımında Run butonuna tıklıyoruz.

Yukarıdaki gibi bir hata alıyorsanız Windows Updatelerini ve aşağıdaki yamayı kurunuz.

http://hotfixv4.microsoft.com/Windows%208.1/Windows%20Server%202012%20R2/sp1/Fix514814/9600/free/478232_intl_x64_zip.exe

Step 1 ve Step 2 aşamalarını tamamladıktan sonra ekran aşağıdaki gibi görünmelidir.

Step 3: Request, Install or Assign Certificates adımında Run butonuna tıklıyoruz hem Default Certificate hem de OauthTokenIssuer için ayrı ayrı sertifika request yapıyoruz. Daha detaylı bilgi için burayı tıklayınız.

Default Certificate seçiliyken Request butonuna tıklıyoruz. Bu ekranlar Lync 2013 kurulumundan biraz daha farklı bir hale getirilmiştir. Anlaşılacağı üzere çok daha pratik ve daha az adımlarla sertifika ekleme işlemlerini tamamlayabiliyoruz.

Aşağıdaki adımla birlikte oluşturduğumuz sertifikayı Assign ediyoruz.

Aynı işlemleri OauthTokenIssuer için de yapıyoruz ve sertifika adımını tamamlıyoruz.

Step 4: Start Services ekranında Lync 2013 kurulumundan farklı olarak servisleri Pool veya FE sunucu için manuel başlatmamızı istemektedir.

Bu işlem için Skype4B Management Shell açıyoruz ve aşağıdaki cmdlet giriyoruz.

“Start-CsWindowsService”

NOT: Enterprise yapıda bir kurulum yaptıysanız pool üzerinden servisleri start etmeniz gereklidir. (Start-CsPool)

Start – Services.msc adımında servislerimizin durumlarını görebiliriz.

internal DNS üzerinde aşağıdaki kayıtları oluşturuyoruz.

SRV kayıdını oluşturmak için aşağıdaki ekranı kullanabilirsiniz.

Kurulumumuz tamamlandı ve son adımda Skype4B Control Panel üzerinde bir kullanıcı oluşturuyorsunuz ve S4B client üzerinden login oluyorsunuz. Bir sonraki makalemizde S4B Control Panel ve kullanıcı ekleme işlemlerini anlatıyor olacağız.

Günümüzde kurum veya organizasyon yapılarında kurumsal içerikte farklı kullanıcılar tarafından değişik kategoride Microsoft Office uygulamaları ile yoğun bir doküman üretimi gerçekleştirilmektedir. Bu yoğun doküman kütüphanesinde özellikle kurumsal yazışmalar için kuruma özel doküman standartları belirlenerek, bu standartlara uygun doküman şablonları hazırlanmaktadır. Hazırlanan doküman şablonları ilgili kullanıcıların ulaşabileceği ortak alana kopyalanarak ihtiyaç anında bu alandan kopyalanarak kullanılması sağlanmaktadır.

İki bölümden oluşan bu makale serimizde hazırlanan Office doküman şablonlarını active directory üzerinden domain içerisindeki kullanıcılara merkezi olarak dağıtımı için gerekli teknik detayları uygulamalı olarak paylaşıyor olacağız. Makalemizdeki adımları başarıyla uyguladığınızda şirket kullanıcılarınız ortak alandan doküman şablonunu kopyalamaya gerek kalmadan Office uygulamalarını (Word, Excel, PowerPoint, vb.) başlattıklarında şirkete ait doküman şablonlarının bulunduğu kategorileri otomatik olarak görecek ve buradan istedikleri şablonu açıp kendi dökümanlarını üretmiş olacaklardır.

Şablon (Template) Nedir?

Şablon ya da İngilizce karşılığı ile Template, önceden tanımlanmış bir düzeni, yazı tipleri, kenar boşlukları, stilleri olan ve açıldığında kendisinin bir kopyasını oluşturan bir belge türüdür. Şablonlarla amaçlanan dökümanın yapısını sıfırdan oluşturmak yerine bu şablonları açıp belgenize özgü metin ve bilgileri doldurmaktır.

Microsoft Office Uygulamalarına ait şablon dosya uzantılarını aşağıdaki şekilde listeleyebiliriz:

·       Microsoft Office Word Şablonu (dotx)

·       Microsoft Office Word 97-2003 Şablonu (dot)

·       Microsoft Office Excel Şablonu (xltx)

·       Microsoft Office Excel 97-2003 Şablonu (xlt)

·       Microsoft Office PowerPoint Şablonu (potx)

·       Microsoft Office PowerPoint 97-2003 Şablonu (pot)

MS Office uygulamaları ile şablon oluşturma konusunda Yeni şablon oluşturma ve Office Online Şablonları ve Temaları makalelerinden detaylı bilgileri elde edebilirsiniz. Makalemizde şablon oluşturmaktan ziyade oluşturulan şablonların organizasyon içerisindeki kullanıcılara active directory üzerinden nasıl dağıtılacağını anlatıyor olacağız.

Uygulama Altyapı Bileşenleri

Microsoft Office dökümanlarının merkezi olarak dağıtımı için altyapıda kullanacağımız sunucular:

·       Active Directory Domain Controller

·       Dosya Sunucusu (File Server)

·       Test operasyonları için istemci bilgisayarlar

Biz makalemizde dosya sunucusu olarak da domain controller sunucusunu kullanıyor olacağız. Kurumsal yapılarda dosya sunucusu rolüne sahipseniz bu sunucunun üzerine doküman şablonlarını konumlandırmanızı öneriyoruz.

Doküman Şablonlarının Merkezi Dosya Sunucu Üzerine Konumlandırılması

Uygulamamızın birinci adımı oluşturulan Microsoft Office doküman şablonlarının dosya sunucusu üzerinde bir klasöre kopyalıyoruz. Burada klasör yapısı tamamen sizin kendi klasör standartlarınıza göre belirlenebilir. Bizim makale içerisindeki klasör hiyerarşimiz aşağıdaki şekildedir:

Biz uygulamamızda Word, Excel ve PowerPoint uygulamaları için gerekli şablonu oluşturduk. Siz ihtiyacınıza göre buna Project, Publisher, Visio vb. gibi diğer Office uygulamalarına ait şablonları da benzer adımlarla uygulayabilirsiniz.

Her ana klasörün içerisinde o uygulamaya ait aşağıdaki gibi şablon doküman dosyalarını kaydediyoruz. Biz makalemiz için örnek olarak birkaç doküman ekledik. Siz kurum içerisinde bunu genişletebilirsiniz.

Word Doküman Şablonları

ÖNEMLI NOT : Word şablon uzantıları dot ya da dotx olmalıdır. DOC ya da DOCX şablon dosyası değildir. Ayrıca dosya isimlerinde Türkçe karakter kullanılmamalıdır.

Excel Doküman Şablonları

ÖNEMLI NOT : Excel şablon uzantıları xlt ya da xltx olmalıdır. XLS ya da XLSX şablon dosyası değildir. Ayrıca dosya isimlerinde Türkçe karakter kullanılmamalıdır.

PowerPoint Doküman Şablonları

ÖNEMLI NOT : PowerPoint şablon uzantıları pot ya da potx olmalıdır. PPT ya da PPTX şablon dosyası değildir. Ayrıca dosya isimlerinde Türkçe karakter kullanılmamalıdır.

Doküman Şablonlarının Paylaşıma Açılması

Yukarıda klasör yapısını hazırladığımız ve doküman şablonlarını kopyaladığımız klasörümüzü kullanıcıların bu şablon dosyalarına erişimi için paylaşıma açıyoruz. Eğer bu klasörün ağ yolundan dosya sunucusuna erişildiğinde listelenmesini istemiyorsanız standart paylaşım yerine gizli paylaşım olarak açabilirsiniz. Bizim burada önerimiz gizli paylaşım yöntemini (paylasimadi$ şeklinde) kullanmanızdır.

Şablonlarını bulunduğu klasörü paylaşıma açmak için klasörün üzerinde sağ tuşa basıp Properties tıklıyoruz. Gelen ekranda Sharing sekmesine geçiyoruz. Sharing sekmesinde Advanced Sharing butonuna tıklıyoruz.

Gelen Advanced Sharing ekranında aşağıdaki gibi paylaşım adını sonuna $ simgesini de ekleyerek gizli paylaşıma açacak şekilde belirtiyoruz.

Bu ekrandan çıkmadan Permissions butonuna tıklayarak paylaşım izinlerinde Everyone:Read (Allow) yetkisinin olduğunu kontrol ediyoruz.

Daha önceki Windows Server 2012 R2 ile Dosya Sunucularda Paylaşım ve Güvenlik İzinleri – Bölüm 1 makalesinde de detaylı incelediğimiz gibi ağ üzerinde paylaştırılmış klasöre erişim sağlandığında paylaşım izinleri ile (Sharing sekmesi), güvenlik izinleri (Security sekmesi) arasında en kısıtlayıcı olan izin geçerlidir. Doküman şablonlarının bulunduğu paylaştırılan klasöre ağdan kullanıcılar erişim sağladığında bu paylaşımı okuyabilmeleri ve erişim sağlayabilmeleri için paylaşım izinlerinden minimum Read yetkisine sahip olmaları gerekir. Burada Everyone yerine ihtiyaca göre domain içerisinde açılmış daha dar kapsamlı bir security grubu da gösterebilirsiniz. Fakat uzun vadede farklı kullanıcıların da bu şablonlara erişiminde ilgili grupları ayrıca eklemeniz gerekecektir.

Bu kontrol sonrasında OK butonuna tıklanarak tüm ekranları onaylıyarak kapatıyoruz.

Böylece klasörümüz gizli paylaşıma açılmış oldu. Ağdan da erişim sağlayarak kontrol ediyoruz.

Küçük Resim Görüntüsü ve Önizleme Görüntüsü Dosyalarının Hazırlanması

Şablon dökümanlarına ait isteğe bağlı olarak küçük resim görüntüsü ya da önizleme görüntüsü resim dosyaları hazırlayarak Office uygulamalarında şablonlar açılmadan önce bu resimlerle önizleme görüntülerinin oluşması ve kullanıcıların kolaylık doküman içeriği hakkında fikir sahibi olması sağlanabilir. Eğer küçük resim ve önizleme görüntü dosyaları tanımlanmazsa doküman şablonu üzerine geldiğiniz kırmızı çarpı işareti şeklinde bir resim görüntülenecektir.

Küçük Resim Görüntüsü

Önizleme Görüntüsü

Şablon dökümanlarına ait aşağıdaki küçük resim ve önizleme görüntülerine ait hazırlanmış dosyaları da yine aynı konumda “images” klasörü içerisine kaydediyoruz. Bu tasarım için kurum içerisindeki grafik ve tasarım birimlerinden destek alabilirsiniz.

İmages Klasörü

Word Küçük Resim (Thumbnail) ve Önizleme (Preview) Görüntü Klasörleri

Word Önizleme (Preview) Resim Dosyaları

Word Küçük Resim Görüntüsü (Thumbnail) Resim Dosyaları

ÖNEMLİ NOT : Şablon Dökümanlarına ait küçük resim ve önizleme görüntü resim dosyalarını oluştururken belirli standartlara dikkat etmeniz gerekir. Küçük resim görüntüsü için 100x120 (genişlik X yükseklik), önizleme görüntüsü için de 256x350 boyutlarında olması gerekir. Ayrıca dosya uzantıları da .jpg, .png, .bmp, ya da .gif uzantısında kaydedilmiş olması gerekir.

İki bölümden oluşan ve kurumsal organizasyonlarda hazırlanmış Microsoft Office doküman şablonlarının active directory domaininde bulunan kullanıcılara active directory logon script kullanılarak merkezi bir sunucudan dinamik olarak dağıtımını içeren makalemizin ilk bölümünün de gerekli altyapıyı hazırladık. Makalemizin ikinci bölümünde görüşmek dileğiyle sağlıcakla kalın.

Günümüzde kurum veya organizasyon yapılarında kurumsal içerikte farklı kullanıcılar tarafından değişik kategoride Microsoft Office uygulamaları ile yoğun bir doküman üretimi gerçekleştirilmektedir. Bu yoğun doküman kütüphanesinde özellikle kurumsal yazışmalar için kuruma özel doküman standartları belirlenerek, bu standartlara uygun doküman şablonları hazırlanmaktadır. Hazırlanan doküman şablonları ilgili kullanıcıların ulaşabileceği ortak alana kopyalanarak ihtiyaç anında bu alandan kopyalanarak kullanılması sağlanmaktadır.

Makalemizin ilk bölümünde hazırlanan doküman şablonlarını bu bölümde de active directory üzerinden domain içerisindeki kullanıcılara merkezi olarak dağıtımı için gerekli teknik detayları uygulamalı olarak gerçekleştireceğiz. Makalemizdeki adımları başarıyla uyguladığınızda şirket kullanıcılarınız ortak alandan doküman şablonunu kopyalamaya gerek kalmadan Office uygulamalarını (Word, Excel, PowerPoint, vb.) başlattıklarında şirkete ait doküman şablonlarının bulunduğu kategorileri otomatik olarak görecek ve buradan istedikleri şablonu açıp kendi dökümanlarını üretmiş olacaklardır.

ŞABLON YAPILANDIRMA DOSYASI : TEMPLATES.XML

Hazırlanan şablon dökümanlarının Office uygulamalarında gelen Available Templates kategorisi altında görüntülenebilmesi için bir XML konfigürasyon dosyasında bu dökümanlara ait tanımlamaların yapılması gerekir. Microsoft Office uygulaması bu XML dosyasını referans alarak şablon dosyasının, küçük resim ve önizleme resim dosyalarının nereden ve nasıl alınacağına karar verir.

Aşağıda örnek bir XML konfigürasyon dosyası içeriğini görüyorsunuz:

XML dosyası içerisinde “application” ve “template” olmak üzere iki ana element parçası vardır. Resimde de görüldüğü gibi öncelikle “featuredcontent” isimli bir ana element açıyoruz. Hemen akabinde “application” elementi açıp içerisinde hangi uygulama için şablon tanımı yapılıyorsa bunu belirtiyoruz. Word için “WD”, Excel için “XL”, PowerPoint için de “PP” kısaltması kullanılır. İlgili uygulama içerisinde tanımlanacak tüm şablon dosyası tanımlarını kapsayan “featuredtemplates” elementi açılır. “Featuredtemplates” elementi içerisinde de her doküman şablonu dosyası için “featuredtemplate” elementi açılarak içerisinde şablon tanımına ilişkin tanımlamalar yapılır. “Title” alanı Office uygulamaları içerisindeki görünecek etiket adı, “source” alanında da dosyanın kaynak yolu tanımlanır. Her template tanımı için “media” elementi içerisinde küçük resim görüntüsü dosyasının özellikleri ve resim dosyası yol tanımı belirtilir. “Preview” elementi ile de önizleme görüntü resmi tanımı ile ilgili tanımlamaları gerçekleştiriyoruz. Her template tanımı sonunda “featuredtemplate” elementi kapatılmalıdır. Herhangi bir uygulama içerisindeki tüm şablon tanımları yapıldıktan sonra da “Featuredtemplates” elementi kapatılmalıdır. Sonrasında da ilgili uygulamaya ait “application” elementi kapatılmalıdır. Eğer Excel ya da PowerPoint gibi ikinci bir uygulama için de şablon tanımı yapılacaksa “featuredcontent” elementi kapatılmadan tekrar yeni bir “application” elementi açılır. Onun içerisinde de o uygulama ve uygulamanın şablonlarına ait alt element tanımları ve değerleri belirtilir ve sonunda da yine “application” elementi kapatılır. Tüm uygulamalara ait şablon tanımlamaları tamamlandıktan sonra da  “featuredcontent” elementi kapatılır.

Örnek bir XML dosyası için bu linküzerinden de erişebilirsiniz.

Biz uygulamamızda aşağıdaki XML dosyamızı oluşturduk ve içerisinde Word, Excel ve PowerPoint uygulamalarına ait şablon tanımlarını tanımladık.

Yukarıdaki şekilde de görüldüğü gibi Word, Excel ve PowerPoint uygulamaları için ayrı ayrı şablon tanımları yapılmıştır.

Bu tanımları içeren XML dosyasını da yine aynı konuma Templates.XML adıyla kaydediyoruz.

ÖNEMLİ NOT : Yeni bir şablon oluşturulduğunda da ilgili şablon ve resim dosyaları dosya sunucusu üzerindeki klasörlere kopyalandıktan sonra şablon yapılandırması mutlaka bu XML içerisine tanımlanmalıdır. Bu tanımlamalarda hiçbir yerde Türkçe karakter kullanılmamalıdır.

Bu oluşturduğumuz XML dosyasının geçerli olup olmadığı ve içeriğinin yorumlanmasını yapacak XML Schema dosyasını da (XSD) aynı konuma oluşturuyoruz. XSD dosyası isteğe bağlıdır, doğrulama yapmak istemiyorsanız tanımlamayabilirsiniz. Standartlar açısından konumlandırmanızı öneriyoruz. Örnek bir XSD schema dosyasına bu linkten erişebilirsiniz. Biz de uygulamamızda OfficeTemplates.xsd isimli schema dosyasını aynı konuma kopyalıyoruz.

Biz uygulamamızda bu linkten indirdiğimiz örneği aynen kullandık.

XML YAPILANDIRMA DOSYASINI OKUYACAK REGISTRY AYARLARININ TANIMLANMASI

Şu ana kadar yaptığımız hazırlıklarla şablon dosyaları, bunların önizleme resimleri, bu dosyaların tanımlamalarını içeren XML yapılandırma dosyamızı hazırladık. Sıra geldi Office uygulamasının bu yapılandırma dosyasını okuyacak şekilde kullanıcı bilgisayarlarında registry ayarlarının yapılandırılmasına. Bu işlem için de Templates.reg isimli bir registry yapılandırma dosyası hazırlıyoruz. Bunun hazırlarken Notepad açıp ilgili tanımlamaları yaptıktan sonra .REG uzantılı olarak dosyayı kaydedebileceğiniz gibi, mevcutta bir bilgisayarda bu tanımlamaları yapıp ilgili anahtar hiyerarşisini REG dosyasına export ederek de oluşturabilirsiniz.

\\MST-DC01\CozumPark-Templates$ paylaşımı altında Templates.reg dosyası içerisinde kullanıcı bilgisayarlarında registry içerisine yazılacak tanımlar girdi olarak belirtilir. Bu tanımlar sayesinde yukarıdaki şablonları içeren XML dosya okunarak istemci bilgisayarlarında ilgili şablonlar listelenecektir.

Templates.reg dosyası içeriğini de aşağıdaki şekilde görmektesiniz:

Buradaki tanımlarda Office 2010 olanlar için 14.0, Office 2013 olanlar için de 15.0 versiyonu için tanımları yaptık. Kullanıcı bilgisayarlarında her ikisi oluşmuş olacak ve kullanılan versiyona göre şablonlar otomatik olarak gelecektir. “ServiceURL” anahtarı ile şablonların okunacağı XML dosyasının kaynak yolu tanımlamasını belirtiyoruz. PROVIDERS altında belirttiğimiz anahtar adı Office uygulaması içerisinde bizim şablonlarımızın belirtileceği kategorinin görünen adıdır. Biz COZUMPARK TEMPLATES olarak tanımladık ve bu şekilde görüntülendiğiniz göreceğiz. DisableBootToOfficeStart tanımı da isteğe bağlıdır ve Office 2013 kullananlar için geçerlidir. Bildiğiniz gibi Office 2013 uygulamalarını başlattığınızda otomatik olarak hazır gelen şablonları ve çalışılan son dökümanları listeleyen bir başlangıç ekranı gelir.

Bunun gelmesini engellemek için DisableBootToOfficeStart registry anahtarını aktifleştiriyoruz. Böyle bir ihtiyaç ya da gereksiniminiz yoksa bunu da tanımlamayabilirsiniz. Biz her açılışta son çalışılan dökümanların otomatik gelmesini istemediğim için bu değeri de belirttik.

REGISTRY DOSYASININ LOGON SCRIPT OLARAK KULLANICILARA UYGULANMASI

Bir önceki adımda kullanıcı bilgisayarlarında Office doküman şablonlarını ve ilave özelliklerini XML yapılandırma dosyasında okuyup, kullanıcı bilgisayarlarına getirecek registry ayarlarını içeren REG dosyasına tanımladık. Şimdi de bu şablonları kullanacak kullanıcılar için REG dosyasını active directory domainine logon olan bu kullanıcılara logon script olarak uzaktan tetiklemeye geldik. Bunun için de bir BAT dosyası oluşturacağız. Biz örneğimizde REGADD.BAT olarak isimlendiriyoruz.

Yukarıdaki şekilde de görüldüğü gibi REG dosyasını ağ yolundan okuyarak import ediyoruz. Bu oluşturduğumuz BAT dosyasını NETLOGON klasörü içerisine kaydediyoruz.

ÖNEMLİ NOT : Eğer mevcut durumda kullanıcılara uygulanan bir logon script varsa bu durumda yukarıdaki BAT dosyasının içerisine yazdığımız satırı mevcut logon script dosyası içerisine ilave etmeniz yeterlidir. Böylece mevcut yapıyı bozmadan ya da değiştirmeden bu ilave satırı da ekleyip çözüme gidebilirsiniz.

Son olarak bu BAT dosyasını çalıştırmak istediğimiz kullanıcı hesabı özelliklerinde Profile tabında Logon Script olarak RegAdd.BAT isimli dosyanın tanımlanmasını yapalım.

Toplu olarak çok sayıda kullanıcı için bu tanımı DS komut satırı araçları, VBS script ya da PowerShell cmdlet ile de yapabilirsiniz. Hatta Active Directory Users and Computers konsolu içerisinde Saved Queries ile ilgili kullanıcıları listeleyip, tamamını aynı anda seçip Properties’den Profile tabından Logon Script tanımlayabilirsiniz. PowerShell ile bu konudaki örneklere burdan ulaşabilirsiniz.

Artık sıra geldi kullanıcı bilgisayarlarından logon olup test etmeye.

KULLANICI BİLGİSAYARINDAN TESTLERİN GERÇEKLEŞTİRİLMESİ

Biz demo ortamımızda Windows 7 işletim sistemi ile çalışan ve Office 2013 yüklü istemci bilgisayarından logon script tanımı yaptığımız MesutAladag isimli kullanıcımızla giriş yaparak yaptığımız ayarların uygulanıp uygulanmadığını test ediyoruz.

Word Uygulamasını çalıştırdığımızda New tıkladığımızda aşağıdaki gibi COZUMPARK TEMPLATES kategorisinin geldiğini göreceksiniz.

COZUMPARK TEMPLATES kategorisine tıkladığınızda da oluşturduğumuz şablonların listelendiğini göreceksiniz.

İstediğiniz şablonu açıp artık dökümanlarınızı hazırlayabilirsiniz.

Eğer Office 2010 kullanıyorsanız da oluşturduğumuz şablonların görüntüsü aşağıdaki şekilde olacaktır:

Bu gelen klasör kategorisine girdiğinizde yine ilgili şablonlarını listelendiğini göreceksiniz.

Bu kontroller Word, Excel, Powerpoint vb. tüm uygulamalar için ayrı ayrı kontrol edebilirsiniz.

Kullanıcı bilgisayarında Registry  uygulamasını başlatırsanız da ilgili registry anahtarları ve string değerlerinin oluştuğu ve doğru bir biçimde geldiğini de kontrol edebilirsiniz.

ÖNEMLİ NOT : Herhangi bir kullanıcı bilgisayarında şablonlar eksik gelirse ya da oluşmazsa [HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\ altından Spotlight anahtarı silinmelidir. Daha sonra log off olup tekrar logon olunduğunda logon script çalışacak ve ilgili şablonlar sağlıklı bir biçimde tekrar yüklenecektir. Bu işlemi logon script yöntemi ile active directory üzerinden uygulamak için de aşağıdaki içeriğe sahip bir REG dosyası oluşturup bunu yine ağ yoluna kopyalayıp logon script içerisinden de öncelikle bu dosyayı çağırabilirsiniz.

Burada dikkat çeken nokta Registry anahtarları tanımlarının başındaki “-“ işareti. Bu işaret ilgili anahtarın silinmesi anlamına geliyor.

Ağ yoluna bu REG dosyasını da kaydettik. Son olarak logon script içerisinden bu REG dosyasını da çağıracak satırı ekliyoruz. Bu satırı üste alıyoruz ki öncelikle mevcut bir tanım varsa registry içerisinden silsin ve daha sonra Templates.REG dosyasından ilgili ayarları import edilmiş olacaktır.

İki bölümden oluşan bu makale serimizde kurumsal organizasyonlarda hazırlanmış Microsoft Office doküman şablonlarının active directory domaininde bulunan kullanıcılara active directory logon script kullanılarak merkezi bir sunucudan dinamik olarak dağıtımını tüm detaylarıyla inceledik. Başka bir makalemizde görüşmek dileğiyle sağlıcakla kalın.

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Geçen günlerde geliştirme sürecinde “Windows Server Technical Preview 2” sürümü yayınlandı. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Ürünün resmi adının ne olacağı konusunda şu an henüz net bir bilgi yok. Benim şu an için tahmin ettiğim, “Windows Server 2016” olacağı yönünde. Önceki sürümlerde olduğu gibi Windows Server 2016 ile birlikte “Cloud OS” yapısını oluşturan bir diğer ürün grubu olan “System Center” ürün ailesi de geliyor olacak. Böylece “Cloud OS” yapısının birlikte oluşturan “Windows Server” ve “System Center” ürünleri ile yeni nesil istemci işletim sistemi Windows 10 birlikte yeni bir dönemi başlatıyor olacak. Windows Server 2016 için şu an daha çok erken olmasına rağmen heyecan verici çok sayıda yeniliği beraberinde getireceğini belirtebiliriz. Bu makalemizde sizlere şu an için “Windows Server Technical Preview 2” sürümüne ile gelen ve gelmesini beklediğimiz diğer yeniliklerden bahsediyor olacağız. Ürün şu an için geliştirme aşamasında olduğundan dolayı anlatacağımız özelliklerde ya da arayüzde resmi sürümde farklılıklar ya da özelliklerin kaldırılması ya da eklenmesi gerçekleşebilir. Biz de zaman içerisinde çıkacak yeni sürümlerdeki yenilikleri bu makalemizi baz alarak güncellemeye ve en hızlı şekilde sizlerle paylaşmaya çalışacağız.

KURULUM SÜRECİ

Bu bölümde sizlerle Windows Server Technical Preview 2 kurulumuna ve kurulum sonrası yeni özelliklere hızlıca bakıyor olacağız.  

Windows Server Technical Preview 2 ISO’su ile kurulum sürecini başlattığımızda  karşımıza kurulumun ilk adımı olan aşağıdaki ekran gelecektir.

Bu ekranda “Language to install” liste kutusundan kurulacak işletim sistemi dili, “Time and currency format” liste kutusundan sistemin dil, saat ve parasal biçiminin hangi dilde olacağı,  “Keyboard or input method” liste kutusundan da klavye dilini seçiyoruz.

Next ile bir sonraki aşamaya geçiyoruz.

Karşımıza kurulumun ikinci aşaması olan aşağıdaki ekran gelecektir.

Gelen ekranda “Repair your computer” seçeneği kullanılarak mevcut kurulu Windows Server 2012 R2 işletim sistemi ile ilgili kurtarma seçeneklerinin bulunduğu moda geçebilirsiniz. Örneğin, mevcut işletim sisteminizin dosyalarında bir zarar görme ya da bozulma durumu oluşmuşsa bu seçenek kullanılarak bu dosyaların onarılarak mevcut işletim sisteminin tamir edilmesi sağlanabilir.  “Repair your computer” seçeneklerini ileriki bölümlerde detaylı olarak inceliyor olacağız. Biz bu aşamada henüz yeni bir işletim sistemi kurulu gerçekleştireceğimiz için “Install now” ile sonraki adıma ilerliyoruz.

“Select the operating system you want to install” ekranında ISO ya da DVD içerisinde mevcut bulunan Windows Server Technical Preview 2 sürümleri listelenir.

Hangi işletim sistemi sürümünü kuracaksak bu listeden seçiyoruz. Biz ISO dosyasından kurulum yaptığımız için gelen seçenekler buna göre geliyor. Gelen listede eski versiyonlar da “Server Core Installation” olarak geçen ifade yerine şimdilik “Windows Server Technical Preview 2” geliyor. Yine önceki versiyonlarda “Server with a GUI” olan madde yerine de “Windows Server Technical Preview 2 (with local admin tools)” olarak geliyor. Grafiksel arayüzün bulunduğu sürümü kuracaksanız  “Windows Server Technical Preview 2 (with local admin tools)” şeklinde listeleneni, tamamen komut satırı tabanlı sürümü kuracaksanız da “Windows Server Technical Preview 2” ile belirtileni seçmeniz gerekiyor. Ürün şu an henüz geliştirme sürecinde olduğu için benim tahminim bu seçenekler yine eskiden olduğu gibi benzer tanımlarla devam edecektir. Şimdilik bu tanımlamalara çok fazla nihai ve kalıcı olarak bakmamanızı tavsiye ederim. Önemli olan genel olarak neler geliyor inceliyor olmamız.  Biz bu aşamada “Windows Server Technical Preview 2 (with local admin tools)” seçeneği seçili iken Next ile sonraki adıma ilerliyoruz.

Bu aşamada gelen “License terms” altında lisans anlaşması metni gelecektir.

“I accept the license terms” kutucuğunu işaretleyerek şartları kabul edip, Next ile bir sonraki adıma geçiyoruz.

Karşımıza “Which type of installation do you want?” ekranı gelecektir. “Upgrade:Install Windows and keep files, settings, and applications” ve “Custom : Install Windows only (advanced)” kurulum seçeneklerinden gerçekleştirmek isteğimiz kurulum tipini seçiyoruz.

Eski versiyon Windows Server sürümünden (örneğin Windows Server 2012 ya da Windows Server 2012 R2 gibi) Windows Server 2016 işletim sistemine yükseltme yapacaksanız “Upgrade:Install Windows and keep files, settings, and applications” seçeneğini kullanıyoruz. Böylece mevcut işletim sistemi üzerindeki tüm uygulamalar, ayarlar korunarak Windows Server 2016 işletim sistemine yükseltme yapılmış olacaktır. Biz şu an için tamamen yeni bir Windows Server Technical Preview kurulumu için “Custom : Install Windows only (advanced)” seçeneği üzerine tıklayarak devam ediyoruz.

Karşımıza aşağıdaki şekilde görülen “Where do you want to install Windows” ekranı gelecektir. Bu adımda Windows Server Technical Preview 2 işletim sistemini hangi volume üzerine yükleyeceksek bu seçimi gerçekleştirmekle ilgili yapılandırmaları gerçekleştireceğiz.

Bu ekranda sürücü problemlerinden dolayı diski görmeme vb. durumlarda “Load Driver” seçeneği ile disk üreticisinden gelen uygun sürücüler yüklenerek disk medyasının tanınması sonrası adımlara devam edilebilir. Sunucu üzerine tanıtılmış fakat henüz bölümleme yapılmamış diskler bu aşamada bölümlenmemiş “Unallocated space” alanı olarak listelenir. Fiziksel ya da sanal sunucuya toplamda kaç farklı disk takılı ise o kadar disk listede gelecektir. Diski birden fazla farklı birimlere (volume) bölmek isterseniz alt kısımda gelen “New” seçeneğini kullanabilirsiniz. Biz şu an tek bir disk takılı olduğu ve bunun tamamına Windows Server Technical Preview kurulumu yapacağımız için  “Unallocated space” alanı seçili iken ilerliyoruz. Diskin tamamı tek bölüm olarak NTFS dosya sistemi ile biçimlendirilecek ve bu bölüme Windows Server Technical Preview 2 kurulumu yapılmış olacaktır. “Unallocated space” alanı seçili iken “Next” ile sonraki adıma ilerliyoruz.

Karşımıza gelen “Installing Windows” aşaması ile artık kurulum sürecini başlatmış olduk.

Bu aşamada artık Windows Server Technical Preview işletim sistemi kurulum dosyaları disk üzerine kopyalanıp, dosyalar kurulum için hazırlanacaktır. Kurulum sürecinde temel işletim sistemi bileşenleri ve özellikleri yüklenecek, kurulum medyasında gelen güncellemeler yapılacak ve kurulum süreci tamamlanmış olacaktır. Bu süreci “Installing Windows” ekranında takip edebilirsiniz.

Kurulum tamamlanınca sistem yeniden başlatılacak ve ilk açılışta karşımıza aşağıdaki şekilde de görülen “Administrator” kullanıcı hesabı için şifre tanımlaması ekranı gelecektir.

Şifre tanımlamamızı yaptıktan sonra ilk logon sürecini başlatıyoruz. Windows Server Technical Preview 2 sunucumuza ilk defa giriş yaptığımızda karşımıza yine önceki sürümlerdeki gibi kullanıcı arayüzü ve  “Server Manager” yönetim aracı gelecektir.  

Server Manager aracında ilk açılışta bir Dashboard ekranı bizi karşılar. Dashboard içerisindeki kısayolları kullanarak sunucumuza rol ya da özellik ekleme, uzaktan yönetmek istediğimiz diğer sunucuları ekleme ve sunucumuz üzerinde yüklü rollerin genel sağlık durumları hakkında bilgiler alabilirsiniz. Logon olduğumuz sunucu ile ilgili detaylar için sol tarafta gelen Local Server seçeneğini kullanabilirsiniz.

Local Server sayfasına geçince karşımıza sunucumuza ait aşağıdaki bilgiler ve bu bilgilerin yapılandırılmasına ilişkin bağlantı kısayollarını bulacaksınız:

·       Bilgisayar adı

·       Domain ve Workgroup tanımları

·       TCP/IP tanımları

·       Bölgesel ayarlara ait bilgiler ve yapılandırma bağlantıları envanter bilgileri ve diğer detaylar gelecektir. Server Manager ile rollerin kurulumu, incelenmesi ve detaylar diğer makalelerde inceliyor olacağız.

Windows Server Technical Preview 2 arayüzü ve genel çalışma ortamı olarak Windows Server 2012 ve Windows Server 2012 R2’ye benzer bir ortama sahip. Kurulum kısmına genel olarak bir göz attık şimdi de şu anki sürüm itibariyle gelen yenilikleri inceleyelim.

Active Directory Domain Servislerde Neler Geliyor?

Windows Server Technical Preview 2 ile Active Directory Domain Servislerinde (AD DS) özellikle active directory ortamlarının güvenliğini artırmaya, buluta-taşıma ya da hibrid mimaride bir kısmı kendi veri merkezinizde bir kısmı bulutta host edilen servislerin desteklenmesine yönelik geliştirmeler geliyor.

Şimdilik gözüken yenilikleri genel olarak sıralarsak:

·       Privileged Access management

·       Azure AD Join

·       Microsoft Passport

·       Windows Server 2003 Domain Controller Desteği Kalkıyor

·       Windows Server 2003 Functional Level Desteği Kalkıyor

·       File Replication Service (FRS) Desteği Kalkıyor

Privileged Access management: Active Directory ortamlarında erişim yetki yönetimi IT departmanları için hala tam anlamıyla oturtulamamış ciddi bir sorun esasında. Günlük işler için kullanılan standart kullanıcı hesaplarına yönetimsel bazı operasyonlar ya da uygulamaların yetki kısıtlarından dolayı domain admins ya da lokal admins yetkisi vererek kullanmaya devam eden çok sayıda örnek görebilirsiniz. Gerçekleştirdiğimiz projelerde ve danışmanlık verdiğimiz yapılarda ciddi bir güvenlik problemi olan bu durumu düzeltmek için elinizden geleni yapsanız da belli bir süre sonra tekrar eski davranışlara geri dönülüyor. Çünkü domain admin ya da local admin gerektiren operasyonlarda arka planda yapılacak işi bu yetkilere sahip bir hesapla gerçekleştirmek için kurum ya da kuruluşlar ilave 3.parti yetki yönetim çözümü ürünlerine başvurarak oluşan güvenlik açığını bu şekilde gideriyorlardı. Microsoft Windows Server 2016 ile bu alanda kendi çözümünü getiriyor : Privileged Access Management yani PAM. PAM, Active Directory ortamlarından güvenliği artırmaya yönelik bir yenilik. Özellikle kullanıcı kimlik bilgilerinin çalınması için kullanılan hash bilgisini ele geçirme, phishing benzeri saldırılara karşı yeni bir güvenlik mekanizması. Microsoft Identity Manager (MIM) kullanılarak yapılandırılan yeni bir yönetimsel erişim çözümü. Bu yeni çözüm sayesinde kullanıcı hesaplarına yönetimsel yetkilere sahip olmaları gereken durumlarda gerekli olan süre için yetki verilip sonrasında otomatik olarak alınmasını sağlıyor olacak. Bu özellik aslında şu anda PowerShell üzerinde de delegasyonda kullanılan Just-Enough-Administration (JEA)üzerine inşa edilen ve Just-In-Time (JIT) Administration olarak adlandırdığımız yönetim biçimi. PowerShell cmdletlerin çalıştırılmasını kısıtlamada kullanılan bir delegasyon yöntemi. JEA kabiliyetleri Window Server 2016 ile beraber sunucu tarafında diğer servislere de genişletilecek gözüküyor. Bu modelde yönetimsel yetkilerin minimum sayıda kullanıcıya verilmesi hedefleniyor. Bu yapıdaki bir diğer hedef de yetkili hesapların tamamen yeni kurulmuş ve güven ilişkisine sahip ayrı bir forest içerisinde tutulması hedefleniyor. Bu yapıda yetkili hesapların kullanımında standart kimlik doğrulama mekanizmalarına ilaveten daha güçlü ve ilave kontrol katmanlarının da etkinleştirilmesi sağlanmış olacak. Burada kafanızı karıştıran yüksek erişimli hesaplar için tamamen ayrı bir forest kurulması olabilir. Fakat mevcut active directory schema’yı genişletme ihtiyacı olmadan tamamen yetki ve hak yönetim amaçlı hesapları tutacak yeni bir forest kurulacak. Bu tip kullanım için yeni bir cross-forest güven ilişkisi geliyor. Bu yeni forest içerisinde mevcut forest içerisindeki gruplarla aynı SID (security identifier) değerine sahip güvenlik grupları oluşturulmuş olacaktır.Bu yapının yönetimini GUI arayüzünden yapmak için de Microsoft Identity Manager (MIM) ürününün kullanıyoruz. MIM, resmi adı FIM(Forefront Identity Manager) olan Microsoft’un kimlik yönetim ürünü ve yeni versiyonunun da 2015 son çeyreğinde çıkmasını bekliyoruz. Esasında burda yapılacak operasyon belli bir süre için kullanıcıları yetkiye sahip yönetimsel gruplara üye yapmak ve belirlenen sınırlı zaman sonunda otomatik olarak gruptan çıkartıp standart kullanıcı durumuna almaktır. Arka planda Kerberos Key Distribution Center (KDC) altyapısı da bu özelliğ destekleyecek şekilde belli bir süre limitli Kerberos token yayınlama desteği ile geliyor. Bu süreçleri tanımlarken hesaplar için kullanılacak kimlik doğrulaması (smart kart ya da PIN vb.) gibi koşullar da belirleniyor. Bu tip kullanım Azure Active Directory (AAD) ile buluta da genişletiliyor olacak. Bu özelliğin kullanılabilmesi için mevcut active directory forest fonksiyonel seviyesinin Windows Server 2012 R2 ya da üzerinde olması gerekir.

Azure AD Join : Kurumsal cihazların bulut domaini olan Azure Active Directory yapısına üye yapabilme desteği. Bu özelliğin öncelikle Azure hesabında aktifleştirilmesi sonrasında aygıtları Azure Active Directory yapısına üye yapabiliyoruz.

Microsoft Passport : Microsoft password anahtar-tabanlı yeni kimlik doğrulama mekanizmasıdır. Password güvenliğinin de ötesine geçerek, kullanıcının kullandığı aygıta bir biometric yöntemlerle (parmak izi vb.) ya da PIN kodu ile giriş yapmasına göre tasarlanmış bir yapı. Özellikle sisteme login olmak isteyen kullanıcının password hash bilgisinin kimlik doğrulama sürecinde ağ üzerinden ele geçirilme ya da çalınma gibi durumlarına karşı geliştirilen yeni bir güvenlik mekanizması.

Windows Server 2003 Domain Controller Desteği Kalkıyor : Windows Server 2012 R2 ve öncesindeki sürümler için active directory geçişleri esnasında aynı anda Windows Server 2003 domain controller ile Windows Server 2012 R2 domain controller aynı domain içerisinde birlikte çalışabiliyordu.Windows Server 2016 ile aynı domain ortamında Windows Server 2003 domain controller ile Windows Server 2016 domain controller sunucuların birlikte çalışma desteği kalkıyor. Temmuz 2015 itibariyle Windows Server 2003 için destek sona erdiğini düşünürsek çoğu kurum ve kuruluş bu yapıya hazır olacağını düşünüyorum.

Windows Server 2003 Functional Level Desteği Kalkıyor : Windows Server 2016 active directory geçişi için sahip olduğunuz forest ve domain fonksiyonel seviyesinin minimum Windows Server2008 seviyesinde olması gerekecek. Temmuz 2015 itibariyle Windows Server 2003 için destek sona erdiğini düşünürsek çoğu kurum ve kuruluş bu yapıya hazır oluyor olacaktır.

File Replication Service (FRS) Desteği Kalkıyor : FRS active directory domain yapılarında domain controller sunucular arasında SYSVOL klasör içeriğinin replikasyonunu gerçekleştirmeyi sağlayan replikasyon servisidir. Daha güçlü ve tutarlı bir servis olan DFSR çıkışıyla artık FRS kullanımı azalmaya başladı. Windows Server 2008 ve üzerinde active directory domain seviyesinde çalışan çoğu organizasyon SYSVOL replikasyon mimarisini FRS’de DFSR’a yükseltmişlerdir. Windows Server 2016 active directory geçişi öncesinde eğer hala FRS kullanıyorsanız bunu öncelikle DFSR’a yükseltmeniz gerekecek. Çünkü Windows Server 2016 ile beraber FRS desteği tamamen kalkıyor.

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext geliştirme sürecinde “Windows Server Technical Preview 2” sürümü ile gelen yeniliklerin özellikle “Active Directory Domain Servisleri” kısmını sizlerle genel olarak paylaştık. Makalenin başlangıcında da belirttiğimiz gibi ürün şu an için geliştirme aşamasında olduğundan dolayı anlattığımız özelliklerde ya da arayüzlerde ilerki sürümlerde farklılıklar ya da özelliklerin kaldırılması, eklenmesi gerçekleşebilir. Windows Server Technical Preview 2 ile gelen yenilikleri ikinci makalemizde incelemeye devam edeceğiz.

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext ile gelen yenilikleri incelemeye devam ediyoruz. Makalemizin ilk bölümünde özellikle Active Directory Domain Service için gelen yenilikleri incelemiştik. Bu bölümde diğer özellikleri incelemeye devam edeceğiz.

İlk makalemizde de belirttiğimiz gibi Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Geçen günlerde geliştirme sürecinde “Windows Server Technical Preview 2” sürümü yayınlandı. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Hyper-V Dünyasında Neler Geliyor?

Windows Server Technical Preview 2 Hyper-V rolünde gelen yenilikleri sıralayacak olursak:

·       Hyper-V Cluster Upgrade Yenilikleri 

·       Storage quality of service (QoS)

·       Sanal Sunucular İçin Konfigürasyon Versiyonu

·       Yeni Nesil Sanal Sunucu Konfigürasyonu Dosya Formatı

·       Yeni Nesil Snapshot Özelliği : Production Checkpoint

·       Hyper-V Manager Aracında Yenilikler

·       Windows Update Üzerinden Integration Service Dağıtımı

·       Kesintisiz NIC ve Memory Ekleme/Çıkarma

·       Linux Secure Boot

·       Connected Standby Uyumluluğu

Hyper-V Cluster Upgrade Yenilikleri  : Mevcut yapıda çalışan bir Windows Server 2012 R2 Hyper-V Cluster yapısına Windows Server Technical Preview 2 Hyper-V sunucusunu dahil edebilme desteği geliyor. Bundan önceki sürümlerde Hyper-V yükseltme projelerinde yeni versiyonla yeni bir cluster yapısı kurup, eski versiyondaki iş yüklerini bu yeni Hyper-V Cluster yapısına taşıyorduk. Windows Server Technical Preview 2 Hyper-V sunucular ile beraber artık yeni bir cluster kurmaya gerek kalmadan mevcut Windows Server 2012 R2 cluster yapısına “Node” olarak ilave edip geçişi gerçekleştiriyoruz. İlk etapta Cluster yapısı Windows Server 2012 R2 Cluster fonksiyonel seviyesinde çalışmaya devam edecek. Ve bu yapıda sanal sunucular Windows Server 2012 R2 ve Windows Server Technical Preview 2 arasından live migration vb. operasyonları destekleniyor. Tüm Hyper-V sunucular Windows Server Technical Preview 2 versiyonuna geçiş yapıldıktan sonra Cluster fonksiyonel seviyesini Windows Server Technical Preview 2’ye yükseltiyoruz. Bu yükseltme operasyonunu PowerShell komut satırından Update-ClusterFunctionalLevel cmdlet ile gerçekleştiriyoruz. Bu yükseltme sonrası Windows Server Technical Preview 2 Hyper-V ile gelen yenilikleri kullanabiliyor olacaksınız. Bu yükseltme yapılmadan Hyper-V tarafında gelen yenilikler aktif olmayacaktır. Windows Server 2012 R2 cluster fonksiyonel seviyesinde çalışan yapıda cluster, Hyper-V sunucular ve sanal sistemlerin yönetimi Windows Server Technical Preview 2 ya da Windows 10 Technical Preview sistemlerinden yapılabiliyor. Cluster fonkssiyonel seviyesi Windows Server Technical Preview 2’ye yükseltilmeden sanal makine konfigürasyon versiyonlarının da yükseltilmesi desteklenmiyor. Yükseltme sonrasında yine PowerShell komut satırından Update-VmConfigurationVersion cmdlet ile makine konfigürasyon versiyonlarının yükseltilmesini gerçekleştirebilirsiniz.

ÖNEMLİ NOT : Cluster fonksiyonel seviyesi Windows Server Technical Preview 2 yükseltildikten sonra tekrar Windows Server 2012 R2 fonksiyonel seviyesine geri dönüş desteklenmiyor. Windows Server Technical Preview 2 Cluster fonksiyonel seviyesine yükseltilen bir Hyper-V cluster yapısına artık Windows Server 2012 R2 Hyper-V sunucu eklenmesi desteklenmez.

Storage quality of service (QoS) : Windows Server Technical Preview 2 Hyper-V ile beraber Scale-Out File Server (SOFS) üzerine kurulu Hyper-V cluster mimarilerinde sanal diskler için storage QoS(Quality of Services)  politikaları uygulama desteği de geliyor. Böylece storage performansı belirlenen politikalara göre otomatik olarak davranış gösteriyor.

Sanal Sunucular İçin Konfigürasyon Versiyonu : Windows Server 2012 R2 Hyper-V sunucular üzerinde çalışan bir sanal sunucuyu Windows Server Technical Preview 2 Hyper-V sunucu üzerine taşıdığınızda ya da import ettiğinizde sanal sunucunun konfigürasyon dosyası otomatik olarak güncellenmiyor. Böylece yeni versiyon üzerinde oluşabilecek olumsuz durumlarda ya da üzerinde çalışan bir uygulamadan dolayı desteklenmeme gibi sorunlarda tekrar Windows Server 2012 R2 üzerine geri alabiliyor durumdayız. Fakat yukarıda bahsettiğimiz cluster fonksiyonel seviyesinde olduğu gibi sanal sunucuların konfigürasyon versiyonunu da Windows Server Technical Preview yükseltmeden yeni gelen sanal sunucu özelliklerini kullanamıyor durumdayız. Bir diğer deyişle sanal sunucunun konfigürasyon versiyonu o sanal sunucunun hangi Hyper-V versiyonundaki sunucularla uyumlu olduğunu gösterir. Sanal sunucu konfigürasyon versiyonunu manuel olarak yükseltiyoruz. Windows Server 2012 R2 uyumlu sanal sunucuların konfigürasyon versiyonu “5”’dir. Bu sanal sunucular hem Windows Server 2012 R2 hem de Windows Server Technical Preview 2 Hyper-V üzerinde çalışabilir. Sanal sunucu konfigürasyon versiyonu “6” ya yükselttikten sonra bu sanal sunucuların Windows Server 2012 R2 üzerinde çalışması desteklenmemektedir.

Mevcut durumda çalışan sanal sunucuların versiyon bilgisi için aşağıdaki gibi PowerShell komut satırından Get-VM cmdlet kullanarak Version özelliğinden elde edebilirsiniz.

Mevcut durumda çalışan sanal sunucuların versiyon yükseltmesi için de yine PowerShell komut satırından Update-VmConfigurationVersion cmdlet kullanıyoruz. Gördüğünüz gibi Windows Server Technical Preview ile PowerShell cmdletler daha renkli J Ve bu komutun kategorisine göre otomatik gelen bir özellik.

ÖNEMLİ NOT : Sanal sunucuların versiyon yükseltmesi sonrasında aşağıdaki durumlarla  karşılaşacaksınız:

·       Bu sanal sunucular artık Windows Server 2012 R2 Hyper-V sunuculara taşınamazlar.

·       Konfigürasyon versiyonu yükseltilen sanal sunucuların versiyonu 6’dan tekrar 5’e çekilemez.

·       Sanal sunucuların konfigürasyon versiyonunun yükseltilebilmesi için sanal sunucunun tamamen kapatılması gerekir. Bu da bir anlamda kesinti anlamına geliyor.

·       Cluster fonksiyonel seviyesi Windows Server 2012 R2 olan Hyper-V cluster yapılarından  Update-VmConfigurationVersion cmdlet bloklanmıştır. Dolayısıyla bu cmdlet kullanılabilmesi için cluster fonksiyonel seviyesinin Windows Server Technical Preview yükseltilmesi gerekir.

·       Sanal sunucuların konfigürasyon versiyonunun yükseltilebilmesi sonrasında yeni konfigürasyon dosya formatlarını kullanıyoruz.

Yeni Nesil Sanal Sunucu Konfigürasyonu Dosya Formatı : Windows Server Technical Preview 2 Hyper-V ile beraber artık sanal sunucuların konfigürasyon dosyaları formatı da değişiyor. Yeni formatla artık sanal sanal sunucu konfigürasyon bilgilerinin yazılması ve okunması çok daha sağlam, güvenli, performanslı ve verimli bir yapıda gerçekleşecek şekilde tasarlanmış. Ve özellikle storage hataları ya da problemlerinde konfigürasyon dosyalarındaki bozulmalar da en aza indirgenecek şekilde düzenlenmiş. Yeni konfigürasyon dosyaları:

·       .VMCX : Sanal sunucu konfigürasyon verilerini tutar.

·       .VMRS : Çalışma zamanı durum bilgisi tutar.

.VMCX binary formatında bir dosyadır. Hem .VMCX hem de .VMRS doğrudan düzenlenemez ya da içeriklerinde değişiklik yapılması desteklenmez.

Yeni Nesil Snapshot Özelliği,  Production Checkpoint : Windows Server Technical Preview 2 Hyper-V ile beraber artık sanal sunucular için iki farklı snapshot (checkpoint) geliyor: Standart CheckPoint ve Production Checkpoint. CheckPoint kavramı Hyper-V dünyasında snapshot teknik deyiminin karşılığı. Windows Server 2012 R2 Hyper-V ile beraber Snapshot kavramı System Center Virtual Machine Manager ürünündeki kullanımla da paralellik göstermesi açısından CheckPoint olarak isim değiştirdi. Kullanım amacı çalışır durumdaki bir sanal sunucunun disklerinin, CPU ve memory bilgisi, donanım konfigürasyonu, durum bilgisi ve verileri ile ilgili anlık yedeğini oluşturmaktır. Böylece gerçekleştireceğimiz bir aksiyon sonrası oluşabilecek olumsuz durumlarda alınan snapshot geri dönerek sağlıklı kopyayı etkinleştirmiş oluyoruz. Standart checkpoint bildiğimiz eski checkpoint operasyonu. Production checkpoint ise yeni bir özellik ve saved state teknolojisi yerine sanal sunucu üzerindeki VSS altyapısını kullanarak veri-tutarlı yedeklemeyi destekleyecek snapshot almayı sağlıyor.

Bu yeni checkpoint sayesinde artık sanalda çalışan ve veritabanı yapısını sahip SQL Server, Exchange Server gibi veri-yoğun sanal sistemlerin snapshot alıp, ihtiyaç durumunda bu snapshotlara geri dönüldüğünde sadece uygulamanın değil verilerin de tutarlı bir biçimde geri yüklenmesi sağlanıyor. İhtiyaç durumunda göre Production checkpoint alınamamsı durumunda Standart checkpoint alınacak şekilde de yapılandırabiliyoruz(Fallback yeteneği).

Hyper-V Manager Aracında Yenilikler : Windows Server Technical Preview 2 Hyper-V ile beraber Hyper-V yönetim konsolunda da yenilikler var:

·       Uzaktaki bir Windows Server Technical Preview ya da Windows 10 Technical Preview Hyper-V host bağlanırken alternatif kullanıcı hesabı bilgileri desteği.

·       Windows Server Technical Preview Hyper-V Manager ile artık eski versiyon Windows Server 2012, Windows Server 2012 R2, Windows 8 ya da Windows 8.1 Hyper-V sistemleri yönetebiliyoruz.

·       Windows Server Technical Preview Hyper-V Manager Hyper-V hostlarla WS-MAN protokolü üzerinde haberleşiyor. WS-MAN protokolü ile CredSSP, Kerberos ve NTLM kimlik doğrulama methodlarını destekleniyor. Ayrıca WS-MAN protokolü 80 portu üzerinden erişim sağladığı için network katmanındaki operasyonları ve erişim standartları açısından da avantajlar sağlıyor.

Windows Update Üzerinden Integration Service Dağıtımı : Windows Server Technical Preview Hyper-V ile sanal sunucular için Integration Service paketleri artık Windows Update servisi üzerinden dağıtılıyor durumda. Böylece integration service ISO dosyasını kullanarak yükleme gereksinimi ortadan kalkmış oluyor. Özellikle servis sağlayıcıların (hoster) müşteri sistemleri (tenant) için Windows güncellemeleri dağıtımında artık sanal sunucu için integration service güncellemeleri de yapılmış durumda olacak. Windows Server Technical Preview artık eskiden kullanılan vmguest.iso dosyasını da içermiyor.

Kesintisiz NIC ve Memory Ekleme/Çıkarma : Windows Server Technical Preview 2 Hyper-V ile sanal sunucu çalışıyorken kesinti olmaksızın ağ kartı aygıtı eklenip, çıkartılabiliyor. Bu özellik sadece Generation 2 sanal sunucular için hem Windows hem de Linux tabanlı işletim sistemleri için destekleniyor. Yine sanal sunucu çalışıyorken kesinti olmaksızın memory ilave etme ya da azaltma operasyonları servis kesintisi olmadan yapılabiliyor. Dynamic Memory aktif edilmemiş durumda da bu özellik destekleniyor. Memory değerinde artırma ve azaltma durumu hem Generation 1 hem de Generation 2 sanal sunucular için destekleniyor.

Linux Secure Boot : Windows Server Technical Preview 2 Hyper-V ile Linux işletim sisteminde çalışan Generation 2 sanal sunucular için secure boot desteği geliyor. Sanal sunucunun ilk açılışından önce Microsoft UEFI Certificate Authority kullanması için gerekli tanımlamayı yapmanız gerekiyor. Bu işlem için yine PowerShell komut satırında aşağıdaki komut icra ediyoruz:

Connected Standby Uyumluluğu : Always On/Always Connected (AOAC) güç modelini destekleyen bilgisayarlar üzerinde Hyper-V rolü etkinleştirildiğinde artık Connected Standby güç durumu destekleniyor. Özellikle Surface aygıtlarında karşılaştığımız ve üzerinde Hyper-V rolü etkinleştirildiğinde devre dışı kalan Connected Standby güç durumu artık devre dışı kalmıyor J Eski Hyper-V versiyonlarında ise Hyper-V rolü etkinleştirildiğinde sadece Hibernate ve Fast Startup güç durumları destekleniyor, Connected Standby etkinliğini kaybediyordu. Bu durumda da Surface cihazımız bir PC gibi çalışıyor, kapağını kapattığınızda cihaz uyku moduna geçmiyordu.

Yeni Nesil Client İle Geliyor ?

Windows Server Technical Preview 2 sunucu işletim sisteminin istemci (client) işletim sistemi de Windows 10 Technical Preview. Dolayısıyla Windows Server Technical Preview özelliklerinin istemci tarafı ile ilgili olanları Windows 10 Technical Preview üzerinde de geliyor.

Yeni İşletim Sistemi Dağıtımı : Windows Server Nano  

Windows Server vNext ile yeni bir işletim sistemi kurulum seçeneği geliyor : Windows Server Nano. Şu an için Windows Server Technical Preview 2 sürümü üzerinde henüz bu seçenek yok. Bundan bir sonraki çıkacak sürümde gelmesini bekliyoruz. Windows Server Nano, Windows Server işletim sisteminin 64-bit mimaride çalışan, komut satırı tabanlı bir dağıtımı. Windows Server 2012 R2 ya da Windows Server 2012 R2 Core’dan farkı konsol arayüzünün olmadığı, mikroservisler için tasarlanmış yeni bir dağıtım. Server Core sürüme göre daha da küçültülmüş bir sürüm. Windows Server 2012 R2 Core sürümü için kapladığı alan 4 GB iken, Windows Server Nano için bu değer 0.4 GB boyutunda.

Windows Server ve Windows Server Nano karşılaştırıldığında elde edilen sonuçlar:

·       Yüzde 93 daha küçük VHD boyutu

·       Yüzde 92 daha az kritik güncelleme gereksinimi

·       Yüzde 80 daha az yeniden başlatma gereksinimi

Bu kazanımlar aşağıdaki aksiyonlarla sağlanmış durumda:

·       Grafik arayüzü kaldırılmış

·       32-bit desteği (WOW64) kaldırılmış

·       MSI ve Server Core bileşenlerinden bazıları kaldırılmış

·       Yerel oturum açma desteği yok

·       Uzak masaüstü oturum açma desteği yok

·       Yönetim tamamen uzaktan özel olarak tasarlanmış web-tabanlı yönetim konsolu, Server Manager konsolu, PowerShell ya da WMI ile sağlanıyor.

·       Sonradan isteğe bağlı Windows Rol ya da feature eklenebiliyor. Fakat bu rol ya da feature’lara ait binary’ler işletim sistemi üzerinde mevcut değil.

·       Büyük oranda yönetim, kontrol ve izleme için PowerShell Desired State Configuration bileşeni kullanılıyor.

Nano Server ihtiyacı özellikle uzun yılların birikimi, müşteri talepleri ve bulut teknolojilerinin geldiği nokta ile ön görülen yol haritası da göz önünde bulundurularak aşağıdaki ihtiyaçlara cevap verecek şekilde geliştiriliyor:

·       Mümkün olan en minimum seviyede yama ve yeniden başlatma ihtiyacı

·       İşletim sistemi imajlarında çok daha küçük boyutlar

·       İşletim sistemi hazırlanması ve provizyonlama sürecinde mümkün olan en az kaynak kullanımı (özellikle bulut mimarisine hizmet veren sunucular için)

·       Windows Server sürücü desteği Nano server için de geliyor.

·       İşletim sistemi provizyonlama süresinin daha da azaltılması

·       Sunucu rolleri ve isteğe bağlı feature’ların Nano Server dışına çıkartılması

·       Yerel yönetim araçları yerine web tabanlı grafiksel yönetim araçları (Azure Portal benzeri)

·       Nano Server üzerinde gelen rol ve feature’lar : Hyper-V, Clustering, Storage rolleri, Core CLR, ASP.NET vNext, PaaSv2 ve Container’lar.

·       Nano server üzerinde yerleşik olarak Antimalware koruması geliyor.

Windows Nano Server gelecek kuşak bulut altyapı ve uygulamalarının üzerine inşa edileceği önemli bir sürüm. Güçlü altyapısı ile hem modern bulut altyapılarını güçlendirecek özellikleri barındırması hem de bulut tabanlı uygulamalar için optimize edilmiş olması Windows Nano Server’ı öne çıkaran yenilikler.

Windows Server 2012 ve sonrasında Windows Server Core ve Windows Server GUI modları arasında dönüşüm ya da geçiş feature ekleme ya da kaldırma ile mümkün olabiliyordu. Fakat aynı durumunda Nano Server için olmayacak gözüküyor. Ayrıca Nano Server, Core Edition ya da GUI sürümler gibi tüm rolleri desteklemiyor olacak.

Windows Server Antimalware Koruması

Windows Server Technical Preview 2 sürümü Windows Server Antimalware koruması yüklü ve aktif çalışır durumda geliyor. Windows Server Antimalware sayesinde sunucumuzun bilinen kötü amaçlı yazılımlara karşı aktif bir koruma sağlanmış olacak. Antimalware ile ilgili güncellemeler Windows Update üzerinden sürekli güncelleniyor olacak. İlk kurulumda Windows Server Antimalware için yönetim arayüzü kurulmuyor. Grafiksel aracı kurmadan WMI, PowerShell ya da Group Policy üzerinden yönetimi gerçekleştirebilirsiniz.

 İsteğe bağlı olarak Server Manager yönetim aracından Add Roles and Features Wizard, ya da PowerShell komut satırından Install-WindowsFeature cmdlet ile Windows Server Antimalware grafiksel aracının kurulumunu gerçekleştirebilirsiniz.

PowerShell İle Neler Geliyor?

Windows Server Technical Preview 2 sürümü ile şu an için PowerShell 5.0 sürümü geliyor. Windows PowerShell 5.0 ile Windows-tabanlı ortamların daha kolay ve daha kapsamlı yönetimi ve kontrol edilmesine yönelik önemli yenilikleri içeriyor.

Windows PowerShell 5.0 geriye-dönük uyumluluk desteği ile PowerShell 2.0, PowerShell 3.0 ve PowerShell 4.0 ile geliştirilmiş cmdlet, script, eklenti, fonksiyon vb. yapıları da herhangi bir değişikliğe gerek kalmadan destekliyor.

Windows PowerShell 5.0 şu an için hem Windows Server Technical Preview 2 sürümü ile hem de Windows 10 Technical Preview client ile kurulu olarak geliyor. Windows Server 2012 R2 ya da Windows 8.1 üzerinde kullandığınız PowerShell versiyonunu PowerShell 5.0 yükseltmek için Windows Management Framework 5.0 Preview paketini indirebilirsiniz.

Windows PowerShell 5.0 İle gelen yenilikleri maddeler halinde sıralayacak olursak:

·       $PSVersionTable.PSVersion değeri 5.0 olarak güncellendi.

·       Class kullanım desteği

·       PowerShell CLI’da komut yazımına göre otomatik renklendirme desteği

·       Etiketleme (Tagging) Destekli Write-Information Cmdlet

·       ConvertFrom-String Cmdlet

·       Dosya ve klasörlerin arşivlenmesi için Microsoft.PowerShell.Archive modülü

·       Yazılım paket yönetimi için PackageManagement (OneGet) modülü

·       Modül Arşive Deposu İçin PowerShellGet Modülü ve Register-PSRepository Cmdlet

·       Hidden Anahtar Sözcüğü

·       Get-Command cmdlet Çıktısında Version Özelliği

·       New-Item, Remove-Item, ve Get-ChildItem İçin SymbolicLink Item Tipi

·       Get-ChildItem cmdlet için –Depth parametre desteği

·       Copy-Item cmdlet ile komut satırı tabanlı Server Core ve Windows Nano Server’ı da destekleyecek Windows PowerShell oturumları arası dosya ve klasör kopyalama

·       Windows PowerShell ISE için Transcript Desteği

·       Detaylı PowerShell Script İzleme ve Analiz yeteneği

·       Mesaj Kriptolama Cmdlet Desteği (Get-CmsMessage, Protect-CmsMessage, ve Unprotect-CmsMessage)

·       Microsoft.PowerShell.Utility modülünde yeni cmdletler (Get-Runspace, Debug-Runspace, Get-RunspaceDebug, Enable-RunspaceDebug, ve Disable-RunspaceDebug)

·       Format-Hex cmdlet İle hexadecimal biçimde görüntüleme

·       Get-Clipboard ve Set-Clipboard cmdletler ile Windows PowerShell oturumları arası pano işlemleri

·       Microsoft.PowerShell.Management modülünde Clear-RecycleBin Cmdlet eklentisi

·       Script çalışmaları için New-TemporaryFileİle geçici dosya oluşturma desteği

·       Out-File, Add-Content, ve  Set-Content cmdletler için –NoNewline parametre desteği

·       New-Guid cmdlet

·       Windows PowerShell Scriptlerinde Debug İçin Enter-PSHostProcess ve Exit-PSHostProcess cmdlet desteği

·       Wait-Debugger cmdlet ile Scriptlerde bekletme yeteneği

·       PowerShell Workflow debugger için komut tamamlama ya da tab ile tamamlama desteği

·       PowerShell Job’larında debug işlemleri için Debug-Job cmdlet

·       PowerShell Job’ları için AtBreakpoint Durumu

·       Test-ModuleManifest cmdlet İle modül versiyon doğrulama desteği

·       NetworkSwitch modülü ile Windows Server logo-sertifikalı switch ve VLAN yönetimi

·       Import-Module ve  Remove-Module cmdlet için FullyQualifiedName parametre desteği ile aynı modülün çoklu versiyonlarını saklama ve çağırabilme desteği

·       Save-Help, Update-Help, Import-PSSession, Export-PSSession, ve Get-Command cmletler için FullyQualifiedName parametre desteği ile aynı modülün çoklu versiyonlarını kullanabilme desteği

Yukarıda sıraladığımız Windows PowerShell temel yapısındaki yeniliklere ilave olarak PowerShell Desired State Configuration (DSC) modülünde de önemli yenilikler geliyor. Bunları da genel olarak sıralayacak olursak :

·       PowerShell ile Class kullanım desteği sayesindeWindows PowerShell Desired State Configuration (DSC) kaynaklarının class ile kullanım desteği. Import-DscResource cmdlet ile ilgili modül içerisinde DscResource özniteliklerini çağırabilme desteği.

·       PSDesiredStateConfiguration modülü içerisindeki aşağıdaki cmdletlere ThrottleLimit parametre desteği eklendi. Bu sayede istenilen cmdletin aynı anda paralel olarak kaç sunucu ya da aygıtta o işi yapacağı belirleniyor olacak.

o   Get-DscConfiguration

o   Get-DscConfigurationStatus

o   Get-DscLocalConfigurationManager

o   Restore-DscConfiguration

o   Test-DscConfiguration

o   Compare-DscConfiguration

o   Publish-DscConfiguration

o   Set-DscLocalConfigurationManager

o   Start-DscConfiguration

o   Update-DscConfiguration

·       Merkezi DSC hata raporlama desteği ile hatalar sadece EventLog içerisine değil aynı zamanda merkezi bir konuma da gönderilerek sonradan analiz için kullanılabiliyor olacak.

·       Windows PowerShell ISE içerisinde Configuration ve Node blokları altında DSC kaynaklarının tanımlanmasına ilişkin yenilikler

·       Node blok içerisinde PSDscRunAsCredential ile istenilen kimlik bilgileri ile çalıştırma desteği

·       Configuration deyimi için 32-bit desteği

·       WaitForAll, WaitForAny, ve WaitForSome ile DSC konfigürasyonlarının çapraz sistemler arası senkronizasyonu

·       Delegasyon güvenliğinde Just Enough Administration (JEA)

·       PSDesiredStateConfiguration modülüne eklenen yeni cmdletler

o   Get-DscConfigurationStatus

o   Compare-DscConfiguration

o   Publish-DscConfiguration

o   Test-DscConfiguration

o   Update-DscConfiguration

Windows Server Technical Preview 2 sürümü ile Windows PowerShell 5.0 Integrated Scripting Environment (ISE) konsolunda da bazı yenilikler geliyor:

·       Uzaktaki sunucularda kayıtlı PowerShell script ya da dosyalarınn PowerShell ISE içerisinden düzenlenebilme desteği geliyor. Bu sayede üzerinde PowerShell ISE kurulu olmayan Server Core ya da Nano Server gibi sürümlerin üzerinde bulunan scriptlerinin uzaktan değiştirilebilmesi ve geliştirilebilmesi. Bu tip kullanım durumlarında PSEdit aracını kullanıyorak ilgili dosyanın yolunu tanımlıyoruz.

·       PowerShell ISE içerisinde Start-Transcript cmdlet desteği

·       Break All (Ctrl+B) menü komutu ile yerel ya da uzakta çalıştırılan tüm scriptlerin durdurulması

Ağ Hizmetlerinde Neler Geliyor?

Windows Server Technical Preview 2 sürümü ile ağ hizmetlerinde gelen yenilikler:

·       DHCP Scope’lar üzerinde NAP desteği kalkıyor.

·       DNS Sunucularda DNS Politikaları geliyor. Bu sayede DNS sunucunun DNS sorgularına cevap verme davranışı istemcinin konum, zaman vb. parametrelere göre belirlenerek değişkenlik gösterebilecek.

·       DNS Politikalarında konum-duyarlı DNS, trafik yönetimi, yük dengeleme, split-brain DNS vb. senaryolar uygulanabilecek.

·       PowerShell içerisinde DNS yönetimine yönelik yeni cmdletler

·       Windows Server Gateway rolünde Generic Routing Encapsulation (GRE) tunnelözelliği geliyor. GRE ile müşteri ağı ile dış ağlar arasında tek bir gateway kullanılarak erişim sağlanabiliyor. Bu özellik System Center VMM üzerinden de yönetilebiliyor.

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext geliştirme sürecinde “Windows Server Technical Preview 2” sürümü ile gelen yenilikleri makale serimizin bu ikinci bölümünde sizlerle paylaşmaya devam ettik. Windows Server 2016 çıkışı için henüz çok erken olsa da sizlerle şimdilik görünen yenilikleri paylaşmaya devam ediyoruz. Ürün şu an için geliştirme aşamasında olduğundan dolayı anlattığımız özelliklerde ya da arayüzlerde ilerki sürümlerde farklılıklar ya da özelliklerin kaldırılması, eklenmesi gerçekleşebilir. Biz de zaman içerisinde çıkacak yeni sürümlerdeki yenilikleri paylaşmaya çalışacağız. Windows Server Technical Preview 2 yeniliklerini incelemeye devam edeceğiz. Bir sonraki makalemizde görüşmek üzere esenkalın.

Merhaba, Windows Azure Web sitesi oluşturma özellikleri ile beraber SharePoint Online uygulamalarımızı Windows Azure üzerinde artık host edebiliyoruz. Bu konuda normal hosting firmanıza build etme haricinde Windows Azure üzerine nasıl SharePoint Online uygulaması oluşturulacağını göreceğiz.

Gereksinimlerimiz

1.      Office 365 SharePoint Online

2.      Microsoft Visual Studio

3.      Windows Azure Üyeliği

Gereksinimlerimizin temini ardından Visual Studio yardımı ile yeni bir SharePoint App oluşturuyoruz.

Ok butonu ile devam ediyoruz ve bu  sefer karşımıza SharePoint Online için hangi tipte bir uygulama oluşturacağımızı soran bir pencere açılacak

Mevcut açılan pencere üzerinde Office 365 SharePoint Online adresimize girerek Provider-hosted seçeneğini işaretleyerek Next butonuna basıyoruzç

Karşımıza gelen pencere, uygulamamızın ASP.Net Web form mu yoksa Asp.Net MVC uygulamasımı olacağını seçmemize yarayan ekrandır. MVC olarak seçip devam ediyoruz. ( Bu kısımda eğer siz klasik web form yazmakta daha iyi iseniz yanı aranız MVC ile limoni ise diğer seçeneği de elbet seçebilirsiniz.)

Hemen Next butonuna basmamızın ardından artık uygulamamızın SharePoint tarafından nasıl yetkilendirileceği ile alakalı. Eğer on-prem bir SharePoint kullanıyorsanız sertifikanızı tanıtabilirsiniz. Biz ilk seçenek olan Windows Azure Access control Service seçeneğiniz seçiyoruz.

Bu seçeneği seçer seçmez önceden vermiş olduğumuz SharePoint Online adresimize bağlı hesap ile login olabilmemiz için Connect to SharePoint penceresi açılacaktır. Gerekli bilgileri doldurarak Sign in diyoruz.

Eğer şansımız da yaver giderse Jartık projemizin oluşmuş halini Visual Studio programımızda görüyor olacağız.

Yukarıdaki ekranda klasik MVC dosya yapısı haricinde AzureApp isminde SharePoint Connection dosyalarının bulunduğu bir settings dosyası daha göreceksiniz. Bu dosyalar sizin SharePoint Online Site Contents alanında bulunan uygulamanızın resim ve config ayarlarını tutar.

Herhangi bir kod ya da tasarım değiştirmeden salt oluşturulan projeyi azure üzerine publish edelim.

Proje üzerine sağ tık ile açılan menüden Publish seçeneğini işaretliyoruz. Web Publish ekranı açılacaktır. Normalde bu aşamada Custom diyerek masa üstümüze ya da herhangi bir yerel diskete de yayınlama yapabiliriz ama biz Microsoft Azure üzerinde yayınlama yağacağımızdan Microsoft Azure Websites seçeneğini seçerek Next ile ilerliyoruz.

Next butonuna bastığımızda mevcut Microsoft Azure aboneliğimizi tanıtmamızı istemektedir. Sign in diyerek login ekranını açıyoruz.

Hemen alttaki iki resimde açılan pencere ve sırası ile email adresi doğrulaması ardından microsoft hesabımızla Azure sistemine login oluyoruz.

Hemen ardından login işlemi tamamlanacak ve Azure üzerinde mevcut web sitelerimiz var ise onların listelendiği bir Dropdown ile karşılacağız. Eğer sistemde herhangi bir tane web sitesi mevcut değil ise new butonuna basarak yenisini oluşturuyoruz.

Aslında burdan sonrası bilgiğiniz klasik azure üzerinde web sitesi oluşturma adımları ile bire bir aynı bir isim secip doğrulandığında create diyoruz.

Web sitesi oluşturulduktan sonra yayınlama alanına otomatik olarak yönlendiriliyoruz. Ayarlar ile oynamadan Next diyerek devam ediyoruz.

İki next ardından karşımıza değişikliklerin ön izlemesini görebileceğimiz bir ekran gelmekte bu ekrande eğer start preview butonuna basarsanız değişen dosyaların isimlerini boyutlarını ve hangi tarihte değiştiklerini görebilirsiniz. Publish diyerek yayınlama işlemini tamamlıyoruz.

Kısabir yayınlama süreci ardından output ekranında gönredilen dosyaları görebiliriz. Bütün dosyalar gönderildikten sonra Success mesajını bekliyoruz.

Yayınlama işlemini Output ekranından takip edebileceğimiz gibi Visual Studio Update 3 ile beraber gelen Web Publish Activity ekranından da yayınlama işlemi görsel olarak takip edilebilir yada sonlandırılabilir.

Evet artık yayınlama işlemimiz bitti. Visual Studio Debug yaparak ( RUN ) projemizi çalıştırıyoruz. Projemiz çalışır çalışmaz bizi Office 365 login ekranına gönderiyor. Bilgileri eksiksiz doldurarak Sign in oluyoruz.

Hemen ardından otomatik olarak yazmış olduğumuz uygulamaya yetki verilecek ekrana yönlendiriliyoruz. Bu kısımda uygulamamızın SharePoint online için güvenilir bir uygulama olduğunu belirterek devam ediyoruz.

Bundan sonrası tamamen zaman alacak  1 yada 2 dakika kadar. Working on it... Bitmesini bekledikten sonra MVC uygulamamız ekranda. Azure üzerine publish ettiğimiz uygulamamız localden test ettiğimizde Office 365 kullanıcı detaylarının ekrana geldiğini göreceğiz.

Bu yazımızda kısaca Microsoft Azure üzerine SharePoint Online Provider Hosted uygulama yayınlama konusuna değinmeye çalıştım. Faydalı olması dileği ile.

Fortigate ve Watchguard arasında IP_SEC VPN kurulumundan bahsedeceğim. Genellikle iki farklı marka Firewall arasında bağlantı kurmak zahmetli ve uğraştırıcı bir işlemdir. Bu nedenle başıma gelmiş olan bu bağlantı ürünü size anlatmak istedim. Yapımızda Datacenter ve Merkez adlı iki lokasyon bulunmaktadır. Merkez Lokasyonumuzda Fortigate 100D V4 MR3 Patch 14 bulunmaktadır. Datacenter Tarafında ise Watchguard XTM 515 Versiyon 11.9.5 bulunmaktadır. Basit bir şekilde açıklamak gerekirse;

Yukardaki şemada gördüğünüz gibi Wan bacakları arasında 192.168.1.0/24 İç Ip bloğu ile 192.168.0.0/24 bloğunu haberleştireceğim. Sözü fazla uzatmadan konuya geçmek istiyorum. İlk olarak Watchguard tarafını anlatacağım.

WATCHGUARD

Bu kısımda ilk olarak Phase 1 ayarlarımızı yapılandırmak için Branch Office Gateway kısmını açıyoruz.

Bu bölümde “ADD” butonunu tıklayarak devam ediyoruz.

Bu bölümümüzde aradaki bağlantı şifresini yazmamız gerekmektedir. Bu şifreyi kayıt edelim. Fortigate tarafında da lazım olacak. Şifremizi yazdıktan sonra “Add” diyerek devam ediyoruz.

Bu bölümde ise Watchguard WAN IP ve Fortigate WAN IP bloklarını yazıyoruz. “External Interface” bölümüne ise hangi WAN bacağından çıkacağımızı belirtmemiz gerekiyor. Ayarlarımızı girdikten sonra “OK” diyerek devam ediyoruz.

Görmüş olduğunuz gibi “Gateway Endpoints” kısmına ayarlarımız gelmiştir. Diğer ayarları yapılandırmak için “Phase 1 Setting” bölümünü açıyoruz.

Burada tüm ayarları yukarıda görmüş olduğunuz şekilde düzenledikten sonra Şifreleme türünü ayarlamak için “Add” diyerek devam ediyoruz.

Bu bölümde ayarlarımızı yukarıdaki şekilde yapmamız gerekmektedir. Bu şekilde ayarlarımızı tamamladıktan sonra artık Phase 2 tarafına geçebiliriz.

“Branch Office Tunnels” bölümünü açtıktan sonra karşımıza aşağıdaki gibi ekran gelmektedir.

Bu kısımda “Add” diyerek devam ediyoruz.

Yukarıda bulunan ayarlar kısman İsim belirledikten sonra “Gateway” bölümünde hangi WAN ı kullanacaksak onu seçiyoruz. Burada dikkat etmeniz gereken ise Alt kısımda bulunan bölümdür. Bu bölümün karşısına tik koyarsanız otomatik olarak sizin adınıza Policy’leri kendisi oluşturacaktır. Gerekli ayarları yapılandırdıktan sonra “Add” diyerek devam ediyoruz.

Burada iki cihaz arasındaki Local Network bilgilerini girmemiz gerekiyor. Local kısımda yazan Watchguard cihazımızın Local bacağıdır. Remote yazan kısımda ise Fortigate Local bacağının IP adresini yazıp “OK” diyerek devam ediyoruz.

Gördüğünüz gibi ayalar bu ekrana düştü. Daha sonrasında ise “Phase 2” ayalarımızı yapmamız gerekmektedir.

Phase 2 bölümünü açtıktan sonra yukarıdaki şekilde ayarları yapılandırdıktan sonra “Add” diyerek devam ediyoruz.

Bu bölümde ise “Authentication ve Encryption ayarlarını yapılandırmamız gerekmektedir. Bu bölümlere dikkat etmeniz gerekmektedir. Zira Fortigate tarafında da bu ayarlara ihtiyacımız olacaktır. Gerekli ayarları yapılandırdıktan sonra “OK” diyerek işlemlerimizi tamamlıyoruz.

Tüm ayarları yapılandırdıktan sonra Policy kısmını açtığınız karşınızda yukarıdaki gibi bir Policy yazıldığını göreceksiniz.

Watchguard tarafındaki ayarlarımızı tamamladık. Şimdi Fortigate tarafındaki ayarları yapılandıracağız.

FORTİGATE

Fortigate tarafında ise işlemler biraz daha kolay gözükmektedir. İlk olarak  “VPN” böülünü açıyoruz.

Bu bölümde “Create Phase “ seçiyoruz.

Karışımıza gelen ekranda ise “Phase 1” ayalarını yapılandıracağız. Yukarıdaki ayarları olduğu gibi girmemiz gerekmektedir. Ayarları girdikten sonra “OK” diyerek çıkıyoruz.

Phase 2 tanımlamamız için “Crate Phase 2” seçeneğini seçiyoruz.

Phase 2 kayıtlarıda bu şekilde olması gerekmektedir. Burada dikkat etmemiz gereken kısım ise DH gruptur. Watchguard üzerinde DH 2 olarak seçmiştik. Burada ise DH 5 olarak seçmemiz gerekmektedir.

Bu işlemleri tamamladıktan sonra Kural oluşturmamız gerekmektedir. Bunu için ilk olarak “Adress” eklememiz gerekmektedir. İlk olarak Fortigate Local bacağı için oluşturuyorum. Yukarıda görüldüğü gibi kayıtları giriyorum.

Bu kısımda ise “Datacenter” ismi ile Watchguard Local Bacağının bilgilerini yazıyoruz.

Son olarak oluşturduğumuz bağlantının veri alışverişi için kural oluşturmamız gerekmektedir. Yukarıda olduğu gibi bir Policy oluşturuyoruz. İşlemleri tamamladığımıza göre artık test işlemlerini yapabiliriz.

Yukarıda görüldüğü gibi IP-SEC VPN çalışır durumdadır.

Cyberoam LAG teknolojisi (Link Aggregation Group) birden fazla fiziksel portun(interface) tek bir port gibi çalışması esasına dayanır. Bu bize yük dengeleme(Load Balance), port yedekliliği(Redundancy), hata toleransı (fault tolerance) sağlayarak yüksek bant genişliği ile kesintisiz hizmet vermenizi amaçlamaktadır.

Cyberoam LAG teknolojisi iki farklı mod desteklemektedir..

1- Active-Backup : Hata toleransı (fault tolerance), ve port yedekliliği sağlayabileceğimiz, trafiğinin aktif port üzerinden aktığı, diğer portların backup durumda kaldığı moddur.

2- 802.3ad LACP : Bu modda yük dengeleme, port yedekliliği ve hata toleransı sağlamaktadır. Tüm portlar trafiği iletme durumundadır.

Not : Lacp modu seçildiğinde kurulum yapılacak switch üzerinde de lacp konfigurasyonları yapılmalıdır.

LAG teknolojisi esasen tüm vendorlarda farklı isimlerde kullanılan bir teknolojidir, Windows Nic Teaming, Linux Bonding, Cisco EtherChannel, Huawei Eth-Trunking, HP Link Aggregation isimleri ile kullanılmaktadır.

Cyberoam üzerinde LAG konfigurasyonuna başlamadan önce port durumlarının kapalı olması(None) gerekmektedir, Aktif olan portlar LAG konfigurasyon sayfasında görüntülenmeyecektir.

LAG konfigurasyonu en az 2, en fazla 4 port tek bir LAG üzerinde konfigure edilebilmektedir. İkinci bir LAG konfigurasyonunda istenirse 4 port daha eklenebilmektedir.

Network>İnterface tabını tıklıyoruz, gelen ekranda LAG konfigurasyonu yapacağımız interface’ler disable durumuna alıyoruz. Add LAG’ı tıklıyoruz.

Interface Name kısmına bir isim veriyorum, ve LAG’a üye yapacağım interface isimlerini tıklıyorum.

Mode kısmında ben 802.3ad (LACP) kullanacağım ve Network Zone kısmından kullanacak olduğunuz Zone seçiyoruz.

Ortak interfacemiz olan LAG’a IPv4 adresini giriyoruz. Advanced Settings Tabını tıklıyoruz.

Auto Negotiation kısmından interface hızını seçebilirsiniz. Burada önemli olan nokta Xmit hash policy kısmıdır.

Layer2 seçilirse iletişim için mac adresleri kullanılacaktır. Layer2+3 seçilirse L2 Mac adresi ve L3 Ip protokolü, Layer3+4 seçilirse Transport layer protokolü üzerinde trafik iletilecektir. (Bkz Osi katmanları), ben Layer2+3 seçerek devam ediyorum.

Seçmiş olduğum 4 interface LAG sanal interface’sine üye oldular. Cyberoam tarafında yapılması gereken ayarları tamamladık, konfigurasyon olarak Lacp seçtiğimiz için switch tarafındaki birkaç vendorun komutlarını paylaşacağım.

Huawei Switch Konfigurasyon

[HUAWEI]interface Eth-Trunk 1

[HUAWEI-Eth-Trunk1]mode lacp

[HUAWEI-Eth-Trunk1]trunkport GigabitEthernet 0/0/1 to 0/0/4

Cisco Switch Konfigurasyon;

Switch(config)#interface range fastEthernet 0/1-4

Switch(config-if-range)#channel-protocol lacp

Switch(config-if-range)#channel-group 1 mode active

HP Switch Konfigurasyon;

Switch(config)# int e 1-4 lacp active

Not: Yapılan tüm ayar ve konfigurasyon yazılım sürümüne göre farklılık gösterebilir.

Skype4B server kurulum işlemleri tamamlandıktan sonra sıra kullanıcılarımızı S4B üzerinde aktif hale getirmeye geldi. Bu işlemler için Skype4B sunucusu üzerinde “Skype for Business Control Panel” adımına geçiyoruz.

Lync 2013 de olduğu gibi Silverlight halen bir gereksinim. Click now to İnstall seçeneğiyle Silverlight kurulumunu tamamlıyoruz.

Silverlight kurulumu sonrası kontrol panelimiz aşağıdaki gibi açılmaktadır. Kullanıcı enable işlemlerimizi Users tabından yapıyoruz. Gördüğünüz üzere ara yüz biraz daha değiştirilmiştir.

Users tabından Enable Users tıklıyoruz.

Add butonuna tıklayıp ilgili kullanıcılarımızı ekliyoruz (Aynı anda birden fazla ekleme yapabilirsiniz) ve ardından Enable tıklıyoruz.

İşlem sonrası ekranımız aşağıdaki gibi olmalıdır.

Office 2013 ProPlus ile gelen Lync 2013 ün client yazılımı güncelleştirme sonrası Skype4B Client olmuştur. Domaine dahil olmuş Client işletim sistemi üzerinden mail adresimiz ve domain şifremiz ile login oluyoruz.

Login işlemi başarıyla tamamlandıktan sonra birleşik iletişim platformumuzu kullanabiliriz.

Umarım faydalı bir makale olmuştur.