Error when pointing to a new FNMS Database Instance

[Matimba1229]

Good day,

We have a new DB instance , so when I run the config.ps1 with the forceupdateconfig switch.

I get this error:

Executing step Install MSMQ.
D:\FlexNet Manager Suite\Support\SetupQueue.ps1 : Method invocation failed because [System.Object[]] does not contain
a method named 'GetVersion'.
At line:1 char:1
+ .\SetupQueue.ps1 MSMQ fnmsBatchProcessorTask 1 -configFlag 'InstallOn ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [SetupQueue.ps1], RuntimeException
+ FullyQualifiedErrorId : MethodNotFound,SetupQueue.ps1

I'm on FNMS 2019 R1, has anyone come across this?

Regards,

Pardon 

[erwinlindemann]

Hi,

What I suggested is instead of running the config.ps1 script with the 'forceupdateconfig' switch, is doing some minor edits to the Windows registry on the FNMS application server.

In the [HKLM\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft\Reporter\CurrentVersion] branch of the registry, you find four key/value pairs that define the connection to the SQL server database instances.

If you delete these four key/value pairs with the keys DatabaseConnectionString, InventoryDatabaseConnectionString, FNMPDWDatabaseConnectionString and SnapshotDatabaseConnectionString before running the config.ps1 PowerShell script, it will prompt for the current DB instances. The subsequent update to the setup of the MSMQ configuration should not show any error message then.

[Matimba1229]

Thanks for your input @erwinlindemann  I have tried this as you said but still getting the same error.

Regards,

Pardon 

[erwinlindemann]

Hi Matimba1229,

On your system, what fails is a PowerShell function call that refers to the Windows "kernel32.dll".

A typical reason could be that you did not launch the PowerShell window using the "Run as Administrator" option.

For testing and debugging, you can try running the PowerShell code snippet below by copying and pasting it into a PS Window. On a Windows 2016 System, as output you should see four numbers (10/0/57/56) with each number on a dedicated output row.

Function Get-OSVersion{
	$signature =  $signature = @"

 [DllImport("kernel32.dll")]

 public static extern uint GetVersion();

"@
	Add-Type -MemberDefinition $signature -Name "Win32OSVersion" -namespace Win32Functions -PassThru
}

$os = [System.BitConverter]::GetBytes((Get-OSVersion)::GetVersion())

Write-Output $os

[Matimba1229]

Thanks @erwinlindemann ,

I always run PS as Administrator. I'm on Windows Server 2012 R2. I ran the script and the result is the same.

Function Get-OSVersion{
	$signature =  $signature = @"

 [DllImport("kernel32.dll")]

 public static extern uint GetVersion();

"@
	Add-Type -MemberDefinition $signature -Name "Win32OSVersion" -namespace Win32Functions -PassThru
}

$os = [System.BitConverter]::GetBytes((Get-OSVersion)::GetVersion())

Write-Output $os
Method invocation failed because [System.Object[]] does not contain a method named 'GetVersion'.
At line:12 char:1
+ $os = [System.BitConverter]::GetBytes((Get-OSVersion)::GetVersion())
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : MethodNotFound

@@ 

[erwinlindemann]

Hi Pardon,

On Windows 2012 Server, the output of the PowerShell script should be something like: 6/3/128/37.

Can you please confirm:

• The user that you are logged in with has local Administrator privileges?
• The PowerShell Version that you are running is recent by running (Get-Host).Version? The Version of PowerShell should be Version 4.0 or higher.

The way the function call of GetVersion is implemented in the PowerShell script seems to be consistent with the Microsoft documentation.

[Matimba1229]

Yes I have confirmed everything, basically all was working as normally we only changed the database instance and config fails to run.

• Service account is local admin on the server.
• Powershell Version: 

          Major Minor Build Revision
          -----     -----       -----     --------
          5           1         14409   1018

Regards,

Pardon 

[erwinlindemann]

Hi Pardon,

PowerShell version is OK.

I don't think the issue is related to the fact that the database instance has changed.

You have to make sure that PowerShell code snippet works on your FNMS server. For collecting additional evidence, I would suggest trying to run the PowerShell code snippet on another computer in your environment. Then you can check what is different on your FNMS application server.

As a workaround for this specific error message, you could rewrite the PowerShell function in the SetupQueue.ps1 module as described in the Microsoft BLOG article.

[ccrawford]

What output do you get with the following?

Get-OSVersion | ForEach-Object { ($_)::GetVersion() }

[Matimba1229]

Hi @ccrawford,

Thanks for your reply. This is the output I get:

We have logged a case with Flexera and our local vendor, the local vendor has today made a change to the Setupqueue.ps1 script as the function it's using is deprecated. So they  just hashed out the MSMQ install function see below,  I'm still testing but so far seems to work.

function InstallMSMQ{
	"Checking for MSMQ installation. The configuration will install MSMQ services if they are not installed."
	$os = [environment]::OSVersion.Version
	$majorVersion=$os.Major
	$minorVersion=$os.Minor
	#$os = [System.BitConverter]::GetBytes((Get-OSVersion)::GetVersion())
	#$majorVersion=$os[0]
	#$minorVersion=$os[1]
	#$build=[byte]$os[2],[byte]$os[3]
	#$buildNumber=[System.BitConverter]::ToInt16($build, 0)
	#"Version is {0}.{1} and build {2}" -F $majorVersion, $minorVersion, $buildNumber

[ccrawford]

That's very strange. Your "OS version" is an array of versions... Let me look more into this and get back to you. I would suggest logging a question with support if you haven't already.

[Matimba1229]

Strange indeed, we've been going back and forth, the case was opened a month ago Case#2153023.

Hashing out the script is what was used as a workaroud all seems to work now.

Reegards,

Pardon