tl;dr

When users are presented with a generic error message, URL in a browser address bar sometimes contain enough details about the error to determine the actual cause.

How to fish

“An error has occurred.” How wonderful. We all have seen it at one point of our CRM lives or another.

Users unable to login, and instead presented with this message. Note that there are no references to send more information to Microsoft, no option to download the log file. Try again or get out. (I’m not sure why did anyone even bother to add Try Again button, like that ever worked.)

So what is going to happen if you decide to stop using this dialog as an excuse to attend to your facebook page and contact system administrator (presumably, you have one of those)? Troubleshooting of generic messages like this one usually involves setting up a trace on CRM server(s), capturing errors, analyzing, drinking lots of coffee, etc. Depending on size of your company and your relationship with administrator it may take a day or two. Or a week. Or a month. Don’t call us we’ll call you. Troubleshooting, in short.

Surely, there must be a better way and on this occasion there is! Let’s have a close look at the URL:

And after plonking this monstrosity into one of the online decoders:

It looks like AD FS server receives an encrypted request from CRM to authenticate but certificate to decrypt the request cannot be found. Quick check of the certificates on the AD FS server and, lo and behold, some smart administrator installed a replacement certificate but re-configured neither AD FS nor CRM servers. Easy to fix by repeating claims & IFD configuration process.

Lesson: before running for help to the community, your system administrator or, gosh, Microsoft, just have a look at URL. If it’s all foreign to you, at least copy URL and send it to your administrator as part of the problem reporting. Unless, of course, all you want to do is to get back to that facebook page.