I think I follow what you are saying.  If I do, we ran across this same scenario and initially we had problems too.  I removed the "specific user" option and just let it install with the default (local system account) option and this worked for us.  What I found that was weird was the fact that we had several install that would not install on an XP computer unless we provided credentials but yet they installed just fine in 7 without specific credentials.  Strange but it worked.   Hope I didn't misunderstand the question. 

We are using 6.9 SP3.

We build computers the same way, making it run directly from the share, although we always use the Run script with the command line to open setup file silently.  Everything installs without any problem and the same job works for our XP builds.  We do use the Run As specific user with a domain acount as well.

What version of the DS are you using? SP?

We are using DS 6.9 SP4.

So here's a new twist.... If i use 7.1 to push out the app, all the dialogs show up and it installs with no probs running the install dirctly from a network share. But in DS 6.9 (on SP5 now), it still installs, but no dialogs. My team wants the dialogs.

Any thoughts on the difference?

Are these machines on the domain when you deploy the sw? We had an issue where the Win7 machines would not join the domain. And the SW jobs does not run because of that(But the status in the conosle is complete and succesful).

The jobs run successfully, just silent. The dialog boxes are suppressed whether you want them to be or not UNLESS you are running the install while logged in as the same account that is being used in the distribute software job. Since we use an elevated AD service account for this, no should ever be logged in with that account.

Trying to figure out the difference in installation context that 7.1 uses as compared to DS 6.9. That appears to be the key between XP and Windows 7.

I think I'll bring support into this.

You may need to change how the job or script is running.

In the Client Run Environment, it defaults to "Default (local system account)".  You may need to change this to "run script in console user session".  This may cause a problem if the machine is not logged in though in Win7.

When you run script in console user session, what rights does it run the installation under, the user's or the system account?

The logged on user's account.  I'm pretty sure in Win7, that's the only way you'll be able to display it in the console user session though.

The user wont have admin rights on their machine (by design).

So why does it work as a 7.1 task?

In DS 6.x, (when running through the Win32 console) you can execute jobs as the system account, as a specified user, or in the current user session. the ONLY two that use different rights are the first two... the third runs AS the user account that is logged in (and the job will fail if no one is logged in). The first two option will use the DS service account (or other specified) and will hide the dialogs due to Window's Session Isolation (a part of UAC - which can't be turned off). Essentially, if you execute a remote "Run As" on Windows 7 (and Vista), you don't see the result unless you are actually logged on to the system as that account. This is by design. If you execute as Run As while logged on (a UAC elevation process), then you get to see the dialogs/application/etc.

In DS 7.x, from what I can tell, it operates as an expansion to the old "Software Delivery Solution" and "DSWeb" approach from NS6. Instead of the server sending/executing the installation on the client computer (like DS 6.9), the new DS 7.x actually sends the job as a "package" to the client. The agent that is then on the computer initiates the "Run As" in the user session, using the DS service account logon (or other specified). This then allows the execution to be elevated, but still visible.

As an example, if you were to send a "Run Script" in DS 6.x to the client computer, in the user console session, and had that script perform a RUNAS to the application (using appropriate credentials), then you could effectively replicate the DS 7.x approach (from how I understand it). Unfortunately, RUNAS doesn't support providing a password in the command (because that is insecure), however you can use a VBScript to perform the RunAs command (via objWshShell.Run) and have it use a special "SendKeys" command to make it work. I've done this before ;)