If You’re Stuck at Home for the PASS Summit

Conferences are a great place to network, to see new technologies or to see existing technologies being used in new ways, or just to get away the day-to-day work. You may love your job, but having a break to refresh and re-focus is certainly good, too. So what if you couldn’t make it out to this year’s Summit?


Definitely get on Twitter and watch the hashtags:

  • #PASSsummit
  • #SQLPass
  • #SQLFamily

There’s sure to be a lot of traffic tagged with those three hashtags along the lines of announcements, new tips and tricks, and thought-inducing points. Also, you’ll be able to interact with folks that are there in person. So while it’s not as good as a face-to-face encounter, it’s still fun and educational.


There’s a lot of options here with regards to recorded content so you can still get some personal training in at home:

Refresh and Re-focus:

Block off an hour or two or your calendar for training. Do a bit of research ahead of time to figure out what you’re going to watch.If possible, book a conference room at your work location and get away from your desk. Or grab your laptop, go to a place with good WiFi, and enjoy a presentation while you eat / relax.

Don’t “Test” Against Production

A few months ago, I was participating in a threat hunting exercise on the security side. The gentleman leading the exercise was discussing some scans to run. However, before we did anything, he made sure to state that we should run against a non-production environment first. Apparently, some of his clients needed to be reminded of this rule.

He had a good tale as to why he personally believed in this IT mantra. He was doing vulnerability scanning for a manufacturing firm at one of their plants. Before he performed the scan against the full floor, he wanted to test in a non-critical environment. During the test, one of the key components for manufacturing in this test environment went off-line. When they checked the device, it was just about a brick. I say just about because they were able to reload the firmware. Fully bricked and they wouldn’t have been able to even do that. To verify that it was the scan, he ran the scan against just another of the same type of device again. Same result. The scan was the culprit. Now imagine if they had run the scan against the production floor without testing. It would have ground everything to a halt.

While the work we do may not have the scale of losses as this gentleman’s could have, the reality is that we should have the expectation that we keep production as stable as possible. Part of that is testing everything first in a like setup that is NOT production. We want to know where stuff is going to break. We want to have the luxury of being able to troubleshoot without having to immediately roll back. Rolling back in production leads to both a loss of reputation and an increase in rework. An increase in rework means we have less time to do new work. Combined loss of reputation as well as less new work being accomplished results in a potentially negative career altering event. That potential goes up based on how much money the organization loses until the rollback is successfully completed.

If your working under an Agile methodology you still cannot ignore this mantra. Agile relies on consistency, such as consistency between environments. Agile also relies on faster feedback loops (AKA adequate but rapid testing). Agile doesn’t mean skipping testing. If you roll directly to production, you’re skipping testing. As time pressed as we can be in IT, there are few instances when we simply don’t have the time to test first.

Automating Everything with PowerShell – Getting Started #tsql2sday

I try to automate everything I can with PowerShell. Whether we’re talking SQL Server, WSUS, Active Directory, or any other product with active support in PowerShell, I try to write scripts to do everything. I believe in the old proviso that good engineers are lazy engineers (thank you, Andy Leonard). And lazy engineers try not to do the same type of work more than once. That’s why automation is key.

What have I automated recently?

  • Restarting WSUS app pools in IIS along with the main WSUS service because, well, there are known performance issues that keep cropping back up.
  • Checking Active Directory Federated Services services and making sure they are started (which they sometimes fail to do after patching).
  • Exporting users and key security groups out of AD and into SQL Server, which makes that information more accessible for developers writing apps that need that information.

I’ve been asked recently how to get started using PowerShell. Essentially, it’s no different than learning anything else in IT.

  1. Have a problem you want to solve.
  2. Have a location to test (this is NOT production).
  3. Find some resources that give you insight into solving the problem.
  4. Try to build a solution.
  5. Test!

With respect to PowerShell, there’s a ton of resources. Of course, there’s the Microsoft documentation. And if you want that documented help locally, there’s a great cmdlet update-help. From there you can use get-help and the cmdlet to find out what the syntax is. If you use the -ex flag, you’ll get the examples. There’s also a large number of scripts and blog posts on just about everything you can think to do. Just do a search with your first keyword being PowerShell and then the rest of the search being what you’re trying to do. For instance, if you’re trying to figure out how to export data out of SQL Server using PowerShell, a good search to run would be: PowerShell SQL Server export data.

There’s no shame in starting with someone else’s script. Most folks do. I often do as well, even though I’ve been writing scripts for a long time now. It’s known as time savings. It’s also known as being a lazy engineer (see above). But don’t just grab a script and run it. Walk through it using the documentation. Try to understand what each line is doing. Figure out what you have to modify for your own environment. And most importantly, don’t be afraid to ask for help.

I can’t emphasize that last statement enough. You’re not going to suddenly be a PowerShell master because your Google-fu is sharp. And learning anything new takes time and effort and, sometimes, a helping hand. If you’ve tried and you aren’t getting it, ask. There’s no point holding on to your pride if you aren’t getting the job done, right?

On a closing note, yes, you can learn PowerShell if you don’t have a problem to solve. However, my experience is that I learn better when I have a goal. If that goal is solving a problem that’s causing me discomfort, I have greater motivation to get the job done. Therefore, try to think of what manual processes you’d like to get automated so you don’t have to deal with them any longer.

Want to learn more about PowerShell and SQL Server? Go here to the original hosting post. You should see links / trackbacks in the comments.