Nick Heim

Download the actual Windows release. Get the MSI. But first, install all the prequisites!

A packaging machine is exposed to the internet and reaches out to dozens of server on the net every day and should therefore be hardened and downlocked. Recommended installation is per user into the profile, which is used to run AutoPkg. This user profile should have not more than standard user rights. For this to work, the MSI have to be advertised with admin rights and the following command:

msiexec /jm AutoPkgWin.msi

CAUTION: This needs an elevated CMD-shell! PS-console does not work!

After this, the Installer can be run with standard user rights.

AutoPkg for Windows requires Windows 10 / Server 2016 or newer, Windows 32 or 64bit and to have Git installed is highly recommended, so managing recipe repositories is possible. Knowledge of Git itself is not required but helps. Tested only on 64bit!

Easy route: With this script (AutoPkg-PreReq-Installer), you can install everything needed, in one run.

Step by step instruction:

The following software and tools are needed as prequisites to run AutoPkg on Windows:

• Python 3.8.x: or 3.10.x Download (Caution: pythonnet is still not compatible with Python 3.9/3.10)
  • (Python 3.10.x works with pythonnet v3.0.0-alpha2 with: pip install pythonnet –pre)
  • Needed libraries: pyyaml, appdirs, msl.loadlib, pythonnet, comtypes, pywin32, certify
  •  If Python is present, those libs are automatically installed by the AutoPkg installer.

• Git (highly recomended): Download

• 7zip: Download

• Windows-Installer-SDK: Download, You have to select a version, that fits your OS. This is necessary for some of the MSI-related processors.
  • Download the webinstaller, choose a download directory and select at least: “MSI Tools”, “Windows SDK for Desktop C++ x86 Apps” and on x64 systems also “Windows SDK for Desktop C++ x64 Apps”, (there will be some additional selections).
  • Then install at minimum: “Windows SDK Desktop Tools x86-x86_en-us.msi” and “Windows SDK Desktop Tools x64-x86_en-us.msi” (x64 only).
  • Find the install location (Somewhere under C:\Program Files (x86)\Windows Kits…)
  • Copy the Wi*.vbs and Msi*.exe files over to your MSITools folder.
  • Register the 64bit mergemod DLL: regsvr32 “C:\Program Files (x86)\Windows Kits\10\bin\xxx\x64\mergemod.dll”
  • If the SDK is present, this COM DLL is automatically registered by the AutoPkg installer.

• Wix-Toolset: Download, version 3.11 should do it. Although, i always use the latest development version.

• MSBuild: Download, THE Windows Make!
  • Install commandline: vs_buildtools.exe –add Microsoft.VisualStudio.Workload.MSBuildTools –quiet

• NANT: Download (Deprecated), this is one of the predecessors of MS-Build (which you should use, when starting with a new build-enviroment).
  • Download the ZIP package, extract it and copy the “nant-0.92” folder to the Tools dir.

Quite a long way from very early adventures with AutoPkg on Windows. Nick McSpadden started it on June 2018. See: https://twitter.com/mrnickmcspadden/status/1011422819853324288.
In early 2019, I was talking with my colleagues Max and Graham about automating the provisioning of packages in there deployment system (JAMF). Jealously, I had to admit, that such a framework was the missing thing in our work of provisioning software into our Windows deployment system (baramundi.de).

That talk did its work and did not let me go… And as a complete novice on Python, i began to poke around the code on https://github.com/autopkg. Naively, I downloaded that stuff and tried it on Windows, which instantly told me, that there were Python functions in use, which were OSX only and not available on Windows. Too bad. ☹

But at the end of February 19, light at the end of the tunnel! Max pointed me at the tweet mentioned earlier. And YES, with the modifications from Nick’s fork, it ran on Windows! From there to the system we have today, it was a long way. Almost 100 recipes and more than 2 dozen processors are doing a great way of saving time and creating much more reliable packages, we ever had before.

So, if you want to try it out for yourself, in about half an hour, you can build a machine, that is ready for AutoPkg.

When i first heard the intention of Mozilla, to abandon the XUL-extension-interface, i was shocked.
How the hell should i deliver a satisfying user experience to our customers, without multi-language interface, Noscript, Adblock and custom configuration?
In the meantime, FF57 has landed, the dust is blown away and our first in-house release of Firefox 57 (57.0.2) is on the deployment system.
What features and extensions did survive the extreme renovation?
First of all: Noscript and Adblock Plus
Further more: Multi-lingual feature with all our Languages spoken here in Switzerland, which automatically follows the OS-Language.
And least but not last: An even better implementation of the GPO-Extension for Firefox!

To achieve all this, quite some work was needed.
The multi-lingual interface, which in theory was already there through the function of the pref “intl.locale.matchOS”, was never usable on Windows.
This is now fixed from V57 onward. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1413866
Zibi, thank you for your fast, straight forward approach and work!

The GPO functionality has been moved to Autoconfig/CCK2.
Thank goes to Pavel Kardash @ https://mozillagpo.sourceforge.io/ for putting together a perfect working Javascript-Module for this.
Just create your autoconfig with the famous CCK2 from Mike Kaply (https://mike.kaply.com/cck2/) and append the 2 lines to cck2.cfg to call the gpo.jsm and you are done!

Adblock Plus seems to work on FF57 out of the box like always.
Noscript is a bit trickier. We had to wait for several week, until with 10.1.5.7, it was quite stable and usable again.
Another story here is to deploy a custom default white-list. We could not find a way to populate this in Autoconfig with Javascript. Maybe later…
In the meantime, we use the default profile functionality from CCK2 to copy a preconfigured “storage-sync.sqlite” file to new profiles.

And with the help of NANT, WIX, 7zip and Powershell, a fully automated build process, gives us a stable MSI-package and several Transforms, in less than 10 min.

The Thinkpad T440p is a real nice device… if there wouldn’t be the missing physical mouse buttons when working with the trackpoint.
Lenovo/Synaptics tried to sacrifice the buttons in favor of a bigger touchpad… and failed gloriously!
Fortunately, they realized it (with the help of thousands of users…) pretty quick. The successor of the T440 series, the 450 had the buttons back on it!
And even better: Those T450 Touchpad-Buttons-Combo is compatible with the T440 series.
And yes, they are sold for € 20-30 on ebay. I bought one from here.
To actually do the work, you need the maintenance manual. Lenovo has it online for most of their products. You can get it here.
Unfortunately it is not quite accurate, when it comes to the removal of the keyboard bezel, which houses the trackpad.
There are a lot of unnecessary steps listed. You only need to remove the battery, the big door and the optical drive to detach the bezel!
Be careful with the removal of the old touchpad! There are 2 cables! One ribbon cable which is clearly seen. And a second, black one with 3 leads on the right side (when looking at the screws)! The new Pad did not have this second cable anymore.
After the assembly a first test… a disappointing one: The buttons had no signs of life! at least, the touchpad was working.
That led me to the assumption, that there must be a configuration problem.
Some googleing later, it slowly appeared, that there must be a configuration problem in the Win10 – Synaptics-driver – BIOS (PCIID) triangle.
It looks like, that the touchpad itself does not have any intelligence on it. That means, even when you change the pad, the PCIID stays the same.
The blog of Cameron Gray was a big help in this findings. And down in comments of his blog, there is a guy, nicknamed “flyoil”, who outlines a possible solution. However, for this to work, one has to break driver signing and disable automatic Updates for drivers, because he changes the drivers INF file, to connect the existing PCIID with the new touchpad.
That led me to the idea, to look for the differences between the installations for the old and the new pad. After a (longer) look at the INF-file, i was left with only 12 registry keys, which where different! In detail:
The PCIID of the Touchpad on my T440p is ACPI\LEN0039
The PCIID of the Touchpad on an T450s is ACPI\LEN200E
So, I installed the latest Synaptics driver from the T450s driver page (jbg211ww.exe), which installed the driver group 12 (see SynPD.inf for details). After that, i searched the x64/SynPD.inf file for differences between
[LENOVO_GROUP41_InterTouch_Inst]
and
[LENOVO_GROUP12_InterTouch_Inst]

The following registry entries sets the right configuration for the new pad:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SynTP\Parameters]
"ExtraCapabilities7Add"=dword:00010000
"ExtraCapabilities7Mask"=dword:FFFFFFFF
"ProcessUnexpectedResetDuringDetection"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Synaptics\SynTPEnh]
"ScrollMethod"=dword:00000005
"SynapticsScrollMethodSpeedFactor"=dword:00005000

Put this into a REG-file and apply it with admin rights and after a reboot, the buttons are in full business!
Good luck,
Nick

Hi folks,
finally, i found the time to publish an piece of extra software, which we successfully used for years.
The basic is the GPO for Firefox Extension from here:
https://addons.mozilla.org/de/firefox/addon/gpo-for-firefox/
See also:

However, since we use GPO’s for different Mozilla-products, we changed the keys, where the Policies are written in the registry.
Computer context:
HKLM/Software/Policies/Firefox
HKLM/Software/Policies/Firefox/locked

User context:
HKCU/Software/Policies/Firefox
HKCU/Software/Policies/Firefox/locked

Therefore, the paths in the ADMX-template point to this locations.

There are still a lot of preferences missing from the template. But it’s a start and adding new ones is not that hard.

gpo_for_firefox-0.9.2-fx-ETH.xpi
Firefox.admx

Here is Version 1.1 of the ADMX-Template to control important settings in Adobes Acrobat and Reader. Now with support for Acrobat/Reader X.
New feature is the the control of the protected mode, which was introduced in Reader X.

Here is an newly created ADMX-Template for disabling the most dangerous security issues in Adobes Acrobat and Reader. With it, you can disable JavaScript globally for version 7-9 of the mentioned products. There is also an option to block JavaScript functions with an entry into the blacklist. It has been done in ADMX to make use of the new Central Store functionality introduced in Server 2k8 AD.

Hello, dear reader.
Welcome to my blog. On this site, i will post different aspects of Windows deployment.