We are trying to use ssrs_migration.rss to migrate reports and subscriptions from one rs server to another
we are getting the error
This method explicitly uses CAS policy, which has been obsoleted by the .NET Framework. In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see http://go.microsoft.com/fwlink/?LinkID=155570 for more information.
however I cannot figure out what switch to use to get this to work
Related
So, I'm trying to figure out how best to go about exposing some reports on a SSRS server that's behind the firewall to users on an extranet site, as discussed here. My DBAs have set a constraint that I pass Windows credentials to the server to gain access, and that the server remain behind the firewall. I'm having trouble conceiving of how to do that and still maintain a secure system in a public-facing DMZ. Here are some of my questions:
How can I allow users to authenticate to AD while preventing brute-force account hacking? In other words, one option is to create an app in the DMZ that accepts a u&p, and attempts to authenticated against AD inside the firewall. However, I need to prevent repeat trying and failing.
Assuming I have an authenticated user, how do I pass that credential to the SSRS server? What languages or mechanisms exist to accomplish that? Does this have to be a .NET app or could I manage it through Java?
How would I accomplish permitting the user to interact with the SSRS server? I don't want to loose all the UI functionality of the reports, and I don't want to rewrite it either. It seems like a hack to write an app that acts as a proxy, but that's all I can think of. Ideas?
TIA
I am trying to use SSRS in a multi-tenant situation. The base version we want to support is SQL Server 2008 but if R2 is needed we might be ok with that.
I am currently using the ReportingService2005.asmx endpoint which seems to expose the ReportService2005SoapClient class (even though all samples seem to show ReportingService2005 class).
When we run a report I want to make a copy of that report from the server, add an embedded datasource, point the datasets to that datasource and then run the report.
I have gotten as far as:
getting the RDL from the server
modifying the XML to add the DataSource
pointing the datasets to point to the new datasource
...but when I try to "CreateReport" I get the following error:
System.Web.Services.Protocols.SoapException: The dataset ‘DataSet1’ refers to the data source “mydatasource_LOCAL”, which does not exist.
at Microsoft.ReportingServices.Library.ReportingService2005Impl.ExecuteBatch(Guid batchId)
at Microsoft.ReportingServices.WebServer.ReportingService2005.ExecuteBatch()
I have added the dataset to the RDL, it looks the same as when I add one in the designer. However, I assume something needs to be added to the server? What am I missing?
(As an aside, I know MS Dynamics enabled multi-tennant SSRS in a single instance, but I see no info on how they did it. If they have any code or anything they share someone could point me to that would be awesome.)
You're using the correct endpoint, more or less. From MSDN:
The ReportService2005 and ReportService2006 endpoints are deprecated in SQL Server 2008 R2. The ReportService2010 endpoint includes the functionalities of both endpoints and contains additional management features.
In any case, you mention you modify the RDL to use a new data source in step 2. I might be wrong, but I think you probably still need to add a DataSource item to your report catalog using the ReportingService2010 CreateDataSource(...) method.
If you deploy a new report from Visual Studio to report server it wil also mention in the log that it's deploying the data source before it deploys the report.
Of course you could also create that data source on the server beforehand, using the report manager (though "mydatasource_LOCAL" may not be an ideal name).
We have an environment where each of our clients has their own database instance (with identical schemas, for all intents and purposes). We have a dashboard application where clients can login to perform CRUD operations on data in their specific database. We use a single code-first EF model for interacting with the databases. (For whatever client is being viewed, we simply pass that client's database's connection string when instantiating the DbContext.)
However, the database instances are a mix of SQL Server 2005 and 2008. (I'm pretty sure this is the root of the problem we're seeing.)
On a particular page, we've begun to see the following error occur:
The version of SQL Server in use does not support datatype 'datetime2'.
From Googling and StackOverflowing, I've come to the conclusion that it's probably due to a misconfigured ProviderManifestToken on the DbContext.
However, the error is sporadic. Based on production error logs, I can view the same client for which the error occurred and perform the same CRUD operations without getting the error.
I'm at a loss.
Is it even possible to programmatically set the ProviderManifestToken? Or maybe the default connection factory isn't properly setting it (and there's something I can do to help it along)? Or am I way off base? Any ideas?
By the way...
The entity that the error is occurring on has 2 datetime columns, both of which are nullable (and the most recent error had null and Jan 13, 2012 as its values for those fields, so I'm pretty sure that this answer about ensuring that the values are within datetime's range doesn't apply.
Well, no solution yet. But we figured out a workaround for now.
If we restart the app pool, then immediately visit the client dashboard for a 2008-backed client, EF will generate and cache a mapping based on SQL Server 2008 constraints and all 2008-backed dashboards work just fine but 2005-backed dashboards fail on writes with the datetime2 error.
However, if we restart the app pool, then immediately visit a 2005-backed client dashboard, EF will generate and cache a mapping based on SQL Server 2005 constraints (which allows the model to work with both 2005 and 2008 database instances).
So, basically, our publish process now has the extra step of immediately visiting a 2005-backed dashboard.
Thank you for posting this. I had the same problem with a console app that visited a SQL2008 DB than a SQL2005 DB and had the same problem. I switched it so it went SQL2005 first, than SQL2008 and the problem went away. I am also using EF code first.
I would like to use some mechanism within SQL Server (or one of its services) to push change messages out (via UDP, for example, but TCP is OK, too) when rows get inserted into a table. I would like for these messages to be more than notifications of change, but to actually contained the changed data. Is there a mechanism that comes with SQL Server 2008 R2 to do this? I've heard of Service Broker and Extended Events, but am not sure that these are the right tools for the job when it comes to getting near real time data pushed out of SQL Server to another app that needs to update its internal state when data in SQL Server changes, without having to query SQL Server (i.e., I want the data to be strictly pushed out of SQL Server).
I the worst case, I can write SQLCLR code that unicasts UDP messages containing changes, but I would like to reuse an existing service, if available.
Since you are using SQL 2008, Change Tracking is built right in.
MSDN provides extensive information on enabling and implementing the feature. This overview article provides a high level view and this article is a great place to start on the implementation.
Unfortunately, because SQL Server Notification Services was removed from 2008 and later, there really isn't a good built-in way to do this. Microsoft's official party line is that Reporting Services can fill the gap, but practical experience proves otherwise.
You're stuck with either a 3rd party solution or rolling your own. Good luck!
I'm looking to implement SQL Server Reporting Services as our standard reporting platform in our company. We were trialing Crystal Reports, but alas it seems to be plagued by issues.
SQL Server Reporting Services looks to be a great product, but I have a concern or two.
I have some existing web apps in ColdFusion, and the backend is in MySQL. If I move forward with SQL Server Reporting Services, how should I set up my environment? Is there a JDBC connector or is ODBC the only way to talk to this?
How does it integrate for the user? Will I need to re-authenticate the user to view the reports? Will I need to put a link in ColdFusion to link to the Reporting Services system? Is there a way to make it seamless for the user?
Should I port all the backend to SQL Server to fully leverage the SQL Server platform? Should I convert my existing apps to ASP.NET, and make the entire platform SQL Server / ASP.NET?
It's not too bad in the fact that the existing apps / MySQL aren't of a size that is too big to port. So I guess just looking for some best practice advise to see if its okay to use the reporting services component on its own, or if I'm much better to consolidate everything into a Microsoft solution.
I think it'll be easier than you think!
Reporting Services will happily pull reports from any OLEDB or ODBC source, and MySQL has ODBC drivers, so there's no problem getting at your data through an SSRS report.
You can set up the authentication in a number of ways. If your users are already authenticated in your Windows domain, this will be easier:
SSRS needs to know who is viewing the report. It will allow anonymous viewing (if you enable it; it's off by default), but if you're using IE and are logged in to the same domain as the IIS server, it's completely transparent
SSRS can then use this identity to connect to the data source, or it can use another identity. This is configurable per report or per data source.
One thing you could do is embed your reports within iframes in your coldfusion pages. This would make the whole thing seamless. The reports are accessible by sending an appropriately formed URL to the server, so it's quite flexible.
As for changing everything to ASP.NET, you'll really only get benefits from that if you ever need to write (and integrate with) your own code to manage the reporting server, or write custom extensions (data providers, delivery extensions and the like), but in my experience this is so rare as to be not worth considering. Go with what you have for now.