WilliamLam.com

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

vCenter Server 6.0 Tidbits Part 2: What is my SSO Domain Name & Site Name?

04.07.2015 by William Lam // 27 Comments

When deploying an Embedded vCenter Server or an external Platform Services Controller, one of the configurations you will be asked for is the vCenter Single Sign-On Domain Name and Site Name as seen in the screenshot below.

Screen Shot 2015-04-02 at 2.54.22 PM
In addition to troubleshooting, you will also need to know about the SSO Domain Name + Site Name if you plan on deploying additional Platform Services Controller for replication purposes or additional vCenter Servers. It is important to note that you do not need to know this information explicitly when deploying using the new Guided UI Installation. You just need to know the hostname/IP Address of your PSC as the rest of the information will automatically be obtained by the tool.

locate-sso-site-name-1
The issue only arises when you are trying to perform a Scripted Installation and this is where you will need to provide both the SSO Domain Name and Site Name and below are the instructions on retrieving this information.

First off, you will need to login to your Platform Services Controller whether that be on a Windows Server or the VCSA.

SSO Domain Name

You will find it in the following two configuration files:

Windows:

C:\ProgramData\VMware\vCenterServer\cfg\install-defaults\vmdir.domain-name

VCSA:

/etc/vmware/install-defaults/vmdir.domain-name

VCSA 6.0u2:

/usr/lib/vmware-vmafd/bin/vmafd-cli get-domain-name --server-name localhost

For more details, check out my previous blog post: vCenter Server 6.0 Tidbits Part 1: What install & deployment parameters did I use?

SSO Site Name

First, you will need to identify where your Lookup Service is running on which is located on your PSC or your Embedded VC instance. What we are ultimately looking for is Lookup Service URL which is in the following format: https://[SERVER]/lookupservice/sdk If for whatever reason you do not know where your PSC is, then you can login to your vCenter Server and find the Lookup Service URL by running the following command:

Windows:

"C:\Program Files\VMware\vCenter Server\vmafdd\vmafd-cli.exe" get-ls-location --server-name localhost

VCSA:

/usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location --server-name localhost

locate-lookupservice
Once we have the Lookup Service URL, we can then find the SSO Site Name by running the following command:

Windows:

"C:\Program Files\VMware\vCenter Server\python\python.exe" "C:\Program Files\VMware\vCenter Server\VMware Identity Services\lstool\scripts\lstool.py" get-site-id --url https://vcenter60-6.primp-industries.com/lookupservice/sdk"

VCSA:

/usr/lib/vmidentity/tools/scripts/lstool.py get-site-id --url https://vcenter60-6.primp-industries.com/lookupservice/sdk 2> /dev/null

locate-sso-site-name-2
VCSA 6.0u2:

/usr/lib/vmware-vmafd/bin/vmafd-cli get-site-name --server-name localhost

As you can see the process to find the SSO Site Name is not really intuitive, but I know Engineering is aware of this and has plans to simplify this in the future.

  • vCenter Server 6.0 Tidbits Part 1: What install & deployment parameters did I use?
  • vCenter Server 6.0 Tidbits Part 2: What is my SSO Domain Name & Site Name?
  • vCenter Server 6.0 Tidbits Part 3: Finding all deployed Platform Services Controller
  • vCenter Server 6.0 Tidbits Part 4: Finding all deployed vCenter Servers
  • vCenter Server 6.0 Tidbits Part 5: New method of patching the VCSA
  • vCenter Server 6.0 Tidbits Part 6: Customizing VCSA’s DCUI
  • vCenter Server 6.0 Tidbits Part 7: Connecting to SSO/PSC using JExplorer
  • vCenter Server 6.0 Tidbits Part 8: Useful ldapsearch queries for vmdird
  • vCenter Server 6.0 Tidbits Part 9: Creating & managing SSO users using dir-cli
  • vCenter Server 6.0 Tidbits Part 10: Automating SSO Admin configurations
  • vCenter Server 6.0 Tidbits Part 11: Automate SSO Admin password change
  • vCenter Server 6.0 Tidbits Part 12: New methods of downloading Support Bundles for VCSA / PSC

Categories // VCSA, vSphere 6.0 Tags // lookupservice, lstool.py, platform service controller, psc, sso domain name, sso site name, vCenter Server, vcenter server appliance, VCSA, vcva, vmafd-cli

vCenter Server 6.0 Tidbits Part 1: What install & deployment parameters did I use?

04.06.2015 by William Lam // 6 Comments

This is the first part in a new blog series that I will be working on in which I will be sharing some simple tips and tricks that I learned along the way while working with vCenter Server 6.0, these especially came in handy during the early development of vSphere 6.0. These tidbits will include information covering both the vCenter Server for Windows (VCS) as well as the vCenter Server Appliance (VCSA).

When installing VCS or deploying the VCSA, you are prompted to fill out a variety of inputs based on the deployment type, SSO Domain, database information, etc. These "install parameters" are then fed into the configuration of either your vCenter Server (Embedded) or separated out with vCenter Server Management Node and Platform Services Controller Node.

Screen Shot 2015-04-02 at 1.15.54 PM
After you successfully deployed your vCenter Server and say a couple of weeks has passed and you are now wondering what install parameters you used either for auditing, informational purposes or more likely you may need to know one of these parameters for adding additional instances say for Enhanced Linked Mode, how might you go and retrieve this information?

Luckily, VMware has made finding this information extremely easy by providing a tiny little utility called "install-parameter" and here are the locations for both platforms:

Windows:

"C:\Program Files\VMware\vCenter Server\bin\install-parameter.bat"

VCSA:

/bin/install-parameter

The utility accepts the name of a well defined set of installation parameters, an example would be "vmdir.domain-name" which specifies the name of the SSO Domain that you had configured:

vc-deployed-defaults-0
You can see the complete list of available installation parameters under the following paths in the two platforms:

Windows:

C:\ProgramData\VMware\vCenterServer\cfg\install-defaults

VCSA:

/etc/vmware/install-defaults

For your convenience, I have also listed all the installation parameters in the table at the very bottom of this post.

In addition to these installation parameters, there are two additional ones that I would like to mention which are not part of this list.

Database Type

The information is stored in a file called db.type with possible values of: embedded, oracle and mssql and here are the paths for the two platforms:

Windows:

C:\ProgramData\VMware\vCenterServer\cfg\db.type

VCSA:

/etc/vmware/db.type

vc-deployed-defaults-2
The possible values for this files is: embedded, oracle and mssql

Deployment Type

The information is stored in a file called deployment.node.type with possible values of: embedded, management and here are the paths for the two platforms:

Windows:

C:\ProgramData\VMware\vCenterServer\cfg\deployment.node.type

VCSA:

/etc/vmware/deployment.node.type

vc-deployed-defaults-1
For those with a critical eye, you might have noticed there is one installation parameter that is not available in any of these files and that would be the SSO Domain Site Name. This property is not really important (outside of troubleshooting) unless you need to add additional Platform Services Controller and replicate with an additional one or adding additional vCenter Servers for enabling Enhanced Linked Mode support. This property is one of the required parameters when performing a scripted install but is not needed if performing the deployment using the guided install method. In the next blog post, I will show you how you can retrieve this property.

vCenter Server 6.0 Installation Parameter

autodeploy.ext.managementport
autodeploy.ext.serviceport
cis-license.int.http
cm.int.cmhttp
cm.url
cm.url.path
db.dsn
db.instance
db.presetupdone
db.provider
db.servername
db.serverport
db.user
eam.int.http
invsvc.int.http
mbcs.int.http
netdumper.ext.serviceport
netdumper.int.webport
perfcharts.int.https
rhttpproxy.cert
rhttpproxy.conf.path
rhttpproxy.ext.port1
rhttpproxy.ext.port2
sca.hostid
sca.int.scahttp
sps.int.pbmhttp
sps.int.pbmhttps
sps.int.smshttp
sps.int.smshttps
sps.int.spshttp
sps.int.spshttps
sshd.ext.port1
syslog.ext.port
syslog.ext.tls
syslog.int.http
syslog.int.port
system.hostname
system.hostname.type
system.urlhostname
system.vm0.hostname
vapi.int.endpoint-http
vapi.int.jmx-port
vc.conf.path
vc.home.path
vc.instance.cfg.path
vmafd.ext.port1
vmca.cert.dir
vmca.ext.port1
vmdir.admin-dn
vmdir.domain-dn
vmdir.domain-name
vmdir.ext.port1
vmdir.ext.port2
vmdir.ldap-port
vmdir.ldu-guid
vmdir.site-guid
vmdir.username
vmkdc.ext.port1
vmkdc.ext.port2
vmkdc.ext.port3
vpostgres.int.server_port
vpxd.ext.port1
vpxd.ext.port2
vpxd.int.sdk-port
vpxd.int.sdk-tunnel-port
vsan-observer.ext.port1
vsm.int.http
vsm.int.https
vsphere-client.ext.port1
workflow.int.jmx-port
workflow.int.service-port
workflow.int.vapi-port

  • vCenter Server 6.0 Tidbits Part 1: What install & deployment parameters did I use?
  • vCenter Server 6.0 Tidbits Part 2: What is my SSO Domain Name & Site Name?
  • vCenter Server 6.0 Tidbits Part 3: Finding all deployed Platform Services Controller
  • vCenter Server 6.0 Tidbits Part 4: Finding all deployed vCenter Servers
  • vCenter Server 6.0 Tidbits Part 5: New method of patching the VCSA
  • vCenter Server 6.0 Tidbits Part 6: Customizing VCSA’s DCUI
  • vCenter Server 6.0 Tidbits Part 7: Connecting to SSO/PSC using JExplorer
  • vCenter Server 6.0 Tidbits Part 8: Useful ldapsearch queries for vmdird
  • vCenter Server 6.0 Tidbits Part 9: Creating & managing SSO users using dir-cli
  • vCenter Server 6.0 Tidbits Part 10: Automating SSO Admin configurations
  • vCenter Server 6.0 Tidbits Part 11: Automate SSO Admin password change
  • vCenter Server 6.0 Tidbits Part 12: New methods of downloading Support Bundles for VCSA / PSC

Categories // VCSA, vSphere 6.0 Tags // db.type, deployment.node.type, install-parameter, vCenter Server, vcenter server appliance, VCSA, vcva, vSphere 6.0

A preview of native syslog support in VCSA 6.0

03.30.2015 by William Lam // 29 Comments

Proper logging of VMware hosts, services and application logs are becoming more and more critical these days and their usage goes beyond just troubleshooting. In many of our customer environments, extended log retention is often mandatory to satisfy auditing and compliance requirements. Support for remote syslog has been around in ESXi for quite some time and has included several enhancements over the years, however logging for vCenter Server itself has not changed much over the years. Historically, vCenter Server started out as a Windows application and outside of standard filesystem logging there is also Microsoft Event Logs which was not really all that useful. With the release of the vCenter Server Appliance (VCSA), syslog support became more attainable, at least without additional 3rd party tools.

I can even remember when I was an administrator, I had to get creative on how to forward vCenter Server logs to a remote syslog server which I had blogged about back in 2012. Though the solution works, it was not ideal especially when you are running several dozen to several hundred vCenter Server instances like many of our customers do today. When I had discovered that there was a Common Logging initiative within VMware for vSphere 6.0, I was pretty excited and I can only guess that this also put a big smile on many of our GSS folks faces 😉

As you can imagine this was no small undertaking, especially with the organic growth of services and applications within vCenter Server. The goal was not only to support native remote syslog but to also standardize on the location, rotation, retention of all the logs and most importantly providing a consistent time stamp of events so that an administrator or 3rd party tool can easily correlate operations across multiple VMware log files. Though complete native syslog support in vCenter Server is not 100% ready just yet, much of the plumbing and foundation has already been finished and in fact you can see some of this in the latest release VCSA 6.0.

With VCSA 6.0, there is partial support for native remote syslog which is configurable through the VMware Syslog Service under the new vCenter Server System Configuration found within the vSphere Web Client.

vcenter_server_6_syslog_1
There are four settings that you will need to configure:

  • Common Log Level - * (everything), info, notice, warn, error, crit, alert & emerg
  • Host - Hostname/IP Address of a *single* remote syslog server
  • Port - Port of the remote syslog server (514 for UDP & 1514 for TCP is already opened on the VCSA firewall)
  • Protocol - Supports tcp, udp & tls

A restart is not required when configuring the syslog service and logs will automatically be forwarded to the remote syslog server which is quite nice. You can also view the health status of the syslog service and its connectivity to the remote syslog server by clicking onto the "Summary" view as seen in the screenshot below. For more information about the new syslog service, check out the official documentation here.

vcenter_server_6_syslog_2
So what exactly does partial syslog support really mean? What logs are being forwarded to a syslog server when the syslog service is enabled?

There are currently two major sets of logs that are forwarded to a remote syslog server when the new syslog service is configured:

  1. All logs from ESXi hosts that are connected to the vCenter Server will be forwarded
  2. A partial set of vCenter Server services (details in table below) will be forwarded
Service Name Service Description Service Log Location
applmgmt-audit Appliance Management /var/log/vmware/applmgmt/applmgmt-audit/applmgmt-audit-syslog.log
audispd Audit Event Dispatcher /var/log/audit/audispd/audispd-syslog.log
auditd Audit System /var/log/audit/auditd/auditd-syslog.log
rbd Auto Deploy /var/log/vmware/rbd/rbd-syslog.log
vmafdd VMware Authentication Framework /var/log/vmware/vmafdd/vmafdd-syslog.log
vmcad VMware Certificate Service /var/log/vmware/vmcad/vmcad-syslog.log
vmdird VMware Directory Service /var/log/vmware/vmdird/vmdird-syslog.log
watchdog-rhttpproxy Watchdog for Reverse HTTP Proxy service /var/log/vmware/rhttpproxy/watchdog-rhttpproxy/watchdog-rhttpproxy-syslog.log
watchdog-syslog Watchdog for Syslog service /var/log/vmware/syslog/watchdog-syslog/watchdog-syslog-syslog.log
watchdog-vmware-vpostgres Watchdog for vPostgres DB service /var/log/vmware/vpostgres/watchdog-vmware-vpostgres/watchdog-vmware-vpostgres-syslog.log
watchdog-vpxd Watchdog for vCenter Server service /var/log/vmware/vpxd/watchdog-vpxd/watchdog-vpxd-syslog.log
watchdog-vws Watchdog for vCenter Web Services service /var/log/vmware/vws/watchdog-vws/watchdog-vws-syslog.log

Note: The information above was extracted from /etc/vmware-syslog/custom-file-location.conf

Here is a screenshot of my vRealize Log Insight instance ingesting the logs that have been forwarded over from my VCSA 6.0:

vcenter_server_6_syslog_7
Although not all the vCenter Server services have been integrated into this new native syslog mechanism, you can see where things headed and hopefully in the not too distant future we will have full native syslog support for all application and system logs found withint vCenter Server. One thing that I really do like is that I can go to one single location to configure my remote syslog server and automatically receive all logs from the ESXi hosts being managed by that vCenter Server and forwarded to the configured syslog server. This definitely makes it operationally friendly so that you have one less thing to configure when provisioning new ESXi hosts.

One limitation that I found when configuring your remove syslog server is that there is no way to reset the values to NULL and the UI also limits the number of remote syslog server to just one, even though you can specify multiple targets. One way to get around this UI limitation is by editing the underlying configuration file which is located in /etc/vmware-syslog/syslog.conf

Here is an example of what the syslog.conf looks like for the above configuration:

*.info @log.primp-industries.com:514;RSYSLOG_SyslogProtocol23Format

If you wish to add a second or even third syslog server, you simply just need to duplicate the existing line and update the hostname or IP Address of your syslog server.

*.info @log.primp-industries.com:514;RSYSLOG_SyslogProtocol23Format
*.info @log2.primp-industries.com:514;RSYSLOG_SyslogProtocol23Format

If you are manually editing the syslog.conf, you will need to restart the syslog service by running the following command for the changes to take effect:

/etc/init.d/vmware-syslog restart

Some of you might say this is great and all, but one of the most important log files which is the vCenter Server log (vpxd.log) is not being being forwarded. How useful is this really to me? I know I definitely asked that question 🙂 Though not ideal, there is a small configuration change you can apply to easily get vpxd.log to also forward to a remote syslog server using the new syslog service.

You will need to change the vCenter Server advanced setting "config.log.outputToSyslog" property (can also be done using vSphere API) from false to true as seen in the screenshot below.

vcenter_server_6_syslog_3
The above assumes you have already configured the syslog service and for this change to go into effect, you will need to restart the vCenter Server service. This can be done using the System Configuration and under the vCenter Server Service, by just right clicking and selecting "Restart".

vcenter_server_6_syslog_4
If we now look at our vRealize Log Insight instance or whatever syslog server you are using, you should now see entries from the vpx.log being forwarded:

vcenter_server_6_syslog_6
You can also perform this change from the command-line by editing the vCenter Server configuration file at /etc/vmware-vpx/vpxd.cfg and modifying <outputToSyslog>true</outputToSyslog>

vcenter_server_6_syslog_5
Once you have saved the changes, you will need to restart the vCenter Server by running the following command:

/etc/init.d/vmware-vpxd restart

For those of you who are considering vSphere 6.0 and using the VCSA, this is something I definitely recommend checking out to help simplify the management of both your logs for vCenter Server and your ESXi hosts. I know the VMware Engineering team is working hard on making native syslog support even easier in the future and I look forward to the complete solution hopefully in the near future.

Categories // ESXi, vSphere 6.0 Tags // ESXi 6.0, syslog, vCenter Log Insight, vCenter Server, vcenter server appliance, VCSA, vcva, vmsyslog, vpx.cfg, vpxd.log, vSphere 6.0

  • « Previous Page
  • 1
  • …
  • 22
  • 23
  • 24
  • 25
  • 26
  • …
  • 44
  • 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

  • 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
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/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...