Central Administration Port Değişikliği

SharePoint kurulumlarınız esnasında Central Administration arayüzünün port bilgisi otomatik olarak atanır ve Configuration Wizard’ı ilk çalıştırdığınızda bu portu değiştirmenize imkan verilir. Ancak çeşitli nedenlerle port bilgisini daha sonra değiştirmek zorunda kalabilirsiniz;

  • Kurulum esnasında bu adımı gözden kaçırmış ve bahsettiğim random port atamasına maruz kalmış olabilirsiniz.
  • Şirketiniz bilgi sistemleri politikalarıyla uyumlu olmayan bir port numarası belirlemiş olabilirsiniz.
  • Farklı bir uygulama ile çakışan bir port belirlemiş veya geçen zaman içinde çakışacak bir uygulamayı yüklemek zorunda kalmış olabilirsiniz.

Bu işlemi basit yolla halletmek için SharePoint 2010, SharePoint 2013 ve SharePoint 2016’da bir PowerShell komutu işinizi görecektir.

Bu işlem ile 1023 ile 32767 arasında SSL için kullanılmakta olan 443 haricindeki portlardan bir tanesini belirleyebilirsiniz. Eğer izin verilmeyen kriterde bir port numarası belirleyecek olursanız “Invalid Port” uyarı mesajını alacaksınız.

Eğer halen SharePoint 2007 ile çalışıyorsanız bu işlemi gerçekleştirmek için stsadm komutunu kullanmalısınız.

İşlemi tamamladığınızda IIS Binding ve diğer adreslemelerin tamamı yeni port numarasına göre düzenlenecek ve artık yeni port numarası ile uygulamanıza erişebileceksiniz. Eğer Central Administration’a hiç ulaşamıyor, port bilgisini de bulamıyorsanız bu durumda aşağıdaki komut kullanılmakta olan port bilgisini göstermek için yeterli olacaktır.

 

Yeni Farm Admin Hesabının Eklenmesi

Test ve canlı ortamlar için olmasa da özellikle geliştirme ortamlarında yeni katılan geliştiriciler için uygulama geliştirmeyi mümkün kılmak adına bazı yetkilendirmeler yapmanız gerekir. Kısaca sıralayacak olursak;

  • Kullanıcının Central Administration > Security tabı altında yer alan menü aracılığı ile “Farm Administrators” SharePoint grubuna eklenmesi.
  • Central Administration içerik veritabanında kullanıcıya yetki verilmesi.
  • Uygulama içerik veritabanında kullanıcıya yetki verilmesi.

Bu işlemleri tek bir kullanıcı için yapmak sorun olmasa da ekip için yapmak veya sürekli eklenen yeni geliştiriciler için tekrar tekrar yapmak sıkıcı olabilir. Bu noktada aşağıdaki gibi bir PowerShell fonksiyonu ile bu işi otomatik hale getirebilirsiniz.

Fonksiyonu kullanmak için ise;

 

Feature Pack vs Service Pack

SharePoint ile uzun zamandır çalışanların farkında oldukları bir konu her geçen gün ürüne ilişkin güncelleme paketlerinin çıkışındaki sürenin kısalması olacaktır.

SharePoint 2003 ve 2007 döneminde belli aralıklarla çıkan (2003 için belirsiz, 2007 için genellikle 2 ayda bir) -düzenli- güncelleme paketlerine ek olarak aşağı yukarı yılda veya bir buçuk yılda bir çıkan Service Pack’ler vardı.

SharePoint 2013 için 2014 yılının sonuna kadar düzenli olmayan aralıklarla devam eden güncelleme paketleri Ocak 2015 itibariyle Microsoft’un da duyurusu ile artık aylık olarak düzenli yayınlanmaya başlandı. Şüphesiz bundaki en büyük nedenlerden bir tanesi özellikle hybrid çalışma prensibinde ilerlemeyi hedefleyen kullanıcı kitlesinin SharePoint Online ile on-premise olarak adlandırdığımız yerel SharePoint kurulumları arasında özellik ve fix bakımından oluşan farklılığın azaltılabilmesine imkan tanınmasıydı.

SharePoint 2016’da da Microsoft SharePoint 2013 için 2015 yılı başında başlattığı düzende, her ay bir güncelleme paketi çıkartarak ilerlemeye devam etti. Hybrid çalışma prensibinde ilerlemeyen kullanıcılar için SharePoint güncelleme sıklığı genellikle yeni kurulan bir ortamın en güncel versiyon ile kurulması ve bir problem ile karşılaşıldığında veya üzerinde çalışılan sistem için sistem birimlerinin belirlediği güncelleme periyodlarında güncel paketlerin geçilmesi şeklindeydi. Her ay çıkan güncellemelerin düzenli yüklenememesi konusunu çok yadırgamıyorum açıkçası. Neticede ortalama 5 sunucudan oluşan orta seviyede bir farm için önce test, sonra canlı ortam periyodunda ilerlendiğini düşünecek olursak ciddi bir zaman ve fonksiyonalite kaybına neden oluyor güncelleme paketleri. Bu nedenle her güncelleme paketi muhakkak değerlendirilip takip edilmesi ve içeriğinde barındırdığı düzeltilen özellikler yakından değerlendirilmeli ve buna göre planlama yapılmalı düşüncesindeyim.

Buradan yola çıkarak geçtiğimiz günlerde yayınlanan Feature Pack 2 sonrası aldığım sorulara istinaden Feature Pack ve Service Pack arasındaki farklılıklara değinmek istiyorum. İlk Feature Pack olan ve Kasım 2016’da çıkan Feature Pack 1 sanırım henüz pek fazla kişinin SharePoint 2016 geçişi yapmadığı döneme denk geldiğinden atlanmıştı. Feature Pack 2 sonrası Feature Pack 1 aramalarının artmış olabileceğini elimde bir istatistik olmasa da tahmin edebiliyorum.

Peki nedir Service Pack, nedir Feature Pack?

Service Pack: Hotfix, security update, critical update ve genel anlamdaki güncellemelerin paketlendiği, test edildiği ve aylık olarak yaygınlaştırıldığı paketlerdir. Service Pack’lerde üreticinin esas odaklandığı konu ürünün stabil kalması, performans ve güvenlik gibi başlıklarda yaşanan sorunların çözümlenmesidir.

Feature Pack: Ağırlıklı olarak ürüne yeni özellikler kazandırmanın ön planda olduğu, müşterilerden alınan geri bildirimler ve ürünün yol haritasında belirlenmiş olan başlıklardaki yeni özelliklerin ürüne kazandırılmasını hedefler.

Feature Pack 1 ile hayatımıza aşağıdaki başlıklar eklenmişti, daha detaylı bilgi için KB makalesinin bağlantısına buradan ulaşabilirsiniz.

  • Administrative Actions Logging
  • MinRole enhancements
  • SharePoint Custom Tiles
  • Hybrid Auditing (preview)
  • Hybrid Taxonomy (preview)
  • OneDrive API for SharePoint on-premises
  • OneDrive for Business modern experience (available to Software Assurance customers)

Feature Pack 2’nin ise (12 Eylül 2017’de yayınlandı) eklediği ana özellikler aşağıdaki şekilde. Daha detaylı bilgi için KB makalesinin bağlantısına buradan ulaşabilirsiniz.

  • SharePoint Framework (SPFx)

SPFx’den daha detaylıca ayrı birkaç yazıda bahsetmek daha doğru olacaktır. 🙂

Yeni Farm (PowerShell)

SharePoint kurulumlarında aslında sihirbaz size son derece yardımcıdır. Aşağıdaki 3 adım ile herhangi bir kod bloğu çalıştırmadan da farm oluşturmak mümkün.

  • Install Farm Pre-Requisites
  • Install SharePoint
  • Run SharePoint Configuration Wizard

Bunun dışında, tercihi herşeyi scriptler ile oluşturmak olanlar için AutoSPInstaller gibi araç setleri de yaratılmış ve kullanıma sunulmuştur. Ancak bu gibi araçların da bazı konfigürasyonlar isteyeceği net. Bu nedenle tam da ortada bir yerde olabilirsiniz. Yani kurulum ile ilgili temel adımları size sunulan görsel arayüzlü kurulum araçlarıyla yapmak, ama sonraki konfigürasyonlar ve servis uygulaması işlemlerinde PowerShell’den yardım almak.

Bu sürecin size bir diğer katkısı da sistem veritabanları da dahil isimlendirmelerine müdehale edebilmek olacaktır. Çünkü varsayılan sihirbazların kullanıldığı ilk yöntemde her ne kadar SharePoint_Config database ismine müdehale edebilseniz de Central Administration yönetim konsolu uygulamasının veritabanı ismine müdehale edemezsiniz. Yukarıda bahsettiğim AutoSPInstaller bu sorunu çözmek ve hatta daha fazlasını yapmak ile beraber bazı kullanıcılar için konfigürasyonu zaman alıcı olarak yorumlanabiliyor.

Aşağıda örnek olarak paylaştığım script ile yukarıdaki ilk iki adımı SharePoint kurulum medyası üzerinden görsel arayüzde yaptıktan sonra farmın oluşturulması işlemini yapabilirsiniz.

 

Tüm Arama İndexleme İşlemlerinin Durdurulması

SharePoint arama hizmeti genel anlamda son derece başarılı çalışan, özellikle içerik indexlemenin yanında bu işlemi yaparken güvenlik ilişkilerini de doğru sağlaması nedeniyle yoğun ilgi gören servislerden bir tanesi. Zaman zaman kurguladığınız arama hizmetinde problemler çıkabiliyor. Hatta öyle ki arama servisinin yönetimi için kullanmanız gereken sayfaya bile erişmeniz mümkün olmayabiliyor. Dolayısıyla buradaki kurguyu kontrol etmek, gerekiyorsa devam eden işlemleri sonlandırmak gibi çalışmalarınızda scriptlere yönelmeniz gerekebiliyor.

İçerik ve yayınlanan site sayısının büyük olduğu ortamlarda arama hizmetini farklı içerik kaynakları tarafından ve farklı zamanlarda indexleme yapacak şekilde kurgulamaya çalışırız. Burada, sunucu tarafındaki kaynak kullanımı, gün içerisinde bir operasyon olmaması gibi nedenlerle saat aralıklarını doğru ayarlamak gerekir. Bu da bizi genellikle akşamları çalışan tam indexleme işlemleri yapmaya iter. Bu durumda indexleme görevlerinin çakışması kaçınılmaz bir hal alabilir. Bazen içerikteki veya servisteki bir sorun sebebiyle de normalde çok daha kısa sürede tamamlanabilecek bir indexleme işlemi uzayabilir ve diğer zamanlanmış görev ile çakışabilir. Bu gibi durumlarda servis tarafındaki yönetim paneline erişebilmek de problem olduysa devam eden indexleme işlemlerini script aracılığı ile durdurmanız gerekebilir.

Aşağıda ilgili SharePoint yaygınlaştırmanızda bulunan arama hizmetindeki tüm içerik kaynaklarında yürüyen indexleme işlemlerini durdurmanıza yardımcı olacak bir script örneği bulabilirsiniz.

Bu işlemi tüm içerik kaynakları için değil de sadece tek bir tanesi için yapmak istiyor da olabilirsiniz. Bu durumda aşağıdaki örneği kullanmanız yeterli olacaktır.

 

Run All Health Analizer Rules

SharePoint 2010’dan bu yana Central Administration aracı ana sayfasında üst bölümde bulunan bir alan aracılığı ile bizlere ortamın sağlık durumu hakkındaki bulgularını gösterir. Bu bölüm, ciddi bir kural ihlali yaşandığında kırmızı, daha az önemli bir kural ihlali yaşandığında ise sarı arka plan rengindedir. Ve tıkladığınızda ilk çalışması biraz yavaş olacak şekilde mevcut yaygınlaştırmanızda bulunan, önceden ayarlanmış kural tanımlarına göre problemli olan bölümleri listeler. Zaman zaman bazı hatalarınızı nasıl düzeltebileceğiniz ile ilgili yol gösterici hata kodları, makale linklerini paylaşmak ile beraber bazı hata kodlarını ise otomatik fix özelliği sayesinde kendisi düzeltebilir.

Söz konusu sağlık durumu kontrollerinde tanımlı kuralların her birinin farklı çalışma aralıkları vardır. Bazı kurallar saatte bir kontrol edilirken bazı kurallar haftalık bazda kontrol edilebilir. Bu durumda özellikle ilk yaygınlaştırma sonrası düzelttiğiniz sorunların SharePoint açısından da düzelip düzelmediğini görmek açısından sorun olan kaydın üst bölümünde yer alan şeritte yer alan “Run Now” butonunu tıklamanız yeterlidir.

Buradaki sorunların fazla olduğu veya her defasında “ne kaldı?” sorusuyla uğraşmak istemeyenler için ise aşağıda tüm Health Analizer rulelarını kontrol eden jobları tetikleyen bir PowerShell scriptini bulabilirsiniz.

 

SPS İstanbul

SPS İstanbul

Biraz dikkatsizlik, biraz şansızlık.. Oldukça uzun süreden beri farklı dönemlerde aktif hale getirdiğim, kimi zaman daha kişisel, kimi zaman daha teknik başlıklara yer verdiğim kişisel sitemi eski verileri aktarmadan yeniden hayata geçirmek durumunda bıraktı beni.

Bu konuda başlangıcı da uzun dönemdir yurt dışında pek çok şehirde düzenlenen ve global bir sosyal ortam haline gelen SharePoint Saturday (SPS) etkinliğinin Türkiye’deki ilk oturumu olacak SPS İstanbul’un duyurusunu paylaşarak yapmak isterim. 7 Ekim 2017‘de Microsoft Türkiye ofisinde gerçekleştirilecek olan etkinlikte benim de konuşmacı olarak yer almam noktasında nezaket gösteren Hasan Köroğlu‘na teşekkür ederim.

Etkinlik hakkında detaylı bilgiye web sitesi olan http://spsistanbul.com adresinden ulaşabilirsiniz.

Görüşmek dileğiyle