Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

SCOM – Contournements du bug APM

par | 1 Oct 2018 |

Si vous gérez au quotidien un environnement SCOM, ou si vous suivez un tant soit peu l’actualité de cet outil, vous avez forcément déjà entendu parler du bug APM : depuis la sortie de SCOM 2016, lors du déploiement de l’agent, le module APM (application monitoring) est susceptible de provoquer le plantage de certains webservices hébergés dans IIS, même lorsque la fonctionnalité APM est désactivée.

Cela peut évidemment avoir un impact conséquent lorsqu’il s’agit de webservices utilisés pour une application critique en production…

Jusqu’ici (et donc depuis presque 3 ans…), Microsoft s’est contenté d’indiquer avoir constaté le problème et l’avoir corrigé « en partie » au fil des mises à jour de SCOM 2016. Cette « partie » est manifestement insuffisante, puisque le problème persiste et oblige à la plus grande vigilance lors du déploiement d’un nouvel agent puisque seule l’installation manuelle avec l’option NOAPM=1 permet de se prémunir à coup sûr du problème.

Avec la sortie de SCOM 1807, Microsoft propose enfin un contournement industrialisable à défaut d’une correction : le changelog indique en effet qu’il est désormais possible de pousser l’agent sans le module APM, que ca soit via la console ou via powershell :

 

Install-SCOMAgent -DNSHostName “nomduserveur.local” -PrimaryManagementServer $PrimaryMS –NoAPM

 

Un second contournement est proposé sur certains blogs ( par exemple https://blogs.technet.microsoft.com/hybridcloud360/2018/06/29/scom-and-apm-the-simplest-workaround/ qui fournit de nombreux détails) :

Il semble en effet que cela ne soit pas le module APM de SCOM 2016 en lui-même qui pose problème, mais plutôt l’ajout du paramètre EnableRTIA Profiler à la règle Apply APM Agent configuration  contenue dans le Management Pack Microsoft.SystemCenter.Apm.Infrastructure ; ce qui explique d’ailleurs que le problème se produise également sur les serveurs disposant toujours d’un agent SCOM 2012 R2 lorsque le reste de l’environnement SCOM a été mis à jour en version 2016 ou ultérieure.

Il suffit donc d’overrider cette règle pour passer le paramètre EnableRTIA Profiler à False, et le problème disparait !

Prenez cependant bien le temps de tester ceci dans votre environnement, il est tout à fait possible qu’il ne s’agisse là encore que d’un contournement partiel…

SCOM – Déplacer le rôle Reporting

par | 1 Oct 2018 |

Lors du déplacement du rôle Reporting vers un nouveau serveur SSRS pour le compte d’un client, je me suis heurté à quelques problèmes et interrogations pour lesquelles les réponses n’étaient pas toujours très claires ou accessibles.

On retrouve par exemple un certain nombre de billets de blogs ou de posts sur les forums technet qui indiquent qu’il n’est pas possible de déplacer la base de données utilisée par SSRS, et donc pas possible de conserver facilement tous les rapports personnalisés et planifiés.
Il est en réalité parfaitement possible de procéder à une nouvelle installation de SCOM Reporting Services sur un SSRS vierge puis de restaurer la base du précédent SSRS, à condition de bien réaliser les opérations dans cet ordre :

  • Sur l’ancien serveur de reporting, sauvegarder les bases ReportServer et ReportServerTempDb (noms par défaut) ainsi que la clé de chiffrement de SSRS et le fichier config
  • Installer SSRS sur le nouveau serveur
  • Installer le rôle SCOM Reporting sur le serveur
  • Restaurer les bases ReportServer et ReportServerTempDb ainsi que la clé de chiffrement
  • Reconnecter SSRS aux bases restaurées
  • Reprendre les paramètres dans web.config

 

Un nouveau problème peut survenir dans la foulée : si le serveur SSRS d’origine exécutait une licence supérieure de SSRS (par exemple Datacenter alors que le nouveau serveur SSRS ne dispose que d’une licence Standard), un message d’erreur vous accueillera lorsque vous tenterez de vous connecter au portail :

 

La solution la plus logique serait de supprimer toute référence à l’ancien serveur dans l’onglet Scale-Out de la console SSRS, mais malheureusement cela ne fonctionne pas.

Il est alors nécessaire de passer directement par l’édition de la table dbo.Keys dans la base ReportServer pour en retirer toute référence à l’ancien serveur en supprimant la ligne correspondante :

DELETE FROM [ReportServer].[dbo].[Keys]

WHERE MachineName = ‘AncienServeur’

Redémarrez ensuite SSRS, et confirmez que le portail fonctionne maintenant bien et que vous pouvez y retrouver toutes vos personnalisations antérieures !

 

Script Powershell – SCOM – Suppression d’overrides de monitor

par | 27 Sep 2018 | , ,

Le script suivant supprime tout les overrides correspondant a une propriété donné, pour un ou plusieurs monitors.

 

 

### DELETE OVERRIDES FROM MONITORS ###

Param(
$MS
,$cred = $(Get-Credential "MyDomain\Myself")
,$targetMonitorsPatern = "Check My App*"
,$OverrideProp = "GenerateAlert"
)

# Import of SCOM module
try
{
Import-Module -Name OperationsManager -ErrorAction stop
}
catch
{
write-host -ForegroundColor red "Error during import of SCOM module"
}

# Connection to management server $MS
New-SCOMManagementGroupConnection -ComputerName $MS -Credential $cred


 #The monitors 
 $targetMonitors = Get-SCOMMonitor -DisplayName $targetMonitorsPatern


 foreach ($Monitor in $targetMonitors) 
 {
 [array]$OverrideToDelete += Get-SCOMOverride -Monitor $Monitor | Where {$_.Property -eq $OverrideProp} 
 }


 $OverrideToDelete | foreach {

 [array]$targetMP += $_.GetManagementPack()
 $targetMP.FindManagementPackElementByName($_.Name).status='PendingDelete'
 $targetMP.AcceptChanges()
 }









Derniers articles

Catégories

Archives

Auteurs/Autrices