Jump to content

LabTech for VDI - Introducing "LabTech Prep"


Recommended Posts

limabone and anyone else that is running into the issue with the MAC address key being created blank after running this process, I think I have the solution for you. I can't take full credit for this as Greg Buerk gave me some information about how the LabTech agents work and how they determine this MAC address which allowed me to troubleshoot the issue and get it working.

 

Basically, LabTech determines that MAC to use in that key by taking the MAC address from the network card that has a default gateway. Obviously in most cases this will be the main network card as it is pretty rare to have two internet accessible NICs. The issue in my case was the main gateway on that NIC was 0.0.0.0 which was above the valid gateway. The server won't use that to try to get to the internet so it won't affect normal operation but LabTech doesn't see it as a valid gateway so it won't add that key. I ran a route delete 0.0.0.0 on the server, stopped the services and deleted the registry keys. When I restarted the services the keys were creaed properly and this time there was a value in the MAC key. I have run LTPrep on the server a few more times and it always recreates with the proper key so this seems to work great.

 

Give it a shot and let me know if you have any issues.

 

Neal

Link to post
Share on other sites
  • 2 months later...

I believe I have a significantly improved the ScreenConnect PowerShell script to fix the ID for PVS/VDI or cloned servers. I have added code to automatically detect the ScreenConnect client guid that needs replaced, and you only need to set your ScreenConnect Server ID in one place. I have this PowerShell script working inside a LabTech script so that for cloned servers, after fixing the LabTech ID issue, I can call the LabTech script to fix the ScreenConnect ID for the cloned server as well. The LabTech script could be triggered to run for VDI computers (e.g., monitor every 15 min a LabTech group of VDI computers with uptime less than an hour, and run the LabTech script), or you can run this PowerShell from a GPO as a startup script.

 

Here's my .bat file to fix the LabTech ID issue:

 

@echo off
echo ::::Stopping LabTech Services::::
echo ::::
net stop ltsvcmon
net stop ltservice
echo ::::
echo ::::Deleting the identifying LabTech RegKeys::::
echo ::::
reg delete hklm\software\labtech\service /v ID /f
reg delete hklm\software\labtech\service /v MAC /f
reg delete hklm\software\labtech\service /v Password /f
reg delete HKLM\Software\Wow6432node\LabTech\Service /v ID /f
reg delete HKLM\Software\Wow6432node\LabTech\Service /v MAC /f
reg delete HKLM\Software\Wow6432node\LabTech\Service /v Password /f
echo ::::
echo ::::Starting LabTech Services::::
echo ::::
net start ltservice
net start ltsvcmon
timeout 5

 

And here's my PowerShell script to fix the ScreenConnect ID:

 

### This script sets the ScreenConnect Client GUID of a client computer to a unique value based off a hash of the computer name
# Look at the ScreenConnect service name on any client computer with ScreenConnect installed to find the server ID for all client computers
$serverid = "< SET YOUR SCREENCONNECT SERVER ID HERE - EXAMPLE:  a99abcd3e012345f >"
Stop-Service -displayname "ScreenConnect Client ($serverid)"
# Find current guid to replace
$rpath = "hklm:\SYSTEM\CurrentControlSet\Services\ScreenConnect Client ($serverid)"
$ipath = (Get-ItemProperty -path $rpath).ImagePath
$replaceguid = $ipath.Substring(($ipath.IndexOf("&s="))+3,36)
# Generate guid based off computer name
$someString = $env:COMPUTERNAME
$md5 = new-object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider
$utf8 = new-object -TypeName System.Text.UTF8Encoding
$hash = [system.BitConverter]::ToString($md5.ComputeHash($utf8.GetBytes($someString)))
[GUID]$guid = $hash.replace("-","")
# Change guid in ImagePath in registry
Set-ItemProperty -path $rpath -name ImagePath -type string -value $($ipath -replace $("s=" + $replaceguid),$("s="+$guid.ToString()))
Start-Service -displayname "ScreenConnect Client ($serverid)"
# Return guid that was set to LabTech Script, or harmlessly output guid if run from GPO
Write-Output $guid.ToString()

Link to post
Share on other sites

I'm not sure what has changed, but with the latest LabTech update we appear to have successfully gotten LabTech to properly re-register with the same agent ID on reboots with vmxnet3 nics in XenDesktop 7.X with machine creation services. I am still doing preliminary testing but am very excited. We haven't tested the ScreenConnect powershell script yet though.

Link to post
Share on other sites
  • 1 month later...

Well I spoke to soon. For some reason, with one client vmxnet3 is working, but for another client, every time I rerun the batch file to delete the reg keys when I start the services up again there is a new password and its showing up as a new computer in labtech. Extremely frustrating to say the least!

Link to post
Share on other sites

I spent all afternoon trying various things and came across this article:

http://www.kendrickcoleman.com/index.php/Tech-Blog/how-to-fix-ghosted-nic-adapters-and-windows-20087-vmxnet3-cloning.html

 

After performing the steps there, specifically installing the MS hotfix, and running devcon and cleaning out old vmxnet3 ghost nics, labtech is now working as I had hoped!

Link to post
Share on other sites
  • 5 months later...

Interesting update...while all our VDI clients in the past have used Windows 2008 R2 and the labtech prep script has worked great, we have one new client that uses Windows 2012 R2 for their VDI desktops. The script seems to work fine for a period of time, I can't say for sure but it would be about a week, after which the servers start showing up as duplicates in labtech when they get shut down/refreshed nightly.

Any experts here have an idea what could be contributing to that? Our workaround is to simply power on the master, shut it down (which triggers the prep script again), snapshot and update our xendesktop machine catalog and then its fine again for a week.

Link to post
Share on other sites
  • 2 weeks later...

Here's a follow-up on the part about handling ScreenConnect in a VDI environment. I just found out that you can just delete the &s= from the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ScreenConnect Client ()\ImagePath value and restart the ScreenConnect Client service. Without the &s= in the ImagePath value, it will automatically use a guid derived from the combination of the MachineGUID and the computer name.

 

https://docs.connectwise.com/ConnectWise_Control_Documentation/Get_started/Knowledge_base/Image_a_machine_with_an_installed_agent

 

Here's a way to code the removal of the &s=:

# Look at the ScreenConnect service name on any client computer with ScreenConnect installed to find the server ID for all client computers
$serverid = "< SET YOUR SCREENCONNECT SERVER ID HERE - EXAMPLE:  a99abcd3e012345f >"
Stop-Service -displayname "ScreenConnect Client ($serverid)"
# Find current guid to delete
$rpath = "hklm:\SYSTEM\CurrentControlSet\Services\ScreenConnect Client ($serverid)"
$valtype = (Get-Item $rpath).GetValueKind("ImagePath")  # Should be type = ExpandString
$ipath = (Get-ItemProperty -path $rpath).ImagePath
$deleteguid = $ipath.Substring(($ipath.IndexOf("&s=")),39)
# Delete from ImagePath in registry
Set-ItemProperty -path $rpath -name ImagePath -type $valtype -value $($ipath -replace $deleteguid,"")
Start-Service -displayname "ScreenConnect Client ($serverid)"

 

However, you can just remove the &s= from the ImagePath value in the registry once in the base image for a VDI or PVS deployment, and you no longer have to run the PowerShell above as a startup script.

Link to post
Share on other sites
  • 6 months later...
On 9/27/2016 at 8:44 PM, bierlyt said:

The LabTech script could be triggered to run for VDI computers (e.g., monitor every 15 min a LabTech group of VDI computers with uptime less than an hour, and run the LabTech script), or you can run this PowerShell from a GPO as a startup script.

 

Hi bierlyt, many thanks for the scripts! Could you (or anybody else who knows of course) tell me how I can actually run a script that stops the Labtech services and restarts them because when I try and do that it causes the script to fail every time, if I run the batch file manually it works fine. I have tried Execute Script/batch/Run as Admin and put in your batch file commands  in the "Script to Execute box" and I've also tried a script that copies a .bat file over to the agent and then runs it using Shell as Admin but neither works, the script fails at the step where the batch file runs, I presume because the LT services get stopped and so it loses control.

Any ideas?

Link to post
Share on other sites
  • 1 year later...
Quote

net stop LTService 
net stop LTSvcMon 
reg delete HKLM\Software\LabTech\Service\ /v ID /f 
reg delete HKLM\Software\LabTech\Service\ /v MAC /f 
reg delete HKLM\Software\LabTech\Service\ /v Password /f

We had been using this method to prep Citrix MCS VMs. It stopped working a while back, just digging into it now. It appears simply stopping the services and deleting the reg values is no longer cutting it-- the services fail to start again.

I've tested on a few agents, same problem when starting the services:

Faulting application name: LTSVC.exe, version: 190.78.7003.30430, time stamp: 0x5c7ef00e
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x000000001a034017
Faulting process id: 0x60c
Faulting application start time: 0x01d54267535ad1bd
Faulting application path: C:\Windows\LTSvc\LTSVC.exe
Faulting module path: unknown
Report Id: 9168886c-ae5a-11e9-82f6-005056a90530
Faulting package full name: 
Faulting package-relative application ID: 

Is this still working for anyone else?

Link to post
Share on other sites
  • 2 months later...
  • 2 months later...

Hi all-

 

We are implementing a vdi solution in our environment and as I read through the thread, it brought up some questions in regards of how we would be able to manage this effectively.  We have our Master image with no users actively using the VDI desktops as of yet.  We want to manage and update the master image as we understand that by updating and maintaining this will replicate the changes to the other vdi desktops for the users.

 

What approach should we take, are there any known issues that we should be aware of?

 

We are on prem and are using ver 19.0.250 of automate with Control.  Any help or suggestions would be appreciated.

Link to post
Share on other sites

There is nothing special for it. Just follow the procedure to delete the appropriate keys for LabTech and run the Powershell for ScreenConnect.

Put it in the shutdown or startup of the image so they run on every reboot of the machine. 

Personally I have had the best luck putting it in both the shutdown and startup as I find machines don't always shutdown cleanly. I put a batch file to delete the keys in the Local Group Policy during shutdown. I then put another batch file in Task Scheduler on startup that stops the services, deletes the keys and restarts them. I delay it for a minute and have it run again in 10 minutes just in case the host is slow during boot which I run into quite a bit. ScreenConnect I put into a startup GPO powershell. The services for ScreenConnect are delayed start anyway so this has worked pretty well.

For all except one client where we can't access their task scheduler, this has worked very well for us. 

Link to post
Share on other sites
  • 1 month later...

We are trying to set the registry keys for the server side portion of this setup, however when we enter them in the GUI it sets the keys in HKLM\Software\LabTech\Global rather than HKLM\Software\Wow6432Node\LabTech\Global. It also sets the MacSignupTimeLimit to -4320 rather than 0. If we try to manually set them in the Wow6432Node location also it removes the keys when we restart the DBAgent. When we stop LTSVC and LTSVCMON, then remove the MAC and ID keys from an agent, then restart the services it brings the agent in with a new ID even though the MAC address remains the same. We are on Automate 2019.10. Has anyone else ran into issues doing this?

Link to post
Share on other sites
  • 2 months later...
On 10/1/2019 at 7:45 AM, kelliott said:

We've instead moved to using LTPosh on boot to reinstall the service. Works better

Can you explain how youre doing this?  possible provide the  LTPOSH script?

Link to post
Share on other sites
  • 7 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...