SSL Certificates and Azure Web Apps

Use it or lose it. The good thing about getting a cert with a 3-year expiration period is that I don't have to worry about it for 3 years. The bad thing is that I forget how in the world I did it last time. I waited until the last minute (or last three hours) to renew a cert today for an Azure web app.

A call to GoDaddy support led to a statement saying that because Microsoft hasn't provided them with documentation, they can't provide their customers with assistance due to potential liability issues.

Of course, there are plenty of blog posts written about this in various forms, but even an Azure post wasn't quite helpful for my lack of knowledge in this area. But this one was. So glad people document things like this.

Tested with IE, Chrome, Safari...oh wait

When I start a new project, particularly when doing a POC, I'll often grab something I've done in the past that is similar and begin to tweak from there. But as POCs tend to evolve, problems occur when my assumptions remain the same. That "tested with..." disclaimer tag that came across from the borrowed project just won't cut it as is.

Case in point: a pretty important line of code that can help generate revenue. Turns out this didn't work with Safari / Chrome:

$('#btnSubmit').trigger('submit');

But this does:

$('form#ajaxForm').trigger('submit');

A good reminder to actually test and not assume. I'm glad I have a co-worker who has a knack for breaking things before customers do.

Priorities and getting things done

This morning I read an older but popular blog post on the duct tape programmer. It is colorful commentary that I've read it before and provides a good reminder on prioritization and getting things done.

There are, no doubt, occasions where you don't want the duct tape programming methodology used, for example when writing the software that keeps an airplane in the sky or a machine that keeps medicine flowing properly into your veins. But I don't work for a company doing those kinds of things. I'm part of a company that buys, sells and delivers building products. We're in an industry that is slow overall to use technology in order to gain competitive advantage and become more effective and profitable. So using "duct tape" here is actually pretty useful and necessary. To paraphrase Joe's post,

I'm not here to write code; I'm here to create value for this organization.

This mindset isn't about making a choice between value-added functionality wrapped in that lovely VB6 gray on the one hand (we have too many of those still in use, unfortunately), and useless but pleasant looking UIs on the other. The development tools and platforms today don't present that one-or-the-other choice. Conceiving, creating and putting into the hands of our business partners the tools that make a difference is paramount. And if it takes duct tape at times to help us do that, so be it.

Windows 8.1 App Mystery - controls randomly disappear but are still interactive

Late last year my team delivered a Windows 8.1 modern app to our outside sales force equipped with ThinkPad 10 tablets. There were bugs to be worked out, of course, and we've still got plenty to fix. But one problem has been truly discouraging given our inability to reproduce it.

The Problem

From time to time, we'd get reports from sales that the top third of screens in the app would simply disappear, leaving just the background of the screen. The weird thing was that the controls that disappeared were actually still interactive. If you knew where they were, you could tap them and do things. But a horrible user experience, especially when you're in front of a customer.

We even saw this problem ourselves on occasion but couldn't reproduce it. The only way to get around it was to close the app and reopen it.

Over time, we came to see that this problem generally occurred after the device had come out of sleep mode. One of our more observant sales reps pointed this out and stated that if he manually closed the app after each customer encounter, the next time he woke the device and used the app he rarely had the issue.

Reproducing the problem

I ran across two SO threads describing the same exact problem: here and especially here. We could actually reproduce the issue using the method he found:

"I can re-create the problem by going to task manager and creating a dump file for the running app. After I do this twice and resume the app, the two text blocks disappear."

He also described how the use of images was related to this problem. Sure enough, we were using an image for our app's background.

Fixing the problem

We removed the background image and instead used a simple Brush. At that point, we could no longer reproduce the issue using the steps above -- problem resolved.

I'm still not sure why the problem occurred in the first place. Possibly related to the lower memory devices (2GB)? Or maybe just something we were doing wrong in the app when trying to use a background image?

Deploying a modern app to a distributed sales force in a not-so-modern industry

Earlier this year a great opportunity came my way: the proof of concept WinRT app created to showcase the possibilities for our sales force was received favorably and my team was given the green light to make it a reality. We started preliminary design work in June, finished the first release in October, and we're currently wrapping up the second release that includes order entry capabilities.

Project Goal

The goal was pretty ambitious given the short time frame and its impact on 150+ sales reps throughout North America:

• Distribute new ThinkPad 10 devices running Win 8.1 Pro with WWAN service.
• Convert the reps to Office 365 in the process.
• Deploy an easy-to-use, touch-first sales intelligence app that provides far more actionable information about our customers than ever before available in the field.

Regarding the sales intelligence app, it certainly helped to have had previous experience creating an occasionally-connected Win 8 app. Here's an overview of the new sales app:

Functional highlights

• Daily engagement list at the rep's fingertips for easy access to customer information.
• Graphical sales trends, filterable by product segments.
• Recent history of quotes and orders for a rep's customer base.
• Rich customer profile info, including sales history and trends, AR and aging data, contacts, quote and order history, even recent history of customer phone interactions with our inside sales.
• Real-time inventory and pricing data on all products.
• Ordering capabilities.

Technical highlights

• Lenovo's ThinkPad 10 device running Win 8.1 Pro, joined to the domain.
• Designed as an occasionally-connected app using SQLite for caching data locally, with a variable refresh schedule so that more static data is cached for longer, while volatile data is refreshed more frequently.
• WinRT (C# / XAML).
• CSLA.NET framework for encapsulating all business logic, not to mention the built-in plumbing necessary to support our 4-tier architecture.
• MVVM Light toolkit.
• RayGun error and crash reporting service.
• Telerik's UI controls for Windows Universal apps
• SCCM for managing deployment, as this is not distributed through the Windows Store.

Other highlights

• The ThinkPad 10 device replaces the sales reps' existing desktops and/or laptops. Given that it runs Win 8.1 Pro, we've even loaded some of our legacy apps onto the device, while other legacy apps are accessed via VMWare's VM View remote solution. It's going to be an adjustment for our sales reps...time will tell.
• This project has certainly helped push our small development group further along to thinking about application design in a more modern way, using newer technologies, frameworks and toolkits.
• The benefits of the CSLA .NET framework show yet again that our investment in learning and adopting the framework has proven valuable, as we can easily leverage our knowledge to build maintainable applications with lower cost.
• RayGun, if you've not checked it out, is quite handy. It allows us to be notified of errors encountered by our distributed users before our help desk even hears about it. It pays to read Hanselman. 
• This app provides a modern experience that parallels our 20 year old legacy order entry app (still VB6 to this day). It has been a great exercise for our IT group and users to be challenged to think outside of the way-we've-always-done-it box. Old paradigms didn't work with a touch-first app, so creativity was required. At the same time, 20 years of an actively developed application reveal that a lot of thought was put in to it by a lot of smart people during that time.

IIS 7.5 + Windows Authentication: some users still getting prompted for credentials

It has been a while since I created an intranet web app that uses Windows Authentication. I recently ran into a problem where some users were able to authenticate correctly while others were prompted for credentials. I spent a lot of time checking and verifying a number of things in the process of trying to figure this out:

Settings Checked

IIS Authentication settings

Made sure Anonymous was disabled, Windows Authentication was enabled.

I saw a number of sites that said to bump up NTLM to the top of the Providers list…which isn’t recommended. (Didn’t work anyway.)

Web.config Settings - made sure the settings were correct there:

<authentication mode="Windows" />
<identity impersonate="false" />

Browser-based settings for users who were prompted for credentials:

Also added the app to the Trusted Sites just to make sure.

Solution

I realized that setting Windows Authentication in IIS causes the current user’s identity to be used when the site’s files are accessed on disk. In the case of the users who were prompted, they weren’t in an AD group that had permission to the root directory. But granting access to the root folder isn’t an option for security reasons, especially if you’re storing a database connection string in the web.config file.

Thanks to this post, I learned IIS 7.5 has a setting that forces IIS to utilize another identity for disk access even when Windows Authentication is utilized. The key is to set the authenticatedUserOverride option to use the “UseWorkerProcessUser” value. Of course, make sure the worker process has permissions to the app's directory.

One more thing

User.Identity.Name no longer works once the change is made. To compensate, you can use the altnerative: Request["LOGON_USER"].

No endpoint listening: WinRT calling a WCF service on the corporate network

Scenario: WinRT app interacting with CSLA business objects hosted in a WCF service on an app server in the corporate domain.

As is typical, early in development the data portal is hosted locally on my dev machine. And the transition to hosting the data portal on a separate app server is generally straight forward. But with this WinRT app, the first I've done for the corporate environment, I ran into this problem:

Drilling down, the inner-most exception message was actually this:

"An attempt was made to access a socket in a way forbidden by its access permissions."

But everything was set up the same way my recent MVC projects have been set up. All permissions in IIS were correct.

The problem, it turns out, was not with IIS or the remote data portal. This article pointed to the necessity of declaring the right capabilities in the WinRT app's package manifest.