Does AutoIt have a workaround/solution for dealing with Win7's "Interactive Services Detection" feature?

[TXTechie]

Hello Everyone,

Does anyone know whether or not AutoIt (a built-in function or a UDF) has a workaround or solution for dealing with Windows 7's Interactive Services Detection feature?

For non-silent deployment packages (those that show some level of User Interface - UI) on Windows 7 (or Vista) how do you display a dialog box, progress bar, message, etc. to the user (Session 1) when deploying a software package that is being deployed by a software deployment solution that utilizes the Local System (SYSTEM) account (Session 0)?

Regards,

TX Techie

[orbs]

 

Does anyone know whether or not AutoIt (a built-in function or a UDF) has a workaround or solution for dealing with Windows 7's Interactive Services Detection feature?

 

if you mean "how to avoid or acknowledge the ISD notification?" then no. AutoIt can not do it, and neither can any other program. it is also a very bad idea, because if someone can do it, then security threats can do it too.

how to override it? that's a different story, it requires a tailor-made solution for the package you are trying to deploy. but basically, mass deployment should be used for silent packages. interactive packages should be installed individually. for example, you can follow the AutoIt tutorial on installing WinZip, create a script for your package, and make it launch in session 1, running as a user with admin rights.

 

 

For non-silent deployment packages (those that show some level of User Interface - UI) on Windows 7 (or Vista) how do you display a dialog box, progress bar, message, etc. to the user (Session 1) when deploying a software package that is being deployed by a software deployment solution that utilizes the Local System (SYSTEM) account (Session 0)?

 

that is the default behavior. if it does not happen, even when the ISD service startup mode is "Automatic", then you have a system issue that will probably not be solved by AutoIt.

[TXTechie]

Let me try to clarify what I want to do. Yes, most of our software deployments are completely silent to the user, but sometimes we want to let the user know something before beginning the installation or at the end of the installation.

For instance, when installing one ore more Office-related applications, we display a dialog box instructing the user to close all Office applications so that the installation is successful and doesn't error out because one or more of the Office applications are running. Another example is to display a dialog box instructing the user to save all open files and then to close all open applications because the software package will automatically force a reboot of the PC at the end (as it is required) - this is only true for a few critical software deployments.

Of course, this wasn't a problem with Windows XP, but starting with Windows Vista the Interactive Services Detection feature will not allow us to do this - at least not with any amount of certainty that the user will actually see the dialog box of instructions, since the user may never see the button flashing on the taskbar. So, I was hoping that AutoIt (either natively or via the UDF's from the community) has provided a way to display a dialog box (or something similar) to the user (Session 1) while the main script is running as Local System (Session 0). Allowing the same functionality as WinXP and previous versions of Windows, without "breaking" the Interactive Services Detection feature. That's why I called it more of a workaround.

Am I making sense?

 

[Tripredacus]

I would recommend you implement a different way to run your programs without having to work around the security feature of Session 0 Isolation. You can read these two and see if you can come up with a way to do it with AutoIT.

http://stackoverflow.com/questions/2464182/windows-2008-renderfarm-service-createprocessasuser-session-0-isolation-and-o

http://stackoverflow.com/questions/5540155/bypassing-session-0-isolation-in-windows-server-2008-successful-but-still-no

[orbs]

you have 2 options:

1) formally:

users do not care about your installations, they don't want to know, and you should not force their attention (that's a sure way to get nagged by users with idiotic questions).

so what to do? simple: force the deployment overnight, and enforce a policy (either technical or formal) that everyone must log-off at end of day. if someone does not and they lose their work, that's their problem. i don't want to be brute, but that's how it is, and eventually this is for their own good. in addition, that way your package is free to reboot the pc if needed.

if you want to be on the safe side, send an email at noon to everyone, inform them there is a major installation scheduled for tonight, and they better log-off if they value their work.

2) technically:

have an agent running in the user session 1. that agent can be informed by the deployment tool (by flag monitoring, if all else fails), and that agent is able to interact with the user. you can even use the built-in Messenger service for that, although very not elegant (not to be confused with any internet-based Microsoft Messenger service for instant messaging or the Windows Messenger and Windows Live Messenger).

in my workplace both methods are implemented, but only one of them is actually used - you can guess which...

[AdamUL]

If you would like to send a message to all users on the local system during an installation, have a look at MSG.exe.  Here is an example.

RunWait('msg.exe * /TIME:60 /V /W "This computer, %COMPUTERNAME%, is going to log off. Please save your work and then close this dialog"', @SystemDir, @SW_HIDE)
Run("logoff 1 & logoff 2 & logoff 3", @SystemDir, @SW_HIDE)

I have used this on quite a few deployments to log users off.  

 

If I need to reboot or shutdown, and inform the user with SHUTDOWN.exe.  Here is an example.

Run('shutdown -r -f -t 60 -c "This computer, %COMPUTERNAME%, is going reboot in 60 seconds. Please save your work."', @SystemDir, @SW_HIDE)

[TXTechie]

Thank you, AdamUL. The msg.exe command/tool is, indeed, a useful workaround. Also, I'm a bit ashamed that in my ~ 20 years experience of technical support and systems management roles, that I was unaware of the msg.exe command/tool, which is built-in to Windows. 

However, I was hoping for more of an internal RunAsUser function (most preferred) or some external DLL or EXE that could be called to perform this function. This would allow for a custom message of my choosing along with the ability to receive input back from the user. Also, since this is now no longer a silent install, I would then prefer to then display a progress bar of the progress of the installation to the user - so that they would know roughly how long until the PC will be rebooted, etc. I already utilize the shutdown.exe message capability, but I'm looking for a more robust way to communicate (two-way) with the user - especially at the beginning of the deployment (as I've just described above). Thank you, again, for your suggestion.

 

orbs - In our environment, we have at least a couple of reasons why we cannot fully implement your formal suggestions... 1) most of our locations are or include manufacturing labs that work around the clock in 3 shifts, and 2) roughly 1/2 of our user community uses Laptops which they take home with them after their work hours.

Are there any chances that someone within the community (with more development knowledge and skill than I currently have) might be willing to develop (or help me to develop) a RunAsUser function using AutoIt - or some other tool?

[BrewManNH]

Did you look at RunAs?

[TXTechie]

Hi BrewManNH,

Unless I'm missing something in the AutoIt Help for the RunAs/RunAsWait functions, I don't see how these can help me as I need a generic solution for any and all software deployments that won't require me to know and have the username and password of all users in my environment. Am I missing something?

[BrewManNH]

Hi BrewManNH,

Unless I'm missing something in the AutoIt Help for the RunAs/RunAsWait functions, I don't see how these can help me as I need a generic solution for any and all software deployments that won't require me to know and have the username and password of all users in my environment. Am I missing something?

I'm missing what it is you're requesting. Without another users username and password, exactly how do you intend to run something as another user?

[TXTechie]

BrewManNH,

Check out the link that I initially shared on the Interactive Services Detection feature. Really, I'm looking for more of a RunAsUserSession - since I want to execute something (GUI, install, etc.) in the user's session 1 rather than in the running process' session 0 (since my and most software deployment solutions use the SYSTEM account).

Edited July 10, 2013 by TXTechie

[orbs]

if i understand you correctly, you want the installer to RunAs a user that have admin rights on the target, and being able to interact with session 1 because it is actually running in session 1.

you have 2 problems with that:

1) how would you launch it? a remote call can launch anything, but limited to its caller context - session 0 if it's a service, caller session otherwise, but never the locally-logged-on user session.

2) even if you overcome that, UAC will show it's ugly head and put a stick in your wheel.

i think your solution would be something along my 2nd suggestion:

have an agent running in the user session 1. that agent can be informed by the deployment tool (by flag monitoring, if all else fails), and that agent is able to interact with the user.

[TXTechie]

Hi orbs,

You may be correct, and I'm not enough of a developer to come up with a solution for your 2nd suggestion (another agent).

In talking with someone else within the Systems Management discipline at another company, he says he has no problem using AutoIt or other deployment mechanisms that do display dialog boxes to interact with users on Win7 using SCCM and he thinks Altiris. So, what I may need to do is contact my software deployment product company (CA) to see if they have a solution for the  Interactive Services Detection feature.

I want to thank everyone for their input and feedback!

[orbs]

yes, Altiris is using an agent running in the user context. that agent is far more powerful than just user interaction, it also collects workstation status info, and allows authorized users to manually launch backup/restore/deployment operations from their session.

naturally, a vendor-supported agent is best, but it is also very not complicated to write such an agent with AutoIt.

[Decipher]

TxTechie,

You may have to FileInstall a seperately compiled script but you should be able to create a process on the default windows station which is user interactive. I don't know about the security/detection thats being mentioned but procesess inherit privileges from their parent process and the Window StationDesktop their created on unless you use WinAPI_CreateProcess to specify the desktop to be used during process creation. What I'm getting at is that you should be able to spawn a child process on the default desktop("Winsta0default") even if your service is running on a non-interactive window station like most services do. I'll post example usage later on just incase you'd like to put the theory to the test.

Anonymous

[TXTechie]

Hi Decipher,

I would greatly appreciate any insight you have. Based on several years (and versions) of working with CA and their solution, I don't have much confidence that they will provide me with a solution to this issue. So, I would certainly be interested in being able to control this on my own, apart from the CA agents.

[Decipher]

Try running this from your service:

#Include <APIConstants.au3>
#Include <WinAPIEx.au3>

Dim $hPrevStation = _WinAPI_GetProcessWindowStation()
Dim $hStation = _WinAPI_OpenWindowStation("WinSta0",  $WINSTA_ALL_ACCESS)
If _WinAPI_SetProcessWindowStation($hStation) Then
    ConsoleWrite("Current Window Station is WinSta0!" & @CRLF)
EndIf
Dim $pText = _WinAPI_CreateString('default')
Dim $tProcess = DllStructCreate($tagPROCESS_INFORMATION)
Dim $tStartup = DllStructCreate($tagSTARTUPINFO)
DllStructSetData($tStartup, 'Size', DllStructGetSize($tStartup))
DllStructSetData($tStartup, 'Desktop', $pText)
If _WinAPI_CreateProcess('', @SystemDir & '\calc.exe', 0, 0, 0, $CREATE_NEW_PROCESS_GROUP, 0, 0, DllStructGetPtr($tStartup), DllStructGetPtr($tProcess)) Then
    ProcessWaitClose(DllStructGetData($tProcess, 'ProcessID'))
EndIf
_WinAPI_FreeMemory($pText)
If _WinAPI_SetProcessWindowStation($hPrevStation) Then
    ConsoleWrite("Original Window Station restored!" & @CRLF)
EndIf

The process should show its GUI.

Anonymous

Edited July 19, 2013 by Decipher