MSI/GPO install

[jabuzzard]

Is there an easy way to get at the .MSI so I can create a transform to install it on my AD setup via group policy object? At the moment it seems to be wrapped up in an executable of some description, and the usual tools seem unable to "burst it open".

JAB

[Rick Brewster]

I'll paste here the instructions that I gave to someone else who asked about this. Unfortunately, it didn't work for him, but maybe you can get it to work and share with us how you got it working.

Paint.NET's installation is still MSI-based, but it's basically hidden from the user. We use a front-end so we can localize all the text, and so that we can build up a list of parameters to the MSI. I tried the MSI-wrapper I mentioned before and it fell over because it was an MSI running an EXE that then ran an MSI and Windows Installer is very adamant about doing one MSI installation at a time.

Run the setup wizard (i.e. PaintDotNet_2_5.exe), then while it's open make a copy of %TEMP%\PdnSetup\PaintDotNet.msi (stick on your desktop or wherever). 
Then close the setup wizard. The following command-line should get the installation you want:

msiexec /i PaintDotNet.msi /passive TARGETDIR="C:\Program Files\Paint.NET" 
DESKTOPSHORTCUT=1 JPGPNGBMPEDITOR=1 TGAEDITOR=1 CHECKFORUPDATES=0 CHECKFORBETAS=0 PDNUPDATING=0 SKIPCLEANUP=0 FRONTEND=1

Handling version 2.6 will be different (mostly for 64-bit vs. 32-bit stuff), but hopefully we'll have a better deployment story at that time.

Let me know if this works!

He mentioned that you have to make an "administrative install", which essentially creates a stub MSI and spills out all the files into a directory. You still need to make sure that those MSI parameters listed above are part of the client's installation.

Anyway, let me know how things go. We're still trying to get this sorted out so that everyone who wants to do this is able to do so. Thanks.

[jabuzzard]

I'll paste here the instructions that I gave to someone else who asked about this. Unfortunately, it didn't work for him, but maybe you can get it to work and share with us how you got it working.

Paint.NET's installation is still MSI-based, but it's basically hidden from the user. We use a front-end so we can localize all the text, and so that we can build up a list of parameters to the MSI. I tried the MSI-wrapper I mentioned before and it fell over because it was an MSI running an EXE that then ran an MSI and Windows Installer is very adamant about doing one MSI installation at a time.

Run the setup wizard (i.e. PaintDotNet_2_5.exe), then while it's open make a copy of %TEMP%\PdnSetup\PaintDotNet.msi (stick on your desktop or wherever).

Then close the setup wizard.

The first bit works I get an MSI and several other files, the exact purpose of all I have yet to determine.

However the reason it failed is quite simple. You have several rows set in the LaunchCondition table of the MSI one of which dictates that the MSI can only be launched from SetupFrontEnd.exe. Consequently launching it using msiexec is going to go nowhere fast.

I have taken the line out of the LaunchCondition table using ORCA from the MSI SDK and and I can then run it through the Wise InstallTailor. I have yet to work out how to move the shortcut in the Start Menu to where I want it, but it appears to work. At least I can deploy it via GPO into a test machine in a test OU.

One can also get rid of the administrator warning by taking out the other relevant line from the Launch Condition table.

JAB.

[Rick Brewster]

Umm ... no, you need to pass in all those MSI properties when you're installing it, such as FRONTEND=1. You should not remove the administrator privilege requirement. I listed the MSI properties and their values in my first post in this thread.

[jabuzzard]

Not wanting to put your back up, but did you read the bit where I said I ran it through Wise InstallTailor? Creates something called a MSI transform that deals with all the command line options in a different manner. I take it you are not familar with packaging and repackaging applications for deployment via group policy object or other similar methods?

As for the administrator install, do you wish to explain how an install via GPO is anything but? Warnings about administator installs when my 250 users next boot up their computer are utterly unwanted, will confuse them no end, and are completely pointless. The point is I know in advance certain conditions related to the install are going to be meet.

No offence but you really do not appear to grasp what I am try to achieve. Like I said in the previous reply I now have it installing perfectly fine completely unattended using a GPO in the Active Directory. The only thing left is to work out how to move the shortcut in the Program menu to a "Graphics Software" sub folder. There are several ways to achieve this it is just deciding which is the best way to do it in this particular case, and I ran out of time on Friday to do it.

[Rick Brewster]

Oh, I don't know much of anything about AD/GPO and deployment. That's why I've always asked whomever I've given these instructions to to please tell me if it works or not (you're the first to actually report back success). When you said "Wise Installer" the only thing that came to mind was the old 16-bit based Wise installation system that is ... very very old. I didn't know there was a thing called InstallTailor (refer back to the first sentence, of course).

Anyway, the the MSI requires "privileged" execution, not for the user to actually be in the Administrators group (SetupFrontEnd.exe does require this). Apparently this allows the MSI service to run the installer for a normal user but in the context of elevated privilege. That's the gist I got anyway, and it worked great for v2.1's MSI for this type of deployment. So I just don't understand why you had to remove it.

The FRONTEND=1 requirement is just because there's a bunch of MSI properties that won't be set up correctly if you just double-click the MSI (the ones that were detailed before). So it's there to prevent users from casually doing a bizarre installation.

The Programs shortcut is actually created by a SetupNgen.exe program that we run as a custom action. It also handles things like ngen'ing our binaries. Do MSI's normally allow you to easily retarget where the shortcuts are made? We create shortcut ourself because we need to manage things like not creating the icon again during an update -- people don't like it when they move the icon elsewhere and then you (as in "me") stick it right back where they didn't want it. It would be easy enough to add an extra MSI property that gets forwarded to this exe that determines where to place the shortcut in the Start Menu.

Anyway I came off as rude in my previous post, so for that I apologize. It was way too early in the morning for me to be in a cordial mood, especially with the deluge of issues that've been coming in for my other project (the one I actually get paid for).

[Rick Brewster]

Unless I am badly mistaken all I was doing was removing a check and it's warning that you need to be running with Administrator priviledges because I know in advance I am going to be meeting these requirements.

Here's what MSDN has to say about the Privileged property:

The Privileged property indicates whether the installation is performed in the context of elevated privileges. The installer sets this property if the user has administrator privileges, if the application has been assigned by a system administrator, or if both the user and machine policies AlwaysInstallElevated are set to true.

...

Developers of installer packages can use the Privileged property to make the installation conditional upon system policy, the user being an administrator, or assignment by an administrator.

Maybe something is causing the Privileged property to not be set? For what you're doing I believe it would naturally be set to 1. If it is actually running with Administrator privilege then removing the check should not cause any harm.

Given the way the install works I would say that an extra MSI property that is handed to the exe to determine the start menu location is the best way.

This will be there for the v2.6 release. Won't be hard to implement. Just something like, PROGRAMSGROUP="Graphics Software". Default will be an empty string which places it at the top.

[aradke]

Hi,

Is there any chance that you could either post your MST or open it in Orca and copy down exactly where and what settings are changed by it? I am getting so many requests to install Paint.net across our network that I'm now at the point where I'm going to have to roll it out organisation wide or face being lynched. ;-)

Thanks,

Andrew

[Rick Brewster]

aradke, What sorts of trouble are you having with deployment?

[Rick Brewster]

The Staging directory is something we use so that the MSI is always in a known location. Lots of people have reported errors such as "The file you've requested is on a network resource that is unavailable" Windows Installer made some weird decision about our installation.

You might be getting that SetupNgen error because the directory doesn't exist when you install using only the MSI. I've added a check so that that won't happen in 2.6.

[aradke]

So at the end of this process do we have a group of settings for an mst that we all agree on?

If so can we create an mst that can be made available for download on the Paint.NET website?

[aradke]

At this point it sounds like 2.6 is not too far off. I would be more than happy to lay the .mst issue to rest for now if I knew that 2.6 would ship with suitable defaults within the stock msi except for one thing; dotnet 2.

I'm sure there are a tonne of reasons for moving from 1.1 to 2.0 but at this point in time Paint.net would be the only application within our organistion that would require it. For this reason I would be expecting to stay with 2.5 for some time and I think a lot of other organisation's would be in a similar position.

As such I think that it is a very important that a suitable .mst (or possibly a modified .msi) is published.

[Rick Brewster]

Yes, there are many reasons for us to migrate to .NET 2.0

The current plan is for the setup program to support something like a /adGpoPrep command-line switch that would give you a copy of the MSI's that are set up properly. Since we support x86, x64, and IA64, there will be 3 MSI's and you'll have to figure out which ones go to which systems (I'll willing to bet you have a very small IA64 population ...)

[Rick Brewster]

Ok here is what I've come up with for v2.6 related to AD/GPO deployment and whatnot. You'll see this in the Beta 2 release (Jan 16th) so it'd be great if someone could test actual AD/GPO deployment at that point.

* We will still only distribute the EXE based installer.

* The EXE installer will support a command-line option, called something like "/createMsi".

* This will create a folder on your desktop(1) called PaintDotNetMsi.

* Three MSI's will be dropped in here: PaintDotNet.*.msi, where * is x86, x64, and ia64. These are for 32-bit, 64-bit, and Itanium platforms.

* The ProductCode for each will be unique, as per the requirements in the Windows Installer documentation. We actually just take the very last byte in the GUID for x86 and add 1 (with rollover) for x64, and add 2 for ia64.

* The x86 MSI will have a LaunchCondition that prevents its installation on 64-bit Windows. Trust me, this is necessary. Otherwise you end up with part of the installer thinking things go into Program Files, and part of the installer thinking things go into Program Files (x86), even if you explicitely set the installation directory to Program Files.

* Any other MSI properties that you specify on the command-line with /createMsi will be patched into the MSI's -- no need for transforms or anything after the fact.

* The default settings will not enable update checking.

* The FRONTEND=1 and Privileged=1 launch conditions have been removed. The GUI setup wizard checks for those anyway.

* When Paint.NET installs, it uses NGEN to precompile its assemblies. However, this can take awhile. So, if you want, you can add a QUEUENGEN=1 property to only queue up the compilation at which point .NET will compile them when the system is "idle". This corresponds to the /queue option when we call ngen.exe.

* The PROGRAMSGROUP property allows you to specify what Start->Programs group the Paint.NET shortcut is created in. By default it is an empty string which places it loosely at the top of the hierarchy with the likes of MSN Messenger and Windows Movie Maker.

* You may set the default language by setting the HKLM\Software\Paint.NET\LanguageName registry key. The application will first look in HKCU and if it doesn't find that it'll look in HKLM. Basically, install it yourself and set the language to what you want, then copy down what the registry key value ends up being from your HKCU.

(1) We can't just dump everything in the current directory because the EXE installer unpacks a bunch of files to %TEMP%/PdnSetup and runs our code from there. So we don't know what "your" current directory is.

Further comment and suggestions are definitely welcome on this!

[Zoom7000]

Thanks for that Rick, just tested this on my network using SMS. Works fine. Just a quick question, are the following properties still valid?

DESKTOPSHORTCUT=0

JPGPNGBMPEDITOR=1

TGAEDITOR=1

CHECKFORUPDATES=0

CHECKFORBETAS=0

PDNUPDATING=0

SKIPCLEANUP=0

I'd like to be able to set Paint.Net as my default editor for JPG, PNG, BMP etc, and also I'd like the option not to have the Installation put a shortcut on the desktop. So is this all still possible?

Thanks

Zoom7000

[Rick Brewster]

Thanks for that Rick, just tested this on my network using SMS. Works fine. Just a quick question, are the following properties still valid?

DESKTOPSHORTCUT=0

JPGPNGBMPEDITOR=1

TGAEDITOR=1

CHECKFORUPDATES=0

CHECKFORBETAS=0

PDNUPDATING=0

SKIPCLEANUP=0

I'd like to be able to set Paint.Net as my default editor for JPG, PNG, BMP etc, and also I'd like the option not to have the Installation put a shortcut on the desktop. So is this all still possible?

Thanks

Zoom7000

You should just have to set DESKTOPSHORTCUT=0. The other options are already set. Read the "Unattended Installation" topic in the help file for more info.

[Zoom7000]

Just installed 2.6 Final using the command line:

PaintDotNet.x86.msi /qn DESKTOPSHORTCUT=0

Works Fine!

Thanks Rick!

[Rick Brewster]

Zoom7000, if you specify DESKTOPSHORTCUT=0 as a commandline parameter along with /createMsi, then that property will be patched into the PaintDotNet.x86.msi file and you won't need to specify it when executing the .msi itself.

[Zoom7000]

Zoom7000, if you specify DESKTOPSHORTCUT=0 as a commandline parameter along with /createMsi, then that property will be patched into the PaintDotNet.x86.msi file and you won't need to specify it when executing the .msi itself.

Thats brilliant Rick, Thanks for that!

Keep up the great work!

Zoom7000