Workflow Manager Addendum MP for SQL Aliases


A SQL Alias is kinda like wearing disguise glasses...


From a security perspective, you can make things difficult for attackers by specifying a SQL alias and different port for SQL.




Symptom - discovery fails for WFM pack


Trying to monitor and figure out what the real database name, instance, etc. can be a challenge.

A couple of years ago, I was able to find an example for one customer where the registry key shed light on the alias.


The workflow manager management pack has a DataSourceModuleType "Microsoft.WorkflowManager.Addendum.v1.WFCommandExecuterDataSource", where this change successfully retrieved the sql server name.

This datasource uses the PowerShell script (WorkflowPSDiscovery.ps1)


This function was changed in one example

# Get computer name from splitted dataSource
function GetPrincipalName {

#$ssWithoutPort = $ss[0].split(',')
#if (-not $ssWithoutPort[0].Contains('.'))
# $ssWithoutPort[0] = $ssWithoutPort[0] + "." + $ADDomain.Name
#$principalName = $ssWithoutPort[0]

$key = 'HKLM:\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo'
$sqlfromalias = (Get-ItemProperty -Path $key -Name $ss).$ss
$sqlserverstr = $sqlfromalias.Split(',')
$sqlserver = $sqlserverstr[1]
$principalName = $sqlserver

return $principalName



Ran into this discovery issue a second time, and the function didn't solve the failure.

Real quick - a shout out and my thanks to Chuck Hughes and Mike Sadoff, for their time and testing this more robust discovery method.




Added logic to fix the assumed InstanceName ($instname) - Most likely why my first function worked (configuration had default SQL instance name of MSSQLSERVER )

Added GetSqlAlias function to help decode the disguise



Gallery download here


Don't forget to override the original workflow manager discovery!