Workflow approval process going to incorrect URL or otherwise not working for 1 approver

I have a user that is an approver on a workflow. When this user gets a notification that he needs to approve a request he goes to a task list, clicks on the request, and then clicks approve. His browser is then redirected to a page that returns the generic IE "Page cannot be displayed" message.

Another user is (and I also am) an approver for this workflow as well. When we go through the same process, the workflow is approved as it should be. I've double checked and all of our rights for this site and workflow are identical.

Also at times, the user in question clicks on the task from the task list screen I mentioned earlier and his browser is directed to the generic "Page cannot be displayed" message.

Here is what the URL looks like when I go the the approval screen from the task list
http://ussrm-wsf:25594/Managers/_layouts/WrkTaskIP.aspx?List=70cc49d8%2D7c8d%2D4fac%2Da15b%2D78674f5ce03a&ID=570&Source=http%3A%2F%2Fussrm%2Dwsf%3A25594%2FManagers%2FLists%2FTasks%2FAllItems%2Easpx

Here is what his looks like:
http://ussrm-wsf:25594/Managers/Lists/Tasks/DispForm.aspx?ID=570&Source=http%3A%2F%2Fussrm%2Dwsf%3A25594%2FManagers%2FLists%2FTasks%2FAllItems%2Easpx

What are some things I can look at to fix this?
Mike MillerSoftware EngineerAsked:
Who is Participating?
 
Mike MillerSoftware EngineerAuthor Commented:
Got it. For anyone who stumbles across this page, here's the solution...

IIS does not authenticate Sharepoint (which I didn't know). Sharepoint uses an internal authentication process which you can find fumbling around on the site. By default, Sharepoint uses Kerberos to authenticate users. Well this particular user was added to several security groups over the past couple weeks which increased the length of his Kerberos ticket. We configure IIS to use NTLM so it never occurred to me that this would be an issue. Well after finding the Sharepoint Authentication page, I changed the authentication mode to NTLM and presto! It worked.

I suppose the alternative would be to remove the user from AD groups :-p
0
 
mccarthybriCommented:
the first thing i would do is have him try on a differant box or have you goto his machine and see if it happens to you.  Its allways to ggod to figure if its the machine or the user profile or a combo of both
0
 
Mike MillerSoftware EngineerAuthor Commented:
Ok I just went to his machine and went to log on as myself....same bad request screen. All I did was click on "Login as another User" (through SP) and it bombed.
0
 
Mike MillerSoftware EngineerAuthor Commented:
I looged in as him on my machine and it seemed to behave the same. Very strange. I poked around in other areas of SP for a while under his ID and then back to the task approval and got a "Request Header Too Long" error.

I also tried running the same process logged in both as him and as myself in Google Chrome and it worked fine. The behavior from my initial post was done in IE 8 both on a Vista and Win7 box. (The only difference in the two is an additional InfoPath popup message on 7 prior to going to the Bad Request error page)
0
 
MsShadowCommented:
Thanks for posting this, wouldn't have figured that out tbh :p
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.