The WMI API was developed by Microsoft in 1998 in response to developers' and system administrators' ever-growing need for a common, scriptable API to manage the components of the Windows operating systems. Before WMI, if you wanted to manage some component of the operating system, you had to resort to using one of the component-specific Win32 APIs, such as the Registry API or Event Log API. Each API typically had its own implementation quirks and required way too much work to do simple tasks. The other big problem with the Win32 APIs was that scripting languages, such as VBScript, could not access them. This limited how much an inexperienced programmer or system administrator could manage systems programmatically. WMI changes all this by providing a single API that can be used to query and manage the Event Log, the Registry, system processes, the file system, or almost any other operating system component.
WMI is the Microsoft implementation of the Common Information Model (CIM) developed by the Distributed Management Task Force (DMTF). The DMTF is an association of various hardware and software companies (e.g., Novell, Microsoft, Cisco, and HP) developing standards in enterprise management. As large enterprises have many computers with many software environments, managing these diverse environments can be a real challenge. In order to unify the management techniques for the sake of simplicity, DMTF defined CIM to represent real-world manageable entities in a unified way. The CIM object model provides a generic set of definitions for hardware and software components. Vendors use this generic object model as a basis for extending CIM to support their own products. WMI is based on the CIM object model and includes extensions that represent the various Windows components.
The WMI DNS Provider was first released as part of the Windows 2000 Resource Kit Supplement 1, but unfortunately, it wasn't ready for prime time. That version was buggy, didn't include all the documented features, and, in several cases, behaved differently from what the documentation described. Also, since the DNS Provider was included as part of a Resource Kit, it was not fully supported by Microsoft, which meant that if you encountered problems, you were largely on your own. That said, much of the functionality you probably need is present in the Windows 2000 version so it may be suitable. You can download the Windows 2000 DNS Provider separately from the Resource Kit via anonymous FTP from the following location: ftp://ftp.microsoft.com/reskit/win2000/dnsprov.zip.
With Windows Server 2003, the DNS Provider is fully functional and supported, although some discrepancies still exist between the Microsoft documentation and the implementation. It is installed automatically whenever you install the DNS Server service.
The three main areas of interest when it comes to managing DNS include server configuration, zone management, and the creation and deletion of resource records. The DNS Provider has several classes to manipulate each of these components, all stored under the root\MicrosoftDNS namespace. With the MicrosoftDNS_Server class, you can manipulate server configuration settings, start and stop the DNS Server service, and initiate scavenging. The MicrosoftDNS_Zone class allows you to create, delete, and modify zone configurations. The MicrosoftDNS_ResourceRecord class and child classes provide methods for manipulating the various resource record types. Each of these is explained in more detail in the next few sections.
Several additional classes supported by the DNS Provider manage other aspects of DNS including the root hints (MicrosoftDNS_RootHints), DNS server cache (MicrosoftDNS_Cache), and server statistics (MicrosoftDNS_Statistics) classes. For more information on these classes, including sample scripts in VBScript and Perl, search for "DNS WMI Provider" in the Microsoft Developer Network Library ( http://msdn.microsoft.com/library/).