Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Chad Miller

Chad Miller is a Senior Manager of Database Administration at Raymond James Financial. Chad has worked with Microsoft SQL Server since 1999 and has been automating administration tasks using Windows Powershell since 2007. Chad is the Project Coordinator/Developer of the Powershell-based Codeplex project SQL Server PowerShell Extensions (SQLPSX). Chad leads the Tampa Powershell User Group and is a frequent speaker at users groups, SQL Saturdays and Code Camps.

SQLPSX 1.6.1 Release

I completed a maintenance release of SQL Server PowerShell Extensions, which address all known open issues. This release is still PowerShell V1, but I plan on working on a V2 release soon. The only notable change is in LibraryShowMbrs, which is used to recursively enumerate local and AD groups I know Quest makes a nice set of free cmdlets that provide this funcitonality. The Quest cmdlets are very good, I use them, however I chose to roll my own for two reasons. First, I did not want to build in a dependency for 3rd party cmdlets. Second, I want to be able to use SQLPSX from within the SQL Server 2008 PowerShell host, which does not support additional cmdlets--only scripts like SQLSPX.
 
The change in LibraryShowMbrs is in the way used to obtain group members. For several years I've used the WMI class Win32_GroupUser. Until recently this had been a reliable WMI class, however for some reason the class simply stopped returning even the name of sub groups and instead only user accounts are returned. I'm not really sure why and I haven't been able to find documentation on this change. I guess not finding documentation is not too suprising since I doubt many folks use WMI to enumerate local and AD groups. The library was re-written to use WinNT Provider and I found this post from Kristopher Bash helpful in creating the code.
 
I want to thank Jorge Seggara (@sqlchicken on Twitter) for helping to find several of the bugs addressed in this release. One of the issues fixed was a missing assembly that I did not find because I was loading it in my profile. I load a lot of things in my profile including initializing the SQL Server 2008 cmdlets and providers in my regular PowerShell using this script that contained the assembly I needed to include in one of the SQLPSX scripts. Due to this issue, I've learned a couple of things, first I need to test using the -noprofile switch. This will best mimic a clean PowerShell installation and I would encourage all script developers to do the same with scripts they distribute. Second, I need to do a better job testing. As scripts become complex its time to look at a more displined form of testing. One tool I learned about in a recent Episode of the PowerScripting Podcast called PSUnit. I'm going to check it out.

Comments

No comments.

Leave a Comment

Please register or log in to leave a comment.