Reporting Services 2005 on Windows 2000 SP4 Domain Controller

Hi all,

I'm experiencing a problem with Reporting Services 2005 running on a Windows 2000 AD Domain Controller.

Installation has been done correctly, SQL 2005 and SSRS 2005 are running correctly (I've followed Microsoft KB911846 to solve the "not dtarting after installation" problem).

Accessing reports virtual folder (http://machinename/reports) from localhost, logged on with user Administrator Report Builder option displays correctly. Also accessing from LAN, but with user Administrator, displys Report Builder Option.

Report Builder button is not displayed with other users (i.e. user Dave)

I've given user Dave same permission as Administrator (Content Manager, in SSRS) but Report Buildr still can't be viewed.

If it can be userful to understand this strange behaviour, looking in "Reporting Services Configuration" tool I can see that Web Service Identity is reported as Not configured, with a beautiful red X besides.

Can someone please help me?

Thank you very much for any suggestion.

Regards,

Dave

Solved! :-)

Just had to set domain users as "System Users" in Report Server Management

Dave

Reporting Services 2005 Access Issue

Hi Everyone,

I've set all SQL services to run using a domain account which is a local administrator, I am able to view reports on the server but when someone from client machine connects to the server it prompts for user id and password and doesn't like unless I give a local server user who is also a local admin on box.

The app pools are also running using a domain a/c which is local admin but even we can't access reports even if I enter this ID from client machine. It is asking for a server user who is also an admin. I went ahead and added all domain users to the browser group but still no success.

The other problem I've is the link to report sent by Subscriptions service is broken, when I click on it I get a page not found error. How can we fix this?

Any help would be good.

Regards,

Sumit

Hey Sumit,

You might want to make sure you have 'Integrated Windows authentication' checked in Reports and ReportServer within IIS. Or you could have 'Enable anonymous access' checked.

Hope this helps.

Jarret

Reporting Server replacing IP address with ComputerName

Hello,
I am facing a strange situation with my reports server.
The machine i am testing the server on has no domain name, only IP.
But, of course, it has a computer name.
When i access the report server manager, i get everything as it should
be, and it shows me the links to the reports, but when i want to see
the report, the report manager replaces IP in the report address, with
the computer name - which makes no sense since i am accessing the
server using the internet.
Hence, i am getting an 404 in the report sub-page.
If i copy the url from there, and go to the page after changing the
computer name to the IP, it works, naturally.
Does anybody know how to change this behavior?
Thanks in advance! :-)
ShlomoYes you need to see this article:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rsadmin/htm/drp_deploying_v1_0h9e.asp
Scroll down to the section that says "Deploying a Report Server for Internet
Access"
=-Chris
<shlomoid@.gmail.com> wrote in message
news:1108301192.984825.325330@.o13g2000cwo.googlegroups.com...
> Hello,
> I am facing a strange situation with my reports server.
> The machine i am testing the server on has no domain name, only IP.
> But, of course, it has a computer name.
> When i access the report server manager, i get everything as it should
> be, and it shows me the links to the reports, but when i want to see
> the report, the report manager replaces IP in the report address, with
> the computer name - which makes no sense since i am accessing the
> server using the internet.
> Hence, i am getting an 404 in the report sub-page.
> If i copy the url from there, and go to the page after changing the
> computer name to the IP, it works, naturally.
> Does anybody know how to change this behavior?
>
> Thanks in advance! :-)
> Shlomo
>|||Thanks!
Worked perfectly.

Reporting Server Name Change

Hello all,
Our organization is looking into merging two AD domains into one domain and
as a result, we need to move a SQL Server 2005 server with Reporting
Services installed on it over to the new domain. In our lab environment, we
found that the SQL Server move was straightforward and presented no
problems. However, the Report Server migration isn't going over that easy.
Essentially, the SSL/TLS certificate needs to be reassigned to reflect the
server's new FQDN and it looks like the connection properties to the report
server is hard-coded to the old FQDN somewhere. Is there anyway to change
this? We're hoping that there's some simple setting someplace that defines
the connection properties, and something that we can change to reference the
new FQDN (and therefore the new SSL certificate name), but we've been unable
to locate it.
Thanks.Got it figured out, in the physical directory for the Reports and
ReportServer IIS virtual directories, there are files named
RSWebApplication.config and rsreportserver.config respectively. The URL
used to connect is defined in there. I changed the reference and restarted
the IIS service and things started working. Thanks anyway.
DLN.
"dln" <dnadon_nospm@.hotmail.com> wrote in message
news:%23llwmNGoGHA.608@.TK2MSFTNGP02.phx.gbl...
> Hello all,
> Our organization is looking into merging two AD domains into one domain
> and as a result, we need to move a SQL Server 2005 server with Reporting
> Services installed on it over to the new domain. In our lab environment,
> we found that the SQL Server move was straightforward and presented no
> problems. However, the Report Server migration isn't going over that
> easy. Essentially, the SSL/TLS certificate needs to be reassigned to
> reflect the server's new FQDN and it looks like the connection properties
> to the report server is hard-coded to the old FQDN somewhere. Is there
> anyway to change this? We're hoping that there's some simple setting
> someplace that defines the connection properties, and something that we
> can change to reference the new FQDN (and therefore the new SSL
> certificate name), but we've been unable to locate it.
> Thanks.
>