IT department drama: Desktop vs. Server teams and who controls the users' desktops

At both BriForum and VMworld, I had a few conversations with people about a problem looming in the near future within their IT departments--Who manages virtual desktops?

At both BriForum and VMworld, I had a few conversations with people about a problem looming in the near future within their IT departments--Who manages virtual desktops?

Most medium to large companies that I've worked with or for over the years have had a very thick, dark line separating the Desktop Team from the Server and/or Network Team.  In mid-to-late 90's, this wasn't a big deal--you had server hardware and desktop hardware, and that was all.  Right around that time, though, the "desktop" started to become less of a cold, hard piece of steel and more of an abstract concept. As software like PCAnywhere and Citrix WinFrame (and many others) started to make desktops available from locations more than a couple feet away, the idea of a "desktop" became even further separated from the actual desktop piece of hardware.

Today, for most of the people that pay attention to our site and the many others out there, providing a desktop is more akin to your cable company providing you with a TV signal than it is to managing each physical processor, hard drive and monitor of a physical desktop.  We don't necessarily care what you use to view your desktop, as long as it can talk to our backend system (think thin client:cable box).  The thing is, when your cable goes out, you know who to call, and the cable company knows how to fix the problem.  For us, though, that's where our troubles begin: Now that the "desktop" isn't just a device, who manages it? 

Years ago, IT Management drew a line around the data center and said "Desktop Team, you get the client operating system and everything that runs on it. Server Team, if it says Server in the title or runs on that server OS, it's yours."

That works for most corporate IT scenarios, except for when it comes to virtual desktops. By following the rules laid down, the Server Team is left managing the desktops provided to users who access them via SBC, because the applications they use run on a server OS.  That means that two departments have to have an intimate knowledge of all the applications in the environment, instead of just the single Desktop Team. It also means that the Server Team better get along well with the Desktop Team.

Add to this VDI and the very thick, dark line starts to turn gray and hazy. As Chetan Ventakesh of Atlantis Computing once commented on

"Desktop people don't own the server hardware.  The one BIG issue in my mind that no one talks about…is that the desktop IT guys have very little control and leverage over the infrastructure that runs their desktops when it comes to VDI. With VDI, the desktop IT team simply owns and controls the content inside the VM - the VM itself and everything under it is locked away from the desktop IT team."

This is the very topic that I had so many conversations about at BriForum and VMworld. Once you introduce virtual client operating systems running on physical server hardware, how can either support team fully manage the solution with the confines of the classic set of rules?

Chetan goes on to say, "This lack of control translates to an inability to dial-up/dial-down critical resources (memory/disk/IOPS) that affect the committed SLA and ultimately the end user experience. This can be frustrating for the desktop teams where they are asked to fix things they can't control. Its going to take some new enlightened organization and practices to be able to get around this one!"

So what we end up with is finger-pointing and positioning, two things that are already abundant in most IT departments.  What we need is a new solution, but that's a complicated issue.  Some ideas, good, bad, or ugly:

  • Is it just a matter of spreading around some responsibility to each of the groups?  That would require cross-training each team, but doesn't that result in redundancies and relaxed accountability?
  • Maybe it's time for IT departments to remove the thick, dark line and bring everyone under one roof. Try telling this to the server people who've "worked up" from the Desktop Team, but it does make sense, operationally. Still, those redundancies are there again, as well as the relaxed accountability.  Sure, each person still has their primary role, but if 30 people have the ability to modify a server's settings, is that better than 10 or 15?
  • For the bureaucratically-inclined, maybe there's an opportunity for a new department here - a Virtualization Department.  Take your best virtualization folks and your most server-inclined desktop folks and put them in their own room.
  • Give the Server Team responsibility over any desktop hosted on server hardware? (I've run into this one before - the Desktop Team at a former employer would put a desktop machine in the data center and claim it as theirs because it's on desktop hardware.  Imagine how happy I was when I found one of these "desktop servers" running a rogue DHCP server.)
  • Give the Desktop Team responsibility over any desktop and the hardware it runs on? (Similar consequences to the above option)

I honestly don't know which option is the best, if one even is. And that's really the point of this article - to get everyone thinking. What is the next step? Have you already dealt with this issue, and if so, how?  I'll collect any and all feedback for a follow-up article, so please comment below.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Couldn't you give them ownership of the DDCs and PVS that are dedicated to VDI only?  You could perhaps create a few upper tear desktop guys for change control and image management, but still give that whole space to the desktop team since desktops are their ultimate responsibility.  Besides, with all that new free time not having to image workstations left and right, what else are they going to do?


From my personal experience within our organisation, the issue is not looming in the near future. Its already here and has been for the past 10 years, when we first implemented Citrix Metaframe 1.8. So i don't think this issue is unique to VDI. After all VDI is SBC in the same way as Citrix/TS is. That dark thick line turned gray for us then. We had 3 teams  - the server team, the desktop team and the application support team. The server team we were, like, "hey who's responsible for installing the client side app onto the TS?" The desktop team, who usually deploys apps to desktops, are saying "its a server, i'm not touching it". Then there are the App Support guys saying "we want to do the installation, as we support the application". But the server guys are saying "no way - you don't have the expertise to install apps on a TS envionrment and trying to make bad apps work in a multi-user environment (what is install mode?)." The server guys will also say, "if you were to deploy the application onto a Fat client, would you go round each desktop and install the software yourself?".

So we had a server team not willing to install the app because its a client application. The desktop team unwilling to install the app because its on a server. Then App Support team willing to isntall the app, but the server team don't trust them to do it properly and its not job of the App Support team to deploy applications - they just meant to provide support tp the application.

Guess what, we still have this problem today! Though we are about to start our upgrade of PS4.0 to XenApp , and as part the upgrade its our chance to re-visit this issue and try to address it once an for all. This is what i am pushing for:

The server team is responsible for the SBC infrastructure - Physical serves; Virtual Servers; Installation of Citrix and supporting the XenApp infrastructure.

The desktop team will be installing and delivering (publishing) the apps onto XenApp (or virtualising apps to be made available via XenApp) . Knowledge transfer from the server team to the desktop team is required.

The application support team will continue to support the applications.

It may not be perfect and may need to be adjusted, but if everyone can agrees on something then we are halfway there.


@Shanghai_Si. You pretty much hit the nail in the head in my opinion. This is very similar to what I wrote today on my blog. In MANY ways SBC in its TS/Citrix form is no different than VDI. We went through all this years ago when starting with SBC. Did not we learn anything? Check it out if you want at



Although we're not yet into the VDI environment, we've handled the separation of duties in the SBC world as follows:

Server/Storage Teams: Provides and supports the server infrastructure and that includes server HW, OS, & disk.

SBC Team (technically called "Application Delivery", we stole the idea from Citrix): Installs and manages the XenApp environment including XenApp installation, configuration and client deployment.  Also manages WI.  Installs all applications onto XenApp servers.

Application Teams: Support only the application functionality.  If differences exist between the traditional desktop install and the SBC install, the SBC team intercedes to translate.

Desktop Team: No resposibilities in the SBC world.

Granted, the SBC team is made up of seasoned professionals that have Server, Desktop and Application development and deployment experience.  Personally, I was a Server guy who went on to Systems Integration and then to Application Deployment and then to SBC.  Two others on the team are ex-Server and another ex-App Development.

However, I would expect that if/when we enter the VDI arena, then the Desktop Team may get a piece of the action.  But Server would still maintain their role providing and supporting the underlying platform.  To ensure a decent SLA, the server team needs to be responsive to the other team's requirements as neither SBC nor VDI have the same requirements nor act as traditional servers.


Gabe - One of the more promising approaches I've seen to seeing this problem being solved is around VDI Orchestration.  I'll use an analogy here to illustrate the point -

A traditional ship's throttle commonly called a telegraph  (Engine order telegraph or EOT does not directly control a ship's engines; instead, changing the throttle lever position on the bridge telegraph rings a bell in the engine room and changes a corresponding telegraph in the engine room to the same settings. The engineer then increases or decreases the throttle to meet the speed set by the ship pilot or captain.

VDI Orchestration works similarly and very well.  I'll give you an example of a real life implementation for a  Financial Services firm done using VRM by Dynamic Ops (a very rich orchestration product) and Atlantis ILIO and vScaler.  When the desktop team figures out that it needs a desktop pool to be incremented/decremented with either (1)fresh desktops (2) more storage (3) more IO bandwidth in particular server/rack/datacenter (based on demand/load) - they use the VRM orchestrator to set a new  threshold that gets communicated via API to  ILIO/vScaler   to  execute.  This is done without the need for the Vmware administrator to be involved (if the resources being consumed from the DRS standpoint are within  certain thresholds). Both ILIO and vScaler are clearly storage and server administration team responsibilities but they are used to delegate desktop-specific controls back to the desktop team who need them the most. And they can do this without needing to involve the server folk (within certain capacity thresholds).

So overall I think the VDI/SBC conundrum of who controls the desktop can possibly be untangled by allowing server & storage folks to continue to be lord and masters of the data center while allowing certain strategic controls important to desktop team SLA commitments to be available INDIRECTLY via Orchestration (within negotiated/agreed upon policies)

Chetan Venkatesh


Atlantis Computing


This will probably throw a curve ball into the discussion but what we've observed very similar things to what's listed above.  However, to our surprise, particularly in very large Enterprise accounts (think top 50 of Fortune 500 or Fortune 2000) is the number of IT Security teams taking a key role in desktop virtualization projects, particularly the role that we'd normally expect the desktop teams to own.

For whatever reason, desktop teams inside large Enterprises often do not own the desktop virtualization projects even if/when the server, storage, and/or application teams do not want it.

I'll give 2 examples:

1) Our company, RingCube, just recently closed our first order and moved vDesk into production at the world's largest commercial bank.  The project owner was a CISO reporting to a COO which was driven by the Board of Directors. We understand why, for our particular customer, security was such a big issue but cost-savings and mobility was arguably even more important to them.  The CISO is a super smart, talented individual and same goes for his team but we'd never expect going into the deal that a CISO would own the project.

2) Fortune Global 2000 top ranked company (very diversified business) has a corporate wide Desktop Virtualization initiative (which is probably a few years away from actual production deployment) being run by a cross-departmental IT body but the  head person responsible happens to be on the Global Security team as his regular day job. Once again, this person is super smart, well respected, history of successfully run projects and true IT professional but very surprising he's running the corporate-wide desktop virtualization initiative.

These are just 2 head-scratching examples that we're still puzzled by but what we're starting to see at least at large companies is that their Security teams have very deep benches of talented IT folks. Also, these teams have a track record of setting the strategy and policy for high-profile IT projects that require mastering the difficult balancing act of dealing with securing end-point devices (OS, patches, AV, FW, HIPS, Anti-spyware, etc.) yet still allowing enough freedom for end-users to be productive via business tools/applications/desktops.

In many large Enterprises, the desktop teams which often include Helpdesk seem to be heavily operational in nature and for whatever reason are not being tasked with decision making authority of the virtual desktop initiatives/projects.  Yes, we're seeing server teams who own ESX and app delivery teams who own Citrix/TS being the leads on these projects too but very rarely do we see the desktop team be the ultimate decision makers.

Windows engineering and/or Windows architecture is also another group that plays a bigger role in owning desktop virtualization but those groups are often not a part of the desktop team.

Again, just a little curve ball of unexpected observation in very large IT shops. Could just be an anomaly that we've stumbled upon several times now?  But who knows for sure?

Food for thought...



Correcton - the first line of my comment should read - One of the more promising approaches I've seen to  this problem being solved is around VDI Orchestration. Thanks!



I like it.  Does the SBC team have the authority/ability to make changes to the OS as needed, or do they have to ask the Server/Storage team to do it?  My fear here, as you can probably guess, is bureaucratizing this thing to the point of inefficiency, which is painful to watch, let alone work with.

I used to work at a place that had two completely separate IT departments and two completely different sets of systems, and I was the only person in the entire place with admin rights to both, and everything else had to be scrubbed for access and verified against policies that were in place just for the sake of having policies.

As long as everyone has the ability and authority to do the things that they need to do, though, it seems like a good situation to me.


This is not a new situation at all. For any organization big enough to functionally split the IT organization we have always had to work across functions – just think about getting the network group to add GPOs to AD for terminal services. What is really going on here is a change in the distribution of users between different groups and hence a question of whether the skills in the desktop group have to be changed or greater emphasis be put on the SBC or server groups. I have seen organizations do either. Personally I see the experience of people coming from TS as being more relevant in desktop virtualization, certainly while it is a hosted solution (ie: pre client virtualization). Long term I can see the split being between a group that can go desk-side, largely for hardware issues, and a desktop management function that combines skills and people from desktop and SBC.

I was intrigued by Doug’s observations on security people owning some of their implementations – maybe this is an example of the convergence of security and operations we keep hearing so much about.

Martin Ingram (AppSense)


Great thread Gabe. Just to give fair credit back to Citrix I'll post a link to Harry's blog where he talks about this.

My feeling is that I agree that this Desktop Virtualization things can't be managed like a server virtualization infrastructure. There needs to be a new organization that is empowered to support this end to end, and those folks need to have a Desktop mindset period. I wouldn't have my ESX guys manage by desktop application packaging team. To Doug D point above on security. I think it's interesting but security guys don't know who to implement anything. Their job description should read, be paranoid and find holes in stuff that is not as important as I would like you to think and shun all execution responsibility. Security should be a function in every team, with a very small cross product team. Otherwise they act like government. Windows desktops are the domain of Windows experts, and those people are not ESX bigots, even if running on top of ESX.



It depends on what level of OS change is required.  We are Local Admins and have the authority to:

Add/Remove local Accounts

Modify local file/folder secuity

Modify operational parameters (like swap size or DEP)

Install utility software that makes the server function as a better SBC server

We cannot Add/Remove Patches or AV policies as these are centrally managed by the Server Team (and we greatly appreciate that!).

It does increase the complexity of the operations and require bi-weekly patch meetings and Change Controls.  But in most cases we can be nimble and do things first and ask permission later.

We also have the authority to manage Group Policy for the servers we manage.

We've found that the Server Team has enough to work on and they really don't want any part of the operations of the SBC servers.

Re: 2 IT teams, we're a Fortune 500 company made of aquisitions of smaller companies and have had at one time, 5 different IT departments.  It think we're down to just 2 now!