SQL filtering.

When you hold a hammer you may end up seeing nails everywhere. I won’t pretend that I don’t have this problem. PowerShell is my hammer and “I see nails”. For example: when I have to work with a product that doesn’t allow me to perform some system-wide searches but allows me to export entire configuration to XML document I will improve my XPath skills and use my hammer for this nail. My XPath series is side effect of that.

I have more ‘nails’ around me though. Like ticketing system (lets keep it nameless) that has (for my needs) very poor search mechanism, but has SQL backend. I could probably use API that this product has (I think? Frankly, I didn’t even try to find it…) but writing something SQL-aware seemed more natural and reusable. After all – I may use the same ‘skeleton’ for anything else that has SQL backend.

Quick tip: new syntax revisited

You probably seen this a lot: new Foreach-Object and Where-Object syntax without script block is something people blogged about a lot. Some people love it, some hate it, some see it as a source of confusion for new-comers. I personally love it and I try to use it whenever possible (but only when working in interactive shell). You will see most of time new syntax works great, but it fails badly when used in more complex filters. I would like to show you how it can be used in combination with old syntax to simplify your code even in more complex situations.

Quick tip: reversed regex.

When working with regular expressions in PowerShell to check if certain string matches a pattern we can use it in both directions: to match or not match it (with –match and –notmatch operators). That’s very handy and it saves us a lot of time, because we don’t have to come up with regular expression that would do it for us. But there are certain situations where operators are not used.

Quick tip: human-readable LDAP filter

Whenever I work with Active Directory and I want to use pretty complex LDAP Filter to search for objects I’m after I’m tempted to use line break here and there to make whole thing easier on eyes of future reviewer (even if the only person to read the code is me “few weeks later”).

Quick tip: regex groups and ‘-split’

If you use –split as often as I do you probably had occasional issue with understanding why certain splits work as expected, and some produce results different from what you anticipated. Recently one of MVPs, Oisin Grehan, shed some light on the reason why this is the case. I thought it might be worth sharing in case you’ve had this issue and you are pulling your hair trying to figure out what’s going on.

Quick tip: replace it (slightly) smarter.

I try to use regular expression as much as I can. Mainly because this gets really “rusty” very quickly when not used. What I like to use very often is PowerShell’s operator –replace. It works wonders, especially when combined with named and numbered captures. But there are situations where this syntax can be hard to apply. I was walking around those issues in the past until I finally came up with solution that seems obvious if you think of it for a minute – so I’m probably not the first one that came up with it. If you did it few years ago – please feel free to look down on me.

Quick tip: $Matches is enough!

It does not happen very often: two posts in two days. But hey – if I have something (IMO) worth sharing, why wait?

Today I got question about parsing text file and while working on a solution I got idea how one can easily leverage named captures to create custom object on-the-fly.

Quick tip: break a code, differently.

This tip may be helpful to most of people, but is specifically targeted for people who share code on blogs and any similar media where width is issue at times.

So far I had two solutions, depending on the pipeline “type”:

• multi-command pipeline – breaking on the pipe symbol
• single-command pipeline – splatting

I avoid backtick (`) as hell, because single whitespace added by potential user after it and whole code becomes broken.

Quick Active Directory search with “pure” PowerShell

As much as I like tools designed for work AD – both from Microsoft and Quest – I’m sometimes amazed how quicker pure ADSI/ ADSISearcher calls can be. Today I said to myself: enough. I know LDAP Filters/ ActiveDirectory attributes good enough to write simple function for myself that would give me all advantages cmdlets give of former, and lightning speed of latter.

Also: I know, I can use LDAPFilters in either tools, but I do not like that I have to pass full filter, I wanted something interactive-work friendly. Normally you have to move back and forth (unless you always start with “(&())”) and always remember to quote everything (or escape brackets).

PowerShell ver. SCCM 2007

When you want some information from SCCM 2007 using PowerShell you have two options: using ADO.NET to talk to SCCM DB directly (yeah, right… ), or using WMI interface. If there are other ways to get there – I’m not aware of them (yet).

Working with good-old Get-WmiObject got better (IMO) in v3 – it’s unintentional (I’m guessing), but it’s the fact. Today I would like to share simple “trick” I use daily on my v3 admin workstation to get some info out of SCCM using WMI.