Archives de la catégorie ‘Windows Server 2012 (R2)’

 

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é :).

Publicités

 

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

 

Malgré l’ajout des ~2300 nouvelles Cmd-lets PowerShell sur Windows Server 2012 R2 et 2016, le meilleur outil de gestion du Networking & Firewalling Windows reste (pour moi :D) le super Command-Line Tool Netsh.exe (Windows Network Shell).

En effet, Windows PowerShell fonctionne aujourd’hui qu’avec un sous-ensemble de fonctionnalités de management Windows Server, n’incluant pas la possibilité de configurer et gérer le Pare-feu Windows et ses fonctions avancées.

J’ai donc décidé de vous regrouper dans le présent post les « Top 10″ des Commandes Netsh que vous devez connaître pour créer, configurer et gérer vos Pare-feu Windows (Client & Server).

Les commandes détaillées ci-dessous peuvent aussi vous être utile lors de la configuration du Firewall Windows IaaS (E.g : VM Azure ou AWS)

 

1.Afficher /Lister une règle spécifique ou toutes les règles du Pare-feu Windows
  • Afficher toutes les règles : netsh advfirewall firewall show rule name=all
  • Afficher une règle spécifique (« SQL » dans l’exemple suivant) : netsh advfirewall firewall show rule name=SQL


2.Activer /Désactiver un ou plusieurs profils du Pare-feu Windows
  • Activer tous les profils du Pare-feu Windows : Netsh advfirewall set allprofiles state on
  • Désactiver tous les profils du Pare-feu Windows : Netsh advfirewall set allprofiles state off
  • Activer le profil « Public » du Pare-feu Windows : Netsh advfirewall set publicprofile state on
  • Désactiver le profil « Privé » du Pare-feu Windows : Netsh advfirewall set privateprofile state off
  • Activer le profil « Domaine » du Pare-feu Windows : Netsh advfirewall set domainprofile state on

3.Réinitialiser les stratégies (par défaut) du Pare-feu Windows
  • netsh advfirewall reset

4.Afficher et Configurer les fichiers Logs du Pare-feu Windows

Notez que le chemin par défaut des fichiers « Logs » liés au Pare-feu Windows est le suivant : C:\Windows\system32\LogFiles\Firewall\pfirewall.log

Vous pouvez visualiser ce chemin par défaut (pour tous les profils du Pare-feu) en exécutant la commande suivante :

  • netsh advfirewall show allprofiles logging

Nous allons définir dans l’exemple suivant le chemin « D:\WSFirewall\Logs\pfirewall.log », pour tous les profils du Pare-feu Windows (Domaine – Privé – Public)

  • netsh advfirewall set allprofiles logging filename « D:\WSFirewall\Logs\pfirewall.log« 

Note : après configuration d’un nouvel emplacement du fichier log pfirewall.log, l’ancien fichier log placé dans le chemin par défaut est automatiquement déplacé et renommé en .old


5.Autoriser ou Refuser le « Ping »
  • Autoriser le « Ping »: netsh advfirewall firewall add rule name= »All ICMP V4″ dir=in action=allow protocol=icmpv4
  • Refuser le « Ping » : netsh advfirewall firewall add rule name= »All ICMP V4″ dir=in action=block protocol=icmpv4

6.Ajouter (Autoriser) ou Supprimer un Port spécifique
  • Ajouter une nouvelle règle autorisant le port 1433 (port par défaut utilisé par SQL Server) : netsh advfirewall firewall add rule name= »Autoriser_Port_SQL Server » dir=in action=allow protocol=TCP localport=1433
  • Supprimer la règle précédente autorisant le port 1433 (port par défaut utilisé par SQL Server) : netsh advfirewall firewall delete rule name= »Autoriser_Port_SQL Server » protocol=tcp localport=1433

7.Autoriser un Programme
  • Dans l’exemple suivant, le Programme « IPScan » placé dans C:\Program Files\IPScan\IPScan.exe » sera autorisé : netsh advfirewall firewall add rule name= »Autoriser_IPScan » dir=in action=allow program= »%ProgramFiles%\IPScan\IPScan.exe »

8.Activer la gestion à distance
  • netsh advfirewall firewall set rule group= »Gestion à distance de Windows » new enable=yes


9. Activer /autoriser Les Connexions Bureau à distance
  • netsh advfirewall firewall set rule group= »Bureau à distance » new enable=Yes


10.Exporter ou importer la configuration & paramètres du Pare-feu Windows
  • Pour exporter toute la configuration du Pare-feu Windows vers D:\WSFirewall : netsh advfirewall export « D:\WSFirewall\WFconfiguration.wfw »

  • Pour exporter toute la configuration du Pare-feu Windows vers D:\WSFirewall : netsh advfirewall export « D:\WSFirewall\WFconfiguration.wfw »

Je vous laisse Run > Netsh Advfirewall /? et découvrir le reste des commandes.

Enfin, toujours gardez à l’esprit que le CLI Netsh.exe fait parti des outils en ligne de commande Windows les plus puissants (et compliqué aussi). Toujours PoC(er), Tester et Valider l’opération sur un LaB /Environnement d’Intégration /PréProd …Etc avant toute application sur les serveurs de Production.

A bientôt

 

S’applique à : Active Directory 2008, 2008 R2, 2012, 2012 R2 et 2016

Dans une infrastructure Active Directory répartie sur plusieurs sites, il arrive de devoir installer un Contrôleur de Domaine sur un site distant ne contenant aucun DC pour l’instant. L’installation nécessite la copie de l’annuaire à travers le réseau lors de l’exécution de l’assistant de configuration. Il est possible pour ce type situation, d’installer le contrôleur sur le site distant avec l’option « IFM : Install From Media ». Dans ce cas il faut préparer un support sur un Contrôleur de Domaine existant. Après l’installation, la réplication se fait à travers les liens réseaux.
Pour préparer le support d’installation il faut se connecter sur un Contrôleur de Domaine existant (un Contrôleur de Domaine en lecture seule ne peut servir de source), monter (connecter) ensuite un support amovible pour stocker les sources comme par exemple sur une clé USB avec la lettre E: (ou X:\ :)), une fois connecté, lancez l’Invite de Commande (CMD.exe) en tant qu’Administrateur et saisissez les commandes suivantes. Notez que dans l’exemple suivant, notre support de stockage amovible est monté avec la Lettre E:

NTDSUtil

Activate instance NTDS

ifm

Create SYSVOL full E:

Il vous faut ensuite attendre la création du support.

Sur votre site distant, déployez votre futur DC Windows Server (physique ou virtuel), installez y les services AD DS et lancez l’assistant pour promouvoir le contrôleur de domaine.

Lors de l’exécution de l’assistant de configuration, cochez la case « Installation à partir du support »  et spécifiez l’emplacement contenant la copie de l’annuaire AD générée lors de l’exécution des commandes ci-dessus (lettre correspondant à votre support de stockage amovible utilisé précédemment, E: dans notre cas) :

ifm_1

 

Cet article est un extrait de l’eBook de référence « Active Directory 2012 R2 – Design et déploiement en Entreprise [Guide du Consultant] »

Cet article voit le jour suite à la demande d’un Follower :).

Sa question était la suivante :

Comment supprimer la partie « Sécurité » du portail RD Web Access ?

La partie « Sécurité » fait simplement référence aux deux options suivantes :

  • Ceci est un ordinateur public ou partagé
  • Ceci est un ordinateur privé

La capture d’écran suivante illustre ces deux options, par défaut affichées sur le portail RD Web Access:

4

Suivez les instructions suivantes pour supprimer tout le bloc « Sécurité » de votre Portail RDWA.

Note : si votre déploiement RDS comprend plusieurs serveurs RDWA, vous devez réaliser les opérations décrites ci-dessous sur chaque RD Web Access du déploiement.

  • Ouvrez une Session Windows sur le serveur RDWA
  • Installez Notepad++ (temporairement) pour faciliter la réalisation des opérations suivantes
  • Éditez (avec Notepad++) le fichier C:\Windows\Web\RDWeb\Pages\fr-FR\login.aspx
    • Note : si votre RDWA exécute WS2012 R2 en EN(glish), le fichier login.aspx est normalement placé dans C:\Windows\Web\RDWeb\Pages\en-US\login.aspx
  • Allez à la ligne 522 et ajoutez <!– 
  • Allez ensuite à la ligne 596 et saisissez –>

1

2

Le but étant de marquer tout le bloc de texte allant de la ligne 523 >> 598 comme « Commentaire » et donc bypasser les options de sécurité.

Enregistrez les modifications et reconnectez-vous sur le Portail RDWA.

Constatez la disparition du bloc « Sécurité » :)) :

3

 

S’applique à : Windows Server 2008 /2008 R2, 2012 /2012 R2 et 2016 | Windows Seven, Windows 8/8.1 et Windows 10

La « Tip of the Week » est un HowTo pour afficher la date du dernier redémarrage de Windows (Server & Client).

Ayant travaillé sur plusieurs projets d’Audit Infrastructure (Windows Server, P2T, Active Directory…) ces dernières années, j’ai pu constater que la plupart des serveurs Windows Server présentant des problèmes de stabilités et/ou dysfonctionnement n’ont aucun « redémarrage périodique » de planifié. Si nécessaire, ces serveurs sont donc redémarrés manuellement.

Redémarrer une machine Windows consiste à faire deux clics de souris ou saisir 2 mots depuis le Menu « Démarrer », mais quand il s’agit d’un serveur de production, l’opération devient plus compliquée : négocier, planifier le redémarrage du serveur, astreinte possible, intervention post-redémarrage possible (si effets de bord post-reboot) …

C’est la raison pour laquelle, le redémarrage d’un serveur Windows Server est souvent une tâche oubliée par les IT Admin /Ing de prod allergiques à ce type d’opération et ne voulant pas prendre le risque, résultat : lors de plusieurs audits réalisés chez différents clients (Banques, Assurances, Grand groupes de l’industrie …), j’ai souvent constaté que :

Plusieurs serveurs (quelques dizaines voire des centaines) n’ont pas été redémarrés depuis plusieurs mois voire plusieurs années (côté Banques & Assurances)

Les serveurs « en attente de redémarrage » présentent toujours des problèmes de stabilité au niveau de certains Services /Fonctionnalités Windows /Couches Applicatives spécifiques

Les serveurs qui n’ont pas été redémarrés hébergent pour la plupart des services /applications critiques (Standards & Métiers)

De plus, un Serveur Windows Server en attente de redémarrage (suite à l’installation de mises à jour Windows par exemple) peut bloquer plusieurs actions telle que l’ajout de nouvelles fonctionnalités /Services /Rôles /Apps, bloque l’utilisation de certaines fonctions /options et ce au niveau de plusieurs Snap-ins, il peut également bloquer (dans certains cas) l’accès distant à différents services …

Vous aurez compris, connaître la date du dernier redémarrage d’un serveur est une information précieuse qui peut vous aider à cerner un ou plusieurs problèmes présents celui-ci.

Ci-après, les différentes techniques vous permettant d’afficher la date du dernier reboot de Windows Server et Client.

Vous pouvez connaître la date du dernier redémarrage d’un Windows (Server & Client) via l’utilisation de différents outils /méthodes, à savoir :

Outil WMIC.exe

Windows PowerShell

Outil SystemInfo.exe

Script PowerShell

 

Via l’outil « WMIC.exe »

Utilisez la commande suivante : WMIC OS Get LastBootUpTime

1

Via Windows PowerShell

Utilisez la commande suivante : Get-CimInstance -ClassName Win32_OperatingSystem | Select CSName, LastBootUpTime
2

Via l’outil « SystemInfo.exe »

Utilisez la commande suivante : SystemInfo | Find /i « Heure de démarrage du Système »

Note : pour les OS en EN utilisez plutôt la commande suivante : SystemInfo | Find /i « System Boot Time »

3

Via Script (PS)

Un script PowerShell a été uploadé par « Gary L Jackson« , sur  la TechNet Gallery et disponible en téléchargement ici.

 

J’espère que cette astuce pourra vous être utile J

A bientôt.

ScriptGuyPic