DUA will not install MSI files

[David Harris]

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]

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

 

[Jon Fincher]

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.

 

[David Harris]

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

 

[KM]

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-us/xpehelp/html/wesamEXECUTE.asp

KM

 

[David Harris]

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

 

[KM]

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

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:

administrator user?

If you read a few threads from
http://groups.google.com/groups?hl=...a=group=microsoft.public.windowsxp.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 Harris]

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.

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

 

[KM]

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

Again, should be machine\Administrator.

KM

 

[David Harris]

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


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

 

[KM]

David,

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.

Something is missing from your image.
A couple of things for you to try (if you still want to fix it which may not
be the case since you got working solution ).
- set more intuitive machine name in your configuration at least for the
testing purpose (a PC component settings in TD).
- try net.exe use command to test the Admin account authentication.
- try to use sc.exe config on another service (change its account
settings) and see if it works. Then you will know if it is sc.exe problem or
the service problem only.
- when sc.exe config is failing, anything is the
system/application/security log appears?
- use Regmon/Filemon to see if anything is missing.

KM