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.
Pazartesi, Ocak 26, 2015
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.
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.
Etiketler:
ÖnerilenBağlantı,
SharePoint 2013,
SharePoint Online
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 ü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.
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.
Kaydol:
Kayıtlar (Atom)