james kahn’s scratchpad

After spending too long away from making a post here, I’ve decided that trying to target my blogging just to Infrastructure Management is far too restrictive for me.  I’m not a professional blogger, and have no desire to be.  I’ll just blog about whatever I like.

Edit: After recent developments in the industry and some re-thinking on my part about the benefits of VDI, I’ve changed my tune on this. VDI is relevant for a significant segment of the market that SBC isn’t. Primary benefits of VDI? User empowerment, desktop customisation and simpler maintenance.

Virtual Desktop Infrastructure - or VDI for short - is one of the latest phenomenons striking the IT industry. If you’re tuned in to the standard IT industry rags, Citrix, and Virtualisation resources, VDI seems to be hailed as the next revolution in desktop delivery. However, that isn’t the case.

For those that aren’t aware, the concept of VDI refers to centrally hosting desktop virtual machines - usually Windows XP or Vista - on a number of servers stored in the data centre. End-users would then use thin-client devices or low-end PCs to connect to and work from these virtualised PCs. The actual operating system and data are all stored centrally in the data centre.

The advantages of doing this include:

• Your data is centralised, so it’s easy to back up and keep it under control.
• You can take advantage of some of the availability features of virtualisation solutions to (perhaps) provide greater uptime.
• Users can have a full “PC” environment when using only a thin client.
• It’s much more hardware and budget-friendly than the terrible blade-PC solutions from HP and IBM. (On a side note: Why anybody would go for a blade PC solution blows my mind. They must have very good sales people).

While at first glance VDI appears to be a compelling and potentially beneficial architecture for running your business on - the truth is a little different. VDI would be a great technology if it existed in a vacuum. Unfortunately, it doesn’t, and there are a number of solutions that already solve many of the problems that VDI does, and they do it in a more cost-effective, manageable way. If you’re investigating VDI, there are two other technologies you should be considering that will probably provide a better solution in the end: Citrix Presentation Server/Terminal Services, or a Managed Desktop Environment.

A Citrix Presentation Server environment involves setting up a farm of Windows Server-based terminal servers, and hosting your user’s applications and desktop environment on these in a classic multi-user fashion. Depending on the applications and server configuration, you can usually get between 50 and 80 users on each standard specification server. To compare Presentation Server with VDI:

• Your data is centralised with either solution.
• Presentation Server/Terminal Services usually has a greater user density, resulting in a higher number of users per physical server, and reduced licensing costs for operating systems when compared to VDI.
• Both have built-in load balancing/availability characteristics, although VDI’s is more seamless if hosted under VMware.
• Presentation Server provides a management platform to manage your user farm, whereas VDI management tools do not solve the platform and application management problems (more on this later).
• While you can give people free reign with VDI, you generally want your Presentation Servers to be controlled to provide a stable user environment.
• Both have inadequacies and are unable to smoothly provide rich, graphically intensive applications.

In short, Presentation Server is generally a cheaper, more manageable solution than VDI for the main VDI use case - hosting the data and applications centrally.

A Managed Desktop Environment is a controlled desktop platform hosted on standard desktop computers. A tool like Altiris’ Client Management Suite, Microsoft SMS/SCCM, or Microsoft System Center Essentials (for smaller environments) provides a standard operating system build, standard application installation packages, configuration management and remote support capabilities. You can give your users as much or as little freedom over their own computers as you like, based on your requirements. When compared with VDI:

• VDI centralises the workstation and data environment to the datacenter; a Managed Desktop Environment doesn’t centralise the workstation platform, but can centralise or replicate the data.
• There aren’t any built in availability characteristics in a single workstation, but if it fails only one user is down for a short time while another machine is automatically built.
• Costs can be similar to VDI, when all hardware and software is accounted for, including capable, thin clients for the VDI solution.
• A Managed Desktop Environment performs well with all types of applications, including graphically intensive ones.

A Managed Desktop Environment needs a management platform (e.g. Microsoft SMS), which has a cost associated with it. However, in order to provide a standard operating platform, a VDI solution also needs a management platform. VDI only addresses the question of where the operating system is run from, and not the desktop environment management system.

Most businesses - I would go as far as to say 99% of the businesses I deal with - would reap more benefit at lower cost from a Citrix Presentation Server solution or Managed Desktop Environment for their core operating environment than with VDI.

VDI is a very neat technology, and it does have it’s place. There are some very specific situations where you might use VDI, for example:

• An outsourced developer (in say, India), that needs to use a Windows desktop environment where they can install applications, don’t use graphically intensive applications, and where you want to protect the data by storing it centrally; and,
• Other development “sandbox” style environments.

VDI, like many other technologies, will find it’s niche in the long term as a point solution, but won’t become a major game changer.

Thanks to BrianMadden.com for their series of articles on VDI.

Edit: Please note that I’m not saying VDI has no uses. I believe that it’s useful in it’s niche, but is not anything to get terribly excited about.

System Center Forum have a very insightful article on when to deploy Systems Center Essentials, and when you shouldn’t.

The only caveat I have with the article is in regards to Operating System deployment - Microsoft Windows Deployment Services will suit the typical SCE environment for OS deployment.

Ian Blyth has a great blog post up about integrating new software or change into a business - in this instance, Systems Center Operations Manager 2007.

The five stages are essentially:

1. The existing status quo;
2. Resistance to change;
3. Chaos as change occurs, knowledge is updated and people learn;
4. Integrating the idea or software into the business processes; and,
5. The new status quo, at a higher level of performance.

Recommended reading.

I’ve been very busy both at work and outside of it recently and haven’t had much a chance to do any blog writing.  I’m still here, and have some articles in the works.

Microsoft Operations Manager 2005 Management Packs can be converted to native Systems Center Operations Manager 2007 Management Packs using two tools, MP2XML and MPConvert.exe. Microsoft have instructions in SCOM 2007 help, as well as on the web.

Keep in mind that in order to do this you will need a MOM 2005 Management Server from which to run MP2XML. If you’re upgrading an existing MOM environment, keep your MOM 2005 management server around until you’ve converted all of your management packs. If you don’t have a MOM 2005 environment but need to use MOM 2005 management packs, you’ll need to set it up in a test environment to do the conversion.

I’ve been living in Brisbane for one year today. Yee-haw, I love this place!

That is all. Thanks for listening.

Microsoft have released a series of quizzes for some of the features of System Center Configuration Manager 2007 beta 2. It’s a great way to test your knowledge, and learn a bit more about this feature-packed up and coming environment management product.

Grab them here.

If you’ve been in the IT industry for longer than a day and a half, you’ve probably had to compromise on something technical. Usually the story goes like this:

• The customer implementing a web-based remote access solution doesn’t want to put in two-factor authentication, despite the fact it’s been proven to be exponentially more secure than a username and password.
• The CIO decides that all user workstations will stay on Windows XP for at least another year, instead of migrating to Vista.
• The CEO knocks back the idea for a stand-by data centre in favour of a less optimal “back up and pray” routine.
• You work for a multi-billion dollar international company and you’ve had to cut out your number one and two features from your new virtualisation product in order to ship on time (I just had to add that one in. No hard feelings, Microsoft.).

It’s the old story - nobody seems to want to do anything properly. Can’t they just…

Woah. Hang on tiger. What does it mean to do something properly?

In the minds of most technical people, doing something properly means implementing every feature. Automating as much as possible. Installing on the best hardware. Configuring in the most secure way. For a developer, it can mean “release when it’s done”, like in the open source world. For a Systems Engineer, it can mean that a Standard Operating Environment machine builds itself, installs and configures every app, and migrates user settings automagically. Technical utopia. White marshmellow clouds, anyone?

The stunningly stark contrast to the technical mindset is the business side of the fence - dollars, and time. Can we leverage the 80/20 rule and cut some corners for most of the benefit? Will implementing this improve our profitability by reducing costs or increasing revenue? Are there other projects that will have a greater impact on the business?

The best path often lies somewhere in the middle, and this is where compromise comes in. As an advocate for whatever technical solution you’re trying to implement - whether you’re selling it to another company or to your own management - convincing the guy that makes the final decision to implement the “proper” solution won’t always happen. When you do compromise on a solution, the important part to know is not whether to compromise, but what parts you should compromise on.

So how should you go about it?

1. Make sure they know the risks

The first, and most important point to remember is this - make sure that those that make the decisions, know the risks. This goes for whether you’re working for an IT partner, internal IT, or development. Your role is to identify the risks so that the decisionmaker can make an educated decision.

For example, if you’re putting in a remote access solution, and the decisionmaker doesn’t want to spend money on two-factor authentication tokens, make sure that they understand that standard username and password authentication is susceptible to all sorts of security problems, whereas two-factor authentication is many times more secure. If they still don’t want two-factor authentication, that’s okay.

If they’ve accepted the risk of the compromise (bad pun unintentional) - that’s their decision to make. You’ve done your job by making sure that they’re aware of it, so they could make an educated decision.

2. Accept that there’s always a trade off

Many technical people get upset, angry or annoyed when someone doesn’t want to implement their full solution. I know I’ve been guilty of it at times. In our minds, the solution is appropriate, and the best to fix whatever the current problem is. Why don’t they just implement it!

Accept that there is always a trade off. Businesses only have so much money to go around, and the highest priority projects get the most attention. Much of the time the solution you’re trying to implement might be quite important, but so are half a dozen other projects that cost just as much. It’s a world of finite resources.

Something has to give - and it usually results in a compromise on your solution.

3. Holding your ground

There are some things that you should never compromise on. The school of life has shown me that if you don’t stick to your guns on these, all hell can break loose later.

You should never compromise on:

• The project implementation process. Especially, don’t skip the design and testing phases. You’re far better to compromise on the functionality of the solution than on the process by which you implement it - you’ll end up with less functionality, but a better solution.
• The supportability of the solution. Don’t put a rush-job, stop-gap solution in place that is unsupportable because of a lack of time. If you don’t have the time to do it right, where are you going to find the time to do it over again?
• Your ethics. It’s not up to me to tell you what your ethics are, but if you start compromising them to cut corners - take a long, hard look at what you’re doing. “Because my boss told me so” isn’t a valid excuse.

4. And sometimes, things just suck

If you’ve explained the risks, accepted that compromises need to be made and held your ground where it counts, and you still have to compromise further - you could have a problem. Either there’s a problem with your perception of the situation, or the decisionmaker’s. Figure out how you’re going to deal with it.

Just don’t get bitter when you’re asked to compromise - everybody’s doing it.

There’s nothing like that feeling of hitting the gym and feeling strong.  Every rep slots into place.  You finish knowing you’ve put in your best effort.  I just had it.  Beautiful.