One of those properties is called Limit Visibility, this is what it looks like. Having hundreds of Delivery Groups and Machine Catalogs probably isn’t what you had in mind, so what else can we do? When applications get published, either all bundled into one Delivery Group or using separate Groups, you can still configure the properties of each application on a individual basis like we were used with earlier versions of XenApp, change its name, location, file type association etc. If you need to publish and manage a few hundred applications the above method might not be your preferred approach. if you don’t assign users to your applications or desktops they won’t be able to access your resources no matter how they are provisioned.īack to application publishing. It doesn’t really matter if you’re using PVS, MCS, App-V etc. Remember that this is just a way of making your resources available to your users, nothing more. Just go through the process of creating a DG and an MC a few times, group your ‘base’ application set, and you’ll be up and running in no time. Using this approach you might potentially end with as many Delivery Groups, and thus Machine Catalogs, as you have applications which for a lot of companies might be just fine.
Although due note that for this to work you will need to create multiple separate Machine Catalogs (MC) as well since a machine can only be a member of one Delivery Group (and Machine Catalog) at a time. But what if you’d like to manage and assign applications on a more granular level, per application or smaller applications groups for example?įirst off you can configure multiple separate Delivery Groups, one per application or smaller groups of applications per DG for example. Which of course could be exactly what you want. Which brings me to the following, what if we decide to publish, let’s say, 10 applications from a single DG? No problem, it just means that all users assigned to that DG will see and have access to these applications and as such will be able to subscribe and launch them. Before I continue, if creating Machine Catalogs and Delivery Groups is something completely new to you, have a look here. Of course resources, and users, can be added or deleted from the DG as needed and there’s basically no limit to the number of DG’s you can create. Per Delivery Group you can ‘publish’ as many applications as you like, which are than managed through that particular Deliver Group. Delivery Groups (DG) are than used to take a few, or all, machines out of a Catalog (you can select them manually), next it will automatically discover all installed or available applications (it does this by communicating with the installed VDA), and last but not least, you will be able to assign these resources to your users, either individually or by AD groups. Machine Catalogs hold the machines from which our resources, applications and or desktops, are published.
Take application, or resource, publishing for example, we now have to deal Delivery Groups and Machine Catalogs, nothing new if you’re used to working with XenDesktop, but if it’s ‘just’ XenApp you know, well… Even now where XenApp 7.5 is a product on it’s own, again, it’s still based on the Flex Management Architecture meaning it also still uses the same wizards and configuration options as in XenDesktop 7.x a few months ago, for the most part anyway. With the merge of XenApp into XenDesktop’s Flex Management Architecture (FMA) a lot changed, for most XenApp admins it meant they had to rethink their designs and as a result it was back to the drawing board.
0 kommentar(er)
