This blog will be about Version 3 of the sort of Update Tool I have been or many am creating. This Update tool will make sure that some verified update files (As an example: AutoDesk) could be installed by a regular user (non-admin)
I will divide this blog into multiple parts
I need to add: It’s all about the idea because running apps in system context could be very dangerous!! You will need to make them install silently!
Some time ago we received a question if we could give the end-user the possibility to update DDS-CAD on their own. That resulted in Version 1 of the tool and also this blog
While writing that blog and the attached PowerShell script we realized we could use this for way more apps. That idea resulted in Version 2 of the tool and also another blog
After writing that particular blog, I felt like it still was missing some stuff but at that point, I received a nice email with the question if I could create a solution for end-users to give them permissions to update the Autodesk Apps
But before I decided to start creating the script itself I needed to do my homework by using google and reading first what Autodesk themselves have to say about this situation
Looking at the “Solution” above, it really doesn’t like a solution to me? So I decided to look further.
2. What options do we have?
After spending some more time searching for other possible solutions, I stumbled upon RunAsSpc (also mentioned on Twitter )
It seems okay, but somehow I didn’t feel right with the administrator password saved in an encrypted file somehow. So back again to the drawing board!
Again I started reading what “Autodesk” is telling us how you could update Autodesk.
So, Autodesk has an Update Tool themselves, which could be pretty useful?. I decided to download the AutoDesk Desktop app to look at how it functions. First I needed to sign in with an Autodesk account and I needed to have some Autodesk apps installed.
Normally when there are updates available you could install them as shown below by pressing update.
It will try to download the required file and after the update has been downloaded it will try to execute it. But when pressing the update button, the Update Manager would launch and it will prompt you to enter your admin credentials in a nice UAC screen.
So my first idea was just to only launch this Autodesk Desktop Tool app as system, just like I did with Sonos app installer. It worked at first… it launched the app within the system context but it failed to install the app updates itself. A lot of Autodesk settings are stored in config (ini) files in the user profile and that’s something the system account doesn’t have, as it is a service account. I guess because those config files are missing when running the Desktop Tool App running as system it will fail to launch the update installation.
Also in one of my last blogs, I added a big warning, telling you to be careful with ServiceUI. Here is a good example when you try to browse for files in the settings menu. You will receive a nice error that it couldn’t find the c:\windows\system32\config\systemprofile\desktop because It will try to open the %userprofile%\downloads folder and that one doesn’t exist!
Guess what happens when you press OK and browse for the CMD.exe in the above search bar?
As shown below…. that totally not okay!!!!!!… So again… please use serviceui.exe carefully!
So we could say, running the desktop app as System wasn’t going to solve our issue and it’s quite dangerous. So let’s take a look at another probably good option
As shown above, we could advise the user to just download all of the required updates? They could download them to the C:\temp\autodesk folder?. Once those files are downloaded we could make sure the regular user could install them by double-clicking the shortcut on their desktop.
This shortcut would launch a scheduled task to find those updates and install them one by one. So we updated the PowerShell script from version 2 to see what happens.
3. Take a look at the PowerShell Script
Normally I would advise you to use a PowerShell Encoded Command when you are creating a Scheduled Task but while writing the Script and improving it, it suddenly stopped working. At first, we didn’t know why but after some digging it was obvious, that we exceeded the maximum of characters you can use in an Encoded Command.
The maximum length of a PowerShell encoded command is 8190 characters. To fix this issue I needed to go back to my old idea to output the content to a file by using $content = @’powershellscript’@
But let’s start with the PowerShell script
As shown above, you could alter the variables of the deployment script to your liking because maybe you don’t want to be dependent on my website to fetch the serviceui.exe?
Let’s continue by looking at the next part below. In this part I am starting to create the PowerShell script itself by using the $content = @’ I showed you earlier. Looking at the script below you will notice I am also configuring some variables and toast notifications
Almost forgot to mention the fact, that I am also trying to detect if the device needs to reboot before you could install the App updates.
That’s pretty cool, right? but let’s continue!
As shown above, now the “Real Script” will launch. It tries to detect if there are any files in the c:\temp\autodesk folder and will create the necessary toast messages I am using to keep the end-user informed. We need to be sure we are launching verified files, to do so I am using the get-applockerfileinformation PowerShell Command
After the file is verified succesfully it will try to start the installation. Of course, you could add the silent parameters to make sure it will be a silent installation but beware each Update file could act differently!
Now we have the whole PowerShell script configured between the @ @ we still need to output it to a file.
To get the toast messages and the installation prompts from the system context into the user context we need serviceui, so let’s download it first if we haven’t already downloaded it.
Okay, now we have output the content to a PowerShell script, we still need to schedule it and change the permissions so a regular user could launch this task configured by the “System”.
Almost done but we still need to create the shortcut to the Public desktop folder and change the permissions on that PowerShell script. As shown below I am changing the ACL on the Powershell file to be 100% sure the user can’t mess with it!
4. The PowerShell Script
Now we have read the Explanation, please download the PowerShell script and take a look at it yourself!
5. The Results
Of course, the script still needs some work as I still need to take a look at some more AutoDesk updates files, because some of them have a different publisher or maybe I need to use some different install parameters. But it looks something like this.
In this video, I have placed a couple of files in the c:\temp\autodesk folder.
As shown above, some REAL Autodesk files and a not signed Autodesk File. So what happens when
- AutoCAD Architecture is installed
- A not signed file is executed
- A signed but not verified executable file is executed?
- We copy an additional install in it and run it a second time
Looking at the first version of the Update Script, it did its job perfectly… but each time we are spending more time on the Script it gets better. It is almost becoming an Endpoint Privilege Manager… ow wait… it’s coming!
Okay until the new Endpoint Privilege management arrives I still like my own idea a lot :).