theak

MDT AutoIT Script Error

17 posts in this topic

#1 ·  Posted (edited)

Getting an error every time I have this AutoIT exe included in my MDT deployment:

IMG_7100.thumb.JPG.3fb87b977ff28de32eeb0

 

Here's the settings I have it within MDT:

mdt_settings.thumb.JPG.539a6810cd7abf03c

Here's the script (BasicInstall-Trend+MSOffice2013+Lync2013,exe) I'm running:

ShellExecuteWait("\\domain.name\cofs\Organization\its\_Support\AutoIT\MSOffice2013Install.exe")
ShellExecuteWait("\\domain.name\cofs\Organization\its\_Support\AutoIT\MSLync2013Install.exe")
RunWait("\\domain.name\cofs\Organization\ITS\_Support\AUSTIN!\AutoHotKey\Ninite Java NET Reader Silverlight Installer.exe")
ShellExecute("\\server-name-av\ofcscan\AutoPccP.exe")

Here's the separate scripts it calls on:

MSOffice2013Install.exe

#cs ----------------------------------------------------------------------------

 AutoIt Version: 3.3.14.0
 Author:         AK

 Script Function:
    Install Office 2013 with no config options, to remove config options, run exe manually

#ce ----------------------------------------------------------------------------

; Script Start - Add your code below here
ShellExecute('\\server-name-fs02\apps$\Office2013\setup.exe', '/config "\\domain.name\cofs\Organization\its\_Support\AutoIT\MS Office 2013\config.xml"')

MSLync2013Install.exe

#cs ----------------------------------------------------------------------------

 AutoIt Version: 3.3.14.0
 Author:         AK

 Script Function:
    Install Lync 2013 with no config options, to remove config options, run exe manually

#ce ----------------------------------------------------------------------------

; Script Start - Add your code below here
ShellExecute('\\domain.name\cofs\Organization\its\_Software & Hardware\Microsoft\Lync-2013_32-BIT_X64\x86\setup.exe', '/config "\\domain.name\cofs\Organization\its\_Support\AutoIT\MS Lync 2013\config.xml"')

 

Losing my marbles on this one. Can't seem to figure it out.

Edited by theak

Share this post


Link to post
Share on other sites



What are the share and file perms for the .\cofs share?  Have you tested running the scripts as the ..-adm service account to verify the script works and the account has proper perms?

Share this post


Link to post
Share on other sites

The report says : The directory name is invalid.
I don't know if a UNC path is allowed as working directory in a Run command line task (it's not possible in a cmd so maybe it's the same thing) Try to use the full path in the command line, and remove the Start in path:

\\domain.name\cofs\Organization\ITS\_Support\AutoIt\BasicInstall-Trend+MSOffice2013+Lync2013.exe

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

The report says : The directory name is invalid.
I don't know if a UNC path is allowed as working directory in a Run command line task (it's not possible in a cmd so maybe it's the same thing) Try to use the full path in the command line, and remove the Start in path:

\\domain.name\cofs\Organization\ITS\_Support\AutoIt\BasicInstall-Trend+MSOffice2013+Lync2013.exe

Tried these settings...

 mdt_settings.thumb.JPG.38b6f8a880a0f1e13

and ending up getting this error:

 

IMG_7115.thumb.JPG.81f95d7623e8adbb0ec45

I KNOW that I'm entering the user name and password correctly, so I'm not sure what the issue is? Is it not authenticating properly on the server?

 

 

 

Edited by theak

Share this post


Link to post
Share on other sites

Is there a best practices on using MDT in combination with AutoIT that I'm missing?

Share this post


Link to post
Share on other sites

Personnaly, for this kind of execution, I declare a new MDT application (using Application without source files or elswere on the network) with a .bat script stored on the deployment share.

This .bat connects to the server using credentials that I specify (in clear in the .bat file) with a net use command and then run the command that I want.

I don't think it's a good practice (because the password is not encrypted), but it avoids me to edit several task sequence, I just have to edit the .bat file once, that's all.

Note that the .bat file can be replaced by an AutoIt script, compiled or not.

 

 

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

@jguinch
Couldn't you configure your share perms for Everyone to have Read-Only, that way you don't have to provide credentials? 

Of course, if you are required to disable the User Rights Assignment Network access: Let Everyone permissions apply to anonymous users, the perms won't work.

Edited by spudw2k

Share this post


Link to post
Share on other sites

One thing to watch out for is the version of WinPE you use. If you use an x64 version of WinPE then you must use a x64 version of Autoit - the x86 version won't work. Apart from that there shouldn't be any issues. Well, none I've come across. 

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

Does the path exist in the users proflle (at that point, i dont exactly know where that is in the install)?  What happens if you uncheck the bottom box?

Edited by boththose

,-. .--. ________ .-. .-. ,---. ,-. .-. .-. .-.
|(| / /\ \ |\ /| |__ __||| | | || .-' | |/ / \ \_/ )/
(_) / /__\ \ |(\ / | )| | | `-' | | `-. | | / __ \ (_)
| | | __ | (_)\/ | (_) | | .-. | | .-' | | \ |__| ) (
| | | | |)| | \ / | | | | | |)| | `--. | |) \ | |
`-' |_| (_) | |\/| | `-' /( (_)/( __.' |((_)-' /(_|
'-' '-' (__) (__) (_) (__)

Share this post


Link to post
Share on other sites

Personnaly, for this kind of execution, I declare a new MDT application (using Application without source files or elswere on the network) with a .bat script stored on the deployment share.

This .bat connects to the server using credentials that I specify (in clear in the .bat file) with a net use command and then run the command that I want.

I don't think it's a good practice (because the password is not encrypted), but it avoids me to edit several task sequence, I just have to edit the .bat file once, that's all.

Note that the .bat file can be replaced by an AutoIt script, compiled or not.

 

 

So I made multiple applications instead of using the AutoIT files, I got the same errors. Not sure why I thought I wouldn't...

So now, I'm confused about something in MDT. I thought it used the credentials entered at the beginning were used throughout the whole deployment process?

Will I need to make a separate share now with access for everyone, or setup a batch file like jguinch mentioned?

Is there no way to manually plug in credentials at the start of the 'application deployment' section?

mdt_settings2.thumb.JPG.c4319963c7db86d7

Share this post


Link to post
Share on other sites

Do you really need to run the script with the specified account, or just have acces to the remote share ?
Maybe you should add a DriveMapAdd call at the beginning of your script to access the remote share with the good rights.

You should make a log file (or use some MsgBox) with a AutoIt exe to see what happens. For example, use DriveMapAdd and look at what it returns, and the try with FileExits Run[Wait] or ShellExecute[Wait].

 

 

Share this post


Link to post
Share on other sites

Do you really need to run the script with the specified account, or just have acces to the remote share ?
Maybe you should add a DriveMapAdd call at the beginning of your script to access the remote share with the good rights.

You should make a log file (or use some MsgBox) with a AutoIt exe to see what happens. For example, use DriveMapAdd and look at what it returns, and the try with FileExits Run[Wait] or ShellExecute[Wait].

 

 

Yes the share is password protected from other users. However, I suppose I could just copy them locally to the deployment server?

The most recent error I received when making each application to install an 'application' within MDT was 'unexpected error code 2'.

I looked up the error code and it typically means file not found.

So my question is, how can I get the AutoIT script to use the rights for a user account with access to the shares I need?

Share this post


Link to post
Share on other sites

It seems your problem is relative to MDT, not AutoIt.

I use several AutoIt scripts with MDT (created as application), stored in the <DeploymentShare>\Applications\MyApps\script.exe
The MDT application is created like this :
Command line : script.exe
Working directory : .\Applications\MyApps

 

Share this post


Link to post
Share on other sites

Random theory:

I think the only reason you are seeing Autoit in the errors, is because it is the first item in the State Restore Group, and anything in that group would fail.   I think it is still an environment error, but I would move my bet to the boot order of the machine.  In that you reboot back into your PE instead of the HD.


,-. .--. ________ .-. .-. ,---. ,-. .-. .-. .-.
|(| / /\ \ |\ /| |__ __||| | | || .-' | |/ / \ \_/ )/
(_) / /__\ \ |(\ / | )| | | `-' | | `-. | | / __ \ (_)
| | | __ | (_)\/ | (_) | | .-. | | .-' | | \ |__| ) (
| | | | |)| | \ / | | | | | |)| | `--. | |) \ | |
`-' |_| (_) | |\/| | `-' /( (_)/( __.' |((_)-' /(_|
'-' '-' (__) (__) (_) (__)

Share this post


Link to post
Share on other sites

where to download the exe file?

Share this post


Link to post
Share on other sites

How should people know what you are talking about? Please be always as specific as possible.
I already posted the solution in your other tread.

 


My UDFs and Tutorials:

Spoiler

UDFs:
Active Directory (2016-08-18 - Version 1.4.6.0) - Download - General Help & Support - Example Scripts - Wiki
OutlookEX (NEW 2016-12-04 - Version 1.2.2.0) - Download - General Help & Support - Example Scripts - Wiki
ExcelChart (2015-04-01 - Version 0.4.0.0) - Download - General Help & Support - Example Scripts
Excel - Example Scripts - Wiki
Word - Wiki
Tutorials:
ADO - Wiki

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Similar Content

    • Jon
      By Jon
      With the imminent public release of Windows 10 I have been readying my test environments to be able to deploy and test Windows 10. This is a quick overview of the main deployment scenarios supported and some links to the software you will need. Also I’ve included some links to a selection of videos from the MS Ignite conference that I found the most useful for someone new to Windows 10 deployment.   Deployment Scenarios   The main deployment scenarios are: Wipe and Load In-place Upgrade Provisioning   Wipe and Load This is the traditional process and follows these general stages: Wipe device Deploy customised OS image Inject drivers Install applications Optionally this can include steps to capture and restore user data and/or settings if present on the device (usually laptops). Wipe and Load can be done with both MDT and ConfigMgr.   Pros Device will be in a known new state Removes any remnants of old installations, updates and obsolete applications. Over months and years performance and disk space can be adversely affected Can use a custom image that could be pre-updated, or contain applications that rarely change - this can drastically improve deployment times Cons Can have a longer deployment time due to re-installation of all applications post-deployment Must have driver packages available for all machine variants Creating scripts to capture and restore user data can be time-consuming   In-place Upgrade This is a newer scenario available for clients running Windows 7/8/8.1. Windows setup does most of the work for you: Save existing user data, settings, applications and drivers Deploy original Windows 10 image Restore everything This is a new scenario introduced with Windows 8.1 and Windows 10 and it will be interesting to see how it works in anger. In the Microsoft presentations I’ve seen this is being advertised as the preferred method for upgrading from Windows 7 and 8. I personally prefer a wipe-and-load so that I know everything is clean. Also, new OS deployment is often used as an good opportunity to upgrade major software like Microsoft Office which makes some of the in-place upgrade benefits redundant. One scenario I think may benefit is the ability to get a Windows client from an OEM and easily upgrade it to Windows 10 while keeping all the drivers it has. Getting the driver packages for new machines was a burden for some smaller companies.   Pros Preserves all data: user data, setting, applications and drivers and therefore is potentially less risky Don’t always require new drivers if existing drivers are compatible Often a shorter deployment time Requires less preparation Cons Cannot use a customised image, the original Windows 10 media must be used If a machine had obsolete installations and settings these will remain   Provisioning  This is another new Enterprise-focused scenario designed to help with the situations where a company wants to ship a new Windows 10 machine directly from the OEM to a user and then have enterprise software and policies applied to that machine to bring it into compliance. This is controlled by a provisioning package (.ppkg) that is obtained and executed on the target machine and can perform the following operations: Change Windows 10 version from Pro to Enterprise and add in Enterprise features, updates and language packs Retains drivers and applications Install or remove Modern UI applications  Enrol into a domain or management solution Provisioning packages are created with the new Windows Image and Configuration Designer (Windows ICD) tool.   Pros Can change Windows from Pro to Enterprise - this previously required a wipe-and-load Enables Bring Your Own Device (BYOD) scenarios Cons  The available policies are a small - but useful - subset of those available in Group Policy Yet another tool to go into the toolkit along with WinPE, WIMs, MDT, ConfigMgr. Many organisations already struggle with the best way to deploy and now we have a choice of bespoke vs MDT vs ConfigMgr vs MDM vs Windows ICD For remote installations, you need a delivery mechanism and the .ppkg files involved may be large The only applications that can be installed are Modern UI applications. PowerShell scripts and Win32 applications are in the long-term plan.   Deployment Tools and Kits Here are links to the toolkits you need for MDT and ConfigMgr to deploy Windows 10. Many are in beta or RC stage - I’ll update the links when the final versions are publicly available. MDT 2013 Update 1 Preview (Windows 10 support) ConfigMgr 2012 Service Pack 2 (Windows 10 support. Ignore the evaluation part. This applies for both 2012 and 2012 R2) Windows Assessment and Deployment Kit (Windows ADK) for Windows 8.1 Update (Windows 8.1 WinPE is used in ConfigMgr 2012 for deployment and works fine for Windows 10) Windows Assessment and Deployment Kit (Windows ADK) for Windows 10 Preview (Contains the Windows ICD)   Videos Here are a selection of videos from the MS Ignite conference in May 2015 that I found the most useful: What’s new in Windows 10 Deployment What’s new with ConfigMgr OSD and MDT Deploying Windows 10: Back to Basics Upgrading to Windows 10 in Depth Troubleshooting Windows 10 Deployment: Top 10 Tips and Tricks