Difference between ESXi Shell time-outs

ESXi Advanced Settings have two timeout parameters to manage ESXi Shell timeout:

• UserVars.ESXiShellTimeOut 
• UserVars.ESXiShellInteractiveTimeOut

Both parameters are by default set to 0 which means the time-outs are disabled. However, it is good practice to set these timeouts as it has a positive impact on security.

But what values should be set there?
What is the difference between ESXiShellTimeOut and ESXiShellInteractiveTimeOut?

Let's start with description of both parameters available in ESXi hosts.

UserVars.ESXiShellTimeOut
Key: UserVars.ESXiShellTimeOut
Description: Time before automatically disabling local and remote shell access (in seconds, 0 disables). Takes effect after the services are restarted.
Value: 0
Default: 0
Read only: No
Range: 0 ≤ x ≤ 86400

UserVars.ESXiShellInteractiveTimeOut
Key: UserVars.ESXiShellInteractiveTimeOut
Description: Idle time before an interactive shell is automatically logged out (in seconds, 0 disables). Takes effect only for newly logged in sessions.
Value: 0
Default: 0
Read only: No
Range: 0 ≤ x ≤ 86400

Is it clear? No? So, here is a more human-readable explanation ...

On ESXi host are following two shells:

• ESXi Shell (Local Troubleshooting Shell available in Local Console) 
• SSH Service (Remote Shell)

What does UserVars.ESXiShellTimeOut setting?
If you want to troubleshoot ESXi locally or remotely, you have to enable services ESXi Shell or SSH. We are talking about ESXi services highlighted in the figure below.

ESXi Shell and SSH services

Advanced setting parameter UserVars.ESXiShellTimeOut is the time in seconds how long are these services (ESXi Shell and SSH) running when explicitly started by vSphere admin for troubleshooting. The default value of UserVars.ESXiShellTimeOut is 0, therefore these services will stay up and running until vSphere admin stop them manually. There is a potential risk that vSphere admin will forget to stop these services after troubleshooting and it would have a negative impact on security as these services should be running only for troubleshooting. That's the reason for best practice to set this timeout setting to some reasonable time for troubleshooting and to stop services automatically after configure time. I think the reasonable time for troubleshooting is for example 4 hours which is 14400 seconds.

What does UserVars.ESXiShellInteractiveTimeOut setting?
If you have started ESXi services ESXi Shell or SSH Service you can do local or remote troubleshooting. Advanced settings parameter UserVars.ESXiShellInteractiveTimeOut configures timeout from the active (interactive) session. In other words, if you do a troubleshooting via SSH session (SSH service must be running) this setting will close the active SSH session in case of idle (no interaction) is higher then UserVars.ESXiShellInteractiveTimeOut value. So, it will close your interactive SSH session but SSH service will stay up and running so you can reconnect and continue with troubleshooting. The same principle applies to local troubleshooting with ESXi Shell.

Do these settings have any impact on Direct Console UI?

No. None of the above two advanced settings have any impact on Direct Console UI (aka DCUI, ESXi Text-based Menu available in Local Console). DCUI is not considered as a shell.

Hope the explanation above help you to understand the difference. If not, please leave the comment below the blog post.

Script to create VMware SRM database

VMware SRM installer creates tables in database automatically but you must prepare MS-SQL database, DB schema and ODBC data source before SRM installation.

Note: SRM has technical requirement to use database schema having the same name as DB user.

Here is the script to prepare MS-SQL database (SITE-A-SRM), schema (SRMlogin) and DB user (SRMlogin) with password (SRMpassword) for SRM:

CREATE DATABASE [SITE-A-SRM];
GO
USE [SITE-A-SRM];
GO
CREATE LOGIN [SRMlogin] WITH PASSWORD=N'SRMpassword', DEFAULT_DATABASE=[SITE-A-SRM], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
BEGIN
EXEC sp_changedbowner 'SRMlogin'
EXEC sp_executesql N'CREATE SCHEMA SRMlogin'
END

I hope it is obvious to everybody that the same procedure (probably with little bit different colored items) must be done in database on SITE-B for second SRM instance.

I generally believe that scripts are better, faster, more consistent and less error-prone then manually creating something via GUI.

Credits: SQL script has been created  by customer's database admin (Ladislav Hajek) contributing with me on SRM project.