Mick Hilhorst 's Tech Blog

Smart Access and Smart Control are both options to change the way your ICA sessions behave. Imagine that you want to disable client drive redirection for certain users or want for only some of your users to have audio redirection. Maybe you even want to only have certain applications be shown on Storefront for users that match an exact Session policy? It’s all possible with the granularity of SmartAccess and SmartControl.

These policies are similar in their name and somewhat in their results, lets have a look at the differences and setup.

SmartAccess

• Needs to be configured on the ADC (Netscaler) and Citrix Studio
• Consumes a gateway universal license per user
• Operates on Citrix Studio level

SmartControl

• Need to be configured on the ADC (Netscaler)
• Only available in Citrix ADC Premium edition
• Consumes a gateway universal license per user
• Operates on ADC Gateway level

---

Configuring SmartControl

SmartControl needs to be configured on the Citrix ADC. You create an ICA policy, then you use an expression to filter the connections that it should apply to and bind it to the applicable Citrix Gateway.

An ICA policy gets bound to a Citrix Gateway server. Before doing so you need to decide if you want all the traffic to have the same policies, or want to filter it based on more granular expressions.

In the example I will create an ICA policy that applies to all traffic (TRUE). Please mind that this ADC version uses ‘advanced policies’ instead of the classic ones as these are deprecated. You may know “TRUE” as “NS_TRUE” (classic).

The ICA policy will have an action tied to it. If you use the gateway with the ICA policy tied to it, and your connection matches the filter defined in the expression, an action will occur. The action decides what kind of access you should (not) have.

Keep in mind that Smart Access policies tend to take precedence over Citrix policies as the Smart Access is configured on the initial connection.

Let’s get started.

1.Go to Citrix Gateway -> Policies -> Citrix Gateway ICA Policies and Profiles -> ICA Policies

---

2.Enter the Name, and define your expression.
Remember: “TRUE” applies to ALL traffic.
Then click ‘Add’ to define a new action

---

3.Name the ICA action and press ADD to define a new access profile on the action.

---

4.Enable/Disable your preferences and press OK and press OK/SAVE on all the following screens.

The ICA policy is now done.

---

5.Browse to your Citrix Gateway Virtual Servers and select the applicable one for the policy you made

---

6.Disable ‘ICA Only’ on your gateway if applicable because the policy can’t be bound / will not work otherwise.

---

7. Go to the Policies*in your gateway. Press the ‘+’ and choose ‘ICA’ from the dropdown. Next, press Continue/Bind.

That’s it, well done! Your ICA policy should now work as intended.
Be sure to share some of your cool expressions in the comments :).

---

Configuring SmartAccess

With SmartAccess you can configure policies in Citrix Studio relating to the connection being made via specific Citrix Gateways. There are a couple of prerequisites we need to complete before we are able to configure these policies.

1. Login to your Citrix Delivery controller
   1a. Enable trust requests trust sent to the XML service port with the following Powershell commands.

asnp Citrix.*

Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true

---

2.Make sure to disable ICA only for the applicable gateway.
2a. Login to the ADC and browse to the applicable Citrix Virtual Gateway.
3b. Click the Citrix Virtual Gateway and edit it.
3c. Disable the ICA only checkbox if applicable.

---

3. Make sure to setup a “Callback URL” on your Citrix Storefront server, also make sure the gateway uses https!

---

4. On your Citrix Studio server, edit the desired delivery group to filter the access.
4b. you can create a new filter by going to the “Access Policy” tab and pressing “Add…”.
4c. Make sure your

Farm name: matches that of the gateway server (remember the callback)
Filter: matches that of the (for example) Session policy binding that you have active on your gateway. If you do not want to filter, you can always use the wildcard (*) instead.

One of the great benefits is that you can control ‘Icon visibility’ with this in Citrix Storefront.
Citrix Storefront enumerates the access to the Desktops/Apps based on this filter.
If your filter does not match, the icons will be hidden which can result in a much cleaner and securer environment.

The access policies and be utilized with custom pre-authentication policies or Session Policy bindings.
There are many great use cases to be found around the internet, but now it is time to create your own!

Things to keep in mind:
*Icon visibility is based on Delivery Group visibility basis and not individual desktop/application basis
*This only works on Delivery Groups, not Application Groups.

Have fun!