For many years we've had a reporting database that we have written our SSRS reports out of, which includes some linked servers. The linked servers are set up on the SQL instance where reporting services lives, as well as the main databases we use to report out of. We've decide to split off reporting service from the main server, and give it its own house.
I've setup SQL 2014 along with reporting services, and published my reports over there instead. All of the 'non-linked' reports work fine. However all the reports that reference a linked server (that used to work on the main server) now fail with the following error in the log file:
Access to the remote server is denied because the current security context is not trusted.
I thought maybe I needed to set up the linked servers on the new RS SQL server to get this to work. I had assumed that it would pass the entire query (including the linked part) over to the data source specified and my primary server would run it and return the data. Nevertheless, I set up the exact same linked servers on the new reporting services box... but still receive the same error.
All these reports worked just fine on the original server, however they all seem to be having issues on the new server no matter what linked server they are connecting to.
I am at a loss, and would love any ideas you guys may have.
Server A:
Main Data Source. This server contains the majority of our data and also housed our Reporting Services. This server has links to several other SQL servers that I was able to openquery to, and join the data to our main data source. We have many published reports that utilize the linked servers and have historically provided no issues.
Server B:
New SSRS box. This new server was set up in an attempt to off-load all of our reporting needs to another box thereby freeing up any resources required to run reports and SSIS packages. I took all of our existing reports and published them to the new server as-is. Initially I didn't think I would need to recreate the linked servers on this box, since those requests would be going to my main data source (Server A). I've tried both with, and without the linked servers existing on Server B, but get the same results. When the linked servers DID exist on Server B, I was able to query them directly with no errors. The services on Server B are running under the same credentials as those on Server A.
Well, I did some more digging and found my resolution. So the data sources have always been using the end users credentials to run the reports. On the old server, the linked servers use a hard coded SQL account to make the connection. This works fine so long as it is all on one server. However, when running from a secondary server it appears that this scenario will not work. Instead, I found that if I make the data source use the 'same' hard coded SQL account and the linked server to make the connection to Server A, the linked servers work fine.
Related
Using the following:
MS Access 2016, Office 365
SQL Server 2012
I have 100+ SQL Server tables and views linked into an Access database via ODBC connection. All of these SQL Server objects are from two SQL Server databases that reside on the same server. All of these connections have been set up using the Access user interface and re-linked via the Linked Table Manager.
I've been experiencing a number of Access database issues lately, so I’m combing through everything with a fine-tooth comb. I noticed that the connection strings for all my SQL Server objects have a number of inconsistencies (see below). There does not seem to be any pattern in terms of when these objects where created and the format of the connection string either.
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1;Network=DBMSSOCN
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database1
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database2
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database2
Is it problematic that there are so many variations of the connection string? I've done some research (i.e., Googling), but I don’t much experience in this area of databases. Some connections have a "Network" specified, but others don’t. Per connectionstrings.com (https://www.connectionstrings.com/define-sql-server-network-protocol/), “Network=DBMSSOC” specifies a Winsock TCP/IP connection, which I believe is the appropriate choice for my network setup. Is it problematic that this parameter is excluded from several of the connection strings?
I would most certainly “harmonize” all of the linked tables to the same connection.
You can use the linked table manager to do this, but likely code is better.
You need to select all tables in the linked table manager, and MAKE sure you click on prompt for new location. This will force you to create (or select) an existing DSN. In fact, I would select all tables from the “one” given database, and then click on the “always” prompt for new location. When you do this, then all will posies the SAME link and connection string.
There are good number of reasons, one good reason is Access will cache the connection for you. So if you have “different” connections for the same database, you will have multiple caches of those connections. This likely will not affect performance “much”, but it still a good idea.
And if you are NOT using a trusted connection, then your connection strings in fact do NOT need to include the uid/password. (However, the cache of the uid/password requires exact string matches (minus the uid/password). In this approach, you can execute a “one time” logon on application start up, and then all linked tables (without the uid/password) will now work. However, you using trusted connections here, so this tip + issue don’t matter.
In your example, you using trusted connections, so issues are “much” less of a worry or problem.
I also STRONG suggest that when you launch the ODBC manager from Access, that you ALWAYS but ALWAYS use a FILE dsn. The reason for this is that then Access will convert the connections to DSN-less for you.
This means that you can now deploy the front end application to any workstation, and you don’t need to setup or have any DSN connection copied, or even setup on the workstation.
So I would in fact select all of the tables for one given database, (check the prompt for new location), and then create a FILE dsn (they are the default anyway). Once you link, then do the same for all the other tables that point to the other database. Again re-link.
The result will be a dsn-less connection, and thus your application will work on any workstation on the network, and do so without having to setup a dsn of any kind on each workstation.
So yes, you don’t have to, but it seems over time, some tables were linked using a different DSN, they should be harmonized. And if you ever introduce some automatic linking code, you want to be able to distinguish between the two databases, and you code will have a rather difficult time doing this with a “hodge” podge of differing connections.
So you can use the linked table manger to harmonizing the connections – just ensure you select all tables from a single given database, and then re-link with a FILE dsn, the result will be a DSN less connection (access will ONLY use the DSN during the linking process – after that, access don’t care, nor does it use or even look at the DSN, or even if it exists.
Having said all of the above, it not clear if this issue is related to your errors, or instabilities in your application. (a good idea is to always distribute a compiled version of your application - (a accDE as opposed to accDB).
I have a SQL server reporting service production environment. I need to duplicate this environment on a totally different machine including the source data, let's call it Dev environment. I have backed up and restored both the source database (sourceDataDB) and the report databases (ReportServer and ReportServerTempDB) to this new machine. Re-configured the new reporting service to point to the new report database. Everything works except when I run a report, the report pull out data from the original source database instance instead of the newly created instance. Of course, I can manually modify the data source information from the Report Manager on the new report server. The challenge is every time the ReportServer and ReportServerTempDB got refreshed from the production database, the modified data source got replaced with the one from production environment.
I wonder if there is a way to automate the process of modifying data source information after each database refresh, either from the database end or from the report manager. I only have one data source that is shared with all the reports. This is a SQL Server 2008 R2
Thanks in advance.
I have been experiencing random connection/handshake problems w/ a hyper server VM running SQL and SSRS
So the network guys suggested building a new VM and trying it there. (Have you tried rebooting? )
I asked that they rename the old server (--> SQLBKUP) and name the new server to the current name (--> SQL) so all my connection strings will continue to work.
Regardless the wisdom of that approach, that is all now done.
All of our applications work. (and the weird handshake issue is gone,joy)
I have reinstalled SSRS and I thought I was home free.
We backed up and restored the ReportServer and ReportServerTemp databases to the new server.
If i try to point to these databases , I keep getting this error
The report server installation is not initialized. (rsReportServerNotActivated) Get Online Help
Any all information I can find about this for 2012 says that the initialization happens automatically when you configure a database.
I tried creating a new database, and presto, everything works fine.
I reconfigured SSRS to point at the old database and I again get the rsReportServerNotActivated error.
I also 'powered down' SQLBKUP in case it was causing some confusion, I cant imagine what that might be, but why not... This did NOT correct the problem.
Any ideas on why the databases that were working on 1 server wont work on the new one?
Searching the interweb for this issue I find two results for 2012 SSRS (many hits for 2005 issues/resolutions )
this article details how the RSExec role should be configured, I have verified that is all correct.
https://msdn.microsoft.com/en-us/library/cc281308.aspx
this article details the mechanics of various ways to move a database. The back up and restore operations went off w/o a hitch.
https://msdn.microsoft.com/en-us/library/ms156421.aspx
neither article mentions cleaning up any server names, ip addresses, etc. that might be in a config table. Inspecting the tables in SSMS, I dont see any tables that look like they might need such attention.
I can always recreate the environment, I am aout to that point, at least I will know what I have in front of me. If anyone has any suggestions, i would appreciate it, Im sure I will be up for a while... :-)
tyia
greg
You are getting that error because you haven't moved the old encryption keys to the new server. SSRS uses encryption to secure credentials and connection information. You'll need to get the encryption keys from the old server and restore them to the new one OR if you don't have the keys anymore you can create new ones but you'll need to setup your connection information again.
First backup your old encryption keys:
Start the Reporting Services Configuration Manager, and
then connect to the report server instance you want to configure.
Click Encryption Keys, and then click Back Up.
Type a strong password.
Specify a file to contain the stored key. Reporting Services appends a
.snk file extension to the file. Consider storing the file on a disk
separate from the report server.
Click OK.
Then restore the keys to the new server:
Start the Reporting Services Configuration Manager, and then connect to the report server instance you want to configure.
On the Encryption Keys page, click Restore.
Select the .snk file that contains the back up copy.
Type the password that unlocks the file.
Click OK.
You can also use the rskeymgmt utility, see the MSDN article: Back Up and Restore Reporting Services Encryption Keys.
If you don't have access to the older server you'll need to delete and recreate the encryption keys. Once you delete the keys the server will automatically re-initialize itself and you'll need to re-enter all of the lost encrypted information.
The following things will occur when you delete the encryption keys:
Connection strings in shared data sources are deleted. Users who run reports get the error "The ConnectionString property has not
been initialized." Stored credentials are deleted. Reports and
shared data sources are reconfigured to use prompted credentials.
Reports that are based on models (and require shared data sources configured with stored or no credentials) will not run.
Subscriptions are deactivated.
Steps to delete the keys:
Start the Reporting Services Configuration tool, and then connect to
the report server instance you want to configure.
Click Encryption Keys, and then click Delete. Click OK.
Restart the Report Server Windows service. For a scale-out
deployment, do this on all report server instances.
This is from MSDN - Delete and Re-create Encryption Keys. The article has a lot more useful information.
For more information also read Configure and Manage Encryption Keys
TThanks, for reading, I'll try to explain my issue in a detailed format as the question I'm asking is a bit high-level for my experience-level.
I'm using VS2005 and SQL Server 2005 with Reporting Services. All of my reports are built in VS2005. The reports are deployed to folders named "Amort" or :Amort_Test" on the Report server depending on the configuration I choose when I deply (Production delpoys to "Amort", Test deploys to "Amort_Test").
In Reporting Services Report manager, I have a data source setup call AMORT (and that is the datasource in my VS2005 reports). The datasource is of type Microsfot SQL Server and the connection string is "Data Source=uslibsql310;Initial Catalog=AMORT_P".
What I'd like to do is have the ability for the reports in the "Amort" folder point to a database called AMORT_P on my server (uslibsql310) while the reports in the folder "Amort_Test" point to the database called AMORT_T on the same server (uslibsql310). Obviously my current configuration, where reports in both folders point to the same datasource, says that reports point to the AMORT datasource which currently points to AMORT_P.
My initial thought was that I could create a new datasources, call it AMORT_Test and have its connection string be ""Data Source=uslibsql310;Initial Catalog=AMORT_P". However, every time I'd deploy my reports, I'd have to change the datasource in VS2005 to read AMORT_Test instead of AMort and then deply, which would be abit of a hassle.
Can anyone think of a more user-friendly solution to this? I'm one who normally finds the quickest solution and goes with it, but in this case I think there must be a way to set this up so that the reports in one folder know to pick one DB and the reports in another folder know to pick a different DB, but my current setup doesn't allow that. I'm not sure where to start in trying to figure this out as I'm a bit of an RS novice.
You're almost there, I think. If I understood correctly, here's your current setup:
One shared datasource
Reports all use that shared datasource for datasets
Two configurations: test and production, each with its own target folder
What you can do now is set OverwriteDataSources to False. Manual labor is required to set the connection string for deployed reports only:
For initial deployment of reports
When you want/choose to change the connection for deployed reports
This manual labor can be either:
Changing the connection string, temporarily enable OverwriteDataSources, and re-deploy
Going to the report manager web frontend to change the connection string
However, your default setup would be to deploy reports to both configurations, without having to worry about connecting test reports to production databases and vice versa.
Imagine you have 2 applications Application A and Application B.
Basically I would like to insert records that exist in Application A into Application B.
Sql Server Reporting Server is available on Application A
And I was wondering if it is possible to build a report that gathers the record that I need and then publish it as a web service so I can consume it on Application B and then do the inserts.
Application A and B are in two different web servers separated by the internet.
If this is possible could someone post a link that shows an example?
BTW: My experience with SSRS is null, but I have been a web developer for quite a while so I have a general understanding of what we could do I just need some one to point me into the right direction.
Thanks in advance.
SSRS is not designed to serve data to other webservers, it is designed to nicely layout and display data from one or more SQL servers.
It seems you can connect SSRS to external SQL servers when you have the right licensing. So if you want you application B to display data from both SQL servers you can use one SSRS report on computer B to display data from both.
However it seems you want to do inserts on computer B, using a report from computer A. I would not use a report for that, but a direct connection using ODBC, JDBC or another inter-database connection strategy - such as simply transferring plain-text files over FTP. The BCP utility is a power tool to output plain-text files from database queries. You could even run that directly from computer B, connecting to computer A.