Migrate Active Directory from 2003 R2 to 2008 R2 Server Core

This blog will step you through the process of migrating your Active Directory domain controllers from Microsoft Windows Server 2003 R2 to Windows Server 2008 R2 Server Core. Server Core is an excellent choice for dedicated domain controllers since it requires less maintenance, has a reduced attack surface, requires less management, and will run on less hardware. Lots of people are scared off by Server Core because there’s no GUI. 

 To be honest with you, it’s a blessing in disguise since you shouldn’t be managing your production Active Directory environment directly on your domain controllers anyway. You can remotely manage AD, DNS, DHCP, etc from your Windows 7 pc with a GUI interface by using the “Remote Server Administration Tools for Windows 7“. I’m sure the tools probably exist for Windows Vista also. See my blog on “How to create an Administrative shortcut” which will make your life a lot easier since the best practice is to log into your pc as a normal user (not as a user with elevated domain privileges).

Prerequisites:
(1) All of your existing active directory domain controllers need to be running Windows 2000 Service Pack 4 or higher.
(2) Your forest must be in at least Windows 2000 native mode.
(3) Verify your Antivirus and Backup agents will run on Windows Server 2008 R2 Server Core.

Copy the contents of the \support\adprep folder from the Windows Server 2008 R2 DVD to a location that is accessible by the schema master for your forest and the Infrastructure Master for each of your domains that you plan to update. The Schema Master is a forest level FSMO role (one per forest). How to identify the schema master article on TechNet. The Infrastructure Master is a domain level FSMO role (one per domain). How to identify the Infrastructure Master article on TechNet.

Log into the schema master as a user who is a member of the Enterprise Admins group and Schema Admins group. Open a command prompt and navigate to the folder where you copied the adprep utility. Run adprep32 /forestprep if the schema master is using a 32 bit version of Windows Server 2003 R2. Run adprep /forestprep if it is a 64 bit version. When the forestprep completes, you will receive the following message:

If all of your domain controllers are running Windows Server 2003 and your forest level is at the Windows 2003 level, then I recommend going ahead and preparing the forest for Read Only Domain Controllers by running adprep32 /rodcprep . When rodcprep completes you will receive the following:

Allow for the changes from the forestprep and rodcprep commands to propagate out to all of the domain controllers in your forest. You can use RepAdmin.exe to verify that the replication is complete. Run:
repadmin /replsum /bysrc /bydest /sort:delta and then repadmin /showrepl

Once the replication of the forest schema updates have completed to all domain controllers in your forest, login to the infrastructure master of each domain in the forest that will be updated to the Windows 2008 R2 level as a member of the domain admins group. Open a command prompt and navigate to the folder where you copied the adprep utility. Run:
adprep32 /domainprep /gpprep

If your domain is not at least in Windows 2000 native mode, you will receive the following error message:

Your forest and domains have now been updated so that you can introduce Windows Server 2008 R2 domain controllers. Since this blog focuses on migrating your active directory environment from Windows Server 2003 R2 to Windows Server 2008 R2 Core, you need to start with a fresh installation of Windows Server 2008 R2 on a new server. One thing to remember is that the R2 version of Windows Server 2008 is 64 bit only so you’ll need hardware capable of running a 64 bit operating system. Any server purchased in the last three years should be fine for the core edition since it has reduced hardware requirements, and in this example, I’m virtualizing the new domain controller using Hyper-V Server 2008 R2.

During the installation of the operating system, select one of the Server Core versions:

Once the installation of the operating system is complete, you are asked to change the password since the initial one is blank. Once this is complete and you log into the server, you notice the huge difference between the normal installation and core which only has a command prompt:

Run sconfig.cmd (which is only available on R2) from this command prompt to start the Server Configuration:

Set the computer name, configure the network settings, install windows updates, and add it to the domain. This process is much easier in the R2 version with sconfig instead of having to manually do everything from the command prompt.

To make this server a domain controller, Run:
dcpromo /unattend /InstallDNS:Yes /ReplicaOrNewDomain:Replica /ReplicaDomainDNSName:mikefrobbins.com /ConfirmGc:Yes  /UserName:mikefrobbins\administrator /Password:* /SafeModeAdminPassword:password /RebootOnCompletion:No

There are many more options for dcpromo /unattend. A list of these options can be found on TechNet. The following command will remove active directory services and revert the server back to a member server if needed.
dcpromo /unattend /AdministratorPassword:password

If you revert the domain controller back to a member server as referenced above, you’ll probably also want to remove the DNS Server role. To remove the DNSServer role, run:
Start /w ocsetup DNS-Server-Core-Role /uninstall

The oclist command will show you a list of roles that are currently installed.

Warning: You cannot manage a Windows Server 2008 R2 DNS Server from Windows Server 2003 R2. You will receive this error even though the DNS Server is operating properly:

To install the DHCP Server role on your core domain controller, execute the following command:
Start /w ocsetup DHCPServerCore

If you don’t use the start /w part of the command, it will still work, but it immediately returns you to a command prompt and you won’t know when the installation of the role has completed.

Set the DHCPServer service to start automatically:  sc config dhcpserver start= auto
Start the DHCPServer Service:  net start dhcpserver
Authorize the DHCPServer:  netsh dhcp add server dc102.mikefrobbins.com 10.0.0.2

Configure the remainder of the dhcp server options from another machine that has the GUI tools installed. Managing DHCP from a Windows Server 2003 R2 machine seems to work fine. Transfer the FSMO roles from your Windows Server 2003 R2 domain controllers before decommisioning them.

Enter the software license key:  slmgr /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
Activate the operating system:  cscript C:\windows\system32\slmgr.vbs -ato

Securing Wireless Networks with Windows Server 2008 and NPS

In this post I’m going to go through the process of securing your wireless network using Windows Server 2008 and the NPS (Network Policy Services) role from start to finish.

Previously, I was using Windows Server 2003 with IAS (Internet Authentication Services) to secure my wireless network, until I recently upgraded all of my servers to Windows Server 2008 – By the way, NPS is the new version and name for IAS.

Here is the TechNet guide which I followed – http://technet.microsoft.com/en-us/library/cc771455.aspx - I will be applying these guidelines to the following environment…

» A Windows Server 2008 machine running AD DS (Active Directory Domain Services)

» A Windows Server 2008 machine running NPS (Network Protection Services) and AD CS (Active Directory Certificate Services)

» A Linksys WAP54G (an entry level wireless access point – you can use any wireless access point that supports RADIUS)

You can run NPS, AD DS and AD CS on the same machine if you want to, but I wouldn’t recommend it (personally, I prefer to keep my domain controllers running only AD DS).

I’m not going to go through the process of installing AD DS as it’s a little out of scope for this post, so we’ll start from having an established domain, and a clean install of Windows Server 2008 on which we will install AD CS and NPS.

The first step is installing AD CS and NPS on your clean Windows Server 2008 install…

1.First, you’ll need to join the server to your existing domain and then restart;

2.After the server restarts, open Server Manager;

3.Click on the Roles node;

4.Click on the Add Roles;

5.On the Server Roles screen, select Active Directory Certificate Services and Network Policy and Access Services;

6.Follow the wizard, selecting Network Policy Server when configuring the Network Policy and Access Services role and leaving the default Certification Authority role service selected for AD CS;

7.Select Enterprise for the setup type for AD CS;

8.Choose Root CA for the CA Type (remember we’re assuming that this is the first Certification Authority in your environment, so if it’s not you either don’t need to install this role, or if you choose you can configure this server as a Subordinate CA instead);

9.Run through the rest of the wizard, making any changes you may wish to, otherwise just leave the defaults as they are appropriate (I changed the CA Common Name to the name of the server, as I think it’s cleaner) – Note that there is a warning at the end of the wizard, stating that the name of this server cannot be changed after installing the AD CS role.

Now that you have a Root CA and an NPS server on your domain, we can start configuring it…

1.Open an MMC console, and go to File -> Add/Remove Snap-in…

2.Add the Certificates snap-in, selecting Computer account for the local computer;

3.Expand Certificates (Local Computers) -> Personal, right click on Certificates and choose Request new certificate;

4.Follow the wizard, choosing Computer for the certificate type and then click the Enroll button, then close MMC;

5.Open the Network Policy Server administrative console from Administrative Tools;

6.Right click on the parent node, NPS (Local) and click Register server in Active Directory – Click OK on the two informational popups;

7.With the NPS (Local) node still selected, choose RADIUS server for 802.1X Wireless or Wired Connections and then click on the Configure 802.1X button;

8.Under Type of 802.1X connections, select Secure Wireless Connections and provide an appropriate name for the policies which will be created as part of this wizard;

9.In the next step, you’ll need to configure a RADIUS client (by the way, RADIUS stands for Remote Authentication Dial In User Service), so click on the Add button;

10.The RADIUS client will be your wireless access point, so for the friendly name type in something to identify the access point (for example, AP01), then provide the IP address or DNS entry for the access point;

11.Click on the Generate radio button, and then click on the Generate button to generate a shared secret – Copy the shared secret to a notepad document, and click OK – Note that on my particular access point, a character limit of 22 characters exists for shared secrets so I had to cut the string down to the acceptable limit, so I would suggest checking for this limitation on your own hardware;

12.Click Next, and then choose Microsoft: Protected EAP (PEAP) and then click on the Configure button (if you get an error message, you probably didn’t follow steps 1 -> 4 correctly);

13.Ensure that the Certificate issued drop down box has the certificate you enrolled in step 4;

14.Click Next, and then click on the Add button to use an Active Directory group to secure your wireless (you should add both the machine accounts and user accounts to this group to allow the machine to authenticate on the wireless before the user logs in);

15.On the next step of the wizard, you can configure VLAN information, otherwise just accept defaults to complete;

16.Restart the Network Policy Server service.

If you expand the Policies node now, you’ll see that the wizard has created a Connection Request Policy and a Network Policy containing the appropriate settings to authenticate your wireless connection – These individual policies can obviously be created manually, but the wizard is an easier method.

You can also remove the less secure authentication method options, and increase the encryption methods in the network policy if you wish (I have configured mine this way)…

1.Under the Network Policies node, bring up the properties of the newly created policy;

2.On the Constraints tab, uncheck all of the checkboxes under Less secure authentication methods;

3.On the Settings tab, click on Encryption and uncheck all boxes except Strongest encryption (MPPE 128-bit);

4.Save the policy and then restart the Network Policy Server service.

With the NPS server configured to accept requests from your wireless access point, you’ll now need to configure the access point to communicate with the NPS servers – These instructions are for my Linksys WAP54G, but will be similar to most access points which support RADIUS…

1.In the web interface for the access point, click on the Wireless tab and assign an appropriate SSID;

2.Click on the Security sub-tab, and set the Security Mode to WPA-Enterprise (if your access point supports WPA2-Enterprise, use this instead);

3.Set the Encryption to AES, and then provide the NPS server IP as the RADIUS Server and the Shared Secret that you saved in step 11 above;

4.Save your settings and restart the access point.

Now your access point should be configured to talk to your NPS server, so all that is left is to configure your clients to connect – The recommended way of doing this, would be to use Group Policy, but the instructions below are for configuring a Windows Vista client – You can easily replicate these actions in a Group Policy under the Security node.

To configure a Windows Vista client which is joined to the domain…

1.Open up the Network and Sharing Center;

2.Click on Connect to a network;

3.Locate the network you have just secured (it should say Security-enabled network next to it) and click the Connect button;

4.It will take a short while to set up the profile and then connect successfully.

You can also configure a few extra settings to speed up the time it takes to connect (it won’t improve the overall speed, only the time it takes to initially connect to the wireless network)…

1.In the Network and Sharing Center, click on Manage wireless networks and then double click the network you set up above;

2.Click the Security tab, and then the Settings button below;

3.The Validate server certificate checkbox should already be selected by default, but you should also select the CA that you set up earlier under the Trusted Root Certification Authorities to speed up the certificate verification process;

4.You can also check the box Do not prompt user to authorize new servers or trusted certification authorities in order to improve the user’s experience.

Some suggestions recommendations…

» Use a security group with the appropriate machine and user accounts as members to secure your network;

» Group Policy is by far the best way to deploy the client side settings, but will obviously require an established domain connection in order to push these settings down to the clients;

» While disabling the SSID of your access point sounds like an increased security measure, it can be a security risk if you are configuring your workstations to actively look for the SSID name – Potential session hijackers could intercept this traffic and set up an SSID for the requested name, unknowingly to the user which would then connect to a potentially malicious network;

» You can vary the encryption type from AES to TKIP if your devices don’t all support AES, although AES is the preferred encryption algorithm;

» If you’re having trouble with your connection, there are a few places you can look to troubleshoot, namely – Local client event logs, the NPS log file which lives in C:WindowsSystem32logfiles and most importantly the Security event logs of the NPS server which contains detailed information about access successes and failures.

Enhanced vMotion Compatibility

Enhanced vMotion Compatibility (EVC) is available for a while now, but it seems to be slowly adopted. Recently VMguru.nl featured an article “Challenge: vCenter, EVC and dvSwitches” which illustrates another case where the customer did not enable EVC when creating the cluster. There seem to be a lot of misunderstanding about EVC and the impact it has on the cluster when enabled.

What is EVC?
VMware Enhanced VMotion Compatibility (EVC) facilitates VMotion between different CPU generations through use of Intel Flex Migration and AMD-V Extended Migration technologies. When enabled for a cluster, EVC ensures that all CPUs within the cluster are VMotion compatible.

What is the benefit of EVC?
Because EVC allows you to migrate virtual machines between different generations of CPUs, with EVC you can mix older and newer server generations in the same cluster and be able to migrate virtual machines with VMotion between these hosts. This makes adding new hardware into your existing infrastructure easier and helps extend the value of your existing hosts. EVC forces newer processors to behave like old processors Well, this is not entirely true; EVC creates a baseline that allows all the hosts in the cluster that advertises the same feature set. The EVC baseline does not disable the features, but indicates that a specific feature is not available to the virtual machine.

Now it is crucial to understand that EVC only focuses on CPU features, such as SSE or AMD-now instructions and not on CPU speed or cache levels. Hardware virtualization optimization features such as Intel VT-Flexmigration or AMD-V Extended Migration and Memory Management Unit virtualization such as Intel EPT or AMD RVI will still be available to the VMkernel even if EVC is enabled. As mentioned before EVC only focuses of the availability of features and instructions of the existing CPUs in the cluster. For example features like SIMD instructions such as the SSE instruction set. 

Let’s take a closer look, when selecting an EVC baseline, it will apply a baseline feature set of the selected CPU generation and will expose specific features. If an ESX host joins the cluster, only those CPU instructions that are new and unique to that specific CPU generation are hidden from the virtual machines. For example; if the cluster is configured with an Intel Xeon Core i7 baseline, it will make the standard Intel Xeon Core 2 feature plus SSE4.1., SSE4.2, Popcount and RDTSCP features available to all the virtual machines, when an ESX host with a Westmere (32nm) CPU joins the cluster, the additional CPU instruction sets like AES/AESNI and PCLMULQDQ are suppressed. 

As mentioned in the various VMware KB articles, it is possible, but unlikely, that an application running in a virtual machine would benefit from these features, and that the application performance would be lower as the result of using an EVC mode that does not include the features.

DRS-FT integration and building block approach
When EVC is enabled in vSphere 4.1, DRS is able to select an appropriate ESX host for placing FT-enabled virtual machines and is able to load-balance these virtual machines, resulting in a more load-balanced cluster which likely has positive effect on the performance of the virtual machines. More info can be found in the article “DRS-FT integration”.

Equally interesting is the building block approach, by enabling EVC, architects can use predefined set of hosts and resources and gradually expand the ESX clusters. Not every company buys computer power per truckload, by enabling EVC clusters can grow clusters by adding ESX host with new(er) processor versions.

One potential caveat is mixing hardware of different major generations in the same cluster, as Irfan Ahmad so eloquently put it “not all MHz are created equal”. Meaning that newer major generations offer better performance per CPU clock cycle, creating a situation where a virtual machine is getting 500 MHz on a ESX host and when migrated to another ESX host where that 500 MHz is equivalent to 300 MHz of the original machine in terms of application visible performance. This increases the complexity of troubleshooting performance problems. 

Recommendations?
No performance loss will be likely when enabling EVC. By enabling EVC, DRS-FT integration will be supported and organizations will be more flexible with expanding clusters over longer periods of time, therefor recommending enabling EVC on clusters. But will it be a panacea to stream of new major CPU generation releases? Unfortunately not! A possibility is to treat the newest hardware (Major releases) as a higher service as the older hardware and because of this create new clusters

vSphere cluster: max 4 ESX hosts per “location” because of HA limitations?

 Duncan Epping has a couple of extremely interesting posts on Yellow-Bricks.com concerning HA even when it comes down to selecting or promoting the HA status of ESX nodes (a must read!), but I want more …

Let’s start with what I assume to know about HA:

- HA works with primary and secondary HA nodes
- The primary nodes are aware of the states and configs of all nodes in an HA cluster
- The secondary nodes depend on the primary nodes
- There is an supported limit of 5 primary HA nodes per cluster
- The first 5 ESX hosts that are added in a HA cluster are initially defined as primary HA nodes
- All the other hosts that are added to the HA cluster are configured as secondary HA nodes
- There’s a way to configure a HA node as primary or secondary, however it’s not possible to configure an ESX host as a “fixed” primary HA node:

• /opt/vmware/aam/bin/Cli

AAM> promotenode (Configure host as a primary HA node)

• /opt/vmware/aam/bin/Cli

AAM> demotenode    (Configure host as a secondary HA node)

- One primary HA node is the Active Primary HA node; this node coordinates the restarts of the VM’s that went down with “crashed” host.
- When the Active Primary HA node goes down, another primary is (s)elected as Active Primary HA node” and takes over the coordinating role.
- A new primary is chosen when another primary is disconnected from the cluster in one of these situations:

•  (Re)configuring HA on a host
• Disconnecting a host from the cluster (manually or by failure)
• Removing a host from the cluster
• In case of a HA failure
• Putting a host into maintenance mode

Especially when you read the last bullet we can establish that HA roles are really dynamic in a VI/vSphere environment. This means that you have no control over the physical location of the primary and secondary roles.

And this is what my post is about:

This situation freaks me out because when you have a larger environment with a couple of possible failure domains as I’d like to call them (represented by any physically separated group of hosts within an HA cluster like different blade chassis or different server rooms) you want to have control over the placement of these HA roles.

And as I stated earlier Duncan Epping has some interesting articles like the HA deep dive and the Primary and Secondary nodes, pick one! which describe how to select a role for a host but this selection is not static; whenever a primary host is disconnected (Maintenance mode, Reconfigure HA and so on) there is a reelection and you lose control over the role placement.

So what if all 5 primaries HA nodes are on the same “possible failure domain” (say blade chassis) and that goes down? Well you just lost all your HA nodes that know what to do in case of a host-failure, so HA won’t work!

We’ll have to nuance the drama a bit: if 5 hosts of a “10 ESX host cluster” go down, you have a major issue anyway, if HA works or not, because you lost half of your capacity.

But you do have to realize that if HA is configured correctly, the 5 remaining hosts have some resources available, you have your primaries separated over the 2 locations and you have defined the start-up rules for the most important VM’s, these important VM’s will be booted up.

If you have the same situation as above but with all 5 primary HA nodes down because they were physically grouped, HA won’t work and none of the crashed VM’s will be booted up automatically!

During VMworld 2009 Marc Sevigny from VMware explained that they were looking into an option which would enable you to pick your primary hosts.This would solve the problem but until then the only solution is to keep your clusters limited to a total of 8 ESX hosts , 4 ESX hosts per “possible failure domain”.

I’m curious if I’m the only one running into this challenge; please let me know!

P.S. Special kudo’s go to Remon Lam from vminfo.nl who discovered this “feature” and reviewed the article.

DSR Direct Routing Loopback Adapters in Windows Server 2008

Recently I ran across an interesting networking issue when using a DSR load balancing setup when converting from Windows Server 2003 to Windows Server 2008. It seems that microsoft has changed the way that the TCP/IP stack functions, so that when we went to configure the loopback adapters and setup IIS to run our websites, the server was unreachable. Worse it had a negative effect on routing to our production servers, since the server in question runs as an auxillary server for the production sites.


Anyhow, we finally found a great article that chronicles the issues, and how to correct them. It all boils down to a couple of commands on the command line to correct it:

netsh interface ipv4 set interface "net" weakhostreceive=enabled


netsh interface ipv4 set interface "loopback" weakhostreceive=enabled


netsh interface ipv4 set interface "loopback" weakhostsend=enabled

esxcfg-vswitch - Virtual Switch Configuration tool

NAME

esxcfg-vswitch - VMware ESX Server Virtual Switch Configuration tool 

COPYRIGHT

VMware ESX Server is Copyright 2006 VMware, Inc. All rights reserved. 

SYNOPSIS

esxcfg-vswitch OPTIONS [VSWITCH] 

DESCRIPTION

esxcfg-vswitch provides an interface for adding, removing, and modifying virtual switches and their settings. By default, there is a single virtual switch called vSwitch0. 

OPTIONS

-a -add 

Add a new virtual switch to the system. It requires a virtual switch name to be provided. 

-d -delete 

Delete a virtual switch. This will fail if any ports on the virtual switch are still in use by VMkernel networks, vswifs, or VMs. 

-l -list 

List all virtual switches and their port groups. 

-L -link 

Add an uplink to a virtual switch. This will attach a new unused physical NIC to a virtual switch. 

-U -unlink 

Remove an uplink from a virtual switch. This will remove a NIC from the uplink list of a virtual switch. If it is the last uplink, physical network connectivity for that switch will be lost. 

-p -pg 

Provide the name of the portgroup for the '--vlan' option. "ALL" can be specified to operate on all portgroups of a virtual switch. 

-v -vlan 

Set the VLAN ID for a specific portgroup of a virtuals switch Using the option "0" will disable VLAN for this portgroup. Requires that the --pg option is also specified. 

-c -check 

Check to see if a virtual switch exists. The program prints a "1" if it exists; otherwise it prints "0". 

-A -add-pg 

Add a new portgroup to a virtual switch with the given name. 

-D -del-pg 

Delete a portgroup. This operation will fail if the portgroup is in use. 

-C -check-pg 

Check to see if the name given is in use for a portgroup. The program prints a "1" if it exists; otherwise prints "0". 

-r -restore 

Used at system startup to restore configuration. This should not be run by users. 

-h -help 

Print a simple help message. 

EXAMPLES

Add a Virtual Switch called vswitch1: 

esxcfg-vswitch -a vSwitch1

Add a Portgroup called 'Production' to vSwitch0:

esxcfg-vswitch -A Production vSwitch0

Add a physical network card, vmnic3, to vSwitch0:

esxcfg-vswitch -L vmnic3 vSwitch0

To remove the vlan id completely, just set it to 0 (in case you have set it by accident on an access port)

esxcfg-vswitch vSwitch0 -v 0 -p “Service Console”

To set a vlan id on the service console (in case you forgot to define this during the installation)

esxcfg-vswitch vSwitch0 -v X -p “Service Console” (enter the vlan number where X is)

Of course make sure to check which vSwitch the Service Console is on (and the name of the Service Console) with esxcfg-vswitch -l

Recover ASA Software from ROMMON

Just putting these commands in a handy place since this seems to happen more often than I thought...
rommon #1> ADDRESS=192.168.1.10
rommon #2> SERVER=192.168.1.1
rommon #3> GATEWAY=192.168.1.1
rommon #4> IMAGE=asa800-232-k8.bin
rommon #5> PORT=Ethernet0/0
rommon #6> tftp

ASA/PIX Order of Operations

====================
Packet Flow Sequence
====================
PIX/ASA - Inside (Higher Sec_Lev) to Outside (Lower SEC_Level)
---------------------------------------------------------------
Eg. Type - [Sub-Type] - Description
1. FLOW-LOOKUP - [] - Check for existing connections, if none found create a new connection.
2. ROUTE-LOOKUP - [input] - Initial Checking (Reverse Path Check, etc.)
3. ACCESS-LIST - [log] - ACL Lookup
4. CONN-SETTINGS - [] - class-map, policy-map, service-policy
5. IP-OPTIONS - [] -
6. NAT - [] - xlate
7. NAT - [host-limits] -
8. IP-OPTIONS - [] -
9. FLOW-CREATION - [] - If everything passes up until this point a connection is created.
10. ROUTE-LOOKUP - [output and adjacency] -

Using ESXTOP With VMware ESXi

Just a quick post about using ESXTOP with VMware ESXi. Obviously in ESXi there is no Service Console so we have to use the vMA (vSphere Management Assistant) to help us. If you haven't installed the vMA on your infrastructure yet, you can download it here:http://www.vmware.com/support/developer/vima/

Once install and configured, login and run the following command: resxtop –server

You will be prompted to login, use the root user/pass of the Host you want to run ESXTOP on (Note: Logging in as root will not work if the Host is in "Lockdown Mode".). You should then be presented with ESXTOP, I believe it has all of the same function as it did in the Service Console

Here you can see all avaliable options when connecting to a Host using RESXTOP

usage: resxtop [-h] [-v] [-b] [-s] [-a] [-c config file] [-d delay] [-n iterations]
               [--server server-name [--vihost host-name]] [--portnumber socket-port] [--username user-name]
              -h prints this help menu.
              -v prints version.
              -b enables batch mode.
              -s enables secure mode.
              -a show all statistics.
              -c sets the esxtop configuration file, which by default is .esxtop4rc
              -d sets the delay between updates in seconds.
              -n runs resxtop for only n iterations.
              --server      remote server name.
              --vihost      esx host name, if --server specifies vc server.
              --portnumber  socket port, default is 443.
              --username    user name on the remote server.
       for more information on interactive and batch modes
       please see man page for resxtop.