I want to deploy Code::Blocks on SSCM. Unfortunately, a weird behavior is observed when \SYSTEM is used (for instance, it doesn’t show in the control panel among other things). I seldom observed this issue for other apps as well. The behavior is not the same if you install as ADMIN and as SYSTEM (both targeting a machine install in c:\Program Files).
That’s when I came in contact with the toolkit for the fist time and discovered the Execute-ProcessAsUser function that somehow use a scheduled task to transfer the install to the current user. So far so good… Tested with psExec.exe that mimics SCCM and SYSTEM. Works as expected as long as the user is an Admin.
That’s where things get complicated. I went as a regular user and tried to deploy the app. After investigating, I noticed that the task created by the toolkit failed to start with code 2147943140. I checked and it seems that is is related to the fact that the user doesn’t have admin rights… But isn’t Execute-ProcessAsUser function meant to transfer rights to solve this kind of problem? Is there a solution or a best practice to deploy such application on SCCM ?
I never say it was magical! lol So if a non admin user is logged in, it won’t work. Since yesterday, I searched and someone told me that it may be possible to mimic a user session with ServiceUI.exe from the Microsoft Deployment Toolkit. I am yet to explore this avenue.
The whole point of doing this is that Code::Blocks has a crappy installer that puts shortcuts in the user profile instead of the %ALLUSERSPROFILE% so if you run as the SYSTEM account you won’t see the shortcuts or the ARP entry in the Control Panel.
Don’t bother with ServiceUI.exe. It just shows SYSTEM’s GUI so that the user can see it.
I think it’s because Code::Blocks is installed in the user’s profile. Why have shortcuts %ALLUSERSPROFILE% that only one user can use?
BTW: If you want all users on a computer to use Code::Blocks, you are going to have to use Active Setup.
The catch? Uninstall will be a pain to automate.
You just hit the core of the problem. I don’t care about the shortcuts indeed. If I do a SYSTEM install, there is no installString. The installer is dumb and put that string into HKEY_USERS(logged user).…
For the rest, the app seems to work. But as you say, Uninstalling is an issue. That’s why I tried that thing above. I realize it is not good anyway since if any other user log on that PC, the uninstallString won’t be visible since it is in another user registry.
Asymmetric behavior between a SYSTEM an an ADMIN install happens more frequently than I though. I have Python 3.5+ in mind: The installer drops the uninstaller in the logged user files but meh… SYSTEM has not such folders! It comes with 10 components and if you try to uninstall them one by one, some will remain… Anyway.
That’s why I am looking for good practices for these kind of rogue apps that behave this way. A good sccm deployment for us is one that can install/uninstall. Usually, we like to uninstall any previous versions before installing the new one (sometimes it is better just to update without installing depending of the app).
Then, if my approach is not good, I wonder what people does when they encounter these kind of situations… Thanks for helping btw!
RE: I wonder what people does when they encounter these kind of situations…
Search for Teams from MS. It’s installed in the user profile too.
Maybe you can use the same tricks.
Another way is to use PSADT instead of the Code::Blocks installer (CrapApp permitting)
Try to move the EXE to an other folder and see if it still works.
I’ve repackaged some CrapApps and all I had to do is massage the registry, shortcuts. Active setup helps too. Maybe capturing what the installation does and reworking the installation to be multi-user aware.
The real issue is the laziness or clueless-ness of the Code::Blocks team itself when it come to packaging.
“Search for Teams from MS. It’s installed in the user profile too.
Maybe you can use the same tricks.”
We like to avoid this because this is unmanageable if you like to keep the apps up to date.
“Another way is to use PSADT instead of the Code::Blocks installer (CrapApp permitting)
Try to move the EXE to an other folder and see if it still works.”
Never tried… Is there a tutorial somewhere… Maybe it’s good to know.
“I’ve repackaged some CrapApps and all I had to do is massage the registry, shortcuts.”
I though of populate the registry entry myself…
“Active setup helps too.”
Maybe! Never used it.
“Maybe capturing what the installation does and reworking the installation to be multi-user aware.”
What tool do you use to do this?
Since the app is going into %Program Files% and is working, I arrange my deployment to manually fetch uninstall.exe from that folder. The solution is satisfying enough. I use Get-InstalledApplications for a lot of things, but unfortunately, it won’t work but I can live with it. I’ll use the good old exe as a detection method for SCCM.
Thanks a lot because now at least I am aware that I can’t transfer rights from accounts. I am still a beginner in this field and I am yet to learn the tricks you proposed. So if I understood correctly, when I encounter a rogue program that does not behave when installed as SYSTEM then I have to find a solution on the installer’s side instead of trying to bend the way SYSTEM works.
I am totally trying this! We borrowed Get-InstalledApplications code and modified it so we can uninstall anything by name with Wildcards. For instance, I don’t know if you know Camtasia. What an annoyance! Each year they release a new version but the old ones remain. So I search for anything like “Camtasia”, extract the uninstallString then loop it until nothing remains. I knew about the PSDAT toolkit but it looked like complete Chinese to me! It’s advanced coding. With CodeBlocks I tested it for the first time by “plugging” it into my own solution. The logging is amazing I must admit. On my part, unless it was a MSI (that allows logging), installing an exe gives not much infos in my log, most of the time unless there is a switch available.
I tried my solution to clean a PC from all Python instances. I polluted a machine with every versions from 2.5 to 3.10 and I came close to removing them all out of one run. But then I discovered the ■■■■ reality where a Software center install is not equal as an ADMIN install and then my world crumbled. I’m still dreaming of a universal uninstaller that can remove EVERYTHING in one scoop. But I despair lol
A use case worth of mention: An admin user install Python 3.10 from Software Center, then tries to run the exe by himself: An installation window will appear as if the application is not installed at all. If that admin user decides to continue and do a machine install, then if he tries to uninstall through Software center the next time it wont be able to uninstall correctly: some modules will remain.
And I didn’t talked about the per user install… How the hell can you keep your machines clean? lol
In your case, you’ll have to find what is the Key name that your setup EXE creates in the registry to create the ARP/Prog&Feats entry and use that for the -ArpKeyName
I thought you wouldn’t need to hide the original ARP entry since the Code::Blocks installer would create its in HKCU. (useless if you are going to make it work for all users on the box)
It’s advanced coding. With CodeBlocks I tested it for the first time by “plugging” it into my own solution. The logging is amazing I must admit. On my part, unless it was a MSI (that allows logging), installing an exe gives not much infos in my log, most of the time unless there is a switch available.