Hello,

Today I'm writing a little article on how to deploy ADDS on a server core.

Installation of the role

If you want to deploy ADDS, you need to enter the following command : Add-WindowsFeature -Name "ad-domain-services" -IncludeAllSubFeature

Deployment of the 1st domain controller in the Forest

To deploy you first domain controller, you need to create some variables. They will contained some mandatory values needed by the PowerShell command (for more information --> https://technet.microsoft.com/en-us/library/hh974720(v=wps.630).aspx) :

$CreateDnsDelegation = $false
$DomainName = "demo.lan"
$NetbiosName = "DEMO"
$NTDSPath = "C:\Windows\NTDS"
$LogPath = "C:\Windows\NTDS"
$SysvolPath = "C:\Windows\SYSVOL"
$DomainMode = "WinThreshold"
$InstallDNS = $true
$ForestMode = "WinThreshold"
$NoRebootOnCompletion = $false
$SafeModeClearPassword = "P@$$w0rd"
$SafeModeAdministratorPassword = ConvertTo-SecureString $SafeModeClearPassword -AsPlaintext -Force

The next step is to execute the following command (it will create your domain and promote your server as a domain controller) : 

$forest = Install-ADDSForest -CreateDnsDelegation:$CreateDnsDelegation `
-DomainName $DomainName `
-DatabasePath $NTDSPath `
-DomainMode $DomainMode `
-DomainNetbiosName $NetbiosName `
-ForestMode $ForestMode `
-InstallDNS:$InstallDNS `
-LogPath $LogPath `
-NoRebootOnCompletion:$NoRebootOnCompletion `
-SysvolPath $SysvolPath `
-SafeModeAdministratorPassword $SafeModeAdministratorPassword `
-Force:$true

Bonjour tout le monde,

Un petit blog post sur comment installer ADDS sur un server Core (déploiement de la fonctionnalité & création du 1er contrôleur de domaine de la forêt).

Déploiement du rôle

Afin de déployer le rôle Active Directory Domain Services , il suffit de taper la commande suivante : Add-WindowsFeature -Name "ad-domain-services" -IncludeAllSubFeature

Déploiement du 1er contrôleur de domaine

Afin de pouvoir déployer notre premier contrôleur de domaine de la forêt, il nous faut mettre en place certaines variables indispensables à la bonne exécution de la commande PowerShell (pour plus de détail sur ces dernières --> https://technet.microsoft.com/en-us/library/hh974720(v=wps.630).aspx :

$CreateDnsDelegation = $false
$DomainName = "demo.lan"
$NetbiosName = "DEMO"
$NTDSPath = "C:\Windows\NTDS"
$LogPath = "C:\Windows\NTDS"
$SysvolPath = "C:\Windows\SYSVOL"
$DomainMode = "WinThreshold"
$InstallDNS = $true
$ForestMode = "WinThreshold"
$NoRebootOnCompletion = $false
$SafeModeClearPassword = "P@$$w0rd"
$SafeModeAdministratorPassword = ConvertTo-SecureString $SafeModeClearPassword -AsPlaintext -Force

Une fois ces variables créées, nous pouvons installer notre premier contrôleur de domaine de la forêt en tapant la commande suivante :

$forest = Install-ADDSForest -CreateDnsDelegation:$CreateDnsDelegation `
-DomainName $DomainName `
-DatabasePath $NTDSPath `
-DomainMode $DomainMode `
-DomainNetbiosName $NetbiosName `
-ForestMode $ForestMode `
-InstallDNS:$InstallDNS `
-LogPath $LogPath `
-NoRebootOnCompletion:$NoRebootOnCompletion `
-SysvolPath $SysvolPath `
-SafeModeAdministratorPassword $SafeModeAdministratorPassword `
-Force:$true

Hello tout le monde,

J'ai réalisé pas mal de migrations de messagerie On-Prem (Exchange et principalement non Exchange) vers Office 365 depuis ces 2-3 dernières années et j'ai également répondu à des d'appels d'offres traitant de ce sujet (ou il fallait chiffrer la prestation mais également les licences du produit de migration et les licences Office 365). Voici un petit retour d'expérience sur quelques informations qu'il faut fournir (notamment dans l'appel d'offres) et qui sont bien souvent manquantes (pour une partie d'entre elles) :

• Le logiciel de messagerie utilisé : Il est important de fournir le logiciel de messagerie utilisé ainsi que sa version.
• Le type de connexion Internet et le débit : En Nouvelle-Calédonie, nous avons un Internet qui n'est pas aussi rapide qu'en Europe ou en Amérique de Nord (surtout en Upload, on est souvent limité à 1Mo si on est abonné ADSL. Il est possible d'avoir plus si on dispose d'une LS ou du RFIP). Il est donc important de fournir cette information nous permettant d'estimer les temps de migration.
• Le nombre de BAL : Bien souvent le nombre d'utilisateurs et fournis mais pas le nombre de BAL (boîtes aux lettres). Il est important de connaître le nombre de BAL individuelles et partagées exactes qu'il faudra migrer (les BAL partagées sont souvent oubliées).
• Utilisation ou non de liste de distribution et si oui combien : Cela nous permet de savoir s'il faudra en recréer et combien il faudra en recréer (cette tâche étant normalement scriptée à l'aide d'un fichier d'entrée contenant les listes à créer ainsi que leurs membres).
• Utilisation des ressources (salles de réunions, véhicules, ...) et si oui combien : Ceci est souvent utile pour les licences du produit de migration (pour les solutions de messagerie On-Prem non Microsoft type Lotus par exemple que l'on migre vers Office 365). En effet, les produits de migration imposent souvent l'achat d'une licence pour chaque ressource que nous migrons (je parle pour les produits de migration que j'ai pu utiliser, je ne les connais bien entendu pas tous).
• La volumétrie globale des BAL actives : Ceci permettra d'estimer le temps global de migration (en fonction du débit mais aussi des limitations Microsoft --> https://technet.microsoft.com/en-us/library/dn592150(v=exchg.150).aspx).
• La volumétrie moyenne d'une BAL
• Est-ce qu'il y a des archives à migrer : Les archives sont souvents oubliés dans les appels d'offres. Il est important d'indiquer s'il y a des archives, si celles-ci doivent être migrées. Il est également important d'indiquer si elles sont sur le serveur ou sur les postes utilisateurs.
• S'il y a des archives, la volumétrie globale des archives : Ceci permettra d'estimer le temps global de migration (en fonction du débit mais aussi des limitations Microsoft --> https://technet.microsoft.com/en-us/library/dn592150(v=exchg.150).aspx).
• S'il y a des archives et que ce paramètre est connu, la volumétrie moyenne d'une archive
• Quelle est la stratégie de reprise des données : Est-ce que l'intégralité des mails doivent être migrés pour chaque BAL ou ne migrons-nous que les 6 derniers mois ou la dernière année ou les 2 dernières années ? Que faisons-nous des archives (les mettre sur les postes uniquement ou les envoyer dans l'archive online) ?
• Y a t'il des dossiers publics (ou technologie équivalente sur d'autre technologie non Microsoft) : S'il y en a préciser la volumétrie.
• Quelle stratégie de migration voulez-vous utiliser : Si vous savez déjà comment vous voulez migrer, indiquez le (migration "big bang", cohabitation, ...). En cas de cohabitation, indiquez si vous voulez que les 2 systèmes se "voient" (est-ce que les personnes de "l'ancien système" doivent pouvoir voir les disponibilités du calendrier de ceux présents sur le nouveau système, ...).
• Faut-il synchroniser l'Active Directory local de l'entreprise avec Office 365 : Ceci est une information importante permettant de connaître la stratégie de gestion des utilisateurs et qui influt sur l'architecture à mettre en place (mise en place d'un serveur supplémentaire pour la synchronisation). Il est faut également préciser si la synchronisation des mots de passe doit être mise en place ou non.
• Est-ce qu'il faut mettre en place du SSO : Le SSO permettra aux utilisateurs de ne pas avoir à retaper leur mot de passe lorsqu'ils sont authentifiés sur leur session Windows de domaine. Ce paramètre va influer sur l'architecture à mettre en place (plusieurs serveurs supplémentaires devront être configurés).
• Y a t'il des équipements ou logiciels qui utilisent le SMTP On-Premise pour envoyer des mails : Les copieurs fournissent la possibilité de "Scan To Mail" et beaucoup d'applications envoient automatiquement des emails. Si c'est le cas, il faudra mettre en place et configurer un relais SMTP.

Le fait de connaître les volumétries nous permet d'estimer les temps d'upload des BAL actives et des archives dans le cloud et la taille moyenne d'une BAL active / archive nous permttra de réaliser un planning de migration en fonction de la volumétrie migrable par journée de migration (souvent nuit et week-end de migration pour ne pas impacter les utilisateurs en journées).

Bien entendu, pas mal de ces questions peuvent être discutées avec le prestataire afin qu'il vous fournisse la solution la plus adaptée à votre besoin et votre contexte et qu'il vous conseille si vos choix ne sont pas arrêtés (sur la reprise de données ou la migration des archives par exemple).

N'hésitez pas à commenter ou donner vos retours d'expérience :)

Bonjour tout le monde,

Comme je monte pas mal d'AD en ce moment (pour des labs ou des clients), je me suis fait des petits scripts PowerShell pour me faciliter la vie. Récemment, j'y ai même ajouté un interface graphique afin de directement modifier les valeurs de mes variables par le biais de cette interface.

Tout a été intégralement codé en PowerShell avec PowerShell Studio.

Cet outil est composé de deux onglets. Le premier permet de configurer le nom du serveur, son IP, son préfixe réseau, sa gateway et son ou ses serveurs DNS (séparés par des virgules). Une fois toutes les informations renseignées, vous pourrez cliquer sur le bouton Configure Server.

Le second onglet permet de déployer la fonctionnalité ADDS ainsi qu'une nouvelle forêt. Vous pouvez alors renseigner le nom de domaine, le nom NETBIOS, le niveau fonctionnel du domaine (WIN2003 à WIN2016), de la forêt (WIN2003 à 2016) et votre Safemode Password. Une fois toutes les informations renseignées, vous pourrez cliquer sur le bouton Deploy ADDS.

Vous pouvez télécharger le code source PowerShell ainsi que le projet PowerShell Studio ici --> http://bit.ly/2eT4CIf 

Vous trouverez également joint à ce poste, une archive contenant l'exécutable.

Dans le futur, d'autres onglets seront ajoutés pour, par exemple, ajouter un contrôleur de domaine à un domaine existant, déplacer les rôles, ...

N'hésitez pas à me faire des retours sur votre utilisation, les éventuels bugs ou autre :)