How to migrate your local user profile to the domain

Apparently, there is no easy way (this or this do NOT work), there use to be a tool to do this (Moveuser.exe), but it stopped working with Windows Vista.

The way to do it now is to write a VBScript that uses WMI, happily, I have found someone that has already done it here.

It basically seems to be using the ChangeOwner Method of the Win32_UserProfile Class, one problem I have found so far is that if the profile to be “moved” in to the domain is heavy (many Gbytes of weight) the ChangeOwner method can take a really long time to do its job. A possible solution then is to move the files outside of the profile dir, run the migration process, and copy the files back (you might need to change the permission information of those files to be able to copy them back)

How to move C:\Users to D:\Users

There is no user friendly way to move your C:\Users folder to D:\ but the user unfriendly way to do it is not too hard (it was a little hard to discover, I learned how to do this when I decided that I wanted to have C:\Winnt\Profiles dir at a different location, after I lost most of my data when my main disk failed, back when Windows NT 4.0 was the latest and greatest OS from Microsoft)

Basically, after you installed Windows (this instructions are for Windows 7 but the general approach is valid since Windows NT 4.0)  you have to:

1. Login with “WhatEverIsYourUserName” account.
2. Run the Command Prompt (cmd.exe) as an Administrator
3. 
4. Copy the C:\Users\ folder to D:\Users using Robocopy
   

   robocopy C:\Users D:\Users /E /COPYALL /R:0 /Z /XJ

   
   



5. Open regedit and modify the ProfileList entry so that it looks like this:

1. Create a new (Administrator) Windows account that you will use to test the configuration change
   
   
    



2. Restart



3. Login with the “Test” Windows account



4. Delete C:\Users



5. See that the  Start menu still works (if you made a mistake, your Start menu is now empty)



6. Delete the registry Key for your “WhatEverIsYourUserName” account (if you still want to use it). (The registry Key is the yellow folder with the S-1-5… name that contains the value ProfileImagePath that points your now obsolete C:\ folder, remember,  you have to delete the whole folder/key, not just the ProfileImagePath value):
   
   
    



7. Log out



8. Now log in with your “WhatEverIsYourUserName” account



9. If you take a look at the registry now, it will look like this (The value in ProfileImagePath now starts with “D:\” instead of “C:\”):
   
    



10. Now you can delete the test account.

And that is it, now the users accounts live in D:\Users\

Layer Separation Violation: Web Configuration Manager... one of ASP.NET 2.0 mistakes?

The management of configuration in .NET applications was improved in .NET 2.0, now it is easier to have custom configuration sections, and we even have pre-built configuration section for Connection Strings (very useful for ADO.NET applications)

But... there are some design decisions I just don't get... "Configuration" is a separate concern from presentation (configuration can be used to set UI behavior, but in my opinion, configuration is in a lower layer), but now we have the WebConfigurationManager for web applications and the ConfigurationManager for client applications ...

From MSDN website:

Using WebConfigurationManager is the preferred way to work with configuration files related to Web applications. For client applications, use the ConfigurationManager class.

First, I thought... "this is going to be a problem", now I won't be able to read configuration in the lower layers (business facade, business rules, data access) without having to use my own proprietary "trick" to hide the fact that for those layers it is irrelevant whether the application has a WebUI or a WinUI... how could the .Net team make such a bad decision?

But then I realized... that i can use the ConfigurationManager from an WebUI (ASP.NET Application) without any problem... so my lower layers don't suffer from contamination from the presentation mechanism...

But now i am wondering... If the ConfigurationManager works perfectly... and doesn't tie my code to a particular presentation code... why should I use the WebConfigurationManager.... in fact... why should anyone use the WebConfigurationManager ? I just haven't figured out that...