Classic Shell: Forum

Hi there

At the Moment we are trying to deploy ClassicShell 4.0.4 over the Version 3.6.8. Using the 64-bit MSI.

The Problem is that we use a System Account (SCCM) to install the MSI. So when a User is logged on, the Explorer.exe from the User is crashing every time.

The Only Solution would be, if it would be possible to close the Startmenu before the installation. (Right-Click and Exit).


We also saw that the Setup is using an application called SetupHelper.exe. With the Parameter -exitSM. This sounds something like what we are looking for.


Has anyone an idea to the problem?

Thanks in advanced.

To close the start menu you run "ClassicStartMenu.exe -exit". That's what "SetupHelper -exitSM" does (but it also looks up the location of the ClassicStartMenu.exe from the registry).

So this is an old post, but seems to be one of the only ones I can find on the web relating to SCCM 2012 deployment and the SYSTEM user account installation/uninstallation causing the explorer.exe to be closed and NOT reopen after install/upgrade/uninstall. I have been fiddling with this for days, gone through iterations or using MSI directly, EXE with command line options, etc. I got past the explorer crashing and not reopening issue using EXE (as it seems to reopen the windows where MSI did not) and some scripting when running the installer as the admin of the machine, but when run through SCCM (which uses SYSTEM) account explorer still crashes/closes and doesn't reopen in the logged in users context.

Here is the two scripts I have come up with. I am using 4.2.5c installer. Upgrading from 4.1.0. They work perfectly when run as logged in user to avoid explorer even closing, but not in SCCM.

- Modified the "Install.cmd" file to be:


- Modified the "Uninstall.cmd" file to be:



Please someone help me out this is beyond frustrating.

Closing the start menu is not a guarantee that Explorer.exe won't have to be restarted. The start menu has a shell extension, which is loaded whenever Explorer needs it. If you want to do this automatically, manually kill Explorer in the beginning, and then restart it after.

And why are you removing registry entries prior to the uninstallation?

I can manually kill it before start, but it does not remember which windows are open that way. Nor can I reopen the explorer as the user logged into the machine. It will reopen them for the SYSTEM user. I remove them just to clean things out. I add them when I install. Is there an issue with doing it before the uninstall? Should I be doing that after the removal?

The scripts I posted work beautifully. Exiting the start menu has removed any of the explorer.exe crashing that I did in testing, but it is not acting the same when running as the SYSTEM account with a different user logged in to the machine.

The uninstaller needs the information from the registry. If you want to clean up what's left, do it after.

The installer is intended to run as the interactive user, not SYSTEM. There are multiple protections in the operating system to limit the communication between users with different privileges. I'm not saying that there is no way to get SYSTEM to work, but you are deep into unsupported territory.

Well, that is unfortunate, as the millions of devices out there managed by hundreds of thousands of SCCM Admins won't be able to make full use of this handy Start Menu as users don't have Administrator access and SCCM is the way they are allowed to install programs. Windows 8.1 especially needs a start menu for normal users that can't wrap their heads around the metro interface. Luckily we'll be upgrading to Windows 10 soon and we'll no longer have need for a separate start menu.

I really think you or any other software developer is missing the boat if they don't take the time to ensure any Windows oriented program is able to be deployed and removed using Microsoft's own flagship client management software. Saying it is "deep into unsupported territory", just doesn't seem to be the way to go. Food for thought.

@CRoth2, what if you use this way to do application installation using local administrator account instead of SYSTEM account: https://social.technet.microsoft.com/Fo ... managerosd

As for Windows 10, after using it, you might realize that Windows 8.1 with Classic Shell is better and more stable over the long term.

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and helped a little with Classic Shell's testing and usability/UX feedback.

I can try that, but it will likely result in the same issue...that the installer/uninstaller is being run as a different user than the person that is logged into the machine, so it will likely result in the same issue for the logged in user as the processes aren't being run in their context. Should be the same for both SYSTEM or another user. The issue the TechNet post addresses is that there are indeed some applications that just won't install at all with the SYSTEM account, so running as Admin makes it go. That shouldn't be the case for this software as it does install with SYSTEM, just has some unfortunate behavior.

It will probably work to run the installer as SYSTEM, as long as there are no interactive users currently logged in. If there are users that are currently using the software, how do you suggest the installer do its work? Any software will have that problem - you can't change files that are currently in use.

I would suggest you do the updates overnight when everybody is logged out.