You can help to find the truth of MH17. Support open source journalism.

298 children, man, women, fathers, mothers, friends, kids, co-workers, neighbors, loved ones all died because some thug decided to press a button launching a deadly missle which ended flight Malaysian Airlines MH17.

What happened next was a disgrace to humanity. Personal belongings were stolen, bodies were not collected in 35 degrees heat, independant observers were obstructed, parts of the plane were removed  etc etc. A DISGRACE!

The world has to find out who did it and these people have to be brought to court. Also the country direcly or in-directly responsible for this act should be punished. It is likely most of the evidence like the BUK laucher has been destroyed by now.

We have to find the truth. There is a lot of evidence to be found on internet. Photos and videos of the crashscene, photos of the BUK missle launcher when it travelled in East Ukraine. A couple of very dedicated people are researching to find out the TRUTH.

Make sure to visiti these sites for more information on the BUK, the damage and much more:

Ukraine@warB found the possible launch site by geo-location using Google maps and other sources
Bellingcat does a lot of research using Google
The Interpreter

Bellingcat is a project run by Eliot Higgins. See Wikipedia. He is the founder of Bellingcat and the Brown Moses Blog. Eliot focuses on the weapons used in the conflict in Syria, and open source investigations tools and techniques.

He does a lot of effort to find the truth. I encourage you to support his work by doing a donation. This can be any amount you like.  It will only take a few minutes of your life.

WE HAVE TO FIND THE TRUTH!

Please support!

Microsoft InMage Scout now available for download as part of Azure Site Recovery subscription

Customers of the Azure Site Recovery service are now able to try InMage Scout for free . Last week Microsoft InMage was acquired by Microsoft.

InMage enables protection of both virtual and physical servers. It does so by installing an agent which intercepts storage traffic, redirect that traffic to an appliance which then replicates the data to another location.

InMage can now be dowloaded for customers wanting to do recovery between two on-premises VMware sites.

As InMage Scout is able to perform V2V conversions it is likely in the future VMware customers can perform a recovery on Microsoft Azure.

Between July 1, 2014 and August 1, 2014 InMage Scout software can be used on a trial basis.

InMage Scout can be downloaded by creating a Azure Site Recovery Vault. At the Setup Recovery select ‘Between two on-premises VMware sites.

Customers pay for the instances they are protecting with InMage Scout through the Azure Site Recovery (ASR) SKU available in the Microsoft Enterprise Agreement beginning on August 1, 2014. InMage Scout is a deployment option available to you as part of the Azure Site Recovery service. Scout is not available for purchase via Azure Direct or Azure Enterprise Agreement monetary commitment. Customers should use the true-up process in the Enterprise Agreement to account for additional instances protected with InMage Scout.

The download is 770 MB in size.

Read the Microsoft blog about this news here.

 

Will VMware customers using agentless security be facing high costs when upgrading to vSphere 2015?

At VMworld 2008 VMware introduced a new way for protecting  virtual machines. Previously anti-virus, firewall, file integrity  and malware protection had to be performed at the virtual  machine level by installing an agent.

With the introduction of the VMsafe.API network traffic can be now intercepted at the hypervisor level and inspected by a virtual appliance.

The VMsafe.API is used by selected number of third party vendors. However VMware announced in 2013 the end of life for the VMsafe.API. Customers wishing to continue agentless solutions might be  facing high costs when upgrading to the vSphere 2015 release which is scheduled to  replace vSphere 5.5 .

Introduction to agentless security

A traditional security agent installed in a virtual machine has a couple of disadvantages:

  1. consumption of resources. Each agent in each guest consumes compute, memory and storage resources. Imagine a situation where each anti-virus guest performs a scheduled scan on viruses at the same time. This will result in many storage IO. These scanning storms are not a nice situation for VDI.
  2. many virusses try to disable the anti-virus agent. By not using an agent but using technology in the kernel instead a much safer protection is created.
  3. powered off guests cannot be protected by using an agent but they can be infected .

VMware announced at VMworld Europe 2008 the VMsafe API.  Basically the API allows inspection of network traffic at the hypervisor level. Network traffic can be intercepted after entering the physical network interface in the ESX(i) host. It is then routed to a vendor appliance. The appliance does the actual scanning on virusses and malware instead of the traditional deployment where agents are used in each virtual machine.

Agentless is not completely true. While an anti-virus agent is not installed in the guest, you still need to install a vShield agent. (thin  agent)

This image below shows the flow of network traffic when VMsafe.API is used. The image is published at Rational Survivability. 

 

After a rather slow adoption  during the next years vendors started to support the API.  Trend Micro was the first vendor to use VMsafe API for protection against virusses. Later McAfee joined supporting VMsafe with their MOVE product. Kaspersky Security for Virtualization  also uses the API.

Juniper Firefly uses the API for firewall purposes like some other vendors.

To use the VMsafe API a seperate VMware product called vShield Endpoint needs to be installed. Initially vShield Endpoint inclusion was limited to the more expensive editions of vSphere.  Alternatively vShield Endpoint could be purchased. At the release of vSphere 5.1 VMware made vShield Endpoint available for free for vSphere Standard Edition and higher.

It looked like VMware was promoting agentless solutions.

In 2013 VMware announced it will no longer support the VMsafe API in ESXi 5.5 . See this KB article titled ‘End of Life support for VMsafe and Partner Solutions using VMsafe on vSphere 5.5 (2058911)‘ for the details. Trend Micro and other vendors stated they will continue supporting the API in vSphere 5.5. To be able to use Trend Micro Deep Security in  vSphere 5.5 and to get full Trend Micro support ,  customers have to use Deep Security version 9 Service Pack 1, PAtch 2.

While in vSphere 5.5 using VMsafe.API is still possible, the next release of vSphere, likely to be named vSphere 6.0, VMsafe.API is no longer included in the kernel of ESXi. VMsafe.API is being replaced by the VMware NSX API (formery known as the NetX API). 

Customers wanting to continue to use agentless security solutions for vSphere 6.0 are likely required to adopt the VMware NSX for vSphere platform.

This raises some questions. NSX is targeted at large enterprises and service providers. It is a network virtualization tool which uses central management for provisioning and configuration of networks. NSX is not for the masses; it can only be sold by a limited number of certified VMware partners called NSX Elite partners. It is not available for public download. Organizations interested in purchasing NSX will have to do a paid Proof of Concept. The PoC will be built by VMware PSO staff.

NSX is also not a cheap extra license on top of vSphere. The list price is almost 5000,- or  $5,996 per CPU. 

VMware partners are not happy about replacing the VMsafe.API with the  NSX.API. This API offers less features as documented in this article.

Some vendors prevent using VMware API or hypervisor based agents. For example InMage, recently acquired by Microsoft, uses agents in guest for replication. They state here: 

Some vendors run an agent in the hypervisor for replication. Problem is that when vSphere 5 came out VMWare broke that connection for other ISV’s. VMware knew in vSphere 4 that they had a heterogeneity problem and needed storage replication. SRM’s failover and failback used to be a framework product to run on array replication. Since VMware is not open source the company does what is in THEIR best interest and put replication in the hypervisor and still supports array based replication. This took off value for other ISV’s because they now were locked out from providing that feature.

So what do you expect when high volume products don’t use open source or standard API’s? Unless that is their business strategy companies have no obligation to maintain standards. If you try to go into the vSphere and use a link such as VMSCSI you have no assurance that VMware won’t make changes that will break the software without notice.

 

At the moment nothing is known about what will be the cost for customers wanting to upgrade to vSphere 6.0 while continue to use agentless security solutions like Trend Micro Deep Security.

A possibility is that a limited edition of NSX will become available which provides the NSX.API functionality to third party solutions. VMware will shoot itself again it the foot (remember vTAX) when requiring their customers to purchase the full VMware NSX for vSphere SKU just to use agentless security solutions. Also their partners will not be happy with this possible move.

 

 

 

 

Microsoft publishes Technical Documentation for System Center 2012 R2

At July 15 Microsoft released a set of documents titled “Technical Documentation for Getting Started with System Center 2012 R2″

This set is very usefull for anyone working with System Center 2012.

The download has 2 documents which are available in both Word and Adobe PDF format:

System Requirements for System Center 2012 R2 is a very comprehensive Word file documenting requirements for hardware, server and client operating system, SQL
Server, Web console, PowerShell, and .NET Framework.

Upgrade Sequencing for System Center 2012 R2  describes the sequence of upgrading System Center 2012 Service Pack 1 (SP1) components to
System Center 2012 R2

Download here

Microsoft also published ‘Technical Documentation for System Center 2012 – Virtual Machine Manager’. This document has 757 pages.

Lots and lots of information on common tasks in SC Virtual Machine Manager. This document has been updated in July 2014.

Microsoft now recommends not using AlwaysOn in Microsoft SQL Server. If you use AlwaysOn, and you are running an asynchronous commit mode, the replica of the database can be out of date for a period of time after each commit. This can make it appear as if the database were back in time which might cause loss of customer data,
inadvertent disclosure of information, or possibly elevation of privilege.

Download here

 

hardwarespecs

Microsoft acquires InMage. Enhanced disaster recovery services for Microsoft Azure

Today Microsoft announced it  has acquired InMage. InMage is a US company while software development is done in India. InMage offers software to enable disaster recovery (DR) for mid-market and enterprises. 

There are many solutions on the market offering DR. However InMage is the only one supporting all assets in a datacenter: both physical and virtual servers ( VMware vSphere, Microsoft Hyper-V and XenServer). It supports Windows Server, Linux, IBM AIX  and Solaris. It supports major enterprise applications like Exchange, SQL, Oracle, SAP and Sharepoint.

One of the software solutions of InMage is Scout. Scout is storage agnostic and allows to replicate virtual machines as well as physical servers to a target location. This can be either a secondary datacenter, to a cloud provider like Azure or to a Managed Service Provider datacenter. InMage has many Service Provider customers in the US. For example SunGuard. Cisco uses InMage Scout in its blueprints which can be used by partners building DRaaS solutions. InMage partners with HP, Hitachi and Fujitsu which provide DR services.

Scout current version is 7.1.

The solutions are offered in three form factors: software, a hardware and as Software as a Service.

Scout will be integrated in the current Microsoft Azure service called ‘Azure Site Recovery’ which is in Preview at the moment.

Besides the support for all major hypervisors a very interesting feature of InMage Scout is the ability to covert hypervisor virtual machine disk formats. So a VMware customer can protect their virtual machines running on vSphere  (which uses  VMDK format) to Microsoft Azure which uses Hyper-V .VHD virtual disks.

Also for example an Amazon customer can easily migrate virtual machines to Azure using InMage Scout.

In this  blogpost,  Takeshi Numoto – Corporate Vice President, Cloud and Enterprise Marketing , states

This acquisition will accelerate our strategy to provide hybrid cloud business continuity solutions for any customer IT environment, be it Windows or Linux, physical or virtualized on Hyper-V, VMware or others. This will make Azure the ideal destination for disaster recovery for virtually every enterprise server in the world. As VMware customers explore their options to permanently migrate their applications to the cloud, this will also provide a great onramp.

Microsoft has two main goals by the acquistion of InMage:

  1. attract Microsoft customers to Microsoft Azure
  2. attract VMware and other non Hyper-V customers to Microsoft Azure. VMware has a large installed base but not every VMware customer can afford a secondary datacenter. Especially in Europe there are not many Service Providers offering a mature Disaster Recovery as a Service offering. VMware itself only recently introduced its vCHS-DR service.

It is interesting to see how the currently in Preview service ‘Azure Site Recovery’ (ASR) will mature now InMage has been acquired. ASR support is limited to Hyper-V virtual machines running on-premises. It provides some orchestration features but is limited in out of the box post-processing of failover of virtual machines. For example changing IP addresses needs to be scripted. It is not unlikely development of ASR will change course.

Technology
InMage Scout uses agents which are installed in a source server (physcial or virtual server). This agent copies every write to disk and sents it to a software appliance called the InMage Scout Server. I understand this can be either a virtual machine (called the Process server) or a hardware appliance 

This appliance has two functions:

  • -a backup function. It stores backup data on disk.
  • -a disaster recovery function. It replicates data to a secondary site or to the cloud. It does compression and encryption as well.

In the secondary location there is a virtual appliance as well which is used to process the replicated data. It stores the replicated virtual disks on storage. Replica’s of virtual machines do not have to be powered on during the replication. This is very usefull as it does not consume compute and memory resources thus lowering costs.

At failover or failover testing virtual machines are created and started.

Conclusion

The acquisition of InMage is a very interesting one. Many see Disaster Recovery as a Service as a  first step for organizations to embrace cloud computing. Now DraaS is open for any enterprise, also non Hyper-V customers. The barrier for using DRaaS is lowered now.