Come risolvere l'errore OSD: script LTIBootstrap non trovato

Quando compare l’errore OSD: script LTIBootstrap non trovato

Questo errore, in pratica, dice una cosa molto precisa: il flusso di bootstrap si aspetta uno script chiamato LTIBootstrap ma non riesce a trovarlo nel punto previsto, oppure non riesce a eseguirlo. In ambiente Microsoft, il problema emerge spesso durante provisioning, avvio di un task sequence, preparazione di un’immagine o esecuzione di un pacchetto di automazione che fa affidamento su file locali o su un percorso di rete. La causa non è quasi mai “misteriosa”: di solito è una combinazione di path sbagliato, contenuto non distribuito correttamente, policy di esecuzione, o permessi insufficienti.

La cosa importante è non partire a tentativi. Prima si capisce dove il bootstrap fallisce: lato client, lato share, lato pacchetto, o lato orchestrazione. Se salti questo passaggio, rischi di spostare il problema senza risolverlo.

Che cosa sta fallendo davvero

In un bootstrap ben fatto, lo script iniziale non è il sistema finale ma solo il punto di ingresso. Serve a scaricare dipendenze, verificare prerequisiti, montare risorse e lanciare l’installazione o la configurazione successiva. Se il messaggio parla di LTIBootstrap non trovato, il primo sospetto deve essere il percorso che lo richiama: spesso il job o la task sequence punta a un file che non è più presente, oppure a una versione di cartella che è cambiata senza aggiornare il riferimento.

In altre parole: non stai ancora vedendo il fallimento dell’installazione, stai vedendo il fallimento dell’innesco. E questo è utile, perché restringe molto il campo.

Classificazione operativa

Categoria: troubleshooting / change controllato, con possibile impatto produzione se il bootstrap serve sistemi in rollout o reset di postazioni critiche.

Stato atteso: il job trova LTIBootstrap, lo esegue e prosegue con la sequenza prevista. Stato osservato: il job si ferma prima dell’installazione, con errore di file non trovato o path non risolvibile.

Ipotesi ordinate per probabilità

1. Path errato o file mancante. Il riferimento allo script è stato cambiato, rinominato o non pubblicato. Si falsifica in meno di 5 minuti verificando il path esatto e la presenza del file sul client o sulla share.
2. Permessi o accesso alla share insufficienti. Il file esiste ma l’account di esecuzione non può leggerlo. Si falsifica controllando ACL, accesso SMB e log di autenticazione.
3. Contenuto pacchetto incompleto o corrotto. Lo script era presente nel repository ma non è stato incluso nel pacchetto distribuito. Si falsifica confrontando l’hash o l’elenco dei file del pacchetto con la sorgente.

Verifiche immediate

Prima di toccare la configurazione, raccogli evidenza minima. Se non hai questi dati, stai lavorando alla cieca.

1. Controlla il messaggio completo dell’errore nel log dell’orchestratore o del client. Cerca il nome del file, il path e il codice di errore esatto.
2. Verifica se il file esiste davvero nel punto atteso. Esempio:

dir C:\path\to\LTIBootstrap* /s

Atteso: una o più occorrenze del file. KO: nessun risultato o file in una cartella diversa da quella referenziata dal job.

1. Se il bootstrap legge da share di rete, verifica accesso e raggiungibilità:

Test-Path \\server\share\LTIBootstrap.ps1
Get-SmbConnection

Atteso: True per Test-Path e connessione SMB attiva. KO: False, errore di autenticazione o share non raggiungibile.

1. Controlla i log del motore di esecuzione, se usi Task Sequence o provisioning. I percorsi cambiano a seconda del prodotto, ma i punti tipici sono i log del client, quelli del deployment agent e i log del sistema. Cerca righe con LTIBootstrap, not found, access denied, cannot execute.

Se il problema è in un ambiente Microsoft con strumenti di deployment, spesso i log utili sono quelli del client di gestione, del task sequence engine o dell’agente di provisioning. Il nome preciso varia, ma il concetto non cambia: devi trovare la riga che mostra il path risolto, non il solo messaggio finale di errore.

Soluzione consigliata passo-passo

1. Conferma il path reale. Prendi il riferimento usato dal job e confrontalo con il file effettivamente presente su disco o share. Se il nome è cambiato, allinea il riferimento. Se il file manca, ripubblica il contenuto corretto.
2. Ripristina il file mancante da una fonte nota. Usa il repository di build, il controllo versione o il pacchetto originale. Evita di creare uno script “simile” a mano: se il bootstrap è parte di una pipeline, un sostituto improvvisato rompe la tracciabilità.
3. Verifica i permessi minimi. L’account che esegue il bootstrap deve almeno leggere il file e, se serve, eseguire lo script. Per una share SMB, controlla sia i permessi di condivisione sia gli ACL NTFS.
4. Se l’esecuzione è bloccata da policy, correggi la causa e non aggirarla. Se il file è presente ma non parte, verifica se ci sono restrizioni di execution policy o controlli di sicurezza che impediscono l’esecuzione di script non firmati.
5. Ridistribuisci il pacchetto e valida su un solo host di test. Non fare subito rollout largo. Prima verifica che il bootstrap parta correttamente su una macchina campione.

Un controllo utile, se stai lavorando con script PowerShell, è verificare la firma o almeno l’origine del file. Non risolve l’errore in sé, ma evita di riaprire il problema tra qualche giorno perché il file è stato modificato da un operatore diverso.

Esempio di verifica rapida lato PowerShell:

Get-Item C:\path\to\LTIBootstrap.ps1 | Select-Object FullName, Length, LastWriteTime
Get-AuthenticodeSignature C:\path\to\LTIBootstrap.ps1

Atteso: file presente, dimensione coerente con la release e firma valida se la tua policy la richiede. KO: file assente, dimensione anomala, firma assente o non valida.

Se il bootstrap viene richiamato da un framework di deployment, controlla anche la definizione del passo che invoca lo script. Un errore frequente è il riferimento a una variabile d’ambiente non valorizzata o a un path relativo che funziona solo quando il contesto di esecuzione è quello giusto.

Snippet di configurazione da verificare, a livello concettuale:

CommandLine=powershell.exe -ExecutionPolicy Bypass -File .\LTIBootstrap.ps1

Se vedi path relativi, chiediti subito: da quale working directory parte il processo? Se non è stabile, rendi il path assoluto. È una modifica piccola, reversibile, e spesso risolve problemi inutili di contesto.

Cause tipiche in ambienti Microsoft

Nel mondo Microsoft, questo tipo di errore compare spesso in scenari abbastanza ripetitivi. Non sono casi teorici: sono i punti che, nella pratica, rompono il bootstrap.

• Il contenuto è stato spostato in una nuova directory ma il task sequence conserva il vecchio riferimento.
• La share è accessibile per alcuni utenti ma non per l’account macchina o per il service account usato dal deployment.
• Il file è presente nel repository ma non è stato aggiornato il pacchetto distribuito ai client.
• Un antivirus o una policy di hardening ha bloccato l’esecuzione o messo in quarantena lo script.
• La macchina sta eseguendo un’immagine vecchia e cerca una struttura di cartelle superata.

La differenza tra risolvere e inseguire il problema sta tutta nel verificare il riferimento esatto che il motore sta usando. Non basta sapere che “il file esiste”: devi sapere se esiste nel punto che il processo usa davvero.

Se l’errore dipende da una task sequence o da un job di provisioning

Qui la logica è semplice: il bootstrap è solo uno step della sequenza. Se lo step fallisce, devi vedere la variabile risolta, il path effettivo e l’utente o il contesto di esecuzione. Un errore classico è usare un path locale su una macchina che si aspetta invece un path UNC, oppure viceversa.

1. Apri la definizione della sequenza o del job e individua il passo che richiama LTIBootstrap.
2. Verifica se il comando usa variabili, path relativi o mapping di rete.
3. Confronta il contenuto pubblicato con quello del repository sorgente.
4. Riesegui il job su un solo endpoint di test dopo aver corretto il riferimento.

Se il job è gestito da una console, preferisci la verifica dal pannello prima di cambiare file a mano. Il vantaggio è banale ma decisivo: capisci subito se il problema è nella definizione del task o nel contenuto distribuito.

Quando conviene fermarsi e raccogliere più dati

Se non sai dove sia stato lanciato il bootstrap, non indovinare. Ti servono almeno tre elementi: il messaggio completo, il path invocato e il contesto di esecuzione. Senza questi dati, il rischio è fare cambiamenti sul repository sbagliato o sulla share sbagliata.

Se un errore di file non trovato compare solo su alcuni host, il problema non è quasi mai “il file” in sé: è la differenza tra contesto, permessi o distribuzione del contenuto.

Se ti manca uno di questi dati, chiudi il gap così: recupera il log esatto del client, annota il path completo e verifica la presenza dello script sul punto di esecuzione. Sono tre passaggi banali, ma sono quelli che evitano la correzione sbagliata.

Controlli finali e rollback

1. Rilancia il bootstrap su un solo host di test e verifica che lo script venga trovato ed eseguito senza errori.
2. Controlla il log successivo allo step incriminato e verifica che la sequenza prosegua oltre il punto di blocco.
3. Se hai modificato un path o un pacchetto, conserva la versione precedente e annota il cambio in modo da poter tornare indietro rapidamente.
4. Se la correzione ha coinvolto permessi o policy, reintroduci il vincolo solo dopo aver confermato che il bootstrap continua a funzionare nel nuovo assetto.

Rollback: ripristina il vecchio riferimento al file, il pacchetto precedente o la configurazione precedente della task sequence. Se hai cambiato ACL o share, riporta i permessi al valore iniziale esportando prima la configurazione o documentando il delta. Blast radius: limitato al job, alla share o al client che esegue il bootstrap, ma trattalo come impatto produzione se la sequenza serve sistemi in rollout o reinstallazione.

Assunzione: il problema nasce da un riferimento non allineato tra job, contenuto pubblicato e percorso reale; se i log mostrano un errore diverso, va rivalutata la catena di esecuzione dal primo step utile.