|
|
|||||||
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 |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
What kinda wkstn OS you running ? Windows 2000+ or do you still got lots of old stuff still kicking around ? |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 ... |
||||||||
|
|
|||||||
just to be clear - obviously you wouldn't disable someones account that hadn't had their home workstation migrated yet ;0) |
||||||||
|
|
|||||||
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! |
||||||||
|
|
|||||||
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??? |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
mmm, interesting. By the sounds of those UDF names it probably is exacly what I need! I will check them out. Thanks Shawn! |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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?? |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
By the way - VBS cannot access those low-level interfaces either ! VB can ! |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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? |
||||||||
|
|
|||||||
You talking to me or Shaun ? |
||||||||
|
|
|||||||
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! |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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? |
||||||||
|
|
|||||||
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:
Find Computer: Code:
|
||||||||
|
|
|||||||
Quote: 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. |
||||||||
|
|
|||||||
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] Code:
|
||||||||
|
|
|||||||
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:
|
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
I think that your function will identify workstaions that need migrated. |