PI Services

Sortie presque simultanée du RU5 de SCOM 2012 SP1 et du RU1 de SCOM 2012 R2

http://support.microsoft.com/kb/2904680

http://support.microsoft.com/kb/2904678

Une dizaine de bug corrigés dont plusieurs commun aux deux versions + certains bugs liés a la supervision des agents Unix/linux.

Introduction

Cet article permet de montrer la gestion des certificats via Powershell au travers d'un problème concret rencontré sur une infrastructure Exchange. Une solution basée sur un script Powershell sera détaillée.

Erreur rencontrée

Contexte : Infrastructure Exchange 2010 avec plusieurs dizaine de milliers de contacts Active Directory importés et mis à jour par un outil tierce.

Dans l’observateur d’événements de nombreux événements 9323 apparaissent.

Ces derniers sont liés à la génération de l'OAB. Exchange détecte un utilisateur dont un certificat est expiré. Ces événements n'apparaissent que sur des objets de type "Contact"  La solution doit contrôler tous les objets Active Directory de ce type.

Solution

La soluton proposée pour purger les certificats invalides des contacts Active Directory se base sur un script Powershell V2. Ce dernier analyse l'attribut UserCertificate (il s'agit d'une liste de certificat).

Avec le type d'objet "System.Security.Cryptography.X509Certificates.X509Certificate2", il est possible d'obtenir des informations sur les certficats contenus dans cet attribut sous forme lisible (et non pas un tableau de bytes ou de valeur hexadécimal comme sur la console Active Directory Users and Computers).

Ci-dessous, un exemple de données récupérées sur les certificats d'un objet Active Directory (ici, il n'y a qu'un seul certificat et la variable $User est un utilisateur Active Directory).

On remarque qu'on accède à des renseignements comme l'émetteur ou le sujet. Les informations qui nous interessent (dates de validité du certificat) sont aussi présentes. Il suffit donc de comparer la date d'expiration contenue dans l'attribut "notAfter" avec la date du jour en cours pour détecter les certificats expirés.

Grâce à la cmdlet "Set-ADObject", il sera ensuite possible de supprimer les certificats qui ne sont plus valides.

Script

En amont de ce script, un transcript est lancé afin de loguer toute les opération effectuées. Une vérification de la présence du module ActiveDirectory ainsi que son chargement sont ensuite réalisées.

Le script appelle une fonction créée pour traiter tout objet AD (ou tableau d'objets AD) qui lui est passé. Pour ma part, je transmets en paramètre tous les contacts présents dans Active Directory. Cependant cette fonction peut très bien être utilisée avec des utilisateurs. Voici l'algolrithme mis en place dans la fonction Test-CertExpiration :

Ci-dessous, vous trouverez le script intégralement commenté. A noter, que le compte exécutant ce script doit posséder les droit suffisants à la modifications des objets AD concernés (via une délégation par exemple).

$ADObjets est un tableau d'objets Active Directory.

Dans ce cas, un tableau d'objets AD est retourné. Pour chaque objet, les attributs CertExpired et CertValid sont ajoutés.

Quelques points clés du fonctionnement de la fonction Test-CertExpiration :

Les paramètres Export et DeleteExpired sont de type switch et ne peuvent apparaître ensemble. Le paramètre ExportPath est dynamique et n'est disponible que si le paramètre Export a été choisi.

Pour information, il n'est pas nécessaire de paralléliser le processus de contrôle du certificat. Après un test effectué sur plus de 90000 contacts Active Directory, il s'avère que ce dernier a duré moins de 5 minutes. Utiliser du multi thread (workflow ou job Powershell) alourdirai le script et ralentirai le processus au lieu de l'accélérer.

Introduction

Powershell est intégré dans tous les nouveaux produits et services de Microsoft. Grâce à ce langage de scripting il est tout naturellement possible d'administrer Exchange Online via le Remote Powershell. Au delà d'offrir des possibilités d'automatisation, certaines opérations ne sont réalisables que par ce biais.

La gestion d'Exchange Online se décompose en 2 parties :
L'installation d'un module Powershell pour la gestion des utilisateurs dans l'Active Directory Azure
La connexion à Exchange Online pour l'administration des paramètres de la messagerie et des boîtes aux lettres.

Cet article s'adresse donc aux personnes souhaitant administrer Exchange Online mais aussi à ceux qui utilisent Active Directory dans le cloud Azure.

Nous allons voir comment accéder à la gestion des utilisateurs sur Office 365, à leurs boîte email Exchange Online. Je montrerai aussi quelques erreurs courantes (problème d'installation et connexion derrière un proxy) que l'on peut rencontrer lors d'une interaction avec Office 365 ainsi que leurs résolutions.

A noter que, comme les sessions distantes Powershell sont apparues avec la version 2, il est nécessaire de posséder à minima cette version pour exécuter les opérations que nous allons voir.

Gestion des utilisateurs Microsoft Online (Azure Active Directory)

Installation :

L'administration des utilisateurs ne peut se faire que via l'installation d'un module Powershell. Ce dernier nécessite un prérequis : Microsoft Online Services Sign-In Assistant. Ci dessous, vous trouverez les liens de téléchargement de ce dernier :

Microsoft Online Services Sign-In Assistant– 32 bit version
http://go.microsoft.com/fwlink/?linkid=236299
Microsoft Online Services Sign-In Assistant – 64 bit version
http://go.microsoft.com/fwlink/?linkid=236300

Voici maintenant les liens pour récupérer le module Powershell :

Microsoft Online Services Module for Windows PowerShell (32-bit version)
http://go.microsoft.com/fwlink/?linkid=236298
Microsoft Online Services Module for Windows PowerShell (64-bit version)
http://go.microsoft.com/fwlink/?linkid=236297

Vérification de l'installation :

Erreurs rencontrées :

1/ Lors de l'installation de Microsoft Online Services Sign-In Assistant, j'ai rencontré l'erreur suivante :

In order to install Windows Azure Active Directory Module for Windows PowerShell, you must have Microsoft Online Services Sign-In Assistant version 7.0 or greater installed on this computer.

Pour résoudre ce problème, il m'a fallu installer la beta de ce prérequis disponible dans le lien ci-dessous :
http://www.microsoft.com/en-us/download/details.aspx?id=39267​

2/ Si un proxy est utilisé lors de la connexion au cloud de Microsoft, alors on obtient l'erreur suivante :

Pour résoudre ce problème, il faut configurer le proxy ainsi que les paramètres d'authentification à utiliser :

Par défaut Powershell utilise le proxy d'Internet Explorer ; on peut reconfigurer le paramétrage du proxy avec la commande « netsh ».

Connexion à Exchange Online

Implémentation :

Le but de l'opération est d’importer toutes les commandes que l’on connait sous Exchange comme « Get-Mailbox » qui existent aussi sous Exchange Online.
Voici les quelques lignes Powershell permettant d'ouvrir une PSSession vers Exchange Online en spécifiant un compte utilisateur pour s'authentifier puis d'importer les cmdlets Exchange. A noter que la liste des commandes disponibles variera en fonction des droits du compte utilisé (grâce à RBAC).

Erreur rencontrée :

Comme pour la gestion des utilisateurs Active Directory dans le cloud, une configuration particulière est attendue lorsque l'on essaie de se connecter en passant par un proxy. L'erreur générique suivante apparaît :

Pour résoudre ce problème, il est possible d'utiliser la même méthode que précédemment. Cependant, on peut aussi définir les paramètres des sessions Powershell distantes et ainsi configurer un proxy. Dans l'exemple ci-dessous nous utiliserons le proxy défini dans Internet Explorer :

La variable $Credential contient les paramètres d’authentification.

Contexte

Dans le cadre de projets, il peut arriver que les licences définitives ne soient pas livrées au moment du déploiement des serveurs. Pour ne pas perdre de temps, il est possible d’installer la version d’évaluation de Windows Server 2012 R2 (http://technet.microsoft.com/fr-fr/evalcenter/dn205286.aspx) qui est valable 180 jours et de la mettre à niveau vers une version commerciale une fois la licence acquise.

Solution

La commande-let DISM permet de mettre à niveau notre version d’évaluation vers une version commerciale (avec licence).

Pour se faire, lancez l’invite de commande en tant qu’administrateur et tapez la commande suivante :

DISM /Online /Set-Edition:<type de version> /ProductKey:<licence> /AcceptEula

Une fois la commande terminée, il faut redémarrer le serveur.

Remarque : Afin de savoir vers quelle type de version il est possible de mettre à niveau le serveur utilisez la commande DISM /Online /Get-TargetEditions

Après le redémarrage le serveur n’est plus un serveur d’évaluation et il peut être activé normalement.

Remarques

1 – Cette commande fonctionne également avec une des nouveautés de Windows Server 2012 R2 : l’AVMA (Automatic Virtual Machine Activation).

2 – Attention cette mise à niveau ne fonctionne pas si le serveur est un contrôleur de domaine. Pensez donc bien à faire la manipulation avant l’installation du rôle Active Directory Domain Services !

Principe

L’ajout d’un disclaimer dans les correspondances électronique est là pour rappeler le caractère confidentiel du contenu de l’email. C’est un rappel de bonne conduite.

Mise en place

Etape 1 : Se connecter au centre d’administration d’Exchange 2013

Exemple d’URL : https://<votre_serveur_Exchange>/ecp

Etape 2 : Cliquer sur “Flux de messagerie” puis “Règles”

Etape 3: Ajouter une règle

Cliquer sur “+” en dessus des règles, choisir “Créer une règle…”.

Etape 4: Configurer la règle

Pour le critère “Appliquer cette règle si…”, choisir l’option “Le destinataire se situe…” et choisir “Hors de l’organisation” comme paramètre.

Pour le critère “Procédez comme suit…”, choisir l’option “Ajouter une exclusion de responsabilité…” et tapez le texte que vous voulez ajouter comme disclaimer en cliquant sur “Entrer du texte…” à droite.

Enfin, sélectionner le paramètre “Ignorer” s’il est impossible d’appliquer l’exclusion de responsabilité.

Pour terminer, cliquer sur Terminer.

Etape 5: Vérifier que la règle est activée

Exemple de disclaimer

Ce message contient des informations confidentielles destinées à la personne mentionnée ci-dessus. Si vous n'êtes pas cette personne, vous n'avez pas l'autorisation de révéler ces informations, de les transmettre à qui que ce soit ou d'en faire des copies. Avertissez l'expéditeur immédiatement et détruisez cet e-mail.

Conclusion

De cette manière, vous pouvez ajouter un message de sécurité de façon simple et centralisé. Vous avez aussi la garantie que le message soit appliqué à tous les mails sortant de votre organisation et sans devoir le gérer par les signatures mails de chacun.

Petite information, un mail non chiffré contenant un disclaimer n’a aucune valeur juridique, c’est comme envoyer une carte postale sans enveloppe. Pensez donc à chiffrer vos emails.

Introduction

Afin de mieux faire correspondre la page de connexion à votre entreprise, il est possible de la personnaliser pour y intégrer logo et couleur de votre compagnie.

Pour personnaliser l’interface de votre portail OWA, deux principales modification sont à faire, le changement des couleurs en modifiant le fichier “logon.css” et changer les images par défaut de la page web.

Les fichiers désirés se trouvent dans le dossier suivant :

Dans ce dossier trois fichiers vont nous interesser :

1. olk_logo_white.png image au format 128x108px

• owa_text_blue.png image au format 423x55px
• logon.css

Avant de commencer, le dossier Resources doit intégralement être copié et sauvegardé.

Interface OWA

Après modification :

Modification du fichier Logon.css

1. Pour décaler le logon Container :

Il arrive que le logonContainer soit décalé, pour configurer sa position, il faut modifier les propriétés “padding” dans la partie ci-dessus.

1. Modifier la couleur des textbox :

Dans cette partie du CSS, on peut modifier les couleurs des deux textbox de la partie LogonContainer.

1. Couleur partie de droite :

1. Changer la couleur de la sidebar

Modification des images

Les images utilisées pour la page OWA sont toutes enregistrées dans le dossier Ressource.

Il suffit de remplacer les images existantes par celles souhaitée en les renommant avec le même nom et en les recardant à la bonne taille (en pixels).

Lorsqu’un agent a été installé manuellement, par exemple en raison d’un flux bloqué temporairement ou d’une installation réalisée par une personne peu habituée à utiliser SCOM, cet agent se retrouve impossible à gérer de façon centralisée depuis la console :

Il n’est malheureusement pas possible de modifier cet état en passant par la console, ni en passant par Powershell ; la seule solution officielle est donc de désinstaller cet agent, puis de le réinstaller en le déployant cette fois depuis la console.

En réalité, cet état est stocké sous forme de « flag » dans la base de données OperationsManager.

La requête SQL suivante permet de lister tous les agents flaggés comme étant « non remotely manageable » :

select bme.DisplayName from MT_HealthService mths

INNER JOIN BaseManagedEntity bme on bme.BaseManagedEntityId = mths.BaseManagedEntityId

where IsManuallyInstalled = 1

On peut donc modifier l’état « non remotely manageable » simplement en passant le flag IsManuallyInstalled de 1 à 0 dans la base de données.

Attention, les modifications en base de données ne sont pas supportées par Microsoft ! Une sauvegarde de la base avant d’y exécuter des requêtes reste toujours vivement recommandé.

• · Pour modifier le flag sur l’intégralité des serveurs et tous les passer en « Remotely Manageable », on utilise la requête SQL suivante :

UPDATE MT_HealthService
SET IsManuallyInstalled=0
WHERE IsManuallyInstalled=1

• · Pour modifier le flag sur un unique serveur, on utilise la requête SQL suivante (note : le BaseManagedTypeID AB4C891F-3359-3FB6-0704-075FBFE36710 correspond au HealthService)

UPDATE MT_HealthService
SET IsManuallyInstalled=0
WHERE IsManuallyInstalled=1
AND BaseManagedEntityId IN
(select BaseManagedEntityID from BaseManagedEntity
where BaseManagedTypeId = 'AB4C891F-3359-3FB6-0704-075FBFE36710'
AND DisplayName = 'server.pouet.lan')

• · Enfin, c’est également l’occasion de mettre à profit la classe MP_AgentCertificate.Server dont j’ai expliqué la création dans l’article Identifier les agents authentifiés par certificat.

En effet, elle contient l’intégralité des serveurs qui s’authentifient par certificat et ces derniers sont dans la majorité des cas des serveurs installés manuellement pour une bonne raison (DMZ etc). Il n’est donc pas souhaitable de les repasser en RemotelyManageable.

Nous allons donc dans un premier temps lister l’ensemble des instances de cette classe à l’aide de powershell (à l’exception des serveurs MS et des gateway, qui sont bien des agents possédant un certificat mais que l’on souhaite gérer de facon centralisée)

Cette liste sera créée sous une forme directement exploitable dans une requête SQL :

$managementservers = Get-SCOMManagementServer | ForEach-Object {$_.displayname}

$certagents = get-scomclassinstance -class (Get-SCOMClass -name "MP_AgentCertificate.Server") | where {$managementservers –notcontains $_.displayname }

foreach ($certagent in $certagents) {"AND DisplayName != '" + $certagent.displayname + "'"}

Il ne reste plus qu’à copier la liste générée (les lignes AND DisplayName != ‘serveurxxx’ ) et à l’intégrer dans la requête SQL précédente :

UPDATE MT_HealthService
SET IsManuallyInstalled=0
WHERE IsManuallyInstalled=1
AND BaseManagedEntityId IN
(select BaseManagedEntityID from BaseManagedEntity
where BaseManagedTypeId = 'AB4C891F-3359-3FB6-0704-075FBFE36710'
AND DisplayName != 'server001'
AND DisplayName != 'server002'
AND DisplayName != 'server003'
AND DisplayName != 'server004'
)

Une fois la requête appropriée exécutée, vos agents devraient apparaitre comme RemotelyManageable dans la console SCOM quasi instantanément (un refresh de la console peut aider si ce n’est pas le cas).

Dans une infrastructure SCOM, il arrive couramment qu’une petite partie des agents nécessite une authentification par certificat, la plupart du temps lorsqu’ils sont installés sur des serveurs en DMZ, Workgroup ou sur des serveurs membres de domaines ne disposant pas de relation d’approbation.

De ce fait, ils sont la plupart du temps installés manuellement et non pas déployés depuis la console SCOM.

Ces agents nécessitent une attention particulière, car leur gestion diffère des agents déployés plus traditionnellement : ils nécessitent un renouvellement de certificat à échéance régulière, ils ne peuvent pas être mis à jour automatiquement…

Il n’existe pourtant par défaut pas de classe ni de groupe ni de vue dans SCOM qui permette de les identifier rapidement.

J’ai donc développé une classe pour y remédier. Elle se base sur un script VBS qui tourne toutes les 24h et identifie la présence de la chaine ChannelCertificateSerialNumber dans la clé HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings et peuple une classe MP_AgentCertificate.Server basée sur Microsoft.Windows.Computer.

Définition de la classe :

<ClassType ID="MP_AgentCertificate.Server" Accessibility="Internal" Abstract="false" Base="Windows!Microsoft.Windows.Computer" Hosted="false" Singleton="false" Extension="false" />

Définition de la découverte :

<Discovery ID="MP_AgentCertificate.Discovery" Enabled="true" Target="Windows!Microsoft.Windows.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">

<Category>Discovery</Category>
<DiscoveryTypes>
<DiscoveryClass TypeID="MP_AgentCertificate.Server" />
</DiscoveryTypes>
<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.DiscoveryProvider">
<IntervalSeconds>86400</IntervalSeconds>
<SyncTime />
<ScriptName>regcertdiscovery.vbs</ScriptName>
<Arguments>$MPElement$ $Target/Id$ $Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Arguments>

<ScriptBody>
Dim oAPI
Set oAPI = CreateObject("MOM.ScriptAPI")
Dim oArgs
Set oArgs = WScript.Arguments
' Check for the required script arguments.
if oArgs.Count &lt; 3 Then
' If the script is called without the required arguments,
' create an information event and then quit.
Call oAPI.LogScriptEvent("regcertdiscovery.vbs",101,0,"script was called with fewer than three arguments and was not executed.")
Wscript.Quit -1
End If
Dim SourceID, ManagedEntityId, TargetComputer, strComputer

SourceId = oArgs(0) ' The GUID of the discovery object that launched the script.
ManagedEntityId = oArgs(1) ' The GUID of the computer class targeted by the script.
TargetComputer = oArgs(2) ' The FQDN of the computer targeted by the script.
Dim oDiscoveryData, oInst

Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)
Const HKEY_LOCAL_MACHINE = &amp;H80000002
strComputer = "."
Set StdOut = WScript.StdOut
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &amp; strComputer &amp; "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings"
strValueName = "ChannelCertificateSerialNumber"

oReg.GetBinaryValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

if IsNull(strValue) then
StdOut.WriteLine "no cert found"
Call oAPI.LogScriptEvent("regcertdiscovery.vbs",101,0,"no cert found")

else
Call oAPI.LogScriptEvent("regcertdiscovery.vbs",101,0,"cert found")

' Discovered the application. Create the application instance.

Set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='MP_AgentCertificate.Server']$")

' Define the property values for this instance. Available

' properties are determined by the Management Pack that

' defines the class.

Call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)
Call oDiscoveryData.AddInstance(oInst)

end if

' Submit the discovery data for processing.

Call oAPI.Return(oDiscoveryData) </ScriptBody>

<TimeoutSeconds>600</TimeoutSeconds>
</DataSource>
</Discovery>

Libre à vous ensuite d’intégrer ces éléments à votre propre MP et d’y ajouter des moniteurs ou de créer une vue listant les instances de la classe MP_AgentCertificate.Server etc.

Note : il peut être utile de créer une override qui exécute cette découverte toutes les 10 minutes dans un premier temps, puis de la supprimer lorsque tous les serveurs sont découverts.

Attention si vous utilisez les instances de cette classe pour effectuer des traitements par lot : elle contient tous les agents possédant un certificat, y compris les MS et les Gateways !

Vous trouverez un exemple d’utilisation de cette classe dans l’article Passer des agents en remotely manageable

Lors de la modification des propriétés d’un User Role (par exemple un changement dans le Scope), le message Parameter UserRoleDisplayName cannot be null apparait au moment de sauvegarder ces changements.

Bien entendu, dans la console SCOM, le champ « user role name » n’est pas vide.

A quoi peut donc être due cette erreur ?

Allons faire un tour dans la base de données, là où sont stockées les localisations :

select LanguageCode,LTValue from LocalizedText

where LTValue like ('operations manager %operators')

On remarque immédiatement que le rôle qui nous pose problème (ici Operations Manager Report Operators, mais cela pourrait être n’importe quel role créé après l’installation) comporte un LanguageCode différent, qui correspond normalement à la langue du système depuis lequel a été créé ce role.

On en déduit donc rapidement qu’un rôle créé depuis une console SCOM installée localement sur votre poste personnel (et dont le Windows est en général en francais) prend le LanguageCode correspondant à ce système et devient impossible à modifier depuis une console installée sur un système localisé dans une autre langue, par exemple depuis la console installée sur le serveur SCOM qui est généralement lui en anglais !

En attendant que Microsoft corrige ce problème, les contournements possibles sont assez évidents :

• Utiliser une console installée sur un Windows localisé dans la même langue que celle qui a servi à créer le rôle
• Modifier le champ LanguageCode des rôles problématiques afin de les passer en ENU. Notez cependant que Microsoft ne fournit pas de support si vous effectuez des modifications manuelles en base de données en dehors de leurs propres instructions.

Nous disposons d’une variable de type tableau avec comme informations des utilisateurs et leurs villes.

Nous allons ici créer dynamiquement une variable pour chaque site présent dans la variable $users et y affecter les utilisateurs.

Nous allons créer une variable de type tableau dans lesquels nous allons récupérer tous les sites disponibles dans notre variable $users.

$sites=@()

Nous alimentons maintenant la variable $sites.

foreach ($user in $users)

{

$sites+=$user.extensionAttribute8

}

$sites=$sites |sort | Get-Unique

Résultats :

Maintenant nous allons créer pour chacun des sites récupérés une variable avec pour nom la valeur récupéré dans la variable $sites

$sites | %{New-Variable -Name $_ -value @() -ErrorAction SilentlyContinue; if ($? -eq $true){write-host "variable créé : $_"}}

Résultats :

Maintenant nous allons alimenter dans les variables créés précédemment dynamiquement les utilisateurs présents dans les sites

foreach ($user in $users)

{

$VariableValue = $Null

$user.extensionAttribute8 |%{$VariableValue = @(((Get-Variable $_).Value)+$user);Set-Variable -name $_ -value $VariableValue}

}

Résultats :