Been slacking off lately and finally made some time to extend Get-ChildItem cmdlet in EventLog provider.
Now, in the following screenshot, I am in the sys: drive of type EventLog for System EventLog.
Get-ChildItem returns list of all EventLogEntry objects for System EventLog.
Now, I can just filter the output to display according to the EventLogEntryType of each EventLogEntry.
And what's cool is that(well about PowerShell that is, not my provider), if I pass an invalid Enumeration value for EntryType parameter, it displays error message with valid enumeration values Error, Warning, Information, SuccessAudit, FailureAudit
It's PowerShell in the works... not my code that displays valid enum values.
Tags : Monad MSH PowerShell ¶ 4:08 PM 0 comments
When PowerShell was still called Monad, there was a PDC05 Hands-On Lab document available with Monad distribution. The document was about "Creating Monad Providers" for Access database.
I have started to go over the old PDC 05 document since I could not find enough documentation to get started. The document was a bit out-dated but it was not hard to figure out what's been changed since Monad beta 2.
Patterns and utility methods are about the same as what's used for creating AccessDb provider in the lab. But the problem was that, I wanted to be able to create a provider-specific parameter for my PsProvider. (Let me get back to this a bit later on)
For e.g.). Under Certificate provider, Get-ChildItem has a Certificate-Provider specific parameter -CodeSigningCert for Get-ChildItem.
Now let's see how one can create a "sys" drive for System EventLog
You can retrieve System event log entries using Get-ChildItem cmdlet(or ls, or dir whichever alias you prefer):
ls sys:
Above is equivalent to:
Get-EventLog -logName System
Both ls sys: and Get-EventLog System returns all event log entries in System EventLog(well as you might or might not have guessed ;)) and not only they display the same content, but the output should look exactly the same.
The reason that output look exactly the same is because there is a pre-defined display format for the type System.Diagnostics.EventLogEntry in $PsHome/dotnettypes.format.ps1xml.
Now, back to the provider-specific parameter for Get-ChildItem, my implementation takes in Index of event log entry. But I would also like to supply additional parameters so that Get-Item can retrieve event log entry based on either EventID or InstanceID like the following
Get-Item -EventID 18
Get-Item -InstanceID 198397
Anyways, here is the current implementation of Get-Item in action
(201..205) is an array holding indexes from 201 through 205 so EventLogEntry objects with Indexes between 201 and 205 are displayed. How neat. I prefer that over
get-eventlog system | ? { ($_.Index -ge 201) -and ($_.Index -le 205) }
since there is no need to specify which log to list event log entries from nor use clunky syntaxes for Index ranges. Well, one can live with above syntax but when it comes to scattered index ranges you want to select, the latter approach gets a bit too uhm, unpractically complicated. Try accomplish ls (1..5+10..15) using Get-EventLog, it doesn't look pretty...
Lastly, Xaegr on IRC has suggested that it wouldn't hurt to add a support to get remote machine's EventLog entries. Xaegr has suggested a UNC path like syntax "\\MachineName\LogName" for the Root string, but I just went with MachineName:LogName for a quick and dirty testing... Now, this functionality is quite buggy... so when I tried to use IP instead of hostname, I get errors like Get-Item cannot find network path, blah... Moreover, you should have already impersonated or authenticated to the remote machine before creating new EventLog PsDrive for the remote machine and must have appropriate privileges to read EventLog. Since I am not systems administrator, this is a bit tough to understand...
Well, I would appreciate it if someone could answer my question on NG(PowerShell News Group)
W00t, My first post using Windows Live Writer... Took me really long to get used to this a bit.
Tags : Monad MSH PowerShell ¶ 12:03 AM 0 comments
