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.
Related
Our team has setup a Windows Server to specifically run SSRS in it. We have the reports running well but we wanted to manage several tasks under the Browser role to get rid of a couple of things. I believe this can be accessed through SSMS by logging in to the Report Server. I did this just fine but when I'm trying to open the properties of the Browser role, it is grayed out and can't be selected. Am I doing something wrong here?
A couple of notes to clear things out:
I'm already using an admin account on the server
The Reporting Server is installed separately to a source DB from which we get to access data
I'm able to do this just fine when both Reporting Server and source DB are on the server
I'm using SQL Server 2016 with the same version of SSRS
We have figured it out. We just need to open SSMS as administrator. Might just be a user error of some sort as we do not need to do this on other servers. Thanks.
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 trying to deploy an SSRS report to a remote server (that is not on my network). I'm not sure how to do this. For a machine on my network, I would just change the TargetURL, but I'm guessing there should be somewhere that I can associate credentials to deploy to a remote server, but I'm not finding it.
I know this is an old post but if someone is wondering about the same question.
I am using vs2017 enterprise. So when you configure your remote url and folder name and everything is perfect to build your project, you hit F5 or deploy your project. Upon successful building vs will prompt you for your report servers credential. Then you do the usual and vs will do its own job. In a moment you will be able to access your report.
Just read about the permission requirements before you try it.
Hope it will help someone.
Thanks
I face a similar issue delivering reports to various servers (customers and dev,qa,staging and production.) In visual studio the best way to do it is start a new project for the new server and import the new reports into it. You end up with a new project for each server.
I found TFS / VS unwieldy and my workflow to manage it unfortunately is doing it manually, or using one of a few open source report uploading tools (there are powershell scripts to do it but I find the tools are more user friendly.)
Best thing to start with is doing it manually; which will sort your initial problem.
Save the file out of your report writer to disk.
In Internet Explorer log into the Report Manager of the remote server http(s)://remoteservername/reports and navigate to the folder you want. Then upload the report.
When its uploaded you may need to fix the connection to the database.
Once you get used to doing this you can use a tool like reportsync to easily and quickly move reports between servers.
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.
I'm trying to use MS Reporting Services. So far I have been able to create a simple report, using the AdventureWorks database.
Next step I wanted to take was to deploy my report. This is what I did:
In the Business Intelligence editor I right-clicked on the project name and clicked properties
I added a Start Item and I set the TargetServerURL to the URL that was displayed in the Reporting Services Configuration Manager. The URL is: http://ADMIN-PC:80/ReportServer
After that I clicked "OK" to go out of the Properties window. Then I hit Build Report Project1 in the Build menu.
After it tries to build it gives me the following error:
The specified report server URL: "http://admin-pc/ReportServer" could
not be found. Verify the syntax of the URL and that the report server
exists.
I'm sure the URL is correct. Or at least, that is what the Reporting Services Configuration Manager says.
So I have no clue what to check next in order to fix this problem. Anyone any idea what to do?
It's always tough to try and troubleshoot these general "it's not working" errors, but here's a rough idea of what I'd try looking at:
Is the service running? If you can connect through Reporting Services Configuration Manager then the answer is probably yes, but it's always the first thing to check!
Are the URLs correct? You may need to check you're using the correct URLs - these can be confirmed through Reporting Services Configuration Manager; by default Named Instances will have URLs like http://admin-pc/ReportServer_InstanceName and http://admin-pc/Reports_InstanceName.
Can I connect out of BIDS? What happens when you connect to http://admin-pc/ReportServer through Internet Explorer? What about http://admin-pc/Reports?
Are there permission issues? By default the only users that can access SSRS are those in the BUILTIN\Administrators group. Is your user in this group?
Is UAC mucking me up? As above, only Administrators will have default access, but if UAC is enabled you still won't connect as an admin even if you're in this group. Try running BIDS or Internet Explorer with Run As Administrator and see if it makes any difference.
Is the URL being registered successfully? The URLs won't work if the port is already in use, but Reporting Services Configuration Manager will quite happily allow you to set this without an error even if the port's in use; it's especially when using port 80.
Check the log file at Program Files\Microsoft SQL Server\<SSRSInstance>\Reporting Services\LogFiles; this will have an error logged if it can't register the URL on the port specified. If you see an error here try a different port.
Any other errors in the log? Failing this, check the log for any more errors.
Not much to go on, I admit, but maybe there's something you haven't looked at here. I'd saying stepping through these checks has solved 99% of the errors that I've seen in the past.