A look at the changes programmers need to make for compatibility with Vista’s UAC.

Vista’s User Account Control (UAC) may seem like a strange topic for a programming column, but Microsoft designed this feature with programmers in mind.

The idea is to force them to build applications that work properly when users are not running with full administrative rights.

Presuming the strategy works, some future version of Windows will be even more locked-down by default. Windows guru Mark Russinovich, who now works for Microsoft, explained this in detail on his blog .

He said: “Windows Vista introduced elevations and Integrity Levels (ILs), even though there is no guarantee your elevated processes aren’t susceptible to compromise by those running at a lower IL: [Microsoft wants] to get us to a world where everyone runs as a standard user by default and all software is written with that assumption.

“Without the convenience of elevations, most of us would continue to run the way we have on previous versions of Windows – with administrative rights all the time.”

The essence of User Account Control is that all users run as standard users, with read-only access to system locations such as the Windows directory, Program Files, and the Hkey_Local_ Machine section of the registry. This applies even if you are running as a local administrator.

On occasions when you need real administrative rights, Vista raises a dialogue on a separate desktop inviting you to allow or cancel the action. This is called elevation. However, once it is approved, the elevated process runs on the same desktop as the standard user.

The obvious danger is that malware running with standard user rights may be able to trick the elevated process into running malicious code. To prevent this, Vista places restrictions on the extent to which non-elevated processes can communicate with elevated processes.

The degree of elevation is called the integrity level, and Vista actually supports four of these: Low is used for Internet Explorer’s protected mode; Medium for normal running; High for administrative tasks; and System. Processes running at a higher integrity level are protected to some degree from lower level processes, but Microsoft admits to some compromises.

Another feature of UAC is called virtualisation. This is designed to support applications that attempt to write to system locations. When virtualisation is enabled, which it is by default, the write appears to succeed, but the data is not really written to the system location. Instead, it goes to the virtual store, which is hidden in the user’s home folder. By default, this is at C:\Users\yourname\AppData\Local\VirtualStore.

If all your applications are behaving well, this will be empty. Most likely it is not: mine includes folders from Adobe, Borland, Creative, Open Office and Microsoft. The virtual store is ugly. Files written there appear to be in a system location, but only when you run as the user who created them. In addition, elevated processes cannot see the virtual store. There is plenty of potential here for bugs and other unexpected behaviour. The registry also has a virtual area that works in the same way for disallowed registry access.

As Russinovich explains, Microsoft created this elaborate system with one eye on security and the other on compatibility.

The aim is to make it feasible to run old applications that require administrative rights, but sufficiently awkward that developers will stop writing applications that need such rights.

This is not just about shrink-wrap software, but also the custom applications on which many businesses rely.

Should you just disable UAC? This is an option, but it does compromise security. You lose features such as Internet Explorer’s protected mode as well as the elevation dialogue. Furthermore, even if you do disable UAC, it is unreasonable to expect this of other users of your application.

UAC has received a bad press in some quarters for displaying too many dialogues, but the problems are exaggerated. Once a machine is set up, elevation dialogues are infrequent, and they will reduce further still as application compatibility improves.

How to use a UAC manifest

An annoying aspect of UAC is that much of it is automatic. At times this gets silly. For example, Microsoft decided that any application with the word ‘setup’, ‘install’ or ‘update’ anywhere in the name should run with administrative rights. It is easy to call a harmless utility UpdateSpreadsheet or something, and then wonder why it is displaying a UAC prompt.

The solution is to make your utility UAC aware, by embedding a manifest. You can use this either to prevent or require elevation for your application.

To embed a manifest in Visual Basic 2005, first create a text file. You can use Visual Studio for this. The key setting is the line:

<ms_asmv2:requestedExecutionLevel

level=’asInvoker’ uiAccess=’false’/>

Change the value of the level attribute to ‘requireAdministrator’ if you need to enforce elevation. Save the file as UpdateSpreadsheet.manifest, for example.

Now you have to embed the manifest in your application. To do this you need the mt.exe tool, which is part of the Windows SDK, a free download. If you have the full version of Visual Studio, mt.exe is installed with it. To use it, open a Visual Studio 2005 command prompt, or any command prompt with mt.exe on the path. Navigate to the folder where your manifest is saved and run the following command:

mt -manifest UpdateSpreadsheet.manifest - outputresource:bin\Debug\UpdateSpreadsheet.exe;#1

Substitute the path to the application for the output resource. The result is no UAC prompt because asInvoker was specified. The virtual store is also disabled for this application. If you have the full Visual Studio 2005, you can add the manifest in an automatic post-build step – see Project Properties, Compile, Build events.

Setup hassles

Once you have created your application, you might want to build a setup for it using a Visual Studio Setup project.

You can create one automatically using the setup wizard in Visual Studio 2005. This builds a setup file using the Windows Installer technology. On the surface this seems a handy tool, but dangers lurk.

The Installer API is among the most arcane and complex in Windows. Everything is fine if you just want to use a single executable, but once you start adding extra files or customising the installation process, there are many potential pitfalls.

One of the Microsoft installer team members wrote a document called the Tao of the Windows Installer. It contains no less than 69 rules you should observe to create a well-behaved setup. It is true that many of these are not relevant to a simple, non-corporate install, but even trivial tasks can trip you up, especially when combined with UAC.

For example, the Windows installer is designed as a database, the idea being that concepts such as commit and rollback are useful when installing applications. One problem is that many setup routines require procedural logic to accommodate user preferences, or different scenarios such as versions of Windows and upgrades versus new installations.

Procedural logic is an uncomfortable fit with the database model. The installer gets round this by allowing for ‘custom actions’, which are scripts or executables you can fire during the install. Even Visual Studio setup projects allow for these, in the Custom Actions editor.

Now imagine your custom action has to copy some files to Program Files, or make other system changes. Even on Vista, setup routines almost always run with administrative rights, so you would think this would be fine, but this is not so. Custom Actions can be of two types – deferred or immediate.

For various reasons, deferred Custom Actions are generally more useful, so Visual Studio creates these by default. However, they are executed using a feature called impersonation, which means that even though the setup has full rights, the Custom Action has only the standard rights of the current user; they are not elevated.

You can overcome this by changing the type of the Custom Action to switch impersonation off, but you cannot do this within Visual Studio. You have to use a clunky tool called Orca, which is a database editor for Microsoft Installer (msi) files, or else use a different setup tool.

Even then there are problems. When you switch off impersonation, the Custom Action runs as System. This means it probably has limited network access. If your users run the setup from a network drive, it may fail.

Also, Custom Actions can be DLLs or executables. It is tempting to make them executables, so they have their own user interface. However, this is not usually a good idea. If your Custom Action displays a dialogue, it may well appear behind the Installer window. Your users will probably think the setup has hung. The solution is to make the Custom Action a DLL, and call functions in the Installer API to display messages and dialogues.

Visual Studio setup projects are not for the faint-hearted. It is best to use other options, such as one-click install, which is the Publish option on the Visual Studio Build menu. Windows Installer is unavoidable in some scenarios, as many Windows management tools assume its use. PCW

Title: Hands on: Vista’s User Account Control
Author: Tim Anderson
Date: 4 Jun 2007
Source: IT Week

Microsoft has made some drastic changes in Windows Vista’s support for personalization. How will this affect your move to Vista? Learn how you can mitigate the impact with built-in and add-on tools.

A computer is actually a highly personal device. As users, we take the time to personalize our desktop backgrounds, screen savers, shortcut placements, etc. to suit our tastes and sometimes even our daily moods. (And many workers will agree that nothing is more frustrating than working with a computer you can’t personalize because everything is locked.)

All of this comes to a head when you move to a new operating system. Protecting a computer profile or personality — data, favorites, desktop settings, application customizations, and more — is probably the most important aspect of any OS deployment project. Anyone who has spent time installing and configuring a new computer will know just how long it takes to get everything just right. This is why personality protection is so important to end users during the migration. So how do you minimize the amount of work required to move to a new OS and, at the same time, maintain all of the hard work users put in to customizing their systems?

There are actually three steps involved. First, you need to decide what to protect or what you will capture before the migration — and what you will restore after the migration. Next, you should look at the differences between Windows XP and Windows Vista in terms of how they manage the content that makes up a computer personality. Finally, you need to determine just how you’ll protect your users’ data and profiles.

1. Decide What to Protect
Windows stores personality settings inside the user profile . Each time a user logs on to a system for the first time — whether in a corporate network through a domain, relying on an Active Directory authentication, or relying on the local security accounts manager database that can be found on every Windows system — Windows generates a profile which is derived from the default profile found on each Windows system. The default profile contains standard settings for user document locations, a standard desktop background, a standard screen saver, and so on.

You can, of course, update and otherwise customize the default user profile so that each user gets a customized environment at first logon. Many organizations take the time to do this so that each user has a standard corporate environment when they use the organization’s computers. You can store this custom default profile in one of two places: within the system image you deploy on each PC or centrally on a domain controller — the server that provides authentication services — so that each time a user logs onto a system for the first time, they will be faced with a common and standard user experience.

But when you move to a new OS, you won’t want to maintain each profile in the network. That’s because some profiles are volatile while others are permanent. For example, when you need to repair a PC and you log on with your credentials, Windows will automatically generate a new profile for you. This profile doesn’t contain any information you need to preserve because, once the computer is fixed, you won’t need to log back onto it.

Network Profile Analysis
That’s why you need to perform a network profile analysis before any system migration. This will help you determine just what you need to protect on each PC. After all, the only profiles you need to protect are those that are in use by users and that actually contain data.

In addition, you’ll want to make sure you only protect valid information from within the profile. For example, your organization won’t want to use network bandwidth and central storage to protect a user’s music downloads, but you will want to make sure you protect a user’s documents and application settings.

On more note: Profiles contain application settings. If you choose to upgrade and perhaps even retire some applications during your migration, you’ll want to capture only those settings you’ve decided to carry forward when you perform the profile protection.

Here are some steps that can help determine which profiles to protect and prepare for migration:

• Protect only profiles that belong to end users.
• Protect only profiles that are in use. If a profile hasn’t been used for six months, then chances are it is not current and doesn’t need protection.
• Ask users to clean up their profiles as much as possible before your migration. This will reduce profile sizes and require less central storage space.
• Work with your application preparation team during the migration to identify which applications will be carried forward and include their settings when you capture user profile information. Discard everything else.
• Move profiles to a network share when you capture them and then back them up.
• Make a list of all of the document types you have decided to protect, then communicate this list to your end users.
• Provide support for users to perform their own backups of anything you will not protect.
• Be as clear as possible when you communicate your protection plan to users to make sure there are no mistakes, and then, if you can afford it, take a backup copy of their entire disk drive before the migration. This way, you’ll have a back out plan if users claim they are missing critical data once the migration is complete.

There are of course, other considerations, but these guidelines should form the main crux of your personality protection policy. 2. From XP To Vista: Profile Structures
There are several differences between the profiles structures in Windows XP and Windows Vista.

First, there is location. In Windows NT, profiles were stored in the WINNT folder, which allowed users read and write privileges. With Windows 2000 and Windows XP, profiles were moved to the Documents and Settings folder structure. With Vista, this has been changed to become the Users folder structure.

The name and makeup of folder structures have changed from NT’s Profiles to XP’s Documents and Settings to Vista’s Users. (Click image to enlarge.)

In addition, the entire structure of Vista’s profile folders has been modified by Microsoft. Because of this new structure, XP user profiles are not compatible with Vista user profiles. To move information from one another, you need to convert the information to Vista’s new format.

Before moving a profile, you need to link the XP and the Vista profile structures. (Click image to enlarge.)

3. Moving Profiles
Now that you’ve decided what to protect and you know how Vista changes will affect this protection, you can determine how you’re going to protect user content during your migration. You could always build your own tool through a combination of scripts and batch files, but there are a lot of profile migration tools on the market, so why bother?

For example, Microsoft offers the free User State Migration Tool (USMT). The USMT is a command-line tool that relies on XML language structure to determine its operation. It lets you capture profiles from one location and restore them in another. In addition, the USMT lets you scan computers to determine which profiles exist and which you should protect. Migration Tools
Several commercial vendors also offer migration tools. Altiris, for example, offers several migration tools (such as Altiris Deployment Solution ) that not only migrate profiles but migrate the entire OS, applications as well as the profile in one smooth operation. And, everything can be automated in a few steps through the use of a wizard in a graphical user interface. The capture or restore job is packaged as an executable that can be delivered and operated in the background by the deployment tool itself.

The same goes for tools such as the Symantec Ghost Solution Suite and LANDesk Management Suite . This makes profile captures much easier and simpler to automate. In addition, it solves the issue of having to run the profile protection process under administrative privileges because that is part and parcel of the deployment tool itself.

Whichever tool you use, make sure it includes the following capabilities:

• Inventory profiles without capturing them to support profile analysis.
• Capture any profile, local or domain-based.
• Capture single or multiple profiles.
• Restore single or multiple profiles.
• Analyze profile usage to help identify obsolete profiles.
• Filter out unwanted profiles from the capture.
• Filter out unwanted profiles from the restore, letting you capture profiles for backup and restore only selected profiles to target machines.
• Filter out unwanted files and folders from the profile capture.
• Store profiles in a variety of locations: local hard disk, network drive, burn it to CD or DVD as required.
• Restore profile settings to appropriate locations for Windows Vista.
• Support either x86 or x64 systems in both captures and restores.
• Capture custom folders, for example, a C:\LocalData folder for information not stored into the default My Documents folder.
• Capture legacy application settings that may be stored in the program’s directory instead of proper locations and restore them to proper locations in Vista.
• Scour the local hard disk for data and documents that have not been stored in appropriate locations.
• Support automation for the capture and restore processes.
• Support the generation of automated executables or scripts for execution in disconnected environments.
• Include encrypted administrative credentials or support the ability to run in protected user mode.
• Integrate with an automated OS deployment tool to provide an end to end deployment process.
• Provide reports on profiles to capture in support of workload estimates.

Using a tool that provides these features will ensure your profile migration works as you expect each time you need to use it.

Take the utmost care when moving computer personalities from one OS to the other. Every migration can be deemed a success only if the end users — the people who will work with the systems you migrate — are completely satisfied and find themselves on familiar ground once you’ve done your work. The way you handle personality migrations can make or break your migration project. Don’t compromise. Get it right the first time.

Title: Windows Vista How-To: Moving User Profiles To Vista Systems
Author: Danielle Ruest, Nelson Ruest
Date: 5 Jun 2007
Source: Information Week

I post this in the hopes that it will help prevent someone else’s pain. And because the search engines (live and google) never did give me any of these answers – they are totally clogged up with content from pre-release versions of Vista and with sites trying to sell or review mobile devices…

My wife has an HP 4150 – a wonderful little PDA. And a while back I put Vista on her laptop. Yesterday she tried to get it to sync, but Vista wouldn’t recognize the device. So she asked me for help, and there begins my tale of woe.

She was right, Vista would see the device through Explorer, so you could copy files back and forth, but the Windows Mobile Device Center (WMDC) wouldn’t see it at all.

After much time googling (see above) I gave up and went directly to the WMDC site – their home page never did show up in google (or live.com)… They say clearly that Windows Mobile 2003 is supported, and the HP 4150 clearly runs WM2003.

So now I’m perplexed. What could be wrong? Ahh! Perhaps there’s an update to the device from HP.

Go to hp.com and sure enough, there’s a ROM upgrade, which I downloaded.

By this point it was a little late, and I was a little frustrated that something so simple and obvious could be so hard. And the Microsoft page made no mention of any difficulties or challenges. No help with troubleshooting – or even any indication that troubleshooting would be required.

So I ran the ROM upgrade utility. On the Vista box. Stupid me. It started, and then failed. Leaving the IPAQ in a totally locked state. As long as the battery was in the device (I took the batter out a few times trying to reset things), the device was on a white logo screen showing a couple numbers (which I assume are hardware revision numbers or something).

At this point I appear to have a battery-powered paperweight, where once I had a PDA. Damn!

That was last night. Fortunately I have some awesome colleagues, and a couple of them replied to my email rant (I wasn’t happy).

Overnight I had left the battery out of the device. It apparently takes a few hours for some capacitors to discharge, and so at a colleague’s suggestion I put the battery back in this morning. Much to my relief the device rebooted with factory settings. Whew!

Then, following the suggestion from a Microsoft colleague, I ran the ROM upgrade from an XP machine. While the ROM upgrade utility will try to run on Vista, it won’t succeed – bad HP for not including an OS version check in such a critical utility!! One simple check like that would have saved me substantial trouble!

The upgrade works great from XP. Which is a lesson: if you decide to upgrade to Vista, make sure to keep at least one XP machine around for the next year or so, until these issues get ironed out. (A corollary to this is that if you only have one machine, you probably won’t want to go to Vista…)

It turns out however, that the ROM upgrade didn’t fix the sync issue. This is because Vista didn’t ship with the release version of WMDC. To get the release version of WMDC 6, you need to go to http://www.microsoft.com/windowsmobile/devicecenter.mspx and download the current version.

In theory I guess Windows Update is supposed to update WMDC for you, but in my experience that’s not true. I had to do force the upgrade manually.

Also, I still don’t know how to find out the version of WMDC you have installed on a machine. So I guess you could argue that everyone should go run that update just in case.

So let me recap. I did the following:

• Tried to sync a WM2003 device with Vista (a supported activity, with no indication that there are issues from Microsoft’s web site) – this failed
• Tried to do a ROM upgrade of the HP 4150 from Vista – this failed horribly
• Found out that the device would reboot after a few hours without power (thankfully!)
• Did the ROM upgrade from XP – successfully
• Manually upgraded WMDC on Vista
• Got the device to sync with Vista

Now my wife has a PDA again, which makes her happy. And that, of course, makes me happy.

Title: How to sync an HP IPAQ 4150 with Windows Vista
Author: Rockford Lhotka
Date: 29 May 2007
Source: Rockford Lhotka

Do you need to change your Windows Vista product key so that you can activate Windows Vista properly?

You can actually use an inbuilt command line tool to help you achieve this very easily. Simply go through the steps listed below:

1. Click on the Start button and key in Command Prompt so that it shows up on your Start Menu search list. Right click on the Command Prompt shortcut and select Run As Administrator.
2. In the Administrator Command Prompt, type in: slmgr.vbs -ipk (and hit Enter).
3. After changing the product key, type in: slmgr.vbs -ato (and hit Enter).