Configure custom screen resolution for a Published Desktop on XenApp 7.x

Finally found some time to write about an interesting thing I discovered during one of my latest projects. With XenApp 6.5 and previous versions it was possible to configure a specific screen resolution in your application configuration this function isn’t available in XenApp/XenDesktop 7.x (Studio).

My customer had a specific use case to run a Published Desktop in a certain screen resolution. When searching for an available solution on the Internet, I came across several articles/blogs for XenApp 6.5, then I found this article from Citrix support: https://support.citrix.com/article/CTX116357 describes how to configure the special screen resolution within StoreFront for Published Apps and Desktops.

I’ve created an additional Desktop with the specific screen resolution name, this way the normal desktop is still available for use with the Desktop Viewer. 

You’ll have to turn off  the “Show DesktopViewer” in the StoreFront configuration, you can configure this in the console or in the web.config file as described in the CTX support article.

StoreFront Console
Stores, Manage Receiver for Web Sites, Configure, Client Interface Settings,

Web.config file:

1. Edit the web.config file located on the StoreFront server in the C:\inetpub\wwwroot\Citrix\storeWeb
2. In the web.config file, locate the following line:
3. showDesktopViewer=”true”
   Modify the value from true to false

So according to the support article I’ve configured the application to start with a specific screen resolution in the default.ica file located on the StoreFront server:

c:\inetpub\wwwroot\Citrix\SiteName\App_Data:

[Production Desktop 1024×768]
TWIMode=Off
DesiredHRES=1024
DesiredVRES=768

Now we should be good to go and test the specific screen resolution for this Desktop.
But directly after login the desktop is displayed in a full screen window.

So for troubleshooting purpose I started the Desktop again and instead of launching the Desktop directly I downloaded the .ica file to see what’s in the .ica file:

[ApplicationServers]
Production Desktop 1024×768 $S1-3=

[Production Desktop 1024×768 $S1-3]

There is a suffix behind the Published desktop name in my case: $S1-3

This bring us back to the default.ica file on the StoreFront server add the suffix “$S1-3” to the application name in your default.ica file:

[Production Desktop 1024×768 $S1-3]
TWIMode=Off
DesiredHRES=1024
DesiredVRES=768

Now login again on the StoreFront server or Netscaler Gateway (don’t forget to replicate the changes if you have multiple StoreFront servers) start the Desktop with the specific screen resolution and there you go:

The disadvantage of configuring Published Desktops with specific screen resolution is that all your desktops will now launch in a full screen mode unless you specify a specific screen resolution in the default.ica file. This is because “Show Desktop Viewer” is turned off in the StoreFront configuration.

For your “normal” desktop you can solve the issue by adding the following configuration to your default.ica file”:

[Production Desktop $S1-3]
Connectionbar=1
TWIMode=Off

Note: It’s advisable to do an IIRESET on your StoreFront servers after you’ve changed the default.ica file.

You have to configure this in the default.ica file for each Published Desktop if you don’t want to run it in Full Screen mode.

In my example above I downloaded the .ica file from the StoreFront website that’s not the easiest way to find the correct name of your Desktop. During the project I had contact with Citrix Support and they couldn’t tell me away to find the correct name of the published Desktop.  In the support article they refer to the following command: “Get-BrokerApplication -ApplicationName” this command will only display the Published Applications not the Published Desktops.

When trying to resolve another problem I found the following Powershell Command: Get-BrokerEntitlementPolicyRule

This command will list the BrowserName (Published Desktop name) that must be used in the default.ica file.

If you take a good look at the suffix at the end of the application name it consist of the following parts:
S1= DesktopGroudUID; this number will changes if you add more delivery groups.
3= Uid; Uid number from the Desktop “application” if you add another Published Desktop to the delivery group it will increase the Uid and the new application number has number 4.

Some additional information:
Starting from Citrix XenApp 7.6, Citrix has changed the way that the WFAPI  returns a “Published Desktop” name. The “Published Desktop” name is now returned as the “BrowserName”.

 

 

 

The Citrix Profile management could not mount virtual disk

David Wilkinson wrote an excellent article about how to configure Citrix Profile management to support roaming OST & Search Indexing.

Here’s a link to David’s article

So it was time to spin up the lab and test this new feature although there are still some limitations. I configured all the settings that are necessary and started testing the solution but I noticed after logon on the users home directory there were no .vhdx files available in the users home directory.

So I started looking at the event log and noticed the following event id 3005 from Citrix Profile Management:

Eventid 3005, Citrix Profile Management

The Citrix Profile management could not mount virtual disk from ‘\\fileserver\home$\user1\windows\VHD\Win2016\OutlookSearchIndex.vhdx’ to access point ‘C:\Users\user1\Appdata\Roaming\Citrix\Search\’.

Error code: ‘0x80070005’:

The Citrix Profile management could not mount virtual disk from ‘\\fileserver\home$\user1\windows\VHD\Win2016\OutlookOST.vhdx’ to access point ‘C:\Users\user1\Appdata\Local\Microsoft\UpmTempMountPoint\’.

Error code: ‘0x80070005’:

My Home directory configuration was done a long time ago, so when looking at this configuration it had the Domain Admins with full control and Domain Users with read/write at the share permissions.
Then I added the “default user group” Everyone back again and removed the other two user groups. And gave the “Everyone” group full control at share level.

Now login again with the normal user account on the VDA, and as you can see in the picture below the .vhdx files are available now!

This is quite interesting, and needs a bit more research. If you look at the open files at the file server you can see the that .vhdx files are accessed by the VDA machine account in my case worker01$:

Just to make sure to see if Citrix Profile Management is using the machine account for accessing the share I removed the “Everyone” group from the Share Permission and added the computer account: worker01$ with full control and the Domain users with read/write permissions and Domain Admins with full control
Next removed the existing profile from the file share and logon with the user account and the .vhdx files are created again during the login process.

Of course if you have multiple VDA’s you can also create a computer group for the VDA computers, instead of configuring them individually.

I’ve searched on the https://docs.citrix.com/en-us/profile-management/current-release.html to find out if there are special requirements for the share permissions with Citrix Profile Management but I couldn’t find them.

 

 

 

XenApp VDA 7.15 CU1 breaks Single Sign-on with Citrix FAS

This weekend I was busy upgrading my demo lab to the latests Citrix 7.15 LTSR CU1 release. In my demo lab I’m running Citrix VDA 7.14 version so after upgrading the VDA to version 7.15 CU1 (LTSR) I noticed Single Sign-on to the desktop was no longer working I got prompted with a login screen on the Window Server 2016 VM:

Looking at the StoreFront and FAS server I didn’t see any errors.
When checking the Windows event log on the VDA I noticed the following error:

While searching on the Internet I’ve found the following article on the Citrix discussions forums: https://discussions.citrix.com/topic/389163-715-vda-upgrade-password-not-passing-through/

When rolling back the VDA to version 7.14 the Single Sign-on works correctly.

If you look closer at the error the VDA cannot find the FAS Server
[S101] Identity Assertion Logon failed. Unrecognised Federated Authentication Service [id: 0]
When VDA 7.14 was installed I found that in the registry at the following location the FAS server is configured:

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Citrix\Authentication\UserCredentialService\Addresses] 
“Address1″=”myfasserver01.domain.local” (REG_SZ)
&
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\Authentication\UserCredentialService\Addresses]
“Address1″=”myfasserver01.domain.local” (REG_SZ)

I exported both registry key’s to a .reg file. After this I upgraded the VDA again to version 7.15 and noticed that these key’s are no longer present after the upgrade.

Now when adding the .reg files that I’ve backup-ed earlier the Single Sign-on works again with VDA 7.15 version. When you reboot the server the registry entries remain on the system.

I’ve also tested this with the VDA version 7.17 and I can confirm that this works correct without the workaround described above. But the 7.15 is an LTSR version so most company’s use this version to ensure they have longterm support.

(Beware that this is a workaround for fixing the Single Sign-on problems for VDA version 7.15 CU1, use this at your own risk and test this in a non production environment first.)

 

 

Netscaler AAA virtual server with SafeNet Grid Token

I’m currently involved in a project on migrating several websites from Microsoft TMG to Citrix Netscaler. Depending on the security level for the website we configure LDAP (Username and Password) or MFA (Multi Factor Authentication) with LDAP & RADIUS for these websites. Our customer is currently using Safenet Grid Token for MFA on the Microsoft TMG so we need form based authentication on the Netscaler, this can be accomplished with Netscaler Gateway or Netscaler AAA Virtual Server.

In my opinion the best way to do this, is with a Netscaler AAA virtual server but remember this requires a Netscaler with Enterprise or Platinum license.  When you use Netscaler Gateway for authentication you have to secure the Netscaler Gateway server to prevent unauthorized access to other internal services or the possibility to setup a SSL VPN. When you use Netscaler AAA virtual server you’ll only get access to the page that’s requested.

SafeNet published an integration guide for Citrix Netscaler with Netscaler Gateway you can find this here. Unfortunately there is no integration guide available for integration with Netscaler AAA virtual server. I’m only describing the changes that are necessary on the Netscaler the SafeNet cloud configuration should be preconfigured.

So when trying to configure the AAA server I followed the integration guide for Netscaler Gateway starting on page 17:

Instead of modifying: index.html and gateway_login_form_view.js you need to change the files according to the integration guide: tmindex.html and tmindex_view.js for the AAA virtual server.

When you open your AAA virtual server or the website you configured with Form Based Authentication you’ll see the following screen displayed: 

When you fill in your User name and click on the Get Grid button nothing happens !!!

I started debugging the page with the Google Chrome Debugger (F12) you’ll see the following error displayed when you click on the Get Grid button:

Uncaught TypeError: Cannot read property ‘value’ of null 
at getChallenge (tmindex.html:92)
at HTMLInputElement.onclick (tmindex.html:1)

So when looking at the debug message I found out that the GetGrid button action is trying to find the User Name that is typed in the form this doesn’t work.
After that I started to look in the gateway_login_form_view.js file because this works with the Netscaler Gateway. There is piece of code missing in the tmindex_view.js file:

gateway_login_form_view.js: (line 33)
var enter_user = $(“<input type=’text’></input>”).attr({‘id’:’Enter user name’,’class’:’prePopulatedCredentials’,’autocomplete’:’off’, ‘spellcheck’ : ‘false’,’name’ :’login’, ‘size’:’30’, ‘maxlength’ : ‘127’,”width”:”180px”,”autofocus”:true}).focus(function(){loginFieldCheck();});

tmindex_view.js: (line 27)
var enter_user = $(“<input type=’text’></input>”).attr({‘class’:’prePopulatedCredentials’,’autocomplete’:’off’, ‘spellcheck’ : ‘false’,’name’ :’login’, ‘size’:’30’, ‘maxlength’ : ‘127’,”width”:”180px”,”autofocus”:true}).focus(function(){loginFieldCheck();});

So what’s missing is the: ‘id’:’Enter user name’
You can copy the code from gateway_login_form_view.js (line33) and replace it in tmindex_view.js on line 27 and upload the file to your Netscaler. Without the attribute id: “Enter user name”, the credentials can’t be sent to SafeNet to request a Grid Token. I don’t know why this is missing in the default tmindex_view.js file on the Netscaler.

Now when we go back to the Netscaler AAA Virtual Server page and type in our User Name and hit the Get Grid button we’ll see the GridToken displayed:

Now users can succesfully retrieve their Grid Token on an Netscaler AAA Virtual Server.

Important: Just as with the index.html and gateway_login_form_view.js you need to copy the files you just changed to the customizations folder to maintain these files after a reboot of the Netscaler.

Create the customizations directory:

mkdir /var/customizations

Copy the files to the customizations directory:

cp /netscaler/ns_gui/vpn/js/tmindex_view.js /var/customizations/tmindex_view.js.mod
cp /netscaler/ns_gui/vpn/tmindex.html /var/customizations/tmindex.html.mod

If the /nsconfig/rc.netscaler file does not exist already create it:

touch /nsconfig/rc.netscaler
chmod a+x rc.netscaler

Run the following command to add an entry to copy the file on startup of the Netscaler:

echo cp /var/customizations/tmindex.html.mod /netscaler/ns_gui/vpn/tmindex.html>> /nsconfig/rc.netscaler
echo cp /var/customizations/tmindex_view.js.mod /netscaler/ns_gui/vpn/js/tmindex_view.js>> /nsconfig/rc.netscaler

Of course you can also use VI to edit the rc.netscaler file.

I’ve had contact with Gemalto Technical Support about the integration guide for Netscaler Gateway and AAA Virtual Server with Grid Token. Their currently working on a new integration guide,  they couldn’t give a date when the new integration guides will be available. When the integration guides are available I’ll add a link to this article.

I’ve configured and tested this on Netscaler 11.1

 

RES ONE Workspace Management Portal – Install prerequisites with PowerShell

With the introduction of RES ONE Workspace V10 the new management portals are available for RES ONE Workspace & RES ONE Automation. Rob Jager made an excellent blog on How to install the RES ONE Workspace Management portal step by step. I’ve installed the management portal a few times now but the prerequisites for IIS (Web-Server) are very specific. The funny thing is that the RES ONE Automation Management Portal installs the prerequisites automatically. If you don’t have tools like RES Automation Manager I’ll show you how can can quickly install the prerequisites with PowerShell on Windows 2012R2:

Add-WindowsFeature Web-Server,AS-NET-Framework,Web-HTTP-Redirect,Web-Asp-Net45,Web-Net-Ext45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Basic-Auth,Web-Windows-Auth,Web-Client-Auth,Web-Cert-Auth,Web-Request-Monitor,Web-Dyn-Compression

Note that .NET Framework 4.5.2 also is a prerequisite you can download it over here

If you don’t install the prerequisites when you’re trying to install the management portal you’ll get the following error message: “RES ONE Workspace Management Portal cannot be installed on systems with Internet Information Services lower than 7.5″

 

 

 

 

 

 

 

 

 

The prerequisites are also described in the RES ONE Workspace Administration Guide:

Hopefully RES changes the installer to automatically install the Window Features just as with the RES ONE Automation Management Portal.

RES ONE Workspace – Windows 10 – We can’t sign into your account

When you configure Windows 10 with RES ONE Workspace 2016 to save your cookies from Internet Explorer 11 according to the following procedure: HOWTO: Configure User Settings for Microsoft Internet Explorer 11 to support Cookie roaming

The following error occurred to me when logging on to a brand new desktop.

The Windows 10 installation was based on version 1607 (OS Build 14393)

To solve this problem simply update Windows 10 to at least the following OS build: 14393.576

How To: Configure Designated account for Windows Authentication RES ONE Workspace Manager

As of  RES ONE Workspace Manager 2015 SR2 it’s possible to configure a designated account for Windows authentication to access the RES ONE Workspace Manager Console.

What does this mean:
You can run the RES ONE WM Console without requiring your account to have database access to the RES ONE WM Database.

Use case:
When you configure your RES WM environment with Windows authentication, you specify an Active Directory Group during the database creation wizard, this group is granted DBO permission on the database and the service account that is used to run the RES ONE Workspace Service needs to be a member of the AD Group to successfully connect to the database.
But when your Help desk or other staff members need access to the RES ONE WM Console they need to be a member of the same Active Directory group that’s used for the service account, this means that all these users have DBO permission on the database on your MS SQL server. Or you have to configure the individual accounts permissions in MS SQL Management Studio to connect to the RES ONE WM Database.

By configuring the designated account for Windows Authentication we can choose a different account to access the RES ONE WM database. And the Help-desk or other staff personnel doesn’t need this account information.

If you don’t configure the designated account for Windows Authentication or make the account a member of the Active Directory group;  The user get’s prompted with the following messages:

Configure designated account for Windows Authentication

1. Create a new user account in your Active Directory Domain, for example: svc_reswmdb
2. Grant the account access permissions to your RESWM DB on the MS SQL Server.
   Open SQL Server Management Studio, Security, Logins and select; New login

Select the user account you created in step one

Go to the tab; User Mapping:

Map the user to your RES ONE Workspace Manager Database and grant the user db_owner permissions, OK and close the SQL Management Studio.

 

3. Now open your RES ONE WM Console and go to Setup, Datastore:

Under Windows Authentication select: Designated account
Enter the the credentials from the account you created in step 1.
(use the following format: domain\username, userprincipalname doesn’t work)

5. Now login with a Help Desk or other account with an administrative roll and verify you can open the RES ONE WM Console.

From the RES ONE Workspace Manager 2015 SR Release notes:

As of RES ONE Workspace 2015 SR2, when using a Microsoft SQL Datastore, you can specify a designated Windows account for RES ONE Workspace Datastore access. This makes it possible for the RES ONE Workspace Console to connect to the Datastore using a designated account if the Consoleuser does not have Datastore access with their own Windows account. Previously, when using Windows authentication for access to the Datastore, it was necessary for the Windows user accounts of Console-users to have access permissions on the database.

As a result, after configuring a designated account for your environment, you can remove Windows user accounts of Console-users from the Active Directory groups that grant them write access to the Datastore.

This increases security because users of the Console no longer need permissions on the Datastore.

The designated account can be specified for existing Datastores, and when creating a new Datastore or migrating one.