Bonjour à tous !

Aujourd'hui voici un billet pour les personnes rencontrant des problèmes de coupures intempestives sur des lecteurs réseau.

Contexte :

Des utilisateurs travaillant sur des lecteurs réseau vous rapportent des problèmes d'accès intempestifs à leurs fichiers, avec des coupures ou des lecteurs marqués comme déconnectés dans le poste de travail.
Ces coupures peuvent intervenir à n'importe quel moment de la journée et ne suivent pas des intervalles précis.

Cependant les serveurs hébergeant les partages concernés par les coupures semblent être toujours les mêmes, tout comme les postes de travail.

Vous pouvez remarquer que les plantages surviennent aussi lorsque les fichiers sont utilisés sur de longues periodes (applicatif sur un lecteur réseau par exemple).

Solution :

Depuis Windows Server 2012 R2 ainsi que Windows 8, Microsoft a introduit une nouveauté dans le traitement des stratégies de groupe.

Le traitement des paramètres de préférences de stratégies de groupe (les fameuses Group Policy Preferences), et plus particulèrement celles concernant les lecteurs réseau se passe désormais en arrière-plan (background processing) et non plus uniquement à l'ouverture de la session d'un utilisateur (foreground processing).

En conséquence, quand vos lecteurs réseau sont mappés avec l'option Replace et non l'option Update, chaque rafraîchissement de la stratégie de groupe concernée entrainera une suppression du lecteur réseau, puis sa re-création provoquant ainsi une coupure temporaire.

C'est donc une nouvelle Best Practice à adopter, l'option Replace ne doit être utilisée que lorsque vous avez besoin d'écraser un paramètre pour le remplacer par un différent (je pense notemment à des mappages d'imprimantes lors d'un changement d'imprimante), l'option Update doit désormais être préférée pour tous les éléments ne devant pas être écrasés mais simplement mis à jour.

A bientôt,

Contexte

Le problème décrit ci-dessous a été rencontré dans le cadre d'une infrastructure DirectAccess sous Windows Server 2012 R2. Celui-ci peut se produire lorsque l'authentification forte (par carte à puce ou OTP) est activée avec des clients Windows 7.

Problème rencontré

Lorsque des lecteurs réseaux sont montés à l'ouverture de la session, cela peut empêcher cette dernière de s'ouvrir correctement et laisser l'utilisateur bloqué sur la page de “Bienvenue” pendant plusieurs minutes voir plusieurs dizaines de minutes.

Analyse

Pour rappel, la connectivité DirectAccess est composée de deux tunnels :

• Le tunnel infrastructure utilisé notamment pour l'authentification et les stratégies de groupes.
• Le tunnel utilisateur qui permet d'accéder à des ressources d'entreprise (partages, applications, site web) en fonction des autorisations de la personne connectée.

Ce problème est une conséquence de l'activation de l'authentification forte. En effet, tant que cette dernière n'a pas eu lieu, le tunnel utilisateur n’est pas créé. Les lecteurs réseaux étant des ressources liés à l’utilisateur, elles sont accédées par ce tunnel. Le système d’exploitation tente de monter les lecteurs réseaux et il faut attendre un timeout de cette opération avant que la session ne s’ouvre.

Solution

Toutes les solutions présentées ici sont des contournements permettant d'éviter le problème mais présentant toutes des inconvénients (à voir selon le cas, celle qui est le plus acceptable pour vous).

1/ Authentification forte pendant l'ouverture de session

Demander l’authentification forte lors de l’ouverture de session permet de déclencher la création du tunnel utilisateur. Ainsi, les lecteurs réseaux peuvent être montés. Cependant, cette méthode implique deux inconvénients :

• Elle ne fonctionne que lorsque la méthode d’authentification forte utilisée est la carte à puce. En cas d’usage d’un OTP, cela ne peut être opérationnelle puisque DirectAccess à un processus propre pour gérer ce type d’authentification décorrélé de celui de l’ouverture de session. Pour plus d’informations, je vous invite à lire cet article : https://blog.piservices.fr/post/2015/11/23/DirectAccess-Deploiement-de-lauthentification-forte
• L’utilisateur est obligé de s���authentifier sur son poste client avec l’authentification. Cela dégrade l’expérience utilisateur lorsque l’on se trouve en entreprise et qu’on ne souhaite donc pas utiliser DirecAccess.

2/ Logon Script

Les lecteurs réseaux sont parfois mappés par un script s'exécutant après l'ouverture de session (logon script). Pour que cette solution soit fonctionnelle, il suffit d'intégrer un test vérifiant que la connectivité DirectAccess est montée et de boucler dessus tant que ce n'est pas le cas. Cela peut être fait en validant l'accès à une ressource d'entreprise comme un partage ou l'url du serveur NLS de DirectAccess. Cependant cette solution présente l'inconvénient de devoir parfois laisser un script tourner continuellement.

3/ Management servers

L’une des autres possibilités est d’ajouter les serveurs de fichiers utilisés par ces lecteurs réseaux dans la liste des serveurs de management. Ainsi, l’accès à ceux-ci se fait via le tunnel infrastructure qui ne nécessite pas d’authentification forte et qui est monté dès le démarrage de l’ordinateur avant l’ouverture de session (si une connexion à internet est disponible). Cependant, cette méthode est contraire à la volonté de sécuriser les accès aux ressources d’entreprise avec de l’authentification forte. En effet, si l’utilisateur ouvre une session, il pourra accéder aux serveurs de fichiers sans authentification forte et par rebond à d’autres serveurs. Cette solution affaiblit donc la sécurité de l’infrastructure.

Si toutefois vous souhaitez implémenter cette solution, il suffit de lancer la console de gestion DirectAccess et de se rendre dans la configuration du serveur ou du cluster via le menu éponyme. Ensuite, il faut cliquer sur le bouton “Edit” de l’étape 3 de l’assistant de configuration.

Dans l’onglet “Management”, il faut indiquer les noms DNS des serveurs de fichiers (les IP ne peuvent être indiquées que si vos serveurs communiquent en IPv6). Vous pouvez ensuite cliquer sur le bouton “Finish”.

N’oubliez pas de mettre à jour les stratégies de groupe en cliquant sur le bandeau qui apparait en bas de la console de gestion DirectAccess. Enfin, il faut récupérer cette nouvelle version des GPOs DirectAccess sur vos postes clients (via la commande “gpupdate” par exemple).

4/ Déclenchement de la connectivité DirectAccess après le logon

Le démarrage d'un des services requis pour la connectivité DirectAccess après l'ouverture de session permet de corriger le phénomène. Le service IP Helper (iphlpsvc) permettant notamment de générer les interfaces de transitions IPv4/IPv6 est l'un deux. En effet, aucun tunnel dédié à DirectAccess n'existera tant que ce service n'est pas démarré. Ainsi, le client ne tentera pas de monter les lecteurs réseaux. Néanmoins, via cette méthode, le tunnel infrastructure n'existe pas non plus tant que l'utilisateur n'est pas connecté. Ainsi, un utilisateur qui se connecte pour la première fois sur un ordinateur ne pourra le faire via DirectAccess. Aussi, les patchs ne pourront être récupérés et les stratégies de groupes ne seront pas mises à jour tant qu'un utilisateur n'a pas ouvert de session. Si toutefois vous souhaitez réaliser cette manipulation, il suffit de créer une stratégie de groupe avec les paramètres ci-dessous.

Dans “Computer Configuration / Preferences / Services”, il faut changer le mode de démarrage du service IP Helper afin qu'il démarre manuellement.

Dans “Configuration / Preferences / Scheduled Tasks”, il faut créer une tâche planifiée lancée par le compte “SYSTEM”.

On définit l'exécution de celle-ci à l'ouverture de session.

Enfin, on indique qu'il faut lancer le service IP Helper via la commande “net start”.

Aussi, il est nécessaire de gérer le cas d'un utilisateur qui ferme sa session afin de ne pas rencontrer le problème lors de la prochaine ouverture de session. Pour cela, il faut créer une seconde tâche se déclenchant à la fermeture de session.

Celle-ci est quasiment identique en dehors de la commande exécutée (“net stop”) et du déclencheur. Ce dernier est paramétré pour détecter l'événement 4647 du journal d'événements Sécurité. Celui-ci correspond à une demande de fermeture de session par l'utilisateur.

Enfin, cet évènement n'est pas généré par défaut. Pour l'obtenir, il faut activer l'audit sur la catégorie “Logoff”. Cette opération s'effectue par stratégie de groupe dans “Computer Configuration / Policies / Windows Settings / Security Settings / Advanced Audit Policy Configuration / Audit Policies”.

Bonjour,

Ce guide fait suite à mon post sur la création d’une collection RDS avec équilibrage de charge sous Windows serveur 2012 R2.

Nous allons voir comment installer le rôle licensing RDS et mettre une GPO basique pour configurer le(s) serveurs(s) host RDS avec ces informations.

Installation du rôle licensing

 Sur la page Overview des services RDS, cliquez sur le plus au dessus de RD Licensing

L’assistant vous demande quel(s) serveur(s) hébergera le rôle. Nous allons ici choisir le serveur qui héberge déjà les rôles Broker et Web (voir post précédent) car aucun des trois n’est très consommateurs de ressources machine et on peut donc les regrouper sur une architecture de petite taille.

Il faudra ensuite ajouter vos licences TS dans la console (Ici mon poste à une CAL temporaire)

Création d’une GPO pour configurer les serveurs host RDS

Afin de ne pas avoir à passer sur chaque serveur nous allons mettre une GPO sur les serveurs avec le rôle host.

J’ai créé une GPO nommée GPO_WRK_RDS_CONFIG et je l’ai placée dans l’OU AD réservée à mes serveurs RDS (tout rôles).

Le filtre de sécurité limite l’application à mes serveurs host RDS.

Nous allons maintenant voir les paramètres obligatoires et intéressants à mettre en place (tout ce qui suit est à adapter à vos besoins car nous).

Tout les paramètres sont dans la partie ordinateur de la stratégie.

Il faut en premier ce rendre dans : “Policies/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host”

Dans la partie “Licensing” :

Les paramètres suivants sont nécessaire pour la bonne configuration de l’infrastructure RDS.

Nous allons renseigner dans la 1ère ligne le nom complet du serveur hébergeant le rôle licensing (dans notre cas LAB-BRDS-02T.labo-pis.dom).

Dans le 3ème, nous spécifions le type de licence utiliser (soit par device, soit par user).

 

Dans la partie “redirection d’imprimante” :

Nous pouvons gérer la redirection des imprimantes clients dans les sessions remote desktop.

Dans le cas de ma dernière expérience il était nécessaire de la bloquer car nous avions des imprimantes installés sur les serveurs et les redirections prêtaient à confusion.

 

Dans le partie “Device and Resource Redirection” :

Nous allons ici bloquer la redirection audio et vidéo, la redirection de l’enregistrement audio, nous autorisons la redirection du port COM (car elle nous est nécessaire pour notre client dans mon cas).

Nous pouvons aussi gérer le presse-papier et d’autres options.

 

 Dans la partie “Session Time Limit” :

Nous allons mettre une durée de vie maximale aux sessions déconnectées.

Nous avons maintenant une collection de serveurs RDS Windows Server 2012 R2 fonctionnelle.

 

Introduction

Même si l'implémentation de DirectAccess s'est fortement simplifiée depuis Windows 2012 R2, il est possible de rencontrer de nombreuses difficultés lorsque le déploiement se fait en entreprise et non dans un lab. En effet, les postes clients, les équipements réseaux et bien d'autres facteurs peuvent influer sur le bon fonctionnement de cette technologie. Cet article à pour but de regrouper des conseils et des astuces pour réussir son déploiement de DirectAccess plus rapidement et est basé sur un retour d'expérience. Ainsi, j'évoquerai notamment les configurations non supportées, les outils pour dépanner un déploiement et quelques conseils lors de l’implémentation de son infrastructure DirectAccess.

NB : Cet article se base sur la version intégrée à Windows 2012 R2 de DirectAccess.

Configurations non supportées

Généralités :

Vous trouverez ci-dessous 2 liens vous indiquant les configurations non supportées et les types de déploiement possibles :

• https://technet.microsoft.com/en-us/library/dn464274.aspx

• https://technet.microsoft.com/en-us/library/dn464273.aspx

Manage Out et ISATAP :

Le Manage Out est la fonctionnalité permettant de gérer un client DirectAccess à distance. Cela peut offrir la possibilité à SCCM d'interagir avec l’ordinateur distant ou encore de se connecter à distance en remote desktop. Cependant, cela nécessite d'être en IPv6 natif. En effet, selon technet, bien que l'ISATAP soit fonctionnel, son utilisation n'est pas supportée. De plus, son déploiement n'est pas possible dans un environnement multisite ou avec du load balancing.

Modification des stratégies de groupes :

La modification des stratégies de groupes créés par DirectAccess n'est pas supportée.

Certificats à courbes elliptiques :

Les algorithmes de la suite B (dont font partie les algorithmes à courbes elliptiques) sont supportés depuis DirectAccess sous Windows 2008 R2 (https://technet.microsoft.com/en-us/library/ee382307(v=ws.10).aspx) et doivent pouvoir être utilisés pour les certificats ordinateurs . Cependant, il n'existe aucune documentation permettant de les utiliser avec DirectAccess. Aussi, le choix des algorithmes utilisés se fait au niveau des règles de connexion qui sont paramétrées par les stratégies de groupes DirectAccess. Par défaut, la règle de connexion utilise l'algorithme RSA. Pour le changer il faut se rendre dans les stratégies de groupe puis modifier les règles suivantes :

• GPO DirectAccess Client Settings : DirectAccess Policy-ClientToCorp

• GPO DirectAccess Client Settings : DirectAccess Policy-ClientToInfra

• GPO DirectAccess Server Settings : DirectAccess Policy-DAServerToCorp

• GPO DirectAccess Server Settings : DirectAccess Policy-DAServerToInfra

Les règles s'éditent dans “Computer Configuration > Windows Settings > Security Settings > Windows Firewall with Advanced Security”. Dans l'onglet “Authentication”, il faut cliquer sur le bouton “Customize” puis éditer la méthode d'authentification utilisant des certificats ordinateurs en la sélectionnant et en cliquant sur “Edit”.

Enfin, le champ “Signing Algorithm” peut être changé avec le bon algorithme.

Cependant, nous avons vu précédemment que la modification de stratégies de groupe DirectAccess n'est pas supportée. De plus, la customisation proposée sera écrasée à chaque modification de la configuration DirectAccess. L'une des solutions pourrait être de créer une stratégie de groupes avec des règles de connexion identiques mais incluant les algorithmes à courbes elliptiques. Cependant, il n'y a aucune certitude que cette règle sera traitée avant l'original car il n'y a pas de priorité sur celles-ci. Il existe donc un flou autour du déploiement de certificats signés par un algorithme à courbes elliptiques.

Contraintes système d'exploitation clients

Windows 8 et supérieur

Les versions Windows 8 clients et supérieures supportent toutes les fonctionnalités de DirectAccess ainsi que tous les types de déploiements. De plus DirectAccess sur Windows 8 ne nécessite pas d'avoir une infrastructure PKI (hormis dans le cas d'une authentification forte, y compris OTP) et fonctionne alors avec des certificats auto signés. Cependant vous pouvez rencontrez quelques contraintes lors de l'activation de l'authentification forte (http://blog.piservices.fr/post/DirectAccess-Deploiement-de-lauthentification-forte.aspx).

Windows 7

Le déploiement de DirectAccess sur des clients Windows 7 nécessite obligatoirement d'avoir une infrastructure PKI (certificat ordinateur en auto enrollment). De plus, si vous souhaitez une infrastrcture en haute disponibilité, sachez que vous ne pourrez opter que pour le load balancing. La fonctionnalité multisite permettant de posséder plusieurs serveurs DirectAccess en standalone tout en laissant le choix au client sur lequel il souhaite se connecter n'est pas disponible pour cette version de Windows. Aussi, si sur Windows 8, la méthode de transition IPv6 / IPv4 recommandée est l'IPHTTPS (notamment par sa simplicité de mise en oeuvre), ce n'est pas le choix le plus évident sous Windows 7. En effet, l'IPHTTPS réalise une double encryption des flux DirectAccess, ce qui peut causer des problèmes de performances. Pour rappel, depuis Windows 8, le tunnel IPSec étant sécurisé, la communication IPHTTPS ne réalise plus d'encryption évitant ainsi de réaliser deux fois cette opération (IPHTTPS et tunnel IPSec).

Troubleshooting

Netsh

L’outil en ligne de commande Netsh est sans doute l’un des outils les plus utiles pour effectuer un premier debug. Pour chaque interface liée à une technologie de transition IPv6/IPv4, nous pouvons obtenir un statut de connexion :

• 6To4 : netsh interface 6to4 show state
• Teredo : netsh interface teredo show state
• IPHTTPS : netsh interface httpstunnel show interfaces

Par exemple, lorsqu’il y a un problème avec la vérification de la CRL sur l’interface IPHTTPS, nous obtenons le code d’erreur 0x80092013 (pour l’attribut “Last Error Code”). Une recherche sur votre code d’erreur vous permettra d’identifier rapidement la cause d’une mauvaise connexion.

D’autre part Netsh peut vous aider à configurer vos interface réseaux. Il est d’ailleurs recommandé de désactiver les interfaces non utilisées. Par exemple, 6To4 qui n’est que très rarement utilisé peut être désactivé via la commande suivante :

Journaux d’événements

Vous pouvez retrouver des informations utiles dans l’observateur d’évènements pour dépanner votre connexion DirectAccess, Le journal “Operational” présent dans “Applications and services Logs > Microsoft > Windows > CAPI2” vous donnera des informations liés à vos certificats (erreur sur la vérification de la CRL, certificat expiré,…). Il convient de l’activer avant de pouvoir l’utiliser. en cliquant sur “Enable Log” via un clic droit sur le journal.

Aussi, le journal de sécurité peut vous renseigner sur les connexions IPSec qui ont réussies ou échouées. Pour se faire, il faut activer l’audit via la commande suivante :

En cas d’erreur, les id des évènements importants à retrouver sont les suivants : 4653, 4654, 4984.

Enfin, en cas de déploiement d’une infrastructure avec authentification forte via OTP, le journal “OTPCredentialProvider” présent dans “Applications and services Logs”, vous renseignera sur les évènements liés à cette méthode d’authentification.

Directaccess Connectivity Assistant

Le Directaccess connectivity assistant (DCA) est un assistant de connexion pour DirectAccess. Ce dernier est nativement disponible sur Windows 8 et supérieur mais nécessite d'être déployé sur Windows 7 (http://www.microsoft.com/en-us/download/details.aspx?id=29039). Il est d'ailleurs obligatoire dans le cadre de l'activation de l'authentification forte (via OTP ou carte à puce).

En marge du déploiement du client, il faut intégré le fichier ADMX dans le magasin central Active Directory afin de pouvoir le configurer par stratégie de groupe sur tous les postes utilisateurs concernés. Il convient donc de créer une stratégie de groupe possédant à minima les paramètres suivants (présent dans “Computer Configuration > Policies > Administratives Templates” ) :

• Corporate resources

• DTEs

Le paramètre “Corporate resources”, correspond à des ressources dont l'accès est testé pour valider que la connexion DirectAccess est opérationnelle. Attention : ces tests sont différents du serveur NLS (Network Location Server) qui permet à Windows de savoir s'il doit tenter de se connecter au réseau d'entreprise via DirectAccess. Ici, il s'agit simplement de tests réalisés par le DCA. La connexion DirectAccess peut être opérationnelle alors que l'une des ressources n'est pas disponible (et la connexion sera alors indiquée comme non fonctionnelle). Il est donc conseillé de fournir des ressources redondées. De plus, pour que DCA fonctionne de façon optimale, il est nécessaire d'indiquer une ressource de type PING et une autre de type HTTP (pointant sur un site web de votre infrastructure qui n’est pas le serveur NLS).

Le paramètre DTEs indique les points de terminaisons de la connexion DirectAccess sur le serveur. Ces derniers peuvent être obtenus de plusieurs manières. Chacune des règles  “DirectAccess Policy-ClientToCorp” et “DirectAccess Policy-ClientToInfra” de la GPO cliente (“GPO DirectAccess Client Settings”) possède l'une des valeurs à renseigner. Pour l'obtenir, rendez-vous dans l'onglet “Advanced” puis cliquez sur le bouton “Customize” de la section “IPsec tunneling”. Le champ “IPv6” de la section “Remote tunnel endpoint” contient la valeur recherchée.

Celles-ci sont à indiquer au format “PING:IP_Récupérée” dans la stratégie de groupe de configuration du client DCA.

Ces valeurs peuvent aussi être récupérées dans le registre via la commande Powershell suivante :

Cet outil permet de générer des logs exploitables par un administrateur pour débugguer des problèmes de connexions (vérification des certificats, test des connexions teredo, 6TO4 et iphttps, configuration firewall, ...). Pour se faire, l'utilisateur qui rencontre une erreur devra effectuer un clic droit sur le client (dans la barre des tâches) et cliquer sur “Advances Diagnostics”. Cela aura pour effet de générer une page html contenant les résultats dans le répertoire “C:\Users\NOM_USER\AppData\Local\Microsoft\DCA”.

DirectAccess Client Troubleshooting Tool

Cet outil permet de débugguer une connexion DirectAccess en la vérifiant point par point (Test certificats, firewall, ...). Ce dernier est disponible à partir de Windows (http://www.microsoft.com/en-us/download/details.aspx?id=41938), cependant, veillez à l'installer sur un système d'exploitation avec langue US sinon vous rencontrerez une erreur pendant l'exécution des tests.

Astuces

Mise à jour du système d'exploitation

Cela peut paraître normal mais il est impératif de mettre à jour continuellement vos serveurs DirectAccess et surtout avant l'implémentation de cette fonctionnalité. En effet, un très grand nombre de correctifs concernant DirectAccess ont été mis à disposition depuis la sortie de Windows 2012 R2.

Configuration IP et changement

Il s'agit plus d'un conseil que d'une astuce mais je vous recommande fortement de ne jamais changer la configuration IP d'un serveur sur lequel DirectAccess est configuré. En effet, cela peut avoir des effets de bord sur le serveur lui-même en dehors de la fonctionnalité DirectAccess qui peut ne plus être configurable. Vous pouvez vous retrouver confronter à devoir remettre l'ordinateur dans le domaine ou réinstaller la machine elle-même.

Configuration IP et load balancing

Si vous envisager un déploiement avec du load balancing, l’IP de la VIP (HLB ou NLB) sera l'IP original de votre serveur DirectAccess lorsque vous configurerez la haute disponibilité. Il faut donc tenir compte de cet aspect lorsque l'on fixe l'IP de son premier serveur DirectAccess lors de ce type de déploiement.

Teredo, 6To4, IPHTTPS et NAT

Dans le cas où l'infrastructure DirectAccess est derrière du NAT, il n'est possible d'utiliser que l'IPHTTPS (quelque soit le mode de déploiement : load banlancing, standalone).

OTP et Carte à puces

Je vous invite à consulter le lien suivant concernant le déploiement de l'authentification forte pour DirectAccess : http://blog.piservices.fr/post/DirectAccess-Deploiement-de-lauthentification-forte.aspx. Ce dernier explique le fonctionnement mais aussi les éventuelles erreurs que vous pouvez rencontrer et comment les corriger.

Introduction

Powershell 5.0 est encore en beta mais de nombreuses nouveautés sont déjà présentes. Nous allons aborder dans cet article quelques unes d'entres elles. Elles peuvent concerner : Powershell, son éditeur (Powershell ISE) ou encore son paramétrage dans Windows. Certaines avaient déjà été évoquées dans l'article suivant lors de la première preview de Powershell 5.0 :
http://blog.piservices.fr/post/Powershell-V5-Preview-est-sorti-!-DSC-Switch-OneGet-et-du-chocolat.aspx

NB : Contrairement à la première beta, Powershell 5.0 est dorénavant disponible pour Windows 2012 et supérieur (qui n’était compatible qu’avec Windows 2012 R2 et supérieur). Le lien suivant vous mènera à la dernière beta sortie (Novembre 2014) :

http://www.microsoft.com/en-us/download/details.aspx?id=44987

Gestion des Archives

Un nouveau module permettant de gérer nativement les archives apparaît dans Powershell 5.0. Cette option n'était auparavant disponible qu'au travers de module réalisé par la communauté. Ce dernier permet de générer des archives (Compress-Archive) ou de les extraire (Expand-Archive). Seul le format Zip est actuellement géré. Un paramètre nommé “update” permet de mettre à jour une archive existante en ajoutant seulement les nouveaux fichiers et les changements sur les fichiers déjà présents dans l'archive. Le paramètre “path” peut définir un ou plusieurs fichiers ainsi qu'un dossier entier en utilisant le caractère “*” (wildcard). Enfin le paramètre “CompressionLevel” permet d'influencer le taux de compression et la taille finale de l'archive.

Support des raccourcis claviers

La console Powershell supporte désormais certains raccourcis clavier : copier (CTRL+C), coller (CTRL+V), tout sélectionner (CTRL+A).

Gestion des liens symboliques

Il est dorénavant possible de créer/supprimer des raccourcis via Powershell. Cette fonctionnalité est incluse dans la commande New-Item en spécifiant le type “SymbolicLink”.

Création d'un raccourci vers un fichier

Création d'un raccourci vers un dossier

On peut aussi lister des fichier via la commande Get-ChildItem en passant par un raccourci !

Event Viewer

Un nouveau journal de log est apparu dans l'observateur d'événements. Par défaut, ce dernier enregistre les lancements de console Powershell et les erreurs générales comme un échec de chargement de module. Ce nouveau journal est situé dans Applications and Services Logs\Microsoft\Windows\PowerShell\Operational. Il peut aussi enregistrer les exécutions de code Powershell. Cette fonctionnalité s'active via GPO.

Attention : Activer l'utilisation de ce journal pour les exécutions de code est très verbeux. Néanmoins cela peut être très utile pour obtenir rapidement des traces d'actions effectuées sur des serveurs via Powershell.

Il est possible d'activer cette fonctionnalité via GPO (voir paragraphe ci-dessous).

GPO

Les modèles d'administration possède désormais un ADMX permettant de gérer quelques paramètres Powershell. Ce dernier est situé dans Administrative Templates / Windows Components / Windows PowerShell. Il serait compatible avec les systèmes d'exploitation de la famille Windows 7 / Windows 2008 et supérieur (je ne l'ai personnellement testé que sur Windows 10 Server Technical Preview). Cette nouveauté n'est donc pas totalement liée à Powershell 5.0 puisqu'elle sera fonctionnelle sur les anciennes versions de Powershell.

Les paramètres configurables sont les suivants :

• Activer les traces dans l'observateur d'événements pour tout exécution de script.
• Activer les traces dans l'observateur d'événements pour les exécutions de module Powershell (il faut préciser les modules concernés).
• Définir la politique d'exécution des scripts (Set-ExecutionPolicy). Il s'agit d'une très bonne nouvelle car il n'existait pas de solution pour généraliser ce paramètre sur un grand nombre de serveur hormis en passant par une ressource DSC (ce qui représente un déploiement beaucoup plus lourd).
• Activer automatique du transcript : cela permet de ne pas avoir à lancer la commande “start-transcript”. Il est également possible de définir le chemin où doit être stocké le transcript. Par défaut le nom du fichier est horodaté, contient le nom de l'ordinateur et est stocké dans le répertoire “Mes documents” de l'utilisateur de la session Powershell.
• Définir la source de l'aide Powershell. Depuis Powershell 3.0, l'aide des cmdlets n'est pas entièrement incluse avec le package d'installation Powershell. Il est nécessaire d'utiliser la commande “Update-Help” pour la mettre à jour (par défaut, elle est récupéré depuis internet). Cela permet entre autre de récupérer l'aide avec la langue qui nous intéresse. Grâce à ce paramètre, on peut dorénavant spécifier une source comme un partage de fichier. Néanmoins, l'utilisateur a toujours la possibilité de changer le comportement en indiquant lui même une valeur lors de l'exécution de la commande via le paramètre “SourcePath”.

Tous ces paramètres sont disponibles dans la configuration ordinateur et utilisateur de la GPO.

Transcript

La génération de transcript n'était jusqu'à présent fonctionnelle que dans la console Powershell. Grâce aux cmdlets “Start-Transcript” / “Stop-Transcript”, il est désormais possible de générer des fichiers de traces aussi via Powershell ISE.

Powershell ISE avec Powershell 4 :

Powershell ISE avec Powershell 5 :

PSEdit

Une nouveauté fait son apparition dans Powershell ISE et le PSRemoting : PSEdit. Cet outil existait déjà et permettait d'ouvrir script dans un nouvel onglet dans Powershell ISE lorsque l'on exécutait la commande suivante : PSEdit chemin_de_mon_script.

Cependant, dans cette nouvelle version de Powershell ISE, il est possible d'ouvrir des fichiers à distances. Il n'y a donc plus besoin d'ouvrir Powershell ISE sur la machine où se trouve le script pour l'éditer. Il suffit d'ouvrir une PSSession puis d'exécuter PSEdit.

Cette fonctionnalité est facilement testable même en local en simulant une session distante :

Il n'y a pas besoin de connaître le chemin exact du script puisque l'auto complétion est disponible pour le retrouver.

Enumérations

La dernière nouveauté expliquée dans cet article est plus orientée scripting. Les énumerations font leurs apparitions dans Powershell. Pour cela un nouveau mot clé est disponible : “enum”. Celles-ci vont nous permettre de réaliser plus rapidement de la validation de paramètres.

Prenons le cas du paramètre ErrorAction disponible sur toutes les commandes Powershell. Il n'est possible de fournir qu'un certain nombre de valeurs : Continue, Ignore, Inquire, SilentlyContinue, Stop, Suspend. Ceux-ci correspondent à une énumération.

La syntaxe d'une énumération est la suivante : Pour utiliser cette dernière dans une fonction :

Nous pouvons remarquer que les choix disponibles sont proposés par le système d'auto complétion.

Enfin, si l'on souhaite récupérer les valeurs d'une énumération, il faut exécuter la commande suivante :

Conclusion

Powershell 5.0 et Windows 10 sont riches en nouveautés pour le langage de scripting de Microsoft. Certaines d'entre elles n'ont pas été abordées mais feront l'objet d'articles dédiées :

• La création de classes d'objets personnalisés.
• Les améliorations de Desired State Configuration comme la gestion des configurations partielles permettant de segmenter celles-ci en plusieurs fichiers (exemple : par fonctionnalité).
• PowershellGet : à l'instar de OneGet qui permet de récupérer des packages, ce dernier offre la possibilité de récupérer des modules depuis internet ou depuis sa propre source. Ainsi, une société peut créer sa bibliothèque de modules Powershell.

Contexte

Suite au déploiement de Lync Server 2013, certains clients souhaitent améliorer la visibilité du produit au sein d’Outlook en rajoutant une icône dans la page d’accueil Outlook (par défaut pour créer une réunion Lync, il faut aller dans la partie calendrier).

Problématique

Cette personnalisation d’Outlook n’existe pas dans les modèles d’administration / personnalisation  d’Office (http://www.microsoft.com/en-us/download/details.aspx?id=35554). Cependant il est possible de déployer ce paramètre par GPO.

Solution

N.B : Cette solution a été testée sous Outlook 2010 et 2013.

Lors de la personnalisation du ruban d’Outlook ce dernier créer le fichier olkexplorer.officeUI. Ce fichier se trouve à l’emplacement suivant :

• Sous Windows XP : %Userprofile%\Local Settings\Application Data\Microsoft\Office\
• Sous Windows 7/8/8.1 :  %userprofile%\AppData\Local\Microsoft\Office\

Il suffit alors de personnaliser le ruban depuis un poste et de récupérer le fichier olkexplorer.officeUI.

Le déploiement du fichier se fait ensuite via un script lancé au démarrage du poste via GPO.

Avant :

Après :

Contexte

Lors de la modification d’un objet dans l’Active Directory (exemple : modification sur l’objet KRBTGT lors de l’installation d’un RODC), le Domain Controller redémarre automatiquement de manière inopinée et non planifiée avec ce message d’erreur :

A la suite du redémarre, les erreurs suivantes se trouvent dans l’Event Viewer :

Application – Wininit – Error 1015 : A critical system process, C:\Windows\system32\lsass.exe, failed with the status code c00000005. The machine must now be restarted.

Application – Application Error – Error 1000 : Faulting application name: lsass.exe

Cause

L’erreur est due à un paramètre de l’Audit object access. Ce problème est vraisemblablement un bug de Windows Server 2012 R2.

Solution

Pour résoudre ce problème, il faut désactiver (ou a minima de ne pas inspecter) la journalisation des accès aux objets dans le Local Security Group ou dans une GPO.

Ce paramètre se trouve dans Computer Configuration, Policies, Windows Settings, Security Settings, Local policies, Audit Policy.

Dans les nouveautés de Windows Server 2012 l’interface graphique de gestion granulaire de mot de passe vient simplifier le travail de l’Administrateur en lui évitant de passer par les GPO et ADSIEdit.

La gestion granulaire des mots de passe est déjà disponible depuis Windows Server 2008, un niveau fonctionnel de 2008 suffit donc pour bénéficier de l’interface graphique sur un serveur 2012.

Avant de commencer : il est très probable que dès la mise en place de la stratégie vos utilisateurs aient à changer de mot de passe, or certaines applications ne peuvent le gérer, je vous conseille donc d’appliquer la stratégie une fois vos utilisateurs délogué.

Dans le Server Manager, lancer le tool “Active Directory Administrative Center” :

Une fois lancé, basculer en vue arborescente (Tree View), puis dans le dossier System, double-cliquer sur le dossier “Password Settings Container”

Pour créer une nouvelle politique de mot de passe, sélectionner dans l’onglet de droite : New –> Password Setting

Nous arrivons alors sur cette fenêtre et l’on remarque que Windows Server 2012 se veut intuitif :

Les textbox précédés d’un astérisque rouge sont des éléments requis pour la création de la stratégie.

Parmi ces éléments, il y a le champ “Precedence”, qui permet – dans le cas déconseillé ou plusieurs stratégies s’appliquerait aux mêmes utilisateurs ou groupes – de gérer quelle stratégie s’applique en priorité.

Une fois le paramétrage terminé, cliquer sur “Add” et la stratégie est immédiatement exécutée pour les utilisateurs concernés.

Une alerte courante est issue du moniteur “Active Directory Bind Monitor” du management pack AD:

The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.

En ouvrant les propriétés de l’alerte (double-clic) et l’onglet Alert Context, on peut voir dans l’exemple ci-dessous le compte incréminé, dans le champ User:

l’execution d’une GPO a échoué pour ce compte.

Independement de la solution proposé dans la description de l’alerte, une premiere piste consiste a verifier si le compte en question n’a pas une session restée ouverte sur la machine (ceci meme si le compte est désactivé dans Active Directory). Si c’est le cas, fermez cette session, reseter le moniteur dans SCOM (il s’agit d’un moniteur de type “Manual Reset”), et verifiez par la suite que le problème ne se reproduit pas.