Size of TNIWINAGENT.EXE

[Hemo2]

I noticed in the latest release, v2.2.3 build 1528, that the size of the TNIWINAGENT.EXE file has increased in size dramatically.  Previous size we used was 291KB and it's now more than twice the size at 720KB in this release.

 

We perform login script scanning on our workstations.  The command we use in our login scripts runs this file from a centralized server.  However, we have a great many workstations (thousands) on remote networks and many of these have limited connection into our primary backbone.

 

We are understandably concerned about the size of this new file and the effect it will have on our bandwidth at these limited networks, so we haven't started using this newer version of the agent.

 

The version of the agent we are currently running is v12.12.04.0.  To help us decide if we want to use this newer version, we'd like to know what changes or enhancements are in this newer, and larger, agent file?  Are the changes something that are needed for new features in the newest TNI update?  Would we be missing anything or causing issues if we continued to use the older agent with the newest version of TNI?

 

Thank you.

[Support]

The size of the agent has increased because it's now built with a new version of the developer environment and the compiler. The main change is that now it fully and natively supports Unicode. This may influence scan results only if you have data of another codepage in it (different from the default codepage used on the scanned machine). For example, a software item with a title in Chinese, Japanese, Russian etc. on a machine using Windows-1252 codepage (English, German, French, etc). With the old version it will come out as "?????", which is now fixed in the new version. If you don't experience anything like that, you can stay with the old version temporarily.

 

I can absolutely understand your concern. When there is a thousand (for example) of users logging in to their computers in the morning, 700 KB become 700 MB of traffic via something that is not 100 Mbit/s. Unfortunately we cannot promise that the size of the agent will be decreased or that it will not be increased more as we add new functionality.

 

It's possible to decrease it dramatically if we take the runtime libraries out of it (similar to the well-known Microsoft Visual Studio runtime libraries), but then it will be needed to pre-deploy them at least once to all machines running the agent. Another way we can take is to make the agent cache itself locally, check the version on the server and download itself from the server only if there is a newer version, otherwise run locally. Whole another way is on your side: put the agent somewhere closer to the client machines (local servers, etc), but then it's a mess to update it and set up additional group policies. Let us know your thoughts on this.

[Hemo2]

Hi Zak.  Thank you for the information.  From a technical standpoint, I don't know that we want to pre-deploy the agent, so it kind of makes sense to leave the runtime library in the agent.  The idea of caching it locally is interesting, but I'm not sure how we would then run the command in our login script.  I think we'd still need to point the the network resource to run the agent just in case the locally cached file didn't exist.

 

So for now, I think we'll run the older version and discuss the larger size of the new version.  I don't think a change is needed on your end at this time.  All our users don't obviously login at the exact same moment in time, so that helps.  If techs run large scale scanning on remote networks, we can have them scale back the number or concurrent scans if we run into response and bandwidth issues.

[Support]

It is possible to create a small stub EXE file that will be run from the server and check if the user has the latest agent cached locally and runs it if he has, or copies the newest agent from the same folder to the user's computer (if he has no file or if it's outdated) and again runs it locally. Do you think this would be useful?

[Hemo2]

I could see that idea as working and useful.