From NSIS to MSI: Deploying the ownCloud Client on Windows
CC Attribution - ShareAlike 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Schmidt, Dominik
Shed some light on the change to MSI. Show usage of the .msi and ask for feedback. ownCloud is switching to MSI for packaging on Windows. This talk shows a few of the reasons and consequences. Live demos included. After the talk there's going to be enough time for questions.
 Please give a warm welcome to Dominic Schmitz. He has done tremendous work on making the own cloud clients actually enterprise ready from a deployment perspective. It's great work and I just hand over the microphone to him and thank you. Thank you John. Hello everybody. Welcome to my talk. As John already said, we're talking about deployment of the young cloud client on Windows. To begin with, I would like to ask you to raise your hand and ask a question at any point in time. You don't have to wait until the end of the talk or anything. Just ask. It's way more fun for everybody. At first, a few words about myself. My name is Dominic Schmitz. I'm D Schmitz on GitHub. I've worked on a lot of stuff. The first thing I did for on cloud was the elder plug-in. I ported the client to Windows, to Mac OS and lots of other stuff. Up until now, we were using Ansys for the installer of the client, which stands for Nullsoft Scriptable System because it was written by the company Nullsoft for Winamp back in the 90s, I think. And it's cool because it supports cross-builds from Linux and you get executable for Windows. It's kind of cool and we use that up until now. But it has a lot of issues. It has a really fragmented ecosystem. It uses a kind of strange scripting language that no one else uses. It's their own proprietary language and it's really hard to use. And we had a lot of issues with it. A lot of issues were hard to fix because of the fragmented ecosystem. A lot of plug-ins aren't properly versioned or anything. They are hosted in a wiki, in a zip file. And there's no way to know if they uploaded a new version or what's supposed to work together. So, yeah, we had a lot of issues. One issue we couldn't fix at all, which you can see at the top, it's the uninstaller, which is generated by Ansys itself and you can't sign it. So that was something that a lot of people complained about. So what are we going to do instead? We're using the Microsoft software installer, which is also known simply as MSI. It's a more standardized approach to software deployment on Windows. It's not the standard. There are a lot of standards, but it's one of the standards. And it has a really declarative nature. So instead of saying, I'm creating a program that installs a file here and installs a file there and does this and this and this, MSI sort of declares what it wants. It declares the state that it wants to achieve in the end. So you declare that you want a file in a specific location and Windows can take care of achieving that. So what we gain by that automatically is that we can remove a DLL from the onCloud client folder and Windows will know how to restore it just without doing anything special. So yeah, because it's a standard, it's used by all the tools that can be used for mass deployment, Microsoft tools and other third party tools use it. You have a standardized way of passing arguments to MSI packages. They are called properties. And you will see them later in the talk how to use them. You can also create transforms for MSI packages, which means you can apply changes. It's kind of a diff. So you can replace strings or replace images or you can preset properties on the MSI package. And you basically are free to do a lot of things. The downside is that you currently can't build MSI packages on Linux. We use a tool called Wix tool set, which used to be able to compile an MSI in wine, but that doesn't work anymore with recent versions of Wix tool set. So we decided against keeping our cross tool chain and switch to a native. So we have answers on the one side, which we can still build, but it's deprecated. So if you have issues with our new release, you still have the chance to use the old binaries with the old compiler and the old package format. But we really discourage it and it's not really supported. So what we did back then, we had an open SUSE VM and we used this main GW compiler with our custom tool set, custom packages for Qt and because it's still on Qt 5.6, we don't have HTTP.2 support. We had to use pre-built binaries for the shell extensions, which made it really hard to develop them. And as I said, this rather weird answers script language. On the other side, our new solution is based on MSI, it's supported, and we have a completely new build infrastructure. We are using Docker for Windows. We are using MS Visual C++ as compiler. We have the latest Qt version. We can build the shell extension as part of the client. And as I said, we use Wix tool set, which uses XML specification for the package it creates. So yeah, what does it look like if you install the MSI? This is the standard install wizard. And yeah, as you can see on the right side, you can select individual features and it's a standard Windows feature. Unlike the Ansys installer, which had kind of handcrafted options to also disable certain features, this is now implemented as proper Windows features. So you can have tools that show you what features package provides and you can just use the standard tools and you don't have to learn a new API for the installer. Of course, when we change the format for the installer, we also need to take care that users get the new package. So what we had to do, we had to add support for MSI, obviously. And we needed to implement a different invocation of the package. And that wasn't in the client version 2.4.1, I think. And it had, so we couldn't just add a new package to our updater server and expect the client to install it. So we had to go to an intermediate update that is now capable of installing the new MSI. So this has a rather inconvenient consequence. You have to install 2.4.3 via the auto updater and only then you can get 2.5. So if you get asked by the client to update to 2.4.3, you should do it because otherwise you won't receive updates in the future anymore. This is a bit unfortunate, but there's no really good solution to this other than keeping to always building the old package, which is obviously a lot of work for not much gain. For this, of course, customers with a branding subscription will also get support for the MSI in the client updater server. It's currently work in progress. It's basically done. It's just waiting for review and final QA. But it will be there soon enough when the brand release is ready. So probably most interesting for admins in the room might be now how you can actually install the MSI. The standard tool for at least for local installation is MSI-exec. You can just invoke it MSI-exec and the name of slash I and then the name of the MSI package in the file name. And it will just launch the installer that you just saw. If you want to script it, you usually don't want any user interaction to be necessary. So you can pass the passive argument, which is also a standard MSI-exec flag and nothing that we came up with. And also the reboot equals really suppress is a standard property, which I mentioned earlier, which you need to specify if you want to avoid a reboot in the end, which we need to enable the Explorer extension after installation. This kind of installation still shows a window with the progress bar, but requires no interaction. If you want to completely hide the window, there's also a silent installation with slash quiet or slash QN or simply slash Q, I think. You can also change the installation directory with the so-called install the property. You can simply specify any folder that you want just as you expected. You can find all of this in the documentation, which can be found under this URL. And yeah, I can simply show you what it looks like. I need to see how it works with the second screen. Interesting. Let's see. What's this called again? We'll move programs. As you see, onCloud is not installed right now. If it's running here, it's just a development build, but no package installed. And we can now go to PowerShell and, for example, just let's see. So there's also another feature, which I was just testing here. Emma, who was really helpful in testing the MSI with us and giving a lot of feedback, requested that when you just suppress the reboot, the exit code of the MSI is set to a certain number that says that a reboot is still required. And for the tool they were using, this was interpreted as an error. So we added another property that says, oh, yeah, please don't schedule a reboot at all. So it doesn't need to be suppressed. But it's not so interesting right now. So as I said, if you just use passive, you should see a, yes, it's signed. You should just see a probe. Well, I forgot, no restart. So if you just pass passive, then you will see a progress bar, but you won't require interaction, as I said. If you use quiet, you don't see anything at all, and it's completely silent. Maybe you can see a big report at Jane's, not much. Hope you enjoyed looking at the latest part. This again. What we should see now is that the size is correctly computed and the icon is correctly set and those were all issues that we had with the old Ansys installer that would have been possible to fix but that meant work and we just get that out of the box with MSI without further problems. So far it seems like a way more robust solution and less brittle solution like Ansys was. What you can also do in here is if you pass X for uninstallation, I don't know where the X is in that work but you can use that and then if you don't forget to type no restart which is the same as a suppress reboot then it will just remove it again. I think that's all I wanted to show you. I need to go back to my slides. Thank you for your attention and questions or feedback? No to the first question? Yes to the second. So they will eventually appear. It's not necessary to make an immediate reboot. It's just needed to restart the Explorer. So in theory you could also just kill Explorer Xer, restart it. Go ahead. You can. Okay so I'm repeating the question now which I forgot for the first question. The question is what happens if the user doesn't install 2.4.3 can the user still go to 2.5 without issues? Yes totally. So the MSI automatically uninstalls the old version and then installs the new one. So that's all the automatic updater does too. So the automatic updater just downloads the MSI and installs it. It doesn't even invoke the old uninstaller itself. Further questions? Then once again thank you for your attention. I think those are the most important things to take home with you. So thanks and bye.
 Please give a warm welcome to Dominic Schmitz.  He has done tremendous work on making the own cloud clients actually enterprise ready  from a deployment perspective.  It's great work and I just hand over the microphone to him and thank you.  Thank you John.  Hello everybody.  Welcome to my talk.  As John already said, we're talking about deployment of the young cloud client on Windows.  To begin with, I would like to ask you to raise your hand and ask a question at any point  in time.  You don't have to wait until the end of the talk or anything.  Just ask.  It's way more fun for everybody.  At first, a few words about myself.  My name is Dominic Schmitz.  I'm D Schmitz on GitHub.  I've worked on a lot of stuff.  The first thing I did for on cloud was the elder plug-in.  I ported the client to Windows, to Mac OS and lots of other stuff.  Up until now, we were using Ansys for the installer of the client, which stands for  Nullsoft Scriptable System because it was written by the company Nullsoft for Winamp  back in the 90s, I think.  And it's cool because it supports cross-builds from Linux and you get executable for Windows.  It's kind of cool and we use that up until now.  But it has a lot of issues.  It has a really fragmented ecosystem.  It uses a kind of strange scripting language that no one else uses.  It's their own proprietary language and it's really hard to use.  And we had a lot of issues with it.  A lot of issues were hard to fix because of the fragmented ecosystem.  A lot of plug-ins aren't properly versioned or anything.  They are hosted in a wiki, in a zip file.  And there's no way to know if they uploaded a new version or what's supposed to work  together.  So, yeah, we had a lot of issues.  One issue we couldn't fix at all, which you can see at the top, it's the uninstaller,  which is generated by Ansys itself and you can't sign it.  So that was something that a lot of people complained about.  So what are we going to do instead?  We're using the Microsoft software installer, which is also known simply as MSI.  It's a more standardized approach to software deployment on Windows.  It's not the standard.  There are a lot of standards, but it's one of the standards.  And it has a really declarative nature.  So instead of saying, I'm creating a program that installs a file here and installs a file  there and does this and this and this, MSI sort of declares what it wants.  It declares the state that it wants to achieve in the end.  So you declare that you want a file in a specific location and Windows can take care of achieving  that.  So what we gain by that automatically is that we can remove a DLL from the onCloud client  folder and Windows will know how to restore it just without doing anything special.  So yeah, because it's a standard, it's used by all the tools that can be used for mass  deployment, Microsoft tools and other third party tools use it.  You have a standardized way of passing arguments to MSI packages.  They are called properties.  And you will see them later in the talk how to use them.  You can also create transforms for MSI packages, which means you can apply changes.  It's kind of a diff.  So you can replace strings or replace images or you can preset properties on the MSI package.  And you basically are free to do a lot of things.  The downside is that you currently can't build MSI packages on Linux.  We use a tool called Wix tool set, which used to be able to compile an MSI in wine, but  that doesn't work anymore with recent versions of Wix tool set.  So we decided against keeping our cross tool chain and switch to a native.  So we have answers on the one side, which we can still build, but it's deprecated.  So if you have issues with our new release, you still have the chance to use the old binaries  with the old compiler and the old package format.  But we really discourage it and it's not really supported.  So what we did back then, we had an open SUSE VM and we used this main GW compiler with  our custom tool set, custom packages for Qt and because it's still on Qt 5.6, we don't  have HTTP.2 support.  We had to use pre-built binaries for the shell extensions, which made it really hard to develop  them.  And as I said, this rather weird answers script language.  On the other side, our new solution is based on MSI, it's supported, and we have a completely  new build infrastructure.  We are using Docker for Windows.  We are using MS Visual C++ as compiler.  We have the latest Qt version.  We can build the shell extension as part of the client.  And as I said, we use Wix tool set, which uses XML specification for the package it  creates.  So yeah, what does it look like if you install the MSI?  This is the standard install wizard.  And yeah, as you can see on the right side, you can select individual features and it's  a standard Windows feature.  Unlike the Ansys installer, which had kind of handcrafted options to also disable certain  features, this is now implemented as proper Windows features.  So you can have tools that show you what features package provides and you can just use the  standard tools and you don't have to learn a new API for the installer.  Of course, when we change the format for the installer, we also need to take care that  users get the new package.  So what we had to do, we had to add support for MSI, obviously.  And we needed to implement a different invocation of the package.  And that wasn't in the client version 2.4.1, I think.  And it had, so we couldn't just add a new package to our updater server and expect the  client to install it.  So we had to go to an intermediate update that is now capable of installing the new  MSI.  So this has a rather inconvenient consequence.  You have to install 2.4.3 via the auto updater and only then you can get 2.5.  So if you get asked by the client to update to 2.4.3, you should do it because otherwise  you won't receive updates in the future anymore.  This is a bit unfortunate, but there's no really good solution to this other than keeping  to always building the old package, which is obviously a lot of work for not much gain.  For this, of course, customers with a branding subscription will also get support for the  MSI in the client updater server.  It's currently work in progress.  It's basically done.  It's just waiting for review and final QA.  But it will be there soon enough when the brand release is ready.  So probably most interesting for admins in the room might be now how you can actually  install the MSI.  The standard tool for at least for local installation is MSI-exec.  You can just invoke it MSI-exec and the name of slash I and then the name of the MSI package  in the file name.  And it will just launch the installer that you just saw.  If you want to script it, you usually don't want any user interaction to be necessary.  So you can pass the passive argument, which is also a standard MSI-exec flag and nothing  that we came up with.  And also the reboot equals really suppress is a standard property, which I mentioned  earlier, which you need to specify if you want to avoid a reboot in the end, which we  need to enable the Explorer extension after installation.  This kind of installation still shows a window with the progress bar, but requires no interaction.  If you want to completely hide the window, there's also a silent installation with slash  quiet or slash QN or simply slash Q, I think.  You can also change the installation directory with the so-called install the property.  You can simply specify any folder that you want just as you expected.  You can find all of this in the documentation, which can be found under this URL.  And yeah, I can simply show you what it looks like.  I need to see how it works with the second screen.  Interesting.  Let's see.  What's this called again?  We'll move programs.  As you see, onCloud is not installed right now.  If it's running here, it's just a development build, but no package installed.  And we can now go to PowerShell and, for example, just let's see.  So there's also another feature, which I was just testing here.  Emma, who was really helpful in testing the MSI with us and giving a lot of feedback,  requested that when you just suppress the reboot, the exit code of the MSI is set to  a certain number that says that a reboot is still required.  And for the tool they were using, this was interpreted as an error.  So we added another property that says, oh, yeah, please don't schedule a reboot at all.  So it doesn't need to be suppressed.  But it's not so interesting right now.  So as I said, if you just use passive, you should see a, yes, it's signed.  You should just see a probe.  Well, I forgot, no restart.  So if you just pass passive, then you will see a progress bar, but you won't require  interaction, as I said.  If you use quiet, you don't see anything at all, and it's completely silent.  Maybe you can see  a big report at Jane's, not much.  Hope you enjoyed looking at the latest part.  This again.  What we should see now is that the size is correctly computed and the icon is correctly  set and those were all issues that we had with the old Ansys installer that would have  been possible to fix but that meant work and we just get that out of the box with MSI without  further problems.  So far it seems like a way more robust solution and less brittle solution like Ansys was.  What you can also do in here is if you pass X for uninstallation, I don't know where the  X is in that work but you can use that and then if you don't forget to type no restart  which is the same as a suppress reboot then it will just remove it again.  I think that's all I wanted to show you.  I need to go back to my slides.  Thank you for your attention and questions or feedback?  No to the first question?  Yes to the second.  So they will eventually appear.  It's not necessary to make an immediate reboot.  It's just needed to restart the Explorer.  So in theory you could also just kill Explorer Xer, restart it.  Go ahead.  You can.  Okay so I'm repeating the question now which I forgot for the first question.  The question is what happens if the user doesn't install 2.4.3 can the user still go to 2.5  without issues?  Yes totally.  So the MSI automatically uninstalls the old version and then installs the new one.  So that's all the automatic updater does too.  So the automatic updater just downloads the MSI and installs it.  It doesn't even invoke the old uninstaller itself.  Further questions?  Then once again thank you for your attention.  I think those are the most important things to take home with you.  So thanks and bye.
ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_0_71.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_72_251.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_252_431.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_432_515.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_516_647.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_648_1559.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_1560_3623.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_3624_4103.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_4104_8399.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_8400_18191.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_18192_19319.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_19320_19955.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_19956_22955.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_22956_25523.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_25524_27455.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_27456_27599.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_27600_27767.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_27768_27863.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_27864_28055.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_28056_28247.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_28248_28415.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_28416_28499.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_28500_28583.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_28584_28643.png ownCloud_conference_2018_From_NSIS_to_MSI__Deploying_the_ownCloud_Client_on_Windows_23yRuMbbGj4_28644_29079.png