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.
Related
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.
Here While I am trying to connect SQL server after installation I am getting the following error.
How to rectify the error, I have tried to restart the SQL service but it is also showing logon Failure.
Then I found out a solution for the logon failure error is that we
need to rewrite the password again in Logon tab and save it. But my
problem is that where can I get the password or which password I need
to rewrite because I don't know the actual password written on that,
So ho Please help me on this.
As this is clearly a SQL Server configuration and not a database related question you should untag everything but sql-server ASAP. Also, you might want to ask future questions like these in the https://dba.stackexchange.com/ forum as StackOverflow is more development focused.
Having said that, to reconfigure the SQL Server service account you need to go to the SQL Server configuration manager via Start Menu or Computer Management. There you can double click the service to see its details. In this case you can (re)set the service account from the Log On tab (see screenshot), here you can choose between a built-in or a managed account. Important note: it is preferred to use a domain account. Managed or Local Service account with minimal privileges are second best. It is ill-advised to use Local System for security reasons.
in Oracle weblogic, in the server monitor I have a server in ADMIN state and I would go in the RUNNING state.
I tried to resume, suspend force, force shutdown, but nothing.
The server has entered admin state for a reason. You need to view the log files to try and find out what the reason is. It could be due to database connectivity failure, bad deployment etc etc. Once you analyze the reason behind the failure you need to resolve it and then startup WebLogic.
The server has entered admin state and could never be started.
The installation process was stuck.
The root cause is the "clustered" option which was selected during the installation.
To solve this problem, i decided to uninstall the oracle Weblogic Server.
During installation, i removed the clustered mode in the "Configure Components" window.
Once the installation completed, the server stat entered in RUNNING mode.
I have been trying to run debugging within SQl server management studio and for some reason the debugger has just stopped working.
This is the message I get:
Unable to start the Transact-SQL debugger, could not connect to the
database engine instance 'server-sql'. Make sure you have enabled the
debugging firewall exceptions and are using a login that is a member
of the sysadmin fixed server role. The RPC server is unavailable.
Before this I get two messages, one requesting firewall permissions and the next says 'usage' with some text that makes little sense.
I have looked at the other similar answers on there for the same message which suggest adding the login as a sysadmin but that is already set. I also tried adding sysadmin to another account but that also didn't work.
In the end I was able to start it by right clicking and selecting run as administrator.
I encountered this issue while connected to SQL using a SQL Server Authenticated user. Once I tried using a Windows Authenticated user I was able to debug without issue. That user must also be assigned the sysadmin role.
This happened to me and I could not find the resolution anywhere. My firewall is disabled so I knew that couldn't be the issue.
According to Microsoft: Configure firewall rules before running the TSQL Debugger:
The server needs to communicate back to the client via RPC. The
account under which SQL Server service is running should have
authenticate permissions to the client.
We had a group policy that was preventing this:
Deny access to this computer from the network (Local account, Guests)
In order to resolve the issue, I had to add the SQL Server service account to the local group "Remote Desktop Users" on my desktop. Hope this helps someone else resolve this frustrating issue.
I try with the following steps, but it did not work (maybe because I'm on a PC in a office and I don't have control of the firewall). But you can try the following.
Check the users role:
IF IS_SRVROLEMEMBER ('sysadmin') = 1
print 'Current user''s login is a member of the sysadmin role'
Follow these instructions:
configure the transact-SQL Debugger
Run SQL Server Management Standard Edition 64 bits (with SQL Server Account)
In my case, I received this error message:
Unable to start the Transact-SQL debugger, could not connect to the computer "local".
I end up close the existing connection, then reconnect to my local SQL server using IP 127.0.0.1 and it works.
What helped me, was from here:
SQL Server Management Studio must be running under a Windows account that is a member of the sysadmin fixed server roll.
The Database Engine Query Editor window must be connected by using
either a Windows Authentication or SQL Server Authentication login
that is a member of the sysadmin fixed server role.
So, I've added sysadmin role to my windows account and run ssms as administrator. Debugger started working normally.
In addition to above works, what make our 2 computers remote debug able, was running: (right click on Window's Start button)
System--> Advanced System Properties-->Computer Name-->Click on Network ID... button
and running that wizard to join workgroup on both computers.
I found this solution by looking at my Windows' Event Viewer and looking for a solution to errors with NetBT Source, that is related to workgroup and computer Name.
Update: after some days, it stop working again.
I had the same problem and double checked al recommended settings. At some point I disabled the firewall on the database server and it worked like a charm. By enabling and checking the Firewall log I noticed this entry:
2019-10-31 16:07:50 DROP TCP 192.168.xxx.xxx 192.168.xxx.xxx 65231 61214 52 S 56576751 0 8192 - - - RECEIVE
When I allowed TCP port 61214 (Inbound rule) and switched the firewall back on, it worked. I don't know why this port is needed, maybe some here on SO?
Anyway, maybe the firewall log can be of help too.
Struggled through many hours and got the answer
You can do the configuration through this doc
https://learn.microsoft.com/en-us/sql/ssms/scripting/configure-firewall-rules-before-running-the-tsql-debugger?view=sql-server-ver15
(1) 2 settings need to done on the remote server where Sql server is installed
(2) 1 setting at client computer (i.e) our computer
We suffered a brute force attempt on our SQL database yesterday and obviously want to prevent this from happening again. The bot or whatever it was was trying to log into the sa account about 30 times a second so in the first instance we have changed the sa account and restricted the IP range that can access SQL via windows firewall. We are also considering disabling the sql server browser and changing the default port.
The problem is none of these things will prevent malicious log in attempts.
I came across a piece of open source software called QaasWall and wondered if anybody had used it and whether it is reputable.
Here is a link to the project site: http://sourceforge.net/projects/qaaswall-window/
Any other tips on how to restrict the number of server log in attempts would be greatly appreciated.
Many thanks.
Clayton.
The best solution is completely disabling access to the database from all hosts which do not need it. E.g. by binding to localhost if the DB is only accessed locally or blocking any connections to the IP/port used by the DB in your firewall.
TheifMaster is correct...the SQL Slammer was really vicious, but installing SQL Server SP3 or SP4 fixed the vulnerability in the sql server listner that this worm exploited. When you install SQL Server 2000 Pre-SP3 from disk your server will get pinged to death...this is why I disable the network connections while installing SQL Server until I can get it fully updated.
I recently installed QAAS Wall on one of my W2003 Servers and it works, but I'm having some difficulties getting the whitelist to work property. It keeps blocking access from one of my database servers.