Developer's Blog

What's new in User Profile Wizard 3.5?

2011-05-11T12:39:00.025+01:00

A lot is the answer! Here are the headlines.

Migrating over a VPN
The ablity to migrate a computer to a new domain over a VPN has probably been our number one request from customers in recent years. If you have ever tried it, you will know that the problem is not so much with the migration itself, but what happens afterwards.

Most VPN connections are made by the user when they are logged on to Windows using software such as Cisco’s VPN client. When a machine is migrated to a new domain it needs to reboot: however, as soon as it reboots the VPN connection is lost. The problem is that after the machine reboots the user cannot logon again – there is no VPN connection to authenticate to the domain and Windows cannot cache the user's logon credentials (so they can logon offline) until the user does authenticate.

User Profile Wizard 3.5 fixes this by caching the user's credentials at the time of the migration. You can either have User Profile Wizard prompt the user for their password during the migration, or set a default password for all users. To enable credential caching you just set the 'vpn' value to 'True' in Profwiz.config. For more details - on this and the other features discussed here - please see the version 3.5 User Guide.

Security Permissions
There are two areas where User Profile Wizard 3.5 changes the way that we handle security permissions. The first is in the way the application is launched on Windows 7. As I described what seems a long time ago, Microsoft's implimentation of User Account Control (UAC) prompts the logged on user for permission to run a program even when that program has been started explicitly with Administrator credentials. Only if the program is started with the local Administrator account (which is disabled by default) or the domain Administrator account does the application run without the UAC "elevation" prompt.

In previous versions of User Profile Wizard we took the decision to force you to use one of the Administrator accounts or run your migration in a different way. In retrospect this was the wrong way to go. People running a migration with administrator credentials that worked fine on XP couldn't understand why they got "Access denied" when running on Windows 7. As a result, if you run User Profile Wizard 3.5 with Administrator credentials (but not the Adminstrator credentials) you will see the UAC prompt in the normal way.

Cue customers asking how to run User Profile Wizard without the prompt :-) The answer being, of course, to use one of the methods previously discussed.

The second change to the way user Profile Wizard handles security permissions in in relation to the user profile itself. By default User Profile Wizard sets security for the new user account at the top of the profile structure (C:\Users\Username on Windows 7, or C:\Documents and Settings\Username on XP) and leaves it to Windows to cascade the security changes through the profile folder structure via inheritance. With version 3.5 you now have another option.

Version 3.5 introduces the 'DeepScan' Profwiz.config value. If the DeepScan value is set to 1, User Profile Wizard will check every folder in the profile structure to see whether the security settings are inherited and, if not, set security on individual folders where inheritance is broken.

In deciding which level to choose, keep in mind that, by default, security on profile folders is inherited and that in most environments setting DeepScan to level 1 will have minimal practical effect. Checking the security on every folder also takes more time, of course. You should test in your own environment to decide which level is best for you.

There is another consequence of setting the DeepScan value to 1. A small number of customers have questioned why User Profile Wizard does not remove the old user account SID (Security IDentifier) from the ACLs (Access Control Lists) of files and folders in the user profile. The simple reason is that removing the old user permissions is principally cosmetic. If you are migrating from an existing domain, the original account loses access when the machine is joined to the new domain; if you are migrating from a local account, the account can be disabled or removed. Leaving the old permissions in place does not cause any security or functionality problems with the profile.

Setting DeepScan to 1, and checking the security on every folder in the profile, allows User Profile Wizard to remove ACL entries for the user’s old user account. This has the effect of cleaning up the permissions on the profile.

Copy Profiles
There is a mantra at ForensiT which we incant (almost) daily: User Profile Wizard does not move, copy or delete any data. Instead it configures the profile in place so that it can be used by the user’s new domain account. This makes the process both very fast and very safe... However, some folks just want to see a copy of the original profile for the new user account. The new 'CopyProfile' setting in Profwiz.config allows you to do just that.

We still believe that you should think carefully before setting the CopyProfile value to ‘True’. There is usually no need at all to create a copy of the original profile and by creating a copy you will make the migration process much slower.

However, there are circumstances where you may need to create copy profiles. For example, on shared workstations which are not already joined to a domain, users may all logon with one account. If you want to move the machine into Active Directory, you can create a copy of the profile for each user account so that each user can logon with their own username, but still retain their familiar desktop.

And more...
There are of course a number of smaller usability and functionality enhancements. These are based mainly on the feedback that we have had from our customers who, between them, have migrated hundreds of thousands of workstations using User Profile Wizard. Thank you to you all!

If you are a customer with maintenance and support, can download User Profile Wizard 3.5 using the link you recieved when you purchased the software.

Changing the Default Profile on Windows 7

2010-09-10T14:08:00.008+01:00

It has become increasingly obvious to us in recent months that people are downloading and installing our User Profile Manager software just in order to use the “Set As Default Profile” feature on Windows 7. Presumably they are then uninstalling the software again afterwards…

The problem is that Windows 7 has greyed out the “Copy To…” feature in the “User Profiles” dialog box that admins have used for years to set up a default profile for users logging onto a Windows workstation.

Why Microsoft have done this is not altogether clear. Responses on the Microsoft’s support forums say things like “There were many issues with it in the prior OSes, even though those issues were not always apparent…” (Mmm… the old invisible problem problem) and that this is “due to the User Account Control (UAC) and other security settings of the user account…” - which doesn’t really ring true either. I suspect that the problem is more to do with the profile folder structure and its reliance on junction points which cannot simply be copied over. But whether this is the case or not, why didn’t Microsoft just fix it? The most likely answer to that is that they just didn’t think it was important enough to spend any time on – which betrays a certain disconnect between Microsoft and those tasked with installing Windows on company machines around the globe.

However, installing User Profile Manager just to set the default profile is like going to a movie just to eat the popcorn. So what we’ve done is to take the "set default profile" code out of User Profile Manager and put it is a small command line utility – DefProf – that you can download for free.

How does it work?
DefProf does not simply delete the old “Default” profile folder and copy over a profile that you specify. Instead it keeps the existing Default profile in place and empties it; this preserves the folder structure with all junctions points and folder security settings. DefProf then copies over the files and settings from another profile that you specify. Additionally, DefProf loads the registry for the specified profile and cleans it up so that any user specific settings (that we know about) are removed.

It is worth emphasizing here that DefProf uses the existing folder structure. This means that if you have already messed up the Default user profile folder, DefProf won't fix it.

Using DefProf
Using DefProf is very easy. Firstly you setup a profile to the way you want just like you always do. Say you create a ‘Setup’ account to do this, and Windows creates a C:\Users\Setup profile folder when you logon. When you’re done making the profile look the way you want, you open a Command Prompt as an Administrator and just type the folder name:

c:\>Defprof setup

That’s it!

Feedback
We’ve done our testing, and DefProf seems to be working fine on Windows 7, 32 and 64-bit, and in a variety of languages. However, if you think we have missed anything please post a comment on the Forum and we'll do our best to fix it.

You can download DefProf here.

User Profile Wizard 3.0 RC1

2008-10-21T13:38:00.004+01:00

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

2008-08-26T12:00:00.005+01:00

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

2008-08-05T13:31:00.009+01:00

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

2008-06-20T10:38:00.000+01:00

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

2008-06-20T10:35:00.000+01:00

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

2008-06-20T10:30:00.001+01:00

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

2008-06-19T13:48:00.003+01:00

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

2007-02-16T14:24:00.000Z

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?

2007-01-24T14:01:00.001Z

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.

Fixing Temporary Profiles and User Profile Wizard 2.5

2006-11-02T16:36:00.000Z

One of the best things about User Profile Wizard is that it is extremely reliable. At ForensiT we spend quite a lot of time helping customers get their migration scripts right, but once everything is working it tends to stay working. There is however, one support question that keeps coming back to haunt us. What is even more frustrating is that it isn't even our problem.

A typical support call will begin like this:

I used your User Profile Wizard tool to migrate my workstations to a new domain a few months ago, and at the time everything went great. Recently, however, several users have tried to login to their workstations and they receive an error message stating that the profile is corrupt (or something) and Windows loads a temporary profile.

What the user seeing is this:

It's that phrase "corrupt local profile" that is really scary. (Users tend to skip over the "Possible causes of this error..." part, and just read that.) If the user then clicks "OK" they get this message:

The good news is that the profile is not corrupt. If we check the computer's Application Event Log we can see the following error:

In this case, salvation is in the DETAIL: "The process cannot access the file because it is being used by another process..." The file in question is ntuser.dat - the file that holds the registry part of the user's profile; which is to say, the data that you see under HKEY_CURRENT_USER if you run regedit when the user is logged on. So what's going on?

Here's the deal: Windows cannot load the same profile twice. Windows cannot load the profile here, because it is already loaded for someone else.

How could that be? One possibility is that the profile has already been loaded by a process, such as a Service, which uses the credentials of an account that shares the user profile of the user who is trying to log in. To get the screenshots above, I changed the configuration of the WMI Performance Adapter Service on a test machine so that it logged on with the local Administrator account:

I then ran User Profile Wizard so that my account would share the profile of the local Administrator account, and then I tried to logon...

We do sometimes see the "cannot load profile" error caused in this way - but not often. Usually the problem occurs because the user has logged on with, say, their local account, logged off and then logged on again with their domain account - which just happens to share the same profile as their local account. In theory this shouldn't be a problem: when the user logs off, Windows should unload their profile so that if they logon with a different account that uses the same profile it won't be "being used by another process." Often - usually - that's the case. Unfortuantely, it doesn't always work that way.

This is such a common problem that there is even a Microsoft Knowledge Base article on the subject. You can find it here: http://support.microsoft.com/default.aspx?scid=kb;en-us;837115

The article states:

This issue may occur if Microsoft Windows or third-party programs such as printer drivers or virus scanners do not stop and release resources when you log off your computer.

The fix given is to install the Microsoft User Profile Hive Cleanup Service (UPHClean) . Unfortuantely, although this works in many cases, some customers report that it does not. What's more, you shouldn't really need to install a new piece of software if all you want to do is migrate a user's workstation - and the user's profile - to a new domain.

So what to do? What we've done in User Profile Wizard 2.5 is simply to have the Wizard not share the profile (by default.) So, for example, say you have to migrate a machine from Novell NDS to Active Directory. You run User Profile Wizard to join the machine to the new domain and migrate the user's existing local account profile so that it can be used by their new domain account. By default, once User Profile Wizard 2.5 has completed the migration it will break the link between the original local user account and the original profile. When the user logs on with their new domain account, they get the profile they have always had. If however, they logon with their original local account Windows will create a new profile for the local account.

If you want to continue to share the profile, so that it is used by both accounts, you must check the "Share Profile" check box:

Running from the command line, you need to use the /NOREMOVE switch. Be aware, however, that some piece of software on the machine might cause you to get the temporary profile error.

User Profile Wizard is essentially a migration tool. If a profile needs to be used regularly by more than one user account, you should be looking at User Profile Manager. Windows cannot load the same profile twice, but User Profile Manager can.

That's it for this post. Next time I'll discuss some of the features of Vista, and the changes we've had to make to User Profile Wizard.