Archives de la catégorie ‘Windows Server 2016’

 

S’applique à : RDS Windows Server 2016 et RDS Windows Server 2019

Introduction

Pour réduire la surface d’attaque sur certains rôles/serveurs RDS, il est fortement recommandé de les déployer sur une infrastructure Windows Server en mode « Core » plutôt qu’en mode « GUI ». Cela vous permet aussi de réduire vos efforts en terme de maintien et exploitabilité de la plateforme (moins d’Updates, moins de config post-déploiement…).

 

Services de rôles RDS pris en charge par Windows Server Core 2016 et 2019

Le tableau ci-dessous, liste les différents services RDS pouvant être déployés/pris en charge sur un Windows Server 2016 et 2019 en mode Core:

Service de rôle RDS Supporté sur Server Core
RDCB  
RDLS  
RDSH  
RDVH  
RDWA  
RDG  
pris en charge

 

non pris en charge

 

En outre, Windows Server 2019 « Core » prend en charge tous les agents (graphiques) de Monitoring, Antivirus, Sauvegarde ou encore Sécurité (Encryption de Disk /Files). Vous pouvez donc continuer à inclure vos serveurs RDS en mode Core dans le périmètre de vos solutions d’infrastructures existantes, et ce sans aucun impact.

Pensez donc à privilégier l’utilisation du more « Core » pour vos serveurs Brokers (RDCB) et de Licences (RDLS).

Note importante : depuis Windows Server 2016, il n’est plus possible de Switcher entre les modes « GUI » et « Core ». Vous devez donc déployer vos serveurs RDS en mode Core « From Scratch ». Les serveurs RDS 2016 (existants) qui sont déjà en mode « Graphique » ne peuvent malheureusement être transformés en mode « Core » comme c’était le cas avec Windows Server 2012 et 2012 R2.

 

Gérer vos serveurs RDS Core à distance

Les serveurs RDS (RDCB et RDLS) exécutant Windows Server 2016 et 2019 en mode Core peuvent être gérés à distance depuis n’importe quelle machine d’administration ayant les outils RSAT installés. Cela pourrait être une machine cliente (Windows 7, 8/8.1 ou encore Windows 10) ou un serveur d’administration (Windows Server 2012 /2012 R2, 2016 ou encore 2019).

Depuis un Serveur d’Administration

Depuis une Session Windows Server (2012 ou ultérieur), lancez Windows PowerShell en tant qu’Administrateur et saisissez la commande suivante :

Get-WindowsFeature RSATRDS* | FT –AutoSize

Les outils RSAT dédiés pour la gestion des services de rôles RDS sont retournés

L’outil (Snap-in) RSAT-RDS-Licensing-Diagnosis-UI correspondant à « Outils de diagnostic des licences des services Bureau à distance » vous permet de gérer et diagnostiquer les services de licence RDS à distance.

Quant à l’outil « Gestionnaire de Licence des Services Bureau à distance« , celui-ci vous permettra d’activer votre serveur de Licence RDS, installer, gérer et migrer vos CAL RDS.

Depuis une machine cliente d’Administration

Il est également possible de gérer votre déploiement RDS depuis une machine cliente (Windows 7 ou ultérieur) ayant les outils RSAT installés.

En effet, ces derniers incluent l’outil « Server Manager » qui vous permet de regrouper vos serveurs RDS de déploiement dans le même pool de serveurs et gérer ainsi votre déploiement depuis le volet « Services Bureau à distance ».

Vous trouverez ci-après les liens de téléchargements des outils RSAT pour les clients Win7 > Win10:

Outils RSAT pour Windows 10

Outils RSAT pour Windows 8.1

Outils RSAT pour Windows 7

 

Enjoy :).

A propos de cet eBook

Le volume 2 de l’eBook MDT 8450 vous permet d’approfondir certaines fonctionnalités MDT comme le déploiement d’application et la personnalisation de l’OSD.

On y verra également comment déployer des correctifs avec WSUS pendant le déploiement d’un poste de travail.

Le déploiement de MDT sur plusieurs sites est également abordé.

 

Publics concernés par cet eBook

Ce guide pas à pas peut intéresser plusieurs populations IT :

  • Architecte Poste de travail
  • Ingénieur /Consultant Poste de travail
  • Administrateur Systèmes /Packageur
  • Technicien Systèmes /Réseaux /Applicatif
  • Toutes personnes désirant se former sur l’outil MDT

 

Enfin, cet eBook est organisé en 5 chapitres, n’hésitez pas à consulter la table des matières pour avoir plus de détail sur les sujets abordé.

L’eBook est disponible sur BecomeITexpert.com, cliquez sur l’image ci-après pour en savoir plus :

Très bon eBook de Nicolas BONNET | Microsoft MVP sur Enterprise Mobility.

Bonne lecture à tous :).

A bientôt,

#HK

Introduction

Vous devez sûrement connaître le fameux client « Connection Bureau à distance » fourni nativement avec les OS Windows (Client & Server). Cette Windows Desktop App fait simplement appel à l’outil MSTSC.exe qui est, aujourd’hui utilisé par la quasi totalité des Admins devant gérer et administrer (à distance) des plateformes Windows Server.

 

Note : Petit reminder, l’outil MSTSC.exe est (par défaut) placé dans : C:\Windows\System32\mstsc.exe

 

En outre, Microsoft propose depuis quelques années un client lourd « Multi-Platforme** » appelé « Remote Desktop« . Cette App est en effet disponible pour :

  • Mac OS X (depuis Mac Apple Store)
  • iOS (depuis Apple Store)
  • Android (depuis Google Play Store)

 

** Vous trouverez ci-dessous les liens de téléchargement de l’App « Remote Desktop », pour les différentes plateformes :

 

Session Bureau à distance « Windows 7 » sur un Smartphone « Samsung »

 

Après avoir sorti cette App « Cross-Platform », Microsoft a commencé à travailler sur son client Web HTML5, appelé RD (Remote Desktop) Web Client 🙂

Ce client est proposé depuis RDS Windows Server 2016 sous forme d’extension/plug-in du service RD Web Access.

Nous allons découvrir à travers cet article comment installer et configurer ce nouveau client RD Web sous RDS 2016.

Let’s Do It !

 

Prérequis

Le déploiement du client RD Web nécessite un certain nombre de prérequis, à savoir :

  • Votre (ou vos) Serveur(s) RD Web Access doit exécuter (à minima) Windows Server 2016 (ou 2019)
  • Votre déploiement RDS 2016 doit comporter (au moins) une Passerelle RDS
  • Les CAL RDS installées doit être de type « Par-Utilisateur« 
  • Les certificats SSL configurés pour la Passerelle RDS et le Serveur RD Web Access doit être délivrés et signés par une CA (Certification Authority) valide Publique : les certs SSL auto-signés empêchent l’utilisation du client RD Web
  • Seuls les connexions provenant des OS Suivants seront acceptés par le Client RD Web :
    • Windows 10
    • Windows Server 2008 R2 (ou ultérieur)

 

HowTo : Installer le client RD Web HTML5 sur un déploiement RDS 2016

Suivez les instructions suivantes pour installer correctement le client RD Web HTML5 au niveau de votre déploiement RDS 2016 :

  • Tout d’abord, ouvrez une Session Windows sur le serveur RD Web Access
  • Lancez Windows PowerShell en tant qu’Administrateur
  • Saisissez la commande suivante pour mettre à jour le module « PowerShellGet« 

Install-Module -Name PowerShellGet –Force

Note : Saisissez Y (comme Yes) pour confirmer l’exécution de la commande

  • Fermez la console PowerShell, et ré-ouvrez une nouvelle instance pour que l’Update du module PowerShellGet soit prise en compte
  • Exécutez la commande suivante pour installer le Module de Gestion du client RD Web :

Install-Module -Name RDWebClientManagement

  • Vous êtes invités à accepter les termes du contrat de Licence, saisissez A comme [All] et validez en cliquant sur Entrée :

  • Vous devez ensuite exécuter la commande suivante pour installer la dernière version du client RD (Remote Desktop) Web :

Install-RDWebClientPackage

  • Une fois le Package du Client RD Web installé, exécutez la commande suivante et notez le résultat :

Get-RDWebClientPackage

Maintenant, vous devez exporter le certificat SSL utilisé par votre service Broker. Ouvrez une Session Windows sur le Serveur Broker et lancez la console (snap-in) MMC > Ajouter « Certificats » > pour le « Compte d’Ordinateur » > Développez « Personal >> Certificats »

Faites un clic-droit sur le certificat utilisé par le service Broker. Dans l’exemple suivant, un seul certificat (rdgateway-hk.corp) a été utilisé pour signer tous les échanges Broker/RDWeb/RDG

  • Le fichier .Cer a été exporté et placé dans C:\
  • Le fichier .Cer exporté précédemment (C:\rdgateway-hk.cer) sera utilisé lors de la prochaine opération pour prendre en charge l’authentification SSO depuis le Client RD Web.
  • Exécutez la commande suivante en spécifiant l’emplacement vers lequel le .Cer a été exporté et placé :

Import-RDWebClientBrokerCert C:\RDGateway-hk.cer

  • Enfin, exécutez la commande PS suivante pour publier le nouveau client RD Web :

Publish-RDWebClientPackage -Type Production –Latest

Note importante : cette commande doit être exécutée si vous devez déployer le client RD Web dans un environnement de production, si vous souhaitez simplement « PoKé » le client RD Web sur un environnement de Test/Dev/Hom, exécutez plutôt la commande suivante :

Publish-RDWebClientPackage -Type Test –Latest

 

Let’s Test tout ça :).

Pour se connecter à votre client RD Web, la syntaxe de l’URL à utiliser est la suivante :

  • Si Installation en Production (paramètre -Type Production)

https://FQDN-de-votre-RDWebAccess.com/RDWeb/WebClient

  • Si Installation en environnement de Test (paramètre -Type Test)

https://FQDN-de-votre-RDWebAccess.com/RDWeb/WebClient-Test

Dans l’exemple suivant, je me connecte sur mon portail RD Web Access hébergé dans Azure. Comme illustré dans la capture d’écran ci-dessous, je suis connecté sur https://rdgateway-hk.xxxxxxxx.com/RDweb/webclient :

Une fois authentifié sur le Portail, je retrouve toutes mes Applis publiées (RemoteApps) :

Je lance une RemoteApp (Server Manager dans l’exemple suivant) …. :

Une fois lancé, je retrouve ma RemoteApp (Server Manager) depuis mon client RD Web.

Comme vous pouvez le voir, le client « lourd » local (MSTSC.exe) n’est pas lancé/utilisé, et je suis dans un mode « Full Web » 🙂 :

J’ai aussi lancé une instance WordPad 🙂 :

N’hésitez pas à publier vos RemoteApps favorites et les tester depuis le client RD Web.

Enjoy :).

 

Note : Un nouvel article sur le RD Web Client sous RDS 2019 arrive bientôt. Stay connected.

#HK o_O

 

J’ai récemment réalisé un audit de plusieurs infrastructures Windows Server « Core ».

J’ai constaté que la Corbeille ($RecycleBin) de plusieurs dizaines de serveurs Windows Server Core (de 2008 à 2016) occupait + de 5 GB d’espace disque.

Il s’agit ici de Disque physique : matériel non supporté > pas d’extension de volume possible !

Pour vider la corbeille et libérer cet espace disque, il fallait exécuter la commande suivante :

Note importante : La commande suivante doit être exécutée depuis une CMD.exe lancée en tant qu’Admin, si vous établissez une connexion Remote Shell Windows (WinRS), vérifiez que le compte utilisé est bien local Admin sur les machines distantes.

rmdir /s %systemdrive%\$Recycle.bin

Confirmez la suppression en cliquant sur Y(es) et voilà le tour est joué :).

J’espère que cette p’tite commande pourra vous être utile ^_^.

A bientôt

#HK

 

Hello Windows Guys,

Aujourd’hui, je vais vous parler d’un sujet souvent oublié et pourtant primordial pour la réussite de tout projet de déploiement Windows Server : Performance Tuning 

Microsoft fournie plusieurs Guidelines /White papers (Web /Docx /Pdf) décrivant les instructions à suivre pour bien tuner son infrastructure Windows Server, 2008, 2008 R2, 2012, 2012 R2 ou encore 2016.

Ces ressources étant réparties sur plusieurs sites /plateformes, j’ai donc décidé de vous regrouper dans le tableau ci-dessous tous les liens et documentations dont vous aurez besoin pour réaliser votre phase « Performance Tuning » avec succès.

OS Documents & Liens
Windows 2016 Performance Tuning Guidelines pour Windows Server 2016
https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/
Windows 2012 R2 Performance Tuning Guidelines pour Windows Server 2012 R2
https://www.microsoft.com/en-us/download/details.aspx?id=51960https://msdn.microsoft.com/en-us/library/windows/hardware/dn529133
Windows 2012 Performance Tuning Guidelines pour Windows Server 2012
http://download.microsoft.com/download/0/0/B/00BE76AF-D340-4759-8ECD-C80BC53B6231/performance-tuning-guidelines-windows-server-2012.docx
Windows 2008 R2 Performance Tuning Guidelines pour Windows Server 2008 R2
http://download.microsoft.com/download/6/B/2/6B2EBD3A-302E-4553-AC00-9885BBF31E21/Perf-tun-srv-R2.docx
Windows 2008 Performance Tuning Guidelines pour Windows Server 2008
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Perf-tun-srv.docx

 

Comme discuté précédemment, la phase « Tuning Performance » est vraiment importante dans tout projet de déploiement (Windows Server ou autre d’ailleurs) car cela vous permettra d’utiliser vos ressources de la manière la plus efficiente et surtout vous aidera à atteindre un niveau de disponibilité de service (SLA /Service Level Availability) élevé.

Un conseil from #HK

Prenez le temps de lire ces documents, certains pages vous redirigent vers d’autres liens/pages, prenez donc le temps de bien lire et comprendre et d’associer les éléments de Tuning en fonction de chaque rôle /composant de la plateforme Windows Server.

Si vous avez des questions, n’hésitez pas à me laisser un commentaire.

A bientôt

#HK

 

Les questions suivantes m’ont récemment été posées par l’équipe « Ingés Systèmes MS » chez un de mes clients ?

Est-il possible de déplacer le fichier pagefile.sys vers un nouvel emplacement (nouveau Disk) via l’interface CLI Windows (via un outil en ligne de commande Windows) ?

Y’a-t-il un risque /impact post-déplacement de ce fichier ?

 

Mes réponses étaient :

Oui, le fichier Pagefile.sys peut être déplacé vers un nouvel emplacement (au niveau de la même partition/disque ou vers un nouveau disque).

Non, aucun risque/impact, si bien évidemment l’opération de déplacement se fait correctement :).

 

Suis-je obliger de déplacer mon fichier pagefile.sys ? Quels « Cases » ?

Avant d’envisager un déplacement du fichier pagefile.sys, commencez d’abord par vérifier que c’est bien ce fichier qui occupe le plus d’espace disque sur votre serveur.

Notez que par défaut, le fichier pagefile.sys est placé dans la partition système C:\ > C:\pagefile.sys

Dans l’exemple suivant, nous exécutions l’outil TreeSize pour connaître les dossiers et fichiers occupant le plus d’espace sur le disque C: de mon DC (il s’agit ici d’un DC physique).

Comme illustré dans la console TreeSize ci-dessous, le fichier pagefile.sys de mon D(omain) C(ontroller) occupe lui seul 25GB de la partition système (C:).

 

Dans le cas de mon client, toutes les partitions C: (de 70GB) n’avaient quasiment plus d’espace disque libre, voir l’exemple suivant avec 9MB d’espace libre :S

Dans ce cas de figure, avec un pagefile.sys à 25GB (~40% de la taille globale de C:), il FAUT obligatoirement le déplacer pour libérer de l’espace disque dans l’immédiat car avec une telle configuration votre DC finira par crasher, rapidement !

 

Requirements

Vous devez bien évidemment avoir un autre disque connecté sur votre serveur « Physique » ou ajoutez un nouveau vDisk à votre serveur Virtuel. Notez que ce dernier doit avoir suffisamment d’espace disque libre pour accueillir votre nouveau fichier pagefile.sys

Important : la configuration d’un nouvel emplacement du fichier pagefile.sys nécessite le Reboot de votre serveur pour que cette modification soit prise en compte.

Déplacer le fichier pagefile.sys vers une nouveau Disque

Exécutez les commandes suivantes pour :

Créer un nouveau fichier Pagefile.sys et le placer dans disque dédié (Lettre D:)

wmic pagefileset create name=D:\pagefile.sys

Définir sa taille (Maximale) à 8192 MB (8GB)

wmic pagefileset where name=D:\pagefile.sys set InitialSize=2048,MaximumSize=8192

Supprimer l’ancien fichier Pagefile.sys (placé dans C:\ dans notre cas)

wmic pagefileset where name=C:\pagefile.sys delete

 

Vérifier que le nouveau fichier pagefile.sys a bien été créé et déplacé

Pour visualiser l’emplacement du nouveau fichier Pagefile.sys, saisissez la commande wmic pagefileset list ou wmic pagefileset list /format:list pour avoir un output au format « Liste ».

A bientôt pour de nouvelles Tips & Tricks Windows, stay connected :).

#HK | Just Another IT Guy

 

Le planificateur de tâches Windows vous permet de créer et gérer des tâches planifiées afin d’automatiser les tâches fastidieuses d’administration Windows (periodic check, lancement de scripts pour déploiement, configuration, …Etc)

Certaines applications crééent de manière automatique des tâches planifiées pour un « Automatic Update » ou simplement réaliser certaines opérations liées à l’application de manière périodique.

Le planificateur de tâches Windows correspond à l’outil/snap-in MMC Taskschd.msc

Pour le lancer, saisissez simplement Taskchd.msc depuis le Menu Exécuter ou Menu Démarré

Dans l’exemple suivant, mon planificateur de tâches contient des tâches « auto-générées » par une Application présente sur mon OS Server (Optimize Start ****), mais aussi deux autres créées « manuellement » : reboot & Update check

Si vous souhaitez migrer votre plateforme Windows Server (2008 R2 ou ultérieur) vers un nouveau matériel (New Hardware) ou nouvelle VM, le planificateur de tâches vous offre la possibilité de migrer (exporter) vos tâches planifiées une par une, si vous en avez 100 ou 200 tâches planifiées … vous devriez donc les exporter à la main, une par un … 😦

HowTo : migrer toutes vos tâches planifiées en une seule opération 🙂

La migration des tâches planifiées d’un serveur à un autre est assez simple.

Il faut savoir que « par défaut », toute tâche planifiée créée est automatiquement placée dans le dossier suivant :

C:\Windows\System32\Tasks

Si je reprends l’exemple précédent, mes tâches planifiées « Optimize Start… » ainsi que « Reboot & Update check » sont donc bien présentes dans C:\Windows\System32\Tasks, voir Screenshot ci-dessous :

Pour les migrer vers un nouveau serveur (Physique ou Virtuel), il suffit de copier le dossier C:\Windows\System32\Tasks et copier son contenu et le coller dans le même dossier du nouveau Serveur.
Et voilà le tour est joué :).

 

Introduction à l’outil CLI « APPCMD.exe »

AppCmd.exe est un Outil en ligne de commande (CLI) fourni avec le rôle Windows Server « IIS ».

C’est un outil d’administration très puissant qui vous permet (entre autres) de :

Créer, configurer et gérer des Sites IIS

Créer, configurer et gérer des Applis et Pools d’Applications IIS

Créer, configurer et gérer des Virtual Directories (Répertoire virtuels IIS)

Démarrer, arrête et recycler les Pools d’application

Afficher/Visualiser des informations sur les Worker Process

…Etc

Pour finir, AppCmd.exe vous permet non seulement de réaliser toutes les tâches d’administration classiques que vous pouvez effectuer depuis l’outil graphique IIS Manager (InetMgr.exe) mais aussi d’industrialiser /d’automatiser à l’aide de scripts Bat(ch) toute tâche d’administration /configuration fastidieuse et répétitive.

 

Définir le chemin par défaut d’AppCmd.exe

Les Best Practices IIS consistent à définir (forcer) le chemin by default de l’outil AppCmd.exe au niveau de la %var% d’environnement %PATH%, cette opération vous faciltera l’utilisation de l’outil car vous pourrez l’appeler depuis n’importe quel CMD Folder et vous n’aurez donc plus à faire du CD (Change Directory) à chaque fois que vous souhaitez appeler /lancer AppCmd.exe

Pour ce faire, la commande ci-dessous est à exécuter sur tous les serveurs IIS Server faisant parti de votre infrastructure système MS (Windows Server 2008 et ultérieur).

SETX PATH « %PATH%;%WINDIR%\System32\inetsrv » /M

Saisissez ensuite la commande suivante pour vérifier que la valeur de la variable %PATH% a bien été Updatée :

Echo %PATH%

Vous pouvez également vérifier le contenu de la variable %PATH% depuis les propriétés systèmes du serveur IIS > Variables d’environnement

Et voilà le tour est joué :).

Stay Connected, plusieurs HowTo IIS sont en cours de préparation.

N’hésitez pas à vous abonner à mon Blog pour rester informé de toute nouvelle publication ^^

See you soon.

#HK

 

S’applique à : IIS Windows Server {2008 /2008 R2 /2012 /2012 R2 /2016}

J’ai récemment réalisé un audit de sécurité sur une infrastructure système Microsoft comprenant plusieurs serveurs Web IIS exécutant Windows Server 2008 R2, 2012 R2 et 2016, après réalisation de quelques tests fonctionnels et analyse des output files, j’ai détecté une faille de sécurité sur une Application Web (d’un éditeur tiers) permettant de récupérer les credentials (login/password) sur certaines pages.

Après étude de la vulnérable, il a été constaté que malgré la configuration du certificat SSL (WebApp accessible en HTTPS Only), certaines pages étaient toujours accessibles en HTTP.

Pour remédier à ce problème de sécurité, la solution suivante a été proposée au client :

Forcer la redirection du trafic HTTP vers le HTTPS sur toutes les pages du WebSite IIS.

Comment ça marche ?

La réponse est le Wonderful module /extension IIS : URL Rewrite.

URL Rewrite Module, qu’est ce que c’est ?

Je vous invite à consulter la vidéo ci-après pour en savoir plus :

En quelque mots : URL Rewrite est un module IIS qui vous permet de créer de Powerful Rules pour optimiser l’expérience utilisateur IIS.

En effet, à l’aide cette extension, vous avez la possibilité d’implémenter des règles pour utiliser des URLs simples et faciles à retenir.

Cela comprend la redirection d’URL /pages mais aussi le type de trafic (e.g : HTTP vers HTTPS).

La dernière version disponible au moment de l’écriture du présent post est la 2.1

Celle-ci prend désormais en charge IIS Windows Server 2016, elle est disponible en téléchargement gratuit ici.

Téléchargez et installez l’extension URL Rewrite sur tous vos serveurs IIS hébergeant la ou les WebApp(s) pour la(les)quelle(s) la redirection vers le HTTPS sera configurée.

Installer URL Rewrite 2.1

Une fois téléchargé, double-cliquez sur le fichier (.exe) pour lancer l’installation du module Rewrite URL.

L’assistant d’installation suivant apparaît :

Cliquez sur « Install » pour démarrer l’installation :

L’installation démarre …

Une fois déployé, l’assistant retourne le message suivant :

 

HowTo : Rediriger le HTTP vers le HTTPS sur une WebApp IIS

Commencez par lancer le Gestionnaire IIS (IIS Manager) en exécutant l’outil InetMgr.exe depuis le Menu « Exécuter » ou « Démarrer »

Sélectionnez le Site Web IIS pour lequel vous voulez rediriger le traffic HTTP vers HTTPS.

Dans l’exemple suivant, la WebApp « XXXXX » sera sélectionnée. Depuis le volet droit, localisez et double-cliquez sur « URL Rewrite »

Depuis le menu « Actions », cliquez sur « Add Rule(s)… »

L’assistant de création de règles suivant apparaît, sélectionnez « Blank rule » et cliquez sur « Ok »

Remplissez les champs ci-dessous de la manière suivante :

Name : HTTP to HTTPS

Pattern : (.*)

Sous « Conditions« , cliquez sur « Add… » pour ajouter une nouvelle condition

Créer /ajouter la condition suivante :

Condition input : {HTTPS}

Check if input string : Matches the Pattern

Pattern : ^OFF$

Sous « Action« , configurer l’action de la manière suivante :

Action type : Redirect

Redirect URL : https://{HTTP_HOST}/{R:1}

Redirect type : See Other (303)

Enfin, cliquez sur « Apply » pour appliquer votre règle URL Rewrite

Une fois créée, la règle URL Rewrite apparaît dans la liste :

 

Faites un test en saisissant simplement http://suivi_de_URL_de_Votre_WebApp et constatez la redirection vers https://suivi_de_URL_de_Votre_WebApp

Hello Windows Guys,

Quand vous déployez un Windows Server ou Client (Windows 7 >10 /2008 R2 >2016), les binaires du client Telnet sont bien présents sur la partition « System » mais la fonctionnalité n’est malheureusement pas activée par défaut.

Vous comme moi, connaissez l’utilité de ce super tool, surtout quand vous êtes amené à valider le fonctionnement d’une solution /service ou simplement appelés à troubleshooter un service.

Si vous lancez CMD.exe sur une machine Windows (Client ou Server), et que vous saisissez Telnet, le résultat suivant vous est retourné :

Pour installer le Client Telnet depuis la même Invite de commande sans avoir besoin de lancer /utiliser le Server Manager ou « Programmes et Fonctionnalités » Windows, exécutez la commande suivante et aller boire le K.fé 🙂

Note : l’invite de commande (CMD.exe) doit être lancée en tant qu’Administration

DISM /Online /Enable-Feature:TelnetClient

Maintenant que le client Telnet est installé, je peux tester la connectivité de mon WebSite sur le port 443 🙂