Auteur/autrice : Enguerrand

Pas de commentaire

Powershell : liste des homedirs orphelins

  de

Afin de libérer un peu d’espace disques sur les serveurs de fichiers portant les homedirs, j’ai développé un script lisant dans un fichier les serveurs de fichiers hébergeant des homedirs, récupérant les noms des répertoires, puis faisant une comparaison entre chaque nom de répertoire et un utilisateur AD. Si l’utilisateur AD est introuvable, cela signifie selon toute vraisemblance que l’utilisateur n’existe plus, et que le homedir peut donc être détruit. Le script exporte enfin vers un fichier texte la liste des homedir orphelins détectés sur chaque serveur.

function noexist{
    Write-Host "Homedir $username doesn't have any owner."
    Add-Content -path "orphan-homedir.log" -Force -Value $username
}


Write-Host "Orphan homedir listing script"
Write-Host "============================="
Write-Host ""
Clear-Content -path "orphan-homedir.log" -Force
for ($Line = 15; $Line -gt 0; $Line--) {
    $RemoteServer = (Get-Content C:\homedir-srv-list.txt -TotalCount 15)[-$Line]
    Write-Host "Building user homedir list on $RemoteServer"
    $HomedirPath = "\\"+$RemoteServer+"\c$\homedir"
    Add-Content -path "orphan-homedir.log" -Force -Value "`r`n$RemoteServer`r`n========"
    $folderlist = Get-ChildItem $HomedirPath | select name
    Write-Host "Compairing homedir list to AD user list"
    foreach ($name in $folderlist) {
        $username = $name.Name   
        Try { $aduser = Get-ADUser $username }
        Catch { noexist }
    }
}
Write-Host "Please find in orphan-homedir.log the list of homedirs that don't have any linked AD account."
Write-Host "Bye"

Il ne reste donc plus qu’à adapter les variables en fonction de l’environnement sur lequel le script est exécuté. Le script doit être exécuté sur un contrôleur de domaine ou une station ayant les outils Powershell ActiveDirectory, ainsi qu’avec un compte utilisateur pouvant parcourir les répertoires administratifs des serveurs.

Télécharger
Pas de commentaire

Configuration d’OpenVPN pour accéder aux autres machines du réseau

  de

Pour des raisons de sécurité, j’applique des filtres IP sur les principaux points d’entrée de mon cloud, avec un serveur ouvert vers l’extérieur qui sert de passerelle vers le réseau interne. Ayant installé OpenVPN pour d’autres usages, je me suis dit qu’il ne serait pas idiot de se servir d’OpenVPN pour accéder au réseau local et donc accéder aux machines de mon réseau cloud sur ma station personnelle, ce qui fait que peu importe mon emplacement, je suis toujours sur une IP acceptée par les différents services et accès de ma plateforme.

Pour ce faire, il suffit tout simplement d’aller dans les propriétés d’un utilisateur OpenVPN, et d’autoriser cet utilisateur à accéder à d’autres sous-réseaux :
Il reste donc à saisir par exemple 172.21.1.0/24 si les machines auxquelles on souhaite accéder sont sur ce sous-réseau.
Une fois la configuration appliquée, un simple ping permet de vérifier les machines du réseau local répondent, et on peut même s’y connecter directement, car étant sur le réseau local, nous ne sommes plus concernés par d’éventuelles règles NAT appliquées sur l’interface physique du serveur.
Ainsi, sur chacun de mes serveurs GNU/Linux, mon fichier /etc/hosts.allow est comme ceci :

sshd : 12.34.56.78 : allow
sshd : 12.34.56.79 : allow
sshd : ALL : deny

La machine est donc accessible uniquement via SSH par le serveur qui fait office de passerelle, soit par le VPN.

Dans le cadre d’un usage du bureau à distance sur une VM Windows, on peut filtrer grâce aux règles de pare-feu et aux étendues :

Je peux donc laisser plus sereinement ma VM Windows ouverte en TSE car elle rejettera systématiquement ce qui ne provient pas de mon réseau local.

Pas de commentaire

VMware et Powershell : liste des alarmes déclenchées sur les hôtes physiques et VM

  de

J’ai développé rapidement sur un coin de bureau un script pour lister les alarmes déclenchées sur les hôtes ESX et les machines virtuelles portées par ces hôtes, car à ma grande surprise, PowerCli ne possède pas de commande permettant de les obtenir directement. Il faut donc ruser un peu et utiliser les vues d’ensemble de machines virtuelles et physiques pour récupérer leur état et ensuite afficher les alarmes en lien. Ce script a été développé et testé avec PowerCli 6.5 ; à noter que depuis la version 6, ce ne sont plus des SnapIn mais des modules (source), il faudra donc adapter le début du script si jamais la version exécutée fonctionne avec des SnapIn.

Import-Module VMware.VimAutomation.Core
$ESXI = Read-Host "vSphere vCenter server to connect to"
Connect-VIServer $ESXI
Write-Host ""
Write-Host "Collecting virtual machines list..."
Write-Host ""
$VMArrayList = Get-VM
foreach ($VM in $VMArrayList)
{
$VMView = Get-View -ViewType VirtualMachine -Filter @{"Name" = "$VM"}
if ($VMView.TriggeredAlarmState.Overallstatus -eq "red")
{
foreach ($VMAlarm in $VMView.TriggeredAlarmState)
{
$VMAlarmType = $VMView.TriggeredAlarmState.Alarm
$VMAlarmTime = $VMView.TriggeredAlarmState.Time
$VMAlarm = Get-AlarmDefinition -id $VMAlarmType
Write-Host "Virtual Machine: $VM"
Write-Host "Alarm: $VMAlarm"
Write-Host "Time: $VMAlarmTime"
Write-Host ""
}
}
}
Write-Host "Done!"
Write-Host "Now collecting physical hosts list..."
Write-Host ""
$HostArrayList = Get-VMHost
foreach ($HostSys in $HostArrayList)
{
$HostView = Get-View -ViewType HostSystem -Filter @{"Name" = "$Host"}
if ($HostView.TriggeredAlarmState.Overallstatus -eq "red")
{
foreach ($HostAlarm in $HostView.TriggeredAlarmState)
{
$HostAlarmType = $HostView.TriggeredAlarmState.Alarm
$HostAlarmTime = $HostView.TriggeredAlarmState.Time
$HostAlarm = Get-AlarmDefinition -id $HostAlarmType
Write-Host "Host: $Hostsys"
Write-Host "Alarm: $HostAlarm"
Write-Host "Time: $HostAlarmTime"
Write-Host ""
}
}
}
Write-Host "Done!"
Télécharger
Pas de commentaire

Un serveur d’un pool DFSR n’est plus synchronisé avec les autres

  de

J’ai rencontré depuis quelques temps des soucis par rapport à un
partage réseau porté par DFSR sur 4 serveurs 2008 R2. Tout d’abord, un premier
dysfonctionnement concernant le Staging Quota plutôt simple à résoudre, et
ensuite un des 4 serveurs qui n’était plus synchronisé avec les 3 autres,
résultant en des différences notables entre les répertoires et les fichiers.

Tout d’abord, la résolution du Staging Quota et une
rapide explication de ce que c’est. Il s’agit d’un espace dont a besoin DFSR
pour opérer proprement la réplication, en fait DFSR s’en sert comme file
d’attente par rapport aux changements qui vont être propagés par la suite sur
tout le pool. La préconisation de Microsoft (voir ce
lien) est d’avoir une taille au minimum équivalente aux 32 plus gros
fichiers du partage répliqué. DFSR fait régulièrement du nettoyage dans cette
file d’attente mais il se peut qu’avec la croissance du partage, le Staging
Quota décidé au départ ne soit pas suffisant. Cette alerte est remontée
dans le journal d’événements (Source : DFSR, Event ID : 4206). J’ai donc
dû l’agrandir ; rien de complexe, cela peut être réalisé en pleine journée car
cela ne nécessite pas de redémarrer le service DFSR. 
Dans dfsmgmt.msc (ou via le Server Manager), on
déroule les réplications, puis en sélectionnant celle qui nous intéresse, on
aura les partages et les serveurs qui constituent ce pool.

L’accès au réglage du Staging Pool s’obtient avec un simple
clic-droit sur le partage, puis Staging.

Maintenant que ce problème est réglé, j’ai réalisé quelques tests
pour d’abord confirmer que le serveur ayant un nombre incohérent de fichiers
dans son partage par rapport aux autres était bien désynchronisé. Un simple
fichier unique créé chacun des 4 serveurs s’est retrouvé propagé sur tous les
autres… sauf un, et celui placé sur le serveur hors synchronisation ne s’est
pas propagé, ce qui signifie que le serveur est désynchronisé à la fois en
envoi comme en réception. Dans la suite de l’exemple, je vais appeler D le serveur
désynchronisé et S le serveur lié qui est en bon état de marche.

D et S sont
deux serveurs Windows 2008 R2 hébergeant un partage DFSR nommé partage ; D et S
doivent avoir les mêmes fichiers (sauf .BAK, .TMP et fichiers commençant par
une tilde car non répliqués par DFSR) et l’un et l’autre opèrent les
transactions en envoi comme en réception. J’ai vérifié si des fichiers
étaient programmés en envoi ou en réception avec cette instruction :

dfsrdiag ReplicationState

Rien. Je vérifie si il reste des fichiers en attente de synchronisation, autrement appelés backlog :

dfsrdiag backlog /SendingMember:D /ReceivingMember:S /RGName:partage
/RFName:partage

Et en effet, de nombreux fichiers étaient en attente de synchronisation, et dans les deux sens ; un état des lieux des fichiers a confirmé cette différence.

Il a donc été décidé de procéder à la suppression et
recréation des liens du serveur D au niveau DFSR. Tout d’abord, on procèdera à
la désactivation du partage dans la console DFS avant de procéder à sa suppression.

En choisissant la première option, non seulement on indique
que l’on ne souhaite plus que le serveur D ne se réplique plus, mais en plus,
on supprime ses liens avec le serveur S (ou le reste du pool, le cas échéant).
En choisissant la deuxième option, on pourrait toujours tomber sur le serveur D
en appelant le partage, ce qui n’est pas souhaitable.
Une fois la suppression effectuée, on procède au rajout de D
comme membre du pool DFS aux côtés de S, en prenant bien soin d’y appliquer les
mêmes paramètres. Rien de complexe, je lie le serveur D à S (qui lui-même peut
être relié à d’autres serveurs du pool), dans les deux sens (envoi et
réception). Quelques captures d’écran du wizard à titre d’exemple :

Un petit tour dans le journal d’événements de S m’indique
qu’il arrête la communication avec son partenaire D à cause d’une erreur
(Source : DFSR, Event ID : 5014).
Je dois donc attendre la réplication entre les ActiveDirectory pour qu’ils enregistrent tous la suppression du membre et son retour dans le pool. Ensuite, cette instruction exécutée sur D et S me permet de les forcer à bien actualiser les informations DFSR afin qu’ils soient totalement à jour.

dfsrdiag pollad

Tout ça, pour rien. Toujours pas une trace de
synchronisation entre D et S. Et dans le journal d’événements de D, je trouve une entrée
m’indiquant qu’il communique bien avec S ; mais ce n’est pas réciproque puisque
S me dit que D n’est plus membre du pool DFS. Je décide donc de regarder au
niveau ActiveDirectory pour voir si je peux y trouver les paramètres DFS. Le
journal d’évènements permet de savoir avec quel DC les serveurs communiquent (Event
ID : 1206).
Un petit coup d’ADSI Edit sur chaque DC sur lequel un
serveur est connecté permet d’en savoir plus : les informations propres à DFSR
se trouvent dans l’objet du serveur. Les réplications sont bonnes car les mêmes
objets sont disponibles sur le DC où D et S sont connectés. A noter que cette
référence au DC ne change que lorsque le service DFSR démarre ; si le DC en
question est arrêté ou supprimé, il faut redémarrer le service DFSR pour que la
prise en compte soit effective et cela peut occasionner des désynchronisations
si ce n’est pas fait.

 

Par acquis de conscience, je vérifie tout de même mes
réplications : repadmin /showrepl * ne me renvoie rien de particulier, toutes
les réplications sont valides et datent de 30 minutes tout au plus. Par ailleurs, le bilan de santé effectué à partir de la
console d’administration DFSR m’indique toujours le même message : « This member is
waiting for initial replication for replicated folder partage and is not
currently participating in replication. This delay can occur because the member is waiting for the DFS
Replication service to retrieve replication settings from Active Directory Domain
Services. After the member detects that it is part of replication group, the
member will begin initial replication.« 
Il est possible d’avoir ce message lorsqu’il n’y a plus de
membre primaire sur le pool DFS ; le membre principal étant celui qui sert
de maître par rapport aux fichiers et qui écrasera les autres lors de la
réplication initiale seulement. Je ne trouve aucune trace dans les journaux
d’évènements (Event ID à chercher : 4002 puis 4112). Je décide alors de
faire du serveur DFS principal le membre primaire :
dfsradmin
Membership Set /RGname:partage /RFName:partage /MemName:ServPrim
/IsPrimary:True

Je force une réplication sur tous les contrôleurs de domaine
afin que l’information se propage sur tous les sites et ensuite je demande aux
serveurs DFS de requêter l’AD pour obtenir le nouveau serveur primaire. Toujours pas mieux.

Finalement, j’ai décidé de supprimer complètement mon partage DFSR, liens et namespace et je l’ai recréé de zéro : les serveurs se synchronisent désormais proprement.