Sharepoint 2010 User Profile Service Application kullanıcı profillerini import etmek için AD tarafında “Replicating Directory Changes” yetkisine sahip bir kullanıcı ister. Ancak sadece profile import connectionun oluşturulması sırasında bu accountu belirtmeniz yeterli olmayacaktır.
Yaşayacağınız sıkıntının çözümü için User Profile Service Applicationun servis accountu olarakda bu kullanıcıyı belirtmelisiniz. Service accountu değiştirmek için Central Administration > Security Settings > Manage Service Accounts bölümünü kullanabilirsiniz.
Sharepoint 2010 ile beraber gelen gelişmiş web analytics için konfigürasyon çok da zor olmayan bir durumdadır.
- Web Analytics servisini başlatın
- Web Analytics service applicationı yaratın
- Monitoring bölümünden loggingi aktif hale getirin.
Bunun üzerine raporları göreceğiniz sitelerde “gelişmiş web analytics” featureınıda açmanız yeterli.
Sharepoint günlük olarak tuttuğu usage loglarını log klasöründe toplar ve gün içinde belirlediğiniz bir zamanlama ile bu dosyaları veritabanına import eder. Gün sonlarında ise import ettiği logları proses ederek rapor veritabanına taşır.
İşte tam bu noktada datanın import edilmesi ama proses edilmemesi sonucu raporların oluşmaması durumu ile karşılaşabilirsiniz. Kontrol ettiğinizde staging database doluyor ama reporting database 0 kayıt gösteriyordur. Bu durum için çözüm şu şekilde;
Hem reporting hem de staging databasein ownerlarını kontrol edin. Eğer bu iki databasein ownerı Web Analytics service applicationın application pooldaki kullanıcısı değilse bu şekilde güncelleyin. Owner olan kullanıcının SQL Server tarafında sysadmin rolünde olması bir çözüm değil malesef. Databse ownerın mutlaka application pool accountu olmasını sağlayın ve akşam proses görevinin yeniden çalışmasını bekleyin. Elle bu görevi çalıştırmak bazen çözüm olmuyor, bu nedenle beklemenizi öneririm.
Sharepoint içerisinde yayınladığınız PDF dokümanların kullanıcıların download etmesine gerek kalmaksızın veya browserda birtakım ayarlar yapmanıza gerek olmaksızın otomatik olarak açılabilmesi için PowerShell’de aşağıdaki komut setini çalıştırmanız yeterli olacaktır.
$mimetypes = "application/pdf","text/html","application/x-shockwave-flash"
$webApp = Get-SPWebApplication http://portal
foreach($mime in $mimetypes)
{
If ($webApp.AllowedInlineDownloadedMimeTypes -notcontains $mime)
{
Write-Host -ForegroundColor White "Adding MIME Type "$mime
$webApp.AllowedInlineDownloadedMimeTypes.Add($mime)
$webApp.Update()
Write-Host -ForegroundColor Green "MIME Type added and saved."
}
Else
{
Write-Host -ForegroundColor Yellow $mime" MIME type is already added."
}
}
BCS ile uğraşma durumunda kaldıysanız bazen nedensiz yere bağlantı kurduğunuz external sisteme ait verilerin görüntülenemediğini ve bunu da genel anlamda bir webpart hatasıymış gibi ekrana getirdiğini görmüş olabilirsiniz. Event Log veya Trace Log’u incelediğinizde de tatmin edecek bir sonuç ortaya çıkmayabilir. Bu durumda BCS Webpartlarından birini sayfanıza ekleyerek aynı external datayı göstermesini isteyebilirsiniz. Burada hatanın detaylarını görebileceksiniz.
Böyle bir başlangıçtan sonra karşımıza çıkan ve çözümlemek için aşağıda yer alan powershell komutunu kullandığımız durumu paylaşmak isterim. BCS için maksimum görüntülenebilir kayıt sayısı limitlenmiştir ve bu değer varsayılan olarak 2000′dir. Şayet bu değeri artırmanız gerekiyorsa aşağıdaki gibi bir komut işinizi görecektir.
Get-Command -Noun SP*BusinessData*
$bdcProxy = Get-SPServiceApplicationProxy | where
{$_.GetType().FullName -eq ('Microsoft.SharePoint.BusinessData.SharedService.'
+ 'BdcServiceApplicationProxy')}
$dbRule = Get-SPBusinessDataCatalogThrottleConfig -Scope
Database -ThrottleType Items -ServiceApplicationProxy $bdcProxy
Set-SPBusinessDataCatalogThrottleConfig -Identity $dbRule
-Maximum 1000000 -Default 1000000
|
Status
|
Value |
| Not Started |
0 |
| Failed on Start |
1 |
| In Progress |
2 |
| Error Occurred |
3 |
| Canceled |
4 |
| Completed |
5 |
| Failed on Start (retrying) |
6 |
| Error Occurred (retrying) |
7 |
| Canceled |
15 |
| Approved |
16 |
| Rejected |
17 |
Sharepoint arama hizmetinde herşey yolunda gidiyor ise
- Indexleme kusursuzca çalışıyor
- Kullanıcı profilleri indexleniyor
- Scopelar düzgün bir şekilde güncelleniyor
- Arama iyileştirme gibi özel web bölümleri sorunsuzca çalışıyor
ve yine de admin olmayan kullanıcılarınız sadece “People Search” yapabiliyor içerik üzerinde yaptığı aramalarda herhangi bir sonuç bulunmadığına dair mesaj alıyorsa bazı yetkilendirmeler yapmak gerekebilir.
Arka planda alınan hata şu şekildedir;
“Process – w3wp.exe (0x161C)
TID – 0x18A0
Area – SharePoint Server Search
Category – Query Processor
Level – High
Message – AuthzInitializeContextFromSid failed with ERROR_ACCESS_DENIED. This error indicates that the account under which this process is executing may not have read access to the tokenGroupsGlobalAndUniversal attribute on the querying user’s Active Directory object. Query results which require non-Claims Windows authorization will not be returned to this querying user.”
Normal şartlarda böyle bir aksiyona ihtiyacınız olmadığını belirtmek istemem ile beraber bazı senaryolarda karşınıza çıkabilecek bir durum. ve çözüm şu şekilde;
- Domain Controller‘ınıza bağlanın.
- Sharepoint Search Service ve Search Crawl accountlarını Windows Authorization Access Group içerisine ekleyin
- Yeniden crawl başlatın (çoğu zaman buna gerek olmayacaktır)
Sharepoint 2010′da Managed Metadata kolonunu kullanmaya çalıştığınızda bazen “The Taxonomy feature (Feature ID “73EF14B1-13A9-416b-A9B5-ECECA2B0604C”) has not been activated” hata mesajını alabilirsiniz. Hatanın sebebi Taxonomy özelliğinin kullanmakta olduğunuz site koleksiyonu için henüz aktive edilmemiş olmasıdır. Aktivasyon işlemini powershell ve ststadm ile aşağıdaki yöntemlerden birini kullanarak gerçekleştirebilirsiniz.
STSADM
STSADM -o activatefeature -id 73EF14B1-13A9-416b-A9B5-ECECA2B0604C
-url http://portal -force
Powershell
Enable-SPFeature -id 73EF14B1-13A9-416b-A9B5-ECECA2B0604C
-URL http:/portal
Sharepoint Designer 2010 ile hazırlayacağınız iş akışlarında varsayılan bir limitasyon bulunmaktadır. Workflow içerisinde tanımlayacağınız değişkenler, approval processlerden kaynaklı olarak workflowa eklenen diğer kaynaklar gibi pek çok workflow ürünü yapı için 7000 ile sınırlandırılmış UserDefinedWorkflowMaximumComplexity değeri.
Bu değeri aşmanız durumunda workflowunuzu publish etmeye kalktığınız zaman dosyalar kaydedilir ancak liste ile ilişkilendirilmesi yapılamaz. Bu nedenle de iş akışını deploy edemezsiniz. Limite yakın iş akışlarında ise akışın “Failed to start” gibi bir hata mesajı ile başlayamaması durumu ile karşı karşıya gelebilirsiniz.
Bu durumda çözüm Microsoft trafından yayınlanmış olan http://support.microsoft.com/kb/2557533 adresindeki knowledgebase makalesinden geliyor. Özetle SP1 sonrası düzenlememize izin verilen UserDefinedWorkflowMaximumComplexity değeri için aşağıdaki gibi bir powershell komutunu çalıştırmak yeterli olacaktır.
[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)
$new_limit = 5000;
$webapp = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup(http://WebAppURL)
$webapp.UserDefinedWorkflowMaximumComplexity = $new_limit
$webapp.Update()
Sharepoint 2010 ile de kullanabileceğiniz “Audit Logging” (Denetim Günlüğü) yapısı out-of-box olarak hazır gelmekle birlikte raporları almak istediğinizde küçük bir sürpriz sizi bekliyor olacaktır. ürün denetim adına vaadettiği tüm bilgileri toplar ama bunun raporunu görebileceğiniz bir bölüm sunmaz.
Aslında sunar ama bunun için Reporting feature’ı aktif hale getirmeniz gerekir. Aşağıdaki stsadm komutu ile featureı aktif hale getirdikten sonra Site Collection Administration başlığı altında artık ilgili menüyü görebilirsiniz.
STSADM.EXE -o activatefeature -name Reporting -url http://sitecollectionurl -force
Bazen, bazı listeleri silmenize Sharepoint izin vermez. Arayüzde “Delete this library” linkini görememeniz bir yerde designer gibi araçlardan da bu tür kütüphane ve listelere eriştiğinizde silemediğinizi görürsünüz. Bunun sebebi şüphesiz sözkonusu liste ve kütüphanelerin sistem kütüphane ve listesi olmasıdır. Tabi bazenzorunlu olarak bu kuralı yıkmanız gerekebilir. Bu işlem için aşağıda yer alan powershell scriptini çalıştırmanız ve ardından listeyi silmeniz mümkündür.
$web = Get-SPWeb http://portal
$list = $web.Lists["Sayfalar"]
$list.AllowDeletion = $True
$list.Update()
0