This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Flexera Community
- :
- FlexNet Manager
- :
- FlexNet Manager Forum
- :
- Logging in FNMP 9.2
Subscribe
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 11, 2018
12:02 PM
Logging in FNMP 9.2
We are currently running FNMP 9.2, and are having an issue importing the ARL. Support said to look in the Recognition.log file, but there are no log files on the server. Any ideas as to how to turn on logging? I've searched both drives on the server, but can't find any current log files. The only ones I see are over five years old.
Erick Hacking, CSAM, CHAMP
IT Software Asset Manager, Lead Sr.
IT Software Asset Manager, Lead Sr.
This thread has been automatically locked due to inactivity.
To continue the discussion, please start a new thread.
5 Replies
- Mark as New
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 15, 2018
07:03 PM
The ARL update process should normally put its log file into the %TEMP% folder of the account that the process runs as. You can run the process manually by logging in to the FlexNet Manager Platform application server, and executing the following in a cmd shell window:
After doing this, check for a %TEMP%\Recogition.log file.
Chris @ Flexera
C:\Program Files (x86)\ManageSoft\DotNet\Bin\MgsImportRecogition.exe
After doing this, check for a %TEMP%\Recogition.log file.
Chris @ Flexera
(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.)
- Mark as New
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 16, 2018
02:46 PM
- Mark as New
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 16, 2018
03:01 PM
The ARL update process can run for a long time if the database is running in a memory or resource-constrained environment; for example, if the database is running on a virtual machine a reasonable amount of memory allocated. It's not usual for the system to run more slowly than usual while the ARL update is running - but if you are seeing that it would further suggest to me that the database server is perhaps under-spec'ed for memory and possibly CPU.
Chris @ Flexera
Chris @ Flexera
(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.)
- Mark as New
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 17, 2018
04:39 AM
Looks like the script stopped doing anything after about 20 minutes. Any change yet? Anything new in the log file?
Is your SQL server running ok? I'd check that and retry the import. Probably a good idea to run at non-peak times.
Is your SQL server running ok? I'd check that and retry the import. Probably a good idea to run at non-peak times.
- Mark as New
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 30, 2018
08:38 AM
Still no change. I have checked with the DBAs and they say the DB Server is fine. They checked all log files, and nothing out of the ordinary. There is plenty of space on the DB Server, and after about 20 minutes the processer goes down to minimum. The App server is the same. There appears to be a lot of network traffic, but nothing happens. The update failed again yesterday. We do run it at non-peak hours. We start it on Sunday morning early, and most weeks it is still running Monday morning, and the only way to get our environment back is to reboot the server. And the log file disappears when it fails, so I have no way of attaching a new log file. It is gone.
I just attached a screenshot of the Task Scheduler. The Import ManageSoft ARL task doesn't have a Last Run date, but has (0x1) instead.
The Import ManageSoft Compliance data sources task ran all day yesterday, and bogged the system down. Yet the same process ran for just over an hour this morning.
I just attached a screenshot of the Task Scheduler. The Import ManageSoft ARL task doesn't have a Last Run date, but has (0x1) instead.
The Import ManageSoft Compliance data sources task ran all day yesterday, and bogged the system down. Yet the same process ran for just over an hour this morning.
gregholmes wrote:
Looks like the script stopped doing anything after about 20 minutes. Any change yet? Anything new in the log file?
Is your SQL server running ok? I'd check that and retry the import. Probably a good idea to run at non-peak times.
Erick Hacking, CSAM, CHAMP
IT Software Asset Manager, Lead Sr.
IT Software Asset Manager, Lead Sr.
