SCCM 1810 ile update dağıtımı yaparken alınan “Failed to Add Update Source for WUAgent of type (2) and id ({4B030855-468F-4C01-9969-6E86F6D36755}). Error = 0x87d00692.” Hatasının çözümü.

Merhaba,  SCCM ürünü ile merkezi update dağıtımı  yaparken alacağınız hatalara sık sık değiniyor ve çözüm yollarını paylaşıyorum. Bir istemcinizin   C:\windows\CCM\logs  dizini altındaki  “wuahandler.log” dosyasını kontrol ettiğiniz de  aşağıdaki hatayla karşılaşıyorsanız yapmanız gereken kontrolleri ve sorunun çözümünü aktarıyorum.

Öncelikle, neden  merkezi update dağıtımı yaptığımız sistemlerde Client veya Sunucu sistemler üzerinde bu loğların kontrollerini yaparız, buna ne zaman ihtiyaç duyarız.  Hatırlarsanız aşağıda linkini paylaşacağım yazım da sıkça raporlarla çalışmanın önemini vurgulamış ve istediğimiz veriyi doğru şekilde getirmesinin bize sunduğu faydaları örneklerle anlatmıştım.

SCCM ile Sunucu Update Süreçlerinin Yönetimi ve Raporlanması.

Örneğin, Windows 10 Versiyon 1803 sistemleriniz var ve update gereksinimleri nedir  üstteki bağlantısını paylaştığım makaleyi okuyarak bu gereksinimleri nasıl öğreneceğinizi görebilirsiniz. Fakat yolunda gitmeyen bir şeyler var. Aşağıdaki ekran görüntüsünde göreceğiniz üzere “4100347” KB idli update paketine hangi sistemlerin ihtiyacı olduğunu ve hangi sistemlerde yüklü olduğunu aşağıdaki rapor üzerinden görebiliyorum. Fakat “detection state unknown”  ibaresi nedir ?  sorgulamasını yaptığınız update paketinin yüklü olup olmadığı veya gereksinim durumu hakkında bilgi toplayamadığı istemciler diyebiliriz.  Zaten o sekmeyi tıkladığımızda bizi bir istemci listesi karşılayacaktır.

Dilerseniz listeyi excele export edip istemcilerinizin makine ismi log on olmuş kullanıcı ismi üzerinde yüklü olan SCCM ajan versiyon bilgisi ve en son ne zaman scan cycle çalışmış tarih bilgisini öğrenebilirsiniz. Ben listede olan bir istemcime bağlandığımda ve “wuahandler.log” dosyasını kontrol ettiğimde aşağıda ekran görüntüsünü paylaştığım hatayı fark ettim.

“Failed to Add Update Source for WUAgent of type (2) and id ({4B030855-468F-4C01-9969-6E86F6D36755}). Error = 0x87d00692.”   Hatasının nedeni bu hatayı üreten istemcinizin  local group policy veya Domain de uygulamış olduğunuz  WSUS group policy’ler nedeni ile SCCM üzerinde servis olarak tanımlı olan WSUS server ile iletişime geçememesi.

Bunu nasıl kontrol ederiz,  bu hatayı aldığınız istemci üzerinde  CMD > rsop.msc  komutunu çalıştırdığınızda aşağıdaki alana kadar gelirseniz orada tanımlı olan WSUS server ayarını görebilirsiniz.

Specify intranet Microsoft update Service location alanında tanımlı olan adresin  SCCM SUP server olan sunucunuz olması gerekiyor.   SCCM ile update dağıtımı yapacağınız sistemler üzerinde bu ayarı policy ile dağıtmanıza gerek bulunmuyor.  Çünkü otomatik olaran SCCM agentlar aracılığıyla bu ayar SCCM Clientlarınıza kaydedilyor. Ama örneğimizde olduğu gibi önceden tanımlı adres varsa o adresi aldığı  GPO ‘yu devre dışı bırakmanız gerekiyor.

İlgili ayarı değiştirdikten sonra  scan cycle tetiklemeniz ve yaklaşık 10 dakika beklemeniz yeterlidir. Daha sonra wuahandler.log dosyasını kontrol ettiğinizde sonuç aşağıdaki gibi olacaktır.

SCCM ile merkezi update dağıtımında alınan “ScanAgent.log dosyasındaki – “Sources are not current.” Hatasının çözümü.

Merhaba, SCCM 1702 ve sonraki sürümler ile Client ve Server sistemlere merkezi Windows  update dağıtımı yapıyorsanız  bazı durumlar da Client veya Server sistemlerinizin dağıttığınız updateleri sağlıklı alıp almadığını veya “Update scan” süreçlerinin sağlıklı olup olmadığını kontrol etmeniz gereklidir.

Yaptığım bir proje de karşılaştığım bir hata ve çözümünü paylaşıyorum.

Hata: Client sistem SCCM SUP Rolü ile iletişime geçerek  software update scan cycle  işlemini yapmıyordu.  Client sistem üzerinde  C:\Windows\CCM\logs\ dizinine gelerek kontrol ettiğim  WUAHANDLER.log dosyasının durumu aşağıdaki gibiydi.

Bu log dosyasından istediğim açıklayıcı veriyi alamadığım için kontrol ettiğim 2.log dosyası  ScanAgent.log dosyası idi. Bu log dosyasındaki hata aşağıdaki gibidir.

İlgili hatanın çözümünü aşağıdaki şekilde buldum.

\Administration\Overview\Hierarchy Configuration\Boundary Groups alanına gelerek Default Boundary Groups özelliklerine giriyoruz. >  References  sekmesine SCCM SUP rolü yüklü olan SCCM site serverımızı veya serverlarımızı ekliyoruz. Ardından client policyleri manuel tetikleyebiliriz veya bir süre sonra  Client ve Server sistemler  update Scan sürecini tetikledikten sonra scanagent.log dosyasından süreci takip edebiliriz.

Aynı sistemin ScanAgent.log dosyasına yukarıdaki işlemleri yaptıktan yaklaşık 10 dakika sonra tekrar baktığımızda sorunun çözüldüğünü aşağıdaki şekilde görebiliriz.

SCCM ile Update dağıtımı esnasında Client sistemlerin log dosyasına düşen “Failed to run BeginSearch() on WUAgent. Error = 0x80080005.” Hatasının çözümü.

Merhaba,  SCCM ürünü ile merkezi update dağıtımı gerçekleştiriyorsanız, bazı durumlar da bazı client veya update dağıtımını yaptığınız server sistemlerin  gönderdiğiniz updateleri düzenli almadığını veya update kontrolünü yapmadığını fark edebilirsiniz. Bu durumda öncelikli client sistem üzerinde kontrol etmeniz gereken bazı log’lar mevcut. Update dağıtımı esnasında sorun yaşadığınız Client sistem üzerinde aşağıdaki path’e erişerek ilgili log dosyasını kontrol ederek işlemlere başlayabiliriz.

Sorun yaşayan Client veya Server sistem de C\Windows\CCM\Logs dizininde kontrol etmeniz gereken ilk log dosyası  WUAHandler.log dosyasıdır. Bu dosyayı cmtrace toolu ile açtığınız da update gönderimi yapmak istediğiniz istemciniz ile SUP server arasında olan trafik ve içeriği mevcuttur.

Bizim sorun yaşadığımız Client sistemimizin  log dosyasında aşağıdaki gibi bir failed uyarısı var.

Hatanın kaynağı bu sorunu yaşadığınız client veya Server sistemin local servislerindeki Windows update Servisinin çalışmıyor veya stop durumda olması.

İlgili servisi started duruma alıp  software Scan sürecini tekrar tetiklemeniz yeterlidir.

Exchange 2013 / 2016 Üzerinde Bir kullanıcının mail gönderebileceği kişi sayısını belirleme.

Merhaba,  bazı durumlarda belirli bir kullanıcının mail göndereceği kişi sayısını sınırlamak isteriz. Örneğin bir departman yöneticisinden ekibindeki 1 personelin maksimum mail göndereceği kişi sayısının azaltılması yönünde bir talep alabilirsiniz. İşlemlere geçmeden önce organizasyon bazında maksimum mail gönderebileceğimiz kişi sayısını görüntülemek için Exchange Management Shell üzerinde aşağıdaki komutu çalıştırabiliriz.

Get-TransportConfig | fl MaxRecipientEnvelopeLimit

Örneğimize konu kullanıcının mevcut kullandığı mail gönderebileceği kişi limitini görmek isterseniz aşağıdaki komut işinize yarayacaktır.

Get-Mailbox -Identity “ozgur.senerdogan” | fl RecipientLimits

Şimdi işlemimize başlayabiliriz,  ECP (exchange Admin  Center ) açalım  ve Recipients alanından ilgili kullanıcıyı bulalım.  Kullanıcı seçili durumda iken Kalem ikonuna tıklayarak veya kullanıcı mailbox’ı üzerinde çift tıklayarak kullanıcı mailbox özelliklerine giriş yapalım.

Mailbox Features tabında  Mail Flow > View Details seçimini yapalım.

Default olarak   Recipient limit seçimi kapalıdır. Biz aktif hale getirip belirlediğimiz sayıyı girebiliriz.

Sayıyı 2 olarak belirledik. Şimdi Exchange Management Shell üzerinden bu sayıyı tekrar kontrol edelim.

İşlemimizi son olarak test edelim. 3 mail adresime mail atıyorum bu hesabımla sonuç aşağıdaki gibi.

İşlemimiz başarılı.

Yaptığımız işlem ile bir kullanıcının sadece belirlediğimiz sayıdaki alıcıya mail atmasını sağladık. Bunu organizasyon bazında yapmak isterseniz yine Exchange Management Shell üzerinde aşağıdaki komutu çalıştırabilirsiniz. Örneğimize sayıyı 100 e çekeceğiz.

Set-TransportConfig -MaxRecipientEnvelopeLimit 100

SCCM ile Sunucu Update Süreçlerinin Yönetimi ve Raporlanması.

Merhaba,  bilindiği ve kabul gördüğü üzere Microsoft System Center ürün ailesinin içinde %40 gibi önem payına ve kullanım oranına  sahip  ürün SCCM ürünüdür diyebiliriz. Peki SCCM ürününün içinde en yaygın kullanılan rollerden  biri nedir dersek şüphesiz Update Management  özelliği aklımıza gelir.

Bu yazıyı yazmaya başlamadan önce mevcutta yayınlanmış olan  Türkçe SCCM ile update yönetimi başlıklı kaynakları incelediğimde  sıfırdan SUP rolünün kurulumu konfigürasyonu ve ilk update dağıtımlarına değinilmiş olduğunu görüyorum.  Veya ADR dediğimiz Automatic Deployment Rule özelliği ile otomatik hale getirilmiş update dağıtımlarından söz edilmiş.  ADR ile yapılan dağıtımlar Client sistemler üzerinde tercih edilse de Sunucular da ne yazık ki ADR dediğimiz otomatik hale getirilmiş Windows update dağıtımları tercih edilmemekte.  Manuel yüklemeler tercih edilmekte. Durum böyle olunca hangi sunucularımızın update gereksinimi var hangi sunucularımızda belirli KB’ye sahip updateler yüklü bunları öğrenebiliyor olmamız gerekli. İşlemlere başlamadan önce önceki yazılarımda da vurguladığım gibi SCCM ile detaylı raporlar almak vs istiyorsak Reporting Services Point rolünün SCCM sunucumuzda veya SQL sunucumuz da yüklü olması zorunlu.

Device Collectionlar SCCM yapınızın yönetimi için önem taşımakta. Kritik sunucuları genelde işletim sistemi versiyonuna göre collectionlar altında toplamanızı öneririm. Örneğin Server 2008 R2, 2012 R2 sürümler için ayrı collectionlar oluşturmanız gibi.  Update dağıtımları yaparken bize sağlayacağı kolaylığı fark edeceksiniz.

İşlemlerimize başlamadan önce genel yaygın olarak Updateler nasıl dağıtılıyor ona değinelim.

SCCM sunucumuz üzerinde Software Library\Overview\Software Updates\All Software Updates alanına geldiğimizde 1000 ve üzerinde update görebiliriz. Bu kadar çok update arasında ihtiyacımız olan updateleri nasıl belirleriz. Önce update dağıtımı yapacağımız işletim sistemi versiyonunu belirler, ardından seçtiğimiz işletim sistemi versiyonu için listelenen updatelerin arasından hangileri bize lazım bunları belirleriz. Bize lazım olmayan updatei dağıtmamıza lüzum olmadığı kanısındayım J

Üstteki ekran görüntüsünde inceleyecek olduğunuz üzere  2 arama kriteri belirledim.  Bunlardan ilki Product  yani update gönderimi yapacağımız ürün ailesi. Windows işletim sistemi olabileceği gibi bir Office 365 Client da olabilir, Office sistemi de Exchange updateleri de. Bizim örneğimiz de  server tabanlı işletim sistemlerini update edeceğimiz için  Product seçimini Server 2012 R2 olarak belirledim.  Required  seçeneği  ise 1 olarak belirledim bu sayıyı arttırmanızı önermem. Çünkü listelediği updatelerin içinden 1 tane bile olsa update isteyen sunucuları check edecek ve ona göre size liste sunacaktır.

Elimizde toplu bir update listesi olduğu sunucularımızın update durumlarını check etti ve istemiş olduğu update türlerini listeledi. Bundan sonraki süreç şu şekilde ilerleyecek  ilgili updateler için bir Software update group oluşturmak ve içerisinde yer alan updateleri önce Download edip ardından deploy etmek.

Üstteki ekran görüntüsünde göreceğiniz üzere belirlediğimiz kriterlere uyan updateleri topluca seçip  sağ click  dediğimiz de Create SUG seçeneği beliriyor. Sonraki adımları Türkçe olarak internet üzerinde rahatlıkla bulabilirsiniz.

Peki  bize listelediği update paketlerini başka türlü elde edebilir miyiz ? mümkün. Reporting point services rolümü yüklüyse aşağıdaki alana erişerek bu raporun daha detaylısını alabiliriz.

SCCM sunucu üzerinde \Monitoring\Overview\Reporting\Reports\Software Updates - B Deployment Management alanına geldiğimizde istediğimiz türde raporlar mevcut. Update gereksinim durumlarını bize verecek olan rapor türü  aşağıdaki rapordur.

Updates required but not deployed raporuna sağ click Run dediğimizde karşımıza aşağıdaki seçenekler çıkmakta.

İlk seçimimiz Collection olacak, dikkat ederseniz yazımın başında  Sunucu işletim sistemlerinize uygun Device Collectionlar oluşturmanızı önermiştim. 

2. seçim olarak Vendor seçimi yapıyoruz  Microsoft seçimi yeterli.

Son seçimimiz Update Class seçimi burada yüklemeyi istediğimiz update türünü seçiyoruz. Critical, updates, Security updates veya Definition updates seçimi yapabilirsiniz.

Seçimlerinizi  yapıp View report butonuna tıkladığınızda  seçtiğiniz collection içindeki sunucular da seçtiğiniz update türünde yükleme gereksinimi olan updateleri size listeleyecektir.

Ben üstteki ekran görüntüsünde Collection olarak Server 2008 R2 seçtim. Çünkü 2012 R2 sistemlerim full updated durumda listeyi boş çıkartacak J

Dilerseniz aldığınız listeyi üstteki gibi excele Export edip detaylı inceleyebilirsiniz.

Peki, elimizde bir liste var, update isteyen sunucular kim bunu nasıl öğreneceğiz diyebilirsiniz çözümü basit, yine raporlardan faydalanacağız.

Hatta bu updateleri var olan bir Software Update grup içerisine üye değillerse üye yapabilir dağıtıma hazır hale getirebiliriz. Aşama aşama ilerleyelim.

İlk kontrol etmemiz gereken alan eksik olan updatelerin durumu. Download edilmiş mi ? herhangi bir Collectiona deploy edilmiş mi ?

Üstteki ekran görüntüsünde paylaştığım  3172605 id’li KB nin durumunu kontrol edelim.

SCCM Sunucu \Software Library\Overview\Software Updates\All Software Updates alanından bu  id’yi arattığımda durum aşağıdaki gibi.

Henüz Download edilmemiş dolayısıyla Deploy edilmemiş durumda. Öncelikle Bu update paketini download etmeliyiz. Sağ click Download seçimi ile ilerleyelim.

Üstteki ekranda yeni Bir deployment paketi oluşturmayacağım. Çünkü önceden var olan Server 2008 R2 sunucularım için indirdiğim updateleri barındıran bir Deployment paketim var Browse seçimi ile onu göstereceğim.

Updatei doğrudan Microsoft’tan indirmesi için seçimim aşağıdaki gibi olacak.

Diğer aşamalar klasik dil seçimi, birden fazla dil seçim şansına sahipsiniz. Önerim işletim sistemi dilinize uygun seçim yapmanız yönünde.

Update paketim başarılı olarak indirildi. Yapmamız gereken bir işlem daha var.

Göreceğiniz üzere Download alanı “Yes” olarak değişti fakat Deployed kısmı halen “No”. Bunun otomatik deploy edilebilmesi için  Edit Membership diyerek üyeliğini belirlemeliyiz.

2008R2_Updates_All  isimli önceden update dağıtımında kullandığım Software Update Group içerisine üye yapıyorum.

Update paketimin üyeliğini gerçekleştirdim.  İlgili SUG gelip sağ click veya  üstteki menüden  Run summarization tıklamam yeterli. Veya bir süre beklemek.

Bakın Run Summarization işlemi sonrası Deployed alanı “Yes” olarak değişti.

Yapmamız gereken seçimize kalmış bir işlem daha var. Eğer ilgili update’in eksik olan sunucuya hemen uygulanmasını istiyorsak  ilgili Device collection üzerine gelip aşağıdaki tetiklemeyi gerçekleştirelim.  Client Notification > Download Computer Policy.

Peki bu update’in eksik olduğu sunucumuz hangisi bunu nasıl öğreneceğiz.

SCCM sunucumuz üzerinde \Monitoring\Overview\Reporting\Reports\Software Updates - A Compliance alanına gelerek aşağıdaki raporu çalıştıralım.

Seçimlerimiz aşağıdaki gibi olmalı.

Update Filter kısmına update id bilgisini girerseniz  Update seçimi alanında o id’ye sahip update paketi direk gelecektir.

Collection alanında ise update gereksinimi olan 2008 tabanlı sunucularınız olduğu collection seçimini yapmalısınız. View report diyerek sonucu görüntüleyelim.

Update is Required alanı ilk aldığımız raporda da olduğu üzere 1 peki bu sunucu hangi sunucu onu görüntüleyelim J

Sunucumuzun ismini bize verdi.  Bu update paketi restart isteyen bir update paketi olsaydı  Restart edilmesi gerekecekti. Üzerinde kritik uygulama çalışan bir Application sunucu ise  iş sahipleriyle görüşerek planlı kesinti isteyecektiniz ve uygun zaman diliminde sunucunun reboot edilmesi işlemini kendilerine bırakacaktınız. Yüzlerce Windows server 2008 R2  sunucunuzun olduğu ortamda 1 tane eksik update’in hangi sunucunuzda  eksik olduğunu bulmak   size hız kazandıran bir yöntem J

Görüldüğü üzere ilgili sunucumuz updatei almış yüklemiş ve restart istiyor J

Sunucu bu update yüklemesi sonrası uygun bir zamanda restart edilebilir. Tabii öncelik uygulama sahibinin onayında ve uygun göreceği zaman diliminde. Telco, Finans gibi kurumlar da sunucu restart edilmesi bir hayli onay ve risk gerektiren süreçlerdir J

Update yüklemesinin son durumunu nasıl öğreneceğiz derseniz aşağıdaki rapor işinize yarayacaktır.

SCCM sunucu \Monitoring\Overview\Reporting\Reports\Software Updates - C Deployment States

Pending System Restart kısmını tıklarsanız  aynı sunucunun ismini görüyor olacaksınız.

Peki, bir örnekle yazımızı sonlandıralım. Bildiğiniz üzere mayıs 2017 de hatta tam tarih vereyim 13 mayıs 2017 günü  WannaCry virüsü yüzünden sistemlerimizi patchlemiştik.   İlgili KB id’ler her OS için farklıydı.  Client Windows 7 tarafta ve Server 2008 R2 tarafta aynı  İd’ye sahip update  geçmiştik. KB 4012212  bu update paketine ihtiyacı olan server 2008 R2 sistemlerimizi kontrol etmek istersek nasıl bir yol izleyeeğiz. ?

SCCM sunucumuz da \Monitoring\Overview\Reporting\Reports\Software Updates - A Compliance bölümüne kadar geliyoruz  ve aşağıdaki raporu çalıştırıyoruz.

Windows 7 ve Server 2008 R2 için aynı id’li update paketi çıkarıldığı için sistem bize platform seçimi soruyor. Server platformunu seçip View Report dediğimiz de liste aşağıdaki gibi çıkacaktır.

İlgili update paketine ihtiyacı olan Sunucum çok şükür yok J olsaydı burada sayısı listelenecekti ve makalemize konu olan yöntemle hangi sunucularımız olduğunu öğrenebiliyor olacaktır.

Başka bir yazıda görüşmek dileğiyle.

SCCM ile Yazılım Envanteri Raporu oluşturma.

Merhaba, SCCM  yazılımının en kullanışlı özelliklerinden birisi de hiç kuşkusuz ki  Donanım ve yazılım envanteri alabilmemizdir.  Uygulama raporu alırken kriter belirleme olanağımız var. Örneğin TeamViewer yazılımı yüklü olan cihazları listelemek gibi veya Adobe Reader’ın belirttiğimiz versiyonunun yüklü olduğu cihazları listelemek  gibi. Veya tüm PC’lerde yüklü olan uygulamaların envanterini alıp excele export edip içerisinden filtreleme şansımızda  var.

SCCM ile yazılım envanteri toplayabilmek için öncelikle Client Settings üzerinde Software inventory açık durumda olmalı.

\Administration\Overview\Client Settings alanına giderek  aşağıdaki ayarın aktif olduğunu kontrol etmeliyiz.

Devamında,  istemci ve Server cihazlarda yüklü olan uygulamaların envanterini çekebilmemiz için Asset  Intelligence bölümünde aşağıdaki ayarı aktif etmemiz gerekiyor. SCCM kurulumu ile birlikte bu ayar default olarak seçili gelmemekte.

\Assets and Compliance\Overview\Asset Intelligence  sağ click Edit  Inventory Classes tıklıyoruz.

Listenin en başındaki SMS_InstalledSoftware seçeneğini aktif hale getirmemiz gerekiyor.

SMS_InstalledSoftware seçeneğini  işaretleyip aktif hale getirdikten sonran SCCM ile yönettiğimiz yapımızın büyüklüğüne ve cihaz sayımızın fazlalığına göre 1 gün ila 1 hafta arası  Data Discovery için beklemeliyiz.

Şimdi  ön gereklilikleri tamamladıktan sonra raporumuzu çekme aşamasına geçebiliriz.  SCCM üzerinde Reporting Services Point rolünün yüklü olduğunu hatırlatmak istiyorum.  Aksi halde rapor alamayız.

SCCMServer\Monitoring\Overview\Reporting\Reports alanına gelerek Search kısmına  Asset software yazmamız gerekiyor.

Computers with specific software installed isimli raporu kullanacağız dilerseniz işinize yarayacak başka raporlar da mevcut.  Ben tüm yüklü olan uygulamaların raporunu alacağım için bu rapor üzerinden gidiyorum.

İlgili rapor üzerinde Run  seçimini yapıyoruz.

2 seçenek bizi karşılıyor. 1. Olan Collection seçimi yapmamızı isteyen bölüm. Tüm cihazlarınızdaki  ( Server ve Client ) yazılımların raporunu almak isterseniz benim seçtiğim collectionu seçmelisiniz. Tam tersi sadece Windows 7 veya win10 cihazlarınızdaki veya Windows server cihazlarınızdaki uygulamaların raporunu almak isterseniz doğru collectionlar oluşturmanız halinde buradan seçerek işlem yapabilirsiniz.  Software Product alanı ise rapor almak istediğiniz uygulamaları isim olarak seçebiliyorsunuz. Örneğin Adobe Reader, veya MS Office gibi. Ben tüm yazılımların raporunu almak istediğim için “All” seçimini yapıp view Report ile devam edeceğim.

View Report seçimini yaptıktan cihaz sayınıza bağlı olarak biraz beklemeniz gerekebilir. 1000 cihaz ve üzeri ortamlarda bu süre 5 dakikanın üzerine çıkabiliyor.

İlgili raporu üstteki resimde göreceğiniz üzere excel olarak export edip   inceleyebilirsiniz.  Excel üzerinde filtreleme yaparak networkünüzdeki  cihazlarınızda yüklü olan uygulamaları ve kaç cihazda yüklü olduğunu cihaz ismi ip adresi gibi bilgilerle öğrenebilirsiniz.