Remote Desktop Connection 6.0 Released

Microsoft have just released version 6.0 of the Remote Desktop Connection client to the wider community! This version allows users to leverage some of the great new functionality introduced in Terminal Services under Vista, including:

  • Network Level Authentication – a new authentication method that finishes user auth before you establish a full Remote Desktop Connection and the logon screen appears, reducing the number of resources before a full RDC connection is established. Also, NLA helps protect users from connecting to remote computers that are set up for malicious purposes.
  • Server Authentication – verifies that you are connecting to the correct remote computer or server, prevents you from connecting to a different box than you intend and from unintentionally exposing confidential information. This feature is enabled by default.
  • Resource Redirection – support for Plug and Play devices that allow redirection.
  • Terminal Services Gateway (TS Gateway) Server Support – RDC uses port 3389 which is normally blocked by a firewall if you are attempting to initiate a connection from the internet. With TS Gateway Server, an internet based Remote Desktop connection is initiated over port 443 through a Secure Sockets Layer (SSL) tunnel, negating the need for a costly VPN or corporate network to send and receive data over the remote connection.
  • Monitor Spanning – support for high-resolution displays that can be spanned across multiple monitors, with a max resolution of 4,096 x 2,048. The monitors must have the same resolution. Additionally, the monitors must be aligned side-by-side.
  • Visual Improvements – support for 32-bit colour and font smoothing.

My personal favourite is of course monitor spanning, but I’m sure that the TS Gateway functionality will be a serious sweetener for the corporate market.

BizTalk 2006 R2 Beta 1 Installation – First Look

Richard Seroter has just posted about the BizTalk 2006 R2 beta 1 installation experience and new functionality – it would appear there is lots of .Net 3.0 and WCF, along with Microsoft EDI/AS2 and BAM Evening goodies!

The installation experience appears to be along the same lines as BizTalk 2006, with added EDI/AS2 configuration options (which appears to be in addition to the Base EDI Adapter), this comes hot on the heels of the AS2 adapter gaining Drummond Certification. A new application (‘BizTalk EDI Application’) appears to be present following installation, along with the new LOB and a host of WCF adapters.

Roll-on the public release of R2!

BTS2006 Install – Pre-Requisite CAB File

I’ve just completed the Microsoft 2934 BizTalk 2006 Admin course and this was the first time I’ve installed BTS06 on an offline server instance (my UAT VPC machines always have an internet connection).

I was pleased to see that for offline installations, the BizTalk team have provided an option to install the pre-requisites from a local CAB file – great work!

Microsoft provide the CAB on their website, however rather than link back to Microsoft, Grant Holiday has all the details on his blog, including the internationalisation links for Windows 2003, XP and 2000.

Yet another great feature in BTS06 – BTS04 installations now take soooooooo long!!

The Service Orientated Architecture Hub

The SOA Hub website provides a handy tool for all things SOA. They have a browsable list of available web services and provide tools to publish and test your own custom services.

The detail for each published web service includes the average response time, costs, provider and service details and links to test the service.

Some of the web services of particular interest (here in the UK) are:

  • Credit card verifier (verify credit card checksums for valid Visa, MasterCard, American Express etc.);
  • Dun & Bradstreet Business Credit Check (perform low risk credit assessments and pre-screen prospects with D & B’s core credit evaluation data);
  • Currency rate converter (perform interactive foreign exchange rate calculations, using current currency rates updated every 10 minutes);

Schema Development: How to Identify Distinguished Fields

When developing schemas, it helps to identify all of the necessary distinguished fields before deploying the solution into production. Making changes to a deployed schema can introduce un-needed complexity and pain if used across multiple projects.

SUnlike promoted fields* however, it can be difficult to identify all of the necessary distinguished fields before deploying the solution (the business will always have a new requirement that needs you to subscribe to the one field you haven’t distinguished following the latest schema refresh…)

To help me identify distinguished fields I use the unique/constant rule:

  • Unique = unsuitable. Unique fields will always contain data that is likely to change with each message instance (e.g. an order reference, invoice reference delivery date) or data that may change on a frequent basis (e.g. order date, delivery date) – It is highly unlikely that you will be required to subscribe to fields that change with each message instance and if you do, ‘why?’ should start to crop up in conversations with co-workers!
    • Constant = suitable. Constant fields will always contain similar data (e.g. trading partner id, party name, routing id etc.), or data that could be considered as an enumeration (e.g. we are using a ‘message status’ field to identify how far through our core B2B process the message is, the statuses can be any one of MAPPING_COMPLETE, CONFIGURATION_COMPLETE or VALIDATION_COMPLETE).

    The image above is a screenshot of version 2 of our core order message showing distinguished (constant) elements and attributes. Fields that are unique (message tracking guid, message guid, original message reference and source filename) are not promoted.

    * In my experience, promoted fields are usually identified during the [orchestration] development phase.

BizTalk 02/04-06/06 R2 EDI Feature Comparison

I recently spoke with a member of the BizTalk EDI Product Team on e-mail about the feature set between 2004/2006 and 2006 R2 after reading several interesting articles about the forthcoming R2 improvements.

The team have now published a post on their blog providing a feature comparison between BizTalk 2002, 2004/2006 and 2006 R2. As an EDI junkie, the following features are particularly appealing:

  • The ability to create custom schemas (I work with a number of trading partners who use EDIFACT 92.1 as their default message set!), although there is a large set already supported.
  • Outbound and inbound message batching/de-batching, including the ability to suspend individual messages or an entire transaction.
  • No need for additional adapters – all assembling/disassembling *appears* to occur in specialised send and receive pipelines.

I hope these new features will bring BizTalk the B2B/EDI market adoption that have previously required costly (yet excellent) third-party adapters.

BTS2006 EDI Base Adapter – Error Occurred in the File System Connector

I installed the BizTalk 2006 base EDI adapter for the first time last night to investigate the differences between the Covast EDI Accelerator and the Base EDI Adapter (the base adapter technology is produced by Covast).

While working through the XML-to-EDI tutorial it became apparent that things were not quite right with my configuration – I was constantly receiving the following error:

Error encountered: ERROR (120) :
An error occurred in the File System connector. Check the details.Cant make a connection to \TITANAEEDIDocsHomeDocumentsPickupEDI. Errormessage: The operation cannot be performed because a network component is not started or because a specified name cannot be used.Foldername: \TITANAEEDIDocsHomeDocumentsPickupEDI, Errormessage: The operation cannot be performed because a network component is not started or because a specified name cannot be used.

It would appear that on installation, a share is created that points to C:Documents and SettingsAll UsersApplication DataMicrosoftBizTalk Server 2006EDISubSystem. The SubSystem folder contains all of the goodies required to make the Base EDI Adapter work – esp.ini, the engine input file (EIF) and Documents directory which provides a message store while the adapter is doing its magic.

The error above however is a little misleading, as it has nothing to do with a network component or the specified name being incorrect. Instead, the EDI Subsystem Users group is not granted access on this share under the default installation. Simply adding the group (with full control) will resolve this error.

It does make me wonder why the installation insists on creating a share to point to the aforementioned location as this directory information is actually held in the SQL Server database. The only reason I can see for using this method is on multi-server installations, where the EDI SubSystem resides on a network share, rather than a local directory. This makes sense, but I’m not too sure behind the reasoning on a default [local] installation.

SQL Server 2005 Service Manager

One of the noticeable omissions from the excellent SQL Server 2005 product is the Service Manager, a tool which provides a quick visual indication as to the state of a local or remote SQL Server instance.

It would appear that I’m not the first to notice this and an excellent freeware version has been produced by Jasper Smith.

This version requires the .NET 2.0 framework, supports both SQL Server 2005 and 2000 versions, and provides interfaces to manage (besides SQL Server): SQL Agent, Analysis Services, Full Text Search, MSDTC, SSIS, SQL Browser and Reporting Services!

Furthermore, there appears to be a very healthy development cycle. Great work Jasper!


Service Manager running in the taskbar:

SQL Server 2005 Service Manager - Taskbar View

Service Manager options:

SQL Server 2005 Service Manager - Options View