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

SQL Server Sunucusunu Sonradan Domaine Almak

Daha çok test veya geliştirme ortamı senaryosu olabilir ancak yine de hiçbir zaman karşımıza çıkmayacağını düşünebileceğimiz kadar masum olmayan konulardan biridir bir sunucuyu yazılımsal işlemler sonrası aktif dizine (domain) almak. Canlı ortamlarında elbette gerekli kurumların bir ön gereksinimidir sunucunun aktif dizinde olması ama yukarıda da bahsettiğim gibi test veya geliştirme ortamlarında veya klonlanmış sanal ortamlarda sunucu adını değiştirmek, sunucuyu aktif dizine almak daha sık gerçekleştirilir.

Aktif dizin yokken konfigürasyonu yapılan bir yazılım, sunucu aktif dizine alındıktan sonra çok farklı davranabilir. Ben bu ufak bilgilendirme yazısında SQL Server üzerinden gitmek istiyorum. Sunucuyu SQL Server kurulumu sonrasında aktif dizine almayı denerseniz karşılaşacağınız temel senaryo şu şekildedir.

Named-Pipes protokolü “Disabled” duruma gelmiştir.
SQL Server Management Studio‘ya bağlanamazsınız.
SQL Server servisleri durmuştur ve başlatamazsınız.

Bu durumun üstesinden gelmek için öncelikle “SQL Server Configuration Manager” ile “Named-Pipes” ı yeniden “Enable” duruma getirin. Ardından Management Studio’ya bağlanamama ve servislerin başlamama sebebi olan kullanıcılarınız yetkisi kısmına geliyoruz. Aktif dizinden önce lokal hesaplarınız sunucuda yönetici rolündeydi ama artık lokal hiçbirşey kalmadı. O halde yeni kullanıcılarınıza hak vermeniz lazım. Bunun için bilinen en kısa yol Management Studio ve oraya erişiminiz yok. Öncelikle bir uyarı, aktif dizine alma işlemi öncesi sunucuda “SQL Server and Windows Authentication” özelliğini aktif hale getirin ve geçici de olsa “sa” kullanıcısına hak verin ki aktif dizine girdiğinizde yeni kullanıcılarınıza hak vermek için sisteme bağlanabilin.

Ama diyelim ki bu yazıyı okuduğunuzda iş işten geçmişti, o halde “SQLCMD” ye merhaba diyelim. Aşağıda yer alan komutlar ile SQLCMD üzerinden yeni kullanıcılarınıza hak verebilir ve hem SQL Server Management Studio erişimi hem de servislerinizin yeniden çalışmaya başlamasını sağlayabilirsiniz.

create login [DOMAINAdministrator] from windows;
exec sp_addsrvrolemember 'DOMAINUser', 'sysadmin';

1 2	create login [DOMAINAdministrator] from windows; exec sp_addsrvrolemember 'DOMAINUser', 'sysadmin';

Hata: Web Application Oluştururken Sayfa Görüntülenemiyor Mesajı

11.12.2018 Yorum yapılmamış

SharePoint farmınızda yeni bir web application yaratmak istediğinizde bazen işlem bir süre devam edip ardından “Sayfa görüntülenemiyor” hata mesajı verebilir. Kontrol ettiğinizde web applicationın sadece Central Administration’ın barındırıldığı sunucu üzerinde yaratılmış olduğunu, farmın diğer web front-end rolündeki sunucularında ise henüz yaratılmamış olduğunu gözlemlersiniz.

Ve bu durumdayken web application altında bir site collection yaratmak istediğinizde hata mesajı alırsınız.

Hatanın çözümü için IIS altında Central Administration uygulaması için shutdown limitini yükseltmeniz yeterli olacaktır. İşlem adımları şu şekilde;

IIS üzerinde Central Administration uygulamasının application pool’una gidin.
Sağ tıklayın ve “Advanced Settings” kısmına gelin.
“Process Model” bölümü içerisindeki “Shutdown time limit” alanı değerini yükseltin. Mesela 200-250 gibi bir değer verebilirsiniz.
IIS’i restart edin (iisreset)

PowerShell Kullanarak Tüm SharePoint Health Analyzer Kurallarını Çalıştırmak

04.12.2018 Yorum yapılmamış

PowerShell’in artık işe yaramadığı bir nokta kalmadı gibi. Pek çoğumuzun yoğun kullanmadığı, gözümüze çarptıkça veya bir süre sonra sürekli kırmızı bir bant görmekten sıkılınca baktığımız bir yer SharePoint Health Analyzer ekranı. Aslında SharePoint 2010’dan bu yana hayatımızda olup özellikle ürünün kendi kendine kontrol edebileceği temel mimari adımları kontrol eden ve olması gerekenler için bizi yönlendiren bir arayüz.

Health Analyzer’ın varsayılan olarak kontrol ettiği yüzlerce temel kural var ve hatta daha fazlasını siz de yazabilir veya yazılmış bir çözüm dosyasını sisteme yükleyerek bu kuralların da kontrol edilmesini sağlayabilirsiniz.

Health Analyzer aslında her bir rule farklı zamanlamalara sahip olacak şekilde SharePoint Timer prosesinde çalışan bir yapı. Dolayısıyla bir job aracılığı ile tetikleniyor ve kurala uygun olan kurallar işletilerek sonucu tehlikeli, uyarı ve bilgi gibi kategorilerde karşımıza çıkıyor. Özellikle yeni kurulum sonrası ortam yapılandırmalarında bazen bu kuralların kendi zamanlamasını beklemeden tetiklenmesini isteyebilirsiniz. Bunun için aşağıdaki gibi bir PowerShell komutu işinizi görecektir.

# Microsoft.SharePoint.PowerShell 'in yüklendiğinden emin oluyoruz. Doğrudan Microsoft SharePoint PowerShell console ile çalıştırabilirsinizde.

$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}
if ($snapin -eq $null) {
  Write-Host "Loading SharePoint Powershell Snapin"
  Add-PSSnapin "Microsoft.SharePoint.Powershell"
}

Get-SPTimerJob | Where {$_.Name -like "*Health*" -and $_.Name -like "*-all-*"} | Start-SPTimerJob

1

2

3

4

5

6

7

8

9

# Microsoft.SharePoint.PowerShell 'in yüklendiğinden emin oluyoruz. Doğrudan Microsoft SharePoint PowerShell console ile çalıştırabilirsinizde.

$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}

if ($snapin -eq $null) {

Write-Host "Loading SharePoint Powershell Snapin"

Add-PSSnapin "Microsoft.SharePoint.Powershell"

}

Get-SPTimerJob | Where {$_.Name -like "*Health*" -and $_.Name -like "*-all-*"} | Start-SPTimerJob

PowerShell console’u “Run as Administrator” modda çalıştırmayı unutmamak gerekiyor elbette. Neticede yapılan işlem yönetici rolünün yetkili olduğu bir başlık.

DLL’i PowerShell Yardımıyla GAC’a Eklemek

03.12.2018 1 Yorum

Uygulamanıza ait DLL dosyasını GAC (Global Assembly Cache) ‘e yüklemek için pek çok yöntem bulunuyor. Bunlardan en kolayı şüphesiz GACUtil.exe. Ancak GACUtil Visual Studio kurulumunun bir parçası olarak karşımıza çıkıyor ve şüphesiz çoğumuzun özellikle canlı ortamda sunucu üzerine Visual Studio kurmak gibi bir şansımız yok. Bu nedenle artık Windows’un ayrılmaz parçası haline gelen PowerShell‘i kullanmak burada en iyi alternatif görünüyor.

[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")            
$publish = New-Object System.EnterpriseServices.Internal.Publish
           
$publish.GacInstall("C:\FakePath\DLLDosyasi.dll")

1

2

3

4

[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")

$publish = New-Object System.EnterpriseServices.Internal.Publish

$publish.GacInstall("C:\FakePath\DLLDosyasi.dll")

Burada önemli olan nokta;

PowerShell console’u “Run as Administrator” modda açın.
İşlem sonrasında eğer bahsi geçen IIS üzerinde host edilen bir uygulama ise iisreset komutunu da çalıştırmayı unutmayın.

Hata: Maximum allowed Correlation Filter have been reached or exceeded

09.11.2018 Yorum yapılmamış

Geliştirmesini yaptığınız workflowlarda yoğun kullanımlar sonrası aşağıdaki gibi bir hata ile karşılaşabilirsiniz.

Exception command text: [dbo].[PerformBatchOperations], exception = Microsoft.ServiceBus.Messaging.QuotaExceededException: The number of maximum allowed CorrelationFilter have been reached or exceeded. Number of filters:100001, Max number of filters allowed: 100000.

Hatadan da anlaşılacağı üzere bu bir sorundan ziyade bir limitlemeye takıldığınız anlamını içerir. Sorunun çözümü için aşağıdaki adımları uygulamanız yeterli olacaktır.

Service Bus Farm’ı stop edin. Bu işlem için “Stop-SBFarm” PowerShell komutunu kullanabilirsiniz.
Limiti yükseltin. Bu işlem için “Set-SBRuntimeSetting -Name MaximumNumberOfCorrelationFiltersPerTopic -Value 1000000” PowerShell komutunu kullanabilirsiniz.
Veritabanı yöneticinizi açın ve SBMessageContainer01 veritabanında bir sorgu çalıştırın “UPDATE TopicsTable SET MaxCorrelationFilters = 1000000“
Service Bu Farm’ı yeniden başlatın. Bu işlem için “Start-SBFarm” PowerShell komutunu kullanabilirsiniz.

PowerShell komutları için hem Service Bus PowerShell ekranını hem de Workflow Manager PowerShell ekranını kullanabilirsiniz.

SharePoint Saturday İstanbul 2018

30.07.2018 Yorum yapılmamış

Hata: Failed to update database “DBNAME” because the database is read-only

25.05.2018 Yorum yapılmamış

Kodladığınız uygulamanız içerisinde, bir batch işlemi çalıştırırken veya bir SSIS paketini çalıştırdığınızda, yani veritabanı üzerinde yazma işlemi yapmak istediğiniz herhangi bir zamanda bu hata ile karşılaşabilirsiniz.

“Failed to update database “DBNAME” because the database is read-only”

Yaptığınız kontrollerde database’in read-only modda olmadığını gözlemlemiş olabilirsiniz. Bunun için pek çoğunuzun bildiği üzere management studio üzerinden ilgili veritabanı ismi üzerinde sağ tıklamanız ve özellikler ekranında “Options” bölümüne gelmeniz ve en alta inmeniz yeterli. Burada “Read-Only” özelliğinin “False” olmasını bekliyoruz. “True” ise zaten hatanın sebebi açıkça ortadadır. Değeri değiştirmeniz yeterli olacaktır.

Biz bu bölümün “False” olmasına rağmen hatayı aldığımızı varsayalım. Bu durumda yapmanız gereken kontroller için aşağıdaki kod bloğunu kullanabilirsiniz. “AdventureWorks” örnek olarak kullanılmıştır. Bu bölümde kendi veritabanı isminizi verebilirsiniz.

SELECT DATABASEPROPERTYEX('AdventureWorks', 'Updateability');
GO

ALTER DATABASE AdventureWorks SET READ_ONLY;

SELECT DATABASEPROPERTYEX('AdventureWorks', 'Updateability');
GO

ALTER DATABASE AdventureWorks SET READ_WRITE;

SELECT DATABASEPROPERTYEX('AdventureWorks', 'Updateability');

1

2

3

4

5

6

7

8

9

10

11

SELECT DATABASEPROPERTYEX('AdventureWorks', 'Updateability');

GO

ALTER DATABASE AdventureWorks SET READ_ONLY;

SELECT DATABASEPROPERTYEX('AdventureWorks', 'Updateability');

GO

ALTER DATABASE AdventureWorks SET READ_WRITE;

SELECT DATABASEPROPERTYEX('AdventureWorks', 'Updateability');

Son olarak SQL Server Express versiyonunu kullananlar için bir ek hatırlatma. Burada AttachDbFileName kullanıyorsanız SQL Server servis hesabınızın Connection String’de belirttiğiniz dosya yoluna erişim ve yazma için izni olduğundan da emin olmalısınız.

Hata: SSIS Access Denied

25.05.2018 Yorum yapılmamış

SQL Server Integration Services kurulumunu yapmanızın ardından kurulum aşamasında servis hesabı olarak verdiğiniz kullanıcı ile bile SSIS instance’ına bağlantı kurarken aşağıdaki şekilde yetki hatası alabilirsiniz.

“Connecting to the Integration Service on the computer ”[SERVERNAME]’ failed with the following error. Access is denied”

Esas olarak SQL Server Integration Services kurulumlarında varsayılan olarak server administrator grubu yetki sahibidir ancak bazen bu kullanıcı ile bile yetki hatası alabilir ve SSIS instance’ına bağlantı sağlayamayabilirsiniz. Bu durumda aşağıdaki adımları takip etmek işinize yarayacaktır. (SQL Server 2014 ve SQL Server 2016 için test edilmiştir)

Component Services ekranını açın. Bunun için Start > Run kısmına “dcomcnfg” yazarak ilerleyebilirsiniz.
Sol bölümdeki panelden Computers > My Computer > DCOM Config bölümüne kadar gelin.
Burada “Microsoft SQL Server Integration Services 12.0” (Bu SQL Server 2014 için, SQL Server 2016’da versiyon numarası 13.0 olacaktır)
Üzerinde sağ tıklayarak “Properties” > “Security” tabına gelin ve ekrandaki bölümlere istediğiniz yetki seviyelerine göre kullanıcınızı veya grubunuzu ekleyin.
İşlemden sonra SQL Server Integration Services servisini yeniden başlatın.

Bazen buna rapmen yetkilendirmede sorun yaşıyor olabilirsiniz. Bu durumda ek bir adım olarak aşağıdakini de uygulayabilirsiniz.

Server Manager > Computer Management > Local Users and Groups > Groups kısmında “Distributed COM Users” grubunu bulun ve kullanıcınızı buraya ekleyin.

WSS_UsageApplication Veritabanı İsminin Değiştirilmesi

27.03.2018 Yorum yapılmamış

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.

SQL Server Sunucusunu Sonradan Domaine Almak

Hata: Web Application Oluştururken Sayfa Görüntülenemiyor Mesajı

PowerShell Kullanarak Tüm SharePoint Health Analyzer Kurallarını Çalıştırmak

DLL’i PowerShell Yardımıyla GAC’a Eklemek

Hata: Maximum allowed Correlation Filter have been reached or exceeded

SharePoint Saturday İstanbul 2018

Hata: Failed to update database “DBNAME” because the database is read-only

Hata: SSIS Access Denied

WSS_UsageApplication Veritabanı İsminin Değiştirilmesi

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

Son Yazılar

Kategoriler