How to upgrade Windows Server 2012 R2 evaluation version to full version

How to upgrade Windows Server 2012 R2 evaluation version to full version

Windows Server 2012 R2

On a couple of occassions recently I’ve changed an 180 day Windows 2012 R2 evaluation server into a full production version. This is particularly useful if your evaluation has worked out well, but you don’t want to reinstall a new producation server from scratch.

In this post we’ll look at the steps required to turn the evaluation server into a production server.

Please note, this does not work for Domain Controllers running on an evaluation license.

On my test server below you can see I only have 2 days left.

Windows 2012 R2 - 2 days remaining

If you try and enter the new product key from the System Control Panel you’ll receive an activation error like below.

Windows 2012 R2 activation failed

Open an Administrative Command Prompt. Then run the command:

slmgr.vbs /dlv

Administrative Command Prompt - slmgr -dlv

Slmgr.vbs /dlv is used for volume licensing, and this step is to gather information only. The/dlv switch displays detailed license information. As you can see below we are currently running the ServerStandardEval edition.

If you wanted to continue using the trial for another 180 days, your could use the /rearmswitch.

Results of slmgr -dlv

From the Administrative Command Prompt, run the command:

dism /online /get-currentedition

This will confirm the information we obtained from slmgr.vbs /dlv, as you can see the current version is ServerStandardEval.

Administrative Command Prompt - dism online get-currentedition

Next, run the command:

dism /online /get-targeteditions

This will show you which versions the current evaluation license can be upgraded to, in our case it can be upgraded to ServerStandard or ServerDatacenter.

Administrative Command Prompt - dism get-targeteditions

Next run the command:

dism /online /set-edition:ServerStandard /ProductKey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx /AcceptEula

This command selects the version of Windows 2012 R2 you want to upgrade to, specifies the product key and Accepts the Eula.

Administrative Command Prompt - 9. dism online set-edition productkey accepteula

Once the process has completed it will prompt you to restart your computer.

Administrative Command Prompt - dism online set-edition productkey accepteula - completed

The process will reboot the server twice.

Reboot adding features

Cleaning up installation

Once completed and logged in you can see in the bottom right hand corner that the server is no longer running and evaluation version. Also on my test server I received an Shutdown Event Tracker.

Windows Server 2012 R2 Standard unexpected shutdown message


How to Use Windows Vista and Windows 7 for One Year Without Activation?

You have to use the same slmgr -rearm command in this method too.

So here is the step-by-step method:

1. Click on “Start button -> All Programs -> Accessories“. Right-click on “Command Prompt” and select “Run As Administrator“. If you are prompted to enter password, enter the password and continue. You can also open Command Prompt in Administrator mode by typing “cmd” in Start Menu Search box and press “Ctrl+Shift+Enter“.

2. Now provide following command:

slmgr -rearm


3. You’ll be prompted to restart Windows, restart it and the trial period will be reset to 30 days again.

4. You can use the same command 3 times. In this way you’ll be able to use Windows for 120 days without activation.

5. Now its time for the main trick. Type regedit in RUN dialog box and press Enter. Now go to following key:

For Windows Vista:

For Windows 7:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform

6. In right-side pane, change value of SkipRearm to 1.


7. Now you’ll be able to use the slmgr -rearm command 8 more times. So you’ll get total 360 days for using Vista and 7 without activation:

120 days by using slmgr -rearm command before registry editing

VMware error on HP Proliant "Host Baseboard Management Controller status"

VMware error on HP Proliant “Host Baseboard Management Controller status”


Saw this today on a HP Proliant DL380 G7 Server.

Host Baseboard Management Controller status


1. It’s a simple one to solve, the server was built with the HP ESXi build, and the management agents are complaining because the iLO is not connected to the network.

2. When you connect the iLO socket to the network the alarm should change as shown below.

Warning Host Baseboard Management Controller status

3. Once you have connected or disabled it you can reset the alarm.

reset vmware alarm

4. Take the opportunity to log in and configure the iLO. Access via an internet browser (it will get a DHCP address by default, you can set a static IP address by entering the iLO setup at boot (see disabling iLO section below)).

5. The user name is Administrator (capital A) and the password will be either on a pull out tab on the front of the server, or a brown cardboard label tied to the front of the server (you did keep that didn’t you!), or on a brown sticker on top of the server chassis. On certain models HP also stick this information under the server lid.

iLOusername and password

6. Then you can log in and configure.

connect to iLO

Disable the iLO

1. If you do not want to use the iLO then you can disable it (I cant think why you would want to, because its a handy piece of kit, but heres how to do it.)

2. Reboot the server, and when prompted press F8 to enter the iLO setup.

iLO press f8

3. Settings > Configure.

configure iLO

4. These are the default settings, use the cursor keys to select and the space bar to enable/disable the options.

iLO options

5. All disabled.

disable iLO


AD Authentication in vCenter SSO 5.5

AD Authentication in vCenter SSO 5.5

With the recently released VMware vSphere 5.5, the component Single-Sign-On (SSO) has been completely rewritten. The biggest change is that the RSA database has been removed, which eliminates much of its complexity. There is also a new identity type (Active Directory (Integrated Windows Authentication)) that works without specifying the AD Controllers directly, like the old vSphere 4.x / 5.0 authentication. The whole process is much easier. This post shows how to enable Active Directory Authentication within the new vSphere 5.5 Single-Sign-On. If you are using vSphere 5.1, read this post.

The method shown in this post allows you to manage users and groups in your central directory. This works for both, the vCenter Server 5.5 installed on Windows Server and the vCenter Server Appliance (VCSA).

  1. Open vSphere Web Client (https://<ADDRESS&gt;:9443/vsphere-client)
  2. Login as administrator@vsphere.local
    Password (Windows): Set during installation
    Password (VCSA): “vmware”
  3. Navigate to Administration > Single Sign-On > Configuration
  4. webclient_administration sso55-configuration
  5. (If there is no Single Sign-On configuration you are probably not logged in as administrator@vsphere.local)
  6. Click the green + sign to add an identity source
  7. Select Identity Source Type:
    A) Windows based vCenter Server 5.5:
    Active Directory (Integrated Windows Authentication)

B) vCenter Server Appliance 5.5 (VCSA):


  1. Click OK
  2. Back at Identity Sources your AD should appear in the list and from now on you are able to assign vCenter permissions to users and groups from your active directory. When you are using the Integrated Windows Authentication, trusted domains are also available. The functionality is very similar to vSphere 4.x and vSphere 5.0
  3. Select you Active Directory and click the “world with arrow” button to make AD to your default domain.
  4. You should get an warning telling you that “This will alter your current default domain. Do you want to proceed?”. This is okay, as you can only have one default domain.
  5. That’s it. You can now set permissions and authenticate against active directory with vCenter Server 5.5 though SSO.

To change the vCenter Server SSO configuration with other users than administrator@vsphere.local, you have to add them to the Administrator Group within SSO:


vSphere 5.5 SSO Integration with Active Directory

vSphere 5.5 SSO Integration with Active Directory

After getting ESXi installed on the Mac Minis and the vSphere vCenter Appliance deployed, my next step was to integrate my labs Active Directory with Single Sign On.  Based on the documentation provided on the vSphere 5.5 Documentation Center, the AD integration was a pretty simple procedure and relies on a handful of fundamental components to complete.

  1. Domain Membership
  2. SSO Service Account
  3. Identity Source
  4. Groups and Permissions
Domain Membership:

The vSphere vCenter Server must be added to the Active Directory domain if vSphere SSO Active Directory integration is going to configured.  If your vCenter is a Windows Server, it is a pretty standardized practice and a generally accepted prerequisite.

My lab is using the vCenter Server Appliance, so joining the domain is pretty simple.

  1. Connect to the vCenter Server Appliance Administration page located at https://%5BVCENTER_SERVER%5D:5480/ and login as root. 
  2. Navigate to the Authentication tab under the vCenter Server configuration
  3. Fill out the domain name with the proper credentials with the proper permissions that will allow the computer account for the VCSA to be created in AD
  4. Save Settings but don’t reboot the Appliance until the Identity Source has been set and the proper roles and permissions are configured.

Screen Shot 2013-11-03 at 4.50.55 PM.png

SSO Service Account:

One of the requirements (if you are not using a machine account) for vSphere SSO Active Directory integration is to have a Service Principal Name (SPN) in Active Directory.  To set the SPN, connect to the Domain Controller and create the Service Account for this purpose:



The SSO Service Account should be a dedicated account with the proper password expiry settings attributed to it.

Once the Service Account is created, open a command prompt as administrator on the Domain Controller and run the following command as depicted below:



Ensure that the last line of the command returns with ‘Updated object’ before moving on to the next step.

Identity Source:

Identity sources allow you to attach one or more domains to vCenter Single Sign-On. A domain is a repository for users and groups that the vCenter Single Sign-On server can use for user authentication.

To set the identity source, ensure that the domain membership and SSOServiceAccount SPN settings are completed, then:

Login to the Web Client (https://%5BVCENTER}:9443/vsphere-client/) and connect to the vCenter Server using the administrator@vsphere.local account.  The password for the account from freshly deployed VCSA will be ‘vmware’.  Do not use & not “admin@system-domain” like you did in vCenter 5.1 SSO.


Navigate to  Home > Administration > Single Sign-On > Configuration page


Use the + sign to add your domain as a new identity source. Select ‘Active Directory (integrated Windows Authentication)’ and complete the following fields as depicted below:

Domain name, Service Principle Name (SPN), User Principle Name (UPN) and the password that you set with your created the account in Users and Computers.


If all the fields are no longer outlined in red, you have completed the them successfully and can select OK. If the settings are correct the progress bar should complete in about 30-60 seconds and there will be an additional Identity Source listed in your configuration.


Once the Active Directory domain is added as an identity source for authentication, the proper group memberships and permissions must be setup in order to see the existing vCenter inventory components.

Groups and Permissions

Staying logged in with the administrator@vsphere.local account; navigate to the ‘Users and Groups’ configuration section on the left hand side, select the Groups Tab in the middle and highlight the Administrators Group as in the picture below.  Near the bottom of the page click the ‘Add Member’ button.


When the ‘Add Principals’ wizard pops up:

  1. User the domain drop-down list to select the Active Directory Domain.
  2. Select  and highlight the Group or User account that will be used to access  and administer the vCenter Server.  I would recommend using a group membership.
  3. Use the Add button to populate the Users: or Groups: field below
  4. Select OK to make the changes.


Now that the Groups (or Users) are added into the correct group memberships (that correspond to the correct roles), the permissions to the vCenter must be applied.

Navigate to Home > vCenter > vCenters and highlight the VCSA instance name on the right hand side of the screen.  Select the Manage tab > then select the Permissions tab and use the + [Add permission] button to add the same User or Group in the above example.


Using the Select Users/Groups wizard:

  1. User the domain drop-down list to select the Active Directory Domain.
  2. Select  and highlight the Group or User account that will require permissions to administer the vCenter Server. 
  3. Use the Add button to populate the Users: or Groups: field below
  4. Select OK to make the changes.


After about 30 seconds, the additional line(s) will show up with having the proper permissions to the vCenter inventory and components.  This is the same functionality as setting roles and permissions in the traditional C# client.

Before testing out the access and permissions, remember to reboot the vCenter Server Appliance and allow the domain membership changes to take place.

After the appliance comes back up and the Web Services have started again, login to the Web Client interface and validate that the authentication and permissions are correct and functional. 


An easy way to tell is the inventory and permissions are correct is to validate on the vCenter Home whether the existing vCenters, Hosts and VMs are showing up  on the left hand side within the inventory as in the example below.


If you are running Windows, make sure to download and install the Client Integration Plug-in to enable the ability to use your currently logged in Active Directory credentials. 


Running Dell DSET remotely on ESXi

For those using Dell hardware, when you log the job with Dell Support, they’ll ask you to run a DSET report. This collects various information of the server including service tag, all hardware devices, firmware versions etc.
There’s 3 ways to get DSET info.
1) Install DSET locally
2) Run DSET LiveCD
3) Run DSET remotely and create a report on a local server.
Each option has their pros and cons.
The DSET download is available at

Install DSET locally

This is pretty straight forward. You can do a normal install and keep the software installed, or choose to create a one time local DSET report. Useful if you don’t want to keep unnecessary software on your servers. Doesn’t require an outage/reboot.

Running DSET LiveCD

Get the latest version at (omsa-71-live). This will boot into a CentOS LiveCD to the graphical user interface with the Dell utils you need on there. You don’t need to know the root password, but it’s “dell”.
Here you can run the DSET util and save it to a USB disk, vFlash, or network share / scp remotely. The DSET output is saved to /tmp/data/.
This requires an outage as it needs to boot from DVD.

Running DSET remotely

So, first we need to install the OpenManageServer Administrator Bundle version 7.4 – you can find that located here.  Go ahead and download the zip file and extract to /var/log/vmware on your host.  Yes, the package will look for that specific path so you will need to be sure it is in /var/log/vmware.  From there we can simply install the vib with the following command

esxcli software vib install -v /var/log/vmware/cross_dell-openmanage-esxi_7.4.ESXi550-0000.vib

Next – DSET

The version of DSET that we will install is 3.6.  The installation for DSET is the standard Next Next type of install – so I won’t go over much of that – just be sure to select both the CIM provider and the collector.  You can find it here.   Once done you are good to go.  Launch a command shell (as administrator) and browse to c:\Program Files(x86)\Dell\AdvDiags\DSET\bin and run the DellSystemInfo.exe command with your desired parameters (example below)

c:\Program Files(x86)\Dell\AdvDiags\DSET\bin\DellSystemInfo.exe -s IP_OF_Host -u root -d hw -n root/dcim/sysman -r C:\

For more info, run dellsysteminfo.exe /h, or just run:

C:\Program Files (x86)\Dell\AdvDiags\DSET\bin> dellsysteminfo.exe -s servername -u root -d hw,st,sw,lg -r c:\temp\
Dell System E-Support Tool, Version 3.5.0
@2004-2013 Dell Inc. All Rights Reserved.
Please enter “root” password:
* Gathering Chassis information…
* Gathering Software information…
* Gathering Logs…
* Gathering System Summary information…
* Preparing and Compressing Report…
* Saving DSET CIM report to path: c:\temp with report file name:


Failed to gather Software/Logs data. Check the IP Address and credentials: – Ensure ssh is enabled.
Failed to gather Software/Logs data. Either user is not part of sudoers list or NOPASSWD is not configured – try using the root account.
Some detailed information is missing from the report: reset OpenManage services.

DSET Output

Once the DSET report has been saved, you can send it to Dell Support for investigation. If you’re curious about what’s contained in report, unzip using the super secret password “dell”, and run the dsetreport.hta file.

There you go!  Your Dell DSET log that you can now forward off to support to get your issues looked after.  This certainly isn’t a very difficult thing to do but troublesome nonetheless trying to match up versions to make things work.  Anyways, hope it helps with anyone having issues.