Pazartesi, Aralık 07, 2015

Napa ile SharePoint Online APP'i Geliştirin!

Napa, Microsoft tarafından Office 365 kod geliştiricilere sunulan ücretsiz ve Online çalışan bir geliştirme aracı. Napa ile Office Add-In'leri ve SharePoint Online APP'lerini kolaylıkla ve kurulum gerektirmeden geliştirmeniz mümkün. Gelin adım adım basit bir tane SharePoint Online APP'ini hayata geçirelim;

SharePoint Online üzerinde App geliştirmek için öncelikli olarak Developer Site'a ihtiyacınız olacaktır. Developer Site'ı Office 365 SharePoint yönetici ekranından kolaylıkla oluşturabilirsiniz. Burada dikkat etmeniz gereken nokta oluşturulacak olan SiteCollection'ın şablonunun Developer Site olması. DeveloperSite size adı üzerinde geliştirme yapmanız ve uygulamanızı test etmeniz için yetkisel anlamda ve ortam anlamında araçlar sağlayacaktır.



DeveloperSite'ı oluşturduktan sonra sıra geldi Napa'yı aktif etmeye. Bu işlem için DeveloperSite üzerinde Add an App dedikten sonra SharePoint Store'a geçmeniz ve oradan da Napa'yı aratmanız yeterli olacaktır. Napa'yı uygulamalar arasından bulduktan sonra siteye eklemeniz yeterli. Napa diğer uygulamalar gibi site içeriğinde yerini alacaktır. Yükleme tamamlandıktan sonra site içeriğinden Napa'ya tıklayarak aşağıdaki ekran ile karşılaşabilirsiniz. Güzel Haber! Geliştirme ve test ortamınız şu anda hazır!



Uygulama giriş ekranında daha önce geliştirdiğiniz projeleri görüntüleyip düzenleyebilir ya da "Add New Project" diyerek yeni bir proje oluşturabilirsiniz. Yeni proje ekle dedikten sonra proje tipi olarak SharePoint Add-In'i seçip, projeye bir isim verip Create dedikten sonra sizi aşağıdaki ekran karşılayacaktır. İşte size javascript ile geliştirme yapabileceğiniz, uygulamayı test edebileceğiniz ve SharePoint'in kaynaklarına erişebileceğiniz bir geliştirme ortamı!



Bu geliştirme ortamı her ne kadar VisualStudio kadar gelişmiş olmasa da gördüğünüz gibi istediğiniz kadar sayfa ekleyebilirsiniz. Bu sayfalarda kullanılmak üzere Javascript metodları tanımlayabilir ve SharePoint'e erişebilirsiniz. Tabi burada unutulmaması gereken nokta SharePoint'e erişirken Client Side Object Model kodları ile ilerliyor olmanız, bildiğiniz gibi SharePoint'e JavaScript üzerinden de rahatlıkla erişebilirsiniz. Bu Post'ta herhangi bir geliştirme yapmayıp varsayılan örneği test edeceğiz. Napa'da proje oluşturduğunuzda kullanıcının adını ekrana basan basit Script sizi karşılar bunu test etmek için sol menüde yer alan Run Project Buttonuna basmanız yeterlidir. İşte Napa ile hayat bu kadar basit. Sizlerin test etmesi adına burada ekran görüntüsü paylaşmıyorum. Sol menüdeki dikkat çeken bir diğer özellik de Open in Visual Studio özelliği. Eğer Napa'nın yetenekleri size yeterli gelmiyorsa tek tık ile projenizi Visual Studio ile de açıp ilerleme şansınız mevcut.

Napa Hakkında daha detaylı bilgi için: https://www.napacloudapp.com/Getting-Started adresini ziyaret edebilirsiniz. Basit bir uygulama geliştirip SharePoint listeleri ile veri alış verişi nasıl yapılır konusunda https://msdn.microsoft.com/library/office/jj220041(v=office.15) adresindeki makaleyi okumanızı ve uygulamanızı şiddetle öneririm.

Perşembe, Ağustos 06, 2015

SharePoint'e Solution Deploy Etmek

SharePoint'te Solution'lar Full Trust ve User Solution's olarak ikiye ayrılır. Bunu daha basit anlatacak olursak eğer sunucuya RDP ile bağlanıp sunucunun her şeyini kontrol edebiliyorsanız Full Trust Solution deploy edebilir ve tüm Farm'ı etkileyecek seviyede işlemler yapabilirsiniz. Office 365 üzerinde kod geliştiriyorsanız doğal olarak burada size herhangi bir sunucu erişimi verilemez ve sadece kendi SiteCollection'ınızı etkileyecek seviyede geliştirme yapabilirsiniz bunu da SandBoxed Solutions olarak adlandırırız ve arayüz üzerinden kolaylıkla siteye Deploy edebilirsiniz. Bu yazımızda Farm Solutions'ı ele alıp bunun Deployment yöntemleri hakkında konuşacağız.

Öncelikle pek çok yerde görülen bir hatayı ele almak istiyorum. Sunucuya Solution Deploy etmek için canlı sunucuya Visual Studio yükleyip ardından Solution'ı burada açıp Deploy etme yöntemi pek çok Developer tarafından maalesef tercih ediliyor. Bu yöntem oldukça yanlış ve riskli bir yöntemdir. Eğer canlı sunucuya Visual Studio kurduysanız Debug'da yapabilirsiniz ve varsayılan ayarlarda kodlar geri çekileceği için bir şeyi düzelteyim derken sistemi tamamen çalışmaz hale getirebilirsiniz. Viual Studio aracılığı ile IIS üzerinde de kolaylıkla işlem yapabiliyor olmanız sistemi patlatmak için açıkçası süper bir fırsat. Bu ve bunun gibi nedenlerden dolayı canlı ve test ortamlarına kesinlikle Visual Studio kurmayı önermiyoruz hatta yasaklıyoruz diyebiliriz. Peki WSP dosyalarını nasıl deploy edeceğiz?

Sistemde var olan Solution'ları görüntülemek için Central Administration Site ara yüzünden faydalanabiliriz. Central Administration Site üzerinde sol menüden System Settings buradan da Manage Farm Solutions linkine tıklayarak şu anda Farm'da yüklü olan Solution'ları görebilirsiniz. Buradan var olan bir Solution'ı silebilir, farklı WebApplication'lara Deploy edebilir ancak buraya yenisini ekleyemezsiniz. Buraya yeni solution eklemek için PowerShell'den faydalanmak gerekiyor. Sisteme yeni bir Solution eklemek için Add-SPSolution komutunu kullanmalıyız. Bu komut oluşturmuş olduğunuz bir WSP dosyasını Farm'a Deploy Edecektir. Aşağıda Add-SPSolution komutunun kullanımını ve bu konuda hayatımızı kullanacak bir kaç komutun açıklamaları yer almaktadır. Bu komutları çalıştırabilmeniz için mutlaka Farm Yöneticisi olmanız gerekir ve SharePoint Management Shell'i Run As Administrator komutu ile açmış olmanız gerekmektedir.

Add-SPSolution
Farm'a yeni bir Solution eklemek için kullanılır. Ara yüz üzerinden bu işlem yapılamaz ve en basit hali aşağıdaki komut kullanılmalıdır.

Add-SPSolution -LiteralPath c:\TCM\SPDeployTest.wsp
Detaylı Bilgi: https://technet.microsoft.com/en-us/library/ff607552.aspx 

Bu adımın ardından Solution Farm'a eklenmiştir anacak referansları WebApplication'lara eklenmemiştir. Solution'ı ilgili Web Application'lara Deploy etmek için aşağıdaki komut kullanılabilir.

Install-SPSolution
Farm'da var olan bir Solution'ın tüm WebApplication'lara ya da herhangi bir tanesine Deploy edilmesine olanak tanır. Bu işlemi ara yüzden de yapabilirsiniz. Solution'ın üzerinde tıklayıp Deploy demeniz yeterli.

Install-SPSolution -Identity SPDeployTest.wsp -GACDeployment -WebApplication http://burakbatur.com
Detaylı Bilgi: https://technet.microsoft.com/en-us/library/ff607534.aspx 

Uninstall-SPSolution
Bir Solution'ı Farm'dan ya da tek bir WebApplication'dan kaldırmak için bu komutu kullanabilirsiniz. Bu işlemi de ara yüzden yapma şansınız vardır. Ara yüzde bu komutun karşılığı retract'tir.

Uninstall-SPSolution -Identity SPDeployTest.wsp
Detaylı Bilgi: https://technet.microsoft.com/en-us/library/ff607873.aspx

Update-SPSolution
Var olan bir Solution'un yeni versiyonunu atmak için aşağıdaki komutu kullanabilirsiniz. Bu işlemi ara yüz üzerinden gerçekleştirme şansınız yoktur bu sebeple PowerShell ile ilerlemek durumundayız.

Update-SPSolution -Identity SPDeployTest.wsp -LiteralPath c:\TCM\SPDeployTest.wsp -GACDeployment
Detaylı Bilgi: https://technet.microsoft.com/en-us/library/ff607724.aspx

Solution Deployment Hakkında Önemli Uyarılar
Farm'a Solution Deploy ederken ve ettikten sonra aşağıdaki hayat tecrübelerinin sizle için faydalı olacağını düşünüyorum:
  • Deploy edecek olduğunuz Solution'ları bir klasör içerisinde gruplayın.
  • Deployment sürecinde kullanmış olduğunuz kodları solution bazlı olarak saklayın bu mutlaka size zaman kazandıracaktır.
  • Ard arda çok sık Deployment yapmayın, iki deployment arasında 1 dakika bekleyin.
  • Deployment sonrasında mutlaka son durumu Central Administration Site üzerinden kontrol edin eğer Deploying'de kaldıysa müdahale etmeniz gereken bir yer var demektir.
  • Install-SPSolution komutundan sonra siteye erişmeden önce en az 1 dakika bekleyin, web.config'de işlem yapıldığı için Application Pool Recycle olacak ve yeniden ayağa kalkması zaman alacaktır. Eğer bu süreçte çağrı gönderirseniz Applicaiton Pool duracak ve 500 hatası alacaksınız.
  • Deploymentlarınızı akşamları mesai saatleri dışına planlayın.
  • Update-SPSolution komutundan sonra mutlaka en az 1 dakika sisteme erişmek için bekleyin.
  • Eğer solution içerisinde yeni eklenen Feature veya var olan Feature'larda değişiklik varsa Update-SPSolution yerine önce Uninstall-SPSolution uygulamayı kaldırın sonra güncelleyip yeniden Install edin.
  • Solution'ları Update etmeden önce mutlaka bir önce sağlıklı çalışanın yedeğini alın olası bir problemde geri dönüşünüz kolay olsun.

Perşembe, Temmuz 16, 2015

Günün İpucu: PowerShell ile SharePoint Web Application'ı Oluşturmak

SharePoint Central Administration Site üzerinden pek çok işlemi yapabiliyoruz ama zaman zaman seri halde işlemler yapmak istediğimizde ya da Central Administration Site üzerinden bir işlemi yapmayı deneyip yapamadığınızda PowerShell imdadınıza koşar. Microsoft dünyasında pek çok alanda çok fazla yetenekleri olan PowerShell'in SharePoint tarafında da yetenekleri azımsanmayacak kadar fazladır. Bu yazımızda ufak bir örnek ile SharePoint'te yeni bir WebApplication oluşturuyoruz. Neden mi? Central Administration üzerinden hata alıyorum :)

SharePoint Management Shell'i açmak için yapmanız gereken ilk iş Windows arama ekranına SharePoint Management Shell yazmak ve uygulamayı "Run as Administrator" seçeneği ile açmak bu adımdan sonra SharePoint Farm'ı üzerindeki her işlemi PowerShell komutları ile yapabilirsiniz. Web Application oluşturmak için aşağıdaki kod bloğunu kullanabilirsiniz.

İlk olarak yeni bir Authentication Provider oluşturarak işe başlıyoruz.

$ap = New-SPAuthenticationProvider

Bu adımın ardından aşağıdaki komutlar ile 80. Porttan yayın yapan host header'ı burakbatur.com olan, SQL01 sunucusunda wss_content_burakbaturcom DB'sini kullanan ve yeni bir Application Pool'u olan bir Web Application oluşturabilirsiniz.
 
New-SPWebApplication -Name "SharePoint - burakbatur.com" -Port 80 -HostHeader burakbatur.com -URL "http://burakbatur.com" -ApplicationPool "SharePoint - burakbatur.com" -ApplicationPoolAccount (Get-SPManagedAccount "BBAS\SPAdmin") -AuthenticationProvider $ap -DatabaseServer "SQL01" -DatabaseName "WSS_Content_burakbaturcom"

Komut hakkında daha detaylı bilgiye https://technet.microsoft.com/en-us/library/ff607931.aspx adresinden ulaşabilirsiniz.

Cuma, Temmuz 10, 2015

SharePoint Yetkilendirme - 3

SharePoint yetkilendirme kavramına daha önce aşağıdaki 2 yazı ile giriş yapmıştık. Öncelikli olarak aşağıdaki linklerdeki yazıları gözden geçirmenizi öneririm.

Bu yazımızda Site Collection düzeyindeki yetkilendirme özellikleri üzerinde ilerliyor olacağız. SharePoint üzerinde SiteCollection Administrator yetkiniz varsa ayarlar tuşundan Site Settings'e geçtiğinizde aşağıdaki bölüm size görünür olacaktır. Tabi bunun için en üst seviye site ayarlarında olmanız gerekmektedir. Eğer ilgili yerde yani Top Level Site üzerinde değilseniz zaten aşağıda görüntülenmekte olan bölümde bir link sizi buraya yönlendiriyor olacaktır.



Bir SiteCollection üzerinde Site Collection Admin hakkınız varsa tahmin edeceğiniz üzere o SiteCollection üzerinde her şeyi yapabilirsiniz. Bu yazımızın odak noktası Yetkilendirme olduğu için yukarıda görüntülenmekte olan bölüm değil daha üstte en sol ve en üstteki grupla yani User and Permissions bölümü ile ilgileniyor olacağız.


Buradaki ayarları başlık başlık açıklayacak olursak en basitinden başladığımızda Site Collection Administrators dikkatimizi çekecektir. Bu link aracılığı ile şu anda sistemde bulunan site koleksiyonu yöneticilerini görür ve yenisini eklersiniz. Daha önceki yazılarımızdan hatırlayacağınız gibi Central Administration Site üzerinden sadece iki tane yönetici tanımlayabiliyordunuz ama bu sınırımız burada aktif değil. Bir site koleksiyonunun ikiden fazla yöneticisi olması durumunda ziyaret etmeniz gereken URL burasıdır.

People and Groups başlığı altında o an aktif olarak sitede tanımlı olan grupları görüntüleyip işlem yapabilirsiniz. Bu yazımızda grupların detaylarına girmeyip bir sonraki yazımızda bu detayı inceliyor olacağız.

Site Permissions bölümü ise site üzerindeki yetki verdiğiniz kişi ve grupları görüntülediğiniz bölümdür. Kimde hangi yetki varı burada görebilirsiniz ve yenilerini ekleyebilirsiniz.

Site App Permissions ise SharePoint sitenize erişecek olan ve içeriği okumasına izin verdiğiniz 3rd party App'leri görüntüleyecektir. Bir APP'in sisteminize erişimini kısıtlamak istiyorsanız buradan silebilirsiniz.

Herhangi bir kişiye yetki vermeden önce ya da var olan yetkileri düzenlemeye geçmeden önce dikkat çekmek istediğim bir nokta söz konusu: Permission Levels (Yetki Seviyeleri)
Permission Levels SharePoint'te yetkinin yani Authorization kavramının en temellerini oluşturmaktadır. Daha açıklayıcı bir şekilde kullanılabilecek yetki kombinasyonları olarak düşünebiliriz. Şimdi yukarıda görüntülenmekte olan Users and Permissions bölümüne tıklayalım ve hiç farklı bir noktaya odaklanmadan doğrudan Ribbon üzerinden Permisson Levels bağlantısını bulalım.



Permission Levels bağlantısına tıkladığınızda aşağıdaki ekran bizi karşılayacaktır.



Bu ekran bize Site üzerinde verilebilecek yetki seviyelerini listelemektedir. Her seviyenin yanında da o seviyenin hakkında açıklama yer almaktadır. Yani şu anda herhangi bir kişiye yetki vermek istersek burada gördüklerimizi ya da bunların kombinasyonlarını kullanabiliriz. Hangi yetki seviyesi ne içeriyoru görmek içinde herhangi bir seviyenin üzerine tıklayabilirsiniz. Burada tiplere göre farklı yetkilerin yer aldığını ve seviyelerin bunların birleşiminden oluştuğunu gözlemlemiş olmalısınız. Dikkat!: Yetkiler arasında yasak (Deny) olmadığına dikkat edin. Yani Windows yetkilerinden alışık olduğumuz en tepeden her yetkiyi ver en alta geldiğinde de bir kişiyi yasakla ki asla girmesin durumu burada söz konusu değil. Yetki verirken ki stratejimiz çok çok önemli olacaktır. 
Yetki seviyelerinden bir tanesine tıkladığınızda  CheckBox'lar sizi karşılayacak ve o seviyeyi dilediğiniz gibi değiştirebilirsiniz. CheckBox'lardaki seçimleri değiştirdiğinizde birbiri ile ilişkili olanlarında otomatik olarak seçildiğine dikkat edin. Peki var olan yetki seviyelerini değiştirmek iyi bir çözüm mü? Bana sorarsanız asla iyi bir çözüm değil? Ama projede kişilerin düzenleme yetkisi olmasını ancak Silme yetkisinin olmamasını istiyorsunuz ve Deny yok!  Bunu nasıl yapacağız?

Yetki seviyesinin en altına indiğinizde Copy Permisson Level düğmesini göreceksiniz. Bu düğmenin yardımı ile size en yakın gelen yetki seviyesini kopyalayıp üzerinde değişikliği yapıp yeni bir isim ve açıklama belirttikten sonra bunu rahatlıkla kullanabilirsiniz. Burada sıfırdan yeni oluşturmak da mümkündür ama hayat tecrübesi olarak burada genellikle bazı CheckBox'ların unutulduğunu söyleyebilirim bu sebeple kopyalayıp ilerlemek en anlamlı yöntem.

Yetki seviyelerini Site seviyesinde de değiştirebilirsiniz ama önerim bu işlemi en üst düzeyde yapmak olacaktır.

Yetki seviyelerini öğrendiğimize göre sıra geldi yetki vermeye ve grup oluşturmaya. Bir sonraki yazımızda gruplar üzerine yoğunlaşıp daha sonra da nihayet yetki veriyor olacağız.

Salı, Nisan 14, 2015

Cumartesi MSHOWTO Office 365 Etkinliğinde Buluşalım!

18 Nisan Cumartesi günü Microsoft İstanbul ofisinde gerçekleşecek olan & Skype for Business Roadshow etkinliğine davetlisiniz. Etkinlikte ben de SharePoint Online ile ilgili bol demolu bir sunum yapıyor olacağım. Kayıtlar dolmadan acele edin.

Ücretsiz Kayıt olmak için tıklayın!


Ajanda aşağıdaki gibidir.

10.00 – 11.00
, Microsoft Exchange Server MVP,
Konu : Office 365 ve On-Premise Exchange Server Mimarisi Hybrid Yapıda Nasıl Çalışır? Geçiş Senaryoları Nelerdir?
Tanım : Bu oturumda, On-premise yapılardaki Active Directory ve Exchange Server mimarilerinin ADFS yardımı ile Office 365 Exchange Online sistemine nasıl bağlanabileceğine dair örneklerde içeren bilgiler aktarılacaktır. Aynı zamanda tüm yapının Office 365’e geçiş senaryolarına değinilecektir.

ARA

11.15 – 12.15
, SharePoint Server MVP, TCM
Konu : SharePoint Online : Hızlı, Kolay ve Esnek Intranet
Tanım : Bu oturumda, Sharepoint Online’ın yeni ve geliştirilen arayüzü üzerinde doküman yönetim sistemine bakılarak varolan yapılardaki Sharepoint ortamları için entegrasyon senaryolarına değinilecektir. Aynı zaman da Yammer, One Drive for Business ve ilgili tüm teknolojiler hakkında bilgi verilecektir.

YEMEK

13.00 – 14.00
, Office System MVP Netaş
Konu: Office 365 Pro Plus Kullanım ve Lisanslama Senaryoları ve Lync Online ile Kurumsal İletişim
Tanım : Bu oturumda, Office 365 Pro Plus paket içeriği lisanslama modelleri ile anlatılırken Lync Online ile kurumsal iletişimin nasıl sağlanabileceğini konularında bilgi verilecektir.

ARA

14.15 – 15.15
, Birleşik İletişim Teknik Çözüm Uzmanı Microsoft
Konu : Yeni Lync, Skype for Business Nedir?
Tanım : Bu oturumda, Microsoft’un son dönemde adını sıkça duymaya başladığımız Skype for Business çözümü için detaylı bilgiye ulaşacaksınız.

ARA

15.30 – 16.30
Önder Değer, Microsoft Azure MVP, Bilge Adam
, System Center Cloud and Datacenter MVP, Bilge Adam
Konu : Azure Active Directory ile Office 365 Kullanım Senaryoları
Tanım : Bu oturumda, On-premise yapıdaki Active Directory ile Azure Active Directory ortamının bütünleşik olarak Office 365 ortamlarında nasıl kullanılabileceği hakkında bilgiler verilecektir.

Kayıt olmak için tıklayın!

Perşembe, Mart 19, 2015

Microsoft Kurumsal Çözümler Günü'nde Buluşalım!

TCM olarak sponsorlarından bir tanesi olduğumuz Microsoft Kurumsal Çözümler Günü İstanbul bu sene 19 Mart'ta Şişli Marriott Hotel'de gerçekleştiriliyor. Etkinlikte paralel oturumlarda gerçeğe dönmüş olan çözümleri dinleyebilirsiniz!

Etkinlik ile ilgili detaylara http://www.microsoft.com/turkiye/kurumsalcozumlergunu/ adresinden ulaşabilirsiniz.

Salı, Mart 10, 2015

Hatırlatma: Microsoft SharePoint Web Application Servisi

Bu gün almış olduğum bir soru üzerinde bu yazıyı yazmaya karar verdim. Soru: Bu servisi durdurursak ne olur?

SharePoint Farm'larını kurgularken sunucu rollerini belirleriz. Şu sunucu Web Front End sunucu olsun, şu sunucu BackEnd ya da Application olsun deriz. SharePoint Farm'ında bir sunucunun Web Front End sunucusu olmasını sağlayan servis Microsoft SharePoint Web Application Servisi'dir. Bir Farm'da bu servisin açık olduğu sunuculara son kullanıcılar gelir, yani Conent Database'lerinin bağlanmış olduğu Web Application'ların oluşturulmasını sağlayan servis budur.

Peki kapandığında ne olur! Yukarıdaki açıklamalar ışığında şunu söyleyebilirim: Sunucudaki tüm kullanıcı Web Application'ları silinir ve yaptığınız ayarların tamamı çöpe gider, doğal olarak sistem erişilmez olur. Bu sebeple eğer sunucuyu Farm'dan çıkarmayacaksanız bu servis normal şartlar altında durdurulup yeniden başlatılmaz.

Pazartesi, Ocak 26, 2015

SiteCollection'ları Belirli bir Content Database İçerisinde Oluşturmak

Daha önceki yazımızda Content DB'lerden bahetmiştik ve arayüzden nasıl yeni Content DB oluşturabileceğimiz üzerinde durmuştuk. Hatırlanacağı üzere DataBase limitleri ile oynayıp SiteCollection'ların farklı DB'lerde yer almasını sağlayabiliyorduk. Peki bir SiteCollection oluştururken bunu sizin belirleyebileceğiniz bir veri tabanı içinde oluşturabilir miyiz? Tabi ki evet ama bun Central Administration Site üzerinden yapmamız maalesef mümkün değil. Bu senaryoda SharePoint Management Shell komutlarını devreye almamız gerekiyor. Bu adımdan önce yine daha önce bir Content Database oluşturmuş olmanız gerekiyor. Daha önceki postta oluşturmuş olduğumuz Content DB'yi kullanarak yeni bir Site Collection oluşturmak için aşağıdaki komutu kullanabiliriz.

New-SPSite http://URL -OwnerAlias "DOMAIN\burak" -Language 1033 -ContentDatabase WSS_Content_BURAKTEST

New-SPSite komutu ve parametreleri hakkında daha detaylı bilgi için https://technet.microsoft.com/en-us/library/ff607937.aspx adresini ziyaret etmenizi şiddetle tavsiye ederim. Bizim burada ilgilenecek olduğumuz özellik "-ContentDatabase"; zaten tahmin ettiğiniz gibi SiteCollection burada belirtilen veri tabanı içinde oluşturulacaktır. Yukarıdaki komutlar ile site oluşturduğunuzda oluşacak olan Top Level Site'ın şablonunu belirtmemiş oluyorsunuz, siteye ilk erişimizde bu seçimi yapabiliyor olacaksınız. Tabi ki PowerShell komutu ile de tüm ayarları belirterek oluşturabilirsiniz.

Perşembe, Ocak 22, 2015

SharePoint Content DataBase'lerini Yönetmek

SharePoint üzerinde bir WebApplication içerisine yüzlerde içerik veri tabanı oluşturabilirsiniz. Buna niye ihtiyaç duyulacağı noktasında ise tabi ki akla ilk gelen şey performans olacaktır. Bu durum her ne kadar performans ile ilgili olsa da aslında arka plandaki limitlere göre çalışmak için de bu durum aslında bir gerekliliktir. Daha önceki yazılarımızda SharePoint limitlerine uymanın ne kadar önemli olduğunu belirtmiştik ilgili yazıya http://burakbatur.blogspot.com.tr/2014/06/sharepoint-2013-limitleri.html adresinden ulaşabilirsiniz.  SharePoint'in içerik veri tabanlarını yönetmek için Central Administration Site'dan faydalanabilirsiniz. Bu işlemler için ilk olarak Central Administration Site üzerindeki Application Management bağlantısına tıklamanız gerekiyor. Bu bağlantıya tıkladığınızda karşınıza gelen sayfanın en altındaki linklerden veri tabanlarını yönetebilirsiniz. Burada en soldaki linkten bir WebApplication'da yer alacak olan içerik veri tabanlarını yönetebilirsiniz, "Specify the default database server"  bağlantısı aracılığı ile yeni bir WebApplication oluşturulurken ya da var olana yeni bir veri tabanı eklenirken kullanılacak olan varsayılan SQL sunucusunu belirtebilirsiniz. "Configure the data retrieval service" bağlantısı aracılığı ile de data iletişimi, paket büyüklüğü ve zaman aşımı gibi değerleri ayarlayabilirsiniz.

Bu postun konusu olan "Manage content databases" bağlantısı üzerinden ise WebApplication'a bağlı olan içerik veritabanlarını yönetebilirsiniz. Bu linke tıkladığınızda yönetebilecek olduğunuz veri tabanları, durumları, şu anda o veri tabanı içinde olan Site Collection'lar ve maksimum SiteCollection sayısını görebilirsiniz. Herhangi bir veri tabanını yönetmek için adına tıklamanız yeterli. Veri tabanının adına tıkladığınızda bu veritabanını silebileceğiniz gibi özelliklerini de güncelleyebilirsiniz. Burada kritik özellikler DataBase Status ve Maximum number of Sites özelliği. Eğer Status Offline da ise bu DB üzerinde işlem yapılamayacağı anlamına gelecektir. Bunu şöyle bir senaryo ile özetleyebiliriz. Bir WebApplication'da 20 tane Content DataBase'iniz var ve bunları bakıma almanız gerekiyor, tüm siteyi offline'a çekmektense parça parça Offline'a çekmek daha anlamlı olacaktır. İşte böyle bir durumda bu özellik gayet anlamlı oluyor.
Maximum number of Site özelliği ise adı üzerinde bir Content DataBase'i içinde max kaç tane Site Collection olacağını belirtiyor. Burada tekrar vurgulamakta fayda var, bahsettiğimiz limit SiteCollection'lara uygulanan bir limittir. Bu özelliğin varsayılan değeri 5000 olarak gelmektedir. Bu şu anlama gelir: eğer bu DB'deki SiteCollection sayısı 5000 ise artık yeni siteleri burada oluşturma. 5000 iyi rakam değil mi? Teker teker SiteCollection açtığınızda zaten dolabilecek bir rakam değil. Asla ulaşılamaz bir rakam gibi, ancak MySite'ların da birer SiteCollection olduğunu burada hatırlatmak isterim ve kullanıcı sayınız 10000'lerdeyse emin olun 2 günde bu limit dolacaktır.
Yeni bir Content DB oluşturmak için arayüzden Add a Content DataBase linkine tıklayabilirsiniz. Bu ekrandan DB'nin oluşacağı sunucu, maksimum değerler, bu DB'yi yönetecek olan Timer Servisin çalıştığı sunucu ve eğer varsa Mirror DB'sini belirtebilirsiniz. Burada kritik nokta eğer veri tabanı sunucunuzda belirttiğiniz isimde bir dosya varsa SharePoint onu kullanacaktır, eğer yoksa güncel versiyon ile yeniden oluşturacaktır. Dikkat! Burada Upgrade işlemi yapamazsınız. Upgrade işlemi için PowerShell'den "Mount-SPContentDatabase" komutunu kullanmanız gerekir. Şimdi test amaçlı olarak WSS_Content_BURAKTEST isimli bir DB oluşturalım.

 
Veri tabanını oluşturduktan sonra tüm veri tabanlarını gördüğünüz sayfaya yönleneceksiniz ve burada artık yeni veri tabanı da listeleniyor olacak. Tabi ki içinde henüz bir Site Collection yer almıyor. İlerleyen günlerde bu konuyu da ele alacağız ancak şimdi oluşacak olan Site Collection'ın otomatik olarak burada yer almasını sağlayalım. Bunu yapmak için hepinizin aklındaki şeyi yapacağım, eski Content DB'nin özelliklerini düzenleyip Max Number of Site değerini şu anki toplam sayıya eşitleyeceğim. Bu işlemin ardından yeni Site Collection oluşturduğumda artık Site Collection yeni veri tabanı içinde yer alıyor olacak. Peki neden böyle bir şey yaptık? Yazının başında da açıklamaya çalıştığım gibi performans nedenlerden bir tanesi ancak canlı erişim performansının yanında bakım performansı, Backup performansı gibi bileşenlerde burada söz sahibi parametrelerdir. Özellikle içerik boyutu büyüdükçe Content DB sayısını arttırın ki Site Collection'lar paralelde farklı DB'ler içinde büyümeye devam etsin. Uzun vadede ciddi performans sorunları yaşayabileceğiniz gibi çok büyük Content DB'ler kullanım anlamında da Lock'lar oluşturabilir ve çalışmanızı da engelleyecek boyuta gelebilir. 


Cumartesi, Ocak 10, 2015

Eğitim Önerisi: Yammer!

Bildiğiniz gibi Yammer! şirket çalışanları için kurumsal bir sosyal ağ sunuyor. Daha önceki yazılarımızda SharePoint'in sosyal ağından da bolca bahsetmiştik ancak SharePoint'te ek geliştirme ile yapmaya çalıştığınız pek çok şey Yammer'da zaten var. Kurumlar için pek çok özellik düşünülmüş ve herhangi bir ek geliştirmeye gerek olmadan direkt kullanılabiliyor. Peki sizce bu yeterli mi? Yammer'daki bir Feed'i nasıl sitemin ana sayfasına getiririm? SharePoint üzerinde Yammer ile entegre custom bir çözüm geliştirilir mi? gibi sorularınıza cevap verecek güzel bir eğitim serisi yayınlandı. Eğitime ücretsiz olarak http://www.microsoftvirtualacademy.com/training-courses/deep-dive-integrate-office-365-apis-in-your-web-apps?m=11480 adresinden erişebilirsiniz.

Cumartesi, Ocak 03, 2015

SharePoint Yetkilendirme - 2

Serimizin bir önceki yazısında yetkilendirme kavramına hızlıca göz atmıştık. Bir önceki yazıya http://burakbatur.blogspot.com.tr/2014/12/sharepoint-yetkilendirme-1.html adresinden ulaşabilirsiniz.

Bu yazımızda sunucu düzeyindeki bir kaç yetkiden bahsediyor olacağız. İlk olarak Windows Server seviyesinden başlayalım. Bir sunucuya SharePoint kurulumu yaptığınızda sunucunun Lokal gruplarına 3 tane yeni grup eklenir. Bunlar;

WSS_ADMIN_WPG
WSS_RESTRICTED_WPG_V4
WSS_WPG

Bilgisayarınızın yönetim ekranına gittiğinizde aşağıdaki resimde de olduğu gibi bu grupları görüntüleyebilirsiniz. Tabi ki bir Farm yapısı söz konusu ise her sunucunun lokalinde bu gruplar vardır ve bu grup üyeliklerinin her sunucuda düzenlenmesi gerekir.


WSS_ADMIN_WPG
Bu gruba ekli olan kullanıcılara tüm SharePoint üzerinde yazma yetkisi verilir. Genel bir yazma yetkisine sahip olması gereken kullanıcılarınız söz konusu ise bu gruba eklemelisiniz.

WSS_RESTRICTED_WPG_V4
SharePoint'te verilebilecek en yüksek yetkiyi kişileri bu gruba dahil ederek verebilirsiniz. Bu grubun üyeleri Site Collection düzeyindeki izinleri düzenlemekten, WebApplication oluşturma ve silmeye kadar her şeyi yapabilir. Bu sebeple açıkladığımız gruplardan en az üyesi olması gereken grup budur.

SharePoint Yazılımı yapan firmalarda en sık gördüğümüz hata tek bir SPAdmin hesabı ile herkesin bağlanıp yazılım geliştirmeye çalıştırmasıdır. Bu firmaların kolayına gelmekle birlikte genellikle bilgi eksikliğinden kaynaklanmaktadır. Yazılım ekip üyelerinizin hesaplarını bu gruba ekleyerek rahatlıkla Development Farm'ı üzerinde geliştirme yapmasını sağlayabilirsiniz. Tabi ufak bir hatırlatma: Deployment yapılabilmesi için ilgili hesaba SQL tarafında da gerekli yetkilerin verilmiş olması gerekiyor.

WSS_WPG
Bu grubun üyelerine tüm farm üzerinde okuma yetkisi verilir. Özellikle Search servisinde kullanılan Search Content Access Account'unun eklenmesi gereken gruptur.

Windows Server seviyesinden Central Admin'e geçtiğimizde de bir kaç ayar daha söz konusu olacaktır. Bunlardan ilki Web Application ayarları sayfasından erişilen User Policy ayarıdır. Bu ayar ile belli bir kullanıcı ve gruba tüm Web Application düzeyinde yetki verebilir ya da kişilerin bu WebApplication'a girmesini yasaklayabilirsiniz.

 

Central  Administration Site üzerinden yapabileceğiniz bir kaç yetki ayarı daha tüm Web Application'ı anonim erişme açmak ya da kapatmak da olabilir. Yukarıdaki resimde gördüğünüz Permission Policy ise bir Web Application içerisindeki Site Collection ve alt seviyelerde kullanılabilecek yetki seviyelerini belirler. Bu adımda örneğin hiç kimseye Deny yetkisi verdirmeyebilirsiniz.

Central Administration Site üzerinde en sık kullandığımız bir diğer ayar da Application Management -->Change Site Collection Administrators bağlantısıdır. Bu bağlantı ile bir Site Collection'ın 1. ve 2. seviye yöneticilerini Central Administration Site üzerinden belirtilebilirsiniz. Burada unutulmaması gereken bir nokta bu bölümden sadece 2 tane kullanıcıyı yetkilendirebilirsiniz. Daha fazlası için Site Collection'a erişip Site Collection ayarları üzerinde aksiyon almanız gerekiyor.