Daniel Feller

Daniel Feller is a Lead Architect at Citrix.  With a app and desktop virtualization history dating back to 1997, Daniel has participated in many different deployments taking on many different roles.  After graduating from Purdue University, Daniel started out as an IT Admin deploying WinFrame and MetaFrame 1.0. Daniel soon joined Citrix Consulting as one of the first consultants and spent many years working on some of the world's largest and most complex environments. In addition to field projects, Daniel has also authored several well known whitepapers like the XenDesktop Design Handbook and created the intricate logic behind Citrix Project Accelerator.  Daniel can usually be seen speaking at conferences focusing on design topics for application and desktop virtualization.
  1. Virtual desktops and local storage

    The desktop is a unique beast within the data center. It is something different than what we've typically placed within the tightly controlled, highly-available environment. What happened so far is that the desktop has changed to better align with data center practices. That means having high levels of availability and utilizing shared storage. But is this the right approach? Should the desktop align with the ...

    Read More

  2. Storage and IOPS guidance for App delivery with XenDesktop 7

    If it wasn't for the cost, I would… (do just about anything) Cost is one of the major barriers to doing almost anything. With enough money and resources, a person can do anything, but this makes a lot of things unfeasible because we don't have an unlimited supply of money. When we tried to create a solution to mobilize Windows applications for 500 users, cost was a ...

    Read More

  3. Sizing XenDesktop 7 App Edition VMs

    In the Mobilizing Windows applications for 500 users design guide, we made the recommendation to allocate 8vCPUs for each virtual XenDesktop 7 App Edition host (formerly known as XenApp). Spreading this out across a server with two Intel Xeon E5-2690 @2.9GHz processors and 192 GB of RAM, we were yielding about 200 users per physical server and roughly 50 users per virtual server. Of course, the ...

    Read More

  4. Deliver a Windows application to 500 users

    We get so excited with the thought of VDI, we often forget to take a step back and focus on what we are trying to do. Here is a recent example… We need to find a way to get an application to our users. Our first problem is that many of our users are not local, which makes installation a challenge. The second problem is that ...

    Read More

  5. The guts of the XenDesktop 7 Blueprint… Hardware Layer

    Sometimes, the things we learn early in life teach us the basic fundamentals we need in the future. Many of us probably had toys like this growing up or have them for our own kids. Of course there are some out there who will say that they can get the square peg into the round hole if the beat the hell out of it. This is ...

    Read More

  6. The brains of the XenDesktop 7 blueprint… Control Layer

    Control, control, you must learn control! - Yoda The control layer is about creating a single, cohesive foundation for the solution that supports the user-layers (users, access and resources). You can NOT do the control layer if you haven't defined your user layer, access layer and resource layer. The control layer of the XenDesktop 7 blueprint is subdivided into Access Controllers - responsible for providing the connectivity to ...

    Read More

  7. The heart of the XenDesktop 7 blueprint… Resource Layer

    Users Access Resources The Resources layer is the next stage of the blueprint. Resources are the desktops and applications that we want to deliver to each user. This is also where many people get stuck because the perception is that there are a lot of options. There can be a lot of option until you start looking at it from a user group per user group perspective. Plus, when ...

    Read More

  8. Continuing to build on the XenDesktop 7 Blueprint with Access Layer

    Based on the XenDesktop 7 Blueprint, we have already created a definition of our user layer. The next step is to define how users will access their environment. Just like a house, you have doors and locks. In order to gain entry, you have to have the right keys for the right door. Defining the access layer is basically focusing on the required access policies for ...

    Read More

  9. The XenDesktop blueprint begins with the users

    The users are first. This is why we have a blueprint for XenDesktop 7 because we want to avoid starting wrong. We want to make sure that the first thing we focus on are the users. Think about it this way, when building a house, one of the first things you have to figure out is what type of a house do you want/need (bungalow, cottage, mansion, ...

    Read More

  10. The Blueprint for XenDesktop 7

    Here is a little secret... Most XenDesktop environments are extremely similar. In fact, if you ignore the numerous hardware combinations out there, the similarities increase significantly. You have user groups (some internal and some external) that need access to some type of resource, whether it be a desktop or an application, which is managed by a set of controllers all running on hardware. So why is desktop ...

    Read More