Benim de konuşmacıları arasında yer aldığım SharePoint Saturday Istanbul 2019 etkinliği 14 Aralık 2019‘da Microsoft Türkiye ofisinde. Etkinliğe ücretsiz olarak https://lnkd.in/de9NrHF adresinden kayıt olabilirsiniz. #SPSIstanbul #SharePoint
SharePoint Saturday İstanbul 2019
SharePoint Designer 2013 yardımıyla SharePoint 2013 seviyesinde iş akışı geliştirmek istediğinizde aşağıdaki şekilde hata mesajı alıyor olabilirsiniz.
“Unable to load workflow actions from server. Please contact your server administrator.”
Bu hata mesajını internette aradığınızda pek çoğu lokal cache’in sıfırlanmasını tavsiye eden pek çok sonuç elde etmeniz mümkün. Ancak benim gibi bu gönderiler sizin de sorununuzu çözmemiş olabilir. Bu durumdaysanız aşağıdaki güncellemeyi yüklemenizi öneriyorum.
https://www.microsoft.com/en-us/download/details.aspx?id=50708
Yeni konfigüre ettiğiniz bir SharePoint farmında Infopath tabanlı formlarınızı web tarayıcı üzerinde görüntülerken aşağıdaki şekilde hata mesajı alabilirsiniz.
“The form cannot be rendered. This may be due to a misconfiguration of the Microsoft SharePoint Server State Service. For more information, contact your server administrator.”
Bu durumda yapmanız gereken işlem oldukça basit. State Service Application’ın aktive edilmesi gerekiyor. Bu işlem için aşağıdaki PowerShell komutlarını kullanabilirsiniz.
Adım 1 : State Service Application Provision İşlemi
|
1 |
New-SPStateServiceApplication -Name "State Service Application" |
Adım 2 : Service Application Proxy’i Yaratın
|
1 |
Get-SPStateServiceApplication| New-SPStateServiceApplicationProxy –defaultproxygroup |
Adım 3 : Service Application Veritabanını Yaratın
|
1 |
Get-SPStateServiceApplication| New-SPStateServiceDatabase -Name "State_Service_Database" |
Adım 4 : Database Şemasını Oluşturun
|
1 |
Get-SPDatabase | where-object {$_.type -eq "Microsoft.Office.Server.Administration.StateDatabase"} | Initialize-SPStateServiceDatabase |
Detaylı bilgi için tıklayınız
SharePoint’in en eski sürümlerinden bu yana kullanılmakta olan bir yöntem olsa da son dönemde gündeme gelen OneDrive, sürükle/bırak yapısı gibi daha modern ve istemci tarafında ek bir servis gereksinimi bulunmayan yöntemler nedeniyle populerliği azalan bir özellik “Open with explorer” bağlantısı. Halen ribbon üzerinde görebiliyor ve kullanabiliyorsunuz. Ribbon üzerinde yer alan bu buton aracılığı ile doğrudan ve sorunsuz olarak işlemi yapabiliyorken bazen bu butonun sahip olduğu fonksiyonaliteyi örneğin hazırlayacağınız bir web bölümü üzerindeki bir buton veya linke kazandırmak isteyebilirsiniz.
Standart bir link vermek maalesef bu konuda sizin için çözüm olmayacak. Çünkü arka planda “Access Denied” hatası alacaksınız. Bu bölümde vereceğiniz link bir UNC path’e olmak zorunda. Bu durumda ise istemci tarafındaki tarayıcınız çalıştırılabilir bir dosya için link olduğunu düşünüyor ve güvenlik gerekçesi ile bağlantının çalışmasına izin vermiyor. Bu nedenle vereceğiniz bağlantıyı aşağıdaki gibi oluşturabilirsiniz.
|
1 |
<a href='#' onClick = "javascript:CoreInvoke('NavigateHttpFolder', 'http://sharepoint/sites/SiteName/LibraryName', '_blank');">Explorer ile aç</a> |
Bu bölümde doğrudan kütüphanenin adresini vermek yerine isterseniz kütüphane içerisindeki alt klasör isimleri ile linkinizi derinleştirebilirsiniz.
SharePoint üzerinde yazılım geliştirme işlemleri yaparken zaman zaman bağlı olan kullanıcının yetki seviyesinin üzerinde bir işlemi kontrollü şekilde daha yüksek bir yetki seviyesinde gerçekleştirmek isteyebilirsiniz. Örneğin arayüz üzerinden bir webpart yardımıyla seçilen kullanıcılara yetki vermek istiyorsunuz. Varsayılan olarak webpartınız o anda bağlı olan kullanıcının yetki seviyesinde çalışacak ve eğer bağlı kullanıcının “Full Control” yetkisi yoksa hata mesajı almasına neden olacaktır.
Bu durumda kodlarınızı aşağıdaki blok içerisine almanız kodlarınızın daha yüksek bir yetki seviyesi ile çalıştırılmasına yardımcı olur ve yaşanan sorunu ortadan kaldırabilirsiniz. Şüphesiz dikkatli kullanılması gereken bir kod bloğu.
|
1 2 3 |
SPSecurity.RunWithElevatedPrivileges(delegate() { //kodlarınız bu kısma gelmeli }); |
Ancak bazen bu blokları kullanmanıza rağmen işlemin gerçekleşmediğini ve arka planda logları incelediğinizde alınan hatanın Access Denied olduğunu gözlemleyebilirsiniz. Bu durumun büyük olasılıkla nedeni bu kod bloğu dışında oluşturulmuş olan bir SPWeb veya SPSite nesnesini kullanıyor olmanızdır. Yani örneğin aşağıdaki gibi kullandığınızda sorun yaşayabilirsiniz.
|
1 2 3 4 5 6 |
SPSite site = SPContext.Current.Site; SPWeb web = SPContext.Current.Web; SPSecurity.RunWithElevatedPrivileges(delegate() { //bu kısımda site ve web nesnelerini kullandığınızı varsayıyoruz }); |
Bu kullanım yerine SPSite ve SPWeb‘in bir instance’ının da SPSecurity.RunWithElevatedPrivileges içerisinde yaratılması ve bu nesnelerin kullanılması sorununuzu çözecektir. Yani kod bloğunu aşağıdaki gibi yapılandırabilirsiniz.
|
1 2 3 4 5 6 7 8 9 |
SPSite site = SPContext.Current.Site; SPWeb web = SPContext.Current.Web; SPSecurity.RunWithElevatedPrivileges(delegate() { using (SPSite elevatedSite = new SPSite(site.ID)) using (SPWeb elevatedWeb = elevatedSite.OpenWeb(web.ID)) { //kodlarınız bu kısıma gelecek } }); |
Gecikmiş bir yazı ancak halen pek çok kişi tarafından sorgulandığını gözlemliyorum. Eylül 2018 döneminde yayınlanan aylık toplu güvenlik güncelleştirme paketleri sonrası SharePoint üzerinde workflow kullanan pek çok kullanıcı (Nintex workflowları dahil) iş akışlarının durduğu veya “Bu akış sistem hesabı tarafından iptal edildi” şeklinde hata aldığı sorunu ile çözüm arayışına geçti. Aslında güvenlik güncellemesinden kısa bir süre sonra Nintex gibi bu servisi kullanan geliştiriciler ve Microsoft tarafından yapılması gereken düzenlemeye ilişkin bilgi paylaşıldı ancak farkına varılmayabiliyor.
Microsoft’un orjinal destek yazısına bu bağlantıdan ulaşabilirsiniz. Kısa bir özet ile bu sorunun nasıl ortadan kaldırılacağı ise şu şekilde.
İlk yöntem elbette yüklenen güvenlik güncellemesini geri almak ancak bu kalıcı bir çözüm değil. Bir anda farkettiğiniz soruna ilişkin kalıcı çözüm devreye alınana kadar sözkonusu güncellemeleri sunucudan silebilirsiniz. Sonrasında ise her web uygulamanızın (elbette tüm web front-end sunuculardaki) web.config dosyasına aşağıdaki satırları eklemeniz gerekecek. (Web.config içinde <AuthorizedTypes araması yaparsanız varsayılan olarak ekli olanların bulunduğu node’a erişebilirsiniz),
|
1 2 3 4 5 6 7 |
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeBinaryOperatorExpression" Authorized="True" /> <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodePrimitiveExpression" Authorized="True" /> <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeMethodInvokeExpression" Authorized="True" /> <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeMethodReferenceExpression" Authorized="True" /> <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeFieldReferenceExpression" Authorized="True" /> <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeThisReferenceExpression" Authorized="True" /> <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodePropertyReferenceExpression" Authorized="True" /> |
İşlem sonrası AppPool recycle olacak ve artık workflowlarda hata almıyor olacaksınız.
SharePoint farm sunucuları üzerinde bir işletim sistemi veya MS Patch yüklemesi yaptıktan sonra zaman zaman karşılaşabileceğiniz hizmet kesintileri sözkonusu olabilir. Aldığınız hata aşağıdaki şekilde ise ve web uygulamalarınıza veya Central Administration web uygulamasına erişirken hata alıyorsanız aşağıdaki şekilde müdehale etmeniz gerekecektir.
“Loading this assembly would produce a different grant set from other instances”
Bu sorunu çözmek için hızlı bir çözüm olarak sorun yaşana uygulamanın web config’inde aşağıdaki şekilde olan değeri
|
1 |
<trust level="Full" originUrl="" legacyCasModel="true" /> |
şu şekilde değiştirmeniz yeterli olacaktır.
|
1 |
<trust level="Full" originUrl="" legacyCasModel="false" /> |
Ancak bu işlem Microsoft tarafından desteklenmiyor ve olası bir Microsoft destek işleminizde ürününüzün destek kapsamı dışına çıkmasına neden olabilir. Bu nedenle tüm web uygulamalarında bu işlemi yapmak yerine aşağıdaki şekilde registry üzerinden tek seferde düzenlemenizi yapabilirsiniz.
Start > Run > regedit sonrası “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework” anahtarına kadar gelin ve buraya yeni bir DWORD yaratın. İsim olarak “LoaderOptimization” kullanacağız. Ve varsayılan değer olarak “1” yazabilirsiniz.
İşlem sonrası IISRESET yapabilirsiniz ancak yapmasanızda geçerli olacaktır.
Eski bir sorun esasen ancak sıklıkla sorulan bir yapıda olduğundan buradan da ayrıca paylaşmak isterim. SharePoint 2013 itibariyle çıkan versiyonlarda kullanıcı menüsü üzerinde bulunması gereken “Sign-in different user” bağlantısı yer almıyor. Bu nedenle de özellikle test işlemleri gerçekleştirirken birden fazla kullanıcı ile çalışmak istediğinizde sorun oluyor. Herhangi bir ek düzenlemeye ihtiyaç duymadan site adresinizin sonuna aşağıdaki şekilde bir bağlantı ekleyip entera basarak farklı kullanıcı ile oturum açmak için gereken kullanıcı adı / şifre ekranını karşınıza getirebilirsiniz.
|
1 |
/_layouts/closeConnection.aspx?loginasanotheruser=true |
Ama bu sorunu kökünden halledip kullanıcı menüsünde bir seçenek haline getirmek istiyorsanız aşağıdaki işlemi yapmanız daha kesin çözüm olacaktır.
|
1 |
<SharePoint:MenuItemTemplate runat="server" ID="ID_LoginAsDifferentUser" Text="<%$Resources:wss,personalactions_loginasdifferentuser%>" Description="<%$Resources:wss,personalactions_loginasdifferentuserdescription%>" MenuGroupId="100" Sequence="100" UseShortId="true" /> |
Bu sayede artık kullanıcı menüsünü açtığınızda aşağıdaki gibi farklı kullanıcı ile oturum ama seçeneği karşınıza gelecektir.
SharePoint web uygulamalarınızda dosyalarınız varsayılan olarak istemci uygulamasında açılabilmesi için temel bir dizi işlemi gerçekleştirmeniz gerekebilir. Öncelikli olarak bu işlemi kütüphane seviyesinde gerçekleştirmek için kütüphanenizin ayarlar bölümünden işlem yapabilirsiniz.
Kütüphane > Ayarlar > Gelişmiş Ayarlar > Belgeleri Tarayıcıda Açma bölümünden seçiminizi yapabilirsiniz.
Bu işlemin site seviyesinde gerçekleşebilmesi için site koleksiyonu özellikleri içerisinden “Belgeleri Varsayılan Olarak İstemci Uygulamada Aç” özelliğini aktive edebilirsiniz.
Yapacağınız bu işlem site koleksiyonunda yaratılacak yeni belge kitaplıklarında ilk maddede yaptığımız ayarda olduğu gibi varsayılan olarak istemci uygulamada açma ayarını düzenleyecektir. Ancak mevcut kütüphaneler için maalesef işe yaramayacak. Bu durumda her bir kütüphane için manuel olarak bu işlemi gerçekleştirebilir veya aşağıdaki gibi bir PowerShell script ile bu işlemin otomatik yapılmasını sağlayabilirsiniz.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Add-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue $SiteUrl = "http://siteaddress" $WebsCollection = Get-SPSite $SiteURL -Limit All | Get-SPWeb -Limit All foreach($web in $WebsCollection) { $LibrariesCollection =$web.Lists | where {$_.BaseType -eq "DocumentLibrary" -and $_.BaseTemplate -eq "DocumentLibrary"} foreach($Library in $LibrariesCollection) { $Library.DefaultItemOpen = "PreferClient" $Library.Update() } } |
SharePoint ortamınızda uygulamalarınızın içerik bilgisini saklamak için SQL Server Remote Blob Storage (RBS) özelliğini kullanıyorsanız yaşamış olacağınız bir problem dosyaların SharePoint ortamından silinmesine rağmen dosya sisteminde yani diskinizde herhangi bir kullanım azalması olmamasıdır. Biraz daha açacak ve genel olarak SharePoint’in çöp kutusu mekanizmasına da bakacak olursak;
Bildiğiniz üzere SharePoint altyapınızda iki kademeli bir çöp kutusu mekanizması yer almaktadır. Bir kütüphaneden sildiğiniz bir dosya öncelikle ilgili sitenin çöp kutusuna taşınır. Varsayılan olarak burada kalma süresi 30 gündür ki bu değer Central Administration aracılığı ile değiştirilebilir. 30 günlük sürenin geçmesinin ardından eğer dosyayı restore etmediyseniz bu defa site koleksiyonunun çöp kutusuna taşınır. Ve yine varsayılan bir ayar olarak 30 gün de burada kalır. Ve ardından artık dosya tamamen silinir. Çöp kutusunda kaldığı süre içerisinde elbette bir soft delete işleminden bahsediyoruz. Dosya sadece silinmiş olarak işaretlenmekte ve restore komutunuz ile aynı şekilde geri alınabilmektedir. Buraya kadar varsayılan bir SharePoint sisteminin davranış şeklini inceledik. Eğer RBS kullanıyorsanız işte tam bu aşamada dosyanın halen blob storeda saklanmakta olduğunu, diskten silinmediğini gözlemleyebilirsiniz. Tabi bunu genelde tek bir dosya silme işleminde hissetmeyiz. Genellikle problemin farkına vardığımız an diskimizin sürekli dolması ve yüklü dosya silme işlemlerimizin ardından bile diskte bir azalma olmadığı zamanlardır.
