Vous souhaitez récupérer les events de Lock Account sur un DC en PS

Voici la ligne à taper :

Get-WinEvent -FilterHashtable @{logname="Security"; Id=4740 }

Il ne vous reste plus qu’a analyser les propriétés des events retournés

Vous avez installé les outils admins sur un serveur mais vous ne trouvez pas le module Configuration Manager PowerShell.

Il y a une petite subtilité, celui ci est présent mais dans les binaires de l’application:

le fichier à importer se trouver dans le répertoire c:\program files (x86)\Microsoft Configuration Manager\AdminConsole\bin et se nomme ConfigurationManger.psd1

Avant import

Après import

Vous êtes dans un contexte de database mirroré, et vous avez besoin de connaitre l’actuel serveur principal.

Voici une fonction qui va vous permettre de l’identifier.

Function Test-SQLConn ($Server)
{
    $connectionString = "Data Source=$Server;Integrated Security=true;Initial Catalog=master;Connect Timeout=2;"
    $sqlConn = new-object ("Data.SqlClient.SqlConnection") $connectionString
    trap
    {
    Write-host "Closed";
    continue
    }
    $sqlConn.Open()
    if ($sqlConn.State -eq 'Open')
    {
        $sqlConn.Close();
        "Opened successfully."
    }
}

Malgré des mises à jour relativement suivies, le Management Pack DHCP conserve des erreurs y compris dans sa version la plus récente à ce jour (6.0.7301.0).

Deux problèmes en particulier me semblent particulièrement récurrents :

- Une alerte “Power Shell Script failed to run” caracterisée par sa description : “System.Management.Automation.RuntimeException: Method invocation failed because [System.String[]] doesn't contain a method named 'Item'.
At line:65 char:20
+ $OS = $CurrVer.Item <<<< (0) + "." + $CurrVer.Item(1) »

- Une absence de retour en Healthy du moniteur DHCP IPv4 Runtime Active Directory Availability Monitor.

Attardons nous donc sur ces deux problèmes.

Dans le premier cas, le message d’erreur nous indique qu’il s’agit de l’échec de l’exécution de la découverte Microsoft.Windows.DHCPServer.2012.R2.ClusterServer.Discovery. Cette dernière permet, comme son nom l’indique, de découvrir les clusters DHCP 2012 R2 et elle utilise pour ce faire le script powershell DiscoverDHCPClusterServer2012R2.

Cette découverte est ciblée sur la classe Virtual Server, c’est-à-dire tous les clusters Windows (et pas uniquement ceux sous Windows 2012), mais le script de découverte vérifie bien la version de Windows dont il s’agit en début d’exécution à l’aide du code suivant :

$CurrOS = Get-WmiObject -Namespace "root\cimv2" -Query "select Version from Win32_OperatingSystem"
$OSVer = $CurrOS.Version
$CurrVer = $OSVer.Split(".")
$OS = $CurrVer.Item(0) + "." + $CurrVer.Item(1)
if ($OS -ne $TargetOSVersion)
{
Write-Host "$SCRIPT_NAME - No Target Operating System"
$discoveryData
exit
}
else
{ exécution de la découverte }

On retrouve dans ce bloc de code la commande indiquée dans la description de l’erreur, $OS = $CurrVer.Item(0) + "." + $CurrVer.Item(1) .

La raison de cette erreur est assez simple : Powershell v2 ne supporte pas la méthode Item, comme l’indique clairement le message d’erreur « Method invocation failed because [System.String[]] doesn't contain a method named 'Item’ ». L’exécution du script échoue donc sur tous les serveurs Windows 2008 ou antérieurs pour lesquels powershell n’a pas été mis à jour !

La résolution est aussi plutôt évidente, il suffit d’utiliser la syntaxe suivante (compatible avec toutes les versions de powershell) à la place :

$OS = $CurrVer[0] + "." + $CurrVer[1]

Passons maintenant au second problème.

Le moniteur est de type Event Reset, c’est-à-dire qu’il doit revenir en Healthy lorsqu’un événement indiquant un retour à la normal apparaît dans le journal d’événement ; par défaut l’événement 1048.

Il semble toutefois que cet événement soit incorrect, ou en tout cas qu’il ne soit pas le seul qui puisse être généré. Dans le cas de l’environnement où j’ai constaté le bug, cet événement n’est jamais généré mais par contre un événement 1044 qui semble valider le même retour à la normal est lui bien présent.

Il faut donc rajouter cet événement au moniteur.

Malheureusement, pour nos deux problèmes, il s’agit d’un management pack scellé. Il est donc impossible de modifier directement le script de la découverte ou la configuration du moniteur.

La solution consiste alors à créer un management pack correctif, qui implémentera donc les bonnes versions de ces workflows et désactivera les versions d’origines erronées.

Et pour ceux qui ne se sentent pas l’âme d’un développeur, un tel Management Pack réalisé par mes soins est disponible ici : Microsoft.Windows.DHCPServer.Fix.xml

Note : ce management pack a été testé dans un environnement spécifique, rien ne garantit qu’il fonctionnera ou qu’il ne posera aucun problème dans le vôtre. Prenez donc le temps de le valider avant de le déployer en production !

Vous est il déjà arrivé de ne pas réussir à activer la découverte réseau sur votre serveur ? 

Pas d'inquiétude cela peut arriver si certains services ne sont pas démarrés.

Contexte

Voici ce que l'on trouve lorsque l'on se rend dans "Panneau de configuration\Réseau et Internet\Centre Réseau et partage\Paramètres de partage avancés"

Ici lorsque l'on coche la case "Activer la découverte de réseau" puis "Enregistrer les modifications"

Si l'on retourne dans le menu "Paramètres de partage avancés" nous nous apercevons que dans le profil que nous venons juste de modifier, la case "Activer la découverte de réseau" n'est pas sélectionné et que celle qui l'est n'est autre que "Désactiver la découverte de réseau"

Solution

Ce phénomène est lié au fait que certains services ne sont pas démarrés, voici la marche à suivre.

Lancez la console "services.msc" et démarrez les services suivants:

1. Découverte SSDP -->  Pour les OS Anglais (SSDP Discovery)
2. Hôte de périphérique UPNP -->  Pour les OS Anglais (UPnP Device Host)

Maintenant vous pouvez retourner dans "Panneau de configuration\Réseau et Internet\Centre Réseau et partage\Paramètres de partage avancés" et enfin activer la découverte de réseau, elle ne changera plus.

Qui n'a jamais été confronté à un conflit d'adresse IP dans son réseau?

Le plus énervant quand cela arrive c'est de déterminer qui a une IP fixe sur sa machine alors que l'ensemble du parc est censé être en DHCP.

Afin de se se faciliter la tâche et de ne pas devoir passer sur chaque poste voici un script qui va vous permettre de savoir quels postes sont éteints, quels postes sont en DHCP et surtout lesquels ne le sont pas et avec quelle adresse IP (ou plutôt l'ensemble des configurations de chaque carte réseau).

Les Outils :

Pour ce faire vous aurez besoin d'un fichier texte avec les informations suivantes:

• La première ligne doit s'appeler "Ordi"
• le reste du fichier contient le nom de vos machines

Exemple :

Dans mon cas le fichier s'appelle DHCP.txt (le nom sera réutilisé dans le Script)

Une fois que le fichier est créé passons à la seconde partie le script:

Dans votre cas il suffira de modifier les lignes:

• 3
• 10
• 17
• 18
• 19 

# Script pour détecter l'état des cartes réseaux

$CSV = "C:\Users\XXX\Documents\DHCP.txt"  # Ici on déclare le chemin d'accès au fichier créé plus tôt

# Import du fichier
Import-Csv -Path $CSV | ForEach-Object {

# Déclaration des variables
$Postes = $_.ordi
$Destination = "C:\Users\XXX\Documents\Audit\DHCP\$Postes.txt" # Attention Ici lorsque vous modifiez le chemin ne supprimez pas $Postes.txt

# Test de connexion afin de vérifier que le poste est démarré
If ((Test-connection $Postes -count 2 -Quiet) -eq "True") {

# Déclaration des variables
$Postes = $_.ordi
$Destination = "C:\Users\XXX\Documents\Audit\DHCP\$Postes.txt" # Attention Ici lorsque vous modifiez le chemin ne supprimez pas $Postes.txt
$Poste_DHCP = "C:\Users\XXX\Documents\Audit\OK.txt" # Ici on déclare le chemin et le fichier dans lequel seront inscrit les postes en DHCP
$Poste_Off = "C:\Users\XXX\Documents\Audit\NOK.txt" # Ici on déclare le chemin et le fichier dans lequel seront inscrit les postes éteints

# Récupération des paramètres de la ou des cartes réseaux
Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Postes | ForEach-Object {
$IP = $_.IPAddress
$DHCP = $_.DHCPEnabled
if (($DHCP -eq $False) -and ($IP -ne $null)) {Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Postes | Select-Object -Property ServiceName,Description,DHCPEnabled,IPEnabled,IPAddress | fl | Out-File $Destination}
Elseif (($DHCP -eq $True) -and ($IP -ne $null)) {Write-Output "Le poste $Postes est en DHCP" | Add-Content -Path $Poste_DHCP}
}
}
Else {
Write-Output "Le poste $Postes est éteint" | Add-Content -Path $Poste_Off
}}

En espérant que cela vous servira.