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