PI Services

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 :

Nous allons pour l’exemple créer un fichier n’ayant pas le droit administrateurs.

Les autres fichiers ont bien le droit administrateurs dans leurs ACL.

Maintenant à l’aide d’un script, nous allons détecter le/les fichiers n’ayant pas l’identité “administrateurs”

Positionnons nous dans le répertoire nous intéressant et récupérons les différents éléments

cd "C:\Users\ato\Dropbox\Divers"
dirs=get-item *

maintenant on créer un tableau ou seront ajoutés les différents éléments n’ayant pas le droits administrateurs

Ensuite à l’aide du code ci dessous, nous allons être capable de récupérer dans le tableau $acl les éléments de notre recherche:

foreach ($d in $dirs)
{
    $ID=(get-acl $d).access | %{$_.identityreference}
    if ($ID -match "administrateurs"){}  #c’est ici que l’on définit l’acl manquant que l’on recherche
    else
    {
        $d.fullname
        $acl=$d.fullname
    }
}

Apres exécution du script, on peut voir que la variable $acl a bien été définis avec le fichier n’ayant pas le droit administrateur

Imaginons que vous devez supprimer à un emplacement donné des répertoires et/ou fichiers n’ayant pas été modifiés depuis 30 jours.

Ce petit script va permettre d’identifier les éléments correspondant à notre critère de recherche.

Positionnons nous dans le répertoire nous intéressant

cd "C:\Users\ato\Google Drive"

On obtient tous les items à notre emplacement

$items= get-item *

Un petit compteur pour identifier le nbre d’éléments qui nous sera retourné

$i=0

Nous allons maintenant récupérer le chemin absolu des items n’ayant pas été modifié depuis au moins 30 jours.

foreach ($item in $items)

{

$days=($item |New-TimeSpan).days

if ($days -ge 30) # c’est ici que nous définissons le nbre de jours

{

$i++

$item.fullname

}

}

echo "Nbres item $i"

Il y a donc 83 items n’ayant pas été modifié depuis au moins 30 jours.

Sur un total de 114 items

Il ne vous reste plus qu’à ajouter un remove-item dans la boucle de traitement si vous souhaitez supprimer les items renvoyés.

Le projet de développement d’un management pack pour étendre la supervision des serveurs Hyper-V V3 offre une nouvelle mise a jour:

Au menu de cette version 1.0.1.282:

- le support des serveurs Hyper-V 2012 R2

- La supervision des Extended Replicas

http://hypervmpe2012.codeplex.com/