Jump to content
MartynKeigher

LabTech for VDI - Introducing "LabTech Prep"

Recommended Posts

Hey all,

 

We (all) have plenty of clients that are, or soon will be, running the majority of their workloads in a VDI (virtual desktop infrastructure) environments, and as Citrix continues to grow, especially with the IMA re-work to FMA, "Desktop as a Service" is soon going to the new "buzz" word in the IT world, and one we WILL have to cater for as MSP's/trusted advisors/etc...

 

This news doesn't play too well into LabTech's favor right now, and as stated on their official website "LabTech does NOT support VDI environments"! SO...now you have to ask yourself: "How the hell will I monitor and manage a clients VDI environment when LabTech "wont work" in there??"

 

INFO: Main challenge point really is the duplication of agents during reboots. - Simple but VERY frustrating! I've seen and heard of several failed attempts at tackling this in the past few months.

 

Well, have no fear...you have come to the right place to find out just how you can do this!!! ;)

 

Before I go into detail on this, I do want to first give a BIG THANKS to Greg B. and a colleague of mine, for helping me iron out the kinks with this. This has been a pet-project of mine for a while, and is now one that I'm glad to say is crossed of my "to-do list": Make LabTech work for VDI! - DONE! 8-)

 

Now, the actual steps involved are incredibly simple and this is what to do:

 

On the LabTech server:

 

Create/modify these keys: (this is a one time thing to prepare the LT server for this style of deployment of its agents, and will not break any "non-VDI" deployed agents you have already pushed or will push in the future!)

 

  • HKLM\Software\WOW6432Node\LabTech\Global\ Create String Value: MacSignup Value: True
    HKLM\Software\WOW6432Node\LabTech\Global\ Create String Value: MacSignupTimeLimit Value: 0

 

rjoGu8H.jpg

For info on these settings: http://bit.ly/H38wZC

 

  • Restart the LabTech Database Agent, so that the registry will reload.

 

On the MASTER TARGET (Golden Image vDisk) (assuming this is Citrix PVS/XD):

 

  • INSTALL LabTech as normal!
    Wait for it to populate in the LT Control Center and then Send an 'Update Config' to it.
    Once the 'Update Config' has finished... Do a 'Send Status' from the LT Tray icon. We want to be sure there is as much data on here as possible before we continue.
    Wait about 5 minutes for this "to bake".

 

OK... now the fun part, (these steps are scripted in the attached file!)

 

  • Stop LabTech Service
    Stop LabTech Service Monitor

 

Delete the following reg keys:

 

  • HKLM\Software\LabTech\Service\ID (or HKLM\Software\Wow6432Node\LabTech\Service\ID) - make sure you do NOT delete the Client or Location ID
    HKLM\Software\LabTech\Service\MAC (or HKLM\Software\Wow6432Node\LabTech\Service\MAC)
    HKLM\Software\LabTech\Service\Password (or HKLM\Software\Wow6432Node\LabTech\Service\Password) - make sure you do NOT delete the ServerPassword

 

 

Next thing you would do is continue as normal, run XenApp Prep and shut down your master template!

 

PS: The ltsvc.exe and ltsvcmon.exe services are set to "Automatic" so they will start when you fire up your images.

 

Let me know how this works out for you all...and stay tuned as I will soon be posting an updated script that will do BOTH the "LabTech Prep" stage and the XenApp Prep stage in ONE simple double-click! That way it saves the admin from forgetting to run this "LabTech Prep" before running XenApp Prep! (seriously...just open the batch file in the attached zip and be prepared to be "underwhelmed" by how simple, but massively effective this is!!) :shock:

 

Enjoy.

 

As always... I will welcome any and all feedback, comments and improvements/suggestions, but as stated before.... it really is a very simple set of steps to make this work. Its just not "officially supported"... yet!

LTPrep-v1.0.zip

  • Like 1

Share this post


Link to post
Share on other sites

Martyn,

 

I wanted to let you know that I tried what you outlined and it works great but the only problem I encountered is that when the labtech services start, they cause windows to notice a change and from there the system no longer is activated. I was working with my co-worker on the provisoning server side and it all boils down to when the labtech services are set to not start, the activation never is a issue but when the labtech services start, the activation windows appears because the new keys are added.

 

I've tried so many different ways to get around this but I can't find the right solution. We are using the KMS to allow the server to activate directly with a KMS server so I'm not sure if that is a problem.

 

What I'm trying to do is find a way to make windows authenticate after the services have started. Have you encountered this problem when setting up you PVS? Also, do you know the regkey location for the serial number reported in labtech as I like to have that one deleted as well?

 

Thanks

Share this post


Link to post
Share on other sites

Hey,

 

What you could do is set the LT (mainly the ltsvc.exe) services set to Automatic (Tiggered Start), this way one all the activation is taken care of, then based a trigger (that you can manually set) the LT Service(s) will then start.

 

The "Triggerd Start" option is not available via the services.msc GUI, but a little command help (detailed here: http://msdn.microsoft.com/en-us/library/dd405513(VS.85).aspx) you may be able to make this work.

 

As for the 'serial number'...which one do you mean? Can you possibly take a screenshot of that, so i know what you are referring to please?

 

Let me know what you come up with! :)

Share this post


Link to post
Share on other sites

From the agent console on the Welcome screen in the OS/BIOS section you'll see the serial number. The reason why I ask is because In Connect Wise it'll register the device as a managed service but I found that the ones with the same Serial Number never show up. If we can change it then it would help that would allow me to have the device registry.

Untitled.png.1a6def4e4ca001c2f8b70511bde7cb19.png

Share this post


Link to post
Share on other sites

Ignore as I think the serial number comes from the ESX host that the VM is on as I found serveral other customers we have on our hosted platform that were on the same host with the same serial number.

 

I'll test the other option to prevent to activation and let you know what I find.

 

Thanks,

Brian

Share this post


Link to post
Share on other sites

All,

 

This function works great as I found my initial problem has something to do with the PVS server and when the maintenance disk is converted to production or test.

 

Removing the three keys mentioned my Maryten as I use this now for when we clone out Citrix servers. I'll provide an update on what I find for our one customer that I'm having the windows activation issues once the keys are removed.

Share this post


Link to post
Share on other sites

Hi Guys,

 

This worked a treat for us until our citrix engineer rolled back the image this week to two weeks ago. Once he did that he did the following :

 

 

Logged into PVS and put the Citrix image into Private mode

 

booted the target machine and uninstalled, then re-installed LT agent

 

then ran the script to remove those registry keys

 

Then resealed the image with Xenapp Server Role Manager.

 

Now none of the agents are checking in and in the LTErrors file we see "Failed Signup, Will wait over 30 minutes to try again."

 

I have looked through LTAsp.txt on our labtech server but it doesnt really shed any light......any help would be muchly appreciated!

Share this post


Link to post
Share on other sites

Good Morning All,

 

Today is a great day for me with LabTech, VDI, cloning of servers, and getting the labtech agents on the new servers to register. I thank Martyn for laying out the ground work on how to complete this but I wanted to add some additional things to this topic. I work in an environment where we have users who clone servers or use Citrix PVS and in the beginning using this method was great as I would make all the key changes and away we go. The problem came when other techs would forget to delete the keys on the base system for the VDI server and they would also forget the steps on the cloned sever to get the new server to report leaving me to sort out the details.

 

Over time I needed to have a way that would correct this automatically without me having to do anything and I came up with a great solution. I created a batch file script that will perform a reg check for the LabTech MAC value and check it against the physical NIC's MAC address and if they're the same, the script will exit but if they don't match, it stops all the services and deletes all the keys and then starts all the services.

 

I've created a GPO configured for computer settings, startup script and applied it to an OU in active directory. This works great and now as long as the tech place the server in the correct OU, I no longer have to check for new devices as the server when it starts up will run the script and correct itself. I also added a tag in there that will create an event log under the application so you can see that the script was completed successfully.

 

Wanted to pass along to the community! I've attached a copy of the script so use at your lesiure!

lt-regkey-check.zip

Share this post


Link to post
Share on other sites

This is great, but one thing to keep in mind is that if you use the EXE installer on a 64-bit OS, the registry key will be located in HKLM\Software\LabTech\Service instead of HKLM\Software\Wow6432Node\LabTech\Software. Instead for detection, I would suggest changing the check to look at the registry values.

reg query HKLM\Software\LabTech\Service /v LocationID

Then if your variable is > 0, run here, else run in Wow6432Node

 

Good Morning All,

 

Today is a great day for me with LabTech, VDI, cloning of servers, and getting the labtech agents on the new servers to register. I thank Martyn for laying out the ground work on how to complete this but I wanted to add some additional things to this topic. I work in an environment where we have users who clone servers or use Citrix PVS and in the beginning using this method was great as I would make all the key changes and away we go. The problem came when other techs would forget to delete the keys on the base system for the VDI server and they would also forget the steps on the cloned sever to get the new server to report leaving me to sort out the details.

 

Over time I needed to have a way that would correct this automatically without me having to do anything and I came up with a great solution. I created a batch file script that will perform a reg check for the LabTech MAC value and check it against the physical NIC's MAC address and if they're the same, the script will exit but if they don't match, it stops all the services and deletes all the keys and then starts all the services.

 

I've created a GPO configured for computer settings, startup script and applied it to an OU in active directory. This works great and now as long as the tech place the server in the correct OU, I no longer have to check for new devices as the server when it starts up will run the script and correct itself. I also added a tag in there that will create an event log under the application so you can see that the script was completed successfully.

 

Wanted to pass along to the community! I've attached a copy of the script so use at your lesiure!

Share this post


Link to post
Share on other sites

Brandon,

 

If you look at the code, it's aready doing that. If it doesn't find it in the normal location, it'll then default to the 64bit folder location. I had gone through this exercise for like 3 months prior to posting this to catch the different variations.

Share this post


Link to post
Share on other sites

Has anyone tried this with Citrix VDI-In-A Box as opposed to Xenapp/XD? If so, is it basically the same configuration?

 

Thanks

Share this post


Link to post
Share on other sites

Looks to me like the server-side keys no longer exist. I've just migrated to a FRESH LT10 install and I only have;

Labtech >

- LabVNC

- Service

 

Note: No General..

Share this post


Link to post
Share on other sites

I have a ticket open with LabTech on this. I have confirmed this works great in VMWare and Citrix Xenapp/Desktop 7.X with an E1000 nic, however this doesn't appear to work if you use vmxnet3. The MAC registry key never gets populated and I end up with a new copy of the machine in LabTech every night when the citrix servers are refreshed.

Share this post


Link to post
Share on other sites

Limabone, did you ever get this figured out? I appear to have the same issue with the vmxnet3 card but it is only for one client and they have two images and it only seems to happen on one of their images. Both have the vmxnet3 card but I have other servers with it too and they all work fine. I can't point it to the card specifically as we use that card everywhere and it is only this one image for this one client.

 

Just wondering if you ever got it to work and if so, what you did. Any other suggestions would be great too.

 

Thanks

 

Neal

Share this post


Link to post
Share on other sites

I never did get around to trying to get it to work. LabTech basically told me it wasn't a supported environment and I had to move on to other things which is unfortunate. I did have a plan to change the LabTech services to be delayed start, thinking that might help, but I haven't tested it yet.

Share this post


Link to post
Share on other sites

That's too bad. It is strange they say it isn't supported as regardless of it being a VDI thing, the MAC address isn't being recorded and if you are using MAC registration that would be an issue. I just don't know what the issue is since it is only happening to servers based off one image. Maybe I will re-install it on that image to see if that works.

 

I doubt delayed start would work as those keys don't get recreated until the services are started. I tried doing it manually today and it still didn't work. This procedure works great otherwise.

Share this post


Link to post
Share on other sites

Oh you are a lifesaver... I was looking into other tools to support these VDI environments.

 

Tell me how i can send you a redbull or coffee haha

Share this post


Link to post
Share on other sites

I posted a question about how people handle ScreenConnect with these kinds of setups before and unfortunately heard crickets. Either nobody else has the issue or nobody has found a solution to it. Well, with the help of a senior ScreenConnect engineer I got this to work. I can post it up here if anyone does have the issue but here is how it works.

 

ScreenConnect, much like LabTech relies on its unique ID to work. The same as LabTech, when you boot multiple machines from an image they all have the same ID and you end up connecting to the wrong machine. What we put together is a Powershell script that you put into the startup of the machine. When the machine boots it strips out the GUID part that is supposed to be unique and substitutes it with some value, in our case we are using the computername since they are generally unique with the way we name our client servers. If after the machines boot you do an update plugins on them the button will now reference that new ID. Basically the ScreenConnect ID consists of two parts, the first one is the ScreenConnect server ID which you will get from the ScreenConnect server (all your agents will have the same one), the second part is a unique ID that must be different for all machines that report in.

 

There is some minor modification for each client you have to deploy this to as you have to first install ScreenConnect into the image and record the GUID. You then replace the GUID in the script with the GUID you recorded. After that when the machines boot they will detect the GUID you entered and whenever they find that they will replace them with the ID you set (computername).

 

My PVS images now all consist of a shutdown Group Policy script which runs LTPrep and a startup Powershell script which runs this process. It is completely automated so no matter who makes the changes to the image they will fix themselves as I am not the one that generally makes them.

 

I am happy to share the Powershell if anyone is interested.

 

Neal

Share this post


Link to post
Share on other sites

Sorry for the delay uploading this guys, been really busy with the final steps of going live and at Automation Nation now.

 

There are a few things you need to do with this script. The script works based off the ID that gets assigned to the server as well as the ID that gets assigned to the actual agent. The service ID is linked to your server so every machine that is deployed to report into your server will have the same service ID. The other ID has to be unique for each machine for them to report in properly report in and that is the part that breaks with ScreenConnect in PVS type setups.

 

Attached is the PS1 file that does this. I put it in the local GPO on the image as a Powershell startup script and once it is published into the startup it will fix the images as the server boots. There are a few things you will need to modify in it to get it to work for your environment.

 

Everywhere there is the option, replace it with your service ID. You can find that from the actual name of the service in the services control panel or from HKLM/System/CurrentControlSet/Services/ScreenConnect Client . Replace the entire including the <> with that value. It should exist 3 times in the script.

 

Next, we need to replace the computer ID. This part has to be unique. The first thing you need to do is install ScreenConnect on the image. Once that is done, go to the same registry key listed above. From there you need to open the ImagePath key. This is the tricky part. It is easiest to copy that entire key to notepad or something.

 

In that key, look for the section between the s= and &k. It will look similar to s=bb31694d-a8d0-414b-b108-85fab013f02d&k and be located after the server URL. It can be tricky to find but copy everything between those values. In the PowerShell script on Line 2 replace the big number between the quotes with this value from the registry. Make sure you leave the quotes.

 

Basically the way the script works is whenever it finds that GUID value in the registry it removes it and replaces it with a variable that equals the computername. The only issue you might run into is if you end up having two servers with the same name for different clients. You could fix that with modifying line 1 to calculate something different but that hasn't been an issue for us. As for deploying this, you can use the same script for all clients. The service ID will always be the same but you will have to modify the agent specific GUID on line 2 as it will be specific to the image you are running this against so it will have to be modified on every clients image.

 

This has worked well for us and PVS is working properly with ScreenConnect now which is great.

 

Let me know if you have any issues.

 

Neal

ScreenConnect - Copy.zip

Share this post


Link to post
Share on other sites

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