Issue with SQL Server 2012 Reporting Services - sql-server

Preface: Installed SQL Server 2016 RC0 and installed and configured Reporting Services all fine, thoughts maybe on potential conflicts with existing SSRS instances?
Issue with SQL Server 2012 Reporting Services, every time I navigate through the configuration manager to either the Web Service URL or the Report Manager URL, I get the following errors:
Report Manager URL returns
HTTP 500 error
Console when opening the Report Manager URL returns
SCRIPT16389: Unspecified error.
http_500.htm (1,1)
HTML1524: Invalid HTML5 DOCTYPE. Consider using the interoperable form
!DOCTYPE html
.http_500.htm (1,1)
Web Service URL returns
The version of the report server database is either in a format that
is not valid, or it cannot be read. The found version is 'C.0.9.45'.
The expected version is '162'. (rsInvalidReportServerDatabase) Get
Online Help
Console when opening the Web Service URL returns,
GET http://localhost:8085/ReportServer_MYREPORTS 500 (Server Error)
To try and resolve this, i've already tried adding RSExecRole to RoleMembers under both ReportServer$MyReports and ReportServer$MyReportsTempDB.
Also tried recreating ReportServer database under the Config Manager, but get the following error.
Generating Database Script - Error:
Microsoft.ReportingServices.WmiProvider.WMIProviderException: An error occurred when attempting to connect to the report server remote procedure call (RPC) end point.
I can confirm that both RPC services, SSRS Services are running with no problems, and also restarted these services multiple times.
I have realised that my ReportServer$MyReports is missing the DBUpgradeHistory table.
Any thoughts?

This will fix the issue right away:
delete from dbo.ServerUpgradeHistory where ServerVersion=[The wrong or upgraded version]

In my case, there was no "ServerUpgradeHistory" table. I needed to install SSRS 2012 on a machine that already had SSRS 2016 to do regression testing for a client that doesn't want to upgrade their system.
What I discovered is that there are SharePoint settings that SSRS installs even if you don't install SharePoint or SharePoint Plugins on your box.
Here's what fixed the problem for me:
Navigate your File Explorer to C:\Windows\assembly\GAC_MSIL\
Note there are many directories in here that have nothing to do with SSRS. We will just focus on seven directories that appear to be related to this problem.
Navigate to Policy.11.0.Microsoft.ReportingServices.Alerting
Enter the assembly directory. This is usually a series of digits followed by a hexadecimal identifier.
E.G. 13.0.0.0__89845dcd8080cc91
This path will vary based on what is installed on the machine
Backup the config file in case you need to roll back changes
E.G. from a Command prompt: COPY *.config *.bak
Open the config file.
Look for the text in the newVersion attribute of the bindingRedirect tag:
<bindingRedirect oldVersion="11.0.0.0" newVersion="13.0.0.0">
Modify this to use "11.0.0.0"
<bindingRedirect oldVersion="11.0.0.0" newVersion="11.0.0.0">
Save your changes
Repeat steps 2 through 8 with the following subpaths:
Policy.11.0.Microsoft.ReportingServices.SharePoint.Common
Policy.11.0.Microsoft.ReportingServices.SharePoint.ObjectModel
Policy.11.0.Microsoft.ReportingServices.SharePoint.Server
Policy.11.0.Microsoft.ReportingServices.SharePoint.SharedService
Policy.11.0.Microsoft.ReportingServices.SharePoint12.Server
Policy.11.0.Microsoft.ReportingServices.SharePoint14.Server
Reboot your computer

Related

SSRS Report fails when trying to run Oracle Stored Procedure

I have an issue whereby I can execute an SSRS report which calls an Oracle Stored Procedure in VS2017, but when I deploy to the SSRS Server and run, it returns the following message:-
• An error has occurred during report processing. (rsProcessingAborted)
o Query execution failed for dataset 'spTestSubDet'. (rsErrorExecutingCommand)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
The dataset 'spTestSubDet' is the Oracle Stored Proc.
Some configuration details:-
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
SSRS version is 15.0.19528.0.
SQL Server version is 2014.
I can execute SQL code and Views against the Oracle server with the same DSN from the deployed report (without the oracle stored proc being present), so I know the DSN configuration is not the issue.
I have also check marked the "Use single transaction when processing the queries" box in the DS Properties.
I’m guessing that it might be some form of “Execute” permissions issue on Oracle, rather than the Report Server, where the Stored Proc is concerned.
As a developer, I don’t have any DBA permissions to interrogate how the SSRS Server is set up, or the Oracle DB, so any suggestions will have to be passed on to my ICT dept.
I also can't enable "remote errors" on the Report Server, but have requested that with the ICT dept.
Any help greatly appreciated.
Seems I got lucky with enabling “Remote Errors” on the report server and not personally having to restart the service.
I now have a more explicit error message from the SSRS report:-
“ORA-06550: line 1, column 7: PLS-00306: wrong number or types of arguments in call to 'SPTESTSUBDET' ORA-06550: line 1, column 7: PL/SQL: Statement ignored”
As mentioned in my original post, the report works fine locally from VS2017, so I don’t know why it’s telling me when deployed and run from the server that there seems to be a problem with the SQL code:-
create or replace
PROCEDURE SPTESTSUBDET
(s1 OUT SYS_REFCURSOR)
IS
BEGIN
OPEN s1 FOR
SELECT
*
FROM
onemain.sbceysubmitted sbceysub
WHERE
sbceysub.STUD_ID = 167071
;
END SPTESTSUBDET;
It’s as simple a test as I can put together and doesn’t use any parameters to complicate things.
I’m wondering if it might be a driver issue, though why it works locally and not on the server is baffling me.
I have Oracle Developer tools “ODAC v18.3.0” installed for VS2017.
The user in the referenced post below had what looked like to be the same problem, but it's not clear what version of the ODAC tools has been used to resolve the issue:-
https://stackoverflow.com/a/60569788/2053847
Any thoughts/help greatly appreciated.
The easiest thing to do is check the log files. I bet this is a SQL exception and it is related to something wrong with the way you are calling the stored procedure or within the stored procedure itself. The log files reside on the SSRS instance at -> SQL SERVER INTALL DIR\MSSQL.15(OR OTHER SSRS VERSION DIR)\Reporting Service\Log Files. Log files for the SSRS manager and SSRS service are saved here. Open the log for the SSRS Service after you encounter the error search for "spTestSubDet" and you should see the detail of the exception that is causing your problems.

KingswaySoft SSIS error when Published - A password is required

I've created a package that gets some information from a sql database and inserts them into Dynamics CRM.
When testing the package from Visual Studio everything goes as expected and the task finishes without any errors and the rows get inserte . However , when I publish the package to SSISDB on Sql Server the package fails with this error :
KingswaySoft.IntegrationToolkit.DynamicsCrm.CrmServiceException : CRM service call returned an error : A password is required in order to establish the connection ...
I tried changing the package protection level to EncryptSensitiveWithUserKey but it still gives the same message as above , created the package again from scratch still doesn't work . This package was working before , maybe there's something I did the last time in configuration which made it work but I cannot replicate it anymore .
Also I tried the Integrated Authentication it says this :
KingswaySoft.IntegrationToolkit.DynamicsCrm.CrmServiceException : CRM service call returned an error : The caller was not authenticated by the service .
#Drinv, this is a typical SSIS runtime deployment issue. You need to make sure that you have provided a password for your job configuration for the connection manager. What you provided to the package doesn't count as far as sensitive fields are concerned (password being one) when you are using the EncryptSensitiveWithUserKey option since user key is not transferrable between different systems or different users. An easy workaround is to change your SSIS package/project's ProtectionLevel setting to encrypt using a password instead, although it may not be the best practice. If you still have trouble getting this going, please reach out to us directly, our team can walk you through the issue.
I found out what I was doing wrong .
My SSIS project was on Project Deployment Model and I was trying to deploy only the package. After making my connections available on project level and deploying the whole project everything worked as expected .

SQL Server 20XX - "encryption not supported on the client" when compiling stored procedure with linked server query

Attempting to compile a stored procedure in SSMS, which contains an open query to a linked server. The linked server is connected and in my 'Server Objects/Linked Servers' folder. I can do the open query in a query tab, but when the same query is ran within the procedure, I get the error
Encryption not supported on the client
This was just working yesterday, with no changes on my end, that I'm aware of.
I am using SQL Server 2014 locally on my machine, and the procedure is attempting to connect to a linked server with a "Pervasive" DB, located elsewhere. Not sure which version.
So far, I've tried rebooting and our SQL Server DBA is unaware of an issue on anyone else's machine.
I found the answer to this elsewhere... Not on Stack Overflow, so I wanted it here for convenience...
When this occurs, in regards to a linked server, it is due to the fact that the encryption required by the target server doesn't match that of the requesting server, so connection could not be established.
To remedy this issue, you can attempt to uninstall everything SQL related on your machine and reinstall... Or you can attempt the following:
Using Command Prompt / Powershell / Cortana, type, 'regedit' and hit enter.
In 'Registry Editor,' navigate to this location... 'HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\SNIxx.x' (The 'x's represent your version of SNI... "Sql Network Interface")
Backup the folder at the following location first, by clicking, 'File/Export' and save it wherever, 'HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\'
Whatever version of SNI you have, in my case 11.0, you will do a file level search and replace, in the file data below, for SNIxx.x, replacing the version number with your's.
Now in Registry Editor, click, 'File/Import' and navigate to the folder where you've saved your new file, double click it, or highlight it and click, 'open'.
Here is the data which needs to exist in that file...
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\ConnectTo]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\DB-Lib]
"AutoAnsiToOem"="ON"
"UseIntlSettings"="ON"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x]
"ProtocolsSupported"=hex(7):73,00,6d,00,00,00,74,00,63,00,70,00,00,00,6e,00,70,
00,00,00,76,00,69,00,61,00,00,00,00,00
"ProtocolOrder"=hex(7):73,00,6d,00,00,00,74,00,63,00,70,00,00,00,6e,00,70,00,
00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\GeneralFlags]
"NumberOfFlags"=dword:00000002
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\GeneralFlags\Flag2]
"Label"="Trust Server Certificate"
"Value"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\LastConnect]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\np]
"DLLname"="SQLNCLI"
"NumberOfFlags"=dword:00000000
"NumberOfProperties"=dword:00000001
"ProtocolName"="Named Pipes"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\np\Property1]
"Name"="Default Pipe"
"Value"="sql\\query"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\sm]
"DLLname"="SQLNCLI"
"NumberOfFlags"=dword:00000000
"NumberOfProperties"=dword:00000000
"ProtocolName"="Shared Memory"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\tcp]
"DLLname"="SQLNCLI"
"NumberOfFlags"=dword:00000000
"NumberOfProperties"=dword:00000003
"ProtocolName"="TCP/IP"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\tcp\Property1]
"Name"="Default Port"
"Value"=dword:00000599
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\tcp\Property2]
"Name"="KEEPALIVE (in milliseconds)"
"Value"=dword:00007530
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\tcp\Property3]
"Name"="KEEPALIVEINTERVAL (in milliseconds)"
"Value"=dword:000003e8
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\VIA]
"DLLname"="SQLNCLI"
"NumberOfFlags"=dword:00000000
"NumberOfProperties"=dword:00000002
"ProtocolName"="VIA"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\VIA\Property1]
"Name"="Default Server Port"
"Value"="0:1433"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\SNIxx.x\VIA\Property2]
"Name"="Default Client NIC"
"Value"="0"
I had a similar problem. The issue was that I had old versions of the SQL tools installed and the computer PATH was still setup to reference the 100 version before the 110 version.
For example, both 2008 and 2012 were installed.
C:\Program Files\Microsoft SQL Server\100\Tools\Binn
C:\Program Files\Microsoft SQL Server\110\Tools\Binn
Reference folder versions here:
SQL Server file names vs versions
I simply referenced the newer version and the problem was resolved.

How do I configure SSRS server to only send a report server URL?

I need to disable the option to attach a report in an SSRS subscription in SQL 2016. The only option that should be available is to send the report URL.
SSRS Subscription Setup
I am curious how to perform the recommended method from MSDN to "configure the report server to send only a report server URL" found in this article https://msdn.microsoft.com/en-us/library/ms160334.aspx.
I tried excluding a render format in my rsreportserver.config like this, but it didn't seem to do anything.
<ExcludedRenderFormats>
<RenderingExtension>PDF</RenderingExtension>
</ExcludedRenderFormats>
I have a test SSRS 2016 environment installed using SSRS Native mode but if needed, I can uninstall and re-install if necessary with a non-default configuration.
I figured it out. In the rsreportserver.config, find this element:
<Extension Name="Report Server Email" Type="Microsoft.ReportingServices.EmailDeliveryProvider.EmailProvider,ReportingServicesEmailDeliveryProvider">
Inside of that element is an element to add excluded file types. Just add all the supported file types and then the attachment option is effectively disabled.
<ExcludedRenderFormats>
<RenderingExtension>HTMLOWC</RenderingExtension>
<RenderingExtension>NULL</RenderingExtension>
<RenderingExtension>RGDI</RenderingExtension>
<RenderingExtension>PDF</RenderingExtension>
<RenderingExtension>MHTML</RenderingExtension>
<RenderingExtension>WORD</RenderingExtension>
<RenderingExtension>EXCEL</RenderingExtension>
<RenderingExtension>PPTX</RenderingExtension>
<RenderingExtension>IMAGE</RenderingExtension>
<RenderingExtension>WORDOPENXML</RenderingExtension>
<RenderingExtension>EXCELOPENXML</RenderingExtension>
<RenderingExtension>CSV</RenderingExtension>
<RenderingExtension>XML</RenderingExtension>
<RenderingExtension>ATOM</RenderingExtension>
<RenderingExtension>HTML4.0</RenderingExtension>
</ExcludedRenderFormats>
Finally, restart the SQL Server Reporting Services services.
Desired end result:

How to Remove a Ghost Server in Web Farm After Migrating a Reporting Services Installation?

Just followed the steps in https://msdn.microsoft.com/en-us/library/ms143724.aspx to migrate a Reporting Services installation onto a new server (from and to SQL 2012 Standard Edition)
But when I'm ready to verify my deployment using the Report Manager web interface I get the error:
The feature: "Scale-out deployment" is not supported in this edition of Reporting Services. (rsOperationNotSupported)
Indeed when I go back to the Reporting Services Configuration manager, under Scale-out Deployment I have 2 servers, the one on the local server (new machine) and a reference to the old Server that has a different name. Problem is when I try to remove it tells me the task has failed:
Microsoft.ReportingServices.WmiProvider.WMIProviderException: Unable to connect to the Report Server . ---> System.Runtime.InteropServices.COMException (0x800706BA): The RPC server is unavailable
I can understand why it's unavailable as it is on a different network all together. so my question is, how can I get rid of it so everything can finally work?
Found it. The way to remove the ghost server is to connect to the ReportServer database, and remove the old server from the dbo.Keys table.
After a restart of Reporting Services, the old server isn't in the list anymore.
USE ReportServer
go
select * from keys
--for safety added to the delete ghost machine if no recent executions in last 30 days.
delete from keys
where MachineName = 'YourGhostServer' --replace with your old server name, if multiple run one by one.
and MachineName not in (select substring(InstanceName,0,(charindex('\',InstanceName,0)))
from ExecutionLog
where timestart>getdate()-30
group by InstanceName)
CAREFUL, run the first part only with the select, analyze the output then copy the specific machine name value (old server name) you wish to delete into the where clause of the delete statement, replacing YourGhostServer verbiage.
Note, the Keys table may have legitimate machines that are network reachable and online. You can verify this by simply pinging them or checking if they run the SSRS Service, don't just simply delete from the table a server that's actually online, instead use the Report Server Manager to remove a Server that's online.
Deleting from the Keys table should only be done if the old machine is truly unreachable or has been decommissioned. At least, that's what I would do in my case. :)

Resources