Dans le cas où, au lancement de Chrome, le processus lsass.exe s’emballe jusqu’à prendre 100% d’un coeur, ça peut être dû à une installation d’extension qui n’aboutit jamais.
Essayer de supprimer 2 fois le dossier %appdata%\Microsoft\Protect\GUID.
Dans le cas où, au lancement de Chrome, le processus lsass.exe s’emballe jusqu’à prendre 100% d’un coeur, ça peut être dû à une installation d’extension qui n’aboutit jamais.
Essayer de supprimer 2 fois le dossier %appdata%\Microsoft\Protect\GUID.
gpedit.msc sert uniquement à modifier les stratégies de groupes locales. La commande est disponible sur les Windows standards (Pro en tout cas).
gpmc.mmc sert à modifier, sur un controlleur de domaine, les GPO qui seront déployées chez les clients via Active Directory. Si cette commande n’est pas disponible sur un serveur, c’est probablement que le rôle de gestion des stratégies de groupes n’a pas été installé (ajouter des fonctionnalités -> Gestion des stratégies de groupe).
Par défaut, toutes les GPO ne sont pas disponibles dans l’outil gpmc.msc. Notamment, la catégorie “Modèles d’aministration”. Or, si on lance gpedit.msc, on voit que beaucoup de stratégies sont disponibles sous cette catégorie.
Pour ajouter des stratégies à l’outil gpmc.msc, on utilise des fichiers ADMX (ou, historiquement, ADM). Ils sont généralement déployés via les mises à jour Windows, mais ne sont disponibles que pour le système local. On les trouve dans le dossier %windir%\PolicyDefinitions, sous la forme de fichiers ADMX associés à des fichiers de localisation ADML dans des répertoires de langue (par exemple fr-FR).
On peut prendre tous ces fichiers, et les copier dans le dossier %windir%\SYSVOL\sysvol\mon.domaine.fr\Policies\PolicyDefinitions
Description du problème chez Microsoft Tuto pour l’activation par GPO
Dans certains cas, lorsque l’on est dans un domaine, et que l’on cherche à accéder à un serveur via son nom complet(FQDN, du type server.domain.example.com), alors le poste considérera que ce domaine appartient à la zone de confiance “internet”, et donc bloquera l’ouverture de certains documents, scripts, exécutables etc.
Pour corriger ce problème, on peut aller dans les options internet du poste en question, et passer les sites *.domain.example.com en zone Intranet.
Mais on peut aussi déployer ceci sur tous les postes du domaine, via GPO, ce qui évite d’avoir à le faire à la main sur chaque poste. Pour ceci, sur un controlleur de domaine :
gpmc.mscConfiguration utilisateur -> Stratégies -> Modèles d'administration -> Composants Windows -> Internet Explorer -> Panneau de configuration Internet -> Onglet Sécurité et activer le paramètre Liste des attributions de site aux zones
Lorsqu’on rentre dans les propriétés du paramètre, on peut afficher les zones, et associer *.domaine.example.com à la valeur 1.Elément en italique
Élément en italique aussi (étoiles)
Élement en gras
Mac OS a tendance à laisser des fichiers un peu partout dans les répertoires auxquels il a accès en écriture.
Pour les supprimer, sous Windows :
cd /d X:\infected\folder
del /s /q /f /a .DS_STORE
del /s /q /f /a:h ._.*
del /s /q /f /a:h ._* # cela peut suprrimer aussi certains fichiers de chrome, attention s'il y'a un profil dans le chemin !
del /s /q /f /a __MACOSX
Le /a permet de matcher quels que soient les attributs.
Sous linux :
find ./ \( -name ".AppleDouble" -o -name .DS_Store -o -name ._.* \) -exec rm -Rf {} \;
But de la manoeuvre : transformer travail.domaine.com en work.ville.nouveaudomaine.fr, ainsi que les noms NetBIOS de TRAVAIL vers WORK.
Sources :
Pour du Server 2003
Pour du Server 2008
Une synthèse
Une autre synthèse
Il faut au préalable créer une nouvelle zone DNS. Pour ceci, Gestionnaire DNS -> nouvelle zone
Dans un cas simple, laisser les choix par défaut (zone principale, intégrée à l’AD, vers tous les serveurs DNS executés sur des DC dans ce domaine). Adapter si besoin.
Nom de la zone à créer : work.ville.nouveaudomaine.fr
Depuis la station de contrôle, on lance une invite de commande en administrateur. Je conseille de dédier un répertoire à la migration
mkdir C:\migration_domaine
cd C:\migration_domaine
Puis
rendom /list
Ceci crée un fichier domainList.xml dans le répertoire courant, qu’il faut éditer en remplaçant l’ancien nom de domaine par le nouveau (il est sage de le backuper avant modification).
On remplace dedans les occurences de travail.domaine.com par work.ville.nouveaudomaine.fr.
On lance ensuite
rendom /showforest
Ceci affiche les infos updatées selon le fichier DomainList.xml modifié. Il ne modifie rien, mais permet de vérifier que la nouvelle organisation est bien celle attendue.
Ensuite,
rendom /upload
Ceci crée le fichier Dclist.xml et l’envoie sur les controlleurs de domaine. Cette étape freeze la foret pour éviter les interactions indésirables entre la migration de domaine, et d’éventuelles modifications sur la forêt.
Microsoft conseille ensuite de répliquer les infos de configuration depuis le serveur Domain Naming Master (mettre son hostname à la place dans la commande suivante) :
repadmin /syncall /d /e /P /q DomainNamingMaster
Si besoin de le connaitre le serveur qui joue le rôle de DNM, on a la commande
dsquery server -forest -hasfsmo Name
Vérifier dans le serveur DNS que nous avons IMPÉRATIVEMENT toutes les entrées définies dans cet article
On peut ensuite lancer la commande
rendom /prepare
qui va vérifier que tous les DCs sont aptes à être mis à jour. Ceci se vérifie sur le fichier Dclist.xml (les DC doivent être en état Prepared).
Enfin,
rendom /execute
qui lance effectivement la mise à jour. Les DCs vont rebooter automatiquement.
Penser à vérifier après reboot que le login se fait bien en utilisant le nouveau domaine, ainsi que les panneau de conf Système.
Vérifier le fichier Dclist.xml, les DCs doivent être à l’état Done.
Si il subsiste un état “Error”, il est possible de compléter la ligne <Retry><Retry> en <Retry>yes<Retry>, puis de réaplliquer cette étape (les DCs à l’état Done ne seront pas réaffectés par la manipulation).
Si un DC reste malgré tout à l’état Error, il faut lui enlever (puis remettre) les rôles AD-DS.
Puis sur un (chaque?) DC après redémarrage :
gpfixup /olddns:travail.domaine.fr /newdns:work.ville.nouveaudomaine.fr
qui met à jour et répare les dépendances de nom de domaine dans le stratégies de groupe après changement.
De même,
gpfixup /oldnb:TRAVAIL /newnb:WORK
qui met à jour le nom NetBIOS du domaine.
À ce stade, il faut redémarrer 2 fois chaque poste client, puis vérifier que son FQDN prend bien en compte le nouveau domaine.
On peut enfin lancer la commande
rendom /clean
qui supprime les références à l’ancien domaine.
Attention, les postes non rebootés 2 fois après cette étape devront être manuellement retirés de l’ancien domaine, puis réintégrés dans le nouveau domaine.
Enfin,
rendom /end
qui finalise la procédure et dévérouille la forêt.
Après connexion d’un client, on peut vérifier que celui-ci est bien présent dans la zone récemment créée des serveurs DNS.
Vérifier/updater les chemins du DFSN, des partages réseaux déployés et des imprimantes déployées
Les FQDN des clients intègrent automatiquement le nouveau nom de domaine, mais pas les serveurs. Pour les renommer correctement, il faut ajouter le FQDN du nouveau domaine, puis le mettre en principal. Pour ceci,
netdom computername DC1.travail.domaine.com /add:DC1.work.ville.nouveaudomaine.fr netdom computername DC1.travail.domaine.com /makeprimary:DC1.work.ville.nouveaudomaine.fr
Les partages réseaux déployés par les GPO ne sont pas mis à jour automatiquement pour utiliser le nouveau domaine/nom d’hôte, il faut le faire à la main
De même pour les imprimantes déployées par GPO. Si le serveur les hébergeant a changé de nom d’hôte, il faut les mettre à jour
si un espace de nom DFS (DFSN) est utilisé, il ne sera pas non plus mis à jour automatiquement
lorsque tout fonctionnait bien j’ai backupé (exporté) puis supprimé la zone DNS de l’ancien domaine des serveur DNS pour en effacer les traces et m’assurer que tout reposait bien sur le nouveau domaine
la synchronisation user/password avec Azure AD Connect ne fonctionnait plus, il a fallu la réinitialiser selon ce post
Dcdiag /test:DNS /DnsRecordRegistration /s:domaincontroller
Vérifier le serveur DHCP et le validité du basculement de l’étendue, s’il existe.
Il peut parfois être nécessaire de reconfigurer complètement les services de synchronisation entre un Active Directory local et les services Office 365 (Azure Active Directory Connect).
Pour ceci, il faut les désactiver chez O365 via Powershell, les désinstaller du serveur local, puis réinstaller AAD Connect sur le serveur local.
On ouvre une session Powershell en admin.
Si les outils de gestion PS vers O365 ne sont pas installés, on le fait via
Install-Module -Name MSonline
(si message de commande introuvable, il est nécessaire d’installer les PackageManagement, dispo ici
On initialise la variable de connection via
$msolcred = get-credential
en rentrant les ids d’un admin sur O365.
On établit la connection aux services O365
connect-msolservice -credential $msolcred
Il est ensuite temps de supprimer les applis AAD Connect du serveur local (ajout/suppression de programme).
Une fois désinstallés, on lance la commande PS :
Set-MsolDirSyncEnabled -EnableDirSync $false
et on valide avec Y.
pour obtenir l’état de synchro, on lance la commande
Set-MsolDirSyncEnabled -EnableDirSync $false
qui doit désormais renvoyer “false”.
Il faut plusieurs heures (voire une nuit) à Microsoft Azure pour prendre réellement en compte l’arrêt de la synchro. Lorsque ce sera fait, l’interface d’admin O365 n’affichera plus le status AAD Connect, ni l’état (Synchronisé/Dans le cloud) des Utilisateurs O365. Les utilisateurs anciennement synchronisés seront de facto considérés comme utilisateurs cloud.
Une fois que la suppression de la synchro est bien prise en compte par les serveurs O365, il suffit de réinstaller Azure AD Connect, avec éventuellement une passe préalable de IdFix.
Cf. ce post
La synchro reprend normalement assez rapidement, et quelques heure plus tard, l’état AAD Connect réapparait dans le centre d’administration O365.
Une partition ntfs contient un métafichier $BadClus qui contient une liste (logicielle) des secteurs marqués comme défectueux.
Suite à une duplication d’un disque vers un disque sain, j’ai retrouvé un système fonctionnel. Toutefois il était impossible d’effectuer une quelconque opération sur cette partition avec Gparted, à cause de cette liste de secteurs.
Il est possible, sous Windows, d’utiliser la commande chkdsk /B C: qui va relire l’intégralité du disque et marquer les secteurs comme non-defectueux s’ils sont lisibles. Mais c’est long…
On peut donc aussi utiliser la commande Linux ntfsfix -b -d /dev/sdX1 pour simplement supprimer cette liste de secteurs. Après un double redémarrage sous Windows, la partition était tout à fait manipulable par Gparted !
J’ai eu récemment un poste dont le Centre réseau et partage m’indiquait systématiquement comme non connecté, alors que le DHCP faisait son office correctement, et que la connexion fonctionnait. Il y avait systématiquement une croix rouge au lieu du symbole de connexion, et il était impossible de gérer les réseaux wifi. Après de longues recherches sur le net, c’est la commande suivante, en administrateur, qui a résolu le souci :
net localgroup Administrateurs localservice /add
Globalement, l’autorisation “Gérer” de AD correspond au status “Propriétaire” sous O365.
Ce qui existe dans l’AD est transmis vers O365/EAC, l’inverse n’est pas (forcément) vrai. Si on souhaite avoir les éléments en local, il FAUT les créer en local.
Les autorisations d’envoyer un mail “en tant que” (par ex. en tant qu’un groupe de distribution) se gèrent dans tous les cas dans l’EAC, car dans le setup actuel, il n’y a pas de serveur Exchange en local, seulement sur O365.
Un utilisateur créé sous AD apparaîtra dans O365 sous “Utilisateurs actifs” et dans EAC sous “Destinataires -> Boîtes aux lettres”. C’est un utilisateur à part entière avec boîte mail dédiée.
Un groupe de sécurité créé sous AD peut avoir une adresse mail renseignée ou non.
Si adresse, il apparaîtra dans O365 sous “Groupes” (en tant que “Sécurité avec extension messagerie”) et dans EAC sous “Destinataires -> Groupes” (en tant que “Sécurité à extension courrier”).
Si aucune adresse mail n’est renseignée, il apparaitra sous O365 sous “Groupes” (en tant que “Sécurité”) et n’apparaitra PAS dans EAC.
C’est avant tout un groupe pour l’organisation de l’entreprise (GPO de l’AD, etc.), qui peut également être utilisé pour remettre un courrier à tous les membres de ce groupe.
Si un autre groupe est lui-même membre du groupe, les utilisateurs de cet autre groupe ne recevront le mail QUE SI cet autre groupe a une adresse de messagerie renseignée dans ses propriétés (ceci permet de couper le transfert vers les N+1 par exemple, si on ne met pas d’adresse mail).
Un groupe de distribution créé sous AD apparaitra dans O365 sous “Groupes” en tant que “Liste de distribution” et dans EAC sous “Destinataires -> Groupes” en tant que Liste de distribution. Il faut lui définir une adresse mail, sans quoi son intérêt est très limité (il semble qu’il n’apparaisse as dans EAC si pas d’adresse mail renseignée).
C’est un alias qui va rediriger le courrier envoyé à l’adresse en question vers tous les membres inclus dedans (permet une gestion différente des groupes de sécurité).
Si un sous-groupe est lui-même membre du groupe, les utilisateurs de ce sous-groupe ne recevront le mail QUE SI le sous-groupe a une adresse de messagerie renseignée dans ses propriétés.
L’autorisation “Send As” ne peut être définie que directement dans le EAC. Par contre, si le groupe a été créé sur AD, l’autorisation “Send On Behalf” est définie dans ADSI, sous l’attribut “publicDelegates”. Il faut toujours attendre quelques (dizaines de) minutes pour que les changements soient effectifs sous Exchange.
Dans certains cas, le client Outlook d’un utilisateur peut rester “bloqué” sur l’intention d’envoyer “de la part de” (on behalf), ce qui echouera si la seule autorisation accordée est “send as”. Pour “réinitialiser” le comportement du client, il faut désactiver puis réactiver le mode “en cache” du compte Exchange.
Il s’agit d’une boîte à part entière, avec son propre stockage/quota (quota de 99Go à l’heure de cet article). Elle permet de centraliser des messages partagés par plusieurs utilisateurs, ainsi que le calendrier. Sur l’Outlook de l’utilisateur, la boîte sera distincte de celle de l’utilisateur.
Elle permet également de partager un calendrier entre tous les utilisteurs.
Comme nous n’avons dans le cas présent pas de serveur Exchange en local, il ne me semble pas possible d’en créer une sur l’AD. Elle peut être créée dans l’EAC sous “Destinataires -> Boîte aux lettres partagée”.
Elle n’apparaitra pas dans l’AD, mais dans O365 sous les “Utilisateurs actifs”, et bien sûr dans l’EAC.
Dans le centre d’administration Exchange (EAC), on peut aller dans Recipients -> Shared, et créer une boite aux lettres partagées. Tous les utilisateurs qui sont entrés dans les propriétés de la boite partagée -> Mailbox delegation -> Full access verront la boite mail ainsi que son calendrier se déployer automatiquement sur leur client Outlook (avec toutefois un délai jusqu’à une heure).
Ceci correspond à une vraie boîte mail à part entière, avec son propre espace de stockage (quota de 99Go à l’heure de cet article) et apparaitra sur le client outlook séparée de la boite principale.
Il semblerait que l’ajout d’un groupe de sécurité, même avec adresse mail renseignée, ne déploie pas automatiquement les boites et calendriers chez les membres du groupe.
Dans le EAC -> Recipients -> Groups, on peut créer des listes de distributions. Ceci ne correspond pas à une vraie boîte mail, mais plutôt à un alias. Les messages sont transférés à tous les utilisateurs définis dans les propriétés de la liste -> Membership.
Si on souhaite qu’un utilisateur puisse écrire depuis l’adresse de la liste de distribution, il faut ajouter l’utilisateur en question dans les propriétés de la liste -> Group delegation, et ajouter son nom sous Send As (envoi en tant qu’alias) ou bien Send on Behalf (envoi en tant que user au nom de alias).
Pour que l’utilisateur puisse envoyer des messages depuis sont Outlook (version de bureau), il faut ajouter le champ De qui est masqué par défaut. Sous 2016, ceci peut se faire dans la fenêtre de rédaction d’un message, sous l’onglet Options. Ensuite, on ajoute à la main le nom de l’alias qui doit servir à envoyer le message. Si les paramètres serveur sont corrects, l’envoi devrait fonctionner. Sinon, essayer de désactiver puis réactiver le mode “en cache” du compte Exchange.