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


February 19, 2012 at 12:26 PM

A while ago I had a little surprise with a demo project.
The project consists of a client application, a claims aware WCF service and AD FS as token issuer.

This demo was working fine until now...
Without changing anything, authentication always fails with this error message (see WIF tracing):

ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.

Offcourse my token issuer certificate was added to the 'trustedissuers' collection on the WCF service, so something must have changed in AD FS.

The signing certificate in AD FS shows this:

As you can see, there are two signing certificates (I had one before). The second signing certificate was created by AD FS automatically because my signing certificate was reaching it's expiration date. This feature - AD FS creating a new self-signed certificate when the old one nears expiration - is called Auto Certificate Rollover.

When using self-signed certificates, auto certificate rollover is on by default.
AF FS will use the signing certificate marked as 'Primary' to sign issued tokens.
The only thing I need to do is adding the new certificate to the trusted issuers collection as shown below:

 

Note: The reason why my sample failed is that I use the out-of-the box 'ConfigurationBasedIssuerNameRegistry' class to resolve the trusted issuer. This class uses the certificate thumbprint to match certificates. Obviously the certificate thumbprint changed when auto certificate rollover issued a new signing certificate. You can avoid this by implementing you own class and for example use the subject name to match issuers.

After adding the thumbprint of the new signing certificate to the trustedIssuers section, the sample should work again ... unless ...

My signing certificate is a self-signed certificate, but the newly created certificate is not trusted on the WCF machine. This results in this error:

ID4257: X.509 certificate 'CN=ADFS Signing - WIN-BEJU5AI4TP7.pbdev.CODit.eu' validation failed by the token handler.

The self-signed signing certificate should be added to the trusted root store of the WCF machine. The action you need to take to make sure the certificate passes validation depends on the certificateValidation mode you use. Mine was set on chaintrust, so adding it to trusted root will do. If you use peertrust, add the certificate to the trusted people store. If you use custom it depends on your implementation.

 

Peter Borremans

Posted in: Security | WCF | WIF

Tags: , , , ,


February 10, 2012 at 9:20 PM

When developing applications that make use of Windows Identity Foundation - WIF (Microsoft's technology to deal with claims-based security in your services) you can encounter exceptions that are not very precise/clear.

In this blog post I will show the difference between WCF tracing and WIF tracing based upon a sample application that is made to fail. The sample application consists of a client calling a service by first obtaining a security token from AD FS 2.0 and then asking the service to enumerate the claims present in the security token. The client will show the claims enumeration as received from the service. 

When I run my application (both the host and the client) this is the result:

 

The window in the background is my ServiceHost, the window in the front is the client. When the client calls the service over transport security the presented claims are enumerated as expected, when doing the same over message security the communication fails.

We will try to find the root cause of the problem by looking into WCF and WIF tracing.

The first thing the seasoned .NET developer will think of is to go in the .config file of your service and enable WCF Tracing:

 

Let's have a look what helpful information we can find in the WCF tracelog and WCF message log after running the sample.

The trace log shows this exception:

 

The message log shows this SOAP fault:

 

Although we have some useful information, "Message security verification failed" and "Security token could not be authenticated" can have a lot of reasons. We are interested in more detailed information about what goes wrong in the communication between clients, AD FS 2.0 and the service.

To find more detailed information we can enable WIF Tracing. WIF tracing cannot be enabled by clicking 'enable' in the Service Configuration Editor tool like we did for WCF Trace. However the idea is similar.

We only need to add two things to our config file (can also be done via the Service Configuration Editor tool):
- A diagnostics source: Microsoft.IdentityModel
- A listener (shared or not)

 The Xml representation looks like this: 

<system.diagnostics>
    <sources>
...
      <source name="Microsoft.IdentityModel" switchValue="Verbose">
         <listeners>
           <add name="WIFListener" />
         </listeners>
      </source>
...
    </sources>
    <sharedListeners>
...
      <add initializeData="c:\...\wif.svclog" type ="System.Diagnostics.XmlWriterTraceListener, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="WIFListener" />
    </sharedListeners>
</system.diagnostics>

The Service Configuration Editor tool view looks like this:

 

That't all you need to do to enable WIF tracing.

Let's re-run the sample app with WIF tracing enabled and hit against the same exception...

After opening the WIF trace-file, I can see this information:

 

As you can see, WIF Tracing gives us a much clearer exception message:

"ID1038: The AudienceRestrictionCondition was not valid because the specified Audience is not present in AudienceUris.
Audience: 'http://localhost:8733/ClaimsEnumeratorService/'"

After checking the service config file, I can see that WIF is exaclty right :)

The audienceUri for my endpoint that uses message security is commented out.
Thanks to WIF tracing I can troubleshoot problems like this in a reasonable time, with only WCF tracing the exception details are just not enough to point you to the right direction.

Both WCF and WIF tracing are priceless for .NET developers...

 

Peter Borremans

Posted in: Security | WCF | WIF

Tags:


October 15, 2011 at 8:58 PM

The BizTalk Sever SDK comes with an interesting Pipeline component sample that allows executing Xsl mapping files in a pipeline.

This functionality can be of interest when the receive port or send port mappings are not executed at the desired time! Receive port mappings are executed after the pipeline execution, send port mappings are executed before the pipeline execution. Thanks to this pipeline component you get control over the exact time when a transformation gets executed.

Although this functionality can be very useful the code of this sample contains some problems that need fixing before using this in production environments.

Let’s take a look at the business end of the sample, the TransformMessage method (you can find the original sample code in this location: <BizTalk installation directory>\SDK\Samples\Pipelines\XslTransformComponent):

 

private Stream TransformMessage(Stream stm)
{
	 MemoryStream ms = null;
	 string validXsltPath = null;
 
	 try 
	 {
  		// Get the full path to the Xslt file
  		validXsltPath = GetValidXsltPath(xsltPath);
  
  		// Load transform
  		XslTransform transform = new XslTransform();
  		transform.Load(validXsltPath);
    
  		//Load Xml stream in XmlDocument.
  		XmlDocument doc = new XmlDocument();
  		doc.Load(stm);
    
  		//Create memory stream to hold transformed data.
  		ms = new MemoryStream();
   
  		//Preform transform
  		transform.Transform(doc, null, ms, null);
  		ms.Seek(0, SeekOrigin.Begin);
 	}
	catch(Exception e) 
 	{
  		System.Diagnostics.Trace.WriteLine(e.Message);
  		System.Diagnostics.Trace.WriteLine(e.StackTrace);
  		throw e;
	}

 	return ms;
}


The signature of the method accepts a Stream as input parameter and returns a Stream as result. Perfect to keep everything streaming…

Then a XslTransform object is created. At first, this might look like a good idea, but XslTransform will load the message into memory internally! For smaller messages this will not cause any issues but bigger messages will cause a System.OutOfMemoryException…

To get rid of this problem I replaced the XslTransform class with the BTSXslTransform class. This class uses the BizTalk transformation engine. The BizTalk transformation engine will only load small messages into memory and will use disk space if the message size reaches a certain threshold.

 

The following line instantiates the BizTalk mapper engine (add a reference to Microsoft.XLANGs.BaseType)

BTSXslTransform trans = new BTSXslTransform();


Use the following line to execute the transform:

trans.ScalableTransform(inputReader, null, vs, new XmlUrlResolver(), false)

 
The following problem we encounter in the original sample is this section:

XmlDocument doc = new XmlDocument();
doc.Load(stm);

This section reads the stream into memory again via an XmlDocument.
I replace this section with this line:

XmlTextReader inputReader = new XmlTextReader(stm);

Instead of feeding the message to the transform method as one memory chunk, I present it a stream that can be pulled by the BTSXslTransform object.

There is one last thing to change in this sample to make it suitable for large messages:

ms = new MemoryStream();

A MemoryStream is used to store the result of the transform operation. Unfortunately a MemoryStream uses memory to store the stream. This makes it unusable for large messages.

Luckily BizTalk Server comes with a stream class that has the same functionality as MemoryStream but one that uses disk space to store large streams. This class is the VirtualStream class (add a reference to Microsoft.BizTalk.Streaming).

Instantiate a VirtualStream object to hold the result of the transformation:

vs = new VirtualStream(VirtualStream.MemoryFlag.AutoOverFlowToDisk);

The AutoOverFlowToDisk instructs this stream to use disk space for large messages.

 

The changed TransformMessage function now looks like this:

 

private Stream TransformMessage(Stream stm)
{
 	VirtualStream vs = null;
	string validXsltPath = null;
  
 	try 
 	{
  		// Get the full path to the Xslt file
  		validXsltPath = GetValidXsltPath(xsltPath);
  		XmlTextReader stylesheet = new XmlTextReader(validXsltPath);

		// Load transform
		BTSXslTransform trans = new BTSXslTransform();
		trans.Load(stylesheet);

		XmlTextReader inputReader = new XmlTextReader(stm);
                    
  		//Create memory stream to hold transformed data.
  		vs = new VirtualStream(VirtualStream.MemoryFlag.AutoOverFlowToDisk);
                
  		//Preform transform
		trans.ScalableTransform(inputReader, null, vs, new    XmlUrlResolver(), false);
    
  		vs.Seek(0, SeekOrigin.Begin);
 	} 
 	catch(Exception e) 
 	{
  		System.Diagnostics.Trace.WriteLine(e.Message);
  		System.Diagnostics.Trace.WriteLine(e.StackTrace);
  		throw e;
 	}
  	return vs;
}

 

When this code is compiled into a pipeline component, it allows executing large transformation exactly where you want it in the BizTalk pipeline infrastructure. This component will keep memory consumption flat, even when processing very large Xml files.

 

The source code of this article can be downloaded from this post as attachement.

 

XslTransform.zip (30,62 kb)

 

Peter Borremans

Posted in: BizTalk | Performance

Tags:


November 30, 2009 at 7:28 PM

This article http://msdn.microsoft.com/en-us/library/cc558565(BTS.10).aspx explains how to optimize network performance for BizTalk servers.

I tested this BizTalk network optimization on a SQL Server cluster.
The result was that the SQL server was significantly faster than 3 other reference servers!
After removing the optimization, the SQL server (that was faster before) performed exactly the same as the other 3 reference servers.
The performance gain was most visible in response times (30% faster on our test environment, for small queries). If you have to setup a low latency environment, this network optimization can help lowering latencies.

Peter Borremans