[SCCM 2007] Task Sequence fails because boot image is inaccessible on SMSPXEIMAGES$

Take a really common OSD Task sequence (for example the default Deployment task sequence) where you need to restart on WinPE.

You deploy normally boot image on PXE point (shares like \\MyServer\SMSPXEIMAGES$) and everything works fine : You press F12, the computer starts with PXE, loads the boot image...
and you get the following error message !?! :

 

Obviously, someone will tell me that a SMSPXEIMAGES$ share is not a "real" Distribution Point. It's only made to boot on PXE.
To avoid that problem, people deploy images everywhere : on PXE shares (SMSPXEIMAGES$ share) and "Real" Distribution Points.



Wrong and Really Wrong ! And I'll prove i:

Let's look at the smsts.log file when the client tries to check if all packages used in the Task Sequence are available. We can perfectly note that the client tries to access the boot image on the SMSPXEIMAGES$ share but something seems wrong because it tries to do that several times.

If we check access rights, we can notice that the default access rights set on the SMSPXEIMAGES$ share are too restrictive. Indeed, only the local administrators group and the system account can access it.


























In order to solve that problem, I recommend to add at least the read access right to the Network Access Account on the SMSPXEIMAGES$ share.
The default NTFS rights are OK.


 
























For more :
You are probably not totally satisfied of my explanation. Indeed, how a client can start on a boot image and can't access the same image few seconds later ?!

When a client boots with PXE, the boot image is not downloaded from the SMSPXEIMAGES$ share but through the WDS service and the TFTP protocol. WDS service runs with the system account and doesn't have any problem to access the boot images.
On the contrary, latter, when SCCM client tries to access the boot image, it used the SMSPXEIMAGES$ windows share.


Moreover :
In certain circumstances, you can get that error randomly with a Task sequence !
Imagine a task sequence where no step consists on restarting on WinPE excepted for the initial boot with PXE (for example, the defaut "Build and Capture" task sequence).


If several task sequences (with several boot images) are advertised on a client, do you know what boot image will be distributed by PXE ?
The client will load the boot image of the latest task sequence advertised on the computer account !
I let you imagine scenarios where depending on the assignments of the collections and the advertisements, 2 computers can have exactly the same task sequence but start on different boot image.

If the boot image loaded on the client corresponds to the task sequence that you select, the task sequence simply starts.

But what happens if you choose a task sequence that requires another boot image than the one loaded ?
The client downloads the right boot image, configures the hard disk boot parameters to start on that boot image, requests the user to eject the CD and restarts the computer. Task sequence starts as soon as the boot image is loaded on the computer.


If the client can't download the boot image, task sequence fails !
That will happen if the boot image is deployed only on the SMSPXEIMAGES$ shares and if you don't modify right access as recommended.

If you provide the read access right to the network access account on the SMSPXEIMAGES$, everything will work fine.

Tricky to understand ? Let's take an example :
On one hand, an OSD Task sequence called "TS1" that use the boot image "Boot1". That task sequence is advertised (not mandatory) on the collection "Coll1".
On the other hand, another OSD Task sequence called "TS2", that use the boot image "Boot2" and that is advertised (not mandatory) on the collection "Coll 2".

You have 2 computers called CompA and CompB.
You add CompA in Coll1 and Comp B in Coll2. You wait few minutes and you add CompA in Coll2 and Comp B in Coll1.
The task sequences TS1 and TS2 are advertised on both computer. However, with PXE, CompA will boot the "Boot2" image and CompB will boot the "Boot1" image. Ok ? fun :o)

Both computers are started and on the SCCM OSD client wizard, you select the task sequence TS1.
No problem for CompB because "Boot1" is already loaded. Task sequence TS1 starts.
For CompA, client must download "Boot1". However that operation will not be made through PXE service but through the windows shares. If client can't download boot image, task sequence fails.


See you soon !
Julien

Récupérer les bon Logs dans SCCM

Tout Troubleshoot commence par chasser les bons logs. Le terme n'est pas trop fort parce que, soyons honnêtes, SCCM en génère beaucoup qu'il dispose un peu partout, autant sur les serveurs que sur les postes de travail. D'ailleurs Microsoft a jeté l'éponge et ceux qui ont lu la page Technical Reference for Log Files in Configuration Manager ont certainement été surpris en lisant :

Locating Configuration Manager Logs
By default, Configuration Manager log files are stored in a variety of locations that depend on the process that creates the log file, and on the configuration of your site systems. Because the location of the log on a given computer can vary, use search to locate the relevant log files on your Configuration Manager computers to help you troubleshoot a specific scenario.

Il y a donc les consultants qui cherchent désespérément les logs PXE au milieu les autres logs SCCM, les techniciens qui ne remontent pas les bon smsts.log, etc...

Pour vous faciliter la vie (et/ou les aller-retours inutiles), je vous propose plusieurs idées :

• Dans le cadre d'un déploiement d'OSD, je vous recommande l'excellent guide de Nicolas Niehaus qui récapitule l'emplacement des différents fichiers de logs : http://blogs.technet.com/b/mniehaus/archive/2012/09/11/troubleshooting-windows-deployments-take-2.aspx

• Pour capturer rapidement et sans faute des logs, j'ai aussi mis au point un script qui peut capturer sur un poste local ou distant (pour peu que votre compte puisse y accéder par les partages administratifs) tout un ensemble de logs. Bien entendu, ce script peut aisément être adapté à n'importe quel produit (ou même copier autre chose que des logs), mais j'ai déjà défini les principaux logs pour les serveurs et les clients SCCM.

Vous pouvez télécharger LogHunter.vbs.

En ligne de commande, la syntaxe est toute bête :
cscript.exe logHunter.vbs [IP / Nom Distant]

Si aucun argument n'est fourni, le script cherche les fichiers sur le poste local.

Si vous fournissez un nom de poste distant par argument, le script transforme tout seul le chemin local en un chemin UNC (donc C:\logs est transformé en \\OrdiDistant\C$\Logs)

Les répertoires à récupérer sont stockés dans un répertoire généré au même emplacement que le script (donc nickel avec une clé USB par exemple pour troubleshooter un déploiement qui se passe mal). Le nom du répertoire est de la forme YYYYMMDD.HHMM-NomOrdinateur

La personnalisation les répertoires à récupérer se fait tout simplement en éditant les premières lignes du script : Il s'agit d'un tableau, où chaque élément est de la forme
"Répertoire local à récupérer | Nom du répertoire de copie".


Ainsi, si je lance le script sur l'ordinateur TOTO avec comme instruction "C:\logs|Logs_sur_C", j'aurai à coté de mon script le répertoire 20120918.214-TOTO avec à l'intérieur le répertoire "Logs_sur_C" qui contient une copie des fichiers contenu dans C:\logs
Je vous laisse étudier les autres exemple fournis avec le script.

Un script à garder pas trop loin et à mettre entre toutes les mains si vous souhaitez qu'on vous rapporte des logs exploitables :o)


N'hésitez pas à me faire des retours

Bon Troubleshoot
Julien