Dell OpenManage Server Administrator installation on ESXi 5

All right folks, I’ve decided to save you hours of time once again and provide a comprehensive guide to installing the Dell OpenManage Server Administrator (OMSA) client on ESXi 5. I pieced this together from a variety of user guides and forum posts and have tested it on an ESXi 5 box I use for labs. Instructions are as follows:

  1. Download the latest version of “Dell OpenManage Offline Bundle and VIB for ESXi”. The easiest way to find it is to go to the Dell Support homepage. Select the model of the Dell server you are working with, filter the operating system to your version of ESXi, expand the System Management section, and do a search for “offline bundle”. Once you download the file, rename it to something simple like omsa.zip. This will make your life easier during the later steps where you will be typing out the file path and filename.
     
  2. Put your ESXi host into maintenance mode and log into vCenter or vSphere and upload the file to the datastore your ESXi host uses.
     
  3. Enable SSH on your ESXi box and establish an SSH session with your favorite terminal emulator. I’m partial to Putty. Once you’ve established your SSH session, move the file from your datastore to /var/log/vmware. Your datastore will be stored under /vmfs/volumes/<datastore_id>. You can obtain the datastore_id variable from the within vCenter/vSphere by clicking the configuration tab, selecting the storage from the hardware menu, and clicking on your datastore in the Datastore pane.
     
  4. Now you’ll want to install the vib to the ESXi host. You can do this by typing the following command.
     
    esxcli software vib install -d /var/log/vmware/<OMSA_filename>
     
    You’ll then be prompted to enter the root username and password. If the installation is successful you’ll receive something similar to the following:

    Installation Result
    Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
    Reboot Required: true
    VIBs Installed: Dell_bootbank_OpenManage_<OMSA_version>
    VIBs Removed:
    VIBs Skipped:

  5. At this point, most guides will tell you to reboot the server, however, we are not done yet. ESXi 5 has a built-in firewall that allows only pre-configured built in services to be allowed through. OMSA runs off port 1311, so we’re going to need to create a new persistent firewall rule.
     
    You can download the OpenManage rule I’ve created from here. Optionally, you can create your own by following the directions from VMWare.
     
    Once the rule is complete, upload it to the ESXi host’s datastore.
     
  6. Now we need to edit /etc/rc.local to make sure that the firewall rule is copied to /etc/vmware/firewall each time the computer is rebooted. We can do this by establishing a SSH connection with our ESXi host, opening vi, and adding the following few lines as referenced by this VMWare article.
     
    cp <location of xml> /etc/vmware/firewall
    esxcli network firewall refresh
     
  7. Finally, reboot your ESXi box for all of the changes to take effect. To access the OMSA installation on the ESXi server, you’ll need to open OMSA Web Services on another box and log into the ESXi host.
     
    Remember that when you log into OMSA Web Services on another computer, you may be automatically logged into OMSA on that computer. Hit Log Out, then the Log In button, and down towards the bottom of the log in page, hit the Manage Remote Node link.

That’s it folks. Enjoy!

Dell OpenManage Essentials Installation Tips

Over the past few days I have been working on getting Dell OpenManage Essentials up and running on our new network. The installation was pretty straightforward and well documented by Dell, but I did run into a few issues that I had to dig through forum posts to find the answers to.

Before I begin, you’ll want to reference Dell’s OME homepage for the software. There are some great videos and whitepapers that walk you through the installation and usage basics.

Now on to the good stuff:

  1. I wasn’t able to get the configuration of SNMP working through Group Policy per the Dell tutorials. When I followed Dell’s instructions, the Traps tab of the SNMP Service tab had the community set to public and I could not change it. Since I was using a custom community name, this wouldn’t work for me. If there is a way to set that via the GPO, I’d love to hear it, because I ended up configuring it per server. My guess is it would need to be configured with a GPO policy and some registry entries set in the GPO preferences.

    Dell’s video on configuring Window’s SNMP clients is pretty solid, but here are the settings you should configure (keep in mind I have SNMP restricted to the server running OME).

    SNMP Settings for OME

  2. OME can also handle traps for ESXi servers using WS-Man. If you reference to the Dell website I listed above, you can download the addon for ESXi.

    I ran into an issue where the ESXi box I installed the software on was not reporting to the OME server. Thanks to a Dell forum poster, my problem was solved. Apparently ESXi 5+ requires a timeout greater than the default. I set my to 10 and all was good in the world. Below is a screenshot of the settings required for WS-Man to work with the ESXi addin.

    WS-Man configuration for OME

  3. Finally, there will be some traps from ESXi that come up as undefined. Don’t waste time trying to import ESXi MIBs (like I did), because OME won’t let you overwrite the predefined MIBs. According to Dell the new MIBs will be incorporated in an update set for Q3 or Q4 2012.

The lesson I took from this little project was that OME is still very new and there are some minor bugs to work out. Overall the software is put together really well and the documentation is the best I have ever come across.

My experience with the 70-640

I decided early last year it was time to update my MCSA to the MCITP:SA (which is actually being changed back to MCSA next July). Upon reviewing the material, I saw they were now including R2 information. Since I didn’t feel like relying solely on Technet for R2 material, I figured I would wait another year and give Microsoft time to get a revamped R2 book out there.

Earlier this year we had a budget approved to upgrade our infrastructure to Server 2008. It seemed like the perfect opportunity to purchase the Server 2008 R2 books and crank through the material via labbing and through real life experience.

Over the next four months, I put my mind into exam mode. I’ve developed a pretty solid system ever since I began taking certification exams back in 2005. I first read through a chapter, go through the chapter again taking handwritten notes, convert the notes to digital form, and end with studying the digitized notes each day until the exam. I’ve found by the time I near the end of the book I’ve memorized a good portion of the first half or two-thirds of the book.

The exam required a ton of labbing. I focused on ADCS, ADRMS, and ADFS since those were the three technologies I had the least amount of experience with. DNS has always come easy for me, so I didn’t spend much time on it. After a few months, I had grasped the material and was ready to take the exam.

I heard Microsoft was changing the format of the exams to make them a bit more difficult, and the changes were noticeable. I won’t go into that because I don’t want to violate the NDA. However, there is a video out there from the head of Microsoft’s certification department that talks about the planned changes.

At the end of the day, I scored 858/1000. I was hoping for something in the 900s, but a pass is a pass. I’ve made my notes available here for anyone who is interested.

On to the 70-642!

Configuring EFS with ADCS Server 2008

Over the past few months I’ve been studying for the 70-640. I decided to put the CCNA on hold since I’m in the process of building a new Server 2008 network. From what I’ve gathered from reviews of the exam from my friends over at Tech Exams, the exam really focuses on AD CS.

In the process of studying for the exam, I’ve been labbing AD CS like crazy. Over the past few days I’ve been setting up a virtual lab similar to the advanced lab detailed in the AD CS Step-by-Step Setup Guide.

Today I decided to play with certificate autoenrollment and EFS. I couldn’t find anything on the web that gave the full details on how to set everything up, so I figured I would write up the process to save others the time it took me to round up all the info.

I’m not going to go into how to setup AD CS, as there are plenty of guides out there that will walk you through the process. With that in mind, let’s begin.

Step 1: Duplicate the EFS Recover Agent certificate template

First and foremost you’re going to want to setup a recovery agent. You’ll be able to use this account to decrypt any documents that users encrypt with EFS. This can be useful in situations like where you have to restore an encrypted document from a backup or if a user somehow manages to lose his or her private key. Due to the power of this account, you’re going to want to make sure to lock it down.

Open up Server Manager, expand the ADCS role, click on the Certificate Templates node, and right-cick on the EFS Recovery Agent template and select Duplicate Template. Choose the Windows 2008 Enterprise option (the test lab is a pure 2008 network). On the general tab check off the option to publish the certificate to Active Directory. I would recommend this option for most certificate templates. Make sure your Request Handling tab looks like the one pictured below:

EFS Recovery Agent - Request Handling tab

Microsoft now recommends you use ECC algorithm rather than the RSA (see Microsoft Changes in EFS). This will require you to change the encryption algorithm on the Cryptography tab from RSA to one of the ECDH variants. Next, tweak your security settings to make sure the accounts you plan on using have the enroll permission. Hit Apply and OK to close the window.

Step 2: Duplicate the User and Basic EFS certificate templates

You’ll want to do this is the same way you duplicated the template in step 1. The General, Request Handling, and Cryptography tabs are going to have the same settings we discussed above. Make you properly configure your security settings. I would recommend giving users autoenroll on the User certificate. Google will produce a number of guides for configuring autoenroll of certificates.

Step 3: Add the templates to the issuing CA’s certificate templates

Open up Server Manager on your issuing CA, expand the issuing CA node, right-click the Certificate Templates node and select New -> Certificate Template to Issue. Select the three templates you created and hit OK.

Step 4: Issue the EFS Recovery Agent certificates

Log on to a computer as the account(s) you want to set as recovery agents, open a new MMC and add the Certificates snap-in, and select the Current User option. Once the snap-in opens, right click over the Personal node, select All Tasks, and Request New Certificate. Select the default policy you are presented with, check off the EFS Recovery Agent template you created, and select Enroll.

At this point you should backup EFS Recovery Agent certificate and private key as detailed in this article. Store the backup in a secure location.

Step 5: Configure EFS PKI settings in the Default Domain Policy GPO

You’ll now want to configure the GPO that will push your EFS settings out to the clients. I’m going to place the settings directly into the Default Domain Policy.

Open GPMC and navigate to the node listed in the screenshot below. Right-click over the Encrypting File System node and hit Properties. Configure as shown in the screenshots below.

EFS GPO - General

On the certificates tab, select the custom Basic EFS template you created.

EFS GPO - Certificates

Leave the Cache tab settings as is unless you have a reason to change them. Click Apply and OK to close the window.

Now you’ll need to add the EFS Recovery Agent. Right-click over the Encrypting File System node and select “Add Data Recovery Agent”. Find the accounts you issued the EFS Recovery Agent certificates for and select them.

At this point, you’re done! You have successfully setup the infrastructure for EFS with Server 2008 AD CS. If you autoenrolled the User and Basic EFS certificates, users will be able to encrypt once they reboot their computers. Otherwise, they will need to request them using Web Enrollment or through the Certificates snap-in.

If you end up having to use the EFS Recovery Agent to decrypt an encrypted document, make sure you remember to load the EFS Recovery Agent certificate and private key for the recovery account on the workstation you are logged into. You would accomplish this by exporting the certificate in the same manner as backing up the key. After that, you would open the Certificate snap-in, right-click the Personal node, select Import, and choose the exported certificate.

This was a real learning experience for me and was very useful in reinforcing a number of AD CS concepts. On to Web Enrollment!

*A few additional helpful tips.

  • If you receive “parameter is incorrect” when trying to encrypt a document,
    check the User and Basic EFS certificate templates to make sure you selected an ECC algorithm.
  • If you receive “access is denied” when trying to decrypt an encrypted document using an EFS recovery agent account, verify that you have loaded the private key for the EFS recovery agent certificate on the workstation. This error also occurs if you changed the recovery agent certificate and the item was encrypted before the change. You can verify this by checking the thumbprint of the certificate (details tab when you double-click a certificate) against the recovery agent thumbprint of the encrypted document (right-click document -> Advanced button -> Details button).