User Profile Wizard 3.0 RC1

We're nearly there... The User Profile Wizard 3.0 "Release Candidate" is now available for download here. We regard RC1 as extremely stable, and we do not foresee any major changes to the code between now and when the product is fully released. There have, for example, been no changes to the core profile migration code since BETA 2.

So what's changed? We have been doing a lot of testing in what might be called "sub prime" environments ;-) Not that we would ever suggest our customers would have such things! So, slow machines on slow connections; client machines that are under load - particularly on boot up. When we were only concerned with "pull" migrations this was not a problem: the client workstation could run the migration at its own pace. Doing a "push" migration, however, involves the "console"machine having to wait for the target workstation to respond to its requests. We've beefed up the code in RC1 to make this communication process more robust.

There have also been some minor enhancements to the functionality User Profile Wizard 3.0 provides. One of the things we get asked about a lot is removing user's Administrator rights when their workstations are migrated to a new domain. This is now really easy: you just need to set the new “RemoveAdmins” attribute in the profwiz.config file to "True".

The other new attribute in the profwiz.config file is "Exclude". This is just a comma-seperated list of user accounts that you don't want to be migrated to the new domain. By default the profwiz.config file lists

ASPNET,Administrator

but you can list any accounts that you want.

Last but definitely not least, the "Deployment Kit" has been completely rewritten for version 3.0. You can now use the Deployment Kit to create or edit a profwiz.config file, meaning you don't have to edit the profwiz.config by hand. What's more the migration scripts that the Deployment Kit now generates are much cleaner because the majority of settings are held in the config file.

So what's left to do? Mainly it's documentation. We still don't have a User Guide for version 3.0. Once that is completed we should be ready for the final release.

Vista Annoyances

I came across this article somewhat optimistically entitled "Vista Annoyances Resolved" It's worth reading because the author, Koroush Ghazi, does try to address some of the - er - quirks of the Vista experience.

The first "annoyance" he tackles is that of constantly changing folder views. This really struck a chord with me: why is it that when I open a folder full of c++ source and header files, Vista has suddenly decided to list them as music - complete with "Artist", "Genre" and "Rating" columns?

Ghazi goes on to discuss eight more annoyances, including User Account Control (for which I don't think there is a resolution), Bad Driver Support (which I don't think is the issue some would have us believe), and constant hard drive activity. The last is quite interesting. Ghazi highlights SuperFetch - the Vista "feature" that loads as much of your RAM as possible with stuff that you might need, so that it doesn't need to be fetched from your hard drive when you do need it. SuperFetch kicks in shortly after Vista boots, which unfortunately is also when you are trying to start Outlook, or whatever, and do some work. My solution to this is a simple one: never turn off your laptop. My Dell D630 now only ever sleeps.

There are problems Ghazi doesn't mention, however. As Paul Thurrott writes, "How about the weird folder/file deletion bugs where you somehow can't get the proper privileges to delete something even though you've navigated through all the required UAC prompts?" This is something I came across early on, and which has never been fixed. Still, at least people are classifying these issues now - the rest is up to Microsoft.

User Profile Wizard 3.0 Beta 2

User Profile Wizard 3.0 Beta 2 is the first "feature complete" release of the latest version of our domain migration tool. What beta 2 adds over the first beta release is the ability to rename things. With User Profile Wizard 3.0 you are able to rename workstations, users, and - for the first time - the user profile itself.

With User Profile Wizard 2.5 you rename user accounts and workstations using a script generated by the Deployment Kit. The way this works is that the script will use a "lookup" file to match a user's existing account name to their account name in the new domain. The lookup file is simply a plain comma-delimited text file. So, for example, if a user's current account name is jsmith and their account name in the new domain is jane.smith, there would be an entry in the lookup file like this:

jsmith,jane.smith

In exactly the same way, you can create a lookup file to change the current workstation name.

User Profile Wizard 3.0 takes the same approach. The difference is that you don't have to use scripting: renaming is built into the tool. All you have to do is tell User Profile Wizard where to look up the new user or workstation name. The way you do that is to put an entry in the .config file (click to view):


Similarly, there is a "machinelookupfile" entry in the .config file for specifying new workstation names. Note that the path to the lookup file is relative to profwiz.exe: if I'm migrating a remote machine from my workstation, "C:\Temp" is on my machine.

The other entries in the section of the .config file shown above relate to migrating machines remotely. "All" tells User Profile Wizard to try to migrate all the profiles on the remote machine. "OldDomain" tells User Profile Wizard which profiles to migrate. If you don't specify an "OldDomain" value, User Profile Wizard will look for local user account profiles, otherwise it will look for profiles of accounts in the domain you specify.

One option that customers have consistently asked for is the ability to rename the profile folder itself. This is the folder that is under C:\Documents and Settings, if you are on XP, or C:\Users if you are on Vista. Up to now User Profile Wizard has not allowed you to rename this folder. This has been quite deliberate on our part. Our aim is always to minimize disruption to the end user - not least because disruption=cost. Some lagacy applications use hard-coded paths to the user's profile, so changing the profile path can break those applications. However, there can be good reasons to change the profile folder name. One argument we have heard quite a lot, is that a Tech coming to look at a user's machine at some point in the future will be looking for the profile folder name to match the user's name - and it could be confusing if it doesn't.

User Profile Wizard 3.0 will now rename the profile folder for you if you want it to. All you have to do is set the "RenameProfileFolder" value in the .config file to "True". Just make sure you test it before you migrate everybody :-)

Introducing User Profile Wizard 3.0 - Part III

Running additional programs as an Administrator

One of the options that was introduced with User Profile Wizard 2.5 was to be able to run a "follow-on" file - a script or an .exe - in the security context of the local administrator account specified by the /LOCALADMIN command line parameter. This has proved very useful for customers who need to carry out additional tasks using admin permissions. With User Profile Wizard 3.0 we have beefed up this functionality.

To be honest, we didn't have much choice. Because 3.0 supports "push" migrations to remote machines, we had to find a way of running any script or executable someone specifies remotely on that machine. Not only that, but we had to make sure Vista's UAC (User Account Control) technology didn't get in the way. The result is that User Profile Wizard 3.0 can run an application interactively on a user's desktop without the user being prompted to "elevate" the process.

To show how this works, lets try and run something that requires Administrator permissions: Vista's Windows Firewall Settings. Normally, of course, you would never want to do this as part of your migration! However, it is as good an example as any. If you run FirewallSettings.exe (and you are not the administrator) you will see this:


Or, if you are not an administrator at all, this:


If we are running an additional process as part of a workstation migration we definitely do not want the user to be bothered these UAC prompts.

To get User Profile Wizard 3.0 to run a follow-on file we need to give it some information: the Administrator credentials with an encrypted password, the path of the file we want to run, and a security hash of the file to guarantee that only that file gets run - unchanged - and no other file. Details on how to create the hash are in the User Guide. We just need to add this information to the profwiz.config file:


Note that in this example these are the only settings that are required: we don't have to migrate a profile or join a domain to get profwiz.exe to run the executable for us - although normally we would be running a follow-on file as part of a migration process. In fact, to stop profwiz trying to join the machine to a domain we set the "NoJoin" parameter here to "True."

The other parameter to note is the "NoGUI" parameter under "Advanced Settings." Generally, if you just type "Profwiz.exe" at the command line, User Profile Wizard will start up in GUI mode. Here we don't want that to happen: we want profwiz to just process the config file: "NoGUI" makes that happen. Now if you type "Profwiz.exe" at the command line, or even just double-click the Profwiz icon, what you get is "Windows Firewall Settings" - and no UAC prompts. You get this even if you are just a regular user with no administrator credentials at all: the credentials are in file.

Want to run the file on a remote machine? No problem...

profwiz /COMPUTER machinename

Of course, in this case FirewallSettings.exe is Vista-specific application, so machinename needs to be Vista machine, but generally this does not need to be the case.

The example here has been a little bit contrived because normally you wouldn't just want to run a file - you would want to migrate a machine. However, I hope that you can see the power that User Profile Wizard can give you over your workstations.


You can check out User Profile Wizard 3.0 for yourself here.

Introducing User Profile Wizard 3.0 - Part II

The profwiz.config file

User Profile Wizard is a very powerful desktop migration tool - and we have plans to make it even more powerful. However, the danger is that the more functionality you add to a tool the more difficult it gets to use. Say I want to my migrate my profile to my new domain account, join my workstation to the domain, and create the computer account in the "Workstations" OU. A typical command line would look like this:


Now, OK, if you are using the Deployment Kit to generate a migration script this complexity will be hidden from you. But if you are using User Profile Wizard to create your own migration process, or if you want to modify the script that the Deployment Kit created, simplifying the command line can only be a good thing.

If we look at the command line above, we can see that most of the parameters will stay the same for every machine that we migrate. The domain name, the administrator credentials, the log file, and in all likelihood the OU as well, will be the same each time. Only the user account details will change. User Profile Wizard 3.0 allows you to save the parameters that stay the same in its profwiz.config file so you don't have to enter them on the command line.

profwiz.config is a standard xml file. You can edit it in notepad or any xml editor of your choice. The job of profwiz.config is to provide default parameters for User Profile Wizard to use. Here's a profwiz.config file to provide the parameters needed for the migration above (click to enlarge):


Now the command line to migrate the profile and join the machine to the domain is just:

profwiz /ACCOUNT David /LOCALACCOUNT David

which has got to be easier! Of course, User Profile Wizard 3.0 can migrate machines remotely, so we could use:

profwiz /COMPUTER computer /ACCOUNT domain_account /LOCALACCOUNT accountname

for each computer we want to migrate.

One of the cool things about the profwiz.config file is that it is read by User Profile Wizard when it is running in GUI mode as well as when it is running from the command line. This means that you can pre-populate the fields in the Wizard with the settings you need, like the domain name and the options for disabling the local account or setting the default logon, etc. For the first time, you can add machines to a specific OU using the GUI by specifying the AdsPath in the profwiz.config file. This goes for the free version of the Wizard too. With the Corporate Edition you can even specify the administrator credentials so that the Wizard won't prompt you. It's all about making your migration easier.

You can check out User Profile Wizard 3.0 for yourself here.

Introducing User Profile Wizard 3.0

Push Migrations
So what's new with User Profile Wizard 3.0? The big change is that User Profile Wizard 3.0 enables you to do "push" migrations. What's a push migration? A push migration is where you can send (or "push") the instructions needed to migrate a machine - say from one domain to another - from another machine. In other words, you can migrate the workstations on your network from your desktop.

Up to now User Profile Wizard has only supported "pull" migrations. Typically this means that when a user logs on to their machine, they pull down a script from the network which migrates their machine. This methodology has proved to be extremely effective over hundreds of thousands of migrations, and will probably remain the dominant means of migrating workstations - especially for large scale migrations. In some organizations however, a push migration may be felt to be more appropriate: if that is the case, User Profile Wizard 3.0 can certainly help.

Under the surface there have been some major architectural changes to User Profile Wizard 3.0 to allow for push migrations. We've kept the familiar Windows Wizard interface for User Profile Wizard 3.0 the same, however. What you do get is a new option:

When you click next, the Wizard will attempt to connect to the remote machine, prompting you for a username and password as required. If the remote machine is already joined to a domain this should be fairly painless. If however the remote machine happens to be a Vista workstation in a workgroup you may have to do some configuration before you start: workgroup Vista machines allow only the local Administrator account to access the machine remotely - an account that is disabled by default!


Once you have specified the domain and username of the account you want to use an existing user profile, the Wizard will show you a list of the profiles - profiles that are on the remote machine, of course.


To migrate a profile you simply need to select it and click next. If the Wizard needs to join the remote machine to a new domain you will be prompted whether you want to restart the machine now. If you say "Yes" the remote machine will reboot in two minutes: anyone logged onto the machine will get a warning, but will not be able to prevent the reboot.



Console Support

Being able to just connect to another machine on the network and migrate it using the GUI on your desktop is pretty cool, but what if you don't want to have to use the GUI every time? Can you do push migrations using the command line and maybe script the whole process? Well of course you can! User Profile Wizard 3.0 has the additional command line parameter /COMPUTER to allow you to specify the remote computer you want to target.


The screenshot above also shows another new feature of User Profile Wizard 3.0: console support. The Wizard is a Windows application, but it can now also run fully in a console window - if that's the way you want to work.

With User Profile Wizard 3.0 we've worked hard to maintain the consistency and reliability of User Profile Wizard 2.5 while adding new features to make administering workstation migrations easier - especially when it come to Windows Vista.

You can check out User Profile Wizard 3.0 for yourself here.

Joining a Samba Domain

Generally there is not much crossover between this blog and my Journey into Linux. However, if you are interested in what a Windows workstation gets up to when it joins a domain, you might what to check this post.

User Account Control

If you're running Vista and you are logged on with an Administrator account (but not the Administrator account) and you double click on the Personal Edition of User Profile Wizard, Vista will darken ominously and throw up the following User Account Control prompt:














Whaddaya mean IF you started this program? You mean you don't know? Your supposed to be a ten billion dollar Operating System for crying out loud!

Now let me say right away that User Account Control (UAC) is a good thing. I'm as guilty as the next Tech of running with permanent Administrator permissions, so the additional level of security that UAC provides is only to be welcomed. However, I'm not convinced by the way Vista implements it.

If you are not logged on with an Administrator account, UAC makes more sense. When you run an application that requires Administrator credentials, you are prompted to enter those credentials.



If you are logged on with the Administrator account, then you are not prompted at all. The same goes if you are logged on with the Domain Administrator account - although again, not just any Domain Admin account, which makes me think that UAC might just be looking for the Administrator RID in the user SID. (In other words, a SID that ends in 500.)

If you are logged on with a different Administrator account UAC makes a lot less sense. Take what happens when you right-click on a program or shortcut and select "Run as Administrator." What happens is that you get the exact same If you started this program, continue message. This is crazy. If the purpose of UAC is notify you when you need elevated permissions, why prompt you for what you've just explicitly requested?

Deleting files from a folder where you "only" have access via membership of the Administrators group is a real mess. Once you hit the delete key you get the normal confirmation "Are you sure you want to move these items to the recycle bin?" dialog box. Click Yes, and you are presented with a "Destination Folder Access Denied" dialog box asking you to confirm the operation. When you click "Continue" UAC kicks in, the screen darkens, and you see the UAC dialog saying "Windows needs your permission to continue." Click "Continue" again, and you get the "Are you sure you want to move these items to the recycle bin?" dialog box AGAIN. I defy anyone to tell me that this is a well thought out software design.

On OS X things are, as ever, slightly different. For example, changing the Mac's power saving options requires Admin permissions. Even if you are logged in with an Admin account, you still have to go through a second level of authentication to make the changes: first by clicking on the padlock:

Then by re-entering your credentials:


Is this a better solution? I'm not sure, but it does seem less disruptive than pausing the entire desktop.

Odd as it may seem, given that Vista took five years to develop, it is difficult not to conclude that UAC hasn't had enough development time. Anyone who tested the different Vista Betas will know that UAC went through many changes: Vista's release may well have just come too early for UAC to be the finished article.

However, we've got the UAC we've got, so we have to get on with it. As developers of administrative utilities it does provide us with a challenge. Vista allows developers to mark their applications (via the application manifest) with one of three execution levels:

• asInvoker - The application runs with the same token as the parent process. (No UAC prompt.)
• highestAvailable -The application runs with the highest privileges the current user can obtain. (No UAC prompt.)
• requireAdministrator - The application runs only for administrators and requires that the application be launched with the full token of an administrator. (UAC prompt.)

One of the features of the Corporate Edition of the Wizard is that you can provide the name of local administrator account and an encrypted password on the command line so that the Wizard can be started from the security context of a standard user account; for example, from a user's logon script. Marking User Profile Wizard with "requireAdministrator" won't work. If we did that, when the Wizard was called from the user's logon script they would be prompted to enter Administrator credentials. Not good. So we have to mark User Profile Wizard to run with the "asInvoker" execution level. This is fine, but it does mean that we have to handle the situation where the Wizard is run in GUI mode or where no Administrator credentials are passed on the command line. Generally, we just throw up a warning:

However, where User Profile Wizard is installed from the setup program, we can do something else. If you right-click an executable on Vista, choose Properties, and then click on the "Compatibility" tab, you have the option of setting the privilege level to run as Administrator. If you check the box, Vista writes the file path to the HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers registry key with the value "RUNASADMIN." This is what the User Profile Wizard Corporate Edition Installer does. It means that when you start the Wizard from the Start menu, Vista runs it with elevated privileges.

So every thing's fine, right? Er... no. Let's rewind to where we wanted to run User Profile Wizard using the Administrator credentials on the command line. If we just use any Administrator account, what's going to happen? Well, we're going to see the UAC prompt at the top of this post all over again.

Under the covers, User Profile Wizard uses the CreateProcessWithLogonW Windows API function, which in turn relies on the "Secondary Logon" Service. CreateProcessWithLogonW requires that you specify a valid username and password, so - again - why the UAC prompt?

My guess is that it will be a while before any of our customers will be doing a major domain migration of Vista workstations. However, for the record, to avoid the UAC prompt when running User Profile Wizard from the command line on Windows Vista, you have a number of options. Firstly, you can specify the actual local Administrator account. Secondly, you can run the Wizard from a management application like SMS, Marimba, or ZENworks. Thirdly, if the machine is already joined to a domain, you can run User Profile Wizard from a script via a Group Policy. Finally, there is a fourth option: but I'll keep that for another post.

Wow! Is Vista really a $10bn Sedan?

So, what do you think of Vista? The reviews of Vista I've seen usually start with how good it looks - which is understandable. It does look good - especially if you can run the Aero desktop and you get the glass title bars and Flip 3D.

Ok, Flip 3D is a bit of a gimmick. But it does put the "Wow" in The "Wow" starts now and shows up in just about all of Microsoft's marketing. For anyone who doesn't know, Flip 3D is the updated task switcher - what you get when you hit alt+tab. (To get the 3D version you winkey + tab instead.) That's right... the task switcher.

Flip 3D gives a glimpse of what a 3D User Interface might look like. Don't be fooled by the marketing though: Vista is not it. What's more, there no indication that Microsoft are pursuing any such radical redevelopment of the Windows User Interface. It wasn't always that way. Flip 3D is the impoverished descendant of an illustrious ancestor: the Microsoft Research TaskGallery project. The ghost of TaskGallery still haunts their website here. Anyone interested should read this article on The Register website dated 22nd January 2001 entitled Windows to go 3D… but not in Whistler. (Whistler was the codename for XP if, like me, you're hazy on Windows code names.)

The User Interface on Windows, on OS X, on Linux, on Solaris, is defined by the same desktop model that was developed by Xerox at PARC 30 years ago. Why is that? Familiarity, certainly, but you would think someone somewhere would take the desktop model on. Aren't there hundreds of millions of people around the world just as familiar with the 3D "User Interface" of the first-person shooter? User Interface development isn't simply about making computers easier and more intuitive to use. The User Interface defines not just how you do things, but what you can do.

Vista is far less radical than, say, Windows 95 was when it was launched. It might be hard to believe now, but Windows 95 was genuinely innovative; it brought 32bit computing and preemptive multitasking into the mainstream, allowing you to run multiple applications at the same time. Admittedly it took a while for processor speeds and memory sizes to reach a level where running multiple applications was easy, but the possibility was there in the Operating System. Windows 95 changed what you could do with a Personal Computer.

Perhaps we've reached the point where Operating Systems have become like cars: each new model does the same basic job that the previous model did, except just a bit more efficiently. Here in the UK, the car maker Audi is showing a TV ad which ends with the line, "To date, NASA have filed 6,509 patents. To get to the A6, Audi have filed 9,621 patents." And? They've built a car. It does the things cars do: start, stop, get stuck in traffic, that kind of stuff. If we have reached the point where Operating Systems have become like cars, it isn't because there's no other choice.

At the UK business launch of Vista, Microsoft's UK managing director Gordon Frazer said Vista cost $10bn to develop. Let me just spell that out for you: 10,000,000,000 dollars. Now if I gave you $10bn (and the source code for XP) and told you to go away and design an Operating System, is Vista what you would come back with? If you start Vista and go to the "Welcome Centre" and then click on "What's new in Windows Vista" what is it that Microsoft themselves want to tell us? The top three are Search from within folders. Organize files in new ways. Keep devices in sync. Is that what they mean by Wow?

There's probably a serious point to be made about competition here - or the lack of it. It's not that (near) monopoly suppliers don't invest in developing their products; it is more that they don't know what to invest in. AMD and Intel are a good example. If it wasn't for AMD we wouldn't have multi-core 64bit processors on the desktop, and Intel would be spending even more millions still trying to perfect Itanium, the processor no one wants. With Linux suppliers desperately trying to make the Linux desktop look as much like Windows as possible (otherwise, the argument goes, no one will switch - when the opposite is more likely to be true - there's no reason to switch) there is little competition to drive innovation.

This is not to say that Vista is a bad operating system - far from it. Vista is a seriously good operating system. It's just that it is a deeply conservative, risk adverse, play-it-safe operating system. Vista doesn't change anything.

One of the things both users and developers have to get used to in Vista is User Account Control (UAC). Next time I'll go into the changes we're making in User Profile Wizard to handle it.