I’ve been thinking and writing about the desktop environment at Westminster College for a while now and have shared a number of thoughts extolling the virtues of virtual desktop infrastructure (VDI). Beyond writing about the journey, I’ve also spent a whole lot of time researching VDI and considering the best way to move ahead at the desktop level for my organization. After much deliberation, we’ve determined a direction and I thought I’d share it with you and explain our reasoning.
We have a number of goals for our desktop environment:
- Improved manageability. We currently have weak processes when it comes to managing the desktop environment. Although we use WSUS for patch management, that’s about as far as we go right now. Everything else is pretty manual.
- Reduced cost. I’d really like to extend the desktop replacement cycle. The tools used by our administrative users continue to evolve, but many of the basic, essential job functions remain static. If we can reasonably extend our desktop replacement cycle by a year or two, we can save a lot of money over time.
- Improved productivity. When it comes to the bottom line, a computer is a tool used by an employee to get a job done for the college – nothing more, nothing less. Even though we want to extend the replacement cycle by a year or two, if possible, we need to avoid doing so by making it painfully slow for a user to get his work done. In fact, we hope to improve the overall performance of employee’s desktop computers through the creative use of technology in the data center.
The VDI decision
On the surface of it, a decision to move forward with VDI might make sense. With VDI, we can leverage our existing hardware by transferring the processing load to servers in our data center and repurposing our existing desktop computers as terminals. As desktop terminals fail, we could replace them with true thin clients, which cost less than a traditional desktop and generally have a longer life expectancy.
At present, though, we’ve decided against the VDI route, but do plan to revisit it in the future. Although we were very excited by some of the advantages presented by the technology, there were some good reasons that we decided to hold off for now.
First of all, we have a goal as an institution to preserve as many budget dollars as possible across the institution. Given the current worldwide financial situation, ending our fiscal year ahead of budget is very important.
Second, we don’t have a good management methodology in place for our existing environment. Throwing VDI into the mix would add additional complexity to the environment that we already struggle to manage. Before we implement something totally new that has a high price tag, we need to make certain that we can leverage the new technology to the maximum extent possible to achieve the highest return. That means that we must first implement better desktop management techniques that we can then apply to a possible future VDI implementation. Throwing good technology into the desktop mix right now just doesn’t make sense; once we get real desktop management tools in place, I’ll feel better about the issue.
Where will we go instead?
In the short term, we’ve identified ways by which we can meet the goals I outlined above without adding VDI. All of the software we need for this endeavor is included in our campus agreement with Microsoft, making it very cost effective to implement. Here’s what we’ll do:
- Implement System Center Configuration Manager (formerly SMS) to assist us with desktop and software management.
- Implement Windows Server 2008 Terminal Services and App-V (Application Virtualization).
- Keep the existing desktop units in place. Even though they’re slow, they can still easily run RDP sessions to the Terminal Services servers. We’ll deploy App-V wrapped packages to our Terminal Servers and then share them out to users using Windows Server 2008’s RemoteApp feature, which provides a single-application terminal session that appears to the user to be running locally. Using RemoteApp, the user’s local PC slowness doesn’t matter as much since the application processing is taking place on a server. We’ll use App-V wrapped software packages to keep Terminal Services-induced conflicts to a minimum. Then, we can deploy the same App-V packages to non-TS clients, too. This will provide a higher degree of consistency across all corners of the environment and we could even extend this methodology to a VDI environment later on.
- As clients fail and we need to replace them, we will give more consideration to a VDI scenario, possibly replacing failed computers with terminals.
By going this route, we will achieve better overall management of our desktop environment and be able to extend these methods to a future VDI environment rather than force-fitting VDI into what we already do. More importantly, the steps we plan to follow will still allow us to meet user demands while at the same time we will be able to correct our desktop management deficiencies. In short, the three goals that I outlined earlier for our VDI project can be met without VDI by simply applying a little creative energy to the issue.
Have a topic idea or question you’d like me to address or answer in a future post? Email me directly right here at firstname.lastname@example.org.