Active Directory Web Services fails to read the settings for the specified Active Directory Lightweight Directory Services instance (1023864)
- After installing vCenter Server, the Active Directory Web Services (ADWS) is unable to read the settings for the specified Active Directory Lightweight Directory Services (AD LDS) instance
- You see the error:
Active Directory Web Services encountered an error while reading the settings for the specified Active Directory Lightweight Directory Services instance. Active Directory Web Services will retry this operation periodically.
- Microsoft Event ID: 1209
ADWS reads these registry entries to check for the configuration settings:
Value: Port LDAP
Data: 1 – 65535 (default: 389)
Value: Port SSL
Data: 1 – 65535 (default: 636)
To resolve this issue:
- Verify that the above registry keys exist and have appropriate values.
- Ensure that the NT AUTHORITY\SYSTEM account has permission to read the values.
- Verify that ADWS runs under the Local System account.
- Ensure that the HKLM\System\CurrentControlSet\Services\<ADAM_INSTANCE_NAME>\Parameters\Port SSL
key is of type REG_DWORD. If the value is REG_SZ, you must delete it and create a new REG_DWORD with the value 636 (decimal).
- HA fails to configure on an ESXi host
- Installing HA (FDM) on an ESXi host in lockdown mode fails
- Unable to configure HA on an ESXi host.
- In the vSphere Client connected to vCenter Server, you see these errors:
- Cannot install the vCenter agent service
- vSphere HA agent cannot be correctly installed or configured.
- In the /var/run/log/fdm-installer.logfile, you see entries similar to:
[pre]fdm-installer:  2011-09-07 07:41:40: Logging to /var/run/log/fdm-installer.log fdm-installer:  2011-09-07 07:41:41: extracting vpx-upgrade-installer/VMware-fdm-eesx-3-linux-455964.tar.gz...  2011-09-07 07:41:41: exec rm -f /tmp/vmware-root/ha-agentmgr/upgrade  2011-09-07 07:41:41: status = 0  2011-09-07 07:41:41: exec cd /tmp/vmware-root/ha-agentmgr/vpx-upgrade-installer  2011-09-07 07:41:41: status = 0 fdm-installer:  2011-09-07 07:41:41: Installing the VIB fdm-installer:  2011-09-07 07:41:41: Result of esxcli software vib install -v=/tmp/vmware-root/ha-agentmgr/vpx-upgrade-installer/vmware-fdm.vib: Connect to localhost failed: Permission to perform this operation was denied.[/pre]
- If the ESXi host is in Lockdown mode before the upgrade when it re-connects to the vCenter Server after the upgrade the following error may be reported when HA attempts to re-configure:unknown installer error
- Disable lockdown mode in the ESXi host. For more information, see Enabling or disabling Lockdown mode on an ESXi host (1008077)
- In vCenter Server, right-click the host and click Reconfigure HA.
- After HA is reconfigured, you can re-enable lockdown mode.
While navigating in the vSphere client the other day I noticed a new tab. When selecting a Datacenter object, a tab called IP Pools appeared. When clicking on this tab you had the option to view and add IP Pools. Having never seen this before my first thought was, what are IP Pools?
After doing some research I found out they were part of the new vApps feature in vSphere. I’ve heard a little about vApps but never looked at them in depth, so I thought I would take the time to research them and write about them.
We’ll come back to IP Pools in a bit. First we’ll cover what a vApp is and how they work in vSphere. VMware’s definition of a vApp is below:
A logical entity comprising one or more virtual machines, which uses the industry standard Open Virtualization Format to specify and encapsulate all components of a multi-tier application as well as the operational policies and service levels associated with it.
A vApp is basically a resource container for multiple virtual machines that work together as part of a multi-tier application.
An example of a multi-tier application is a typical Web-based application where you might have three tiers: Web, application and database; which are often run on three separate servers. For example, you may have Microsoft IIS running on one server (tier 1), IBM WebSphere running on another server (tier 2) and a Microsoft SQL Server running on a third server (tier 3).
The three applications on each server all work together and are mostly dependent on each other for the application to function properly. If one part of the tier became unavailable, the application will typically quit working as it relies on all the tiers for the application to work.
Virtualization can introduce some challenges with multi-tier applications. For example, if one tier is performing poorly due to resource constraints on a host, then the whole application will suffer as a result. Another challenge comes when powering on a host server, as often times one tier relies on another tier to be started first or the application will fail.
VMware introduced vApps as a method to deal with these problems by providing methods for setting power-on options, IP address allocation and resource allocation, and provide application-level customization for all the virtual machines in the vApp. When you configure a vApp in vSphere you specify properties for it, including CPU and memory resources, IP allocation, application information, and start order, as shown below.
Once you are done configuring a vApp, you can add virtual machines (VMs) to it by dragging them using the vSphere client. You can also create resource pools inside of them and nest vApps inside of vApps. If you edit the settings of a VM, select the Options tab, and then select vApp Options, you can enable the vApp functionality for the VM and set individual vApp options for the VM. Once you have created a vApp you can easily export it in Open Virtualization Format (OVF) format, as well as deploy new vApps from one that are already created. To use vApps you must have a Distributed Resource Scheduler-enabled cluster; all of the meta-data information for a vApp is stored in the vCenter Server database.
So now that you know what a vApp is, back to what IP Pools are. IP Pools, as you might have guessed, are pools of IP addresses that you can associate with vSwitch port groups. They essentially act as Dynamic Host Configuration Protocol (DHCP) servers to assign IP addresses from the pool to a VM, so essentially the vCenter Server is acting as a DHCP server. When you configure an IP Pool you specify a range of either IPv4 or IPv6 addresses, DNS and proxy settings, and finally select which vSwitch port groups that the pool will be available to.
To configure an IP address range you need to do it in the following format with the starting IP address, a pound sign and the number of IP addresses, like this:
So the above range would make the following IP addresses available in the IP Pool:
172.20.20.155 - 172.20.20.164 and 172.20.20.175 - 172.20.20.179
Once you have an IP Pool configured, you can assign it to a vApp by editing its properties and changing the IP Allocation Policy from Fixed to Transient. For more information on configuring and using vApps and IP Pools check out the resources below.