Hi guys I'm working on a blog that discusses the u...
# citrix-vad
l
Hi guys I'm working on a blog that discusses the usage of tags with citrix and was looking for use case on were people have used tags and also thoughts and opinions if they are good, bad or ugly
👀 2
b
Reboot schedules, maintenance mode, scaling plans, dedicated desktops within a DG... there are plenty usecases
s
Love tags.
l
But why have in a delivery group and not just have more delivery groups. @Balint Oberrauch just play devil's advocate here. Is it just not an over complication?
s
In small shops it may not seem like you need it, but at scale it helps consolidate.
a
I leveraged tags for reboot. I used Posh scripts to toggle maintenance based on tags. This allowed a set of systems to be available for overnight processing and the rest were rebooted. Then maintenance was toggled on the 2 sets of systems before the start of business day. I've need to write up the Posh module I wrote for this and get it pushed to the Posh Gallery. Another thing on the to do list 😁.
👍 3
l
thanks @Alain Assaf
the main use case i had seen was to group servers of a delivery group into different desktops
i hand not thought ob the script use case
p
Tried tags in application groups. Works well. Tried tags in a delivery group, to split users across VMs in different locations. Didn’t work consistently.
👍 1
l
@Paul Brown cheers
c
I have two application groups with all the production apps added (Prod/Pre production) and two Delivery Groups prodduction/pre prod. I then use priority and tagging to limit resource launches based off AD group membership to the Prod/pre production application groups. I can then test PVS Vdisk updates to a subset of users by just adding them to the Pre production AD group and next time they launch their production apps they launch on the pre production VDA's booted off the new Vdisk version
j
There is a limit to the number of tags you can have - think it's about 400 or something
👍 2
We used to use them for chargeback purposes. so we could bill different business units correctly
l
ahh that's inventive
d
I used tags, to provision five published desktops, from the same pool of VDAs, for the users to have multiple desktops running, from the same delivery group.
l
This is how i see the tags used mostly and getting more popular @Daniel Madsen what are the benefits that you see going it this way and not just use separate delivery groups. Try not to have my own opinion on this as mine might not always be the best.
s
Ive used tags for FMLA, maternity leave, VIP Desktops or security isolation / forensic analysis so people knew not to delete them in studio. We had a posh that would delete unused desktops after x amount of days. If one of the tags was applied, the posh would skip. Also what someone else mentioned about reboot schedules to kind of fool proof that no one would reboot all the desktops in a group at once.
👍 2
j
The point of tags is that they can be used for many different purposes. They're a tool you can use or not use dependent on your environment and requirements. Think about AD - do you put all your objects in a single OU and use filters for policies or do you nest all the OUs and put the policies on the OUs they apply to? Or mix and match? The choice is yours - there is no right or wrong answer. Use tags if your organization needs them or you have a specific use case they will help to meet. If you don't need them, don't. Sometimes it is down to the personal preference of the architect or admin. To summarize - YMMV
👍 1
l
Thanks guys 🙂 what i love about these slack channel s are these open dicussions
d
@Luke Irvine, this was for a special use-case, where the users needed Single-Session VDAs with large workloads. That was the only reason. On the same occasion, we changed to UPM, since FSLogix wasn't able to write-back from every session. Haven't look back since 🙂
j
I love them, my env is dynamic thanks to them. A tag per desktop (prod, silo-env1, etc.). Very simple to script and reliable. Used also for reboot. It was the game changer that finally trigger the migration from XenApp 6.5 to 7.x.
c
Had a situation where a bad app required a certain Citrix Policy be disabled or it crashed. Tagged persistent virtual desktops where this app was run to apply the policy.