2017-07-25 3 views
2

Mise à jourComment démarrer PowerShell dans WiX avec un accès approprié au Registre Windows?

Intéressant, si je lance 32bit Powershell pour exécuter le script, il me donne la même erreur. Il semble que la PowerShell 32 bits n'a pas accès à l'arbre de registre 64 bits? J'ai essayé d'utiliser WixQuietExec64 mais il a donné la même erreur. J'ai également essayé de fournir le chemin complet de la powershell (C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe) pour assurer l'installateur pour lancer la version 64bits, mais que STILL a donné la même erreur ... On dirait que cela peut être provoqué par l'installateur MSI lui-même étant 32bit ??

MSI (s) (4C:C0) [14:25:49:955]: Hello, I'm your 32bit Elevated Non-remapped custom action server. 

Original post

Je le script test.ps1 suivant:

$exchangeroot = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\" 
$allexchanges = Get-ChildItem -Path Registry::$exchangeroot -Name | Where-Object { $_ -match "^V.." } 
$sorted = $allexchanges | Sort-Object -descending 
If ($sorted.Count -gt 1) { $latest = $sorted[0] } Else { $latest = $sorted } 
$setup = $exchangeroot + $latest + "\Setup" 
$properties = Get-ItemProperty -Path Registry::$setup 
$properties 

Exécution du script dans une fenêtre PowerShell normale donne le résultat suivant:

PS C:\Program Files (x86)\TrustValidator Exchange Server Plugin> .\test.ps1 

Required machine-level settings.   : 1 
Services         : C:\Program Files\Microsoft\Exchange Server\V15 
NewestBuild        : 10845 
CurrentBuild        : 710737954 
Information Store Service     : 1 
Messaging and Collaboration Event Logging : 1 
MsiInstallPath       : C:\Program Files\Microsoft\Exchange Server\V15\ 
... 

Alors Ça marche. Maintenant, le lancement PowerShell de l'installateur WiX et l'exécution du script, il ne génère pas le même résultat:

WixQuietExec: Get-ItemProperty : Cannot find path 
WixQuietExec: 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Setup' because it 
WixQuietExec: does not exist. 
WixQuietExec: At C:\Program Files (x86)\TrustValidator Exchange Server Plugin\test.ps1:10 
WixQuietExec: char:16 
WixQuietExec: +  $properties = Get-ItemProperty -Path Registry::$setup 
WixQuietExec: +     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
WixQuietExec:  + CategoryInfo   : ObjectNotFound: (HKEY_LOCAL_MACH...erver\v15\Set 
WixQuietExec:  up:String) , ItemNotFoundException 
WixQuietExec:  + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetIt 
WixQuietExec:  emPropertyCommand 

Maintenant, si l'on observe le message d'erreur, il est comme si elle a accès de l'arbre jusqu'à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\, parce que mon script chercherait et énumérerait toutes les versions, donc v15 doit être accessible jusqu'à ce point, mais quand il essaye d'aller plus loin pour obtenir le ItemProperty, il ne peut pas. Cela m'amène à croire que quelque chose me manque peut-être quand je lance PowerShell à partir de l'installateur WiX ...?

C'est ce qui est dans mon fichier wxs:

<SetProperty Id="InstallPlugin" 
    Before ="InstallPlugin" 
    Sequence="execute" 
    Value ="&quot;powershell.exe&quot; -Command &quot;cd '[INSTALLFOLDER]'; &amp; '[#TestPS1]' ; exit $$($Error.Count)&quot;" /> 
<CustomAction Id="InstallPlugin" BinaryKey="WixCA" DllEntry="WixQuietExec" Execute="deferred" Return="ignore" Impersonate="no" /> 

Voici une liste des articles que je l'ai déjà essayé ou double vérifié:

  • J'ai essayé différentes combinaisons de -NoProfile, -ExecutionPolicy ByPass, -Version 2.0 et toujours pas bon.
  • Je suis déjà en cours d'exécution du programme d'installation comme InstallPrivileges="elevated"
  • Je suis déjà en cours d'exécution de la CustomAction comme Execute="deferred" et Impersonate="no"
  • J'ai essayé avec AdminImage="yes"
  • J'ai essayé de placer <Property Id="MSIUSEREALADMINDETECTION" Value="1" />

Toute autre idée serait appréciée. :(

Répondre

0

Oh ... mon ... dieu ...

Ok j'ai finalement obtenu ce travail. Il y avait en fait plusieurs problèmes et les solutions à ces problèmes étaient en fait en bits et des éléments d'information que je rassembler à travers plusieurs questions SO.

Pour résumer, voici ce que je voulais faire:

  1. Lancer une powershell de WiX pour exécuter mon script d'installation.
  2. Ma recherche de script Windows Registry (nécessite 64 bits) pour installer l'emplacement Exchange Server
  3. Mon script charge le script Exchange Management Shell (EMS) (nécessite 64 bits et l'utilisateur approprié) de l'emplacement d'installation
  4. Sous la session EMS, mon script exécuté un brunch d'autres scripts pour enregistrer un plugin Echange

problème 1)

Peu importe ce que je faisais, l'installateur WiX lance toujours mon powershell en 32b cela, quel que soit le réglage Platform="x64", Win64="yes", et même WixQuietExec64. J'ai même construit le programme d'installation dans Visual Studio comme x64 et tout le reste comme x64.

La solution est de référencer directement la powershell sysnative, elle doit être sysnative dans le SetProperty.

C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe 

En fait, je ne ai essayé auparavant, et je pensais que cela ne fonctionnait pas, mais la cause était masqué par le problème 2 ci-dessous.

Problème 2)

Partout je lis, ils ont dit que vous devez exécuter avec Execute="deferred" Impersonate="No". Je crois que cela fonctionnerait en effet pour la plupart des cas si vous ne faites rien de génial. Cependant, je devaitImpersonate. J'ai découvert que le programme d'installation WiX exécute votre autorité de certification en tant qu'élément avec l'utilisateur NT Authority/System. Cela m'a vissé parce que le script Exchange Management Shell que j'essayais de source utiliserait essentiellement vos informations d'identification et essayer d'établir une session avec le serveur Exchange ... et bien sûr vous ne pouvez pas vous connecter en tant que NT Authority/System!

La solution est d'utiliser Impersonate="yes" pour que l'installateur WiX courrait votre CA comme élevée et l'utilisateur que vous êtes actuellement connecté. J'ai toujours eu l'impression que vous devez utiliser Impersonate="no" lors de l'utilisation Execute="deferred" ... mais vous don 't. J'ai renoncé à résoudre ce problème pendant quelques jours, puis je suis retourné à elle et l'ai fait fonctionner. Les 2 commandes les plus utiles qui m'a aidé compris cela était en fait:

  • whoami
  • Get-ChildItem env: (pour vérifier la PROCESSOR_ARCHITECTURE)