/build/static/layout/Breadcrumb_cap_w.png

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)

Posted by: anonymous_9363 16 years ago
Red Belt
0
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
Posted by: Grenex 16 years ago
Senior Yellow Belt
0
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.
Posted by: anonymous_9363 16 years ago
Red Belt
0
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
Red Belt
0
Process Monitor has the /AcceptEula switch so see if PsKill has a similar one.
I guess the help-file should provide this info for you.
Posted by: anonymous_9363 16 years ago
Red Belt
0
It doesn't... :) Or should that be :( ?
Posted by: anonymous_9363 16 years ago
Red Belt
0
ORIGINAL: Grenex
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.
Could you not add the file and the reg data to your package template(s)?
Posted by: Grenex 16 years ago
Senior Yellow Belt
0
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. [:(]
Posted by: anonymous_9363 16 years ago
Red Belt
0
ORIGINAL: Grenex
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.
Come on! You have to be kidding! :) Any packager worth having is going to be completely at home with scripts.
Posted by: Grenex 16 years ago
Senior Yellow Belt
0
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
Posted by: Grenex 16 years ago
Senior Yellow Belt
0
BTW: Yes, we could add it to our template, but where is the fun in that!? ;)
Posted by: anonymous_9363 16 years ago
Red Belt
0
ORIGINAL: Grenex
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.
Wanna 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
Posted by: Grenex 16 years ago
Senior Yellow Belt
0
If I was using GPOs to deploy, I would.
I am using SMS, and one of my guys is writing a script to automate package setup with a single click script.

Ahhh...lazy are we! LOL

Everyone enjoy the holiday weekend!
Posted by: jmcfadyen 16 years ago
5th Degree Black Belt
0
seeing we are all selling scripts you could buy my sms one then :-)

I might throw some of it up on the blog shortly actually. automating SMS collections advertisements etc.
Posted by: nheim 16 years ago
10th Degree Black Belt
0
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
Posted by: Grenex 16 years ago
Senior Yellow Belt
0
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.
Posted by: Shafeek CP 11 years ago
White Belt
0

copy the below into a notepad and save as .reg file then run it first before you run the package.

[HKEY_CURRENT_USER\Software\Sysinternals\PsKill]

"EulaAccepted"=dword:00000001

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ