WiX, UAC, azione personalizzata gestita e imitazione

Ho creato un pacchetto di Windows Installer utilizzando WiX 3.6 che incorpora un'azione personalizzata C#.WiX, UAC, azione personalizzata gestita e imitazione

In questa fase, l'installazione richiede che

Il programma di installazione essere eseguito utilizzando un account di amministratore locale specifico (in questo caso, l'account di installazione di SharePoint, che è un amministratore locale) Controllo account
utente essere disabilitato

Non esiste un modo per ignorare il requisito n. 1, perché l'azione gestita può eseguire solo determinati passaggi se viene eseguita nel contesto dell'account di installazione di SharePoint.

Vorrei rimuovere il requisito n. 2 e lasciare che il programma di installazione funzioni correttamente anche se UAC è abilitato.

Ho studiato il problema in modo piuttosto estensivo, ma non riesco ancora a farlo funzionare. Ho impostato InstallScope = "perMachine" nel mio pacchetto, che sembra richiedere correttamente l'elevazione UAC, ma il programma di installazione non riesce ancora con il famigerato errore 2869.

Il problema principale è che la mia azione personalizzata è configurata con Impersonate = "sì" perché deve essere eseguito nel contesto dell'utente corrente, non nell'account dell'amministratore locale. Quando eseguo una ricerca online, quasi tutte le "correzioni" puntano a Impersonate = "no" nell'azione personalizzata, ma non è un'opzione per me.

La mia domanda è: esiste un modo per eseguire un'azione gestita personalizzata con l'identità dell'utente corrente senza che UAC sia completamente disabilitato?

fonte

2012-10-16 Raphael Londner

Amore una risposta a questo. –

Sto provando a fare la stessa cosa. Il modo in cui sto cercando di aggirare l'ostacolo è la creazione di un file EXE che ha privilegi di amministratore necessari nel app.manifest (http://stackoverflow.com/questions/3915370/impersonating-in-net-using-process-start-and -uac/3915492 # 3915492). Quindi chiamo EXE come azione personalizzata differita di tipo 2 che impersona l'utente (http://stackoverflow.com/a/8828776/1203288). Tuttavia, questo funziona sulla mia macchina, ma sto riscontrando problemi su altre macchine: non è nemmeno in esecuzione su altre macchine purché sia richiesto admin nell'app.manifest. Spero che questo ti dia un buon inizio. – bsara

Quando si utilizza Impersonate="yes" l'azione personalizzata viene eseguita senza privilegi di amministratore con le credenziali dell'utente attualmente registrato.

Quando Impersonate="no" l'azione personalizzata viene eseguito in un contesto sistema. Durante l'esecuzione nel contesto di sistema, l'azione personalizzata ha pieno accesso al sistema.

Da WiX CustomAction element documentazione, Impersonate attributo:

Questo attributo specifica se il Windows Installer, che esegue come LocalSystem, dovrebbe impersonare contesto utente dell'utente l'installazione durante l'esecuzione di questa azione personalizzata. In genere, il valore deve essere "sì", tranne quando l'azione personalizzata richiede privilegi elevati per applicare modifiche alla macchina.

fonte

2012-10-20 11:18:23

Ho fatto questo, ma la mia applicazione lancia un'eccezione System.UnauthorizedAccess. Come potrebbe accadere questo, quando avrò i diritti di sistema? – AstralisSomnium

@AstralisSomnium Prova ad assicurarti che l'azione personalizzata sia effettivamente eseguita con accesso completo. 'Impersonate =" yes "' è valido solo per le azioni _deferred_. A loro volta, le azioni posticipate non hanno pieno accesso alle proprietà di installazione, è possibile utilizzare solo 'CustomActionData'. –

Penso che sia effettivamente il contrario. Secondo la documentazione WIX:. "Questo attributo specifica se il Windows Installer, che esegue come LocalSystem, dovrebbe impersonare contesto utente dell'utente l'installazione durante l'esecuzione di questa azione personalizzata In genere il valore deve essere 'sì', tranne quando l'azione personalizzata ha bisogno di privilegi elevati per applicare le modifiche alla macchina. " Così impersonate = "no" significa la vostra azione viene eseguito come LocalSystem, che ha pieno accesso alla macchina, e impersonate = "sì" significa l'azione personalizzata viene eseguito con i privilegi dell'utente installazione. –

Dove si fa riferimento all'azione personalizzata?

Avere il .msi in esecuzione con privilegi elevati potrebbe non essere sufficiente. Per garantire che l'azione personalizzata funzioni con privilegi elevati, è necessario utilizzare un'azione personalizzata posticipata e fare riferimento ad essa nel InstallExecuteSequence.Questo potrebbe non risolvere i tuoi problemi, ma gli articoli collegati in fondo vanno in dettaglio nello spiegare le logiche UAC durante un'installazione msi.

In sostanza, non tutto il programma di installazione non porta i privilegi con esso, un bisogna essere sicuri di eseguire l'azione personalizzata quando il programma di installazione utilizza i privilegi elevati.

Fonte: http://blogs.msdn.com/b/rflaming/archive/2006/09/30/uac-in-msi-notes-when-general-custom-action-mitigation-fails.aspx

Spero che troviate utile questa informazione, potrei essere di maggiore assistenza se si condivide il codice di azione personalizzata.

fonte

2014-08-13 08:41:14 Epiderma

Sebbene questo collegamento possa rispondere alla domanda, è meglio includerlo e le parti essenziali della risposta qui e fornire il link per riferimento. Le risposte di solo collegamento possono diventare non valide se la pagina collegata cambia. –

Hai ragione, scusami, l'ho modificato con una risposta migliore. Sono nuovo e sto ancora imparando come usare StackOverflow. Grazie. – Epiderma

WiX, UAC, azione personalizzata gestita e imitazione

risposta

Problemi correlati