In the first part article I explained the current infrastructure and the requirements the organization had for the new environment, while I started describing the project using the biggest discussion points in the second article. In this third article I will continue describing the project using the discussion points Global Load Balancer and Server Installation/Configuration.

 

Discussion Point 2: Global Load Balancer

As stated earlier we had two data center and there should be a way to divide the users between the two data centers at the initial start. We required a smart mechanism which provides functionality to check if the end-device (Access Gateway) is up-and-running and check how high the load is of those devices. The data center team offered the service in their catalogue, but the service did actually not exist. In their way to accommodate these services the data center team came up with cloud based DNS+ service. As it was very unclear what the service was offering, we also did not like the idea to use a cloud based solution to provide access as an access point for internal access. As in one of the environment NetScalers were available, we offered to use those NetScaler also to use those as Global Load Balancer. Unfortunate the data center team did not have experience with those devices and refused to add NetScalers to their infrastructure. Endless discussions as both parties don’t want to use the offer the other party made. Currently this is still discussed and argued, so a final solution is still not in place.

Discussion Point 3: Server Installation/Configuration

During the project we started about installing and configuration of the XenApp servers. We asked the data center team what they will deliver and they answered that by default they deliver the VMs pre-installed with a desired Operating System. When we discussed this option we found out that you don’t get local administrator rights, otherwise they cannot guarantee the stability of the VM. In our opinion this was not acceptable, because for Citrix administration we think that local admin rights are definitely required and as others (none Citrix specialist) have local administrator rights we found that actually a risk. As this was not discussable we decided to build our own operating system deployment. I will come back to this one in the next paragraph in more detail, but for now it’s enough to know that our solution requires a PXE boot. In that stage we found out that access to the VM boot actions and similar tasks are not provided by the data center (so no rights in vCloud director or the vCenter). So during the first set-up and test phase of the deployment tasks, we needed to call one of the guys to start-up the VMs every single time. Logically this was frustrating for both sides and also those people were not always available, so several times we had to wait for the availability of one of those users to restart a VM.

With the discussion that we needed to install the operating system the need to use an Electronic Distribution System (EDS) became even more important. So within the team the decision to use an EDS was easily made (over scripted installations). We also decided quickly that the applications will be virtualized using App-V, as we already had good experiences with the product, has lot of advantages in this environment and was used for application virtualization within several divisions (o a kind of standard product) . As this was an easy discussion we needed to select an ESD. As mentioned in the requirements we should re-use current used techniques. So we asked the data center if they have a deployment product and they did namely Altiris. Personally I’m not a big fan of Altiris, so I was not that happy with this standard product. While continuing receiving information about their deployment we found out that they would like to replace Altiris as it was an older version and the cost to upgrade were pretty high. The guys within the team had a preference for using System Center Configuration Manager as the company has good contracts with Microsoft and the knowledge of the product was available within the team. Also the data center team had a preference for using SCCM; however it was not scheduled for the near future. So our environment should be up and running for a long time, before SCCM was implemented. We suggested that we build the SCCM environment, but on first hand they would not allow us to that within their data center. After some new insights (read pressure from higher management) they agreed that we build SCCM in the services ranges, so it could be converted to the central deployment technique in the feature.

Last topic was about the automation process in total. I’m a big fan to automate as much as possible. As the management asked to set-up an environment that could be re-used for other division, the automation of the first servers (like XenApp/Workspace Manager and so on) would make sense. However the team thought that was too much effort to build scripts just for single usage (per platform). I pointed them to the risk to perform any installation manually, although all steps were well documented in a manual. Unfortunate in that same timeframe the SCCM guys did not achieve the goal to make the installations and configuration variables in such way that you provide the details for example of the XenApp installation and those are filled dynamically in the script. I still believe this should be possible with SCCM, but unfortunate I don’t have that knowledge myself. Because this variable part could not be reached currently (in this time frame), the necessary for an automated installation of the first server for the specific component was also less relevant. You could actually say that I lost this discussion, although the officially statement is that because of lack of time the decision have been made to manually install and configure the first server manually (via documented installation steps).

Summarization

In this third article I continued with the biggest discussion point’s number two and three (Global Load Balancer and Server Installation/Configuration). In the upcoming article I will continue describing the other discussion points like Citrix Access Gateways and Outbound Connections. Also I will describe the experiences so far and my final thoughts of this project.