after upgrading to FNMS 2019 R2 one of our beacons is stetting all of its windows scheduled tasks to status disabled. Did someone came across this somehow strange behavior or got any idea what could causing this?
"we do not have any process in place which would disable scheduled tasks. However, it is possible that WIndows is disabling the scheduled task if it is unable to run. In light of this, can we check the following:
1. Are there any ndupload.exe tasks stuck in task manager? If so, please try killing any that you see. 2. Are there any global policies in place which could be disabling scheduled tasks?"
The end result was that after manually enabling the task, it started to work based on what I can see in the case history.
(Anything expressed here is my own view and not necessarily that of my employer, Flexera) If the solution provided has helped, please mark it as such as this helps everyone to know what works.
I've never seen this directly but initial thoughts are that the tasks were disabled beforehand and so it was maintained or the password for the service account needs updating.
Not sure if either of these apply?
(Anything expressed here is my own view and not necessarily that of my employer, Flexera) If the solution provided has helped, please mark it as such as this helps everyone to know what works.
"we do not have any process in place which would disable scheduled tasks. However, it is possible that WIndows is disabling the scheduled task if it is unable to run. In light of this, can we check the following:
1. Are there any ndupload.exe tasks stuck in task manager? If so, please try killing any that you see. 2. Are there any global policies in place which could be disabling scheduled tasks?"
The end result was that after manually enabling the task, it started to work based on what I can see in the case history.
(Anything expressed here is my own view and not necessarily that of my employer, Flexera) If the solution provided has helped, please mark it as such as this helps everyone to know what works.
We have found the root cause of the issue, and are fixing the beacon installer so that the issue does not occur any more.
As a workaround, make sure that the npcap-0.995-oem.exe that Beacon uses during the install is in the Windows temp folder. This should help avoid the issue you are running into.
could you please get a bit more into detail with your workaround.
Had 2 customers, one is affected by this issue (task disabled) and the other not. Checked both system C:\Windows\Temp and can't find the npcap-0.995-oem.exe. When checking the %AppData%\Local\Temp folder I've found the file on the server of the not affected customer. But, the file is stored in the %AppData% folder of the logged in user (Flexera Service Account) and we're running all Beacon Tasks as NT AUTHORITY\SYSTEM (local system). Could you please specify where to store the file to fix the issue when running all beacon tasks as local system. Could you also please explain why this happend not to all beacon installations?
Edit: Do we've to reinstall the Beacon software when the npcap file is located in the Temp folder?
Could you please confirm that your task scheduler had the same error msg. Bit confused how a missing npcap file should be the reason for disabling all upload tasks ?!
I don't know as much about this problem as some others, but here are a few additional details from my understanding:
* I can imagine the npcap-0.995-oem.exe file may well be in a user's temp folder (likely the temp folder of the user account that was used to install the beacon), not necessarily the system temp folder. * The problem is triggered when a discovery process executes: if Windows Installer notices that the npcap-0.995-oem.exe file it installed in the temp folder no longer exists, Windows Installer seeks to be smart and automatically initiates a self-heal of the beacon software. When a Windows Installer self-heal of the beacon software is done, the scheduled tasks are left in a disabled state.
(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)
I don't quite follow your explanation, why would a fully installed beacon, which processes a discovery process, start a "self healing" process by starting the Windows Installer. I would expect Discovery to abort. We successfully use a vCenter Discovery & Inventory Task via the beacon.
Windows Installer has a built-in mechanism that checks that key files that have been installed still exist when certain processes run. If a key file is found to be missing (such as occurs when the npcap-0.995-oem.exe file is unexpectedly deleted), Windows Installer kicks off a "repair" operation on the MSI package in an attempt to recover the missing file.
(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)
Generally data source connection details will not be lost when upgrading or repairing an installation of the beacon.
Likewise, in most cases the user identity used for running beacon servers and scheduled tasks will also be OK. However once scenario where these user identities may be lost during an upgrade or repair operation is if you have modified the identity used for services or scheduled tasks yourself after the beacon was previously installed. In this situation you will likely have to reapply similar changes after an upgrade/repair is done.
(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)
one thing i experienced with one of our customer is that office365 token was not accepted after we upgrade (inplace) the Server Operating system for the beacon server , we had to reauthenticate the connection for the new token.
