November 2007

Today VMware released version 1.1 of VMware Fusion, their desktop virtualization product for Intel-based Macs.  I’ve been using Fusion since the very earliest days and have been really pleased with the product, so I had no hesitation in upgrading to the latest release.  Although there’s nothing terribly revolutionary here, what I’ve seen so far shows me that it is a solid update to an already solid product.  Sure, they’ve extended some of the DirectX support, and added a UI feature here or there, but these are evolutionary changes as the product matures.  If you’re running Fusion and haven’t yet upgraded, I recommend doing so.  Just keep in mind that you’ll need to update the VMware Tools, which generally means a reboot of your virtual machine.

Now, what would be exciting to see from the Fusion team would be more feature parity with Workstation 6.0.  Namely, a UI for advanced networking configurations, linked clones, multiple snapshots, etc.  In particular, the multiple snapshot feature would be very useful, and is pretty much in-line with the product’s consumer-oriented focus.  How about it, Regis and team?

Thanks for visiting my site! My name is Scott Lowe, and this is my weblog about various technical subjects and the occasional personal topic.

Personal Information

I live with my wife, Crystal, and our kids in the greater Raleigh-Durham, NC area. When I’m not working or spending time with my family, I’m working in our church, Knightdale Church of God, as a youth leader.

Professional Information

I’ve been in the Information Technology field for more than 15 years, starting out with desktop support and ending up as a senior engineer with ePlus Technology, a local reseller/VAR in Raleigh with corporate headquarters in Herndon, VA. Along the way, I worked as an instructor, a technical trainer and Microsoft Certified Trainer (MCT), systems administrator, IT manager, and Chief Technology Officer for a small start-up. In my current role as a senior engineer with ePlus, I specialize in server virtualization, storage, and related enterprise technologies.

In addition, I also recently became a contributor to SearchVMware.com, a VMware-focused website with technical articles, how-to’s, tips, and news.

Contact Me

If you’d like to send me an e-mail, you can reach me at this e-mail address.

It seems like Microsoft just doesn’t learn.  OK, I’ll grant you, it’s hard for a multi-billion dollar company with tens of thousands of employees to move quickly or respond nimbly to customer concerns, but I can only justify their actions so far.  Here we are again, for the second time in as many months, talking about Microsoft pushing software to Windows machines when that software was unapproved or unwanted.

Last time something like this happened, Microsoft was updating their Windows Auto Update client, even when automatic updates were turned off.  The explanation was something along the lines of “we needed to update the auto-update client so it would work”, failing to recognize that if it was turned off it didn’t really need to work, did it?

This time, we find Microsoft unexpectedly changing the applicability scope for an update delivered via Windows Server Update Services (WSUS) and delivering that update as a revision.  Because most WSUS installations are set to auto-approve revisions—this helps reduce the administrative overhead of managing the update list—this update was pushed out to all systems.  And because this update was a full installation, not just an update, then suddenly organizations find themselves with loads of machines running Windows Desktop Search (WDS).  Oh, that includes the servers in the datacenter, too.

The WSUS team at Microsoft posted a blog entry trying to explain the behavior and, in my opinion, failing miserably.  Since this was technically classified as a revision to an existing update, the WSUS team insists that this revision would only have been installed if prior WDS updates had also been approved.  This is consistent with the automatic approval of revisions.

Unfortunately, it would appear that Microsoft made poor judgment calls in a number of areas:

• Listing this as a revision (which is supposed to be limited to changes in metadata or applicability rules, never changes in binaries) when in fact it appears to be an entirely new version of WDS
• Changing the applicability rules for this update to include all systems, including those that did not previously have WDS installed
• According to some customers, installing the update even when previous updates were not approved

In my opinion, this bodes poorly for Microsoft.  Managing patches is already a huge task for many admins.  Now administrators have to worry about “updates” getting installed that shouldn’t have been because there’s been an applicability change to the update, or it was listed as a revision when it’s really a new set of binaries.

If by chance you were hit with this, you can uninstall WDS with either of the following commands:

%windir%\$ntuninstallkb917013\spuninst\spuninst /quiet /norestart

MsiExec.exe /X{E72019B8-1287-4093-BE9B-1CFA7BA1A8D2} /quiet /norestart

Are there any readers out there who were actually affected by this issue?

Back at the start of October, about a month ago, I wrote about an exciting new opportunity that had recently opened up for me. I couldn’t really disclose any details at that time, but now that everything has finally materialized into reality I can share exactly what is happening.

So here’s the opportunity that I was talking about—I’m writing as a contributor for SearchVMware.com, a new TechTarget site focused on VMware virtualization. I am really excited about this! I’ve written three articles so far, all of which were published yesterday:

VDI on VMware Virtual Infrastructure: Using the three main components

In some aspects, Virtual Desktop Infrastructure (VDI) takes the best of server-based computing and removes many of the drawbacks. Most people understand that the concept of VDI is using virtualization software, typically VMware Virtual Infrastructure 3 (VI3), to host instances of a desktop operating system instead of a server operating system…

Configuring VLANs in VMware VI3 (Virtual Infrastructure 3)

The key to understanding VI3’s support for VLANs lies with the concept of a “VLAN trunk”. A non-trunk port—also called access port—carries traffic for a single VLAN, but a trunk port carries traffic for multiple VLANs simultaneously…

Authentication in a VMware VI3 Implementation

Many organizations that have implemented VMware Virtual Infrastructure 3 (VI3), including both ESX Server and VirtualCenter, but do not have a firm grasp of how these components handle authentication…

More articles are in the works, so be sure to stay tuned to SearchVMware.com! And, if you have any suggestions for future articles that should be written, please let me know. Or, better yet, register at SearchVMware.com and let me know there too!

I’ve received some feedback from a reader who alerted me to some sort of interaction between the Local Security Policy on the Windows side and Linux servers authenticating to Active Directory via Kerberos/LDAP/Samba.  I haven’t quite been able to get to the root issue yet, but here’s the high level overview.

The reader was seeing strange delays at the end of a Linux logon process that seemingly could not be explained.  After jumping through all the hoops, another administrator within the organization changed the Local Security Policy setting that governed the use of LM and NTLM authentication, and the delays disappeared.

The policy had been set to allow both LM and NTLM authentication; when changed to allow only NTLM authentication, the delays disappeared immediately.  The Linux server in question did have Samba installed, so apparently Samba was timing out trying the LM authentication; this caused the delays.  Of course, this is all just speculation, as we don’t know exactly why the policy change eliminated the delay.

In any case, since I’ve been pushing the use of Samba in my latest integration instructions (Solaris version here), I thought it might be prudent to mention this feedback.  In the event you start seeing some strange delays in your Linux authentication requests, check the Local Security Policy and see if LM authentication is being permitted.  That might just be your culprit.