Archive for the ‘Upgrades’ Category

WS2003Windows Server 2003 (WS2003) was first released in, surprise, 2003. It replaced Windows Server 2000. Microsoft has released several derivatives including Windows Compute Cluster Server 2003, Windows Storage Server 2003, Windows Small Business Server 2003, Windows Home Server, and Windows Server 2003 for Embedded Systems.

WS2003 mainstream support ended in July 2010. On July 14, 2015, Microsoft will officially end extended support for WS2003. Microsoft will not release any updates, including security updates or patches, after this date.  At that point you can pay Microsoft for security fixes for WS2003, but it is very expensive and not delivered promptly. Most antivirus solutions will not be supported on WS2003 after 7/14/2015 meaning that there will be no signature updates for new vulnerabilities. Considering the rate at which new malware opportunities are discovered in all flavors of Windows platforms, any WS2003 systems you have in production will quickly become vulnerable. As one data point, there were 37 critical updates for WS2003 in 2013, 10 years after the product’s release. WS2003 will not pass any further security or compliance audits. Expect stiffer fines and other penalties if you experience a data breach where a WS2003 system is part of the application environment.

This should not be a surprise. Microsoft has published its support policy and product end of life chart on its web site for over ten years. There are a lot of servers still running WS2003 out there. A Microsoft survey in January 2014 showed about 22 million WS2003 systems in use. A large number of those are in small and medium sized businesses. Many of these SMB companies do not have large IT staffs or budget to make any kind of a migration.   There are probably at least 10 million WS2003 systems still in use today. Even many Fortune 500 companies are still dependent on WS2003, and most will not have migrated by the deadline, especially as it seems to take about six months to make the migration off WS2003.

Microsoft introduced Windows Server 2008 in 2008 as the successor product to WS2003. However, Windows Server 2008 is not the best destination for your WS2003 systems. Microsoft will end mainstream support for Windows Server 2008 on the same day that it ends all support for Windows Server 2003, July 14, 2015, while extended support ends in January 2020. If you need to move off Windows Server 2003 in any of its flavors, you are better served to jump to Windows Server 12. Windows Server 12 was generally available in September 2012 and released R2 in October 2013. Mainstream support for Windows Server 12 is scheduled to run until January 2018.

Microsoft provides assistance. Perhaps as an indication of their sense of urgency, the first thing you see on that Microsoft page is a count down clock telling you, down to the second, how long you have. Microsoft is, not surprisingly, pushing migration of your WS2003 servers to the cloud powered by Microsoft Azure. In some cases, that may make sense, but only if you want to make a significant change in your operations and procedures. Moving to the Cloud should be a business decision, not a technology decision. Like a lot of things involving cloud computing, the end point is often a better place to be, but getting there under a deadline can be risky. You should at least look at the material Microsoft provides to help in discovering which of your applications and workloads are running on WS2003, assess those applications and workloads by type, importance, and complexity, and choose a migration destination for each. For some of those workloads and applications, moving them to the Cloud may be the easier and less risky solution.

Your IT department probably has some good reasons for not migrating:

  • Your current server hardware may not support Windows Server 12.
  • Some of your mission-critical applications may not be supported on Windows Server 12.
  • You do not have sufficient financial or IT resources to make the migration while simultaneously keeping your IT environment running.
  • Unfamiliarity with Windows Server 2012.

The second may be the most serious, and may take the longest to fix. In the worst case, you may need to migrate to a different application.

In the meantime you may be able to mitigate some of the risk by restricting access to your WS2003 servers. Products like the Unisys Stealth Solution may help. It can completely isolate your WS2003 systems from the outside world, allowing communication only from the specific systems and users you permit. Since the protection is based on user identity, not specific network location or device identity, the rights of an individual change automatically when their role changes. As Unisys says, “You can’t hack what you can’t see.”

If you do not have the resources, get help. There are many companies out there with experience in migrating off WS2003. You do not have to go it alone.

The last word:

Windows Server 2003 is potentially as serious a security problem as Windows XP. Hopefully you are well past getting rid of that OS from your entire IT environment as have all of your business partners who share any proprietary, financial or customer protected data.

If you are running Windows Server 2008 you should start planning to move them to Windows server 12.

The keys to a successful operating system migration are planning and testing. These exercises can feel like a huge drain on your resources, and each migration can itself cause new problems. But you have to do it; you cannot afford to be vulnerable.

Comments solicited.

Keep your sense of humor.



Read Full Post »

Don’t mess up the installation and upgrade processes for your software products.  They have the opportunity to negatively impact customer satisfaction, revenue, and profit.  Like dusting, nobody notices when you do it right, but it is obvious when you don’t.  These two aspects are actually different sides of the same problem: getting your software product into production for a customer and allowing you to get paid.

Don’t miss the opportunity to make a great first impression.  That first time your new customer really sees your product is when he tries to install it.  We have all had the experience of installing something that was really difficult, with lots of manual steps, poor installation documentation, and lots of “I wonder what I should do next” stop points.  Or you call the help desk and get someone as confused as you are.  Even if the help desk people are competent and help you on the first call, the product now is branded in your mind as complicated and hard to use.  Bad first impressions are hard to overcome.

When a new version for your product comes out, how painless is it to get it installed?  How much disruption to your customer’s business does it cause, and how much effort is required to get it right?  If your customer perceives that it is harder to install your upgrade than to move to your competitor, what do you think he will do?  It is much better to never make the customer even ask the question.

One place I worked had a fairly common CRM (customer-relationship management) package from a major vendor.  In order to get some problems fixed and take advantages of some new features, we needed to upgrade from version n to version n+1.  The vendor said it would take two days, so it was scheduled over a weekend.   It took more than seven days and involved a lot of work from both the vendor and us.  That was a week where we couldn’t take orders, send invoices, or even properly handle support calls without a lot of manual effort.  That vendor doesn’t supply the CRM system there anymore.

Over the years I have been thrown into situations with existing product sets that had serious customer satisfaction problems.  It is nice in one way: it wasn’t my fault things were the way they were, and since I was the new kid on the block I could always ask the stupid questions like “why is that so hard?”  However, the issues were usually engrained as much in the culture as the technology, and culture can be interesting to fix.

In one case I started by looking at the support call log for the past six months.  Almost 80% of the calls were about installation or upgrades.  Some of the calls were open for weeks until they were resolved.  The support team was top notch, but the software was just very complicated to install, and it had to be manually installed at lots of places.  These calls had several suboptimal results: support calls cost real dollars to respond to, the customer is not going to pay his invoice until the product actually works which delays revenue, and the customer isn’t real happy with your product.  The latter persists and gives your competition an easy way to throw FUD (fear, uncertainty, and doubt) the next time the customer needs more product.  I took a small set of the best engineers and made it their problem.  They started by sitting at the support desk taking calls, calling customers who had reported serious installation or upgrade issues, and listening to what the customer wanted.  Now, as is often the case, what the customer wanted was that all you had to do was get the installation CD close to the system and everything would happen automatically.

The team came up with a totally different way of looking at the problem.  A couple of months later they had an installation process that we could use across the product line that asked all of the necessary questions up front, then automatically did everything everywhere.  If it was an upgrade installation, then it didn’t even ask the questions, it figured the answers out from the existing environment.  The net result was that six months later our support calls for installations and upgrades were only about 10% of our calls, and were almost always resolved in the first call.  I and the CEO started get emails from customers who wanted to tell us how great our software was.  Even better, we entirely replaced our biggest competitor at a large account simply because we could get a new project up and running in one day instead of the three days the incumbent vendor claimed was required.

In another case we had a product that was fairly critical to a customer’s operation.  The primary engineer on the product was much more interested in adding neat new features than in making the upgrade painless.  I sent the engineer to visit the customer for a few days and see how the customer was actually using the product, and to directly see how lost time for an upgrade impacted the customer.  When he got back, the engineer disappeared into his office for a couple of weeks, then demoed his new upgrade mechanism to us.  I sent him back to the customer’s site to show the customer and get his feedback.  The customer was ecstatic – his upgrade downtime went from many hours to less than a minute, and the manual input required went to virtually nothing, eliminating the human error that had sometimes forced the customer to re-install the upgrade several times to get it right.

The best part of both of these examples is that there was very little change to the product – it was almost all in the installation.

In most software development organizations, the developers view installation as unimportant and uninteresting.  No one wants to work on it.  It is often the last thing done, and is done quickly without much thought and without much testing.  The first thing that needs to happen is to change that culture.  Engineers usually take great pride in their work.  I have found that if you actually talk to them about the importance of installation and upgrades to their customers and the company’s revenue, you can usually get them to change their view.

When should you start worrying about these issues?  You can maybe get by a couple of early adopters with a labor-intensive installation process, and maybe you can get that first customer to the first real production release by going in yourself and doing all of the work involved.  But after that, the product must be easy to install and upgrades must be trivial to do and have the absolute minimum impact on the customer.

While every situation is a different, there are a few guidelines to consider:

  • Only ask a question once.
  • Ask all of the questions up front, especially if the installation / upgrade process will take more than a few seconds.
  • Verify, to the extent possible, all installation parameters at the time they are provided to the process.
  • If something goes wrong during the installation process, make sure you give the customer enough information to determine the exact nature of the problem and to give your help desk folk a good chance of solving the problem on that important first call.
  • Allow the user or administrator to make a reasonable change to any configuration item at any time without a re-install, and “remember” the change.
  • For upgrades, pick up the current installation parameters.  In general, there should be no need to ask questions during an upgrade.
  • When replacing a competitor’s product, give the customer the opportunity to pick up configuration information from your competitor’s product.  Even better, have your installation look for your competitor’s product and give the customer a single click option to configure your product the same way.

Talk to your customers about their issues with upgrades and installs.  Make sure your qualification tests include significant testing of the process, especially upgrades.

Make sure your customer doesn’t have to upgrade everything at the same time.  If you have different components that may be scattered in the customer’s environment, make sure that different versions can interoperate to some degree, and publish those rules.  If components at version n+2 can operate with components at version n and n+1, that’s great.  If you are limited the compatibility to only version n+ 1 and version n, then publish that.  Of course, some features may not be enabled when all components aren’t at the same level that supports those features case.

The most critical place to have an effortless install is for your demo or trial package.  If that doesn’t install obviously and quickly with no problems, you don’t even have a chance for a sale..

The last word:
Where do the most experienced aircraft engineers work?  On the landing gear.  It’s hard to get right and you have to get it right. Bad things happen when they fail, and there is no opportunity to try it again.  Who should design and develop your installation and upgrade processes?  Your most experienced designers and developers.  If you don’t have top notch installation experts on staff, go rent some.  Once you get it right, it is fairly easy to keep it that way.

Comments solicited.

Keep your sense of humor.


Read Full Post »