2010-11-26 10 views
5

Por lo que he investigado y preguntado a otras personas, parece que el MSI normal se ejecuta como usuario limitado la mayor parte del tiempo, especialmente durante las fases de la GUI.¿Puedes forzar a MSI a ser siempre administrador?

Pero la aplicación requiere un aviso elevado durante la fase de instalación de todos modos, y me encantaría tener derechos de administrador durante las acciones personalizadas que se realizan durante las fases de selección de la GUI. ¿Realmente no hay forma de forzar la solicitud de UAC desde el principio?

Además, también se deben realizar algunas acciones personalizadas durante la instalación de Active Directory, y tampoco se puede realizar si el MSI se ejecuta como invitado o algo así.

Respuesta

2

Puede iniciar su MSI desde bootstrapper, que contiene el manifiesto apropiado incrustado.

1

Durante la fase de la GUI, siempre se ejecuta en un contexto de usuario no elevado. Solo la acción personalizada en InstallExecuteSequence se eleva en el modo de ejecución diferida.

Para solucionar este bien debe volver a diseñar su MSI o utilizar un programa previo (setup.exe), que solicitud de elevación en el arranque

http://msdn.microsoft.com/en-us/magazine/cc163486.aspx#S7

+0

Ese es un diseño supercortado de Microsoft. Yo diría que setup.exe está bien si no es para usuarios que hacen clic en setup.msi o en instalaciones desatendidas de Active Directory. – Coder

+0

Puede pasar un parámetro (propiedad pública) a su MSI (por ejemplo, RUNFROMSETUP) desde su setup.exe y alertar al usuario (utilizando LaunchCondition) si la propiedad no se pasa. Al instalar a través de instalación desatendida de AD, podría pasar el parámetro en la línea de comandos (creo que MSI siempre se elevará a través de SMS). De esta forma, el usuario recibe un mensaje cuando ejecuta directamente el MSI y también se puede ejecutar desatendido. –

2

Uso del Privileged propiedad en un lauchcondition.

3

Las acciones personalizadas aún pueden fallar en Vista, Server 2008 y Windows 7 incluso cuando se ejecuta un instalador elevado. Esto se debe a que se ejecutan suplantando al usuario que elevó el proceso.

Las acciones personalizadas que requieren privilegios completos y no usan información por usuario deben marcarse para ejecutarse sin suplantación. De esta forma se ejecutan bajo la cuenta del sistema local sin restricciones.

+0

¿Cómo se marcan? – Coder

+0

Asegúrese de que se ejecutan en InstallExecuteSequence, después de InstallInitialize con los indicadores "msidbCustomActionTypeInScript" y "msidbCustomActionTypeNoImpersonate". En Wix puede establecer el indicador Suplantación en "no". –

Cuestiones relacionadas