Surface Power Supply Fix

New Surface hack: Using a power cord from a printer instead of the provided outlet cord.

My Surface 3 power adapter has recently stopped working. There are 2 parts to it – the part that connects to the device and the part that connects to the outlet. These both connect together to form the power supply. For a while I had trouble with the combined parts and it only worked again when I rammed the 2 parts together to form a very strong connection. The combined parts stopped working today.

After looking at the part that goes to the outlet I realized it looked just alike to power adapter used with most printers. So I swapped it out with my printer cord and my Surface is charging again!

This should be a much better replacement part than buying a whole new Surface power adapter for up to $100. Just find your HP printer (or buy a super cheap one anywhere) and use this part instead.

I will add some pictures here soon.

BizTalk PowerShell Provider officially updated

A few days ago I blogged that I had put together an unofficial update to the BizTalk PowerShell Provider. I joined up with the project on CodePlex and they put me to work quick!

Tonight I checked in some updates and now we have a new release,, which works on BizTalk 2013. I will be taking down the link for the unofficial release now. Please try it out and report any issues on the CodePlex site.

Please let me know if you have any suggestions for new cmdlets. I have a couple ideas I am going to be working on and will also be working on expanding the documentation and examples. I am also interested in making some cmdlets that work with the BizTalk Services components of Windows Azure.


BizTalk PowerShell Add-In updated for BizTalk 2013

I was working on building out the BizTalk 2013 environments for a client when one of the guys in IT mentioned that the BizTalk PowerShell snap-in was not updated for working with BizTalk 2013. The CodePlex site at mentions the currently released version only works on BizTalk 2010.

So I downloaded the source and rebuilt from my BizTalk 2013 VM. I only had to go through the migration wizard and install WiX to get all of the projects to build. Then I ran the installer and started using it from a PowerShell prompt. It appears to be working fine to me. I uploaded the file as PSBizTalk BizTalk 2013 Verison 0.1 to my SkyDrive. (update: I updated the provider officially on CodePlex. Please go to the release page).

I did not increment the version information or do anything else you might expect would be done, just rebuilt it into the MSI so you can use it in your BizTalk applications. Please let me know if you try out the updated version and if there are any issues.


Ben Cline

BizTalk 2013 RTM is out now!

The latest full version of BizTalk was released yesterday to MSDN. Here is the official announcement: General availability is coming up soon.

I downloaded the Standard edition from MSDN yesterday but the Developer edition has not made it to MSDN yet.

There are many new and improved features but the ones I am most excited about are the improved ones. The new features are primarily around updates to the platform for working with the cloud and working with the latest versions of the underlying technologies and tool versions.

A comprehensive list of the updates is available at: Microsoft has done a good job of continuing to release updates for BizTalk through the cumulative updates. But there are often things about the product that you wish could change. In the 2013 release there are many updates that fix some of these architectural annoyances.

For example, dynamic send ports have always run under the default host for the adapter which led to unusual errors and problems when different hosts have separate accounts. I once worked for a customer that wanted to reduce the attack surface of his BizTalk hosts by running each one under a separate account. Unfortunately the customer used dynamic send ports extensively and these all executed under the same account across all of the BizTalk applications. This behavior was a problem because we had to set NTFS permissions on the paths the dynamic send port used but kept using the wrong account to set this. This problem has been overcome in the 2013 release.

Another improvement in the new product is the ESB toolkit is now part of the main product and there are much fewer steps to deploying the ESB Toolkit. In BizTalk 2010 the ESB Toolkit setup often took a full day to a couple days to setup properly unless you scripted it yourself. Having the toolkit baked into the main product is a real time saver and will make it easier to deploy BizTalk solutions.

It is great to see the new version of BizTalk because it is a reminder of Microsoft’s long-term commitment to BizTalk customers.

Changes in ADFS 2.1 from ADFS 2.0

Well it has been a while since I last posted. I have been sitting on a couple things and wanted to get this information out there.

Recently I had to work on an ADFS 2.0 to 2.1 migration. There is apparently not any supported easy way to upgrade an ADFS environment to work on Windows Server 2012 with SQL Server 2012. I had to recreate all of the ADFS artifacts such as claim provider trusts, relying party trusts, attribute stores, etc. This is a little painful if you created all of these manually but is much easier if you have saved off PowerShell scripts for creating these objects.

In this post I am blogging about the changes I uncovered working with ADFS 2.1. Most of the changes to ADFS in 2.1 are relatively trivial. In my experience almost everything appears the same in the user interfaces for ADFS. Now the ADFS installation is a role rather than a separate hotfix installer and is part of the base Windows Server 2012 install.

If you have saved off any scripts or other tools for working with ADFS 2.0, you will need to update these for ADFS 2.1. Changes that will be required are:

  • The ADFS PowerShell snap-in is no longer required to be added manually. This was my experience with having the PowerShell 3.0 feature installed. So any lines such as the following lines below can just be removed:

Add-PSSnapin Microsoft.ADFS.PowerShell
Remove-PSSnapin Microsoft.ADFS.PowerShell

  • Also, the PowerShell 3.0 ISE tool now includes Intellisense-like support so it is possible to enter cmdlet arguments much easier. This is a huge help.
  • The folder of the ADFS files is now at C:\Windows\ADFS rather than C:\Program Files\Active Directory Federation Services 2.0. If you use a script to call fsconfig.exe you will need to update the script with this new path to fsconfig.exe.
  • The custom claim rules policies base class is now in a .NET 4 assembly so you will be required to update all assemblies that reference this base class to .NET 4.0. So any classes that derive from Microsoft.IdentityServer.ClaimsPolicy.dll must have their build configuration updated to be .NET 4.0 or later.


I did find another change with ADFS 2.1. If you have made any customizations to the web.config file of the ADFS virtual directory, you will need to update the version details in the web.config as well as remove the reference to Microsoft.IdentityModel. What I did to update this file was to do the following find/replace tasks on the web.config:

  • Update version details to
  • Update version details to

I will keep updating this page with any other changes I find with ADFS 2.1. Thanks!

Workaround for Kerberos SSPI Context Errors in BizTalk

A couple weeks ago one of my clients was experiencing constant “Cannot generate SSPI Context” errors in BizTalk. These are Kerberos errors and they are extremely annoying because they happen constantly whenever you are trying to use any database function with BizTalk. These would fill up the event logs on my client’s server and was a huge time waster because they would prevent me from doing just about anything with BizTalk.  I would receive these errors when trying to start a host or change almost anything in the BizTalk admin console. I think the source of the problem is that something about the domain membership was different than some of the accounts on the server and this led to Kerberos authentication problems.

As a temporary fix I was able to restart the BizTalk server but the errors eventually came back again. The errors basically paralyze a BizTalk server and they are complicated to diagnose and sometimes you just do not have enough time to do diagnostics – like in a production environment. The fix provided next is similarly a workaround, it does not solve the root problem but at least provides another way to get the server working.

To attempt to resolve the problem, I tried a couple different things such as removing the server from the domain and adding it back in, but none of these things were successful at removing the problem completely. I did also try switching my Enterprise Single Sign On account and master key but this did not conclusively solve the problem.  I was looking at the article at and tried some of the suggestions but was not getting anywhere. Then I tried disabling TCP/IP for SQL connections and just use named pipes based on using SQL Configuration Manager or the SQL Network Configuration tool. TCP/IP seemed like such a fundamental protocol that I was not optimistic the problem would go away by switching protocols, but it worked for me. Many people also think that named pipes only works on a single server and functions like IPC but this is not exactly right.

My use of this workaround was on BizTalk 2010, W2K8 R2, with SQL 2K8 R2 when SQL is on a separate server than BizTalk.

The KB article above solely mentions this workaround in the context of SQL and Kerberos so I am blogging that this fix is working for me on my BizTalk server too. ‘


Changing ADFS Proxy App Pool Account

A few days ago I was working on finishing up an ADFS implementation and I had customized quite a bit of the built-in ADFS website pages. I needed to use Windows authentication to access a database, and I realized that the ADFS Proxy website app pool by default runs under Network Service. This was troubling because I did not want to grant permissions to Network Service in the database so I needed to modify this account.

I went through the standard stuff to modify the app pool identity and got this error:

Encountered error during federation passive request.

Additional Data

Exception details:

System.IO.FileNotFoundException: Error reading the C:\Program Files\Active Directory Federation Services 2.0\PT directory.

at System.IO.FileSystemWatcher.StartRaisingEvents()

at Microsoft.IdentityServer.ProxyTrust.ProxyTrustManager.StartTokenWatch()

at Microsoft.IdentityServer.ProxyTrust.ProxyTrustManager.get_Current()

at Microsoft.IdentityServer.PolicyModel.Client.PolicyStoreReadOnlyTransferClient.GetServiceChannel()

at Microsoft.IdentityServer.PolicyModel.Client.PolicyStoreReadOnlyTransferClient.GetState(String serviceObjectType, String mask, FilterData filter, Int32 clientVersionNumber)

at Microsoft.IdentityServer.ProxyConfiguration.ProxyConfigurationReader.GetServiceSettingsData()

at Microsoft.IdentityServer.ProxyConfiguration.ProxyConfigurationReader.GetFederationPassiveConfiguration()

at Microsoft.IdentityServer.Web.PassivePolicyManager.GetPassiveEndpointAbsolutePath()

at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.GetPassiveEndpointAbsolutePath()

So I opened the path at “C:\Program Files\Active Directory Federation Services 2.0\PT” which is the folder for the stored proxy token and granted full control to my domain account user. The file written to this directory is constantly updated, so the account does need to be able to remove the file. By default the Network Service account has full control, most likely because the ADFS proxy Windows service also runs under Network Service.

Then I just restarted IIS and this worked.


CRM 4 adapter works with BizTalk 2010

A couple months back I did a test for a client about whether the legacy Dynamics CRM 4 adapter would work successfully on BizTalk 2010. I know this is not the recommended configuration and that the CRM 2011 SDK does not mention this as an acceptable or supportable configuration. Many companies have made a significant investment in CRM 4 and may not be able to upgrade their CRM software. So I am just putting this information out there in case you are wondering.

Others have reported needing to use a registry workaround for getting the adapter to install for BizTalk 2009: I followed this workaround with BizTalk 2010 on Windows Server 2008 R2 and it worked fine. The CRM 4 adapter install worked fine. I was also able to run the schema creation wizard in VS 2010.

I did not try running the software in this configuration in a production environment and have not tested this configuration completely. But usually in my experience if the install works fine and the designers still work in VS then you can probably work with this configuration, if only for a temporary workaround while you create a migration strategy.


Export Powershell Objects to Xml – in a more natural format than Export-CliXml


On a recent project I was calling a PowerShell script and wanted to return Xml from the script so that I could iterate on an object using Linq to Xml. I investigated options available for exporting an object in Powershell to Xml and looked at some built-in cmdlets like Export-CliXml:, but I could not get over how complicated my Linq to Xml query would have to be for relatively simple objects. The Export-CliXml format is extremely verbose and is not really easy to work with once you get the Xml out.


The following snippet shows how to output the Xml and uses custom serialization to Xml for the SamlEndpoint type which shows up as the type name until you drill into the type to get the property information.

function DumpObjectToXml($obj) {
$a = $obj

$openingTag = "<" + $a.GetType().Name + ">"

$ret = $ret + $openingTag

Get-Member -InputObject $a -MemberType Properties | ForEach-Object {

$CurrentName = $_.Name

$a.GetType().GetProperties() | ? { $_.Name -eq $CurrentName } | ForEach-Object {

$specialSerialization = $false

# Handle specialized serialization for object properties of parent object

if ($_.Name -eq "SamlEndpoints") {

if ($obj.SamlEndpoints -ne $null) {

$d = $obj.SamlEndpoints | ? { $_.BindingUri -like "*HTTP-POST" }

$val = $d.Location.AbsoluteUri

$specialSerialization= $true


else {

$val = ""



if ($_.CanRead -eq $true -and $specialSerialization -eq $false) {

$val = $_.GetValue($a, $null)



$out = "<" + $_.Name + ">" + $val + "</" + $_.Name + ">"

$ret = $ret + $out


$closingTag = "</" + $a.GetType().Name + ">"

$ret = $ret + $closingTag

return $ret


This can be helpful for outputting a list of objects returned by another cmdlet as Xml. Here is a simple example that builds a usable Xml element for the relying parties returned from the built-in ADFS cmdlet:

$rpOut = "<RelyingPartyTrusts>"

Get-ADFSRelyingPartyTrust | ForEach-Object { $rpOut = $rpOut + (DumpObjectToXml -obj $_) }

$rpOut = $rpOut + "</RelyingPartyTrusts>"

The resulting output looks like this:

<ClaimsAccepted>Microsoft.IdentityServer.PowerShell.Resources.ClaimDescription Microsoft.IdentityServer.PowerShell.Resources.ClaimDescription</ClaimsAccepted>


This technique of using objects returned from PowerShell can be very valuable when you want to report on objects that may only be exposed through a PowerShell interface and no supported or available .NET API. There are some limitations to this approach though. Not all objects returned from some cmdlets have properties that can be read in an isolated, atomic way. When trying this technique with Get-Process errors occur indicating the services must be stopped before reading the properties. I think this is due to the way the cmdlet is coded. I tested this script with many of the ADFS cmdlets and it is working well.

Blog at

Up ↑