Can't Get Launch Condition Right...

[Superfreak3]

I'm trying to add to an existing launch condition to allow for install on 2019.

The application is only to be allowed on Win 7 and 10 workstation OSs and Server 2019.

Before adding 2019 support, the condition looked like this...

(VersionNT64>=601 AND MsiNTProductType=1) OR SERVEROSBYPASS

The SERVEROSBYPASS is an in-house backdoor to install on unsupported OSs and is populated if a file is found.  All of that has been working fine for years.

What I tried was this for Server 2019...

(VersionNT64>=601 AND MsiNTProductType=1) OR SERVEROSBYPASS OR WindowsBuild>=17763

It seems that the problem is with WindowsBuild>=17763.  I stripped everything but that from the condition and it still does not allow install on Server 2019.  Is that property deprecated?  Is the value I'm checking for incorrect?  Or is there some syntax problem?

I'm stumped.

What I did do was add a message to the install to show WindowsBuild number and it is reporting 9600.  The system is definitely Server 2019 so that seems to me that that property may have been abandoned and doesn't work for newer OSs.

I'm wondering if I should just create a custom action to check for allowed OSs, set a property and use that as my condition.

[roman2]

When you install an .msi installation package on

Windows 10, Windows Server 2016 or Windows Server 2019,

the VersionNT value is 603.

More Information

---

This version numbering is by design.

To maintain compatibility, the VersionNT value is 603 for

Windows 10, Windows Server 2016, and Windows Server 2019.

[roman2]

Windows Server 2012 R2 x64     VersionNT64 = 603 AND MsiNTProductType <> 1
Windows 10 x64                               VersionNT64 = 1000 AND MsiNTProductType = 1
Windows Server 2016 x64            VersionNT64 = 1000 AND MsiNTProductType <> 1

[Superfreak3]

So, we're currently supporting this app on Win 7, Win10, and Server 2019.  So VersionNT64 = 1000 AND MsiNTProductType <> 1 wouldn't work for us as that would allow install on Server 2016.  That's why I was trying to utilize the WindowsBuild property, which doesn't seem to work or is not applicable to newer OSs.

[roman2]

Name                                 Version  Build           Number    Release

Windows Server 2016, Version 1607 10.0    14393    2016-08-02 
Windows Server 2016, Version 1709 10.0    16299    2017-10-17 
Windows Server 2019

1909 18363     2019 - SAC                     12 Nov 2019
1903 18362     2019 - SAC                     21 May 2019
1809 17763      2019 - LTSC                  13 Nov 2018
1803 17677     Server 2019 Preview 09 Jun 2018

[Superfreak3]

If you notice in the original post, I tried using the WindowsBuild property, but it was always resolving to an earlier build version on the later OSs.

[roman2]

Make a test setup.

Put in the InstallWellcome dialog an text field with following command:

WindowsBuild = [WindowsBuild]

Build it and start on WS2019

You will see, what really the value of WindowsBuild is.

[Superfreak3]

I'll try it again, but from the initial post...

"What I did do was add a message to the install to show WindowsBuild number and it is reporting 9600.  The system is definitely Server 2019 so that seems to me that that property may have been abandoned and doesn't work for newer OSs."

[roman2]

Yes. You are right.

I have check this property on very new WS2019 install version Nov, 2019

It also  is reporting 9600

?!

[roman2]

I see the only way to get a build version, it is to

read   key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

CurrentBuildNumber ---> 17763

Regards

Roman

[roman2]

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

[Superfreak3]

For right now, I think this points to a custom action to detect the newer OS.  There was some .NET method I tried to get the versioning or build number, but I found that too deprecated and not reporting the correct version.

Here's the hack I'm currently using for now...

RegistryKey registryKey = Registry.LocalMachine.OpenSubKey("Software\\Microsoft\\Windows NT\\CurrentVersion");

if (registryKey != null)
{
string pathName = (string)registryKey.GetValue("productName");

if (pathName.IndexOf("Server 2019") > 0)
{
session["SERVER2019"] = "1";
session.Log("Server 2019 detected.");
}

I cobbled this together last week and didn't notice the CurrentBuildNumber value in that that key.  I'll ride with what I have for now unless/until it becomes problematic.

[roman2]

Yes, CA is also possible.

You can achieve the same result building a custom search for the same reg.key

I think the issue is solved now, by you!