If you are like us, we are always on the cutting edge (what do you expect – we work for Microsoft <g>) and because of this we have to often find unusual methods to work around the fact that OEM’s are not always “up to speed” and releasing installers and such that are for operating systems that are still in beta.
Because of this, many of you might find yourself scratching your head when you attempt to update your client or server hardware using the OEMs installation file (*.msi or *.exe). In this post, I want to share a couple of examples of where I was able to successfully get around this using a pretty “unknown” piece of functionality in Windows 7 or Server 2008 R2.
Windows Vista implemented the first version of User Account Control (or limited administrator) functionality that has gotten rave reviews since its release (the tone here is missing). As much as we hate it, the feature is one that can save your bacon (or rear end) if you are a standard user. Beyond that, limited administrator can also make your life miserable as you attempt to run installers who are written in such as way that they expect to run as a user who has a full administrator token. This isn’t the case with Windows Vista or the upcoming Windows 7.
You have a user account, let’s say Chris, that is a member of the local machine’s administrators group. However, this account is not the actual user named ‘administrator’ and thus your administrative privileges are not included as part of your standard token when running 99% of the time. However, if you attempt to do something such as install a device driver that requires administrative privileges then the system prompts you asking you to elevate. You have two choices – Allow or Disallow.
Until released, there are a great deal of OEMs who will not officially support Windows 7 as they are in “testing” mode. Thus, you are unable to access bits that are natively targeted at Windows 7 client or server. This creates a little bit of a quandry for you if you have a need to update a server with an application that doesn’t natively support Windows 7.
The nice thing is that the security model for Windows 7 hasn’t changed drastically from Windows Vista. The key word is drastically and for the most part you will not fail if you attempt to push a Windows Vista installation on a system that is running Windows 7.
Recently, I had the need to install a Support tool to obtain information about one our SAN-connected hosts. The program was provided to me by EMC. I ran the tool on the server and what I received was the following:
Causes the following to occur…
The other scenario we saw this was with Dell downloadable Windows applications that will update driver hardware.
There are a multitude of ways you might get this error. I can’t cover them all but the key is how to work around these and get the installations working.
To workaround issues such as those outlined, you can use the compatibility mode available in Windows 7 & Server 2008 (it was also in Vista but I haven’t tested it as much <g>)
To use compatibility, do the following:
The installation or setup should now run and execute as the system is now running in compatibility mode.
Can you make a silent install package that will run in compatibility mode?