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

 

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

Publicités

 

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

S’applique à : RDS Windows Server 2012 R2, RDS Windows Server 2016, Windows 8(.1), Windows 10

SniffPassword

Microsoft a apporté plusieurs améliorations en matière de sécurité au couple d’OS {Windows Server 2012 R2 & Windows 8.1} pour les protéger contre les attaques PtH (Pass-the-Hash). Les mots de passes des comptes utilisateurs ainsi que leur Hashes sont généralement stockés sur le Disque et la Mémoire du Poste de travail /Serveur, si votre machine est compromise, vos informations d’identification peuvent être réutilisées par un Hacker pour accéder à d’autres systèmes /plateformes /services critiques sans que vous soyez au courant.

Introduit avec Windows Server 2012 R2, la fonctionnalité « Restricted Admin Mode » ou « Mode d’Administration Restreinte » a été conçu pour protéger les comptes Administrateurs (locaux et du domaine) contre ce type d’attaque en s’assurant que les informations d’identification saisies lors d’une connexion Bureau à distance ne soient mémorisées et stockées dans la mémoire de la machine distante, qui peut potentiellement être compromise.

Quelques scénarios typiques

Equipe Help Desk utilisant un compte « Administrateur » pour effectuer du support N1/N2 à distance (via RDP) sur les machines des utilisateurs du réseau

Equipe IT Admins utilisant un compte « Administrateur du Domaine » pour effectuer du support N3 à distance (via RDP) sur des serveurs Membres.

Processus d’ouverture de Session RDP

Lorsque vous établissez une Connexion Bureau à distance sur une machine distante, vous êtes invités à vous authentifiez : Apparition de la fameuse boite de dialogue « Sécurité de Windows« :

LogOnWindows

L’authentification se fait dans un premier temps avec le service local RDP via le Process « Remote Interactive Logon ». Dans ce contexte, le mot « Interactive » signifie que l’utilisateur saisi « physiquement » son nom d’utilisateur et son mot de passe associé.

Le Service RDP tente ensuite d’ouvrir une Session Réseau sur la machine distante pour vérifier si l’utilisateur est autorisé à s’y connecter/accéder ou pas. Lors de cette phase, aucune information d’identification n’est requise. En effet, le ticket Kerberos ou Hash NTLM ayant été créés lors de l’ouverture de session initiale peuvent être utilisés pour l’authentification via réseau.

Une fois authentifié par le service RDP de la machine distante, les informations d’identification de l’utilisateur sont envoyées à travers un canal sécurisé vers la machine distante, l’ouverture de session « Interactive » a lieu ce qui permet à l’utilisateur distant de voir et accéder au Bureau à distance.

Prérequis

La fonctionnalité « Restricted Admin Mode » est supportée uniquement par les OS suivants :

OS Server : Windows Server 2012 R2 et Windows Server 2016

OS Client : Windows 8.1 et Windows 10

Donc avant de lancez une Connexion Bureau à distance en mode « Restricted Admin », assurez-vous que celle-ci est établie depuis et vers un des OS cités ci-dessus.

Dois-je utiliser le mode « Restricted Admin » ?

Si vous souhaitez restreindre les accès Bureau à distance sur des machines pouvant présentées un problème (machine présentant des problèmes de stabilité, potentiellement compromise, infectées par des virus…), vous pouvez envisager l’activation du mode « RestrictedAdmin », car comme expliqué ci-haut, vous pouvez être sûre que vos infos d’identifications ne peuvent être réutilisées par un programme malveillant ou un Hacker pour s’introduire sur d’autres machines du réseau jugées « critiques » comme les DC, BDD, Filers …

Cependant, certaines « Best Practices » de l’éditeur soulignent une préférence pour le « Hardening d’OS » incluant la mise en place de stratégies de sécurité pour renforcer la sécurité des comptes Administrateurs (locaux et du domaine), comme par exemple :

Le compte « Administrateur du Domaine » doit uniquement être utilisé pour s’authentifier sur les DCs pour gérer et administrer l’infrastructure AD et JAMAIS pour administrer les serveurs membres, les machines des utilisateurs du réseau …

Chaque machine du réseau doit avoir un compte « Administrateur » et mot de passe unique pour les besoins de gestion, d’administration et support

Comment utiliser le mode « Restricted Admin » ?

Le mode « Restricted Admin » est représenté par un paramètre de l’outil MSTSC.exe (Application Cliente : Connexion Bureau à distance).

Cette fonctionnalité correspond au paramètre /RestrictedAdmin, lancez MSTSC /? depuis l’invite de commande (CMD.exe) ou le Menu Démarré et constatez la disponibilité du mode « /RestrictedAdmin »:

MSTSCPI

Activer ou Désactiver le mode « Restricted Admin » 

Le Mode « Restricted Admin » est désactivé par défaut.

Pour activer cette fonctionnalité, une nouvelle clé doit être créée au niveau du BDR (Base de Registre), voir les paramètres suivants:

Chemin : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Valeur DWORD (32-bits) : DisableRestrictedAdmin

Données de la valeur : 0

Vous pouvez également activer cette fonctionnalité d’une manière centralisée sur un ensemble de serveurs /postes de travail via GPO, et ce via l’utilisation du paramètre de Stratégie de groupe suivant :

Chemin : Configuration Ordinateur | Stratégies | Modèles d’administration | Système | Délégation d’informations d’identification

Paramètre : Limiter la délégation d’informations d’identification à des serveurs distants

Valeur du paramètre : Activé

Une fois activé, si vous établissez une Connexion Bureau à distance (en mode Normal sans le paramètre /RestrictedAdmin) sur un serveur distant, le message suivant apparaît:

RestrictedAdminIssue

Maintenant, essayez de vous connecter à votre machine distante via l’utilisation de la commande : MSTSC /RestrictedAdmin

Note : Cette commande peut être lancée depuis le Menu Démarrée ou l’Invite de commande (CMD.exe)

Comme illustré dans l’image ci-après, la connexion Bureau à distance avec le mode « RestrictedAdmin » renforcé permet l’ouverture de la Session Bureau à distance :

AccèsBàD_OK

Limitations du mode « Restricted Admin »

Comme expliqué précédemment, quand le mode « Restricted Admin » est activé, l’utilisateur authentifié sur la machine distante n’a pas la possibilité de se connecter sur d’autres machines ni ressources du réseaux,
En effet, la délégation étant restreinte, les connections vers les autres machines s’effectuent via le compte d’ordinateur local.

Vous risquez (par exemple) de ne pas pouvoir vous connecter à un lecteur réseau depuis une Session Bureau à distance.

Dans l’exemple suivant, une Connexion Bureau à distance (en mode Restricted Admin) a été ouverte sur le DC. Le Gestionnaire de Serveur du DC a été lancé et une tentative de Connexion sur le serveur distant RDS01 a échouée (pas de délégation d’informations d’identification):

SrvPool_N.OK

Cette fois ci, une Connexion Bureau à distance (en mode normal : sans le Mode Restricted Admin) a été ouverte sur le DC. Le Gestionnaire de Serveur du DC a été lancé et une tentative de Connexion sur le serveur distant RDS01 a réussie (délégation d’informations d’identification ):

SrvPool_OK

S’applique à : RDS Windows Server 2012 R2 uniquement

Si un ou plusieurs de vos serveurs RDG 2012 R2 (Remote Desktop Gateway : Passerelle des Services Bureau à distance) ont récupéré la mise à jour « KB3102467« , celle-ci peut causer un crash de la console « Gestionnaire de Passerelle des Services Bureau à distance » (ou « RD Gateway Manager » pour les OS en EN).

La KB3102467 décrit la mise à jour « .NET Framework 4.6.1 » pour Windows Server 2012 R2.

J’ai essayé de reproduire le problème sur mes LABs RDS (OnPrem & Cloud), le problème parvient au niveau d’un serveur RDG sur 2.

Microsoft vient de publier un « Fix » pour corriger ce bug post-install de l’Update .NET Framework 4.6.1

Un reboot post-application du Fix est requis, donc pensez à planifier l’application de ce correctif sur vos serveurs RDG de Prod.

Lors de plusieurs interventions chez différents clients, le besoin suivant m’a été exprimé :

Peut-on faire apparaître le nom d’utilisateur (AD) sur le portail RD Web Access ?

Tout d’abord, il faut savoir que par défaut, tout utilisateur authentifié sur le Portail RD Web (Remote Desktop Web Access) ne voit pas apparaître son nom d’utilisateur sur celui-ci, voir l’image ci-après :

1

Le coin supérieur droit de cette page (fichier Default.aspx) regroupe uniquement les deux boutons : Aide & Se déconnecter

Nous allons voir à travers cet article comment personnaliser le Portail RDWeb pour afficher le nom d’utilisateur connecté à côté du bouton « Se déconnecter ».

Par défaut, l’ensemble des fichiers correspondant au Portail RDWA sont stockés dans C:\windows\web\RDWeb\Pages

Donc commencez par faire une copie de ce dossier avant de suivre les instructions détaillées ci-après.

Le but étant d’avoir un moyen de rétablir le portail RDWA en cas de mauvaise manipulation /erreur de configuration.

Comment ça marche ?

  1. Editez le fichier C:\windows\web\RDWeb\Pages\Web.config
  2. Localisez la ligne 52 : <system.web>
  3. Copiez /collez le code suivant (en dessous de la ligne 52) :
    <compilation defaultLanguage="c#" debug="true">
      <assemblies>
        <add assembly="System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
      </assemblies>
    </compilation>
  4. Le résultat doit ressembler à celui illustré dans l’image suivante:2
  5. Ce code a pour but d’indiquer au serveur RDWA que nous avons besoin d’insérer un code spécifique, et plus précisément un code (.NET) depuis la DLL « System.DirectoryServices.dll »
  6. Dès que le code est inséré, enregistrez et fermez le fichier Web.config
  7. Maintenant, éditez le fichier C:\windows\web\RDWeb\Pages\fr-FR\Default.aspx
  8. Localisez la ligne 225 : </script>
  9. Copiez /collez le code suivant (avant la ligne 225) :
    private static string GetDisplayName(string strUserName)
    {
      string strLDAPPath = "LDAP://dc=vLAB,dc=Lan";
      string strFilter = string.Empty;
      
      if(strUserName.Contains("\\")){strUserName = strUserName.Substring(1 + strUserName.IndexOf("\\"));}
      strFilter = "(SAMAccountName=" + strUserName + ")";
      if(strUserName.Contains("@")){strFilter = "(UserPrincipalName=" + strUserName + ")";}
      
      System.DirectoryServices.DirectoryEntry de = new System.DirectoryServices.DirectoryEntry(strLDAPPath);
      System.DirectoryServices.DirectorySearcher ds = new System.DirectoryServices.DirectorySearcher(de);
      ds.Filter = strFilter;
      ds.PropertiesToLoad.Add("DisplayName"); 
      System.DirectoryServices.SearchResultCollection results = ds.FindAll();
      
      return (results != null && results.Count > 0) ? Uri.EscapeDataString(results[0].Properties["DisplayName"][0].ToString()) : string.Empty;
    }
  10. Remplacer la valeur de LDAP://dc=vLAB,dc=Lan par le nom DNS de votre domaine AD
  11. Le résultat doit ressembler à celui illustré dans l’image suivante : 3
  12. Le code inséré occupe les lignes 224 > 240 sur mon fichier Default.aspx
  13. Localisez ensuite la ligne 248 : baseurl= »<%=SecurityElement.Escape(baseUrl.AbsoluteUri)%> »
  14. Insérez la ligne de code ci-après après la ligne 248 ‘baseurl…. » :
    userdisplayname="<%=GetDisplayName(strDomainUserName)%>"
  15. Le résultat doit ressembler à celui illustré dans l’image suivante : 4
  16. Les étapes ci-dessus permettent d’afficher le nom d’utilisateur sur la page Default.aspx uniquement. Pour faire la même chose sur les autres pages du Portail RDWA, le fichier Site.xsl doit également être modifié, pour ce faire éditez ce dernier qui se trouve dans C:\windows\web\RDWeb\Pages\Site.xsl 
  17. Localisez la ligne 15 (ligne vide) et insérez le code suivant juste en dessous :
    <xsl:variable name="userdisplayname" select="/RDWAPage/@userdisplayname"/>
  18. Enfin, localisez la ligne 322 (ou 323 selon la configuration du déploiement RDS 2012 /2012R2) : <xsl:value-of select= »$strings[@id = ‘SignOut’] »/>
  19. Copiez /collez le code suivant juste après cette ligne :
    <xsl:if test="$userdisplayname">(
    document.write(decodeURIComponent(''));)</xsl:if>
  20. Le résultat final doit ressembler à celui illustré dans l’image suivante :

5

Enregistrez et fermez le fichier Site.xsl et connectez-vous sur le Portail RDWA.

Enfin, constatez l’apparition du nom complet de l’utilisateur authentifié (Hicham KADIRI dans l’exemple suivant) :

6

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

C’est une technique pour les [RDS Advanced users only].

Toute mauvaise manip sur les fichiers Web.config /Default.aspx /Site.xsl peut entraîner un downtime du portail RDWA

Vérifiez que vous avez bien copié /sauvegardé le dossier C:\Windows\Web\RDWeb\Pages avant d’appliquer cette procédure sur vos serveurs RDWA de prod :).

Goodluck et à bientôt.