The solution contains a web part which lists all user profile images and names. It works for some users, but not for others. When it doesn't work, the user is requested to log in over and over again (for as many times as there are images on the page). The server is returning a 401 (access denied) for each image.
On the page where the web part is deployed, the images are referenced to as http://intranet01/my/profile/.../image.png. If I copy this link and open it in the browser, I can see the profile picture in question. However, if I try to access http://intranet.company.com/my/profile/.../image.png in the browser, I get an access denied and can't see the image.
As mentioned, the images are referenced as http://intranet01/my/profile/.../image.png. In a test env. the same images are referenced as /my/profile/.../image.png (i.e. server relative). Why the images aren't referenced server relative on the env. in question is beyond me.
It doesn't matter if I browse the site with intranet01, intranet or intranet.company.com - I still get access denied on the page in question.
It should not be an issue with the page or the user, as the page is published and I myself am a site collection admin and still get access denied, while others whom are normal users can access the page (and images - and yes, they can see the images). It seems like this is not consistent though, as normal users also can get an access denied.
We use claims based authentication. We have uploaded all the images using PowerShell, and run the command Update-SPProfilePhotoStore after completion (with the mysitelocation url parameter of intranet.company.com).
Edit to add: If I access the intranet with http://intranet01 I only get access denied two times because two of the images are linking to http://intranet.company.com/my/..., while the others are linking to http://intranet01/my/... And if I access with intranet.company.com, the two same images are working, while all the others are not.