Articles Tagués ‘Windows 10’

 

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

Microsoft vient de publier les Modèles d’Administrations/Administratives Templates (ADMX, ADML) AD pour Windows 10 {1709} Creator Updates. Téléchargez-les dès maintenant en cliquant sur le lien ci-dessous

Le fichier téléchargé (MSI file) inclut les modèles d’administration publiés pour Windows 10 (Fall Creators Update « 1709 »), dans les langues suivantes :

  • cs-CZ Czech – Czech Republic
  • da-DK Danish – Denmark
  • de-DE German – Germany
  • el-GR Greek – Greece
  • en-US English – United States
  • es-ES Spanish – Spain
  • fi-FL Finnish – Finland
  • fr-FR French – France
  • hu-HU Hungarian – Hungary
  • it-IT Italian – Italy
  • ja-JP Japanese – Japan
  • ko-KR Korean – Korea
  • nb-NO Norwegian (Bokmål) – Norway
  • nl-NL Dutch – The Netherlands
  • pl-PL Polish – Poland
  • pt-BR Portuguese – Brazil
  • pt-PT Portuguese – Portugal
  • ru-RU Russian – Russia
  • sv-SE Swedish – Sweden
  • zh-CN Chinese – China
  • zh-TW Chinese – Taiwan

 

Enfin, notez les prérequis (OS Requirement) suivants :

  • Windows 10
  • Windows 8.1
  • Windows 7
  • Windows Server 2016
  • Windows Server 2012 R2
  • Windows Server 2012
  • Windows Server 2008 R2
S’applique à : Windows Vista, Windows 7/8/8.1, Windows 10, Windows Server 2008/2008 R2, Windows Server 2012/2012 R2, Windows Server 2016
A noter que certains paramètres et instructions ne sont disponibles que sur les dernières versions de Windows Server et Windows Client, e.i Windows 10 - Windows Server 2016. lancer MSG.exe /? dan un premier temps pour obtenir la liste des paramètres disponibles

 

Introduction

WhoAmI.exe est un outil en ligne de commande natif dans les systèmes d’exploitation Windows Server et Windows Client.

Il vous permet de lister tous les privilèges et groupes d’appartenance de l’utilisateur connecté actuellement (de manière interactive) sur une Session Windows. WhoAmi.exe permet également de collecter les informations telles que le FQDN /UPN ou encore LOGONID de l’utilisateur connecté.

S’il est utilisé/exécuté sans aucun paramètre, WhoAmi.exe affichera le nom de l’utilisateur connecté actuellement et son domaine d’appartenance (au format NTML Domaine\Nom_Utilisateur) ou le nom du Groupe de travail (WorkGroup) si la machine n’est pas intégrée dans un domaine Active Directory.

Syntaxe

L’outil WhoAmi.exe peut être utilisé sous trois modes différents (trois syntaxes), à savoir

Sysntaxe 1 :

WHOAMI [/UPN | /FQDN | /LOGONID]

/UPN | Affiche le nom d’utilisateur au format UPN (nom d’utilisateur principal).
/FQDN |  Affiche le nom d’utilisateur au format FQDN (nom de domaine pleinement qualifié).
/LOGONID | Affiche l’ID de connexion de l’utilisateur actuel.

LIRE LA SUITE...

 

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 🙂

 

GPO Guys, Hello Again :),

Dans le cadre d’un projet de migration vers Windows Server 2016, une task intéressante faisant partie du plan de migration consistait à convertir toutes les GPOs locales de certains serveurs (en mode WorkGroup) placés en DMZ vers des GPOs de domaine A(ctive) D(irectory).

J’aimerais donc partager avec vous à travers cet article la méthode /outils utilisé pour réaliser cette action, qui n’est malheureusement pas décrite dans les K(nowledge) B(ase) de MS.

Alors comment ça marche ?

Tout d’abord, vous devez faire le listing de toutes les machines ayant des GPOs locales, à transformer en GPOs de domaine.

Téléchargez ensuite l’outil LGPO.exe et placez-le sur toutes les machines Windows ayant des GPOs Locale à récupérer.

LGPO.exe est un outil en ligne de commande très puissant qui vous permet d’accélérer la gestion de vos stratégies de groupes locales (LGPO : Local Group Policy Objects).

Actuellement disponible en V2.0, LGPO.exe prend désormais en charge les MLGPO (Multiple Local Group Policy Objects) ainsi que les valeurs de Registre REG_QWORD 64-bit.

LGPO.exe fait partie du package « Microsoft Security Compliance Toolkit 1.0« .

 

Vous pouvez le télécharger gratuitement ici.

HowTo : Transformer une GPO locale >> GPO de domaine

Dans l’exemple suivant, nous allons convertir une GPO locale, configurée sur un de mes serveurs d’administration et la transformer /migrer vers un domaine Active Directory.

Je vais commencer par placer (via un Copy/Paste) l’outil LGPO.exe sur mon serveur d’administration (l’outil sera placé dans le dossier C:\GPOTools) et je lancerai ensuite l’Invite de Commande (CMD.exe) en tant qu’Administrateur.

Enfin, la commande suivante est exécutée pour faire un Backup de la GPO locale :

LGPO.exe /b C:\LocalGPOs_Backup /n MyLocalGPO

Maintenant que le Package de GPO Locale est généré, lancez l’outil GPMC.msc depuis un Domain Controller ou une machine d’administration ayant les outils RSAT installés et suivez les instructions suivantes :

  • Copiez /Collez le Package de GPO généré précédemment sur votre DC ou Machine d’Administration
  • Faites un clic-droit sur le noeud « Group Policy Objects » (ou Objets de stratégie de groupe si votre OS Server est en FR) et sélectionnez « Import Settings…« 

  • L’assistant d’importation de paramètres GP apparaît, cliquez sur « Next /Suivant » pour continuer
  • Spécifiez l’emplacement de la sauvegarde GPO locale créée précédemment :

  • Vérifiez les informations concernant votre GPO locale et cliquez sur « Next /Suivant » :

  • Une fois les paramètres importés, cliquez sur « Finish » pour lancer /confirmer le processus d’importation au niveau de la GPO de domaine

  • L’assistant vous affiche le statut post-importation des paramètres : Succeeded si l’opération s’est bien déroulée 🙂 :

  • Enfin, vérifiez que les paramètres de votre GPO locale sont bien présents au niveau de la GPO de domaine :

Et voilà le tour est joué :).

HK.

Vous découvrez à travers cette vidéo l’outil en ligne de commande « NET.exe » ainsi que les différents modes et contextes dans lesquels vous pouvez l’exécuter.
Pour vous permettre de vous familiariser avec l’outil, les explications sont suivies de plusieurs démonstrations techniques.

N’hésitez pas à « Liker & Partager » cette vidéo et vous abonner à notre chaine YT pour être informé de toute nouvelle vidéo publiée.
Stay in touch :);

A bientôt

HK

 

S’applique à : RDS Windows Server 2012, RDS Windows Server 2012 R2 et RDS Windows Server 2016

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

Plusieurs services de rôles RDS peuvent être hébergés et exécutés sur Windows Server 2016 en mode « Core ». Voir le tableau ci-après :

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 2016 « 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 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 2008/2008, 2012 /2012 R2 ou encore 2016).

Depuis un Serveur d’Administration

Depuis Windows Server (2008 R2 ou ultérieur), lancez Windows PowerShell 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