Is a Service not allowed to write to a network share?

[felecha]

I'm working on a system that has a several computers that run an
alerting system. There are 2 "Host" machines that have no user
interface, and one "Admin" station that has an Administrator's
application for configuring and reporting. They are on a simple
local network, just the 3 machines, no wider access.

We do a certain amount of communication between them, using UDP and
MessageQueueing and also in one instance a VB.Net Windows Forms
application on the Admin station, that has a button that a user can
click that will write a new ini file for the system and send it to a
network share on the Hosts, named "DataShare". It is simple enough,
just using File.Delete and File.Copy, with the normal syntax --
File.Copy("C:\IniFileFolder\Configuration.ini",
"\\HostA\DataShare\Configuration.ini"). It's been working for a long
time.

There is also a Windows Service application written in VB.Net, running
on the Admin station. It runs as a Service and receives and processes
stuff coming in on the MessageQueue. We want to use it as a means of
deleting old, out-of-date log files on the Hosts. There are many
logs kept, each one starts a new dated log file once per day, and we
figure we will delete logs older than 10 days. I wrote a simple
method that works just fine, but I did it as a development version in
a Forms application first, since that's easier to debug. I copied the
method's code into the Service, built it, installed it, and now I find
that it throws an Exception

System.UnauthorizedAccessException: Access to the path
"\\HostA\DataShare\Configuration.ini" is denied.

The exact same code, it works in the Forms version, fails in the
Service version.

Is there some security aspect to Windows XP Pro that does not allow
file access to a Service running on another machine?

[Steven]

Things to check:
1. Permissions. both file, application, and directory.
2. Is another process holding the ini file exclusively.
If all else fails, you could send a msg via message queue that creates a
local process to handle the .ini file.
"felecha" <fe*******@yahoo-dot-com.no-spam.invalid> wrote in message
news:41**********@Usenet.com...

I'm working on a system that has a several computers that run an
alerting system. There are 2 "Host" machines that have no user
interface, and one "Admin" station that has an Administrator's
application for configuring and reporting. They are on a simple
local network, just the 3 machines, no wider access.

We do a certain amount of communication between them, using UDP and
MessageQueueing and also in one instance a VB.Net Windows Forms
application on the Admin station, that has a button that a user can
click that will write a new ini file for the system and send it to a
network share on the Hosts, named "DataShare". It is simple enough,
just using File.Delete and File.Copy, with the normal syntax --
File.Copy("C:\IniFileFolder\Configuration.ini",
"\\HostA\DataShare\Configuration.ini"). It's been working for a long
time.

There is also a Windows Service application written in VB.Net, running
on the Admin station. It runs as a Service and receives and processes
stuff coming in on the MessageQueue. We want to use it as a means of
deleting old, out-of-date log files on the Hosts. There are many
logs kept, each one starts a new dated log file once per day, and we
figure we will delete logs older than 10 days. I wrote a simple
method that works just fine, but I did it as a development version in
a Forms application first, since that's easier to debug. I copied the
method's code into the Service, built it, installed it, and now I find
that it throws an Exception

System.UnauthorizedAccessException: Access to the path
"\\HostA\DataShare\Configuration.ini" is denied.

The exact same code, it works in the Forms version, fails in the
Service version.

Is there some security aspect to Windows XP Pro that does not allow
file access to a Service running on another machine?

[felecha]

turned out to be wonderfully simple, but not in the docs.

If I set the code to Username = "MachineName\AccountName" it works.
It shows up in the Services console as ".\AccountName". I had
already tried setting Username = ".\AccountName", which got the error
saying that was an invalid account.

Very strange, but hey, as my favorite professor always said, "In the
end, working is good."