Accessing MSAccess dll's from a Windows Scheduled Task

[jdaelhousen]

I have a bit of a problem I'm hoping someone can shed some light on...

I have a VB.Net console application written in VS 2003 that produces a .exe file that now sits on a Windows 2000 server directory. This exe does the following 3 things:

1.) Using the VB Interaction SaveSetting() method, it programmatically updates the system registry under the HKEY_CURRENT_USER\SOFTWARE key and saves a directory location used by a PDF driver (so that the pdf driver does not prompt for a location).

2.) opens up an instance of a local MSAccess database (i.e., set objAccess = New Access.Application(c:\mydatabase.mdb))

3.) Uses the DoCmd.OpenReport method to create a physical .pdf report to the location specified above in step 1. Then the report is emailed out to a group of users.

When I'm logged on to the Windows 2000 server as my user i.d. and I double click the .exe file, everything works perfectly.

However, I'm running into problems when trying to automate this and kick off the .exe file with a Windows scheduled task. If I run the scheduled task as my i.d., I do not get past step 2 above as it keeps giving me the following error:
"System.UnauthorizedAccessException: Access is denied." It appears that my userID cannot create a new instance of MSAccess but only when run through the scheduled task.

If I run the scheduled task as NT AUTHORITY\SYSTEM, I get an error message on step 3 above with the following error message:
"There was a problem retrieving printer information for the Win2PDF on PDFFILE:. The object may have been sent to a printer that is unavailable."
In this case it appears that I cannot save registry settings as the NT AUTHORITY\SYSTEM user for the pdf printer.

So my questions are first, does anyone know why I cannot create an instance of MSAccess when using the scheduled task. And second, why can't I save registry settings when I run the .exe through a scheduled task as the NT AUTHORITY\SYSTEM user?

Thanks in advance,

John

[kenobewan]

Most of your questions come down to permissions. Your question is confusing in that it appears to associate saving a db file with installing db software. The install works with an account that suggest using windows authentication without impersonation.

[jdaelhousen]

Most of your questions come down to permissions. Your question is confusing in that it appears to associate saving a db file with installing db software. The install works with an account that suggest using windows authentication without impersonation.

Yes, it does come down to permissions which is what I'm trying to figure out. Let's start simpler:

I'm an admin on the server. If the .exe works fine and can open instances of MSAccess when I double click it, why does it fail to instantiate MSAccess when a scheduled task runs the executable as the NT AUTHORITY\system user? What am I missing here?

Thanks,

John

[kenobewan]

Yes, it does come down to permissions which is what I'm trying to figure out. Let's start simpler:

I'm an admin on the server. If the .exe works fine and can open instances of MSAccess when I double click it, why does it fail to instantiate MSAccess when a scheduled task runs the executable as the NT AUTHORITY\system user? What am I missing here?

Thanks,

John

You have hit the nail on the head - Access is run under your admin account but not the anonymous account. Are you planning to automate this task on any other machines/servers?

[jdaelhousen]

You have hit the nail on the head - Access is run under your admin account but not the anonymous account. Are you planning to automate this task on any other machines/servers?

I apologize, my previous reply was a bit confusing after I reread it. First to answer your question, I am planning to automate this task with the scheduled task only on the server that the exe is currently sitting. It will not be deployed anywhere else.

But I think I might have miscommunicated what's actually going on here. Let me take a step back and reconfirm what's going on:

If I double click the .exe everything works fine.

If the scheduled task executes the .exe as my user ID I get the "Access is Denied" error (can't instantiate MSAccess).

If the scheduled task executes the .exe as the NT AUTHORITY\SYSTEM user, the application can instantiate MSAccess, but I get other errors mentioned in my original post about reading registry settings. Therefore, I'd like to solve this problem if possible by executing the scheduled task as my i.d. and get past this inability to instantiate MSAccess.

Thanks,

John

[kenobewan]

NP. This is why I mentioned impersonation in my first post, I believe now that this may be the key to your problems. An example might help:
User Impersonation in .Net.

[jdaelhousen]

NP. This is why I mentioned impersonation in my first post, I believe now that this may be the key to your problems. An example might help:
User Impersonation in .Net.

Thanks, kenobewan. I'll give this a whirl later tonight when I get some time and reply back with my results. It does appear from first glance that this might be the issue.

Thanks again.

[jdaelhousen]

Well the impersonation code didn't seem to work. After referencing the ImpersUser dll in my project, I tried running the 1 line of code to impersonate as the NT AUTHORITY\SYSTEM user. No errors were thrown so i'm assuming that the impersonation as NT AUTHORITY\SYSTEM went through ok, but I still could not open up the access database. I'm really stumped here.

[kenobewan]

You are having no joy because, not an insult, you are new to this. To progress with this prob you'll need to learn much more about .net.

This is time consuming in the short term, but you'll benefit in the long run if you face other situations like this. The alternative is to hand this over to a developer.

The reason I am saying this is not be unkind, but we are starting to go around in circles here. I believe that there is enough info in my posts to solve this problem.

[jdaelhousen]

You are having no joy because, not an insult, you are new to this. To progress with this prob you'll need to learn much more about .net.

This is time consuming in the short term, but you'll benefit in the long run if you face other situations like this. The alternative is to hand this over to a developer.

The reason I am saying this is not be unkind, but we are starting to go around in circles here. I believe that there is enough info in my posts to solve this problem.

No offense taken, however I am a developer and know how to write .net exe modules and have been doing so for several years. What I'm not familiar with are account permissions because I'm not a network administrator. And don't take this the wrong way because I appreciate your help, but other than the impersonation class that didn't fix the issue, you didn't suggest anything that I haven't already tried. So I think I need to present my issue to another message group. There has to be someone who has faced this same exact problem before. Thanks again.