Archive

Posts Tagged ‘PXE’

Comment activer le PXE à travers Hyper-V lorsque l’on fait un environnement de test de type PoC pour SCCM 2012 R2 ?

Bonjour à toutes et à tous,

Après un long moment d’absence, je poste ce rapide message de type “pense-bête” afin d’expliquer simplement comment déployer, en mode PXE une machine physique lorsque l’on utilise la fonction OSD de SCCM 2012 R2 virtualisé dans un environnement Hyper-V en mode PoC.

En effet, dans un environnement de type PoC, nous avons tendance à ne déployer que des machines virtuelles. Mais il arrive parfois qu’on soit obligé d’aller plus loin dans les tests et vouloir prouver qu’on peut déployer une machine bien réelle.

Les raisons peuvent être multiples : Soit pour tester Bitlocker lors de la descente de Windows, soit pour tester et valider l’intégration de nouveaux pilotes (drivers) pour un nouveau modèle, ou encore prouver l’intégration des modèles de PC en vigueur dans une solution nouvelle que peut représenter SCCM 2012, coupler avec MDT ou non.

Bref, tester ou démontrer la solution l’OSD de SCCM 2012 ayant pour cible aussi bien des machines virtuelles que physique.

De plus, pour une démo cliente, l’environnement de type PoC peut être mobile si vous installez celui-ci sur un portable plus (+) “technique” que bureautique. Dans mon cas, mon environnement est un RoG (Republic of Gamer) sous Windows 2012 R2, de type Core i7 possédant 32 Go RAM, 1 Téra SSD dédié l’environnement et 128 Go SSD pour l’OS du host (l’OS du portable).

Les pré-requis de l’environnement et de SCCM 2012 R2 étant assez gourmands, je vous conseille au minimum, 16 go Ram, Core i5, un disque dur 500 Go en 7200 tours dédié l’environnement et 1 disque dédié à l’OS de votre host.

Côté services sur le host (votre machine), installez dans cette ordre les services suivants :

Service DNS : Celui-ci permet de mettre en cache les requêtes de résolution de l’ensemble de l’environnement virtualisé (SUP de SCCM (synchronisation Software Updates Point), accès au web pour toutes les machines virtuelles ou physiques), Délégation de la zone DNS pour Active directory hébergé sur votre DC virtuelle, etc.

image

Service DHCP : Votre machine host (votre portable) ne fera pas parti du domaine Active directory virtualisé. Cependant, le service DHCP permettra de distribuer une adresse IP à toutes vos clients OSD (physiques ou virtuels). Il vous faudra dans ce cas, mettre en premier l’adresse IP de votre DC (qui sera aussi serveur DNS) dans vos scopes DHCP et par la suite mettre en 2ème position l’adresse IP de serveur host (votre portable) DNS également.

image

Service Hyper-V : Bien sûr, mettre en place Hyper-V afin de construire tout votre environnement de type PoC. Une fois les redémarrages d’installation effectués et Hyper-V installé, je vous conseille, tout de suite, de mettre en place vos VLAN Virtual Switch depuis la console. D’attribuer une adresse IP statique tout de suite pour chacun d’eux depuis les propriétés des cartes réseaux de votre Host (ATTENTION NE PAS SPECIFIER DE PASSERELLE).

image

Note : Si vous ne créez pas vos Virtual Switchs, vous risquez de ne pas les voir apparaitre dans la console Routage Accès Distant. Même si vous redémarrer le service Routage Accès Distant, l’énumération des cartes réseau de votre Host ne fonctionnera pas (ou pas toujours).

Autre point, afin de pouvoir faire du PXE vers des machines bien réelles, l’un des “Virtual Switchs” sera couplé à ma carte Ethernet.

image

Routage Accès Distant : Pourquoi mettre en place sur votre host ce service ?? Tout simplement parce que celui-ci servira de “Centre” d’aiguillage réseau entre votre environnement PoC et Internet (Ou tout ce qui peut être considéré comme externe à votre environnement virtuel).

Dans mon cas, mais aussi dans le votre, j’activerai la fonction NAT (Network Access Translation) afin permettre à mes machines clientes de sortir vers l’extérieure et sur le Net grâce au WIFI. Raison pour laquelle j’utilise aussi un portable, le WIFI étant présent de base…

image

image 

image  image

Une fois votre environnement virtualisé, Microsoft System Center 2012 R2 Configuration Manager, installé et configuré et les rôles OSD activés, en attribuant le Virtual Switch à vos machines virtuelles, Virtual Switch lui-même lié à votre Carte Ethernet de votre host Hyper-V (de votre portable), couplé aux options DHCP (066 et 067) pour l’OSD, il vous est désormais possible de cibler par PXE, à la fois vos machines virtuelles et vos machines physiques connectées directement en Ethernet sur votre portable, hébergeant l’ensemble des services.

image

Note : Les options DHCP, 066 et 067 sont obligatoires, car dans cet environnement, la notion ou fonction d’IPHelper n’existe pas et n’est pas possible.

Enjoy !

avatar_thumb2 Michel PICOLLET
Solution Architect Microsoft [System Center]
mpicollet@event-horizon.fr

Catégories :Hyper-V, SCCM, Windows Étiquettes : , , , , , , , , , , , ,

SCCM – Impossibilité de publier les images de boot sur un serveur, point de distribution, si celles-ci sont déjà présentes dans le PXE Et le répertoire SMSBoot\[x] reste vide)

septembre 30, 2012 1 commentaire

Bonjour à tous,sccm20124

Venant d’être confronté au problème, voici un post regroupant un ensemble d’actions qui m’ont permis de m’en sortir. A tester bien sûr !

Description du problème

1. Une fois les images boot marquées comme devant être utilisées et publiées sur le rôle PXE, il est impossible de les publier sur un serveur ayant le rôle de point de distribution.

clip_image002

2. Les répertoires x86 et x64 se trouvant dans le répertoire \RemoteInstall\ SMSBoot\ sont vides et ne possèdent pas les fichiers de démarrage, nécessaires au PXE.

Ce problème engendre un service PXE inopérant sur les postes de travail, rendant inopérant l’ensemble des déploiements de systèmes d’exploitation !

Actions de résolution

1. Supprimer vos images de boot du PXE
2. Supprimer vos images de boot de votre point de distribution (Même si la copie n’a pas fonctionné)
3. Décocher l’activation du « rôle » PXE sur votre point de distribution
4. Supprimer le rôle de point de distribution sur votre serveur
5. Désinstaller le rôle serveur WDS (Windows Deployment Service)
6. Redémarrer votre serveur (Anciennement DP\PXE)
7. Sauvegarder les répertoires suivants dans un endroit sûr sur votre serveur :

– SCCMContentLib
– SMSPKG*
– SMSSIG

    8. Une fois sauvegardés, supprimer les répertoires suivants de tous vos lecteurs :

– SMSPKG$
– SMSPKGx$
– S
MSPKGSIG
– SMSSIG$
– SCCMContentLib
– RemoteInstall

Vider le répertoire C:\Windows\Temp

    9. Bien vérifier bien que le fichier Tag : No_SMS_On_Drive.SMS est bien présent sur les lecteurs appropriés

Lire la suite…

Catégories :SCCM Étiquettes : , , , , , , , ,

SCCM – Troubleshooting avancé et la boule de Cristal

sccm2012Bonjour à tous,

Je fais ce post, vite fait pour vous relater un problème que j’ai rencontré avec ConfigMgr 2007 (SCCM). Et notamment, avec le rôle Management Point versus PXE. Nous avons un serveur Central SCCM (hébergeant aussi la base SQL) et un serveur dédié pour les rôles de PXE, Distribution Point et State Migration Point.

Quant au Central, celui-ci possède les rôles habituels, et notamment le rôle de Management Point.

CONTEXTE/ISSUE
Nous avions déplacé temporairement, le rôle Management Point sur le serveur dédié (PXE, etc.), dans le but de corriger un problème IIS sur le serveur d’origine (Central). Et notamment, concernant la configuration de BITS sur le répertoire CCM_Incoming (Error 500 httpSendRequest)…

Au passage, je vous donne la procédure pour réinstaller Microsoft IIS sur SCCM :

http://blogs.technet.com/b/configurationmgr/archive/2009/08/12/configmgr-2007-how-to-properly-reinstall-iis-in-windows-server-2008-on-an-sccm-2007-site-system.aspx

Là, aucun problème, tous les services SCCM raccrochent les informations, et considèrent correctement le nouveau serveur Management Point comme acquis et fonctionnel sur le serveur dédié (PXE, etc.)

Une fois le problème IIS corrigé sur le serveur, nous avons, bien sûr voulu rebasculer le rôle MP sur son serveur d’origine. Et là problème ! Ce qui s’était bien passé la 1ère fois sur le serveur temporaire, s’est mal passé la deuxième fois (Apparemment), lorsque nous avons remis le rôle à sa place. nous nous sommes pas aperçu tout de suite :

La particularité de ce problème, c’est qu’une fois le rôle MP réinstallé sur le serveur d’origine (Central), le fichier de LOG : MPControl.log fait un Code Retour 200 OK dans son autocheck httpSendRequest !! Si on consulte les fichiers de LOG IIS, même chose ! Code Retour 200 !

Malgré tout impossible de déployer une Task Sequence de déploiement de Windows Seven !!

ANALYSES
Après avoir consulté le fichier Log : MPSetup.log, je ne vois aucune erreur, hormis l’installation du fichier MSI. Erreur que j’avais résolu par une réinstallation du rôle MP, pour corrigé le problème. Ceci avait d’ailleurs fonctionné, raison d’ailleurs pour laquelle je n’avais aucune erreur dans le fichier de Log : MPSetupl.log qui se terminait bien par : Installation Successfully.

Mais malgré tout, le rôle Management Point ne fonctionnait plus, et ceci malgré ce que pouvaient dire les fichiers de Logs d’IIS de SCCM (MPControl.log), etc. Je ne parle pas de la console qui reste muette sur le sujet … “Tout est vert, il fait beau, 25 degrés à l’ombre, bref ! Rien à signaler !

Donc je décide d’investiguer côté poste de travail : Le symptôme sur les postes de travail était le suivant : Les postes démarrent bien en mode PXE, chargent bien l’image de démarrage WINPE, mais redémarrent brusquement au bout de 60 secondes, voir moins (Et ceci malgré une console DOS (F8) ouverte). Malgré tout, nous arrivons a récupérer le fichier Log : SMSTS.Log et là l’erreur fait son apparition : No MP Certificates

Une rapide analyse m’envoie vers le fichier de Log : SMSPXE.log. Dans celui-ci, je vois que le serveur Management Point, ainsi que la clé de sécurité (le fameux Certificat) ne sont plus renseignés :

Loaded PXE settings from DB: Default MP: <empty>, Public Certificates: <empty>

ACTIONS DE CORRECTIONS
1 – Je décide donc, de redémarrer le service PXE Service Point (WDS) sur le serveur, afin de forcer le rôle PXE à lire dans la base, les informations concernant le Management Point, afin qu’il met à jour la nouvelle condition du dit rôle ! Rien à faire. Les données ne sont toujours pas renseignées !

2 – Je décide donc d’installer le Rôle PXE (Moins impactant que le rôle MP, sachant qu’on est en production). Même chose ! Aucun effet ! Les données restent vides ! Les services sont inopérants !

Donc par déduction, le problème, vient à coup sûr du Management Point ! De plus, entre-temps, on m’annonce que toutes les télédistributions d’applications sont arrêtées. Les clients n’ont plus accès aux publications !! Bonjour la pression ! Bref ! Quoi qu’il en soit, cela me conforte dans l’idée que le problème vient bien du Management Point sur le Central. Je décide donc de désinstaller celui-ci du serveur Central.

Mais avant… Une rapide recherche chez Microsoft, pour savoir si le problème est référencé ! Et je retrouve la KB et la procédure que j’avais faite pour corriger le problème d’installation du MSI : http://support.microsoft.com/kb/2419559/fr-fr

[… As of right now, the easiest way to resolve this issue is to remove and reinstall the BITS component. If the ConfigMgr 2007 Management Point role was already installed then it will also be necessary to remove and reinstall that role once you’ve done the same with BITS…]

3 – Je ré-applique donc la procédure, malgré que mon installation MP.MSI se soit bien passée la 1ère fois et que du point de vue de SCCM, le rôle Management actuel, fonctionne !

Sans surprise, la procédure se passe correctement, le Management Point revient en [Status 200 OK] dans MPControl.log, idem dans les fichiers de Logs de Microsoft IIS du Central… Le tout est de savoir ce que fait le PXE derrière ! Bah il fonctionne !!! Les champs sont renseignés. Je retrouve le nom FQDN de mon Management Point, ainsi que sa clé de Sécurité (Certificat).

Loaded PXE settings from DB: Default MP: SERVER.EVENT-HORIZON.FR, Public Certificates: 308201E63082014FA00302010202109326C3F7A4B9D2934497E…

Je repousse les boot images sur le serveur PXE (En conséquence de mes premières actions concernant PXE). Tout redevient comme avant ! Le déploiement OSD fonctionne à nouveau, ainsi que les publications d’applications !

Je voulais partager cette expérience avec vous, car cela vous donne un exemple de troubleshooting dans SCCM, dans lequel il n’est pas toujours évident de diagnostiquer un problème quand les logs ne reflètent par l’état réel des services SCCM, Et c’est encore moins facile quand la console SCCM reste muette comme un carpe !

Pour finir, dans l’histoire, je ne suis pas sûr que le réel problème vienne de Microsoft IIS. Je pense à quelque chose de plus profond, lié au socle et à un manque de stabilité du serveur. Je pense que le problème de Microsoft IIS n’est qu’un symptôme. Problème qui nous a d’ailleurs obligé à réinstaller IIS dès le début de l’incident ; Que part effet domino, le reste à suivi, provoquant le bug… Bienvenu dans le monde SCCM ! 🙂

Enjoy !

Michel PICOLLET | EXAKIS Paris
Solution Architect Microsoft [System Center]
mpicollet@event-horizon.fr

%d blogueurs aiment cette page :