Supressing EULA in MS PSkill for packages?
I have found need for using Microsoft's PSKill and other PS tools from the same suite, but upon first run they prompt for End User License Agreement (EULA). I want to prepopulate all the workstations in my environment with these tools that my SMS packages can use them (when needed) to close processes. If I run them from SMS, wont my install hang up/fail on the EULA prompt during silent installs?
0 Comments
[ + ] Show comments
Answers (16)
Please log in to answer
Posted by:
anonymous_9363
16 years ago
Capture the license agreement process in an installer project, then add the information gleaned into the package you're deploying. As these are simple tools, I can't imagine there's be too much complication: probably just a HKCU entry...
EDIT: I should follow my own advice, shouldn't I? The first hit from a Google for 'PSKILL +EULA' got me http://forum.sysinternals.com/forum_posts.asp?TID=9038&KW=EULA
EDIT: I should follow my own advice, shouldn't I? The first hit from a Google for 'PSKILL +EULA' got me http://forum.sysinternals.com/forum_posts.asp?TID=9038&KW=EULA
Posted by:
Grenex
16 years ago
Sorry, but that will not suffice (I should have added those details to my original thread)
The EULA is a registry key in HKCU portion of the registry. Assuming I am installing my package with SMS (which runs in the local system context) or installing it remotely by pushing to the target PC using PSEXEC and specifying alternate credentials, there is no way to pre-populate those keys for the context of the installing ID before the package installs. I want to call PSkill.exe as one of my first actions to ensure apps that may conflict with my install are shut down, so it needs to run right after cost initialization in the sequence
One thought was to have a custom action at the start of the script (prior to calling PSKill) to populate the proper HKCU keys, but that is a pain in the @$$ to do that each time for every package I want to use one of teh PSTools .EXEs for.
I see lots of refernces on Appdeploy.com to using PSkill.exe, but nobody mentions how they work around this snag.
The EULA is a registry key in HKCU portion of the registry. Assuming I am installing my package with SMS (which runs in the local system context) or installing it remotely by pushing to the target PC using PSEXEC and specifying alternate credentials, there is no way to pre-populate those keys for the context of the installing ID before the package installs. I want to call PSkill.exe as one of my first actions to ensure apps that may conflict with my install are shut down, so it needs to run right after cost initialization in the sequence
One thought was to have a custom action at the start of the script (prior to calling PSKill) to populate the proper HKCU keys, but that is a pain in the @$$ to do that each time for every package I want to use one of teh PSTools .EXEs for.
I see lots of refernces on Appdeploy.com to using PSkill.exe, but nobody mentions how they work around this snag.
Posted by:
anonymous_9363
16 years ago
Thinking around the problem, why not build a WMI-based script and use the .Terminate method to kill the process? No file-copying, no HKCU issues...
Option Explicit
Function KillProcess(ByVal strProcessName, ByVal strComputer, ByVal strUser, ByVal strPassword)
Dim objLocator
Dim wbemServices
Dim wbemObjectSet
Dim wbemObject
Dim strMsg
Dim blnKilled
On Error Resume Next
KillProcess = False
Set objLocator = CreateObject("WbemScripting.SWbemLocator")
If Len(strUser) > 0 And Len(strPassword) > 0 then
Set wbemServices = objLocator.ConnectServer(strComputer,,strUser, strPassword)
else
Set wbemServices = objLocator.ConnectServer(strComputer)
End if
If Err.Number <> 0 Then
MsgBox Err.Description,,"ProcessesRemote"
WScript.Quit(False)
End If
Set wbemObjectSet = wbemServices.InstancesOf("Win32_Process")
If strComputer <> "." Then
strMsg = "Process killed on " & strComputer & " at " & Now() & vbCRLF & vbCRLF
Else
strMsg = "Process killed at " & Now() & vbCRLF & vbCRLF
End If
strMsg = strMsg & "PID" & vbTAB & "Name" & vbCRLF
strMsg = strMsg & "---" & vbTAB & "-" & vbCRLF
For Each wbemObject In wbemObjectSet
If UCase(wbemObject.Name) = UCase(strProcessName) Then
wbemObject.Terminate
blnKilled = HasProcessTerminated(strProcessName)
End If
If blnKilled Then
strMsg = strMsg & wbemObject.ProcessID & vbTAB & wbemObject.Name & " killed" & vbCRLF
End If
Next
KillProcess = True
Set wbemObjectSet = Nothing
Set wbemServices = Nothing
Set objLocator = Nothing
End Function
Function HasProcessTerminated(ByVal strProcessToCheck)
'// Monitor process termination
Dim strSQL
Dim strProcessName
HasProcessTerminated = False
strSQL = "SELECT * FROM __instancedeletionevent " & "WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'"
Set colMonitoredProcesses = objWMIService.ExecNotificationQuery(strSQL)
Do While UCase(strProcessName) <> UCase(strProcessToCheck)
Set objLatestProcess = colMonitoredProcesses.NextEvent
strProcessName = objLatestProcess.TargetInstance.Name
Sleep(1)
intCounter = intCounter + 1
If intCounter > intMaxWait Then
Exit Function
End If
Loop
HasProcessTerminated = True
Set colMonitoredProcesses = Nothing
Set objLatestProcess = Nothing
End Function
Sub Sleep(ByVal intSleepPeriod)
'// Timer returns the number of seconds that have elapsed since midnight.
Dim intStartTime
Dim intEndTime
Dim intCurrentTime
On Error Resume Next
intStartTime = Timer
intEndTime = intStartTime + intSleepPeriod
Do While Timer <= intEndTime
Loop
On Error Goto 0
End Sub
Posted by:
AngelD
16 years ago
Posted by:
anonymous_9363
16 years ago
ORIGINAL: GrenexCould you not add the file and the reg data to your package template(s)?
One thought was to have a custom action at the start of the script (prior to calling PSKill) to populate the proper HKCU keys, but that is a pain in the @$$ to do that each time for every package I want to use one of teh PSTools .EXEs for.
Posted by:
Grenex
16 years ago
One would assume the PSTool EULA is required to prevent the suite from being used as a malicious attack tool, sadly it causes us to not take advantage of it for its proper use.
I COULD create the WMI script, but I was hoping to make it a bit simplier for anyone who wants to package in my environment without having to know that long script, or how it works.
I guess I can continue to use Kill.exe (windows 2000) and TSKILL.exe (Winxp) in my environment and do conditional checking to see which one to run for each package....
Was hoping to find a better answer for this. [:(]
I COULD create the WMI script, but I was hoping to make it a bit simplier for anyone who wants to package in my environment without having to know that long script, or how it works.
I guess I can continue to use Kill.exe (windows 2000) and TSKILL.exe (Winxp) in my environment and do conditional checking to see which one to run for each package....
Was hoping to find a better answer for this. [:(]
Posted by:
anonymous_9363
16 years ago
ORIGINAL: GrenexCome on! You have to be kidding! :) Any packager worth having is going to be completely at home with scripts.
I COULD create the WMI script, but I was hoping to make it a bit simplier for anyone who wants to package in my environment without having to know that long script, or how it works.
Posted by:
Grenex
16 years ago
The way I see it, the best packager is a lazy SOB who will do anything to automate and simplify anything so that a braindead person could do it.
One of the best packagers/engineers I ever met in my life self proclaims himself to be lazy, and says it is the reason why he strives to automated everything he can. I admire him for that. ;) LOL
One of the best packagers/engineers I ever met in my life self proclaims himself to be lazy, and says it is the reason why he strives to automated everything he can. I admire him for that. ;) LOL
Posted by:
Grenex
16 years ago
Posted by:
anonymous_9363
16 years ago
ORIGINAL: GrenexWanna buy my prepare-MSI-for-GPO-deployment script? Drop an MSI-containing folder on to it, go get coffee while it creates the permissioning group, creates the GPO, creates the links to the GPO, sets all the delegation, removes 'Authorised Users' from the scope and finally creates the advertising script. You never met anyone lazier than me. LOEL
The way I see it, the best packager is a lazy SOB who will do anything to automate and simplify anything so that a braindead person could do it.
Posted by:
Grenex
16 years ago
Posted by:
jmcfadyen
16 years ago
Posted by:
nheim
16 years ago
Hi Kevin,
on the one or two occasions, when i needed pskill during an install, i included it as binary stream into the package an called it from there.
Since it is a quite small utility, this seemed a insignificant grow of the package.
Another thing: Since SMS runs under a particular user, which is you have access to during an SMS session, why can't you populate those HKCU keys then?
A different story will be the first use from a regular profile. This could be solved with self healing through an advertised shortcut.
Regards, Nick
on the one or two occasions, when i needed pskill during an install, i included it as binary stream into the package an called it from there.
Since it is a quite small utility, this seemed a insignificant grow of the package.
Another thing: Since SMS runs under a particular user, which is you have access to during an SMS session, why can't you populate those HKCU keys then?
A different story will be the first use from a regular profile. This could be solved with self healing through an advertised shortcut.
Regards, Nick
Posted by:
Grenex
16 years ago
Nheim:
The point to be made is "Order of operations"
lets assume that I want to use PSKILL to close all open instances of excel.exe before my package does ANYTHING (uninstall, reinstall, install, etc).
I am OK with attaching the PSKILL.exe as a binary to the MSI package, but the issue is that I need to pre-populate the EULA keys for the SMS account (or any other account running the package). Obviously I can create a VBscript custom action to create the key, and follow it with a custom action with the binary attachment to run PSKILL.exe I was trying to avoid all of that if possible.
My "Ideal" end state goal is to prepoulate the PCs with the PSKILL.exe file (which i can do with my new core build) and just have the logic in my package template ready to go. Set the name of the app to kill via a standard property. If the property is set to a default value, it does nothing. When I set it to the name of an app, it kills it.
Just trying to streamline the process for the new environment without a LOT of overhead to think about in every package.
The point to be made is "Order of operations"
lets assume that I want to use PSKILL to close all open instances of excel.exe before my package does ANYTHING (uninstall, reinstall, install, etc).
I am OK with attaching the PSKILL.exe as a binary to the MSI package, but the issue is that I need to pre-populate the EULA keys for the SMS account (or any other account running the package). Obviously I can create a VBscript custom action to create the key, and follow it with a custom action with the binary attachment to run PSKILL.exe I was trying to avoid all of that if possible.
My "Ideal" end state goal is to prepoulate the PCs with the PSKILL.exe file (which i can do with my new core build) and just have the logic in my package template ready to go. Set the name of the app to kill via a standard property. If the property is set to a default value, it does nothing. When I set it to the name of an app, it kills it.
Just trying to streamline the process for the new environment without a LOT of overhead to think about in every package.
Posted by:
Shafeek CP
11 years ago
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.