Winbatch and session 0 on Windows 7

[siocnarf]

Hi,

Sometimes, we need deploying softwares and the package would not be totally automate. The problem might be software activation or button press. Are they any good practices to run those scripts with SCCM 2012 R2 silently and hidden. SCCM will run those packages under session 0.

I believe no MouseMove, sendkeys.

Thanks,

François

[td]

Under session 0 isolation can't see how there could be  a way to run scripts that would automation UI elements since they are not connected to an interactive desktop.

[ChuckC]

AFAIK, though, the Control Manager extender still functions properly in session #0, even though the other "simulated input" methods that rely on an interactive desktop [e.g. SendKey*(), Mouse*()] are non-functional.

[td]

AFAIK, though, the Control Manager extender still functions properly in session #0, even though the other "simulated input" methods that rely on an interactive desktop [e.g. SendKey*(), Mouse*()] are non-functional.

You are correct.  I realized that  after my original response but hadn't had the chance to post a new response yet.

If the install UI used regular user and common controls, the Control Manager extender should be able to interact with the install's UI.  However, the use of those control types is not as 'common' as it once was.   This seems to be particularly true of installation programs.  It could also be a bit tricky identifying the controls on the fly, if they change some of the underlying properties Control Manager relies on on a per run basis.   The other issue would be the session 0 UI detection service that Windows may or may not be running.   

There are few ways to create and/or switch to and view  a session 0 window station/desktop.  One of those techniques might be a useful way to test and debug a script running in session 0.

[td]

Should have mentioned that the UI Detection service only runs for 32-bit session 0 processes.

[td]

Some of the WIL Win* functions like 'WinClose' should also work in session 0.

[siocnarf]

Hi,

Thanks a lot!

But, Is it something existing explaining what is working and how running it?

Thanks,

[siocnarf]

If the install UI used regular user and common controls, the Control Manager extender should be able to interact with the install's UI.  However, the use of those control types is not as 'common' as it once was.   This seems to be particularly true of installation programs.  It could also be a bit tricky identifying the controls on the fly, if they change some of the underlying properties Control Manager relies on on a per run basis.   The other issue would be the session 0 UI detection service that Windows may or may not be running.   

There are few ways to create and/or switch to and view  a session 0 window station/desktop.  One of those techniques might be a useful way to test and debug a script running in session 0.

What do you mean with "the use of those control types is not as 'common' as it once was. "?

[td]

Many application user interfaces do not use Windows User and Common controls directly. They either subclass the controls or create their own from a generic window.   This is mostly because of changes in development environments and strategies.  Many development environments have there own windows that serve the same purpose as user and common controls.  For example, dotNet's WPF that uses DirectX for rendering  or the browser I am using to type this that uses an XML based system for describing and displaying windows. Other examples include Java based applications and  Windows Runtime applications.

The Control Manager Extender only works with Windows User and Common controls for the most part.

[siocnarf]

Hi,

Does Winbatch since useable for automate software installation when need?

Thanks,

[ChuckC]

I think that the most accurate and meaningful answer to that is question is, "your mileage may vary".

As Tony explained, the suitability of WinBatch as a software automation tool that drives the UI for a software installation package depends entirely on whether or not any given software installer uses controls [e.g. the Windows "Common Controls"] that can be interrogated & manipulated by the Control Manager extender.  If the installer does this, then,  yes, WinBatch can most likely be used to successfully automate the installer.  Conversely, if the software installation package doesn't do this, then WinBatch is less likely to to be able to automate the installer.

Another thing to look at is whether or not the installation package supports using some kind of an "answer file" or some other kind of input file or set of command line switches that causes it to perform the installation w/o requiring interactive input from a user.

Since you haven't provided any real world examples of a particular software installation that you'd like to automate, it's very difficult to provide a more specific & detailed answer to your question.

[td]

It is also important to remember that WinBatch provides many ways to automate UI applications.  In most cases, you can use one or more of these technologies for any given application.  In this case, specifically an application running in session 0, the available technologies are limited because of the restrictions imposed by the OS.

[siocnarf]

Hi,

I was using Winbatch while using Windows XP. I had exactly the same problems. Sometimes Winbatch was detecting the Windows or not. Winbatch is not "the solution", it is part of a toolbox. Usually, we will try running the installation from Commandline. Sometimes, the software might need a web activation then Winbatch might be good to do that job.

Sometimes the software will not install from a commandline then I would prefer trying an installation with Winbatch before trying a snapshot. Since Windows XP, there was an evaluation. Now the installation is ran Under the system account and we might expect a different behavior. My preoccupation was "will an automation ran Under the system account being working if it was working during the Scripting (manually)".

While running with SCCM the session might be close or lock, then it is another preoccupation.

My Partner spole me about AutoIt but I am familiar with Winbatch not AutoIT. Also, I believe AutoIT would not run Under lock session or logoff.

So your answer, seems to be, Winbatch will do the job if the manufacturer's software installation was done to use the correct control.

Thanks,

François

[td]

You could also consider using WinBatch CLR hosting and the dotNet UI Automation classes.  There are one or two examples in the Tech Database.  Like the Control Manager Extender, these classes do not work for all windows but some windows can be automated with these classes that cannot be automated with Control Manger.  The reverse is also true.

The classes are also  a real challenge to work with and usually require the use of the inspect.exe tool to discover the window information you need to use the classes.  I only bring this up to point out that there are alternatives available.  I guess it is mostly a question of how desperate you are to find a solution and how much time and patience you have to develop that solution when Control Manger is not up to the task in session 0.

Also remember that running as system and session 0 isolation impose different limitations on what you can do.  They are not synonymous.