Re: [ActiveDir] admt 2.0 - nt4 computer migration
point taken on the clean reboot - biggest issue has been the failure of user profile migration MS have owned up on a workstation retaining some sort of lock on the user profile despite being logged out - err 7334 is generated on a more general note do people share my view that the level of documentation on the ADMT - error codes / reasons ... is to say the least a bit sparse !!?? GT - Original Message - From: Fuller, Stuart [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 5:15 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration GT, Mostly OT but is related if you are starting the workstation migration journey... Rick's comment about the task manager and checking machines reminded me of something else we did during the workstation migrations. Our operating mantra during the process was clean reboot...clean rebootohmmclean rebooot. :) We used batch files with a FOR statement to drive shutdown.exe and uptime.exe. Shutdown allowed us to force the list of workstations to reboot right before the migration. The Uptime batch file (piped to a .csv file) allowed us to monitor the reboot cycle and make sure all the machines were ready to go. This had the side benefit of weeding out the problem child machines. If shutdown didn't work then the ADMT agent would generally bonk as well. Uptime was also useful in monitoring the reboot after the ADMT agent was finished. Machines that took a long time with the agent could be found and then checked. -Stuart --- Example Shutdown batch file: REM Modify the line below for location of workstation list set file=c:\temp\machineList.txt FOR /F tokens=1 delims=, %%i in (%file%) do shutdown \\%%i /R /c -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2003 2:08 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Gentlemen, thanks to all for your contributions to this. will be going to customer site later this week to do some exhaustive testing on this issue (assuming of course that the computers have not melted in the ridiculously warm weather we are having here !) any other things that you can add will be v gladly received. GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 11:16 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Stuart, Graham - The Agent exec is ADMTAGNT.EXE. Also, I don't remember it running under the Explorer process, as when we did our migrations (well, the on-going saga...) it was an easy matter to check how a machine was doing by bringing up task manager to determine status and load on the box. Had to do this numerous times as workstations took too long and we needed to determine the real status of the process. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] admt 2.0 - nt4 computer migration
GT, Mostly OT but is related if you are starting the workstation migration journey... Rick's comment about the task manager and checking machines reminded me of something else we did during the workstation migrations. Our operating mantra during the process was clean reboot...clean rebootohmmclean rebooot. :) We used batch files with a FOR statement to drive shutdown.exe and uptime.exe. Shutdown allowed us to force the list of workstations to reboot right before the migration. The Uptime batch file (piped to a .csv file) allowed us to monitor the reboot cycle and make sure all the machines were ready to go. This had the side benefit of weeding out the problem child machines. If shutdown didn't work then the ADMT agent would generally bonk as well. Uptime was also useful in monitoring the reboot after the ADMT agent was finished. Machines that took a long time with the agent could be found and then checked. -Stuart --- Example Shutdown batch file: REM Modify the line below for location of workstation list set file=c:\temp\machineList.txt FOR /F tokens=1 delims=, %%i in (%file%) do shutdown \\%%i /R /c -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Monday, July 14, 2003 2:08 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Gentlemen, thanks to all for your contributions to this. will be going to customer site later this week to do some exhaustive testing on this issue (assuming of course that the computers have not melted in the ridiculously warm weather we are having here !) any other things that you can add will be v gladly received. GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 11:16 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Stuart, Graham - The Agent exec is ADMTAGNT.EXE. Also, I don't remember it running under the Explorer process, as when we did our migrations (well, the on-going saga...) it was an easy matter to check how a machine was doing by bringing up task manager to determine status and load on the box. Had to do this numerous times as workstations took too long and we needed to determine the real status of the process. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] admt 2.0 - nt4 computer migration
Gentlemen, thanks to all for your contributions to this. will be going to customer site later this week to do some exhaustive testing on this issue (assuming of course that the computers have not melted in the ridiculously warm weather we are having here !) any other things that you can add will be v gladly received. GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 11:16 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Stuart, Graham - The Agent exec is ADMTAGNT.EXE. Also, I don't remember it running under the Explorer process, as when we did our migrations (well, the on-going saga...) it was an easy matter to check how a machine was doing by bringing up task manager to determine status and load on the box. Had to do this numerous times as workstations took too long and we needed to determine the real status of the process. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fuller, Stuart Sent: Friday, July 11, 2003 3:41 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration G, Can't really speak to the specific technical upgrade process for ADMT. If I remember correctly, we simply installed the latest version over the top of the new one and everything seemed to work out. I think we did have to reinstall the password export service again... We ran the majority of our migrations from the ADMTv2 off of the .Net Server (e.g. 2003) Beta 3 CD. We wanted the v2 because of the password migration bit. We did update the ADMT from the Beta3 version to the RC1 version at about 3/4 through our migration. We didn't really see any differences and upgrading didn't solve a broke workstation migration issue we were having on a dual-proc machine. If it is the NT policy, then on the NT workstation you are trying to migrate, back out the allowed run policy and then try the migration again. If changing the policy via poledit doesn't work you can try looking at the reg keys. JSI FAQ (http://www.jsiinc.com/SUBA/tip/rh0050.htm) lists the two you need to look at (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explor er\ RestrictRun = 1 and entries under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explore r\RestrictRun). Test the workstation by running some unallowed application first so that you know the policy has really been backed out and not reapplied through whatever your distribution mechanism is. If backing off the NT policy doesn't work then re-verify the ADMT setup (http://support.microsoft.com/?kbid=260871). Can you migrate any other NT/2000/XP workstations? If so then ADMT is probably set up correctly and the trouble will be with the specific NT workstation build. According to JSI's note 0362, the RestrictRun policy only works on processes run from the Explorer process. I have no clue if the agent process is being remotely initiated on the workstation via the Explorer process but if between workee and no-workee this is the only difference. Additionally, I couldn't find in my brief surfing expedition what specifically the agent .exe are. Looking at our ADMT console the two probable candidates are ADMTAgnt.exe and DCTAgentService.exe. If the only solution is to add the agent executables to the allowed list then hopefully someone else on the mailing list knows what these really are. Stuart Fuller Active Directory State of Montana -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 12:25 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Stuart, i share your views. i have assmued this is going to be a problem general to NT4 workstation migration - based on first two tested - both failed with identical message. the number of NT4 workstations still in production means a manual migration is not the most practical option. in the course of resolving this i have observed that the contents of the ADMT2 distribution are about 8 months more recent than the production ADMT2 programs that were in good faith !! from the .NET RC1 media, i am assuming the upgrade to be a supported process and will just see if this issue is not specific to ADMT version - i have also noted from netiq.com that they had to patch migration software to resolve similar issues of computer migration migration - do you have any issues specific to versions of ADMT ?? if it does prove to be issues of the allowedrunlist whacking me then the question remains as to what exe's need to be added to support the ADMT operation thanks for your support GT - Original Message - From: Fuller, Stuart [EMAIL PROTECTED] To: [EMAIL
Re: [ActiveDir] admt 2.0 - nt4 computer migration
Rick, thanks for post reply. is your inference then that it is conceivable that a restrictive allowedrunlist tattooed into the registry is able to prevent whatever application it is to run on the NT4 workstation. ??? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:13 AM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham, System Policy on NT 4.0 is truly tatooed to the system. If you turn it off and back on, it's still there - unless manually removed or the policy is backed out via the de-application of said policy. And, sadly - I can't tell you right now what needs to run (yes the Agent, damn it - but what IS the Agent?) Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, July 09, 2003 4:25 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration but then thinking about it no - when i failed on the first nt4 host thought it was down to that computer so tried another one straight away - same access denied result have spoken with the developers of the nt4 build - there is a system policy with an allowedrunlist policy - that was that even while logged off this registry value is tattooed into the computer registry if this is possible which i must confess to not being sure on then need to work out what actually needs to be allowed to run for the admt dispatch agent to execute clutching at straws a bit !!! GT - Original Message - From: Wilkinson, Stephen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 2:01 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration I think Larry's first response could be it Graham. We saw exactly this in our testing with the Quest Migrator product. You must make sure there is no computer account with the same name already in the AD - hiding in an OU you least expect it! (ours got there during testing by manually moving test boxes in and out of the ad domain and forgetting to remove the computer accounts. Stephen Wilkinson Tel +44(0)207 4759276 Mobile +44(0)7973 143970 E-Mail: [EMAIL PROTECTED] -Original Message- From: Duncan, Larry [mailto:[EMAIL PROTECTED] Sent: 08 July 2003 21:45 To: '[EMAIL PROTECTED]' Has the Everyone group been added to the Pre-Windows 2000 Compatible Access group in the new domain? -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows 2000 target domain. the migration environment is working fine with windows 2000 professional clients have got issues with the migration of an NT4 workstation the extract from dispatch.log on the admt server is attached from which i am hoping to get a few clues as to the access denied have checked the obvious issues such as sourcedom\domain admins being a member of the local administrators group and the computer migration being run while logged an as a member of that sourcedom\domain admins group Thanks GT List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ -- If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. -- List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] admt 2.0 - nt4 computer migration
Graham - I have no documentation of an 'allowedrunlist' policy or setting in NT 4.0 (not saying that it doesn't exist - just in the limited time I have this AM I can't find anything). But, given that it does exist, yes - that's what I'm saying. If the policy does truly enforce WHO can run WHAT - then this could be an issue. With that being said - this agent (ADMT), in my experience, runs at the LocalSystem context, and therefore should not be subject to the rules of a ruleset applied by system policy, AFAIK. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Friday, July 11, 2003 5:20 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Rick, thanks for post reply. is your inference then that it is conceivable that a restrictive allowedrunlist tattooed into the registry is able to prevent whatever application it is to run on the NT4 workstation. ??? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:13 AM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham, System Policy on NT 4.0 is truly tatooed to the system. If you turn it off and back on, it's still there - unless manually removed or the policy is backed out via the de-application of said policy. And, sadly - I can't tell you right now what needs to run (yes the Agent, damn it - but what IS the Agent?) Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, July 09, 2003 4:25 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration but then thinking about it no - when i failed on the first nt4 host thought it was down to that computer so tried another one straight away - same access denied result have spoken with the developers of the nt4 build - there is a system policy with an allowedrunlist policy - that was that even while logged off this registry value is tattooed into the computer registry if this is possible which i must confess to not being sure on then need to work out what actually needs to be allowed to run for the admt dispatch agent to execute clutching at straws a bit !!! GT - Original Message - From: Wilkinson, Stephen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 2:01 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration I think Larry's first response could be it Graham. We saw exactly this in our testing with the Quest Migrator product. You must make sure there is no computer account with the same name already in the AD - hiding in an OU you least expect it! (ours got there during testing by manually moving test boxes in and out of the ad domain and forgetting to remove the computer accounts. Stephen Wilkinson Tel +44(0)207 4759276 Mobile +44(0)7973 143970 E-Mail: [EMAIL PROTECTED] -Original Message- From: Duncan, Larry [mailto:[EMAIL PROTECTED] Sent: 08 July 2003 21:45 To: '[EMAIL PROTECTED]' Has the Everyone group been added to the Pre-Windows 2000 Compatible Access group in the new domain? -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows 2000 target domain. the migration environment is working fine with windows 2000 professional clients have got issues with the migration of an NT4 workstation the extract from dispatch.log on the admt server is attached from which i am hoping to get a few clues as to the access denied have checked the obvious issues such as sourcedom\domain admins being a member of the local administrators group and the computer migration being run while logged an as a member of that sourcedom\domain admins group Thanks GT List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ -- If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. -- List info : http://www.activedir.org/mail_list.htm List FAQ: http
Re: [ActiveDir] admt 2.0 - nt4 computer migration
Rick, thanks your time on this issue. my view is that we failing at the installation of the agent - as i read it this takes place using the credentials of the logged in user at the ADMT console ?? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 2:05 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham - I have no documentation of an 'allowedrunlist' policy or setting in NT 4.0 (not saying that it doesn't exist - just in the limited time I have this AM I can't find anything). But, given that it does exist, yes - that's what I'm saying. If the policy does truly enforce WHO can run WHAT - then this could be an issue. With that being said - this agent (ADMT), in my experience, runs at the LocalSystem context, and therefore should not be subject to the rules of a ruleset applied by system policy, AFAIK. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Friday, July 11, 2003 5:20 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Rick, thanks for post reply. is your inference then that it is conceivable that a restrictive allowedrunlist tattooed into the registry is able to prevent whatever application it is to run on the NT4 workstation. ??? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:13 AM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham, System Policy on NT 4.0 is truly tatooed to the system. If you turn it off and back on, it's still there - unless manually removed or the policy is backed out via the de-application of said policy. And, sadly - I can't tell you right now what needs to run (yes the Agent, damn it - but what IS the Agent?) Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, July 09, 2003 4:25 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration but then thinking about it no - when i failed on the first nt4 host thought it was down to that computer so tried another one straight away - same access denied result have spoken with the developers of the nt4 build - there is a system policy with an allowedrunlist policy - that was that even while logged off this registry value is tattooed into the computer registry if this is possible which i must confess to not being sure on then need to work out what actually needs to be allowed to run for the admt dispatch agent to execute clutching at straws a bit !!! GT - Original Message - From: Wilkinson, Stephen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 2:01 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration I think Larry's first response could be it Graham. We saw exactly this in our testing with the Quest Migrator product. You must make sure there is no computer account with the same name already in the AD - hiding in an OU you least expect it! (ours got there during testing by manually moving test boxes in and out of the ad domain and forgetting to remove the computer accounts. Stephen Wilkinson Tel +44(0)207 4759276 Mobile +44(0)7973 143970 E-Mail: [EMAIL PROTECTED] -Original Message- From: Duncan, Larry [mailto:[EMAIL PROTECTED] Sent: 08 July 2003 21:45 To: '[EMAIL PROTECTED]' Has the Everyone group been added to the Pre-Windows 2000 Compatible Access group in the new domain? -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows 2000 target domain. the migration environment is working fine with windows 2000 professional clients have got issues with the migration of an NT4 workstation the extract from dispatch.log on the admt server is attached from which i am hoping to get a few clues as to the access denied have checked the obvious issues such as sourcedom\domain admins being a member of the local administrators group and the computer migration being run while logged an as a member of that sourcedom\domain admins group Thanks GT List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm
RE: [ActiveDir] admt 2.0 - nt4 computer migration
G, Let me clarify what I stated earlier... ADMT needs to be able to resolve the name of the workstation (e.g. find it on the network) and be able to get to the admin$ share on the workstation. When you run ADMT workstation migration, you are running in the security context of the user logged into the ADMT console (unless you use runas). This user needs to have administrator privileges on the target workstation. You can test this very simply by mapping a drive to the target workstation's admin$ share. If that works then you know that the ADMT user does have admin rights and the share is working. We have found that this cheese-o-matic test is the best indication that the ADMT workstation migration will run correctly. However from your other posts, I don't think normal ADMT security is your issue. It looks like the allowed list of applications from the NT Policy is whacking you. In any event, the whole point of the ADMT is to automate the workstation migration. If this is a problem for only a couple of machines, you could just manually migrate them. Join them directly to the new AD domain and simply copy over the user profile. You may have to work on fixing printers and resetting some file rights but usually on a user workstation that is pretty minimal. When we were doing our migration, we ran into about one out every two hundred workstations that had some type of underlying problem where ADMT would bonk. We took those as one-offs and figured it was easier to spend 10 minutes manually migrating the workstation then spending hours trying to figure out why ADMT was failing. On the ones that we did troubleshoot, it was never ADMT fault, it something whacked with the workstation OS, IP stack, NIC, or even shudder the Novell client. Stuart Fuller Active Directory State of Montana -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 8:58 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Rick, thanks your time on this issue. my view is that we failing at the installation of the agent - as i read it this takes place using the credentials of the logged in user at the ADMT console ?? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 2:05 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham - I have no documentation of an 'allowedrunlist' policy or setting in NT 4.0 (not saying that it doesn't exist - just in the limited time I have this AM I can't find anything). But, given that it does exist, yes - that's what I'm saying. If the policy does truly enforce WHO can run WHAT - then this could be an issue. With that being said - this agent (ADMT), in my experience, runs at the LocalSystem context, and therefore should not be subject to the rules of a ruleset applied by system policy, AFAIK. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Friday, July 11, 2003 5:20 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Rick, thanks for post reply. is your inference then that it is conceivable that a restrictive allowedrunlist tattooed into the registry is able to prevent whatever application it is to run on the NT4 workstation. ??? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:13 AM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham, System Policy on NT 4.0 is truly tatooed to the system. If you turn it off and back on, it's still there - unless manually removed or the policy is backed out via the de-application of said policy. And, sadly - I can't tell you right now what needs to run (yes the Agent, damn it - but what IS the Agent?) Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, July 09, 2003 4:25 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration but then thinking about it no - when i failed on the first nt4 host thought it was down to that computer so tried another one straight away - same access denied result have spoken with the developers of the nt4 build - there is a system policy with an allowedrunlist policy - that was that even while logged off this registry value is tattooed into the computer registry if this is possible which i must confess to not being sure on then need to work out what actually needs to be allowed to run
Re: [ActiveDir] admt 2.0 - nt4 computer migration
Stuart, i share your views. i have assmued this is going to be a problem general to NT4 workstation migration - based on first two tested - both failed with identical message. the number of NT4 workstations still in production means a manual migration is not the most practical option. in the course of resolving this i have observed that the contents of the ADMT2 distribution are about 8 months more recent than the production ADMT2 programs that were in good faith !! from the .NET RC1 media, i am assuming the upgrade to be a supported process and will just see if this issue is not specific to ADMT version - i have also noted from netiq.com that they had to patch migration software to resolve similar issues of computer migration migration - do you have any issues specific to versions of ADMT ?? if it does prove to be issues of the allowedrunlist whacking me then the question remains as to what exe's need to be added to support the ADMT operation thanks for your support GT - Original Message - From: Fuller, Stuart [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 6:30 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration G, Let me clarify what I stated earlier... ADMT needs to be able to resolve the name of the workstation (e.g. find it on the network) and be able to get to the admin$ share on the workstation. When you run ADMT workstation migration, you are running in the security context of the user logged into the ADMT console (unless you use runas). This user needs to have administrator privileges on the target workstation. You can test this very simply by mapping a drive to the target workstation's admin$ share. If that works then you know that the ADMT user does have admin rights and the share is working. We have found that this cheese-o-matic test is the best indication that the ADMT workstation migration will run correctly. However from your other posts, I don't think normal ADMT security is your issue. It looks like the allowed list of applications from the NT Policy is whacking you. In any event, the whole point of the ADMT is to automate the workstation migration. If this is a problem for only a couple of machines, you could just manually migrate them. Join them directly to the new AD domain and simply copy over the user profile. You may have to work on fixing printers and resetting some file rights but usually on a user workstation that is pretty minimal. When we were doing our migration, we ran into about one out every two hundred workstations that had some type of underlying problem where ADMT would bonk. We took those as one-offs and figured it was easier to spend 10 minutes manually migrating the workstation then spending hours trying to figure out why ADMT was failing. On the ones that we did troubleshoot, it was never ADMT fault, it something whacked with the workstation OS, IP stack, NIC, or even shudder the Novell client. Stuart Fuller Active Directory State of Montana -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 8:58 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Rick, thanks your time on this issue. my view is that we failing at the installation of the agent - as i read it this takes place using the credentials of the logged in user at the ADMT console ?? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 2:05 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham - I have no documentation of an 'allowedrunlist' policy or setting in NT 4.0 (not saying that it doesn't exist - just in the limited time I have this AM I can't find anything). But, given that it does exist, yes - that's what I'm saying. If the policy does truly enforce WHO can run WHAT - then this could be an issue. With that being said - this agent (ADMT), in my experience, runs at the LocalSystem context, and therefore should not be subject to the rules of a ruleset applied by system policy, AFAIK. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Friday, July 11, 2003 5:20 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Rick, thanks for post reply. is your inference then that it is conceivable that a restrictive allowedrunlist tattooed into the registry is able to prevent whatever application it is to run on the NT4 workstation. ??? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:13 AM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham
RE: [ActiveDir] admt 2.0 - nt4 computer migration
Right - I would assume that this account is a member of the local Administrators group, either directly or by membership of some other group? Someone mentioned, and rightly so, that if you cannot map TO \\machine_name\admin$ as the account in question then the ADMT will not be able to install the Agent. Then, it really doesn't matter under what context it runs - it's not there. I would try and map to the admin$ share, copy an executable to the directory, then execute the program. Just so that you can prove that map, copy and execute. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Friday, July 11, 2003 9:58 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Rick, thanks your time on this issue. my view is that we failing at the installation of the agent - as i read it this takes place using the credentials of the logged in user at the ADMT console ?? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 2:05 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham - I have no documentation of an 'allowedrunlist' policy or setting in NT 4.0 (not saying that it doesn't exist - just in the limited time I have this AM I can't find anything). But, given that it does exist, yes - that's what I'm saying. If the policy does truly enforce WHO can run WHAT - then this could be an issue. With that being said - this agent (ADMT), in my experience, runs at the LocalSystem context, and therefore should not be subject to the rules of a ruleset applied by system policy, AFAIK. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Friday, July 11, 2003 5:20 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Rick, thanks for post reply. is your inference then that it is conceivable that a restrictive allowedrunlist tattooed into the registry is able to prevent whatever application it is to run on the NT4 workstation. ??? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:13 AM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham, System Policy on NT 4.0 is truly tatooed to the system. If you turn it off and back on, it's still there - unless manually removed or the policy is backed out via the de-application of said policy. And, sadly - I can't tell you right now what needs to run (yes the Agent, damn it - but what IS the Agent?) Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, July 09, 2003 4:25 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration but then thinking about it no - when i failed on the first nt4 host thought it was down to that computer so tried another one straight away - same access denied result have spoken with the developers of the nt4 build - there is a system policy with an allowedrunlist policy - that was that even while logged off this registry value is tattooed into the computer registry if this is possible which i must confess to not being sure on then need to work out what actually needs to be allowed to run for the admt dispatch agent to execute clutching at straws a bit !!! GT - Original Message - From: Wilkinson, Stephen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 2:01 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration I think Larry's first response could be it Graham. We saw exactly this in our testing with the Quest Migrator product. You must make sure there is no computer account with the same name already in the AD - hiding in an OU you least expect it! (ours got there during testing by manually moving test boxes in and out of the ad domain and forgetting to remove the computer accounts. Stephen Wilkinson Tel +44(0)207 4759276 Mobile +44(0)7973 143970 E-Mail: [EMAIL PROTECTED] -Original Message- From: Duncan, Larry [mailto:[EMAIL PROTECTED] Sent: 08 July 2003 21:45 To: '[EMAIL PROTECTED]' Has the Everyone group been added to the Pre-Windows 2000 Compatible Access group in the new domain? -Original Message- From
RE: [ActiveDir] admt 2.0 - nt4 computer migration
G, Can't really speak to the specific technical upgrade process for ADMT. If I remember correctly, we simply installed the latest version over the top of the new one and everything seemed to work out. I think we did have to reinstall the password export service again... We ran the majority of our migrations from the ADMTv2 off of the .Net Server (e.g. 2003) Beta 3 CD. We wanted the v2 because of the password migration bit. We did update the ADMT from the Beta3 version to the RC1 version at about 3/4 through our migration. We didn't really see any differences and upgrading didn't solve a broke workstation migration issue we were having on a dual-proc machine. If it is the NT policy, then on the NT workstation you are trying to migrate, back out the allowed run policy and then try the migration again. If changing the policy via poledit doesn't work you can try looking at the reg keys. JSI FAQ (http://www.jsiinc.com/SUBA/tip/rh0050.htm) lists the two you need to look at (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explor er\ RestrictRun = 1 and entries under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explore r\RestrictRun). Test the workstation by running some unallowed application first so that you know the policy has really been backed out and not reapplied through whatever your distribution mechanism is. If backing off the NT policy doesn't work then re-verify the ADMT setup (http://support.microsoft.com/?kbid=260871). Can you migrate any other NT/2000/XP workstations? If so then ADMT is probably set up correctly and the trouble will be with the specific NT workstation build. According to JSI's note 0362, the RestrictRun policy only works on processes run from the Explorer process. I have no clue if the agent process is being remotely initiated on the workstation via the Explorer process but if between workee and no-workee this is the only difference. Additionally, I couldn't find in my brief surfing expedition what specifically the agent .exe are. Looking at our ADMT console the two probable candidates are ADMTAgnt.exe and DCTAgentService.exe. If the only solution is to add the agent executables to the allowed list then hopefully someone else on the mailing list knows what these really are. Stuart Fuller Active Directory State of Montana -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 12:25 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Stuart, i share your views. i have assmued this is going to be a problem general to NT4 workstation migration - based on first two tested - both failed with identical message. the number of NT4 workstations still in production means a manual migration is not the most practical option. in the course of resolving this i have observed that the contents of the ADMT2 distribution are about 8 months more recent than the production ADMT2 programs that were in good faith !! from the .NET RC1 media, i am assuming the upgrade to be a supported process and will just see if this issue is not specific to ADMT version - i have also noted from netiq.com that they had to patch migration software to resolve similar issues of computer migration migration - do you have any issues specific to versions of ADMT ?? if it does prove to be issues of the allowedrunlist whacking me then the question remains as to what exe's need to be added to support the ADMT operation thanks for your support GT - Original Message - From: Fuller, Stuart [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 6:30 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration G, Let me clarify what I stated earlier... ADMT needs to be able to resolve the name of the workstation (e.g. find it on the network) and be able to get to the admin$ share on the workstation. When you run ADMT workstation migration, you are running in the security context of the user logged into the ADMT console (unless you use runas). This user needs to have administrator privileges on the target workstation. You can test this very simply by mapping a drive to the target workstation's admin$ share. If that works then you know that the ADMT user does have admin rights and the share is working. We have found that this cheese-o-matic test is the best indication that the ADMT workstation migration will run correctly. However from your other posts, I don't think normal ADMT security is your issue. It looks like the allowed list of applications from the NT Policy is whacking you. In any event, the whole point of the ADMT is to automate the workstation migration. If this is a problem for only a couple of machines, you could just manually migrate them. Join them directly to the new AD domain and simply copy over the user profile. You may have to work on fixing printers and resetting some file rights
RE: [ActiveDir] admt 2.0 - nt4 computer migration
I may be chiming in a little late on this thread... We ran into an issue when we were testing ADMT where the agent wouldn't install. The way we got around this was adding a line to our users logon script that added the acct. that ADMT is using to run to the local admin group on the clients workstations. -Tim -Original Message- From: Rick Kingslan [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 2:54 PM To: [EMAIL PROTECTED] Right - I would assume that this account is a member of the local Administrators group, either directly or by membership of some other group? Someone mentioned, and rightly so, that if you cannot map TO \\machine_name\admin$ as the account in question then the ADMT will not be able to install the Agent. Then, it really doesn't matter under what context it runs - it's not there. I would try and map to the admin$ share, copy an executable to the directory, then execute the program. Just so that you can prove that map, copy and execute. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Friday, July 11, 2003 9:58 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Rick, thanks your time on this issue. my view is that we failing at the installation of the agent - as i read it this takes place using the credentials of the logged in user at the ADMT console ?? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 2:05 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham - I have no documentation of an 'allowedrunlist' policy or setting in NT 4.0 (not saying that it doesn't exist - just in the limited time I have this AM I can't find anything). But, given that it does exist, yes - that's what I'm saying. If the policy does truly enforce WHO can run WHAT - then this could be an issue. With that being said - this agent (ADMT), in my experience, runs at the LocalSystem context, and therefore should not be subject to the rules of a ruleset applied by system policy, AFAIK. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Friday, July 11, 2003 5:20 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Rick, thanks for post reply. is your inference then that it is conceivable that a restrictive allowedrunlist tattooed into the registry is able to prevent whatever application it is to run on the NT4 workstation. ??? GT - Original Message - From: Rick Kingslan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:13 AM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Graham, System Policy on NT 4.0 is truly tatooed to the system. If you turn it off and back on, it's still there - unless manually removed or the policy is backed out via the de-application of said policy. And, sadly - I can't tell you right now what needs to run (yes the Agent, damn it - but what IS the Agent?) Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, July 09, 2003 4:25 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration but then thinking about it no - when i failed on the first nt4 host thought it was down to that computer so tried another one straight away - same access denied result have spoken with the developers of the nt4 build - there is a system policy with an allowedrunlist policy - that was that even while logged off this registry value is tattooed into the computer registry if this is possible which i must confess to not being sure on then need to work out what actually needs to be allowed to run for the admt dispatch agent to execute clutching at straws a bit !!! GT - Original Message - From: Wilkinson, Stephen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 2:01 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration I think Larry's first response could be it Graham. We saw exactly this in our testing with the Quest Migrator product. You must make sure there is no computer account with the same name already in the AD - hiding in an OU you least expect it! (ours got there during testing by manually moving test boxes in and out of the ad domain and forgetting
RE: [ActiveDir] admt 2.0 - nt4 computer migration
Stuart, Graham - The Agent exec is ADMTAGNT.EXE. Also, I don't remember it running under the Explorer process, as when we did our migrations (well, the on-going saga...) it was an easy matter to check how a machine was doing by bringing up task manager to determine status and load on the box. Had to do this numerous times as workstations took too long and we needed to determine the real status of the process. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fuller, Stuart Sent: Friday, July 11, 2003 3:41 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration G, Can't really speak to the specific technical upgrade process for ADMT. If I remember correctly, we simply installed the latest version over the top of the new one and everything seemed to work out. I think we did have to reinstall the password export service again... We ran the majority of our migrations from the ADMTv2 off of the .Net Server (e.g. 2003) Beta 3 CD. We wanted the v2 because of the password migration bit. We did update the ADMT from the Beta3 version to the RC1 version at about 3/4 through our migration. We didn't really see any differences and upgrading didn't solve a broke workstation migration issue we were having on a dual-proc machine. If it is the NT policy, then on the NT workstation you are trying to migrate, back out the allowed run policy and then try the migration again. If changing the policy via poledit doesn't work you can try looking at the reg keys. JSI FAQ (http://www.jsiinc.com/SUBA/tip/rh0050.htm) lists the two you need to look at (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explor er\ RestrictRun = 1 and entries under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explore r\RestrictRun). Test the workstation by running some unallowed application first so that you know the policy has really been backed out and not reapplied through whatever your distribution mechanism is. If backing off the NT policy doesn't work then re-verify the ADMT setup (http://support.microsoft.com/?kbid=260871). Can you migrate any other NT/2000/XP workstations? If so then ADMT is probably set up correctly and the trouble will be with the specific NT workstation build. According to JSI's note 0362, the RestrictRun policy only works on processes run from the Explorer process. I have no clue if the agent process is being remotely initiated on the workstation via the Explorer process but if between workee and no-workee this is the only difference. Additionally, I couldn't find in my brief surfing expedition what specifically the agent .exe are. Looking at our ADMT console the two probable candidates are ADMTAgnt.exe and DCTAgentService.exe. If the only solution is to add the agent executables to the allowed list then hopefully someone else on the mailing list knows what these really are. Stuart Fuller Active Directory State of Montana -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 12:25 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Stuart, i share your views. i have assmued this is going to be a problem general to NT4 workstation migration - based on first two tested - both failed with identical message. the number of NT4 workstations still in production means a manual migration is not the most practical option. in the course of resolving this i have observed that the contents of the ADMT2 distribution are about 8 months more recent than the production ADMT2 programs that were in good faith !! from the .NET RC1 media, i am assuming the upgrade to be a supported process and will just see if this issue is not specific to ADMT version - i have also noted from netiq.com that they had to patch migration software to resolve similar issues of computer migration migration - do you have any issues specific to versions of ADMT ?? if it does prove to be issues of the allowedrunlist whacking me then the question remains as to what exe's need to be added to support the ADMT operation thanks for your support GT - Original Message - From: Fuller, Stuart [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 11, 2003 6:30 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration G, Let me clarify what I stated earlier... ADMT needs to be able to resolve the name of the workstation (e.g. find it on the network) and be able to get to the admin$ share on the workstation. When you run ADMT workstation migration, you are running in the security context of the user logged into the ADMT console (unless you use runas). This user needs to have administrator privileges on the target workstation. You can test this very simply by mapping a drive
RE: [ActiveDir] admt 2.0 - nt4 computer migration
I think Larry's first response could be it Graham. We saw exactly this in our testing with the Quest Migrator product. You must make sure there is no computer account with the same name already in the AD - hiding in an OU you least expect it! (ours got there during testing by manually moving test boxes in and out of the ad domain and forgetting to remove the computer accounts. Stephen Wilkinson Tel +44(0)207 4759276 Mobile +44(0)7973 143970 E-Mail: [EMAIL PROTECTED] -Original Message- From: Duncan, Larry [mailto:[EMAIL PROTECTED] Sent: 08 July 2003 21:45 To: '[EMAIL PROTECTED]' Has the Everyone group been added to the Pre-Windows 2000 Compatible Access group in the new domain? -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows 2000 target domain. the migration environment is working fine with windows 2000 professional clients have got issues with the migration of an NT4 workstation the extract from dispatch.log on the admt server is attached from which i am hoping to get a few clues as to the access denied have checked the obvious issues such as sourcedom\domain admins being a member of the local administrators group and the computer migration being run while logged an as a member of that sourcedom\domain admins group Thanks GT List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ -- If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. -- List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] admt 2.0 - nt4 computer migration
thanks for the posted replies am pretty sure this is the case - was a prerequisite of pwd migration which is going fine and dandy. existing computer a/c sounds a possibility - will give that a whirl nice and friendly error messages heh !!! GT - Original Message - From: Duncan, Larry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 9:45 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration Has the Everyone group been added to the Pre-Windows 2000 Compatible Access group in the new domain? -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows 2000 target domain. the migration environment is working fine with windows 2000 professional clients have got issues with the migration of an NT4 workstation the extract from dispatch.log on the admt server is attached from which i am hoping to get a few clues as to the access denied have checked the obvious issues such as sourcedom\domain admins being a member of the local administrators group and the computer migration being run while logged an as a member of that sourcedom\domain admins group Thanks GT List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] admt 2.0 - nt4 computer migration
Graham, Some things to check: Do theAdministrative Shares exist on the NT workstations? Is the administrator account that you are using to migrate the workstations a member of the workstations' local admin group? John WitasickProject Manager - Windows Networking Services Group - Original Message - From: Graham Turner To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 4:23 PM Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows2000 target domain.the migration environment is working fine with windows 2000 professionalclientshave got issues with the migration of an NT4 workstationthe extract from dispatch.log on the admt server is attached from which i amhoping to get a few clues as to the "access denied"have checked the "obvious" issues such as sourcedom\domain admins being amember of the local administrators group and the computer migration beingrun while logged an as a member of that sourcedom\domain admins groupThanksGT This E-mail, including any attachments, may be intended solely for the personal and confidential use of the sender and recipient (s) named above. This message may include advisory, consultative and/or deliberative material and, as such, would be privileged and confidential and not a public document. Any Information in this e-mail identifying a client of the department of Human Services is confidential. If you have received this e-mail in error, you must not review, transmit, convert to hard copy, copy, use or disseminate this e-mail or any attachments to it and you must delete this message. You are requested to notify the sender by return e-mail.
Re: [ActiveDir] admt 2.0 - nt4 computer migration
but then thinking about it no - when i failed on the first nt4 host thought it was down to that computer so tried another one straight away - same access denied result have spoken with the developers of the nt4 build - there is a system policy with an allowedrunlist policy - that was that even while logged off this registry value is tattooed into the computer registry if this is possible which i must confess to not being sure on then need to work out what actually needs to be allowed to run for the admt dispatch agent to execute clutching at straws a bit !!! GT - Original Message - From: Wilkinson, Stephen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 2:01 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration I think Larry's first response could be it Graham. We saw exactly this in our testing with the Quest Migrator product. You must make sure there is no computer account with the same name already in the AD - hiding in an OU you least expect it! (ours got there during testing by manually moving test boxes in and out of the ad domain and forgetting to remove the computer accounts. Stephen Wilkinson Tel +44(0)207 4759276 Mobile +44(0)7973 143970 E-Mail: [EMAIL PROTECTED] -Original Message- From: Duncan, Larry [mailto:[EMAIL PROTECTED] Sent: 08 July 2003 21:45 To: '[EMAIL PROTECTED]' Has the Everyone group been added to the Pre-Windows 2000 Compatible Access group in the new domain? -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows 2000 target domain. the migration environment is working fine with windows 2000 professional clients have got issues with the migration of an NT4 workstation the extract from dispatch.log on the admt server is attached from which i am hoping to get a few clues as to the access denied have checked the obvious issues such as sourcedom\domain admins being a member of the local administrators group and the computer migration being run while logged an as a member of that sourcedom\domain admins group Thanks GT List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ -- If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. -- List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] admt 2.0 - nt4 computer migration
definitely the case of migration account have checked the driveletter$ shares - can;t from memory remember the other shares - which one in particular does admt need - admin$, ipc$ ?? - Original Message - From: John Witasick To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 10:09 PM Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Graham, Some things to check: Do theAdministrative Shares exist on the NT workstations? Is the administrator account that you are using to migrate the workstations a member of the workstations' local admin group? John WitasickProject Manager - Windows Networking Services Group - Original Message - From: Graham Turner To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 4:23 PM Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows2000 target domain.the migration environment is working fine with windows 2000 professionalclientshave got issues with the migration of an NT4 workstationthe extract from dispatch.log on the admt server is attached from which i amhoping to get a few clues as to the "access denied"have checked the "obvious" issues such as sourcedom\domain admins being amember of the local administrators group and the computer migration beingrun while logged an as a member of that sourcedom\domain admins groupThanksGT This E-mail, including any attachments, may be intended solely for the personal and confidential use of the sender and recipient (s) named above. This message may include advisory, consultative and/or deliberative material and, as such, would be privileged and confidential and not a public document. Any Information in this e-mail identifying a client of the department of Human Services is confidential. If you have received this e-mail in error, you must not review, transmit, convert to hard copy, copy, use or disseminate this e-mail or any attachments to it and you must delete this message. You are requested to notify the sender by return e-mail.
RE: [ActiveDir] admt 2.0 - nt4 computer migration
ADMT needs \\targetcomputername\admin$ Good test to see if security is a problem, is to simply try mapping a drive from the computer running ADMT to the admin$ share. (e.g. net use * \\targetcomputername\admin$. Make sure that you are logged in on the ADMT computer with the credentials that the ADMT is running under. Stuart Fuller Active Directory State of Montana From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 3:59 PMTo: [EMAIL PROTECTED]Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration definitely the case of migration account have checked the driveletter$ shares - can;t from memory remember the other shares - which one in particular does admt need - admin$, ipc$ ?? - Original Message - From: John Witasick To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 10:09 PM Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration Graham, Some things to check: Do theAdministrative Shares exist on the NT workstations? Is the administrator account that you are using to migrate the workstations a member of the workstations' local admin group? John WitasickProject Manager - Windows Networking Services Group - Original Message - From: Graham Turner To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 4:23 PM Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows2000 target domain.the migration environment is working fine with windows 2000 professionalclientshave got issues with the migration of an NT4 workstationthe extract from dispatch.log on the admt server is attached from which i amhoping to get a few clues as to the "access denied"have checked the "obvious" issues such as sourcedom\domain admins being amember of the local administrators group and the computer migration beingrun while logged an as a member of that sourcedom\domain admins groupThanksGT This E-mail, including any attachments, may be intended solely for the personal and confidential use of the sender and recipient (s) named above. This message may include advisory, consultative and/or deliberative material and, as such, would be privileged and confidential and not a public document. Any Information in this e-mail identifying a client of the department of Human Services is confidential. If you have received this e-mail in error, you must not review, transmit, convert to hard copy, copy, use or disseminate this e-mail or any attachments to it and you must delete this message. You are requested to notify the sender by return e-mail.
RE: [ActiveDir] admt 2.0 - nt4 computer migration
Graham, System Policy on NT 4.0 is truly tatooed to the system. If you turn it off and back on, it's still there - unless manually removed or the policy is backed out via the de-application of said policy. And, sadly - I can't tell you right now what needs to run (yes the Agent, damn it - but what IS the Agent?) Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, July 09, 2003 4:25 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] admt 2.0 - nt4 computer migration but then thinking about it no - when i failed on the first nt4 host thought it was down to that computer so tried another one straight away - same access denied result have spoken with the developers of the nt4 build - there is a system policy with an allowedrunlist policy - that was that even while logged off this registry value is tattooed into the computer registry if this is possible which i must confess to not being sure on then need to work out what actually needs to be allowed to run for the admt dispatch agent to execute clutching at straws a bit !!! GT - Original Message - From: Wilkinson, Stephen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 2:01 PM Subject: RE: [ActiveDir] admt 2.0 - nt4 computer migration I think Larry's first response could be it Graham. We saw exactly this in our testing with the Quest Migrator product. You must make sure there is no computer account with the same name already in the AD - hiding in an OU you least expect it! (ours got there during testing by manually moving test boxes in and out of the ad domain and forgetting to remove the computer accounts. Stephen Wilkinson Tel +44(0)207 4759276 Mobile +44(0)7973 143970 E-Mail: [EMAIL PROTECTED] -Original Message- From: Duncan, Larry [mailto:[EMAIL PROTECTED] Sent: 08 July 2003 21:45 To: '[EMAIL PROTECTED]' Has the Everyone group been added to the Pre-Windows 2000 Compatible Access group in the new domain? -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows 2000 target domain. the migration environment is working fine with windows 2000 professional clients have got issues with the migration of an NT4 workstation the extract from dispatch.log on the admt server is attached from which i am hoping to get a few clues as to the access denied have checked the obvious issues such as sourcedom\domain admins being a member of the local administrators group and the computer migration being run while logged an as a member of that sourcedom\domain admins group Thanks GT List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ -- If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. -- List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] admt 2.0 - nt4 computer migration
While continuing my interest in this issue, I came across the following Q-article that seems dead-on: http://support.microsoft.com/default.aspx?scid=kb;en-us;316073 -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows 2000 target domain. the migration environment is working fine with windows 2000 professional clients have got issues with the migration of an NT4 workstation the extract from dispatch.log on the admt server is attached from which i am hoping to get a few clues as to the access denied have checked the obvious issues such as sourcedom\domain admins being a member of the local administrators group and the computer migration being run while logged an as a member of that sourcedom\domain admins group Thanks GT List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] admt 2.0 - nt4 computer migration
Has the Everyone group been added to the Pre-Windows 2000 Compatible Access group in the new domain? -Original Message- From: Graham Turner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] admt 2.0 - nt4 computer migration Am attempting the migration of computer from NT4 source domain to Windows 2000 target domain. the migration environment is working fine with windows 2000 professional clients have got issues with the migration of an NT4 workstation the extract from dispatch.log on the admt server is attached from which i am hoping to get a few clues as to the access denied have checked the obvious issues such as sourcedom\domain admins being a member of the local administrators group and the computer migration being run while logged an as a member of that sourcedom\domain admins group Thanks GT List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
