I'm having problems getting external images to show up in a report. As
suggested in other posts in this group - the resource is linked to a fully
qualified server name.
The reporting services is locked down to authenticated users. The image url
is to the same server and I've tried setting access to both anonymous access
and authenticated users. I don't believe it is a permissions problem
because I can paste the url in a browser and view the image with no problem.
When I right click on the red x (where the image should be) and go to
properties and look at the url - it only shows the server name and not the
rest of the url (folder and file name.) When I review the data that provides
the url for the external image - the correct url is in there. I copy and
paste to the browser - the image comes up fine.
This really has me stumped - because everything seems to be right. I have
this running in three sites with no problem and don't see what I'm doing
different here. The only difference is that this is running in a tightly
locked down hospital setting. Is there some browser setting that can be set
in a policy that would restrict a web page from pulling info from multiple
sources or something?
Thanks,
DavidHi David,
Welcome to the MSDN newsgroup.
As for the image displaying problem, based on my experience, we could
troubleshoot from two aspects, the client-side browser and the server-side
report deisgn. Have you try visisting the report page from other client
machines to see whether the image can display well? If also suffering the
problem, it is likely the report or the image part is not correctly
rendered. Also, as you mentioned that when you right click the "X" and view
URL, it doesn't point to the correct image file path ,yes? I suggest you
also use the browser's "View Source" menu item to check the HTML source of
the report page, if the <img> element is not assigned the correct "src"
attribute, it is likely the server report's design has some thing incorrect
that cause this problem.
Regards,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)|||I looked at the source code and it says this for the image <IMG class="r1"
SRC="">
I verified the data in the dataset and it is coming back with the correct
url for the image.
When I look at the source for a page that is rendering correctly (in a
different location) it's coming back with the following
<IMG class="r1"
SRC="</DIV></TD><TD">http://hvsql01/ReportServer?%2fCardioDx%2fNuclear&EncounterID=22004&rs%3aFormat=HTML4.0&rs%3aImageID=189"></DIV></TD><TD
ROWSPAN="3" style="WIDTH:3.18mm">
I'm a little suprised at the url for the image source. Looks like it's
coming from the reportserver instead of directly from the source. Makes
sense I guess having to generate the pictures in other formats would require
pulling it through the rendering engine.
Everything looks the same as the source running successfully in another
environment.
Thanks for helping narrow this down however - not sure what to do at this
point.
I'm running SQLRS with service pack 2. One of the fixes I tried to apply was
to add an unattended mode user with the rsconfig app. Nothing changed but
it accepted it.
"Steven Cheng[MSFT]" <stcheng@.online.microsoft.com> wrote in message
news:5X1KGl1QGHA.1592@.TK2MSFTNGXA03.phx.gbl...
> Hi David,
> Welcome to the MSDN newsgroup.
> As for the image displaying problem, based on my experience, we could
> troubleshoot from two aspects, the client-side browser and the server-side
> report deisgn. Have you try visisting the report page from other client
> machines to see whether the image can display well? If also suffering the
> problem, it is likely the report or the image part is not correctly
> rendered. Also, as you mentioned that when you right click the "X" and
> view
> URL, it doesn't point to the correct image file path ,yes? I suggest you
> also use the browser's "View Source" menu item to check the HTML source of
> the report page, if the <img> element is not assigned the correct "src"
> attribute, it is likely the server report's design has some thing
> incorrect
> that cause this problem.
> Regards,
> Steven Cheng
> Microsoft Online Support
> Get Secure! www.microsoft.com/security
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>|||Thanks for your respone David,
I've also performed some further tests on my side and did found some clues.
Actually, what you have seen (I'm a little suprised at the url for the
image source. Looks like it's coming from the reportserver instead of
directly from the source) is the expected behavior because SQL Reporting
service does not directly simply put the external image's address in the
report's rendered html. Instead, the report server will first retrieve the
image stream itself than provide a url point to the image stream from the
report server. Therefore, this make it important that we need to make sure
our report server application can correct access that image under its
running security account. See the below note in BOL:
====================External Images
You can include stored images in a report by specifying a URL to the image.
When you use an external image in a report, the image source is set to
External and the value for the image is the URL address to the image (for
example, http://<servername>/images/image1.jpg).
When the report is previewed in Report Designer, preview uses the
credentials of the user to display the image. When the report is run on the
report server, the report server uses the unattended execution account to
retrieve the image. If the unattended execution account is not specified,
the image is retrieved using no credentials (anonymous user account). If
either of these accounts have insufficient rights to access the image, the
image will not be displayed in the report. For more information about the
unattended execution account, see Configuring an Account for Unattended
Report Processing.
====================
And based on my test, when I specify an invalid url ( or a url the report
server can not access). the "src" attribute of the <img> tag will be empty
, just like <img ... src="http://pics.10026.com/?src=" /> , and this conforms to what you'r
encountering also, correct? So I think the problem is possibly caused by
the web url based image is not correctly accessed by the report server
application.
So far I think there're two things we can check:
1. security, whether the images are protected by any authentication which
require certain security context(account) to access
2. web proxy setting , since you can visit the image in browser, is there
any proxy setting in browser which is not utilized by the report server
appliation that cause the image unaccessible?
Regards,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)|||Thanks Steven,
As I mentioned in my last post - I had already set up the system for
unattended execution and permissions were set for Domain Admin.
That leaves me with your second suggestion which I don't understand. Can
you explain a little further what I'm supposed to be looking for? When RS
processes the image - does it use the proxy server to get the image? Is
that what you are saying?
Thanks,
David
"Steven Cheng[MSFT]" <stcheng@.online.microsoft.com> wrote in message
news:sSZ3o1ARGHA.7144@.TK2MSFTNGXA03.phx.gbl...
> Thanks for your respone David,
> I've also performed some further tests on my side and did found some
> clues.
> Actually, what you have seen (I'm a little suprised at the url for the
> image source. Looks like it's coming from the reportserver instead of
> directly from the source) is the expected behavior because SQL Reporting
> service does not directly simply put the external image's address in the
> report's rendered html. Instead, the report server will first retrieve the
> image stream itself than provide a url point to the image stream from the
> report server. Therefore, this make it important that we need to make
> sure
> our report server application can correct access that image under its
> running security account. See the below note in BOL:
> ====================> External Images
> You can include stored images in a report by specifying a URL to the
> image.
> When you use an external image in a report, the image source is set to
> External and the value for the image is the URL address to the image (for
> example, http://<servername>/images/image1.jpg).
> When the report is previewed in Report Designer, preview uses the
> credentials of the user to display the image. When the report is run on
> the
> report server, the report server uses the unattended execution account to
> retrieve the image. If the unattended execution account is not specified,
> the image is retrieved using no credentials (anonymous user account). If
> either of these accounts have insufficient rights to access the image, the
> image will not be displayed in the report. For more information about the
> unattended execution account, see Configuring an Account for Unattended
> Report Processing.
> ====================> And based on my test, when I specify an invalid url ( or a url the report
> server can not access). the "src" attribute of the <img> tag will be empty
> , just like <img ... src="http://pics.10026.com/?src=" /> , and this conforms to what you'r
> encountering also, correct? So I think the problem is possibly caused by
> the web url based image is not correctly accessed by the report server
> application.
> So far I think there're two things we can check:
> 1. security, whether the images are protected by any authentication which
> require certain security context(account) to access
> 2. web proxy setting , since you can visit the image in browser, is there
> any proxy setting in browser which is not utilized by the report server
> appliation that cause the image unaccessible?
> Regards,
> Steven Cheng
> Microsoft Online Support
> Get Secure! www.microsoft.com/security
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>
>
>|||Hi David,
The proxy I means is the proxy your webclient (like browser) need to visist
external internet resources. For example, when you use IE to visit some
certain resources, maybe you're configured to use some proxy server in IE's
connection setting(or you've used any proxy client which automatically
configure this for you). However, for report server application ,it may not
utilize the same setting as IE, thus, there may occur some issue when
report server application try visit some external resources. So I'm not
sure whether your network environment is something like this.
Regards,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)|||I just came back from the installation and there are no proxy servers set
up.
Do you have any other suggestions? I really do not have any idea what
could be wrong here.
Thanks - David
"Steven Cheng[MSFT]" <stcheng@.online.microsoft.com> wrote in message
news:ypy%23J4oRGHA.6492@.TK2MSFTNGXA03.phx.gbl...
> Hi David,
> The proxy I means is the proxy your webclient (like browser) need to
> visist
> external internet resources. For example, when you use IE to visit some
> certain resources, maybe you're configured to use some proxy server in
> IE's
> connection setting(or you've used any proxy client which automatically
> configure this for you). However, for report server application ,it may
> not
> utilize the same setting as IE, thus, there may occur some issue when
> report server application try visit some external resources. So I'm not
> sure whether your network environment is something like this.
> Regards,
> Steven Cheng
> Microsoft Online Support
> Get Secure! www.microsoft.com/security
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>|||Just spent 4.5 hours on the phone and an open ticket with Microsoft and
determined that there is a bug in IIS that doesn't pass permissions on to
local virtual directories.
Finally - the work around for this is to put a file path in where the url is
supposed to go for the image. This worked great - bypassed problems iis is
having and seems to run a little faster too.
Here's a "for instance" sent by the tech at MS. Put whatever path to your
image.
file:///c:/WINNT/Zapotec.bmp
David
<drchips@.nospam.nospam> wrote in message
news:%23lj9EowQGHA.1328@.TK2MSFTNGP10.phx.gbl...
> I'm having problems getting external images to show up in a report. As
> suggested in other posts in this group - the resource is linked to a
> fully qualified server name.
> The reporting services is locked down to authenticated users. The image
> url is to the same server and I've tried setting access to both anonymous
> access and authenticated users. I don't believe it is a permissions
> problem because I can paste the url in a browser and view the image with
> no problem.
> When I right click on the red x (where the image should be) and go to
> properties and look at the url - it only shows the server name and not the
> rest of the url (folder and file name.) When I review the data that
> provides the url for the external image - the correct url is in there. I
> copy and paste to the browser - the image comes up fine.
> This really has me stumped - because everything seems to be right. I have
> this running in three sites with no problem and don't see what I'm doing
> different here. The only difference is that this is running in a tightly
> locked down hospital setting. Is there some browser setting that can be
> set in a policy that would restrict a web page from pulling info from
> multiple sources or something?
> Thanks,
> David
>|||Thanks for your followup David,
So the problem still be caused by the IIS side, really a bit surprising.
Anyway, glad that you've got it working now.
If there's anything else we can help, please feel free to post here.
Regards,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment