Does anyone know how to transfer a Windows 2000 user account(username,password - I don't need their profile) from one Windows 2000 box to a another Windows 2000 box.
thanks
thanks
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
User account transfer
- Thread starter ackka
- Start date
GrnEyedLdy
Instructor
Ackka,
Are you in a Domain or Workgroup environment?
Patty
![[ponytails2]](/data/assets/smilies/ponytails2.gif "[ponytails2] [ponytails2]")
You don't, this would bypass the security built into the system!
Each user on each box is unique, and has a unique SID associated with that system and user account. From the question I am assuming you have a workgroup configuration.
You can not "transfer" a user account (although you can copy a profile to another system), although you can create a "new" user on a new system with the same name and password, but the SIDs for each system are different. This is the same reason you can not "restore" a user account you accidently deleted, each is unique by design, and for security reasons. Since passwords are encrypted, you can not read them on the server, and you would need to know the current password to create the new account.
HTH
David
Each user on each box is unique, and has a unique SID associated with that system and user account. From the question I am assuming you have a workgroup configuration.
You can not "transfer" a user account (although you can copy a profile to another system), although you can create a "new" user on a new system with the same name and password, but the SIDs for each system are different. This is the same reason you can not "restore" a user account you accidently deleted, each is unique by design, and for security reasons. Since passwords are encrypted, you can not read them on the server, and you would need to know the current password to create the new account.
HTH
David
- Thread starter
- #4
I am in a Workgroup environment, the machine serves as a simple data backup for about 20 users. People connect using the Windows sharing ability. Each user is assigned permissions on the data backup using NTFS.
I can recreate the server on another machine it just means I have to recreate those 20 accounts and have all users set their individual passwords again.
The SID is not a problem because I use groups to assign permissions to NTFS folders and files. So recreating the security settings should't be a problem???
Is their a way to copy the password in the encrypted form??
I can recreate the server on another machine it just means I have to recreate those 20 accounts and have all users set their individual passwords again.
The SID is not a problem because I use groups to assign permissions to NTFS folders and files. So recreating the security settings should't be a problem???
Is their a way to copy the password in the encrypted form??
I do not know how else to break the news to you, but Welcome to the world of Microsoft! You CAN NOT COPY the passwords, etc. , they only work on the system they are created on in the workgroup environment, end of story! Therein lies the FIRST RULE OF GATES. 
This is why we use Domains, so we only need to maintain ONE set of user files. For a workgroup, there is no way to share access permissions between different systems without haveing a user account set on each system in the workgroup the user needs to access, with all the headaches of trying to keep passwords current, etc.
Hate to tell you, but SIDs are the problem. The use of groups is great, but these are local groups on the local system and these use the local user accounts and their SIDs to control access. Using a Domain puts the user accounts on the central server (the DC), and makes these available to add to local groups all over the Domain, AND it allows you to force users to change their passwords on a regular basis, etc., and to enforce real security policy in the system. WIth all that is going on today in the InterNet world, if your users and systems are able to access the InterNet, then YOU WANT TO BE USING A DOMAIN configuration to enforce a security policy for protection of the Company assets.
HTH
David
This is why we use Domains, so we only need to maintain ONE set of user files. For a workgroup, there is no way to share access permissions between different systems without haveing a user account set on each system in the workgroup the user needs to access, with all the headaches of trying to keep passwords current, etc.
Hate to tell you, but SIDs are the problem. The use of groups is great, but these are local groups on the local system and these use the local user accounts and their SIDs to control access. Using a Domain puts the user accounts on the central server (the DC), and makes these available to add to local groups all over the Domain, AND it allows you to force users to change their passwords on a regular basis, etc., and to enforce real security policy in the system. WIth all that is going on today in the InterNet world, if your users and systems are able to access the InterNet, then YOU WANT TO BE USING A DOMAIN configuration to enforce a security policy for protection of the Company assets.
HTH
David
Sysprep only works if the two systems are identical hardware, etc., and you do not want two identical systems in the network anyway (causes all kinds of wierd problems), so what would be the point? As I see it, this is a Workgroup, not a Domain, and only the user ID data is what is wanted on the other systems. Sysprep copies everything on the system, so does not help the situation anyway.
Domain solves the problems once and for all, but will be a one-time headache to convert as changing the local workstations to move into the domain will change the users local configuration. You will need to copy the existing local local user profile into the profile that will be created new on each system as it is moved into the domain. Just work, not an inpossible task, and would have to be done at each system. Pay off is great though, for all the reasons mentioned earlier.
HTH
David
Domain solves the problems once and for all, but will be a one-time headache to convert as changing the local workstations to move into the domain will change the users local configuration. You will need to copy the existing local local user profile into the profile that will be created new on each system as it is moved into the domain. Just work, not an inpossible task, and would have to be done at each system. Pay off is great though, for all the reasons mentioned earlier.
HTH
David
- Thread starter
- #8
thanks for the help guys, we decided to set up a basic domain, active directory server...
Good decision, I believe you will eliminate many of the common management problems you constantly have to fix in the workgroup environment.
While you are at it, use the opportunity to put in place some good security practices and establish a set of corporate security policies, such as changing passwords regularily, passwords can not be reused, passwords must be at least 8 characters & numbers, set log on times, set group policies, etc. You need to put this in place with the blessings of the top, otherwise it will not work. YOu do not need the additional blame of being the "BAD GUYS" for forcing users to operate in a safe and sensible manner.
In todays world you can not afford to just let the system run, the financial loss can be too great.
Hope it all works out.
David
While you are at it, use the opportunity to put in place some good security practices and establish a set of corporate security policies, such as changing passwords regularily, passwords can not be reused, passwords must be at least 8 characters & numbers, set log on times, set group policies, etc. You need to put this in place with the blessings of the top, otherwise it will not work. YOu do not need the additional blame of being the "BAD GUYS" for forcing users to operate in a safe and sensible manner.
In todays world you can not afford to just let the system run, the financial loss can be too great.
Hope it all works out.
David
![[morning]](/data/assets/smilies/morning.gif "[morning] [morning]")
gman10,
There are quite a few, here are some interesting ones:
- If you have several controllers, you could manage all of them (AD, Trusts, etc) from one controller with Hyena.
- It is very fast to deal with clients.
- You can move users from one domain to the other, or do a bunch at the time.
- all options to remotely manage clients, even full registry editing.
- view and correct the user rights directly on the clients
- add printers to clients remotely.
- Who is logged on.
- See what hotfix are installed on the clients.
- Ability to create overall reports about your network
etc..
You really have to explore it to see all the features that are available. What I like is that all options are put in one system. You don't have to open many apps to manage your network. There are also plenty of nice facilities such as being able to see the SID of a client, being able to send an operator message to a client or a user, remote shutdown, and many others.
I actually learned about this app by reading treads on this site. I got the 30 days version and found it very handy. Obviously, more options could be added to make it the perfect Operator tool, but already it is very useful to me.
Arlem![[blues]](/data/assets/smilies/blues.gif "[blues] [blues]")
There are quite a few, here are some interesting ones:
- If you have several controllers, you could manage all of them (AD, Trusts, etc) from one controller with Hyena.
- It is very fast to deal with clients.
- You can move users from one domain to the other, or do a bunch at the time.
- all options to remotely manage clients, even full registry editing.
- view and correct the user rights directly on the clients
- add printers to clients remotely.
- Who is logged on.
- See what hotfix are installed on the clients.
- Ability to create overall reports about your network
etc..
You really have to explore it to see all the features that are available. What I like is that all options are put in one system. You don't have to open many apps to manage your network. There are also plenty of nice facilities such as being able to see the SID of a client, being able to send an operator message to a client or a user, remote shutdown, and many others.
I actually learned about this app by reading treads on this site. I got the 30 days version and found it very handy. Obviously, more options could be added to make it the perfect Operator tool, but already it is very useful to me.
Arlem
dholbrook wrote
>Sysprep only works if the two systems are identical >hardware, etc.,
The whole point of sysprep is to distrubute a image on machine with different hardware!
>and you do not want two identical systems in the network >anyway (causes all kinds of wierd >problems)
???? Sysprep is made for making identical systems that do not cause weird problems!
> so what would be the point? As I see it, this is a >Workgroup, not a Domain, and only the user ID data is what >is wanted on the other systems. Sysprep copies everything >on the system, so does not help the situation anyway.
- SIDS & Hardware configuration
Everything else is spot on
>Sysprep only works if the two systems are identical >hardware, etc.,
The whole point of sysprep is to distrubute a image on machine with different hardware!
>and you do not want two identical systems in the network >anyway (causes all kinds of wierd >problems)
???? Sysprep is made for making identical systems that do not cause weird problems!
> so what would be the point? As I see it, this is a >Workgroup, not a Domain, and only the user ID data is what >is wanted on the other systems. Sysprep copies everything >on the system, so does not help the situation anyway.
- SIDS & Hardware configuration
Everything else is spot on
ashpp,
The stated desired action was to ONLY transfer/copy the user account from one system to another in a workgroup, not to do what sysprep is designed to do, i.e., to copy an entire computer hardware configuration.
Sysprep is designed for taking a configuration from a master unit and making copies to units with identical or nearly identical hardware. Syspart, not sysprep, is used for systems with different hardware. Sysprep REQUIRES the target computer to have an identical HAL, and mass storage devices, and Advanced Configuration and Power Interface (ACPI) support to function, and plug and play devices will be detected. Otherwise Sysprep will fail. Sysprep DOES NOT copy the Sid, it prepares an image of the hard drive to be transferred to another identical hard drive.
Your statement"The whole point of sysprep is to distrubute a image on machine with different hardware!" is incorrect. Sysprep require a third party disk image utility like Ghost to complete the action, sysprep by itself will not distribute any image to another system.
None of this addresses what the original question was. There is NO requirement to copy hardware configurations stated, only the user accounts, and therefore Sysprep is not the solution. User accounts require the SID to be copied, and that does not work (violates all the security requirements and the system design).
The basic problem is that in a workgroup, unique user accounts need to be created and maintained on each system in the workgroup that the user needs to access. These accounts, even if given the same username and password, are unique with different SIDs for each account, assigned by the system they are created on. You CAN NOT COPY the user accounts (READ: Account DOES NOT = Profile) from one system to another. Domains, on the other hand, will have a single user account in the Domain, and it can be used on all systems in the domain (unless otherwise restricted by the adinistrator) and there is only ONE user account to manage, therefore the problem goes away. Domain user accounts CAN be placed in the local admin or other local groups on a system if needed to provide the user specific access locally, but it is not a new user account, it is still the Domain account, and uses the Domain login.
The solution to the stated problem (the headache of maintaining user accounts on multiple systems in the workgroup environment) is why Domains were created in the first place.
HTH
David
The stated desired action was to ONLY transfer/copy the user account from one system to another in a workgroup, not to do what sysprep is designed to do, i.e., to copy an entire computer hardware configuration.
Sysprep is designed for taking a configuration from a master unit and making copies to units with identical or nearly identical hardware. Syspart, not sysprep, is used for systems with different hardware. Sysprep REQUIRES the target computer to have an identical HAL, and mass storage devices, and Advanced Configuration and Power Interface (ACPI) support to function, and plug and play devices will be detected. Otherwise Sysprep will fail. Sysprep DOES NOT copy the Sid, it prepares an image of the hard drive to be transferred to another identical hard drive.
Your statement"The whole point of sysprep is to distrubute a image on machine with different hardware!" is incorrect. Sysprep require a third party disk image utility like Ghost to complete the action, sysprep by itself will not distribute any image to another system.
None of this addresses what the original question was. There is NO requirement to copy hardware configurations stated, only the user accounts, and therefore Sysprep is not the solution. User accounts require the SID to be copied, and that does not work (violates all the security requirements and the system design).
The basic problem is that in a workgroup, unique user accounts need to be created and maintained on each system in the workgroup that the user needs to access. These accounts, even if given the same username and password, are unique with different SIDs for each account, assigned by the system they are created on. You CAN NOT COPY the user accounts (READ: Account DOES NOT = Profile) from one system to another. Domains, on the other hand, will have a single user account in the Domain, and it can be used on all systems in the domain (unless otherwise restricted by the adinistrator) and there is only ONE user account to manage, therefore the problem goes away. Domain user accounts CAN be placed in the local admin or other local groups on a system if needed to provide the user specific access locally, but it is not a new user account, it is still the Domain account, and uses the Domain login.
The solution to the stated problem (the headache of maintaining user accounts on multiple systems in the workgroup environment) is why Domains were created in the first place.
HTH
David
dholbrook,
>The stated desired action was to ONLY transfer/copy the >user account from one system to another in a workgroup, >not to do what sysprep is designed to do, i.e., to copy an >entire computer hardware configuration.
I know...
>Sysprep is designed for taking a configuration from a >master unit and making copies to units with identical or >nearly identical hardware. Syspart, not sysprep, is used >for systems with different hardware. Sysprep REQUIRES the >target computer to have an identical HAL, and mass storage >devices, and Advanced Configuration and Power Interface
>(ACPI) support to function, and plug and play devices will >be detected
Sysprep (lastest ver) doesn't require you to have the same mass controller. ACPI/HAL though is correct.
>Your statement"The whole point of sysprep is to distrubute >a image on machine with different hardware!" is incorrect. >Sysprep require a third party disk image utility like >Ghost to complete the action, sysprep by itself will not >distribute any image to another system.
OK.. The whole point is sysprep is to prepare the OS prior to cloning.
>The basic problem is that in a workgroup, unique user >accounts need to be created and maintained on each system >in the workgroup that the user needs to access.
I wasn't suggesting you could use sysprep for the solution, just commenting that you are incorrect that using sysprep causes 'weird' problems.
Anyway, the whole point of my post was to get you back for that deny comment you made
>The stated desired action was to ONLY transfer/copy the >user account from one system to another in a workgroup, >not to do what sysprep is designed to do, i.e., to copy an >entire computer hardware configuration.
I know...
>Sysprep is designed for taking a configuration from a >master unit and making copies to units with identical or >nearly identical hardware. Syspart, not sysprep, is used >for systems with different hardware. Sysprep REQUIRES the >target computer to have an identical HAL, and mass storage >devices, and Advanced Configuration and Power Interface
>(ACPI) support to function, and plug and play devices will >be detected
Sysprep (lastest ver) doesn't require you to have the same mass controller. ACPI/HAL though is correct.
>Your statement"The whole point of sysprep is to distrubute >a image on machine with different hardware!" is incorrect. >Sysprep require a third party disk image utility like >Ghost to complete the action, sysprep by itself will not >distribute any image to another system.
OK.. The whole point is sysprep is to prepare the OS prior to cloning.
>The basic problem is that in a workgroup, unique user >accounts need to be created and maintained on each system >in the workgroup that the user needs to access.
I wasn't suggesting you could use sysprep for the solution, just commenting that you are incorrect that using sysprep causes 'weird' problems.
Anyway, the whole point of my post was to get you back for that deny comment you made
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question