Après avoir installé DirSync, par défaut, l'intervalle de synchronisation entre votre AD et Office 365 est de 3h. Vous pouvez modifier cette valeur (augmentation ou diminution) ou alors forcer, à l'aide de PowerShell, une synchronisation.

Pour ce faire, lancez une console PowerShell en tant qu'administrateur depuis le serveur où DirSync est installé. Entrez la commande suivante afin de charger le module DirSync :

Import-Module DirSync

Une fois le module chargé, déplacez-vous dans le dossier C:\Program Files\Windows Azure Active Directory Sync\DirSync puis sourcez le fichier ImportModules.ps1 en entrant la commande suivante :

.\ImportModules.ps1

Dès que ceci est effectué, entrez la commande suivante :

Start-OnlineCoexistenceSync

L'équipe produit PowerShell à annoncer il y a quelques heures qu'ils venaient de publier la version 2 des Azure DSC Extension.

Pour plus d'information, voici le lien de l'article : http://blogs.msdn.com/b/powershell/archive/2015/06/17/azure-dsc-extension-v2-0-released.aspx

Pour plus d'information sur l'historique des versions c'est par ici : http://blogs.msdn.com/b/powershell/archive/2014/11/20/release-history-for-the-azure-dsc-extension.aspx

Après avoir installé et configuré DirSync, l'intervalle de synchronisation entre votre domaine et Office 365 est de 3h par défaut. Il est possible de modifier la valeur de la clé SyncTimeInterval située dans le fichier C:\ProgramFiles\Windows Azure Active Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.Config.

Dans la capture d'écran ci-dessous j'ai modifié la valeur à 12h. La synchronisation entre le domaine et Office 365 se fera donc 2 fois par jour :)

Dans Office 365, vous pouvez créer vos utilisateurs via la console d'administration ou via PowerShell. Dans le cas ou vous utilisez PowerShell, il faut attribuer une licence à votre utilisateur après l'avoir créer. Pour ce faire, voici la liste des commandes à exécuter :

$sku = Get-MsolAccountSku

La commande ci-dessus permet de récupérer son abonnement

New-MsolUser -UserPrincipalName "demo@yourdomain.onmicrosoft.com" -DisplayName "Demo User" -FirstName "Demo" -LastName "USER" -UsageLocation FR

La commande ci-dessus permet de créer un nouvel utilisateur

Set-MsolUserLicense -UserPrincipalName "demo@yourdomain.onicrosoft.com" -AddLicenses $sku.AccountSkuId

La commande ci-dessus permet d'attribuer une licence pour cet utilisateur

Microsoft à annoncé hier que l'équipe PowerShell allait officiellement supporté SSH mais aussi contribuer au projet OpenSSH Community. Pour plus d'information voici le lien du blog post officiel : http://blogs.msdn.com/b/powershell/archive/2015/06/03/looking-forward-microsoft-support-for-secure-shell-ssh.aspx

Par défaut, tous les utilisateurs créés dans un domaine sont "stockés" dans le container Users si aucune OU n'est spécifiée (par exemple lorsque l'on créé les utilisateurs en utilisant PowerShell). A des fins de gestion (GPO), il est fortement conseillé de le changer.

Pour ce faire, il vous faudra le DN (Distinguished Name) complet de l'OU cible qui sera votre nouveau "container" par défaut pour vos utilisateurs. Dans mon cas, le DN est "OU=Users,OU=LAB,DC=LAB,DC=LAN". Afin de modifier votre emplacement par défaut, tapez la commande redirusr suivi de votre DN comme ci-dessous :

• redirusr "OU=Users,OU=LAB,DC=LAB,DC=LAN"

Bonjour tout le monde,

Un petit post non technique pour faire une peu de pub pour SF2i, la société dans laquelle je travaille :)

Microsoft nous a décerné le titre de Partenaire Microsoft de l'année en Nouvelle-Calédonie (https://goo.gl/e3RTAf) !

C'est une 1ère en Nouvelle-Calédonie et c'est pour moi une grande fierté de travailler dans cette société :)

Je profite de ce post pour féliciter tous les collaborateurs de SF2i qui ont permis de remporter ce titre et pour remercier le gérant de l'entreprise, qui sait nous faire confiance et nous permet de réaliser pleinement tous nos projets ! Je remercie également tous nos partenaires ainsi que nos clients qui nous font confiance.

Bonne journée :)

Bonjour à tous.

Aujourd'hui, je vous propose une petite astuce qui vous permet de modifier le container par défaut au niveau duquel les ordinateurs intégrés à l'AD sont mis. En effet, par défaut, tous les ordinateurs intégrés dans un domaine (poste client ou serveur) sont "stockés" dans le container Computers. A des fins de gestion, il est fortement conseillé de le changer (GPO).

Pour ce faire, il vous faudra le DN (Distinguished Name) complet de l'OU cible qui sera votre nouveau "container" par défaut. Dans mon cas, le DN est "OU=Computers,OU=LAB,DC=LAB,DC=LAN". Afin de modifier votre emplacement par défaut, tapez la commande redircmp suivi de votre DN comme ci-dessous :

• redircmp "OU=Computers,OU=LAB,DC=LAB,DC=LAN"

Dans cet article nous allons voir :

• Comment installer le rôle DHCP en PowerShell
• Comment autoriser le serveur DHCP dans l'AD
• Comment créer des scopes DHCP

Etape 1 : Installation du rôle

Afin de pouvoir installer le rôle DHCP, nous allons utiliser la commande suivante :

Install-WindowsFeature DHCP -IncludeManagementTools

Le paramètre -IncludeManagementTools permet d'installer la console d'administration DHCP

Etape 2 : Autorisation du serveur DHCP dans l'AD

Maintenant que vous avez installé votre rôle, il vous faut autoriser votre serveur au niveau de votre AD. Pour ce faire, entrez la commande suivante :

Add-DHCPServerInDC -DNSName Nom_Serveur

Au niveau du paramètre -DNSName, pensez à entrer le FQDN de votre serveur (Nom_Serveur.Votre_Domaine)

Etape 3 : Configuration d'un scope DHCP

Maintenant que votre rôle est ajouté et que votre serveur est autorisé dans l'AD, vous pouvez ajouter vos scopes. Dans le cadre de cet article, un seul scope basique sera configuré tel qu'indiqué ci-dessous :

• Nom : LAB-PC
  
• Description : Plage DHCP des ordinateurs du domaine LAB
• Plage IP : De 192.168.100.100 à 192.168.100.200
• Passerelle par défaut : 192.168.100.2
• Serveur DNS : 192.168.200.10

Création de l'option de serveur DNS :

Set-DhcpServerv4OptionValue -DNSServer 192.168.100.10 -DNSDomain lab.lan -Router 192.168.100.2

Création du scope :

Add-DhcpServerv4Scope -Name "LAB-PC" -StartRange 192.168.100.100 -EndRange 192.168.100.200 -SubnetMask 255.255.255.0 -Description "Plage DHCP des ordinateurs du domaine LAB"

Votre serveur DHCP est maintenant installé, autorisé dans votre AD et votre scope est configuré. Vous pouvez vérifiez cela en ouvrant la console DHCP.

Bonne configuration :)

Pour tous ceux d'entre vous qui font des installations SharePoint et qui utilisent AutoSPInstaller GUI pour configurer AutoSPInstaller, j'ai été agréablement surpris ce matin en voyant que les développeurs en avaient fait une version web :) L'URL de ce site est : https://autospinstaller.azurewebsites.net/

Une fois sur le site vous avez 2 possibilités :

• Démarrer une configuration de 0 et le site vous génèrera un fichier XML : Option Load Default Template sur la page d'accueil
• Fournir un de vos fichiers XML de configuration afin de le modifier : Option Load From My XML sur la page d'accueil

Si vous n'avez pas internet au moment de la configuration, pas de panique ;) La version graphique existe toujours mais elle est considérée comme dépréciée par les développeurs de l'application.

Bonnes installations SharePoint :)

Si vous avez mis en place le content type hub et qu'au moment de la configuration vous vous êtes trompé au niveau de l'URL renseignée, vous vous êtes probablement rendu compte qu'il n'était pas possible de modifier cette URL via l'interface.

Si vous êtes dans ce cas, ne vous inquiétez pas. Il est possible de modifier cette URL mais uniquement en utilisant PowerShell.
Pour ce faire, il faut utilisant cette commande : Set-SPMetadataServiceApplication -Identity "Votre_Application_De_Service" -HubURI "http://votre_nouvelle_url"

Attention, en exécutant cette commande, un avertissement apparaîtra à l'écran. Ce dernier vous indique qu'en réalisant cette action, il faudra absolument republier tous les types de contenu.

Ceci fonctionne avec SharePoint 2010 et 2013.

Aujourd'hui, une petite astuce pour créer une valeur de registre de type DWORD.

Supposons que la clé de registre HKCU:\Software\Sylver existe déjà et que je veuille créer une valeur de type DWORD ayant pour nom "MyDWORD" et pour valeur 5.

Voici la commande PowerShell à utiliser : New-ItemProperty "HKCU:\Software\Sylver\" -Name "MyDWORD" -Value 5 -PropertyType "DWORD" 

On peut ensuite aller vérfier dans l'éditeur de registre si la valeur a bien été créé.

Avec Hyper-V (version Windows Server 2012R2 et Windows 8.1 Pro/Ent), il est très très simple de récupérer la liste de toutes les machines hébergées sur un hôte Hyper-V.

La seule commande à connaitre est : Get-VM

Si on veut lister uniquement les machines virtuelles étant démarrées : Get-VM | Where-Object State -eq 'Running'

Hello tout le monde,

Pendant l'Ignite Microsoft a dévoilé pas mal de chose sur les nouveaux produits dont SharePoint 2016.

Voici un petit article sur lequel je suis tombé indiquant les nouveautés concernant le déploiement de SharePoint : http://blogs.technet.com/b/wbaer/archive/2015/05/12/what-s-new-in-sharepoint-server-2016-installation-and-deployment.aspx

Vivement qu'on puisse mettre la main sur cette nouvelle mouture de SharePoint et qu'on puisse s'amuser avec :)

Attention : SharePoint 2016 étant encore en développement, cet article peut évoluer.

Il n'y a pas très longtemps, j'ai eu besoin de lister tous les services Windows arrêtés sur un serveur et de redémarrer ceux ayant un statut de démarrage à Automatique.

J'ai donc tout de suite pensé à Get-Service. Cependant, après avoir tous les membres disponibles, aucun ne permet de récupérer le statut de démarrage d'un service. Surement un oubli de la part de Microsoft.

Je me suis donc tourné vers notre très chère amie Get-WMIObject [:P] Voici la commande :

Get-WmiObject win32_service | select name, startmode,state | Where-Object -FilterScript {($_.State -eq "Stopped") -and ($_.startmode -eq "Auto")} | Start-Service

Expliquons maintenant chaque partie du pipeline de cette longue commande. Get-WmiObject win32_service | select name, startmode,state  permet de récupérer les services Windows en ne filtrant que sur le nom, le mode de démarrage et l'état du service.

Where-Object -FilterScript {($_.State -eq "Stopped") -and ($_.startmode -eq "Auto")} permet de filtrer sur les services étant arrêtés ($_.State -eq "Stopped") et ayant un mode de démarrage automatique ($_.startmode -eq "Auto").

Une fois ces éléments récupérés, nous pouvons taper la commande Start-Service afin ne démarrer que les services ayant un mode de démarrage automatique et étant arrêtés.

Avant toute chose, je tiens à préciser que ceci n'est en aucun cas une solution qui doit être déployée sur des serveurs de production !

J'utilise cela uniquement sur certains serveurs de tests que je mets en place dans le cadre de lab lorsque ces derniers sont connectés à Internet.

Ceci étant dit, ce billet de blog vous décrit comment vous pouvez installer Microsoft Security Essentials (MSE pour les intimes) sur une plateforme Windows Server (testé 2008R2, 2012 ou 2012R2).

Par défaut, si vous téléchargez MSE et que vous tentez de l'installer sur un serveur, vous avez le message d'erreur : Microsoft Security Essentials cannot be installed on your operating system

Il existe cependant une astuce permettant de l'installer. Après avoir téléchargé l'exe de MSE, il faut régler le mode de compatibilité afin que le programme s'exécute en mode Windows 7. Pour ce faire, effectuez un clique droit sur l'exe et cliquez sur Propriétés.

Une nouvelle interface apparaît à l'écran. Dirigez-vous vers l'onglet Compatibilité puis cochezl'option Exécuter ce programme en mode de compatibilité pour et sélectionnez l'option Windows 7.

Une fois ceci effectué, ouvrez une console en tant qu'administrateur, dirigez-vous dans le dossier contenant l'exe de MSE puis exécutez la commande mseinstall /disableoslimit. Vous devriez pouvoir installer MSE à la suite de cela.

Après avoir entré cette commande, on constate que l'assistant d'installation s'ouvre et nous permet d'installer MSE.

Vous pouvez, par la suite, mettre à jour et utiliser MSE sur votre serveur.

Encore une fois, ceci n'est pas du tout préconisé pour des environnements de production.

Ces derniers temps je monte pas mal d'environnement SharePoint pour des clients avec Office Web Apps 2013 (OWA pour les intimes).

Pour information, OWA 2013 peut être installé sur un serveur Windows Server 2008R2, Windows Server 2012 ou Windows Server 2012R2. Un certain nombre de pré-requis sont obligatoires afin qu'OWA puisse être installé.

Vous trouverez sur mon repository GitHub un petit script permettant d'installer ces pré-requis sur un serveur Windows Server 2012 ou Windows Server 2012R2. Afin de pouvoir exécuter ce script, vous devez disposer du dossier SXS (présent dans l'ISO d'installation de Windows Server).

Voici un exemple d'utilisation du script d'installation des pré-requis (supposons que l'ISO de Windows Server 2012 est dans le lecteur DVD qui porte la lettre D) : 

• .\OWA13_Install-ServerPrerequisites.ps1 -SXSFolder "D:\Sources\sxs"

Si lors de votre installation de SharePoint 2013, vous avez laissé l'emplacement par défaut des logs (ULS et Usage & Health), il se situe dans le dossier C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\LOGS.

Une bonne pratique est de ne pas mettre ces logs sur le disque C. Si vous voulez les déplacer, disons sur le disque E, voici les commandes PowerShell à exécuter :

• Déplacer les logs ULS : Set-SPDiagnosticConfig -LogLocation "E:\SharePoint\Logs\ULS"
• Déplacer les logs Health & Usage : Set-SPUsageService -UsageLogLocation "E:\SharePoint\Logs\UsageHealth"

Ces 2 commandes ne fournissent aucun retour. Une fois ces dernières tapées, vérifiez que vos logs ont bien été déplacés.

J'ai créé un script qui permet de déplacer les logs ULS et Health & Usage. Voici comment l'utiliser :

SP_Move-SPLogs.ps1 -ULSLog "E:\SharePoint\Logs\ULS" -HealthUsageLog "E:\SharePoint\Logs\HealthUsage"

Pour télécharger ce script, c'est par ici :)

Si, lors de la conception de vos scripts, vous avez besoin de connaître le nom de la machine sur laquelle le script s'exécute voici une commande que vous pouvez utiliser :

• [system.environment]::MachineName

Vous pouvez également taper cette commande directement dans une console PowerShell afin de connaître le nom de votre machine.

Aujourd'hui, je montais une machine virtuelle de test au niveau de laquelle je mettais en place :

• Active Directory Domain Services (le domaine mis en place est lab.local)
• SQL Server 2008R2
• SharePoint 2010

Mon administrateur SQL se situe dans un groupe de sécurité de type Global se nommant SQLAdmins et mon administrateur SharePoint est membre d'un groupe de sécurité de type Global ayant pour nom SPAdmins.

Ces 2 groupes doivent absoluement être dans le groupe local Administrators du serveur. Hors, ayant mis un place un AD et mon serveur étant un contrôleur de domaine, il n'est plus possible d'accéder à l'interface graphique permettant d'effectuer cette action. La seule solution est d'utiliser notre bonne vieille ligne de commande cmd.

Afin de pouvoir ajouter ces 2 groupes globaux à mon groupe local Administrators, voici les 2 commandes que je dois entrer dans ma console cmd lancée en tant qu'administrateur :

• net localgroup Administrators /add LAB\SQLAdmins : Ajout du groupe SQLAdmins dans le groupe local Administrators
• net localgroup Administrators /add LAB\SPAdmins : Ajout du groupe SPAdmins dans le groupe local Administrators

Dans les commandes ci-dessus, remplacez LAB par le nom de votre domaine et SQLAdmins et SPAdmins par le nom de votre groupe ou de votre utilisateur. Si vous être sur un OS en français, remplacez Administrators par Administrateurs.

Enfin, pour vérifier que votre commande a été exécutée avec succès, entrez la commande :

net localgroup Administrators

Remplacez Administrators par Administrateurs sur un OS en français. Vous devriez voir apparaître vos groupes ou utilisateurs.

J'ai récemment fait un article sur comment récupérer tous les utilisateurs stockés dans vos groupes AD en utilisant un script PowerShell.

J'ai fait évoluer ce script pour lister également les ordinateurs et les groupes imbriqués. Un fichier de sorti est toujours généré suite à l'exécution du script est ce dernier sera du type :

Le script utilise les commandes PowerShell suivantes :

• Get-ADGroup : Avec le paramètre "-Filter *", cette commande permet de récupérer les groupes AD. Cette commande (sans l'option -Filter *) permet également de récupérer les groupes imbriqués dans un autre groupe
• Get-ADGroupMember : Permet de récupérer les membres d'un groupe AD
• Get-ADUser : Avec le paramètre "-Properties Enabled", cette commande permet de récupérer l'état du compte (actif ou désactivé).
• Get-ADComputer : Permet de récupérer les objets ordinateurs

J'ai ensuite utilisé des foreach afin de boucler sur les groupes, les ordinateurs et les comptes utilisateurs. J'utilise également des conditions if/else afin de pouvoir filtrer et loguer (si c'est un compte utilisateur, s'il est actif ou non, si c'est un compte ordinateur ou un groupe).

La liste des paramètres à fournir au script :

• LogFilePath : Chemin du fichier de log qui sera généré par le script. Attention, ce chemin doit finir par un "\".

Un exemple d'exécution du script : .\AD_Get-ADObjectsByGroup.ps1 -LogFilePath "D:\Logs\"

Pour télécharger le script : C'est par ici

Récemment, un client m'a demandé de lui transmettre un fichier plat contenant tous les groupes AD avec les membres de chacun de ces groupes, ainsi que l'état du compte (activé ou non). Le fichier devait être du type : 

NOM_DU_GROUPE :

- User 1 -> Enable
- User 2 -> Disable
- User 3 -> Enable
- ...

Afin de pouvoir réaliser cette action, j'ai uniquement besoin de 3 commandes : 

• Get-ADGroup : Avec l'option "-Filter *", cette commande permet de récupérer tous les groupes AD
• Get-ADGroupMember : Commande permettant de récupérer tous les membres d'un groupe
• Get-ADUser : Avec le paramètre "-Properties Enabled", cette commande permet de récupérer l'état du compte (actif ou désactivé)

J'ai ensuite utilisé des foreach afin de boucler sur tous les groupes et tous les utilisateurs. J'ai également utilisé des Write-Host et Write-Output afin d'écrire sur la console et d'écrire dans un fichier.

La liste des paramètres à fournir au script :

• LogFilePath : Chemin du fichier de log qui sera généré par le script. Attention, ce chemin doit finir par un "\".

Un exemple d'exécution du script : .\AD_Get-ADUserByGroup.ps1 -LogFilePath "D:\Logs\"

Pour télécharger le script : C'est par ici.

Ce script peut bien entendu être amélioré; notamment au niveau du fichier de sortie (création d'un csv ou xml ou directement d'un fichier Excel avec plusieurs onglets - ajout de vérification, try catch, ...). Je vous laisse améliorer ce script en fonction de vos besoins.

Suite à une installation du SP2 de SQL Server 2012 chez un client cette semaine, un collègue et moi même sommes tombés sur un petit souci qui a pris quelques heures à être résolu.

Description du contexte

L'infrastructure sur laquel nous travaillions est composée de 2 serveurs Windows Server 2012R2 au niveau desquels il y a un cluster SQL Server 2012 RTM de 2 noeuds (N01 et N02).

Lorsque vous disposez d'un cluster SQL, l'installation des SP ou mises à jour SQL doivent se faire sur le noeud passif. Dans le cadre de ce post, le noeud passif est le N02. Une fois l'installation du SP2 terminée avec succès sur N02, il faut le faire sur N01. Hors, ce dernier étant le noeud actif, il est donc impératif de basculer le rôle SQL Server sur N02 afin que ce dernier deviennent actif et que N01 devienne le noeud passif. En effet, il est fortement conseillé de mettre à jour un noeud passif dans un cluster. Une fois N01 passif, il sera alors possible d'installer le SP2 sur ce noeud.

Après l'installation du SP2 sur le noeud N02, au moment de réaliser la bascule du rôle SQL Server sur ce dernier, une erreur est survenue empêchant la bonne éxécution de la bascule. Étant donné qu'il est indispensable que cette bascule ait eu lieu pour pouvoir installer le SP2 sur le noeud N01, Il nous était donc impossible d'effectuer cette installation. L'erreur se manifestait en empêchant le moteur SQL de démarrer ... Plutôt génant pour pouvoir effectuer la bascule et, à terme, se servir de son cluster SQL !

Un rapide parcours de la console des évènements critiques SQL Server permet de récupérer l'ID de l'erreur et de faire quelques recherches sur Internet qui s'avèrent être inutiles ... L'ID retourné était la 1069.

En allant jeter un coup d'oeil au service SQL Server, on se rend compte que le code de sortie est le 1067. Ce dernier est un code de sortie assez général indiquant que le service n'a pas réussi à démarrer. Ceci ne nous aide donc pas beaucoup à la résolution de l'erreur.

Résolution

Après avoir effectué plusieurs recherches sur internet et testé quelques résolutions trouvées ci et là, aucunes de ces dernières n'étaient fructueuses et la bascule ne se faisait donc toujours pas sur le noeud N02.

En regardant les services de la console de configuration SQL, nous nous sommes rendu compte que le mode de démarrage du service SQL Browser était sur désactivé. En effet, pour des raisons de sécurité, il est fortement conseillé de le désactiver, sauf si vous utilisez des services qui ont besoin du Browser pour pouvoir fonctionner.

Après avoir repasser le mode de démarrage à manuel pour le service SQL Browser et après l'avoir démarré, nous avons alors rententé d'effectuer une bascule. Et la, miracle ... la bascule s'est faite.

Après avoir effectué la bascule sur le noeud N02, la mise à jour du noeud N01 a pu se faire. Il fallait également démarrer le service SQL Server Browser sur ce noeud afin de pouvoir ré-effectuer une bascule dans le sens opposé.

La leçon à retenir, et la solution qui a permis de résoudre notre problème, est qu'il ne faut pas que les services SQL soient désactivés lors d'une bascule des rôles sur le serveur SQL venant d'être mis à jour !

Pour tous ceux qui en auraient besoin, vous trouverez ci-dessous les liens de téléchargement du SP2 de SQL Server 2012 (français et anglais).

Lien de téléchargement du SP2 de SQL Server 2012 en anglais : http://www.microsoft.com/en-us/download/details.aspx?id=43340

Lien de téléchargement du SP2 de SQL Server 2012 en français : http://www.microsoft.com/fr-FR/download/details.aspx?id=43340

Dans le cas où vous auriez besoin de fournir un credential sans avoir aucune interaction humaine (dans le cadre d'un script notamment), il vous sera indispensable de créer un objet de type PSCredential qui va vous permettre de stocker de manière sécurisée votre credential. Vous pourrez ensuite utiliser cet objet au niveau de votre script afin de fournir à ce dernier les credentials nécessaires à sa bonne exécution.

$user = "Administrator"
$pwd = ConvertTo-SecureString "MyP@55w0rd" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($user,$pwd)

Vous pouvez maintenant utiliser l'objet $cred pour fournir le credential de l'utilisateur Administrator.

Afin de pouvoir intégrer une machine à votre domaine en PowerShell, il faut utiliser la cmdlet Add-Computer avec les paramètres suivant :

• DomainName : Permet de spécifier votre domaine
• DomainCredential : Permet de fournir le compte utiliser afin d'entrer la machine dans le domaine
• OUPath : Permet de spécifier l'OU dans laquelle vous voulez mettre votre machine

Dans mon cas, le domaine est lab.local. Je dipose d'une OU nommée Computers située elle-même dans une OU nommée LAB. Ma commande est donc la suivante :

Add-Computer -DomainName lab.local -DomainCredential administrator@lab.local -OUPath "OU=Computers,OU=LAB,DC=lab,DC=local"

Après avoir entré cette commande, une fenêtre apparaît à l'écran vous demandant d'entrer le mot de passe du compte administrator. Entrez-y le mot de passe puis cliquez sur le bouton OK.

Une fois ceci effectué, vérifiez que votre machine a bien été ajouté dans la bonne OU.

Bien entendu, vous devez redémarrer votre machine pour que le changement prenne effet.