Adding a desktop via hostname actually adds it via IP?

When you import a machine into vWorkspace, we stamp the registry with a Unique ID.

This makes the datacollector connect to the Connect broker and identify itself using the unique id.

This sends a message to the Broker including the new ip address (causing the flipflop you see)

Add the computers via name instead.

Sorry I'm confused; I AM adding the computer via name. 

Hi Nick,

I'm curious as to why the Desktops change their IP so frequently, I understand that the lease time expires but before the lease time comes to an end, the client should contact the DHCP server to renew the existing lease and the same address should be kept.

How short is your lease time? What kind of DHCP server do you have in your environment? How many DHCP servers do you have and are these changing often? How often are these machines left turned off (I'm assuming they are physical machines) and how long for?

If this is only 5 machines and you cannot force the clients to renew correctly, perhaps you can create 5 IP reservations in the DHCP scope based on MAC address?

Thanks, Sam

Sorry Nicholas, my mistake.

Interestingly, I added my physical machine via IP and it's changed IPs several times since then. vWorkspace has always tracked it correctly.

Here is what happens when adding Physical machines (Slightly different to VMs):

When added by hostname, we will look up the details via DNS, initialize the machine (which involves stamping a unique code in the registry) and from that point forward the machine sends heartbeats to the broker and this is used to track it.

However, if the machine is shutdown, for example, the heartbeats stop. After 3 missed heartbeats the broker will attempt to connect to the machine again.

It does this by checking DNS for the IP address and then attempting to start/install the Data Collector on the IP that DNS responded with.

I suspect this is where your system is going wrong. What manages your DNS ? There is an AD/DNS/DHCP setting that allows machines to update DNS with their new IP address. This means that as soon as a new machine has been assigned an IP, it will tell DNS and that should prevent the issue you're seeing.

It may be possible that 2 machines ended up with the same "unique" stamp because of a DNS setting like this not being set. So to check this, open up regedit on both machines (The correct machine and the new one) and navigate to

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Provision Networks\Common\ComputerID

If both have the same ComputerID, this is continuing to cause your issue and the registry key should be deleted from the machine that you don't wish to use and the Quest Data Collector service should be stopped.

Thanks, Andrew

Hi Andrew,

Yes - it doesn't happen every time.  Just sometimes for some reason.

Thanks for your explanation.  This could be where there's an issue.  Our DNS is MS. 

"There is an AD/DNS/DHCP setting that allows machines to update DNS with their new IP address... that should prevent the issue you're seeing"   OK.  Where is this setting?  Would be good to check it.

I found a PC entry in vWS that was flipping, and you're right.  The two PCs it's flipping between both have the same ComputerID reg entry.

I could delete this entry, then stop (restart??) the Quest Data Collector service on which PC?  The one that vWS shouldn't be talking to, or the one it should be?

This is still a bandaid solution - it's not ideal that a team will have to monitor all the PCs and perform these steps every time we find a problem computer.  Is there a better way?

To be honest the easier way for us to fix it is to just remove the PC from the vWS console, then add it back in again, but still this is manual and means we have to constantly look out for this problem occuring.

Thanks,
Nick.

Hi Sam,

I wouldn't say the IPs change frequently, but we have almost 300 physical PCs in this desktop group, so IP changes are bound to happen.  Yes, in general PCs will pick up the same IP that they had before, but not always.  Our DHCP lease is set to 1 day, which is quite short and will possibly exacerbate this issue.

Our DHCP is Microsoft 2012.  We have 1 DHCP server.  The machines are user PCs, so can be left on all the time, or rebooted a hundred times a day.  Generally I'd say they're left on for the most part.  Forced reboot every month or two for patches.  I'd say they're generally not left turned off for any period, but I'm not sure.

Setting static IPs is a bandaid, and we have used it from time to time to fix this issue for important PCs, but it's not a proper solution...

Thanks,

Nick.

Hello,

The best option is to make sure vWorkspace doesn't get confused again. The way to make sure this happens is to make sure your Clients /DHCP always updates the DNS server with the new IP and then we shouldn't get confused.

This article explains how you can configure this to work. support.microsoft.com/.../816592

To answer your new question.

1. Stop the Data Collector on both PCs.

2. Delete the reg key from the PC that vWs should not be talking to.

3. Start the Data Collector on the PC that you want vWs to talk to.

Thanks, Andrew.

Ah i see.

Yep we already have the "Register this connection's address in DNS" ticked for clients, all clients are windows 7 and above, so we shouldn't need the "Dynamically update DNS reconds only if requested by the DHCP clients" setting.  The DNS appears to be getting updated correctly anyway, i don't think this is a problem.

What i see as the problem is when the IP changes on PC-A, vWorkspace will connect to the existing IP which has now been allocated to PC-B, and say "oh, i need to initialise you again for some reason", and then assign the same ComputerID to that PC-A has to PC-B which is where the issue starts.  Really at this point, vWS should say "OK, in the console i have your hostname as 'PC-A', but I see your hostname is 'PC-B', so i will ignore you and wait for the real PC-A to check in again and update it's IP.

DNS isn't instant, so if vWS connects to a DNS name that has a new IP (and is a different (wrong) computer), it shouldn't automatically assume that this PC is the correct one.  At this stage it appears to be automatically assuming DNS is always 100% correct, which i don't think is a sustainable position..?

Yes, it's only physical machines that we have to use DNS for. The rest we ask the Hypervisor for the current IP of the machine.

The DHCP setting might still help as, normally, a client only re-registers it's current IP with DNS every 24hours. 

For physical machines, The way we protect against this at the moment is that the Heartbeat from the datacollector also sends the current IP address to the Broker. Also, a heartbeat should be sent to announce the machine is being shutdown - this means our console will mark it as Powered Off and none of the Initialize stuff would happen.

So for what you describe to happen,The PC would need to be Powered off in a non graceful way or removed from the network without ceremony - eg, unplugged network cable. And then left turned off /unplugged for longer than it's DHCP lease.

Is this normal in your environment?

Is it that the PCs are turned off for a long time or is it that they are laptops that are sometimes away from the office?

Or is it that your DHCP lease is really short? 

If you're only using Physical Machines there, a good way to avoid this problem other than remember to shut the machines down. Would be to increase the amount of time that should pass before we initialize a machine - this should give your DNS a chance to update.

You can 1, Increase the amount of time between heartbeats. 2.Increase the number of missed hearbeats before we mark it as offline 3. Increase the amount of time that we wait before we try to initialize an offline machine 

This means that the physical machine will have more time to come back on and send it's own heartbeat with it's new IP address too.

I can still see a scenario where you'll get this problem though (Laptops most likely) so if you have this need, raise a Support case and we'll get it raised as an issue. 

Thanks, Andrew.

Hi Andrew,

Thanks for the explanation.  Our DHCP lease was set to 1 day (historical reasons, but we can change this now).  Also, in every case I can remember, a laptop was involved.  What's probably happening is the user is closing the lid, and then undocking the laptop from the dock without shutting down, which is a behaviour I don't think we'll be able to change.

Probably the combination of the short lease and undocking will be the issue.  Changing the lease to 7 days will vastly reduce the problem, but not eliminate it.  If the laptop get's a new lease on day 1, then at day 6 they are undocked from the network, i'm guessing we'll still have the problem if it's not redocked within a day to reclaim the IP.

Regarding your work arounds, I imagine #1 and #2 will have undesirable side effects - the console won't be as up to date as it previously was.  #3 sounds interesting, however.  Really, I only EVER want to initialise a PC when I manually add it to the vWS console.  I don't want vWS running around initialising for me.  I can't see why i would ever want this?  How can i change this setting?

Thanks,

Nick.

Yeah, there is definitely a need to change this behaviour for the laptops.

I can't find you in our system to raise a case for you. If you can raise a case, I can get this logged as an option for Physical machine so that we don't try to initialise it.

The initialise is needed for VDI.

Currently, there isn't actually a way to turn it off. The maximum delay with just option 3 is 1 hour. The reason I mention 1 and 2 is  with the heartbeats every hour and up to 10 missed heatbeats you get 10 hours before marked offline and then another hour before we try to initialise it.

I still don't think that'll be enough time for your Laptop users though.

With regards to the DHCP lease, the client should try to renew it's lease halfway through it's lease period but there will still be times with Laptop Users where this goes wrong.

Let me know the SR number when you raise a case and I'll take it so you don't need to re-explain all of this :)

Aha, a workaround:

If you don't want the initialise to cause this issue, edit the Administrative account that you have specified for the Desktop Group (or for individual machines within the desktop group)

1. Right Click on the Desktop Group and select Properties

2. Click on Administrative account

3. Type in a fake name into the account

4. Any initialise task will now fail

5. When you genuinely need to use an Administrator account, you can override the account on a per machine basis so you can quickly add in the account, do the task and then set it back to use the Desktop Group account.

Hi Andrew,

I actually already opened a ticket back when I created this forum post.

SR Number:2293529

It's pretty old though.  Will this do?  Or do i need to open another one?

Nick.