Étiquette : ActiveDirectory

Pas de commentaire

Désactivation de OneDrive via GPO

  de

Petite problématique du jour, désactiver proprement OneDrive sur les stations du domaine via GPO. Rien de bien difficile, tout est déjà prévu dans les politiques pour désactiver le composant OneDrive sur des OS Windows 7 ou plus récents.

Tout d’abord, création d’un groupe d’ordinateurs dans l’ActiveDirectory ; à terme il faudra cibler tous les postes et donc un filtre par défaut suffira une fois la GPO liée à l’OU comprenant les stations, mais étant donné qu’au départ il s’agit d’un pilote, le plus simple était de créer un groupe et d’ajouter dedans petit à petit les stations concernées par la GPO et utiliser le groupe comme filtre.

Les paramètres concernant OneDrive se trouvent dans Computer > Policies > Administrative Templates > Windows Components > OneDrive :

Il suffit d’activer l’option visant à empêcher l’utilisation de OneDrive pour le stockage de fichiers.

Ensuite, lier la GPO sur l’OU concernée ; attention, en utilisant en filtre un groupe d’ordinateurs, il faut lier la GPO sur l’OU englobant toutes les stations concernées, sans quoi la politique ne redescendra pas sur lesdites stations.

Un gpupdate /force plus tard sur les stations visées par la GPO, on a bien disparition du lien OneDrive sur le bandeau de navigation sur la gauche et il est impossible pour certaines applications installées sur la machine de sauvegarder les données sur OneDrive ou même de les charger ; par ailleurs un appel de l’application OneDrive ne donne rien.

Avant.
Après.
Pas de commentaire

Powershell : liste des homedirs orphelins V2

  de

J’avais présenté dans un précédent article un script Powershell permettant de lister les homedirs orphelins, c’est à dire les homedirs dont le compte AD lié n’existe plus. Celui-ci se basait sur une vérification du nom du répertoire et testait la corrélation avec un utilisateur existant dans l’AD. Rapide mais peu robuste car un utilisateur changeant d’identifiant déjoue le script.

J’ai donc réalisé une v2 de ce script, en utilisant cette fois-ci l’instruction Get-Acl pour récupérer le propriétaire des répertoires. Chaque homedir possède en propriétaire un SID qui renvoie vers un utilisateur local ou du domaine. Si l’utilisateur du domaine est supprimé, alors le SID disparaît de l’annuaire… mais reste référencé en tant que propriétaire du homedir, comme on peut le voir sur cette capture d’écran du répertoire avec la colonne Owner affichée :

comptetest sur DOMAIN existe toujours par contre les comptes propriétaires des autres répertoires ont été supprimés de l’AD car Windows ne fait pas le lien entre le SID enregistré et un SID existant dans l’annuaire.      

Le script commenté est disponible en fin d’article et est prêt à être adapté à n’importe quel environnement.

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

Write-Host "Orphan homedir listing script V2"
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 "Checking directories ACLs"
foreach ($folder in $folderlist) {
$folderFullPath = $homedirpath+$folder.Name
$prop = Get-Acl $folderFullPath
if ($prop.Owner.Contains("S-1-5-21")) { noexist }
}
}
Write-Host "Please find in orphan-homedir.log the list of homedirs that don't have any linked AD account."
Write-Host "Bye"
Télécharger
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

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.