Sciteforautoit3 not "sysprep" capable

[MattHiggs]

Hey all. I have a deployment server set up in my home environment from which I create, capture, deploy, and all-around test different deployment technologies for use in an enterprise environment. As many of you may be aware, sysprep is the tool which one would run on a "reference computer", from which a custom install image will be captured to deploy the same operating system to other devices, to generalize it and remove "machine-specific" information. As a part of my personal operating system deployment, I have autoit and Scite4autoit3 installed as part of the image. However, when this image is installed, scite4autoit3 does not function properly. Allow me to elaborate. Scite4autoit3 store certain, important configuration files for the tools it uses in the users "Appdata" directory. Unfortunately, unless the "copy profile" flag is set during the capture process (not a good idea as this can result in permission issues with other applications that are stored in "appdata"), the "appdata" folder is not copied into the capture. The most prevalent issue that I find results from this is, when attempting to launch "code wizard" from within Scite4AutoIt3, I get an error message saying "Required file not found (C:\Users\{Username}\Appdata\Local\AutoIt v3\SciTE\CodeWizard\colors.ini)

CodeWizard will now exit!!!". Copying the "colors.ini" file from the Program files installation folder of scite4autoit3 to the specified folder resolves issue, but I just thought I would make people aware if this was not known, as I am sure that code wizard is not the only tool with configuration files in the AppData folder that don't work properly on an os that is deployed with it pre-installed.

[Jos]

You findings are correct.
Do you have any proposal how this could be done better considering the SciTE and it's utilities settings are stored per Username?

So you either need to do the installation after you installed windows for the targetted user or you can make the whole installation portable, meaning all config files are stored in the directory the program resides.

Jos

[orbs]

saving personal settings in users' profile, while the executable and other program files are stored in the Program Files folder, is common and sensible procedure.

what is not sensible is that an application crashes if there is no personal settings file. lack of personal settings is common for first run of any application; and the application should then start with some hardcoded defaults.

i was going to say that this should be communicated to the author of SciTE, but i just visited the code for CodeWizard and i see it's an AutoIt script (oddly, i did not find the exe thought, just the source code file CodeWizard.au3).

i'm using AutoIT v3.3.14.2, SciTE v3.6.2

so i think the proper solution would be to ask the AutoIt dev team in charge of the SciTE utilities, to modify the utilities to include hardcoded defaults, in case no personal settings file exists.

EDIT: updated SciTE to v3.6.6, i see no change in behaviour.

Edited July 23, 2016 by orbs

[Jos]

The behavior of SciTE and most utilities is supported by me, but CodeWizard is an odd one as the original authors aren't around anymore.
Any change proposals are always welcome. just submit the proposed Source update and changes implemented. I will review and implement it in the source provided by the installer.
As to the "No EXE" comment: All AutoIt3 script utilities in the SciTE4AutoIt3 installer are ran as source with AutoIt3.exe as the compiled versions were causing False positives  and even flagging the Website to be an dangerous site to go to by google. Hence the change.

Jos

Edited July 23, 2016 by Jos

[MattHiggs]

Is there a way to make it so that the the data stored in Appdata folder is copied to the default user profile upon sysprep?  I have been using a few resources/scripts to accomplish this for certain registry keys (like Windows explorer settings for example), but not for use when sysprep is run.  Sysprep kind of frustrates me: for a tool meant to make windows installations more "customizable", venturing too far outside the norm (like say, uninstalling default windows store apps in windows 8 and above) will break it

http://stealthpuppy.com/customize-the-windows-default-profile/

 

But as for the error, the only suggestion that will work will most likely be to move any files which are required by the application to run out of the user profile folder or any of its sub-directories. 

Set-RegistryValueForAllUsers.ps1

Edited July 29, 2016 by MattHiggs

[JLogan3o13]

On something of a broader side of the topic, if you're deploying images in an enterprise environment, whether through Altiris (yes, it's still out there), SCCM, etc., you have to know that best practice is to install just the OS with updates. If you look through the MS documentation for Config Manager, for example, the suggestion is to capture only your OS, then use the task sequence for installing device-specific drivers. Once the OS is installed, you then use collections to properly deploy software. I service a number of clients, from 10-PC Mom and Pop shops to Universities, and have repeatedly seen (and been called in to resolve) issues with either trying to capture all the applications in the image or trying to deploy the applications through the image task sequence. It just never seems to work well for them.

I realize you are doing this in your home lab, but if you are translating that to your enterprise environment it might be worth thinking through whether you want to capture AutoIt in the image or just repackage it into an MSI and deploy after the fact.

[orbs]

@JLogan3o13,

2 hours ago, JLogan3o13 said:

... best practice is to install just the OS with updates ...

that is a matter of opinion and experience. i find it quite the opposite - the whole concept of an image is to have all applications preinstalled. i've been using Altiris configured by deployment team exactly as you suggested, and guess what? to all deployments i've included the task sequence for all (well, almost all) applications that anyone in our scope may be using. this saves so much work building task sequences for different users groups. hey, user: the app is there. don't need it? just don't use it.

then i've done the same with a faculty network of near 700 pc's, using Ghost Server (i wonder if that still exists...) everything is preinstalled, use only what you need. sure, it bloats the image; but that's a decent trade-off.

and yes, you have to do it right; i.e. avoid conflicts between versions and dependencies. but when you do it in advance, you solve the conflicts before they reach the end-user. when you leave that part to every individual deployment, as you suggest, you take the risk of running into walls at real-time, when the user needs a working pc. if you're lucky, you can get an ad-hoc, tailor-made workaround; you have no time to put together a formal solution.

oh, and - 

2 hours ago, JLogan3o13 said:

... If you look through the MS documentation for Config Manager, for example, the suggestion is to ...

the guys at MS, especially at the documentation department (which often makes me feel like it's quite a different department than the dev & QA) are hardly real-life sys.admins. their "suggestions" are based on naught, and should be treated as such. often i find them inane.

@Jos,

the CodeWizard.au3 has this in it:

If @Compiled Then
    DirCreate($CodeWizardIniPath)
    FileInstall("colors.ini", $CodeWizardIniPath & "\colors.ini")
EndIf

if i read it right, then i conclude that if you make the SciTE installer include the file colors.ini in the same path as CodeWizard.au3, and cancel the @Compiled condition, it should solve the issue.

@MattHiggs,

1) can you check the above? i.e. before you sysprep, include that file as i suggest, and after deployment, remove the @Compiled condition and check?

2) are there any other SciTE utilities that exhibit the same behaviour?

 

Edited August 2, 2016 by orbs

[Jos]

8 minutes ago, orbs said:

the CodeWizard.au3 has this in it:

If @Compiled Then
    DirCreate($CodeWizardIniPath)
    FileInstall("colors.ini", $CodeWizardIniPath & "\colors.ini")
EndIf

if i read it right, then i conclude that if you make the SciTE installer include the file colors.ini in the same path as CodeWizard.au3, and cancel the @Compiled condition, it should solve the issue.

That really needs changing so we don't have an color.ini in the scriptdir, which will only be confusing. Maybe one day I will take the time to go over that script and change it in a way I can/will support it, unless somebody else feels the urge to do so.

Jos

[JLogan3o13]

1 minute ago, orbs said:

@JLogan3o13,

that is a matter of opinion and experience.

You are correct, it is the opinion of the larger number of people that do this for a living, based on their experience. Hence why it is called "best practice".

Quote

the guys at MS, especially at the documentation department (which often makes me feel like it's quite a different department than the dev & QA) are hardly real-life sys.admins. their "suggestions" are based on naught, and should be treated as such. often i find them inane.

I happen to disagree strongly, as I work with many of these gentlemen, and feel your statement comes from a source of ignorance regarding their abilities. I guarantee you, should you ever sit for the MCTS or beyond, you will see plenty of real-world examples of why the approach you speak of is not the most practical.

I am glad it works for you in your smaller environment. For my current customer, with more than 65,000 PCs, I would not do them the disservice of a hap-hazard approach. Let's call it a difference of professional pride

[MattHiggs]

From what I have read, you are both right.....  Microsoft specifically says that the applications which are pre-installed in the OS image have to be "sysprep-compatable".  You should take a look at the documentation on their deployment site which describes the difference between "fat" and "thin" images: both of which are completely valid and work.  Also, the whole point of pre-installing certain apps is to save time.  For example, say you had windows 7 os with office 2013 (not 365 version) and also needed to install visual studio with almost all its features.  The installs alone would take almost an hour, lest I mention the Windows updates which you will have to wait for as they download and reboot your pc (Windows can't install updates for which it doesn't have software at the time, since updates are installed in custom capture but no software).  As to how one determines if a application is sysprep compatible is beyond me, but I would think that a very large portion of it would have to do with if the program files are not actually stored in "program files", but actually are in "app data" (eg Spotify and bittorrent sync) and being a Microsoft product couldn't hurt either.  Again, that is not 100% the case, as I do not know exactly what will transfer over vs not, break something, etc.  For example, for one of the very first corporate deploys I was in charge of 3 years ago, they wanted all the applications pre-installed.  However, this also included the Cisco VPN client software that the company used at the time, which, for those of you who have tried sysprepping a machine with the Cisco VPN client know, completely breaks the deployment (bluescreened AFTER the sysprep and capture had taken place.  So I had essentially just captured a useless image lol).  Only after extensive searching did I find that the Cisco VPN client had one particular registry key that it installed which blew the whole thing out of the water.  In summation, you are both right and wrong....there is no right answer.  Its a matter of preference.  Oh, and JLogan3o13, I actually only use a combination of Windows deployment services and Microsoft deployment toolkit.  I don't  have the quantity or quality of hardware to either build physical or virtual servers to incorporate SCCM into the mix.  That in of itself is a monster that I would rather just stay away from.  I can write powershell or Autoit scripts to do what I need within my particular scope of operating system deployments.

 

Edited August 2, 2016 by MattHiggs

[JLogan3o13]

Fair enough, @MattHiggs, I get that SCCM (or Altiris, back when it was worth anything) is a beast in and of itself, and not all environments use it. I've done a number of customers with just MDT as well. 

Just out of curiosity, if you build an image and include, just as an example, Flash Player. When the new version comes out, you update your image to reflect this. What is your method then for cleaning up those machines that have the older version, or do you just wait for a re-image scenario?

[MattHiggs]

I use chocolatey.  Awesome tool.  Just run "choco upgrade flashplayerplugin -y".  Oh, and after the deployment completes, as the "command to run when mdt completes" (I forget what the custom setting variable is), I run a boxstarter script hosted on gist to automatically perform certain configurations, download modules, etc.  There are so many way to automate processes nowadays.  I love it!!

Edited August 2, 2016 by MattHiggs

[MattHiggs]

I have had the pleasure of recently writing a couple of packages to host specifically for company deployments.  What a learning curve...  Can't say I have ever done or experienced anything quite like it

Edited August 2, 2016 by MattHiggs