Introduction à Windows Server Core

Proposée déjà depuis quelques éditions, la version Core de Windows Server permet de s’affranchir de l’interface graphique habituellement livrée avec le système d’exploitation. Si certaines API graphiques sont disponibles et permettent l’exécution d’applications graphiques comme le bloc-notes, la philosophie de cette version est orientée ligne de commandes et plus précisément Powershell.

Dans ce dernier article de l’année, je vais présenter cette version de Windows en commençant par l’installation, la configuration et quelques exemples d’utilisation du système.

A noter que la version utilisée pour cet article est Windows Server 2019 ; si sur certaines versions précédentes de Windows il était possible d’installer ou désinstaller tout l’environnement graphique une fois l’OS déployé, cela n’est pas possible sur 2019. Il est donc important bien réfléchir au type d’environnement nécessaire avant de procéder à l’installation.

La phase d’installation ne présente aucune différence ; nous choisissons donc la version Windows Server 2019 et non celle avec le Desktop Experience. Une fois l’installation terminée, une fenêtre cmd s’ouvre avec un premier prompt de login.

Mot de passe configuré et utilisateur connecté, nous sommes face à un prompt cmd tout simple. Un outil permet d’effectuer toute la configuration de base du système : cet outil s’appelle sconfig et peut être appelé directement dans le prompt en tapant sconfig.

Nous allons donc renommer la machine, puis lui affecter une adresse IP ; tout ceci se fait sans la moindre ligne de commande. D’autres paramètres sont accessibles, mais je ne vais pas les aborder ici car l’outil est plutôt simple d’usage.

Le serveur a donc son nom et une adresse IP. La prochaine étape va être le déploiement des rôles ADDS et la création d’une nouvelle forêt. Dans un premier temps, il va falloir installer les rôles ADDS, puis ensuite procéder à la création de la forêt. Ceci se réalisant en Powershell, nous allons quitter sconfig pour revenir à notre prompt cmd, puis appeler le moteur Powershell en saisissant simplement powershell.

Cette instruction va installer les rôles :

Install-WindowsFeature -name AD-Domain-Services

Celle-ci va créer la forêt. Les paramètres DomainMode et ForestMode permettent de définir le niveau de fonctionnalité ; ici, WinThreshold représente le niveau maximal (2016). Pour plus d’informations concernant le commandlet Install-ADDSForest, je vous renvoie vers la documentation en ligne.

Install-ADDSForest -DomainName dundermifflin.inc -DomainMode WinThreshold -ForestMode WinThreshold -Database "C:\Windows\NTDS" -SysvolPath "C:\Windows\Sysvol" -Logpath "C:\Windows\Logs"

En validant, il ne reste plus qu’à confirmer que l’on souhaite bien procéder à la création d’une forêt avec un domaine pour que celle–ci commence, puis le serveur redémarre.

Une fois le serveur de nouveau accessible, nous allons nous connecter avec notre nouveau compte Administrator. De nouveau sous Powershell, nous allons voir les rôles et fonctionnalités installés sur le système :

Get-WindowsFeature

Le retour de la commande est vraiment bien fait car il présente hiérarchiquement les rôles et fonctionnalités comme sur la version à interface graphique. Dans le cadre de cet article, nous allons déployer le rôle DFS Namespace car nous souhaitons partager des répertoires et les présenter avec un nom de domaine plus parlant que le nom de la machine. Pour installer une nouvelle fonctionnalité, il suffit de reprendre le nom de la deuxième colonne en paramètre de la commande, comme ceci :

Install-WindowsFeature FS-DFS-Namespace

En validant par entrée, le système va déployer la fonctionnalité. Pour celle-ci, il n’y a pas besoin de redémarrer.

Procédons à la création d’un répertoire qui va être partagé pour être utilisé avec DFS. Ce répertoire nommé docs sera dans C:\dfs.

cd \
mkdir dfs
cd dfs
mkdir docs

Afin d’être déclaré en tant que répertoire DFS, ce répertoire doit être partagé au niveau serveur :

New-SmbShare -Name "docs" -Path "C:\dfs\docs" -FullAccess "DUNDERMIFFLIN\Administrator"

Une fois le répertoire partagé, il peut être ajouté en tant que racine DFS. Ici, je vais procéder à la création d’une racine DFS au niveau domaine. Pour plus d’informations, consultez la documentation en ligne du commandlet New-DfsnRoot.

New-DfsnRoot -TargetPath "\\w2019core01\docs" -Type DomainV2 -Path "\\dundermifflin.inc\docs" -EnableAccessBasedEnumeration:$true

Désormais, je peux parcourir les dossiers partagées grâce à l’URL \\dundermifflin.inc\docs. Procédons à la création d’un répertoire partagé accessible via DFS, nommé dsi.

New-DfsnFolder -Path "\\dundermifflin.inc\docs\dsi" -TargetPath "\\w2019core01\dsi"

Nous avons donc notre répertoire DFS et sa racine, mais pas d’utilisateurs ; notre AD fraîchement installé est toujours vide. Grâce aux modules ActiveDirectory pour Powershell installés, nous allons administrer notre annuaire local en Powershell également. Nous allons créer quelques OU pour ranger nos objets.

New-ADOrganizationalUnit "DUNDERMIFFLIN.INC"
New-ADOrganizationalUnit "Users" -Path "OU=DUNDERMIFFLIN.INC,DC=dundermifflin,DC=inc"
New-ADOrganizationalUnit "Groups" -Path "OU=DUNDERMIFFLIN.INC,DC=dundermifflin,DC=inc"

Ainsi, dans notre AD existera une OU DUNDERMIFFLIN.INC, comprenant 2 autres OU nommées Users et Groups. Procédons à la création d’un utilisateur et d’un groupe :

New-ADGroup -SamAccountName "admins" -Name "Admins" -Path "OU=Groups,OU=DUNDERMIFFLIN.INC,DC=dundermifflin,DC=inc" -GroupScope "Domain"
New-ADUser -SamAccountName "michael.scott" -Name "Michael Scott" -Path "OU=Users,OU=DUNDERMIFFLIN.INC,DC=dundermifflin,DC=inc" -AccountPassword (ConvertTo-SecureString -AsPlainText "Password01" -Force)
Enable-ADAccount "michael.scott"

Ajoutons ce compte au groupe des admins du domaine :

Add-ADGroupMember -Identity "Domain Admins" -Members michael.scott

Puis connectons-nous avec. Tentons d’accéder au répertoire DFS créé plus haut avec le compte de Michael Scott, et nous aurons bien une erreur de droits insuffisants, car nous avons seulement autorisé Administrator à accéder à ce répertoire.

Get-ChildItem \\dundermifflin.inc\docs

Nous allons donc autoriser le compte à accéder à ce partage, mais seulement en lecture.

Grant-SmbShareAccess -Name "docs" -AccountName "michael.scott" -AccessRight Read

En validant, le retour du commandlet va afficher les droits positionnés sur le partage. Si on reexécute la commande plus haut, cela doit désormais fonctionner.

Voici qui conclut pour cette introduction à Windows Server Core. L’administration d’une telle machine n’a rien de spécialement compliqué pour peu que l’on soit habitué à travailler avec Powershell ; de plus la documentation en ligne de Microsoft est une véritable mine d’or permettant d’obtenir les syntaxes des commandlets. Plus une question d’habitude que de véritable connaissance technique, l’administration d’un serveur Core peut également se faire à distance depuis un serveur à interface graphique si ce dernier possède les RSAT (Remote Server Administration Tools) installés. En dehors de certains serveurs applicatifs qui nécessitent une interface graphique, il est tout à fait possible d’avoir une ferme de serveurs d’infrastructure sous Windows tous dépourvus d’interface graphique. Représentant un gain non négligeable de ressources, la démocratisation du mode Core dans une infrastructure pourra également pousser les équipes d’administration à scripter de plus en plus leur travail et tâches récurrentes, à centrer sur un serveur d’administration tous les outils et consoles à distance, ce qui va de pair avec une homogénéisation des processus et un travail plus efficace.

Introduction au Windows Admin Center

Après avoir déployé mon premier Windows Server 2019 sur une plateforme de tests, j’ai été invité à essayer le Windows Admin Center au premier démarrage. Cet outil se veut être le futur de l’administration des plateformes Windows, serveurs et clientes et souhaiterait bien rendre le besoin d’interfaces graphiques sur les serveurs obsolète.

Basé sur une interface web, le Windows Admin Center – que j’appellerai WAC par la suite – est une grosse évolution du Server Manager qui n’avait pas bougé d’un iota ou presque depuis la sortie de Windows Server 2012. Tout comme lui, il fonctionne principalement grâce à WMI et offre un panel d’options pour gérer des serveurs distants (nativement à partir de 2016, avec une installation supplémentaire sur 2012 R2), mais aussi des postes de travail sous Windows 10, des clusters ou des infrastructures plus complètes, en local ou également dans Azure.

Idéalement, on installe le petit MSI d’une soixantaine de méga-octets du WAC sur une machine d’administration et ensuite on attaque cette interface web depuis n’importe quel navigateur, en local ou à distance.

Connexion à l’interface avec prompt de login.

Bien que l’outil soit utilisable en production selon Microsoft, il y a quand même quelques choix de design qui me perturbent : la connexion se fait via un vulgaire prompt et l’outil n’est pas compatible avec Internet Explorer, mais Edge, qui n’est pas disponible sur Windows Server. Cette restriction – techniquement compréhensible – pourrait se révéler handicapante dans certains environnements où l’administration ne se fait qu’à partir d’un serveur et sur lequel aucun autre navigateur est installé.

Au moins Microsoft ne manque pas d’humour quant à l’abandon d’Internet Explorer !

Pour la suite des événements, j’ai donc dû déployer un Firefox sur mon serveur pour naviguer. L’interface est plutôt agréable, typique des produits Microsoft actuels.

La page d’accueil d’un système présente les informations de base, à peu près comme on pouvait les trouver sur le Server Manager avant.

Très peu de dépaysement mais également très peu de nouvelles fonctionnalités. Ce qui est appréciable, c’est que l’on regroupe sous un même outil le Server Manager mais aussi les différentes consoles (regedit, mmc), sans oublier la possibilité d’exécuter du Powershell à distance !

Bon, ça n’a pas fonctionné du premier coup, mais après avoir martelé la touche entrée et saisi mes identifiants, c’est bien passé :

On peut même en théorie se passer des partages administratifs. Cependant, il faudra utiliser un autre navigateur que Firefox car il m’était impossible de parcourir l’arborescence jusqu’au bout. Microsoft ne supporte officiellement que Edge et Chrome – ce qui encore une fois, me paraît être un choix douteux étant donné la réputation de Chrome par rapport au soin apporté concernant la confidentialité des données de navigation.

Le panneau des rôles et fonctionnalités est évidemment inclus dans le WAC

Les fonctionnalités sont plus ou moins les mêmes lorsqu’on administre une station de travail avec Windows 10 ; étant donné qu’il existe déjà des outils de gestion de parc bien installés sur le marché, le WAC devrait rester cantonné à la gestion des serveurs et des infrastructures, d’autant plus qu’il y a de nombreuses intégrations possibles avec Azure (notamment une fonctionnalité de sauvegarde de serveur, que j’aimerais tester dès que possible).

Au final, après quelques heures passées sur l’outil, j’ai plus le sentiment d’avoir à faire à une évolution plus qu’une révolution, même si c’est une petite révolution qui pourra être menée par rapport aux habitudes sur les plateformes Windows. Une évolution, car le WAC ne reste qu’un Server Manager en plus moderne, un peu moins complexe, moins rigide et intégrant différentes consoles MMC ; une révolution car cet outil permet de pousser un peu plus les versions headless (sans interfaces graphiques) de Windows, plus légères et plus facilement administrables à distance. Si les interfaces graphiques avaient un sens pour une facilité d’administration avant et de gestion des fichiers (lorsqu’elles n’étaient pas requises pour un applicatif particulier, évidemment), c’est désormais le cas inverse : elles n’ont plus grand intérêt lorsqu’on peut tout réaliser à distance. Si cela est depuis longtemps possible avec Powershell, les outils de management déployés ici et là sur les stations, les consoles MMC ou encore le Server Manager, le WAC a l’intérêt d’offrir une centralisation sur un seul outil accessible depuis n’importe quelle station du réseau. J’ai hâte de pouvoir utiliser un peu plus cet outil dans un cadre plus consistant que sur une maquette de test. 😀

Vous pouvez télécharger le setup du Windows Admin Center directement sur le site de Microsoft.