Server 2003 is new the Windows XP

As a grizzled veteran of many desktop migrations, I remember (all too well) the many pitfalls and challenges in migrating to Windows XP. Even worse, I also remember migrating to Windows 200. Which is really showing my age. Time to move on? No way. We are getting pretty good now at migrating desktops. We have automated workstation builds, large scale deployment platforms applications and we seem to get getting the update process working without causing major service outages with each month. 

Now it is time to focus on our server platforms. Microsoft has a rolling lifecycle policy that details when each platform will receive mainstream support, extended support and also details the final day of patches and bug-fixes to the specified platform. I have included an image from Microsoft’s support lifecycle web page that details the basic structure of how Microsoft supports its applications and development platforms.

As you can see from the chart below, for Microsoft’s Windows 2003 (R2) mainstream support has already ended. This means that though the platform will still receive security updates, Microsoft will no longer respond to feature requests. And, no more complimentary (free) support for Windows 2003.  Here are some of the details on the support lifecycle for Windows Server 2003.

Migrating to Windows 7 from Windows XP was a big problem with a host of associated technical and logistical challenges including;

• refresh of desktop hardware was required
• application compatibility issues were a significant technical challenge
• potential complications from a new, more restricted security model were possible
• a browser change (from IE6 to IE 7 or IE10) caused unforeseen migration issues

Now, with the current impetus to migrate from Windows 2003, we are again facing all these issues and the following additional challenges;

• hand-crafted server builds and application installations are difficult to replicate
• there is an increased business risk to higher numbers of users affected by server outages
• database and other server connections and dependencies are more likely and more complex
• older applications may no longer be supported
• cross-dependency issues are exacerbated on newer 64-bit platforms

And if Windows 2003 end-of-life support wasn't enough of an issue, the following other technologies will expire also on the same day (July 15th, 2015);

• Compute Cluster Pack: 14 July 2015
• Forefront Client Security: 14 July 2015
• Host Integration Server 2004: 13 January 2015 (I haven’t heard of this one inyears)
• Internet Security and Acceleration Server 2004 Enterprise Edition: 14 April 2015
• Internet Security and Acceleration Server 2004 Standard Edition: 14 October 2014
• Microsoft Operations Manager (MOM) 2005: 13 January 2015
• Systems Management Server 2003 and 2003 R2: 13 January 2015
• Virtual Server 2005 and Virtual Server 2005 R2: 13 January 2015

According to HP, over 11 million systems are currently running Windows server 2003. That’s over 25,000 servers that need to be migrated each day before extended support expires.

The time to start planning is now!

Microsoft Security Baselines for Window 8.1 and IEII

As a nod to the idea that it's not just compatibility that you have to worry about, Microsoft has release their latest iteration security baselines for Windows 8.1, Internet Explorer 11 and Server 2012.

This collection of documentation and Group Policy Objects (GPO's) details a secure baseline for your server and desktop environments.

Here is a quick highlight of the topics included in this documentation pack;

• Use of new and existing settings to help block some Pass the Hash attack vectors
• Blocking the use of web browsers on domain controllers
• Incorporation of the Enhanced Mitigation Experience Toolkit (EMET) into the standard baselines
• Removal of the recommendation to enable "FIPS mode" 
• Removal of almost all service startup settings, and all server role baselines that contain only service startup settings.

This documentation pack includes the following folders;

• Administrative Templates
• Documentation
• GP Reports
• GPO
• WMI Filters

The two key sections in the Recommended Security Baseline Settings document (.DOC file) are the new settings in Server 2012 R2 and the removed (deprecated) settings for Windows and Internet Explorer.

You can download the necessary files from here: http://blogs.technet.com/cfs-filesystemfile.ashx/__key/telligent-evolution-components-attachments/01-4062-00-00-03-62-67-77/Win81_2D00_WS2012R2_2D00_IE11_2D00_Baselines_2D00_BETA.zip

Note: that this is a BETA version and is subject to change.

Thanks to Aaron Margosis's very nice MSDN blog for the update. 

Flash Compatibility in Internet Explorer 10

As like many of you, I have downloaded the Windows 8 and like a few of you, I have installed it on a number of machines, virtual environments and different hardware platforms. My DELL All-in-One is currently is my favorite as it supports a touch interface. That said, the Touch-enabled drivers are not quite there yet (gestures are not currently working) but otherwise the initial experience has been positive.

And now, for the real world: my middle child (of three) was trying to visit a flash based "Barbie dress-up" site (no, not one of my favorites, for those at the back) and things got a little more complicated. The site loaded in the desktop view (currently our default) but would not in the Metro side of things.

Doing a little reading, I found about the IE 10 Compatibility View list on MSDN which reads; 

"While any site can play Flash content in Internet Explorer 10 for the desktop, only sites that are on the Compatibility View (CV) list for Flash can play Flash content within Internet Explorer 10 in the Windows Metro style UI."

And further on;

"Internet Explorer 10 uses the CV list to enable specific sites to run with the Flash Player functionality supported in Internet Explorer 10. Microsoft manages and distributes the CV list and determines which sites go on the list. Decisions regarding how sites that require Flash Player are treated on the CV list are evaluated based on the quality of experience of the site in Internet Explorer 10, taking into consideration factors like performance, responsiveness, touch interaction, security, privacy, and battery life."

So, if you have Flash site, you need to submit it to Microsoft to get it on the CV list, and see it in its wonderful glory on IE10 Metro mode. You can submit your domain and site to Microsoft at the following address; iepo@microsoft.com

If you want to just get things working (my preferred approach) you can also edit the following registry entry; HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Flash\DebugDomain

If you are wondering what WILL NOT work under Flash for IE10, Microsoft has provided a rather long list including;

• Camera
• Microphone
• Printing
• Feature bookmark (for example, Flash Anchors)
• Relying on double-click (double-click is consumed by the player, for zoom to fit, and not propagated to the Flash content as a double-click event)
• Use of rollover and rollout event
• Relying on P2P (Windows Metro style design guidelines disallows the creation of a socket server)
• Relying on the following Flash touch APIs: Pan, Zoom, Rotate, Swipe, and PressAndTap

I am not a fan of Flash, but it makes sense for Microsoft to support Flash (with a heavy future focus on HTML5 and JavaScript) and it appears that they have come a reasonable compromise with Flash support on desktop mode and not for Metro.

Read more here:

Developer Guidance for Web Sites with Flash Content in Windows 8

http://blogs.msdn.com/b/ie/archive/2012/06/22/developer-guidance-for-web-sites-with-flash-content-in-windows-8.aspx

Developer guidance for websites with content for Adobe Flash Player in Windows 8

http://msdn.microsoft.com/en-us/library/ie/jj193557(v=vs.85).aspx

Application Management for the rest of us

What does Application Management for the rest of us really mean?

I started my career in IT attempting to create the necessary tools and infrastructure to deploy large numbers of applications in a demanding and dynamic enterprise environment. Over the past 15 years I have progressed through a journey in automating as much of the application management process as possible. This process involved several stages including:

• Discovery: Finding out who owns/wants/understands a particular application 
• Application Packaging: getting the installation routines into standard and manageable format (e.g. MSI installer or App-V)
• QA and Testing: ensuring consistent quality and compliance to the corporate standards
• User Acceptance Testing: ensuring that users got what we they requested
• Deployment: the actual delivery of the applications to the intended platform (both server and desktop)
• Retirement: the process of removing or decommissioning applications that are no longer required

As you can imagine each of these steps requires technical skill, expertise and time to complete. And therefore, the cost for each stage and the aggregate of the entire process is expensive and risky.  In addition, like any non-core business process a potential distraction to the task of running a business. So, why do organizations go through this process?

I think that there are three reasons;

1. Cost
2. Risk
3. Increased User Expectations

Creating a process that can be optimized, automated and quality checked will generally be cheaper in the long run if not immediately compared to an ad-hoc informal approach when applied to large-scale systems. If you know all of your users by name, you may not need an automated deployment tool. If you can’t count all of your offices on both hands, you definitely do. Added to the expected cost savings, most organizations will generally prioritize the risk of failure over anything else. And more recently, application users and owners expect a rapid and robust delivery process for their business critical applications. The bar has been raised with the perceived ease of installation and upgrades with Apple’s iPhone based applications. And, now large corporates are now expected to support many disparate systems and timescales that would not even be considered only a few years ago. 

And, what if I am not a large corporate?

Here is where life gets’ interesting. What if I only have 200 applications instead of 10,000? Do I still need a packaging process and deployment systems? With large-scale systems the cost saving are large and easily quantified. With smaller systems, the benefits may not outweigh the investment of standardized processes and automation technology. 

There are definite benefits to managing your application portfolio with tools and processes including;

• Faster deployments - if business agility is important, getting applications deployed and updated quickly may be a key business driver
• Lower support costs: sometimes difficult to measure, but standardized process and industry best practices generally lower IT supper costs
• Regulatory compliance:  some industries will require high levels of processes and documentation that only automation tools can deliver

There are a host of other reasons, but most organizations benefit from reduced overheads, better business agility and are more profitable if they employ standardized, highly automated IT processes. If you are not doing, chances are that your competition will and will deliver a faster, better and cheaper product that you.

How can smaller organizations get these benefits without the associated high costs?

A new approach is needed. Through the use of new levels of automation, web-based self-service access and per-application pricing, organizations can benefit from the tools and technologies previously only enjoyed by the large corporate IT environments. 

We can raise the quality bar for smaller organizations IT systems while reducing the barriers to entry through;

• Easy to use, web-based services (minimizing infrastructure requirements and investments)
• Extensive process automation (saving time, and reducing costs)
• Low-risk Pay-as-you-go usage models 

Watch this space, to find out more.

Whose OS is it anyway?

I've got a question burning away in my mind - and I am not sure if I am right to ask it. I feel that, at the very core of Microsoft Vista and Windows Server 2008 rages a battle of hearts and minds over a possibly forgotten but all-encompassing issue.

The question that begs for a reply is; Whose operating system is it anyway?"

My focus is getting applications to work and the engineering effort required to deploy, install and manage thousands of applications on large heterogeneous networks. I have encountered an overcome numerous challenges including;

• User Account Control UAC
• Application Compatibility 
• Security Restrictions

And now, I seem to face my greatest hurdle of them all; the mother of all technical challenges: Windows Resource Protection.

In Microsoft's own words; "Windows Resource Protection (WRP) prevents the replacement of essential system files, folders, and registry keys that are installed as part of Windows Server 2008 and Windows Vista."

Simply put; there is a system in place to ensure that you can not over-write either files or registry settings that the OS (Vista or Windows Server 2008) requires to function. In fact, most DLL's and executables within the Windows directory (the main OS directory) are protected under Windows Resource Protection (WRP) - meaning, that for most system files, you simply can not change or update these files or settings.

The principle of this system is pretty benign - keep the OS working. This increases stability, reduces support calls and generally makes most people are happy about this. The challenges begin when you need to update the OS for your own dark-hearted, nefarious purposes. Such as, to get an application to work….

Under Windows XP and Server 2003, there was a system called System File Protection (SFP) that relied on a cache (local copy) of "good DLL's". In the event that that a key OS system file was updated, the system would check the file version against this known list and replace the new file with the file taken from the local cache. This was a moderately successful security system with easy work-arounds.

HINT: stop the SFP service, update the local cache, update the target file in the system directory, restart the SFP service.

With Vista, there are a number of "approved" methods (Supported Resource Replacement Mechanisms) including;

• Windows Service Packs installed by TrustedInstaller.
• Hotfixes installed by TrustedInstaller.
• Operating system upgrades installed by TrustedInstaller.
• Windows Update installed by TrustedInstaller.

The Vista/Server 2008 WRP uses local security settings to restrict access to these protect files and settings - only allowing access to the TrustedInstaller module.

This makes things particularly difficult if you need to update a file on the OS - only Microsoft is allowed to touch these areas. My primary complaint is this; There should be a mechanism for system administrator to update the OS.

At present, I can not generate Windows Service Packs, customize Hotfixes or create my own Operating System upgrades. This is primarily due to restricted API's and Microsoft's freely acknowledged lack of documentation.

So this begs the question, "If I can't change it, who can?" And, if the answer is a certain software behemoth, I plan to raise a merry stink about this….


References:
About Windows Resource Protection
http://msdn.microsoft.com/en-us/library/aa382503(VS.85).aspx


Support Resource Replacement Mechanisms
http://msdn.microsoft.com/en-us/library/aa382540(VS.85).aspx

Static Analysis: Out of the closet

A friend of mine, Chris Jackson may or not be known to you few who read this blog. Touted as the Top Man in Application Compatibility he undoubtedly has more knowledge, experience and understanding on the topic of application compatibility than all other organic (non-silicon) beings on the planet.

Recently, he posted a note on his blog about static analysis for application compatibility that may be interesting.

His posting can be found here;

http://blogs.msdn.com/cjacks/archive/2010/03/23/it-s-not-your-to-do-list-using-application-compatibility-tools-to-diagnose-problems-not-surface-them.aspx?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+Microsoft%2FMSDN-Blogs+(MSDN+Blogs)

I think his views on the topic are interesting - however, I think he raises a few key points that I feel the need to comment upon.

Chris notes that;

"One thing you want to be very careful of with all of the tools: it’s remarkably easy to surface all kinds of “issues” which would be “better” if you fixed them, but the software still lets you get your job done if you did nothing about it. Chances are, you were given the budget for an application compatibility project, not an application quality project. Application quality projects cost more than application compatibility projects – don’t create one accidentally."

I think from what we are seeing in the Enterprise application compatibility space is that as part of a migration to Windows 7 (or App-V) getting your applications to the next platform, really is a "Quality Issue". We are finding that most clients standards have changed and/or improved over the past few years since the last migration (remember the move TO Windows XP??).

So, the point here is that there is probably a large chunk of work to be done on each package as part of the migration effort. So, here is a quick summary of the tasks you may to complete to get each application package ready for the target platform;

1. Windows 7 Compatibility fixes
2. App-V tuning and optimization
3. Industry Best Practice Updates
4. Quality Assurance Analysis and Updates

So, you may have a lot of work to do to get your application packages into shape for the new platform. When we created AOK, we saw this issue coming and created automated fixes for these issues.

So, if you are doing a Compatibility Project, you are probably expected to also deliver a Quality Project.  And, my guess is that you need an automated solution for both the analysis and the remediation. 

Automated Fixing is good practice, good change control

I've been singing the praises of automation (hey, I am a computer guy) for several years now and in many instances it has been focussed on the application migration arena .  However, in more and more discussions with organisations the whole BAU (Business as Usual) topic pops up when we’re looking at application compatibility and maintaining that gold standard across the enterprise once the deployment is complete. Meaning, keeping the applications working while the organization changes above and below the application stack.

So this got me thinking about organizational Change Control and how automation fits in. Here’s my "50,000 Application"  view of the benefits of automation for Change Control within an organization;

1. Automation is good for change control –because of its orderly, process driven fashion it makes it easy for system administrators to achieve consistency across all changes with the application estate.
2. Automation by its very nature will have some form of log files build it. This puts more than a tick in the box for the auditing process and makes referring back to issues /process simple, quick and cost effective. Auditing tracks user actions and with good logging, you get the logic of the reporting and remediation process as well.
3. Consistency – already mentioned in part 1 – the removal of human error is key here. When it comes to migrating an application estate of native, web, browsers and portals, consistency is king. Automation enables organisations to achieve this.
4. It’s quick, it’s fast and it’s cheap. Automation frees up resource to focus on the bigger issues, it saves time and money both things the enterprise is short of in today’s economic climate. Computers are cheap, people are great, but not cheap.
5. Automation is trustworthy. This is a big leap for some. You trust your calculator because you have used it enough times and it has been right enough times to earn that trust. Automation algorithms (I prefer the term recipes) are generated by humans, performed by computers but generally tested by humans. When you trust an algorithm, you are trusting the humans who tested the outcome. Automation outcomes get tested by more people, more often and generally under more conditions than a manually performed process. Once you get automation right, it stays right, for longer.

So, if you are playing chess, calculating Pi or fixing application compatibility issues, I would place my bets on the  organic/fleshy coach, and the silicon player any time.

See you in Berlin next week!