[tweetmeme]
In this tutorial I will guide you through setting up the database for VMware Site Recovery Manager 4.1. There must be a database for the primary site and a separate database for the secondary or disaster recovery site. If you are using Site Recovery Manager in the same site or in a lab environment you can use the 1 sql server, just make sure you have separate databases. If you are planning to run Site Recovery Manager between sites that are geographically dispersed, then you must have a database server in each site. Note: For this lab I’m running SQL 2008 R2 Enterprise for demo purposes, it does fully work, but is not on the supported compatibility matrix from VMware http://www.vmware.com/pdf/srm_compat_matrix_4_x.pdf So if you are running SRM for testing purposes feel free to use SQL 2008 R2 otherwise if you are installing into production, check the compatibility matrix as to which SQL versions are supported
1. Open up your database management studio. As you can see in this tutorial I will be using Microsoft SQL Server 2008 R2. Click Connect.
2. At the top left hand corner of the screen click New Query.
3. The schema and username used to authenticate to the database needs to be exactly the same. The database name doesn’t but for this tutorial I will be keep all 3 elements the same name. Type in CREATE SCHEMA vmwaresrm; and click Execute. You should see Command(s) completed successfully, in the messages area below.
4. Clear the last query and type in CREATE DATABASE vmwaresrm and click Execute. Again you should see Command(s) completed successfully, in the messages area below.
5. Clear the last query again and type in USE vmwaresrm This selects the vmwaresrm database for the next few commands.
6. We are going to create a user and password for this database and assign it the schema we created earlier. Type in CREATE LOGIN vmwaresrm WITH PASSWORD =’vmw@re123′; then on a new line CREATE USER vmwaresrm FOR LOGIN vmwaresrm WITH DEFAULT_SCHEMA = vmwaresrm; Click Execute. Again you should see Command(s) completed successfully, in the messages area below.
7. Hit F5 to refresh the page and you should now see your newly created database. Expand the database vmwaresrm – Security – Users.
8. Right click on the vmwaresrm user that we created and select properties. Under Database role membership: select db_owner. This is one of the requirements for SRM. Click Ok
9. Now expand Security – Logins and right click on the vmwaresrm user and click properties.
10. Change the Default Database to vmwaresrm.
11. Select Server Roles and select bulkadmin. Click Ok.
12. Close SQL Management Studio and then open it again. This time change the Authentication to SQL Server Authentication and login with the vmwaresrm user and password that we created in step 6. Click Connect.
13. Click New Query at the top left hand side and type in the following CREATE SCHEMA vmwaresrm AUTHORIZATION vmwaresrm; and click Execute. You should see Command(s) completed successfully below. You can now clock SQL Management Studio.
14. Now lets connect to our VMware vCenter server in the primary site. VMware Site Recovery Manager can only use the 32-bit ODBC connector. Browse to C:WindowsSysWOW64 and open up odbcad32.exe.
15. Click the System DSN Tab.
16. Click Add and select SQL Server Native Client 10.0. If you don’t see this option you can install the sqlcli.msi file from the SQL CD. Click Finish.
17. Give the new DSN a name, description and select the sql server that you want to connect to. Click Next.
18. Select SQL Server Authentication and type in the username and password that we created in step 6. Click Next.
19. You will see that the default password is greyed out by default and is already vmwaresrm. Though you can click Change the default database to: and select vmwaresrm. Click Next.
20. Click Next.
21. A summary of the DSN connection is displayed.
22. Click Test Data Source and you should see TEST COMPLETED SUCCESSFULLY!. Click Ok.
Disclaimer:
All the tutorials included on this site are performed in a lab environment to simulate a real world production scenario. As everything is done to provide the most accurate steps to date, we take no responsibility if you implement any of these steps in a production environment.
was this with enterprise 2008 R2 or standard 2008 R2?
I used SQL 2008 R2 Enterprise for this lab
Dude, your my hero! I just lost 3 hours trying to figure this out before I found your article.
VMWare seems to have assumed we are all SQL experts which I clearly am not!