Client needs to use their own TightVNC

[JoshK 0]

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

[cgauss 1]

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

[JoshK 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

[Greg.Buerk 1]

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

 

Hope you can wait till then

[Orion Withrow 0]

We are in the same boat...how long until "then"??

[pfp 0]

I'd also like to know when "then" is.

[Lethal 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?

[TekCon 0]

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

[cgauss 1]

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.

[Barry.Collins 0]

Sorry to reopen this but the above solution does not seem to work. LabVNC runs and causes TightVNC to fail.

[gibsurfer84 2]

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.

[LoneWolf 13]

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).

[MetaMSP 16]

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.

[LoneWolf 13]

@MetaMSP, I'm not seeing the attached script. Can you re-attach it?

[MetaMSP 16]

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.

[MetaMSP 16]

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

[LoneWolf 13]

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.