allanster
asked on
Migrate User Account From Active Directory To Workgroup
One of the companies I provide IT for has twenty XP Pro clients whose user accounts authenticate on a Win2000 Active Directory server. I want to migrate them to a workgroup without any of the individuals losing any of their settings. I have copied and pasted their domain account (local, they don't roam) into their new local account, they were limited users on the domain, when I assign them as an admin on the local, all of their stuff is there, when I downgrade their rights back to limited it is gone. I have applied their local account as the owner on their directory and subcontents, as well as Replace permission entries on all child objects. When I downgrade them to limited, their look and feel is gone. When I upgrade them back to Admin, the look and feel is back. What am I missing here?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
First of all, let me say "Thanks" to both of you for your help.
My somewhat limited experience with File and Settings Transfer Wizard seems to indicate that it is doing an incomplete job of the same thing that I am doing only with needless extra steps of compression and expansion. If you read Microsoft's documentation they tell you that it is migrating only certain specific application data, also, tinkering with it yielded some errors about being unable to migrate some of the cache in from the "all users" profile, this indicates that it is moving more than just my desired one user account. Display resolution, email passwords aren't brought over, OE mail is handled incorrectly, etc... in addition to this, I am leary of it based on other's experience... http://Q_23208327.html
As far as decentralizing the environment, yes, it is precisely because of my concerns of the Win2k croaking. Virtualizing (I run SEP servers virtualized) is an excellent idea if they had an extra physical server to use, but if they did, I could just set up a failover AD to begin with. I actually plan on using their sole server as a vm host as soon as I get AD off of there.
I notice from answers to questions similar to mine, many of the experts here are passionate about AD, I however, am not. It has it's place in a Fortune 500 with primaries and secondaries, I disagree with those that believe it also has it's place in the mom and pop companies. There will always be some point of diminishing return where the work required maintaining AD doesn't justify the time saved from individually administrating a small group of workstations. The things I need centralized work with or without AD (antivirus, access, sql, etc...), all of the users are restricted and none have admin rights save myself. I find myself spending far less time maintaining workgroups as what I spend managing AD, also there is reduced complexity and point of failure. I am moving them to a ReadyNAS NV+ (NAS expandable RAID) w/ spare drive and spare shell. All of this costs far less, is far more reliable, and requires almost zero maintenance after initial (painless) setup. I know because I have run them for years in all of the other companies I service and once I've set quotas, that's it, maybe a resync (mouse click) once a month as a preventative.
Now that I am off my soap box, in regards to your questions...
While the username/password will be the same, the permissions would need to be adjusted to reflect the SID/GID change from the domain\username to computer\username.
I agree, this is what I seem to be missing, could you please elaborate the steps?
Are you copying only the single user's that uses the workstation, or are you copying all the user's profiles to all the other workstations? I.e. if userA's workstation dies. Can they use an alternate workstation and what about their data?
Just want to migrate the user's one AD local account over to their nonAD local account on the same workstation. Each user's profile exists only on their workstation. There isn't alternate workstation for them to use, if it dies I fix it or replace it. Their drive is imaged and backed up on ReadyNAS NV+ with True Image Universal Restore.
My somewhat limited experience with File and Settings Transfer Wizard seems to indicate that it is doing an incomplete job of the same thing that I am doing only with needless extra steps of compression and expansion. If you read Microsoft's documentation they tell you that it is migrating only certain specific application data, also, tinkering with it yielded some errors about being unable to migrate some of the cache in from the "all users" profile, this indicates that it is moving more than just my desired one user account. Display resolution, email passwords aren't brought over, OE mail is handled incorrectly, etc... in addition to this, I am leary of it based on other's experience... http://Q_23208327.html
As far as decentralizing the environment, yes, it is precisely because of my concerns of the Win2k croaking. Virtualizing (I run SEP servers virtualized) is an excellent idea if they had an extra physical server to use, but if they did, I could just set up a failover AD to begin with. I actually plan on using their sole server as a vm host as soon as I get AD off of there.
I notice from answers to questions similar to mine, many of the experts here are passionate about AD, I however, am not. It has it's place in a Fortune 500 with primaries and secondaries, I disagree with those that believe it also has it's place in the mom and pop companies. There will always be some point of diminishing return where the work required maintaining AD doesn't justify the time saved from individually administrating a small group of workstations. The things I need centralized work with or without AD (antivirus, access, sql, etc...), all of the users are restricted and none have admin rights save myself. I find myself spending far less time maintaining workgroups as what I spend managing AD, also there is reduced complexity and point of failure. I am moving them to a ReadyNAS NV+ (NAS expandable RAID) w/ spare drive and spare shell. All of this costs far less, is far more reliable, and requires almost zero maintenance after initial (painless) setup. I know because I have run them for years in all of the other companies I service and once I've set quotas, that's it, maybe a resync (mouse click) once a month as a preventative.
Now that I am off my soap box, in regards to your questions...
While the username/password will be the same, the permissions would need to be adjusted to reflect the SID/GID change from the domain\username to computer\username.
I agree, this is what I seem to be missing, could you please elaborate the steps?
Are you copying only the single user's that uses the workstation, or are you copying all the user's profiles to all the other workstations? I.e. if userA's workstation dies. Can they use an alternate workstation and what about their data?
Just want to migrate the user's one AD local account over to their nonAD local account on the same workstation. Each user's profile exists only on their workstation. There isn't alternate workstation for them to use, if it dies I fix it or replace it. Their drive is imaged and backed up on ReadyNAS NV+ with True Image Universal Restore.
I'll not step on the soapbox but will only address your questions.
What AD maintenance issues do you have to regularly address that is longer than managing 20 users on 20 workstations? Do you use Group Policies to manage what resources are available to users? Do you plan on setting up similar local policies on each workstation? SEP can and does benefit from a centralized environment.
The permissions set on directory/file is based on a User ID which is unique. If you have a share on the member server where you have share files from all user, login into it using a local account server\username. Look within the security settings of a file, and you'll see a numeric representation of the file owner.
What you have to do after copying the files, is to use the take ownership mechanism by clicking the advanced option under the security tab of the properties of the individual user's folder.
I think there is a command line migration utility that might have a command line switch to assign the correct security settings upon the transfer.
Do you perform the same backup for the windows 2000 server? Do you have a DR plan to deal should a failure of the windows 2000 occur?
Under your scenario, userb's system (workstationb) dies. Userb has a task that is due the day of the failure.
One option is to restore userb's data to workstationc and let userb complete their task.
userb will not have a problem logging into workstationc since it is in the AD.
In a decentralized environment, you have to add userb to workstationc.
Restore the files.
Reset the permissions/ownership of the files.
A yet simpler approach is to setup the users as Roaming with Folder redirection.
Userb gets up, goes to workstationc, logs in and continues their tasks.
workstationc dies, the user gets up and goes to the next.
Mitigating a failure in a 20 workstation environment with presumably 20+ users is not to decentralize, but to eliminate the single point of failure.
On what server is the current SEP virtualized? Don't you have two SEP servers?
If you have two hosts where you virtualize, you can easily virtualize a SEP server that is also the DC. The AD functionality is not resource intensive.
What AD maintenance issues do you have to regularly address that is longer than managing 20 users on 20 workstations? Do you use Group Policies to manage what resources are available to users? Do you plan on setting up similar local policies on each workstation? SEP can and does benefit from a centralized environment.
The permissions set on directory/file is based on a User ID which is unique. If you have a share on the member server where you have share files from all user, login into it using a local account server\username. Look within the security settings of a file, and you'll see a numeric representation of the file owner.
What you have to do after copying the files, is to use the take ownership mechanism by clicking the advanced option under the security tab of the properties of the individual user's folder.
I think there is a command line migration utility that might have a command line switch to assign the correct security settings upon the transfer.
Do you perform the same backup for the windows 2000 server? Do you have a DR plan to deal should a failure of the windows 2000 occur?
Under your scenario, userb's system (workstationb) dies. Userb has a task that is due the day of the failure.
One option is to restore userb's data to workstationc and let userb complete their task.
userb will not have a problem logging into workstationc since it is in the AD.
In a decentralized environment, you have to add userb to workstationc.
Restore the files.
Reset the permissions/ownership of the files.
A yet simpler approach is to setup the users as Roaming with Folder redirection.
Userb gets up, goes to workstationc, logs in and continues their tasks.
workstationc dies, the user gets up and goes to the next.
Mitigating a failure in a 20 workstation environment with presumably 20+ users is not to decentralize, but to eliminate the single point of failure.
On what server is the current SEP virtualized? Don't you have two SEP servers?
If you have two hosts where you virtualize, you can easily virtualize a SEP server that is also the DC. The AD functionality is not resource intensive.
ASKER
What AD maintenance issues do you have to regularly address that is longer than managing 20 users on 20 workstations?
I have to manage 20 users on 20 workstations whether I use AD or not. This idea that because I can push out GPO's that I no longer still have to maintain these workstations is hype. Is there some GPO that prevents dust from collecting on the heat sinks that I am not aware of?
Do you use Group Policies to manage what resources are available to users?
I do now, but luckily not for much longer.
Do you plan on setting up similar local policies on each workstation?
Yes, they are called "Restricted User".
SEP can and does benefit from a centralized environment.
It certainly does, that's why I run it as such, and consequently it works just as well for workgroups as it does AD domains, in fact I have the clients from the domain sitting alongside the 100 clients from the other companies workgroups in the same exact centralized policy that manages all of them and SEP doesn't care or provide any extra functionality to the ones that are in the domain versus the ones that are in the workgroup.
The permissions set on directory/file is based on a User ID which is unique. If you have a share on the member server where you have share files from all user, login into it using a local account server\username. Look within the security settings of a file, and you'll see a numeric representation of the file owner.What you have to do after copying the files, is to use the take ownership mechanism by clicking the advanced option under the security tab of the properties of the individual user's folder.I think there is a command line migration utility that might have a command line switch to assign the correct security settings upon the transfer.This is helpful and what I am asking. Unfortunately I have already tried this without success, in addition, when I toggle the user to admin rights, it's all there and working, when I toggle the user back to restricted, it's all there but can't be accessed. I am looking for a specific step by step solution to new restricted user profile to have the same access as the original restricted user profile. With this step for step, perhaps I will see something I have missed.
I already knew from reading four previous similar threads that every time someone asks this they get berated about "why would they do such a stupid thing?" instead of getting actual answers.
I understand that you are trying to be helpful, but you don't understand the structure of these companies, their budgets, and so forth. For instance, you are questioning don't they have two servers, no they don't. This is a group of companies that are all owned by an umbrella but they are separate entities and are not allowed to share resources. I let the one piggyback clients onto another's AV server. I understand roaming profiles (and corrupted ones too). I understand DR and have it in place (including the server). I am the sole IT guy for all of these companies and whether or not I want them as workgroups or domains is my business, I after all have to live with the decisions and maintain them either way. I don't need a lecture about why I should be using AD, I need an answer on how to move an AD domain restricted user to a workgroup restricted user without losing settings and files.
I have to manage 20 users on 20 workstations whether I use AD or not. This idea that because I can push out GPO's that I no longer still have to maintain these workstations is hype. Is there some GPO that prevents dust from collecting on the heat sinks that I am not aware of?
Do you use Group Policies to manage what resources are available to users?
I do now, but luckily not for much longer.
Do you plan on setting up similar local policies on each workstation?
Yes, they are called "Restricted User".
SEP can and does benefit from a centralized environment.
It certainly does, that's why I run it as such, and consequently it works just as well for workgroups as it does AD domains, in fact I have the clients from the domain sitting alongside the 100 clients from the other companies workgroups in the same exact centralized policy that manages all of them and SEP doesn't care or provide any extra functionality to the ones that are in the domain versus the ones that are in the workgroup.
The permissions set on directory/file is based on a User ID which is unique. If you have a share on the member server where you have share files from all user, login into it using a local account server\username. Look within the security settings of a file, and you'll see a numeric representation of the file owner.What you have to do after copying the files, is to use the take ownership mechanism by clicking the advanced option under the security tab of the properties of the individual user's folder.I think there is a command line migration utility that might have a command line switch to assign the correct security settings upon the transfer.This is helpful and what I am asking. Unfortunately I have already tried this without success, in addition, when I toggle the user to admin rights, it's all there and working, when I toggle the user back to restricted, it's all there but can't be accessed. I am looking for a specific step by step solution to new restricted user profile to have the same access as the original restricted user profile. With this step for step, perhaps I will see something I have missed.
I already knew from reading four previous similar threads that every time someone asks this they get berated about "why would they do such a stupid thing?" instead of getting actual answers.
I understand that you are trying to be helpful, but you don't understand the structure of these companies, their budgets, and so forth. For instance, you are questioning don't they have two servers, no they don't. This is a group of companies that are all owned by an umbrella but they are separate entities and are not allowed to share resources. I let the one piggyback clients onto another's AV server. I understand roaming profiles (and corrupted ones too). I understand DR and have it in place (including the server). I am the sole IT guy for all of these companies and whether or not I want them as workgroups or domains is my business, I after all have to live with the decisions and maintain them either way. I don't need a lecture about why I should be using AD, I need an answer on how to move an AD domain restricted user to a workgroup restricted user without losing settings and files.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks again for all of the suggestions, I am going to bite the bullet on this one and use the Wizard. Even after assuming ownership, I was unsuccessful on getting the permissions to propagate both when manually copied and using profile copy. I went back to look at the four previous questions on this forum and it is apparent that the only reason their "solutions" worked is because each of these were running their user accounts with full admin rights. Had they been running their user accounts restricted (like they should have been), manual copy or profile copy would not have worked in a manner that would have been useful.
The wiz worked on my test box so... astralcomputing offered the wiz up first but arnold was much more thorough so I am splitting.
The wiz worked on my test box so... astralcomputing offered the wiz up first but arnold was much more thorough so I am splitting.
ASKER
Thanks for the help, much appreciated!
Lets say each computer is accessed by a single user all the time.
You are converting the management of one server (AD) into the management of 20 computers along with 20 users.
If the concern is with what happens should the win2k server dies, you could look into setting up a VM that will be the AD backup server.
While the username/password will be the same, the permissions would need to be adjusted to reflect the SID/GID change from the domain\username to computer\username.
Are you copying only the single user's that uses the workstation, or are you copying all the user's profiles to all the other workstations? I.e. if userA's workstation dies. Can they use an alternate workstation and what about their data?