VMtoday

Posts Tagged ‘Microsoft’

I recently completed a VMware VI 3.5 to vSphere upgrade in a small environment (5 hosts, 80 VM’s).  Being a small environment, the upgrade was planned for one big overnight blitz.  Unfortunately, the size of the environment did not afford a test environment to uncover potential issues before the upgrade.  The upgrade to vSphere itself went swimmingly (the vCenter server had been upgraded a couple weeks earlier).  However, some things in the environment started to go wonky once the upgrade was complete.  Specifically, name resolution (DNS), DHCP, WINS, Group Policy, and really anything Microsoft Active Directory related just did not work.

Let me explain a bit about the environment so you can better understand what the problem was and how it was corrected. The environment was an all Microsoft shop, except for VMware of course. The company follows a virtualize-first policy and is about 90% virtualized, including the Active Directory Domain Controllers. The DC’s are Windows 2008 and serve up DHCP, DNS, and WINS in addition to their Directory Services roles.

The problems really began after I upgraded the virtual hardware version from v4 to v7 (check out page 97 of the vSphere Upgrade Guide for the upgrade procedure).  When a Windows server is upgrade from VMware Hardware Version 4 to 7, the VMware Upgrade Helper Service handles the reconfiguration of network adapters on the upgraded virtual machine.  The VMware Upgrade Helper Service is installed with VMware Tools and is one of the reasons, along with getting drivers installed for the new hardware, for upgrading VMware Tools before upgrading the hardware version.  If you review the Event Viewer Application log on an upgraded machine you will see several entries from VMUpgradeHelper (Source) with several different Event ID’s (26, 280, 272, 108, & 105).  An examination of these events will show that the VMware Upgrade Helper service 1.) Backed up the network configuration at OS shutdown, 2.) Started Automatically with the OS, 3.) Checks the device ID for the network adapter, 4.) If the device ID has changed (as a result of a hardware upgrade), the backed up configuration is restored and Event ID 269 is logged.

This behavior should be transparent for most configurations, with the exception of a slightly longer boot time following the upgrade.  However, I did notice a few problems with the NIC settings being restored under certain conditions.  First, on servers with a statically configured IPv4 stack, IP addresses and DNS server addresses were restored, but the WINS server addresses were not restored.  I suspect this is an oversight in the VMware Upgrade Helper service, but is probably not a major issue for many servers/environments as WINS is infrequently used.  However, for a WINS server itself to lose its configuration to use itself as a WINS server, bad things happen.  There are several ways to correct this – scripts, DHCP Options, etc.  In the end, this wasn’t really a show stopper for me in this small environment.

The second, and bigger issue for me, was that after the virtual hardware was upgraded and the VMware Upgrade Helper Service did it’s job my Active Directory and related services were not available.  DNS was not functioning, DHCP was not handing out addresses, and I couldn’t connect to AD using ADUC, GPMC or LDAP.  It took me a few minutes to figure out what was going on.  This seems to be what happened: the virtual hardware upgrade caused a new virtual network adapter to be installed in the VM and all of the settings, including the MAC, address to be restored.  The HW v4 NIC was removed from the machine, but Windows held onto the device as a ‘ghost NIC’ in Device Manager.  The core AD services, including DNS and DHCP, were still attempting to bind to the ghost NIC.  This behavior persisted through service restarts and reboots of the guest.  It wasn’t until I examined the IP configuration on the new NIC and clicked Apply (instead of canceling out) that I was prompted with a message indicating that there was more than one network interface configured with the same IP address, queuing me into the solution.

The error message should be familiar to anyone who has performed a Physical-to-Virtual migration (P2V) and is easily corrected by removing the old device through Windows Device Manager.  The device is hidden so you first have to expose it before deleting it.  Check http://support.microsoft.com/kb/315539 for details or simply follow my instructions below.  To expose the non-present NIC, open a command prompt and enter:

set devmgr_show_nonpresent_devices=1

You can then open Device Manager (enter devmgmt.msc at the command prompt to save some time).  In Device Manager, click View | Show Hidden Devices.  Expand Network Adapters and find the grayed-out entry for the old NIC as pictured below.

Select the ghost NIC and right-click | Uninstall to remove it.

The final gotcha for me on this is that the set devmgr_show_nonpresent_devices=1 command does not work on Windows 2008 (or Vista, Windows 7, or Windows 2008 R2).  To see and remove ghost NICs from Windows 2008, and environmental variable must be defined.  To set the variable, open Server Manager from the Windows Start Menu.  Highlight ‘Server Manager (%SERVERNAME%)’ in the left-side tree-view pane.  Click ‘Change System Properties’ in the right-hand pane.  Switch to the Advanced tab and click ‘Environment Variables.  Create a new System variable by clicking the New button.  The Variable name should be ‘devmgr_show_nonpresent_devices’ and the value should be ’1′ as pictured below.

Click OK to close out of any open Windows.  A reboot is not necessary for the variable to take effect, although you may have to close out of all open Device Manager Windows and then reopen devmgmt.msc.  Click View | Show Hidden Devices and remove the ghost NIC as described above.  A quick reboot after I removed the ghost NIC from the domain controllers and all Active Directory, DNS, DHCP, and WINS services immediately began operating normally.  This second issue is more of a Microsoft problem in my opinion, and has been around for some time.

Before you start getting all upset and the FUD starts flying (“this is Microsoft/VMware’s latest attempt to break VMware/Microsoft?”), it wasn’t really vSphere that broke Active Directory; It was me.  A little better planning and not rushing through the last wee hours of the upgrade Window could have saved some trouble.  If you are planning a similar upgrade, it would be best to upgrade your domain controllers/DNS servers one at a time and remediate the issues I have decribed before upgrading the next.  This will ensure continued availability of your Active Directory and other critical services during your upgrade.

Microsoft published a document named “Getting to Know Hyper-V: A Walkthrough from Initial Setup to Common Scenarios” last week.  According to Microsoft, “this guide provides detailed step-by-step walkthroughs for testing Hyper-V on a pre-production environment. You can use this guide to become familiar with Hyper-V and the process of creating and managing virtual machines. Also included in this guide are useful scenarios that you can test to better understand how Hyper-V can address the business goals of your organization.”  The document serves as a sort of evaluators guide for Hyper-V, stepping the reader through everything from enabling VT in BIOS through virtual networking.  It also includes some sections on using snapshots, base virtual machine templates, and managing Hyper-V based virtual machines remotely with Hyper-V Manager.  If you want more in-depth documentation on Hyper-V you can go through http://technet.microsoft.com.

As a side note, Microsoft has published the Microsoft Manual of Style for Technical Publications to help standardize technical documentation.  I have long been a fan of Microsoft’s technical documentation for its easy to read style, although it sometimes lacks the depth that I desire.

While we’re on the topic of virtualization documentation, I have also been quite pleased with VMware’s technical documentation over the years, and have found it to be continually increasing in quality, providing very specific technical guidance and references to additional resources.  I have also been pleased to see that VMware has improved delivery options for documentation.  VMware offers several formats for documentation delivery, including web-based and PDF’s.  Start with the Documentation Roadmap for a quick introduction to the available documentation, and where to find what you need.

You can find web-based vSphere documentation here: http://pubs.vmware.com/vsp40/.   The web-based documentation is great for running searches on.  All vSphere documentation can be accessed through this page: http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esx40_vc40.html.  If you want to do a full grab of all of VMware’s documentation for an in-house repository (e.g. SharePoint), check out xtravirt’s VMware Documentation Downloader script.

If you are looking for quick and easy evaluator guide-type documentation from VMware, check out these resources: ESXi Installable and vCenter Server Setup Guide and the Virtualization Kit (registration required) at http://www.vmware.com/resources/wp/virtualization101_register.html.

There is a ton of less formal VMware documentation in several places:

• Technical resources and case studies here: http://www.vmware.com/resources/techresources/
• Proven practices around Strategy, Applications, Security, Management, and Availability at VIOPS.
• Official VMware Blogs at http://www.vmware.com/vmtn/planet/vmware/.
• Community blogs aggregated by VMware at Planet v12n: http://www.vmware.com/vmtn/planet/v12n/
• VMworld Recorded Sessions & Labs (VMworld 2009 Sessions available as of today, September 14th) at http://vmworld.com.
• The VMware Community Forums: http://communities.vmware.com/
• And, 3rd party books like Scott Lowe’s Mastering VMware vSphere 4.

Do you have other sources of virtualization documentation or easy methods of searching documentation to find exactly what you need when you need it?  If so, leave a comment!

A user reported an issue with one of the VM’s in my environment this morning.  It seems that an automated process had spun up the CPU to 100% in the Windows guest and the system was deadlocked.  I was still at home when I received the message on my BlackBerry, so I fired up the VPN on my Windows 7 laptop, opened the VI3 client and….., um, where is it?  The VI3 client icon was in the taskbar, but the app was nowhere to be found – it had opened off-screen where my secondary monitor usually lives.  This is nothing new for the VI client – I have experienced it numerous times in the past.  But this was my first time with the problem on Windows 7.

Pre-Windows 7, I would have right-clicked the Windows taskbar for the app, selected ‘Move’, and then used the keyboard arrow keys to guide the phantom window home.  Windows 7 does not have the same Windows positioning options on a right-click to the taskbar so I had to find another way. Enter Windows shortcut keys.  Here’s how I brought the VI3 Client window back into view:

1. Make sure that the VI3 Client window is in the foreground by selecting it in the taskbar.  You’ll know that it is in the foreground when the taskbar icon gets a white glow as pictured here:
2. Press the hotkey combination: “ALT+Space, M” for Move.
3. Use the keyboard arrow keys to move the window to your active monitor, pressing “Enter” once the window is visible to commit the move.
4. If the arrow keys fail to move the window and/or you hear the Windows error sound, your VI3 Client windows is probably maximized.  The move option is not available when a window is maximized.  To work around this condition use the hotkey combination: “ALT+Space, R” for Restore.  You should now be able to move the window using steps #2 & #3 above.

If you are still really struggling, break out the trusty old registry editor and follow along:

1. Close any open VMware Infrastructure Client windows
2. Navigate to HKEY_CURRENT_USER\Software\VMware\VMware Infrastructure Client\Preferences\UI
3. Locate the ApplicationLocation key.  This key provides the X-Y coordinate for the VI Client window at startup.
4. Modify the string value to 0-0.  This value will cause the VI3 client to open in the center of your primary display.
5. If you run different sized/resolution displays, you may also want to change the ApplicationMaximized or ApplicationSize keys to fit your needs.
6. Launch the VMware Infrastructure Client and get back to work.

We picked up a few new 17″ MacBook Pro’s at work. We’re a Microsoft shop, so Mac’s aren’t part of the basic knowledge for our IT staff, myself included. I don’t want to be the Windows guy who says “I don’t do Macs” – part of being a technologist is serving the user base where they are at with the technologies they require to do their job (but please, included me in determining your requirements and technological solutions – a Mac might be really cool, but might not fit with the organizations needs or your IT group’s ability to support your solution). Really, that’s what Web 2.0 is all about – compatible, interchangeable tools that offer customized functionality for the users’ abilities and needs. Come to think of it, that’s what VMware is all about too – the right resources in the right place at the right time, independent of underlying hardware, application/OS agnostic, able to rise above local shortcomings by pushing to the cloud….

To be fair, I was issued a Mac at a previous company, but didn’t care much for it as the programs I had to run for my job were Windows based. I ran VMware Fusion, but it could only take me so far – funny things start to happen when you are in a VM, RDC’ing to a client server, opening the VI client and console’ing to a VM. Shortcut keys behave strangely, and one can only create so many alternate key mappings before going insane. It wasn’t the right tool for me and my job, but Macs do serve some purposes very well – graphic design and iPhone app development in my current case.

I didn’t have a requirement to do much customization the new Mac’s, but they did have to allow users to authenticate to the current Microsoft Windows Active Directory Domain. I hit a few snags as I went through the process, including making domain users local administrators and allowing domain users to log in to the Mac while off-line. Here is what I came up with for a final process in my environment – adjust according to your needs:

1.) Configure OS X to talk to the Active Directory

• Using Spotlight (LeftCommand+Space), open the ‘Directory Utility’
• Switch to the Services tab
• Tick the box next to Active Directory plug-in (Note: You may have to click the lock icon to make configuration changes).
• Highlight the Active Directory plug-in and click the Configure icon (pencil icon).
• Enter an Active Directory Domain, using the FQDN (example: mydomain.local)
• Enter a Computer ID.  This ID will be used to create a computer object in the AD.
• Expand Advanced Options:
  • On the User Experience Tab:
    • Check the box for ‘Create mobile account at login’.
    • Uncheck the box for ‘Require confirmation before creating a mobile account’.
    • Choose the ‘Use UNC path from Active Directory to derive network home location’ if your AD is set to map a user’s home location to a UNC and/or DFS path; if not, you may want to uncheck this option.
  • On the Administrative tab:
    • Check the box for ‘Allow Administration By:” and then Add the Active Directory ‘domain admins’ and ‘enterprise admins’ group
    • Check the box for ‘Allow Authentication from any domain in the forest’ if appropriate for your environment
• Click the Bind button and enter credentials for an account with permissions to join the domain on the Active Directory domain you are joining.  Note: The computer account may appear in the default AD ‘Computers’ container even if the redircmp utility was used on the domain to change the default Organizational Unit (OU) of new computers joining the domain.
• Click OK.
• Verify that the Active Directory Domain that you configured correctly appears with a green dot on the ‘Directory Servers’ tab of the Directory Utility.
• Close the Directory Utility.

2.) Configure basic login options

• Open the Accounts tool from Apple | System Preferences | Accounts
• Click Login Options (Note: you may have to click the lock icon to allow changes to be made).
• Configure the Login Options settings as follows:
  • Automatic Login: Disabled
  • Display login windows as: Name and Password
  • Check the box for Allow network users to login to this computer.
    • Click the Options button and configure all network users (i.e. – all Domain users) or only select users to have login permissions.
  • Configure other options as desired.
• Log out of the local Admin account

3.) Log in using a domain user account (with permissions to login to the server (see above) while connected to the network) using the AD user.name and password

• The first login may take several minutes to complete as a local account is being created.
• Open the Accounts tool from Apple | System Preferences | Accounts
• Highlight the logged-in user’s account.
  • Check the box for ‘Allow user to administer this computer’ as appropriate
  • Verify that the ‘Settings’ button for Mobile Account is grayed out – this means that an offline account has been created for the user.

4.) Test the config by removing network connectivity (disable AirPort and/or pull the network cable) and log in as the user you just configured.

5.) Buy VMware Fusion so you can run Windows on your Mac when all the stuff you were used to just ain’t there anymore