Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Suppression d’items antérieurs à X jours en Powershell

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.

 

image

 

Sur un total de 114 items

 

image

 

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

Réplication DFS-R & contraintes d’utilisation

Contexte

Lors de l’utilisation d’un partage réseau, les utilisateurs on souvent l’habitude de travailler directement sur les fichiers partagés.

Afin d’éviter toute corruption des données, un système de verrouillage est utilisé, il garantie que seul un unique utilisateur n’édite le fichier. Ce système fonctionne avec les fichiers temporaire/propriétaire.

Voici les étapes d’ouverture et d’enregistrement pour un fichier Word :

1. A l’ouverture du fichier, Word crée un fichier temporaire où les modifications seront enregistrés. Si un autre utilisateur tente de modifier le fichier, le message d’erreur suivant lui apparait :

Ce fichier est déjà ouvert par <nom_utilisateur>. Souhaitez-vous en faire une copie ?

2.  Lors de l’enregistrement du fichier, Word supprime la version d’origine, et la remplace par le fichier temporaire qu’il a renommé comme le fichier d’origine.

Ainsi, plusieurs utilisateurs auront accès au même fichier sans que celui-ci ne soit corrompu.

Contraintes en mode répliqué

Dans le cas d’un partage de fichiers répliqué, l’intégrité des fichiers n’est plus assurée.

Prenons le scénario suivant :

image

Dans ce cas de figure les utilisateurs sont redirigés depuis le namespace vers l’un des deux serveurs de données. En fonction de l’ordre “Refferal Ordering” qui par défaut dirige les clients entre les deux serveurs de manière égale.

Or si un utilisateur modifie le fichier work.docx sur le serveur FILE01, le serveur FILE02 n’en seras pas avisé (la fonction de verrouillage de fichier étant locale) et un autre utilisateur seras en mesure de modifier le même fichier causant une perte d’intégrité où le dernier fichier enregistré sera celui gardé par les deux serveurs.

Afin d’éviter ce type de comportement dangereux, il est possible de modifier le fonctionnement des deux serveurs, tout en gardant un minimum de répartition de charge.

Contournement

Imaginons que les serveurs FILE01 et FILE02 hébergent chacun deux fichiers répliqués indépendamment, Commerce et Administratif.

La première chose à faire est de forcer les clients à n’accéder qu’à un seul des deux serveurs, le serveur secondaire seras utilisé dans le cas où le premier venait à ne plus fonctionner.

Pour ce faire il faut dans la partie “Folder Targets” du namespace Commerce choisir le dossier hébergé par le serveur secondaire (FILE02), ouvrir la fenêtre des propriété puis choisir l’onglet “Advanced” et affecter à ce dossier la priorité “Last among all targets” :

image

Ainsi les utilisateurs souhaitant accéder au partage Commerce, seront toujours dirigé vers FILE01 en priorité.

On peut également aller plus loin et interdire la modification des fichiers sur l’un des serveurs le rendant membre “Read-Only”. La réplication ne fonctionneras alors que dans un sens et le serveur Read-Only, comme son nom l’indique ne pourras qu’afficher les fichiers hébergé en lecture seule.

Pour appliquer le Read-Only sur le serveur secondaire, choisir dans la partie “Replication” le lien de réplication, et dans l’onglet “Membership” sélectionner le serveur membre secondaire comme ceci :

image

Conclusion

A l’aide de ce contournement les utilisateurs Administratif utiliserons un serveurs tandis que les utilisateurs Commerciaux en utiliseront un autre.

Les deux serveurs sont malgré tout répliqués donc en cas de défaillance de l’un, l’autre pourras prendre le relais, cependant, il ne faut pas oublier – en cas de défaillance du serveur principal – de retirer l’option “Read-Only” si celle-ci a été mise en place.