Snow Client is very inaccurate.

Jeremy asked a question.

January 25, 2018 at 8:00 AM

Hey guys! I have 32 computers that are showing in Quarantine, some from November last year. But 15 of them are currently and have been active the whole time. These machines are all running client version: 3.7.06. What might be causing this? If I uninstall the client and reinstall it the next day it shows up as active.

Any thoughts or suggestions would be greatly appreciated!

Portal User
8 years ago
Jeremy, Are the agents are reporting and have you sent a test update from one? If they are not reporting, they will show as in Quarantine after whichever time you have listed. Mark
Expand Post
- Jeremy
  8 years ago
  Can you tell me how that is done? And what may cause that? Get Outlook for Android<https://aka.ms/ghei36>
  Expand Post
  - Portal User
    8 years ago
    Jeremy, If these are on your network, they should report in but if they are not, this may be one thing that you need to consider. Secondly, if you have upgraded to SLM 8, I would use Agent 5 and then send an update (you will need to check in Snow DB for this reporting rather than SLM). Agent version 3 run a command pormpt or via Task manager as Admin C:\Program Files\INVENTORYCLIENT\client64.exe –scan Agent 5 run a command pormpt or via Task manager as Admin C:\Program Files\Snow Software\Inventory\Agent -snowagent.exe scan Hope this helps Mark
    Expand Post
iankimble
8 years ago
Hi Jeremy, i've seen the same issue so we have a dashboard setup to report on clients not connecting after 48 hours. i've never had to reinstall the client as 99% of the time it's the service that has stopped and just needs to be restarted - never found any errors (unless it's disk space). we get a handful a week in this scenerio but i'm not looking further into the cause until I move to inv5 agents
Expand Post
- rswain
  8 years ago
  Hello - I'm seeing the same issue and it is all over the board on what has been "seen" or not. We are also trying to get agent 5.x installed, but having issues where SLM doesn't see the new install. (Have ticket open with Snow)
  Expand Post
Community Manager (Flexera Software)
8 years ago
Hello Jeremy, maybe test a Snow Inventory Agent (version5) if this might be a difference? Greetings, Roland
Expand Post
Portal User
8 years ago
Hi Jeremy, I have come across the same issue over the past few days. A server I know a colleague has access to was showing as quarantined with no activity for over 35 days, yet I know that they have been accessing the server via RDP in the past week. I gained access to the server and checked the inventory files in the data folder. (C:\Program Files\INVENTORYCLIENT\Data) The files in the data folder were all dated November 2017 (e.g. 25/11/2017). I deleted all of the data files and restarted the Snow Inventory Client in "Services" on the server. A lot of the data files regenerated immediately once the service was restarted. The following day when I check the SLM the server was showing as active. My guess here would be that the Snow Inventory Client service had crashed/had a blip at some point and stopped regenerating the data files. We are on the same client version as you and are not able to upgrade yet due to having a hosted platform. I am hoping when I check tomorrow that I will see the server has reported in today also. Hope this helps Greg
Expand Post
- Portal User
  8 years ago
  Some good news. The server reported in as active! Another server I attempted this on however did not. When I checked the client.log file I saw the following: 07:30:16 : : client64 **** 07:30:16 : : client64 New session: 2018-02-06 (UTC-00:00) [Version 3.7.02.15173] 07:30:16 : : client64 Windows 64-bit [Version 5.2.3790] Service Pack 2 07:30:16 : : client64 **** 07:30:16 : ERROR: client64 Cannot get config. 404 Not Found 11:42:13 : ERROR: client64 Cannot get config. 404 Not Found 11:43:46 : : client64 **** 11:43:46 : : client64 New session: 2018-02-06 (UTC-00:00) [Version 3.7.02.15173] 11:43:46 : : client64 Windows 64-bit [Version 5.2.3790] Service Pack 2 11:43:46 : : client64 **** 11:43:46 : ERROR: client64 Cannot get config. 404 Not Found I am waiting to hear back from our host, but I believe that there may be a configuration problem here.
  Expand Post
david.husk
8 years ago
In above I see: "There is a setting in the SLM SMaCC under Core settings that you can work with on this, it is INVENTORY_TRANSFER_DATE_OFFSET. it should be set to 1, but you might crank it up to 30, then set the TMP_UPDATE_JOB_MODE in the location to 12, and kick of a Data Update Job (this update will take ~40% longer then normal, so plan accordingly). " Can someone tell me in extreme detail what "INVENTORY_TRANSFER_DATE_OFFSET" does? The Doc description is "Number of days to perceive a computer as updated when transferred from data source." Can someone tell me in extreme detail what "TMP_UPDATE_JOB_MODE" units are and what it does ? The Doc description is "Temporary override mode setting for the Data Update Job (resets automatically)." Thanks
Expand Post
Landon Owens (Flexera Software)
8 years ago
Hello Jeremy , There are a few things that might be going on here. on the 3.x client there is a file in the INVENTORYCLIENT/Data folder called client.dat. it contains the last scan date and should be updated each time, you might take a look at that to see if something is preventing that from happening (NOTE: I have never seen this happen before). The other might be that the system was turned off for a while, and we had to many successive DUJ's where the system did not change anything. There is a setting in the SLM SMaCC under Core settings that you can work with on this, it is INVENTORY_TRANSFER_DATE_OFFSET. it should be set to 1, but you might crank it up to 30, then set the TMP_UPDATE_JOB_MODE in the location to 12, and kick of a Data Update Job (this update will take ~40% longer then normal, so plan accordingly). These two steps should thoroughly rebuild the scanned in systems and get all these systems reporting into SLM, also will also have the affect of rebuild any indexes in your DB as well. After the update job, make sure to set the OFFSET back to 1, leaving it at 30 with greatly impact the length of time you DUJ will take (the MODE 12 changes back to normal automatically).
Expand Post

10 of 11