I had an application that I was working where the client insisted on using an Access database for the application. The application was running on a two node server farm so the Access database had to be located on a seperated machine and accessed over the network. When upgrading the server farm from 2000 to 2003 the client ran into an issue accessing the database. After checking to make sure it wasn't an error with the connection to the location where the database was held I attempted to put the database underneath the site and connect to it there. Well that connection worked fine and the data could be accessed. Long story short after some research and some long hours on this I found that the issue was a combination of things. First under IIS 6 all applications are run under application pools. The application pools do not pass the identity along that they run under. This creates a problem when trying to access a remote drive. To solve this issue you can enable impersonation of the account that you had IIS to run as the anonymous user. To do this you need to open the web.config file of your application. Under the and then insert a line that is similar to this: < IDENTITY impersonate="true/" > This line should be used if you wish to impersonate the user as the account that the user is logged in as on their desktop. or < IDENTITY impersonate="true" userName="< your" user name > password=< USER account password > /> This line should be used if you want to specify one specific account to impersonate. After I turned on the impersonation in my project another issue appeared. I got the dreded /< YOUR name application > Application Error. This issue was addressed in Microsoft KB82719 Article. When a .NET application executes it uses the TEMP folder of the ASPNET user, or whatever user you have specified to run your .NET applications, to run and store temporary files. When you run an Access database/application temporary files are opened but since you are impersonating a user that user does not have access to open these files under the ASPNET temp directory. The solution for this is simple, go into the file structure and grant the account access to the temp folder in C:Document settingsServerNameASPNETlocal settings folder. Only give the account access to the Temp folder so that a security risk is not created. |
