We have two instances of SSRS 2016 installed, as one of them requires Windows authentication and the other requires custom authentication. The latter follows all the latest direction from the sample everyone references, except that it leverages a REST call to a separate authentication API we use for our applications rather than creating a user DB just for this use. We have given ourselves all permissions via the web portal, using the user account from this separate authentication API. Everything works fine until we finally try to execute a report and receive the error,
Could not load file or assembly 'Microsoft.ReportingServices.ProcessingObjectModel, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. Access is denied.
We've found nothing referencing such an error and are stumped at this point. Any help would be greatly appreciated.
I had ran into this exactly same issue, and the cause was permissions setup for the execution account. I was providing him with admin permissions and full control setups on the folder, and file but the issue persisted. The solution was to remote desktop on the machine with the execution user account and acess the REport Server bin folder. With this the pop up to gain permanent admin permissions on it showed, and accepting this lifted the issue.
It took me days to nail this down, which seems like a bug. so I thought of posting this. I hope this helps.
Related
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 running into an error I just can't solve. I'm trying to host my website through an external hosting company.
Most reports consist of a server side permission issue but my hosting doesn't think that is the issue and won't budge on the idea.
Here is the message I'm getting:
Description: The application attempted to perform an operation not
allowed by the security policy. To grant this application the
required permission please contact your system administrator or change
the application's trust level in the configuration file.
These are the suggestions I got send through from my hosting company:
Change to "On"
<customErrors mode="Off"/>
Your connection is also referencing a database called
aspnet-Foundation-20151005115145.mdf however I cannot locate this
file, it's likely your database connection string is incorrect as its
trying to connect to a local database.
My database isn't active and is commented out in the Web.config file so this shouldn't be playing a part in the problem, right?
What's the best way to troubleshoot this issue?
Edit:
I have just added the following to the Web.config file to no avail.
<securityPolicy>
<trustLevel name="Medium" policyFile="web_mediumtrust.config" />
</securityPolicy>
I'm using BIDS (Visual Studio 2008) to create and deploy SSRS reports to a report server, on a third-party hosted server.
The username and password that it uses to deploy reports onto the report server seems to be saved somehow, and I don't seem to be able to change it. Is there a way of changing this account? I'm getting a rsAccessDenied as expected. Previously it has asked for a username and password. To confirm, I'm getting this in the Error List pane:
The permissions granted to user 'SERVERNAME\ssrs' are
insufficient for performing this operation.
I can't start the software using these credentials as they only exist on the server. I can't change the permissions of this "fixed" account either as it's used by staff for read-only viewing of the reports. I already have an account for writing to the server that I would use if this software would let me.
I've looked at every setting I could find and I've tried creating a new solution, copying the report I need to deploy to this solution, but it still doesn't ask me for credentials.
The credentials were saved in Windows Control Panel -> Credential Manager (I'm on Windows 7). Just edit or delete the "Windows Credentials" for the server. For me, these credentials were, I think, saved by Internet Explorer rather than BIDS, but BIDS is happy to use them anyway.
I have created a folder that all users have full control over. In this folder is my backend, while the frontend resides on the local hard drive. I can open the database on my development computer, even over the network. On all other computers, the system simply loads the access welcome screen, or access opens and closes automatically.
Can there be virus protection or a firewall blocking this? I have enabled network connections, and allowed all vba projects, etc.
Can there be a reference issue? If I have a reference for an Outlook library, and have compiled the file into accde format, would this prevent any error messages and simply cause the database to fail? I can open the backend tables on all computers, it is just the frontend that will not open.
Any suggestions will be helpful. I am not at the site, so I will take all suggestions and try them when I return.
A few things come to mind:
Have a look in the Windows Event Log.
Another issue could be happening if the locations where the front-end is located has not been added to the list of Trusted Locations in MS Access.
If you put the accdb front-end on the user's machine, can it be opened? Do you get any error?
As you mentioned, there could be a reference issue. Try to remove the reference and convert your early-binding with late binding instead (use CreateObject).
Add some sort of logging to your application and log as much as possible to a text file from the startup sequence of your application. This may let you know if there is some of your startup code that fails.
In my development environment, every time I reboot windows (which must be done at least daily for me), all of my Shared SSRS Datasources lose their credentials.
Currently I have them set up to log into the database using a fixed credential, but on reboot all the datasources pop over to using no credentials. Granted, it's only in the dev environment, and I can just check out/update the datasource/check back in and it will work fine... until I reboot again.
FYI, I've been using these Shared Datasources for at least 2 years and no problems, but in the last month or so, it's been a recurring daily problem.
Help?
I'm assuming you are talking about the Shared Data Sources in a Report Server project in Visual Studio, as opposed to a Data Source created directly on Reporting Services. The latter, the data is stored all in the ReportServer database that was specified when setting up SSRS.
Now, as for the .rds file used in Visual Studio, if you open the file up in a text editor, notice that the username and password is not stored in the file. It is actually stored in the .rptproj.user file. So, check that someone didn't remove the .user file from source control (.user files shouldn't be in source control, but in your case...).
This is scenario is testable by entering your credentials, saving all files, and exiting Visual Studio. Find and delete the .rptproj.user file, and open your Report Server project up again and see the credentials gone!
A work around is add the "User ID=user;Password=pass" as part of the Connection String. When the .rds is opened up, the Connection String won't show this portion, but the Credentials tab should have the right values.
Could this be related to the boot order of services on your machine.
Just a guess: Maybe there is new functionality in SP3 that checks if the connection credentials are valid. If they are not valid they are cleared.
The problem would then happen if this check is done before SQL server has had time to start. This would explain why they are cleared when the machine restarts.
I have recently experienced the same problem, but I can't connect it to a reboot. It seemed to happen when I checked the solution from source control - we use Team Foundation Server. After disabling the service account a bazillion times, it somehow healed itself and began behaving. I found this post and checked my project folder for the rptproj.user file that benson mentioned, and it has a modified date of the day I had problems, but a create date of close to what I can remember as having created the project, so I will pay attention to this in the future.
Did anyone come up with anything new on this issue?
I realize you may have read this already, but something here could help? http://msdn.microsoft.com/en-us/library/ms159846.aspx
I would pay attention to how the SSRS was installed and also what accounts the servies run as, as well as an domain logon policies.