Come risolvere l'opzione Approva o Nega script disabilitata in SCCM

Quando in SCCM la voce Approva o Nega script risulta disabilitata, il problema di solito non è nello script in sé ma nel contesto operativo: oggetto selezionato, permessi della console, stato del contenuto o versione del client/server. In pratica stai vedendo un sintomo di autorizzazione o di workflow, non un guasto del motore di approvazione.

La prima cosa utile è distinguere dove compare la voce disabilitata: nella console su un singolo script, in una collection, nell’area Software Library, oppure nel portale aziendale/Endpoint Analytics. La diagnosi cambia parecchio. Se la voce è grigia solo per alcuni oggetti, il problema è quasi sempre nel tipo di oggetto o nel suo stato. Se è grigia ovunque, il sospetto si sposta su RBAC, ruoli mancanti o console non allineata alla site version.

Come funziona davvero l’approvazione script in SCCM

In Configuration Manager gli script non sono tutti uguali: quelli caricati nella libreria, quelli già approvati, quelli in attesa di revisione e quelli referenziati da una policy non si comportano allo stesso modo. La voce di approvazione diventa disponibile solo se:

• stai selezionando un oggetto script nel nodo corretto della console;
• il tuo ruolo RBAC include l’azione di approvazione;
• lo script è in stato Pending approval o comunque gestibile;
• la console è allineata con il sito e non sta usando una cache o una versione vecchia.

La conseguenza pratica è semplice: se il tasto è disabilitato, non partire dalla “correzione” dello script. Prima verifica se la console ti sta mostrando un oggetto che non può essere approvato da quel profilo o in quello stato.

Cause più frequenti, in ordine di probabilità

In ambienti reali le cause ricorrenti sono queste:

1. RBAC insufficiente: il ruolo non ha il diritto di approvare script o non vede il contesto corretto.
2. Oggetto non eleggibile: lo script è già approvato, è stato ritirato, oppure non è nello stato atteso.
3. Console o site non coerenti: versione diversa, cache, permessi corrotti localmente, oppure replica incompleta tra site server e provider.

Ci sono altri casi meno comuni, ma spesso vengono confusi con il problema principale: problemi di replica del provider SMS, oggetti danneggiati nel WMI locale della console, oppure un update del Configuration Manager Console che ha lasciato un client GUI in stato incoerente.

Verifiche rapide lato console e permessi

La verifica più veloce è capire se il problema segue l’utente o l’oggetto. Accedi con un account amministrativo diverso, idealmente con un ruolo più ampio, e prova la stessa azione sulla stessa console. Se il comando si abilita, hai già isolato il problema su RBAC o scope.

Controlla anche il percorso del nodo. In genere l’approvazione degli script passa da Software Library e non da un contesto laterale o da una vista filtrata. Se stai lavorando su una collezione o su un report, la voce può essere presente ma non pertinente all’oggetto selezionato.

Per un controllo operativo dei privilegi, sul site server puoi verificare il ruolo assegnato all’utente nella console e confrontarlo con i permessi effettivi nel database. In ambienti dove hai accesso al SQL backend, una query di ispezione sui ruoli e sugli scope aiuta a capire subito se l’account vede la feature ma non ha il diritto di eseguirla.

-- Esempio orientativo: verificare ruoli e scope dell'utente nel database SCCM
SELECT r.AdminID, r.LogonName, r.DisplayName, s.CategoryName
FROM RBAC_Admins r
LEFT JOIN RBAC_SecuredCategoryMembers scm ON scm.AdminID = r.AdminID
LEFT JOIN RBAC_SecuredCategories s ON s.CategoryID = scm.CategoryID
WHERE r.LogonName = 'DOMINIO\utente';

La query esatta può variare per versione e schema, quindi usala come traccia di verifica, non come copia-incolla cieco. Se non hai accesso al database, il controllo equivalente è nella console: Administration → Security → Administrative Users e verifica ruolo, scope e security role assegnati.

Verifiche sullo stato dello script

Se il permesso è corretto, passa allo stato dello script. La voce di approvazione si disabilita spesso quando lo script non è realmente in attesa di approvazione. Cerca campi come Approval state, Status, Approved by o Approval required nella scheda proprietà dell’oggetto.

Il controllo utile è questo: uno script “approvabile” deve essere in uno stato coerente con il workflow. Se è già approvato, il comando di approvazione non ha senso e la GUI lo mostra grigio. Se invece è in pending ma la voce resta disabilitata, allora il problema è a monte: permessi, scope o console.

Un altro dettaglio da non sottovalutare è la provenienza dello script. Se è stato importato o creato da un processo automatico, verifica che il contenuto sia stato salvato correttamente e che non manchi il metadato necessario per l’approvazione. In alcuni ambienti il problema compare dopo migrazioni o restore incompleti, quando l’oggetto esiste ma la sua relazione con i metadati di approvazione non è stata ricostruita bene.

Controllo della console: versione, cache e integrità locale

La console SCCM può mostrare comportamenti anomali quando è fuori allineamento rispetto al site server. Se il sito è stato aggiornato e il client console no, alcune azioni diventano indisponibili o vengono interpretate male. Questo succede più spesso di quanto si ammetta, soprattutto dopo maintenance window o update cumulativi.

Prima di toccare il sito, fai una verifica locale: chiudi la console, riaprila con privilegi elevati e controlla il file di log della console. I riferimenti utili sono in genere sotto il profilo utente, nella cartella dei log della console Configuration Manager. Il nome e il percorso possono cambiare in base alla versione, ma il principio resta: cerca errori di accesso, mismatch di versione o problemi di caricamento dei provider.

# Esempio di controllo rapido dei processi e della versione console lato client Windows
Get-Process | Where-Object {$_.ProcessName -match 'Microsoft.ConfigurationManagement'}

# Controllo versione installata della console
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\SMS\Setup' | Select-Object ClientVersion

Se la console è vecchia, aggiornarla è un’azione reversibile e a basso rischio. Se invece sospetti una cache corrotta, chiudi la console, rinomina il profilo locale della console o pulisci i file di cache secondo la procedura interna prima di reinstallare. La reinstallazione è l’ultima opzione, non la prima.

Workflow di correzione consigliato

Quando la voce resta disabilitata, il flusso corretto è questo:

1. Conferma che stai selezionando un vero oggetto script nel nodo corretto della console.
2. Prova con un account amministrativo diverso per distinguere tra problema oggetto e problema permessi.
3. Verifica lo stato dello script: pending, approved, denied, retired o non eleggibile.
4. Controlla versione della console e allineamento con il site server.
5. Ispeziona i log della console e del provider SMS per messaggi di access denied, object not found o invalid state.

Se il test con l’account alternativo abilita il comando, la soluzione più pulita è correggere il ruolo RBAC o lo scope dell’utente originale. Se invece il comando resta disabilitato per tutti, il problema è quasi certamente nello stato dell’oggetto o nella coerenza del provider.

In caso di oggetto danneggiato o replica incoerente, una strada prudente è forzare l’aggiornamento della console e del provider, senza toccare i dati applicativi. Prima verifica che il site server sia sano, che il servizio SMS Provider risponda e che non ci siano errori nel log del site server. Se hai un cluster o più site system, controlla anche che la replica WMI o SQL non sia in ritardo.

Log e punti di osservazione utili

Per non andare a tentoni, guarda almeno questi punti:

• Console log: errori di caricamento, permessi, accesso al provider.
• Site server log: problemi di approvazione, oggetti non trovati, access denied.
• SMS Provider: incoerenze tra console e database, timeout o errori WMI.
• Event Viewer sul server SCCM: eventi di servizio, WMI, applicazione.

Se non conosci il nome esatto del log nella tua versione, non forzarlo a memoria: apri la cartella dei log del client console o del site server e ordina per data. La presenza di messaggi come Access denied, Invalid object, Cannot load provider o Approval state mismatch è già sufficiente per restringere il problema.

Intervento minimo reversibile prima di cambiare qualcosa

Se devi intervenire, parti da azioni reversibili. La sequenza più sicura è:

1. Riapri la console con un account diverso o con privilegi elevati.
2. Aggiorna la vista dell’oggetto e forzane il reload.
3. Verifica la versione della console rispetto al site server.
4. Ripristina eventuale cache locale della console, senza toccare il server.
5. Solo dopo, valuta riparazione o reinstallazione della console.

Questa sequenza ha blast radius minimo: agisce solo sul client amministrativo e non modifica script, collection o policy distribuite ai device. Il rollback è immediato: chiudi la console, ripristina eventuali file rinominati e riavviala. Se hai aggiornato la console, il rollback consiste nel reinstallare la build precedente solo se consentito dal tuo standard operativo.

Quando il problema è davvero lato server

Se tutte le verifiche lato console sono negative, il focus passa al site server. Qui il sospetto principale è un provider non coerente, una replica in ritardo o una degradazione del servizio SMS. In quel caso la disabilitazione del comando è solo la superficie visibile di un problema più profondo.

Controlla che i servizi SCCM critici siano in esecuzione e che il server risponda correttamente alle richieste di amministrazione. Verifica anche che il database sia raggiungibile e che non ci siano lock o timeout sullo schema del sito. Se il sito è in manutenzione o ha appena subito un aggiornamento, aspetta la fine della replica prima di concludere che il problema sia permanente.

Un errore tipico è scambiare un ritardo di replica per un bug dell’interfaccia. Se lo script è stato appena creato o modificato, ma la console secondaria non mostra ancora lo stato corretto, aspetta la propagazione e confronta il comportamento direttamente sul server primario.

Fix strutturale: evitare che ricapiti

Una volta risolto, conviene mettere un minimo di disciplina operativa. Per gli script approvabili in SCCM, definisci una procedura standard che includa:

• ruolo RBAC dedicato per chi approva, separato da chi pubblica;
• verifica della versione console dopo ogni update del site;
• controllo log minimo prima di aprire ticket su “tasto grigio”;
• ciclo di approvazione documentato per gli script critici.

Questa separazione riduce gli errori operativi e rende più chiaro dove si è rotto il flusso: pubblicazione, revisione, approvazione o distribuzione. In ambienti grandi, il vantaggio non è teorico: tagli subito il rumore quando un operatore vede un comando disabilitato e non sa se chiedere un permesso, aprire una console diversa o fermare la pipeline.

Checklist finale da usare sul campo

Se devi chiudere il caso rapidamente, questa checklist basta spesso a isolare il guasto:

1. Conferma che l’oggetto sia uno script approvabile e non un altro tipo di risorsa.
2. Prova con un account admin diverso e confronta il risultato.
3. Controlla stato dello script e campo di approvazione nella proprietà dell’oggetto.
4. Verifica versione console e allineamento con il site server.
5. Apri i log della console e del provider per errori di permessi o stato.
6. Se serve, rigenera la cache locale della console o reinstallala.

Se dopo questi passi la voce resta disabilitata, il problema non è più “l’interfaccia che non funziona”, ma un’anomalia concreta da trattare sul site server o sul modello RBAC. A quel punto ha senso aprire un’analisi più profonda su provider, replica, database o corruzione dell’oggetto.

Assunzione operativa: il comando disabilitato è stato osservato in console Configuration Manager su ambiente Windows recente, con accesso amministrativo standard e senza modifiche straordinarie al site nel momento della verifica.