This message was deleted.
# _general
s
This message was deleted.
r
They should keep the same ip address unless you are out of available IPs. Maybe you need a larger subnet.
c
It is split between 2 subnets. I am just afraid that the web console, and other things aren't able to manage the VDAs because of the IP change. Have you ever seen an issue with a VDA booting not pulling in Group Policies automatically?
r
I have not seen issues with DHCP and MCS. For group policy applying i would include a boot script that runs gpupdate /force. Also you may want to use settlementperiodbeforeuse on your delivery group to give a little time for gpos to apply
👍 1
c
Interesting. I might have to do that. The "fix" I have been testing is deleting the computer cached group policies before sealing the image. I looked in the event viewer. I can see it pull the policies when it boots up, but it doesn't find anything to change. I am just trying to find a root cause. This was working fine for years, and this just started happening last week or so.
j
@Rob Zylowski that is is the first time I’ve seen that parameter - awesome - no more delay on desktop service moving forward in my projects - thanks 🍺
r
Agreed its a good one to know. 🍻
n
i always put my gold image into the prod ou before shutdown to get the gpo's and then update the catalog.
s
When I first deployed MCS, I had issues where the machines would occasionally boot with the wrong IP address. After trying various fixes, I ended up putting ipconfig /release, ipconfig /renew in the startup script.
m
that lease time is waaaaaaaay too low, set it to never expire or something like a month if they reboot every week.
it’ll try to get a new lease, and potentially change ip, every 30 mins
if it changes IP with sessions on it, then those sessions are hosed
c
Mike, do you have any documentation that can point to DHCP lease times for MCS? I haven't found shiiiiit. I would like to take something solid to the Network team to prove that we need to change it. Currently lease times are set for 2 hours.
I did find more info. I haven't been able to reproduce this issue when I simply restart the servers. It seems to only happen when I update/deploy an image via MCS. Currently in this env we don't have a seal script or any local startup or shutdown scripts. (this has been working fine for years) • The Gold Master is in its own OU • When the VDA first initializes it pulls in the GPOs from the Gold Master's OU • I can see a GP error in the event viewer of the failed gpupdate before the name change. Says that it will try at next interval. • It has been 30 hr, and no new gpupdate has been attempted according to the event viewer • I also see a DNS error failing to register the server PTR, as the DNS server refused. • I did an NSlookup on the IP of the last server deployed and it is reporting as the Gold Master's name • This is reflected in the gpresult.exe /H filename.html • But not with a simple gpresult /r • I deleted all the broken reverse DNS lookups and the IPs seem better, but the OUs still don't pull right. • Again this worked for years, now its broke, it is driving me crazy.
m
ooof, move the gold image to the OU that the clones are going to be in, do a gpupdate /force before shutting it down, and look into BISF for sealing, it will clean up DHCP
I can link you to my top 10 citrix optimizations talk that says fix your DHCP lease times, but as for anything from citrix themselves I'll have to go digging
c
I will take any links you got. I would really appreciate it. I know in my heart of hearts that moving the Gold Master to the OU would fix the issue, but I might get some push back because it used to work and people don't like things shuffled around.
m
https://support.citrix.com/article/CTX135500 PVS says make it unlimited but that is because of the streaming disk
https://portal.nutanix.com/page/documents/solutions/details?targetId=BP-2079-Citrix-Virtual-Apps-and-Desktops:top-best-practice-checklist.html This say the complete opposite, to reduce the lease time to 1 hour, and I have no idea why you would do that
maybe @Jarian Gibson or @Kees Baggerman know
This also says you can reduce it to a few hours
In my experience, if you are low on IP addresses you don't want to reduce the lease times, you want to increase the dhcp scope
because if you renew the lease and it changes IP everyone will lose their sessions, and if you don't have scavenging turned on or DNS auto registration working properly nobody will be able to get back into that session on the new IP because it won't update in DNS correctly
and the number of environments I've seen where it is set up correctly is staggeringly small
https://xendesktopguy.com/2015/11/30/machine-connection-failure-refused/ This is typically what I've seen with small leases
The other problem with tiny lease times is you increase your AD replication traffic if you are using AD for DNS
If you have AD integrated DNS zones and dynamic updates working you don't need to worry about lease times and scavenging and it'll probably just work they way you expect it to, but when you don't it's a nightmare and leads to all those connection refused errors
j
But a dhcp lease renewal will always take the same IP that it has been assigned during that renewal process - dhcp won’t randomly change the IP address of a server in the middle of the day when that renewal happens, that would be utter chaos - sure if a server is off, the lease expires, another device can pull it, but never whilst a server is alive and well
m
I've seen win7 VDA attempt to renew its dhcp lease in the middle of the day and get a new IP. I agree that's not how a dhcp lease is supposed to work, but it's not an impossible scenario, especially in a dhcp scope with no free IPs.
also if your lease is super low, like 1 hour, and for whatever reason it can't renew in that time then the lease will expire and it will have to release the IP and get a new one. So if you have issues with your network or DHCP server...
It's not a super common scenario but it's also not one you ever want to be in. I'm open to being convinced that super low lease times are worthwhile in certain scenarios, but I've yet to see what those are.