Au menu des nouveautés :

• Support de Windows 8 (Client+Server) Consumer Preview
• Déploiement sur VHD
• Application de GPO pendant le déploiement (support des templates de Security Compliance Manager)
• Support de Powershell V2 pour les tâches : la version 3 n’est pas supportée à l’heure actuelle.
• Support de Windows ADK : le successeur d’AIK pour Windows 8 et Windows 7 (supporté dans certains scénarios seulement)
• WinPE 4, WinRE (en natif !), DaRT (en natif aussi), USMT 5
• et encore d’autres nouveautés

Pour récupérer MDT 2012, ça se passe par ici.

Il me tarde de mettre à jour ma plateforme MDT 2010 pour jouer avec PowerShell notamment !!

Après la sortie du SP1 de Windows Server 2008 R2 et de Windows 7, des images ont été créées pour intégrer le SP1 et ainsi éviter son installation. Il ne manquait plus que la création d’image pour Hyper-V Server. Et c’est maintenant chose faite avec Hyper-V Server 2008 R2 SP1 ! Vous pourrez donc profiter de Dynamic Memory et RemoteFX dès l’installation du serveur

Pour ceux qui ne connaissent pas Hyper-V Server, il s’agit d’une édition particulière de Windows qui fonctionne en mode minimal (aussi connu sous le nom « Core ») qui embarque uniquement Hyper-V. Vous ne pourrez pas installer d’autres rôles sur cette édition. Alors pourquoi une édition particulière ? Elle est totalement gratuite, même pour un usage en production !

Vous allez me dire « ok mais c’est une version tronquée d’Hyper-V ?! ». Eh bien non ! Vous pouvez faire exactement les mêmes choses qu’avec Hyper-V sur Windows Server

Pour le téléchargement, ça se passe par ici : http://www.microsoft.com/downloads/en/details.aspx?FamilyID=92e2c4ba-6965-4f8e-abbe-cbb40556b680

Vous pouvez télécharger les outils d’administration à distance ici.

Aujourd’hui, c’est l’équipe Windows Server à Redmond qui fait cela. Ils ont identifié 5 axes principaux de développement et voudraient savoir si cela correspond vraiment aux attentes des entreprises. Ces 5 axes sont :

• Rendre les utilisateurs encore plus mobiles
• Travailler avec des contraintes de réduction de budgets IT
• Reprise après sinistre et planification de la sauvegarde des données
• Rendre encore plus sécurisé et hautement disponible les systèmes serveur
• Réduction des coûts matériels et fournir plus de services (qui soient facilement administrables)

Vous pouvez donc donner votre avis sur le futur de Windows Server sur le blog de l’équipe Windows Server (en anglais) !

Une fois que votre fichier est créé, il faut générer la clé privée et la requête de création de certificat. Cela se fait avec la commande certreq :
certreq -new server.inf server.req

Le fichier .req contient la requête qu’il faut soumettre à votre autorité de certification avec la commande ci-dessous. Si l’autorité accepte votre demande, elle vous retournera un fichier .crt
certreq -submit server.req server.crt

Il ne vous restera plus qu’à associer le certificat à la clé privée en faisant :
certreq -accept server.crt

Et voilà C’est vraiment rapide une fois que votre fichier inf est créé et ça permet aussi d’automatiser une étape de plus lors du déploiement de serveurs

Voici enfin arriver l’ajout/retrait de mémoire dynamique dans Hyper-V R2 ! On notera également l’arrivée de RemoteFX qui s’inscrit dans la virtualisation du poste de travail (VDI) : vous pourrez ainsi profiter de l’accélération matérielle de votre poste de travail local en utilisant un environnement virtualisé.

Pour plus d’informations et télécharger ce Service Pack 1 en beta, visitez la page dédiée chez Microsoft.

Lors de la tentative d’exportation, vous aurez ceci :

On pourra exporter le certificat sans problème… mais il sera incomplet puisqu’il manquera la clé privée. La migration sera donc un échec.

La clé privée est stockée sur l’ordinateur. On pourrait donc l’exporter si elle n’était pas marquée comme non exportable. Il n’est pas possible de désactiver cette protection dans Windows. Il faudra passer par un produit tiers nommé Jailbreak de iSEC Partners. Sous 32 bits, vous pourrez utiliser la mmc fournie. Sous 64 bits, seul jbstore.exe est fonctionnel. N’ayant que du 64 bits, je n’ai pu tester que jbstore. L’inconvénient majeur de jbstore est qu’il exporte tous les certificats et clés privées du magasin personnel sélectionné (qu’il soit utilisateur ou ordinateur). Il faudra donc faire le ménage une fois que vous aurez importé le fichier pfx mais c’est toujours mieux que de ne pas pouvoir migrer le certificat.

Pour exporter vos certificats et clés privées, il faudra exécuter :

jbstore /computer myserver.pfx M0tdePa$$e

• /computer : désigne le magasin personnel de l’ordinateur. Changez en /user pour utiliser le magasin personnel de l’utilisateur exécutant jbstore
• myserver.pfx : désigne le fichier dans lequel seront stockées les clés
• M0tdeP@$$se : mot de passe protégeant les clés. Il doit être très long (une phrase sans espaces) et complexe (caractères spéciaux, chiffres)

Pour exporter le magasin personnel de l’ordinateur, vous devrez être administrateur local de la machine.

Et voilà, il ne vous reste plus qu’à importer le fichier pfx sur votre machine cible

Ouvrez ensuite Finder puis allez dans Applications, Utilities, Directory Utility. Si le cadenas en bas à gauche n’est pas ouvert, cliquez dessus afin de vous authentifier en tant qu’admin local de votre Mac. Cliquez ensuite sur le + afin de configurer l’accès à Active Directory. Dans la liste Add a new directory of type, choisissez Active Directory.

Entrez le nom de votre domaine Active Directory dans Active Directory Domain puis le nom de votre Mac dans Active Directory dans Computer ID. Enfin entrez les identifiants (sous forme UPN) permettant la jonction à votre domaine Active Directory.

Patientez quelques instants et votre Mac sera joint à votre domaine Active Directory.

Vous pourrez ensuite vous connecter avec vos utilisateurs d’Active Directory. Déconnectez-vous de votre session courante et vous pourrez ensuite vous connecter avec un compte Active Directory en cliquant sur Other.

Entrez ensuite votre compte Active Directory en format UPN. Je vous conseille de changer le suffixe UPN pour que le login UPN soit identique à l’adresse email du compte. Sur la capture ci-dessous, je ne l’ai pas fait puisque ce n’est qu’un test rapide.

La connexion va prendre quelques instants la première fois puisqu’il faut créer votre répertoire personnel.
Une fois connecté, Finder s’ouvre automatiquement sur votre répertoire personnel nouvellement créé prouvant que la connexion à Active Directory est bien faite.

Voilà rapidement comment joindre Mac OS X à Active Directory. En complément, je vous conseille de lire les Best Practices: Integrating Mac OS X with Active Directory (documentation Apple).

Toute la suite se passera dans le répertoire %userprofile%\Documents\migrateCAkit. On commence ensuite la sauvegarde des différents éléments de l’autorité. Je suis sur une autorité d’entreprise donc il est possible de sauvegarder les modèles de certificats. Cela se fait avec la commande suivante :
certutil -catemplates > catemplates.txt

Il faudrait également sauvegarder le CSP (Cryptographic Service Provider) de votre autorité s’il n’est pas standard : je vous laisse consulter Technet pour cela.
Passons à la sauvegarde de l’autorité. Celle-ci se déroule en deux étapes : la sauvegarde de la base de données et de la clé privée de l’autorité. Je vais commencer par la sauvegarde de la clé avec
certutil -backupKey %userprofile%\Documents\migrateCAkit\backupCA

Cela aura pour effet de créer le répertoire backupCA pour ensuite demander un mot de passe pour crypter la clé privée.
!! ATTENTION !! Le mot de passe choisit doit être complexe : il va protéger votre clé privée d’autorité de certification pendant la migration. Il doit donc être choisi avec attention. Une fois que la clé aura été sauvegardée (le fichier sera nommé .p12), on va pouvoir passer à la sauvegarde de l’autorité. Cela se fait très simplement avec
certutil -backupDB %userprofile%\Documents\migrateCAkit\backupCA

Le temps de sauvegarde varie selon le nombre de clés stockées dans votre autorité. A partir de maintenant, il est souhaitable que personne ne génère de certificats : ces derniers seraient perdus. Si vous souhaitez une disponibilité de service et donc ne pas éteindre votre PKI, vous pourrez faire une sauvegarde incrémentielle et la restaurer sur l’autorité du serveur Core. Je me place dans le cas où la disponibilité de service n’est pas obligatoire donc je vais éteindre l’autorité avec
sc stop certsvc

Je pourrai ensuite sauvegarder les paramètres de mon ancienne autorité : ces paramètres sont stockés pour la majorité dans la base de registre. D’autres sont stockés dans l’annuaire de l’AD (CN=Public Key Services,CN=Services,CN=Configuration,DC=todorovic,DC=adds où DC=… désigne le nom de mon domaine AD) et donc accessibles depuis n’importe où (pas besoin de migrer). Pour sauvegarder les paramètres de la base de registre, il faut lancer
regedit /e CAsettings.reg HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Certsvc

Cela va exporter la branche Certsvc dans un fichier de registre. Ce fichier contiendra le nom de machine du premier serveur. Le nom du serveur Core sera probablement différent, il sera donc nécessaire de modifier la clé CAServerName du fichier de registre. Vous pouvez le faire manuellement avec notepad, voici un exemple automatisé en powershell
Get-Content CAsettings.reg | Foreach-Object { $_ -replace "oldserver","newserver"} | Set-Content CAsettingsCore.reg

Cet exemple peut paraître long mais l’auto-complétion de Powershell aide à aller vite Notez que je créé un nouveau fichier CAsettingsCore.reg : cela permet d’avoir le fichier original sous la main si besoin.

Maintenant, il est temps de copier le répertoire %userprofile%\Documents\migrateCAkit vers le serveur Core.

Ensuite il suffit de lancer dcpromo /unattend:%userprofile%\dcpromo.txt. Les outils Active Directory vont s’installer et la réplication de l’AD va s’effectuer. Un redémarrage sera nécessaire.

Il me reste à migrer les services de certificats et dhcp avant de finir la bascule de serveur. Le service DNS est automatiquement installé. Si toutes les zones sont intégrées à l’AD, la réplication est faite régulièrement entre les deux AD et il n’y a pas de besoins spécifiques de migration.

Migration ADDS+ADCS 2008R2 vers Server 2008R2 Core (partie 2)