Shaun_Hill
(Getting the hang of it)
2006-03-03 05:38 PM
Need Help with ADSI

Hi all, I need some assistance please with a script I want to create but am new to ADSI. We have been running a NT4 domain for quit some time and only recently began to migrate to AD 2003 (we now running in mixed mode). We have been migrating users and pc's using the ADMT 2.0 tool. What I am finding is people even after being migrated are still logging on to the old domain! I am sure there could be many reasons but I want to stop it! I was thinking about what would be the best way to achieve this and my curent thinking is to create a script and place it on the NT4 domain that will check when a user logs on if there is a computer and user account existing on the 2003 domain for them and the pc they are loggin on from. If there is then I will display some message and force them to logoff.

Please can I get a sample script which can do one of these checks? I don't want you to write me the whole script just need some asistance to get me started...

Also, will the script work throughout or is it neccessary to have the ADSI sdk installed on every machine to run these queries?

regards
Shaun


Howard Bullock
(KiX Supporter)
2006-03-03 05:47 PM
Re: Need Help with ADSI

My suggestion would be to disable the NT4 account of the person that was migrated. If you find that they can not access some resource then you could reanble the NT4 until the problem has been resolved.

ShawnAdministrator
(KiX Supporter)
2006-03-03 06:01 PM
Re: Need Help with ADSI

Little out of my bounds here, but assuming the workstations have been migrated to the new domain, why not just blow-away the 2-way trust and make it one-way. Then they wont have the option of logging into the old domain.

Shaun_Hill
(Getting the hang of it)
2006-03-03 06:01 PM
Re: Need Help with ADSI

Lol, my head is wrapped around scripting.... should have thought of that simple solution!Thanks Howard, you are correct! I must be loosing my mind

Shaun_Hill
(Getting the hang of it)
2006-03-03 06:15 PM
Re: Need Help with ADSI

I think I agreed to soon... Just been thinking a little bit more and the problem is not as easy as just disabling the old user account. The problem is not the user account but the computer accounts. Our users are mostly roaming and all the users accounts have been migrated but not all the computer accounts have... (we doing this is a staged process) And you never know where they might be logging on!

Now we come to what Shawn is saying: with the trust the computer does not need to be migrated to logon to either domain, but when the NT4 domain falls away, then Bam we will have problems...

I also want to identify the computers that are not migrated yet and log this in a file. So if this script can work then this would just be an added procedure. ie. computer account not in AD then computer is not migrated...

Does any of this make any sense? I know I'm struggling myself.
I still think a script to do this check would be the best solution


ShawnAdministrator
(KiX Supporter)
2006-03-03 06:39 PM
Re: Need Help with ADSI

What kinda wkstn OS you running ? Windows 2000+ or do you still got lots of old stuff still kicking around ?

Shaun_Hill
(Getting the hang of it)
2006-03-03 06:44 PM
Re: Need Help with ADSI

thank garden we don't have any nt4 or 95/98 stuff around! Its all 2000/XP.
I'm busy working right now on a search query using ADO and ADSI. I'm just struggling to figure out what info to get from AD to determine if the object exists. Most likely I might have to say if there is an error then it doesn't exist and if it returns something the it obviously does exist.


ShawnAdministrator
(KiX Supporter)
2006-03-03 06:44 PM
Re: Need Help with ADSI

hmmm, I am still a little unclear as to why disabling the old accounts wont work. Your goal is to get everyone using their new accounts - would it really kill your folks if for a time, they couldn't log into un-migrated workstations ? We have roamies too - but find that they usually dont roam too far ...

ShawnAdministrator
(KiX Supporter)
2006-03-03 06:46 PM
Re: Need Help with ADSI

just to be clear - obviously you wouldn't disable someones account that hadn't had their home workstation migrated yet ;0)

Shaun_Hill
(Getting the hang of it)
2006-03-03 06:50 PM
Re: Need Help with ADSI

The environment does not allow for it. We have users that walk over us like carpets and it wouldn't be acceptable. I also like things to go smooth and like to know exactly what the status is of this project. You could say Id rather work smart then hard and don't want any surprises. I think I can achieve this, I was hoping somebody out there had a similar need and a could see how they did it. Don't stress too much, I will definately post a final script once i have figured it all out. I like this ADSI though!

Howard Bullock
(KiX Supporter)
2006-03-03 07:14 PM
Re: Need Help with ADSI

Wait a minute here....

What do computer accounts in an NT4 domain have to do with disabling NT4 user accounts in the same domain? Nothing from what I can see. If you migrated all of the NT4 user accounts, then disable the NT4 user accounts. As long as the NT4 domain trusts your new account domain, users can logon using the AD user account from the NT4 domain workstation.

What am I missing???


ShawnAdministrator
(KiX Supporter)
2006-03-03 07:34 PM
Re: Need Help with ADSI

Well, getting back to your original question ... from your NT4 logon scripts could you check against the @DOMAIN and @LDOMAIN macros, or since all your machines are NT5 - could look at Howards ADSI UDF's for:

GetComputerOU()

-and-

GetUserOU()

Not sure what these functions would return when not joined to NT4, but having them returning nothing versus something would prolly tell you something.


Shaun_Hill
(Getting the hang of it)
2006-03-03 07:43 PM
Re: Need Help with ADSI

Howard you are correct. The problem occurs when you remove those trusts. Then they will no longer be able to logon to AD because their isn't a computer account in AD. So disabling their old Nt4 account would prevent them from logging on to the old domain but it doesn't tell us that their computer account is migrated. You could check this all manually but i don't like to work hard. Removing the trust would bring chaos which I want to avoid and this should be the last step in the migration process. My reasonning is if I leave their old account active and they attempt to use it I can check if their is a computer account on AD and kick them off if there is and also trap the fact that they are or are not migrated computers.
It just makes things neat and tidy for me and our IT staff.

The purpose of the script would be twofold:
1. Prevent migrated computers from logging on to the old domain
2. Trap which computers still need to be migrated. (i don't trust all the completed paper forms and there is bound to be machines that where left out)


make any sense? I might be doing this totally the wrong way but I think it will work


Shaun_Hill
(Getting the hang of it)
2006-03-03 07:45 PM
Re: Need Help with ADSI

mmm, interesting. By the sounds of those UDF names it probably is exacly what I need! I will check them out. Thanks Shawn!

Howard Bullock
(KiX Supporter)
2006-03-03 07:53 PM
Re: Need Help with ADSI

The issue then is you want to log the event of a logon from a computer in the NT4 domain. That is trivial.

In you logon script, creat an IF...ENDIF block that checks @domain. If this matches your old NT4 domain then create a file containing what data is important to you and write it to an open share on a server.

You can then see what NT4 domain based computers were used to logon.

You should not be altering your domain trusts until all the computers have been removed from the domain. As a houskeeping measure the computer account in the NT4 domain should be deleted as the final step of the computer migrstion to the new domain.


Oh, disable those migrated user account in the NT4 domain.


Shaun_Hill
(Getting the hang of it)
2006-03-04 02:20 PM
Re: Need Help with ADSI

Hi Howard, thanks for that suggestion. I had thought of it but I don't get consistent results with @Domain for some reason. E.g. My PC was one of the first to migrated and @Domain tells me it's the old NT domain? But on some other pc's that have been migrated @domain is correct and tells you it's the new domain. I'm not sure if this has something to do with the ADMT tool because sometimes that process completes but with error, but it usually all still works. I've been led to believe this has something to do with roaming profiles.

Also for the script to be effective it will probably need to verify a user account on the new domain as well, just to ensure I don't kick them off the old domain with out an account to use on the new one.

Has anybody been using the IADSContainer, IADSComputer, or IADSUser in their scripts? I can't find examples of these and am struggling to get the vb version converted. It's like I can't access this from kix??


ShawnAdministrator
(KiX Supporter)
2006-03-04 02:31 PM
Re: Need Help with ADSI

Your right, you cannot access those from Kix. Those are low-level COM interfaces (the standard is that COM Interfaces start with the letter "I") ... the good news is that microsoft (usually) provides scriptable interfaces to these same low-level interfaces - they are called dual-interfaces.

Bottom line: While the low-level interface reference material can be usefull, it is really not meant for scripting. What you need to find is an ADSI scripters reference guide.


ShawnAdministrator
(KiX Supporter)
2006-03-04 02:36 PM
Re: Need Help with ADSI

By the way - VBS cannot access those low-level interfaces either ! VB can !

ShawnAdministrator
(KiX Supporter)
2006-03-04 02:53 PM
Re: Need Help with ADSI

I may have given you the wrong impression by saying Kixtart doesn't support (for example) IAdsUser - it does - its just that it uses the scriptable flavor of IAdsUser ... example:

$user = GetObject("WinNT://domain/administrator,user")

$user does indeed implement IAdsUser ... its the same if you do a getobject on a Container ... it implements IAdsContainer - the difference is that it implements it at a SCRIPTABLE level - not on a low-level ... and its not guaranteed that ALL low-level objects and members will work at the scriptable level.


Les
(KiX Master)
2006-03-04 04:16 PM
Re: Need Help with ADSI

Shawn,
You are talking in circles now.

When a computer is migrated from NT4 to AD, why would the NT4 computer account not be disabled immediately? Same for the user account... why not disable them in NT4 as soon as they are migrated?


ShawnAdministrator
(KiX Supporter)
2006-03-04 04:22 PM
Re: Need Help with ADSI

You talking to me or Shaun ?

Shaun_Hill
(Getting the hang of it)
2006-03-04 04:42 PM
Re: Need Help with ADSI

I think he is talking to me... I hear all of what you are saying guys, I'm going to be stubourn and say I am definately going do this in a script. I got a search script for the user almost working properly just needs a few more tweaks. I will adjust it to do the same thing but for computer. If I can i will see if it possible as a udf. ie ismigrated(olddomain,newdomain) but its too soon to start speaking like that. I appreciate all your guys help so far!

Howard Bullock
(KiX Supporter)
2006-03-04 06:00 PM
Re: Need Help with ADSI

If your computer reports that @domain is the old domin than the computer was NOT migrated and the computer is still in the old NT4 domain.

I have eliminated a hundred NT4 domains and you need to force people to use the AD user account. Disable the NT4 user accounts that have been migrated. Remediate and logon problems that crop up.


Then in the AD user's logon script check @domain. Any computer reporting the NT4 domain needs to be moved from the NT4 domain to the AD.


Check into Netdom.exe.

If you follow this process you will successfully complete your migration in short order. I can not speak more strongly on this subject without being rude.


Les
(KiX Master)
2006-03-04 06:02 PM
Re: Need Help with ADSI

I was talking to both of you.

Shawn is making me dizzy with his yes/no/maybe/so talk.

I headed up the AD migration for our company and we simply disabled the accounts immediately after migrating them. I don't understand why you need to get stubborn about it.


Shaun_Hill
(Getting the hang of it)
2006-03-04 07:20 PM
Re: Need Help with ADSI

I do hear you Les but let me describe our environment. About 70% of the machines have touch screens with no keyboards, these particular pc's take about 30 -45 minutes to complete migration vs a p4 which takes about 5 minutes. The users already sulk when we have down time, So any issues that will arise can become a major headache for me. Also we have about 1000 of these machines and only 2 IT staff on duty per shift. I really don't want to work hard. In addition, if something doesn't work then we would rather they revert back untill we resolve the problem, therefore deleting the old computer account might just make it worse because it take away this option.

Re: Howard, my pc was definatly migrated and the computer accounts exists on both domains. I really don't know why @Domain sometimes reports the incorrect domain. I suppose the only way to really test if it was properly migrated would be to remove the trusts... That would be bad at this stage. Also that doesn't then ensure that there is a user account for them in the new domain. So I would still need to do that check. (Which have working now just the computer search remains). If I an can confirm that @Domain is giving an accurate result then that would mean a lot of the machines we have already migrated are not done properly. Maybe I could use this to verify if the migration was a success and not a flop which maybe my pc is? How does @domain determine where your computer account resides?


Shaun_Hill
(Getting the hang of it)
2006-03-04 08:28 PM
Re: Need Help with ADSI

Here is my work in progress, still got a bit to do. Two scripts, 1 to confirm user account migrated, other to confirm computer account migrated. Like to know if I can use @domain to verify a successfull migration... $sDomain and the logfile path need to be configured. Must still consolidate into single script. Have not included the forced loggoff yet.

Find User:

Code:
 
Dim $Con ;(As ADODB.Connection)
Dim $Cmd ;(As ADODB.Command)
Dim $Rs ;(As ADODB.Command)
Dim $Root
;RootDSE for Domain - cannot be dynamic because you not logged onto AD
Dim $sDomain
;Configure RootDSE
$sDomain = "DC=playtime,DC=playing,DC=com"
Dim $OU
Dim $Domain
Dim $sADsPath
Dim $sFilter
Dim $sAttribsToReturn
Dim $sDepth
Dim $strCount
Dim $UserLog
$UserLog = "\\host\INCOMING\MIGRATIONLOG.TXT"

$strName = @UserID
If $strName = ""
? "No username was specified. "
Exit
Else
? "Searching for User Account Name: " + $strName
EndIf

; Create ADO connection object for Active Directory
$Con = CreateObject("ADODB.Connection")
If (@Error <> 0)
? "Error Creating Connection Object"
Exit
Else
? "Successfully Created ADO Connection Object"
EndIf

$Con.Provider = "ADsDSOObject"
If (@Error <> 0)
? "Error Setting Active Directory Provider"
Exit
Else
? "Successfully Set Active Directory Provider"
EndIf

$Con.Open "Active Directory Provider"
If (@Error <> 0)
? "Error Opening Active Directory Provider"
Exit
Else
? "Successfully Opened Active Directory Provider"
EndIf

; Create ADO command object for the connection.
$Cmd = CreateObject("ADODB.Command")
If (@Error <> 0)
? "Error Creating ADO Command Object"
Exit
Else
? "Successfully Created ADO Command Object"
EndIf

$Cmd.ActiveConnection = $Con
If (@Error <> 0)
? "Error Assigning Connection"
Exit
Else
? "Succesfully Assigned Connection"
EndIf

;$OU = "OU=Tsogo Domain Users,OU=MTC"

$Domain = GetObject("LDAP://" + $sDomain)
If (@Error <> 0)
? "Error Connecting to Domain: " + $sDomain
Exit
Else
? "Succesfully Connected to Domain: " + $sDomain
EndIf

$sADsPath = "<" + $Domain.ADsPath + ">"
If (@Error <> 0)
? "Error setting ADsPath"
Exit
Else
? "Succesfully set ADsPath: " + $sADsPath
EndIf

;(objectCategory=computer)
; Build the filter element of the commandtext
If ($strName = "")
? "Error Nothing in Search String"
Exit
Else
;(&(objectCategory=computer)(|(name=leased*)(name=corp*)))
$sFilter = "(&(objectCategory=person)(objectClass=user)(sAMAccountName=" + $strName + "))"
? "Search String: " + $sFilter
EndIf

; Build the returned attributes element of the commandtext.
$sAttribsToReturn = "sAMAccountName"

; Build the depth element of the commandtext.
$sDepth = "subTree"

; Assemble the commandtext.
$Cmd.CommandText = $sADsPath + ";" + $sFilter + ";" + $sAttribsToReturn + ";" + $sDepth
If (@Error <> 0)
? "Error in Query Command Text"
Exit
Else
? "Successfull Query Command Text: " + $Cmd.CommandText
EndIf

; Execute the query.
$Rs = CreateObject("ADODB.Recordset")
If (@Error <> 0)
? "Error Creating Recordset Object"
Exit
Else
? "Successfully Created Recordset Object"
$Rs = $Cmd.Execute
EndIf

$strCount = $rs.RecordCount
If ($strCount > 0)
? "Found " + $strCount + " Accounts. User " + $strName + " Account has been migrated "
Sleep 2
If Open( 3 , $UserLog , 5 ) = 0

$x = WriteLine( 3 , "UserMigrated " + " " + @USERID + " " + @DATE + " " + @TIME + @CRLF)

Else

BEEP

? "failed to open file, error code : [" + @ERROR + "]"

EndIf
Else
? "Unable to find any username on AD for " + $strName
If Open( 3 , $UserLog , 5 ) = 0

$x = WriteLine( 3 , "UserNotMigrated " + " " + @USERID + " " + @DATE + " " + @TIME + @CRLF)

Else

BEEP

? "failed to open file, error code : [" + @ERROR + "]"

EndIf
Exit
EndIf



Find Computer:

Code:
  

Dim $Con ;(As ADODB.Connection)
Dim $Cmd ;(As ADODB.Command)
Dim $Rs ;(As ADODB.Command)
Dim $Root
;RootDSE for Domain - cannot be dynamic because you not logged onto AD
Dim $sDomain
;Configure RootDSE
$sDomain = "DC=playtime,DC=playing,DC=com"
Dim $OU
Dim $Domain
Dim $sADsPath
Dim $sFilter
Dim $sAttribsToReturn
Dim $sDepth
Dim $strCount
Dim $ComputerLog
$ComputerLog = "\\host\INCOMING\MIGRATIONLOG.TXT"

$strName = @WKSTA
If $strName = ""
? "No computer name was specified. "
Exit
Else
? "Searching for Computer Account Name: " + $strName
EndIf

; Create ADO connection object for Active Directory
$Con = CreateObject("ADODB.Connection")
If (@Error <> 0)
? "Error Creating Connection Object"
Exit
Else
? "Successfully Created ADO Connection Object"
EndIf

$Con.Provider = "ADsDSOObject"
If (@Error <> 0)
? "Error Setting Active Directory Provider"
Exit
Else
? "Successfully Set Active Directory Provider"
EndIf

$Con.Open "Active Directory Provider"
If (@Error <> 0)
? "Error Opening Active Directory Provider"
Exit
Else
? "Successfully Opened Active Directory Provider"
EndIf

; Create ADO command object for the connection.
$Cmd = CreateObject("ADODB.Command")
If (@Error <> 0)
? "Error Creating ADO Command Object"
Exit
Else
? "Successfully Created ADO Command Object"
EndIf

$Cmd.ActiveConnection = $Con
If (@Error <> 0)
? "Error Assigning Connection"
Exit
Else
? "Succesfully Assigned Connection"
EndIf

$Domain = GetObject("LDAP://" + $sDomain)
If (@Error <> 0)
? "Error Connecting to Domain: " + $sDomain
Exit
Else
? "Succesfully Connected to Domain: " + $sDomain
EndIf

$sADsPath = "<" + $Domain.ADsPath + ">"
If (@Error <> 0)
? "Error setting ADsPath"
Exit
Else
? "Succesfully set ADsPath: " + $sADsPath
EndIf

;(objectCategory=computer)
; Build the filter element of the commandtext
If ($strName = "")
? "Error Nothing in Search String"
Exit
Else
;(&(objectCategory=computer)(|(name=leased*)(name=corp*)))
$sFilter = "(&(objectCategory=computer)(objectClass=computer)(name=" + $strName + "))"
? "Search String: " + $sFilter
EndIf

; Build the returned attributes element of the commandtext.
$sAttribsToReturn = "name"

; Build the depth element of the commandtext.
$sDepth = "subTree"

; Assemble the commandtext.
$Cmd.CommandText = $sADsPath + ";" + $sFilter + ";" + $sAttribsToReturn + ";" + $sDepth
If (@Error <> 0)
? "Error in Query Command Text"
Exit
Else
? "Successfull Query Command Text: " + $Cmd.CommandText
EndIf

; Execute the query.
$Rs = CreateObject("ADODB.Recordset")
If (@Error <> 0)
? "Error Creating Recordset Object"
Exit
Else
? "Successfully Created Recordset Object"
$Rs = $Cmd.Execute
EndIf

$strCount = $rs.RecordCount
If ($strCount > 0)
? "Found " + $strCount + " Accounts. Computer " + $strName + " Account has been migrated "
Sleep 2
If Open( 3 , $ComputerLog , 5 ) = 0

$x = WriteLine( 3 , "ComputerMigrated " + " " + @WKSTA + " " + @DATE + " " + @TIME + @CRLF)

Else

BEEP

? "failed to open file, error code : [" + @ERROR + "]"

EndIf
Else
? "Unable to find any username on AD for " + $strName
If Open( 3 , $ComputerLog , 5 ) = 0

$x = WriteLine( 3 , "ComputerNotMigrated " + " " + @WKSTA + " " + @DATE + " " + @TIME + @CRLF)

Else

BEEP

? "failed to open file, error code : [" + @ERROR + "]"

EndIf
Exit
EndIf




Howard Bullock
(KiX Supporter)
2006-03-04 10:10 PM
Re: Need Help with ADSI

Quote:

I really don't know why @Domain sometimes reports the incorrect domain. I suppose the only way to really test if it was properly migrated would be to remove the trusts...




Wrong!!!


You could:
1. Use NLTEST.exe to verify to which DC the workstaion is connected for its secure channel. If it is in the AD domain it will say so and you should delete the computer account from the NT4 domain.

nltest /parentdomain

will tell you the domain of membership.

nltest /sc_verify:DomainName will verify your workstaion trust to the domain

2. Simply delete the computer account from the old domain. If you can continue to logon to AD then everything is fine. If not use Netdom.exe to have your computer join the new domain.

You do not play around with the domain TRUSTs until you are ready to decommission the old domain. The trust affect affects authentication form the AD to all computers in the old domain. You only need to address individual computers.


Howard Bullock
(KiX Supporter)
2006-03-04 10:24 PM
Re: Need Help with ADSI

There seems to be a logic flaw in the way you expect to use your code. Accounts can exist in multiple domain but the necessary processing and communication to the user may not yet have occurred.

You need to be in control of the migration process. that means that you TELL the user when his account is migrated instructing them on the new logon procedure that should be used on a particular date. On that date you disable the user account in the old domain.

I would suggest that you migrate the users and computers as two separate processes.

What operating systems are you trying to migrate to the AD domain? That fact may alter the processes and tools used to accomplish the task.

You can then use NETDOM to remotely change the workstation membership to the AD domain.
Code:
NETDOM MOVE machine /Domain:domain [/OU:ou path]
[/UserD:user] [/PasswordD:[password | *]]
[/UserO:user] [/PasswordO:[password | *]]
[/UserF:user] [/PasswordF:[password | *]]
[/REBoot[:Time in seconds]]

NETDOM MOVE Moves a workstation or member server to a new domain

machine is the name of the workstation or member server to be moved

/Domain Specifies the domain to which the machine should be moved. You
can specify a particular domain controller by entering
/Domain:domain\dc. If you specify a domain controller, you
must also include the user's domain. For
example: /UserD:domain\user

/UserD User account used to make the connection with the domain
specified by the /Domain argument

/PasswordD Password of the user account specified by /UserD. A * means
to prompt for the password

/UserO User account used to make the connection with the machine to
be moved

/PasswordO Password of the user account specified by /UserO. A * means
to prompt for the password

/UserF User account used to make the connection with the machine's
former domain (with which the machine had been a member before
the move). Needed to disable the old machine account.

/PasswordF Password of the user account specified by /UserF. A * means
to prompt for the password

/OU Organizational unit under which to create the machine account.
This must be a fully qualified RFC 1779 DN for the OU.
If not specified, the account will be created under the default
organization unit for machine objects for that domain.

/REBoot Specifies that the machine should be shutdown and automatically
rebooted after the Move has completed. The number of seconds
before automatic shutdown can also be provided. Default is
30 seconds

When moving a downlevel (Windows NT version 4 or before) machine to a new
domain, the operation is not transacted. Thus, a failure during the operation
could leave the machine in an undetermined state with respect to the domain it
is joined to.

When moving a machine to a new domain, the old computer account in the
former domain is not deleted. If credentials are supplied for the former
domain, the old computer account will be disabled.

The act of moving a machine to a new domain will create an account for the
machine on the domain if it does not already exist.

Code:

NETDOM JOIN machine /Domain:domain [/OU:ou path] [/UserD:user]
[/PasswordD:[password | *]]
[UserO:user] [/PasswordO:[password | *]]
[/REBoot[:Time in seconds]]

NETDOM JOIN Joins a workstation or member server to the domain.

machine is the name of the workstation or member server to be joined

/Domain Specifies the domain which the machine should join. You
can specify a particular domain controller by entering
/Domain:domain\dc. If you specify a domain controller, you
must also include the user's domain. For
example: /UserD:domain\user

/UserD User account used to make the connection with the domain
specified by the /Domain argument

/PasswordD Password of the user account specified by /UserD. A * means
to prompt for the password

/UserO User account used to make the connection with the machine to
be joined

/PasswordO Password of the user account specified by /UserO. A * means
to prompt for the password

/OU Organizational unit under which to create the machine account.
This must be a fully qualified RFC 1779 DN for the OU.
If not specified, the account will be created under the default
organization unit for machine objects for that domain.

/REBoot Specifies that the machine should be shutdown and automatically
rebooted after the Join has completed. The number of seconds
before automatic shutdown can also be provided. Default is
30 seconds

Windows Professional machines with the ForceGuest setting enabled (which is the
default for machines not joined to a domain during setup) cannot be remotely
administered. Thus the join operation must be run directly on the machine
when the ForceGuest setting is enabled.

When joining a machine running Windows NT version 4 or before to the domain
the operation is not transacted. Thus, a failure during the operation could
leave the machine in an undetermined state with respect to the domain it is
joined to.

The act of joining a machine to the domain will create an account for the
machine on the domain if it does not already exist.



Shaun_Hill
(Getting the hang of it)
2006-03-05 06:29 PM
Re: Need Help with ADSI

Hi Howard, thanks for pointing me in this direction. Been looking at NLtest and I'm getting the same results as @Domain. I.e. NLTest /parentdomain reports my parent domain as the old domain. Now I'm convinced I have a few failed migrations.

Please tell me if you agree. If @domain reports the old domain name then the machine is not migrated properly even if there is a computer account for the machine in the new domain.

If this is correct then can I use this simple function to do this check.

Code:


Function IsMigrated($NewDomain)
If @Domain = $NewDomain
$IsMigrated = 1
Else
$IsMigrated = 0
EndIf
EndFunction



Mart
(KiX Supporter)
2006-03-05 08:38 PM
Re: Need Help with ADSI

If NLtest returns the old domain name then the migration is not done or screwed up and should be done or corrected.
In this case I’d not go for @domain but use NLtest instead.

Like Howard said DO NOT touch the trust until all wksta’s are migrated and the old domain is ready to get trashed. Just delete (or disable) the wksta and user account in the old domain right after they are migrated.


Howard Bullock
(KiX Supporter)
2006-03-05 10:53 PM
Re: Need Help with ADSI

I think that your function will identify workstaions that need migrated.