Evren Ayan | Bir Danışmanın Günlüğü

WSS_UsageApplication Veritabanı İsminin Değiştirilmesi

Arama hizmetini yapılandırmanız ile beraber WSS_UsageApplication ismiyle bir servis uygulaması ve aynı zamanda buna ait aynı isimle bir veritabanı yaratılır. Bu veritabanı ismini çeşitli sebeplerle değiştirmek isteyebilirsiniz. Yaratılırken ismini değiştirmek kontrolünüzde olmayan bu servis için veritabanı ismini değiştirme adımları aşağıdaki şekilde olacaktır.

Öncelikle aşağıdaki komutlar ile veritabanı ismini SQL Server düzeyinde değiştirin.

USE master;
GO
ALTER DATABASE WSS_UsageApplication SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
ALTER DATABASE WSS_UsageApplication Modify Name = 'TEST_UsageApplication'
GO
ALTER DATABASE TEST_UsageApplication SET MULTI_USER;
GO

1

2

3

4

5

6

7

8

USE master;

GO

ALTER DATABASE WSS_UsageApplication SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

GO

ALTER DATABASE WSS_UsageApplication Modify Name = 'TEST_UsageApplication'

GO

ALTER DATABASE TEST_UsageApplication SET MULTI_USER;

GO

Ardından aşağıdaki powershell komutuyla servis uygulamasının SharePoint düzeyinde veritabanı ismini yeni veritabanı ismi olarak güncelleyin.

Set-SPUsageApplication -Identity "WSS_UsageApplication" -DatabaseName "TEST_UsageApplication" -DatabaseServer "DATABASE_SERVERNAME"

1	Set-SPUsageApplication -Identity "WSS_UsageApplication" -DatabaseName "TEST_UsageApplication" -DatabaseServer "DATABASE_SERVERNAME"

Hata: This item could not be crawled because the repository did not respond within the specified timeout period

23.03.2018 Yorum yapılmamış

SharePoint 2013 veya 2016 ortamlarınızda sağlıklı çalışan bir arama hizmetinde indexleme esnasında aşağıdaki gibi bir hata ile karşılaşabilirsiniz. Bu hata sonrasında crawl işlemi duracak ve diğer öğeler için devam etmeyecektir.

“This item could not be crawled because the repository did not respond within the specified timeout period. Try to crawl the repository at a later time, or increase the timeout value on the Proxy and Timeout page in search administration. You might also want to crawl this repository during off-peak usage times”

Hatanın çözümü için aşağıdaki iki yolu deneyebilirsiniz;

Sunucu üzerinde Internet Explorer‘ı açın ve Internet Options > Connections > LAN settings bölümüne gidin. Burada “Automatically detect settings” checkboxındaki seçimi kaldırın. Ayrıca eğer internet erişimi vs için proxy kullanıyorsanız proxy ayarlarını da kapatın.
Central Administration > Manage Service Applications > Search Service Application > Farm Search Administration bölümüne gidin ve timeout sürelerini daha yüksek değerler ile değiştirin.

Bu adımlardan sonra yeniden crawl işlemini başlattığınızda sorun olmadan indexlemenin başladığını göreceksiniz.

Hata: Database is up to date but some sites are not completely upgraded

19.02.2018 Yorum yapılmamış

SharePoint’in eski bir sürümünden yeni bir sürüme yükselttiğiniz uygulamalarda bazen ön yüzde herhangi bir hata ile karşılaşmasanızda Central Administration üzerinde yer alan “Database Upgrade Status” sayfasına gittiğinizde yükseltme yaptığınız uygulamanın veritabanı için “Database is up to date but some sites are not completely upgraded” hatasını gözlemliyor olabilirsiniz. Bu hata aslında upgrade işleminin tam da istediğimiz gibi gitmediği, birşeylerin eksik olduğu anlamını taşır ve müdehale gerektirir.

Bu statüde bir veritabanınız var ise aşağıdaki PowerShell komutu ile öncelikle yükseltmesi başarıyla sağlanamamış veritabanınızın sistemdeki ID’sini öğrenmeniz gerekir.

Get-SPContentDatabase -Identity <your content database name>

1	Get-SPContentDatabase -Identity <your content database name>

Ardından aşağıdaki komut ile bu veritabanı için yükseltme işlemini zorlayabilirsiniz.

upgrade-spcontentdatabase -id <database GUID>

1	upgrade-spcontentdatabase -id <database GUID>

Bu komut esnasında hata alıyorsanız hata mesajının sizi yönlendirdiği upgrade log dosyasını incelemenizi öneririm. Zira artık hata ilk upgrade sırasında yaşanan anlık bir hatadan ziyade yükseltmeyi engelleyen bir durumunuzun olduğu anlamına geliyor. Buradaki hata olasılıkları çok çeşitli olabilir, log dosyasını iyi okumak lazım. Mesela basit bir hata olarak upgrade ettiğiniz site koleksiyonunda açık olması beklenen bir feature kapalı olabilir. Bu durumda öncelikle bu sorunu gidermeli ve ardından yukarıdaki komutları çalıştırmalısınız.

Yukarıdaki senaryoyu uyguladınız ancak yine de sayfayı kontrol ettiğinizde hata mesajını görmeye devam ediyorsunuz. Bunun nedeni sayfanın güncellenmesi için SharePoint Configuration Wizard‘ı çalıştırmanız gerekliliği. Configuration Wizard başarıyla çalıştıktan sonra artık olması gerektiği gibi “No action required” mesajını görebilirsiniz.

Yeni Web Uygulaması Yaratırken Sayfa Görüntülenemiyor Hatası

16.02.2018 Yorum yapılmamış

Herhangi bir sorunu bulunmayan bir farmda bazen yeni bir web uygulaması taratırken “Page cannot be displayed” hatası alabilirsiniz. Bu hatanın ardından yapacağınız kontrolde web uygulaması için gerekli veritabanının yaratıldığı ancak IIS web applicationın sadece lokal sunucuda yaratılıp farmdaki diğer sunucularda yaratılmadığını gözlemlersiniz. Ve hatta lokal sunucuda da IIS altındaki dizinin içeriği muhtemelen boş olacaktır.

Söz konusu web uygulaması için yeni bir site koleksiyonu yaratmak istediğinizde ise hata mesajı ile karşılaşacaksınız.

Bu hatanın yüksek olasılıklı sebebi Central Administration web uygulaması için application pool shut down timeoutunun yeterli gelmemesidir. Varsayılan olarak bu süre 90 saniye ve yeterli gelmemesi durumunda işlem yarıda kesilerek amaçladığınız sonuca ulaşmanızı engelliyor. Sorunu aşmak için aşağıdaki adımları yerine getirebilirsiniz;

IIS üzerinde Central Administration application pool’unu bulun.
Sağ tıklayarak “Advanced Settings” bölümünü açın.
“Process Model” sekmesindeki shut down limiti 90 saniye yerine 200 veya 250 saniye olarak değiştirin.
IISRESET komutunu çalıştırın.
Yeniden web uygulaması yaratmayı deneyin.

Git Repo’dan Güncel Dosyaları Pull Yöntemiyle Alamamak

06.12.2017 Yorum yapılmamış

Git Repository’den güncel dosyaları elde etmek için pull işlemi yapmak istediğinizde yaşadığım bir sorunu ve çözümünü paylaşmak isterim. Her “pull” işleminden sonra aşağıdaki şekilde bir hata alıyordum.

“Your local changes to the following files would be overwritten by merge”

Visual Studio aracılığı yaptığınız pull işlemlerinde (arayüzden) aldığınız bu hatanın çözümü için projeniz adına git komut satırını açıp aşağıdaki şekilde komutları çalıştırmak dosyaların güncellenmesine yardımcı olacaktır.

git reset --hard
git pull

1 2	git reset --hard git pull

PowerShell Yardımıyla Dosya İndirmek

04.12.2017 Yorum yapılmamış

PowerShell yardımıyla yapamayacağımız işlem yok gibi, mâlum içeriğinde doğrudan kod yazabiliyoruz. Bu noktada işe yarar bir scripti daha paylaşmak istiyorum. Bunu dilerseniz bir fonksiyon haline getirebilir, belli aralıklar ile çalışacak şekilde zamanlayabilir ve sürekli hale getirebilirsiniz.

$siteurl = "http://yoursite"
$sourcefile = "SharedDocuments/Book1.xlsx"
$destinationfile = "C:\Temp\Book1.xlsx"
$web = Get-SPWeb $siteurl
$file = $web.GetFile($sourcefile)
$filebytes = $file.OpenBinary()
$filestream = New-Object System.IO.FileStream($destinationfile, "Create")
$binarywriter = New-Object System.IO.BinaryWriter($filestream)
$binarywriter.write($filebytes)
$binarywriter.Close()

1

2

3

4

5

6

7

8

9

10

$siteurl = "http://yoursite"

$sourcefile = "SharedDocuments/Book1.xlsx"

$destinationfile = "C:\Temp\Book1.xlsx"

$web = Get-SPWeb $siteurl

$file = $web.GetFile($sourcefile)

$filebytes = $file.OpenBinary()

$filestream = New-Object System.IO.FileStream($destinationfile, "Create")

$binarywriter = New-Object System.IO.BinaryWriter($filestream)

$binarywriter.write($filebytes)

$binarywriter.Close()

Provider type not defined

30.11.2017 Yorum yapılmamış

SharePoint 2013 ortamında daha sık olmak üzere SharePoint 2016 ortamlarında da karşımıza çıkan bir hata ve çözümünden bahsetmek istiyorum. Normal şekilde çalışan bir SharePoint farmınızda bazen sadece tek bir uygulamayı (veya bazen birden fazla uygulamayı) etkiler şekilde aşağıdaki gibi bir hata mesajı ile karşılaşabilirsiniz.

SPSecurityContext: Get trust client failed with exception: System.IO.FileLoadException: Could not load file or assembly ‘Microsoft.IdentityModel.Extensions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=69c3241e6f0468ca’ or one of its dependencies. Provider type not defined. (Exception from HRESULT: 0x80090017) File name: ‘Microsoft.IdentityModel.Extensions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=69c3241e6f0468ca’ —> System.Runtime.InteropServices.COMException (0x80090017): Provider type not defined. (Exception from HRESULT: 0x80090017) at Microsoft.SharePoint.SPSecurityContext.GetTrustChannel() at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs, SecurityToken delegateTo, SPRequestSecurityTokenProperties properties)

An exception occurred when trying to establish endpoint for context: Could not load file or assembly ‘Microsoft.IdentityModel.Extensions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=69c3241e6f0468ca’ or one of its dependencies. Provider type not defined. (Exception from HRESULT: 0x80090017).

Hatanın temel nedeni uygulamanın application pool’u için kullandığınız hesabın “Impersonate a client after authentication” hakkını kaybetmiş olmasını söyleyebiliriz. Bu nedenle de çözümü bu hakkı yeniden vermek olacak. İşlemi gerçekleştirmek için aşağıdaki adımları takip edebilirsiniz.

Start > Administrative tools > Local Security Policy > Local Policies > User Right Assignments > Impersonate a client after authentication adresine gidin.
Application pool hesabını buraya ekleyin.
Sunucuyu yeniden başlatın.

Sorununuz çözülmüş olacaktır. Durumu anlık olarak kurtarmak için bir trick ise bu işlemi daha sonra yapmak üzere geçici olarak sunucuda iisreset komutunu çalıştırmış olmanız da uygulamanın yeniden çalışır hale gelmesini sağlayacaktır.

SharePoint 2013, .Net Framework 4.6

29.11.2017 Yorum yapılmamış

SharePoint 2013’ün güncel Windows Server sürümleri üzerinde (üzerinde .Net Framework 4.6 yüklü olarak bulunan veya manuel olarak yüklenmiş olan) kurulumu esnasında hemen hemen hepimizin yaşadığı, çözümü basit bir problem için kendi kişisel siteme de not bırakmak istedim 🙂

SharePoint kurulumu öncesinde mâlum, öncelikle prerequisite installer uygulamasını çalıştırarak ortamın kurulum için gerekli ön işletim sistemi bileşenlerini konfigüre etmesini ve gerekli olan eklentileri sunucuya indirerek kurmasını sağlıyoruz. Prerequisite installer’ın hiç problemsiz tamamlanmasından sonra bile .Net Framework 4.6’nın yüklü bulunduğu sistemlerde SharePoint 2016 için elinizde bulunan kurulum dosyalarını çalıştırdığınızda hata almanız mümkün. Alacağınız hata mesajı aşağıdaki gibi, bu ürünün .Net Framework 4.5 gerektirdiğini belirtiyor olacak. Halbuki, eğer dikkat ettiyseniz zaten prerequisite installer’ın ilk görevlerinden biri .Net Framework 4.5’i yüklemek ve sorunsuz tamamlanmıştı!

Bu durumun sorun olmaktan çıkması amacıyla Microsoft 1 yıl kadar önce bir KB makalesi paylaşmıştı zaten. https://support.microsoft.com/en-us/help/3087184/sharepoint-2013-or-project-server-2013-setup-error-if-the–net-framewo adresinden ulaşabilirsiniz bu makaleye.

Özetle yapılması gereken;

Eğer SharePoint kurulumunu iso gibi paketlenmiş bir yapıdan gerçekleştiriyorsanız öncelikle dosya içeriğini ayrı bir klasöre açın.
SharePoint Server için bu adresten srvsetup.dll’i indirin. Makalede SharePoint Foundation ve Project Server için olan versiyonları da var.
Zip içerisinden srvsetup.dll’i çıkartın ve SharePoint setup klasörünüz içerisindeki “updates” klasörü içerisine kopyalayın.
Şimdi kurulum exe’sini yeniden çalıştırabilirsiniz.

Arama Hizmeti Veritabanı İsmi Değiştirmek

27.11.2017 Yorum yapılmamış

SharePoint 2016 arama hizmetini Central Administration web arayüzünü kullanarak oluşturmaya çalışmak sanırım en basit yöntem ancak SharePoint Central Administration her servis uygulamasını yaratmak için farklı form arayüzleri sunuyor bizlere. Bir kısmında veritabanı ismini değiştirebilir servis seviyesinde detaylı konfigürasyonlar yapabiliyorken bir kısmında bunların bir bölümüne izin vermiyor. Arama hizmeti de bunlardan bir tanesi. Eğer Central Administration arayüzünü kullanarak arama hizmetini yapılandırırsanız SharePoint aşağıdaki dört veritabanını ismini size sormaksızın yaratacaktır.

Admin Database:
<Servis Uygulaması Adı>
Analytics Database:
<Servis Uygulaması Adı>_AnalyticsReportingDB
Crawl Database
<Servis Uygulaması Adı>_CrawlDB
Links Database:
<Servis Uygulaması Adı>_LinksDB

Halbuki bir çoğumuz özellikle paylaşımlı veritabanı sunucusu kullandığımız veya sadece benim gibi takıntılı olduğundan bu bölümde veritabanı isimlendirmelerinde bir kuralın takip edilmesini isteyecektir. Hele ki Central Administration aracılığı ile yaratıyorsanız bu isimlerin sonuna bir de GUID şeklinde uzantı gelecektir ki kabul edilemez 🙂

Bu durumu aşmak için aslında bir bölümünü benim de daha önce paylaştığım PowerShell scriptleri var. Bu sayede Search Service Application’ın en detay konfigürasyonlarına kadar script içerisinden müdehale edebiliyorsunuz. Bazen bunlarda her ortamda çalışma garantisi vermiyor tabi.

Bugün öğrendiğim bir yöntemi paylaşmak isterim. Adım adım uyguladığınızda hedefimize ulaşmamızı sağlayan bir yöntem.

Devamı

SharePoint Migration Tool from Microsoft

24.11.2017 Yorum yapılmamış

Aslında bir miktar zaman geçti aracın duyurulmasının üzerinden ancak ben bu konuda yazmaya ancak vakit bulabiliyorum. Geçtiğimiz aylarda Microsoft tarafından oldukça işimize yarayabilecek bir araç duyuruldu. Öncelikle aracın indirme bağlantısını paylaşayım : http://aka.ms/spmt

Aracı indirdikten sonra yapılması gereken oldukça basit, “install” butonuna tıklamak ve yüklenmesini beklemek. Araç bir clickonce application olarak yükleniyor ve sonraki açılışlarında güncellemeleri kendisi kontrol ediyor. Yeni çıkan bir araç olduğundan bu aralar bir miktar güncelleme gelecektir diye düşünüyorum düzeltmeler anlamında. Açılışta sizi basitçe akışı görüntüleyen bir ekran karşılıyor ve sihirbazı başlatıyorsunuz.