EWF/DUA help needed

[Guest]

I am trying to update a custom shell using DUA and EWF. Here is my DUA script-

// move the file from C:\ to c:\windows\systems32, but force it to wait
until a reboot to mov
MOVEFILE,0,1,C:\DUA\JP.exe,1,c:\Windows\System32\JP.exe,DAMOVEFILE_DELAY_UNTIL_REBOOT|DAMOVEFILE_REPLACE_EXISTING

// now commit EWF and reboo
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe c: -commit,,DAYES,,administrator,,admin,,,,,,
REBOOT,,DAREBOOTOPT_REBOOT

the script compiles ok, and it runs on the target, but the system never
reboots. I have used the script successfully without the EXECUTE statement
and without EWF, and it updates the shell OK. What do I need to do to update
the shell using EWF?
thanks
kevin

 

[KM]

kevin,

Your script does not reboot becuase it most likely fails on the EXECUTE
command.

Something seems to be wrong in your command:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.e
xe c: -commit,,DAYES,,administrator,,admin,,,,,,

Look at the command syntax:
3, [ErrorMode], [RebootOK], [ExpandMode], [ApplicationName], [ExpandMode],
[CommandLine], [WaitForCompletion], [Timeout], [ExpandMode], UserName,
[ExpandMode], [Domain], [ExpandMode], Password, [LogonFlags],
[CreationFlags], [ExpandMode], [CurrentDirectory],
[1, StartupInfo] | [0], [NewEnv]

You may want to try to execute something like:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.e
xe c: -commit,DAYES,,,administrator,,YourMachineName,,admin,,,,,,

Please note all the changes made in the command string.


You may also want to include the event log in your configuration so you can
debug DUA errors.
There is also a verbose mode for logging that will write all DUA commands to
the application event log.

Under the
[HKLM\SYSTEM\CurrentControlSet\Services\XPEAgent\Parameters\Config] key add
"Logging"=dword:1 value.

Btw, it may not be good implementation of your script for the purpose of
changing running app with EWF on.
With EWF command you just commit a registry change to move/replace the
JP.exe file on next reboot. The file will be replaced each reboot until you
commit EWF again.
If it is acceptable you can issue a command to close your Shell app
[properly] (e.g., command like "JP -closeall" may close all instances of the
app), than replace the exe and commit EWF. Since you reboot then, the new
shell exe will be used. This is, of course, assuming you can change the JP
app.

KM

I am trying to update a custom shell using DUA and EWF. Here is my DUA script-

// move the file from C:\ to c:\windows\systems32, but force it to wait
until a reboot to move
MOVEFILE,0,1,C:\DUA\JP.exe,1,c:\Windows\System32\JP.exe,DAMOVEFILE_DELAY_UNT
IL_REBOOT|DAMOVEFILE_REPLACE_EXISTING

// now commit EWF and reboot

EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.e
xe c: -commit,,DAYES,,administrator,,admin,,,,,,

 

[KM]

One more time with better wrapping...

Your script does not reboot the device because it likely fails on the EXECUTE command.

Something seems to be wrong in your command:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe c: -commit,,DAYES,,administrator,,admin,,,,,,

Look at the command syntax:
3, [ErrorMode], [RebootOK], [ExpandMode], [ApplicationName], [ExpandMode],
[CommandLine], [WaitForCompletion], [Timeout], [ExpandMode], UserName,
[ExpandMode], [Domain], [ExpandMode], Password, [LogonFlags],
[CreationFlags], [ExpandMode], [CurrentDirectory],
[1, StartupInfo] | [0], [NewEnv]

You may want to try to execute something like:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe
c: -commit,DAYES,,,administrator,,YourMachineName,,admin,,,,,,

Please note all the changes made in the command string.


You may also want to include the event log in your configuration so you can debug DUA errors. There is a verbose mode for logging
that will write all DUA commands to the application event log.

Under the [HKLM\SYSTEM\CurrentControlSet\Services\XPEAgent\Parameters\Config] key add "Logging"=dword:1 value.

Btw, it may not be good implementation of your script for the purpose of changing running app with EWF on.
With EWF command you just commit a registry change to move/replace the JP.exe file on next reboot. The file will be replaced each
reboot until you commit EWF again.

If it is acceptable you can issue a command to close your Shell app [properly] (e.g., command like "JP.exe -closeall" that close all
running instances of the app), then replace the exe and commit EWF. Since you reboot then, the new shell exe will be used. This is,
of course, assuming you can change the JP app.

KM

I am trying to update a custom shell using DUA and EWF. Here is my DUA script-

// move the file from C:\ to c:\windows\systems32, but force it to wait
until a reboot to move
MOVEFILE,0,1,C:\DUA\JP.exe,1,c:\Windows\System32\JP.exe,DAMOVEFILE_DELAY_UNT
IL_REBOOT|DAMOVEFILE_REPLACE_EXISTING

// now commit EWF and reboot

EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.e
xe c: -commit,,DAYES,,administrator,,admin,,,,,,

 

[Doug Hoeffel]

KM:

Btw, it may not be good implementation of your script for the purpose of

changing running app with EWF on.

With EWF command you just commit a registry change to move/replace the

JP.exe file on next reboot. The file will be replaced each

reboot until you commit EWF again.

I thought this too until I tried it. I also do the commit after the DUA
script runs and before I shutdown and restart. It appears that the file
copying/renaming occurs on the next boot before the EWF becomes enabled. I
know for a fact that the files are not replaced on each subsequent boot
until the next commit. The area in the registry that holds the pending file
copying/renaming is clean after one reboot.

HTH... Doug

One more time with better wrapping...

Your script does not reboot the device because it likely fails on the EXECUTE command.

Something seems to be wrong in your command:

EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.e
xe c: -commit,,DAYES,,administrator,,admin,,,,,,

Look at the command syntax:
3, [ErrorMode], [RebootOK], [ExpandMode], [ApplicationName], [ExpandMode],
[CommandLine], [WaitForCompletion], [Timeout], [ExpandMode], UserName,
[ExpandMode], [Domain], [ExpandMode], Password, [LogonFlags],
[CreationFlags], [ExpandMode], [CurrentDirectory],
[1, StartupInfo] | [0], [NewEnv]

You may want to try to execute something like:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.e
xe
c: -commit,DAYES,,,administrator,,YourMachineName,,admin,,,,,,

Please note all the changes made in the command string.


You may also want to include the event log in your configuration so you

can debug DUA errors. There is a verbose mode for logging

that will write all DUA commands to the application event log.

Under the

[HKLM\SYSTEM\CurrentControlSet\Services\XPEAgent\Parameters\Config] key add
"Logging"=dword:1 value.

Btw, it may not be good implementation of your script for the purpose of

changing running app with EWF on.

With EWF command you just commit a registry change to move/replace the

JP.exe file on next reboot. The file will be replaced each

reboot until you commit EWF again.

If it is acceptable you can issue a command to close your Shell app

[properly] (e.g., command like "JP.exe -closeall" that close all

running instances of the app), then replace the exe and commit EWF. Since

you reboot then, the new shell exe will be used. This is,

 

[KM]

Doug,

changing running app with EWF on.
JP.exe file on next reboot. The file will be replaced each

I thought this too until I tried it. I also do the commit after the DUA
script runs and before I shutdown and restart. It appears that the file
copying/renaming occurs on the next boot before the EWF becomes enabled.

Well.. It is very possible since the kernel "MoveFileEx routine" happens early at the kernel load.
If this is true, it is good to have the MoveFileEx working properly with EWF.
I don't think there is any problem with RAM EWF but intersting how this works with DISK EWF. Its cache gets commited at the boot
time. If it is not EWF NT loader which commits the cache then there might be some inconsistencies if some FS changes have been made
by the MoveFileEx.

I know for a fact that the files are not replaced on each subsequent boot
until the next commit.

How do you know that?

The area in the registry that holds the pending file
copying/renaming is clean after one reboot.

It should be clean if you check that within the runtime. The best would be to check the registry offline.

If you happened to still have that image, can you check that? It would be interesting to know.

Basically, you would need to apply DUA script, reboot, make sure the file(s) got replaced, shutdown the device and check the
registry key offline. If it is clean now, you are right - EWF gets loaded after the kernel MoveFileEx routine.

Thanks for the note,
KM

 

[Doug Hoeffel]

KM:

You bring up some good points.

I have not looked at the registry offline. I am basing my assumptions on
the fact that I see the following registry key populated after my DUA script
runs and I do the commit (before rebooting):

HKLM\System\CurrentControlSet\Control\Session Manager\FileRenameOperations

If this renaming was occuring on every boot then I would see the same
pending file renaming in the registry, i.e. this renaming would have been
committed. This is not the case. After one reboot the file renaming is
done.

HTH... Doug

Doug,


Well.. It is very possible since the kernel "MoveFileEx routine" happens early at the kernel load.
If this is true, it is good to have the MoveFileEx working properly with EWF.
I don't think there is any problem with RAM EWF but intersting how this

works with DISK EWF. Its cache gets commited at the boot

time. If it is not EWF NT loader which commits the cache then there might

be some inconsistencies if some FS changes have been made

by the MoveFileEx.


How do you know that?


It should be clean if you check that within the runtime. The best would be to check the registry offline.

If you happened to still have that image, can you check that? It would be interesting to know.

Basically, you would need to apply DUA script, reboot, make sure the

file(s) got replaced, shutdown the device and check the

registry key offline. If it is clean now, you are right - EWF gets loaded

after the kernel MoveFileEx routine.

 

[KM]

Doug,

You bring up some good points.

I have not looked at the registry offline. I am basing my assumptions on
the fact that I see the following registry key populated after my DUA script
runs and I do the commit (before rebooting):

HKLM\System\CurrentControlSet\Control\Session Manager\FileRenameOperations

If this renaming was occuring on every boot then I would see the same
pending file renaming in the registry, i.e. this renaming would have been
committed. This is not the case. After one reboot the file renaming is
done.

Well.. This is why I asked about the offline check. The pending registry key would be cleaned by the kernel anyway since the move
operation is done on the boot. So if you checked the registry key at run time it would be empty anyway and the file rename (move)
would be done. The EWF overlay cache, however, would be increased. So, potentially, the RAM EWF usage could blow out (if the moved
files are very big or too many of them) at the boot time - not good and could be repaired offline only.
This is only the case, of course, if the pending move operation happens after EWF is up and running. This may not be true as I
mentioned earlier.

KM

 

[Guest]

One more time with better wrapping...

Your script does not reboot the device because it likely fails on the EXECUTE command.

Something seems to be wrong in your command:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe c: -commit,,DAYES,,administrator,,admin,,,,,,

Look at the command syntax:
3, [ErrorMode], [RebootOK], [ExpandMode], [ApplicationName], [ExpandMode],
[CommandLine], [WaitForCompletion], [Timeout], [ExpandMode], UserName,
[ExpandMode], [Domain], [ExpandMode], Password, [LogonFlags],
[CreationFlags], [ExpandMode], [CurrentDirectory],
[1, StartupInfo] | [0], [NewEnv]

You may want to try to execute something like:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe
c: -commit,DAYES,,,administrator,,YourMachineName,,admin,,,,,,

Please note all the changes made in the command string.

I have changed the script file, but got the same result. I suppose it is
mute though if there is a better way to update using ewf.

You may also want to include the event log in your configuration so you can debug DUA errors. There is a verbose mode for logging
that will write all DUA commands to the application event log.

Under the [HKLM\SYSTEM\CurrentControlSet\Services\XPEAgent\Parameters\Config] key add "Logging"=dword:1 value.

Btw, it may not be good implementation of your script for the purpose of changing running app with EWF on.
With EWF command you just commit a registry change to move/replace the JP.exe file on next reboot. The file will be replaced each
reboot until you commit EWF again.

Can you elaborate on this? What registry key gets changed, and how do I
invoke the EWF command to commit (I thought that's what I was trying to do
above???)

If it is acceptable you can issue a command to close your Shell app [properly] (e.g., command like "JP.exe -closeall" that close all
running instances of the app), then replace the exe and commit EWF. Since you reboot then, the new shell exe will be used. This is,
of course, assuming you can change the JP app.

There is no problem shutting down the shell app, but
cmiWlxAutoRestartShell is set true so the shell automatically restarts. Is
there a registry location to turn it off? If so then a DUA script could turn
off autoshellrestart, copy the new shell app, turn on autoshellrestart again
thus have no need for reboot?
thanks
kevin

 

[Doug Hoeffel]

Ah, now I see where you were going with this. This is an interesting point.

I'm not sure when I'll have an opportunity to check this out though.

Thanks.. Doug

Doug,


Well.. This is why I asked about the offline check. The pending registry

key would be cleaned by the kernel anyway since the move

operation is done on the boot. So if you checked the registry key at run

time it would be empty anyway and the file rename (move)

would be done. The EWF overlay cache, however, would be increased. So,

potentially, the RAM EWF usage could blow out (if the moved

files are very big or too many of them) at the boot time - not good and

could be repaired offline only.

This is only the case, of course, if the pending move operation happens

after EWF is up and running. This may not be true as I

 

[KM]

--
Regards,
KM, BSquare Corp.

One more time with better wrapping...

Your script does not reboot the device because it likely fails on the EXECUTE command.

Something seems to be wrong in your command:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe c: -commit,,DAYES,,administrator,,admin,,,,,,

Look at the command syntax:
3, [ErrorMode], [RebootOK], [ExpandMode], [ApplicationName], [ExpandMode],
[CommandLine], [WaitForCompletion], [Timeout], [ExpandMode], UserName,
[ExpandMode], [Domain], [ExpandMode], Password, [LogonFlags],
[CreationFlags], [ExpandMode], [CurrentDirectory],
[1, StartupInfo] | [0], [NewEnv]

You may want to try to execute something like:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe
c: -commit,DAYES,,,administrator,,YourMachineName,,admin,,,,,,

Please note all the changes made in the command string.

I have changed the script file, but got the same result. I suppose it is
mute though if there is a better way to update using ewf.

Not sure I understand what you are saying here.
Anyhow.. did you check the event log as I mentioned earlier? It will give you more descriptive info on the failure.

....

Can you elaborate on this? What registry key gets changed, and how do I
invoke the EWF command to commit (I thought that's what I was trying to do
above???)

See the discussion between me and Doug in this thread. Doug has mentioned the key already :
HKLM\System\CurrentControlSet\Control\Session Manager\FileRenameOperations.

You do commit the EWF overlay but, as I was saying, you commit only the pending move/rename file action (the reg.key). The file
itself will only be moved on the next boot. If it appears that the pending operation is processed by the kernel after EWF driver is
up and running, the operation will be processed on every next boot. This is not really a big issue to you if the file being replaced
is not big (taking some RAM for EWF cache size growth).

If it is acceptable you can issue a command to close your Shell app [properly] (e.g., command like "JP.exe -closeall" that close all
running instances of the app), then replace the exe and commit EWF. Since you reboot then, the new shell exe will be used. This is,
of course, assuming you can change the JP app.

There is no problem shutting down the shell app, but
cmiWlxAutoRestartShell is set true so the shell automatically restarts. Is
there a registry location to turn it off?

[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon], "Config" dword value. The 5-th bit of the value is responsible for
AutoShellStart under Minlogon.

See my replies in this thread:
http://groups.google.com/groups?hl=...=1&selm=eFsLs#[email protected]

If so then a DUA script could turn
off autoshellrestart, copy the new shell app, turn on autoshellrestart again
thus have no need for reboot?

Regards,
KM

 

[Guest]

--
Regards,
KM, BSquare Corp.

One more time with better wrapping...

Your script does not reboot the device because it likely fails on the EXECUTE command.

Something seems to be wrong in your command:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe c: -commit,,DAYES,,administrator,,admin,,,,,,

Look at the command syntax:
3, [ErrorMode], [RebootOK], [ExpandMode], [ApplicationName], [ExpandMode],
[CommandLine], [WaitForCompletion], [Timeout], [ExpandMode], UserName,
[ExpandMode], [Domain], [ExpandMode], Password, [LogonFlags],
[CreationFlags], [ExpandMode], [CurrentDirectory],
[1, StartupInfo] | [0], [NewEnv]

You may want to try to execute something like:
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe
c: -commit,DAYES,,,administrator,,YourMachineName,,admin,,,,,,

Please note all the changes made in the command string.

I have changed the script file, but got the same result. I suppose it is
mute though if there is a better way to update using ewf.

Not sure I understand what you are saying here.
Anyhow.. did you check the event log as I mentioned earlier? It will give you more descriptive info on the failure.

Well, I managed to create the event log, but I am having greate difficulty
reading it. I have shared c: of the target on a network and can find the
event log file (appevent.evt) in the directory, but can't open it. I opened
the EventViewer through the control panel, and try to connect to remote
computer, but continually get "Unable to connect...network path not found."
This message comes up after using the tools in the EventViewer to find the
target (i.e click browse...Advanced...Find Now.) Any suggestion about how to
view the file?

....

Can you elaborate on this? What registry key gets changed, and how do I
invoke the EWF command to commit (I thought that's what I was trying to do
above???)

See the discussion between me and Doug in this thread. Doug has mentioned the key already :
HKLM\System\CurrentControlSet\Control\Session Manager\FileRenameOperations.

You do commit the EWF overlay but, as I was saying, you commit only the pending move/rename file action (the reg.key). The file
itself will only be moved on the next boot. If it appears that the pending operation is processed by the kernel after EWF driver is
up and running, the operation will be processed on every next boot. This is not really a big issue to you if the file being replaced
is not big (taking some RAM for EWF cache size growth).

If it is acceptable you can issue a command to close your Shell app [properly] (e.g., command like "JP.exe -closeall" that close all
running instances of the app), then replace the exe and commit EWF. Since you reboot then, the new shell exe will be used. This is,
of course, assuming you can change the JP app.

There is no problem shutting down the shell app, but
cmiWlxAutoRestartShell is set true so the shell automatically restarts. Is
there a registry location to turn it off?

[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon], "Config" dword value. The 5-th bit of the value is responsible for
AutoShellStart under Minlogon.

See my replies in this thread:
http://groups.google.com/groups?hl=...=1&selm=eFsLs#[email protected]

If so then a DUA script could turn
off autoshellrestart, copy the new shell app, turn on autoshellrestart again
thus have no need for reboot?

Regards,
KM

 

[KM]

Doug,

Ok.. Just to close the thread. I did a quick test and here is the results.

I was using inuse.exe tool (should be the same MoveFileEx call as from DUA).
The reg.value key created was [HKLM\SYSTEM\CurrentControlSet\Control\Session Manager],"PendingFileRenameOperations" (REG_MULTI_SZ).

I committed EWF on system protected volume (to make the registry change persistent). Checking at run time on next boot the file was
renamed, the registry value deleted (this means the kernel did its job).

Then I shutdown the device and verified the registry offline - the value is still there and the actual file on the disk is the old
one. This is to confirm that the pending operations are done after EWF driver is up and running.

Therefore I was right - it may not be a good practice to use pending file operations - move/delete/rename - with EWF is On.

 

[KM]

kevin,

Well, I managed to create the event log, but I am having greate difficulty
reading it. I have shared c: of the target on a network and can find the
event log file (appevent.evt) in the directory, but can't open it. I opened
the EventViewer through the control panel, and try to connect to remote
computer, but continually get "Unable to connect...network path not found."
This message comes up after using the tools in the EventViewer to find the
target (i.e click browse...Advanced...Find Now.) Any suggestion about how to
view the file?

Well.. Beside making the Event Viewr to work on your image (possible but more efforts) you can just explore the logs offline.
Event Viewer from XP Pro machine will allow you to open .evt files and see thier contents.

KM

 

[Guest]

kevin,


Well.. Beside making the Event Viewr to work on your image (possible but more efforts) you can just explore the logs offline.
Event Viewer from XP Pro machine will allow you to open .evt files and see thier contents.

KM

when I tried to view them off line, the Event Viewer gave a message saying
the files were correupt. I am currently adding the eventviewer to the image,
and will let you know what happens.
I appreciate your time on this
kevin

 

[Doug Hoeffel]

KM:

I agree. I think what I may do in future QFE's via DUA is to perform
another commit/reboot so that the file move/rename does not occur on each
subsequent boot. I think I would rather do that instead of disabling EWF.

Good job!
.... Doug

Doug,

Ok.. Just to close the thread. I did a quick test and here is the results.

I was using inuse.exe tool (should be the same MoveFileEx call as from DUA).
The reg.value key created was

[HKLM\SYSTEM\CurrentControlSet\Control\Session
Manager],"PendingFileRenameOperations" (REG_MULTI_SZ).

I committed EWF on system protected volume (to make the registry change

persistent). Checking at run time on next boot the file was

renamed, the registry value deleted (this means the kernel did its job).

Then I shutdown the device and verified the registry offline - the value

is still there and the actual file on the disk is the old

one. This is to confirm that the pending operations are done after EWF driver is up and running.

Therefore I was right - it may not be a good practice to use pending file

operations - move/delete/rename - with EWF is On.

 

[Guest]

when I tried to view them off line, the Event Viewer gave a message saying
the files were correupt. I am currently adding the eventviewer to the image,
and will let you know what happens.
I appreciate your time on this
kevin

I successfully installed the eventviewr and found the the DUA agent is
causing an error event ID 125. On the target there was no help about what
that meant. i exported the log to my dev. machine and found that the
description for event 125 can't be found (great!) and it also read
"The following information is part of the event: DUAgent,
CreateProcessWithLogonW, The specified service does not exist as an installed
service."
To me, this is no help. Can anyone help debug this DUA script
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe c: -commit,DAYES,,,administrator,,JobPro,,admin,,,,,,
Is it a logon problem???, a cmd line error???
thanks
kevin

..

 

[KM]

kevin,

I successfully installed the eventviewr and found the the DUA agent is
causing an error event ID 125. On the target there was no help about what
that meant. i exported the log to my dev. machine and found that the
description for event 125 can't be found (great!) and it also read
"The following information is part of the event: DUAgent,
CreateProcessWithLogonW, The specified service does not exist as an installed
service."
To me, this is no help. Can anyone help debug this DUA script-
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe

c: -commit,DAYES,,,administrator,,JobPro,,admin,,,,,,

Is it a logon problem???, a cmd line error???

What the DUA service account you set? It is set on the Device Update Agent Settings page (default=Local System).
You will need to switch to run DUA under Administator.

IIRC, if DUA runs under Local System it runs EXECUTE command content under default credentials. It is the service default behaviour
if AutoLogonLevel reg.value under [HKLM\SYSTEM\CurrentControlSet\Services\DUAgent\Parameters\Config\Sessions\0000] key is not
specified (or set to 1). If you set the AutoLogonLevel=2 it should never use default credentials. You can manage the value from TD
if you set DUAgent_dwAutoLogonLevel extended property of the Device Update Agent component (Advanced button).

Please let us know if this helps.

KM

 

[Guest]

kevin,

I successfully installed the eventviewr and found the the DUA agent is
causing an error event ID 125. On the target there was no help about what
that meant. i exported the log to my dev. machine and found that the
description for event 125 can't be found (great!) and it also read
"The following information is part of the event: DUAgent,
CreateProcessWithLogonW, The specified service does not exist as an installed
service."
To me, this is no help. Can anyone help debug this DUA script-
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe

c: -commit,DAYES,,,administrator,,JobPro,,admin,,,,,,

Is it a logon problem???, a cmd line error???

What the DUA service account you set? It is set on the Device Update Agent Settings page (default=Local System).
You will need to switch to run DUA under Administator.

IIRC, if DUA runs under Local System it runs EXECUTE command content under default credentials. It is the service default behaviour
if AutoLogonLevel reg.value under [HKLM\SYSTEM\CurrentControlSet\Services\DUAgent\Parameters\Config\Sessions\0000] key is not
specified (or set to 1). If you set the AutoLogonLevel=2 it should never use default credentials. You can manage the value from TD
if you set DUAgent_dwAutoLogonLevel extended property of the Device Update Agent component (Advanced button).

Please let us know if this helps.

KM

Hi sorry for the delayed response. When I changed the DUA account to
Administrator, the DUA working directory never even gets created. As far as
changing the autologon param. it appeared to do nothing (still return event
ID 125 the event viewer.) The company I work for has given me the go-ahead
to find some 1 on 1 training to not just resolve these issues, but to gain a
better working understanding of XPe. If this is something you can provide or
direct me to someone who can, please email to kbodily at charter.net.
thanks

 

[KM]

kevin,

Sure thing. Check out this link: http://www.bsquare.com/training_support/windowsxpe.asp

KM

kevin,

I successfully installed the eventviewr and found the the DUA agent is
causing an error event ID 125. On the target there was no help about what
that meant. i exported the log to my dev. machine and found that the
description for event 125 can't be found (great!) and it also read
"The following information is part of the event: DUAgent,
CreateProcessWithLogonW, The specified service does not exist as an installed
service."
To me, this is no help. Can anyone help debug this DUA script-
EXECUTE,,DAYES,,c:\windows\system32\ewfmgr.exe,,c:\windows\system32\ewfmgr.exe

c: -commit,DAYES,,,administrator,,JobPro,,admin,,,,,,

Is it a logon problem???, a cmd line error???

What the DUA service account you set? It is set on the Device Update Agent Settings page (default=Local System).
You will need to switch to run DUA under Administator.

IIRC, if DUA runs under Local System it runs EXECUTE command content under default credentials. It is the service default
behaviour
if AutoLogonLevel reg.value under [HKLM\SYSTEM\CurrentControlSet\Services\DUAgent\Parameters\Config\Sessions\0000] key is not
specified (or set to 1). If you set the AutoLogonLevel=2 it should never use default credentials. You can manage the value from
TD
if you set DUAgent_dwAutoLogonLevel extended property of the Device Update Agent component (Advanced button).

Please let us know if this helps.

KM

Hi sorry for the delayed response. When I changed the DUA account to
Administrator, the DUA working directory never even gets created. As far as
changing the autologon param. it appeared to do nothing (still return event
ID 125 the event viewer.) The company I work for has given me the go-ahead
to find some 1 on 1 training to not just resolve these issues, but to gain a
better working understanding of XPe. If this is something you can provide or
direct me to someone who can, please email to kbodily at charter.net.
thanks