Monday, 30 June 2014

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.



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

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

Monday, 9 June 2014

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

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

Wednesday, 21 May 2014

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.

Thursday, 17 April 2014

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

Monday, 31 March 2014

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;

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. 





Monday, 10 March 2014

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!

Thursday, 20 February 2014

Bit MUI LIP

I was asked by a client today what the difference between a Microsoft MUI and a LIP. And, more importantly, "what were the application compatibility consequences of multi-language support?"

I thought I knew what a MUI was - the language and resource layer that you could add onto Windows XP and Server 2003 to fully support languages such as French, German and Spanish.  I remember these resource packs well as when they initially appeared in my MSDN Select CD binder - I thought that they were a god-send. After spending nearly a year on getting Windows 2K to (properly) support Chinese (all three types including Big5) and Japanese (hiragana, katakana and Kanji) through 3rd party software such as Twin Bridge's IME, I was ready for anything.

And, Microsoft's own words, the MUI is defined as,

"Multilingual User Interface Pack is a set of language specific resource files that can be added to the English version of Windows Professional. When installed on the English version of Windows, MUI allows the user interface language of the operating system to be changed according to the preferences of individual users to one of the 33 supported languages".


OK, sounds pretty clear… Now, what is this LIP stuff?

Again, referencing TechNet, "Microsoft Windows XP Professional Language Interface Pack (LIP) is a high-quality, localized "skin" for emerging or minority language markets, such as Catalan, Lithuanian, and Thai.

And, what is the difference between a MUI pack and a LIP installation? Get ready as,

"The main difference is in the level of localization in comparison to MUI packages: LIP packages provide the desktop user with an approximately 80% localized user experience. In addition, LIP doesn't allow users to switch languages. Once a LIP is installed, all users using that machine will have the same User Interface (UI) language. "

So, in summary it looks like the MUI is a "switchable" comprehensive interface while the LIP is a 80% permanent installation.


References:

Windows XP Multi-lingual User Interface (MUI) FAQ's

Application Compatibility and the Microsoft MUI

Microsoft LIP Frequently Asked Questions