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.
>
No comments:
Post a Comment