Search results for 'app:weblogs' matching tag 'PoweShell'

SQLIse – A PowerShell SQL Server Query Tool

Anonymous — Fri, 04 Jun 2010 05:00:00 GMT

I am doing some work at the moment building SQL PowerShell training for an upcoming PowerShell MasterClass. In my searching, I came across a small project being done by Chad Miller, called SQLIse. As Chad describes in his blog, SQLISE is an ISE add-on that provides “a basic IDE for T-SQL that includes the ability to exit, execute, parse and format SQL code from within PowerShell ISE”.

SQLISE is a part of a larger SQL PowerShell project called SQL Extensions for PowerShell or SQLPSX. Having played a bit with both extensions, they are pretty cool and can certainly help IT Pros who have to deal with SQL. Chad has even created a short video to demostrate SQLISE – get this at YouTube: http://www.youtube.com/v/1KcNSHn7oTA&hl=en.

SQLISE has two pre-requisites. First, you need to have the PowerShell Pack installed and you need the SQLPX extensions loaded. You can get PowerShellPack from the MSDN Code Gallery.

One issue I faced was that the SQLIse installation process was not seamless or easy. In order to get this running, I needed two uber-modules (SQLPSX and PowerShellPack) and these come from different places. Second, the installation process requires you to run programs, SQLPSX_Install and PowerShellPack.MSI.

I find this somewhat contrary to the spirit of Modules in PowerShell V2 in that modules should be deployable using only Xcopy. In my case, I did not want either uber-module to be loaded in the personal modules folder, but in the system modules folder. But the installer(s) gave me no option. More importantly, while the SQLPSX installation program seemed to run, but left the module folder empty. A bit of hacking (and running streams.exe across the expanded file set!) enabled me to get the module installed. But sadly the hacking did not work well – and some of the features do not work. More hacking I suspect is needed.

In summary, a great feature let down by the complex installation process.

Technorati Tags: PoweShell,CodePlex,MSDN Code Gallery,SQL

PowerShellPlus v2.1 Beta

Anonymous — Wed, 04 Feb 2009 06:00:00 GMT

This is sort of exciting - PowerShellPlus v2.1 Beta is live! I’ve used PowerShell Plus for some time and love it. But there are things that I’d like to see, in particular the CTP3 support. Well, now we have that – and I’m downloading it as I write this post. The features in 2.1 that catch my eye are: VBS support, STA MOde, Code Sharing and of course, CTP3 support. I’ll be posting more once I have the code running and have a chance to give it a good test!

Technorati Tags: Powershell Plus,PoweShell,CTP3

PowerShellPlus v2.1 Beta

Anonymous — Wed, 04 Feb 2009 06:00:00 GMT

Technorati Tags: Powershell Plus,PoweShell,CTP3

Date and Time in PowerShell

Anonymous — Wed, 14 Jan 2009 06:00:00 GMT

In yesterday’s PowerShell script of the day entry,posted over on my PowerShell scripts blog, I re-implemented an MSDN sample (originally written in VBScript) that calculates up time. The script first used a WMI class (Win32_OperatingSystem) to determine when a computer started. Then the script gets the current time, and works out and displays the difference (i.e. the currentnt uptime).

The .NET framework contains a class, System.DateTime, that provides a variety of time/date related features.The PowerShell Cmdlet Get-Date returns a System.DateTime object that contains the current date and time. You can use the methods and properties of the class to get aspects of that current date and time as you need. For example:

PSH [D:\foo]: $d=Get-Date
PSH [D:\foo]: $d.Date

14 January 2009 00:00:00

PSH [D:\foo]: $d.Year
2009
PSH [D:\foo]: $d.IsDaylightSavingTime()
False

You can, of course, pipe your DateTime object to Get-member to see the other properties and methods on this class (or refer to the MSDN documentation). There’s a lot of pretty rich date and time handling available.

The problem I had with yesterday’s script is that WMI uses a different format for date and time. The Win32_OperatingSystem WMI object has a property, LastBootUpTime which returns the date and time when the OS was last booted. However, WMI returns this as a string that is formatted rather differently to System.DateTime, as you can see here:

PSH [D:\foo]: $os=Get-WmiObject Win32_OperatingSystem
PSH [D:\foo]: $os.LastBootUpTime
20090112142457.454125+000

This demonstrates that .NET, and therefore PowerShell, uses a native date/time formats that are different. For many admins (and for most native level developers) this is not a big deal. But if you need to inter-operate, you have a small issue of converting between the two formats.

As it turns out, solving this issue is simple. The developers of .NET created a simple solution. First, there’s a .NET class, System.Management.ManagementDateTimeConverter, which does date and time conversion. This class has a method, ToDateTime which converts a WMI date string into a .NET DateTime object. I used this method in the WMIDateStringToDate function in Get-Uptime.ps1.

You can either implement a function (i.e. WmiDateStringToDate) in your profile or cut/pasted it into any WMI script you write. Naturally, you could just use the .NET method natively. As follows:

PSH [D:\foo]: $os=get-wmiobject win32_operatingsystem
PSH [D:\foo]: $time = $os.lastbootuptime
PSH [D:\foo]: [System.Management.ManagementDateTimeconverter]::ToDateTime($time)

12 January 2009 14:24:58

PSH [D:\foo]: ([System.Management.ManagementDateTimeconverter]::ToDateTime($time)).hour
14

As with most things PowerShell, easy stuff is very easy while complex stuff is often just a method call away.

Technorati tags: WMI, PoweShell, System.Management.DateTimeConverter.