I have already set up my clustered environment. But now, there is a requirement came for reporting service for only one instance.
When I try to add it using the "Add feature to the existing environment" option in setup. However, I can't see Reporting Service on there.
So how I install and set up reporting service to the required instance.
As you may know, SSRS is not a cluster aware feature, so the install requires some extra steps. Also, if you want high availability for SQL Server Reporting Services you should deploy it in a farm which provides both availability and load balancing.
Adding SSRS on an installed SQL Server Cluster Instance is not so straight forward. When we try to add SSRS on an existing SQL Server cluster instance, the install does not allow us to proceed after the Installation rule check page because one of the rules fails during the rule check process. One solution is to install SSRS as a separate instance, but since this configuration was already a multi-instance cluster I was not in favor of increasing the number of instances by installing SSRS as a separate instance. Below I will explain the step by step method to configure SSRS on an existing SQL Server cluster instance without deploying a farm
Step 1
To add/install SSRS on an installed SQL Server Instance, we need to run setup again on each cluster node. First run SQL Server setup on your active node (Node 1). Follow all necessary steps in the setup windows. Make sure to run this setup to add SSRS on your existing instance rather than creating a new instance. Choose Reporting Services on the feature selection page of the setup window. After we start the install, we will get an error because one of the rules will fail as shown below.
Step 2
When you get the above error, you cannot proceed with the install because the "Next" button will be disabled due to this failed rule.
To get a detailed report about this failed rule, click on "view detailed report" shown in the above screenshot and you will get details about this rule as shown below.
Step 3
As we already saw that we cannot add SSRS to an existing SQL Server cluster, the solution is to run setup and skip the installation rules to install SQL Server Reporting Services in an existing clustered instance.
Run the below command at the Windows command prompt to start SQL Server setup on the active node. Make sure to run this command after changing the root directory of the command prompt to the location where you have placed the SQL Server setup files.
Setup.exe /SkipRules=StandaloneInstall_HasClusteredOrPreparedInstanceCheck /Action=Install
Once you press enter to run the command, the SQL Server product version will display on the command prompt, as shown above, and an installation window named "Program Compatibility Assistant" will appear. Now click on "Run program" to proceed with this installation.
Step 4
Now follow the same process which you normally do in an installation. Again choose the existing instance to add SSRS and select Reporting Services in the feature selection page which we need to install.
Now this time you can see the installation rule check passes without an error, because we skipped the installation rule process to make this installation possible.
Step 5
Here we can see the "Next" button is enabled, so click on Next to install SQL Server Reporting services on the active node.
Step 6
Once you are done with the installation on the active node (Node 1), follow the same process on each of the other nodes in the cluster.
Step 7
Now that each of the nodes has Reporting Services installed, it is time to configure Reporting Services on each node using "Reporting Services Configuration Manager" which can be found under configuration tools.
Here the configurations would be the same as you would have for any Reporting Services configuration. One thing will change though, we will use the SQL Server failover cluster network/virtual name while making a connection to the report database server. If we use node names in place of the failover cluster network name, the report server will be unable to connect to the report server database in case failover occurs.
Configure Reporting Services on each node in the same way with SQL Server failover cluster network name otherwise you will get the below Report Manager error after failover when an instance is online from another node.
Step 8
Now you are done with your SSRS configuration. Go ahead and launch Report Manager to check whether SSRS is configured properly. You can also test your Report Manager accessibility after failover and failback to verify whether it's providing the necessary failover functionality.
Related
I am currently building Non Production TFS 2015 environment. I am restoring database including DBs from production to the new QA DB instance. I performed DB restore using TFSRestore.exe. The restore work successfully.
In TFS QA then I install Application Tier and configure to TFS QA and TFS QA service account.
Then I did RemapDBs, Reset Owner, RegisterDB then start the service. Then I change the Notification URL to point to QA TFS Url.
What is strange is that I can see that in Applications Tiers, I can see 2 machine names display. One is TFS Prod machine and TFS QA Machine Name. How I can remove Production TFS machine name under Application Tier section.
I check the checkbox "Filter out machines that have not connected in more than 3 days"
After 3 days the TFS Prod machine is remove from the Application Tier section. Since I want to do inplace upgrade to the next version therefore is it safe to do this?, how do I know this would not impact the TFS Prod?
I did run the
TFSConfig ChangeServerID /SQLInstance:SPTEST\Contoso /DatabaseName:Tfs_Configuration /ProjectCollectionsOnly
as result, it created new hostID (Guid Number) inside TFS_configuration.tbl_ServiceHost. However, when I select a project in Team Foundation Server I receive an error TF31001: Cannot connect to Team Foundation Server at Project1. The server returned the following error. Value cannot be null. Parameter name: service Definition
Resolve this by delete anything under cache folder
c:\users[username]\Appdata\Local\Microsoft\Team Foundation\5.0\Cache
This is similar post
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0ba7caad-4210-4991-b6f0-d4f1dd8c409b/removing-application-tier-server
According to your description, your scenario should be Move or Clone Team Foundation Server from one hardware to another
(Clone option) Reconfigure server IDs and remap databases:
Perform the next set of steps on the new application-tier server if
you intend to continue using the original TFS instance. These steps
are necessary to avoid the risk of corruption of one or both
deployments. If both servers are live, you could end up with
corruption, particularly if they are pointing to the same SharePoint
or reporting resources.
So, please try to Reconfigure server IDs and remap databases. If that still not work, I'm afriad that you have to remove the DB instance and reconfigure the QA envrionment step by step following the instruction mentioned here.
UPDATE:
Seems you just restored an application-tier server but not Move or Clone Team Foundation Server from one hardware to another
For restoring an application-tier server, the name of the old application-tier server remains there is expected (See the end of this article.).
Note: The name of the old application-tier server will still appear in
the list of application-tier servers in the administration console for
Team Foundation. If you select the Filter out machines that have not
connected in more than 3 days check box, the old server will disappear
from the list within three days.
So, to avoid showing the old App Tier machine name you need to follow the steps to Move or Clone Team Foundation Server from one hardware to another as I mentioned in the original answer.
Note: You must install but not configure TFS on the new data-tier
server, and then use the restore function in the Scheduled Backups
node
I am also getting this issue. I followed all the cloning steps to move to my new TFS boxes, and I got it up and running, after running the command TFSConfig ChangeServerID.
But on the new server, under Application Tier > Application Tiers, I see two servers.
The new SQL box, and the old TFS box!
This is on TFS 2017.
I am trying to install a 3 node Active-Active-Active SQL WFC. One of the SQL role IPs we had set aside was actually already in use. Originally, once I received the message, I tried removing the role by running the "Remove node from a SQL Server failover cluster" in the Maintenance page of the SQL Server Installation Center. The uninstall completed, but the role is still there, and now when I attempt to run the Removal again, when I get to the "Cluster Node Configuration" step, the "SQL Server instance name:" dropdown doesn't provide any instances.
I wanted to know what the best steps would be to remove this role? Can I remove it through Failover Cluster Manager without harming future SQL role setups? Can I try re-installing with the same information and then uninstalling again when it inevitably fails? Can I change the DNS so that the IP matches the Network name that we've provided it?
Thank you for pointing me in the right direction.
I am a total newbie in SQL/SQL server stuff, and I am using SSRS to make a new reporting server/service and upload some .rdl files to it
I have a reporting server on a machine, which has a lot of reports and data sources uploaded to it's database.
I created a new reporting server with a fresh database on another machine, and what I want to do is to copy the old database content to the fresh one (the reports and the datasources..etc)
I have no copy of the individual reports to upload them to the new server using localhost/reports
is there's a fast solution to what i am having? please do it in detail because I never worked with SQL before.
Different ways to do this:
Report Server Databases
Use the detach/attach or backup/restore instructions here. Both of these methods require a backup of encryption keys on the existing instance, which are then restored to the new report server instance. Instructions on backup/restore of encryption keys here. Migrating the ReportServer and ReportServerTempdb databases is the easiest way to ensure all content is available on the new server.
Report Object Scripting
Reporting Services Scripter is an older (but still working with SSRS 2008R2, not sure about 2012) tool that can be used to transfer objects (folders, shared data sources, shared data sets, reports, etc) between report servers. Good choice if you want to pick and choose what is migrated.
If you are receiving an error regarding unsupported scale-out deployment, this means you are running Standard edition and need to remove the old report server entry from the database in the new location. It can be done using Reporting Services Configuration Manager, or by using rskeymgmt at command line.
Reporting Services Configuration Manager
Open Reporting Services Configuration Manager and connect to the new report server instance.
Click on Scale-out Deployment to view registered report servers.
Select the old report server instance and click the Remove Server button.
Command line and rskeymgmt
Browse to the Tools\Binn folder of your SQL Server client installation.
Run the following to list registered report servers
rskeymgmt -l -i
Using the installation ID (GUID) of the old report server, remove it
rskeymgmt -r -i
More info on scale-out deployments and rskeymgmt here.
To migrate Reporting Services, use migration manual from MSDN (https://msdn.microsoft.com/en-us/library/ms143724(v=sql.120).aspx). If you encounter "the feature: scale-out deployment is not supported in this edition of reporting services. (rsoperation notsupported)" error, go to ReportServer database and remove the old encryption key from table dbo.Keys.
I've followed the steps at the site http://www.dotnetspider.com/resources/24960-How-Process-SSAS-Cubes-Automatically.aspx
It works in development phase, but I need to change the target of the cube in deployment environment.
I opened the package file and I've edited it manually, but it doesn't works...
I don't know if is authentication problems. But my questions is, how to parametrize the target of the cube that I want to process?
Thanks.
obs: I'm not expert in Analysis Services but I need to execute this job.
The best way is to, in SSIS, base your Analysis Services connection on an expression:
Create a variable #[Server] to hold the name of your Analysis Services server.
Add an expression to you Analysis Services connection, pointing the property ServerName to that variable.
Add a Package Configuration to your package, so you can have different configurations according to where you want to deploy the package.
I did this:
Make a DOMAIN\USER administrator of SQL Server Analysis Services
Give the same DOMAIN\USER the fixed-role "sysadmin" on the SQL Server.
Create new credentials in SQL Server with Login Data of this DOMAIN\USER.
Create a proxy user on SQL Server with the new created credentials, and allow AS Service Command and AS Service Query execution.
Create your SQL Server Agent Job that execute a query for cube processing and select the created proxy user.
I deployed my working package on server which is enterprise edition, SSIS installed on it. When I tries to run package by connecting to integration services engine from my desktop SQL client (which doesn't have SSIS installed) I get error "The task "Send Mail Task" cannot run on this edition of Integration Services. It requires a higher level edition."
Does it mean that I need to login to the server (RDP) and then run the package?
Also, when I schedule the package thru SQL agent it fails saying login time out but my windos auth login works for everything from connecting, deployment. Any clue?
For your first problem - yes, you need to RDP into the server in order to use SSMS to start the package. When you start it using SSMS on your client, it's attempting to launch the DTExec process on your client machine. It's not running DTExec on the server.
Your second problem is likely a permissions issue. Possibility #1: The connections you have set up on your package require your authentication information, and they don't have it because they're running as the Agent account. You can fix that by creating a Proxy for your account and using that to run your job step. Possibility #2: The connections you have set up on your package are having their sensitive information stripped out due to the default encryption on the packages that prevents anyone but "you" from seeing it - including a SQL Agent job that isn't running "as you". The same resolution as above can help that (as well as others).