Paul McCran's

Portfolio
There are quite articles out there which explain how to create disclaimers on previous versions on Netscaler, but I could not find any way of creating a pre-authentication disclaimer on the Netscaler 10.5 vpx appliance.  With that in mind, I decided to create my own simple disclaimer.  I've included the details on how this can be done below.  I'm not a Web Developer, so you might find better ways to design the Disclaimer screen.   


Install WinSCP on your management device.  WinsSCP will allow you to access and modify the Netscaler CSS and image files.  The main CSS sheet for the Netscaler logon page is called  “Caxtonstyle.css”.  This file can be found in the following Netscaler directory:  /netscaler/ns_gui/vpn/images/caxtonstyle.css.

Netscaler Front End Changes
 
In Netscaler Global Configuration Settings, Change the Client theme to Custom.  Then make your changes.
 
You will be able to rename the netscaler image files (gifs etc) and the caxtonstyle.css file using WinSCP.  Be sure to make a copy of the .css sheets and files that you change.  You will be able to upload your own images in place of those currently used on the Netscaler, but be sure to name them exactly as the Netscaler references them.  A good a free way identify graphic files and styles on a page would be to use the built in Browser Development tools.  You can use the element selector to identify the specific webpage components and their CSS/HTML references.   This information can then be used to modify the corresponding Netscaler .CSS or Image files.  The following webpage describes where some of these changes can be made:

http://www.icenlemon.co.uk/blog/?p=232

Storefront Front End Changes
The Storefront website can be configured by modifying the “C:\inetpub\wwwroot\Citrix\StoreWeb\contrib\custom.style.css” file.  This file will initially be blank, apart from a few basic CSS settings.  You can use IE built in Development tools to identify elements on the webpage and their corresponding CSS element name. You will then be able to add the name into this custom css file, so that your changes overwrite the default settings.  The image files are stored in “C:\inetpub\wwwroot\Citrix\StoreWeb\uiareas\Store\media”. 

 
Disclaimer

Create a CSS file called "Disclaimer.css" and store this in “/var/netscaler/gui/vpn”. 
Rename the Index.html file in “/var/netscaler/gui/vpn” to Indexhome.html
Create an Index.html file and save it to “/var/netscaler/gui/vpn”

Copy the following into the "Disclaimer.css" file (You can change the colours later):

body {

background-image: url("/vpn/media/bg_bubbles.jpg");

background-color:#14235C;

color:Black;

}

.container{

}

.DText{

Position:absolute;

font-family:Verdana;

Font-Size:12px;

font-weight:bold;

color:Black;

top:50%;

left:50%;

em:50px;

transform: translate(-50%, -50%);

background-color:#FFFFFF;

padding:20px;

margin:20px;

line-height:200%;

}

.DButton {

margin-left:45%;

top: 30%;

}

 

#navcontainer { }

#navcontainer ul

{

margin-left: 0;

padding-left: 0;

list-style-type: none;

font-family: Arial, Helvetica, sans-serif;

text-align: center;

}

#navcontainer a

{

display: block;



background-color: #14235C;

border-bottom: 1px solid #14235C;

}

#navcontainer a:link, #navlist a:visited

{

color: #FFF;

text-decoration: none;

}

#navcontainer a:hover

{

background-color: #6B79AD;

color: #fff;

}


The next thing would be to copy the following Disclaimer information into the Index.html page that you created.  Replace the lorem ipsum text with your own disclaimer text:

<html>

<head>

<link rel="stylesheet" type="text/css" href="disclaimer.css">

</head>

<body>

<DIV Class="Container">

<DIV Class="DText">

<P>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed vitae justo dictum, aliquam nulla nec, maximus lacus. Etiam pharetra, dui sed viverra consequat, felis sem faucibus nibh, eget vestibulum turpis augue eu risus. Donec consectetur vulputate accumsan. Cras vel est dignissim, dignissim orci non, volutpat est. Sed mattis lorem ac urna luctus consequat. Nunc volutpat neque vitae euismod finibus. Mauris dictum at lacus non pulvinar. Nullam tempor ex vel ipsum tincidunt, sit amet fermentum eros condimentum. Donec enim risus, tempor sed enim eu, ornare cursus orci. Nam ipsum nunc, mollis non turpis sit amet, consectetur convallis tortor.
</P>

<div id="navcontainer">

<ul id="navlist">

<li id="active"><a href="indexhome.html" id="current">I Agree</a></li>

</ul>

</div>

</DIV>

</DIV>

</body>

</html>

The Netscaler loads “Index.html”, which will use the external cascading style sheet called “Disclaimer.css”

These two files are found in the directory called “/var/netscaler/gui/vpn”.  These files are responsible for the initial Disclaimer page that appears when a user browses https:\\yournetscaler.com

The “I agree” button on the Disclaimer page will redirect the user to the Netscaler logon page when it is pressed.  The netscaler Logon file is called “indexhome.html” and is linked to numerous style sheets, so you would need to use the IE/Chrome to identify and change element on that page (As described in in the sections above)

 
I have tried to add a disclaimer text translation, but haven't got this working yet. So you will be able to modify and improve on this.
 

You will be able to use the Storefront custom CSS file to design and match the storefront logon (Green Bubbles) with the Netscaler logon. 
When a PVS server reads from the Vdisk image in the PVS store, the data from that image would normally be read into the System Cache memory of the server- this means that if the PVS server has sufficient RAM, then there would be little need thereafter to read from the image saved on disk.  The target devices will have the image data streamed to them from the PVS server's system Cache memory (RAM).  A PVS server is able to read the data into memory if the image is stored on block level storage, but it will not read any of the data from a Vdisk that is stored on a CIFS/SMB share.  You will wonder why this is the case, as a Windows server has no issue reading any other type of file into system cache at any other time. 

There were traditionally 4 main Oplock types used:

L1 - Exclusive lock placed on a file.  A client can cache Read or Write operations to the file (cached on client).  This locks other users and systems form using the file

L2 - Shared Read Only Lock.  Caches RO Locks. Because only RO operations are being cached, it will allow multiple clients to access the file

The old "Opslock" system was replaced by "Leasing" in SMB version 2.1 (Server 2008R2)

If  you look at the above two locks, you will notice that it should have been possible for the Vdisk to be accessed if an L2 lock is placed on the file, but this functionality was disabled by the PVS installation, to reduce failover times.  However, the failover scenarios described by Citrix are only relevant to Write cache files that are stored on the PVS server or Vdisks placed in Private mode.  Each of those options aren't recommended in the majority of scenarios, so it's ok to enable the Opslock settings again. 

Server 2008 R2 File Server:

HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters
“autodisconnect” = dword:0000ffff
‘Smb2″ = dword:00000001

Windows 2008 R2 Provisioning Server:

HKLM\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters
“EnableOplocks” = dword:0×00000001
HKLM\SYSTEM\CurrentControlSet\services\mrxsmb\Parameters
“OplocksDisabled” = dword:0×00000000
“CscEnabled” = dword:0×00000001
HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters
“autodisconnect” = dword:0x0000ffff
“Smb2″ = dword:0×00000001

Allocate enough RAM to your file server so that the Vdisk can be read into System Cache of that server.  Do this for your PVS server too.

There will be an impact on system performance, so make sure you test this and also read up on how you can make this highly available (Clustered).  There are some articles that explain how to use Microsoft SOFS configurations for this, but be aware that at the tie this blog post was written, there where issues with Vdisk updates and performance when using Server 2012 SOFS for the Vdisk store.



LMdiag -c
lmhostid -hostname
If your Citrix Director user is unable to search users within a specific AD Domain, this may be because your login account is no a member of that forest or the Web Server isn't part of that forest either.

You can change the following IIS setting to make this work for the account:

connector.activedirectory.domains=(user),(server),ENDUSERDOMAIN


1 - Adminstrator configure a VM with the App's and settings that they require to be unique for all of the planned VMs.

2 - The final image is a .vmdk virtual disk file that resides in a folder on the root of the datastore it is deployed to

3 - Admin defines the size of vm,  vcpu , memory via the MCS Wizard

4 - Admin chooses amount of vms to be created and added to catalog in the MCS Wizard

5 - Admin chooses a naming convention for the machines to be created in the catalog, in the MCS Wizard

6 -VMs are all created as "Linked Clones"

7 -Each VM created has two or three disks assigned to it:

Master image - single base disk .vmdk file - mounted as non persistent on SCSI 0:0 to each VM. allows RO to base .vmdkand all data changes are redirected to a .REDO file in the VM's home folder.

Personality Disk - A small 16MB VMDK mounted on SCSI 0:1.This contains some basic info such as machine name, SID, Domain Computer account password and other unique info injected into the OS on boot-up

Personal vDisk (Optional) This disk is used in cases where you want persistence in your VM

The time line for all of this is as follows:

1 - MCS takes a VMwaresnapshot of the Master VM

2 - MCS creates a Temp VM (XD Temp 4)which is configured with the vmdk form the original master image that was has just has a snapshot.

3 - It then clones the Temp VM (XD-Temp-4) to anohter VM, using some name supplied in he creation wizard and then appends "-baseDisk-datastore-51 to it. The VM is created with this name so that the folder and basedisk.vmdk inside have the naming convention specified in MCS

4 -After cloning, the new VM with the appended (-basedisk...) name, it is reconfigured to have the disk removed.

5 - MCS issues a command to delete the VM By first removing the disk from the VM, it prevents the base disk .vmdk and folder from being deleted when the VM is deleted. The result is that all of the VM files are purged but the base disk is still there, as well as the description name selectled in the MCS wizard.

6 - A new VM is then created called "Preparation"-+ the name specified in MCS wizard
This prep VM is created with the amount of CPU and ram specified in mcs wizard

7 -The new prep VM is reconfigured to add our basedisk created in earlier steps. Unlike all linked clones that will be created the VMDK is NOT mounted as independent: non-persistent. The contents of the base disk still need to alter to make it suitable for multiple MCS linked clones though.

8 -The prep VM is reconfigured again and the 2nd VMDK is added. This time, the .VMDK file added is a small disk file called "prepare-identify.vmdk" The file is provisioned as 16MB but is only 16KB and holds a simple file structure with a couple of files to be used for preperation process

9 -The prep VM is powered on. 

10 -After power on, it is prepared with the information found in the identifty disk:
The OS and office installations are Re-armed so that each MCS linked clone created later is ready to run with their own custom identify files

11 -After the "in guest" processing of the powered on prep VM has completed onthe prep VM, the VM is shtudown from within the guest (So a power off command will not shown in the logs)

12 -Once powered off, it is reconfigured to remove the base disk (to prevent deletion)

13 -After reconfiguration completes, the prep VM is deleted from disk
at this point, the base disk is left behind and has now been prepped and ready to be a read-only disk that all mcs linked clones will mount as their C: drive

14 -Next the VMs are created 3 at a time, using the naming convention stated in MCS wizard.

15 -After creating the VMs they are reconfigured 3 times each:

 First reconfig- VMs are sized according to the specs in the wizard

 Second reconfig- the base disk .vmdk is mounted in the VM SCSI0:0 in "Independent-non persistent" mode (RO) this is to prevent changing/locking the base disk and all write activity is redirected to a REDO file in the VMs home folder,
 
Third reconfig - A small 16mb Id disk is added similar to the one added to preparation VM.  The disk is placed in the home folder of the VM and is named %VMNAME%-IdentityDisk.vmdk". the contents of the ID disk are at the heart of what allows machines created iwth mcs to be non-persistent linked clones that can have their master disk updated, yet still persist and keep an idenity on the network]

16 -The process is repeated for 3 VMs concurrently until the total number of VMs specified in the MCS wizard is reached
Here are a few new features built into Xenapp 7.6:


Session prelaunch & session linger

Session prelaunch starts a session before the session is requested, so the application launch time in minimised.  Session Linger is used to keep the session open for a configured amount of time once the application closes. 

Support for unauthenticated anonymous users

For delivery groups containing server OS machines. You can allow users to access applications and desktops without presenting credentials to storefront or receiver. Used when users access via Kiosks so that the application may ask for the credentials, but the citrix portals do not

When configuring a delivery group, there is the option to grant access to authenticated and unauthenticated users or both. When you grant access to unaithenticated users you must create an unathenticated users storefront store

Connection Leasing

Citrix recommends using a HA fault tolerant SQL database configuration.  However, that is not enough, because there are often times when network interruptions will prevent delivery controllers

Form accessing the database, which in turn, results in users not being able to connect to their applications and desktops.

Connection leasing is designed to compliment the usual HA SQL deployment, by allowing users to connect and reconnect to their most recently used apps and desktops, even when the site database is not available.

Each controller caches users connections to the most recently used app’s and desktops. If the database becomes unavailable, the controllers enter into a lease connection mode and replays the cached connections when a users attempts to reconnect to a recently used app or desktop.

 Application Folders

Some of you may have wondered why it wasn’t possible to group your applications into folders in newer versions of storefront, well now you can. This makes managing large groups of applications easier as you can logically group applications into parent and nested folders within the delivery group (Up to max of  5 levels nested)

 Xenapp 6.5 Migration

This is a good option for those companies who wish to retain much of their Xenapp 6.5 polices and have them ported into the new Xenapp 7.6 environment:

After you install the XenApp 7.6 core components and create a Site, the migration process follows this sequence:

  • Run the XenApp 7.6 installer on each XenApp 6.5 worker, which automatically upgrades it to a new Virtual Delivery Agent for Windows Server OS for use in the new Site.
  • Run PowerShell export cmdlets on a XenApp 6.5 controller, which export application and Citrix policy settings to XML files.
  • Edit the XML files, if desired, to refine what you want to import to the new Site. By tailoring the files, you can import policy and application settings into your XenApp 7.6 Site in stages: some now and others later.
  • Run PowerShell import cmdlets on the new XenApp 7.6 Controller, which import settings from the XML files to the new XenApp Site.
  • Reconfigure the new Site as needed, and then test it.

 Advanced connection throttling

Specify maximum simultaneuous actions, simultenues personal storage inventory updates, and actions per minute that can occur on a host connection

Enhanced reporting in Studio

More details and status and error reporting when updating pvd images. Better licensing alrets when using the licensing node

SSL/TLS

Enable secure sockets between users and VDAs by configuring SSL/TLS on the machines where the VDA is installed and in the Delivery groups that contain the VDAs
I will post my own version of these instructions soon, but in the meantime, here is the Citrix eDocs link for this.

http://support.citrix.com/proddocs/topic/dws-storefront-26/dws-configure-single-fqdn.html#dws-configure-single-fqdn
Next PostNewer Posts Previous PostOlder Posts Home