David Gardiner - SQL

Azure SQL and enabling auditing with Terraform

2025-02-17T08:00:00.000+10:30

Sometimes when you're using Terraform for your Infrastructure as Code with Azure, it's a bit tricky to match up what you can see in the Azure Portal versus the Terraform resources in the AzureRM provider. Enabling auditing in Azure SQL is a great example.

In the Azure Portal, select your Azure SQL resource, then expand the Security menu and select Auditing. You can then choose to Enable Azure SQL Auditing, and upon doing this you can then choose to send auditing data to any or all of Azure Storage, Log Analytics and/or Event Hub.

It's also worth highlighting that usually you'd enable auditing at the server level, but it is also possible to enable it per database.

The two Terraform resources you may have encountered to manage this are mssql_server_extended_auditing_policy and mssql_database_extended_auditing_policy.

It's useful to refer back to the Azure SQL documentation on setting up auditing to understand how to use these.

A couple of points that are worth highlighting:

If you don't use the audit_actions_and_groups property, the default groups of actions that will be audited are:

BATCH_COMPLETED_GROUP SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP FAILED_DATABASE_AUTHENTICATION_GROUP
If you do define auditing at the server level, the policy applies to all existing and newly created databases on the server. If you define auditing at the database level, the policy will apply in addition to any server level settings. So be careful you don't end up auditing the same thing twice unintentionally!

Sometimes it can also be useful to review equivalent the Bicep/ARM definitions Microsoft.Sql/servers/extendedAuditingSettings, as sometimes they can clarify how to use various properties.

You'll see both the Terraform and Bicep have properties to configure using a Storage Account, but while you can see Log Analytics and Event Hub in the Portal UI, it's not obvious how those set up.

The simplest policy you can set is this:

resource "azurerm_mssql_server_extended_auditing_policy" "auditing" {
  server_id = azurerm_mssql_server.mssql.id
}

This enables the server auditing policy, but the data isn't going anywhere yet!

Storage account

When you select an Azure Storage Account for storing auditing data, you will end up with a bunch .xel files created under a sqldbauditlogs blob container.

There are a number of ways to view the .xel files, documented here

Using a storage account for storing auditing has a few variations, depending on how you want to authenticate to the Storage Account.

Access key

resource "azurerm_mssql_server_extended_auditing_policy" "auditing" {
  server_id = azurerm_mssql_server.mssql.id

  storage_endpoint                        = azurerm_storage_account.storage.primary_blob_endpoint
  storage_account_access_key              = azurerm_storage_account.storage.primary_access_key
  storage_account_access_key_is_secondary = false
  retention_in_days                       = 6
}

Normally storage_account_access_key_is_secondary would be set to false, but if you are rotating your storage access keys, then you may choose to switch to the secondary key while you're rotating the primary.

Managed identity

You can also use managed identity to authenticate to the storage account. In this case you don't supply the access_key properties, but you will need to add a role assignment granting the Storage Blob Data Contributor role to the identity of your Azure SQL resource.

resource "azurerm_mssql_server_extended_auditing_policy" "auditing" {
  server_id = azurerm_mssql_server.mssql.id

  storage_endpoint  = azurerm_storage_account.storage.primary_blob_endpoint
  retention_in_days = 6
}

Log analytics workspaces

To send data to a Log Analytics Workspace, the log_monitoring_enabled property needs to be set to true. This is the default.

But to tell it which workspace to send the data to, you need to add a azurerm_monitor_diagnostic_setting resource.

resource "azurerm_monitor_diagnostic_setting" "mssql_server_to_log_analytics" {
  name                       = "example-diagnostic-setting"
  target_resource_id         = "${azurerm_mssql_server.mssql.id}/databases/master"
  log_analytics_workspace_id = azurerm_log_analytics_workspace.la.id

  enabled_log {
    category = "SQLSecurityAuditEvents"
  }
}

Note that for the server policy, you set the target_resource_id to the master database of the server, not the resource id of the server itself.

Here's what the auditing data looks like when viewed in Log Analytics:

Event Hub

Likewise, if you want data to go to an Event Hub, you need to use the azurerm_monitor_diagnostic_setting resource.

resource "azurerm_monitor_diagnostic_setting" "mssql_server_to_event_hub" {
  name                           = "ds_mssql_event_hub"
  target_resource_id             = "${azurerm_mssql_server.mssql.id}/databases/master"
  eventhub_authorization_rule_id = azurerm_eventhub_namespace_authorization_rule.eh.id
  eventhub_name                  = azurerm_eventhub.eh.name

  enabled_log {
    category = "SQLSecurityAuditEvents"
  }
}

Multiple destinations

As is implied by the Azure Portal, you can have one, two or all three destinations enabled for auditing. But it isn't immediately obvious that you should only have one azurerm_monitor_diagnostic_setting for your server auditing - don't create separate azurerm_monitor_diagnostic_setting resources for each destination - Azure will not allow it.

For example, if you're going to log to all three, you'd have a single diagnostic resource like this:

resource "azurerm_monitor_diagnostic_setting" "mssql_server" {
  name                           = "diagnostic_setting"
  target_resource_id             = "${azurerm_mssql_server.mssql.id}/databases/master"
  eventhub_authorization_rule_id = azurerm_eventhub_namespace_authorization_rule.eh.id
  eventhub_name                  = azurerm_eventhub.eh.name

  log_analytics_workspace_id     = azurerm_log_analytics_workspace.la.id
  log_analytics_destination_type = "Dedicated"

  enabled_log {
    category = "SQLSecurityAuditEvents"
  }

Note, this Terraform resource does have a storage_account_id property, but this doesn't seem to be necessary as storage is configured via the azurerm_mssql_server_extended_auditing_policy resource.

You would need separate azurerm_monitor_diagnostic_setting resources if you were configuring auditing per database though.

Common problems

The diagnostic setting can't find the master database

It appears that sometimes the azurerm_mssql_server resource reports it is created, but the master database is not yet ready. The workaround is to add a dependency on another database resource - as by definition the master database must exist before any other user databases can be created.

Diagnostic setting fails to update with 409 Conflict

This error seems to happen to me when I try and set up Storage, Event Hubs and Log Analytics at the same time.

Error: creating Monitor Diagnostics Setting "diagnostic_setting" for Resource "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.Sql/servers/sql-terraform-sql-auditing-australiaeast/databases/master": unexpected status 409 (409 Conflict) with response: {"code":"Conflict","message":"Data sink '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.EventHub/namespaces/evhns-terraform-sql-auditing-australiaeast/authorizationRules/evhar-terraform-sql-auditing-australiaeast' is already used in diagnostic setting 'SQLSecurityAuditEvents_3d229c42-c7e7-4c97-9a99-ec0d0d8b86c1' for category 'SQLSecurityAuditEvents'. Data sinks can't be reused in different settings on the same category for the same resource."}

After a lot of trial and error, I've found the solution is to add a depends_on block in your azurerm_mssql_server_extended_auditing_policy resource, so that the azurerm_monitor_diagnostic_setting is created first. (This feels like a bug in the Terraform AzureRM provider)

resource "azurerm_mssql_server_extended_auditing_policy" "auditing" {
  server_id = azurerm_mssql_server.mssql.id

  storage_endpoint  = azurerm_storage_account.storage.primary_blob_endpoint
  retention_in_days = 6

  depends_on = [azurerm_monitor_diagnostic_setting.mssql_server]
}

Switching from Storage access keys to managed identity has no effect

Removing the storage access key properties from azurerm_mssql_server_extended_auditing_policy doesn't currently switch the authentication to managed identity. The problem may relate to the storage_account_subscription_id property. This is an optional property and while you usually don't need to set it if the storage account is in the same subscription, it appears that the AzureRM provider is setting it on your behalf, such that when you remove the other access key properties it doesn't know to set this property to null.

If you know ahead of time that you'll be transitioning from access keys to managed identity, it might be worth setting storage_account_subscription_id first. Then later on, when you remove that and the other access_key properties maybe Terraform will do the right thing?

Solution resource

If you ever hit the Save button on the Azure SQL Auditing page, you may end up with a Solution resource being created for your auditing. This is useful, though it can cause problems if you are trying to destroy your Terraform resources, as it can put locks on the resources and Terraform doesn't know to destroy the solution resource first.

You could try to pre-emptively create the solution resource in Terraform. For example:

resource "azurerm_log_analytics_solution" "example" {
  solution_name         = "SQLAuditing"
  location              = data.azurerm_resource_group.rg.location
  resource_group_name   = data.azurerm_resource_group.rg.name
  workspace_resource_id = azurerm_log_analytics_workspace.la.id
  workspace_name        = azurerm_log_analytics_workspace.la.name

  plan {
    publisher = "Microsoft"
    product   = "SQLAuditing"
  }

  depends_on = [azurerm_monitor_diagnostic_setting.mssql_server]
}

Though it seems that when you use Terraform to create this resource, it names it SQLAuditing(log-terraform-sql-auditing-australiaeast), whereas if you use the portal, it is named SQLAuditing[log-terraform-sql-auditing-australiaeast].

So instead this looks like a good use for the AzApi provider and the azapi_resource

resource "azapi_resource" "symbolicname" {
  type      = "Microsoft.OperationsManagement/solutions@2015-11-01-preview"
  name      = "SQLAuditing[${azurerm_log_analytics_workspace.la.name}]"
  location  = data.azurerm_resource_group.rg.location
  parent_id = data.azurerm_resource_group.rg.id

  tags = {}
  body = {
    plan = {
      name          = "SQLAuditing[${azurerm_log_analytics_workspace.la.name}]"
      product       = "SQLAuditing"
      promotionCode = ""
      publisher     = "Microsoft"
    }
    properties = {
      containedResources = [
        "${azurerm_log_analytics_workspace.la.id}/views/SQLSecurityInsights",
        "${azurerm_log_analytics_workspace.la.id}/views/SQLAccessToSensitiveData"
      ]
      referencedResources = []
      workspaceResourceId = azurerm_log_analytics_workspace.la.id
    }
  }
}

Other troubleshooting tips

The Azure CLI can also be useful in checking what the current state of audit configuration is.

Here's two examples showing auditing configured for all three destinations:

az monitor diagnostic-settings list --resource /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.Sql/servers/sql-terraform-sql-auditing-australiaeast/databases/master

gives the following:

[
  {
    "eventHubAuthorizationRuleId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.EventHub/namespaces/evhns-terraform-sql-auditing-australiaeast/authorizationRules/evhar-terraform-sql-auditing-australiaeast",
    "eventHubName": "evh-terraform-sql-auditing-australiaeast",
    "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-terraform-sql-auditing-australiaeast/providers/microsoft.sql/servers/sql-terraform-sql-auditing-australiaeast/databases/master/providers/microsoft.insights/diagnosticSettings/diagnostic_setting",
    "logs": [
      {
        "category": "SQLSecurityAuditEvents",
        "enabled": true,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "SQLInsights",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "AutomaticTuning",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "QueryStoreRuntimeStatistics",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "QueryStoreWaitStatistics",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "Errors",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "DatabaseWaitStatistics",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "Timeouts",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "Blocks",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "Deadlocks",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "DevOpsOperationsAudit",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      }
    ],
    "metrics": [
      {
        "category": "Basic",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "InstanceAndAppAdvanced",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "WorkloadManagement",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      }
    ],
    "name": "diagnostic_setting",
    "resourceGroup": "rg-terraform-sql-auditing-australiaeast",
    "type": "Microsoft.Insights/diagnosticSettings",
    "workspaceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.OperationalInsights/workspaces/log-terraform-sql-auditing-australiaeast"
  }
]

And the Azure SQL audit policy

az sql server audit-policy show -g rg-terraform-sql-auditing-australiaeast -n sql-terraform-sql-auditing-australiaeast

Gives

{
  "auditActionsAndGroups": [
    "SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP",
    "FAILED_DATABASE_AUTHENTICATION_GROUP",
    "BATCH_COMPLETED_GROUP"
  ],
  "blobStorageTargetState": "Enabled",
  "eventHubAuthorizationRuleId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.EventHub/namespaces/evhns-terraform-sql-auditing-australiaeast/authorizationRules/evhar-terraform-sql-auditing-australiaeast",
  "eventHubName": "evh-terraform-sql-auditing-australiaeast",
  "eventHubTargetState": "Enabled",
  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.Sql/servers/sql-terraform-sql-auditing-australiaeast/auditingSettings/Default",
  "isAzureMonitorTargetEnabled": true,
  "isDevopsAuditEnabled": null,
  "isManagedIdentityInUse": true,
  "isStorageSecondaryKeyInUse": null,
  "logAnalyticsTargetState": "Enabled",
  "logAnalyticsWorkspaceResourceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.OperationalInsights/workspaces/log-terraform-sql-auditing-australiaeast",
  "name": "Default",
  "queueDelayMs": null,
  "resourceGroup": "rg-terraform-sql-auditing-australiaeast",
  "retentionDays": 6,
  "state": "Enabled",
  "storageAccountAccessKey": null,
  "storageAccountSubscriptionId": "00000000-0000-0000-0000-000000000000",
  "storageEndpoint": "https://sttfsqlauditauew0o.blob.core.windows.net/",
  "type": "Microsoft.Sql/servers/auditingSettings"
}

SQL client alias not working

2021-03-10T11:00:00.000+10:30

This morning I was trying to create a SQL client alias. An application assumes my local SQL Server instance is named 'SQLEXPRESS' but I've installed SQL Server 2019 Developer Edition (which installs as the default instance).

I opened SQL Server 2019 Configuration Manager and created an alias.. It didn't work. I can never remember whether to use the '32bit' configuration or the other one! I tried both, still no success.

I checked Google to see I was doing it right. Yep, tried this and still no luck.

Let's double-check how my local instance is configured..

Whoops! Aliases can only use 'Named Pipes' or 'TCP/IP' and both of those protocols are disabled.

Let's enable TCP/IP

And enable binding to 1433 on localhost for IPv4 and IPv6. I won't bother with the other IP addresses as I'm not planning to share this instance externally.

Restart the SQL service and we're all good.

Oh.. and for my own reference, the '32bit' client alias did the trick for SSMS, but for a .NET application I needed also add a non-32bit alias too.

Converting a SQL Server .bacpac to a .dacpac

2018-08-27T21:30:00.000+09:30

Microsoft SQL Server has two related portable file formats - the DACPAC and the BACPAC. Quoting Data-tier Applications:

A DAC is a self-contained unit of SQL Server database deployment that enables data-tier developers and database administrators to package SQL Server objects into a portable artifact called a DAC package, also known as a DACPAC. A BACPAC is a related artifact that encapsulates the database schema as well as the data stored in the database.

When they say related, they're not kidding! Both of these files formats are based on the Open Packaging Conventions (a fancy way of saying it's a .zip file with some other bits), and cracking them open you discover that a bacpac file is basically a dacpac with a few extra files and a couple of different settings. Knowing this, it should be possible to manually convert a bacpac to a dacpac.

First, unzip the .bacpac file (using 7-zip, or rename to .zip and use Windows File Explorer’s Extract Archive).

Now do the following actions (you could do these programmatically if this is something you need to do repeatedly):

Edit model.xml
1. Change DataSchemaModel@SchemaVersion to 2.4
Edit Origin.xml
1. Change ContainsExportedData to false
2. Change ModelSchemaVersion to 2.4
3. Remove ExportStatistics
4. Recalculate the SHA256 checksum for model.xml and update the value stored in Checksums/Checksum@Uri=’/model.xml’
Remove directories \_rels and Data

Now re-zip up the remaining files and change the file suffix back to .dacpac

To verify that the .dacpac is valid, try using SSMS with the Upgrade Data-tier Application wizard. Run it against any database and if you can proceed to without error to the "Review Upgrade Plan" step, you should be good to go.

Running SQL Server Configuration Manager without SQL Server installed

2017-06-24T21:21:00.001+09:30

I like to have SQL Server Management Studio (SSMS) installed as part of my standard development environment. Usually this is because I also have an instance of SQL Server Developer or Express Edition installed, but not always.

One thing I noticed with the separate distribution of SSMS is that it also includes all the other management tools that used to be bundled with the server, like SQL Server Configuration Manager.

I wanted to change the SQL Client configuration settings and Configuration Manager is the tool I’d use to do that. But when I fired it up (it’s named SQL Server vNext CTP2.0 Configuration Manager in the latest release of SSMS), I’ve been greeted with this message:

I don’t see this problem when an instance of SQL Server is installed though.

The fix is documented in KB 956013. I ran the following from an elevated command prompt:

mofcomp "%programfiles(x86)%\Microsoft SQL Server\140\shared\sqlmgmproviderxpsp2up.mof"

Now SQL Server Configuration Manager starts up without error

Oh, and the easiest way to install SSMS is to use Chocolatey!

choco install sql-server-management-studio

Installing future SQL Server updates with confidence

2016-03-28T08:52:00.000+10:30

Great to read that Microsoft are now making the “cumulative update” packages ‘recommended’ installs, and the updates themselves will be easier to obtain - no longer requiring a email address to download directly, and also being listed in Windows Update Catalog (and maybe in the future as an optional update on Microsoft Update).

As a developer, I’ve often installed the latest CU (cumulative update) just because I like to be current on my own PC – but I’ve traditionally been more conservative with production SQL Servers that I’ve had to look after over the years. In the latter case I’ve installed the latest service pack, but only added a CU if it seemed likely to address any issue we might be having at the time.

With this change, now pushing out the latest CU can be done with more confidence and probably should be considered part of maintaining your SQL Server infrastructure. Quoting from the above article:

You should plan to install a CU with the same level of confidence you plan to install SPs (Service Packs) as they are released. This is because CU’s are certified and tested to the level of SP’s.

A few years back I remember thinking that the SQL Server team had really set the standard for releasing regular updates for their products (especially compared to the lack of updates at the time to fix problems with older versions of Visual Studio 2005/2008). Since then the VS team have upped their game, and now they are pushing new major servicing updates out around every quarter. That doesn’t include out-of-band updates to VS extensions that are done more frequently.

So it’s great to see the SQL Server team stepping up the pace another notch.

ALTER AUTHORIZATION

2015-03-10T16:28:00.001+10:30

(For my own reference)

To resolve this issue in Microsoft SQL Server (often observed when you restore a database that came from another server):

Run this:

alter authorization on database::[MyDbName] to sa;

SSDT BI Install Logs

2014-07-07T22:56:00.001+09:30

A short note for my reference. When you install SQL Server Data Tools – Business Intelligence for Visual Studio 2013, the installer writes a log file to a folder under C:\Program Files (x86)\Microsoft SQL Server\120\Setup Bootstrap\Log\

Handy if you’re trying to install it remotely or via an unattended install file and need to diagnose any errors.

Chris Testa-O'Neill on Increasing Business and IT collaboration with SQL Server

2013-12-18T15:08:00.001+10:30

I was one of the few who braved the 39°C heat outside to hear Chris Testa-O'Neill (@ctesta_oneill) speak at this month's Adelaide SQL Server User Group. Great to have Chris back in Adelaide again.

It proved to be a really interesting presentation about what BI tools are now available, and what tools are appropriate for what problems.

Reporting Services
Report Builder
PowerView
PowerPivot

The talk concluded with a nice demonstration of setting up PowerPivot in Excel, highlighting what could be achieved by a business 'power user', and what areas they would require assistance from a BI expert.

We also met in a different room from normal which I think most people thought was a better space. Plus (as you may observe in the photo above), it has a grand piano – I'm sure we could find a use for that somehow!

SSDT Talk Notes

2013-04-22T17:00:00.000+09:30

Here's a summary of the talk I did at the Adelaide SQL Server User Group last week. Most of the talk was a demo (only a couple of PowerPoint slides) so hopefully this is a useful reference for those who attended.

Intro to SSDT

Evolution of DataDude
The new way of shipping BIDS
Ships with SQL Server 2012 and Visual Studio 2012
Replaces 'Database Projects' from previous versions
Updates every 4-6 months (in time for SQL Azure updates)
- Ships with VS 2012 and with SQL 2012
- Free tool - use VS shell or integrate with existing
- Will update frequently to keep up with SQL Azure features

Connected

SQL Server Object Explorer
Connect to local or Azure
Queries
Execution Plans
Client stats

Disconnected

Database projects
Model-based
Edition-aware targeting (project properties)
- Can switch to azure to check if database is compatible with azure
Table designer/code view
- Synchronised
- Demo deleting a column
  - Can see errors (even before building) of related objects (eg. Views) that reference column
Build creates a 'dacpac' (Data-tier Application Package)
- 'Upgrade data-tier application' from SMSS
Declarative model
'Create New Project' via SQL Server Object Explorer
F5 builds and deploys database to localdb
Snapshots
Import .sql files
Code analysis

Schema Compare

Connected, Project, dacpac or snapshot
Update changes (defaults to not losing data)

Refactoring

Expand wildcards to column names - SELECT *
Semantic refactoring through model - not just find/replace
Go to Reference, Find all references

Publish database

Directly
Via SQL script
DACPAC
- C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\sqlpackage.exe

"c:\Program Files (x86)\Microsoft SQL Server\110\dac\bin\SqlPackage.exe" /action:driftreport /tsn:.\sql2012

/outputpath:c:\tmp\driftreport.xml /tdn:SsdtSample

Unit testing

Right-click on stored proc to create unit tests

3rd Party Integration and extensions

Red Gate SQL Compare (beta)
Version control
Laan SQL Formatter (soon)

Speaking on SSDT at Adelaide SQL User Group

2013-04-10T00:48:00.001+09:30

Today just happens to be T-SQL Tuesday, and this month's question is "how did you come to love presenting?"

The first time I presented in front of a group? hmm that's a tough question. Actually now that I think about it, it might have been the first time I did the kids' story as a young teenager teaching Sunday School. Keeping the attention of 5 year olds is a tough gig, but I must have done ok as that's something I still enjoy doing to this day. Sunday school, youth groups, camps, church conferences – they all gave me opportunities to try out "being up the front".

Moving more to the IT-side of things, getting opportunities to present at local user groups and events has definitely been a highlight. The last couple of years I've also been able to work in and present at the hands-on-labs at Microsoft's TechEd conferences, which is great fun.

One great thing about presenting is that it can be a two-way street. Sometimes you end up learning just as much from those you're presenting to as you hope they did from you.

Speaking of presenting, it's nice to be able to get back to the Adelaide SQL User Group next week and present on SQL Server Data Tools. It's something I've been using a bit lately and thought it would be of interest to others too. I've been involved with this group since it first started years ago, but for the last 12 months or so I've been unable to make the Wednesday timeslot in person due to some family commitments, so I'll be looking forward to catching up with some old friends.

If you're free next Wednesday lunchtime, feel free to register and come along. It would be great to see you!