I have two pairs of servers, one web server one DB server in each pair. I installed SQL Server 2008 in my DB servers and everything works, but reporting services only works in one.
In one of my servers, reporting service refuses to deploy my reports to http://xx.xx.xx.xx/ReportServer and says "Unable to deploy the server check to make sure target url is correct..." However it works fine in the other server.
What are the possible conditions for a reporting service to refuse deployment??
Does it require IIS to deploy? Are there some sort of port 80 restrictions on one of the servers making it unable to deploy?
Any ideas??
check your rights on the server you can't deploy to.
also, go onto the server where you can't deploy to and double check the url for the web service in reporting services configuration
Related
Mystery of the Day:
I have two users who access SQL Server Integration Services remotely from their local machines. User 1 successfully connects using the Integration Service server type in SSMS. User 2 gets this error:
Note that 2005 is mentioned in the error, tho user 2 does not have 2005 installed. Both User 2 and the server are running 2014. Both users have the same persmissions on the remote server, and both are admins on the server. User 2 also gets this error when connecting to SSIS on the server, however, she is able to connect successfully when running SSMS as an administrator on the server. Here are some things that we've already tried:
Confirmed that User 2 is using a lower version of SQL than the version on the server.
Matched both users SSMS permissions to each other.
Added User 2 to the server's DCOM.
Restarted SSIS service on the server.
And this:
We suspect there may be a version issue between local and remote installations, but not sure what to check in that regard. There many similar posts to our issue, but we have combed through without success. Hoping someone can help here.
Thank you.
I changed the default logon of the SQL Server Integration Services 15.0 service to be the NT account on the VM I was given and was able to connect to Integration Services after a service restart.
I am trying to install the Reporting role In SCCM but I have a lot of issues while trying to connect to the reporting server because I dont know about SQL :( ..
The reporting role is installed in a diferent server than the sccm and is working fine, there is acces to the https and http urls.
I have dissabled the firewall in both server for testing purposes but I am getting a message that says the conection string is not valid.
I have tested setting up the reporting database name or the SCCM database name but y cant get along the error.
When install a Reporting Services point on a remote Site System, you need to be sure that the Report server must host SQL Reporting Service. Reporting Services connects to the Configuration Manager site database to retrieve data that is returned when you run reports. So in your screenshot above:
Site Database Server Name: Your site database Server Name (If not default instance, specify instance name)
Database Name: Your site Server database Name
Typically the wizard automatically retrieves the site database server FQDN and SQL database name.
Reporting Services Server Instance: Reporting service instance Name on remote server
User Name: Specify a account that Reporting Service use to connect to Site Database to retrieve data.
If you go through Microsoft Website, you'll get full detailed step by step guide at: InstallReportingServicesPoint
We three application servers and three database servers. We're trying to enable Kerberos authentication between the application servers and the database servers. All of the application servers can successfully connect to two out of the three database servers. The app servers are using Windows 2008 and Windows 2012 with IIS 7.0.
The database servers are using Windows 2012 and SQL Server 2008 R2. We can't figure out what is different between the two SQL Server instances that work and the one that does not. The one that does not appears to not be receiving tokens as it is reporting an anonymous login.
Everything is on the same domain. I am using Kerberos in order to allow IIS to impersonate the client user. We have a production app & database server and a test app and database server. We're trying to setup a training/QA app and database server. None of the app servers have any difficulty connecting to either the live or test database servers. All of them fail to connect to the QA database server. We're trying to track down what is different on that server.
I am developing a report in PowerBI Desktop based on data hosted in an Azure SQL Server VM.
When publishing a report, I get the below error:
Publishing succeeded, but the published report cannot connect to the
data source because we were unable to find a gateway. Please install
and configure an enterprise gateway
I believe this is because the enterprise gateway is installed locally on my azure VM, however I'm accessing it from my desktop by going over the web and through the firewall. Therefore I believe the issue is that my pc acceses the machine at
mymachine.cloudapp.net
Whilst the enterprise gateway knows the machine as
netbios-name
Is there any way that I can upload a desktop report to powerBI web using this configuration? The other solution would be to get the machine and sql server to identify itself as "mymachine.cloudapp.net" so that I can use this as the name to connect to through the enterprise gateway, but I'm not sure how to do that (adding the alias to SQL Server isn't enough).
It's a bit hacky, but I've got a work around.
Open the server and edit your hosts file and add the following line:
127.0.0.1 mymachine.cloudapp.net
Make sure that mymachine.cloudapp.net has been configured in SQL Server as an alias.
In PowerBI, add a new enterprise gateway data source, this time, use mymachine.cloudapp.net to connect rather than netbios-name. You will need to use SQL Authentication to connect.
Obviously connecting PowerBI to an Azure VM in this way is not ideal, as it could potentially be unencrypted, but this works around the issue of different host names between PowerBI Desktop and Web.
I was going to process the cube deployment and found the error.
I changed the target server name from 'localhost' to this,and tried different way but in vain.
Here is the snap from my SSMS
You may have multiple issues going on but the first and foremost is you do NOT deploy SSAS Multidimensional [MDX] models to a SQL Database Engine Instance!
Unless you have a very odd configuration ATI-PC\MSSQLSERVER should point to the default MS SQL Server Database Engine Instance NOT an SSAS MDX instance!
The SSMS screen shot you show is for the local host connection you show is for a Database Engine with SQL Server Authentication (SA), which I would assume the instance is called MSSQLSERVER which is the default instance name.
1) What is your SSAS instance name?
2) Does your windows account have permissions? SSAS doesn't allow for SQL server authentication so it must be windows authentication.
3) Is SQL Browser running?
4) Have you configured SQL Browser to allow for the protocols and to allow connections from both Localhost and ATI-PC(InstanceName)?
to connect to Analysis Services Change the Server Type. When first launching SSMS you can do that via changing server type and then modifying the server name to the appropriate name.
If your SSMS is already open you can select "Connect" drop down and choose Analysis Services.
Check on your SQL Browser Configuration by Launching "SQL Server (Version) Configuration Manager" then step through the different areas as far as how to configure it is somewhat self explanatory and because you are deploying an AdeventureWorks cube I would surmise that the configuration would be earlier in you tutorial you are working on.
I am sure that you have 'SQL Browser' service running in services.msc. Still I doubt your account which you logged in has access to SSAS and also to connect to that underlying SQL Server. Try checking both for the access, if you selected deploy as service account check that account has access in SSAS. If still you have issues trying checking the eventvwr if you are getting any more errors. If it is development box try recycling SSAS services and try deploying?