I have ongoing issues, often due to lack of documentation, with the
Groupwise Windows client installation / deployment, *especially* around
the various MS components it ships with.
To start with the basics, the included VC runtimes are all severely
outdated. For instance, VC2015 has been binary replaced by VC2017, but
all others aren't remotely current either, eventhough they're often many
Also, I take issue that in GW18 (which is a change from GW2014), even
manually calling the groupwise.msi (vs. the setup.exe or install.bat),
always forcefully installs the VC runtimes, regardless if they're
already installed or not.
To make it worse, that results in all other install methods (install.bat
or setup.exe), installing the outdated runtimes twice. That alone makes
up for 2/3rd of the time the client install requires (which on slower
machines is insane, and can take up to 20 minutes).
Now, with GW18.1 it get's even more confusing. The GW18.1 client
suddenly includes and install VC *2010* runtimes again, whereas GW18.0X
clients did not. Does GW18.1 really includes *new* functionality over
GW18.0 clients that are based on a 8 year old VC runtime?
Another strangeness: GW18.1 suddenly also includes and (attempts to
install) the .NET 2.0 runtime again (which was no longer included in
18.0. Which is strange, as .NET2.0 can not be seperately installed on
any supported windows version of the GW client. It's for XP based
windows only, all newer Windows versions (and GW is supported only from
GW7 or newer) include minimum .NET 3.5, which includes .NET 2.0
Oh, and last but not least: The years old bug that when you execute the
groupwise.msi directly, the install fails with typelib registration
errors when you don't explicitly call the MSI "as administrator" (even
when the logged in windows user already has admin rights) is also still
there. This is a perfect indication that the MSI is broken, this should
never happen. *If* a MSI needs elevated rights it is supposed to ask,
not silently fail. This is an indication that the .msi itself calls some
external activity (probably an executable) that needs elevated rights,
but doesn't supply or check them.
Micro Focus Knowledge Partner
No emails please!