WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Automating the silent installation of Site Recovery Manager 5.8 w/Embedded vPostgres DB

10.28.2014 by William Lam // 6 Comments

Last week I had a nice email exchange with Ben Meadowcroft who is the Product Manager for VMware's Site Recovery Manager. While chatting with Ben, I learned about new feature that I was not aware of in the latest SRM 5.8 release which now supports an embedded vPostgres database. Not only does this greatly simplify the installation and not requiring an external database like Microsoft SQL or Oracle, it is also on par in terms scalability with the external databases which is great for customers. I definitely like this improvement in the SRM installation and making it easier to evaluate and POC without requiring a large resource footprint.

UPDATE (11/09/15) - For silent installation of SRM 6.x, please take a look at this article here as some of the install params have changed.

In addition to new database feature, I also learned that SRM supports a silent mode installation which I was not aware of before either. I figured this might come in handy for those needing to automate an SRM deployment given you will need at least two installation: one for the protection site and one for the recovery site. I did not see much documentation on this topic and it has been awhile since I have played with SRM, I thought this would be a good opportunity for some automation goodness as well as checking out some of the new SRM 5.8 features including VSAN support as well as the new vSphere Web Client integration.

In my lab, I wanted to run the a minimal setup and the least amount of Windows 🙂 With that, I was able to use two VCSA, 2 SRM hosts running on Windows 2008 R2 and six Nested ESXi hosts as shown in the diagram below:
silent-installation-of-site-recovery-manager-0
To perform a silent installation of SRM, you need to specify a list of 35 parameters to the actual executable which is quite daunting and can also be quite error prone. It actually took me a few tries before I was able to get it working and I wanted to make easier so that anyone can just consume it. I decided to create a simple Windows batch script called install_srm.bat which wraps all the required parameters in a set of variables that can easily be modified by anyone. Out of the 35, only 31 of the parameters can be edited and of those only 15 is really required to be tweaked (which is clearly noted in the script) but also shown below:

  • SRM_INSTALLER - The full path to the SRM 5.8 installer
  • DR_TXT_VCHOSTNAME - vCenter Server IP/Hostname
  • DR_TXT_VCUSR - vCenter Server Username
  • DR_TXT_VCPWD - vCenter Server Password
  • VC_CERTIFICATE_THUMBPRINT - vCenter Server SSL SHA1 Thumbprint
  • DR_TXT_LSN - SRM Local Site Name
  • DR_TXT_ADMINEMAIL - SRM Admin Email Address
  • DR_CB_HOSTNAME_IP - SRM Server IP/Hostname
  • DR_TXT_CERTPWD - SSL Certificate Password
  • DR_TXT_CERTORG - SSL Certificate Organization Name
  • DR_TXT_CERTORGUNIT - SSL Certification Organization Unit Name
  • DR_EMBEDDED_DB_DSN - SRM DB DSN Name
  • DR_EMBEDDED_DB_USER - SRM DB Username
  • DR_EMBEDDED_DB_PWD - SRM DB Password
  • DR_SERVICE_ACCOUNT_NAME - Windows System Account to run SRM Service

Note: To retrieve the vCenter Server SSL Certificate Thumbprint, you can either view the details using a regular web browser as shown in the screenshot below

Screen Shot 2014-10-27 at 10.11.59 PM
or you can run the following command on a UNIX/Linux using the openssl utility to extract the thumbprint:

echo -n | openssl s_client -connect [VC-IP-ADDRESS]:443 2>/dev/null | openssl x509 -noout -fingerprint -sha1

Depending on the number of SRM installations you require, you will need to modify the script to perform those additional deployments. As you can see below, I have my two SRM sites implemented. I have also gone ahead and paired both my SRM setups as well as deploy and configure the vSphere Replication 5.8 using the vSphere Web Client. I definitely recommend checking out the latest SRM 5.8 release if you have not already and you may also want to consider using the embedded vPostgres database for future SRM installation to help simplify the deployment and management of SRM.

silent-installation-of-site-recovery-manager-9
For those of you who are interested in the variable mappings to the SRM UI installer (which is pretty straight forward), I took screenshots of each step and mapped them for your convenience.

silent-installation-of-site-recovery-manager-1
silent-installation-of-site-recovery-manager-2
silent-installation-of-site-recovery-manager-3
silent-installation-of-site-recovery-manager-4
silent-installation-of-site-recovery-manager-5
silent-installation-of-site-recovery-manager-6
silent-installation-of-site-recovery-manager-7
silent-installation-of-site-recovery-manager-8

Categories // Automation, SRM Tags // site recovery manager, srm, vpostgres, VSAN, vSphere Replication

Monitoring vCenter SSO User Account Expiration

01.29.2013 by William Lam // 2 Comments

Did you know that user accounts created in the vCenter SSO Server automatically expire by default after 365 days? If you do not update your password prior to the expiration date, in about a years time you could potentially be locked out of your vCenter SSO Server which also applies to the admin@system-domain account.

You can change the default password expiration policy by logging into the vSphere Web Client with an SSO Administrator account. Under the configuration section of "Sign-On and Discovery", there is a Password Policies tab that allows you can modify password policies. By default, this is set to 365 days. I would also recommend that after you have installed and setup your vCenter SSO Server, you add at least one user or group from your directory service such as Active Directory and assign it to the SSO Administrator group. This will ensure that you can still log in to the SSO configuration in the event the local SSO user accounts are locked out.

Even though you can change the password expiration policy, there is still no automated notification or alerting built-in for user accounts that are going to expire. The best you can do is to create a calendar event to remind you update your passwords prior to the expiration date. I am sure that many of you are anxious to add another color event to your already busy schedule 🙂

While investigating alternative options a few weeks back, the only method that I have found to retrieve the status for each SSO user is to directly connect to the vCenter SSO Database. There are two specific tables of interest, one which provides the current password policy and the other providing the last password changed date for each SSO user:

  • ims_authn_password_policy
  • ims_principal_data

Disclaimer: This "may" not be officially supported by VMware.

Instead of having you manually dig around in the SSO Database, I have created a Perl script called getSSOUserExpiration.pl which can connect to either a MSSQL or vPostgress backend SSO database. The script which will automatically list out the current password policy as well as user accounts that will be expiring in N days, where N is input provided by the user. You also have the ability to configure the script to automatically email you the results which is nice for a daily or weekly report and can be setup using a cronjob or a scheduled task. There are several configuration variables that will need to be adjusted based on your environment and these are all located within the script itself. For more details on how to setup and use the script, please take a look at the Setup and Configuration section below.

Note: To reduce any negative impact to the vCenter SSO Database, you should add or ask your DBA's to create a limited read-only account and limit access to the following tables above. You may even be able to have your DBA's create a scheduled routine for the specific queries and have that emailed to you internally.

Here is a screenshot of connecting to a vPostgres backend Database:

Here is a screenshot of connecting to a MSSQL backend database:

Here is a screenshot of what the email report looks like:

Note: The email body should contain the specific vCenter SSO Database, but I am not sure why it is not showing up in Gmail, but it does work for other email clients.

Setup and Configuration

vPostgres

To connect to a vPostgres DB, you will need to install the following two perl packages: perl-DBI and perl-DBD-Pg. In this example, I am using the vMA appliance and the zypper package installer. For more details on how to add a SLES repo, please take a look at the following article. I also assume if you are connecting to a vPostgres DB, then you are using the VCSA (vCenter Server Appliance) and by default it does not accept remote connections. We will need to also make two configuration changes to the VCSA for our script to be able to connect to the database.

Step 1 - Run the following two commands to install both perl packages:

sudo zypper in perl-DBI
sudo zypper in perl-DBD-Pg

Step 2 - SSH into your VCSA and in the following configuration file /storage/db/vpostgres/pg_hba.conf you will need to add the network in which you will be connecting from:

host    all             all             172.30.0.0/24           trust

Step 3 - SSH into your VCSA and in the following configuration file /storage/db/vpostgres/postgresql.conf you will need to add the IP Address(s) that you want vPostgres to listen for remote connection. If you use "*", it will allow all addressees:

listen_addresses = '*'

Step 4 - For the changes to go into effect, you will need to restart the vPostgres DB by running the following command:

service vmware-vpostgres restart

Step 5 - Modify the getSSOUserExpiration.pl script and provide the credentials to your vCenter SSO DB. If you need help in identifying the vCenter SSO DB credentials, please refer to this article for the details.

MSSQL

To connect to an MSSQL DB, there are a few additional steps and packages that will be required. We will be using FreeTDS which provides libraries to connect to an MSSQL DB for UNIX/Linux platforms. There was a bit of trial and error in getting the MSSQL solution working and I would like to thank Reuben Stump for his assistance. The following article was used as a reference for the setup below.

Step 1 - Run the following two commands to install the required packages:

sudo zypper in perl-DBI
sudo zypper in gcc

Step 2 - Download and extract the contents of the FreeTDS package:

wget ftp://ftp.astron.com/pub/freetds/stable/freetds-stable.tgz
tar -zxvf freetds-stable.tgz
cd freetds-0.91

Step 3 - Compile and install FreeTDS under /usr/local/freetds:

export SYBASE=/usr/local/freetds/
./configure --prefix=/usr/local/freetds
make
sudo make install

Step 4 - Add your vCenter SSO Server details into the FreeTDS configuration file located in /usr/local/freetds/etc/freetds.conf

[sso]
host = 172.30.0.239
port = 1433
tds version = 7.0

In the example above, I named my database entry "sso" but you can use any name and this will be referenced when editing the script in step 5.

Step 5 - Modify the getSSOUserExpiration.pl script and provide the credentials to your vCenter SSO DB.

Categories // Automation, Security, vSphere, vSphere 5.5, vSphere 6.0 Tags // expiration, perl, sso, ssodb, vpostgres, vSphere 5.1

vCloud Suite Virtual Appliances: Passwords, Databases, URLs, etc

01.07.2013 by William Lam // 11 Comments

I recently re-organized my home lab and I got rid of a bunch of VMs for random projects that I have been working on last year. Part of this re-organization was to re-deploy a few of the virtual appliances found within the vCloud Suite. As part of the deployment, I often find myself scouring various documents looking for default credentials to the OS, VAMI interface or the application. It is not always easy to find and I often end up going to Google or the VMTN forums for the answer.

As a fun little exercise, I thought why not deploy all of the latest virtual appliance that are available in the vCloud Suite and just document the latest usernames/passwords for the application, OS, VAMI interface, database configurations, URLs, etc.? This would primarily be a reference for myself, but thought it might also benefit others as well. Duncan Epping had done this awhile back for vCloud Director and few other virtual appliance and funny enough, his site was one of the first ones I found for the default vCloud Director password.

Not only have I deployed all the virtual appliances from the vCloud Suite, which can be seen from the screenshot below,  but I also went through each appliance and validated the credentials for the application, OS or VAMI interface if applicable as well as identify all database credentials and configurations which are not all publicly documented (this took a bit of digging in the appliances, but was not too difficult if you know where to look).

[Read more...]

Categories // Uncategorized Tags // appliance, database, Oracle, password, postgres, root, username, vami, vcloud suite, vmware, vpostgres, vSphere

  • « Previous Page
  • 1
  • 2
  • 3
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...