Elczar Adame's Shared Points on SharePoint

Archive for October, 2007

WCF in Windows Server 2008 – Part I


WCF in Windows Server 2008

Part I of II : HTTP Transport


This piece intends to share with the community an elemental and high-level thought on Windows Communication Foundation in Windows Server 2008. It is composed of two parts, where Part I focuses on HTTP transport, and Part II focuses on non-HTTP transports implementation.

Application Server Foundation

Application Server Foundation, or also known as Application Server Core, is constituted of Application Server technologies provided in Windows Server 2008. The Application Server Core adjoins Microsoft .NET Framework 3.0, in addition to the baseline of .NET Framework 2.0. As an expanded server role that offers an integrated environment for business application, the Application Server is a composite of the following components:

1.    Windows Communication Foundation (WCF)

2.    Windows Workflow Foundation (WF)

3.    Windows Presentation Foundation (WPF)

Windows Communication Foundation is drawn to put forward a unified programming shape to intercommunicate and interoperate with other applications through a new service-oriented programming model. Moreover, Windows Workflow Foundation is the programming model and engine for developing workflow-enabled applications, while Windows Presentation Foundation is designed for building Windows smart-client applications.

Windows Communication Foundation

Windows Communication Foundation is a runtime and a set of APIs designed for sending and receiving messages across applications. As we have mentioned, it is a service-oriented programming model for intercommunication and interoperation with other systems, and considered as a great facilitator of SOA.

Based on concept of message-based communication, the Windows Communication Foundation is architecturally layered into contract, service runtime, messaging, activation and hosting.

To appreciate these layers, we need to put into consideration that communication in Windows Communication Foundation happens through endpoints. An endpoint contains of address, binding, and contract. An address is a network location where the endpoint is located, a binding defines how the endpoint communicates, and a contract defines what the endpoint is communicating.

In the topmost layer of Windows Communication Foundation are the Contracts. This layer provides a high-level APIs including data contract, message contract, service contract, and the policy and binding of our service, where the data contract defines the message parameter, the message contact characterizes every message part, the service contact delineates the service method signature, and the policy and binding specifies the rules of communication. Being defined in XSD document, every message parameter of a service can be exposed to or consumed by any system that understands XML.

The Service Runtime defines the runtime behavior of the service, including throttling behavior, error behavior, metabase behavior, instance behavior, message inspection, transaction behavior, dispatch behavior, concurrency behavior, and parameter filtering of the service.

While a service message is communicated between endpoints, the Messaging stratum is composed of channels, also know channel stack, that processes this message. Zooming in on this layer, we have the transport protocols (HTTP, TCP, PIPE, and MSMQ), encoding (Binary, MTOM, Text, and XML), security and reliability (WS-Security, and WS-Reliability).

Lastly, a service could be a self-hosted service or can be hosted by an agent, the Internet Information Services. In its Hosting and Activation architectural layer, a WCF application is also designed run as an executable, a Windows service, or a COM+ component.

WCF and IIS 7.0

In hosting a distributed application built in Windows Communication Foundation, we need the services of Internet Information Services 7.0. The IIS 7.0, as the Web server of Windows Server 2008, employs Windows Process Activation Service (WAS) to facilitate activation and communication over network protocols supported by WCF – e.g. HTTP, NET.TCP, NET.PIPE, and NET.MSMQ.

For a brief paper on Internet Information Services 7.0, please click here.


To complete this piece, we are going to walk in the course of HTTP implementation and we will attempt to ponder on non-HTTP implementation on my subsequent post. With the following considerations, we will be creating a WCF Service that defines our business logic and a WPF Windows Application that references our service.

1.    We have installed Application Server and Web Server roles on our Windows Server 2008.

2.    We have activated the IIS 6 Metabase Compatibility service of our Web Server.

3.    For our purpose, we will be using the default components of WCF Service and Windows Application (WPF) templates in Microsoft Visual Studio 2005 as installed through WCF and WPF extensions.


Now, we will start by creating our WCF Service.

1.       Let us open our Microsoft Visual Studio 2005. Start > All Programs > Microsoft Visual Studio 2005 > right-click Microsoft Visual Studio, then click Run as Administrator.

2.       To create our WCF Service, let us click File > New > Web Site.

3.       In the New Web Site dialog box, let us select WCF Service template, and our location to http://localhost/WCFService.  Below is the illustration.




4.       If you have not installed some of necessary Application Server and Web Server services, you will be prompted by a message as illustrated below.





5.       Our WCF Service consists of contact, an interface class, and a configuration file that defines the services and service behaviors. And to make it personable, we will edit some items as:


In the Service.cs file:


public interface IService



    string Operation(string Value);


    string DataOperation(Profile Value);



public class Service : IService


    public string Operation(string Value)


        return "Hello: " + Value;


    public string DataOperation(Profile Value)


        return "Hello: " + Value.FirstName + " " + Value.LastName;




public class Profile


    string firstname;

    string lastname;



    public string FirstName


        get { return firstname;}

        set { firstname = value;}



    public string LastName


        get { return lastname;}

        set { lastname = value;}




In the Service.svc file:

<% @ServiceHost Language=C# Debug="true" Service="Service" CodeBehind="~/App_Code/Service.cs" %>


In the web.config file:



      <service name="Service" behaviorConfiguration="returnFaults">

        <endpoint contract="IService" binding="wsHttpBinding"/>





        <behavior name="returnFaults" >

          <serviceDebug includeExceptionDetailInFaults="true" />

              <serviceMetadata httpGetEnabled="true" />





6.       Now its time for us to build of service. If it is successfully built, let us browse http://localhost/WCFService/Service.svc and we expect a page, as illustrated, that notifies us the metabase publishing for this service is currently disabled.


7.       To enable the metabase publishing of our service, we need to add <serviceMetadata httpGetEnabled="true" /> inside the <system.serviceModel> tag of our configuration file. It would result as



        <behavior name="returnFaults" >

          <serviceDebug includeExceptionDetailInFaults="true" />

              <serviceMetadata httpGetEnabled="true" />




8.       By browsing again our WCF service at http://localhost/WCFService/Service.svc, we will notice that it is already ready to be referenced.


At this time, as the final step, we will create our WPF Windows Application that references our WCF Service.

1.       Let us open our Microsoft Visual Studio 2005. Start > All Programs > Microsoft Visual Studio 2005 > right-click Microsoft Visual Studio, then click Run as Administrator.

2.       To create our WCF Service, let us click File > New > Project.

3.       In the New Project dialog box, let us select Windows Application (WPF) template, and name it WPFClient. Below is the illustration.

4.       Then, we will add a service reference pointed to the WCF Service we have created. Right-click our solution in the Solution Explorer, then click Add Service Reference. Write http://localhost/WCFService/Service.svc  in the Service URL  and name it Proxy. Below is the illustration.




9.       Add Button and name it as ButtonRetrieve.

10.  In our XAML file, let us add Click="ButtonClick" inside our <Button> tag.

11.   Lastly, we will add this method in the xaml.cs file of our WPF application:


void ButtonClick(object sender, RoutedEventArgs e)


       WPFClient.Proxy.ServiceClient service = new WPFClient.Proxy.ServiceClient();

            string Message = service.Operation("Paul");





12.   Let us build our application and we will have a WPF application that consumes a WCF service.

And that’s it. Hope to share you something.

Invalid Configuration Data in IIS 7.0: A Security Stuff


Invalid Configuration Data in IIS 7.0: A Security Stuff


HTTP Error 500.19 – Internal Server Error. The request page cannot be accessed because the related configuration data for the page is invalid. Have you encountered this in hosting your Web application in Web Server (IIS 7.0) role of Windows Server 2008? Let us start with an illustration.


Invalid Configuration Data


This is a security matter and not an issue! The Internet Information Services 7.0 lucidly communicated that it can’t read the configuration file of our Web application. It is because of the following:

1. We are using Anonymous Authentication access. Below is the illustration:



2. Our Web application file is located in our user’s folder – e.g. Documents > Visual Studio 2005 > Projects – where only the owner has an access. Below is the illustration.



With this, I would recommend to put our Web application files in C:\inetpub\wwwroot directory where permission is granted to USERS and/or IIS_IUSRS by default – or any directory where you can afford to grant such permission. Together with this, we could now browse our Web application hosted in IIS 7.0.


Hope to share with you something.

Web Server in Windows Server 2008


Web Server in Windows Server 2008

Internet Information Services 7.0 in Windows Server Code Name “Longhorn” revolutionizes the Web server architecture by providing us the following augmentations:

1.    Windows Process Activation Services (WAS) that empowers our site to employ HTTP/HTTPS and non-HTTP protocols.

2.    Modular architecture that allows us to include and exclude modules as needed.

3.    Integrated platform with ASP.NET, Windows Communication Foundation, and Windows SharePoint Services.

What is more, these architectural innovations assure us of utmost compatibility with our existing application – e.g. ADSI, ASP .NET applications, ISAPI extensions, et al.

In this piece, I will be deliberating on Windows Process Activation Services, and Modular Architecture with ASP.NET integration. Then again, I’ve posted a brief piece on Windows SharePoint Services integration at http://elczara.spaces.live.com/blog/cns!554EC06D366AC9D5!220.entry.

Windows Process Activation Services

By eradicating the dependency on HTTP, Windows Process Activation Service model simplifies the Internet Information Services architecture. It is the process activation service of IIS 7.0 to support both HTTP and non-HTTP transports, including TCP, Named Pipes, and MSMQ. What is more, it provides management services of application pool configuration and worker process in the entire IIS 7.0 request processing.


Figure 1. Windows Process Activation Services as a required feature for IIS 7.0.

In the entire request-processing-response servicing, IIS 7.0 takes benefit of several components. These include Windows Process Activation Services, World Wide Web Publishing Service (W3SVC), Listener Adapters, Protocol Listener, and Worker Process.

At this instant, to appreciate the enhancement made in IIS 7.0 through WAS, we will initially give a glance on the process on IIS 6.0 in worker process isolation mode.

1.    Upon receipt, the HTTP protocol stack (HTTP.sys) validates the request. If valid, the HTTP.sys verifies the requested content type. Else, it will notify the client.

2.    If the requested content is static, a response will immediately be served to the client. Else, the HTTP.sys verifies the presence of response in the kernel-mode cache.

3.    If the response is in the cache, HTTP.sys will immediately provide the response. Else, the same request will be placed in queue.

4.    If the queue has no corresponding worker process, the HTTP.sys informs the WWW Service to initialize one. With this, the worker process processes the request.

5.    The Worker Process sends the response to HTTP.sys, and the later sends it the client.


With the birth of IIS 7.0, however, the paradigm has sifted to WAS-centered architecture. Below is the tabular presentation of the process:



Protocol Listener

Listens for incoming protocol-specific request. It may be HTTP, NET.TCP, NET.PIPE, or NET.MSMQ request. Moreover, HTTP.sys remains the listener for HTTP request.

Windows Process Activation Service

Reads information from applicationHost.config file and passes it to listener adapters.

Listener Adapter

Based on the information received from WAS, it pulls request from the application pool queue and passes it to corresponding process protocol handler. However, if no corresponding application pool employed for the request, the WAS will initialize one. Moreover, w3svc provides the listener adapter for HTTP request.

Process Protocol Handler

Channels request through the service model of a particular protocol for processing. Note that WWW Services is no longer administering the worker process.

 Modular Architecture

Internet Information Server 7.0 is a lightweight server core with several pluggable features, known as modules. Thus, they could be included into or excluded from this core as needed. A module is either a Win32 DLL or a .NET 2.0 type included within an assembly. The former is called native module while the later is called managed module. Moreover, these modules can be replaced by a custom module developed in IIS 7.0 C++ APIs, or ASP.NET 2.0 APIs.


Figure 2. Modules feature view in IIS 7.0 Manager.

With this architecture, we can take advantage of:

1.    Minimized attack surface area and memory trail by adding only modules that are needed.

2.    Integrated IIS and ASP.NET features that once were duplicated.

3.    Availability of ASP.NET features to all request type.

With this model, ASP.NET is no longer employed with our Web server as a standalone application framework. It serves by now being a platform for extending the IIS Web server, facilitating ASP.NET components to turn into constituents of the IIS request processing pipeline. Hence, ASP.NET services can now apply to any content type including ASP pages and PHP pages.

Figure 5 Integration with ASP.NET in IIS 6.0 and IIS 7.0 (Click the image for a smaller view)

Moreover, with the innovated configuration store of IIS 7.0, we have the leverage to examine these modules by opening the <globalModules> and <modules> elements of the configuration file located in (%windir%\System32\inetsrv\config\applicationHost.config where the former defines the server level modules or global modules, and the later delineates the enabled modules for all applications on the server.

Native Modules    




Allows us to access any public content without providing a credential.


Requires us to provide a credential to access content. It transmits unencrypted base64-encoded passwords across the network.


By mapping the SSL client certificate to an Active Directory account, it facilitates usage of client certificate for authentication.


Lets us define how our Web server passes information to an external program.


Implements validation of configuration.


Aside from implementing the IIS 7.0 detailed error feature, it allows us to customize the error messages returned by our Web server.


Provides us support to tailor logging format of Web server activity footed on our needs.


Lets us configure the default file for the Web server.


Employs by submitting hashed password to the Windows domain controller.


Employs browsing of our Web server directory.


Implements HTTP compression of dynamic content.


Implements tracing of failed requests to diagnose our Web application.


Supports FastCGI, which offers a high-performance option to CGI.


Takes up the IIS 7.0 output caching and the HTTP.sys caching process.


Affords us to log our Web site activity.


Implements support to redirect user request to a defined destination.


By mapping the SSL client certificate to a Windows account, where credential and mapping rules are maintained within the IIS configuration store, it facilitates usage of client certificate for authentication.


Permits us to allow or deny request from a specific IP address and domain name.


Implements support for files that extend IIS functionalities, knows as ISAPI filters.


Implements support for Web content using ISAPI extensions.


Carries out protocol-based actions – e.g. setting response headers and redirecting headers based on configuration.


Employs screening of requests to our server based on defined rules.


Server Side Includes (SSI) facilitates dynamic generation of HTML pages.


Implements HTTP compression of static content.


Employs publication of static Web file format in our server.


Allows us to define access restriction rules to our Web content. It could be bound to users


Works only in an intranet environment leveraging our Windows domain security implementation.

Managed Modules


Implements configuration of anonymous identification for application authorization.


Makes sure the presence of an authentication object.


Employs verification of user permission to access the file requested.


With the aid of Forms Authentication Provider, it lets us implement client registration and authentication at the application level.


Stores the contents of a processed ASP.NET page in memory which allows ASP.NET to send a page response without going through the page processing lifecycle.


Correlates information with a specific user and accumulates the information in a standard format.


Aids us to manage authorization, granting us to define user access in the resources of our application.


Since HTTP is a stateless protocol, it enables us to store and retrieve values across different Web pages.


Implements verification of user permission to access the URL requested.


Facilitates mapping of URL displayed to user to the URL of a page in our Web application.


With the aid of Windows Authentication Provider, it implements Windows authentication in conjunction with IIS authentication to secure ASP.NET applications.

WSS 3.0’s IIS 7.0 Role Services


WSS 3.0’s IIS 7.0 Role Services


In my preceding blog on WSS 3.0 in Windows Server® Code Name “Longhorn”, we have mentioned that installing WSS 3.0 role includes installation of Web Server (Internet Information Services 7.0) role and other features – e.g. .NET Framework 3.0, Windows Internal Database, and Windows Process Activation Service. As illustrated below, this is apparent during our installation.


Internet Information Services (IIS) 7.0 is the Web Server for Windows Server 2008. Not to mention that Windows Vista has also features depending on version, it provides all the features and services needed to host web applications. As compared to IIS 6.0, the Web server has been redesigned in IIS 7.0 with new components:

1.     A novel service, Windows Process Activation Service (WAS), which enables sites to use protocols other than HTTP and HTTPS. It manages application pool configuration and worker processes instead of WWW Service. Thus, we can run WAS without WWW Service if you do not need to listen for HTTP requests in HTTP.sys.

2.     A Web server engine that can be customized by adding or removing web server modules.

3.     Integration of request-processing pipelines from IIS and ASP.NET.


With its modular architecture, IIS 7.0 provides fundamental modules/role services for Windows SharePoint Services 3.0. It could be categorized as:

            1. Web Server

                        1.1. Common HTTP Features

                        1.2. Application Development

                        1.3. Health and Diagnostics

                        1.4. Security

                        1.5. Performance

            2. Management Tools

                        2.1. IIS Management Console

                        2.2. IIS 6.0 Management Compatibility



Common HTTP Features


Static Content

Allows our WSS 3.0 web server to publish static web file formats.

Default Document

Allows configuration of the default page of our SharePoint site.

Directory Browsing

Allows browsing of the content of our SharePoint site directory. By default, it is disabled.

HTTP Errors

Since our SharePoint site is running in classic mode, custom errors apply only to non ASP.NET content.


Application Development



Provides a server-side object-oriented programming environment necessary of our SharePoint site. These are ASP.NET resources that are directly available to deliver for WSS 3.0 – e.g. Pages and Controls, Connection String, Providers, et al.

.NET Extensibility

Allows changes, additions, and extensions of web server functionality in the request pipeline, the configuration, and the user interface.

ISAPI Extensions

Supports dynamic web content development using Internet Server Application Programming Interface (ISAPI) extensions. For our SharePoint site, we have: aspnet_isapi.dll, author.dll, admin.dll, shtml.dll, and owssvr.dll.

ISAPI Filters

Gives support for web application that uses ISAPI filters. It is a program that enhances our WSS 3.0 server behavior. It receives every HTTP request made to our WSS 3.0 server to provide supplementary functionalities – e.g. logging request information, user authentication and authorization. Our SharePoint site, by default, implements aspnet_filter.dll.


Health and Diagnostics


HTTP Logging

Grants logging of our SharePoint site activity. By default, it is logged at %SystemDrive%\inetpub\logs\LogFiles with W3C format. This is in addition of the usage event logging in Windows SharePoint Services 3.0 at \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs path.

Logging Tools

Provides infrastructure to manage our WSS 3.0 server logs and automate common logging tasks.

Request Monitor

Provides infrastructure to monitor our SharePoint site health. Thanks to the Runtime Status and Control API (RSCA).


Provides infrastructure to diagnose and troubleshoot SharePoint site. With specificity to Failed Request Tracing, it disabled by default and configured to %SystemDrive%\inetpub\logs\FailedReqLogFiles directory with 50 maximum number of trace files.


Below is an illustration of the requests for the worker process.





Basic Authentication

Requires that users provide a valid user name and password to access our SharePoint site. It works across firewalls and proxy servers, but it transmits unencrypted base64-encoded passwords across the network.

Windows Authentication

Works only in an intranet environment. We can use the Windows domain security implementation already in place to authenticate client connections to our SharePoint site. It is our default authentication setting.

Forms Authentication

ASP.NET forms-based authentication works well for our SharePoint site on public web servers that receive numerous requests.

Request Filtering

With incorporation the core features of URLScan into a module called Request Filtering and additional feature called Hidden Segments, it screens all incoming requests based on configured rules – e.g. double-encoded requests filtering, high-bit-characters filtering, file extensions filtering, et al.


Below is an illustration of authentication feature view in IIS Manager.





Static Content Compression

Provides infrastructure to configure HTTP compression on static content of SharePoint site. This is for effective bandwidth utilization, and to provide faster transmission times between IIS and compression-enabled browsers.

Dynamic Content Compression

Provides infrastructure to configure HTTP compression on static content of our SharePoint site.


Below is an illustration of compression feature view in IIS Manager.



Hoping to contribute something…Thanks…



WSS 3.0 in Windows Server 2008 Beta 3

WSS 3.0 in Windows Server 2008 Beta 3

I’ve been exploring Windows Server 2008 Beta 3 and WSS 3.0 to contribute in the Windows Server 2008 Insiders group of MS Philippines.

With the following considerations, do you want to join me in walking through its basic installation process?

a. Installation of Windows SharePoint Services 3.0 fails if it is done together with other Role that requires restart.
b. Reinstallation of Windows SharePoint Services 3.0 fails if it is uninstalled using Server Manager.
c. Access to create Web Application through SharePoint 3.0 Central Administration is denied.

1. To start, we will open our Server Manager. Click Start, point to Administrative Tools, then click Server Manager. Below are the illustrations.

2. In the Server Manager, let us select Roles, then Add Roles. As illustrated below, we will be prompted by the Add Roles Wizard.

3. Along the wizard steps, we will select Windows SharePoint Services 3.0 as the role to be installed.

NOTE: Installation of WSS 3.0 role includes installation of Web Server (IIS 7.0) role and other features – e.g. .NET Framework 3.0, Windows Internal Database, and Windows Process Activation Service.

4. As illustrated below, we are expected to have Web Server (IIS) and Windows SharePoint Services in our Roles Summary list.

5. And finally, browse http://Server Name/ and we will have our Team Site running in Windows Server 2008 Beta 3.

Let me inform you once these known issues are resolved. Thanks.

Tag Cloud