December 18, 2012 at 3:57 PM

At a certain point in time when installing BizTalk, you will need to install some extra “components”. In the BizTalk installation wizard this is referred to as a prerequisite file.

This file can be downloaded automatically from within the wizard, but most likely you have some good reasons not to do that:

  • You’re installing more than 1 BizTalk server and/or environment at the same time
  • You do not want to wait for downloads to finish
  • Internet access is not available on BizTalk servers
  • etc …

There are a bunch of reasons why a seasoned BizTalk professional/administrator needs to have a backup copy of these files available just in case you might ever need them…

Below you can find a list of all BizTalk prerequisite files I have come across and where to find any further localized versions in case you might need them.

 

BizTalk 2013 beta

I haven’t found the BizTalk 2013 beta prerequisite CAB file links anywhere, but I’m sure this is overkill to this post… it’s better to download them within the wizard.

The beta is just for evaluation purposes anyway, so you would not install this on an actual server + the file is most likely subject to change due to it’s beta status.

 

BizTalk 2010

The following list is taken from the installation document for BizTalk 2010 found here.

Platform Localization Link
Windows Server 2008 (32 bit) EN Download
Windows Server 2008 (64 bit) EN Download
Windows Server 2008 R2 EN Download

 

BizTalk 2009

The following list is taken from the installation document for BizTalk 2009 found here.

Platform Localization Link
Windows XP (32 bit) EN Download
Windows XP (64 bit) EN Download
Windows Server 2003 (32 bit) EN Download
Windows Server 2003 (64 bit) EN Download
Windows Vista (32 bit) EN Download
Windows Vista (64 bit) EN Download
Windows Server 2008 (32 bit) EN Download
Windows Server 2008 (64 bit) EN Download

 

BizTalk 2006 R2

The following list is taken from the installation document for BizTalk 2006 found here.

Platform Localization Link
Windows XP (32 bit) EN Download
Windows XP (64 bit) EN Download
Windows Server 2003 (32 bit) EN Download
Windows Server 2003 (64 bit) EN Download
Windows Vista (32 bit) EN Download
Windows Vista (64 bit) EN Download

 

I hope this helps someone who needs the quick download!

Posted in: BizTalk

Tags: ,


December 14, 2012 at 2:23 PM

In more advanced WCF scenarios, the BizTalk standard functionality can be insufficient.  In those cases, WCF extensibility can help us to overcome the limitations of the standard BizTalk WCF adapters.  Typical examples are custom MessageInspectors, ErrorHandlers, Decoders and AuthorizationBehaviors.

 

Once you have registered the extensibility, you can configure it on the WCF-Custom or WCF-CustomIsolated receive and send ports:

 

      image

 

When the WCF send or receive port is executed, your WCF extensibility objects will be injected into the WCF channel stack.

 

But how can we register these WCF extensions?

 

BizTalk 2006 R2 and BizTalk 2010

In the previous versions of BizTalk, there was only one way to register WCF extensions: the machine.config.

 

-   The C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config is needed for 32-bit processes:

  • BizTalk 32-bit host instances
  • IIS 32-bit applications
  • BizTalk Administration Console

 

-   The C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config is needed for 64-bit processes

  • BizTalk 64-bit host instances
  • IIS 64-bit applications

 

        image

 

BizTalk 2010: The new feature

BizTalk Server 2010 comes with a nice new feature for registering your WCF extensibility assemblies. The new feature allows you to avoid the machine.config and to register them in BizTalk itself. Let’s have a look!

 

  • Browse to the WCF-Custom adapter handlers.

 

        image

 

  • Open the receive or send handler.  Choose Properties.

 

        image

 

  • Here you can import a web.config / app.config that contains your WCF extensions.

         

       image

 

BizTalk 2010: The caveat

Unfortunately, this doesn’t work if your receive port is hosted in IIS.  You can register the WCF extensions on the WCF-CustomIsolated adapter handlers. However, when the WCF-CustomIsolated receive port is called, you get an activation error:

 

“WebHost failed to process a request.

Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/45653674

Exception: System.ServiceModel.ServiceActivationException: The service '/ApplicationName/Service.svc' cannot be activated due to an exception during compilation. The exception message is: Unable to create endpoint behavior configuration element from XML configuration.

Check the following:

1. Verify behavior element extensions in machine.config are correctly configured.
2. Restart the application if machine.config was recently updated.
3. Ensure the configuration is valid XML that conforms to the configuration schema.”

 

Adding the WCF extensions in the corresponding web.config of IIS also doesn’t solve this issue.  The only solution I’ve found is to register them again in the machine.config.  Remember that BizTalk 2010 is .NET 4.0.

 

- The C:\Windows\Microsoft.NET\Framework\v4.0.30319\CONFIG\machine.config is needed for 32-bit processes:

  • BizTalk 32-bit host instances
  • IIS 32-bit applications
  • BizTalk Administration Console

 

- The C:\Windows\Microsoft.NET\Framework64\v4.0.30319\CONFIG\machine.config is needed for 64-bit processes

  • BizTalk 64-bit host instances
  • IIS 64-bit applications

 

Conclusion

-   Only when using the WCF-Custom adapter in BizTalk 2010, you can register WCF extensions in BizTalk itself.

-   In all other scenarios, you need to register them in the corresponding machine.config.  This has the drawback that this also influences other applications on the server.

 

Please get in touch if you managed to get this working!

Posted in: BizTalk | WCF

Tags:


November 28, 2012 at 4:39 PM

Today I’ve encountered an issue with remote BizTalk deployment.  Every night we run a TFS build and the result of that build is deployed to our BizTalk Test Server.  Because the build process runs on our TFS Build Server, we actually perform a remote deployment to the BizTalk Test Server.  Until last night, everything worked fine.

 

The error

This error occurred during the import of one of the binding files: Failed to create 'WCF-Custom' Transport Component.

 

The reason

It was the first time we tried to remotely import a BizTalk binding file that contained the WCF-Custom adapter.

 

The troubleshooting

I used the Microsoft.BizTalk.Deployment.DeployerComponent to import the bindings.  I created a workaround for the issue, by executing BTSTASK.exe remotely via PSEXEC.exe.  This worked fine, but then I’ve got the same error while starting receive locations and send ports, that were configured with the WCF-Custom adapter.  As I didn’t have a good command line alternative for this functionality, the workaround was useless.

Afterwards, I’ve tried to install some extra BizTalk software on the TFS Build Server. And yes, this was the way to go!

 

The solution

The Windows Communication Foundation Adapter runtime should also be installed on the local machine (in our case TFS Build Server).  This is not documented somewhere and it’s not the behavior you would expect.  The BizTalk deployment libraries work fine for remote deployment, until you use the WCF adapter…

 

This is an overview of the BizTalk software installed on our TFS Build Server:

- BizTalk Developer Tools and SDK  [needed to run Unit Tests]

- BizTalk Project Build Component  [needed to build BizTalk Projects]

- BizTalk 2010 Cumulative Update Pack 4.0 [contains this fix]

- Windows Communication Foundation Adapter [apparently needed to remotely import bindings containing WCF adapters]

 

image     image

Posted in: BizTalk | Deployment

Tags:


November 21, 2012 at 3:36 PM

You want to make a custom BizTalk pipeline component that handles content from an inbound XML-message, e.g. getting a value with XPath. Then you could use a MemoryStream or load the message in an XmlDocument. This is not the most performant way for doing this, though. Loading the message into memory with an XMLDocument, can take up to 10 times of the amount of space than the actual message size.

 

If you want to make a pipeline component that has a good performance, you might want to use an Xml(Text)Reader, a ReadOnlySeekableStreem or a VirtualStream. This doesn’t load the message entirely into memory.

 

In order to do this, you will need the assembly Microsoft.BizTalk.Streaming.dll.

You can find this assemby in the GAC and get it by executing this in cmd.exe:

cd C:\Windows\assembly\GAC_MSIL\Microsoft.BizTalk.Streaming\3.0.1.0__31bf3856ad364e35
xcopy Microsoft.BizTalk.Streaming.dll "C:\Program Files (x86)\Microsoft BizTalk Server 2010"

 

For an example you can check out this post:

http://blog.codit.eu/post/2011/10/15/XslTransform-pipeline-component.aspx

For more info about the VirtualStream and it’s advantages, you can take a look at this topic:

http://msdn.microsoft.com/en-us/library/ee377071(v=bts.10).aspx

Posted in: BizTalk | Performance | XML

Tags:


November 14, 2012 at 4:43 PM

It’s a good practice to have some XML validation in your BizTalk integration flows.  It prevents you of sending mal-formatted messages to back-end systems and it also gives you the opportunity to validate incoming messages.  In the BizTalk toolbox, you have two standard pipeline components that can perform this XML validation.  Let’s have a look...

 

XML Disassembler (or XML Assembler)

The default configuration of the XML Disassembler will not perform any kind of XML validation on the message


If you want to enable XML validation on the XML Disassembler you need to set Validate document structure to True and explicitly set the Document schema(s) that need to be validated. Compared to the specified Documents schema(s):
- If the processed message has the same TargetNamespace#RootNodeName combination, XML validation will be performed

- If the processed message has another TargetNamespace#RootNodeName combination, an exception will be thrown (can’t recognize the data)

 

    image


XML Validator

The default configuration of the XML Validator will already perform XML validation. How? It retrieves the XML definition from the BizTalkMgmtDb, at run-time, using the TargetNamespace#RootNodeName combination.

-   If a matching schema is found, XML validation will be performed on the processed message

-   If no matching schema is found, the XML Validator will throw an exception (cannot retrieve document specification)


You can also explicitly specify at design-time the Document schema(s).  Compared to the specified Documents schema(s):

-   If the processed message has the same TargetNamespace#RootNodeName combination, XML validation will be performed

-   If the processed message has another TargetNamespace#RootNodeName combination, no XML validation will be performed


    image

 

Conclusion

You see a different behavior when comparing the components, especially when specifying Document schema(s). Depending on your needs, you can choose the appropriate setup.  I mostly opt for the combination of the XML Disassembler and XML Validator, both with their default configuration.  It has the advantage that you don’t need to configure anything at design-time.  They work together in this way:

-   The XML Disassembler is responsible for retrieving the BTS.MessageType, promoting context properties and debatching

-   The XML Validator will validate all messages, deciding at run-time which schema to use

Posted in: BizTalk | General | Schemas | XML

Tags:


November 5, 2012 at 10:50 AM

Microsoft has just released the beta release of BizTalk Server 2013.  The first good news is that the initial name (BizTalk 2010 R2) has changed to BizTalk 2013, indicating it will be a major release, providing longer support to our customers.  The Windows Azure image gallery will also be updated to include BizTalk 2013 beta.

Codit is part of two different TAP programs with the same product team: BizTalk 2013 and the Windows Azure BizTalk Services (earlier known as EAI & EDI services).  We have been testing our Integration Framework for BizTalk Server and our Integration Dashboard for BizTalk Server against this new release and we can say we are ready.

It’s great to see things are moving in the Microsoft integration space.

 

The beta can be downloaded here: http://www.microsoft.com/en-us/download/details.aspx?id=35553 and contains the following capabilities:

  • Integration with Windows Azure Service Bus – these are mainly out-of-the-box adapters for Windows Azure Service Bus (both messaging & relay)
  • Support for REST – seeing the web- & device-world move to a REST-oriented approach, it is a very good thing to see support for REST in BizTalk 2013.  And this is not only for consuming, but also for exposing RESTful services!
  • SFTP adapter – this has been a request for years and it’s with great relief that a true SFTP adapter will be part of BizTalk 2013
  • ESB Toolkit – The ESB toolkit has been one of the most unclear parts of BizTalk since its inception.  From guidance over toolkit and now ending up as part of the product.  The configuration experience is much better, which is already good.
  • Dependency tracking – the administration console now shows the dependencies between artifacts
  • Other changes – enhanced SharePoint adapter, improvements in send ports…
  • Host Integration Server, that comes with your BizTalk license, also has some improvements in the following areas: DB2 integration, TI management, Support for MQ v7.5 & v7.1

Conclusion

What first looked like a pure platform update (aligning with SQL Server 2012, Windows Server 2012, .NET 4.5) now has changed to a big upgrade with a lot of enhancements to the product.  Having a full release is an important sign to the market, meaning support lifecycle for this product is significantly longer.


October 30, 2012 at 3:01 PM

It’s a common practice to reuse schemas / types within your BizTalk solution.  Lately, I’ve encountered an issue regarding this.  Here you can find a simplified example and a solution to the problem.

 

Assume you have two reusable schemas (no dependencies between them):

-   http://schemas.codit.eu/common#Address

-   http://schemas.codit.eu/common#ContactInformation

 

Now you want to create a “Person’ schema in the http://schemas.codit.eu namespace, by reusing the previous schemas.

-   First you need to import the Address schema

-   Secondly you need to import also the ContactInformation schema.  This results in the error:

 
 The namespace of the schema you are trying to add clashes with one of the namespaces already declared.  Please choose another schema.

 image

 

Although, in XSD this is not a limitation.  So I’ve tried to work around the BizTalk Schema Editor and opened the XSD as an XML file.  I’ve manually added the XSD import of the ContractInformation schema:

 

image

 

After this workaround, I’ve opened the schema again with the BizTalk Schema Editor, without any errors.  It just seems to be a limitation of the BizTalk Schema Editor.

 

image

Posted in: BizTalk | General | Schemas

Tags:


October 24, 2012 at 4:19 PM

For a recent project I needed to send messages to BizTalk through an ASP.NET application.
The purpose of the ASP.NET website was to provide a simple user interface to send messages to BizTalk, where people can download / upload messages (with validation).

The users can first validate their message, this is done through a BizTalk pipeline that parses the message and does several checks to see if it is valid.

I exposed a request-response receive location using net named pipe binding that executes the validation.
The BizTalk pipelines parses the message and converts it to a “Validator Message” that contains the errors / warnings of the message.

Some of the files that are uploaded are pretty huge ( > 100 mb as a flatfile).
That is one of the reasons why I opted for the net.pipe binding, because this binding can implement streaming (note: not all bindings can implement streaming mode!).
Another reason why I opted for that binding is because this binding is perfect for communication between WCF applications on the same machine.

BizTalk

Here is how I set-up the BizTalk side.

I created one request-response receive port and added a receive location. I route the message I receive from the receive pipeline directly back to the send pipeline of that port, so I don’t need additional send ports.
You can see how to do this in another blogpost
The receive location uses the WCF-Custom adapter with the netnamedBinding.

I changed some default values, like the maxReceivedMessageSize, and made sure that “transferMode” is set to “Streamed”.

image

I also needed to change some settings in the “Messages” section.
I had to change the inbound and outbound message body, this is dependent on how you name the WCF interface in your .NET application (see section “.NET application” below).

Inbound Message Body

Extract the stream by selecting the xpath, in my case the xpath looks like following:

/*[local-name()='SubmitMessage' and namespace-uri()='http://App.services/BizTalk']/*[local-name()='Message' and namespace-uri()='http://App.services/BizTalk']

Also make sure that you set the Node Encoding to “Base64”, since we are sending a stream.

Outbound Message body

You also need the “wrap” the stream we receive back, so it is a valid response message according the interface of the WCF service we setup in the .NET application.

You can do this by setting the template. In my case I had to set it like following:

<ns0:SubmitMessageResponse xmlns:ns0="http://App.services/BizTalk">     
     <ns0:SubmitMessageResult xmlns:ns0="http://App.services/BizTalk">         
          <bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007" encoding="base64"/>     
     </ns0:SubmitMessageResult> 
</ns0:SubmitMessageResponse>

Be sure to include the “encoding” parameter so it encodes the message as base64.

image

Only thing left to do is set the uri of the receive location, example:  net.pipe://localhost/App/ValidatePricat

.NET Application

First thing to do is create the WCF interface.

I implemented the “IClientChannel” so I could use an OperationContextScope in my client to add a custom WCF header.

[ServiceContract(Namespace = "http://App.services/BizTalk")]
public interface IBizTalkSubmitService : IClientChannel {         
   [OperationContract(Action = "*", ReplyAction = "*")]         
   Stream SubmitMessage(Stream Message);  
}

 

Now for sending the stream to BizTalk.

FIrst create a channelfactory of the interface above, using the correct binding.
Make sure you set the transferMode to “Streamed”.

NetNamedPipeBinding b = new NetNamedPipeBinding("NetNamedPipeBinding_BizTalkService"); 
EndpointAddress epa = new EndpointAddress("net.pipe://localhost/App/" + operation); 
var myChannelFactory = new ChannelFactory<IBizTalkSubmitService>(b, epa);

Next create the client. You will see I am using an OperationContextScope. This is for adding a custom WCF header.
The reason why I need to add a custom WCF header is because the site is multilingual, so I implemented multiple languages in the BizTalk solution for returning error / warning messages concerning the validity of the message in the correct language.

You will see following line of code:

header.GetUntypedHeader("PropertyContainer", "https://R4A.Properties");

BizTalk will automatically promote the messageheader in the context. For this to work, you will need to create (and deploy) a propertyschema containing the property “PropertyContainer” (the one you defined in the above line of code) in the correct namespace.
The value of the “propertycontainer” is an XML document that has been encoded (but this could also be a simple string), I did this because I have multiple properties (language, some codes for validation, ..) and this way I can easily extract it in a custom pipelinecomponent in BizTalk.

This is the full code:

public Stream SendMessage(string operation, Dictionary<string, string> contextProperties, Stream message)        
{            
     NetNamedPipeBinding b = new NetNamedPipeBinding("NetNamedPipeBinding_BizTalkService");            
     EndpointAddress epa = new EndpointAddress("net.pipe://localhost/App/" + operation);           
     var myChannelFactory = new ChannelFactory<IBizTalkSubmitService>(b, epa);           
     
     IBizTalkSubmitService client = null;            
     Stream response = null; 
           
     try
     {                 
          client = myChannelFactory.CreateChannel();                
          using (OperationContextScope contextScope = new OperationContextScope(client))                 
          {                     
               if (contextProperties != null)                     
               {                         
                    XmlDocument xDoc = new XmlDocument();                         
                    XmlElement rootNode = xDoc.CreateElement("PropertyContainer");                        
                    foreach (KeyValuePair<string, string> pair in contextProperties)                         
                    {                             
                              XmlElement prop = xDoc.CreateElement(pair.Key, "https://R4A.Properties");                             
                              prop.InnerText = pair.Value;                            
                              rootNode.AppendChild(prop);                         
                    }                        
                    xDoc.AppendChild(rootNode);                        
                    var header = new MessageHeader<string>(HttpUtility.HtmlEncode(xDoc.InnerXml));                         
                    var untyped = header.GetUntypedHeader("PropertyContainer", "https://R4A.Properties");                         
                    OperationContext.Current.OutgoingMessageHeaders.Add(untyped);                    
               }                    
               
               response = client.SubmitMessage(message);                 
          }                
          
          ((IClientChannel)client).Close();   
          
     }catch(Exception ex)             
     {                     
          ((IClientChannel)client).Abort();             
     }            

     return response;   
      
}

That’s it!
Now simply call the “SendMessage” method and you can send a stream to BizTalk and receive a stream back.
This way my website doesn’t need to read the message and no memory problems can be encountered, because everything works streaming.
And using the custom WCF header, I can still add some extra information to the message.

I couldn’t find a similar blogpost about this subject, so hopefully this will help you :)

Posted in: BizTalk | WCF

Tags: , ,


October 10, 2012 at 3:42 PM

On one of the projects we were doing, we needed to migrate the BizTalk 2006 R2 applications to BizTalk 2010.
This gave us the chance to change the running SOAP BizTalk services to WCF services. These services have more capabilities and are easier to configure.
We only had one restriction: the clients may not be forced to change. After some searching on the web, I found following post:

http://maximelabelle.wordpress.com/2010/08/12/creating-soap-compatible-biztalk-wcf-services/ and I like to share it with you.

First of all, I will explain how to expose a schema as a WCF Service;

Expose a Schema as a WCF Service

To create a WCF-service, use the BizTalk WCF Service Publishing Wizard. You can find it in the BizTalk Server 2010 folder at the Windows start menu.

clip_image001[5]

With this wizard you can set up the service endpoint.
You can choose between WCF-BasicHttp, WCF-WSHttp and WCF-CustomIsolated as a transport type and choose the application where you want to create the receive location in BizTalk.

clip_image002[2]

At the next step you get the choice to choose if you want to expose an orchestration or a schema as a WCF Service. In our case we will choose the schema choice.
The wizard gives you a tree of service methods, operations and request-response. Here you can add methods and one- or two-way operations. Define the schema type for your request and/or response from an assembly.

clip_image003[2]clip_image004[3]

clip_image005[2]clip_image006[2]

Fill in the target namespace of the WCF Service and choose the host and web directory where the service will be reachable.

The last step is a summary of the service you are going to create.... congratulations, you have created a WCF Service in BizTalk!

A new site is created in IIS and a receive location has been created for this service. The URI property refers to the address of the site in IIS.

Look also at the Receive Handler which is the BizTalkServerIsolatedHost. This means that this port is running under IIS.

clip_image007[2]

clip_image008[2]

Check if the receive location is started and if the Application pool of the site has the correct identity to work with BizTalk.

clip_image009[1]

If you try to browse to the site and receive a login error then you have to give the application pool the correct identity.

If after browsing to the site and you receive the following screen, you have created a WCF service with success.

clip_image010[1]

Change the Service to be able to communicate with the old SOAP-clients

First thing you need to do, is download the WSDL of the old SOAP Service and store it in the same folder of your SVC-file.

Open the WSDL and change the address location to the URI of the SVC-service.

When you look in the folder where the SVC-file is situated, there is also a web.config file of the service.

Load this web.config file in the WCF Service Configuration Editor for easy modifying.

clip_image011[1]

Go to the advanced tab and open the Service Behavior. Open the configuration and in the Service Metadata\ExternalMetadataLocation you have to add the path to the old WSDL. Save the config and close the configuration editor.

Now if you go to the service you will see that the URL of the WSDL has changed, also the WSDL itself now refers to the old one.

For the last step, you will need to change the Inbound BizTalk message body and the outbound WCF message Body.

The old ASMX message has one node more than a WCF envelope. You have to tell BizTalk were to get the find the message in the received envelope.

Open the settings of the receive location and click on configure, go to the message Tab. In the Inbound BizTalk message body check the path option and use the xpath '”/*/*” to go to the child node of the received message.

clip_image012

For the outboundWCF message body you need to wrap your message in an extra node because the client is demanding an extra Operation node as a wrapper. You also have to give this node the service namespace.

Restrictions, this pattern can only be used when you have a service that only has one operation due to the wrapper element you have to declare in the outbound WCF message body.

Hope this helps.
 - Robert Maes


October 5, 2012 at 4:15 PM

This week I represented Codit at the Windows Server 2012 Launch event in Antwerpen. The Launch event had two separate tracks; a Windows Server track and an Azure track. Remarkable is that even on a Windows Server launch event, half of the sessions was about Azure.

In this post I will go over some nice features of Windows Server 2012 - in my personal point of view. This post is no attempt by any means to list all new features and changes in comparison with previous Windows Server versions.

Metro

The first thing you’ll notice is that even Windows Server 2012 uses the Metro ‘Start’ screen (or should we say Modern UI now?). Because Metro is primarily targeting touch-based devices, at first this feels a little odd for a server, but we will get used to it…

clip_image002

Server Manager

The new Server Manager screen is displayed automatically when you boot up your Windows Server 2012. The new Server Manager was a very pleasant surprise! The Server Manager has a dashboard screen with a ‘tile’ for each server role you added to your Windows Server machine:

clip_image004

Each tile gives an instantaneous overview about the state of that specific feature (IIS, DHCP, DNS, AD FS …). Errors are immediately visible because of the red tile. If you click the ‘events’ link displayed in a tile, you will get all events related to that Windows Server feature – very convenient.

That’s not it yet for the Server Manager, you can add other Windows Servers to this dashboard! This will give you a single screen overview of the state of your Windows Servers! Especially when you don’t have SCOM, this is a very useful feature.

Windows Servers can also be grouped in a Server Group. In this way you can perform operations on the group instead of on each server separately.

AppFabric?

Some people expected to get Windows Server AppFabric out of the box with Windows Server 2012. Guess what, it’s not!
Instead Windows Server 2012 ships with IIS8. IIS8 offers a lot of new features and I was very surprised that there wasn’t a single session about IIS8 during the launch event. IIS8 offers a Central Certificate Store; a shared store to manage your certificates in one place instead of on every node of your server farm.
IIS8 also supports WebSockets. WebSockets provide a full-duplex communication channel between the browser and the Web Server over a TCP connection. WebSockets allow pushing content to web clients without an incoming request from that client first! What is very interesting that all this works over port 80 (the TCP channel starts as a HTTP handshake that is then upgraded). All this enables you to push content to your clients over a TCP connection without modifying firewall settings.

.NET

Out of the box, Windows Server 2012 ships with .NET Framework 4.5. When you need .NET Framework 3.5 SP1 (e.g. for SQL Server 2012) you will have to install it separately. I advise you to do this up front, before installing SQL Server 2012. The SQL Server 2012 Installation Wizard fails when .NET framework 3.5 SP1 is not installed. It fails during installation not during the prerequisites check! This means you will need to go through the SQL Server 2012 Installation Wizard again…

 

 

Peter Borremans