As I have committed in my previous posting, http://elczara.spaces.live.com/blog/cns!554EC06D366AC9D5!214.entry, herewith is an update on WSS 3.0 implementation on Windows Server 2008.

SharePoint bit is no longer available in Windows Server 2008 RC1. We need to install it separately as we did before. However, WSS 3.0 without service pack hasv know compatability issue with Windows Server 2008 RC1, thus we need to install WSS 3.0 "with" SP1 slipstream. It is available at:

32-bit Version : http://www.microsoft.com/downloads/details.aspx?FamilyId=EF93E453-75F1-45DF-8C6F-4565E8549C2A&displaylang=en

64-bit Version : http://www.microsoft.com/downloads/details.aspx?FamilyId=9FB41E51-CB03-4B47-B89A-396786492CBA&displaylang=en

Is MOSS 2007 "with" SP1 slipstream already available?

The Service Pack 1 includes the following:

1. Support for Windows Server 2008

2. Support for Internet Information Services (IIS) 7

3. Support for creating Web Parts by using AJAX

4. New operations and properties for the Stsadm command line tool

5. Includes over 60 hotfixes across all areas of SharePoint Products and Technologies

IIS 7.0 Configuration System

Let us step one level higher in our exploration. At the base of Internet Information Services 7.0 in Windows Server 2008, is an innovated and XML-based configuration system is established. Unlike the IIS 6.0 metabase, the entire configuration state is in files and no in-memory configuration store is used. With an administrative protection, the configuration is portable by merely copying it to other Web servers or sharing it. Nevertheless, the same configuration file could now be centrally shared across the Web servers group.

Configuration Levels

The server-wide configuration setting is stored in applicationHost.config file located at %windir%\System32\inetsrv\config directory which could be delegated in the <system.webServer> section of the root web.config file for application level settings. Moreover, the machine.config and web.config files located at %windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG\ directory remain the global configuration settings for .NET Framework and ASP.NET respectively, and the <system.web> section of the root <web.config> continues to provide the application level settings.

Organization of Settings

The configuration file is logically organized by section. A section is an independent group of settings that defines the operation and extensibility of the server or an application. Being an independent unit, it cannot be nested. Below is an illustration:

<applicationPools>

            <add name="DefaultAppPool" />

            <add name="Classic .NET AppPool" managedPipelineMode="Classic" />

            <applicationPoolDefaults>

                <processModel identityType="NetworkService" />

            </applicationPoolDefaults>

</applicationPools>

Sections can be assembled into a section group. But unlike a section, a section group does not define any server nor application operation. Its sole purpose is to hierarchically organize logically-related sections. For this reason, it could be nested for further groupings. In the applicationHost.config, the sections groupings are defined through <configSections>. Below is the illustration:

<configSections>

<sectionGroup name="system.applicationHost">

<section name="applicationPools" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />

…

</sectionGroup>

<sectionGroup name="system.webServer">

      <section name="asp" overrideModeDefault="Deny" />

      …

</sectionGroup>

</configSections>

applicationHost Section Groups

The applicationHost.config, as we have mentioned earlier, contains the server-wide configuration settings/sections that are group into system.applicationHost and system.webServer. The former contains global settings employed by the Windows Process Activation Service, while the later is used by the Web server engine and modules.

Aside from the section groups, we can incorporate a <location> tag in the configuration file. It is often employed for locking and unlocking a configuration section, to manage the application level delegation. It is done by defining the overrideMode value of a specific site. In the illustration below, the default document could not be changed in the root web.config file; otherwise, it would fire an exception.

<location path="Sample Web Site" overrideMode="Deny">

            <system.webServer>

                  <defaultDocument enabled="true">

                        <files>

                              <clear />

                              <add value="default.aspx" />

                        </files>

                  </defaultDocument>

            </system.webServer>

      </location>

Schema and Other Configuration Files

The configuration system is charted by a declarative schema located at %windir%\System32\inetsrv\config\schema directory, including IIS_schema.xml for IIS configuration settings, ASPNET_schema.xml for ASP.NET configuration settings, and FX_schema.xml for other .NET Framework configuration settings. Note that we need not to make any changes on the schema files. However, if necessary for us to create a custom section, we could add a separate schema file on the same directory.

Aside for the applicationHost.xml file, we could experience the presence of administration.xml and redirection.xml configuration files in the %windir%\System32\inetsrv\config directory. The former holds the settings necessary for the Internet Information Services Manager tool, and the later contains settings necessary to point a Web server to a remote/shared configuration files and schema.

 Hoping I have shared something.

IIS 7.0 – ASP.NET Integration

This paper is an attempt to précis the ground-breaking integration of IIS 7.0 and ASP.NET in the Web sever core of Windows Server 2008, emphasizing the significant facets engrossed by the integration, and a demonstration that implements ASP.NET Forms Authentication for non-ASP.NET content types.

Significant Facets

In my paper on Web Server in Windows Server 2008, I have pointed out that ASP.NET is no longer employed with the Web server as a standalone application framework. It serves by now as a platform for extending the IIS Web server, facilitating ASP.NET components to turn into constituents for its request processing pipeline.

In the previous versions of IIS, ASP.NET request is passing through a native IIS processing before it will be forwarded to an ASP.NET ISAPI assembly (aspnet_asapi.dll) for managed code processing. On the other hand, other content types may be accommodated through native IIS request processing, like in the case of static file, or by other ISAPI extensions. Thus, non-ASP.NET requests could not enjoy the ASP.NET managed modules.

In IIS 7.0, however, ASP.NET is no longer implemented as an IIS ISAPI extension. The native process model of IIS and the managed process model of ASP.NET are unified into a sole process model. With the integration of ASP.NET runtime, IIS 7.0 made both native (C++ API) and managed (ASP.NET) modules available to any type of request. In other words, ASP.NET modules are now relevant to any content type including ASPX page, HTML page, and other content types. Additionally, this integration results to a unified modules and handlers configuration. It has eliminated, furthermore, duplication of some strides in the request processing pipeline, such as authentication and authorization.

Demonstration

1.       As we have mentioned earlier, this section will demonstrate the extensibility of ASP.NET Forms Authentication to non-ASP.NET content types. We will start by creating a database using ASP.NET SQL Server Setup Wizard. To do this, let us open our Visual Studio Command Prompt and execute aspnet_regsql. In this demonstration, we will name our database as ASPNETDatabase.

2.    Using Visual Studio 2005, we will create a Web site and call it ASPNETWebSite.

3.    Subsequently, we will add two static files: an HTML page with a title of HTML Page, and an image file.

4.       After that, we will add a Login.aspx page, and we will include a Login control as:

<asp:Login ID="Login1" runat="server"></asp:Login>

5.    To preliminary implement Forms Authentication to our Web application, let us open our web.config file and change the <authentication> mode value from Windows to Forms, then we will add some values to our <authorization> element. The results will be:

<authentication mode="Forms"/>

<authorization>

            <deny users="?"/>

      </authorization>

6.    After completing the previous task, we will open our Intenet Information Services Manager and add a Web site, we will name it ASPNET Web Site, pointing the Content Directory to the location of our Web application.

7.    In the ASP.NET area of our ASPNET Web Site Home, let us do the following:

a.        Set Connection String: Server=ServerName;Database=ASPNETDatabase;User ID=UserName;Password=Password

b.    Add .NET User

8.       Lastly, we will add some values in the <modules> section of our applicationHost.config to make it <modules runAllManagedModulesForAllRequests="true">. It is located at %windir%\System32\inetsrv\config\applicationHost.config.

By default, even though that our application pool is set to Integrated mode, ASP.NET modules are configured with managedHandler precondition. It means that only ASP.NET request will be carried out by managed modules. Now, if we want to employ ASP.NET modules to all our requests, we can write the following in the web.config file of our Web application right after the <configuration> element:

<system.webServer>

            <modules>

                  <remove name="FormsAuthenticationModule" />

<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />

                  <remove name="UrlAuthorization" />

<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />

            </modules>

</system.webServer>

Otherwise, like what we have did in this step, we can set the runAllManagedModulesForAllRequests of the <modules> element to true to shape all managed modules to carry out any type of request notwithstanding of their repective managedHandler precondition.

9.    At this moment, we will notice the following:

a.    A corresponding application pool is created with an Integrated Managed Pipeline Mode. This means the ASPNET Web Site we have created benefits the IIS 7.0 and ASP.NET integration. Thus, ASP.NET forms authentication is functional even to our HTML pages and image file. To explore, you can downgrade it to Classic mode, and browse the site. There you will notice that the HTML page and the image file do not require authentication.

b.    Since our Web application is configured for forms authentication, Forms Authentication component is coordinately enabled in IIS,  and the connection string we have set is automatically reflected in web.config file of our Web application. This underlines the unified configuration results of the integration.

c.    The user we have provisioned is stored in the aspnet_Users table of our ASPNETDatabase.

10. Now, its time for us to explore http://Server Name:Port Number/File Name to appreciate the extensibility of ASP.NET Forms Authentication.

Hoping to share you something.

WCF in Windows Server 2008

Part II of II : non-HTTP Transports 

Groundwork

As we have brought up previously, the objective of this piece is to carve up basic and high-level considerations on Windows Communication Foundation in Windows Server 2008. We have focused on HTTP transport implementation in Part I, and we will hub on non-HTTP transports in this part. Along the demonstration section, we will seek to enhance our previous WCF service and WPF client applications, then we will attempt to put in plain words some of the fundamental codes.

Review

In the previous part, we have given attention on one of the three constituted technologies of Application Server Core in Windows Server 2008, the Windows Communication Foundation. It is a new service-oriented programming model, edged by .NET Framework 3.0, to intercommunicate and interoperate with other applications.

We have also mentioned that in hosting a distributed WCF application in the Internet Information Services 7.0, it entails employment of Windows Process Activation Service (WAS) to facilitate activation and communication over network protocols including HTTP, NET.TCP, NET.PIPE, and NET.MSMQ.

Non-HTTP Transports

In TCP-based communication, the messaging session between machines is established before exchanging data. Each machine is identified through a logical IP address. In the process of delivering a unit of information on a network, the TCP manages the fragmentation of message into packets (a unit of transported information), and the reassembly of the same message from packets. Moreover, the same protocol resends lost packets and guarantees that no data fragment is duplicated.

In the heart of WCF TCP transport is the TCP Port Sharing service. It is a Windows service that allows TCP ports, over Intranet, to be shared across applications that are using WCF for communication. By principle, it is faster than HTTP protocol, but it is no more than for WCF-WCF communication.

A named pipe, on the other hand, is an object in the Windows operating system kernel, including a section of shared memory. It can be employed to grant communication channel between processes on the same computer or between processes on different computers across a network. For WCF, moreover, it is employed using net.pipe schema and ideal for an on-machine implementation of message delivery between WCF applications.

MSMQ, running as an NT service, is one of the features of Windows Server 2008. It is employed by WCF for its queued communication using net.msmq schema. The MSMQ Managers manages message-transfer from a Transmission Queue to a Target Queue. Unlike other transports, queued transport puts into operation the isolation between service, client, and transport. Hence, the transacting parties can fall short without producing an effect on the real communication. Furthermore, it provides reliable communication in spite of failures of the sender and receiver by backing up the message in their corresponding message store.

To endow with consistent communication, MSMQ employs transactional messaging where message is communicated under a transaction. Transaction is a set of operations designed in such a way that if one operation fails, the entire transaction will not be sent to queue.

Additionally, MSMQ provides an asynchronous communication pattern. Hence, the sender needs not to wait for the message to be received and processed by the receiver. Sent message may remain in the Transmission Queue, based on the defined value, until it is sent to the Target Queue. Else, it will be transferred to a Dead Letter Queue.

Demonstration

1.    Primarily, we will verify if non-HTTP protocol is supported. Let us open our Internet Information Services Manager. Click our WCFService site, then click Bindings. In the Site Bindings dialog box we could identify the protocols that are supported.

2.    To complete the configuration, we will open the applicationHost.config file of our IIS at %SystemDrive%\Windows\System32\inetsrv\config directory and add some values to the <enabledProtocols> tag of our Web site. In this case, the results will be:

<site name="Default Web Site" id="1" serverAutoStart="true">

<application path="/WCFService" applicationPool="DefaultAppPool" enabledProtocols="http,net.tcp,net.pipe,net.msmq">

<virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot\WCFService" />     

      </application>

      <bindings>

<binding protocol="https" bindingInformation="*:443:" />

<binding protocol="http" bindingInformation="*:80:" />

<binding protocol="net.pipe" bindingInformation="*" />

<binding protocol="net.msmq" bindingInformation="localhost" />

<binding protocol="net.tcp" bindingInformation="808:*" />

      </bindings>

</site>

NOTE: Enabled Protocols property does not have corresponding user interface in Windows Server 2008 Beta 3.

3.    Now we will open the WCF Service application we have created in Part I.

4.    In the Solution Explorer, let us open the Service.cs file.

Notice that the System.ServiceModel is being referenced. It is the namespace that brings Windows Communication Foundation to existence. As the name suggests, this is what we referred as WCF service model.

Other noticeable attributes that characterizes the service model are the [ServiceContract] annotation for the interface (dispatching) and the [DataContract] annotation for the data definition (serialization).

5.       Let us add a Namespace to our [ServiceContract] attribute and an Action named parameter to our [OperationContract] attribute. The results will be:

[ServiceContract(Namespace="http://tempuri.org/IService")]

public interface IService

{

    [OperationContract(Action="Operation:String")]

    string Operation(string Value);

    [OperationContract(Action="DataOperation:String")]

    string DataOperation(Profile Value);

}

An incoming SOAP message is dispatched to a corresponding method based on the Action attribute of an operation contract. Thus, a message with Operation:String action is identified with Operation method, its target operation contract.

6.       Upon enhancing our service contract, let us as well carry out basic enhancement on our [DataContract] attribute by adding a Namespace named parameter and some named parameters to our [DataMember] attribute. The results will be:

[DataContract(Namespace="http://tempuri.org/Profile")]

public class Profile

{

    string firstname;

    string lastname;

    [DataMember(Name="First", Order=0)]

    public string FirstName

    {

        get { return firstname; }

        set { firstname = value; }

    }

    [DataMember(Name = "Second", Order = 1)]

    public string LastName

    {

        get { return lastname; }

        set { lastname = value; }

    }

}

The data contract is defined for serialization, where the data in the incoming SOAP message is mapped to a corresponding .NET object. In the above code, the SOAP payloads to the .NET string data type. The [DataContract] annotation signifies that we are using the default serialization engine of WCF. This engine serializes fields annotated with [DataMember].

By data contract, WCF service communication is directed through the SOAP body. If required to channel data through header, we can create a message contract and specify the message header and message body fields respectively. To wit:

[MessageContract]

public class Message

{

    [MessageHeader]

    public HeaderMessage HeaderMessage;

    [MessageBodyMember]

    public BodyMessage BodyMessage;

}

7.    The next step is to revisit the service implementation we have made in Part I and do an enhancement on its behavior through [ServiceBehavior] attribute. The results will be:

[ServiceBehavior(Namespace="http://tempuri.org/IService", ConcurrencyMode=ConcurrencyMode.Multiple)]

public class Service : IService

{

    public string Operation(string Value)

    {

        return "Hello: " + Value;

    }

    public string DataOperation(Profile Value)

    {

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

    }

}

8.    Let us open our web.config file and extend our service endpoints to non-HTTP protocols by adding the following <endpoint> attributes to the <system.serviceModel> section of the file:

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

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

Unlike in self-hosting, IIS hosting does not require us to specify the endpoint address because it is already provided by the location of our .svc file.

9.    Lastly, let us to build our enhanced WCFService.

10. Now, let us open the WPFClient Windows application we have created in Part I and update our Proxy service reference. To do this, right-click the Proxy.map file under the Service References folder, then click Update Service Reference.

11. In app.config file, we will notice additional entries for net.tcp and net.pipes protocols in both <bindings> and <client> sections. Since the service contract interface could not be loaded with multiple <endpoint> configuration, we need to select preferred endpoint in the <client> section, then omit the others.

12. With this, we could rebuild and execute our application enjoying various types of communication protocols.

WCF in Windows Server 2008

Part I of II : HTTP Transport

Groundwork

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.

Demonstration

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:

[ServiceContract()]

public interface IService

{

    [OperationContract]

    string Operation(string Value);

    [OperationContract]

    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;

    }

}

[DataContract]

public class Profile

{

    string firstname;

    string lastname;

    [DataMember]

    public string FirstName

    {

        get { return firstname;}

        set { firstname = value;}

    }

    [DataMember]

    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:

<system.serviceModel>

    <services>

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

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

      </service>

    </services>

    <behaviors>

      <serviceBehaviors>

        <behavior name="returnFaults" >

          <serviceDebug includeExceptionDetailInFaults="true" />

              <serviceMetadata httpGetEnabled="true" />

            </behavior>

        </serviceBehaviors>

    </behaviors>

  </system.serviceModel>

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

 <behaviors>

      <serviceBehaviors>

        <behavior name="returnFaults" >

          <serviceDebug includeExceptionDetailInFaults="true" />

              <serviceMetadata httpGetEnabled="true" />

            </behavior>

        </serviceBehaviors>

 </behaviors>

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");

            MessageBox.Show(Message);

  }

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

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.

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

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:

 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    

Managed Modules

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

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

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

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

Hoping to contribute something...Thanks...

Microsoft Office Outlook 2007 Integration

I was once asked: “Is there an offline support for SharePoint lists and document libraries?” Yes there is! Using Microsoft Office Outlook 2007 as our offline client application.

Not to mention that this walkthrough is applicable as well for other SharePoint lists/libraries, we will be focusing on the integration and synchronization of SharePoint calendar with Outlook.

1.       In our Outlook My Calendar, we will create two activities. For our purpose, we will set them as:

a.       Outlook Activity A,  September 20, 2007, 9:00 AM to 10:00 AM.

b.      Outlook Activity B, September 20, 2007, 1:00 PM to 3:00 PM.

2.       In our SharePoint Calendar, we will create an activity. We will set  it SharePoint Activity A, September 20, 2007, 11:00 AM to 1:00 PM.

3.       Now we will start the integration. In our SharePoint Calendar page, click Actions, then Connect to Outlook. We will be transferred to Microsoft Office Outlook 2007 with the Connect this SharePoint Calendar to Outlook dialog box. Below is the illustration.

4.       In the same dialog box, let us click Advanced. We will be prompted by the SharePoint List Options dialog box. Below is the illustration.

5.       For our purpose, we will change the Folder Name to SharePoint Calendar, and leave the Update Limit being checked to update our subscription with the publisher’s recommendation. Then, click OK.

6.       In our Connect this SharePoint Calendar to Outlook dialog box, click Yes. Automatically, our SharePoint Calendar will be integrated in our Outlook under Other Calendars category. Below is the illustration.

7.       In our Outlook menu, let us click Tools, then Account Settings. The Account Settings dialog box will be displayed. Notice that our SharePoint Calendar is already listed in the SharePoint Lists. Below is the illustration.

8.        At rest in the Tools menu, let us point to Send/Receive, then to Send/Receive Settings, then click Define Send/Receive Groups. 

9.       In the dialog box as before, click Edit. The Send/Receive Settings – All Accounts dialog box will be displayed. Under our SharePoint account, as illustrated below, our SharePoint Calendar is included in our Send/Receive Options check list.

10.   To synchronize our SharePoint Calendar with the Calendar in our SharePoint site, let us click Tools menu, point to Send/Receive, then click Send/Receive All.

NOTE:  This is not a synchronization of SharePoint Calendar with Outlook My Calendar.

11.   To copy our Outlook My Calendar to SharePoint Calendar, let us select both Outlook Activity A and Outlook Activity B, the click Edit menu, then click Copy to Folder. The Copy Items dialog box will be displayed. Below is the illustrated results.

12.   In the Copy Items dialog box, under SharePoint Lists, select SharePoint Calendar, then click OK. Below is the illustrated results.

NOTE: The file is located in our C:\Documents and Settings\User Name\Local Settings\Application Data\Microsoft\Outlook directory as .pst file.

NOTE: If you roam Microsoft Office Outlook 2007, the SharePoint List is synchronized into a folder under the proxy .pst.

NOTE:  Any mismatched item will be detached and the original version  will be potted in the Local Failures folder.

13.   Lastly, let us click Tools menu, point to Send/Receive, then click Send/Receive All. Then, let us open our SharePoint site, and there we have a synchronized calendar items.

14.   Yet again, we can do the same Outlook integration with our SharePoint Contacts, Document Library, and Task List. Thanks.

Step 1: Create KPI List
1. on the Report Center, click Site Actions, select View All Site Content, then click Create.
2. Under Custom Lists, click KPI List. Complete necessary information, then click OK.

Step 2: Add KPI to KPI List
1. Click the arrow next to New.
2. Select "Indicator Using Data in SharePoint List" as KPI Type.
3. Complete necessary items on the New Indicator page. Specifically:
 3.1. Under SharePoint List and View, in the List URL box, enter the URL of the list or library.
 3.2. Under Value Calculation, select Number of List Items.
4. Complete applicable items in the Status Icon section.

Step 3: Publish KPI List
1. click Add a Web Part in the zone in which you want to publish the KPI.
2. Select Key Performance Indicators web part to insert the entire KPI List. Or select KPI Details web part to choose one KPI from the KPI List. Then, click Add.
3. In the web part tool pane, configure Indicator List and other applicable items. Then, click OK. 

Microsoft Office SharePoint Designer 2007 makes it straighforward to integrate business workflow/logic through Workflow Designer. The basic steps of creating a workflow are always the same: First you define the workflow, and then you create the rules by choosing conditions and actions.

Before you create a workflow, consider the following:
1. It is attached to a SharePoint list or library.
2. If necessary, custom columns and settings must be configured before you design the workflow.

Step 1: Opening a SharePoint Site
1. On the File Menu, click Open Site.
2. Select a SharePoint site and click Open. The selected SharePoint site will be opened.

Step 2: Opening a Workflow Designer
1. On the File Menu, select New, then click Workflow. The Workflow Designer will be opened.

Step 3: Defining the Workflow
1. Complete the Define Your New Workflow wizard. Then, click Next.
2. Specify the details of your workflow by defining related Conditions and Actions. Then, click Next.
3. To check your workflow, click Check Workflow. Then, click Finish.