Validating design for virtualized branch office server

Written by Ingmar Verheij on May 30th, 2011. Posted in Performance testing

Recently a large system integrater asked me to validate a design they’ve made for a customer. Their customer has around 100 branch offices in europe and requested a new infrastructure that would be managed by the system integrator.

Although the design in general has been validated (the building process was started months ago), the scaling was based on estimates. In fact, there where some assumptions during the design phase. With the deadline coming closer more doubts rised about the scaling.


We agreed on performing a loadtest to simulate the user actions, validate the design and find bottlenecks before the implementation. A nominal load of 100 users was required.

Secondly, the impact of a System Center Configuration Manager (SCCM) deployment on the overall performance was needed. Will there be an impact on the file and print capabilities and how much is that impact?


Most branch offices consist of 100 physical Windows 7 desktops/laptops, some of them would be larger (above 200 CCU). There where three system configurations, small/medium and large. The overall design had the following requirements:

– Central directory services;

– Distributed file services (both local files per branch office as company wide shared);

– Centralized management;

– Centralized back-up;

– e-Mail services;

– Minimal maintenance for each branch office;

– Preferrably virtualized.


Global design

The global design consisted of a centralized datacenter with Active Directory services, Distributed File Services (DFS) and Microsoft Exchange for e-mail services. The datacenter will be hosted at the datacenter of the system integrator with high availability in place.

Since the connection to the datacenter cannot be guaranteed, and are out of scope for the project, a local solution for each branch office was required. For each branch office 1 Fujitsu RX300 server with Fujitsu DX60 SAN was used.

Fujitsu RX300

Fujitsu DX60




Citrix XenServerOn each server Citrix XenServer 5.6 was used as the hypervisor. This simplified management and portability while consolidation the number of required servers.

One virtual machine was used as a Domain Controller, File and Print server. A second VM contained System Center Configurations Manager (SCCM) server for workstation and application deployments. A third VM contained a back-up proxy server, this server was out of scope during the test.


LoadTest design

Since the actions of 100 concurrent users needed to be simulated, and physical windows 7 desktop would be used, this would require a total of 100 desktops. These workstations where unavailable, and quite frankly would be overkill.

Citrix XenAppWe agreed on using Citrix XenApp servers as stepping stone servers. The XenApp server would host the users, applications and would we used to simulate the user actions.

Altough the Citrix XenApp server would create a different load then the Windows 7 desktop, the differents are small. Indepent from the type of device a logon process would take placing, including authentication, authorisation and logon process. Since the same applications would be used, the generated load would be equal.

DeNamiKDeNamiK LoadGen will be used to generate the load. Sessions will be launched, user actions will be simulated (based on the scenario described by the customer) and response times will be measured.LoadTest design








During the first test LoadTest, where we wanted to validate the design by simulating 100 concurrent users, a problem rised. The indexing of files there where created (or copied) had a great impact on the workload, caused by SearchIndexer.exe. Not only did this generated an additional 20% CPU load, the disks got an additional load aswell. Considering to schedule the indexing of files to off-peak hours is recommended.

Another problem rised; during the test a backup process was started. An administrator in the datacenter, working on the centralized backup, had somehow triggerd a backup on all branch servers. Due to this additional load, and from the indexing of files, the response times while opening files was poor.

The goal of 100 concurrent users was achieved and the design was validated. After stopping the rogue processes the response times where normal.

At the second test, where the impact of an SCCM deployment was investigated, a big spike in responsetimes was measured during the start of the OS deployment. After some basic research the conclusion was that the spike was caused by a network configuration error.


Altough I’m used to LoadTesting server based computing environments like Microsoft RDS or Citrix XenApp, none of these techniques where used by this customer. By using Citrix XenApp as a stepping stone serve more users can be simulated. By consolidating 100 users on 4 physical Citrix XenApp servers, and 4 LoadBots, we required 92 less machines! This resulted in a test that was build and executed  fast, within a week results where presented.


Ingmar Verheij

Ingmar Verheij

At the time Ingmar wrote this article he worked for PepperByte as a Senior Consultant (up to May 2014). His work consisted of designing, migrating and troubleshooting Microsoft and Citrix infrastructures. He was working with technologies like Microsoft RDS, user environment management and (performance) monitoring. Ingmar is User Group leader of the Dutch Citrix User Group (DuCUG). RES Software named Ingmar RES Software Valued Professional in 2014.

More Posts - Website

Follow Me:
TwitterLinkedInGoogle Plus

Tags: , ,

Trackback from your site.

Leave a comment



%d bloggers like this: