In log files i have this error:
Throwing
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException:
AuthzInitializeContextFromSid: Win32 error: 5; possible reason -
service account doesn't have rights to check domain user SIDs.,
Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException:
The report server has encountered a configuration error.
SSRS has account type network service and it's running. I've created folder for writing pdf report, made folder as shared and gave Everyone group full control.
When I go to website where report is, everything is working, but when I add subscription for that report, I always got same error in log. I have running Sql profiler to catch callih procedure for report, but it's never called from subscription.
In ssrs configuration, I haven't specified delivery email because I don't need it.
You need to ensure that your service account has the Windows Authorization Access permission.
You can find more information on this here.
Also, whenever a new subscription is created, it is usually created under the account of the individual who is logged into the SSRS session that created it. This can be changed, and there are directions on how to do this here.
So, in summary, you need to make sure that the account the subscription is running under is in the Windows Authorization Access (WAA) group.
what am I do is set Subscription and Execution same with Service account, but I'm not use Subscription actually, but this fixed issue.
Related
I'm running SQL Server 2016 and have local reporting services running.
I can run my SSRS reports up fine and display them to screen.
I can also export them to PDF or to CSV but if I try to export to Word, PP or EXCEL I get:
Reporting Services Error
An error occurred during rendering of the report. (rrRenderingError)
An error occurred during rendering of the report.
The type initializer for 'MS.Utility.EventTrace' threw an exception.
Requested registry access is not allowed.
the same report works fine on other peoples machines in the office so I know it's not to do with the report itself.
I've tried
Has anyone else had this issue or know how I can shift it?
I just spent hours troubleshooting this in a fresh install of SSRS 2019 using an updated database from a prior version.
I'm using an execution account with low permissions and did not want to make it a full Local Admin permanently but I tried adding it, unsuccessfully.
I removed the account from unattended execution in Report Services Configuration Manager and suddenly was able to export to XLSX. I was not sure what the fallout would be for existing reports, so I was not satisfied with this solution either.
Elsewhere I saw a recommendation to use Process Monitor (procmon) to watch for registry key access denials, you can download it here procmon.
It was difficult to search all of the output but you can filter by registry key access, then look for the RS executables or the result ACCESS DENIED.
In my case, it was HKU\%service account sid%\Software\Microsoft\Avalon.Graphics, and granting the execution account (not the account that runs the service) Read access to this key resolved the issue.
I got the same issue. Check in the URL (once you click on excel) whether the format is EXCELOPENXML. If yes change it to EXCEL.
Then it will download and work correctly.
You can enable it to 'EXCEL' by default by changing the 'rsserverconfig' file under reporting services. It will download in 'xls' format not 'xlsx'
NOTE: This solution is a common workaround when rendering extensions fail to work due to your deployment configuration or environment.
RSServerConfig
C:\Program Files\Microsoft SQL Server Reporting Services\SSRS\ReportServer\rsreportserver.config
Look for the Render section, enable or disable the export formats that you want your users to have access to. see Rendering Extensions Overview on SQLDocs for more information on individual extensions.
<Render>
<Extension Name="WORDOPENXML" Type="Microsoft.ReportingServices.Rendering.WordRenderer.WordOpenXmlRenderer.WordOpenXmlDocumentRenderer,Microsoft.ReportingServices.WordRendering"/>
<Extension Name="WORD" Type="Microsoft.ReportingServices.Rendering.WordRenderer.WordDocumentRenderer,Microsoft.ReportingServices.WordRendering" Visible="false"/>
<Extension Name="EXCELOPENXML" Type="Microsoft.ReportingServices.Rendering.ExcelOpenXmlRenderer.ExcelOpenXmlRenderer,Microsoft.ReportingServices.ExcelRendering" Visible="false"/>
<Extension Name="EXCEL" Type="Microsoft.ReportingServices.Rendering.ExcelRenderer.ExcelRenderer,Microsoft.ReportingServices.ExcelRendering" Visible="true"/>
…
<Render>
I had the same issue in SSRS2016 on a clean install of Windows Server 2016 & SQL 2016 with SSRS with all SP's & CU's and windows updated applied.
To confirm my fix, the execution account was not a member of the local administrators group on the SSRS server, once added and stop/start of SSRS, I am now able to export to Excel & Word, not the most secure way of getting it working but better than enabling the depreciated Excel 2003.
I had the same issue in SSRS 2019, and the fix was quite easy.
In Report Server Configuration Manager > Service Account, I had it set to "Use built-in account" = "Virtual Service Account".
I changed to "User another account", and selected a local users who is part of the Administrators group.
NOTE: This is NOT the Execution Account. This is for the Service Account.
You could be getting this error in Excel because the maximum number of rows that can be put in an excel sheet is 65536. If your data has more rows than that it will throw that error.
I'm working on integrating a report into a browser, and I get this error:
An error has occurred during report processing. (rsProcessingAborted)
Cannot create a connection to data source 'dsFederatedSample_SurveyLevel_STG'. (rsErrorOpeningConnection)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
Does this have to do with SQL vs Windows authentication?
First thing I would try is to get a bit more information on the error - that's a pretty generic message.
You could enable remote errors as per the error message and replicate the error for more information.
Or check the Report Server error logs to see what error was logged.
%programfiles%\Microsoft SQL Server\<SQL Server Instance>\Reporting Services\LogFiles\
The next step would be to connect as the Data Source user to the database, run any code/stored procedures that the report is using with the same parameters you're using when running the report, and see if any errors occur. Make sure the account you are using has permission and that you have entered the name and password correctly in the Data Source.
In SQL Server 2008 in addition to the above two options you have a third option to make this setting through SQL Server Management Studio.
1.Start Management Studio and connect to Report Server Instance (make sure you select 'Reporting Services' server type).
2.Right click on the ReportServer and Select Properties
3.Click Advanced
4.In EnableRemoteErrors, select True.
5.Click OK.
I had the same issue "Cannot create a connection to data source...Login failed for user.." on Windows 8.1, SQL Server 2014 Developer Edition and Visual Studio 2013 Pro. All solutions offered above by other Stackoverflow Community members did not work for me.
So, I did the next steps (running all Windows applications as Administrator):
VS2013 SSRS: I converted my Data Source to Shared Data Source (.rds) with Windows Authentication (Integrated Security) on the Right Pane "Solution Explorer".
Original (non-shared) Data Source (on the Left Pane "Report Data") got "Don't Use Credentials".
On the Project Properties, I set for "Deployment" "Overwrite DataSources" to "True" and redeployed the Project.
After that, I could run my report without further requirements to enter Credentials. All Shared DataSources were deployed in a separate Directory "DataSources".
In my case, this was due to using Integrated Windows Authentication in my data sources while developing reports locally, however once they made it to the report manager, the authentication was broke because the site wasn't properly passing along my credentials.
The simple fix is to hardcode a username/password into your datasource.
The harder fix is to properly impersonate/delegate your windows credentials through the report manager, to the underlying datasource.
The issue is because your data source is not setup properly, to do that please verify your data source connection, in order to do that first navigate to Report Service Configuration Manager through
clicking on the start -> Start All -> Microsoft SQL Server ->Configuration Tool -> “Report Service Configuration Manager”
The open Report Manager URL and then navigate to the Data Source folder, see in the picture below
Then Create a Data Source or configure the one that is already there by right click on your database source and select "Manage" as is shown below
Now on the properties tab, on your left menu, fill out the data source with your connection string and username and password, after that click on test connection, and if the connection was successful, then click "Apply"
Navigate to the folder that contains your report in this case "SurveyLevelReport"
And Finally set your Report to the Data Source that you set up previously, and click Apply
if you use null values in your stored procedure, you will need to set the parameters to accept null values. That worked for me.
In my case I had in one report many different datasets to DB and Analysis Services Cube. Looks like that datasets blocked each other and generated such error.
For me helped option "Use single transaction when processing the queries" in the CUBE datasource properties
I had a similar problem, and being the newbie that I am it took me a while to figure out but I learned the user must have a login in SSMS. I created the logins with the following parameters:
Under Server Roles - check sysadmin
Under User Mapping - I selected the database and the report server. For each I checked datareader and datawriter
Under Securables - I checked anything that would allow the user to connect to the database and view anything
I also found that one of the existing logins had denydatareader and denydatawriter checked. Once I removed these it worked.
I'm not saying this is the best way to do it, just what worked for me. Hope this helps
More information will be useful.
When I was faced with the same error message all I had to do was to correctly configure the credentials page of the DataSource(I am using Report Builder 3). if you chose the default, the report would work fine in Report Builder but would fail on the Report Server.
You may review more details of this fix here:
https://hodentekmsss.blogspot.com/2017/05/fix-for-rserroropeningconnection-in.html
I had the exact same issue.
The cause could be different but in my case, after trying several different things like changing the connection string on the Data Source setup, I found that this was the infamous 'double hop' issue (more info here).
To solve the problem, the following two options are available (as per one of the responses from the hyperlink):
Change the Report Server service to run under a domain user account, and register a SPN for the account.
Map Built-in accounts HTTP SPN to a Host SPN.
Using option 1, you need to select 'Windows' credentials instead of database credentials to overcome the double hop that happens while authentication.
I am trying to schedule the delivery of a report to a shared folder in a workgroup(without domain). But I keep getting the error message of
Failure writing file: A logon error occurred when attempting to access the file share. The user account or password is not valid.
I have tried several combinations of acounts with or without ComputerName:
ShareAccount
Share\ShareAccount
Server\ServerAdmin
Server\ShareAccount
And I have created an identical account with same password on both side.
Also, have tried set and unset unattended execution account with server administrator account.
I am sure the shared folder can be accessed with the same UNC path and account in windows explorer. Not sure what else I can try.
Is there anybody successfully do the file share delivery without domain? Or any other way I can schedule to export a report?
This feature works fine in SSRS so it is your settings which are wrong.
You will also want to have the subscription run as a specified user.
Create a local user on the computer to where you wish to save your report. Call it ReportUser.
For the purposes of this answer, we will call the the computer where you wish to save the report FileServer.
ReportUser needs write access to the share you are trying to use.
Try your report - if it still doesn't work then:
Launch Windows Explorer but Run As your new ReportUser - you will need to enter the password you have just created.
Navigate to the share by typing \\computername\fileshare - this proves your share is setup correctly.
Right click in the folder and create a new text document. this proves you have write permission to the folder.
Successfully completing those steps will mean that SSRS will be able to write to the share.
Within SSRS you need to be writing to:
\\computername\fileshare
The username will be \FileServer\ReportUser with a password that you have just created.
One more thing - run the schedule straight after your test - to prove something isn't happening to the network, e.g. overnight maintenance etc.
Environment: All machines are Windows Server. SSRS SQL Server 2016 version on one machine (SSRS service is the sole process running there). SSRS catalog on another machine that hosts SQL Server 2016. File delivery to a third machine.
On the SSRS machine (the one hosting the Reporting Services service), create a local account.
On the receiving machine (the one where the file will be delivered), create a local account with the same name and password as above. Also on the receiving machine, share a directory and grant read/write permissions to the local account just created.
On the Subscription tab of the Report Manager interface (or whatever is used to create a subscription), for the "Credentials used to access the file share" setting, select "Use the following Windows user credentials". Enter the name of the account created above, but do not prefix it with anything ("FILESERVER\ShareDeliveryUser" bad; "ShareDeliveryUser" good). Enter the password.
I tried numerous combinations, including attempting to use the "file share account," but this was the only way that worked.
Strangely, on the Report Manager interface, the "Result" of the last run always shows "Failure writing file...", although the file is indeed delivered.
Attributing original answer to post by user ExoStatic here https://social.msdn.microsoft.com/Forums/en-US/bdc5b51c-444b-442d-9657-3cf5495e79d0/file-share-delivery-failing#7725882e-d7c6-4b3d-88f6-2620409c3d48. Edited for clarity.
I'm working on integrating a report into a browser, and I get this error:
An error has occurred during report processing. (rsProcessingAborted)
Cannot create a connection to data source 'dsFederatedSample_SurveyLevel_STG'. (rsErrorOpeningConnection)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
Does this have to do with SQL vs Windows authentication?
First thing I would try is to get a bit more information on the error - that's a pretty generic message.
You could enable remote errors as per the error message and replicate the error for more information.
Or check the Report Server error logs to see what error was logged.
%programfiles%\Microsoft SQL Server\<SQL Server Instance>\Reporting Services\LogFiles\
The next step would be to connect as the Data Source user to the database, run any code/stored procedures that the report is using with the same parameters you're using when running the report, and see if any errors occur. Make sure the account you are using has permission and that you have entered the name and password correctly in the Data Source.
In SQL Server 2008 in addition to the above two options you have a third option to make this setting through SQL Server Management Studio.
1.Start Management Studio and connect to Report Server Instance (make sure you select 'Reporting Services' server type).
2.Right click on the ReportServer and Select Properties
3.Click Advanced
4.In EnableRemoteErrors, select True.
5.Click OK.
I had the same issue "Cannot create a connection to data source...Login failed for user.." on Windows 8.1, SQL Server 2014 Developer Edition and Visual Studio 2013 Pro. All solutions offered above by other Stackoverflow Community members did not work for me.
So, I did the next steps (running all Windows applications as Administrator):
VS2013 SSRS: I converted my Data Source to Shared Data Source (.rds) with Windows Authentication (Integrated Security) on the Right Pane "Solution Explorer".
Original (non-shared) Data Source (on the Left Pane "Report Data") got "Don't Use Credentials".
On the Project Properties, I set for "Deployment" "Overwrite DataSources" to "True" and redeployed the Project.
After that, I could run my report without further requirements to enter Credentials. All Shared DataSources were deployed in a separate Directory "DataSources".
In my case, this was due to using Integrated Windows Authentication in my data sources while developing reports locally, however once they made it to the report manager, the authentication was broke because the site wasn't properly passing along my credentials.
The simple fix is to hardcode a username/password into your datasource.
The harder fix is to properly impersonate/delegate your windows credentials through the report manager, to the underlying datasource.
The issue is because your data source is not setup properly, to do that please verify your data source connection, in order to do that first navigate to Report Service Configuration Manager through
clicking on the start -> Start All -> Microsoft SQL Server ->Configuration Tool -> “Report Service Configuration Manager”
The open Report Manager URL and then navigate to the Data Source folder, see in the picture below
Then Create a Data Source or configure the one that is already there by right click on your database source and select "Manage" as is shown below
Now on the properties tab, on your left menu, fill out the data source with your connection string and username and password, after that click on test connection, and if the connection was successful, then click "Apply"
Navigate to the folder that contains your report in this case "SurveyLevelReport"
And Finally set your Report to the Data Source that you set up previously, and click Apply
if you use null values in your stored procedure, you will need to set the parameters to accept null values. That worked for me.
In my case I had in one report many different datasets to DB and Analysis Services Cube. Looks like that datasets blocked each other and generated such error.
For me helped option "Use single transaction when processing the queries" in the CUBE datasource properties
I had a similar problem, and being the newbie that I am it took me a while to figure out but I learned the user must have a login in SSMS. I created the logins with the following parameters:
Under Server Roles - check sysadmin
Under User Mapping - I selected the database and the report server. For each I checked datareader and datawriter
Under Securables - I checked anything that would allow the user to connect to the database and view anything
I also found that one of the existing logins had denydatareader and denydatawriter checked. Once I removed these it worked.
I'm not saying this is the best way to do it, just what worked for me. Hope this helps
More information will be useful.
When I was faced with the same error message all I had to do was to correctly configure the credentials page of the DataSource(I am using Report Builder 3). if you chose the default, the report would work fine in Report Builder but would fail on the Report Server.
You may review more details of this fix here:
https://hodentekmsss.blogspot.com/2017/05/fix-for-rserroropeningconnection-in.html
I had the exact same issue.
The cause could be different but in my case, after trying several different things like changing the connection string on the Data Source setup, I found that this was the infamous 'double hop' issue (more info here).
To solve the problem, the following two options are available (as per one of the responses from the hyperlink):
Change the Report Server service to run under a domain user account, and register a SPN for the account.
Map Built-in accounts HTTP SPN to a Host SPN.
Using option 1, you need to select 'Windows' credentials instead of database credentials to overcome the double hop that happens while authentication.
I get the following error when trying to run reports:
The current action cannot be completed. The user data source credentials do not meet the requirements to run this report or shared dataset. Either the user data source credentials are not stored in the report server database, or the user data source is configured not to require credentials but the unattended execution account is not specified. (rsInvalidDataSourceCredentialSetting)
By the way I am running it from VS2010 with SQL Server 2008 Reporting Services.
How do I solve this issue?
Yes, I've seen this. You can set the Credential and Connection Information such that a report is run impersonating the unattended user account. This article explains how to set up this type of report running. This setup is especially useful if you want to use the credentials inside a dynamic connection string (for example when you need to insert the credentials through a parameter).
If you don't want to run using the unattended user account, you should review your DataSource and connection string as defined in the report. Perhaps play around with the settings and different configurations for the datasource to create a different setup. The above links should be a start for some documentation.
In my case, it was because of some deployment parameters.
Go to Project Property by Right-clicking at the Project name in Solution Explorer and select Properties.
In Configuration Properties > General, change OverwriteDatasets and OverwriteDataSources in Deployment section to True for both parameters.
Click OK.
in my case, replacing linked server connections with local (fetched from remote locations and stored in local tables)data connections helped. we also checked this for ALL subreports/linked reports and it worked fine.
This happened to me today, it was because I was using the wrong datasource in my report. So I changed the datasource manually in Report manager and it worked. I guess another choice is to redeploy your report with the correct datasource.
This happened to me today. I am using Visual Studio 2019 for creating the reports for SQL Server 2014.
One of my reports had an embedded data source, but it was unconfigured/not configured properly. (You can see embedded data sources in the "Report data" pane under "data sources").
However, the embedded data source wasn't actually being used. I created the embedded data source earlier for debugging and forgot about it.
After deleting the unused embedded data source, the error went away.
This is from Microsoft:here
User Action
Change the settings for the current report so that it can run unattended, and then try to create the subscription or other scheduled operation again. Use the following steps to configure a report to run unattended:
1) Go to the Data Sources properties page of the report that you want to automate.
2) For the Connect Using option, select Credentials stored securely in the report server.
3) In User Name and Password, type credentials that can be used to access the database. If you are using SQL Server as the data source, the user name must be valid for both logging on to the server and for accessing the database that contains the data for the report.
4) If the user name and password are credentials for a Windows account, select Use as Windows Credentials. If the credentials are for a SQL Server user login, do not select this check box.
Do not select the check box Impersonate the authenticated user after a connection has been made to the data source, regardless of authentication type. This option cannot be used for reports that run unattended.