That… Could Be A Problem…

9Nov/150

PowerCLI – Quick Stats Not Up To Date Error

Recently rebooted one of my vCenters and came across an error on my ESXi hosts stating "Quick stats on *vmhost* is not up-to-date". A couple seconds worth of googling brought me to VMware KB2061008 which helped to resolve the issue.
Quick Stats Error Message

However, the KB only went through the GUI process of adding in the requisite parameters but there's no fun in clicking through the GUI so I came up with a short script that's applicable to vCenter 6.0 which can also accomplish performing the parameter creation/updates for the KB's workaround.

Once you run the script, you'll still need to restart the vCenter service on your VCSA or Windows server. If you happen to be in the web client:
Go to "Administration" then to the "Deployment" area to select "System Configuration"
Select "Services", then select "VMware vCenter Server"
Select "Actions" followed by "Restart"

Once the service is back up and running the error will no longer be present.
vCenter Service Restart

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

15Sep/151

PowerCLI 6.0 R2 – Announcing vROps Integration!

For those that have been requesting some vCOps and/or vROps integration into PowerCLI, as I have been, we finally have our solution! PowerCLI 6.0 R2 brings that to the table in the form of a new module: VMware.VimAutomation.vROps

The following functions are featured in the module:
Connect-OMServer
Disconnect-OMServer
Get-OMAlert
Get-OMAlertDefinition
Get-OMAlertSubType
Get-OMAlertType
Get-OMRecommendation
Get-OMResource
Get-OMStat
Get-OMStatKey
Set-OMAlert

Here's a couple tips to get started using it:
To begin pulling stats you will need to authenticate to the vROps instance via Connect-OMServer:
Connect-OMServer

After getting connected, and being connected to an associated vCenter, check out the resources via Get-OMResource by piping it a VMHost, VM, or so forth:
get-omresource

As you can see, I pulled the resources for a VMHost. Some of the basic, higher level, information is in there such as Health status and value, whether or not vROps is receiving any data about it, and how far back data has been collecting for the resource.

The following is pulling the same information for the vROps VM in my lab environment:
get-omresource

If you want to go straight to the stats, I don't blame you one bit. However just running the Get-OMStat command is going to fill your PoSh window with every single stat available for that resource at all the time points available. Overwhelming would be putting it lightly, so you'll want to also familiarize yourself with Get-OMStatKey. This function allows you to see what all stats you can actually pull:
get-omstatkey

Couple things I feel the need to point out:

  • Include both the AdapterKind and ResourceKind objects when calling this function, it returns every possible stat key possible without it... All 17,646 of them.
  • Even when including the AdapterKind and ResourceKind, I would highly recommend filtering out what what you're looking for. The HostSystem ResourceKind has 2225 stat keys alone.

Finally, lets select a stat key and pull some detailed stats by way of the Get-OMStat function. In this scenario, I'm pulling CPU Ready Summation values:
Get-OMStat

Some of the other functions included surround alerting.

The Get-OMAlert function pulls all of the vROps alerts:
get-omalert

Since there happens to be some alerts, let's check out two abilities of the Set-OMAlert function. The first option being cancelling of an alert:
set-omalert -Cancel

If you notice in the example, the alert still exists but it's status is changed to "Inactive".

Next up, let's check out the suspend function of the Set-OMAlert function:
Set-OMAlert -SuspendMinutes

Overall, the new module definitely gets my stamp of approval! Thanks to the Automation and PowerCLI team for listening to the users and getting this integrated!

Additional information is available at the following link: https://blogs.vmware.com/PowerCLI/2015/09/powercli-6-0-release-2-is-now-generally-available.html

29Dec/140

PowerCLI – View – Pool Health Check Report

I've been given the chance to work with View a little more here recently and focus in on some of the gaps that are missing, specifically around reporting and alerting. vC Ops and the View adapter are in use, however the alerts leave much to be desired. I'm glad to be able to say that the gaps are filled in with the new version, and new title, of vR Ops and the View adapter but this environment is not yet to that point.

Examples of the vR Ops alerts which are included by default:

vR Ops Default View Alerts

What gaps am I referring to? I'm aiming specifically at the View Pool state, provisioning state and the amount of available desktops compared to the headroom configuration.

To do this, I enlisted the help of the View PowerCLI cmdlets and the View Connection server ADAM database to create the script below that creates an output similar to this:
(Note: the asterics around the value that caused the report to be sent)

View Pool Report Output

Before getting to the script, lets cover some of the requirements of the script:

  • This script is to be run from a Connection server.
  • This script is currently formatted to have the report be consumed by way of email.
  • The email variables need to be filled in to match the environment it's being run in.
  • The email is sent only if the following criteria are met:
    • A Pool's state is false.
    • A Pool's provisioning state is false.
    • A Pool's available desktops are less than the headroom setting by the amount set in the desktopthreshold variable.
  • The default desktop threshold is meant to be a percentage and is set to a default of 90%, or 0.9. This is easily modified on line 22.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

28Oct/130

PowerCLI – One-Liner – Check All VMHosts’ Time

It's everyone's favorite time of year, daylight savings time. If your NTP solution is solid, there's no worries and you've never had to think twice about it. If you're like everyone else, you at least want to run a couple scripts to verify and validate everything is looking good.

A little bit of background, the environment I was running this report on had 100+ hosts.

An easy one-liner:
Get-VMHost | sort Name | select Name,@{Name="Current VMHost Time";Expression={(Get-View $_.ExtensionData.ConfigManager.DateTimeSystem).QueryDateTime()}}

Depending on the size of your environment, this could take 20 seconds or an hour. In my case, it took 14 minutes. However, due to the time it took to run, quite a few hosts were reporting different times. A discrepancy of 14 minutes either way meant that the hosts were all just about in sync. If you're only worried about time zone issues, a 14 minute discrepancy is acceptable.

Example based upon the environment I was working in:
PowerCLI C:\ > Get-Date -Format g; Get-VMHost | sort Name | select Name,@{Name="Current VMHost Time";Expression={(Get-View $_.ExtensionData.ConfigManager.DateTimeSystem).QueryDateTime()}}; Get-Date -Format g

10/9/2013 10:19 AM
Name Current VMHost Time
---- -------------------

10/9/2013 10:33 AM

At this point you may be thinking, there has to be a faster way to do this. You're right, there is. To do so, you have to leave the comfort of the PowerCLI cmdlets behind and make a swap over to the .NET view objects cmdlets. In this case, Get-View will be used.

Good news, it is still another one-liner:
Get-View -ViewType HostSystem -Property Name,ConfigManager.DateTimeSystem | sort Name | select Name,@{Name="Current VMHost Time";Expression={(Get-View $_.ConfigManager.DateTimeSystem).QueryDateTime()}}

As you can see, there's a bit of a difference between the one-liners and there will be a bit of a learning curve as well. The time savings will be worth it though. To prove it, this version only took 2 minutes to run. That's a 12 minute savings!

Example based upon the environment I was working in:
PowerCLI C:\ > Get-Date -Format g; Get-View -ViewType HostSystem -Property Name,ConfigManager.DateTimeSystem | sort Name | select Name,@{Name="Current VMHost Time";Expression={(Get-View $_.ConfigManager.DateTimeSystem).QueryDateTime()}}; Get-Date -Format g

10/9/2013 10:35 AM

Name Current VMHost Time
---- -------------------

10/9/2013 10:37 AM

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

21Feb/130

Fusion-IO Caching Tests…

After some issues with the setup and configuration of the Fusion-IO ioCache cards we picked up, I finally got to dig in and do some basic testing with IOMeter.

To setup the test, I configured a new 20GB VMDK on it's own paravirtualized SCSI Controller. The drive was formatted NTFS in a full/non-quick method as the F: drive. The IOMeter test was run on a single worker against the entire F: drive. The All-in-one test was selected and run for 20 minutes.

First up, I tested the drive all by itself with no caching enabled:

IOps: 1348.69 Read IOps: 670.1738 Write IOps: 678.5159

Next, I tested Volume based caching. I started off by making the following modifications to the Fusion-IO tab within vCenter as follows to add only the F: drive to the Volume Caching Filter:
Volume Based Caching

Then I reset the F: drive by formatting it again as NTFS in a full/non-quick method. Once the format was complete, I reran the IOMeter test and received these results:

IOps: 1486.163 Read IOps: 737.5608 Write IOps: 748.6018

Lastly, I tested the Drive based caching. I went back to the Fusion-IO tab within vCenter and removed the Volume Caching Filter on the F: drive and then set the Drive Caching Filter to Drive1 (Drive0 was the drive the OS was installed on, Drive2 was the drive which is attached by FusionIO automatically):
Drive Based Caching

Then I reset the F: drive by formatting it again as NTFS in a full/non-quick method. Once the format was complete, I reran the IOMeter test and received these results:

IOps: 1509.644 Read IOps: 748.7889 Write IOps: 760.8555

I also managed to grab a shot of the Performance graphs for the disk during the tests via vSphere client: (pardon the lapse between 2PM and 3PM on the graph)
Performance Graph on Disk

So to review and put the results all on the same table:

No Caching Enabled IOps: 1348.69 Read IOps: 670.1738 Write IOps: 678.5159
Volume Caching Enabled IOps: 1486.163 Read IOps: 737.5608 Write IOps: 748.6018
Drive Caching Enabled IOps: 1509.644 Read IOps: 748.7889 Write IOps: 760.8555

Remember, these are just initial results with nothing but having the card installed, drivers installed, firmware upgraded, ioTurbine installed, and the guest package installed. While some of the results weren't exactly what I was expecting, I'm pretty excited to dig in deeper to see what kind of performance we can gain out of these cards.

Small update...

While this particular blog post is about caching, since that's how these cards will be used in this environment, I couldn't help but go back, mount the Fusion-IO card as VMFS storage, SvMotion the F: drive over to the Fusion-IO VMFS datastore and run the test again. So once again, the F: drive was formatted as NTFS in a full/non-quick method. Once the format was complete, I reran the IOMeter test and received these results:

IOps: 5443.904 Read IOps: 2700.201 Write IOps: 2743.703
16Jul/120

RDM Conversion Pain Points…

The latest infrastructure I've inherited is loaded full with RDMs. My first order of business was to get rid of them, especially since we aren't using them for any reason other than a possible performance improvement.

The steps we've been taking is to get rid of them:

  • Convert from a physical RDM to a virtual RDM
    • Shut down system
    • Take note of SCSI information
    • SCSI Settings

    • Remove and Delete from Disk
    • Apply
    • Re-add the RDM as a virutal RDM instead
  • Perform a Storage Migration from one datastore to any other datastore, specifically move the virtual RDM
  • Once complete, check the settings on the VM and verify that the hard disk is listed as "virtual disk"

A couple of the pain points we've run into:

Removing and deleting of the physical RDMs did not work as planned. Roughly 10% of the VMs ran into a problem where the pointer files were not properly removed and therefore the RDMs could not be remapped as virtual RDMs. We could still add a hard disk and point it at the pointer files and it properly added back to the VM. We tried rescanning HBAs, we tried different SCSI controllers, etc.

Finally, we figured out that by going into the datastore and manually deleting the pointer files and then vMotioning the VMs to another ESXi host within the cluster, we could then add a new RDM to those previously used RDMs.

In the case of Storage vMotioning the virtual RDMs to a new datastore, if we SvMotioned the RDM to a Storage DRS datastore cluster it only moved the pointer files. If we went through and checked the "Disable Storage DRS" option and selected an individual VMFS datastore, it did the conversion over to VMDK. Adds an extra step, but still gets the job done.
Disable Storage DRS

Only a 100+ more RDMs to go... Good times.

11Apr/121

vDR – causing problems…

For those new to vSphere 5's GUI, there's a new column that's been added to the Virtual Machine view by the name of "Needs Consolidation".
Needs Consolidation

This option was put in due to the occasional problem when Snapshots did not delete properly and would leave the delta files remaining in the VM's folder while the Snapshot Manager would show no snapshots existing.

With this option added to the columns, you should also take note of the option within the Snapshot options for each VM which will now allow a user to select the "Consolidate" function
Consolidate Snapshot

As noticed with the first screenshot, we had a couple systems which were requiring some consolidation to them. So another admin went through and hit the consolidated button and got hit with a "Unable to access file since it is locked" error. Normally, you can go through and figure out which file is being locked with some command line work or by rebooting the host (via: VMware KB: 10051) however our VM is running so there's something else going on.
Locked File

I still decided to dive into the CLI and check it out. I was stunned...
Deltas!

18 deltas... 18! Regardless of the vmsn file in there, there was no record of there being any snapshots.

In this case, that system probably hasn't even been rebooted 18 times much less been snapshot that many times... Except, vDR (VMware Data Recovery) is setup on it to do daily snaps. So I checked the vDR appliance settings and I found 8 disks too many attached.
Locked File

After removing all of those extra hard disks, the consolidations would succeed. Note, it took a while, but they did succeed.
Locked File

Just another reminder of while vDR is a great tool to have on hand, it should definitely not be the one and only method of backup

3Apr/121

SRM: vSphere Replicated VMs stuck in a “Sync” status

Here recently I've noticed that there is an occasional time where the VMs I have replicating using the vSphere Replication system are stuck in a "Sync" status for an overly long time.

After pulling the logs, I was able to figure out what was happening... Timeouts, lots of them. The log file vmware-dr.log pulled from the remote site was full of lines like the following: (local is the SRM server, peer is the vCenter server)

2012-04-02T07:35:04.077-04:00 [02784 verbose 'Default'] Timed out reading between HTTP requests. : Read timeout after approximately 50000ms. Closing stream TCPStreamWin32(socket=TCP(fd=2596) local=10.xx.xx.xxx:9085, peer=10.xx.xx.xxx:55039)

2012-04-02T11:54:34.159-04:00 [02744 verbose 'Licensing'] Asset in sync.
2012-04-02T11:58:12.527-04:00 [02868 info 'LocalVC' opID=ac2d1cb] [PCM] Received NULL results from PropertyCollector::WaitForUpdatesEx due to timeout of 900 seconds
2012-04-02T11:58:12.723-04:00 [02860 info 'LocalVC' opID=596971f7] [PCM] Received NULL results from PropertyCollector::WaitForUpdatesEx due to timeout of 900 seconds

After a brief discussion with our network engineers, it was believed that there was no problem with the connection between the local and remote site. So I took a "when in doubt, reboot" approach. I restarted the SRM service on the remote SRM server. No luck. After that, I did a "Restart Guest" on the VRS system at the remote site. After about 5 minutes, the systems started to connect and replicate again.

I've noticed it a lot, and I've heard from other people whom also manage their own SRM deployments that a reboot is a pretty good first step in troubleshooting. So keep that in mind as issues arise and troubleshooting is required.

8Dec/115

VMware Update Manager: Error Code 7

After updating from vSphere 4 to vSphere 5 (both hosts and vCenter) in our production environment, I happened to run into a problem with VMware's Update Manager (VUM) and it's ability to update the hosts. When attempting to remediate the host I was being given a message stating: The host returns esxupdate error code: 7. Cannot download VIB. Check the Update Manager log files and esxupdate log files for more details.
vCenter Warning

So I do as the error code says, and go check out the logs...

vmware-vum-server.log sample of what I saw:

2011-12-08T10:51:17.916-05:00 [02704 warning 'Libs'] SSLVerifyIsEnabled: failed to read registry value. Falling back to default behavior: verification off. LastError = -2146885628

2011-12-08T10:55:54.054-05:00 [02704 error 'Default'] SSLStreamImpl::BIORead (0c594a48) failed: The specified network name is no longer available.

2011-12-08T10:55:54.054-05:00 [02704 error 'Default'] SSLStreamImpl::DoServerHandshake (0c594a48) SSL_accept failed with BIO Error

2011-12-08T10:55:54.054-05:00 [02704 error 'Ufa.HTTPService'] accept failure class Vmacore::Ssl::SSLException(SSL Exception: BIO Error) on stream (null)

2011-12-08T10:55:54.054-05:00 [02704 error 'Ufa.HTTPService'] stream is NULL - no read scheduled

2011-12-08T10:56:49.625-05:00 [03392 error 'PropertyJournal'] [ValidateChange]INVALID operations on path supportedUpdateProduct["embeddedEsx 4.0.0"]: lastOp=ADD, thisOp=ADD - ADD can only follow REMOVE

2011-12-08T10:56:49.625-05:00 [03392 error 'PropertyJournal'] [ValidateChange]INVALID operations on path supportedUpdateProduct["embeddedEsx 4.1.0"]: lastOp=ADD, thisOp=ADD - ADD can only follow REMOVE

2011-12-08T10:56:49.625-05:00 [03392 error 'PropertyJournal'] [ValidateChange]INVALID operations on path supportedUpdateProduct["esx 4.0.0"]: lastOp=ADD, thisOp=ADD - ADD can only follow REMOVE

2011-12-08T10:56:49.625-05:00 [03392 error 'PropertyJournal'] [ValidateChange]INVALID operations on path supportedUpdateProduct["esx 4.1.0"]: lastOp=ADD, thisOp=ADD - ADD can only follow REMOVE

2011-12-08T10:56:50.347-05:00 [03392 error 'PropertyJournal'] [ValidateChange]INVALID operations on path supportedUpdateProduct["embeddedEsx 4.0.0"]: lastOp=ADD, thisOp=ADD - ADD can only follow REMOVE

2011-12-08T10:56:50.347-05:00 [03392 error 'PropertyJournal'] [ValidateChange]INVALID operations on path supportedUpdateProduct["embeddedEsx 4.1.0"]: lastOp=ADD, thisOp=ADD - ADD can only follow REMOVE

2011-12-08T10:56:50.347-05:00 [03392 error 'PropertyJournal'] [ValidateChange]INVALID operations on path supportedUpdateProduct["esx 4.0.0"]: lastOp=ADD, thisOp=ADD - ADD can only follow REMOVE

2011-12-08T10:56:50.347-05:00 [03392 error 'PropertyJournal'] [ValidateChange]INVALID operations on path supportedUpdateProduct["esx 4.1.0"]: lastOp=ADD, thisOp=ADD - ADD can only follow REMOVE

2011-12-08T10:57:34.344-05:00 [01796 warning 'Libs'] SSLVerifyIsEnabled: failed to read registry value. Falling back to default behavior: verification off. LastError = -2146885628

esxupdate.log sample from the host:

2011-12-08T15:57:29Z esxupdate: vmware.runcommand: INFO: runcommand called with: args = '['/sbin/esxcfg-advcfg', '-q', '-g', '/UserVars/EsximageNetTimeout']', outfile = 'None', returnoutput = 'True', timeout = '0.0'.

2011-12-08T15:57:29Z esxupdate: vmware.runcommand: INFO: runcommand called with: args = '['/sbin/esxcfg-advcfg', '-q', '-g', '/UserVars/EsximageNetRetries']', outfile = 'None', returnoutput = 'True', timeout = '0.0'.

2011-12-08T15:57:29Z esxupdate: vmware.runcommand: INFO: runcommand called with: args = '['/sbin/esxcfg-advcfg', '-q', '-g', '/UserVars/EsximageNetRateLimit']', outfile = 'None', returnoutput = 'True', timeout = '0.0'.

2011-12-08T15:57:29Z esxupdate: esxupdate: INFO: ---
Command: scan
Args: ['scan']
Options: {'nosigcheck': None, 'retry': 5, 'loglevel': None, 'cleancache': None, 'viburls': None, 'meta': ['http://*VIRTUALCENTER*:9084/vum/repository/hostupdate/DELL/metadata_1323354549.zip', 'http://*VIRTUALCENTER*:9084/vum/repository/hostupdate/csco/csco-VEM-5.0.0-metadata.zip', 'http://*VIRTUALCENTER*:9084/vum/repository/hostupdate/vmw/vmw-ESXi-5.0.0-metadata.zip'], 'proxyurl': None, 'timeout': 30.0, 'cachesize': None, 'hamode': True, 'maintenancemode': None}

2011-12-08T15:57:29Z esxupdate: BootBankInstaller.pyc: INFO: Unrecognized value "title=Loading VMware ESXi" in boot.cfg

2011-12-08T15:57:30Z esxupdate: vmware.runcommand: INFO: runcommand called with: args = '['/sbin/bootOption', '-rp']', outfile = 'None', returnoutput = 'True', timeout = '0.0'.

2011-12-08T15:57:30Z esxupdate: downloader: DEBUG: Downloading http://*VIRTUALCENTER*:9084/vum/repository/hostupdate/DELL/metadata_1323354549.zip to /tmp/tmp0HbTco...

2011-12-08T15:57:30Z esxupdate: Metadata.pyc: INFO: Unrecognized file vendor-index.xml in Metadata file

2011-12-08T15:57:30Z esxupdate: downloader: DEBUG: Downloading http://*VIRTUALCENTER*:9084/vum/repository/hostupdate/csco/csco-VEM-5.0.0-metadata.zip to /tmp/tmpBQa1zj...
2011-12-08T15:57:30Z esxupdate: Metadata.pyc: INFO: Unrecognized file vendor-index.xml in Metadata file

2011-12-08T15:57:30Z esxupdate: downloader: DEBUG: Downloading http://*VIRTUALCENTER*:9084/vum/repository/hostupdate/vmw/vmw-ESXi-5.0.0-metadata.zip to /tmp/tmpyQ8Q7O...

2011-12-08T15:57:30Z esxupdate: Metadata.pyc: INFO: Unrecognized file vendor-index.xml in Metadata file

2011-12-08T15:57:30Z esxupdate: BootBankInstaller.pyc: INFO: Unrecognized value "title=Loading VMware ESXi" in boot.cfg

2011-12-08T15:57:30Z esxupdate: HostImage: DEBUG: Live image has been updated but /altbootbank image has not. This means a reboot is not safe.

2011-12-08T15:57:30Z esxupdate: HostImage: DEBUG: Live image has been updated but /altbootbank image has not. This means a reboot is not safe.

2011-12-08T15:57:30Z esxupdate: vmware.runcommand: INFO: runcommand called with: args = '['/usr/sbin/vsish', '-e', '-p', 'cat', '/hardware/bios/dmiInfo']', outfile = 'None', returnoutput = 'True', timeout = '0.0'.

2011-12-08T15:57:30Z esxupdate: esxupdate: INFO: All done!

2011-12-08T15:57:30Z esxupdate: esxupdate: DEBUG: <<<

There wasn't much in there to give me much to go on, however the "Unrecognized file vendor-index.xml in Metadata file" part was a good lead. I was using the default download sources, so that shouldn't be a problem. I turned off the Windows firewall, no luck. I put in the URL to the repository and could get to it just fine.

I don't normally stage the updates, but I went back and clicked on the "Stage" button. That ran just fine, even staged the Dell extension for our EqualLogic MEM. Tried to remediate again, no luck. This time I tried to do just the extension, it worked!

I go back and check out the staged updates, 2 are listed as missing! We've found our problem.
vCenter Warning

I head out to the VMware Download Patches site: http://www.vmware.com/patchmgr/download.portal and download the missing patches and then import them into the VUM Patch Repository and remediate the host again. It worked!

Moral of the story: always check to make sure that the patches are not only listed as available, but that they're able to be staged.

Update...

One thing I may have MAJORLY overlooked... Check the status of your "vmw" and "csco" folders. If they look like "VMW" and "CSCO", they will not work and have to be lower case!

This is not the case with the example I have included above, but I have run into it on another install. Such a simple thing to overlook on accident.

29Nov/110

Generating RSA Key & CSR for use with VMware Solutions…

Ever received a Security Warning while logging into either you ESX/i host and/or vCenter?
That's due to the SSL certificate being untrusted with your machine. You can always click the "Ignore" button or check the "Install this certificate..." box and then "Ignore" and move on, however you can improve the security by replacing the certificates with certificates signed by a commercial certificate authority (CA).
Certificate Warning

To generate an RSA Key and certificate signing request (CSR), we'll start by downloading the OpenSSL-Light application on the system you'll be installing or have already installed a VMware application. The application is available from the following site: http://www.slproweb.com/products/Win32OpenSSL.html

Download the "Win32 OpenSSL v1.0.0e Light" application along with the "Visual C++ 2008 Redistributables". Once downloaded, run the Visual C++ file (in this case, "vcredist_x86.exe"). Click "Next", check the "I have read and accept the license terms." box and click "Install", wait a couple seconds and click "Finish".
Downloaded Files
Setup
Accept Terms
Configuration
Finish

Now it's time to install OpenSSL by running the "Win32OpenSSL_Light-1_0_0e.exe" and installing it to your desired location. Click "Next", accept the agreement and click "Next", choose an install location (default is the root of C:, but I don't like cluttering up the root of C:) and click "Next", click "Next", change the option so that the OpenSSL DLLs are copied to the OpenSSL binaries (/bin) directory and click "Next", then click "Install", once the installer is finished click "Finish".
Setup
Accept Terms
Destination
Start Menu Folder
OpenSSL DLLs
Confirmation

From this point, open up a command prompt and navigate to the bin folder within the location of the installation of OpenSSL. To generate the key, run the following command: openssl genrsa 1024 > rui.key Once that is complete, generate the CSR by running this command: openssl req -new -key rui.key > rui.csr After running the command, you'll be asked to populate some information regarding your country name, state, city, organization name and unit, common name and email address.
Command Line Work

If you happen to receive the error: "WARNING: can’t open config file: /usr/local/ssl/openssl.cnf" this is due to OpenSSL being unable to find the openssl.cnf file. To correct this error, run the following command: set OPENSSL_CONF=c:[PATH TO OPENSSL DIRECTORY]binopenssl.cfg

After creating the CSR, submit it to either the admin of your Microsoft Certificate Services CA or to whomever handles the certificates from a commercial CA.