sharepoint Arşiv

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

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.

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.

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

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.

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

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.

PowerShell Yardımıyla Dosya İndirmek

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.

 

SharePoint 2013, .Net Framework 4.6

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

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.

SharePoint Migration Tool from Microsoft

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.

 

 

Microsoft Flow – Hatırlatma Uygulaması

Microsoft Flow ile ilgili daha önceki kısa yazılarımda Flow’un ne olduğundan, şablon kullanarak nasıl akış geliştirebileceğimizden ve boş bir akış ile farklı türdeki eylemleri nasıl kullanabileceğimizden bahsetmeye çalışmıştım. Şimdi bir gerçek hayat uygulaması hazırlamaya çalışalım istiyorum.

Pek çok müşterimizde SharePoint üzerinde tuttukları dokümanlar veya liste öğeleri üzerinden hatırlatma uygulaması ihtiyacı oluyor. Örneğin bir kütüphanede sözleşmelerinizi tutuyorsunuz. Meta veri olarak sözleşmenin başlangıç tarihi ve bitiş tarihi elinizde veri olarak var. Bu durumda bir sözleşme hatırlatma uygulaması çok işe yarardı sanırım. Örneğin sözleşmenin bitmesine 30 gün kala yenileme çalışmalarını yapabilmeniz için size e-posta gelseydi. Veya çalışanlarınıza ait özel sağlık sigortalarını bir listede tutuyorsanız ve her özel sağlık sigortasının yenileme tarihi farklıysa günlük kontrolleri sizin yerinize bir sürecin yapması ve ilgili kişilere yenileme çalışması için hatırlatma bilgisi verseydi eminim işiniz bir hayli kolaylaşırdı. Bu konudaki senaryo örneklerini artırmak mümkün. Bu nedenle burada örneklemeye çalışacağım senaryo şu şekilde olacak.

“Sigortalar isimli bir listemiz var. İçeriğinde personelin adı, sigortanın türü ve sigortanın yenileme tarihi bilgisini tutuyoruz. İlgili poliçenin yenilenmesine 7 gün kala bir hatırlatma e-postası almak istiyoruz.”

Söz konusu örnek için SharePoint listemiz aşağıdaki görünümde olacak.

 

Microsoft Flow – Boş Akış Oluşturma

Daha önceki kısa yazılarımda Microsoft Flow’un ne olduğundan ve hazır bir şablonu kullanarak hızlıca ihtiyaca yönelik bir otomasyon kurmaktan bahsetmiştim. Bu yazılara ayrıca aşağıdaki bağlantılardan da erişebilirsiniz.

Şimdi ise boş akış şablonunu kullanarak yeni bir senaryonun denemesini yapmaya çalışalım. Senaryomuz şu olacak;

“OneDrive’ımız içerisindeki spesifik bir klasöre, dosya adı içerisinde belirttiğimiz metin geçen dosyalar için bir akış oluşturmak. Eğer belirttiğimiz metin geçiyorsa buna göre konu barındıran bir e-posta, geçmiyorsa farklı bir konu ve içerikte başka bir e-posta almak. Ve son olarak her iki koşulda da bu dosyanın SharePoint içerisinde belirteceğimiz bir kütüphaneye kayıt olmasını sağlamak”

Bunun için öncelikle https://flow.microsoft.com adresine kullanım yetkisi olan bir hesap ile giriş yapmamız gerekiyor elbette. Ardından üst bölümde yer alan bağlantı aracılığı ile “Boş akış oluştur” komutunu veriyoruz.

Microsoft Flow – Şablondan Akış Oluşturma

Microsoft Flow ile temel hedef kitle etkin kullanıcı (power user) olarak nitelendirdiğimiz, bilgisayar ve temel Microsoft Office kullanım yetkinliğine sahip kişiler. Bu nedenle Flow içerisinde kod yazmaya olan ihtiyaç en aza indirgenmiş durumda. Tabi bazı alanlarda filtreleme gibi işlemleri yerine getirmek için bir miktar teknik kişi desteğine ihtiyaç olacaktır. Çünkü bu bölümlerde OData filtreleri, vb yapılar kullanılıyor.

Bu kısa yazıda mevcut şablonlar üzerinden iki servisi birbirine bağlayarak bir süreci otomatikleştirmeye çalışacağız. Temel senaryomuz şu şekilde;

“Twitter’da belli bir hashtag kullanılarak atılmış tweetleri bir SharePoint listesinde toplamak”

Microsoft Flow’un 300’den fazla şablon barındırdığından bahsetmiştik. Bu şimdilik etiketiyle vermemiz gereken bir rakam çünkü her geçen gün hem paylaşım yapan insanların hem de Microsoft’un yeni servisleri veya senaryoları barındıran şablonları buraya eklemekte olduğu bilgisini paylaşmakta yarar var.

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. 🙂