L’interface réagit aux clics.
Pour sélectionner du texte, on peut faire Maj+clic puis copier avec Ctrl-Maj-C.

Pour rafraîchir, Ctrl-L
Pour figer l’affichage, Maj+Z. Idem pour dé-figer.

On verra + d’infos en utilisant sudo htop .

Threads

Par défaut, htop montre tous les threads descendants d’un processus parent.
Si on souhaite ne voir que les processus parents, on peut utiliser le raccourci H (en majuscule), ou bien aller dans le Setup -> Display -> Hide userland process threads.
Directive dans le fichier de conf :
hide_userland_threads=1

Setup

Avec F2, on peut personnaliser l’affichage.

Ce setup peut être enregistré dans un fichier ${HOME}/.config/htop/htoprc .
Pour ceci, il faut quitter htop avec F10 ; si on fait Ctrl+C ou Q ça n’enregistre pas la config.
Si F10 ouvre un menu de l’émulateur de terminal, on peut soit désactiver ce raccourci dans les options du terminal, soit cliquer sur Exit.

La catégorie “Meters” concerne la partie avec les graphs, moitié haute du terminal.

La catégorie “Screens” concerne la partie inférieure du terminal, qui liste les processus.
En colonne pratique, il y a M_SWAP pour voir l’utilisation du swap.
M_PSSWP ?

Update 10 years anniversary de ce post

Il faut avoir l’iso de la version de Windows que l’on souhaite installer.

Principe

UEFI:NTFS, du créateur de Rufus, est un petit bootloader efi qui arrive à chainloader un exécutable efi sur une partition NTFS.
On va l’utiliser pour avoir une partition principale en NTFS, et pouvoir mettre les install.wim qui dépassent les 4Go.

En cas de boot en mode EFI, c’est UEFI:NTFS qui est lancé et qui lance aussitôt l’installeur Windows depuis la partition NTFS.
(certaines cartes-mères peuvent être capables de booter directement la partition NTFS, mais ce n’est pas toujours le cas)

En cas de boot en mode BIOS, le secteur de démarrage de l’installeur Windows aura été écrit sur le MBR de la clé USB ; il est capable de lancer directement l’installeur Windows depuis la partition NTFS. UEFI-NTFS n’intervient pas du tout.

Préparation de la clé

Il faut télécharger UEFI-NTFS sur le github du projet
Prendre “uefi-ntfs.img” et extraire le contenu pour plus tard.

Il faut une clé USB en table de partition MBR. Plus elle a de capacité, plus on pourra stocker de versions Windows dessus.

Faire une 1ère partition qui prend quasiment tout sauf 100 Mo (voire 10 Mo).
On la formate en NTFS et on lui met le drapeau boot (servira pour le boot en mode BIOS).
On y copie tout le contenu de l’iso Windows de la version de notre choix (attention, Win 7 nécessite des bidouilles pour faire fonctionner le boot efi).

Faire une 2e partition en FAT32, avec le drapeau “esp” (pas sûr que ce soit nécessaire).
Copier dessus le contenu de “uefi-ntfs.img”.

Enfin, brancher la clé sur un Windows 8.1 ou + récent, et mettre le secteur du boot sur le MBR de la clé (remplacer X: par la lettre de la partition NTFS) :
X:\boot\bootsect.exe /nt60 X: /mbr

Sélection du Windows à installer

Le mécanisme de démarrage (BIOS ou EFI) des installeurs Windows étant le même pour toutes les versions, il suffit de copier tous les fichiers de la version désirée à la racine de la partition NTFS.

Pour un switch rapide d’une version à l’autre, on peut copier tous les fichiers d’install dans un dossier indiquant les caractéristiques de la version, par exemple “10_22H2_64”.
Il y’a à juste à sortir ces fichiers vers la racine pour installer cette version (après avoir rangé la précédente version installée dans son propre dossier).

Chaque version de Windows pourrait avoir besoin de son ei.cfg (ou de son absence).

Propriétaire

Le propriétaire d’un appareil a certaines possibilités en +, comme gérer les applications dans le Portail d’entreprise.

On peut modifier ou supprimer ce propriétaire :
Intune -> Appareils -> Tous les appareils -> choisir l'appareil -> Propriétés -> Changer (ou Supprimer) l'utilisateur principal

Si aucun propriétaire n’est affecté à un ordi, il sera considéré comme un ordi partagé.

Groupes locaux

Il est possible d’ajouter automatiquement un/des utilisateurs à un groupe local du poste sur lequel ils se connectent.
Ceci peut par exemple servir à accorder automatiquement le droit de se connecter en RDP à un poste.

Intune -> Endpoint Security -> Manage -> Account Protection  
Create Policy -> Local user group membership

On y choisit le groupe local auquel appartiendront les utilisateurs.
On y affecte les utilisateurs/groupes concernés.
Enfin, on assigne les groupes/postes sur lesquels ce paramétrage sera effectif.

Admin locaux

Il est possible d’utiliser ce mécanisme pour ajouter les utilisateurs au groupe “Administrateurs”. Ceci permet une certaine granularité dans cette affectation (choix des postes).

Mais si on souhaite qu’un utilisateur soit systématiquement admin, sur tous les postes, on peut utiliser les rôles Entra pour ça, et ajouter l’utilisateur au rôle “Microsoft Entra Joined Device Local Administrator”.

Office

intune-configs-office.html

Installation d’applications

Installs MSI

https://www.it-connect.fr/intune-comment-deployer-une-application-au-format-msi/

Télécharger le fichier MSI.
Identifier le paramètre d’installation silencieuse en lançant my-installer.msi /?.
Par exemple, pour 7zip, c’est /quiet.

Aller sur le portail Intune -> Applications -> Windows puis Créer.
Type : application métier
Choisir le fichier MSI précédemment téléchargé
Renseigner un “Nom de l’éditeur” (par exemple 7-zip)
Choisir un contexte d’installation (uniquement la session de l’utilisateur, ou bien au niveau de la machine) ; parfois cette option n’est pas dispo
“Ignorer la version de l’application” permet d’installer les applications qui se mettront à jour toutes seules (ex : Firefox, Chrome…)
On place le flag silencieux dans “Arguments de ligne de commande”

Dans l’écran suivant, on choisit les affectations souhaitées.
“Obligatoire” signifie que l’appli sera forcément installée.
“Disponible” signifie que l’appli est disponible dans le “Portail d’entreprise” pour que les utilisateurs qui le désirent puissent l’installer.
“Désinstaller” sert à forcer la désinstallation de l’appli.

Quelques (dizaines de) minutes après la validation, l’appli devrait se retrouver sur les postes.

Win32 apps

Permet de déployer tout type de programme personnalisé, notamment des .exe et des scripts.
Doit être packagé en un fichier .intunewin. Ceci se fait avec IntuneWinAppUtil.

Création du fichier .intunewin

On met tous les fichiers nécessaires dans un dossier, par exemple .\0-Input.
Il faut spécifier un fichier, qui est celui qui sera exécuté, c’est le “setup file”.
On spécifie un dossier de sortie qui stockera le fichier résultant.

\IntuneWinAppUtil.exe -c <setup_folder> -s <setup_file> -o <output_folder>

typiquement
\IntuneWinAppUtil.exe -c .\0-Input -s .\Install.ps1 -o .\1-Output

Création du déploiement

Dans le centre d’admin Intune, aller dans Apps -> Windows -> Create -> Windows apps (Win32)
Définir un nom, une description, un éditeur.

Il faut alors définir la commande à lancer. Ici, on lance un script Powershell, donc on met :
%windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe -Executionpolicy Bypass .\MyScript.ps1

En commande désinstallation, on met
%windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe -Executionpolicy Bypass .\Uninstall.ps1

Les règles de détection permettent au système de savoir que l’application a été installée.
Il est obligatoire d’en préciser au moins une.
En ce cas, comme on modifie le registre, on vérifie l’existence d’une ruche.
On définit le chemin à rechercher (par exemple HKEY_CURRENT_USER\SOFTWARE\0_TEST).

Scripts

Remediations

https://learn.microsoft.com/fr-fr/intune/intune-service/fundamentals/remediations

Nécessite une licence Windows Enterprise (standalone, ou incluse dans Microsoft 365 F3, E3 ou E5)

Définition automatique du domaine de connexion

Permet de n’avoir besoin de taper que “user” sur l’écran de connexion Windows, plutôt que “user@mondomaine.com”.
Note : taper uniquement “user” semble fonctionner si le profil a déjà été créé.
Mais pour une première ouverture, il faut taper l’UPN complet.

Pour éviter ça, on peut définir un domaine par défaut, qui sera appelé si on ne tape pas de “@mondomaine.com”.

Intune -> Appareils -> Configuration -> Créer -> Nouvelle stratégie
Win 10 et ultérieurs -> Modèle -> Restrictions d’appareil
Nommer la configuration
Section “Mot de passe” -> “Domaine de locataire Microsoft Entra préféré”
entrer mondomaine.com

Affecter les postes souhaités.
On peut laisser vide “Régles d’applicabilité”.

Une fois appliqué, on verra (entre autres) la clé de registre HKLM\SOFTWARE\Policies\Microsoft\AzureAdAccount et la valeur PrefferedTenantDomainName.

Si on souhaite se connecter sur le poste avec un utilisateur local, on peut utiliser la syntaxe
.\admin

RDP

Si on essaye d’accéder en RDP à un poste qui n’est pas joint à Entra, et qui n’a qu’un utilisateur local (par exemple admin), le domaine de connexion sera automatiquement ajouté au username entré, soit admin@mondomaine.com, ce qui ne fonctionnera pas. Pour éviter ceci, on peut utiliser la syntaxe
remotecomputer\admin
Mais ceci nécessite de connaître et taper le hostname du poste distant, ce qui n’est pas commode. Essayer en ce cas la syntaxe
local\admin
(voir si ça fonctionne ?)
ou .\user ?

Suppression

Selon mes tests, il suffit d’arrêter d’appliquer la stratégie, et le paramétrage finit par disparaître du poste.
Mais ce post indique quelques entrées de registre si ceci ne suffisait pas :
https://community.spiceworks.com/t/removing-preferred-aad-tenant-domain-name/933841/2

Config de Windows Hello

Windows Hello Entreprise -> Utiliser Windows Hello for business (utilisateurs)

Windows Hello Entreprise -> Utiliser Windows Hello pour les entreprises (appareils)

Windows Hello peut aussi être complètement désactivée au niveau du tenant

Afficher une liste d’utilisateurs sur l’écran de connexion

Devices -> Configuration profile
Settings Catalog
Chercher
“Enumerate local users on domain-joined computers”
L’appliquer au niveau du poste.

Map drives

Je vois 2 méthodes qui fonctionnent : l’import de modèles ADMX, et un script Powershell.

ADMX

Avec les modèles ADMX, le lecteur réseau sera créé, même si le chemin réseau est introuvable (pratique pour être sûr que le lecteur est créé, même en l’absence de connectivité vers le serveur).
Par contre, si le lecteur est déconnecté, il ne sera plus jamais connecté automatiquement ; le paramétrage s’applique une seule fois (par utilisateur par poste).

Script Powershell

Il est facile de monter un lecteur réseau via script Powershell, mais la difficulté est de le faire exécuter automatiquement, sans action de l’utilisateur.
Pour ceci, ce site génère un script qui, si il est lancé hors du contexte utilisateur (donc en user “SYSTEM”), va créer une tâche planifiée qui s’applique à tous les utilisateurs, lors de leur logon.
Ceci fonctionne très bien si la ressource partagée est accessible dès le logon.

Dans le cas où on a besoin d’un VPN pour accéder à la ressource partagée, il faut relancer la tâche planifiée après connexion du VPN.
Pour éviter aux utilisateurs de chercher les tâches planifiées, il est possible de définir un 2nd déclencheur, par exemple le verrouillage de session.
J’ai trouvé la syntaxe grâce à ce post et j’ai rajouté/modifié ce bloc dans le script :

    $stateChangeTrigger = Get-CimClass -Namespace ROOT\Microsoft\Windows\TaskScheduler -ClassName MSFT_TaskSessionStateChangeTrigger
    $onLockTrigger = New-CimInstance -CimClass $stateChangeTrigger -Property @{
        StateChange = 7  # TASK_SESSION_STATE_CHANGE_TYPE.TASK_SESSION_LOCK (taskschd.h)
    } -ClientOnly
    
    $atLogonTrigger = New-ScheduledTaskTrigger -AtLogOn
    
    $triggers = @( $atlogonTrigger, $onLockTrigger )
    
    [...]
    
    $null = Register-ScheduledTask -TaskName $schtaskName -Trigger $triggers  [...]

Pour trouver les valeurs à utiliser, on peut configurer une tâche planifiée manuellement, via la GUI, puis chercher ses détails via PS :

# On récupère la tâche dans un objet
$task = Get-ScheduledTask "MyTaskName"

# Vue très simplifiée de la tâche
$task

# Vue plus détaillée
$task | select-object *

# Vue des déclencheurs
$task.Triggers
 

PC partagé

PC partagé ->

LAPS

https://learn.microsoft.com/en-us/intune/intune-service/protect/windows-laps-overview
https://learn.microsoft.com/en-us/intune/intune-service/protect/windows-laps-policy

https://www.it-connect.fr/tuto-intune-configuration-windows-laps/

Autoriser scripts Powershell

https://www.dmtt.blog/post/set-the-powershell-execution-policy-using-an-intune-configuration-profile

Appareils -> Configuration -> Nouvel élément
Modèles d’administration -> Composants Windows -> Windows Powershell -> Turn On script execution (existe aussi en version user)

Présentation

MDM = Mobile Device Management = GPM = Gestion des Périphériques Mobiles
-> administration centralisée des appareils (façon GPO)

Centre d’administration :
https://intune.microsoft.com

https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/how-it-pros-can-use-configuration-service-providers

Choix du MDM

Plusieurs possibilités pour la gestion des appareils :

• Intune (requiert licence Intune)
• Basic Mobility and Security (capacité d’aministration + restreintes,mais permet d’administrer les appareils dont les users n’ont que des licences Basic ou Standard)
• 3d party tools je suppose

Ce MDM se définit au niveau du tenant.
On peut voir le MDM actuel dans le centre d’admin Intune -> Administration de locataire -> Détails du locataire -> Autorité MDM
S’il est sur “Office 365 Mobile”, il faut le définir sur Intune.

On peut définir son MDM ici :
https://intune.microsoft.com/#view/Microsoft_Intune_Enrollment/ChooseMDMAuthorityBlade

Il apparaît alors comme Autorité MDM “Microsoft Intune”

https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/mdm-authority-set

Pour que les appareils appliquent les stratégies paramétrées sur Intune, ils doivent impérativement avoir “Intune” défini en MDM !

Basic Mobility and security

Si on souhaite juste utiliser la gestion gratuite

Il faut commencer par activer la gestion des appareils :
https://learn.microsoft.com/en-US/microsoft-365/admin/basic-mobility-security/set-up?view=o365-worldwide#activatemdm

Activate Basic Mobility and Security
https://compliance.microsoft.com/basicmobilityandsecurity

Dans Entra -> Appareils, on verra le MDM défini à “Office 365 Mobile”

Licences

Nécessaires pour utiliser Intune.
Licence incluse dans les abonnements E3, 365 Business Premium (PAS Standard), entre autres.
Possible de prendre une licence autonome (Microsoft Intune Plan 1, à 7.50€/mois)

https://learn.microsoft.com/en-us/mem/intune/fundamentals/licenses

Embarquement (enrollment) des appareils

https://learn.microsoft.com/fr-fr/windows/client-management/mdm-enrollment-of-windows-devices
https://www.toutwindows.com/blogtoutwindows/intune-details-dun-enrolement-windows/

Le rôle des manipulations suivantes est de faire gérer un appareil par Intune.

Pour s’assurer qu’un appareil est bien géré par Intune, on peut vérifier que :

• il apparaît bien dans Entra, section Appareils
• il est mentionné avec “Intune” comme GPM
• il apparaît dans le centre de gestion Intune

Si une des ces conditions n’est pas remplie, les configurations Intune ne s’appliqueront pas.

Comme d’hab, prévoir de patienter quelques (dizaines de) minutes pour que les changements soient reflétés sur la console d’admin web MS.

Inscription automatique

Nécessite une licence Entra ID P1 au minimum.
Contenue dans Business Premium.

https://learn.microsoft.com/fr-fr/intune/intune-service/enrollment/windows-enroll

Elle se configure soit dans Entra soit dans Intune.
Elle est définie selon les utilisateurs, et non les appareils.

Entra admin center -> Identité -> Paramètres -> Mobilité
De là, sélectionner “Intune”, et activer “Étendue de l’utilisateur Gestion des données de référence” (permet de sélectionner les utilisateurs pour lesquels sera activé l’inscription automatique Intune)
Par défaut c’est Aucun, mais on peut choisir “Tout le monde”, ou bien Partiel (une sélection de users/groupes)

C’est l’utilisateur qui fait la jonction initiale à Entra qui va définir l’enrollement automatique ou non.
Si on joint Entra avec un user SANS enrollment, puis qu’on se connecte avec un utilisateur AVEC enrollment, le poste ne sera pas joint à Intune pour autant. Il faut défaire la jonction (dsregcmd /debug /leave) puis la refaire en utilisant un utilisateur AVEC enrollment automatique.

Une fois l’enrollment réalisé, le poste reste connu d’Intune, même si les utilisateurs suivants n’ont pas d’enrollment automatique, ni même pas de licence Intune (mais en ce cas, les configurations ne seront pas appliquées).

Inscription manuelle

Pour embarquer manuellement un appareil Windows, il faut l’appli Company Portal (Portail d’Entreprise) télechargeable depuis le Store.

Il est nécessaire d’ajouter de 2 CNAME dans le DNS (enterpriseenrollment.company.com et enterpriseregistration.company.com ) pour permettre la découverte automatique des points de connexion
https://learn.microsoft.com/fr-fr/intune/intune-service/enrollment/windows-enrollment-create-cname

https://learn.microsoft.com/en-us/mem/intune/apps/store-apps-company-portal-app

Pour l’embarquement des appareils, il faudra ajouter le “Compte Professionnel ou scolaire” (ce qui enregistre l’appareil dans Entra), mais également le “Configurer pour une utilisation professionnelle”.
Une fois cette 2e étape réalisée, l’appareil sera mentionné avec le GPM “Office 365 Mobile” et apparaîtra dans Intune.
De plus, dans “Paramètres -> Comptes -> Accès Professionnel et scolaire”, il sera mentionné comme “Connecté à (nom de l’organisation)” (avec icône de serviette de travail).

Vérification/synchro

https://learn.microsoft.com/fr-fr/mem/intune/user-help/sync-your-device-manually-windows#next-steps

C’est un peu l’équivalent de “gpupdate /force”
Sous Win 10, aller dans Paramètres -> Comptes -> Accès Professionnel et Scolaire
Cliquer sur le GPM (icône de la mallette) puis Informations. On peut alors Synchroniser ou “Créer un rapport”

Sur la console d’admin intune, on peut aller dans Appareils -> Tous les appareils -> choisir le poste -> Configuration de l’appareil.
On y voit les différentes stratégies qui sont appliquées (avec succès ou erreur) sur l’appareil en question.

https://techcommunity.microsoft.com/t5/microsoft-intune/is-it-really-impossible-to-force-an-intune-sync-from-the-command/m-p/3818315

Logs

Observateur d’évenements (eventvwr.msc)
Journaux apps services -> Microsoft -> Windows -> DeviceManagement - Enterprise…

Le journal Admin donne des infos à chaque actualisation.

ADMX

Il est possible d’importer des fichiers .admx pour avoir leurs réglages disponibles dans Intune.

Il faut commencer par récupérer (ou créer) les fichier .admx en question.

Intune -> Appareils -> Gestion des appareils -> Configuration puis onglet Importer ADMX
Puis clic sur “+ Importer”
Choisir l’admx et l’adml

Il est possible que l’import échoue, notamment s’il fait référence à un autre admx absent. Par exemple, “Windows.admx” semble parfois nécessaire (notamment pour ajouter drivemapping.admx )

Une fois l’import réalisé, le fichier admw est disponible dans le même onglet “Import ADMX” , et en cliquant sur les 3 petis points au bout de la ligne, on peut le supprimer.

Utilisation

Appareils -> Stratégies -> Créer -> Nouvelle stratégie -> Modèle -> Modèles d’administration importés

Scripts

Sysnative

Windows intègre un mécanisme de redirection transparent qui fait que lorsqu’une application 32 bits demande à accéder à C:\Windows\System32, le système va en réalité écrire dans C:\Windows\SysWOW64. De même avec Program Files et Program Files (x86).
Ça permet un cloisonnement des architectures, mais ça pose un souci lorsque l’on veut qu’une application 32 bits accède au vrai répertoire System32 (typiquement pour installer un pilote).

Pour contourner ce problème, une autre redirection est mise en place : celle de C:\Windows\Sysnative vers le vrai C:\Windows\System32 .

Attention, ce lien Sysnative n’est visible que par les applications 32b ! Les applis 64b (dont l’explorer) ne le voient pas et ne peuvent pas y accéder.

Comme les scripts Intune sont exécutés dans un contexte 32b, si on souhaite accéder à System32 via ces scripts, il faut donc leur indiquer le chemin Sysnative.

https://www.samlogic.net/articles/sysnative-folder-64-bit-windows.htm
https://call4cloud.nl/sysnative-64-bit-ime-intune-syswow64-wow6432node/

Apps

https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/deployment-plan-protect-apps

Pare-feu

Endpoint Security -> Manage -> Firewall
Create policy -> Plateform : Windows -> Windows Firewall rules

On ajoute ensuite des Configuration Settings.
Le nom sera le nom donné à la règle dans le pare-feu.
On choisit Allow ou BLock, puis on fait Edit instance.
Dans les paramètres, il me semble indispensable de spécifier le protocole (6 pour TCP, 17 pour UDP, 1 pour ICMP4, 58 pour ICMPv6), sans quoi on a des messages d’erreur concernant d’autres champs.

Lien MS pour des infos sur les champs

Lorsqu’on valide la règle et qu’on l’affecte à un poste, un mécanisme de push peut immédiatement déclencher une actualisation du poste (en tout cas sous Win 11 24H2).

Vérification

Sur le poste client, on va dans “Pare-feu avec fonctions avancées” -> Analyse -> Pare-feu.
On y voit toutes les règles actuellement actives.
Attention, c’est le seul endroit où on voit les règles qui viennent d’Intune ; elles n’apparaissent par dans les “règles entrantes”.

Si la règle n’apparaît pas, diagnostiquer avec l’observateur d’events, chercher l’event 404 dans le journal Admin (voir ci-dessus pour le chemin).

truncate -s 20G ./file.dat

Le but est d’activer le Wake-on-Lan.
Testé sur un Dell Optiplex 3050 et une ASUS STRIX X570-F GAMING.

https://www.dell.com/support/kbdoc/en-uk/000129137/wake-on-lan-wol-troubleshooting-best-practices

Il faut bien sûr que le matériel supporte le WoL. C’est le cas de l’Optiplex 3050.
Il est nécessaire de paramétrer le BIOS, mais également le pilote sous l’OS que l’on utilise, car il va déterminer le comportement de la carte réseau à l’extinction de l’OS.

Attention, il arrive qu’un chip réseau supporte le WoL, et rapporte :

Supports Wake-on: pumbg
Wake-on: g

mais que la carte (implémentation vendeur) n’en soit en réalité pas capable !

De mon expérience, le paramétrage du WoL sur une carte fille PCIe est moins stable que sur la carte réseau intégrée à la carte-mère/chipset.

Paramétrage BIOS

Dell Optiplex 3050

J’ai commencé par faire une mise à jour du BIOS vers la version la plus récente, pour limiter les risques de bug logiciel du BIOS.
Vérifier les paramètres suivants :

• System configuration -> Integrated NIC -> Enabled
• Power Management -> Wake on LAN/WLAN -> Lan Only (ou autre réglage qui active sur le WoL sur le LAN)
• Power Management -> Deep Sleep control -> Disabled

À ce stade, normalement le WoL est actif. Il se voit par l’allumage d’une des 2 LEDs de la carte réseau.
On peut “réinitialiser” le statut WoL en débranchant électriquement le poste puis en le rebranchant. Il devrait s’allumer un court instant, puis s’éteindre, mais la LED du NIC doit rester allumée.

STRIX X570-F GAMING

Advanced -> APM Config -> Power On By PCI-E
Advanced -> Network Stack -> Enabled + IPv4 PXE Support : Enabled

Paramétrage Debian

Lorsqu’on éteint le poste via la commande sudo poweroff, la carte réseau s’éteint complètement, car l’OS peut contrôler son comportement à l’extinction.
Il faut donc lui dire de maintenir la carte en fonctionnement.

On commence par installer ethtool, qui permet de voir/gérer l’état des cartes réseau :
apt install ethtool

On définit la carte à gérer :
iface=ethX

et on peut consulter une carte avec :
sudo ethtool $iface ou
sudo ethtool $iface | grep -i Wake-on

et on a notamment les lignes :

Supports Wake-on: pumbg
Wake-on: d

Chaque lettre a une signification, trouvable dans man ethtool, et qui sont :

p   Wake on PHY activity
u   Wake on unicast messages
m   Wake on multicast messages
b   Wake on broadcast messages
a   Wake on ARP
g   Wake on MagicPacket™
s   Enable SecureOn™ password for MagicPacket™
f   Wake on filter(s)
d   Disable  (wake on nothing).  This option clears all previous options.

Le WoL implémenté généralement est le “MagicPacket™”, il faut donc avoir que la carte supporte “g”.

L’état “Wake-on” correspond à l’état actuel ; on voit ici qu’il est désactivé, donc si j’éteins le poste, la carte-réseau n’aura aucune LED allumée et il sera impossible de le rallmuer via WoL.
À ce stade, le WoL restera désactivé même si on va dans le bios, qu’on sauvegarde, qu’on ré-éteint le poste.
Il est nécessaire de débrancher/rebrancher électriquement le poste pour que le WoL recommence à fonctionner.

Pour activer le WoL, il faut entrer cette commande :
sudo ethtool -s $iface wol g

dont la réussite se voit dans la sortie de :
sudo ethtool $iface | grep -i Wake-on

Si on éteint le poste, le WoL restera activé.
Mais au prochain boot, le status WoL sera à nouveau défini sur d !

Il faut donc l’activer à chaque démarrage.
Des infos ici : https://wiki.debian.org/fr/WakeOnLan

Je passe par la méthode de création d’un service systemd : On peut créer le fichier de définition du service avec cette commande, à lancer en root :

if [ -z "$iface" ] ; then echo -e '\nIl faut définir la variable $iface !\n' ; else echo "[Unit]
Description=Configure Wake-up on LAN

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -s $iface wol g

[Install]
WantedBy=basic.target" > /etc/systemd/system/wol.service ; fi

On active le service au démarrage, ainsi qu’immédiatement, et on recharge le démon systemd :

sudo systemctl enable wol
sudo systemctl start wol
sudo systemctl daemon-reload

On doit normalement avoir “g” sur le paramètre “Wake-on” à chaque démarrage, et donc pouvoir éteindre le poste via poweroff en maintenant le status WoL actif.

Paramétrage Windows

https://www.dell.com/support/kbdoc/en-uk/000129137/wake-on-lan-wol-troubleshooting-best-practices

Gestionnaire de périph, aller dans les propriétés du NIC -> Power Management ->
Allow this device to wake the computer : coché
Only allow a magic packet to wake the computer : non coché

radvanced tab
Energy-Efficient Ethernet -> Disabled (pas indispensable ? )
Enable PME : Enabled

Obligatoire : Désactiver fastboot
Panneau de conf -> Options d’alimentation -> Choisir actions boutons -> Désactiver démarrage rapide
Ou bien powercfg -h off qui rend impossible le démarrage rapide.

Autres actions qui peuvent être nécessaires ?

Allumage à distance

On note l’adresse mac de la cible à réveiller :
distantmacaddr=00:11:22:33:44:55

Sous Debian il y a au moins 2 outils pour réveiller un poste via WoL :
sudo apt install etherwake wakeonlan

On peut utiliser etherwake, qui nécessite les droits root et de préciser explicitement l’interface qui envoie le paquet magique :
sudo etherwake -i ethX $distantmacaddr

ou bien wakeonlan :
wakeonlan $distantmacaddr

Consommation électrique

Sur l’Optiplex 3050, je constate environ 0.9W lorsque le poste est éteint avec WoL activé.

En phase de BIOS/démarrage, je constate environ 20W, et lorsque Debian est lancé mais sans aucune activité, je constate environ 9W.

En lançant quelques processus un peu gourmands en CPU/RAM/disque (mais sans être un test intensif non plus), je monte à 40W.

Installer utilitaires CLI

Centre de paquets -> Paramètres -> Sources de paquets
Ajouter une entrée, choisir un nom, et ajouter :
https://packages.synocommunity.com/
comme Emplacement.

L’actualisation devrait se faire tout seul, et on peut alors chercher synocli .
On a notamment les “Disk Tools” qui fournissent entre autres ncdu ; les “File Tools” qui fournissent entre autres nano ; les “Monitor Tools” qui fournissent entre autres iperf.

SSH et dossier home

Le SSH s’active dans
Panneau de configuration -> Terminal & SNMP

Si on veut pouvoir y accéder via SFTP, il faut l’activer dans
Panneau de conf -> Services de fichiers -> FTP -> SFTP

Enfin, si on veut pouvoir se connecter via clé SSH, il faut activer les dossiers homes. pour ceci :
Panneau de conf -> Utilisateurs et groupes -> Avancé -> Accueil utilisateur

Synchronisation du dossier partagé

Pour une synchronisation unidirectionnelle d’un Syno source vers un Syno destination.
Fonctionne à l’échelle d’un dossier partagé.
Lance rsync en sous-jacent, avec l’option --delete .

Sur le Syno destination, il faut aller dans
Panneau de conf -> Services de fichiers -> rsync
et activer le service rsync.

Sur le Syno source, il faut aller dans
Panneau de conf -> Services de fichiers -> Avancé
et trouver “Synchronisation du dossier partagé”.
Clic sur “Liste des tâches” et ajouter une tâche (tâche = transfert sortant).

Sur le Syno cible, dans le même menu, on voit l’état du serveur, et on a la possibilité de gérer la “Liste des connexions”, c’est à dire les transferts entrants.

Lorsque la tâche est lancée, la ligne de commande lancée est de ce genre :

/usr/bin/rsync --timeout=600 --verbose --progress --no-h -rlpt -go -H -W --one-file-system --syno-auth --syno-acl --syno-pseudo-root --numeric-ids --exclude-from=/tmp/EXCLUDE  /volume1/MONPARTAGE/ --rsync-path=rsync -e "/usr/bin/ssh -p 11122 -oNumberOfPasswordPrompts=1 -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oServerAliveInterval=10 -oServerAliveCountMax=60" -s raphael@10.0.10.89::Public/ --exclude=/*/#recycle/

et le fichier exclude contient ça :

/#recycle/***
/#snapshot/***
/@eaDir/SYNO@.fileindexdb/***
/@eaDir/SYNO@file_index_queue
/@eaDir/SYNO@file_index_queue.tmp
/@eaDir/SYNO@.fileindexdb@SynoEAStream
/@eaDir/@dedupedb/***

Types de synchro

Depuis le Syno source, si on va dans la section “Liste des tâches”, il y a un bouton pour “Synchroniser maintenant” et un bouton pour “Synchro complète”.

“Synchro maintenant” va faire une synchro très rapide, qui ne fait que copier les fichiers nouveaux/modifiés vers la destination. Pour ~ 20To de données en ~ 4 millions de fichiers, qui a déjà été complètement synchronisé 1h avant, cela met 2-3 minutes. Les fichiers de la destination absents de la source ne sont PAS supprimés.
C’est cette synchro qui est faite par la planification.

“Synchronisation complète” va mettre + de temps (environ 40 minutes pour le même volume de données) mais va créer un miroir complet des données, incluant la suppression des fichiers/dossiers de la destination qui sont absents de la source, ainsi que la réplication des permissions.

Permissions

Lorsque la synchro de dossier partagé est activée, les permissions avancées sont activées sur les partages de la destination ; si on veut que les utilisateurs puissent y acccéder, il faut les ajuster en conséquence (ou les désactiver).
Ça se règle dans le Panneau de config -> Dossiers partagés -> Modifier -> Permissions avancées

Synology Drive Server

Permet la syncho bidirectionnelle entre 2 Syno.

Hyperbackup

Restauration

La restauration d’un dossier partagé se fait en intégralité, sans tenir compte des données pré-existantes.

Lorsqu’on restaure, le contenu existant n’est pas effacé ; il faut d’abord supprimer/vider le partage de réception avant de restaurer Si le partage n’existe pas, il est automatiquement créé.

Spécificités Btrfs

Snapshots

Si le système de fichiers d’un dossier partagé est btrfs, on peut installer le paquet “Snapshot Replication”.
Celui-ci permet de gérer les instantanés. L’assistant est assez intuitif.

Pour un dossier partagé donné, si on coche la case “Rendre visible” (onglet Avancé), on peut accéder aux instantanés dans le dossier #snapshots à la racine du dossier partagé.
Ceci permet également d’activer la fonctionnalité des “Versions précédentes” dans l’explorateur Windows.

Si on veut analyser l’espace utilisé sur le dossier partagé avec ncdu, il faut penser à exclure ce dossier :
ncdu /volume1/MONPARTAGE --exclude "#snapshot*"

Réplication

Permet de dupliquer un dossier partagé vers un 2e NAS, par les commandes btrfs send et btrfs receive.
Si cette fonctionnalité est activée, un snapshot est créé à chaque réplication.

Par défaut, seul l’instantané généré lors de la réplication est répliqué.
Il est toutefois possible d’envoyer en + également les instantanés locaux. C’est une option disponible lors de l’assistant, ou en modifiant la tâche de réplication (onglet Avancé). Elle ne concerne que les instantanés créés après l’activation de l’option.

La rotation des versions des instantanés se paramètre indépendamment sur chaque NAS.

Sur la source, des snapshots des partages réseau sont dans /volume1/@sharesnap. C’est ce chemin qui est utilisé pour le send.
Sur la destination, la replication en cours est stockée dans le dossier /volume1/@sharesnap_receiving/.

La réplication se configure depuis le NAS source, et elle nécessite que les volumes sur les 2 NAS soient formatés en btrfs.
L’utilisateur choisi pour établir la connexion doit être membre du groupe “administrators” sur la destination.

Quand un partage sur la destination est paramétré pour recevoir des instantanés, on ne peut plus lui configurer des instantanés locaux.

Dans les paramètres de l’app Snapshot Replication, on peut modifier le nombre de tâches en parallèle ; par défaut c’est 1 seule.
Ainsi, même si des réplications sont planifiées au même moment, il n’y aura pas de parallélisation des accès disques, afin de conserver des performances optimales.

Nettoyage de l’espace

Pour que l’espace soit réellement récupéré lors de la suppression d’un snapshot, on peut activer le nettoyage des données. Pour ceci :
Gestionnaire de stockage -> Stockage -> bouton “Planifier le nettoyage des données”

On peut choisir des périodes sur lesquelles ce nettoyage est mis en pause.

Divers

restauration des utilisateurs depuis une sauvegarde (.dss) lorsqu’ils existent déjà sur la cible ?
-> les passwords des utilisateurs existants ne semblent pas remplacés par les éléments de la sauvegarde

Synoacl

synoacltool -add /volume2/backups/latest/LOGICIELS/ everyone:*:deny:-w-pdD-A-W-Co:fd–

find /volume2/backups/history/xxx/$share/* -type d -exec synoacltool -set-archive “{}” is_inherit,is_support_ACL ;

Portail Azure

https://portal.azure.com

La colonne de gauche inclut Accueil, Tableau de bord et Tous les services.
Ensuite viennent les services favoris. On peut supprimer ces favoris dans “Tous les services -> Favoris”.
On peut ajouter des services aux favoris dans “Tous les services -> Tout” (ou Récent) en cochant l’étoile.

Facturation

L’organisation de la facturation dépend du type de contrat. Par exemple :
Microsoft Online Services Program
Enterprise Agreement
Microsoft Customer Agreement
etc…

Pour voir le type de contrat :

Portail Azure -> Cost Management + billing -> Billing Scopes
Le type de contrat est listé pour chaque billing scope (étendue de facturation)

https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/view-all-accounts

MCA

Le point de départ est le compte de facturation (billing account). C’est ici qu’est conclu le contrat de licence (MCA).
Un compte contient 1 ou plusieurs profils de facturation.

Chaque profil (Billing Profile) correspond à une facture. Il comprend notamment :

• des informations de paiement (numéro CB)
• 1 ou plusieurs sections de facturation (invoice section)

Un profil doit avoir un plan Azure pour utiliser des ressources Azure.
Si pas de plan Azure dans le profil, il sera impossible d’y créer un abonnement (subscription) Azure. Le plan est visible dans les Propriétés du profil de facturation.
Lorsque l’on crée un profil de facturation via Azure, il me semble que ça crée automatiquement un plan Azure (probablement Pas-as-you-go ?).
Pour ajouter un plan Azure à un profil pré-existant qui n’en a pas, essayer avec cette URL :
https://portal.azure.com/?createAzurePlan=true#view/Microsoft_Azure_SubscriptionManagement/SubscriptionCreateBlade

Chaque section de facturation contient 1 ou plusieurs “Subscriptions” (abonnements) et/ou autres produits d’azure marketplace

On peut facilement transférer une abonnement vers une autre section de facturation au sein du même profil.
Pour ceci, il faut rentrer dans l’aperçu (Overview) d’un abonnement en passant par le menu “All billing subscriptions”. Si on passe par le menu “Azure subscriptions” l’option ne sera pas disponible.
Une fois ouvert l’aperçu, on a, dans le menu en haut, l’option “Change -> Invoice section” qui permet de choisir une autre section de facturation au sein du même profil.

Un abonnement contient des groupes de ressources ;
qui contiennent eux-mêmes des ressources.

Le nom du “billing profile” sera visible sur la facture.
Les noms des “invoice sections” seront visible également

Il me semble que le nom du “billing account” n’est pas visible sur la facture.

On peut prendre un abonnement de support ; sinon, seulement un support pour la facturation mais pas de support technique.

Groupe de ressources

Un Groupe de ressources est un conteneur “logique” qui a pour but de réunir toutes le ressources qui peuvent être utilisées par un “projet”, une “solution”. Par exemple des VMs, du stockage, etc.

À la création, on l’associe à un abonnement, qui sera utilisé pour la facturation. On lui donne un nom, et on choisit sa localisation géographique.
On peut ensuite lui donner des “étiquettes”, avec chacune une valeur, qui sont des catégories.

Entra

Voir https://memo.raphaelguetta.fr/post/entra

Azure files

Voir https://memo.raphaelguetta.fr/post/azure-files

GPO

Pour faire littéralement des GPO, il faut nécessairement un serveur virtuel !

https://learn.microsoft.com/fr-fr/entra/identity/domain-services/manage-group-policy

Sinon nous pouvons ne pas avoir de DC, et gérer les appareils avec Intune (endpoint manager ; Mobile Device management, soit MDM)
https://memo.raphaelguetta.fr/post/azure-intune

RBAC

Role-based Access Control
https://learn.microsoft.com/en-us/azure/role-based-access-control/overview
Un rôle contient 3 éléments :

• le “security principal”, l’élement concerné par l’attribution de rôle (user/group/service principal/managed identity)
• la définition de rôle, qui est un ensemble de permissions (R/W/delete/mofify/grant etc)
• l’étendue (scope), qui définit l’ensemble de resosurces auxquelles s’applique ce rôle (groupe de gestion/abonnement/groupe de ressource/ressource)

L’assignation d’un rôle (role assignment) est l’action d’attacher une définition de rôle à un security principal .

ABAC

Attribute-based Access Control
https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-overview

https://learn.microsoft.com/en-us/azure/backup/azure-file-share-backup-overview

Récap

Un “compte de stockage” doit être “registered” dans un “vault”.
-> se consulte et gère dans Resiliency -> Vaults -> Manage -> Backup infrastructure -> Azure storage accounts -> Storage accounts

Un “partage (file share)” qu’on sauvegarde dans un “vault” devient un “protected item”.

Le contenu de ce partage sauvegardé dans un vault devient un “backup item” - avec ses différentes versions, et types de sauvegarde (snapshot/vault).

Vault

Les sauvegardes doivent nécessairement être stockées dans un “vault”.
Pour le service Azure Files, il faut créer un “Recovery Services vault”
https://learn.microsoft.com/en-us/azure/backup/backup-create-recovery-services-vault
Pour ceci, dans le portail Azure, chercher “Resiliency” (anciennement “Business Continuity Center”), et ouvrir Manage -> Vaults.

Attention, il n’est actuellement pas possible de changer la redondance d’un vault après sa création (ou au moins tant que des éléments sont backupés dedans).

Types de sauvegarde

Il y a des sauvegardes de type “snapshots”, et d’autres de type “vaulted-standard”.

La principale différence que j’ai vu entre les 2, c’est que les snapshots ont la nécessité d’avoir le partage originel encore accessible ; si il est supprimé, il sera impossible d’accéder au contenu des snapshots (bien que ceux-ci soient encore visibles dans les vaults).
À l’inverse, un partage stocké dans un vault peut être restauré, même après sa suppression.

Par aileurs, la restauration de type “file recovery” (restauration de certains fichiers individuels) ne peut se faire qu’à partir d’un snapshot.
Le vault permet uniquement la restauration de l’ensemble du partage.

De même, seule les “snapshots” permettent de récupérer les versions dans l’explorateur, onglet “Versions précédentes”.

Backup policy

Il faut ensuite créer une politique de sauvegarde ; consiste en un vault de destination, un type de sauvegarde (snapshot-only, ou bien vault), une fréquence de sauvegarde et une durée de rétention des sauvegardes. Pour ceci :
https://learn.microsoft.com/en-us/azure/backup/quick-backup-azure-files-vault-tier-portal

Dans “Business Continuity Center” (ou “Resiliency”), ouvrir Manage -> Protection Policies puis Create policy -> Create backup policy. Choisir “Azure Files (Azure Storage)” et sélectionner le vault précédemment créé.

Pour une sauvegarde complète, MS recommande de choisir “Vault-Standard” comme niveau de sauvegarde.
Choisir la fréquence de sauvegarde (au + fréquent toutes les 4h, et 6 sauvegardes par jour).

Une fois créée, la politique apparaît dans la liste des “Protection policies”, en tant que politique gérée par Azure. Il faut toutefois s’assurer que la “Datasource type” est bien définie sur “Azure Files (Azure Storage)” pour la voir apparaître.

Activation de la sauvegarde

Aller dans “Business Continuity Center -> Overview” et cliquer sur “+ Configure protection”. Choisir “Azure”, “Azure Files” et “Azure Backup” en solution.
Choisir le vault créé précedemment.
Choisir le compte de stockage contenant les données à sauvegarder. Choisir le ou les partages à inclure dans la sauvegarde. Choisir la stratégie de sauvegarde désirée (celle créée précédemment).

Les différents partages au sein d’un même compte de stockage ne peuvent pas utiliser des vaults différents. On peut choisir de ne pas sauvegarder tous les partages d’un compte de stockage, mais ceux sauvegardés le seront tous dans le même vault.

Déclenchement manuel d’une sauvegarde

Aller dans les détails du vault, puis Protected items -> Backups items. Choisir “Azure Storage”.
Choisir le partage à sauvegarder, et ouvrir les détails, puis clic sur “Backup now”.
Les points de sauvegarde déclenchés manuellement ne sont pas soumis à la politique de rétention standard, mais ont une date de validité définie directement lors de la création du backup (par défaut c’est 1 mois).
L’avancement de la sauvegarde peut être suivi dans les notifications.

Consulter l’état de la sauvegarde

Partages encore existant

comptedestockage -> Files shares -> partage -> Operations -> Snapshot
On y voit les snapshots, ce qui l’a initié, et on peut naviguer en cliquant sur une version.
J’ai l’impression qu’on voit tous les snapshots (à vérifier sur une grosse quantité).

Ces snapshots sont également visibles dans l’explorateur Windows, propriétés du dossier partagé, onglet Versions précédentes.
(note : si un lecteur réseau est connecté directement au partage (dossier racine, par ex. \company.file.core.windows.net\partage\ ), il aura des “versions précédentes”. Mais si c’est un sous-dossier du partage qui est monté en tant que lecteur réseau (par exemple \company.file.core.windows.net\partage\dossier ), alors les versions précédentes seront absentes du lecteur réseau lui-même (par ex. Z:\ ). Mais on les retrouvera sur les sous-dossiers du lecteur réseau. (par ex. Z:\travail\ )

Si on clique sur Operations -> Backup, on est invités à paramétrer la sauvegarde si ce n’est déjà fait.
Si elle est configurée, on y voit les 60 derniers snapshots (je crois).
On y voit aussi le type de sauvegarde (snapshot/vaulted).

Cas général

Resiliency -> Manage -> Vaults -> choisir -> Protected items -> Backup items -> Azure storage (Azure Files) -> View details

On peut voir l’état

Restauration

https://learn.microsoft.com/en-us/azure/backup/restore-afs

Dans les propriétés d’un partage, si on va dans Operations -> Snapshots, on peut voir les snapshots disponibles.
On peut accéder à chacun d’eux via l’explorateur Windows, via clic-droit -> Restaurer les versions précédentes.
Ceci permet un accès facile et en autonomie à des versions précédentes.

Restauration d’un partage

Il est également possible de restaurer un partage complet.
Si le partage existe encore, on peut passer par ses propriétés -> Backup, choisir le point et choisir “… -> Restore share”.

Sinon, on peut aller dans le vault

Suppression du partage

Dans le cas où un partage est supprimé, les snapshots apparaissent toujours dans le vault, mais ne sont pas restorables/explorables !
Le message suivant s’affiche :
Listed restore points are not available as the associated file share containing the restore point snapshots has been deleted permanently. We recommend undeleting file-shares within the soft-delete retention period to prevent permanent deletion.Learn More

Changement de Vault pour un compte de stockage

https://learn.microsoft.com/en-us/azure/backup/backup-azure-files-faq

Pour pouvoir changer le vault qui recevra les sauvegardes d’un compte de stockage, il faut d’abord désactiver la protection pour chacun des partages de ce compte, puis désenregistrer le compte de stockage du vault.

Pour stopper la protection, aller dans Business continuity Center -> Protected items. Choisir “Azure Files” en source. Choisir les partages appartenant au compte de stockage concerné. Choisir Stop Backup dans la barre du haut.
La doc MS indique qu’on peut choisir de conserver les données sauvegardées, ou bien de les supprimer ; mais dans mon expérience, il est indispensable de les supprimer pour pouvoir désenregistrer le compte de stockage.

Une fois la protection stoppée, ouvrir le vault actuel, puis aller dans Manage -> Backup infrastructure puis Azure storage accounts -> Storage accounts.
Choisir le compte de stockage à désassocier, clic sur les … à droite puis “Unregister”.

Limites de quantités de sauvegarde

https://learn.microsoft.com/en-us/azure/backup/azure-file-share-support-matrix

Rapport par mail

Business Continuity Center -> Monitoring + Reporting -> Reports

Coût et soft-delete

https://azure.microsoft.com/en-us/pricing/details/backup/

L’option de soft-delete des données de sauvegarde, activée par défaut, peut se définir dans les propriétés du vault :
Business Continuity Center -> Vaults -> choisir - Settings -> Properties -> Soft Delete and security settings
Lorsque cette option est activée, lors la suppression d’une sauvegarde, les données de celle-ci sont conservées pendant 14 jours.

On peut désactiver cette fonctionnalité, ou bien modifier/augmenter la durée de rétention après suppression.
Selon cette page :
https://learn.microsoft.com/en-us/azure/backup/backup-azure-enhanced-soft-delete-about#pricing
la conservation des données est gratuite pendant 14 jours (en cas d’augmentation de la durée de conservation, ce sont les 14 derniers jours qui sont gratuits ; si on undelete les données avant la fin de la rétention, on paye depuis le 1er jour).

Snapshots

Il y a un coût d’abonnement de ~6€/mois.

Pour le modèle pay-as-you-go, l’espace utilisé par les snapshots est facturé au même coût que le stockage Azure Files. Son espace dépend de l’évolution des données (des données n’évoluant pas du tout n’utiliseront aucun espace pour leurs snapshots).
Pour voir l’espace utilisé par les snapshots d’un compte de stockage,
Storage accounts -> sélectionner -> Monitoring -> Metrics puis régler ainsi :
Metric Namespace : File
Metric : Fileshare Snapshot Size
Dans ce modèle pay-as-you-go, on a l’info pour l’ensemble du compte de stockage ; il ne me semble pas possible de décomposer par partage.

Pour le modèle provisionned v2, l’espace utilisé par les snapshots essaye de rentrer dans le quota provisionné.
Si le total de l’espace utilisé (fichiers+snapshots) ne dépasse pas l’espace provisionné, il n’y aura pas de surcoût.
Si l’espace utilisé total dépasse le quota provionné, les snapshots sont facturés à part (environ 1€/100Go/mois).
Pour voir l’espace utilisé par les snapshots, même méthode que ci-dessus, mais il y a en + une section Metrics dans le détail du partage (ou on peut afficher les métriques du compte de stockage puis ajouter un filtre sur le nom du partage, ce qui revient au même).

Recovery Services Vault

Il y a un abonnement mensuel de ~12€/vault/mois.

L’espace utilisé dans le vault est également facturé, avec son propre coût, dépendant notamment de la redondance choisie.

Général

Azure Files est un stockage cloud, accessible via SMB par une machine locale, ou une VM Azure.

Azure Files peut stocker plusieurs types de ressources, comme les conteneurs blob, mais je m’intéresse ici uniquement aux partages de fichiers.

Il y’a également la possibilité de créer des partages NFS, mais je n’aborde pas ce cas ici. Un partage est accessible soit par SMB soit par NFS, mais pas les 2 en même temps.

Guide de planification général Azure Files

https://learn.microsoft.com/en-us/azure/storage/files/storage-files-planning

Quelques considérations

MS conseille de ne pas mélanger les différents types de ressources au sein d’un même compte de stockage (si il contient un partage Azure Files, alors il est déconseillé d’y mettre un stocke blob par exemple).

Dans la mesure du possible, essayer de ne mettre qu’un seul partage par compte de stockage (chaque partage aura son propre compte de stockage).

Compte de stockage

https://learn.microsoft.com/fr-fr/azure/storage/common/storage-account-overview

La gestion se fait sur le portail Azure, section “Comptes de stockage”.
Il faut créer un compte de stockage (qui lui-même doit appartenir à un groupe de ressources).
Les performances du compte de stockage (standard ou premium) est défini définitivement à la création du compte.

Le compte de stockage est protégé par 2 clés, “storage account key”. On peut les voir sur le portail Azure, dans le compte de stockage -> Sécurité + réseau (colonne de gauche) -> Clé d’accès.
Ces clés donnent un accès admin complet à l’ensemble des partages et données du compte de stockage.

Pay-as-you-go ou provisionned

https://learn.microsoft.com/en-us/azure/storage/files/understanding-billing

Calculateur de coûts ici :
https://azure.microsoft.com/en-us/pricing/calculator/

Il y a 2 modèles de facturation pour les partages Azure Files :

• le modèle provisionné v2 (le v1 est uniquement pour les storage premium, en SSD) (on définit d’avance une capacité max de stockage, des IOPS et de la bande passante, et le coût est fixe)
• le modèle à l’usage, où on paye chaque Go de stockage, chaque transaction, et chaque Mo de transfert

Le modèle de facturation est défini au niveau du compte de stockage, et sera visible dans ses propriétés (Kind : StorageV2 pour du PAYG, FileStorage pour du provisionné).
Cependant, pour les modèles provisionnés, le décompte de l’usage des ressources est fait pour chaque partage. C’est lorsqu’on déploie un partage que l’on commence à être facturé.

Pour des volumes de données faibles, le modèle PAYG peut être intéressant, mais il revient vite cher s’il y’a du volume de données (~ 300€/mois pour 2.7 To de données en cool storage dont le seul accès est la sauvegarde quotidienne ; en cool storage, le coût des transactions est vite important ! )

Le modèle provisionné peut vite être + intéressant, mais il a des quantités minimum (32Go, 500IOPS, 60MiB/s) qui induisent des coûts fixes, avec un minimum de ~30€/mois pour chaque partage.
Il est possible d’augmenter les performances du partage à tout moment. Pour ça :
Comptes de stockage -> sélectionner -> File shares -> ... (au bout de la ligne du partage) -> Change size and performance
On peut également diminuer le provisonnemnt, mais seulement 1 fois/24h.

Redondance

https://learn.microsoft.com/fr-fr/azure/storage/common/storage-redundancy

LRS : 3 copies dans le même datacenter
ZRS : 1 copie dans chacun de 3 datacenter différents (dans la même région primaire)
GRS : LRS en zone primaire + LRS en zone secondaire
GZRS : ZRS en zone primaire + LRS en zone secondaire

Le niveau de redondance est défini au niveau du compte de stockage, mais il pourra être changé par la suite. Pour ceci :
Storage accounts -> sélectionner -> Data management -> Redundancy
et choisir la nouvelle redondance.
Attention MS prévient que ça peut mettre plusieurs jours (ou semaines !) pour démarrer.

Zones de disponibilité :
https://learn.microsoft.com/fr-fr/azure/reliability/availability-zones-overview?tabs=azure-cli#azure-regions-with-availability-zones

Partages

Une fois le compte de stockage créé, on peut créer des partages (Portail -> Comptes de stockage -> Partages de fichiers puis + Partage de fichiers). Le nom ne peut pas contenir de majuscule.

Chaque partage a son propre niveau de performance (froid, chaud, optimisé pour les transactions).
Celui-ci peut se changer par la suite si besoin.
MS conseille, s’il y a des gros volumes à transférer, de commencer par le niveau optimisé pour les transactions le temps de la migration, puis de repasser à un autre niveau après.

Chaque partage a ses paramètres de sauvegarde.

Suppression réversible (Soft delete)

Concerne uniquement la suppression d’un partage (et non de fichiers dans ce partage).
Si activé, lorsqu’un partage est supprimé, il reste “dans la corbeille” pendant un temps (configurable).
Activé au niveau du compte de stockage, pour tous les partages lui appartenant.
Article chez MS

Les partages dans l’état soft-delete sont facturés selon le modèle de facturation choisie pour le compte de stockage (ils comptent comme s’ils étaient actifs).

Paramètres SMB

Récap chez Microsoft

L’accès SMBv3 est ok pour Windows 10 et Debian Bullseye. Les paramètres SMB sont identiques pour tous les partages au sein d’un compte de stockage.

Accéder au partage Azure Files

Article chez Microsoft

Obtenir l’UNC

Ça devrait toujours être \\nomducomptedestockage.file.core.windows.net\nom-du-partage .

Pour le vérifier :
Azure Portal -> Comptes de stockage -> Sélectionner le compte de stockage souhaité -> Partage de fichiers (colonne de gauche du panneau central) puis clic sur Connecter
Cela donne un script, dans lequel on trouve l’UNC.
On y voit aussi la clé de sécurité, derrière le /pass=

Connexion via clé

Si on veut établir la connexion manuellement, on peut ajouter les informations de connection dans Panneau de configuration -> Comptes d'utilisateur -> informations de connexion Windows (ou à la volée lors de la connexion) :

• Adresse : nomducomptedestockage.file.core.windows.net
• Utilisateur : nomducomptedestockage (ou localhost\nomducomptedestockage )
• Mot de passe : clé du compte de stockage

Il est bien sûr possible d’automatiser le déploiement de ce partage via GPO (ou Intune).

Depuis Linux

smb://nomducomptedestockage.file.core.windows.net/nom-du-partage
Mêmes utilisateurs et mot de passe. “Domaine” non-pertinent.

Authentification/autorisations

Article chez Microsoft

L’accès au partage se fait :

• soit par la “storage account key” (donne un accès complet admin à tous les partages du compte de stockage)
• soit par un accès basé sur l’identité (IAM)

Si on veut utiliser l’IAM, il est bien de commencer par vérifier que le montage fonctionne en utilisant la storage key, pour s’assurer du bon fonctionnement de la partie réseau sans s’occuper de la partie authentification.

Si on veut utiliser l’IAM, il faut le paramétrer. Un paramétrage sur le compte de stockage lui-même est nécessaire (chaque entité doit avoir les droits d’accès au compte de stockage pour accéder à un partage inclus dedans).

Ce paramétrage se fait sur le portail, dans Compte de stockage -> le choisir -> Access Control (IAM) -> Add -> Add role assignment .
On recherche “SMB”, puis on choisit le rôle “Storage File Data SMB Share Contributor” (pour un contributeur simple, qui peut modifier les fichiers).
On y affecte ensuite l’entité qui doit bénéficier de ce rôle (un groupe, un utilisateur).

Si on souhaite pouvoir modifier les ACL directement sur les dossiers/fichiers, depuis l’explorateur Windows, il faut accorder le rôle “Collaborateur à privilèges élevés de partage SMB des données du fichier de stockage”.

Chaque partage de ce compte héritera de cette IAM. Il est possible de surcharger chacun des partage avec d’autres droits (par exemple refus d’accès ?).

Il y a 3 méthodes d’authentification auprès d’une “source AD”, chacune avec ses spécificités.

Auprès d’un AD local (AD DS)

Il est nécessaire de pouvoir contacter ce DC local lors de l’établissement de la connexion au partage.
Ce DC local peut éventuellement être hébergé dans le cloud, avec accès via un VPN.
Disponible seulement pour les utilisateurs hybrides (synchronisés depuis le DC local vers Entra ID).

Introduction - MS
Activation - MS

Entra Domain Services (Entra DS, anciennement Azure AD DS)

Il s’agit d’un domaine géré (managé) par MS, qui fournit entre autres des fonctionnalités de DC et de GPO.
Il semble plutôt fait pour la gestion centralisée de serveurs virtuels, et il ne peut être contacté que via la connexion à un VPN.
Prend en charge les utilisateurs hybrides ainsi que cloud-only.
Les clients (postes utilisateurs) ne peuvent pas être Entra-joined ou Entra-registered.
les clients doivent être joints au domaine hosté pour que tout soit automatisé.
Il est toutefois possible de monter le partage depuis un poste non-joint à un domaine en fournissant des IDs explicites.

Récap chez Microsoft
Activation

Entra Kerberos

C’est une authentification directement auprès d’Entra, uniquement pour les utilisteurs hybrides (synchronisés depuis un DC local).
L’accès peut se faire sans besoin de connexion au DC (sauf pour régler les droits d’accès, là une connexion au DC sera nécessaire).
Les postes clients doivent être Entra-joined ou Entra-hybrid-joined ; pas ok si joints à Entra DS ou si joints uniquement à un AD local.

Détails sur mon memo

Migration des données

https://learn.microsoft.com/fr-fr/azure/storage/files/storage-files-migration-overview

Plusieurs méthodes possibles ; par exemple :

• simplement avec robocopy d’un lecteur à l’autre
• avec Azure Storage Mover
• avec Azure Files Sync

Azure Files Sync

https://brouillons.raphaelguetta.fr/post/azure-files-sync/

Pour synchroniser un serveur local avec un partage Azure Files Sync
https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-planning

Possible de faire de la synchro simple.
Possible aussi de donner au server local un rôle de cache, les clients s’adressant à lui et lui échangeant avec Azure.

Azure Storage Mover

https://learn.microsoft.com/en-us/azure/storage-mover/service-overview

Capable de gérer des gros volumes de données.
Transfère les metadonnées.

Requiert la création sur Azure d’une ressource Azure Storage Mover
Requiert ensuite la création d’un agent (apparement c’est une VM)

Coût

https://azure.microsoft.com/fr-fr/pricing/details/storage/files/#pricing

Il y’a plusieurs choses distinctes qui sont facturées : stockage utilisé, transactions (lecture/écriture de données), metadonnées, backups, snapshots etc…

Facturation provisionnée (espace pré-payé, qu’il soit utilisé ou non)

Facturation à l’usage pour les modes standard (optimisé pour les transactions, chaud, froid).

Le stockage est de moins en cher quand on descend dans les gammes (optimisé pr transactions -> chaud -> froid)
Les transactions sont de + en + chères quand on descend dans la gamme.

Il est possible de changer le niveau de chacun des partages à tout moment. Ceci entraîne toutefois des transactions donc de la facturation.

Sauvegarde

https://learn.microsoft.com/en-us/azure/backup/azure-file-share-backup-overview

https://memo.raphaelguetta.fr/post/azure-files-backup

Disques managés

disques virtuels attachables à une VM azure en tant que disque local
https://azure.microsoft.com/fr-fr/pricing/details/managed-disks/
en HDD, 8To = 300€/mois

Montable sur plusieurs serveurs virtuels ?