I've been following Microsoft's guide for installing a dev environment on Windows 7:
http://msdn.microsoft.com/en-us/library/ee554869.aspx
In order for it to not run like a dog I've created a SQL Server 2008 instance on our database server specifically for this dev machine. The article does mention that you might be wanting to use an external database in regard to making sure the database cumulative update is installed. It doesn't make any other mention of configuring it to use a external database. I was hoping that the configuration wizard would then prompt about which database to use but annoyingly it just set-up the configuration database locally.
How do I go about installing SharePoint on a dev environment with an external database, and will I need to reformat this machine and do it all again?
Well, this depends on what your environment looks like. For instance, is this machine part of a domain?
If so, it should be as simple as selecting "Server Farm Install", or something like that when you did the binaries installation. Then, when you run Products and Configuration Wizard, it will ask you for DB info. Note: if you are doing this, I would recommend you to be part of the 'sa' role on the database server as you will be creating databases.
If you are not part of a domain, it gets a little trickier, but not too bad. Check out this article.
http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=112
-= Plan B =-
You can always give this a whirl. This is the method we use to keep the DB guys from screaming. It also allows us to give our databases nice names.
http://technet.microsoft.com/en-us/library/cc262869.aspx
Related
My problem is that after I installed SQL Server Management Studio and use .\SQLEXPRESS as a server name. It says that it can't connect it.
I read lots of things about that problem and one thing was to go to computer management and check the sql server browser if it is started.
When I go there I do not find any files for sql. On time of the installing I do everything correct as it is supposed to be. That's why I cannot understand why it doesn't work. Any ideas ?
I suspect that you have installed the tools only (SQL Management Studio) and not SQL Server itself. If you want to connect to your own SQL Server (any instance starting with a dot ".") then you will need to install it on your machine.
You can download the full installation SQL Express package direct from Microsoft. There are several editions available to suit your environment and needs.
http://www.microsoft.com/en-au/server-cloud/products/sql-server-editions/sql-server-express.aspx
It gets a little complicated trying to find what you want since there are so many variants and editions. I recommend that you head over to Scott Hanselman's blog where he has laid it all out very nicely by release version, edition and environment (32/64 bit)
His preferred link: http://downloadsqlserverexpress.com
Original post: http://www.hanselman.com/blog/DownloadSQLServerExpress.aspx
So, it seems it isnt installed... was it installed? Check google what it's folders are for your system and go look if the folders exist. Make a backup of existing folders and re-install if need be. then attach any existing files to to recreate the databases, if any.
I'm quite a newbie, just trying to learn some new things. I've recently started learning c# etc and I'd also like to create a new SQL Server database using SQL Server Management Studio.
The thing is that for some reason I am not able to connect to the server. I might have done something wrong (or haven't done something that I should have done). Been researching the problem a lot on google and I found some tips but I still can't make it work.
I even found some installation tutorial in here: http://www.sqlcoffee.com/SQLServer2014_0005.htm and I only noticed that I used some different options (I used default, didn't change anything) like for example in "Database Engine Config" I chose "Windows authentication mode".
So that's what I get: http://imgur.com/2ftOdSB
Also I think I may have some problem with services, because when I go to the server configuration manager, the list is completely empty.
Thanks for any tips. If I don't solve this, I can always uninstall SQL Server Management Studio and reinstall it - this time following the steps in the tutorial. Hopefully that wont be necessary so help me please:)!
I've had a look at the link you posted about the installation instructions. As I mentioned before SQL server enterprise (database engine) won't install on a non-Server OS, You'll need at least Windows Server 2008. Have a look at msdn.microsoft.com/en-us/library/ms143506(v=sql.120).aspx for the system requirements. During the installation there must have been an option to install the database engine, but it was probably disabled because of your OS.
I suggest you uninstall 2014 Enterprise and download SQL Server 2014 express microsoft.com/en-gb/download/details.aspx?id=42299 and make sure you select database engine as part of the installation.
If you want to get into SQL, I would suggest trying out MySQL first. I've utilized it a little bit and found it to be fairly simple with a decent amount of documentation. This version of SQL will still function with various languages. It doesn't utilize Windows authentication, but rather lets you set a root password specific to the database itself. I don't know if your software is similar to that but there may be an option to not use Windows authentication and instead authenticate within the database software itself.
I had a SharePoint server, now i want to move this from one machine to another machine.
This is what i did for the migration.
I have just installed sharepoint server in my new machine and i have removed the Sharepoint_config and wss_content databased from the new server. and i have restored both the databases from the old server. Then i tried to run the Central Admin and i got Unable to connect to content database error.
Is replacing the DB is wrong. is there any other way to migrate SP server from one machine to another. I have tried my taking Farm backup and restore i had many problem with that. so i feel replacing DB would be better for me. any suggestions please?
Move SharePoint between servers is a huge effort.
Data in databases are very depends on the SharePoint install and its environments. So, I suggest just re-install the SharePoint on the new server, and then restore site collection backups to the new install.
Install SharePoint Server on the new server machine
Backup site collections from the old server, follow this guide: http://technet.microsoft.com/en-us/library/cc263441(v=office.12).aspx
Create Web Applications on the new server
Restore site collections from the prev. backups, follow this guide: http://technet.microsoft.com/en-us/library/cc262087(v=office.12).aspx
Be aware, if you have farm level customize solutions (developed by Visual Studio) or css files deployed in the LAYOUT folder, don't forget to re-deploy them on the new server.
I guess this question is too old and my answer will not help topicstarter... However, I was looking to refresh my own knowledge on this topic and I feel it will be useful to share it here.
This solution is not good for every SharePoint deployments, of course, it's just a general idea.
And I don't think it suits production environments well... but if you are brave and foolish as myself, you can do it there as well, with some additional precautions like backups and so on.
Here are prerequisites:
SharePoint was initially installed in Farm mode (not in Single Server mode)
Both old and new servers are in the same domain
You know Farm Passphrase used for initial installation
Old server is still intact and accessible from the new server
Steps to do
Skip steps 2-6 if you don't want to move databases to new location
Install SharePoint on the new server and join to existing farm. See
https://technet.microsoft.com/en-us/library/cc261752.aspx for details on joining procedure.
Ensure that the SharePoint is read-only. You can just shut down MS SQL DBEngine service if it's ok for your users.
Install MSSQL Server on the new server or other location you want. Remember, that it's not a good idea to keep SharePoint and MSSQL on the same server if it's not a demo/dev environment
Move all SharePoint databases to the new MSSQL Server. You can simply copy all DB files and attach it to the new SQL, or go full backup and restore way.
Important: Create an SQL client alias on the new server with cliconfg tool. See blogs.msdn.com/b/priyo/archive/2013/09/13/sql-alias-for-sharepoint.aspx for details.
Use your old SQL instance name as alias name. E.g. if your old server had SQL installed alongside with SharePoint on SharePoint.mydomain.com, alias name should be "SharePoint.mydomain.com"
Set Server name for alias to the new SQL location. Something like "NewServer.mydomain.com"
Ensure that you specify correct port number for SQL connection or configure network for default dynamic port. It is not necessary only if you have local SQL server on the same machine.
Create identical SQL client alias on the old server (this is needed to correctly remove old server from farm)
Remove old server from the farm. See this technet article for details
Update DNS settings or whatever you use to point users to the new server.
That's it. Hope it will help someone
Simple problem. I'm working on a Delphi 2007/WIN32 application which now uses MS Access as simple data store. I have to modify it to support SQL Server Express, which is easy. These modifications are working so the application can be deployed using either SQL Server or MS Access. (Whatever the user prefers.) I did consider deploying the whole application together with the SQL Compact but this is not practicak. Using SQL Server Express 2008 instead of 2005 is an option, but also has a few nasty side-effects which we don't want to resolve for now.
The problem is deploying the whole project. The installation with SQL Server would need a quiet installation so the user won't notice it. SQL Server is mentioned in the documentation so they know it's there. We just don't want to bother them with technical issues. In most cases, such an installation will go just fine.
But what if the user already has an SQL Server (2005) installation which is used for something else? Personally, I would prefer to just install a second instance of SQL Server on their system so it won't conflict with the other installation. (Thus, if they uninstall the other app, the SQL instance will just stay installed.)
While SQL Server 2005 and 2008 can be installed on the same system simply by using two different names for the instance, I wonder if it's also possible to install SQL Server 2005 twice on a single system to get two instances. And if possible, how?
To answer your question: yes SQL2005/SQL2008 and SQLExpress2005/2008 can all live happily side by side. The default instance name for the SQLExpress install is [machine name]\SQLEXPRESS. But having said that, you should consider giving your customer the option to use the sql instance they already have, and only install a new instance if they choose to.
I don't know if SQLExpress can be installed silently (most likely it can as long as you specify the right properties on the command line when you install it). But we have rolled it out to lots of customers, and they have very few issues installing it normally.
Edit: I have added this as an edit because a comment doesn't allow enough.
I understand your reluctance to both having the user install SQL manually, and to sharing another instance. To address these points:
uninstalling a product should never automatically uninstall the SQL instance, even if that SQL instance was put there when installing that product. By all means the database can be blown away, but uninstalling a SQL instance should be a manual process, as it is a server product that may be used by many other products
you can make your task a lot easier by using a decent installer product. For instance, we use InstallShield. It has a sql browse dialog built in (its a baked in feature of InstallShield) that the user can use to select which sql instance and database they want to use for our product. The details the user enters are then inserted in to the web.config file using an XML file change task (also functionality baked into InstallShield). By using dialogs like this you eliminate a lot of potential user errors.
if there is already an existing sql instance, use it. The only dependence your database should have on the instance is that it is the right version (i.e. SQL2005, and 2008 is fine for a 2005 database). The only time you should demand your own instance is if you are processing/storing enough data that you require your own server, or if you are depending upon undocumented features. If the existing instance is already under heavy load, then insisting on a new instance on a different server is fine, but then you have also avoided that whole side-by-side situation. Alternatively you could just install in to the existing instance and get the customer to commit to upgrading the hardware.
I hope this helps somewhat - i'm just trying to persuade you that there are limited reasons for needing a separate instance and that 99% of the time you will be fine installing in to an existing instance. It's nice to have your own instance but in reality it brings you few real benefits, especially if you are using a robust installer.
You can install SQL Server Express in silent mode using the /Q command line switch or use the /QS command line switch to see setup progress without user input. You can install a named instance on a system that already has SQL Server installed.
http://msdn.microsoft.com/en-us/library/ms144259.aspx
There are a number of reasons why it is very useful to have your own instance of an SQL Server.
You can decide for yourself what type of authentication you use (SQL authentication or Windows authentication). Although Windows authentication is recommended, scenario's exist where this is simply not an option. And enabling SQL authentication for an instance where other products use the same instance is a security risk.
You can safely assume that your product is the only user of the installed instance. So with installing and uninstalling the instance you know the version and databases in use by that instance. No extra detection needed, as long as different versions of your product use the same SQL configuration and version.
Isolation of your installments (files, registry keys, dll's and other products) is a very good practice!
Also, uninstalling an SQL Server instance doesn't lead to data loss, because the data files of the databases will not be removed. After reinstalling, you can attach the data files again if needed.
that being said, SQL Server express can be installed in three different interaction modes:
Full UI, including SQL license agreement acceptance
Silent, but with detailed progress UI
Silent, without any progress UI (and suppressed errors!)
Detailed instructions for installation can be found at http://msdn.microsoft.com/en-us/library/ms144259(SQL.90).aspx
We have a DB server with a couple web app db's on there (don't get a ton of traffic). We'd like to make use of the server and allow it to be the DB server for sharepoint. I'm assuming it's not good practice and that sharepoint should have it's own exclusive db server. Am I right in that conclusion, or is it alright if we put the database on a server that already hosts other databases.
You can install SharePoint on an existing DB server, sure. Unless your environment is going to be huge, I don't see why you would give it its own DB server. It will use an embedded SQL Server instance if you want, but you'll get better performance if you have the full-blown version. We're running a few SharePoint apps on our DB server with a number of other applications.
The way in which I solve this is to install a second SQL Server instance dedicated to SharePoint, as SharePoint likes to have a lot of control over the database and spews all sorts of stuff such as logins, etc. across the instance, which you really want to separate from your standard line of business instance.
The added bonus is multiple SQL Server instances on the same physical machine are included in your licence.
Be careful with the SQL Server collation. I think SharePoint requires a particular setting for this. See http://www.moss2007.be/blogs/vandest/archive/2007/07/24/sharepoint-2007-and-sql-server-collation-latin1_general_ci_as_ks_ws.aspx for one reference.
Prior to centralizing our environment we had many Sharepoint sites located on servers with existing applications. I'm not a fan of adding an additional named instance as this increases the administrative overhead for the DBA. You have to know how much use you expect of your Sharepoint instance then measure the resource utilization of your existing applications balance it from there.