There are circumstances that can prevent you from connecting to your Project Server instance with the Project Professional client. These problems often relate to security applied to the workstations by your IT department. When problems relate to specialized security, determining the nature of the problem can be quite tedious. If this is happening on a widespread basis in your organization, look to security policies first. The largest culprit here is changes to registry security on the workstations. Beyond these very esoteric problems in the realm of security, you can take some obvious troubleshooting approaches.
In order for Project Web Access to download the Project Server ActiveX controls at the time of first logon, a client machine must at least have “Run ActiveX controls and plug-ins” enabled and “Download signed ActiveX controls” must be set to at least Prompt, if not Enable, under directory security for your Trusted Sites zone. Further, the user logged onto the workstation must have permission to install new software; otherwise, the ActiveX download for Project Server will fail.
Your first approach should be to try the basic troubleshooting techniques, as follows:
Make sure that your Project Server site wasn’t configured with an invalid name such as with spaces or an underscore in the URL. If you find this is the case, try again after deleting and re-creating it.
Passing the first test, in your browser, select Tools Internet Options, click the Security tab, and select the Trusted sites icon. Click the Sites button and uncheck the “Require server verification (https:) for all sites in this zone” check box if you’re not requiring SSL. Type the URL for the site in the appropriate field in the dialog box. Be certain to use the full form beginning with “http://”. This will add the Project Server instance to the Trusted site zone and assist in troubleshooting. For an illustrated version of these instructions, see the “Unable to Make Project Server a Trusted Site” section later in this chapter.
While you’re still in the Options dialog box, click the Security tab, and then click the Trusted sites zone. Click the Custom level button and make sure that signed ActiveX objects are enabled for download and installation. Also make sure that the account with which you’re logged onto the client machine has software installation privileges. This is a gotcha for users attempting to install on a corporate test system with proper authority.
On the Connections tab, click LAN Settings and make sure that “Automatically detect settings” isn’t checked on your client. If you’re using a proxy, enter it manually.
Find the downloaded programs file on your client and remove the project server ActiveX objects if either PJ10enuC Class or PJAdoInfo2 Class is installed.
Finally, if the Project Professional client was installed before you logged onto Project Web Access for the first time, complete step 5 and uninstall the Project Professional client, then reboot. Access Project Web Access through the browser before you attempt to reinstall the Project Professional client.
Project Server public newsgroup contributor David Cheslow reported a possible client-side fix when ActiveX download fails when the aforementioned configuration is verified. This may or may not help you, but it’s nondestructive to at least verify these settings.
Delete the ActiveX objects if any were partially installed from the downloaded program files directory.
Click the Start button and select Run.
Type RegEdt32 (typing RegEdit won’t work).
Expand to HKEY_LOCAL_MACHINE/Software/Classes.
Choose Security Permissions from the menu.
Select the allow check boxes for Read, Full Control, and Allow inheritable permissions. Click OK.
It’s my current assumption that if you run into a problem like this, it’s because your company alters the registry for security purposes. Problems like this are difficult to troubleshoot when they arise.
This error occurs most often because something is amiss with the MDAC installation. If you’ve implemented a default IIS installation, your Web site should contain an MDAC installation, and if you’ve correctly performed the postinstallation steps outlined in Chapter 5, your MDAC should be configured correctly. If you don’t recall having manually set a DLL’s IP restrictions to Granted on this directory, this is a likely cause in your case. Another possibility is the use of the URL Scan utility. If you’re using the URL Scan utility, refer to KB article 316398. Otherwise, this error occurs most often on systems that have had changes made beyond the default OS installation described in Chapter 5.
Symptoms include the following:
Problems with this Web Page might prevent it from being displayed properly or functioning properly. In the future, you can display this message by double-clicking the warning icon displayed in the status bar.
Error: Internet Server Error: Object/module not found
VB Script: Microsoft Project Web Access
An error occurred while trying to access the resources stored on the database. Either there are too many resources, or the Microsoft Project Server may not have the correct DSN configuration. Contact the server administrator.
Cannot Create Business Objects
The first two messages are most likely to occur due to issues on the server, whereas the third error scenario occurs most often because of client-side issues. One way to make this determination is to test the system using various clients. If all fail, the problem is most likely on the server. If some clients connect, client-side issues are most likely.
It’s entirely possible, but not likely, that the MSADC virtual directory wasn’t created or that MDAC isn’t installed on your server at all. The more likely cause is that directory security hasn’t been properly configured on the msadcs.dll located in the MSADC virtual directory. Verify this first by opening Internet Services Manager and expanding the Default Web Site. Click the MSADC virtual directory, right-click the msadcs.dll, and select Properties. On the Directory Security tab, click the Edit button next to IP and Domain Restrictions and make sure that Granted Access is selected. After you make the change, try accessing the site again. For more information on re-creating MSADC on your server, see KB article 321357.
If the msadcs.dll has the proper Granted Access configuration, then the next step is to upgrade or reinstall MDAC. To do this, search the software downloads section on the Microsoft Web site. Download and install the latest version for your OS. Do the same for the client if you’re receiving the “Cannot Create Business Object” error. Even though you may have a current OS, some third-party vendors have older versions of MDAC overwrite newer ones when installing their software. Typically, upgrading to the latest version of MDAC has no effect on the offending application and clears up the issue on the client.