Effectuer une sélection.
Clic-droit dessus -> Tracer la sélection.
Choisir l’épaisseur du trait.
La couleur utilisée sera la couleur de l’avant-plan.
Effectuer une sélection.
Clic-droit dessus -> Tracer la sélection.
Choisir l’épaisseur du trait.
La couleur utilisée sera la couleur de l’avant-plan.
La connexion au nouveau Teams utilise le mécanisme ModernAuth ; celui-ci peut récupérer les comptes “Professionnel ou scolaire” paramétrés dans Windows.
Si le compte est paramétré, Teams New se connecte sans avoir besoin d’entrer le mot de passe (et ce même après s’être déconnecté dans Teams).
Si on déconnecte le compte dans les paramètres, Teams New reste connecté s’il l’était.
Si on déconnecte ensuite Teams New, il faut ré-entrer le mot de passe pour se connecter à Teams.
Il peut toutefois arriver qu’on ait besoin de supprimer manuellement les fichiers de connexion, par exemple pour faire disparaître les suggestions de connexion Teams, soit pour résoudre certains problèmes de connexion (notamment vers les organisations externes).
Pour ceci, il faut renommer/supprimer les dossiers suivants.
ATTENTION, ça va supprimer/réinitialiser toutes les connexions MS : (Accès pro/scolaire, connexion à la licence Office, identifiants Teams etc).
%LocalAppData%\Packages\MSTeams_8wekyb3d8bbwe
%LocalAppData%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
%LocalAppData%\Microsoft\OneAuth
%LocalAppData%\Microsoft\TokenBroker
%LocalAppData%\Microsoft\IdentityCache
Éventuellement redémarrer le poste, et l’ensemble des logons Microsoft devrait être vierge.
https://learn.microsoft.com/fr-fr/microsoftteams/troubleshoot/teams-administration/clear-teams-cache
Pour l’ancien Teams (pas testé) :
%appdata%\Microsoft\Teams
L’interface réagit aux clics.
Pour sélectionner du texte, on peut faire Maj+clic puis copier avec Ctrl-Maj-C.
Avec F2, on peut customiser le setup.
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ésacitver ce raccourci dans les oprtions du terminal, soit cliquer sur Exit.
Pour figer l’affichage, Maj+Z. Idem pour dé-figer.
Update 10 years anniversary de ce post
Il faut avoir l’iso de la version de Windows que l’on souhaite installer.
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.
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 (je mets de côté 1Go pour être large, mais même 10 Mo devraient être largement suffisants).
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
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).
truncate -s 20G ./file.dat
Le but est d’activer le WoL sur un Dell Optiplex 3050.
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.
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 :
À 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.
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.
https://www.dell.com/support/kbdoc/en-uk/000129137/wake-on-lan-wol-troubleshooting-best-practices
Il semblerait que ce soit via le gestionnaire de périph, aller dans les propriétés du NIC -> Power Management ->
Allow this device to wake the computer
Only allow a magic packet to wake the computer
advanced tab
Energy-Efficient Ethernet -> Disabled
config panel :
Turn on fast startup ?
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
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.
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.
https://learn.microsoft.com/en-us/azure/storage/files/storage-files-planning
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).
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.
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 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.
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
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.
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).
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.
Ç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=
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) :
nomducomptedestockage.file.core.windows.netnomducomptedestockage (ou localhost\nomducomptedestockage )Il est bien sûr possible d’automatiser le déploiement de ce partage via GPO (ou Intune).
smb://nomducomptedestockage.file.core.windows.net/nom-du-partage
Mêmes utilisateurs et mot de passe. “Domaine” non-pertinent.
L’accès au partage se fait :
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).
Chaque partage de ce compte héritera de cette IAM. Il me semble qu’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.
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
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
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.
https://learn.microsoft.com/fr-fr/azure/storage/files/storage-files-migration-overview
Plusieurs méthodes possibles ; par exemple :
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.
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)
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.
https://learn.microsoft.com/en-us/azure/backup/azure-file-share-backup-overview
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 “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).
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
Une fois créé, toujours dans “Business Continuity Center”, 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.
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.
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.
https://learn.microsoft.com/en-us/azure/backup/restore-afs
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”.
https://learn.microsoft.com/en-us/azure/backup/azure-file-share-support-matrix
Business Continuity Center -> Monitoring + Reporting -> Reports
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).
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).
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.
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 ?
https://www.it-connect.fr/chapitres/les-cinq-roles-fsmo/
Les rôles FSMO sont des rôles spéciaux, chacun détenu par un seul DC au sein du domaine (le maître d’opération).
Primary DC
Maitre des noms de domaine
Contrôleur de schema
Gestionnaire RID
Maitre d’infrastructure
Pour avoir les 5 d’un coup :
netdom query fsmo
Pour les avoir 1 par 1 :
dsquery server -hasfsmo <role>
avec <role> pouvant valoir “pdc”, “name”, “schema”, “rid” ou “infr”.
Sur le détenteur du rôle FSMO, lancer la commande ntdsutil
puis
role
connections
connect to server newservername puis touche q
transfer <role> master
avec pouvant valoir “rid”, “schema”, “infr”, “naming” ou “pdc”
(sauf pour pdc, ne pas mettre “master”)
et confirmer le transfert
Il faut alors “seize” le rôle.
Pour ceci, passer par ntdsutil.
https://support.microsoft.com/help/255504
Il m’est arrivé d’avoir un fichier mp3 sur lequel vlc me sortait des tags qui n’étaient pas du tout ceux mentinnés par id3v2.
Après analyse du fichier, j’ai vu qu’il s’agissait de tags Monkey’s Audio (APE tags).
Pour les gérer sous Linux, j’ai trouvé le logiciel apetag (qui n’est pas dans les dépôts Debian).
git clone https://github.com/robertmuth/apetag
make
qui nous donne l’éxécutable apetag (que l’on peut éventuellement mettre dans /usr/local/bin pour l’avoir dans le $PATH).
apetag -m erase -i file.mp3
Pour plusieurs fichiers à la fois, il me semble que la wildcard ne fonctionne pas, donc avec find :
find ./ -iname "*.mp3" -exec apetag -m erase -i {} \;
FOR /L %N IN () DO @echo "commande" & timeout 5 & "C:\mysoft.exe"