PI Services

Le blog des collaborateurs de PI Services

Windows Server Core : Récupérer la main sur une console fermée

Bonjour à tous !

Aujourd'hui voici un court billet pour les personnes travaillant sous Windows Server Core.

Contexte :

Vous travaillez sur Windows Server Core, donc sans aucune GUI installée.

Vous êtes connecté au serveur à travers une connexion RDP.

Pour une raison X ou Y, au cours de votre session de travail, vous fermez malencontreusement votre invite de commande ou console PowerShell et vous n'avez plus aucun moyen de l'ouvrir !

Problématique :

Habituellement, le seul moyen de relancer une invite de commande ou une console Powershell est de passer par le Gestionnaire des tâches, qui peut s'ouvrir à l'aide la commande Ctrl+Alt+Suppr.

Si vous accéder au serveur en utilisant une connection à distance avec un rebond, la commande Ctrl+Alt+Suppr n'est pas prise en compte au sein du dernier bureau à distance ouvert, donc vous ne pouvez pas ouvrir le Gestionnaire des tâches via le raccourci habituel.

Solution :

Il existe cepandant un raccourci afin d'ouvrir le Gestionnaire des tâches, qui est Ctrl+Shift+Escape

Ensuite, il suffit de cliquer sur le menu File puis sur Run New Task afin de relancer au choix l'exécutable correspondant à la console Invite de commande ou à la console Powershell.

Bonus :

Voici la liste des consoles toujours accéssibles sous Windows Server Core et celles qui ne le sont plus :

Application

Server Core

Server with Desktop Experience

Command prompt

available

available

Windows PowerShell/ Microsoft .NET

available

available

Perfmon.exe

not available

available

Windbg (GUI)

supported

supported

Resmon.exe

not available

available

Regedit

available

available

Fsutil.exe

available

available

Disksnapshot.exe

not available

available

Diskpart.exe

available

available

Diskmgmt.msc

not available

available

Devmgmt.msc

not available

available

Server Manager

not available

available

Mmc.exe

not available

available

Eventvwr

not available

available

Wevtutil (Event queries)

available

available

Services.msc

not available

available

Control Panel

not available

available

Windows Update (GUI)

not available

available

Windows Explorer

not available

available

Taskbar

not available

available

Taskbar notifications

not available

available

Taskmgr

available

available

Internet Explorer or Edge

not available

available

Built-in help system

not available

available

Windows 10 Shell

not available

available

Windows Media Player

not available

available

PowerShell

available

available

PowerShell ISE

not available

available

PowerShell IME

available

available

Mstsc.exe

not available

available

Remote Desktop Services

available

available

Hyper-V Manager

not available

available

 A bientôt,

DirectAccess - Mise en place d'une ferme NLS en version Core virtualisée sous Hyper-V R2

Pré-requis et architecture

Parmis les pré-requis à la mise en place de DirectAccess, un serveur Web répondant en HTTPS est nécessaire. Ce serveur, nommé NLS pour Network Location Server, ne doit pas être joignable depuis l'extérieur. En effet, sa seule et unique fonction est de permettre aux postes clients sous Windows Seven de détecter correctement leur emplacement réseau :

  • Si le serveur NLS est accessible, alors le poste client sait qu'il est connecté à l'intérieur du réseau de l'entreprise (dans ce cas, le poste ne tente pas de se connecter à l'aide des technologies DirectAccess)
  • Si le serveur NLS est inaccessible, alors le poste client sait qu'il est connecté à l'extérieur (dans ce cas, le poste tente de se connecter à l'aide des technologies DirectAccess)

Le but du serveur NLS n���est pas d’afficher un site Web complexe mais juste de répondre à une simple requête HTTP encapsulé dans du SSL. En ce qui concerne le contenu de cette page, il n'y a pas de pré-requis particulier (une page HTML vide, ou bien la page par défaut de IIS 7.5 peut tout à fait être utilisée!). Pour héberger le "rôle" NLS, Microsoft conseille de respecter les préconisations suivantes :

  • Utiliser un serveur dédié (même si il est tout à fait envisageable de réutiliser un serveur Web existant)
  • Mettre en place un site Web hautement disponible

La mise en place de la haute disponibilité sur le rôle NLS est extrêmement importante ! En effet, si le serveur NLS tombe, tous les postes de travail situés en LAN pour lesquels DirectAccess est configuré, penseront qu'ils sont à l'extérieur de l'entreprise (car le NLS ne sera pas joignable) et tenteront alors de se connecter en IPv6 à la passerelle DirectAccess ce qui perturbera leur connexion au réseau de l'entreprise !

Si l'on respecte à la lettre les préconisations de Microsoft, la mise en oeuvre du rôle NLS implique donc l'utilisation de deux serveurs Web avec équilibrage de charge réseau (load balancer matériel ou NLB). Afin de minimiser les coûts en matériel, il est tout à fait possible de virtualiser les serveurs Web sous Microsoft Hyper-V R2 et d'activer le NLB entre les deux machines virtuelles pour fournir la haute disponibilité.

Dans la suite de ce billet, vous trouverez la procédure complète mettre en place cette configuration (ferme de machines virtuelles NLS en NLB). La petite subtilité étant l'usage d'une version Core de Windows Server 2008 R2 ce qui permet de réduire encore plus l'utilisation en ressources matérielles sur les serveurs Hyper-V tout en minimisant la maintenance.

Déploiement de 2008 R2 en version core

Une fois l'installation du système en version Core réalisée dans les deux machines virtuelles, et une fois le mot de passe du compte Administrator défini, une invite de commande telle que celle-ci s'affiche :

Cmd

Une série de commande va permettre de mettre en place le serveur Web IIS 7.5.

Pour commencer la commande sconfig (nouveauté de 2008 R2), permet d'effectuer une configuration rapide (nom de la machine, jointure au domaine, configuration TCP/IP).

sconfig 

Je ne détaille pas cette partie qui ne devrait pas poser trop de soucis. En cas de doute vous pouvez vous référer à la documentation sur Technet ( http://technet.microsoft.com/en-us/library/ee441254(WS.10).aspx). Pour les amateurs de l'invite de commande, il est également possible d'exécuter ces différentes opérations à l'aide de netsh (cf. : http://technet.microsoft.com/en-us/library/ee441257(WS.10).aspx).

Une fois ces différentes opérations effectuées on peut envisager d’activer le bureau à distance pour avoir une administration plus souple.

MMC-Remote-Management

Mise en place du rôle IIS 7.5 sur 2008 R2 en version core

Une fois le système correctement configuré, le rôle serveur Web doit être installé.

Remarque : Dans un premier temps, seuls les composants basiques de IIS sont déployés afin de pouvoir disposer d'un site (enfin une page ;-) ) complètement statique.

Une nouvelle commande est apparue dans 2008 R2 pour installer les rôles et fonctionnalités offerte par la version core :

dism /online /enable-feature /featurename:IIS-WebServerRole

Pour faciliter l’administration du site, il faut activer la prise de contrôle à distance au travers de la console d’administration Internet Information Service (IIS) Management et le WAS :

dism /online /enable-feature /featurename:IIS-ManagementService

dism /online /enable-feature /featurename:WAS-WindowsActivationService dism /online /enable-feature /featurename:WAS-ConfigurationAPI

Attention cela ne suffit pas, il faut aussi autoriser l’administration à distance par MMC en ajoutant la clé de registre suivante :

Reg Add HKLM\Software\Microsoft\WebManagement\Server /V EnableRemoteManagement /T REG_DWORD /D 1

La dernière étape consiste à démarrer le service de management et à modifier son type de démarrage en automatique pour qu'il se lance à chaque démarrage de la machine :

sc config wmsvc start= auto

net start wmsvc

Une fois ces étapes réalisées, le site Web par défaut de IIS doit être visible en saisissant http://<IP-SERVEUR> et le rôle IIS du serveur Core peut être configuré à distance à la console MMC graphique !

Installation du certificat et passage en HTTPS

Pour avoir accès au site en HTTPS il reste deux choses à faire. La première consiste à installer le certificat contenant la clé privée en ligne de commande :

certutil –importPFX  “C:\certificat.pfx”

Lors de son exécution la commande certutil nécessite la saisie du mot de passe pour valider l’import du PFX.

Une fois le certificat importé dans le magasin de certificat de l'ordinateur, il faut configurer IIS de manière à ce qu'il le prenne en compte. Pour cela, vous pouvez utiliser la console IIS Management depuis un poste distant. Il faut cliquer sur le site Web par défaut, puis sur Bindings, et enfin sélectionner le certificat voulu dans la liste déroulante (dans cet exemple le certificat se nomme "PI Services Secure Access").

Binding

A l'issue de cette étape, le site Web par défaut doit être accessible en saisissant l'URL https://<IP-SERVEUR>.

Mise en place du NLB entre les deux machines virtuelles

Remarque : Avant d'entamer la configuration du NLB sur les deux machines virtuelles, vérifiez que l'option enable spoofing of MAC address est bien activée dans les propriétés de la carte réseau sur les deux machines virtuelles (cette option se configure avec la console MMC Hyper-V Manager). Cette option est apparue avec Hyper-V R2 et permet le bon fonctionnement du NLB au sein des machines virtuelles.

Pour mettre en place le Network Load balancing, il faut commencer par installer la fonctionnalité sur chacun des serveurs de la ferme. Pour cela, saisissez la commande suivante :

Dism /online /Enable-Feature /FeatureName:NetworkLoadBalancingHeadlessServer

Une fois la fonctionnalité installée, le plus simple est d'utiliser la console Network Load Balancing Manager depuis un poste client pour configurer le cluster (la console doit être exécutée avec les "crédentials" d'un compte possédant les droits administrateur sur les serveurs Web).

Pour créer un nouveau cluster, il faut effectuer un clic droit sur Network Load Balancing Clusters, sélectionner New, puis se laisser guider par l’assistant :

 New-Cluster1 New-Cluster2

Il est possible d'affiner la configuration de la ferme NLB en précisant les ports TCP et UDP sur lesquels l'équilibrage de charge sera actif. Dans l'exemple ci-dessous, deux règles activent l'équilibrage de charge sur les ports 80 TCP et 443 TCP (seul l'équilibrage de charge sur le 443 est nécessaire à DirectAccess).

New-Cluster-Rules

Pour ajouter un nouveau membre à la ferme NLB, il faut effectuer un clic-droit sur le cluster existant, sélectionner Add Host to Cluster, puis préciser l'adresse IP du deuxième serveur Web.

New-Cluster-Membres

Une fois le second noeud ajouté et le cluster correctement convergé, il faut vérifier que le site Web est accessible en HTTPs via l'adresse IP virtuelle du cluster (saisir https://<adresse-IP-virtuelle> dans un navigateur).

La dernière étape consiste à créer une entrée dans le DNS pour pointer vers l'adresse IP virtuelle. Cette entrée DNS doit correspondre au FQDN du certificat précédemment importé (par exemple NLS.PISERVICES.FR).

Une fois l'entrée DNS créée, vérifiez que le site Web est accessible via l'URL https://nls.piservices.fr. Aucune erreur de certifiat ne doit s'afficher dans le navigateur !

Remarque : Il est possible de tester le cluster en mettant en pause l'une des deux machines virtuelles (via la console MMC Hyper-V Manager) !

A partir de cet instant la ferme de serveurs NLS est pleinement opérationnelle !

Mise en place d'une page Web dynamique sur la ferme NLS

Pour faciliter le dépannage lors de la mise en place de DirectAccess, il est souvent nécessaire de connaitre l'adresse IP utilisée par le poste de travail pour accéder au serveur NLS. Cela permet de déterminer quelle technologie de transition a été utilisée (6to4, Teredo, ISATAP, NAT64...).

Pour cela il suffit de modifier la configuration de la page par défaut des serveurs NLS afin d'afficher l’IP du client. Dans cet exemple, le langage ASP.net est utilisé.

Pour pouvoir héberger une page en ASP.net des composants supplémentaires doivent être installé sur les serveurs. Tout d’abord, il faut installer les Framework .NET 2 et 3 :

dism /online /enable-feature /featurename:NetFx2-ServerCore

dism /online /enable-feature /featurename:NetFx3-ServerCore

Les fonctionnalités ISAPI et ASP.NET doivent également être installées sur le rôle IIS :

dism /online /enable-feature /featurename:IIS-WebServerRole

dism /online /enable-feature /featurename:IIS-ISAPIFilter

dism /online /enable-feature /featurename:IIS-ISAPIExtensions

dism /online /enable-feature /featurename:IIS-NetFxExtensibility

dism /online /enable-feature /featurename:IIS-ASPNET

Enfin il faut installer le WAS et le service de gestion :

dism /online /enable-feature /featurename:IIS-ManagementService

dism /online /enable-feature /featurename:WAS-WindowsActivationService

dism /online /enable-feature /featurename:WAS-ConfigurationAPI

Pour démarrer le service de management, le rendre automatique et autoriser la gestion à distance, il faut exécuter les commandes suivantes :

Reg Add HKLM\Software\Microsoft\WebManagement\Server /V EnableRemoteManagement /T REG_DWORD /D 1

sc config wmsvc start= auto

net start wmsvc

A présent le serveur est capable d’interpréter du code ASP.net, il est donc possible de créer une page ASPX. Dans l'exemple ci-dessous, une page default.aspx a été créée et le site a été reconfiguré pour l'utiliser en document par défaut :

DefaultDocument

Voici le résultat obtenu avec les méthodes permettant de récupérer les adresses IP (seul le "body" de la page est affiché) :

<body>
    <form id="form1" runat="server">
    <div>
        Nom du serveur :    <%= Request.ServerVariables["SERVER_NAME"]%><br />
        Adresse IP du serveur :     <%= Request.ServerVariables["SERVER_ADDR"]%><br />
        Adresse IP du visiteur :     <%= Request.ServerVariables["REMOTE_ADDR"]%>
    </div>
    </form>
</body>

NLS

N'hésitez pas à laisser un commentaire sur cette procédure si vous avez des éléments à ajouter ou des précisions à demander.

SCOM – Installation d’un agent sur un Windows Server Core

A quoi ressemble l’installation d’un agent SCOM sur une version Core de Windows 2008 R2?

Et bien, pas de différence au niveau de l’installation de l’agent (du moins à distance):

1) Découverte

clip_image002

2) Installation

clip_image004

clip_image006

clip_image008

La spécificité du système d’exploitation (version Core) n’est pas indiquée dans le nom du système d’exploitation détecté (Microsoft Windows Server 2008 R2 Enterprise):

clip_image010

mais un nouveau type d’objet permet de les distinguer:

image

image

image

Notons au passage qu’il en est de même pour les Windows 2008 et que les Windows 2008 R2 sont également inclus dans la catégorie Windows Server 2008 Operating System (ce qui paraît logique)