gonzo070777

Thank you to all for the tips and suggestions. I experimented with both proposed solutions and had forgotten about the cmd file route. The send option worked perfectly but it prevented easy concurrent data copies plus it was slow to type everything and not as transparent to the user. I've been able to combine the cmd suggestion with my lengthy '&' command and found that i can still use my whole string except when I want to check the robocopy %errorlevel% I just have to do that tiny portion via the CMD line and it reports correctly so far. CMD file contents: ** added an edit so you can see which drive failed the cmd portion %~d0 will tell you the drive letter of the error or success Echo %ERRORLEVEL% If %ERRORLEVEL% GTR 7 Echo There was an error in the data copy for drive %~d0 & Echo. & Echo Please investigate further! & Echo. & Pause If %ERRORLEVEL% LSS 8 Echo There were NO errors in the data copy for drive %~d0 & Echo. & Echo Enjoy using ... So for future reference this works in case anyone else runs into the issue: Global $sCommand = 'C:\windows\system32\robocopy.exe C:\Source_Files\ d:\ *.* /xf buttons2.ini /xd Local_Files /S /copy:DAT /dcopy:t /purge /fft /DST /R:1 /W:2 & c:\temp\RoboERR.cmd & Echo Continue with any other operations as normal & Echo .... ' ;So the error level will only report correctly with anything you put in the cmd file, once the cmd file is done the %ErrorLevel% will report as zero again with anything in the following & functions after the cmd file Run(@ComSpec & " /c " & $sCommand) ;I can't use runwait because I can have 7-10 robocopies running concurrently udating different USB sticks so any error checking needs to be done at the Command level

So i think I figured out the issue but don't know the workaround... If I change the /c to /k to leave the window open and then manually type in Echo %errorlevel% it returns the proper code. So it appears that by using the & joiner to add additional commands is the issue... the %errorlevel% will not return the proper code until you manually type in echo %errorlevel% after it completes I guess this thread can be closed as this is probably a DOS limitation unless anyone has any ideas.

Sorry I tried to explain that in my first post.

Robocopy should only report %errorlevel% of 0 when No errors occurred and no copying was done at the Command prompt If files were copied/mismatched/deleted the %Errorlevel% should be between 1 and 7. If there were any type of errors the %ErrorLevel% should be between 8 and 16. The issue is if I run the command through a pure DOS Command prompt outside of AutoIT I get the correct %errorlevel% returned in the DOS window. If I run the same command via an AutoIT script the %ErrorLevel% in the DOS Command window that is opened by AutoIT always returns 0 even though there are files copied/deleted/mismatched and/or if an error occurs. Unfortunately this prevents me from doing any type of error checking with Robocopy via AutoIT..

Sorry, I forgot to put that. Within AutoIT the @error is always 0 as well if I change it to RunWait.

Good morning. I'm running into an issue where if I run the following example from a compiled script it always returns 0 in the command window. If I run the same item outside of AUtoIT from a command prompt (both standard user and as Admin) it returns the proper error code. Any ideas on what could be going on. I'm not trying to pass a variable to AutoIT, I just need the proper error code returned at the command prompt. Robocopy Version 10.0.16299.15 OS: Windows 10 - Outside of AutoIT this returns the proper error code: C:\windows\system32\robocopy.exe C:\Source_Files\ d:\ *.* /xf buttons2.ini /xd Local_Files /S /copy:DAT /dcopy:t /purge /fft /DST /R:1 /W:2 & Echo The Error level is %ERRORLEVEL% - Within AutoIT script as follows always returns 0... Global $sCommand = 'C:\windows\system32\robocopy.exe C:\Source_Files\ d:\ *.* /xf buttons2.ini /xd Local_Files /S /copy:DAT /dcopy:t /purge /fft /DST /R:1 /W:2 & Echo The Error level is %ERRORLEVEL%' Run(@ComSpec & " /c " & $sCommand) So what am I missing or doing wrong 😕

For _AD_Open. Variable: $techusername, $techpassword are the same for all scenarios and input fields(User ID and password in the GUI) in _AD_Open.au3 All other fields also match what is being used (DNSDomain, HostServer, Confiuration) in the GUI and the AD_Open line of code. If I use the stock script from your UDF: - Domain machine: Works fine. I'm able to get the "Logon Was Successful" with the same username/password passed by $techusername, $techpassword - Workgroup: Gives -2147352567 upon launch (expected since it doesn't know what the AD server name should be on the workgroup machine) If I modify the line in _AD_Open.au3 from _AD_Open() to _AD_Open($techusername, $techpassword, "DC=us,DC=XXXX,DC=com", "XXAD_serverXX.us.XXXX.com", "CN=Configuration,DC=XXXX,DC=com") ;to pass the technician username / password who has rights to AD and the AD variables - Domain Machine: works fine. I'm able to get the "Logon Was Successful" with the same username/password passed by $techusername, $techpassword - Workgroup: Works fine, no error. I'm able to get the "Logon Was Successful" with the same username/password passed by $techusername, $techpassword (Result is the same with both "CN=Configuration,DC=XXXX,DC=com" and "CN=Configuration,DC=us,DC=XXXX,DC=com")

In my custom script I have the #RequireAdmin due to other items being run. So I did add it to the stock _AD_CreateComputer.au3 and compiled. I got the same error result with or without #RequireAdmin on the workgroup machine.

So here are the results and observations: - running _AD_Open.au3 on the domain computer shows the Configuration without the DC=US. I did try it with the DC=US and clicked logon and it works the same (So I guess either way will open AD properly). Clicking logon says logon was successful with the tech credentials with and without the DC=US. I bring that same _AD_open.au3/EXE script to the workgroup machine and it fails, so I change the _AD_open() line to _AD_Open($techusername, $techpassword, "DC=us,DC=XXXX,DC=com", "XXAD_serverXX.us.XXXX.com", "CN=Configuration,DC=us,DC=XXXX,DC=com") and the script runs on the workgroup machine (also launches if I remove the DC=us, from that line) I'm able to get the logon successful on the workgroup machine as well with that change. I've tried using the Windows logon name, Netbios login, as well as the User principal name. All end with Logon was successful. I try the Create computer in AD again on the workgroup machine with the DC=US and all three login methods and returns the same dreaded error -2147352567. If I run the same exe on the machine that is already on the Domain it says successful. I guess also if there a way to add the user to the machine in AD after the fact? I can have a second script run once the machine is rebooted on the domain. To clarify what is being done: 1. We have a workgroup machine 2. I display a GUI that asks for Technican Credentials, New machine name, user to be local admin from domain users 3. Script creates machine in AD, renames the machine, joins to domain, adds domain users to local admin group and reboots 4. Machine is now fully joined to domain and end user logs in with their credentials The sticking point is that they would like the end user to also be able to Join the machine to the domain if needed. The initial join is done with the tech credentials right now but if there is a way to add the end user to the AD machine after the fact once on the domain I could use that as a workaround if I can't get it to work in the workgroup state.

Thank you for the quick reply. Below is the redacted _AD_open. The tech account has full rights to create and modify unlimited computers (this is a special technician account setup by the firm to create, edit, delete computer accounts and modify user accounts) _AD_Open($techusername, $techpassword, "DC=us,DC=XXXX,DC=com", "XXAD_serverXX.us.XXXX.com", "CN=Configuration,DC=XXXX,DC=com")

First post on the forum but long time lurker. Self learning AutoIT on my spare time. So let me say first and foremost thank you for this awesome UDF. It's been great! I have run into an issue with the _AD_CreateComputer.au3 One issue I can work around, the other I can't. So it appears to log into AD just fine with the AD_open. Here are the two issues I've run into. One I made a loose workaround the other I can't figure out a work around. I searched this thread and couldn't find a resolution so I'm sorry if I missed it. 1) If I use _AD_CreateComputer.au3 on a machine that is in a workgroup I get a return code of -2147352567 when I create the machine in AD - (If I use the same exact script on a machine that is already on the domain it works just fine without error code) (I've also tried run as the Network user and that didn't help) Result with error -2147352567: It does actually create the machine in AD and gives the login used for AD_Open rights to add the machine to the domain. So I worked around this by using that one error code as a pass. (that is the only modification to the sample script) 2) The second part I can't workaround is that in the last field "User/group to use this computer (samAccountName or FQDN):" no matter what I enter there it will not add that user entered to the created machine if the machine part of the workgroup - (Again if the machine is already on the domain it works as intended and adds both the login used for _AD_open as well as the name entered there). Result with error -2147352567: It does however continue to add the login used for _AD_Open to the machine. I haven't found a way to add this user to the AD machine after the machine is on the domain either (this is why I say I haven't found a workaround for this one. I did try a little to use _AD_AddUserToGroup.au3 but either I don't get it or I'm doing something wrong, I did put $ after the computer name) Again if this AU3 is run this on a machine that is already part of the domain it works as designed. So in both cases it seems to be an issue with the machine being part of a workgroup instead of being part of a domain. Any help or suggestions would be appreciated, AKA what am I missing? I hope it's something simple I've missed being new to AutoIT.