J
Joel P.
We have had a number of instances where a user of Microsoft Project 2003
Professional without reason could not connect to the Project Server. Trying
to sign onto PWA challenges the user to enter password (which should not
occur, given our users are set up for Windows authentication.
The only solution we have found is to recreate the windows profile on the
desktop.
We tried a number of things:
- Rebooting doesn't help
- Clearing cookies and browser cache doesn't help
- The test connect fails as well
- Trying to connect to PWA fails (user challenged to enter password, which
fails when the password is re-entered)
- We tried deleting the PWA ActiveX objects (in Options, Settings, General,
View Objects, deleting the two objects starting with PJ*)
Our users are:
- Set up to use Windows Authentication.
- Running XP SP1 or SP2.
- The project server URL is listed in the trusted sites in the IE Security
Options
-
The problem persists even if IE security is set to "Low"
Interestingly, if the user uses the exact same logon ID/password from a
different box (using windows terminal services) the user can connect fine.
So we know the problem is local to the client machine.
Professional without reason could not connect to the Project Server. Trying
to sign onto PWA challenges the user to enter password (which should not
occur, given our users are set up for Windows authentication.
The only solution we have found is to recreate the windows profile on the
desktop.
We tried a number of things:
- Rebooting doesn't help
- Clearing cookies and browser cache doesn't help
- The test connect fails as well
- Trying to connect to PWA fails (user challenged to enter password, which
fails when the password is re-entered)
- We tried deleting the PWA ActiveX objects (in Options, Settings, General,
View Objects, deleting the two objects starting with PJ*)
Our users are:
- Set up to use Windows Authentication.
- Running XP SP1 or SP2.
- The project server URL is listed in the trusted sites in the IE Security
Options
-
The problem persists even if IE security is set to "Low"
Interestingly, if the user uses the exact same logon ID/password from a
different box (using windows terminal services) the user can connect fine.
So we know the problem is local to the client machine.