We get to the number 7. It is long way behind us so let’s review what we did already:
In the first part – we installed first Delivery Controller and setup our new XenDesktop 7.6 site.
In the second part – we have configured first site.
In the third part – we prepared the template image of Windows Server 2012 R2 that will be used by MCS service for creation of new machines that will be hosting user desktops and applications.
In the fourth part – we upgraded XenApp 6.5 server to XenApp 7.6.
In the fifth part – we created machine catalogs and used previously prepared master image. We attached to the site as well upgraded XenApp 6.5 server.
In the sixth part – we delivered applications to the end users by creating delivery groups.
In the seventh part – we will configure StoreFront so that end users could launch their apps.
This time we will launch Citrix StoreFront console. You can as well do the same in Citrix Studio but let’s use StoreFront console.
We can as well choose which transport protocol we will use for our communication with StoreFront. As we should always secure our environment as much as possible we choose of course HTTPS. It is possible to change as well the port number but 443 is probably the most widely opened port in IT environments.
- To make the store unavailable to users on public networks, select None. Only local users on the internal network will be able to access the store.
- To make only resources delivered through the store available through NetScaler Gateway, select No VPN tunnel. Users log on directly to NetScaler Gateway and do not need to use the NetScaler Gateway Plug-in.
- To make the store and all other resources on the internal network available through a Secure Sockets Layer (SSL) virtual private network (VPN) tunnel, select Full VPN tunnel. Users require the NetScaler Gateway Plug-in to establish the VPN tunnel.
Due to the fact that this is my test environment I will generate self-signed certificate. In your production environment you should of course use your domain Certificate Authority and generate server certificate with full FQDN.
Please ensure to place newly generated certificate under Personal certificate store. Do not use Web Hosting.
All right – we have bond our certificate with our website. Let’s check now StoreFront console. As you see the information about missing certificate is gone now.
All right. We have to do the last thing. Configure StoreFront server name on our Delivery Group. As you see right now there is none server defined.
We should now Edit Delivery Group and from the list choose our StoreFront server.
Let’s try then log to the StoreFront website.
That’s strange 🙂 Everything should be fine now, but it isn’t. To be honest it took my a while to find a source of the problem. It occurred that this is because of my configuration: I have both Delivery Controller and StoreFront server installed on the same machine. So I have to share ports between XML service and IIS. To workaround that problem I had to change the transport type for my Delivery Controllers to HTTP. So my connection between StoreFront and XML service is not secured now – passwords are sent in clear text. That is of course not possible in production environment and that is why you should plan separate servers for each infrastructure role in your XenApp/XenDesktop site. So let’s fix my problem and try to launch our app. First we need to edit Delivery Controllers configuration under Stores tab in StoreFront console.
Then I need to change transport type to HTTP.
Everything looks good 🙂 It was probably much harder to configure properly StoreFront than I thought at the beginning. But we succeeded! Right now we have fully operational XenApp/XenDesktop site with StoreFront. That’s all for today. See you in the part of our First Look series!