Just going into prod with a major FIM solution and we found that approvals weren’t working. The request was sent, the email arrived, but when the user went to the Portal to attempt to respond to the request they got “Unable to process your request” immediately after clicking “Submit”.
I actually guessed the cause straight away – but then spent three hours on fruitless troubleshooting because of something I didn’t know about Approval objects – more on that below.
The problem was an incorrect externalHostName in the Microsoft.ResourceManagement.Service.exe.config file.
Actually it wasn’t supposed to be incorrect – but it turned out a peculiarity in the customer’s network means that Kerberos only works using the cname instead of the full fqdn. So I figured the problem was that externalHostName was “fimservice.mydomain.com” instead of just “fimservice”.
I changed the config file, restarted the FIMService and IIS and … still could not approve.
Queue the aforementioned three hours of enabling and trawling log files, messing with service accounts and SPNs, and general hair tearing. After enabling verbose logging I could see this error: “The Portal cannot connect to the middle tier using the web service interface” – something that I know is often externalHostName. So why didn’t my first change fix it?
Well actually it had – just not for the existing Approval objects. And here’s the thing I didn’t know: Approval objects are stamped with the externalHostName from the config file. So change the config file and your existing Approvals are still broken. You need to trigger a new Approval before you can tell for sure if the problem still exists.