Hi,
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?
Thanks & best regards
Oliver
‎Jan 23, 2020 02:27 AM
I've checked the case and the main response was:
"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.
‎Jan 23, 2020 07:46 AM
Hi @oqueck
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?
‎Jan 23, 2020 07:23 AM
Yes! This happened to us last week.
Case 01974277. We had to work with Support to get it to stop disabling the scheduled tasks.
‎Jan 23, 2020 07:41 AM
I've checked the case and the main response was:
"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.
‎Jan 23, 2020 07:46 AM
‎Feb 25, 2020 06:11 AM
Hi there,
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.
I hope this helps.
Thanks!
‎Feb 26, 2020 01:13 PM
Hi @Alpesh ,
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?
Thanks and Best,
Dennis
‎Feb 28, 2020 02:41 AM - edited ‎Feb 28, 2020 02:54 AM
‎Feb 28, 2020 06:32 AM
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.
Best,
Dennis
‎Feb 28, 2020 06:51 AM
‎Feb 28, 2020 07:02 AM
‎Feb 28, 2020 07:35 AM
One quick question here , will it cause loss of any beacon inventory connections or credentials when we repair a beacon?
Regards,
Junaid Vengadan
‎Mar 28, 2021 03:55 AM
No
It won't change in existing setting in repair application.
‎Mar 28, 2021 04:24 AM
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.
‎Mar 31, 2021 06:20 AM
@ChrisG that's great and make sense 🙂
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.
Regards,
Junaid Vengadan
‎Apr 01, 2021 03:03 AM