Installing VMware vShield Edge Manager

While I know installing the VMware vShield Edge Manager isn’t exactly all that exciting, I took the time to document during a deployment in a test lab and what better to way to use some of these screenshots than to write up a blog post.  There isn’t a whole lot to during the install but for those who are interested in knowing what the install looks like, please read on.

Proceed with downloading the VMware vShield Edge Manager from the VMware downloads site as shown in the screenshot below:

Once you’ve downloaded the OVA file, open up your vSphere Client, log into vCenter, select File –> Deploy OVF Template…:

Browse and select the OVA file you’ve downloaded:

Click Next:

The details of the OVF summarizing what you’re deploying will be displayed:

Agree to the EULA as we always do:

Choose a descriptive name for the vShield Manager:

Select the host you would like to deploy the vShield Manager on:

Choose to either Thick or Thin provision the vShield manager:

Review the summary and click finish to begin the deployment:

As with any other OVAs, vCenter will begin creating the virtual machine:

 

 

Once completed, you’ll see a new virtual machine in your cluster:

Proceed with powering up the virtual machine and open up the console:

The vShield operating system will begin to load:

Believe it or not, it took me awhile to figure out what the what the login credentials were because I missed it in the manual so in case anyone is searching for what the default vShield Manager admin credentials are, it’s:

Login: Admin

Password: default

Once you’ve successfully logged in, begin the setup by typing:

enable

setup

The wizard will ask you for the following:

1. IP Address
2. Subnet Mask
3. Default gateway
4. Primary DNS IP
5. Secondary DNS IP
6. DNS domain search list

Once you’ve completed the wizard, exit the vShield Manager console by typing exit and log back in:

You can check to see whether your IP address setting was applied with the following command:

show interface

Once you’ve confirmed that the settings you’ve configured during setup has been applied, launch a browser and browse to the vShield Manager’s IP address:

Login with the admin/default credentials:

Once you’ve successfully logged in, you will be placed in the configuration page:

You can navigate around the other pages such as the Updates page:

The Users page:

The System Events page:

The Audit Logs page:

To complete the setup, navigate to the configuration page, proceed with entering your vCenter Server information and click on the Save button.  Once you’ve saved the vCenter information, you’ll see the following message:

Changing the vCenter address may result in unpredictable behavior. Please update only if you change IP of your current vCenter Server.

Note:  Please make sure you complete the vCenter information before proceeding to the next step.

 

Complete the install by registering vShield Manager as a Plug-in in vCenter by clicking on the Register button.  Once you’ve done so, you’ll see the following message:

Plugin is registered successfully

You should also confirm that the plugin shows up in the Plug-in Manager of vCenter:

Nothing too fancy but this should give you an idea of how simple it is to install and register the vShield Manager.  Configuring it will require much more thought.

Lync Server 2010 Desktop Share issue with Windows 7 and UAC: “Share control is disabled for elevated applications.”

For those who have come across one of my earlier posts about:

OCS 2007 R2 Desktop Share issue with Windows 7 and UAC

http://terenceluk.blogspot.com/2010/10/ocs-2007-r2-desktop-share-issue-with.html

… I finally had some time over this weekend to try testing the same scenario with Microsoft Lync and the results were more or less the same with the only difference being a new warning message is displayed in the Lync client. The following screenshots demonstrates the problem:

A desktop share is initiated:

The shared desktop loads:

Control is given to the person viewing the shared desktop and he proceeds to open the registry editor:

Opening the registry triggers UAC so the person viewing the shared desktop sees the following message:

Sharing is currently paused.

The person sharing their desktop sees the following:

Once the user sharing their desktop proceeds with selecting Yes to UAC, the shared screen loads:

However, the person viewing the shared desktop can no longer move the mouse. The person sharing the desktop can reclaim control:

Then give control again:

While the person viewing the desktop can move the mouse again, they will find that they cannot move or interact with the registry editor. What’s different about Lync Server 2010 and OCS 2007 R2 with this issue is that in Lync, you will see the following warning message in the instant message window of the person sharing their desktop:

Share control is disabled for elevated applications.

Clicking on the text will show the following message:

There are applications running at an elevated privilege on your desktop. A participant in control will not be able to control these applications.

As with OCS 2007 R2, disabling UAC appears to fix this problem but it’s probably not the best solution due to security concerns so I will update this post if I ever figure out if there is a way to get around this without disabling UAC.

Quick note about updating Cisco UCS B Series Infrastructure Firmware via CLI

This post won’t be like the step-by-step or how-to posts I usually write but rather something I can reference to if I ever need to update a component’s firmware within a Cisco UCS B Series Infrastructure.  The guide to use to find all the CLI commands required for updating and activating firmware for the components is:

Cisco UCS Manager CLI Configuration Guide, Release <version #>

The screenshot below is taken from the guide: Cisco UCS Manager CLI Configuration Guide, Release 1.4(1)

As an example, the screenshot below shows steps for updating and activating the firmware for an adapter:

The following Putty session shows the following commands and their output:

• scope adapter 1/4/1
• show firmware
• update firmware 1.4(1j)
• activate firmware 1.4(1j) ignorecompcheck set-startup-only
• commit-buffer

It’s obvious from the commands above that using the CLI to upgrade firmware may not be the most efficient way of doing so since you’re going to be executing commands to update one component at a time.  In the example above, the infrastructure I used had 6 chassis with 4 blades each so you can imagine just how long it would have took.  Due to the lack of time I have, I didn’t get a chance to try digging a bit deeper on whether it’s possible to execute a command to update and activate more than one component of the same type at the same time.  If I ever do get to spend more time on this and find that there is a way, I’ll write an update.

Updating Cisco Nexus 5000 NX-OS firmware from 4.1(3)N2(1) to 4.2(1)N2(1a)

I’m no networking expert but I’m always interested in learning new skills and I had the opportunity to update a Cisco Nexus 5000 switch during my visit to Charlotte, NC so while this is nothing special to all of the networking professionals out there, I took the time to document the procedure and thought it would be handy to write a blog post for me or other systems professionals to reference in the future.

Let me begin by listing the version that I had to upgrade from and the version I had to upgrade to:

Current Nexus 5000 NX-OS firmware version: 4.1(3)N2(1)

Nexus 5000 NX-OS firmware version to be updated to: 4.2(1)N2(1a)

The guide I used was for this upgrade was:  Cisco_Nexus_5000_Series_NX-OS_Software_Upgrade_and_Downgrade_Guide__Release_421.pdf

The first step as per the document above is to check to amount of space available on the Nexus 5000’s bootflash by executing the following command:

dir bootflash

Review the output from the command and ensure that there is enough space to upload the new firmware.  Once you’ve confirmed that you have enough space, download the firmware version you would like to upgrade the Nexus 5000 to:

System Image: n5000-uk9.4.2.1.N2.1a.bin

Kickstart Image: n5000-uk9-kickstart.4.2.1.N2.1a.bin

Have a TFTP server with the firmware ready to be downloaded by your Nexus 5000 switch.  For this example, I used 3CDaemon:

Through the console of the Nexus 5000 switch, execute the following:

copy tftp://<IPofTFTPserver>/<SystemImage.bin> bootflash:<SystemImage.bin> vrf management

Note: Notice the vrf management command included at the end of the line.  The reason this is required is because I’m using the management port on the Nexus 5000 switch to grab the image off of the TFTP server.  Without this, you may get a “No route to host” error because the Nexus 5000 switch will try to go out a different interface/vrf.

Once you’ve copied the System Image to the Nexus 5000’s bootflash, continue and copy the the Kickstart Image as well:

copy tftp://<IPofTFTPserver>/<KickstartImage.bin> bootflash:<KickstartImage.bin> vrf management

Now that the images have been successfully copied, continue by executing the show install all impact command:

show install all impact kickstart bootflash:<KickstartImage.bin> system bootflash:<SystemImage.bin>

After the show install all impact command successfully executes, proceed with executing the install all command:

install all kickstart bootflash:<KickstartImage.bin> system bootflash:<SystemImage.bin>

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

Make sure you don’t inadvertently execute:

install all kickstart bootflash:<KickstartImage.bin> system bootflash:<KickstartImage.bin>

… or you’ll get a FAIL. Return code 0x4045001E (mismatch between actual image type and boot variable). error:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

Once the update completes, you will be asked to reload the switch if you are upgrading to a major revision (i.e. 4.1 to 4.2):

Once the switch successfully reloads, execute a show version to confirm that the intended NX-OS has been loaded:

Simple for the seasoned network engineer, easy enough to follow by a server professional.

Problem joining Cisco UCS 6120 / 6140 Fabric Interconnect to cluster with error message: “Illegal seek”

I ran into an interesting problem the other day while configuring two 6120XP fabric interconnects for a new cluster where joining the second fabric interconnect to the cluster would continuously fail.  While the error message I encountered may not specifically apply to the problem I had, if you are encountering the same error message, please read on and see if it the solution applies to your situation. 

Problem

You have 2 Cisco UCS 6120XP or 6140XP fabric interconnects that you’re configuring to be primary and subordinate nodes for a cluster.  The first fabric interconnect was configured to be a cluster and as you complete the configuration for the subordinate to join the cluster, you receive the following error:

Connecting to peer Fabric interconnect… done

Retrieving config from peer Fabric interconnect… Client program has issued a close()

Server-read() error: Success

Cluster config receive error: Illegal seek

unable to retrieve!

Hit enter to try again or type ‘restart’ to start setup from beginning…

?

Solution

The root cause of this problem was actually quite simple, the firmware for the fabric interconnect and the UCS Manager was of different versions.  The following screenshot shows that the fabric interconnect’s firmware version was 1.4 while the firmware version for UCS Manager was 1.3. 

If you have the same version mismatch and you’re having problems joining the second subordinate node to the cluster, simply downgrade or upgrade the firmware so there are no mismatches.

Cisco UCS B Series Infrastructure Backups

I’m beginning to notice that I get asked about UCS backups more than once a month and the questions range from what are the differences all the way to how do I go about in restoring them.  While all of the answers can be found in the UCS GUI or CLI Config Guide, I thought it may be worth while to write a post summarizing the way I usually describe about the backups so I can point colleagues and clients to if I get asked again in the future.  Note that details to what I write in this log post can be found in Cisco’s documentation.

Types of Backups

As of today, there are 4 types of backups to choose from and the following is a straight copy and paste from the manual (CLI_Config_Guide_1_3_1.pdf):

Full state - A binary file that includes a snapshot of the entire system. You can use the file generated
from this backup to restore the system during disaster recovery. This file can restore or rebuild the configuration on the original fabric interconnect, or recreate the configuration on a different fabric interconnect. You cannot use this file for an import.

All configuration - An XML file that includes all system and logical configuration settings. You can
use the file generated from this backup to import these configuration settings to the original fabric
interconnect or to a different fabric interconnect. You cannot use this file for a system restore.

System configuration - An XML file that includes all system configuration settings such as usernames,
roles, and locales. You can use the file generated from this backup to import these configuration settings
to the original fabric interconnect or to a different fabric interconnect. You cannot use this file for a
system restore.

Logical configuration - An XML file that includes all logical configuration settings such as service
profiles, VLANs, VSANs, pools, and policies. You can use the file generated from this backup to import
these configuration settings to the original fabric interconnect or to a different fabric interconnect. You
cannot use this file for a system restore.

For the specific page of these descriptions, see the following screenshots:

The descriptions are pretty self explanatory but to add a bit more value to this post, I will list a few examples of when I would choose which type of backup:

Full state – I use this type of backup for disaster recovery purposes.  If I were to ever lose a fabric interconnect due to hardware failure, this is the backup that I would use to perform a full recovery of the fabric interconnect.

All configuration – Though a Full State backup may make it seem like an All configuration backup is not necessary, I almost always suggest to have one of these backups because of the flexibility you have with how and what you can restore to your UCS infrastructure with this file.  It’s important to understand that the Full State backup is actually a binary file while the All configuration backup is actually an XML file.  The former does not allow you to edit the configuration in anyway but the latter, being more or less a text file, allows you to make modifications to the file prior to restoring it.  With this flexibility, you can selectively restore only certain components of the backup file.  Other than using this backup as a way to recover a fabric interconnect replacement, you can also use this for large scale deployments such as the one I’m currently involved in where there are 3 datacenters across the US and Canada.

System configuration – Nice to have as well but with the All configuration backup, you can edit the file to restore only the System configuration to your UCS infrastructure.

Logical configuration – Same as System configuration backups.

Additional Backup Options

Parameter	Option	Explanation
Admin State	Enable Disable	This option allows you to decide whether the backup should kick off immediately.  Choosing the Enable option will immediately start the backup upon closing the backup window while choosing the Disable option queues up the job in the tasks window so the backup doesn’t start until you change the Admin State to Enable.
Preserve Identities	Enable Disable	This allows you to specify whether pool-derived identity values, such as vHBA WWPN, vNIC MAC, WWNN, and UUID, will be saved with the backup allow you to restore all of the components with the exactly same identity values.  One of the reasons why you would want this is if you have configured your servers to boot from SAN and have zoned the WWNN accordingly.
Location of Backup File	Remote File System Local File System	The Remote File System option allows you to place the backup on a remote server while the Local File System allows you to place the backup directly on the workstation you are using to connect with UCS Manager.
Protocol	FTP TFTP SCP SFTP	The options are self explanatory so I’m just going to list what the letters abbreviate for: FTP - File Transfer Protocol TFTP - Trivial File Transfer Protocol SCP - Secure Copy Protocol SFTP - Secure File Transfer Protocol
Hostname	Text field	The IP or name of the FTP, TFTP, SCP, or SFTP server.
Remote File	Text field	The name of the backup file.  You can also include a path in this field.
User	Text field	Username if the protocol being used requires authentication.
Password	Text field	Password if the protocol being used requires authentication.

Restoring Backups

The procedure for restoring backups pretty simple.  What you will need is to a FTP, TFTP, SCP, or SFTP server that is accessible through the fabric interconnect’s management interface to download the backup and restore it.

The following is what a Full State backup restore looks like:

Note: 3CDaemon is a free TFTP and FTP server I use for the fabric interconnect to retrieve the backup file.

The following is what a Logical configuration backup restore looks like:

Notice the example shows an import job that is created with the Admin State as Disabled:

The restore immediately begins when the Enabled radio button is selected for the Admin State:

Note: An All configuration and System configuration would look the same.

Additional Restore Options

Parameter	Option	Explanation
Admin State	Enable Disable	This option allows you to decide whether the backup should kick off immediately.  Choosing the Enable option will immediately start the backup upon closing the backup window while choosing the Disable option queues up the job in the tasks window so the backup doesn’t start until you change the Admin State to Enable.
Action	Merge Replace	Merge will have the information in the imported configuration file compared with the existing configuration information.  If there are conflicts, the import operation overwrites the information on the Cisco UCS instance with the information in the import configuration file. Replace will have the current configuration information replaced with the information in the imported configuration file one object at a time.
Location of Backup File	Remote File System Local File System	The Remote File System option allows you retrieve the backup on a remote server while the Local File System allows you to retrieve the backup directly on the workstation you are using to connect with UCS Manager.
Protocol	FTP TFTP SCP SFTP	The options are self explanatory so I’m just going to list what the letters abbreviate for: FTP - File Transfer Protocol TFTP - Trivial File Transfer Protocol SCP - Secure Copy Protocol SFTP - Secure File Transfer Protocol
Hostname	Text field	The IP or name of the FTP, TFTP, SCP, or SFTP server.
Remote File	Text field	The name of the backup file.  You can also include a path in this field.
User	Text field	Username if the protocol being used requires authentication.
Password	Text field	Password if the protocol being used requires authentication.

How to force a Cisco UCS 6100 series fabric interconnect to become the primary node in a cluster

I ran into an extremely annoying problem today while setting up a new UCS B series infrastructure cluster for a client where a newly configured 6120 would get stuck in an election progress and seemingly never promotes itself to become the primary fabric interconnect even though the other node is down.  The following is what the command show cluster state outputs:

A: UP, ELECTION IN PROGRESS (Management services: UP)

B: UNRESPONSIVE, INAPPLICABLE, (Management services: UNRESPONSIVE)

The reason why this problem was annoying was because as long as this fabric is stuck in this state, I was not able to log into UCS Manager to work with the GUI.  I know enough to get around within the CLI but tasks such as reviewing the logs to troubleshoot was much easier to do with the GUI.  To get around this, you can use the following command to force the fabric interconnect that is stuck in limbo to become primary node:

connect local-mgmt
cluster force primary

Once you’ve successfully forced the fabric interconnect to become the primary node, you will be able to connect to UCS Manager via the cluster IP.