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.

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.

• http://burakbatur.blogspot.com.tr/2014/12/sharepoint-yetkilendirme-1.html
• http://burakbatur.blogspot.com.tr/2015/01/sharepoint-yetkilendirme-2.html

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.

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

18 Nisan Cumartesi günü Microsoft İstanbul ofisinde gerçekleşecek olan Office 365 & Skype for Business MVP 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
Emre Aydın, Microsoft Exchange Server MVP, MSHOWTO
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
Burak Batur, 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
Ahmet Uygur, 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
Oğuzhan İlkan Boran, 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
Mustafa Kara, 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!

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.

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.

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.

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. 



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.

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.

SharePoint Yetkilendirme - 1

Yetkilendirme SharePoint'in basit ama bir o kadar da en önemli kavramlarından bir tanesidir. SharePoint açsından baktığımızda oldukça kolay olan bu konunun aslında çok da bilinmediğini görmekteyiz. Yetkilendirme konusunu mümkün olduğunca detaylı olarak bir kaç post halinde ele alıyor olacağız. İlk olarak genel kavram ve açıklamalar ile başlayalım.

Talep: SharePoint üzerinde bize bir kullanıcı açar mısınız?

Yukarıdaki talep aslında her müşteriden size gelebilecek ve kolaylıkla yerine getirilecek bir talep gibi görünebilir ama sistemi incelediğimizde aslında bu talep yerine getirilemez. Talebin yerine getirilememesinin çok basit bir açıklaması var: SharePoint kendi üzerinde kullanıcı saklamaz. Daha önceki yazılarımızda Authentication ve Authorization kavramlarını ele almıştık. (http://burakbatur.blogspot.com.tr/2011/09/sharepoint-guvenlik-tipleri.html) Bir kez daha hatırlamak gerekirse:

Authentication: Kimlik denetimi anlamına gelmektedir. Yani kullanıcı gerçekten var mı? Kullanıcının kullanıcı adı doğru mu? Kullanıcının parolası doğru mu? Kullanıcının hesabı aktif mi? gibi soruların cevabını verecek olan kavram Authentication'dır.

Authorization: Yetkilendirme anlamına gelmektedir. Kullanıcı hangi işlemleri yapabilir? Kullanıcı hangi kütüphanelere erişebilir? Kullanıcının yazma yetkisi var mıdır? Kullanıcı dosya silebilir mi? gibi sorulara ise Authorization kavramı ile cevap verilir.

SharePoint'te yetkilendirme adı üzerinde Authorization ile başlar yani başka bir deyişle SharePoint kendi üzerinde kullanıcı adı ve parola saklamaz bunu başka sistemlerden bekler ve SharePoint üzerinde sadece var olan kullanıcıya ya da gruba yetki verilir. Peki bu kullanıcılar nerede saklanıyor? SharePoint'te kullanıcıların Authenticate olabileceği yerin ayarını WebApplication düzeyinde yapabilirsiniz. Burada iki seçenek söz konusudur. Bunlardan bir tanesi Claims Based Authentication, diğeri de Windows Authentication'dır. Eğer Windows aktif ise kullanıcıları sadece AD'den Authenticate ettirebilirsiniz. Güvenlik tipiniz Claims ise hem AD'den hem de Forms Authentication alt yapısı ile N sayıda kaynaktan kullanıcılarınızı Authenticate ettirebilirsiniz. Güncel versiyon olan 2013'de varsayılan tipimiz Claims Based Authentication'dır. Bu tipin 2010'daki varsayılanı Windows Authentication'dı 2013'de bu değişti!

Yetkilendirme işlemine Local Windows Gruplarından başlayıp, Web Application ile devam edebilirsiniz hemen ardından Site Collection düzeyinde bir yetkimiz daha mevcuttur. Top Level Site'a geçtikten sonra ise Web düzeyinde, List ya da Library düzeyinde ve SubWeb düzeyinde yetkiler devreye girer. List ya da Libray içinde girdiğimizde de Klasör ve öğe üzerinde yetkilendirmeye kadar girebilirsiniz. Dikkat ederseniz aslında SharePoint'in hiyerarşisi üzerinden hızlıca geçmiş olduk, yetkilendirme adımlarında da bu hiyerarşi çok çok önemlidir.

İlerleyen yazılarımızda her seviyedeki yetki seviyesini ve üstten yetki devralma ya da özel izin kavramlarını ele alıyor olacağız.

SharePoint User Information List

SharePoint sizin gördüğünüzün yanında arka planda çok fazla gizli liste barındırmaktadır. Bunlardan bir tanesi de User Information List'tir. Bu liste sistemde oturum açan kullanıcıların bilgilerini saklar ve kullanıcı detayına tıkladığınızda eğer MySite'lar aktif değilse kullanıcı bilgilerini bu liste üzerinden görüntülersiniz. Tüm listeye erişmek için herhangi bir site üzerinde /_catalogs/users/detail.aspx Rekative URL'ini kullanabilirsiniz.

Bu liste User Profile Synchronization Service tarafından her senkronizasyonda güncellenir ancak senkronizasyonda problem varsa ara ara bu listeye manuel müdahale etmeniz gerekebilir. Bu senaryoda aşağıdaki kod bloğunu SharePoint Power Shell arayüzü ile kullanabilirsiniz. Biz aşağıdaki örnekte sadece E-Mail alanını ele aldık ama liste detaylarından sütunlara göz atıp istediğiniz herhangi bir özelliği de değiştirebilirsiniz.

$site = Get-SPSite "http://SiteCollectionURL"
$web = $site.RootWeb
$list = $web.Lists["User Information List"]

$item = $list.Items | where {$_["Account"] -eq "domain\userName"}

$item["Work e-mail"] = deneme@deneme.com

$item.update()

$web.Dispose()
$site.Dispose()

SharePoint Teknik Diyagramları!

Hepimiz proje geliştirmeye başlamadan önce dizayn adımında duruma üstten bakmak isteriz, genel anlamdaki pek çok senaryoyu görebileceğiniz hatta poster boyutunda indirebileceğiniz SharePoint çözüm diyagramlarına https://technet.microsoft.com/en-us/library/cc263199(v=office.15).aspx adresinden ulaşabilirsiniz.

SharePoint Kod Örnekleri

SharePoint Development ile ilgili farklı senaryolardaki kod örnekleri Office Dev Center sitesi üzerinden sunulmaktadır, özellikle SharePoint üzerinde yazılım geliştirmeye yeni başladıysanız ya da kendinizi bu alanda farklı noktalarda geliştirmek istiyorsanız https://code.msdn.microsoft.com/sharepoint adresinizi ziyaret edebilirsiniz. 

SharePoint InfoPath Form Services Arayüzde Olmayan Özellikleri Listeleme

Her ne kadar geleceği çok parlak olmasa da pek çoğumuz için Microsoft Office InfoPath çoğu noktada hayat kurtaran bir uygulama olmuştur. Özellikle formlara Browser üzerinden erişip işlem yaptırmak, Client'larda herhangi bir şey kurulu olmadan aksiyon alıyor olmak ve çoğu işlemi de kod yazmadan kurallar ile işletmek gerçekten kulağa çok hoş geliyor. Proje ve kullanım oranı büyüdükçe çok güvendiğiniz SharePoint InfoPath Form servisleri zaman zaman size problem çıkarmaya başlar. Bu problemler uygulamanın tasarımı, sistem kaynaklarının yetersizliği gibi konulardan kaynaklanmakla birlikte zaman zaman da arka plandaki gizli ayarlardan kaynaklanıyor olabilir. Uygulamanız geniş kitlelere yayıldıkça zaman zaman varsayılan değerlerle oynamanız gerekebilir. SharePoint Central Administration ekranı üzerinden bir takım ayarlar ile oynayabiliyorsunuz ama asıl hayat kurtaran ayarlara PowerShell ile müdahale etmeniz gerekebilir. Bu işlemler oldukça basittir. 

InfoPath Form Services'in tüm ayarlarını görüntülemek için ilk olarak SharePoint Management Shell ekranını Run As Administrator seçeneği ile açalım ardından aşağıdaki kod ile InfoPath Form Services'in tüm ayarlarını görüntüleyebilirsiniz.

$SPInfopath=Get-SPInfoPathFormsService

$SPInfopath | Select *

Bu kodları çalıştırdığınızda ekranda aşağıdaki şekilde tüm ayarları ve bu ayarlara atanmış olan değerleri görüyor olacaksınız.

TypeName                                 : Forms Service
FormTemplates                            : ......
DefaultDataConnectionTimeout             : 10000
MemoryCacheSize                          : 250
MaxDataConnectionTimeout                 : 20000
MaxDataConnectionResponseSize            : 1500
MaxDataConnectionRoundTrip               : 20000
MaxFormLoadTime                          : 40000
RequireSslForDataConnections             : True
AllowEmbeddedSqlForDataConnections       : False
AllowUdcAuthenticationForDataConnections : False
AllowUserFormCrossDomainDataConnections  : True
AllowUserFormBrowserEnabling             : True
MaxSizeOfFormSessionState                : 4194304
MaxSizeOfUserFormState                   : 4194304
MaxPostbacksPerSession                   : 75
MaxUserActionsPerPostback                : 200
ActiveSessionsTimeout                    : 1440
AllowUserFormBrowserRendering            : True
AllowViewState                           : False
ViewStateThreshold                       : 40960
DataConnectionFiles                      : {}
ExemptUserAgents                         : {crawler, googlebot, ms search, msnb
                                           ot...}
Instances                                : {}
Applications                             : {}
Required                                 : False
JobDefinitions                           : {}
RunningJobs                              : {}
JobHistoryEntries                        : {}
CanUpgrade                               : True
IsBackwardsCompatible                    : True
NeedsUpgradeIncludeChildren              : False
NeedsUpgrade                             : False
UpgradeContext                           : Microsoft.SharePoint.Upgrade.SPUpgra
                                           deContext
Name                                     :
DisplayName                              :
Id                                       : c4211568-4ede-4e2f-81f1-******
Status                                   : Online
Parent                                   : SPFarm Name=SharePoint_Config_***
Version                                  : 1814277
Properties                               : {}
Farm                                     : SPFarm Name=SharePoint_Config_***

UpgradedPersistedProperties              : {}

Bu ayarlardan herhangi birini düzenlemek için aşağıdaki örnekteki gibi bir aksiyon alabilirsiniz. Örneğin biz bu örneğimizde DefaultDataConnectionTimeout değerini 10 000'den 20 000'e çekiyoruz.

$SPInfopath.DefaultDataConnectionTimeout = 20000

Yukarıdaki kodu çalıştırdığınızda değer direkt güncellenecektir. Tüm özellikleri tekrar listeleyerek sonuca göz atabilirsiniz. Bu arada hangi özelliği ne zaman değiştirmeniz gerekiyor? Buna tabiki siz direkt karar vermemelisiniz. Herhangi bir hata aldığınızda ilgili log dosyasına gidip hatayı analiz ettiğinizde SharePoint zaten size gerekli bilgiyi veriyor olacaktır. 

SharePoint 2013 Limitleri!

Her yazılımın olduğu gibi SharePoint'in de ilk çıktığı günden beri limitleri var. Bu limitler her versiyon ile değişmekle birlikte özellikle bir site hiyerarşisi kurgularken mutlaka kontrol edilmeli. SharePoint kullanan firmaların sistemleri incelendiğinde genellikle aşağıdaki hatalar ile karşılaşılıyor.

• Tüm içerik tek bir Content Databese'inde yer alıyor ve bu DataBase'in boyutu çok büyük limitlere çıkmış.
• Tüm dokümanlar tek bir doküman kütüphanesinde yer alıyor.
• Her URL için yeni bir Web Application ve Application Pool oluşturulmuş ve böylece çok fazla WebApplication ortaya çıkmış.

Yukarıdaki örnekler tabi ki arttırılabilir ama dikkat edecek olursanız genellikle ortak noktaları limitler. Örnek vermek gerekirse SharePoint'in performanslı çalışabilmesi için doküman kütüphanesi başına tek bir view'da görüntülenecek 5000 dokümanı aşmayacak bir mimari kurmanız gerekiyor.
Content Database'lerinizin boyutu 200 GB'ı geçmemeli.
Sistemde maksimum 10 Application Pool ve 20 WebApplication olmalı.

Dikkat ederseniz burada genellikle olmalı kelimesini kullanıyoruz, yukarıda belirttiğimiz limitler aşılabilen şeylerdir ama zorunlu durumlar dışında aşılması önerilmez ve en önemlisi "desteklenmez" aşağıda paylaştığımız linkteki limitlerin pek çoğunun yanında "Supported" ifadesini göreceksiniz. Bu ifade bu limitin aşılabileceğini ama aşıldığı durumlarda sistemin UnSupported durumda olacağını belirler. Bu herhangi bir hata yokken sıkıntı olmamakla birlikte, bir problemde Microsoft'tan destek alamayabileceğiniz ve sorununuzun çözümsüz kalacağı anlamına gelir. Bu sebeple yeni bir mimari kurgularken aşağıdaki linkte yer alan limitleri dikkate almanızı ve her sistem mimarisi oluşturma öncesinde bu linki ziyaret etmenizi şiddetle öneririm.

SharePoint 2013'ün Yazılım limit ve kısıtlamalarına https://technet.microsoft.com/en-us/library/cc262787.aspx adresinden erişebilirsiniz

User Profile Servis Senkronizasyonu Starting'de başlama problemi

SharePoint üzerinde User Profile Service denince akla ilk gelen senkronizasyon oluyor ve senkronizasyon servisini çalıştırmaya çalıştığınızda da en sık karşılaştığınız hatalardan bir tanesi servis durumunun Starting'de kalmasıdır. Burada ilk dikkat etmeniz gereken nokta servisin çalıştırılacağı hesabın AD üzerinde Replicate Directory Changes yetkisinin olması (Bu yetkinin verilmesi için http://technet.microsoft.com/en-us/library/hh296982.aspx adresindeki makaleden faydalanabilirsiniz.) ve Farm Admin hesabının makinede local admin olmasıdır tabi ki bu durumun çok fazla nedeni olabileceği için burada adım adım nedenlerini saymak yerine bu durumdan nasıl çıkaracağınızı anlatıyor olacağım detaylı bilgi için http://www.harbar.net/articles/sp2010ups2.aspx adresindeki makaleye de göz atmanızı öneririm.

Servisi Starting durumundan çıkarmak için aşağıdaki kodları SharePoint Power Shell Admin ekranı üzerinden çalıştırabilirsiniz. Burada çok dikkatli olmanız gereken bir şey var. Aşağıdaki kodlar sadece servisin durumunu değiştirmiyor senkronizasyon database'ini sıfırlıyor. Aşağıdaki kodlar çalıştıktan sonra yapmış olduğunuz tüm senkronizasyon ayarları sıfırlanacak ve her şeyi yeniden yapmanız gerekecektir, aşağıdaki kodları çalıştırmadan önce mutlaka senkronizasyon ayarlarınızı bir yere not edin, burada Backup işinize yaramaz çünkü zaten amacınız mevcut durumu yok etmek mevcut durumun Backup'ını almak yerine senkronizasyon ayarlarınızı bir yere not edin. Tabi bu işlemlerden önce farmdaki diğer ayarlar için Full Backup almanızı şiddetle tavsiye ederiz :)

$syncDBType = "Microsoft.Office.Server.Administration.SynchronizationDatabase"
$upaSAType = "User Profile Service Application"
$syncDB = Get-SPDatabase | where-object {$_.Type -eq $syncDBType}
$upa = Get-SPServiceApplication | where-object {$_.TypeName -eq $upaSAType}

$syncDB.Unprovision()
$syncDB.Status = "Offline"
$upa.ResetSynchronizationMachine()
$upa.ResetSynchronizationDatabase() 
$syncDB.Provision()

restart-service SPTimerV4

Bahçeşehir Üniversitesi SharePoint Semineri

Bu gün Bahçeşehir Üniversitesi'de düzenlenen etkinlikte SharePoint 2013 ve Office 365 anlatma fırsatı buldum, özellikle Office 365'in sağladığı kolaylıklar katılımcıların dikkatini çekti ve bu doğrultuda kafalardaki soru işaretlerini gidermeye çalıştık. Bu etkinlikten dolayı sevgili Onur Yazıcı ve Bahçeşehir Üniversitesi öğrencilerine çok teşekkürler. 

SharePoint 2013 Sp1 Yayında

Microsoft SharePoint Server 2013 için Service Pack 1'i duyurdu. Service Pack içerisinde bu güne kadar olan tüm Update Pack'ler geliyor olacak. Service Pack'de göze çarpan en büyük değişiklik SkyDrive'ın One Drive olarak karşımıza çıkıyor olması ve Yammer ile daha kolay entegre olabiliyor olmak. Service Pack ile ilgili detaylı bilgiyi http://blogs.office.com/2014/03/03/sharepoint-server-2013-service-pack-1-now-available/ adresinden edinebilirsiniz.

Hata: We're still collecting the latest news. You may see more if you try again a little later.

SharePoint 2013'te Newsfeed'inize tıkladınız ve sizi We're still collecting the latest news. You may see more if you try again a little later. yazısı karşılıyor. Biraz hatta bir kaç gün beklediniz ve hala aynı yazı sizi karşılıyor ise bunun 2 neden olabilir. Ya gerçekten hiç kimse uzun süredir bir şey paylaşmamış ya da Distribute Cache servisininiz doğru çalışmıyor. ilk durum için aksiyon almanıza gerek yok ama ikinci durum için işler pek de iyi gitmiyor demektir. SharePoint 2013 Newsfeed performans gereksinimleri nedeni ile datayı size Cache'den getirir, Cache'den datanın gelmesinden sorumlu olan servis SharePoint 2013 Distrubute Cache servisidir ilk olarak bu servisin çalıştığından emin olmak gerekiyor burada işler oldukça kolaydır ve Central Admin sitesi üzerinden servisin çalışıp çalışmadığını görebilirsiniz.

Distribute Cache servisi çalışıyor ve hala aynı hatayı alıyorsanız arka plandaki servise göz atma zamanı gelmiş demektir. Distribute Cache servisi de arka planda AppFabric Caching Servisini kullanır. Bu servis bir Windows servisidir ve hatayı yakalamak için mutlaka AppFabric Caching servisine de göz atmanız gerekir, eğer çalışmıyorsa çalıştırın. Servisin çalıştırılmasının ardından göz atmanız gereken bir durum daha vardır. Distribute Cahce servisi birden fazla makine üzerinde çalıştırıldıysa arka planda bir Cache Cluster oluşur ve gerekli Cache'leme işlemleri Cluster üzerinden yürütülür. Cache Cluseter'ın doğru çalışıp çalışmadığını gözlemlemek için Power Shell ekranı üzerinden aşağıdaki kodu çalıştırın.

Get-CacheHost

Burada eğer hata dönüyorsa büyük ihtimalle Cache Cluster'ınız aktif değil ya da üzerinde bulunduğunuz sunucu Cache Cluster'ı kullanmıyor demektir. Cache Cluster'ı kullandırmak için aşağıdaki kodu kullanabilirsiniz. Tabi ki bu işlemleri Distribute Cache servisinin çalıştığı tüm makinelerde yapmanız gerekiyor.

Use-CacheCluster

Yukarıdaki kodun ardından tekrardan Get-CacheHost kodunu çalıştırın ve bu sefer eğer bir aksilik yoksa Cache Cluster'ı Cluster'a dahil olan sunucuları ve durumlarını görüyor olacaksınız. Eğer burada bir problem yoksa belli bir süre sonra Newsfeed'inizde o andan sonra paylaşılan Feed'ler geliyor olacaktır. Cache Cluster üzerinde faklı problemler söz konusu ise AppFabric Caching Service üzerindeki hatalara yoğunlaşmanız gerekiyor.

SharePoint Nasıl Yapılır: Doküman Kütüphanelerinde versiyonlama işlemleri

SharePoint'in kullanım amaçlarından biri de Doküman Yönetimi içindir, dokümanlarınızı yönetirken arka planda alt ve üst versiyonlarınızın oluşturulması için bir kaç ayar yapmanız gerekiyor. SharePoint eğer siz isterseniz dokümanlarınızın N sayıda versiyonunu sizin için arka planda saklayabilir ve aynı URL üzerinden her zaman size sizin görebileceğiniz son versiyonu servis eder. Sizin göreceğiniz son versiyon cümlemizi biraz daha açmak için ilk olarak SharePoint'in doküman versiyonlama mekanizması üzerinde konuşalım.

SharePoint dokümanların Major ve Minor versiyonlarını oluşturabilir. Major versiyonlar son kullanıcıların gördüğü yayınlanmış olan versiyonlar olarak nitelendirilirken Minor versiyonlar ise genellikle üzerinde çalışılan yani Draft versiyon olarak düşünülür. Doküman kütüphanesi üzerinde yer alan bir ayar ile Draft versiyonun son kullanıcılardan otomatik olarak gizlenmesini sağlayabilirsiniz ve siz doküman üzerinde çalışırken son kullanıcı sizin en son yayınladığınız Major versiyonu görmeye devam eder, yani yetki seviyenize göre aynı URL üzerinden size dokümanın görebileceğiniz son versiyonu servis edilir. Tabi burada SharePoint penceresinden baktığımızda Word, Excel, PowerPoint, ses, video ya da herhangi bir web sayfasının bir doküman olduğunu vurgulamakta fayda var, yani ShrePoint ile geliştirilmiş bir sitenin herhangi bir sayfası da bizim için bir doküman ve yukarıda açıkladığımız durum web sayfası için de geçerli, web sitesi geliştirirken de bu özellikten faydalanıp aşağıda açıklayacağımız işlemleri gerçekleştirebilirsiniz.

Herhangi bir kütüphanede versiyonlamayı aktif hale getirmek için Ribbon'dan Library Settings (Kütüphane Ayarları) bölümüne geçmeniz gerekiyor. Library Settings sayfasında sol bölümde yer alan Versioning Settings bölümünden gerekli ayarları yapabilirsiniz.

 

Versiyon ayarlarını daha geniş ele almak için sayfamızı en temelden ele almaya başlayalım. Bu sayfada yer alan en önemli özelliklerden bir tanesi de Content Approval özelliğidir. Versiyonlama özelliğinden bağımsız olarak açıp kapabileceğiniz Content Approval özelliği ile içeriklerin onaylı olarak yayınlanmasını sağlayabilirsiniz ve Content Approval'ı aktif ettiğinizde kütüphaneye o andan sonra upload edeceğiniz her doküman bir onaya sunulur ve onaysız dokümanlar son kullanıcılara servis edilmez. Onaysız dokümanlar sadece kütüphane üzerinde değil arama sonuçlarında da kesinlikle servis edilmez ve kritik bilgileriniz meraklı gözlerden korunmuş olur. Burada son kullanıcılar diye bahsettiğimiz hedef kitle sadece okuma hakkına sahip olan kullanıcılardır. Peki onayları kim verecek? Herhangi bir SharePoint sitesinde son kullanıcılara yetki verirken ya da izin seviyelerini ayarlarken Approvals şeklinde bir yetki görmüş olmalısınız Approve (Onay) yetkisi olan herhangi bir kullanıcı herhangi bir dokümanı onaylayabilir. Buradaki iş akışı tek seviye ve paralel bir iş akışıdır.

 

 

 

Document Version History bölümü ise dokümanlar üzerinde versiyonlama özelliğinin aktif olup olmayacağını belirttiğimiz bölümdür. Bu bölümde dikkat ederseniz iki farklı seviye söz konusu. İlk paragrafta da açıkladığımız gibi buradan Major ve Minor versiyonların aktif olup olmayacağını seçebiliyorsunuz. Sadece Major versiyoları aktif edip her verisiyonu bir öncekinin yedeği gibi düşünebilir ya da hem Major hem de Minor versiyonu aktif edip son kullanıcılar en son Major'u görürken siz yeni versiyon oluşturmak için aynı sayfa üzerinde çalışmalarınızı sürdürebilirsiniz. Seçmiş olduğunuz versiyonlama tipine göre alt taraftaki kutuların aktif olduğunu göreceksiniz, burada geriye dönük kaç Major ve Minor versiyonun saklanacağını belirtebiliyorsunuz. Bu bölümde kapasite planlaması açısından çok önemli bir bölümdür eğer gereksiz yere fazla versiyon saklarsanız diskinizin planladığınızdan daha önce dolduğunu göreceksiniz bu sebeple burada dokümanlarınızın kritiklik seviyesine göre bir limit vermeniz son derece anlamlıdır.

Draft Item Security bölümünden ise Minor versiyonların güvenlik seviyesini ve kimlere görüntüleneceğini belirtiyorsunuz. Bu bölüm dikkat ederseniz varsayılan olarak herkese açıktır ancak yapacağınız bir ayar ile sadece kütüphanede düzenleme yetkisine sahip kullanıcılar tarafından görüntülenmesini ya da onaylama ve o öğeyi en son güncelleyen kişi tarafından görüntülenmesini sağlayabilirsiniz.

Require Check Out özelliği ise doküman üzerinde birlikte çalışan kişilerin birbirlerinin değişikliklerini ezmemesini sağlayabilirsiniz. Yani bir kişi doküman üzerinde çalışacağı zaman dokümanı CheckOut yapıp kendi üzerine alabilir ve o kişi düzenlemeyi bitirip değişiklikleri CheckIn komutu ile sunucuya yükleyinceye kadar herkes ilgili dokümanı readonly görecektir. Bu özelliği Yes olarak ayarlayacak bu işlemi zorunlu hale getirebilirsiniz ki biz genellikle bu şekilde kullanmanızı öneririz.

Hatırlatma: SharePoint Object Model Development SystemUpdate metodu.

SharePoint üzerinde kod geliştiriyorsunuz ve yazdığınız bir program aracılığı ile ya da Event Receiver üzerinden bir listenin bir öğesini update ediyorsunuz. Zaman zaman kullanıcılardan bu tarz işlemler sonucunda maillerin gittiği ya da bazı iş akışlarının çalıştığı veya update eden kişinin değiştiği şeklinde hatalar alıyoruz. Yapılan update işleminden sonra herhangi bir olayın tetiklenmemesi için ya da tabir caizse hayalet gibi işlem yapmak için SystemUpdate metodunu kullanabilirsiniz. Bu metod belirttiğiniz işlemi istediğiniz gibi yapacak ve ardından hiç bir olay çalıştırmayacaktır ve son kullanıcı bu updateden haberdar olmayacaktır. Metod hakkında gerekli bilgi için http://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.splistitem.systemupdate(v=office.15).aspx adresini ziyaret edebilirsiniz.

SharePoint Update Pack'lerin Kurulumu

Bildiğiniz gibi Microsoft düzenli aralıklarla ürünlerle ilgili Update Pack'ler yayınlıyor. Sistemde karşılaşılan belli problemler özelinde iyileştirmeler içeren bu güncellemeleri sisteme kurmak zaman zaman zorunluluk oluyor. SharePoint 2013 üzerindeki tüm update pack'lere http://technet.microsoft.com/en-us/sharepoint/jj891062.aspx adresinden erişebilirsiniz. 

SharePoint 2013'ü ilk kurduğunuzda SharePoint'in RTM olarak yüklendiğini fark etmiş olacaksınız. Update'leri kurabilmeniz için ilk olarak Mart 2013 Public Update'ini kurmak zorundasınız yukarıda belirttiğim linkten ilk olarak bunu indirip sisteminize kurabilirsiniz. Tabi burada ufak bir hatırlatma yapmak gerekiyor; Dosyayı indirmeye başladığınızda oldukça büyük olduğunu fark edeceksiniz bu da aslında demek oluyor ki kurulum oldukça uzun sürebilir. Bu sebeple kuruluma başlamadan önce mutlaka hem SQL hem de SharePoint Farm Backup'ını alın. Farm'da birden fazla sunucu söz konusu ise kurulumları paralel olarak tüm sunucularda başlatabilirsiniz. Kurulumlar bittikten sonra ilk olarak tüm sunucuları yeniden başlatmanız ardından da SharePoint Product and Technologies Configuration Wizard'ı her sunucu üzerinde sırayla çalıştırmanız gerekiyor. Wizard tüm sunucularda problemsiz bir şekilde çalıştıktan sonra Update kurulumu tamamlanmış olacaktır. Ardından diğer Update'leri geçebilirsiniz. Burada önemli olan her update'i direkt geçmek yerine sisteminizde problem gördüyseniz ilgili Update'i geçmek olacaktır.

Sisteminizde hangi Update'in yüklü olduğunu tespit etmeniz için Farm Build Numaranıza göz atmanız gerekiyor bunun için Central Administration Site üzerinden System Settings / Manage Servers in this Farm yolunu takip ederek  Configuration database version başlığı altından görebilirsiniz. Burada yer alan Build numarası hangi Update'in yüklü olduğunu size belirtecektir.

Problem: Prerequest Kurulumunda Karşılaşılan Hatalar

SharePoint 2010 ile birlikte kurulum işlemleri de oldukça kolaylaştı. Daha önceki versiyonlarda çok zorlu olan kurulum süreci 2010 versiyonundan itibaren artık çok kolay. Internet'e bağlı bir sunucu ile her şeyi kolaylıkla yapabiliyorsunuz. SharePoint kurulumundan hemen önce Prerequest kurulumunu çalıştırıp bekliyoruz ve Prerequest Setup aracı bizim için gerekli işlemleri yapıyor. Tabi hayat her zaman bu kadar rahat olmuyor; zaman zaman bu adımda da hata ile karşılaşıyoruz ve bu sorunların üzerinden gelmek zorunda kalıyoruz. Aşağıda sık karşılaşılan bir kaç problemi birlikte inceleyelim tabi ki daha farklı problemlerde olabilir ancak probleminiz umarım bunlardan biridir;

Sunucu Internet'e Bağlı Mı?
Pek çok kurumsal firmada sucular varsayılan olarak Internet'e bağlı değildir, makinenin network'e bağlı olması Internet'e bağlı olacağı anlamına gelmiyor maalesef, ilk olarak bu adımı kontrol etmenizde fayda var. Sunucuya Proxy sunucusu vs belirtmek gerekiyor olabilir. Eğer güvenlik kısıtlamaları nedeni ile sunucunun Internet'e çıkması söz konusu değilse http://social.technet.microsoft.com/wiki/contents/articles/14582.sharepoint-2013-install-prerequisites-offline-or-manually-on-windows-server-2012-a-comprehensive-guide.aspx adresindeki adımları izleyip gerekli toolları manual olarak download edip kurmanız gerekiyor.

Sunucunun Dosya İndirmesi kısıtlanmış olabilir mi?
Sunucu Internet'e bağlıdır ama download hakkı kısıtlanmış olabilir, bu da sık karşılaştığımız problemlerden bir tanesi yine manual bir dosya indirerek bu adımı da kontrol etmenizde fayda var.

Prerequest Tool'u Application Server Rolünü kurabildi mi?
Üstte belirttiğimiz iki hata herhangi bir uzmanlık gerektirmeyen ancak dalgınlıktan atlanabilecek bir kaç madde. Ancak her şey yolunda ve Prerequest kurulum aracı sunucuda Application Server rolünü yani IIS'i kurmuyorsa daha ciddi problemlere merhaba diyebilirsiniz. Bu adımda en sık karşılaştığımız hata sunucu kurulurken gerekli dosyaların tamamen eklenmemiş olmasıdır bu adımda Application Server rolünü manual kurmanız gerekebilir ve genellikle bu adımda da hata alırsınız.
Bu senaryoda Windows Server 2012'inizin AddRemove Features bölümüne gitmeniz gerekiyor ve gerekli bileşenleri seçtikten sonra yükleme için bir Alternate Path belirtip kurulum dosyalarını göstermeniz gerekiyor. Bu adımda IIS problemsiz bir şekilde kurulursa Prerequest aracını yeniden çalıştırıp diğer maddeleri sihirbaza kurdurabilirsiniz.

Yine gerekli bileşenlerin Internet'ten download edilmesi için de sunucu üzerinde bir ayar yapıp Prerequest aracını tekrardan çalıştırmanız gerekiyor bunun için aşağıdaki maddeleri takip edebilirsiniz.

1. Run penceresine MMC yazın ve MMC konsolunu açın.
2. MMC penceresinde File/Add-Remove Snap-in menüsünü seçin.
3. Açılan menüden Group Policy Object Editor objesini seçip Add butonuna tıklayın.Ardından ok diyerek bu ekranı geçin.
4. Group Policy Object Editör ekranında Administrative Templates/ System seçeneğine gelin.
5. "Specify Settings for optional component installation and component repair" seçeneğini seçip düzenleyin.
6. İlk olarak Enable seçeneğini seçin ve alttaki checkBox'lardan "Contract Windows Update directly to download repair content instead of Windows Server Update Services (WSUS)" seçeneğini seçin.
7. Kaydedip MMC'i kapatın ve Prerequest aracını yeniden çalıştırın.

Yukarıda belirttiğimiz hatalar haricindekiler için araç hata verdiğinde bir log dosyası üretir, bu log dosyasındaki bilgiler çok çok kıymetlidir. Buradaki hataları bulup ardından bu loglara göre araştırma yapmanızı tavsiye ederim.

Windows Server'da Loopback Check İşlemini Disable Etmek

SharePoint'te DNS yönlendirmesi yaptığınızda sunucu üzerinden lokaldeki web application'a erişemediğinizi fark etmişsinizdir. Siteyi çağırıyorsunuz ancak kullanıcı Authenticate olamıyor ve doğal olarak siteye erişemiyorsunuz. Dışarıdan siteye eriştiğinizde problem olmayacaktır ancak bu durum SharePoint'in servisleri açısından can sıkıcı durumlar oluşturabilir. Örneğin Search Servisi siteye erişmeye çalışacak ve doğal olarak erişemeyecektir. İçeriğiniz düzgün bir şekilde Crawl edilmediği için de aramalarınız sonuç vermeyecektir.

Yukarıda açıkladığımız durum Windows Server'ın varsayılan güvenlik ayarlarından kaynaklanmaktadır. Bu durumun önüne geçmek için Loopback Check işlemini Disable etmeniz gerekiyor. Bunun için maalesef bir arayüz yok mecburen çalıştıra regedit yazıp kayıt defterine geçmeniz gerekiyor. Ardından aşağıdaki adımlar ile kolaylıkla gerekli işlemi yapabilirsiniz.

1. Kayıt defterinde
   HKEY_LOCAL_MACHINE\
   SYSTEM\
   CurrentControlSet\
   Control\
   Lsa
   düğümünü bulun. 
2. LSA düğümüne tıklayın ve içerikte aşağıdaki resimde gördüğünüz gibi sağ tıklayıp yeni bir DWORD değeri ekleyin.
   
   
3. Eklemiş olduğunuz değerin adını DisableLoopbackCheck olarak belirleyin.
4. DisableLoopbackCheck değerine çift tıklayıp değerini 1 olarak belirleyin ve kaydedin.   

Bu işlemin ardından tarayıcıyı yeniden başlattığınızda artık sisteme erişiyor olacaksınız. Mevcut servislerin session'larını yenilemek için sunucuyu yeniden başlatmayı da tercih edebilirsiniz.

SharePoint Designer WorkFlow Hatası: Unable to load workflow actions.

SharePoint Designer aracılığı ile daha önce oluşturduğunuz iş akışlarını güncellemek ya da yeni bir iş akışı eklemek istediğinizde can sıkıcı bir hata ile karşılaşabilirsiniz. Hata size "Unable to load workflow actions." demektedir. Hata mesajına tıkladığınızda da maalesef sayfa görüntülenemiyor şeklinde bir hata alabilirsiniz. Bu hata can sıkıcı olmakla birlikte birden fazla nedeni olabilir. Custom yüklemiş olduğunuz bir iş akışı action'ında problem olabilir ya da gerçekten iş akışının özellikleri ile ilgili problem olmuştur. Ancak daha genel olarak bu hata Farm'da yer alan problemli bir Feature'dan kaynaklanıyor olabilir. Evet yanlış okumadınız garip ama gerçek. Feature yanlış yüklenmiş olabilir ve burada yüklenmesi gereken sayfanın yüklenmesini engelliyor olabilir ya da Feature'ın fiziksel klasöründe bir problem oluşmuş olabilir ve bu nedenle hata veriyordur.

Farm'daki hangi Feature'ın buna neden olduğunu anlamak için Fiddler (http://fiddler2.com) isimli programdan faydalanabilirsiniz. Fiddler bir Web Debugging tool'udur ve sayfayı debug edip hataları görmenize olanak tanır. Üreticisi hiç de yabancı olmadığımız Telerik firmasıdır ve tabi ki güvenilirdir. :) Belirtmiş olduğum adresden Fiddler'ı indirip kurduktan sonra problemli olan siteyi izlemeye başlayabilirsiniz. Burada yapmanız gereken şey hatayı tekrar almak için daha önce takip ettiğiniz adımları takip etmektir. Hatayı yakaladığınız anda Fiddler'a dönün, yanında kırmızı işaretlenmiş maddeler görüyor olacaksınız. Bu adımda hatayı yakaladınız demektir ve içini detaylıca analiz etmeniz gerekmektedir. Hatanın bulunduğu satıra tıklayın ve ardından TextView tabına geçin. Burada tam anlamıyla hatanın nereden kaynaklandığını size açıklayacaktır. Burada genellikle görmeyi beklediğimiz hata SharePoint Root\TEMPLATE\FEATURES klasörü altına yer alan bir Feature'ın bulunamadığıdır. Eğer yok olan Feature sizin için önemli ve yerine koymanız gereken bir Feature ise solution'ı yeniden deploy edebilir ya da daha önce deploy ettiğiniz yerden fiziksel dosyayı buraya kopyalayabilirsiniz. Ancak hataya neden olan Feature sizin hatayla Farm'a deploy ettiğiniz ama artık işinize yaramayacak problemli bir Feature ise bunu Uninstall etmelisiniz. Fetaure'ın bir şekilde adını kestirip STSADM aracı ile Unistall edebilirsiniz ya da bunun için de CodePlex'te güzel bir uygulama mevcut.

SharePoint Feature Administration and Clean Up Tool adındaki aracı http://featureadmin.codeplex.com/ adresinden indirip kullanabilirsiniz. Araç direkt çalıştırılabilen bir exe'dir ve direkt istenilen sunucunun lokaline kopyalanıp çalıştırılabilir. Uygulama içerisinde scope'lara göre Feature'ları listeleyebiliyorsunuz ve yüklenemeyen ya da problemli olan fetaure'lar size kocaman bir ERROR yazısı ile gösteriliyor. İlgili Feaute'a tıklayıp direkt uygulama üzerinden Uninstall edebilirsiniz ve bu şekilde problemlerinizden kurtulabilirsiniz. Tabi burada ufak bir hatırlatma yapmakta fayda var. Uygulama sadece problemli değil tüm Feature'ları da silebilecek yetenektedir bu sebeple her attığınız adımda çok dikkatli olun ve bence kullandıktan sonra production ortamından uygulamayı kaldırın.

Gördüğünüz gibi basit bir Fetaure hatası portaldaki WorkFlow'larınızı yönetmenizi engelleyebiliyor. İşin güzel tarafı büyük ihtimalle yukarıdaki açıklama çözüm olacaktır eğer olmazsa yine ilk adım olarak hem farm hem de site collection düzeyine yüklenen aynı ID'li Feature var mı diye bakın derim. Eğer bu da çözüm olmazsa Internet'te araştırmaya başlayabilirsiniz.