• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 281
  • Last Modified:

Terminal Server running Access App problem

We have a Terminal Server setup in our domain which recently had an Access 97 app installed. Only the Domain Administrator account can run the app properly. Members of Domain Admins and even the Local Terminal server administrator account cannot execute the .mdb properly.

The application itself is attempting to launch a new instance of MS Word 97 and Access returns error code 70 - Permission denied. Access is using OLE automation to launch Word.  Below is the code that fails:

Dim objWrd As New Word.Application

objWrd.Visible = True

............. results in the error above as soon as Access attempts to create the object application.

We can see Word running as a process in Windows NT.  We have attempted every method possible to launch Word without success, including using the CreateObject() method, etc ...  Application level permissions are correct.

I set auditing on all files and found that the program was failing to access certain files due to NTFS permissions. I have resolved this but the app still doesn't function correctly. I have tried to audit the registry but failed with Terminal server saying that I am tampering with the license agreement or something. Is there a way around this?

Any ideas?

Thanks
0
jkan052699
Asked:
jkan052699
1 Solution
 
dlb6597Commented:
Was Terminal Server in "install mode" when access was installed?

Also, you can get NTFILEMON and NTREGMON from http://www.sysinternals.com to show access problems to files and registry keys without applying auditing to all files.
0
 
jkan052699Author Commented:
Yes Office was installed per MS instructions.

Have tried Regmon already. Useful but it hasn't helped me track down the keys that cannot be accessed.
0
 
wlaarhovCommented:
Look in the profile of the user that has installed the software.
Just this afternoon I had about the same problem with another application.
It turned out that some of the files and some ini files landed in the c:\wtsrv\profiles\administrator\windows directory.
The solution was to use the control panel / system applet / User profiles tab to copy the administrators profile to "default user".
After deleting all existing profiles and letting users logon again my problem was fixed.

0
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

 
chhoganCommented:
Go to c:\wtsrv\systems32\msjet35.dll and make sure permissions are set to read access for everyone and see if that fixes the problem.
0
 
jkan052699Author Commented:
Thank you all.
I have got a response from Microsoft and it seems that Office was not originally installed in install mode. The downside of this is that we have to reinstall Terminal server from scratch as uninstalling office then using eraser97 then reinstalling office in install mode does not seem to work.
Good eh.
0
 
jkan052699Author Commented:
To chhogan
Thanks for your help.
Sorry but I had to reject your answer as I wanted to give the points to dlb6957 as his answer was the closest to the one offered by Microsoft.
The msjet35.dll was one thing that I had already covered during the file audit.
0

Featured Post

[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now