SSRS report in EPM 2007 demo VPC

[Mike Mahoney]

I am having problems with the Project List report. I can get this
report to work in a single server environment but not in a two tier
system.

I have two tier environment
MSPS2007/MOSS wfe and application server SQL 2005 and SSRS server

The project list view enables you to drill down to a project detail
view or use the report icon to display project report dashboard (a
separate SSRS report.

In the two tier environment from within Reports Manager the hyperlinks
work as expected but from within Sharepoint web page the same command
fails.

The navigation code is: ="javascript:void(window.open('" & Fields!
Project_Detail_View_URL.Value & "','_top'))"

The seem to be because of anti-phishing protection within Sharepoint/
IE - Event 1034 - Cross-Domain Barrier and Script URL Mitigation. This
article addresses the problem - http://msdn.microsoft.com/en-us/library/cc994346(VS.85).aspx

Unfortunately my limited programmming skills prevent me from from
resolving this problem:

Is there an easy way to resolve this

Note I am using domain service accounts and kerberos authentication.
SSRS is not integrated with sharepoint

Thanks

Mike

 

[Stephen Sanderlin]

Are both sites using their fully-qualified domain names (FQDNs) in the
links (e.g. http://server.domain.tld/reports vs. http://server/reports),
and are the domains the same for both URLs?


--

Stephen Sanderlin

Principal Consultant

MSProjectExperts



For Project Server Consulting: http://www.msprojectexperts.com

For Project Server Training: http://www.projectservertraining.com



Read my blog at: http://www.projectserverhelp.com/

Join the community at: http://forums.epmfaq.com

 

[Mike Mahoney]

Are both sites using their fully-qualified domain names (FQDNs) in the
links (e.g.http://server.domain.tld/reportsvs.http://server/reports),
and are the domains the same for both URLs?

--

Stephen Sanderlin

Principal Consultant

MSProjectExperts

For Project Server Consulting:http://www.msprojectexperts.com

For Project Server Training:http://www.projectservertraining.com

Read my blog at:http://www.projectserverhelp.com/

Join the community at:http://forums.epmfaq.com














- Show quoted text -

Hi Stephen

Both servers are in the same domain, Accessing Report Manager or
Report Server sites from either server works fine. PWA works
perfectly fine from either server (using same credentials). II tried
putting FQDN in the text string and it then prevented drilldown in the
reportserver interface (which previously worked) - it prompts for
authentication - which it won't accept).

When you click on the hyperlink (project name) the java script is
displayed on the message line at the bottom of IE. In SSRS site it
executes but in Sharepoint Web Part does not.

regards

Mike

 

[Stephen Sanderlin]

Right.. but if you're not using the FQDNs, IE has no way of knowing they
are in the same domain. (e.g. server1 to server2 will fail cross-domain,
but make them FQDNs in the same domain.tld and they will not).



If you had not previously configured SRS to work with an FQDN, you need
to make some configuration changes. Check out this page
(http://bloggingabout.net/blogs/mgla...es-on-a-fully-qualified-domain-name-fqdn.aspx)
for more info. If SharePoint/PS is not configured to use the FQDN
either, you will need to adjust the Alternate Access Mappings.



Let me know if this resolves the problem!



--

Stephen Sanderlin

Principal Consultant

MSProjectExperts



For Project Server Consulting: http://www.msprojectexperts.com

For Project Server Training: http://www.projectservertraining.com



Read my blog at: http://www.projectserverhelp.com/

Join the community at: http://forums.epmfaq.com

 

[Mike Mahoney]

Right.. but if you're not using the FQDNs, IE has no way of knowing they
are in the same domain. (e.g. server1 to server2 will fail cross-domain,
but make them FQDNs in the same domain.tld and they will not).

If you had not previously configured SRS to work with an FQDN, you need
to make some configuration changes. Check out this page
(http://bloggingabout.net/blogs/mglaser/archive/2007/01/26/hosting-rep...)
for more info. If SharePoint/PS is not configured to use the FQDN
either, you will need to adjust the Alternate Access Mappings.

Let me know if this resolves the problem!

--

Stephen Sanderlin

Principal Consultant

MSProjectExperts

For Project Server Consulting:http://www.msprojectexperts.com

For Project Server Training:http://www.projectservertraining.com

Read my blog at:http://www.projectserverhelp.com/

Join the community at:http://forums.epmfaq.com









- Show quoted text -

Hi Stephen

Both servers are included in trusted sites, isn't this sufficient? If
I create a basic page in WSS and create a link to the SSRS report,
the report works fine, but the same link doesn't function in a web
part page.
The article I referenced above says the cause is:

The form element's submit() or onclick handler provides a reference
for two common functionalities blocked by Internet Explorer 7 and
Internet Explorer 8 due to a JavaScript URL:
- location.href
- window.open

However I don't know how to apply the remediation suggestion with the
context of the SSRS report.

I will review the blog you suggested but it does not seem relevant to
this problem.

regards

Mike

 

[Stephen Sanderlin]

Hi Mike,



Based upon your symptoms, it would not appear to be sufficient. Again,
without an FQDN, IE has no way of determining whether the two names are
within the same domain or not. Have you attempted to disable the
protection as described in the Error 1034 documentation and proven that
it is indeed the cross-domain protection that is the cause of your
issue?



With regards to modifying the report, I believe you would need to
customize the rendering engine of SRS in order to alter the JavaScript
it outputs. You may want to inquire in one of the SSRS newsgroups
concerning this, as I'm not intimately familiar with this process.
Another option would be to verify that Microsoft has not released a
patch to address this behavior, though I do not believe they have.



Short of doing that, I would recommend that you consider reconfiguring
the systems to use the appropriate FQDN.



Steve

--

Stephen Sanderlin

Principal Consultant

MSProjectExperts



For Project Server Consulting: http://www.msprojectexperts.com

For Project Server Training: http://www.projectservertraining.com



Read my blog at: http://www.projectserverhelp.com/

Join the community at: http://forums.epmfaq.com