Ten Changes You May Not Know About Vista

Windows Vista was released a little more than 18 months ago, yet it’s still causing surprises in some quarters. By now, the list of new features in Vista should be familiar to many BizTech readers, but there are a lot of small changes in Vista that are not so well known. Some are new to Service Pack 1 and some are present in the release to manufacturing, but many are overlooked and a few are still undocumented. We took a hard look at 10 of these subtle changes in the product that could affect you in different ways, and where possible, we offer a workaround for each change.

ONE: Dive in and learn all the little changes.
There are a lot of big, obvious changes to the user interface in Vista, but there are also numerous small changes in which settings have been renamed or moved to different tabs or properties sheets — often for no apparent reason. Here’s an example: In Windows XP, you can find the version of an executable (.exe) file by opening Windows Explorer, right-clicking on the file and selecting Properties, and then choosing the Version tab — the second of five tabs displayed. In Vista, this tab is now called Details and is the fourth, not second, tab. Why the change? Bottom line is, if you upgraded to Vista, plan on spending some time learning new ways to perform familiar tasks (granted, some of these new ways are better than the old ways). And if you think some settings might be missing in Vista, check around — they may have been simply moved or renamed.

TWO: Know the features of Vista editions.
With the expanded slate of editions for Vista, some features you think will work may not. An example is Services For Unix (SFU) 3.5, which you could download and install on any Windows XP Professional computer — great for administering mixed environments from a workstation. Vista’s version of this, called Subsystem for UNIX-based Applications (SUA), can be installed only on Vista Enterprise or Ultimate editions, not Vista Business. Check carefully what each Vista edition supports and doesn’t support before committing to one particular edition for your environment.

THREE: Launch a program from the command prompt.
In Windows XP, you could drag and drop a shortcut for a program into a command-prompt window, then hit Enter to start the program. This meant you could use the RunAs command to launch a command prompt with administrator credentials, and then use this trick to launch various programs as an administrator while still logged on as an ordinary user. All this could be done without having to type the full path to the application, which may be long and may contain spaces. Unfortunately, this trick no longer works in Windows Vista. The somewhat tedious workaround is to hold down the Shift key while you right-click on the shortcut and select Copy As Path, then paste the path into your command-prompt window.

FOUR: Open a command prompt at a specific directory.
In XP, when you open a command-prompt window, it opens at the current directory regardless of whether you use RunAs or not. In Vista, ordinary command-prompt windows do the same, but if you right-click on a shortcut to cmd.exe and select Run As Administrator, it always opens at c:\windows\system32. There’s a workaround, however: If you want to open an admin-level command prompt to a specific directory (say, d:\somefolder) you can create a shortcut on your desktop to c:\windows\system32\cmd.exe /k “cd /d d:\somefolder” and then right-click on it and select Run As Administrator.

FIVE: Log on manually to a specific domain.
Before Vista, if there were two or more Active Directory domains in your forest, or your forest had a trust set up with another forest, you could use a drop-down list to select a domain when pressing Ctrl+Alt+Del to log on. In Vista, however, this drop-down list of domains is gone and there’s no way to get it back. That means you must type in either domainname\username or a UPN name (for example, username@domainname.com) in order to log on to a specific domain. There’s no workaround — unless you want to write your own credential provider.

SIX: Launch Internet Explorer using different credentials with Fast User Switching.
In XP, you could run Internet Explorer in a security context other than logged-on user by right-clicking on iexplore.exe in Windows Explorer and selecting RunAs. This was useful if your user account is a local administrator account and you want to run IE using ordinary-user credentials for greater security. In Vista, however, because of IE’s new Protected Mode, you can’t start IE using different credentials than your current logon account. The workaround is to use Fast User Switching (FUS) to log on to your system as a different user and run IE from there.

SEVEN: Use a third-party product to customize the default logon-screen background.
Prior to Vista, businesses that wanted to “brand” their default logon-screen backgrounds could do so by modifying the HKEY_USERS\.Default\Control Panel\Desktop\Wallpaper registry key. This procedure has worked since Windows NT but doesn’t work in Vista. In fact, there’s no supported method for changing the background that is displayed before a user logs on to a Vista computer. A workaround is to use a third-party product, such as Stardock LogonStudio, but be aware that Microsoft doesn’t support this approach.

Eight: Make subfolders automatically available offline.
In XP, when you made a folder available for offline use and it contained subfolders, you were asked if you wanted to make the subfolders available offline as well. This prompt is gone in Vista; subfolders are now automatically made available offline when you make the parent folder available offline. This change could have a significant downside if a subfolder has gigabytes of data stored in it. In Vista, fortunately, the Music, Pictures and Videos folders are peers of the Documents folder (unlike XP, in which they are subfolders of My Documents).

NINE: Replace logon scripts with Group Policy Preferences.
Many logon scripts that worked with previous versions of Windows may not work properly with Vista. In particular, scripts that do things such as change network settings or write to the registry will display a User Account Control consent prompt when the user logs on, even if the user is a local administrator on the computer. The way to fix this is to ditch your logon scripts and use Group Policy Preferences to perform these tasks on your client computers.

TEN: Remember to change any scripts for automating Terminal Services.
Terminal Services administrators who are used to the /console switch need to be aware that this switch is now gone and has been replaced with /admin. This may require changing any scripts you have that use /console to automate Terminal Services administration.