MSI Erreur “L'ordinateur doit être approuvé pour la délégation” causé par KB2918614
Nous avons une MSI installateur qui a récemment cessé de travailler sur un Windows 2008 R2 environnement. Le programme d'installation est copiée sur l'ordinateur cible à l'aide de la \\servername\c$\
admin UNC actions et est ensuite exécutée à distance à l'aide de la méthode de création sur le WMI classe Win32_Process. L'exécution à distance maintenant échoue avec le message d'erreur suivant dans l'Observateur d'Événements:
La description pour l'ID d'Événement 10837 à partir de la source MsiInstaller ne peut pas être
trouvé. Soit le composant que soulève cet événement n'est pas installé sur
votre ordinateur local ou l'installation est corrompu. Vous pouvez installer
ou de réparer le composant sur l'ordinateur local.Si l'événement provient d'un autre ordinateur, l'affichage de l'information
doivent être enregistrées avec l'événement.Les informations suivantes sont incluses avec l'événement:
Produit: NOTRE NOM de PRODUIT -- L'opération demandée ne peut pas
être achevé. L'ordinateur doit être approuvé pour la délégation et l'
compte d'utilisateur actuel doit être configuré pour autoriser la délégation.
Après recherche il semble que ce est causée par un récemment publié correctif de sécurité pour Windows Installer. Lorsque je désinstalle KB2918614 le programme d'installation commence à travailler de nouveau, et si j'ai réinstaller KB2918614 la MSI cesse de fonctionner à nouveau.
Le message d'erreur indique que, pour résoudre le problème, nous devons avoir à un Administrateur de Domaine modifier l'ordinateur cible à l'aide de Utilisateurs et Ordinateurs Active Directory pour autoriser la délégation, cependant, la MSI est de ne PAS utiliser toutes les ressources à distance, donc je ne vois pas pourquoi cela est nécessaire. La même MSI et l'exécution à distance de processus fonctionne très bien sur Windows Server 2012, donc je me demande si c'est un problème avec le patch pour 2008 R2.
Existe-il d'autres façons de contourner ce message d'erreur?
Mise à JOUR: Ce ne semble pas être un problème avec le WMI à distance de l'exécution, comme il se produit également lorsque nous essayons d'installer le MSI à distance à l'aide de Powershell, WinRM, et la Invoke-Commmand -ComputerName TargetComputer ...
applet de commande. Il y a un changement dans la façon dont le programme d'installation de Windows 2008 R2 fonctionne après l'installation de KB2918614 qui empêche maintenant l'action personnalisée à partir de la fin de tâche.
Eh bien, vous êtes en fait en utilisant une ressource distante, le fichier provient d'un autre ordinateur. Windows sait et stocke cette information dans un autre NTFS les flux de données. Poser des questions à ce sujet à l'superuser.com
Nous avons conçu la MSI et l'espoir de trouver un moyen de le réécrire pour contourner ce problème pour nos clients. J'ai vérifié pour voir si le fichier a été bloqué, mais il ne semble pas avoir la Sécurité: "Ce fichier provient d'un autre ordinateur" ou Débloquer l'option dans les propriétés du fichier.
Nous avons également rencontrer des problèmes avec la distance de l'exécution d'une MSI après ce MS mise à Jour a été appliquée. J'ai parlé avec un représentant de Microsoft, aujourd'hui, qui a dit que c'était un problème connu en cours d'élaboration. Il m'a dit qu'ils sont en espérant avoir un patch qui corrige ce quelque part dans l'intervalle de temps de la mi-octobre à début novembre.
J'ai suivi avec Microsoft aujourd'hui, et ils m'ont dit la trouvé de solution ici devrait résoudre le problème: support2.microsoft.com/kb/3000988. Cependant, je vois que dans la réponse ci-dessous qui est voté. Quelqu'un a appliqué ce correctif et il n'avait pas de travail pour eux?
OriginalL'auteur Greg Bray | 2014-08-29
Vous devez vous connecter pour publier un commentaire.
De ce que je comprends,
Avec KB2918614, MS ont apparemment essayé de réparer quelque chose dans le Service Windows Installer.
De nouveaux trucs:
%windir%\Windows\Installer. Cela se fait pour tous les produits installés
sur la machine(avec KB2918614 déjà installé).
Erreur:
Et, dans cette comparaison, pour une raison quelconque, ces incompatibilité! (Trouvé dans les journaux détaillés MSI).
Une fois cela échoue, il cherche
La Machine politique de la valeur "AlwaysInstallElevated'
La stratégie de l'utilisateur de la valeur "AlwaysInstallElevated'
Maintenant, si vous exécutez une installation silencieuse "qn", cette erreur est levée: MSI_LUA: de l'invite d'Élévation désactivé pour le silence s'installe.
Informations Supplémentaires:
Mon MSI est ivkoded par le biais d'un programme d'amorçage exe. Mais, ça n'a pas vraiment d'importance. Même un manuel de l'appel à msiexec par ligne de commande se comporte de la même manière.
Toutes les entrées/solutions, n'importe qui?
OriginalL'auteur DebugBreak
C'est le mot de la MME Entreprise Soutenir les gens.
Apparemment, ils ne sont pas au courant de tout corriger. Au moins à partir de maintenant.
Ils sont tous en disant que cette base de connaissances est de corriger une faille de sécurité.
Je ne comprends pas ce genre de correctif de sécurité ce qui permet une nouvelle Installation sans une invite UAC, mais jette une invite UAC uniquement pour la Mise à niveau.
Solution 1: la Distribution de hachage.
Capturer le fichier de Hachage* dans une machine et de les distribuer à d'autres machines.
Hash des fichiers sont créés en vertu de l' “%windir%\installer” répertoire. La convention de nommage est comme suit: “SourceHash
* Ce fichier est créé uniquement lorsqu'un Produit est installé avec KB2918614 installé sur la machine.Ce répertoire est caché. Ouvrir l'invite de cmd à l'aide de "exécuter en tant qu'administrateur". Traverser ce chemin et ouvrez le dossier à l'aide de "explorer". de commande.
[Je ne pouvais pas résoudre le problème à l'aide de cette approche - peut-être parce que l'accès à ce répertoire nécessite des privilèges d'administrateur dont le programme d'installation de Windows lui-même pourrait ne pas avoir]
Solution 2: Liste Blanche.
Que si vous faites confiance à l'application qu'il est toujours signé numériquement et ne contiennent pas de quoi que ce soit malveillant(même dans le futur).
Étape 1: Activer Le Filtrage Par Liste Blanche
Sous la Clé “HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer”, créez une valeur DWORD: “SecureRepairPolicy” et définissez sa Valeur à 2.
Étape 2: Ajouter l'application à la liste blanche
Créer une nouvelle clé “SecureRepairWhitelist” dans "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer” et de créer des valeurs de type string avec les codes des produits(y Compris les fleurs crochets {}) du produit.
... Hélas, ces deux solutions de contournement besoin des privilèges d'administrateur!
Bienvenue. Ouais, c'est assez mauvais pour les développeurs. Les utilisateurs finaux peuvent en quelque sorte de travail leur chemin. Une suggestion: si possible: lorsqu'un scénario de mise à niveau est rencontré, désinstallez le produit et de faire une nouvelle installation.
J'ai essayé la distribution de la table de hachage, mais la MSI était de le supprimer et de tenter de recréer l'échec qui se passait pendant la récréation. Je n'arrivais pas à obtenir des listes d'autorisation de travail. Le programme d'installation de la clé qui manquait, alors j'ai essayé d'utiliser psexec -s et qui ont travaillé. La liste blanche est répertorié comme une solution de contournement sur msdn: support.microsoft.com/en-us/kb/2918614
OriginalL'auteur DebugBreak
Voici mon automatique de la façon d'utiliser le registre de la liste blanche contourner mentionné sur le site de Microsoft.
Maintenant, avant que je lance mon installation commande sur une machine distante, je regarde la MSI et d'en extraire le code du produit avec Get-ProductCodeFromMSI, puis utiliser les Add-GuidToWhitelist pour ajouter chaque GUID à la liste sur l'ordinateur. Voici un exemple:
Avant de faire cela, chaque machine peut être testé et réparé pour la solution de contournement à l'aide de Test-SecureRepairPolicy et de Réparation-SecureRepairPolicy, respectivement.
Get-ProductCodeFromMSI nécessitera la DLL référencés à être placé quelque part et débloqué - cette DLL peut être récupéré à partir de la Wix toolset.
Code pour les fonctions que j'référence est ici:
OriginalL'auteur Chris N
Je rencontre également le problème. J'ai un script powershell pour installer MSI sur des machines distantes (en utilisant la Commande Invoke-command applet de commande et de fournir les informations d'identification avec le script), mais tout à coup, il n'a pas pu installer MSI qui, je suppose, également à partir de ce correctif de sécurité.
Après exécutez le fichier d'installation MSI manuellement sur l'ordinateur cible à l'aide du compte de domaine (à partir du bureau à distance), du coup le script powershell pouvez exécuter l'installation MSI à l'aide de compte de domaine, mais toujours pas réussi à installer si j'ai utilisé de la machine cible locale compte admin.
Je préfère l'ajouter comme commentaire, mais je n'ai pas assez de rep pour le faire. Si l'autre a toute solution ou une explication pour ce que j'aimerais savoir aussi. Merci.
OriginalL'auteur pradana
C'est à la SourceHash{produit code} les fichiers sous \windows\installer répertoire.
Ce fichier peut être ouvert avec Orca vous pouvez lire le contenu. Il contient un nom de fichier, algorithme de hachage prescripteur, et de hachage. Sur Windows 2k3 ce hash est une base64ed de hachage sha256 avec le dernier octet changé.
Si vous renommer le SourceHash fichier pour votre produit de la manière, j'ai trouvé la mise à jour travaillé et après cela, une nouvelle SourceHash fichier est généré. Vous pouvez ensuite diff les deux source de hachage des fichiers. Dans le cas que j'étudie, lorsque vous diff les deux fichiers, seul le hachage répertoriées pour le msi d'origine est différente.
Après une mise à niveau réussie de la valeur de hachage de la nouvelle msi répertoriés dans la source de hachage de fichier correspond à celui de la source d'installation. L'cassé sourcehash fichier a été évidemment généré à partir d'une modification/la source différente MSI, bien que je n'ai pas encore été en mesure d'identifier qui.
OriginalL'auteur carpenterjc
J'ai le même problème. Msi n'a pas pu être installé avec la Commande Invoke-command Chic. J'ai trouvé que si je installer tout de MSI sur le serveur localement sous le même compte qui est utilisé pour la Commande Invoke-command le problème est résolu et Invoke-Command commence à travailler comme d'habitude.
OriginalL'auteur Iurii
Réponse de Microsoft:
Cette mise à jour de sécurité corrige une vulnérabilité signalée confidentiellement dans Microsoft Windows. Cette vulnérabilité pourrait permettre une élévation de privilèges si un attaquant exécute une application spécialement conçue pour que les tentatives de réparation a été précédemment installé l'application. L'attaquant doit disposer d'informations d'identification valides et être en mesure d'ouvrir une session localement pour exploiter cette vulnérabilité.
Solution de contournement si vous avez des problèmes avec la réparation de la demande:
Désinstaller l'application et de la réinstaller avec la mise à jour de sécurité installée. (sourcehash fichier généré avec la mise à jour de sécurité)
Copier manuellement le sourcehash fichier c:\windows\installer dossier. Comme le sourcehash fichier est généré sur la base de fichiers de l'application, le sourcehash fichier généré sur Un ordinateur peut être utilisé sur l'ordinateur B.
http://happysccm.com/kb2918614-uac-gate/ - commandes pour le désinstaller.
OriginalL'auteur HappySCCM
J'ai eu cela aussi bien sur des serveurs différents. Après quelques heures de creuser, j'ai découvert qu'ils ne pouvaient pas atteindre les contrôleurs de domaine. Vérifiez vos paramètres DNS et de s'assurer qu'ils peuvent atteindre l'ANNONCE. Après correction de cette erreur a disparu.
OriginalL'auteur Eric Herlitz
Si vous sont en cours d'exécution à travers psexec, tout en ajoutant l'argument-s également à la résolution de l'erreur. Ensuite, il est exécuté à distance de l'utilisateur du système et le contrôle de compte d'utilisateur n'est pas requis.
OriginalL'auteur curlyhairedgenius