Jump to content
  • 0
JoshK

Client needs to use their own TightVNC

Question

We have a client with their own IT staff. They use TIghtVNC to get into their machines for management and do not want to change how they access them. We do not use Labtech's VNC to access machines and don't need LabVNC to work.

 

When we install the Labtech agent on the machines, it breaks their TightVNC access. When they fix their VNC, the Labtech agent keeps resetting settings.

 

Is there a way to prevent the Labtech agent from making any changes to existing TightVNC installations? Or a way to script it to put the settings back quickly? I am assuming that this is updating the settings on a regular basis with a schedule or something.

 

Thanks,

Josh

Share this post


Link to post
Share on other sites

16 answers to this question

Recommended Posts

  • 0

We ended up switching our customers to UltraVNC for the same reason. They needed to use it internally.

Share this post


Link to post
Share on other sites
  • 0

Unfortunately, they really want to stick with TightVNC. I have to find a way to make Labtech and their TightVNC coexist or I need to remove Labtech for them. I don't even need Labtech's VNC to work there. We use ScreenConnect for remote control.

 

I was thinking I might be able to create a script to put all their TightVNC registry entries back in place each night. I would want to make it as reliable as possible, so I would need to find out what Labtech is overwriting, when it does it, how often it does it, and how it does it.

 

I'm hoping someone here has had to deal with that or has some knowledge of the inner workings of what the agent is doing with TightVNC settings and the service.

 

Josh

Share this post


Link to post
Share on other sites
  • 0

2014, gets rid of tightvnc and uses a custom UltraVNC that can coexist with other ultravnc installs.

 

Hope you can wait till then

Share this post


Link to post
Share on other sites
  • 0

Sorry to reopen an old post but we had the same situation but using Ultravnc.

Our customer already had UltraVNC installed on their machines for their internal IT staff however now these staff can not connect to their machines with ultravnc but we can connect via labvnc.

the only fix we have found is that you need to remove the ultravnc service and run from startup but this requires a user to log in for remote access.

 

Anyone got any ideas?

Share this post


Link to post
Share on other sites
  • 0

Any Update on this ... i would like to strip labvnc from some customers machines as they use tight vnc

Share this post


Link to post
Share on other sites
  • 0

We still deploy UltraVNC for the customers to use. No issues.

 

If you want to completely disable labVNC (which we do) create a new Template. Properties.

Name = lt_nolabvnc

Value = True

 

Apply it, restart the Labtech agent and labVNC will go away.

Share this post


Link to post
Share on other sites
  • 0

Yeah this doesn't seem to work. This is a huge security hole for us, we require consent with screenconnect, yet LabVNC connects right in and our guys are bypassing SC because of it.

Share this post


Link to post
Share on other sites
  • 0

Just a question (disclaimer: I am not LabTech Support), but when it didn't work for everyone here, was that for already onboarded agents?

 

Everything I know about LabTech indicates that the changes to the template as listed above would only happen during onboarding. If an agent is already onboarded, LabVNC would stay; you'd need to run a script to uninstall. However, for a brand new agent onboarded into a location (group) whose template specified nolabvnc as true, it shouldn't install --provided LabTech themselves doesn't have a bug (in which case I'll open a service ticket myself, as I need the above option to work for a client of ours).

Share this post


Link to post
Share on other sites
  • 0

We just had a client with high security requirements request this change to their LT environment, and in that recent experience, setting the nolabvnc property does not work... and furthermore, it leaves labvnc and tvnserver hanging around to be waiting for a connection anyway. However, KI 8509792 gives us a pathway to remove these files from the system:

1. Stop ltagent.

2. Open the dependancy table in SQLYog and remove the labvnc,exe and tvnserver.exe records.

3. Restart the database agent.

4. import the attached script and run against all agents.

5. If you're super-concerned, you may want to make remote file monitors if exist %ltsvcdir%\labvnc.exe and %ltsvcdir%\tvnserver.exe

 

Hope this helps,

Ryan

 

No warranties expressed or implied; your mileage may vary. Good while supplies last, void where prohibited.

Share this post


Link to post
Share on other sites
  • 0

Reattaching script per request.

 

TVNServer is the server-side component, LabVNC is the client side and can hold ports required by other "approved VNC solutions," so if you want to completely remove LT's VNC functionality, both need to go.

 

Note that the attached script does remove both files from endpoints, but this will have no effect unless the records in the dependency table are removed beforehand. If the record remains, the file(s) will just get recreated the next time the LabTech agent restarts.

Share this post


Link to post
Share on other sites
  • 0

So for whatever reason, I can't get the attached script to show up in the post, so here's the data you need to recreate it:

 

Toggle FasTalk ON

SET: @LTPath@ = AgentExpand[%ltsvcdir%]

Execute Batch as Admin and store result in: @shellresult@

 

And the batch that actually is the heart of it:

 

net stop ltsvcmon

taskkill /im ltsvcmon.exe /f

net stop ltagent

taskkill /im ltsvc.exe /f

net stop tvnserver

taskkill /im labvnc.exe /f

del /f /q "@LTPath@\labvnc.exe"

taskkill /im tvnserver.exe /f

del /f /q "@LTPath@\tvnserver.exe"

net start ltagent

net start ltsvcmon

Share this post


Link to post
Share on other sites
  • 0

Thank you, @MetaMSP .

 

Interestingly enough (I'm not sure if it's true) I was told by LabTech support that if the rows were removed from the MySQL database as you mentioned in #13, the next time an agent was restarted, it should remove those dependencies itself automatically. I have not had time to test whether this is actually true, but I will be doing so in the future. I'll be using your script as well, as I can't be sure that information is correct.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×