I have a problem with an application called Manugistics, which connects to an Oracle 8i database using ODBC. The application works only for members of the Administrators group. When nonadministrators attempt to use the application, they receive error 429, "ActiveX component could not open the object." Also, when I publish the application as seamless, even an administrator can open it only once. What's the problem?
See Microsoft article for information about installing ODBC and Microsoft Data Access Components (MDAC) on Windows NT Server 4.0, Terminal Server Edition (TSE). The article is easy to is clear, and I have successfully followed its steps several times.
One of two issues might be causing your user rights problem.
- You have some incorrect permissions on a file. Some DLL files require RWX access (Read, Write, Execute access rights). You can use auditing in user manager or FileMon to help resolve this issue.
- You installed the ODBC driver or the user Data Source Name (DSN) while in Execute mode instead of in Install mode.
- The Microsoft article recommends that you check NTFS permissions, but they should be correct by default. NTFS permissions tell you the correct permission in case you have locked down your terminal server.
- The Install mode issue is more likely the culprit. To check for this problem, search for the file odbc.ini, which contains ODBC settings. The file typically resides in the %SystemRoot% and in the administrative user's %HomeDrive%. The registry key HKEY_CURRENT_USER\SOFTWARE\odbc also contains ODBC settings. If you weren't in Install mode when you set up the ODBC connection, no .ini mapping occurred and the registry edits didn't copy to HKEY_LOCAL_MACHINE\SOFTWARE\microsoft\windows ntcurrent version\terminal server\install\sotware. If this is the case, you must uninstall the DSN configuration and driver and reinstall them in Install mode. Then run the compatibility script. The ODBC compatibility script calls the ODBC key, which changes the location pointer for the log file to each user's %rootdrive%. It then instructs you to run Change User /Install when you configure a user DSN. If your software doesn't require a user DSN, you might be better off with a system DSN. The system DSN is automatically available for all users, so would avoid this issue. As a last resort, give the Everyone group full access to eliminate possible NTFS permissions problems.
Session Sharing might be causing your seamless applications problem. Session Sharing is a feature of Citrix MetaFrame 1.8 for TSE Service Pack 1 (SP1) and for Windows 2000 Terminal Services that lets seamless published applications run over the same connection, which saves licenses and time. Session Sharing, which is on by default, occurs before the load balancing check, which means that an application shares a session before it is load balanced. By adding the following value in the Registry, you can disable Session Sharing to let load balancing do its thing: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\Wfshell\TWI SeamlessFlags = 1 (REG_DWORD)