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

 

Ping everyone,

Petit retour d’expérience !

J’ai été sollicité par l’équipe d’Ingés RUN aujourd’hui chez le client chez lequel je suis en mission pour un problème sur la vue « Etendu » du snap-in « Services.msc », qui apparemment est vide !!

Ce problème a été constaté sur des postes de travail « physiques » Windows XP SP3 /Windows 7 mais aussi sur des serveurs « Virtuels » Windows Server 2003 /2008 ou encore 2008 R2.

Sous un Windows XP, le contenu de la vue « Etendu » ressemble à ça:

MMCEXView

Il peut être lié à plusieurs choses mais généralement il parvient suite à un crash d’IE (récupération d’un mauvais correctif, mauvais upgrade d’IE …) mais aussi parce que certaines bibliothèque de liens dynamiques (DLL) soient endommagées.

La problème a été résolu en ré enregistrant certaines DLL, voir procédure ci-après :

Pour Windows XP /Windows Server 2003 (quelque soit le Service Pack)

Lancez l’invite de commande (cmd.exe) et saisissez les commandes suivantes (l’une après l’autre):

 regsvr32 jscript.dll 

 regsvr32.exe  mmcndmgr.dll

 regsvr32.exe vbscript.dll

Après l’exécution de chaque commande, un message s’affiche vous indiquant que la DDL spécifiée est bien enregistrée.

Par exemple, après l’exécution de la commande regsvr32 jscript.dll, le message suivant est affiché :

Jscript Reussi

Si toutefois le problème persiste, c’est que d’autres DDL à part jscript, mmcndmgr et vbscript soient endommagées, dans ce cas là, je vous invite à télécharger et appliquer le Fix suivant que (heureusement :D) MS nous propose encore :

http://www.microsoft.com/fr-FR/download/details.aspx?id=44664

Note : ce Fix est appliquable uniquement à Windows XP & Windows Server 2003. N’oubliez pas de le télécharger dans la langue de votre OS sinon l’installation échouera.

Pour Windows 7 /2008 ou 2008 R2

Lancez l’invite de commande (cmd.exe) en tant qu’Administrateur et saisissez les commande suivantes (l’une après l’autre)

 regsvr32 jscript.dll 

 regsvr32.exe  mmcndmgr.dll

 regsvr32.exe vbscript.dll

Après l’exécution de chaque commande, un message s’affiche vous indiquant que la DDL spécifiée est bien enregistrée.

Par exemple, après l’exécution de la commande regsvr32 jscript.dll, le message suivant est affiché :

Jscript Reussi_W7

Si toutefois le problème persiste, c’est que d’autres DDL à part jscript, mmcndmgr et vbscript soient endommagées, dans ce cas là, je vous invite à télécharger et appliquer le Fix suivant :

http://www.microsoft.com/fr-FR/download/details.aspx?id=44621

Note : ce Fix est appliquable uniquement à Windows 7 SP1 & Windows Server 2008 R2. N’oubliez pas de le télécharger dans la langue de votre OS sinon l’installation échouera.

Enfin, notez que cette procédure (réenregistrement de DDL) a fonctionné dans 95% des cas, le problème a été résolu sur « uniquement » un des postes de travail posant problème (sous Windows 7 Pro) en désinstallant et réinstallant IE 9.

Publicités

 

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 :

IMG28

IMG29

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

IMG30

IMG31

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

IMG33

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

IMG32

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

IMG34

  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

IMG35

-> 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.

IMG36

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

IMG37

 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 »

IMG38

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 :

IMG39

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

IMG40

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

IMG41

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

IMG42

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

IMG43

  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

IMG34

-> 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

IMG44

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

IMG45

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

IMG46

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 :

IMG47

 

IMG49

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

IMG50

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é

IMG48

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

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

Aujourd’hui, les entreprises et organisations nécessitant un niveau de sécurité élevé, exigent une infrastructure à clés publiques (Infrastructure PKI « Public Key Infrastructure ») au sein de leur S.I.

La carte à puce fait parti des composants physiques d’une infrastructure PKI et permet d’augmenter le niveau de sécurité en matière d’authentification des utilisateurs sur un réseau d’entreprise.

Ce matin, le client chez lequel je suis en mission me demande si nous pourrions configurer une action lorsqu’un utilisateur retire sa carte à puce du lecteur, par exemple : verrouiller sa session Windows automatiquement après le retrait de sa carte à puce.

Eh bien, c’ela est possible, et ce, a l’aide d’un paramètre de stratégie de groupe.

Comment ça marche ?

La configuration se fait en deux étapes :

1. Depuis la console de gestion des stratégies de groupe (GPMC.MSC), créez une GPO au niveau de l’OU contenant les ordinateurs du domaine sur lesquels vous voulez appliquer ce paramètre, faites ensuite un clic droit dessus et sélectionnez Editer.

=> Naviguez jusqu’au Configuration ordinateur Paramètre Windows \ Paramètres de sécurité \ Stratégies locales \ Options de sécurité.

=> Localisez le paramètre de stratégie de groupe Ouverture de session interactive : comportement lorsque la carte à puce est retirée, comme montré ci-après :

 

Image

 

=> Double-cliquez dessus et choisissez Verrouiller la station de travail comme action, voir image ci-après:

Image

 

2. Deuxième étape consiste tout simplement à configurer le type de démarrage du service Stratégie de retrait de la carte à puce en Automatique ou Automatique (début différé) sur les postes de travail. Je vous recommande le type Automatique (début différé) pour éviter tout verrouillage automatique de l’ordinateur avant même le chargement complet du programme /driver de la carte à puce et donc avant même le retrait de la carte à puce par l’utilisateur.

Note : vous pouvez utiliser la commande suivante pour configurer le service Stratégie de retrait de la carte à puce en Automatique (début différé) au lieu de passer par la console « Services »

! : la commande est à lancer depuis une Invite de commande en Mode Administrateur

sc config « SCPolicySvc » start= delayed-auto

Enfin, redémarrez vos postes de travail pour que les modifications soient prises en compte (application GPO & Configuration du service).

J’espère que cette article pourra vous être utilise.

Cette procédure s’applique à : Windows Server Core 2008, 2008 R2, 2012 et 2012 R2

Après le déploiement d’une installation minimale de Windows Server Core 2008, 2008 R2, 2012 ou 2012 Server, vous vous retrouvez qu’avec une simple invite de commande, il s’agit de la seule et unique Interface Utilisateur « UI – User Interface » depuis laquelle vous devez configurer et gérer votre Server Core.

Par défaut, vous êtes positionné dans le répertoire C:\Users\VotreProfilUtilisateur si votre serveur fait parti d’un groupe de travail (exemple : C:\Users\Hicham) ou C:\Users\VotreProfilUtilisateur.Domaine si votre serveur fait parti d’un domaine Active Directory (exemple C:\Users\Hicham.masociete.local), voir image ci-après :

1

Généralement, vous pouvez être amenés à exécuter des scripts, des outils en lignes de commande ou des programmes qui sont souvent stockés dans %windir%\System32, %ProgramFiles% ou tout simplement dans un dossier spécifique sur une de vos partitions /disques et vous préférez arriver directement dessus au lieu d’arriver sur C:\Users\VotreProfilUtilisateur.

Vous pouvez changer le répertoire par défaut de l’invite de commande soit :

=> Au niveau l’Utilisateur

=> Au niveau de l’Ordinateur

1. Changer le répertoire par défaut au niveau l’Utilisateur La procédure suivante vous permettra de changer le répertoire par défaut uniquement pour l’utilisateur avec lequel vous effectuez cette procédure:

* Depuis l’invite de commande, saisissez REGEDIT 

* L’éditeur de Registre s’ouvre, naviguez jusqu’au :

2

* Faites un clic droit sur « Command Processor », sélectionnez « Nouveau » et ensuite « Valeur de chaîne » (voir image ci-après)

3

* Saisissez Autorun comme nom de la valeur, validez en cliquant sur OK, ensuite double-cliquez la valeur Autorun

* Supposant, vous voulez arriver directement sur le répertoire « MesOutilsAdmin » placé dans la partition D:, parce que ce dernier est par exemple votre boite à outils qui contient l’ensemble des programmes & outils en ligne d’administration. eh bien, il suffit de saisir la commande CD /D D:\MesOutilsAdmin dans le champs « Donnée de la valeur » et validez en cliquant sur le bouton OK.

4

* Fermez l’éditeur de Registre.

* Depuis l’invite de commande, saisissez Logoff pour déconnecter votre session Windows.

* Reconnectez-vous en utilisant votre login et mot de passe Windows, l’Invite de commande vous affiche désormais par défaut  le chemin : D:\MesOutilsAdmin

11

 

2. Changer le répertoire par défaut au niveau de l’Ordinateur

* Depuis l’invite de commande, saisissez REGEDIT

* L’éditeur de Registre s’ouvre, naviguez jusqu’au : HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

10

* Localisez la valeur « Shell » et double cliquez dessus

* Renseigner la commande suivante comme valeur de la clé Shell :

cmd.exe /c « cd /d « CHEMIN_SOUHAITE » & start cmd.exe /k runonce.exe /
AlternateShellStartup »

 

Ou « CHEMIN_SOUHAITE » est le répertoire /chemin vers lequel vous voulez arrivez directement.

Exemple :

cmd.exe /c « cd /d « %USERPROFILE% » & start cmd.exe /k runonce.exe /
AlternateShellStartup »

Ou pour reprendre l’exemple précédent :

cmd.exe /c « cd /d « D:\MesOutilsAdmin » & start cmd.exe /k runonce.exe /
AlternateShellStartup »

11

 

 

Cette procédure s’applique aussi à Windows Server Core 2008, 2008 R2 et 2012.

Invite de commande_SC2012

Ça peut vous arriver de fermer l’invite de commande (Interface utilisateur) sous Windows Server Core 2012 ou 2012 R2 et malheureusement l’environnement épuré ne vous permet plus de l’ouvrir une nouvelle fois à moins que vous vous déconnectez  ou redémarrez complètement le serveur, ce qui n’est pas vraiment une solution surtout s’il s’agit d’un environnement de production.

Je vous propose l’astuce suivante qui vous permet de reouvrir l’invite de commande sous Server Core 2012 /2012 R2.

Notez que cette procédure est valable aussi sous Windows Server Core 2008 /2008 R2:

1. Appuyer sur les touches Ctrl+Shift+Echap simultanément, le « Gestionnaire des tâches«  s’ouvre

2. Cliquez sur « Plus de détails »

Image

3. Cliquez sur le menu « Fichier » et sélectionnez « Exécuter une nouvelle tâche »

Image

4. Saisissez « Cmd » ou Cmd.exe (exécutable correspondant à l’Invite de commande).

Image

Enfin, l’Invite de commande réapparaît :). Notez que vous êtes positionné dans %windir%\System32 et non pas dans le répertoire /chemin ou vous étiez avant la fermeture de l’invite de commande.

Le mode « Server Core” est une version allégée de Windows Server 2008 / 2008 R2 pourvu d’options d’installations et de configurations minimales.

Depuis la version 2008 de Windows Server, Microsoft a introduit l’option « Installation minimale => Server Core Installation » de ce produit.

Les installations Server Core offrent un environnement d’exécution UNIQUEMENT des rôles serveur suivants :

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

et UNIQUEMENT les fonctionnalités suivantes :

  • 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)

En optant pour une installation Server Core pour un serveur, vous pouvez réduire votre charge de travail administrative et davantage limiter les risques de sécurité. Une installation Server Core offre les avantages suivants :

  • Réduction de la maintenance. Du fait que l’option d’installation Server Core installe uniquement les éléments nécessaires pour les rôles serveur définis, une maintenance moins importante est requise que pour une installation complète de Windows Server 2008.
  • Réduction de l’exposition aux attaques. Du fait que les installations Server Core sont minimales, le nombre d’applications exécutées sur le serveur est moins important, ce qui diminue la surface d’exposition aux attaques.
  • Réduction de la gestion. Avec un nombre plus réduit d’applications et de services installés sur un serveur exécutant l’installation Server Core, les besoins en gestion sont réduits.
  • Diminution de l’espace disque requis. Une installation Server Core exige uniquement environ 1 gigaoctet (Go) d’espace disque pour l’installation et environ 2 Go pour les opérations postérieures à l’installation.

Pré-requis matériels

  • CPU : 1GHz (x86) OU 1.4GHz (x64)
  • RAM : 512MB
  • Espace Disque: 10 GB

Article bientôt disponible …

A très bientôt les amis :).