Bu videomuzda içerik yönetimini detaylandırıp site düzeyinde yönetilen içerik tipleri ve site sütunları hakkında derinlere iniyoruz.
Perşembe, Mart 30, 2017
SharePoint Son Kullanıcı Eğitimi Bölüm 4 - İçerik Yönetimi (Part2)
Bu videomuzda içerik yönetimini detaylandırıp site düzeyinde yönetilen içerik tipleri ve site sütunları hakkında derinlere iniyoruz.
SharePoint Son Kullanıcı Eğitimi Bölüm 4 - İçerik Yönetimi (Part1)
Bu videoda SharePoint içerik yönetim sistemi temellerine giriş yapıyoruz ve genel yetenekler üzerinde tur atıyoruz.
Salı, Mart 28, 2017
Cumartesi, Kasım 26, 2016
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.
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:
Ö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.
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.
- 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.
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 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.
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.
Ü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!
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.
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.
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.
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.
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 ü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.
Salı, Aralık 16, 2014
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.
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.
Perşembe, Kasım 27, 2014
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()
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()
Cumartesi, Eylül 20, 2014
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.
Perşembe, Ağustos 14, 2014
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.
Perşembe, Temmuz 10, 2014
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.
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.
Cumartesi, Haziran 14, 2014
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.
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
- 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ış.
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
Kaydol:
Kayıtlar (Atom)