R
Ryan Hanisco
Hi Jesse,
First off, it is not natural at all to have users in the Local Administrators group, so you are on the right track
Secondly, you might not be pleased by this, but this is working exactly as it should. You have a few problems here...
1. While it is physically possible to have two domains with different FQDNs but the same NetBIOS name, this is a really bad idea. While I am assuming that you did this to make things compatible and ease the transition from one domain to the other, you have really shot yourself in the foot. Many of the tools that are normally used for migrations like this and trusts rely on NetBIOS names and will not function correctly when the two are the same. I have done Migrations using only the FQDNs, and, while I have gotten this to work, this is not the designed behavior of the tools.
2. When Migrating user accounts, there is a lot more to it than just the representation of UserName and Domain. Everything is really referred to by its GUID and SID. Just changing the domain membership of the workstations does not translate into a change of the user profiles, rather a new profile will be created for the users as they'll have different SIDs in the new domain.
3. The mapping between SID and Profile path is done in the local registry of each workstation. To make this available to users, you either need to make changes to the keys or to persist the SIDHistory in the accounts as you move them.
Solution:
What you need to do here is an actual migration, rather than just playing with the accounts between domains. No amount of smoke and mirrors will substitute for a carefully planned migration. I would suggest that you download the ADMTv2 and do a migration of users from your source domain to the final destination. This way you will persist the accounts, passwords, and SIDHistory so you'll keep everything live and have access to all resources as you migrate the old domain and re-allocate its resources to the new domain.
The best source for info on this are the help files for the ADMTv2 (they are actually very very good) and the white paper at intrinsic.net. take a look at these, test the migrations in a dummy run, and then implement slowly. Also, once you are done, leave the SIDHistory intact if your security rules will allow it. Otherwise, deploy the UPH Cleaner, and manually edit the registry to do the SID translation on local profiles.
Ryan Hanisco, MCSE, MCDBA
Network Engineer
FlagShip Integration Services, Inc.
(e-mail address removed)
Hi Ryan,
I was wondering if you would be able to assist me, as I was searching
the Microsoft TechNet discussion groups and found your input useful in
similar issues. Basically I have a PC which is connected to the 1st
server, which is a domain controller. The user which logs on to this
machine is a member of the Domain Users group and is a LOCAL Power User
on the local machine, ie. In the Power Users group in Computer
Management - Local Users and Groups - Groups - Power Users, I have:
DOMAIN\Power Users.
Normally, I would have Domain Users in the local Administrators group,
but due to needing users to be restricted in their rights on the local
machine, we cannot allow that.
I have 2 servers, both Domain Controllers, with different domain names,
lets call them test1.com and test2.com. The NETBIOS name is 'DOMAIN'
for both. They are basically identical in hardware and OS
specifications.
The problem that I'm getting is that when I'm migrating from the 1st
Server to the 2nd Server and the PC has Domain Users as Local Power
Users only and not Local Administrators, when I do the process of
disjoining from the 1st Server and joining to the second server, the
profile is not displayed properly after being migrated across.
The process that is done when copying the user profiles across is:
- Join to Server 1 domain
- Set Domain Users as Local Power Users
- Log on to Server 1 as the User
- Change profile settings
- Log off
- Log into machine as Local Administrator
- Disjoin from Server 1 domain
- Log into machine as Local Administrator again
- Join Server 2 domain
- Log into Server 2 domain as Domain Administrator
- Set all Domain Users as Local Power Users
- Copy all profiles from C:\Documents and Settings to C:\Profiles.bak
(Except All Users, Default Users, Administrator)
- Delete all profiles from C:\Documents and Settings to C:\Profiles.bak
(Except All Users, Default Users, Administrator)
- Log off and Log into the domain as the User
- Log off and Log into the domain as Administrator
- Delete *new profile from C:\Documents and Settings
- Copy User's old profile from C:\Profiles.bak to C:\Documents and
Settings and rename to the deleted *new profile name
- Re-apply appropriate permissions to the profile folders
- Reset Security permission on all child objects
- Log off and log back on as the User on to the domain
* This is where the profile should look correct - however this seems to
only be the case when Domain Users are set as Local Administrators and
not Power Users.
If you have any questions or suggestions, your reply would be much
appreciated.
Regards,
Jesse O'Brien
Systems Engineer
*********************
Pronet Technology
4/613 Whitehorse Road
Mitcham VIC 3132
Tel: (03) 9873-8386
Fax: (03) 9873-8389
DISCLAIMER:
The information contained in this email and any attachments are confidential and are solely intended for the recipient or someone authorised to receive the recipient's email. If you have received this email in error, please notify the sender immediately and delete this email and any copies from your computer system. Do not disclose, distribute, copy, print or rely on this email.
Any views or opinions expressed in this email is solely of the sender's and do not necessarily represent the views of Pronet Technology. The Company cannot accept liability for any views or comments made by our employees outside the scope of our business.
While Pronet Technology has taken every effort to ensure protection against virus infection, it is the recipient's responsibility to check the email and any attachments for viruses prior to opening. Pronet Technology accepts no liability for any loss or damage that may result from the recipient receiving this message or any attachment.
First off, it is not natural at all to have users in the Local Administrators group, so you are on the right track
Secondly, you might not be pleased by this, but this is working exactly as it should. You have a few problems here...
1. While it is physically possible to have two domains with different FQDNs but the same NetBIOS name, this is a really bad idea. While I am assuming that you did this to make things compatible and ease the transition from one domain to the other, you have really shot yourself in the foot. Many of the tools that are normally used for migrations like this and trusts rely on NetBIOS names and will not function correctly when the two are the same. I have done Migrations using only the FQDNs, and, while I have gotten this to work, this is not the designed behavior of the tools.
2. When Migrating user accounts, there is a lot more to it than just the representation of UserName and Domain. Everything is really referred to by its GUID and SID. Just changing the domain membership of the workstations does not translate into a change of the user profiles, rather a new profile will be created for the users as they'll have different SIDs in the new domain.
3. The mapping between SID and Profile path is done in the local registry of each workstation. To make this available to users, you either need to make changes to the keys or to persist the SIDHistory in the accounts as you move them.
Solution:
What you need to do here is an actual migration, rather than just playing with the accounts between domains. No amount of smoke and mirrors will substitute for a carefully planned migration. I would suggest that you download the ADMTv2 and do a migration of users from your source domain to the final destination. This way you will persist the accounts, passwords, and SIDHistory so you'll keep everything live and have access to all resources as you migrate the old domain and re-allocate its resources to the new domain.
The best source for info on this are the help files for the ADMTv2 (they are actually very very good) and the white paper at intrinsic.net. take a look at these, test the migrations in a dummy run, and then implement slowly. Also, once you are done, leave the SIDHistory intact if your security rules will allow it. Otherwise, deploy the UPH Cleaner, and manually edit the registry to do the SID translation on local profiles.
Ryan Hanisco, MCSE, MCDBA
Network Engineer
FlagShip Integration Services, Inc.
(e-mail address removed)
Hi Ryan,
I was wondering if you would be able to assist me, as I was searching
the Microsoft TechNet discussion groups and found your input useful in
similar issues. Basically I have a PC which is connected to the 1st
server, which is a domain controller. The user which logs on to this
machine is a member of the Domain Users group and is a LOCAL Power User
on the local machine, ie. In the Power Users group in Computer
Management - Local Users and Groups - Groups - Power Users, I have:
DOMAIN\Power Users.
Normally, I would have Domain Users in the local Administrators group,
but due to needing users to be restricted in their rights on the local
machine, we cannot allow that.
I have 2 servers, both Domain Controllers, with different domain names,
lets call them test1.com and test2.com. The NETBIOS name is 'DOMAIN'
for both. They are basically identical in hardware and OS
specifications.
The problem that I'm getting is that when I'm migrating from the 1st
Server to the 2nd Server and the PC has Domain Users as Local Power
Users only and not Local Administrators, when I do the process of
disjoining from the 1st Server and joining to the second server, the
profile is not displayed properly after being migrated across.
The process that is done when copying the user profiles across is:
- Join to Server 1 domain
- Set Domain Users as Local Power Users
- Log on to Server 1 as the User
- Change profile settings
- Log off
- Log into machine as Local Administrator
- Disjoin from Server 1 domain
- Log into machine as Local Administrator again
- Join Server 2 domain
- Log into Server 2 domain as Domain Administrator
- Set all Domain Users as Local Power Users
- Copy all profiles from C:\Documents and Settings to C:\Profiles.bak
(Except All Users, Default Users, Administrator)
- Delete all profiles from C:\Documents and Settings to C:\Profiles.bak
(Except All Users, Default Users, Administrator)
- Log off and Log into the domain as the User
- Log off and Log into the domain as Administrator
- Delete *new profile from C:\Documents and Settings
- Copy User's old profile from C:\Profiles.bak to C:\Documents and
Settings and rename to the deleted *new profile name
- Re-apply appropriate permissions to the profile folders
- Reset Security permission on all child objects
- Log off and log back on as the User on to the domain
* This is where the profile should look correct - however this seems to
only be the case when Domain Users are set as Local Administrators and
not Power Users.
If you have any questions or suggestions, your reply would be much
appreciated.
Regards,
Jesse O'Brien
Systems Engineer
*********************
Pronet Technology
4/613 Whitehorse Road
Mitcham VIC 3132
Tel: (03) 9873-8386
Fax: (03) 9873-8389
DISCLAIMER:
The information contained in this email and any attachments are confidential and are solely intended for the recipient or someone authorised to receive the recipient's email. If you have received this email in error, please notify the sender immediately and delete this email and any copies from your computer system. Do not disclose, distribute, copy, print or rely on this email.
Any views or opinions expressed in this email is solely of the sender's and do not necessarily represent the views of Pronet Technology. The Company cannot accept liability for any views or comments made by our employees outside the scope of our business.
While Pronet Technology has taken every effort to ensure protection against virus infection, it is the recipient's responsibility to check the email and any attachments for viruses prior to opening. Pronet Technology accepts no liability for any loss or damage that may result from the recipient receiving this message or any attachment.