Monday, August 27, 2012

Reliving "Revolutionary" with Windows 8

"What do you think of Windows 8?"   I hear this question all the time... everywhere I go.   I hear people talking about it on the bus, in line at coffee shops, and even in odd places like hospital rooms.  It's the biggest change we've had in the PC in well more than a decade.  Everyone knows this is as big as broadband in everyone's home.

But... more than a decade?   Really? 

Definitely.  How old would a child be if it was born the last time there was a *true*, major version iteration of Windows?   3?  8...? 

How about...  18?   Yeah...  18... old enough to drive.  Old enough to be looking at colleges. The Daytona (Windows NT) / Chicago (Windows 95) user experience, were it a child, would now be looking at an opportunity to suffer the choice between Romney or Obama.  The experience unleashed on IT and the public introduced us to the Start menu, the Desktop, managed application installs, and several other major features that the enterprise and private user alike have now literally grown up on.

Some might argue that Windows XP was a hefty revision that almost qualifies, but I would say not so much.  Improvements abounded, but the core user experience hasn't changed by more than revision increments in Windows 98, ME, 2000, XP, 2003, 2008, 7... really...  since Windows 95. 

But, with Windows 8, this changes.  Windows 8 brings us a whole new user experience in the "Modern UI" formerly known as "Metro UI". 

If you recall, Windows 95 still essentially lived on top of DOS, and had enough of the Windows 3.x framework to run all the apps we'd already come to depend on (like Word 6, Excel 5, and Windows AOL 2.5).  While those programs ran in Chicago, there were compatibility issues, and the user interface really started to look crusty on legacy applications.  I was actually a relatively late adopter, waiting until Windows 98 before I finally succumbed to the dark side. (I had discovered IBM OS/2 Warp and become a fan... it actually took a 1-2 punch to Warp to get me to switch.  1:  When Warp was stable, it was unbeatable, but when it crashed it was unrecoverable, (and crash, it inevitably did).  2:   Command & Conquer / Red Alert, which had an improved video mode that was only available when installed in Windows... and it was even more awesome in that improved resolution mode. )

Just like Windows 95, Windows 8 is a transitional OS.

One of the big things I keep hearing about Windows 8 is... what a P.I.T.A. is is to figure out. "Microsoft is taking a huge risk with this... why are they breaking my Windows?", I hear.  Or...  "I'm open-minded.  I subjected myself to it until the pain became unbearable.  (I can't wait until Mac OS X takes over.)"

Transition, though?  Yes.  Transition.  Again, this is the first real full version increment of the Windows user experience that we've seen in years, and it all comes down to this Modern UI thing.  It does exactly what Windows 95 did to Windows 3.x on DOS.  It wipes the slate clean and re-imagines how we operate our computers from the ground up using modern human interface devices... (HIDs). 

Touch screen, movement, gestures, enhanced 3D graphics... these are things that started to accelerate development not long after the release of 95, but the world was still on the Windows 95 learning curve.  Hardware was too immature & expensive to develop an OS around them then... So, while you were getting comfortable with your desktop, (if you haven't noticed) your cell phone's user experience surpassed your desktop.

So on the surface (no pun intended) this is what Windows 8 is...  it's a full OS-deep refresh that catches home computing back up to what people have gotten used to in their cellphones.

"Common sense" says this all implies a true P.I.T.A. for people and companies that dig in on it. 

Let's look a little deeper, though, at what else this represents.  Again, this is a transitional OS.  It does everything the old user experience did... if you dig a bit.  It does this to support the old applications with their freshly encrusted-feeling user experience.  People can continue leveraging your old technology investments.  Indeed, you can continue making investments in the old user experience...  just know that the writing's on the wall. 

It's only a matter of time before people do what they inevitably did with Daytona/Chicago... adopt, extend, and embrace, or be extinguished.  

Why?  Because... when it comes down to it, the part that people really hate is not the "user experience" part.   It's the "NEW" part that hurts.  Once the "NEW" wears off, what you've got left is a really genuinely cleaner, better, more efficient UI that leverages new hardware in important ways, and puts it years ahead of desktop OS competition, both in terms of capability, and even in terms of price point...  and pushes that same advantage out seamlessly to a myriad of other devices.  So getting past the sharp learning curve on one device means you'll be rocking the new UI everywhere in no time.

Like the glory days of the Dot-Com boom, the days of Daytona & Chicago, these will be days of learning and technical renovation, even re-invention.  This is what I see coming with Windows 8 in the desktop, with an added benefit of being even more ubiquitous than it was back in the 90's.  With the coming of Surface, Windows Phone 8, your apps will have more opportunity to run in more places, on more machines, than ever before.... using more "Star Trek" functionality than we're yet used to. 

Those looking to remodel that kitchen... here's your wake up call.  Windows 8's user experience is representative of what made the Dot Com days so great... (and there were some plus sides.)  It was when leveraging any of the revolutionary new technology became a competitive advantage all by itself.  Early adopters will feel the pinch of the initial investment, but... with some planning, will reap the rewards by having that pain behind them by the time Windows 9 rolls around. 

I, for one, look forward to my new OS overlord.

Friday, August 17, 2012

Using Client Certs to Pull Data from WCF in SSIS Data Flow Transform Script

I've recently had the opportunity to brush off my SSIS skills and revisit this toolset.   In my most recent usage, I had a requirement to use SSIS to pull data from a WCF web service that was a) using the net.tcp protocol, and b) used transport security with a client X.509 certificate for authentication.

This was fun enough by itself.  Configuring WCF tend typcially to be non-trival even when you don't have to tweak app.config files for SQL SSIS services.  One of my goals, in fact, was to avoid having to update that, meaning I had to put code in my SSIS Script block in the data flow to configure my channel & security & such.

Luckily, I was able to find examples of doing this with wsHttpBinding's, so it wasn't a stretch to tweak it for netTcpBinding with the required changes to support certificate authenticated transport security.

Here's the code...
using System;
using System.Data;
using Microsoft.SqlServer.Dts.Pipeline.Wrapper;
using Microsoft.SqlServer.Dts.Runtime.Wrapper;
using System.ServiceModel;
using SC_13defb16ae45414dbac17137434aeca0.csproj.PaymentSrv;

public class ScriptMain : UserComponent
    ChannelFactory<IProfile> channelFactory;
    IProfile client;
    public override void PreExecute()

        bool fireAgain = false;
        this.ComponentMetaData.FireInformation(0, "Pull From Profile Service.PreExecute", "Service URI: '" + this.Variables.varProfileServiceUrl + "'", null, 0, ref fireAgain);
        this.ComponentMetaData.FireInformation(0, "Pull From Profile Service.PreExecute", "Cert Fingerprint: '" + this.Variables.varClientCertFingerprint + "'", null, 0, ref fireAgain);

        //create the binding
        NetTcpBinding binding = new NetTcpBinding();
        binding.Security.Mode = SecurityMode.Transport;
        binding.Security.Transport.ClientCredentialType = TcpClientCredentialType.Certificate;
        binding.Security.Transport.ProtectionLevel = System.Net.Security.ProtectionLevel.EncryptAndSign;

        EndpointAddress endpointAddress = new EndpointAddress(this.Variables.varPaymentServiceUrl);
        channelFactory = new ChannelFactory<IProfile>(binding, endpointAddress);

            //" x8 60 66 09 t6 10 60 2d 99 d6 51 f7 5c 3b 25 bt 2e 62 32 79");

        channelFactory.Credentials.ServiceCertificate.Authentication.CertificateValidationMode =
        //create the channel
        client = channelFactory.CreateChannel();

        IClientChannel channel = (IClientChannel)client;

        this.ComponentMetaData.FireInformation(0, "Pull From Profile Service.PreExecute", "Open Succeeded.", null, 0, ref fireAgain);


    public override void PostExecute()

        //close the channel
        IClientChannel channel = (IClientChannel)client;

        //close the ChannelFactory


    public override void Input0_ProcessInputRow(Input0Buffer Row)
        Guid txGuid = Guid.NewGuid();
        Profile profile = null;
            profile = client.getProfile(txGuid, Row.ProfileId);
            Row.PSProfileType = GetProfileType(profile);
        catch (Exception ex)
            string message = ex.Message();
            Log(message, 0, null);
    private string GetProfileType(Profile profile)
        return "x";
So one of the challenges I encountered while using this method had to do with the client certificate.  This error drove me nuts:

The credentials supplied to the package were not recognized.
Server stack trace:
   at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc)
   at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential)
   at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte[]& thumbPrint)
   at System.Net.Security.SecureChannel.GenerateToken(Byte[] input, Int32 offset, Int32 count, Byte[]& output)
   at System.Net.Security.SecureChannel.NextMessage(Byte[] incoming, Int32 offset, Int32 count)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost, X509CertificateCollection clientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation)
   at System.ServiceModel.Channels.SslStreamSecurityUpgradeInitiator.OnInitiateUpgrade(Stream stream, SecurityMessageProperty& remoteSecurity)
   at System.ServiceModel.Channels.StreamSecurityUpgradeInitiatorBase.InitiateUpgrade(Stream stream)
   at System.ServiceModel.Channels.ConnectionUpgradeHelper.InitiateUpgrade(StreamUpgradeInitiator upgradeInitiator, IConnection& connection, ClientFramingDecoder decoder, IDefaultCommunicationTimeouts defaultTimeouts, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.AcceptPooledConnection(IConnection connection, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Open()
Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at System.ServiceModel.ICommunicationObject.Open()
   at ScriptMain.PreExecute()
   at Microsoft.SqlServer.Dts.Pipeline.ScriptComponentHost.PreExecute()
If you look at it, this is an authentication error.  Tracing the code, it happens AFTER the code successfully retrieves the client certificate from the certificate store.  The call to SetServerCertificate succeeds without incident.

The error hits  when the code opens the channel, and tries to use the private key attached to the client certificate to prove to the server that "I'm a valid client."

I went nuts because I was an administrator on the machine, and had installed the client certificate to the certificate store myself.  It initially worked, and there was no indication that there was a problem getting the certificate from the cert store.

It turns out that when you use the machine store under these circumstances, I needed to give myself explicit permission to the client certificate in order for the SetServerCertificate to get the private key along with the client certificate.  This was counter-intuitive for two *additional* reasons:  1)  I was an administrator on the box, and already should have had this permission by the fact that my login account belonged to the administrators group (which you can see from the pic below, also had access.)  2)   It worked the day before.  When I imported the private key originally to the key store, it appears somewhere in the depths of Windows 7 (and this applied on Server 2008 R2 as well) I still had permission in my active session context.  When I logged out, that login context died, and, coming back the next day, I logged in again, not realizing I wouldn't be able to access the key.  Giving myself explicit permission as shown below allowed me to run my SSIS package within Visual Studio and from SSMS.
(Sorry, Blogger's not letting me include this bigger... click it for full size view.)

Tuesday, August 7, 2012

Microsoft Announces Windows Phone Dev Center

I've learned a few things in the past months in working with the SharePoint community.  Namely, if you don't have something nice to say, don't say anything at all.  In today's age of social media meeting business networking, this is more important than ever.  

I hope, however, that Microsoft's Windows Phone Dev Team forgives me for the tough love I dished out on them back in May.  (I won't even link to that post.)  

I love developing apps in Silverlight & C# for my phone, and I'm so happy to see an update that directly impacts us App Developers...  

Here's the Windows Phone Developers Blog:

Here's the great looking new app publisher's experience for Windows Phone Developers:

I haven't fully explored it yet, but at first glance, it looks much more like the excellent developer's & publishers' experience I've come to take for granted from Microsoft... I can't wait to explore it more and see how it all came together.