Liste des applications GUI sous Windows Server Core 2012 R2

S’applique aussi à Windows Server Core 2008 – 2008 R2 – 2012 

Malgré l’absence de l’interface graphique habituelle dans une installation minimale « mode Core » ainsi que :

• Menu Démarrer
• Barre des tâches,
• Windows Explorer Desktop Shell (Explorer.exe)
• Toutes les consoles MMC
• Tous les utilitaires de panneau de configuration, sauf « Intl.cpl » et « Timedate.cpl ».
• Windows Mail
• Windows Media Player
• Tous les outils comme Paint, Calculatrice et Wordpad

Certains outils et applications graphiques restent disponibles et accessibles, ci-après la liste des applications GUI :

Note : sous Windows Server Core 2008 et 2008 R2, l’outil Microsoft Support Diagnostic Tool (MSDT.exe) est disponible en plus des applications GUI listées ci-dessus.

Il suffit de saisir le nom de l’exécutable ou fichier .cpl (Control Panel) pour faire appel à l’application souhaitée, si vous voulez configurer la « Date & Heure » par exemple , vous saisissez Timedate.cpl depuis l’invite de commande et la boite de dialogue s’ouvre, voir image ci-après :

Liste des rôles et fonctionnalités sous Windows Server Core 2012 R2

S’applique aussi à Windows Server Core 2012 Sous Windows Server Core 2008 et 2008 R2, uniquement les fonctionnalités et rôles suivants sont pris en charge :

9 Rôles

• Services de domaine Active Directory (AD DS)
• Services AD LDS (Active Directory Lightweight Directory Services)
• DHCP
• DNS
• Services de fichiers
• Serveur d’impression
• IIS (Serveur Web )
• Hyper-V **
• Services de diffusion multimédia en continu **

** :  Les binaires des deux rôles « Serveur Hyper-V & Services de diffusion multimédia en continu » ne sont pas présents par défaut sur Windows Server 2008, il faut télécharger d’abord depuis le centre de téléchargement de Microsoft | Note : Hyper-V est inclut dans le SP1 de Windows Server 2008 

 

10 Fonctionnalités

• Sauvegarde
• Chiffrement de lecteur BitLocker
• Clustering avec basculement
• MPIO (Multipath I/O)
• Équilibrage de la charge réseau
• Stockage amovible
• Protocole SNMP (Simple Network Management Protocol)
• Sous-système pour les applications UNIX
• Client Telnet
• Service WINS (Windows Internet Name Service)

 

Sous Windows Server Core 2012 et 2012 R2 de nouveaux rôles et fonctionnalités sont désormais supportés et fournit avec l’OS. Des fonctionnalités supplémentaires peuvent être ajoutées à partir des sources d’installation de Windows Server 2012 ou 2012 R2 « fichier .wim ».

Pour connaître la liste complète des rôles et fonctionnalités

=> Commencez par lancer Windows PowerShell en saisissant la commande Start PowerShell depuis l’invite de commande

=> PowerShell s’ouvre, saisissez la cmdlette Get-WindowsFeature 

PowerShell collecte alors les informations sur les rôles et fonctionnalités Windows et vous retourne le résultat comme montré dans l’image ci-dessus.

Comme vous pouvez le constater, la colonne « Install State » indique le statut du rôle, service de rôle ou fonctionnalité, on distingue 3 statuts :

Available : Le rôle, service de rôle ou fonctionnalité est disponible (ses binaires sont présents sur l’OS) et peut être ajouté /installé

Removed : Le rôle, service de rôle ou fonctionnalité est supprimé (ses binaires ne sont pas présents sur l’OS). Il faut donc ajouter /installer le rôle, service de rôle ou fonctionnalité à partir des sources d’installation de Windows Server 2012 R2 (depuis fichier .wim par exemple)

Installed  : Le rôle, service de rôle ou fonctionnalité est déjà installé Certains rôles et fonctionnalités dépendant du mode « GUI » comme WDS, AD FS ou encore Visionneuse XPS ne peuvent être installés et sont supprimés par défaut (removed)

Pour obtenir la liste complète des rôles et fonctionnalités qui ne peuvent être ajoutés /installés (par défaut)

=> Depuis Windows PowerShell, saisissez :

Get-WindowsFeature | Where-Object {$_.InstallState -eq « Removed »}

Pour obtenir la liste complète des rôles et fonctionnalités qui peuvent être ajoutés /installés

=> Depuis Windows PowerShell, saisissez :

Get-WindowsFeature | Where-Object {$_.InstallState -eq « Available »}

Note : Certains rôles et fonctionnalités sont installés par défaut avec Windows Server Core 2012 et 2012 R2

Pour obtenir la liste complète des rôles et fonctionnalités installés par défaut :

=> Depuis Windows PowerShell, saisissez :

Get-WindowsFeature | Where-Object {$_.InstallState -eq « Installed »}

Pour conclure, Windows Server Core 2012 R2 prend en charge :

13 rôles

• Services de Certificat Active Directory (AD CS)
• Services de domaine Active Directory (AD DS)
• DHCP
• DNS
• Services de fichiers (dont le Gestionnaire de ressources du serveur de fichiers)
• Services AD LDS (Active Directory Lightweight Directory Services)
• Hyper-V
• Services d’impression et de numérisation de document
• Services de diffusion multimédia en continu
• IIS (dont une partie d’ASP.NET)
• Services WSUS (Windows Server Update Services)
• AD RMS (Active Directory Rights Management Server)
• Routage et accès distant, y compris les sous-rôles suivants :
  • Service Broker pour les connexions des services Bureau à distance
  • Gestionnaire de licences
  • Virtualisation

29 Fonctionnalités

• Microsoft .NET Framework 3.5
• Microsoft .NET Framework 4.5
• Windows PowerShell
• Service de transfert intelligent en arrière-plan (BITS)
• Chiffrement de lecteur BitLocker
• Déverrouillage réseau BitLocker
• BranchCache
• Data Center Bridging (DCB)
• Stockage étendu
• Clusters de basculement
• MPIO (Multipath I/O)
• Équilibrage de la charge réseau
• Protocole PNRP (Peer Name Resolution Protocol)
• Expérience audio-vidéo haute qualité Windows
• Compression différentielle à distance
• Services TCP/IP simples
• Proxy RPC sur HTTP
• Serveur SMTP
• Service SNMP
• Client Telnet
• Serveur Telnet
• Client TFTP
• Base de données interne Windows
• Accès Web Windows PowerShell
• Service d’activation des processus Windows
• Gestion du stockage Windows basé sur des normes
• Extension WinRM IIS
• Serveur WINS
• Prise en charge de WoW64

 

Astuce : si vous êtes amenés à gérer une infrastructure système Windows Server Core 2012 R2 existante  et  que vous souhaitez connaître la liste des rôles, services de rôle ou fonctionnalité qui ont déjà été ajoutés, vous pouvez spécifier un filtre avec mot clé, dans l’exemple suivant, je souhaiterais savoir si le rôle DHCP est déjà installé ou pas, depuis Windows PowerShell vous saisissez :

Get-WindowsFeature | Where-Object {$_.DisplayName -Like « *DHCP*}

Veillez à bien mettre le symbole * avant et après le mot de clé.

Désactiver l’IPv6 et ses composants en un seul clic

 

J’ai publié un script permettant de désactiver l’IPv6 et tous ses composants dans la Galerie TechNet.

Le script est téléchargeable ici

Il est à exécuter avec des privilèges Administrateur, il s’applique à :

• Windows Vista
• Windows Seven
• Windows 8
• Windows 8.1
• Windows 2008
• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2

Désactiver l’animation à la première ouverture de session sous Windows 8 et Windows 8.1

Quand un utilisateur ouvre sa session Windows pour la première fois sous Windows 8, Windows 8.1, Windows RT ou encore Windows RT 8.1, une animation de bienvenue s’affiche et les images suivantes défilent pendant quelques secondes jusqu’à que vous voyez votre bureau classique ou le Menu Accueil ‘Interface UI ».

Pour certains professionnels IT comme les administrateurs ou les ingénieurs systèmes gérant des parcs informatique composés de postes de travail ou des tablettes exécutant l’une de ces versions, cette animation à la première connexion peut représenter une perte de temps pour les utilisateurs finaux parce qu’ils sont obligés d’attendre pendant cette phase de préparation de leurs nouveaux comptes utilisateurs, qui des fois peut prendre un temps non négligeable.

En désactivant cette animation de première connexion, la préparation du nouveau compte utilisateur prendra moins de temps et l’utilisateur ne verra pas les différentes phases de préparation.

Je vous présente à travers cet article deux méthodes pour désactiver cette animation de la première ouverture de session.

#Méthode N°1 

1. Ouvrez l’éditeur de registre (regedit.exe) en tant qu’Administrateur

2. Naviguez jusqu’au

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

3. Faites un clic droit sur System => Nouveau => Valeur DWORD 32bits :

=========================================================

Nom de la valeur           : EnableFirstLogonAnimation

Données de la valeur   : 0 : Désactiver l’animation 

=========================================================

Pour réactiver l’animation de bienvenue remplacez la donnée de la valeur EnableFirstLogonAnimation par 1

ASTUCE

J’ai développé un petit script Batch que vous pouvez télécharger à cette adresse :

http://gallery.technet.microsoft.com/Dsactiver-lanimation-de-la-79d61a30

Ce script est à exécuter en tant qu’Administrateur, il permet de créer cette valeur au niveau de la BDR:

C’est pratique lorsque vous voulez automatiser cette tâche via une GPO par exemple (e.i : script d’ouverture de session).

#Méthode N°2 

1. Ouvrez l’éditeur de stratégie de groupe local (GPEDIT.msc)

2. Naviguez jusqu’au Configuration Ordinateur \ Modèles d’Administration \ Système \ Ouverture de session

3. Localisez le paramètre de stratégie de groupe « Afficher l’animation à la première connexion » et double cliquez dessus

4. Cliquez sur Activé pour activer ce paramètre.

5. Ouvrez l’Invite de commande et saisissez gpupdate /force pour rafraîchir la base des stratégies de groupes.

Après avoir appliqué l’une des deux méthodes, les utilisateurs ouvrant désormais une session Windows pour la première fois verront uniquement le message suivant:

 

Obtenir le numéro de série et le modèle d’un serveur ou poste de travail à l’aide de l’outil WMIC.exe

Vous pouvez être amené à faire appel au support technique d’un constructeur de serveurs ou de postes de travail (Dell, HP, IBM …etc) suite à un problème matériel, souvent la personne au bout du fil vous demande dans un premier temps le numéro de série (appelé aussi Service Tag) du serveur ou poste de travail posant problème.

Parfois le modèle de la machine peut être demandé aussi pour identifier précisément le matériel.

Ces informations sont généralement présentes sur une étiquette collée quelque part sur le serveur ou le poste de travail (sous la batterie, à l’intérieur de la machine ou encore sous l’unité centrale voir des fois à des endroits inaccessibles).

De plus, Il se peut aussi que le texte de l’étiquette soit effacé.

Eh bien, sachez que vous pouvez utiliser l’outil en ligne de commande WMIC.exe pour obtenir le numéro de série ainsi que le modèle de votre serveur ou poste de travail.

L’outil WMIC.exe interroge le BIOS (si ces informations y sont stockées, ce n’est pas toujours le cas) et vous les affiche.

Pour ce faire, ouvrez l’invite de commande (cmd.exe) en tant qu’Administrateur et saisir :

=> Pour obtenir le numéro de série

WMIC Bios get serialnumber

=> Pour obtenir à la fois le numéro de série et le modèle

WMIC csproduct get name, identifyingnumber

Voir image ci-après:

 

Bug : Windows 8.1 avec l’Update KB2919355 et WSUS 3.0 SP2 avec SSL

 

Si vous utilisez un serveur WSUS (Windows Server Update Services) en version 3 avec SP2 pour le téléchargement, gestion et distribution des mises à jour sur l’ensemble des postes de travail de votre réseau et plus précisément sur des postes de travail Windows 8.1, sachez qu’un problème de communication entre WSUS 3.0 SP2 avec SSL activé et WIndows 8.1 avec l’update KB2919355 a été identifié.

Desciption du problème

Ce problème parvient dans les situations /scénarios suivants:

1. Postes de travail : Windows 8.1 avec l’update KB2919355 ne peuvent contacter et récupérer des mises à jour depuis un serveur WSUS 3.0 SP2 installé sur l’une des versions suivantes de Windows Server

• Windows Server 2003 SP2
• Windows Server 2003 R2 SP2
• Windows Server 2008 SP2
• Windows Server 2008 R2

2. HTTPS et SSL (Secure Sockets Layer) sont activés sur le serveur WSUS
3. TLS 1.2 n’est pas activé sur le serveur WSUS

Le problème parvient uniquement sur les infrastructures WSUS 3.0 SP2 ou le serveur WSUS est configuré en HTTPS avec SSL activé (quant à l’option TLS 1.2, elle est désactivée « par défaut ») et uniquement sur des postes de travail exécutant Windows 8.1 avec la KB2919355.

Solution

#Premier scénario:

Si votre serveur WSUS 3.0 SP2 est installé sur Windows Server 2008 R2, la solution la simple vous permettant de rétablir la situation et résout ce problème d’analyse de mises à jour depuis les postes Windows 8.1 avec KB2919355 est :

##Méthode 1 : Activer TLS 1.2 sur le serveur WSUS

##Méthode 2 : Désactiver le protocole HTTPS sur le serveur WSUS

#Deuxième scénario :

Si votre serveur WSUS 3.0 SP2 est installé sur une version autre que Windows Server 2008 R2, la solution serait de :

##Méthode 1 : Désactiver le protocole HTTPS sur le serveur WSUS

Dès que Microsoft publiera un « Fix » pour corriger ce problème, vous pouvez réactiver le HTTPS sur le serveur WSUS

La mise à jour KB2919355 est toujours disponible et téléchargeable depuis Microsoft Update, je vous invite à contrôler et arrêter son téléchargement /déploiement sur les postes de travail de votre réseau jusqu’à publication du correctif, qui l’éditeur ne tardera pas à le publier.

Pour info : la même mise à jour « KB2919355 » est disponible pour Windows Server 2012 R2, nous avons identifié un problème de démarrage lié à cette KB sur certains serveurs (certains modèles HP, Dell, Supermicro ..), je vous invite à lire cet article :

Problème de démarrage après l’installation de la mise à jour KB2919355 sous Windows Server 2012 R2

Migration des utilisateurs et groupes locaux depuis Windows Server 2003 vers Windows Server 2008 R2

 

Note : cette procédure s’applique aussi à des serveurs faisant parti d’un domaine Active Directory

Dans un « Groupe de travail », aucune gestion centralisée des comptes utilisateurs et des groupes n’est possible.

En effet, ces derniers sont créés et stockés localement sur chaque serveur et gérés depuis l’outil « Utilisateurs et groupes locaux » : lusrmgr.msc

Dans un groupe de travail et dans le cas d’une migration d’un ou plusieurs serveurs exécutant Windows Server 2003 vers Windows Server 2008 R2, la migration des comptes utilisateurs et groupes locaux est un élément à prendre en compte afin que les utilisateurs locaux puissent continuer à avoir accès au(x) serveur(s) après l’upgrade en Windows Server 2008 R2.

Je vous présente à travers cet article la procédure de migration des utilisateurs et groupes locaux depuis Windows Server 2003 vers Windows Server 2008 R2 en utilisant la fonctionnalité Windows « Outils de migration de Windows Server » fournit avec Windows Server 2008 R2.

Important : Framework .Net v2.0 & PowerShell v1.0 (ou toutes versions ultérieurs) sont des pré requis pour cette migration, à vérifier ou à installer éventuellement sur le serveur source exécutant Windows Server 2003. De plus, notez que Windows Server 2003 doit avoir au moins le SP1 pour supporter Windows PowerShell v1.0. Donc commencez par installer le SP1 de Windows Server 2003 si ce n’est pas déjà fait.

Nous allons effectuer cette migration depuis un serveur source nommé « SRV2003 » exécutant Windows Server 2003 SP1 vers un serveur de destination nommé « SRV2008R2 » exécutant Windows Server 2008 R2.

Les deux serveurs sont dans un Groupe de travail.

Sur mon serveur source « SRV2003« , j’ai les comptes utilisateurs et groupes locaux suivants :

Le serveur de destination « SRV2008R2 » est fraîchement installé, aucun compte utilisateur ni groupe local n’est présent pour l’instant :

Etapes de migration

1. Depuis le serveur de destination « SRV2008R2 », ouvrez l’Invite de commande en tant qu’Administrateur et saisissez la commande suivante pour installer la fonctionnalité « Outils de migration de Windows Server »:

Servermanagercmd -i Migration

Note : vous pouvez aussi utiliser le Gestionnaire de serveur pour ajouter /installer cette fonctionnalité Windows 

Dès que l’installation est terminée, cliquez sur Démarrer, ensuite Outils d’Administration et vérifiez que le dossier Outils de migration de Windows Server est ajouté :

1. Maintenant, nous allons utiliser l’outil SmigDeploy.exe (outil fournit avec la fonctionnalité qu’on vienne d’installer) pour créer /générer un dossier de déploiement pour le serveur source, ce dossier contiendra les outils nécessaires qui vont nous permettre d’effectuer la migration des comptes utilisateurs et groupes locaux vers le serveur de destination.

Pour ce faire, commencez par créer et partager un dossier depuis le serveur source :

-> Ouvrez l’invite de commande depuis SRV2003 et saisissez les commandes suivantes pour créer et partager le dossier de déploiement « Migration » :

Mkdir C:\Migration

Net Share Migration=C:\Migration

-> Saisissez ensuite (depuis la même invite de commande) : Start /w C: 

Pour accéder à la partition C: hébergeant le dossier de déploiement que vous venez de créer et partager.

-> Faites un clic droit sur le dossier Migration ensuite sélectionnez Propriétés et enfin cliquez sur l’onglet Partage

-> Cliquez sur Autorisations et cochez l’autorisation « Modifier » pour Tout le monde, cliquez ensuite sur Appliquer ensuite OK.

Lancez cette fois ci l’Invite de commande depuis le serveur de destination SRV2008R2 et saisissez les commandes suivantes :

-> Pour accéder au dossier contenant l’outil de migration SmigDeploy.exe

cd %windir%\System32\ServerMigrationTools

-> Pour générer le dossier de déploiement pour le serveur source.

Note : mon serveur source SRV2003 (Windows Server 2003 SP1) est en version x32 donc je vais utiliser la valeur X86 avec le paramètre Architecture :

SmigDeploy.exe /package /architecture X86 /os WS03 /path \ \SRV2003\Migration

 Si votre OS Windows Server 2003 est en version x64, remplacez la valeur X86 par X64.

-> Enfin, vous pouvez constater que le dossier \ \SRV2003\Migration contient désormais un dossier nommé « SMT_ws03_x86 »

3. Nous devons maintenant terminer la configuration du dossier de déploiement sur le serveur source en inscrivant certaines Cmdlettes PowerShell, lancez l’invite de commande depuis SRV2003 saisissez :

cd C:\Migration\SMT_ws03_x86

SmigDeploy.exe

Après l’exécution de SmigDeploy.exe, une fenêtre de Windows PowerShell s’ouvre automatiquement :

Si par erreur vous avez fermé la fenêtre PowerShell, lancez Le module PowerShell des outils de migration de Windows Server :           ->Cliquez sur le menu Démarrer, ensuite Outils d’administration et enfin Outils de migration de Windows Server et cliquez sur Outils de migration 

Nous allons utiliser le paramètre Export-SmigServerSetting pour exporter tous les comptes utilisateurs et groupes locaux.

J’ai créé le dossier suivant C:\Migration\Export, ce dernier recevra le fichier exporté (.mig).

-> Depuis la fenêtre PowerShell ouverte, saisissez la commande suivante :

Export-SmigServerSetting -User All -Group -Path \SRV2003\Migration\Export -Verbose

Vous êtes invité à renseigner un mot de passe pour encrypter le fichier de migration qui sera généré :

Après avoir renseigné le mot de passe, une phase de collection des données démarre

Quand l’export est effectué, le résultat suivant apparaît :

Après l’export, un fichier nommé « srvmig.mig » est généré dans C:\Migration\Export

1. Nous arrivons à la dernière étape qui consiste tout simplement à importer le fichier de migration généré précédemment « srvmig.mig » contenant tous les comptes utilisateurs et groupes locaux du serveur source dans le serveur de destination (Windows Server 2008R2)

-> Depuis SRV2008R2, Cliquez sur le menu Démarrer, ensuite Outils d’administration et enfin Outils de migration de Windows Server et lancez Outils de migration de Windows Server en tant qu’Administrateur

-> Saisissez la commande suivante :

Import-SmigServerSetting -User Enabled -Group -Path \SRV2003\Migration\Export -Verbose

Vous êtes invité à renseigner le même mot de passe spécifié au moment de l’export

Après avoir renseigné le mot de passe, une phase de collection des données démarre

Après l’import, le résultat suivant apparaît :

Notez que si des comptes utilisateurs ou de groupes présents sur le serveur de destination portent le même nom que les comptes utilisateurs ou groupes exportés depuis le serveur source, ces derniers ne seront pas migrés, c’est le cas pour le compte Administrateur.

Enfin, cliquez sur Démarrer ensuite Exécuter et saisissez Lusrmgr.msc, vérifiez que vos comptes utilisateurs et groupes locaux sont bien migrés :

 

Vérifiez aussi les appartenances des comptes utilisateurs aux groupes :

Important : Les comptes utilisateurs locaux migrés ont « par défaut » les propriétés suivantes :

==> L’utilisateur doit changer le mot de passe à la prochaine ouverture de session

==> Le compte est désactivé

Donc n’oubliez pas de réactiver les comptes utilisateurs après la migration.

J’espère que cet article pourra vous être utile.

Problème de démarrage après l’installation de la mise à jour KB2919355 sous Windows Server 2012 R2

 

Le correctif KB2919355 a été publié par Microsoft le 05/05/2014, ce dernier s’applique uniquement à Windows Server 2012 R2 et Windows 8.1. Il est téléchargeable depuis le centre de téléchargement de Microsoft (pour une installation en mode Offline), depuis Microsoft Update ou encore depuis un serveur WSUS disponible sur le réseau local.

Plusieurs personnes ont rencontré un problème de démarrage de Windows Server 2012 R2 après l’installation de cette mise à jour et l’ont remonté sur plusieurs forums notamment sur le forum TechNet de Microsoft.

Il s’avère que ce problème parvient uniquement sur certains modèles de serveurs HP, Dell, IBM et Supermicro et plus précisément sur certains serveurs ayant l’une des cartes RAID suivantes :

• Dell H200 PERC controller
• HP Dynamic Smart Array B320i controller FBWC
• HP Dynamic Smart Array B120i SATA RAID Controller
• IBM x240 with on-board LSI SAS2004 ROC controller
• LSI 2308 on-board controllers
• LSI 9211-4i controllers
• LSI 9211-8i controllers
• LSI SAS 9211
• Supermicro X10SL7-F motherboard
• Supermicro X9DRH-iTF motherboard
• Supermicro X9SCM-IIF motherboard

 

Donc, si vous rencontrez ce problème sur un serveur ayant une carte RAID faisant parti de la liste ci-dessus, ne perdez pas des heures ou des jours de diagnostic ni à chercher une solution, démarrez tout simplement votre serveur Windows Server 2012 R2 en mode sans echec et désinstaller la KB2919355 pour que le serveur démarre normalement de nouveau.

Microsoft ne communique pas encore sur ce bug mais apparemment des investigations sont en cours et l’éditeur ne va pas tarder à publier un « Fix » pour corriger ce problème.

J’espère que cet article pourra vous être utile.