By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,650 Members | 1,785 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,650 IT Pros & Developers. It's quick & easy.

Windows Service Account

P: n/a
I'm hoping someone can give me a little guidance. I have written a
simple Windows Service that goes out and scrapes a few web pages and
updates some data in an access database. The service works correctly
in the IDE and trying to be a good citizen I set it to run as "Local
Service" when I install it.

However once installed it fails silently. My log eventlog message
saying the the DB was updated successfully is written, however the
actual write to the database doesn't happen. There does not seem to
be an error or exception that I can catch, it just doesn't write.

Once I change the service to run as "Local System" it works
correctly. So my question is should I really avoid using "Local
System". I have read the articles explaing he dangers, yet I see lots
of services running as it on my system. Maybe its more like a
guidance "Do so if you can, but if not don't worry too much about it?"
Is there another option? Is there a better way to know where the
problem with the "Local Service" account exists? Like I said when I
debug it in the IDE it works correctly, but at that point it is
running as my user account (which apparently has all the rights it
needs).

Should I just create another user account and play with the permission
until I find the right ones. This service goes out to client
locations so I hate to make them do too much manual work in creating
an account (as some clients I doubt would even know how to do it),
etc?

Thanks,

Matt
Jul 31 '08 #1
Share this Question
Share on Google+
3 Replies


P: n/a

I'm guessing your db isn't configured to allow permissions from the (being
used) user.

2 suggestions:
Switch to sql authentication.

Figure out ( and give permissions ) to the correct user for your db.
Here is some crappy code to figure out (so you can log it) the user.
You're thinking "I know who the user is", but sometimes its good to do it
while in the code.

Go to Control Panel / Users and you can see a list of "built in" users that
a windows machine has.

private string FindIIdentity()

{

try

{

string returnValue = string.Empty;

WindowsIdentity ident = WindowsIdentity.GetCurrent();

returnValue = ident.Name;

try

{

returnValue += " on " + System.Environment.MachineName;

}

catch (Exception ex)

{

}

return returnValue;

}

catch (Exception ex)

{

return "Error Finding Identity";

}

}


"Matt Lowrance" <ma*************@gmail.comwrote in message
news:87**********************************@a1g2000h sb.googlegroups.com...
I'm hoping someone can give me a little guidance. I have written a
simple Windows Service that goes out and scrapes a few web pages and
updates some data in an access database. The service works correctly
in the IDE and trying to be a good citizen I set it to run as "Local
Service" when I install it.

However once installed it fails silently. My log eventlog message
saying the the DB was updated successfully is written, however the
actual write to the database doesn't happen. There does not seem to
be an error or exception that I can catch, it just doesn't write.

Once I change the service to run as "Local System" it works
correctly. So my question is should I really avoid using "Local
System". I have read the articles explaing he dangers, yet I see lots
of services running as it on my system. Maybe its more like a
guidance "Do so if you can, but if not don't worry too much about it?"
Is there another option? Is there a better way to know where the
problem with the "Local Service" account exists? Like I said when I
debug it in the IDE it works correctly, but at that point it is
running as my user account (which apparently has all the rights it
needs).

Should I just create another user account and play with the permission
until I find the right ones. This service goes out to client
locations so I hate to make them do too much manual work in creating
an account (as some clients I doubt would even know how to do it),
etc?

Thanks,

Matt


Jul 31 '08 #2

P: n/a
Read the OP carefully:

1. The OP does not need to find which user account is running the Windows
service. He has said that it work when using "Local System" account, but not
when using "Local Servic" account.
2. He does not use SQL Server, hence not point to "switch to sql
authentication"

To the OP:

Since you use Jet database (Access database), the user account that runs the
application and accesses data in it must have read/write permission to the
folder where the *.mdb file is in. Local System account has mighty power to
access to almost everywhere of the computer, hence it works. Local Service
account, on the other hand, has very limited access to computer resources by
default, you need to explicitly assign permissions to this account to use
resources on the computer. That is, when you place a program to a computer
running as services, you should start with a most restricted user account
and only assign access permissions as needed. In your case, it is good
choice to use Local Service account, but you need to explicitly allow this
account to read/write to the floder where *.mdb sits. Of course you can
choose other user account to run the windows service as long as the account
has sufficient access permissions.

"sloan" <sl***@ipass.netwrote in message
news:OH**************@TK2MSFTNGP05.phx.gbl...
>
I'm guessing your db isn't configured to allow permissions from the (being
used) user.

2 suggestions:
Switch to sql authentication.

Figure out ( and give permissions ) to the correct user for your db.
Here is some crappy code to figure out (so you can log it) the user.
You're thinking "I know who the user is", but sometimes its good to do it
while in the code.

Go to Control Panel / Users and you can see a list of "built in" users
that
a windows machine has.

private string FindIIdentity()

{

try

{

string returnValue = string.Empty;

WindowsIdentity ident = WindowsIdentity.GetCurrent();

returnValue = ident.Name;

try

{

returnValue += " on " + System.Environment.MachineName;

}

catch (Exception ex)

{

}

return returnValue;

}

catch (Exception ex)

{

return "Error Finding Identity";

}

}


"Matt Lowrance" <ma*************@gmail.comwrote in message
news:87**********************************@a1g2000h sb.googlegroups.com...
>I'm hoping someone can give me a little guidance. I have written a
simple Windows Service that goes out and scrapes a few web pages and
updates some data in an access database. The service works correctly
in the IDE and trying to be a good citizen I set it to run as "Local
Service" when I install it.

However once installed it fails silently. My log eventlog message
saying the the DB was updated successfully is written, however the
actual write to the database doesn't happen. There does not seem to
be an error or exception that I can catch, it just doesn't write.

Once I change the service to run as "Local System" it works
correctly. So my question is should I really avoid using "Local
System". I have read the articles explaing he dangers, yet I see lots
of services running as it on my system. Maybe its more like a
guidance "Do so if you can, but if not don't worry too much about it?"
Is there another option? Is there a better way to know where the
problem with the "Local Service" account exists? Like I said when I
debug it in the IDE it works correctly, but at that point it is
running as my user account (which apparently has all the rights it
needs).

Should I just create another user account and play with the permission
until I find the right ones. This service goes out to client
locations so I hate to make them do too much manual work in creating
an account (as some clients I doubt would even know how to do it),
etc?

Thanks,

Matt


Jul 31 '08 #3

P: n/a
Youch.

You got me. I did not see "access" at all til I read closely.

Nix my post. Sorry for the confusion.
Well, you can use the find IIDentity to the user to give folder permissions
to I guess.
But as stated, you already know the user account.

"Norman Yuan" <Fa******@FakeEmail.Notwrote in message
news:en**************@TK2MSFTNGP04.phx.gbl...
Read the OP carefully:

1. The OP does not need to find which user account is running the Windows
service. He has said that it work when using "Local System" account, but
not when using "Local Servic" account.
2. He does not use SQL Server, hence not point to "switch to sql
authentication"

To the OP:

Since you use Jet database (Access database), the user account that runs
the application and accesses data in it must have read/write permission to
the folder where the *.mdb file is in. Local System account has mighty
power to access to almost everywhere of the computer, hence it works.
Local Service account, on the other hand, has very limited access to
computer resources by default, you need to explicitly assign permissions
to this account to use resources on the computer. That is, when you place
a program to a computer running as services, you should start with a most
restricted user account and only assign access permissions as needed. In
your case, it is good choice to use Local Service account, but you need to
explicitly allow this account to read/write to the floder where *.mdb
sits. Of course you can choose other user account to run the windows
service as long as the account has sufficient access permissions.

"sloan" <sl***@ipass.netwrote in message
news:OH**************@TK2MSFTNGP05.phx.gbl...
>>
I'm guessing your db isn't configured to allow permissions from the
(being used) user.

2 suggestions:
Switch to sql authentication.

Figure out ( and give permissions ) to the correct user for your db.
Here is some crappy code to figure out (so you can log it) the user.
You're thinking "I know who the user is", but sometimes its good to do it
while in the code.

Go to Control Panel / Users and you can see a list of "built in" users
that
a windows machine has.

private string FindIIdentity()

{

try

{

string returnValue = string.Empty;

WindowsIdentity ident = WindowsIdentity.GetCurrent();

returnValue = ident.Name;

try

{

returnValue += " on " + System.Environment.MachineName;

}

catch (Exception ex)

{

}

return returnValue;

}

catch (Exception ex)

{

return "Error Finding Identity";

}

}


"Matt Lowrance" <ma*************@gmail.comwrote in message
news:87**********************************@a1g2000 hsb.googlegroups.com...
>>I'm hoping someone can give me a little guidance. I have written a
simple Windows Service that goes out and scrapes a few web pages and
updates some data in an access database. The service works correctly
in the IDE and trying to be a good citizen I set it to run as "Local
Service" when I install it.

However once installed it fails silently. My log eventlog message
saying the the DB was updated successfully is written, however the
actual write to the database doesn't happen. There does not seem to
be an error or exception that I can catch, it just doesn't write.

Once I change the service to run as "Local System" it works
correctly. So my question is should I really avoid using "Local
System". I have read the articles explaing he dangers, yet I see lots
of services running as it on my system. Maybe its more like a
guidance "Do so if you can, but if not don't worry too much about it?"
Is there another option? Is there a better way to know where the
problem with the "Local Service" account exists? Like I said when I
debug it in the IDE it works correctly, but at that point it is
running as my user account (which apparently has all the rights it
needs).

Should I just create another user account and play with the permission
until I find the right ones. This service goes out to client
locations so I hate to make them do too much manual work in creating
an account (as some clients I doubt would even know how to do it),
etc?

Thanks,

Matt



Jul 31 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.