Wednesday, January 30, 2008

WMI, PowerShell and PowerShell's WMI Type Accelerators

I've been playing with PowerShell's WMI interface as part of some writing work I'm doing. As I see it, PowerShell lacks built-in cmdlets to do everything. However that really is not a problem since a lot of thing can be pretty easily achieved using a few lines of PowerShell! 

PowerShell introduces the concept of type accelerators. These look like normal .NET types (type name specified inside square brackets), but they are managed by PowerShell itself. Type accelerators are just shortcuts to existing underlying functionality.

There are three WMI related type accelerators in PowerShell V1. If you are using  WMI with PowerShell, you really should know these three:

  • [WMI] - this TA helps you to get directly to a particular WMI object. You provide a string containing a detailed path to a particular WMI object and the TA returns the object. This is a little easier than using Get-WMIObject in those cases when you actually know the details of which occurrence you want.
  • [WMICLASS] - this TA gets you to a class definition. This then enables you to access WMI Class static methods. The Get-WMIObject enables you to get to instances, but to create new instances you need access to the static methods of the class.
  • [WMISEARCHER] - this TA helps you in terms of querying. When creating a WMISEARCHER, you specify a WQL query (e.g. Select * FROM Win32_Process WHERE Handlecount > 1000). You can use the searcher to execute that query and return results. This is a little easer for some times of administration.

WMI Type Accelerators are not well defined or well documented either on MSDN or inside the product itself. I hope my attempts at providing this information are useful - let me know what I'm missing and I'll try to add it. Over the coming week or so, I'll be blogging about each type accelerator in more detail. The posts also contain some simple sample code that demonstrates these cool features.

Did I mention - PowerShell rocks!!!

Technorati tags: , ,

Monday, January 28, 2008

MSDN Library Community Content and PowerShell

Microsoft turned on the community content feature of the MSDN site in late 2006, just over a year ago. That meant users could add content to MSDN in the way of additional samples,commentary, best practices, and even just simple typos! If you navigate to the root of the MSDN library page(http://msdn2.microsoft.com/en-us/library/default.aspx) you can see the statistics relating to the community content.

Thus far, I've added over 120 samples - mainly using PowerShell with a variety of components, including COM, WMI and .NET. I enjoy being one of the top contributors! I wonder if anyone over at Microsoft has noticed!

Over the past couple of days, I've been using PowerShell with several WMI and .NET objects and tonight I'm playing with the GPMC Com object.It's great that you can do so much with PowerShell, but the sheer inconsency of things lower down in the technology stack are infuriating. Sometimes things are case sensitive, other times not, some times you use quotes to hold names, other times not, etc - you probably know what I mean. This is not PowerShell's fault, but the result of a huge amount of parallel uncoordinated development within MS and therefore part of your learning curve.

The big advantage, however, of PowerShell is that you can do SO much all with one basic tool. And with a bit of work, you can write functions (and soon real cmdlets) in script that hide some of the nasty details.

PowerShell Rocks!!

Saturday, January 26, 2008

Global DNS Query Block List in Windows Server 2008

Looking over at the TechNet DNS sub-site, I've been reading a neat document: DNS Server Global Query Block List. The document describes a new feature in WS08's DNS Server: the Global Query Block List.

Some network protocols rely on DNS name resolution  to resolve specific well known host names. Two examples are WPAD and ISATAP. Malicious users could register hosts computers using these names and thus pose as a legitimate server.

Windows uses the web proxy auto-discovery protocol to discover a local web proxy. The client queries DNS for wpad.<domain> where <domain> is the computer's domain name (eg wpad.contoso.com for a computer in the contoso.com domain).

Intra-site Automatic Tunnel Addressing Protocol (ISATAP) is part of the set of protocols used to aid in IPv6 migration. ISATAP tunnels IPv6 traffic in IPv4 packets. The IPv6 traffic comes from an IPv6 network to the ISATAP server for for transmission across IPv4 only networks. Essentially, ISATAP servers encapsulate inbound IPv6 traffic into IPV4 traffic and passes it to another ISATAP server for conversion back to IPv6 and transmission to another IPv6 aware host. ISATAP does not provide for automatic ISATAP router discovery. ISATAP hosts use a potential routers list (PRL) to discover available ISATAP routers, typically  by using DNS to locate a host named isatap on the local domain (eg isatap.contoso.com).

In the case of both these protocols, if a malicious user was to rename their system it could then appear to be a genuine server, to the potential detriment of the user. The result may just be a denial of service, but could be worse. And even if your network doesn't use these protocols, your clients my be trying to use them anyway. In that case, they are vulnerable to the hijacking that DNS dynamic update enables.

The Server Block list prevents such hijacking by refusing to reply to a query. This renders the dynamic update useless. If you subsequently implement either protocol, then just remove the relevant name from the block list. Before doing this, you should manually enter the relevant RRs into DNS, and adjust the ACLs to remove the miscreant's ability to hijack the name.

And of course, you can use this same technique in your own environment, perhaps by protecting a computer called accounting, or manufacturing or something similar.

To configure the DNS query block list, you use DNSCMD as shown here:

PS C:\foo> dnscmd /config /globalqueryblocklist wpad isatap gratefuldeadmusiclibrary

Registry property globalqueryblocklist successfully reset.
Command completed successfully.

To view the current block list, use the /info switch with DNSCMD as shown here:

PS C:\foo> dnscmd /info /globalqueryblocklist

Query result:
String:  wpad
String:  isatap
String:  gratefuldeadmusiclibrary

Command completed successfully.

A neat feature!

Saturday, January 19, 2008

Microsoft and Time Travel

Happy New Year for those of you who have survived the holiday period, and the shocking reality of being back to work.

I've been looking at some documentation on the new functions and features of  DNS in Windows Server 2008. As to be expected, there's a bunch of really good documentation up on the MS web site.

One ,j- separating the DNS client from the DNS server (complete with hyperlinks to drill down for more information). A nice touch! Following the link to the article DNS Server, there's a good overview of the features of DNS. The DNS team should be congratulated on producing good useful and usable documentation.

But then I noticed the last updates to these pages: November 13, 2008 for the DNS Infrastructure page, and November 9, 2008 for the second! WOW - 11 months from now!! That's pretty cool.

So - is there more to Windows Server 2008 than meets the eye or has Microsoft really invented time travel?? I also wonder what sort of overtime arrangements the writers get for posting content they last update 11 months in the future!

Technorati Tags: ,,,