Tag Archive for windows xp

Guest post – Common Patterns In Windows XP Application Rationalisation

In this Guest post Barry Angell, CTO of Juriba will talk about the Common Patterns In Windows XP Application Rationalisation.

——————————————————————————————-

When you have been involved in as many enterprise desktop migrations as we have at Juriba in the past few years, you start to see certain patterns emerging.  This ranges from the general underestimation of work effort through to a familiar lack of project deployment strategy.  The resulting impact is unfortunately one of business disruption, increased cost and a longer project than anticipated.

One of the most common patterns we see is in the application rationalisation arena.  There is an almost unwritten expectation that the post-migration world will be much cleaner than the pre-migration world.  This is entirely reasonable.  In even the best managed environment, 10 years of running an operating system and thousands of desktops is inevitably going to drive complexity into the application estate.  Essentially, you cannot rally against human nature.  It is much quicker for a support analyst or business user to install an application manually than tell your customer (the end user) that they must wait 15, 30 or even up to 90 days (in some organisations) to get their packaged application distribution.

Unfortunately, this leaves every project in the world with a serious dilemma and a decision that no migration programme in the world really wants to take; do we give the users what they officially have, or do we try to give them back what they had installed prior to migration?  The former breeds a cleaner project of known states but likely user disruption.  The latter places a huge amount of additional workload on the teams in analysis, categorisation, identification and possibly licensing of applications.

So we end up with a choice where neither answer is particularly appealing.  Do we take a big decision to take on the add/remove programs mess or do we take the expected business impact of users not getting back what they had previously by replacing the like for like official application entitlements?  We consider a third option – can we collect usage data to do the rationalisation for us, requiring a 60-90 day minimum lead time for trustworthy information?

If we decide to go down the add/remove programs or discovery/usage route, we are left with a mass of data.  Typically around 2.1 times the computer count (in other words an estate of 10,000 computers will yield an application count of 21,000 unique application entries).  A quick scan around the room generally identifies the poor individual(s) that will be charged with categorising the list!

Time passes, money gets burnt, resources are employed and we end up with a normalised list of applications.  A common pattern here is that the output of this work is in spreadsheets.  Unfortunately, this effectively means the programme is stuck with static data for the foreseeable future.  Many normalisation efforts use a combination of logic and human choices which are not repeatable for refreshing the data.  Some usage tools will do a certain level of normalisation out of the box but very rarely get anywhere near to your required result without further manual intervention.

So we now enter the application packaging phase.  Of course the applications team are used to MSI packages, some of which include multiple add/remove programs entries.  They don’t understand the list of normalised applications from ARP that you have provided, and now need to manually map those entries to something that they recognise – a difficult job.  Further, it is much harder to find source code for an ARP entry than it is to find an MSI you have already packaged!

Now of course, these applications do eventually get completed.  The team works through the mess and delivers the required end result with a lot of effort.  But it all feels so wrong – an incredibly painful journey, but a path that the vast majority of organisations will tread in the coming couple of years.

The moral of the story is that as an industry, we need to get better at desktop applications management.  Moving to Windows 8 or 9, moving to virtual should not be the huge effort that it is today.  Let’s get our heads around the problem and start solutioning.  I would love to see a concerted effort to uniquely identify applications – whether it be an executable, Excel macro, add/remove program entry or packaged MSI, the world would be a better place if we had a central database somewhere!  A place where you could upload your app metadata and store it for reference later.  If we don’t start solving this now, I fear that the next rollout will be another wheel re-invention.  Nobody wants that!

Barry Angell – CTO – Juriba Ltd  |  Simplifying Desktop Migration

Twitter: @juriba  | Email: barry.angell@juriba.com

 

Path to Windows 7 – Part I. History and timeline

timeleft_887_days

Windows 7 is now over 2 years old. October 22nd 2009 was the official release date for the OS that had the fastest adoption in history. A lot of lessons where learned over the last two years and I will go through a few of them on this blog.

Windows XP is now over 10 years old. When it was launched DSL connections was barely available and Wi-Fi wasn’t even on the roadmap. The first Wi-Fi client for XP was introduced on SP1 and a decent client was delivered on SP2. It is also worth mentioning SP1a, when Microsoft removed Windows VM, the engine to run Java applications. Windows XP has great back then, but lacks great features introduced by Windows Vista and Windows 7. User experience is not great on XP, which used to stand for eXPerience, but now stands for eXPired.

Windows XP extended support expires on April 2014, mainstream support finished in 2009. That means that to get support or bespoke patches you will have to pay a support contract (including retroactive to 2009 to today).
As an IT department you can’t afford to support an OS or applications that are no longer supported by the manufacturer. But one may argue that security updates are still available, and that’s true, that is the only benefit left available for free until the end of extended support.

The first lesson we learned over the last 2 years is that a migration from Windows XP to Windows 7 takes some planning, as no in place upgrade is available. There are several things to consider, they will be covered on the next few posts. A Typical “XP to 7” migration takes between 12 to 18 months, which means that if you start right now you don’t have much time left.

There is a great Desktop Gadget to follow how much time is left until XP eXPires. The gadget is called Windows XP End of Support Countdown Gadget.

Stay tunned for the next Path to Windows 7 article. Subscribe!