XenDesktop – Assigning Private Desktops by Client IP or Hostname

Background Information

By default XenDesktop provides desktops on a First Come First Serve basis and, with regards to Private Desktops on an “Assignment on First Use” basis. In some scenarios, it’s preferable to pre assign these private desktops based on a client device. This document is only applicable to Delivery Groups with private desktops – the following will not work with shared delivery groups.

Assigning Private Desktops

The “Get-BrokerPrivateDesktop” and “Set-BrokerPrivateDesktop” cmdlets are used to allocate particular desktops to a client.

References:

http://support.citrix.com/proddocs/topic/citrix-broker-admin-v2-xd7/get-brokerprivatedesktop-xd7.html

http://support.citrix.com/proddocs/topic/citrix-broker-admin-v2-xd7/set-brokerprivatedesktop-xd7.html

Use the command as follows:

Set-BrokerPrivateDesktop DOMAIN\DESKTOPNAME –Option1 Option –Option2 Option

The following options are recommended:

-AssignedIPAddress <string>

This is the local IP of the connecting client.

-AssignedClientName <string>

This is the NETBIOS (NB: Not the FQDN) name of the connecting client. NB: Does NOT work if an IP Address is assigned. Clear the IP first.

-PublishedName <string>

This is a custom published name to differentiate the pre-assigned private desktop from the rest of the Delivery Group (NB: As of XenDesktop 7.1, it appears that you are unable to remove a PublishedName attribute once it has been assigned!) e.g:

Set-BrokerPrivateDesktop CONTOSO\VDI001 –AssignedIPAddress 10.12.43.98 –PublishedName “Front Office”

The following can be used to get a quick overview of what has been assigned:

Get-BrokerPrivateDesktop | ft MachineName,AssignedIPAddress,AssignedClientName,PublishedName

Removing the Non-Assigned Desktop

After assigning a client device to a specific VDI Desktop, users will be presented with two desktops – the pre-assigned client-based desktop and their own user-based desktop, from the same delivery group. If all desktops have been pre-allocated, the user will still see a launch icon, though an error will be displayed when attempting to connect.

The “Get-BrokerAssignmentPolicyRule” and “Set-BrokerAssignmentPolicyRule” cmdlets are used to control this.

References:

http://support.citrix.com/proddocs/topic/citrix-broker-admin-v2-xd7/get-brokerassignmentpolicyrule-xd7.html

http://support.citrix.com/proddocs/topic/citrix-broker-admin-v2-xd7/set-brokerassignmentpolicyrule-xd7.html

Use the commands as follows:

Run “Get-BrokerAssignmentPolicyRule” to return a list of rules. Note the “Name” of the assignment policy rule you want to modify (It will almost certainly match your Delivery Group name)

The following command will now disable the ‘default’ user-based desktop:

Set-BrokerAssignmentPolicyRule –Name “Desktop Name” –Enable $false

Where a client has a private desktop assigned by IP or Hostname, only that desktop is displayed. If the user logs on elsewhere, no desktop will be displayed.

Alternatively, the “ExcludedUsers” option may be used to only hide this desktop from particular users.

Delivery Group Authentication

By default, XenDesktop only uses Users and Groups to authenticate against a Delivery Group. If a user is not in the Delivery Group they won’t see any desktop associated with it, even if the desktop has been specifically assigned to their client device.

Get-BrokerAccessPolicyRule” and “Set-BrokerAccessPolicyRule” can be used to modify Delivery Group authentication beyond what is possible from within the console.

References:

http://support.citrix.com/proddocs/topic/citrix-broker-admin-v2-xd7/get-brokeraccesspolicyrule-xd7.html

http://support.citrix.com/proddocs/topic/citrix-broker-admin-v2-xd7/set-brokeraccesspolicyrule-xd7.html

Specific configuration is out of the scope of this document, but it’s possible to base authentication on IP Address or to simply open up the Delivery Group to all users.

Share

7 thoughts on “XenDesktop – Assigning Private Desktops by Client IP or Hostname

  1. Hi,

    I have a question, it is regarding the set-broker command, we want to assign a specific vm/vdi to thinclient. We did successfully assign 1 vm/vdi to thinclient1, but when we try to assign the same vm/vdi to thinclient2, it is not working.. why is that?

  2. Hi there

    A very interesting Blog. It is almost what I am searching for, but the Requirements I have are going a little bit further. I search for the Possibility to do exactly what you describe (Assign the VDI to the Client IP) but I don’t want to publish the VDI Desktop, I have to publish VM Hosted Apps.
    It is because the User have also some Applications installed on the Client.
    We need the Fixed Allocation because of local attached Hardware we need in the VDI who uses a Software with a Local Database (on the VDI)…. So it has to be the same VDI for the Client, but not the Desktop, just the Application.
    Is there a possibility to use VM Hosted Apps, assigned to the IP Address of the Client? It is working assigned to a User…

    Thanks for your Help

    Tobias

  3. My question seems fairly basic but I have not found a solid solution outside of VDiaB Kiosk-mode. The goal is to replace conference room physical desktops with VDI (XD7.6). Essentially create a Machine Catalog and Delivery Group for each Conf Rm and then static assign the Desktop to a thin/zero client in each room. This would be a single desktop to many user environment which desires that user profiles be kept locally and persistent (no current UPM). I am at a loss with XD and the requirements.

    Perhaps publishing a desktop for each Conf Rm from XA would work better? My other option would be pushing the use of “conf_room_xx” login accounts as opposed to allowing personal logins.

    Thoughts? Thanks!

    • Hi – if you’re absolutely set on using local profiles (Which I have to say does go against the grain somewhat) you’d simply need to create a single machine catalog and delivery group with [x] number of persistant dedicated desktops. You can then use this guide to manually assign IP’s to a specific Virtual Machine

  4. Hi Dan,

    Just wondering if you know any way possible in Citrix XenDesktop 7.1 to assign specific IP from a range/pool to a specific group like the following:

    Delivery Group 1 – (Server Team, 8 people)
    IP address range: 10.117.84.1 until 10.117.84.8
    Firewall Access type: all servers unrestricted

    Delivery Group 2 – (Application Team, 20 people)
    IP address range: 10.117.84.9 until 10.117.84.29
    Firewall Access type: Business Object Servers, SAP Servers, SQL Servers and Oracle Servers only.

    Delivery Group 3 – (Accounting & Finance Team, 50 people)
    IP address range: 10.117.84.30 until 10.117.84.30
    Firewall Access type: SAP Servers, Quicken Servers and Finance Team Servers only.

    Delivery Group 4 – (Remote Access outside of Office, the rest of the people)
    IP address range: 10.117.84.31 until 10.117.84.253
    Firewall Access type: Exchange Servers, SharePoint Servers and File Servers only.

    the reason it has to be done in that way because the firewall rule must be defined per specific IP address group.

    is that possible with Either MCS or PVS delivery type ?

    • Hi Aladmin,

      Yup – you should be able to do most of this by using the “Set-BrokerAccessPolicyRule”. Use Get-BrokerAccessPolicyRule to confirm your changes and to get your rule names.

      You’ll need to enable the Client IP filter by running the following command:

      Set-BrokerAccessPolicyRule -Name “Rule Name” -IncludedClientIPFilterEnabled $true

      You can then add IP’s that are allowed using the following:

      Set-BrokerAccessPolicyRule -Name “Rule Name” -AddIncludedClientIPs IP_ADDRESS_HERE

      You can use individual addresses or a subnet mask, but I’m not sure if you can easily define a range.

      E.g:

      Set-BrokerAccessPolicyRule -Name “Rule Name” -AddIncludedClientIPs “192.168.1.1”
      Set-BrokerAccessPolicyRule -Name “Rule Name” -AddIncludedClientIPs “192.168.1.0/24”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.