ASPNET can't write in event log on win XP

[Guest]

Hi,

I'm sorry, this question is also posted in dotnet.framework, I don't know in
which newsgroup my question belongs to...

I'm trying to write in the event log and it looks like it's any of my
applications which are called by ASP.NET that are having trouble with event
log. Here's the
error:

System.InvalidOperationException: Cannot open log for source {0}. You may
not have write access. ---> System.ComponentModel.Win32Exception: Access is
denied

I didn't have this problem on windows 2000. But since I'm on Win XP now, I
have to solve this. I set full control to everyone on every drive of my
computer and it still not working...

Any idea of how to set permissions so ASPNET can write in event log in Win Xp?

Thanks,

Steph

 

[Vadivel Kumar]

Hi,

I think, the following try-outs may help you:-

1. Thoroughly check the access is given to the user ASP.NET and appropriate
groups are in member-of tab.
2. Switch off the inbuild xp firewall and check whether it is working, if it
is working then your firewall configuration has to changed accordingly.
3. Run Asp setup shipped with the .net framework again.

Plz post a reply if you have any further clarifications.

Cheers!
Vadivel Kumar

 

[Kevin Spencer]

I didn't have this problem on windows 2000. But since I'm on Win XP now, I

have to solve this. I set full control to everyone on every drive of my
computer and it still not working...

You might want to undo that. Kind of dodgy in terms of security.

Changing file and folder permissions isn't going to help anything. You need
to change permissions for the Event Log. That's not a drive, and it's not a
folder. See the following article (which I Googled) to find out how:

http://searchvb.techtarget.com/vsnetTip/1,293823,sid8_gci887779_tax293033,00.html

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Guest]

Indeed, I remove full control for everyone... ;-)

I tried your solution and it didn't work. I also put ASPNET in adminstrator
group and it still not working... I get the same error.

I running short of ideas!!

any other idea?

Thanks,

Steph

 

[Kevin Spencer]

I tried your solution and it didn't work. I also put ASPNET in

adminstrator
group and it still not working... I get the same error.

If you tried it and it didn't work, you didn't try it right. You might want
to make sure that the account you assigned permissions to is the account
under which your local ASP.Net app is running. Other than that, GIGO.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Guest]

Hi,

Where can I know for sur on which account ASP.net is running?

However, I used the impersonation in web.config to solve my problem. I guess
it's not the best way to solve that, but at least it works on my developement
server.

<identity impersonate="true" userName="stephane" password="12345"/>

Thanks,

Steph

 

[navyjax2]

Solved in a different way....

I had a similar problem. I had to put in the impersonate line (just minus the user name and password) in my web.config, as well, but I ALSO had to make sure that both my virtual directory and the folder (as seen in IIS, since my folder was inside the wwwroot folder) BOTH had only one type of authentication. For some reason, they each had both Anonymous AND Windows authentication checked in the Security tab, Authentication and Access control Edit button, of the Properties window. I had changed it for the virtual directory, but didn't check the folder that was there in IIS. Once I changed the folder to just Windows Authentication (and said to accept the inheritance to child nodes - the virtual directory), it worked - but I was also logged in as an Admin, so for anyone else trying to use this to solve their issue, they would either have to be an Admin, run their site under the context of an Admin through impersonation, use a service account in the web.config and give it the appropriate privileges to the Event Log registry key that needs to get created for their web app, or use anonymous authentication.

BTW, that link, searchvb.techtarget.com/vsnetTip/1,293823,sid8_gci887779_tax293033,00.html, well they removed their article. But I always favor giving service accounts admin privileges, then taking away their logon locally rights, anyway. If it doesn't work through an admin account, there's something else wrong, I always say . Prevents having to granularly re-assign permissions to a Windows piece that you might not remember how you changed when trying to install the part somewhere else.

-Tom