Has anyone been able to get a DUA script to execute msiexec and use it to
install an MSI file.
The current command I am using is ...

EXECUTEPROCESS,,,,msiexec.exe,,msiexec.exe /qn /fa
C:\DUATemp\Update.msi,DAYES,60000,,DASEC_REV,,,,DASEC_REV,,,,,,c:\windows\system
32,1,,WinSta0\Default

When DUA runs the script containing the command, msiexec displays a dialog on
the embedded device saying 'Incorrect command line parameters'. However if I
run the same command from a command prompt on the device it works successfully.

To try to work around the problem I setup a batch file to execute the command.
However although DUA executes the batch file msiexec does nothing.

Can anyone tell me what I am doing wrong here?

David

"David Harris" <dh_at_daharris_com.NoSpAm> wrote in message
news:(E-Mail Removed)...
> Has anyone been able to get a DUA script to execute msiexec and use it to
> install an MSI file.
> The current command I am using is ...
>
> EXECUTEPROCESS,,,,msiexec.exe,,msiexec.exe /qn /fa
>
C:\DUATemp\Update.msi,DAYES,60000,,DASEC_REV,,,,DASEC_REV,,,,,,c:\windows\sy
stem
> 32,1,,WinSta0\Default
>
> When DUA runs the script containing the command, msiexec displays a dialog
on
> the embedded device saying 'Incorrect command line parameters'. However
if I
> run the same command from a command prompt on the device it works
successfully.
>
> To try to work around the problem I setup a batch file to execute the
command.
> However although DUA executes the batch file msiexec does nothing.
>
> Can anyone tell me what I am doing wrong here?

UPDATE
-----------
If I change the DUA command to ...

EXECUTEPROCESS,,,,msiexec.exe,,/qn /fa
C:\DUATemp\Update.msi,DAYES,60000,,DASEC_REV,,,,DASEC_REV,,,,,,c:\windows\sy
stem32,1,,WinSta0\Default

DUA does not return an error code and continues to execute subsequent
commands, msiexec does not show the error dialog, but the install of the msi
file does not occur.

If I then create a batch file (c:\windows32\xxx.bat) containing the commands
....

c:
cd \windows\system32
msiexec.exe /qn /fa C:\DUATemp\Update.msi
echo %1 %2 %3 > c:\xxx.log

And change the DUA command to ...

EXECUTEPROCESS,,,,xxx.bat,,/qn /fa
C:\DUATemp\Update.msi,DAYES,60000,,DASEC_REV,,,,DASEC_REV,,,,,,c:\windows\sy
stem32,1,,WinSta0\Default

I can verify that the batch file is being run because the file 'c:\xxx.log'
is created containing the correct command line parameters. But the msiexec
command seems to exit without doing anything. If I run the xxx.bat file at
a command prompt, msiexec works correctly and installs the update.

Any ideas why
David

"David Harris" <dh_@_daharris_com.NoSpAm> wrote in
news:cbaqo8$bcl$1$(E-Mail Removed):

>
> "David Harris" <dh_at_daharris_com.NoSpAm> wrote in message
> news:(E-Mail Removed)...
>> Has anyone been able to get a DUA script to execute msiexec and use
>> it to install an MSI file.

Two things to look at here, David.

First, what account is DUA client running under? If you're logged in as
Administrator and DUA is running under Local System, that may cause an
issue.

Second, try adding a /l*v argument to the msiexec command line. This
will generate a verbose Windows Installer log in %temp% that will give
you more info about why the update is failing through DUA.

--
--Jon, MS

This posting is provided "AS IS" with no warranties, and confers no
rights.

"Jon Fincher" <(E-Mail Removed)> wrote in message
news:Xns9512B3CF3E6E4jonfionlinemicrosoft@157.54.3.22...
> "David Harris" <dh_@_daharris_com.NoSpAm> wrote in
> news:cbaqo8$bcl$1$(E-Mail Removed):
>
> >
> > "David Harris" <dh_at_daharris_com.NoSpAm> wrote in message
> > news:(E-Mail Removed)...
> >> Has anyone been able to get a DUA script to execute msiexec and use
> >> it to install an MSI file.
>
> Two things to look at here, David.
>
> First, what account is DUA client running under? If you're logged in as
> Administrator and DUA is running under Local System, that may cause an
> issue.
>
> Second, try adding a /l*v argument to the msiexec command line. This
> will generate a verbose Windows Installer log in %temp% that will give
> you more info about why the update is failing through DUA.
>
> --
> --Jon, MS
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.


The image is constructed using WinLogon.
The image is very restricted at present and I cannot use system error log
entries to try and determine what is wrong.
DUA will only run when configured to run as 'Local System', and not when
configured as 'Administrator'.
Have already added the '/l*v c:\xxx.log' options to msiexec command line. This
produces a log when msiexec is run manually but not when it is run by the DUA
service. I can confirm that the batch file is run by DUA and that the batch
file is executing the correct msiexec command line. However msiexec immediately
exits and no log is produced at all.
Running the batch file manually (at a command prompt) causes msiexec to run
correctly.

David

David,

> The image is constructed using WinLogon.
> The image is very restricted at present and I cannot use system error log
> entries to try and determine what is wrong.

Why not? You can copy over the %SystemRoot%\system32\config\SysEvent.Evt
file from the image and analyze it offline (just load into Event Viewr on an
XP Pro machine).

> DUA will only run when configured to run as 'Local System', and not when
> configured as 'Administrator'.

Isn't that what Jon pointed out?

Have you tried using EXECUTE command instead of EXECUTEPROCESS? Then you can
run it in the security context of the specified credentials. Just use
UserName, Password, Domain options.
http://msdn.microsoft.com/library/en...samEXECUTE.asp

KM

> Have already added the '/l*v c:\xxx.log' options to msiexec command line.
This
> produces a log when msiexec is run manually but not when it is run by the
DUA
> service. I can confirm that the batch file is run by DUA and that the
batch
> file is executing the correct msiexec command line. However msiexec
immediately
> exits and no log is produced at all.
> Running the batch file manually (at a command prompt) causes msiexec to
run
> correctly.
>
> David

Status Report
---------------
I have now got the batch file reliably executing msiexec under DUA and
producing a log (there was one mis-typed char in the DUA script). Examining
the logs produced for a DUA-based install and a manual install I found that
it is a privilege level issue that is causing the problems. DUA is running
the batch file as 'Default User' instead of as
'administrator' and because of this msiexec cannot access & update the
registry properly.

So there are two possible solutions, make DUA run as 'administrator' instead
of 'Local System', or use EXECUTE as suggested by KM.

Manually changing the service settings in the deployed image (that has extra
debug components added) so that DUA runs as the administrator user solves
the problem and msiexec works correctly under DUA. However as Internet
Explorer is not in the release image that option is not available to me
(services.exe complains and exits without allowing you to do anything) so I
have to define the administrator password (this is not blank due to security
considerations) in the DUA component before the image is built. After
trying out all the relevant settings I could find I was still not able to
get DUA to run out-of-the-box as the administrator user.
Therefore I tried to add an EXECUTE command to my DUA script. Using the
sample provided in the documentation and feeding in my parameters ...

EXECUTE,,DANO,,c:\windows\system32\cmd.exe,,c:\windows\system32\cmd.exe /k
set,,,,administrator,,,,****,,,,c:\windows\system32,1,,WinSta0\Default

(Domain is blank as the machine does not use windows networking)
Running the DUA script containing the above command places the following
entry in
the Application event log ....

DUAgent Service - Error Executing Command
CreateProcessWithLogonW. The specified service does not exist as in
installed service.

I have tried variation on the EXECUTE command in case there was a typo in
the documentation but the same error occurs whatever I do.

Questions:
-----------
Has anyone been able to set a password in the DUA component definition that
allows DUA to work out-of-the-box in the deployed image as the administrator
user?
What is wrong with the EXECUTE command listed above?

David

David,

> Manually changing the service settings in the deployed image (that has
extra
> debug components added) so that DUA runs as the administrator user solves
> the problem and msiexec works correctly under DUA. However as Internet
> Explorer is not in the release image that option is not available to me
> (services.exe complains and exits without allowing you to do anything) so
I
> have to define the administrator password (this is not blank due to
security
> considerations) in the DUA component before the image is built.

Not sure I understood this part (services.exe does not work on your
runtime?? why IE mentioned here?).

Why you just don't set Administrator option in he DUA component settings? Or
you're saying that if yo set the option, DUA still runs as "Default User"?
This is weird then. I'd check out if DUA gets installed properly (FBA log,
system log).

Anyway.. to automate service config at run time you can always use sc.exe
tool from NT Resource Kit.
If you want to change the account the service runs under, use a command like
"sc.exe <ServiceName> config obj=<AccoutName> password=<AccountPassword>".

> Therefore I tried to add an EXECUTE command to my DUA script. Using the
> sample provided in the documentation and feeding in my parameters ...
>
> EXECUTE,,DANO,,c:\windows\system32\cmd.exe,,c:\windows\system32\cmd.exe /k
> set,,,,administrator,,,,****,,,,c:\windows\system32,1,,WinSta0\Default

Have you tried using DALOGONWITHPROFILE option (next to password) ?

> (Domain is blank as the machine does not use windows networking)
> Running the DUA script containing the above command places the following
> entry in
> the Application event log ....
>
> DUAgent Service - Error Executing Command
> CreateProcessWithLogonW. The specified service does not exist as in
installed service.

If not above, then it may be a non DUA problem.
Are you able to use "runas" command to run you msiexec manually as a
different user?
If not, you may probably dig into that and see why it does not work.

> I have tried variation on the EXECUTE command in case there was a typo in
> the documentation but the same error occurs whatever I do.
>
> Questions:
> -----------
> Has anyone been able to set a password in the DUA component definition
that
> allows DUA to work out-of-the-box in the deployed image as the
administrator user?

If you read a few threads from
http://groups.google.com/groups?hl=e...sxp.embedded.*
you will notice that EXECUTE/Administrator has been mentioned and used.

> What is wrong with the EXECUTE command listed above?

See comments above.

> David

> Not sure I understood this part (services.exe does not work on your
> runtime?? why IE mentioned here?).

The customer has specified that Internet Explorer must not be in the build
and the Control Panel\Administrative Tools\Services UI will not work without
it.

> Why you just don't set Administrator option in he DUA component settings?
Or
> you're saying that if yo set the option, DUA still runs as "Default User"?
> This is weird then. I'd check out if DUA gets installed properly (FBA log,
> system log).

Setting the DUA component to start services as administrator causes the
service to be registered to run as the .\Administrator user but not to start
in the deployed image. There are no problems reported in any logs except to
indicate that the DUA service could not start.

> Anyway.. to automate service config at run time you can always use sc.exe
> tool from NT Resource Kit.
> If you want to change the account the service runs under, use a command
like
> "sc.exe <ServiceName> config obj=<AccoutName> password=<AccountPassword>".

Sorry, forgot about the existence of sc (been working 24/7 lately).
Running 'sc start duagent' says The service did not start due to a logon
failure. This is obviously because no password is specified for that user
in the DUA component definition. Looking thru the properties for the DUA
component shows that there are several places where a password could be
specified (in advanced properties and service properties). Putting the
correct password into any/all of those locations still does not allow DUA to
run as the administrator user.

In the build running 'sc config duagent obj= .\Administrator password=
*****' returns success. However running 'sc start duagent' afterwards still
says The service did not start due to a logon failure. The same thing
occurs when it is run after a reboot.
If I use the Services UI to set the password (in a debug build that has IE
in it) then DUA will start running as the administrator user. Running 'sc
config' to change the service password after that has been done correctly
allows the password to be changed and the DUA service will start if the
password supplied by sc is correct and not if it is incorrect. If I then
delete the DUA service and re-create it using sc (providing the
administrator account settings) it is possible to successfully
start/stop/configure the service using sc. However doing the same thing
before using the Services UI to set the password does not allow DUA to run
with administrator privileges. This seems to indicate that the Services UI
adds some persistent data to the system that is not lost when the DUA
service is deleted. This is inherited by the new DUA service created by sc
allowing it to run without problems.

> > EXECUTE,,DANO,,c:\windows\system32\cmd.exe,,c:\windows\system32\cmd.exe
/k
> > set,,,,administrator,,,,****,,,,c:\windows\system32,1,,WinSta0\Default
> Have you tried using DALOGONWITHPROFILE option (next to password) ?

Yes. The command is still not executed and the logs show the same error.

> Are you able to use "runas" command to run you msiexec manually as a
> different user?

Added 'runas' to the image and executed 'runas /env
/user:.mymachine\administrator cmd' as per help. This gave me the clue as
to how the DUA execute command should be structured. Using the DUA command
.....

EXECUTE,,DANO,,c:\windows\system32\cmd.exe,,c:\windows\system32\cmd.exe /k
set,,,,administrator,,mymachine,,****,,,,c:\windows\system32,1,,WinSta0\Defa
ult

Caused the command prompt to appear as per the runas utility. So rebuilt
image with no debug components and re-ran DUA as 'LocalSystem'. Unchanged
DUA script would not cause command prompt to appear. Added 'runas'
component to image. DUA script executed correctly causing the command
prompt to appear with the correct user privileges.

!!!! VICTORY !!!! DUA now runs my batch scripts with administrator
privileges.


LESSONS LEARNED
------------------------
There seems to be no way (that I can find) to get DUA to run with anything
other than with LocalSystem privileges without using the Services UI to set
it to run with .\Administrator user privileges.

To use the EXECUTE command in a DUA script you must have the 'RunAs Service'
component installed or you always get a 'Service Not Installed' error
message logged when DUA executes the command.

In the DUA script your EXECUTE command must specify 'mymachine' in the
domain field when using local user accounts.

Debugging DUA scripts in an image configuration that does not have Internet
Explorer in it is a pain in the *** .

Many thanks to all those who helped!
David

David,

First of all I am glad you fixed your problem.

> The customer has specified that Internet Explorer must not be in the build
> and the Control Panel\Administrative Tools\Services UI will not work
without it.

Ok. You must have referred to MMC console UI. This is absolutely true - it
requres IE in the build.

> Setting the DUA component to start services as administrator causes the
> service to be registered to run as the .\Administrator user but not to
start
> in the deployed image. There are no problems reported in any logs except
to
> indicate that the DUA service could not start.

Likely the password issue again.

> In the build running 'sc config duagent obj= .\Administrator password=
> *****' returns success. However running 'sc start duagent' afterwards
still
> says The service did not start due to a logon failure. The same thing
> occurs when it is run after a reboot.

Again, have you tried using "machine\Administrator" notation here?

> If I use the Services UI to set the password (in a debug build that has IE
> in it) then DUA will start running as the administrator user. Running 'sc
> config' to change the service password after that has been done correctly
> allows the password to be changed and the DUA service will start if the
> password supplied by sc is correct and not if it is incorrect. If I then
> delete the DUA service and re-create it using sc (providing the
> administrator account settings) it is possible to successfully
> start/stop/configure the service using sc. However doing the same thing
> before using the Services UI to set the password does not allow DUA to run
> with administrator privileges. This seems to indicate that the Services
UI
> adds some persistent data to the system that is not lost when the DUA
> service is deleted. This is inherited by the new DUA service created by
sc
> allowing it to run without problems.

My guess would be that Services MMC helped you create the authetication
channel for the service.
Although, I could be wrong.

But the fact is that I have never had problems with sc.exe config command.

> EXECUTE,,DANO,,c:\windows\system32\cmd.exe,,c:\windows\system32\cmd.exe /k
>
set,,,,administrator,,mymachine,,****,,,,c:\windows\system32,1,,WinSta0\Defa
ult

Yup, makes sense :-)

> LESSONS LEARNED
> ------------------------
> There seems to be no way (that I can find) to get DUA to run with anything
> other than with LocalSystem privileges without using the Services UI to
set
> it to run with .\Administrator user privileges.

Again, should be machine\Administrator.

KM

> > In the build running 'sc config duagent obj= .\Administrator password=
> > *****' returns success. However running 'sc start duagent' afterwards
> still
> > says The service did not start due to a logon failure. The same thing
> > occurs when it is run after a reboot.
>
> Again, have you tried using "machine\Administrator" notation here?


> > There seems to be no way (that I can find) to get DUA to run with
anything
> > other than with LocalSystem privileges without using the Services UI to
> set
> > it to run with .\Administrator user privileges.
>
> Again, should be machine\Administrator.

I did try to use 'machine\Administrator' notation (did not include it in
posting to cut a VERY long set of tests short). Used the full machine name
as reported by system (OEM-??????). sc returned an error message indicating
the account name or password was invalid.

David