The Windows Server AppFabric MP for System Center Operations Manager 2007 SP1/R2 is now available here:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=7e870c9a-0b5b-4cca-8d8c-42a66b8c9741.
The Windows Server AppFabric Management Pack discovers and comprehensively monitors the system components of the AppFabric. Primarily using the event log, the MP will monitor the health of the Event Collection Service, the Workflow Management Service, the Caching Service, and the system databases. The MP will also provide basic monitoring of the WCF and WF services that the AppFabric manages.
Enjoy!
-Adam
We are thrilled to announce the final availability of Windows Server AppFabric!
As announced today at TechEd North America, Windows Server AppFabric is available for download to Windows Server 2008 (and Windows Server 2008 R2) Standard Edition and Enterprise Edition customers.
Additional information on Windows Serer AppFabric can be found at the following locations:
Thank you to everyone who participated in the beta program and provided invaluable feedback – we couldn’t have shipped it without your input.
Happy downloading! - Cliff
Today we are pleased to announce a Beta 2 Refresh for Windows Server AppFabric. This build supports the recently released .NET Framework 4 and Visual Studio 2010 RTM versions—a request we’ve had from a number of you. Organizations wanting to use Windows Server AppFabric with the final RTM versions of .NET 4 and Visual Studio 2010 are encouraged to download the Beta 2 Refresh today. Please click here for an installation guide on installing the Beta 2 Refresh. We encourage developers and IT professionals building ASP.NET applications or applications that use WCF or WF and run on IIS to download the Beta 2 Refresh and provide feedback at http://connect.microsoft.com/dublin/feedback or via our forum at http://social.msdn.microsoft.com/Forums/en-US/dublin/threads/.
Windows Server AppFabric is a set of application services focused on improving the performance and management of Web and Composite applications. To deliver these benefits, Windows Server AppFabric provides distributed caching technology and pre-built management and monitoring infrastructure that utilize familiar .NET skills.
Currently in Beta 2, Windows Server AppFabric enhances the Application Server role in Windows Server and is available as a free download.
When VS 10 RC/.Net Framework 4 RC is installed, the previous version of VS 10 Beta2/.Net Framework 4 Beta2 is uninstalled. If you have Windows Server AppFabric Beta1 installed (Shows up as “Application Server Extensions for .NET4” on the machine that it has been installed), ideally you would uninstall AppFabric Beta1 before uninstalling VS 10 Beta2/.Net Framework 4 Beta2.
If you already uninstalled VS 10 Beta2/.Net Framework 4 Beta2 or upgraded to .Net Framework 4 RC before uninstalling AppFabric Beta1 then uninstall of AppFabric Beta1 will fail, you would need to follow the following steps to uninstall AppFabric Beta1.
AppFabric uninstall requires the following files and you will have to manually create them if they are missing. Note that you may have old_v4.0.21006 folders in your framework directories. Refrain from renaming this directory to v4.0.21006 but instead create new copies of the v4.0.21006 folders.On 32 bit machine:%windir%\Microsoft.Net\Framework\v4.0.21006\config\machine.config%windir%\Microsoft.Net\Framework\v4.0.21006\config\web.config
On 64 bit machine:%windir%\Microsoft.Net\Framework\v4.0.21006\config\machine.config%windir%\Microsoft.Net\Framework\v4.0.21006\config\web.config
%windir%\Microsoft.Net\Framework64\v4.0.21006\config\machine.config%windir%\Microsoft.Net\Framework64\v4.0.21006\config\web.config
The files machine.config and web.config should contain the following line:machine.config:<configuration/>
web.config:<configuration/>
You can also use a simple script to create the files:
@echo off
set OLDDOTNETCONFIGDIR=%windir%\Microsoft.Net\Framework\v4.0.21006\config
if NOT exist %OLDDOTNETCONFIGDIR% (
echo creating config directory
mkdir %OLDDOTNETCONFIGDIR%
)
if NOT exist %OLDDOTNETCONFIGDIR%\machine.config (
echo creating machine.config
echo ^<configuration/^> > %OLDDOTNETCONFIGDIR%\machine.config
if NOT exist %OLDDOTNETCONFIGDIR%\web.config (
echo creating web.config
echo ^<configuration/^> > %OLDDOTNETCONFIGDIR%\web.config
After creating the files with the content specified above, run setup.exe of AppFabric Beta1 to uninstall AppFabric Beta1. You can achieve the same result by uninstalling KB970622 (Application Server Extensions for .NET4) via Uninstall Windows Update in Control Panel.
After unistalling AppFabric Beta 1, be sure to remove the %windir%\Microsoft.Net\Framework[64]\v4.0.21006 directory and its files.
Restart the machine.
Follow these steps only if you are not installing AppFabric Beta2 and would like to make your applications run on .Net Framework 4 RC without AppFabric installed. NOTE: These steps do not cover changes between .Net Framework 4 Beta2 and RC, changes for WCF/WF between beta2 and RC are listed at http://blogs.msdn.com/endpoint/archive/2010/02/10/4-0-beta2-rc-wcf-wf-breaking-changes.aspx
First you need to locate and clean up your applicationHost.config file:
· Under %windir%\System32\inetsrv\config
· Open the applicationHost.config file in notepad
· Search for serviceAutoStartMode and remove all instances of this attribute in application elements
· Search for previouslyEnabledProtocols and remove all instances of this attribute in application elements
Then, the following clean-up steps need to be performed for every web.config file in 2 basic scopes of IIS hierarchy, site and application.
· Search for microsoft.applicationServer and if there is a match, remove the entire section from <microsoft.applicationServer> to </microsoft.applicationServer>
· Search for workflowInstanceControl and if there is a match, remove the <workflowInstanceControl/> element and all of its attributes.
Steps listed below provide details on how to locate the various config files at specific scopes:
1. Clean your site web.config
a. Launch IIS Manager: start->run-> inetmgr (launch IIS manager using %windir%\system32\inetsrv\inetmgr)
b. Locate and select your web site in the left navigation pane (expand the server node, and expand the Sites node)
c. Right click the web site and select Explore
d. Locate the web.config file in the explorer window that opens up (you are done if there is no web.config file in that directory)
e. Open the file in notepad and follow the cleanup steps described above.
f. Repeat for each of the web sites under the sites node.
2. Clean up your application or virtual directory web.config
b. Locate and select your application or virtual directory in the left navigation pane (expand the server node, expand the sites node, and expand your application node)
f. Repeat for each of your applications under each of the sites.
See Also: http://developers.de/blogs/damir_dobric/archive/2010/02/19/uninstalling-of-appfabric-beta-1.aspx
Read all about the new features here or just download it here.
In our previous post, we discussed the topic of Monitoring Applications using Windows Server AppFabric. In this post, we will show how to use the same tools in more advanced ways to troubleshoot problems in your applications.
Introduction
The previous post introduced the AppFabric Dashboard (pictured below). As you can see, it does a good job of giving you a quick view of the state of your WCF and WF services while highlighting potential problems. The AppFabric Dashboard is the starting point for many paths that you can take while troubleshooting. We’ll explore a few of the more common paths to get you familiar with the toolset.
Tracked Events
Most troubleshooting scenarios will require users to examine event data that was captured from the problematic service at the time the problem manifested itself. The dashboard provides several ways to drill down into the relevant event data quickly.
How to Drilldown
AppFabric provides a Tracked Events View that displays event data within IIS manager. This view lets users customize the query that is sent to the monitoring database using common filters. From the dashboard, you can use the Tracked Events Action to see the latest events that have been tracked, and then customize your query. Alternatively, you can click on any of the metrics displayed in the WCF Call History and WF Instance History sections, and a pre-created query will be used to save you time. For example, you could click the Exceptions metric and the resulting query would just show event data that contains exception information.
Using the Main Event List Pane
The main pane within the Tracked Events View displays a table of events that match the current query. The sortable columns in the table provide a high level summary of what the events mean. You can also right click rows in the table to get a context menu that provides useful tasks such as relating an event to a tracked Workflow instance. This is useful when you want to get events from an operation that spanned multiple services, maybe even different machines, as long as they are sharing the same monitoring database.
Using the Details Pane
When an event is selected in the main pane, the Details Pane at the bottom of the view displays information that was captured with the selected event. This includes custom event properties, environment information, tracked variables (for Workflow Services), and Error details (if applicable).
Using the Query Summary
As mentioned earlier, the query that is used to retrieve event data from the monitoring database can be customized. You would do this using the Query Summary control at the top of the Tracked Events View. Using this control, you can filter by several common criteria such as Emit Time, Event Type, End To End Activity Id, and Tracked Variables (Workflow only).
Monitoring Configuration
AppFabric provides a default monitoring configuration that is sufficient for common health monitoring and basic troubleshooting tasks. Sometimes, a more granular level of event data is required to troubleshoot a problem. AppFabric provides a UI tool that lets you modify the monitoring configuration that is stored in web.config files.
Changing the Monitoring Level
From any scope in the IIS hierarchy (Server, Web Site, Application), select the Configure action from within the .NET 4 WCF and WF Action section and then select the Monitoring tab. You can then choose from one of the 5 predefined monitoring levels.
· Off* – No event data is collected
Use this level if you don’t want to pay any overhead for collection event data
· Errors Only* – Only warning and error information is collected
Use this level if you’re not interested in calculating health monitoring metrics, you want optimal performance, but you still want visibility into errors
· Health Monitoring (default) – Collects all information from “Errors Only” as well as lightweight event data that allows the Dashboard’s metrics to be populated.
Use this level if you want a balance between event collection overhead and visibility into the state of your services
· End To End Monitoring – Collects all information from “Health Monitoring” as well as additional events that allow the construction of message flows across distributed service calls.
Use this level if you need to reconstruct the flow of your service(s)’ execution, either for one service or across services.
· Troubleshooting – Collects all available event data, excluding tracked Workflow variables and arguments. Note that to collect this application specific data a custom tracking profile must be used.
Use this level if you need the most detailed information that is available. This is useful when troubleshooting problems that are not immediately obvious.
* NOTE: at OFF and Error levels dashboard metrics will not be fully functional
Configuring Sytem.Diagnostics Tracing and Message Logging
While the tools described above will help you troubleshoot the more common problems, more advanced will warrant more invasive techniques. More detailed log files may be required to diagnose a problem. In this case, a user might want to enable System.Diagnostics Tracing and Message Logging via their configuration files. AppFabric provides a tool that lets you enable and configure these capabilities from within IIS Manager. While on the monitoring tab in the Configure WCF and WF dialog, note the Diagnostic Tracing and Message Logging section. Click Configure. The dialog that appears makes it very easy to configure the level of tracing/message logging, as well as the destination file location(s).
Summary and Additional Resources
In this post, you learned about some of the troubleshooting capabilities built into AppFabric’s IIS Manager Tools. Look for future posts to go into more advanced administration topics that let you use PowerShell and other tools to manage your AppFabric environment.
This post aims to provide you with an introduction into monitoring the health and activity of your WCF- and WF-based applications with Windows Server AppFabric. More specifically, the post will outline the AppFabric tooling features that are built into IIS Manager as well as outline some basic strategies in using these features to monitor your applications.
At the center of AppFabric’s monitoring tools is the Dashboard, which provides a centralized gateway to view the health of WCF and WF services deployed locally or to a server farm. It exposes real-time data for durable WF services and historic data for both WCF and WF services. The Dashboard is designed to provide a holistic summary of all positive and negative metrics on your services in a hierarchical form, starting from a high level and allowing you to drill down incrementally to an atomic level via one of our query-able enumeration pages. Consistent with other IIS Manager features, the Dashboard can be viewed from the server, site or application scopes via the tree view in the Connections Pane on the left hand side of the IIS Manager UI.
Before I explain further, it is important to note that the Dashboard sources data from one or more persistence and monitoring databases. In order for metrics of a particular service to be surfaced on the dashboard, it needs to be configured to utilize persistence (storage of persistence data in one or more Persistence databases) and/or configured to utilize event collection (storage of events in one or more Monitoring databases).
Dashboard Structure and Navigation Flow
The Dashboard is divided into three primary sections: Persisted WF Instances, WCF Call History, and WF Instance History. Each section provides a summary of a particular data pivot and drilling down within each section will lead you to the section’s own respective enumeration page. The first section (Persisted WF Instances) presents ‘live’ data while the subsequent sections provide historic metrics that are constrained to a particular time period. The time period can be modified via the ‘Time Period’ drop-down on the Dashboard menu with both predefined and custom options available.
Each section within the Dashboard can be collapsed or expanded. The collapsed view only allows the section’s summary bar to be visible, providing users with aggregate counts of all positive and negative metrics associated with the subject area (e.g. WCF Call History). Expanding the section will display a series of metrics that breakdown the aggregate counts shown on the section’s summary bar into key contributing factors/sources. For example, expanding the WF Instance History section will display a breakdown of activations and failures by the top 5 services as well as a count of the number of instance failures that have been recovered versus unrecovered. All metrics on the Dashboard are clickable, allowing you to drill-down into the counts to see details on each enumerated item via each section’s respective query page.
Monitoring the health of WCF Services
The AppFabric in this release only support persistence on WF services. As such, monitoring of the health of WCF services will be enabled by AppFabric’s event collection capabilities. With event collection enabled the Dashboard provides visibility into WCF calls and service exceptions via the WCF Call History section.
The summary bar of the WCF Call History section within the Dashboard is aimed at providing an aggregate count of all successfully completed calls and WCF service exceptions over a given period of time. Expanding the section provides some key breakdowns that allow you to:
1. Identify services in high demand: The first column lists the top 5 services (when applicable) with the highest number of completed calls over a given period.
2. Identify top exception-causing services: The center column lists the top 5 services (when applicable) that have encountered the highest number of WCF service exceptions over a given period.
3. Gain breakdown of key causes of WCF service exceptions: The purpose of the third column is to provide a numeric breakdown on the key causes of service exceptions: faulted calls and failed calls. It is important to note that service exceptions can also be caused by issues other than failed or faulted calls, such as service activation errors.
All metrics within the WCF Call History section can be clicked on, allowing you to drill-down into the aggregate count to view an enumerated list via the Tracked Events enumeration page. Depending on the metric you selected, the Tracked Events enumeration page will display the corresponding items via running a prepopulated query.
Monitoring the health of WF Services
The Dashboard provides varying levels of monitoring capabilities for WF services. All WF services regardless of durability can be configured to utilize AppFabric’s event collection capabilities, allowing data at varying verbosity to be collected for monitoring and troubleshooting purposes. This data is surfaced on the Dashboard via the WCF Call History and WF Instance History sections. Durable WF services can also utilize AppFabric’s persistence infrastructure which will allow the Dashboard to also provide live visibility into the health of persisted workflow instances. This feature is provided by the Dashboard’s Persisted WF Instances section.
Using historic data for Health Monitoring
Any WF-based service that is configured to utilize Dublin’s event collection capabilities set at ‘Health Monitoring’ level or above will be able to make visible on all historic metrics on the Dashboard. Since WF-based services also use WCF for communication, the WCF Call History section will also expose monitoring data on these services. For the purpose of this sub-topic, I will focus on discussing the WF Instance History section as the WCF Call History section has already been discussed earlier.
The purpose of the WF Instance History section is to provide a historic overview of all workflow instance activations, failures and completions over a given period. These three key metrics are presented in the summary bar of the section. Expanding the section provides some key breakdowns that allow you to:
1. Identify WF services in high demand: The first column lists the top 5 services (when applicable) with the highest number of instance activations over a given period.
2. Identify WF services with most instance failures: The center column lists the top 5 services (when applicable) that have experienced the greatest number of instance failures over a given period.
3. Understand recovered versus unrecovered instances: The purpose of the third column is to put in context the aggregate failure count in terms of what items are potentially still actionable.
All metrics within the WF Instance History section can be clicked on, allowing you to drill down and view an enumerated list via the Tracked WF Instances page. In addition to the instance information available on the page, you are also able to navigate or view all tracked events for a given instance, assuming that event collection is enabled for the parent service.
Using Persistence data for Health Monitoring
For durable WF services that are configured to utilize AppFabric’s persistence capabilities, the Dashboard provides live visibility into running and suspended persisted instances via the Persisted WF Instances section. Sourced by one or more persistence databases, the section offers an overview of what is happening with your durable workflows.
The summary bar of the Persisted WF Instances section contains a numeric breakdown of all running (Active or Idle) and suspended instances currently associated with your environment. When further context is required, expanding the section provides some key breakdowns that allow you to:
1. Identify durable WF services with highest current demand: The first column lists the top 5 services (when applicable) that currently have the most number of active or idle instances.
2. Identify services with most suspended instances: The center column lists the top 5 services (when applicable) that currently have the most number of suspended instances.
Again, like other sections, all metrics within the Persisted WF Instances section can be clicked on, allowing you to drill down and view an enumerated list via the Persisted WF Instances page. The enumeration page not only provides details on each persisted WF instance that satisfy the query conditions, but also supports instance control operations (i.e. Resuming a suspended instance). Similar to the Tracked WF Instances page, you can also navigate to and view all tracked events for a given persisted instance, assuming that event collection is enabled for the parent service.
AppFabric’s monitoring tooling is predominantly delivered via four features within IIS Manager: Dashboard, Persisted WF Instances enumeration, Tracked WF Instances enumeration and Tracked Events enumeration. Starting from the Dashboard, AppFabric’s feature set is aimed to surface the health of WCF and WF services and provide incremental drill-downs via query-able enumeration pages to assist in investigation and problem-diagnosis activities.
Next week’s post will focus in more detail on using AppFabric tools to troubleshoot applications. Also for more information on AppFabric monitoring and troubleshooting tools in general, view the endpoint.tv episode with demonstration here.
Goal:
Configuration of WCF 3.5 services can be challenging and .NET 4 introduces additional configuration settings for WF services and new WCF features. Today, there are several options available to edit configuration: svcConfigEditor.exe, Visual Studio, and Notepad.
All of these tools provide a basic, but complete experience that enables you to edit the entire set of configuration knobs available in System.ServiceModel. While many of these configuration knobs may be relevant during development, very few are relevant for application administrators.
So in the Windows Server AppFabric, we have looked at configuration settings that application owners are most likely to tweak, and set out to provide a rich tooling experience for these specific settings.
The list includes:
AppFabric Tools:
Much of the AppFabric management experience resides inside of IIS Manager in order to deploy and manage WAS-hosted services. ASP.NET applications are already configured via IIS Manager, and hence, adding the AppFabric configuration experience helps provide a seamless Web service configuration environment in IIS Manager. We also provide a rich scripting experience for all UI configuration via PowerShell cmdlets. So, most of the settings supported in AppFabric management UI can also be changed using PowerShell, giving you the ability to script post-deployment configuration.
Most of the application/service configuration experience we introduced in IIS Manager can be found in a single configuration dialog available at all IIS scopes:
Figure 1: Configuration dialog at the application scope
Tabs used in the configuration UI provide configuration options for various sections, which gives you a single dialog/UI to edit all configuration from. All of these tabs are context-sensitive, i.e., depending on the scope, they vary slightly. For example: you can only enable Auto-start (Availability tab) at the application or the service scope.
Defaults:
What does it really mean to configure at all of these scopes?
The WCF and WF service project templates in Visual Studio 2010 make use of a new simplification of the configuration system in NET 4: The <service> tag can be omitted in the configuration, in which case, services use certain defaults, including a default service behavior. That default service behavior is by convention the service behavior that has no name (the name attribute is omitted or set to an empty string), aka a “nameless behavior”.
It turns out that many of the settings we have chosen to tool are in fact service behaviors. So when we offer the ability to edit a setting in a service behavior at the service scope (ex: service throttling), we edit whichever behavior the service is using, named or nameless. But at the virtual directory, application, site, and server scopes, when editing that same setting, we will in fact edit a nameless service behavior at that scope.
Now, in the realm of service behaviors merging like regular collections in .NET 4, what this really means is that you can manage an inheritance chain of “default” settings that will apply to your services.
For example, you could define a default SQL WF Persistence store at the server scope. That setting will apply to all WF services on your server that use the default service behavior. And this setting could be modified for specific sites on your server, or even disabled for certain applications or services.
Details worth noting
This default story in AppFabric configuration has one consequence though. If your service is still using the “old configuration” standard of <service> tag and named (i.e., non-default) service behavior, this entire hierarchy of configuration that you set up with the dialog will not apply to the service. We offer a way to opt-into this new world, with the “Use Defaults” button in the configuration dialog’s general tab at the service scope.
Additionally, the monitoring settings defined at the application, site, or server scope will actually apply to all of your services. This is because the monitoring configuration in general is not service behavior based. Note that out of all the monitoring settings, only WF tracking is defined in a service behavior.
Additional information to keep in mind during configuration:
In conclusion, the Windows Server AppFabric leverages the new configuration features introduced in .NET 4 to provide a rich tooling experience in IIS Manager and via PowerShell for the configuration settings that application owners are most likely to change.
To quickly get everyone started on the Windows Server AppFabric, we decided to focus our second post on deployment. This way you can be up and running in no time and we can help you avoid any common issues. As a reminder, you can get the bits here and if you have questions we can help you out at the forums here.
There are actually four different ways in which you can install the AppFabric:
· Web Platform Installer
· UI Based Setup and Configuration
· Command Line/Scripted Installation and Configuration
· Offline/Sysprep Installation and Configuration
Installing the AppFabric using the technology provided by the Web Platform installer is by far the easiest way to get started. In this approach, all of the AppFabric pre-requisites are handled for you and configuration settings that are appropriate for a single machine installation are applied. This approach will satisfy anyone who wants to have a jumpstart in getting their environment ready. The other techniques provided are more suitable for preparing a production server or for configuring shared resources.
If you want more control over their installation you would opt for the UI based setup and configuration. The AppFabric UI based setup and configuration is designed to guide you through the steps necessary to perform the installation and machine level configuration of the AppFabric features. The setup experience is geared towards making the single machine installations as painless as possible. While multi machine scenarios are also supported by the UI.
If you are an advanced user setting up a shared environment you will be interested in the Command Line/ Scripted scenarios. Appfabric setup command line interface offers all the flexibility you need to select the feature set of the AppFabic features you are interested in and the AppFabric PowerShell cmdlets allow you to customize the configuration of your environment to suit your needs.
If you are setting up multiple machines then you will be happy to know that AppFabric setup also fully supports Offline and Sysprep scenarios.
Quick list to get you started installing AppFabric Beta 1
· Supported Operating Systems:
o Windows 2008 R2 RTM
o Windows 7 RTM
o Windows Server 2008 SP2
§ IIS Must be enabled and the following hot fixes must be applied
· Apply Hotfix 970773
· Apply Hotfix 970772
o Windows Vista Sp2
NOTE: Installation on Beta or Release Candidates is not supported. IIS must be enabled prior to applying hotfixes.
· Required .NET Framework:
o AppFabric requires .NET Framework 4 Beta 2 available here.
NOTE: Please cleanly uninstall all previous versions of .NET 4 Framework
· General Pre-Requisites:
o The Installation Guide and the Release Notes have a complete and detailed list of general pre-requisites that may be helpful if you having difficulties
NOTE: Make sure you uninstall any older versions of pre-requisites before installing the ones required by the AppFabric.
· Remote Databases:
o The Configuring a Server Farm section in the Installation Guide has good information on using a remote database with the AppFabric.
· Cache only installation:
o Microsoft .Net 4 is not required if you are only installing the Distributed Cache components of the AppFabric.
The AppFabric team is continuing to do work to improve the setups experience, the way the features of the AppFabric are integrated and the way pre-requisites are handled in all platforms. If you have any questions, you run into any problems installing the AppFabric , the best way to contact us is through the AppFabric forums.
Welcome to the new Windows Server AppFabric Blog for IT Professionals. All content on this blog is by Microsoft team members building the Windows Server AppFabric. This is our chance to show you some of the cool things we have been working on. It is also your opportunity to give feedback straight to the product team members building the Windows Server AppFabric.
Today we are kicking off a series of topics on the AppFabric features related to Service and Wroflow Management. For IT Professionals, the AppFabric Service and Workflow Management is the way to run and manage .Net 4 Windows Workflow (WF) and Windows Communication Foundation (WCF) services. If your project uses .NET 4 WF or WCF, the Service and Workflow Management features of AppFabric will provide significant improvements in the following areas:
· Health Monitoring and Troubleshooting Services
· Workflow Instance Management
· Scaling-Out Distributed Applications
· Simplified Configuration Tooling
· Scripting Management Tasks
We do this by extending the reach of the existing IIS Manger tools to cover managing, controlling, monitoring and troubleshooting middle tier services that encapsulate business logic and support the web tier. If you are not familiar with IIS Manager, you can learn all about it here.
Health Monitoring and Troubleshooting Services
Workflow Instance Management
Scaling-Out Distributed Applications
Simplified Configuration Tooling
Scripting Management Tasks
This entry was meant to give you a quick view into some of the features that the AppFabric provides for Service and Workflow Management. Future posts will delve into specific topics to provide you with details on how to manage your WF and WCF services. Here are some additional places you can get information on the Windows Server AppFabric right away:
First off, Beta 1 of the Windows Server AppFabric has just been released – download it and give it a try for yourself. The final version of the Windows Server AppFabric will be released shortly after Visual Studio 2010 ships.
Second, we started a MSDN developer center for the Windows Server App Fabric here.
Finally, if you would like more details on how the Windows Server AppFabric can help you implement WF and WCF services, check out our companion blog here.
Remember, this blog is also your opportunity to send feedback straight to the product team. Go out and try Beta 1 and share your experiences with us. It would be great to know what works well and what we can improve upon in all areas of the AppFabric product and documentation. Also, let us know what samples, whitepapers, videos, or other content you’d like us to produce to help you better understand the AppFabric technology.