Monday, 27 February 2017

Test connection to remote SQL Server Database from an Application server

While aiming to test whether a SQL connection is succeeding between an Application server and a remote Database Server, it is often not possible to install SQL Server Management Studio (SSMS) or Microsoft Command Line Utilities (MsSqlCmdLnUtils) due to the locked down nature of the targets, particularly in test and production environments.

A lightweight approach that worked for me recently, makes use of components that have been a part of windows boxes for a long time, albeit different levels of database driver support as the components have evolved, the Microsoft Data Access Components (MDAC).

MDAC provide a Universal Data Link, which can be configured using a common user interface for specifying connection properties as well as testing the connection.

 Data Link properties dialog box

Get started – Create a simple text file

Simply create a .txt file anywhere on your system

  • rename the extension to .udl

Double click the Universal Data Link file (.udl)

We are then presented with the Data Link Properties dialog, which will look very familiar.

Using either Windows Integrated Security or a specific Username / Password combination the connection to the database can be tested.

You can also save your configuration settings you have applied by just selecting ‘OK’ on the properties dialog, useful for reoccurring scenarios, more complex configurations or just as a handy utility for future reference.

Using this approach, i was able to determine very quickly that the password for a test environment database had been changed in just a few minutes.


Feel free to contact me via my site AssemblySoft to discuss any ways i can help with your next project...

Monday, 13 February 2017

Debugging a Batch Script, managed by the Windows Task Scheduler (Part 1)

I was contacted recently with an interesting problem that had arisen for a client where a batch script was not working as expected and silently failing in a production environment. It was being run by the Windows Task Scheduler which was reporting a '1' return code from the Task:Action history. As the script was configured to run silently there was no easy way to see what was going wrong. The Event Log did not contain anything useful and unfortunately the batch script didn't contain any logging statements. There was also a strong desire not to install any remote tooling or alter the code as it had been working previously and was currently servicing.

I thought i would share the steps taken to identify and fix the issue as it is not uncommon to be faced with a black box, which seemingly doesn't offer much at first glance, but with a little investigation, the lights can soon be turned back on.

Understanding the Stack

After some investigation it became clear that apart from 'always getting given the fun stuff' the batch script was calling python scripts, via the python runtime, which in turn called out to .Net components via Iron Python.

The basic setup of the scheduler with the task running the scripts can be seen in the screenshot below.

Looking Forward

Have put this article together in two parts. This part 1 focuses on obtaining the errors from the batch script. The second part looks at extracting the errors from the python and .Net layers.

The Solution

Something in the stack was failing but it was unclear what.

The first thing i proceeded to do was make a backup of the existing task by performing an export. This ensured we had all the properties and settings stored and provided a way back should it be required. I then used the exported properties to create a new task, essentially a copy that could be used to debug. Every care would now be required to ensure that any additions were on a read only basis in terms of affecting flow and data. After disabling the failing task it was time to get some output from the script by adding some Echo statements.
The Task Scheduler provides an 'Add Arguments' text box where i attempted to pipe the output to a text file using > c:\logs\dailyTasks.log

This gave me an initial win where i could see my newly entered echo statements from the batch file but no actual errors. 

After some digging i added 2>&1 to the end of the argument list and voila, an error appeared in my log. Unfortunately the error was still rather cryptic and not very meaningful.

I also added double pipe (>>) to 'append' rather than 'overwrite' which proved to be useful to see progress.

So the arguments to the batch file now looked as follows:
>> c:\logs\dailyTasks.log 2>&1

For those in a more traditional setup, this article will hopefully add a little help to getting the actual errors being reported from a batch script, being run and managed  by the Windows  Task Scheduler. This journey still has a way to go and for those interested in the Python and .Net integration, please read on in Part 2.


Feel free to contact me via my site AssemblySoft to discuss any ways i can help with your next project...

Friday, 3 February 2017

ASP.Net Core 1.1 DOS Vulnerability

January 2017 Update for ASP.NET Core 1.1

Yesterday, Microsoft released an update for ASP.NET Core 1.1 due to Microsoft Security Advisory 4010983. The advisory is for a vulnerability in ASP.NET Core MVC 1.1.0 that could allow denial of service. 

Affected Software

The vulnerability affects any Microsoft ASP.NET Core project if it uses the following affected package version.
Affected package and version
Package name
Package version

Advisory FAQ

How do I know if I am affected?
ASP.NET Core has two different types of dependencies, direct and transitive. If your project has a direct or transitive dependency on Microsoft.AspNetCore.Mvc.Core version 1.1.0 you are affected.
Full details of the advisory can be found here:
Further details on how to obtain the update and instructions for install can be found on the .Net Core Blog:
Although we are so excited about cross platform development with our favourite tooling and embracing .Net Core, it keeps us mindful that we are still in the early stages of the journey and should consider carefully when choosing whether now is the right time to embark on a full blown production adoption for enterprise wide solutions.