8.03 Auto Update fails as restricted user

Yahoo Archive
1
I would have to agree... very bad programming. We're still in the implementation/testing/training stages. During training, we had problems where users would get an error if they tried to change the options for a screen. The program was trying to write to a file in the All Users profile. They seemed to have fixed it with patch F (at least I can't duplicate it now that we've moved to rev F), but it still led me to wonder about their development process - this software is written for Windows, using Microsoft development tools and technologies, is touted as being a Microsoft partner, and they don't even respect the Windows security model.




From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Joe Rojas
Sent: Friday, May 18, 2007 3:32 PM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] 8.03 Auto Update fails as restricted user


Unfortunately I don't have a solution but I wanted to chime in.

I notice this issue also. This is just bad programming on Epicor's part.
They boast being a gold partner MS but to create an application that
doesn't take into account restricted user permissions in annoying.

I hope they get enough feedback and fix this.

Joe Rojas

Information Technology Manager

Symmetry Medical TNCO

15 Colebrook Blvd

Whitman MA 02382

781-447-6661 x7506

jrojas@...

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Scott Edell
Sent: Friday, May 18, 2007 1:48 PM
To: vantage@yahoogroups.com
Subject: [Vantage] 8.03 Auto Update fails as restricted user

I'm having a problem with the Auto Update failing when run as a
restricted user because of the Manufacturing System Monitor service, and
I'm wondering if/how some of you have gotten around the problem.

The Auto Update routine tries to uninstall the Manufacturing System
Monitor service, update all the appropriate files, then reinstall the
service. I've given Domain Users read/write/modify permissions to the
C:\client803 directory, so writing and updating files isn't a problem,
but users don't have high enough permissions to install/uninstall
services. The service doesn't uninstall, so when the update gets to the
files that the service uses, it fails with a "The file
'C:\client803\Client\Epicor.Mfg.Lib.ISysmon.dll' is currently locked."
error. If the service isn't running, like if I shut it down remotely,
the update completes using the user's credentials, but I can't see
myself doing that all day on the day of a roll out.

Has anyone found a way around this? What does the Manufacturing System
Monitor service even do? Some machines don't have it, because it was a
restricted user account that first started up the program and kicked off
the Auto Update part of the initial install, and they seem to work
properly.

Thanks,
Scott

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]




[Non-text portions of this message have been removed]
2
I'm having a problem with the Auto Update failing when run as a restricted user because of the Manufacturing System Monitor service, and I'm wondering if/how some of you have gotten around the problem.

The Auto Update routine tries to uninstall the Manufacturing System Monitor service, update all the appropriate files, then reinstall the service. I've given Domain Users read/write/modify permissions to the C:\client803 directory, so writing and updating files isn't a problem, but users don't have high enough permissions to install/uninstall services. The service doesn't uninstall, so when the update gets to the files that the service uses, it fails with a "The file 'C:\client803\Client\Epicor.Mfg.Lib.ISysmon.dll' is currently locked." error. If the service isn't running, like if I shut it down remotely, the update completes using the user's credentials, but I can't see myself doing that all day on the day of a roll out.

Has anyone found a way around this? What does the Manufacturing System Monitor service even do? Some machines don't have it, because it was a restricted user account that first started up the program and kicked off the Auto Update part of the initial install, and they seem to work properly.

Thanks,
Scott

[Non-text portions of this message have been removed]
3
Unfortunately I don't have a solution but I wanted to chime in.



I notice this issue also. This is just bad programming on Epicor's part.
They boast being a gold partner MS but to create an application that
doesn't take into account restricted user permissions in annoying.

I hope they get enough feedback and fix this.



Joe Rojas

Information Technology Manager

Symmetry Medical TNCO

15 Colebrook Blvd

Whitman MA 02382

781-447-6661 x7506

jrojas@...



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Scott Edell
Sent: Friday, May 18, 2007 1:48 PM
To: vantage@yahoogroups.com
Subject: [Vantage] 8.03 Auto Update fails as restricted user



I'm having a problem with the Auto Update failing when run as a
restricted user because of the Manufacturing System Monitor service, and
I'm wondering if/how some of you have gotten around the problem.

The Auto Update routine tries to uninstall the Manufacturing System
Monitor service, update all the appropriate files, then reinstall the
service. I've given Domain Users read/write/modify permissions to the
C:\client803 directory, so writing and updating files isn't a problem,
but users don't have high enough permissions to install/uninstall
services. The service doesn't uninstall, so when the update gets to the
files that the service uses, it fails with a "The file
'C:\client803\Client\Epicor.Mfg.Lib.ISysmon.dll' is currently locked."
error. If the service isn't running, like if I shut it down remotely,
the update completes using the user's credentials, but I can't see
myself doing that all day on the day of a roll out.

Has anyone found a way around this? What does the Manufacturing System
Monitor service even do? Some machines don't have it, because it was a
restricted user account that first started up the program and kicked off
the Auto Update part of the initial install, and they seem to work
properly.

Thanks,
Scott

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]