Windows Services inside Windows Azure Platform

After running the following command line in Windows Azure,

net start

Following running services are returned.

These Windows services are started:

   Base Filtering Engine
   Certificate Propagation
   Cloud Drive
   CNG Key Isolation
   COM+ Event System
   Cryptographic Services
   DCOM Server Process Launcher
   DHCP Client
   Diagnostic Policy Service
   Distributed Link Tracking Client
   Distributed Transaction Coordinator
   DNS Client
   File Server Resource Manager
   Group Policy Client
   Hyper-V Guest Shutdown Service
   Hyper-V Time Synchronization Service
   IKE and AuthIP IPsec Keying Modules
   IP Helper
   IPsec Policy Agent
   KtmRm for Distributed Transaction Coordinator
   Network List Service
   Network Location Awareness
   Network Store Interface Service
   OS Diagnostic Service
   Plug and Play
   RdAgent
   Remote Access Connection Manager
   Remote Procedure Call (RPC)
   Remote Registry
   Secondary Logon
   Secure Socket Tunneling Protocol Service
   Security Accounts Manager
   Server
   Software Licensing
   System Event Notification Service
   TCP/IP NetBIOS Helper
   Telephony
   Terminal Services
   Terminal Services Configuration
   Terminal Services UserMode Port Redirector
   User Profile Service
   Virtual Disk
   Windows Error Reporting Service
   Windows Event Log
   Windows Firewall
   Windows Management Instrumentation
   Windows Remote Management (WS-Management)
   Windows Time
   Workstation

The command completed successfully.

Looks familiar? Sure, because the operating system currently running in an Azure Instance is Windows Server 2008. It is not strange to see so many old faces here. Nevertheless, there are some new services, such as "Cloud Drive", "OS Diagnostic Service" and "RdAgent", with corresponding processes namely clouddrivesvc.exe, osdiag.exe and rdagent.exe.

The functionality of "OS Diagnostic Service" is quite straight forward according to its name. But for other two services? Who knows?

The Windows Version Number in Windows Azure Platform

I finished a prototype of performance monitoring system yesterday. One of its functions is to query the version number of running systems.

So then it returns:

Microsoft Windows [Version 6.0.6002]

According to the version number given, the possible Windows system in Windows Azure Platform should be either Windows Vista or Windows Server 2008. Obviously, as a server operating system, it is unlikely to be Windows Vista. Therefore, it is for sure that an Azure Instance runs Windows Server 2008 in it.

It is interesting that the newest server version, Windows Server 2008 R2, does not sit inside Windows Azure Platform. Is the Azure Team also waiting for the Service Pack 1 of Windows Server 2008 R2? To make sure that the new system is safe enough?

Provisioning on Existing Cloud Platforms

Forward: I participated in a book chapter writing in last month. The book chapter is about cloud provisioning. And the following are some paragraphs prepared for that chapter.

Prominent cloud platforms, including Amazon Elastic Compute Cloud (EC2), open source platform Eucalyptus, Microsoft Windows Azure, Google App Engine and GoGrid Cloud Hosting offer a variety of services to their users for monitoring, managing and provisioning resources. Amazon EC2 offers three services namely Elastic Load Balancer, Auto Scaling and CloudWatch. Eucalyptus uses a hierarchical controller structure. Windows Azure implements a service called Azure Fabric Controller. GoGrid Cloud Hosting provides a service named F5 Load Balancer. Google App Engine supports scalable technology that all Google applications are based on.

All five cloud platforms are able to do load balancing, provisioning and auto scaling to some extent. But the way of achieving the provisioning goals varies. Some platforms can be managed automatically; some are just on a half way to the goals; some are totally accomplished behind the scenes; while some have to do all staffs manually.

Amazon Elastic Compute Cloud

Elastic Load Balancer, Auto Scaling and CloudWatch are three web services used in Amazon EC2 to achieve the goal of resource provisioning. Elastic Load Balancer is in charge of delivering incoming connections across multiple Amazon EC2 instances automatically. It pays close attention on health conditions of instances, rerouting traffic from faulty instances to faultless instances within a single availability zone or across multiple zones. Auto Scaling is used to scale the number of Amazon EC2 instances up or down when demand spikes or subsides respectively, according to pre-defined conditions. The last service among three, CloudWatch, is responsible for monitoring cloud resources, for instance Amazon EC2 and Elastic Load Balancer, in real-time. It provides developers with detailed metrics related to instances’ resource utilization, operational performance, network traffic and etc.

Furthermore, Amazon CloudWatch metrics is also a fundament of enabling Elastic Load Balancer and Auto Scaling services, because decisions of provisioning by Elastic Load Balancer and scaling by Auto Scaling are made based on the collected metrics data. Although three services are published separately, all functions of three services in Amazon EC2 are strictly supported via APIs of WSDLs which enable simplicity and possibility of SOA-based integrations of services.

Eucalyptus

Eucalyptus is an open source cloud platform which is compatible in frontend with Amazon EC2 API, but implements a totally different design structure in backend. The system is composed of three controllers to control the virtualization environment in a manner of centralized and hierarchical structure. The three controllers from bottom to up are Node Controller, Cluster Controller and Cloud Controller, respectively being in charge of managing physical resources for virtual machines, coordinating Node Controllers in the same availability zone, processing connections from external clients and administrators.

Among three controllers, the Cluster Controller is a key component of provisioning and load balancing. Each Cluster Controller sits in head node of a cluster to form an availability zone, linking outer public networks and inner private networks together. By monitoring state information of instances in the pool of Node Controllers, it determines the flow of incoming connection to the first Node Controller which has enough free resources to process. But so far Eucalyptus still lacks of some functionality, such as auto scaling, live migration and build-in scheduler.

Microsoft Windows Azure

Azure Fabric Controller is a highly redundancy tolerance service designed for monitoring, maintaining and provisioning machines to host the applications that developers created and stored in Windows Azure, sitting inside Windows Azure Fabric. Fundamentally, Windows Azure Fabric has a weave-like structure that is composed of nodes (servers and load balancers) as well as edges (power, Ethernet and serial communications).

The Fabric Controller supervises nodes in Windows Azure Fabric by different approaches depending on node types. If it is a node of a hardware load balancer, despite potential brands and devices it could be, the balancer is driven by the Fabric Controller through a custom driver which is implemented from an Azure supported driver model for compatibility purpose. If a node is marked as a server, a build-in service, named Azure Fabric Controller Agent, runs in the background, tracking the current state and the goal state of the server, communicating with Azure Fabric Controller. With the reported states from the server, the Fabric Controller can promote it from the current state to the goal. If a fault state is reported by the Agent, the Fabric Controller can manage a reboot of the server or a reprovisioning of running applications from the current server to other servers.

Besides managing servers and load balancers on nodes, the Fabric Controller is also in charge of resource provisioning by supporting a declarative service model. Declarative service specifications is appointed in every application, while the Fabric Controller look through Azure Fabric to match resources that meet required demands of CPU, bandwidth, operating system, redundancy tolerance and etc. However, most of these promised configurations are not available right now. Only some fixed templates are allowed in current CTP version.

GoGrid Cloud Hosting

GoGrid Cloud Hosting offers developers up to three F5 Load Balancers for each account to distribute Internet traffic across servers, as long as IPs and specific ports of these servers are attached into the load balancers. The load balancer follows two algorithms to route connections. Round Robin algorithm serves incoming traffic to servers one after another by taking turns in an equally distributed fashion. And Least Connect algorithm keeps routing incoming messages to the server that maintains least connection sessions. If the load balancer detects a server crashing happened, all upcoming connection traffic will bypass the crashed server, and redirect to other remaining servers.

So far, GoGrid Cloud Hosting only gives developers a programmatic way to facilitate auto scaling through GoGrid API, but there is no common solution provided by GoGrid, like Amazon Auto Scale does. Developers have to write a piece of codes to collect usage data, and run/close servers or migrate up to a new larger server based on collected data.

Google App Engine

Unlike other cloud platforms, Google App Engine offers developers a scalable platform in which applications can run, rather than giving a highly customized virtual machine. Therefore, accessing to the underlying operating system is restricted in App Engine. And all tuning of load balancing, resource provisioning and auto scaling are managed by the system behind the scenes.

Running Samples of Geneva Beta 2 in Windows 7

As the official website advised, Microsoft code name "Geneva" is an open platform that provides simplified user access and single sign-on for on-premises and cloud-based applications in the enterprise, across organizations, and on the Web. Currently the newest version is Beta 2, released on Aug. 18, 2009, about two months later than the release of Windows 7. So when my colleague, Yang, tried to make its samples run in Windows 7 Professional. Some strange errors popped up.

We worked together for a long time to modify setup scripts and authority issues, getting it work eventually. I categorized errors that we came across, and corresponding solutions we made as following.

1. Error in “Run SamplesPreReqSetup.bat”

The script cannot find httpcfg.exe tool in the current running environment.
You can install this by going to the following link

"http://go.microsoft.com/fwlink/?LinkID=100322"
Please ensure that httpcfg.exe is installed in your PATH or the directory this script is running from.

Please press Ctrl-C to stop this batch file

Solution: Change the following line in both SamplesPreReqSetup.bat and SamplesPreReqCleanup.bat:

(ver | findstr /C:"6.0") && set IsVista=true

to

(ver | findstr /C:"6.1") && set IsVista=true

2. HTTP Error 500.19 - Internal Server Error

The requested page cannot be accessed because the related configuration data for the page is invalid.

Error Code: 0x80070005
Config Error: Cannot read configuration file due to insufficient permissions

Solution: Grand the group ‘IIS_IUSRS’ READ permission to ‘Getting Started’ folder.

3. Server Error in '/XXXXXXXXWebApp' Application - Configuration Error

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: ID1024: The configuration property value is not valid.
PropertyName: serviceCertificate
Error: ID1039: The certificate's private key could not be accessed. Ensure the access control list (ACL) on the certificate's private key grants access to the application pool user.

Solution: Find the newest two key files in folder ‘%ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys’, grand the group ‘IIS_IUSRS’ READ permission to these two files.

4. Server Error in '/ XXXXXXXXWebApp' Application - The system cannot find the file specified.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Security.Cryptography.CryptographicException: The system cannot find the file specified.

Solution: Change the application pool to ‘Classic .NET AppPool’ for this application in IIS 7. You can find details of how-to in Change an Application Pool for an Application (IIS 7) .

Migrating Google Page Creator to Google App Engine

Forward: this is an article that I was originally posted in Chinese on April 19th, 2009 before closure of Google Page Creator. Although Google Page Creator has already been deprecated nowadays, the idea of using Google App Engine as a free web server to host static files is somehow still applicable to Blogger users. Therefore, I translated the post into English to share my experience of migrating Google Page Creator to Google App Engine, as well as mapping multi-directory structure into single directory structure to achieve backward compatibility with Google Page Creator by configuring app.yaml.

Google has announced to shut down Google Page Creator in June this year. The disappearance of the free web hosting service brings us an inevitable painful of finding alternatives. As announced, the official solution is Google Page Creator migration to Google Sites. But for those Blogger users who want to host their JavaScript and CSS files for free, Google Sites might not be an appropriate option.

Instead, Google App Engine, a Google cloud hosting platform, is more suitable for hosting those static files, comparing with Google Sites. After all, Google App Engine is designed for automatic scaling according to the number of incoming connections. And the new file storage rule allows the size of a file up to 10MB, and 1000 files in all.

Google App Engine is a powerful service that serves dynamic pages in Python and Java languages. If you want to make a dynamic website run, it is essential to learn programming languages. But for hosting static files, a little knowledge of mapping files and directories to URLs in app.yaml configuration, running test in a local development server and uploading configuration and static files is enough. No specific programming skills are required.

Currently, I hold two Google Page Creator websites, one is alpha.roc.googlepages.com hosting JavaScript demo applications, and another one is alpha0roc.googlepages.com storing scripts, pictures and downloading files. Since Google Page Creator and Google App Engine supports different directory structures, single directory structure and multi-directory structure separately. I plan to adjust various files from a single root directory of one Google Page Creator website into multiple directories under Google App Engine website according to file formats. I also decide to migrate both websites into one Google App Engine website namely alpha0rocdemo.appspot.com, placing alpha.roc.googlepages.com into 'demo' directory (can be directly accessed through an index.html) and relocating alpha0roc.googlepages.com into 'blog' directory (only for hosting resources like pictures and scripts, can only be accessed through exact URL, no index.html). The backward compatibility from the new multi-directory structure to the old single directory structure is managed by app.yaml.

Following content comes from the handlers section of app.yaml, defining the map relationship between URLs and static files.

handlers:
- url: /demo/(.+)
  static_files: demo/\1
  upload: demo/(.+)
- url: /demo/.*
  static_files: demo/index.html
  upload: demo/index.html

- url: /blog/download
  static_dir: blog/download
- url: /blog/(.*\.(gif|png|jpg|ico|css|js))
  static_files: blog/template/\1
  upload: blog/template/(.*\.(gif|png|jpg|ico|css|js))
- url: /blog/(.*)
  static_files: blog/download/\1
  upload: blog/download/(.*)

- url: /.*
  script: index.py

The uploaded files and directories are shown below.

|-- app.yaml # app.yaml configuration file is in the root directory
|-- blog     # Maps to http://alpha0roc.googlepages.com/ website, no 
|   |        # index.html.
|   |        # Adjusts picture and script files from single directory 
|   |        # structure into 'template' directory, and places other 
|   |        # files into 'download' directory.
|   |-- download # Line 09-10 in app.yaml makes sure that requests 
|   |   |        # can access resources through 
|   |   |        # http://alpha0rocdemo.appspot.com/blog/download
|   |   |        # Line 14-16 in app.yaml keeps backward compatibility 
|   |   |        # with Google Page Creator, connections to 
|   |   |        # non-pictures and non-scripts redirect into 
|   |   |        # 'download' directory.
|   |   |-- DatabaseV20070511.accdb
|   |   |-- LineCount.py
|   |   |-- PolaroidsPhotos.atn
|   |   |-- fanfou.v08.py
|   |   |-- fanfou.v09.py
|   |   `-- gongfan2.tar.bz2
|   `-- template # Line 11-13 in app.yaml keeps backward compatibility 
|       |        # with Google Page Creator, connections to picture 
|       |        # and script formats, such as gif, png, jpg, ico, css 
|       |        # and js, go into 'template' directory.
|       |-- author.png
|       |-- bg.jpg
|       |-- blogicon.ico
|       |-- comh3.png
|       |-- commentbck.png
|       |-- cup.png
|       |-- fanfou.js
|       |-- footer-wp.png
|       |-- footer2.png
|       |-- ie60.css
|       |-- listseparator.png
|       |-- logo.png
|       |-- mainmidpart.png
|       |-- maintoppart.png
|       |-- menu2ie.png
|       |-- menu_button2.png
|       |-- quotes.gif
|       |-- recommendation.js
|       |-- righthead.png
|       |-- rssicon.png
|       |-- searchbck.png
|       |-- sidebarbottom.png
|       |-- sidebarmid.png
|       |-- sidebartop.png
|       |-- socialbcklk6.png
|       |-- twinfish_100.png
|       |-- widgetbck.png
|       `-- widgeth2.png
|-- demo     # Matches to http://alpha.roc.googlepages.com/ website, 
    |        # including HTML files.
    |        # Create a directory to hold relevant files for each 
    |        # demo application under 'demo' directory. 
    |-- GongfanAdv   # A new directory of an application. Its original 
    |   |            # access address is, 
    |   |            # http://alpha.roc.googlepages.com/gongfan2.htm.
    |   |            # Create an empty gongfan2.htm page in 'demo' 
    |   |            # directory. Add 'meta refresh' into the page to 
    |   |            # keep consistency to the old address. Accessing 
    |   |            # to the old address is redirected to the 
    |   |            # gongfan2.htm under demo application directory 
    |   |            # 'GongfanAdv'.
    |   |-- favorite.png
    |   |-- geocode.js
    |   |-- gongfan.js
    |   |-- gongfan2.htm
    |   |-- logo.png
    |   `-- mail.png
    |-- gongfan2.htm # A new HTML file added to keep consistency to 
    |                # the old address
    |
    |-- index.html   # Line 05-07 in app.yaml guarantees accessing 
    |                # to index.html
    |
    `-- template     # The original directory name of the template 
        `            # in Google Page Creator is '-'. But in Google 
        `            # App Engine, '-' directory is not allowed to 
        `            # be uploaded. Therefore, 'template' directory 
        `            # is used instead.
        `            # There is only one HTML file applying the 
        `            # template. So I replace the template path 
        `            # inside the HTML file for convince.
        `            # But it should be possible to configure 
        `            # app.yaml to do URL redirect like this:
        `            # url: /-/(.+)
        `            # static_files: demo/template/\1
        `            # upload: demo/template/(.+)
        `-- includes
            `-- style
                `-- lagoona
                    `-- icy
                        |-- 3c-alt-bottom.gif
                        |-- 3c-alt-top.gif
                        |-- body-bg.gif
                        |-- footer-bg.gif
                        |-- h2-bg.gif
                        |-- h3-bg.gif
                        |-- h4-alt-bg.gif
                        |-- h5-bg.gif
                        |-- header.gif
                        |-- hr-bg.gif
                        |-- ollist-bg.gif
                        |-- sidebar-list-bg.gif
                        `-- ullist-bg.gif

After uploading files into Google App Engine, accessing to background pictures, JavaScript and CSS files of this blog are all redirected to alpha0rocdemo.appspot.com. Although Google App Engine limits request numbers and bandwidth for daily use, the quote somehow is enough for most of individual blogs.