fox weblog

Automating Visual Studio from VFP

stuartd — Thu, 11 Oct 2007 12:29:00 GMT

Updating a file in a Visual Studio project from VFP is pretty straightforward. First up, get a reference to the project:

oVS = createobject("VisualStudio.Solution.8.0") && VS2005 
oVS.Open("C:\projects\example.sln")
oProject = oVS.Projects(1)

Each project has a ProjectItems collection: each can be a folder or a file. The items can be referenced by name, so this returns a reference to an XML file in the XML folder:

oDocument = oProject.ProjectItems("XML").ProjectItems("file.xml")

Each item has a URL property which indicates (for a file) the file name, but this is only available via the Properties collection:

cFilePath = substr(oDocument.Properties("URL").Value, 9) && strip off file:///
xmltocursor(alias(), "_cliptext") && Get XML on the clipboard
strtofile(_cliptext, cFilePath) && write to file.

You can do this while VS has the file open, it will notice and prompt you to reload the file.

Slipstreaming VFP

stuartd — Tue, 27 Mar 2007 11:12:00 GMT

The February 2007 CTP of VFP9 SP2 can be slipstreamed into the original VFP installation: this means that it's integrated into the setup process so it will directly install VFP9 SP2 - or, alternatively, VFP9 SP2 can simply be run from the slipstream directory (or from a USB device or CD) without the need to install the upgrade.

This alleviates the need to run the Community Technology Preview of SP2 on a virtual (or spare) machine in order to still be able to support applications which require VFP9 SP1.

To slipstream you need to copy your VFP9 CD to a writeable drive, and make sure the directory is writeable by unchecking Read-Only in it's attributes and selecting the option to cascade this change to subfolders. Then use WinZip or a similar program to extract the patch file from the SP2 download - in this instance VFP9.0sp2-KB925841-X86-Enu.msp

The patch can then be applied using this command (adjusting for file locations as required):

msiexec /a c:\vfoxpro9.0\vs_setup.msi /p c:\temp\VFP9.0sp2-KB925841-X86-Enu.msp

Tone

stuartd — Tue, 12 Sep 2006 19:42:00 GMT

How applications 'talk' to users, especially in messageboxes and other dialogs, sets the tone for an application and colours the user experience.

The first question is usually - who is 'talking' here? The computer, the program, or the developer? Sometimes it's hard to tell. For example this message from iTunes/Windows: "iTunes has detected that it is not the default player for audio files." iTunes is referring to itself in the third person, as is the norm. This is one source of the confusion that dialogs can cause - generally users will attempt to determine the source of a popup by the text, rather than the subtle clues that distinguish operating system dialogs from application dialogs, and Windows would refer to iTunes in more or less exactly the same way that iTunes refers to itself. No wonder it causes confusion: but none of the other choices are appealing, either: using the first person - "I've got a problem", or avoiding that by using a passive sense of self - "A problem has occurred" - both fail to identify the program at all, unless visual branding is used, which is often not practical (especially with low-profile applications). Remembering that to users it's their computer that is trying to communicate with them (rather than a program or programmer) helps to get the tone right.

Many of the factors influencing text choices tend to encourage terseness - the desire for a simple interface, allowing that localization can make text longer, or there's never quite enough space allocated by the designer on the dialog to put as much text as you might want. This can lead to a situation where any words deemed as superfluous are excised in order to achieve a clipped quasi-military precision: applications which are overly terse run the risk of appearing to be issuing orders to the user, but excess verbiage must also be a avoided: "Experienced UI designers literally try to minimize the number of words on dialogs to increase the chances that they will get read." -- Spolsky

Microsoft's Vista UI guidelines are comprehensive (if not yet complete) and I was interested to see they have put much thought about this basic but crucial part of human-computer interaction and done a whole article on Text And Tone and using the Vista tone is rule 9 in the Top Rules for Vista applications (where it is defined as "clear, natural, concise, and not overly formal".) These guidelines are primarily intended for consumer applications, but they apply equally to corporate environments where applications often get away with terse, incomprehensible and sometimes outright rude messages because users don't have a choice whether to use them or not. Programs should at the very least be polite and respectful and try to be helpful, and treat users as intelligent beings who might appreciate a little assistance with a task or decision.

Of course, it's equally important to decide what messages should be presented and how: messageboxes are hopelessly intrusive, and neither Vista's task dialogs or Mac OS's Sheets really solve any of the problems, as they are still modal, still covering your application's user interface (possible even covering the source of or reason for the message), and still much too easy to simply disregard without reading. If a data entry application presents a messagebox that says "Your changes have been saved" every time the user saves some data, are they really expected to process it every time? I wait hovering over the enter key, ready to tap it as soon as the dialog appears: and if the save goes arse-over-tip and I'm unexpectedly presented with a failure dialog instead, then I'll probably press enter when that pops up, and I've made an unknown decision. Oops: hope the default action was well chosen.

One common use case of messageboxes is when a problem or 'situation' has occurred and the user has to make a 'decision'. While this may be valid, if a mesage is really important it's worth considering an alternative approach by using your application's own UI to describe the situation and to elicit the user's choice. A common mistake is to assume that modality simply means being always-on-top, but it doesn't: modality means that the application has different modes, where the same actions have different results. This definition of a modal dialog box reconciles the two, as "a modal dialog box puts the user in the state or 'mode' of being able to work only inside the dialog box." When a modal dialog is open (notably system dialogs like opening or saving a file, or showing a messagebox) the application in a new mode where it's normal functionality is unavailable: there might be different key bindings, no access to the application's inbuilt help (though that can be accessed from a messagebox in VFP9 using the new BindEvent functionality) or any application tools. When notifications are handled within the application interface, there is no incentive for the user to immediately dismiss the dialog in order to return to normal application mode, as they have never left it. It's not always practical (or desirable) to do this, but it's worth working to minimise messagebox usage to improve application flow and usability.

There's a list of the Top Violations of the Vista UI guidelines, which includes many real examples from the current version of Windows. The Daily WTF have some amusing collections of terrible dialogs; although they haven't been updated for a long time the User Interface Hall of Shame (and Hall of Fame) are very instructive. I'm also looking forward also to content appearing in the Error Message section of the Vista guidelines.

foxkb - foxpro kb article archive

stuartd — Wed, 23 Aug 2006 23:18:00 GMT

foxkb - foxpro kb article archive

Determining Active Directory group membership

stuartd — Mon, 14 Aug 2006 15:19:00 GMT

In order to determine whether a user is a member of an Active Directory group (or a member of a group which is a member of the group) in a large directory, iteration through the members collection is too slow as each group can contain thousands of members: we need to be able to tell what groups are members of each group and recursively query those until we find a group the user is a member of.

There are various means of querying the Active Directory: the recommended way for clients like VFP is to use ADO. The ADO AD provider supports two types of query: LDAP filters and SQL. SQL has to be used as VFP doesn't understand the multi-valued adVariant objects returned by LDAP filter queries and can't parse the individual values (using WMI to access the AD returns the same kind of variant arrays, although single-value properties can be accessed)

This example code will determine if the current user is a member of a specified Active Directory group:

lparameters cGroup

* Determine if the current user is a member of this group.
* As group memberships can be nested - user is a member of a group
* which is a member of a group which is a member of the target group -
* use recursive queries to look into the contained groups. Because some of the
* groups have thousands of user members, use querying not iteration.

local oConnection, oCommand, oADSysInfo, cUser, oUser, cUserName, ;
	oRoot, cRootDomain, lMember

*	Pass the ADSPath to the target group 
*	cGroup = "CN=TestGroup,OU=Security Groups,DC=foxite,DC=com"

oConnection = createobject("ADODB.Connection")
oCommand = createobject("ADODB.Command")

oConnection.Provider = "ADsDSOObject"

oConnection.open()
oCommand.ActiveConnection = oConnection

oADSysInfo = createobject("ADSystemInfo")
cUser = oADSysInfo.UserName
oUser = getobject("LDAP://" + cUser)
cUserName = oUser.SamAccountName

oRoot = getobject("LDAP://RootDSE")
cRootDomain  = oRoot.get("DefaultNamingContext")

lMember = .f.

IsGroupMember_Recurse(cGroup, cUserName, oCommand, cRootDomain, @lMember)

return lMember

procedure IsGroupMember_Recurse(cGroup, cUserName, oCommand, cRootDomain, lMember)

	if lMember
		* We are already a member: speed through the rest of the recursion stack
		return
	endif

	* Need a different oRS for each iteration
	local oRS, cSQL, cGroupPath

	* Is user a member of group?
	cSQL = [SELECT name from 'LDAP://] + cRootDomain + ;
		[' WHERE memberOf='] + cGroup + ;
		[' AND objectClass='user' AND SAMAccountName = '] + cUserName + [']

	oCommand.CommandText = cSQL
	oRS = oCommand.Execute

	if oRS.RecordCount > 0
		* ? cUserName + " is a member of " + cGroup
		lMember = .t.
	else
		* Get the groups which are a member of this group
		cSQL = [select distinguishedname from 'LDAP://] + cRootDomain + ;
			[' where memberof='] + cGroup + [' and objectclass = 'group']

		oCommand.CommandText = cSQL
		oRS = oCommand.Execute

		* Recurse
		do while not oRS.eof
			cGroupPath = oRS.fields(0).value
			IsGroupMember_Recurse(cGroupPath, cUserName, oCommand, cRootDomain, @lMember)
			oRS.MoveNext
		enddo
	endif

endproc

Calling Vista's TaskDialog API

stuartd — Tue, 23 May 2006 12:29:00 GMT

Calling the TaskDialog API from FoxPro (in Vista build 5308) turned out to be a bit harder than Craig Boyd makes it sound but once it emerged that the string parameters have to be manually null-terminated and converted to Unicode it became much easier (if you don't convert the strings the output looks like this)

declare integer TaskDialog in "comctl32.dll" ;
	integer nHWND, ;
	integer hInstance, ;
	string cTitle, ;
	string cDescription, ;
	string cContent, ;
	integer nButtons, ;
	integer nIcon, ;
	integer @ nResult

* Icons

#define TD_ICON_BLANK			100
#define TD_ICON_WARNING			101
#define TD_ICON_QUESTION		102
#define TD_ICON_ERROR			103
#define TD_ICON_INFORMATION		104
#define TD_ICON_BLANK_AGAIN		105
#define TD_ICON_SHIELD			106

* Button values: ABORT and IGNORE appear to have been deprecated.

#define TD_OK            1
#define TD_YES         	 2
#define TD_NO            4
#define TD_CANCEL        8
#define TD_RETRY         16
#define TD_CLOSE         32

cTitle = "Taskdialog title bar text"
cDescription = "Description text"
cContent = "Main content of task dialog text: what to do and " + ;
	"where to do it"

cTitle = strconv(cTitle + chr(0), 5)
cDescription = strconv(cDescription + chr(0), 5)
cContent = strconv(cContent + chr(0), 5)

nButton = 0

nReturn = TaskDialog(_vfp.hwnd, 0, cTitle, cDescription, cContent, ;
	TD_OK + TD_CLOSE, TD_ICON_SHIELD, @nButton)

if nReturn = -2147024809
	? "Invalid arguments were passed"
else
	do case
		case nButton = 1
			? "You pressed OK"
		case nButton = 2
			? "You pressed Cancel"
		case nButton = 4
			? "You pressed Retry"
		case nButton = 6
			? "You pressed Yes"
		case nButton = 7
			? "You pressed No"
		case nButton = 8
			? "You pressed Close"
		otherwise
			? "Return value was " + transform(nButton)
	endcase
endif

Connecting to WinRM with Windows Vista

stuartd — Mon, 01 May 2006 20:13:00 GMT

Windows Vista (currently RC1, build 5536) ships with WinRM installed but the service is only started automatically on Longhorn Server: if you want to use WinRM on Vista the service has to be started manually. Whether this is still the case in the final product, or which versions of it, remains to be seen. It's presence currently is no surprise given the shared code base of WS2003 and Vista, but significant changes have been made to the WinRM configuration schema in Vista.

The WinRM configuration now includes the settings for WinRS - Windows Remote Shell - and allows these to be set programatically. Also, though, administering WinRM in Vista is now possible via the Group Policy editor.

There's also now a quickconfig command which sets WinRM up as a server - starts the service, creates a listener on all IPs, and adds the firewall exceptions.

This it what the revised schema looks like:

Config
    MaxEnvelopeSizekb = 150
    MaxTimeoutms = 60000
    MaxBatchItems = 20
    SoapTraceEnabled = false
    MaxProviderRequests = 25
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = false
            Digest = true
            Kerberos = true
            WindowsIntegratedAuthentication = true
        DefaultPorts
            HTTP = 80
            HTTPS = 443
        TrustedHosts
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
        MaxConcurrentOperations = 100
        EnumerationTimeoutms = 60000
        MaxConnections = 5
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            WindowsIntegratedAuthentication = true
        DefaultPorts
            HTTP = 80
            HTTPS = 443
        IPv4Filter = * 
        IPv6Filter = * 
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 4294967295
        MaxConcurrentUsers = 5
        MaxShellRunTime = 4294967295
        MaxProcessesPerShell = 10
        MaxMemoryPerShell = 83886080
        MaxShellsPerUser = 5

To test Vista as a client using HTTP, the Basic Auth property must be set to true. To do this, use XML files, the Group Policy editor, or script:

winrm set winrm/config/client/auth @{Basic="true"}

To test Vista as a server using HTTP to connect, basic authentication needs to be enabled for the WinRM service and an HTTP listener created just like for WS2003R2 (although Group Policy has a setting to "Allow automatic configuration of listeners" this does not create the listener itself).

The listener uses the newer config URI and introduces some subtle changes from the previous version. The IP selector has been replaced by Address, which has several options: * listens on all IP addresses on the machine, IP:192.168.1.1 listens only on the specified IP address, and MAC:... listens only on IP addresses for the specified MAC.

This foxpro code creates, enumrates, and then deletes an HTTP listener which listens on all IP addresses:

* Create, enumerate and destroy a listener - Vista
oWsman = createobject("WSMAN.Automation")
oSession = oWsman.CreateSession()
cSchema = "wsman:microsoft.com/wsman/2005/12/"

cComputerName = "VISTA_VM1"
cResource = cSchema + "config/Listener?Address=*+Transport=HTTP"

cXML = [<cfg:listener xmlns:cfg="] + cSchema + [config/listener.xsd">]
cXML = cXML + "<cfg:hostname>" + cComputerName + "</cfg:hostname>"
cXML = cXML + "</cfg:listener>"

* Create the listener
cResponse = oSession.create(cResource, cXML)
messagebox(cResponse)

* Enumerate it:
cResponse = oSession.Enumerate(cSchema + "config/Listener").ReadItem()
messagebox(cResponse)

* Now delete it: there is no response to this operation if it is successful
cResponse = oSession.delete(cResource)

Command-line VFP

stuartd — Thu, 27 Apr 2006 09:57:00 GMT

It's surprisingly easy to create a command-line interface to your application: example usages could be application updates, maintenance routines, anything that doesn't require a user interface.

As an example create a file called vfp.cmd somewhere in the default path (e.g. the system32 directory for local admins or at install) and add the following:

@cscript //nologo "%~dpn0.vbs" %*

This executes a script which is on the same drive, the same path, has the same name as the cmd file, has the extension vbs, and passes all the command line arguments to the script host.

Then create a file in the same directory as the .cmd file called vfp.vbs with these contents:

dim i, oVFP
i = 0

wscript.echo "Arguments:"

do while i < wscript.arguments.count 
	wscript.echo wscript.arguments(i) & "(" & i & ")"
	i = i + 1
loop

set oVFP = createobject("VisualFoxpro.Application")
wscript.echo "VFP File path:"
wscript.echo oVFP.DefaultFilePath

Once this has been done, open a command prompt and type

vfp foo bar

to see the results. Your script could process the arguments itself, or it could pass them to your application or COM server depending on the requirements.

Remote connections to Windows Server 2003 using WinRM

stuartd — Mon, 10 Apr 2006 21:17:00 GMT

WinRM by default only allows remote connections via a secured connection using SSL (HTTPS). It can be configured to allow connections via HTTP, but as the documentation says, unless you are using IPSec to secure the connection between your client and server then the credentials used to adminster the server are sent in plaintext.

Configuring client and server (Windows Server 2003)

This code returns the current configuration for WS2003R2 (see here for the Vista config schema and what you need to do to access it: I will cover remote connections to/from Vista in another article) To configure WinRM, use the Put method, passing XML returned by the Get on the Config objects with the appropriate attributes set as required.

* Access config XML (Win 2003 Server)
oWsman = createobject("WSMAN.Automation")
with oWsman.CreateSession()
	cXML = .get("wsman:microsoft.com/wsman/2005/06/config")
	messagebox(cXML)
endwith

The default configuration for a Windows 2003 server is below: because the WinRM client and service have basic authentication disabled remote connections via HTTP cannot be attempted or accepted.

Config
    MaxEnvelopeSizekb = 50
    MaxTimeoutms = 60000
    MaxBatchItems = 20
    SoapTraceEnabled = false
    MaxProviderRequests = 25
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        HTTP
            Port = 80
            Unencrypted
                Basic = false
                Digest = false
                Negotiate = false
        HTTPS
            Port = 443
            Basic = true
            Digest = true
            Negotiate = true
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
        MaxConcurrentOperations = 100
        EnumerationTimeoutms = 60000
        MaxClientCertInfoSize = 16384
        MaxConnections = 5
        HTTP
            Unencrypted
                Basic = false
                Negotiate = false
        HTTPS
            Basic = true
            Negotiate = true

Server configuration

From this output the XML containing the properties to be modified can be extracted and the new values substituted. This example XML could be used to allow basic authentication on inbound HTTP connections in WS2003:

<cfg:Config xmlns:cfg="wsman:microsoft.com/wsman/2005/06/config.xsd">
    <cfg:Service>
        <cfg:HTTP>
            <cfg:Unencrypted>
                <cfg:Basic>true</cfg:Basic>
            </cfg:Unencrypted>
        </cfg:HTTP>
    </cfg:Service>
</cfg:Config>

Client configuration

HTTP authentication has to be explicitly allowed on the client as well: this is for WS2003 as well.

<cfg:Config xmlns:cfg="wsman:microsoft.com/wsman/2005/06/config.xsd">
    <cfg:Client>
        <cfg:HTTP>
            <cfg:Unencrypted>
                <cfg:Basic>true</cfg:Basic>
            </cfg:Unencrypted>
        </cfg:HTTP>
    </cfg:Client>
</cfg:Config>

To set the configuration, pass the XML via the Put method (to the appropriate config URI). If successful, the new configuration is returned, otherwise XML indicating fault or failure. The session object's Error method will have details of the problem:

cResultXML = oSession.put("wsman:microsoft.com/wsman/2005/06/config", cConfigXML)

Creating a Listener

Once this has been done - or if you intend to connect using HTTPS - one or more listeners must be created on the target system. Listeners must be created and adminstered locally using WinRM.

This example code illustrates creating a listener, enumerating it, and finally deleting it. You will have to specify the IP address and hostname in the appropriate functions:

oWsman = createobject("WSMAN.Automation")
oSession = oWsman.CreateSession()
cSchema = "wsman:microsoft.com/wsman/2005/06/"

cResource = cSchema + "config/Listener?IP="
cResource = cResource + GetIPAddress() + "+Port=" + GetPort()

cXML = [<cfg:Listener xmlns:cfg="] + cSchema + [config/listener.xsd">]
cXML = cXML + "<cfg:Hostname>" + GetComputerName() + "</cfg:Hostname>"
cXML = cXML + "<cfg:Transport>" + GetTransport() + "</cfg:Transport>"
cXML = cXML + "</cfg:Listener>"

* Create the listener
cResponse = oSession.create(cResource, cXML)
messagebox(cResponse)

* Enumerate it:
cResponse = oSession.Enumerate(cSchema + "config/Listener").ReadItem()
messagebox(cResponse)

* Now delete it: there is no response to this operation if it is successful
cResponse = oSession.Delete(cResource)

function GetComputerName
	return "VMAC"

function GetIPAddress
	return "192.161.1.240"

function GetPort
	return "80"

function GetTransport
	return "HTTP"

The winrm command line would generally be used to do these operations on servers.

winrm put wsman:microsoft.com/wsman/2005/06/config -file:c:\config.xml
winrm create wsman:microsoft.com/wsman/2005/06/config/Listener?IP=192.168.1.240+Port=80 @{Hostname="VMAC";Transport="http"}
winrm enumerate wsman:microsoft.com/wsman/2005/06/config/Listener

You can check the connection using a command like the following. It doesn't appear possible to pass the required parameters to the automation session's Get method, as unfortunately the resource locator object is missing in WS2003R2 (it is available in Vista)

winrm get wsman:system/2005/06/this -machine:vmac -transport:http -username:stuart -password:helloworld

Establishing the remote connection to WMI

The WSMan.Automation object has a CreateConnectionsObject method which returns an object to whose properties are assigned the credentials to be used for the connection, and this object is passed to the CreateSession method with the appropriate connection flags. On my home network I have been unable to connect by IP address - the session object's error method returns <h1>Bad Request (Invalid Hostname)</h1> - and I have been unable to connect through the Windows Firewall.

#DEFINE WSManFlagCredUsernamePassword	4096
#DEFINE WSManFlagUseDigest	65536	
#DEFINE WSManFlagUseNegotiate	131072	
#DEFINE WSManFlagUseBasic	262144		

oWSMan = createobject("wsman.automation")

oCredentials = oWSMan.CreateConnectionOptions
oCredentials.username = "username"
oCredentials.password = "password"

cAddress = "http://VMAC"

* Use WSManFlagUseNegotiate instead of WSManFlagUseBasic for domain credentials
oSession = oWSMan.CreateSession ;
	(cAddress, WSManFlagUseBasic + WSManFlagCredUsernamePassword, oCredentials)

cSchema =  "http://schemas.microsoft.com/wsman/2005/06/"
cNamespace = "wmi/root/cimv2/"
cClass = "Win32_ComputerSystem"

cResource = cSchema + cNamespace + cClass

oItems = oSession.Enumerate(cResource)
messagebox(oItems.ReadItem())

Windows Remote Management (WinRM) part 1

stuartd — Thu, 30 Mar 2006 22:47:00 GMT

Windows Server 2003 Release 2 (WS2003R2) and Windows Vista introduce a new variety of firewall-friendly remote server management, Windows Remote Management (WinRM), an implementation of the Web Services for Management specification. Instead of marshalling objects across RPC using DCOM, WinRM uses SOAP Web Services via HTTP and HTTPS for remote connections. The web server doesn't have to be installed (but it can be) as HTTP is now a system component.

It's possible to connect to the WMI service on the remote server for diagnostics and management, or to any hardware baseboard management controllers installed in case of server or component failure. WinRM is installed bud disabled by default in Vista [build 5536] but needs to be installed on WS2003R2. It is not available for Windows XP or earlier versions of Windows.

Accessing resources

WinRM operations are marshalled by the session object which is returned as the result of a successful connection to a local or remote computer from the WSMan object. The session object has a Get method which is used to access a specific class instance - in this case the HTTP system driver.

local oWsman, oSession, cSchema, cNamespace, ;
	cClass, cResource, cResult
	
oWsman = createobject("WSMAN.Automation")
oSession = oWsman.CreateSession()

cSchema =  "http://schemas.microsoft.com/wsman/2005/06/"
cNamespace = "wmi/root/cimv2/"

* Only Key properties can be used to identify the target instance
cClass = "Win32_SystemDriver?Name=HTTP"

cResource = cSchema + cNamespace + cClass
cResult = oSession.Get(cResource)

messagebox(DisplayOutput(cResult))

procedure DisplayOutput(cXML)
	local oXMLFile, oXSLFile
	oXMLFile = createobject("MSXml2.DOMDocument.3.0")
	oXSLFile = createobject("MSXml2.DOMDocument.3.0")
	oXMLFile.loadxml(cXML)
	* XSL file is in system32 directory
	oXSLFile.load("wsmtxt.xsl")
	return oXMLFile.TransformNode(oXSLFile)
endproc

Configuration GETs

There are some specific GET queries which can be executed:

* Get the WinRM version
oSession.Get("wsman:system/2005/06/this")

* Get the WinRM configuration (WS2003R2)
oSession.Get("wsman:microsoft.com/wsman/2005/06/config")

* Get the WinRM configuration (Vista)
oSession.Get("wsman:microsoft.com/wsman/2005/12/config")

Note the Vista configuration URL uses a different schema and requires full Vista administrative rights: to access it you must therefore either be logged on as Administrator or if your account is in the Administrators group you must start VFP via right-clicking on the shortcut or executable file and choosing "Run as administrator" - this attribute can be also set as the default on a given shortcut in the "Compatibility" tab.

Simple enumerations

The session object's Enumerate method returns a collection of objects of a certain class and allows iteration through them.

local oWsman, oSession, cSchema, cNamespace, ;
	cClass, cResource, cXML, oItems
	
oWsman = createobject("WSMAN.Automation")
oSession = oWsman.CreateSession()

cSchema =  "http://schemas.microsoft.com/wsman/2005/06/"
cNamespace = "wmi/root/cimv2/"
cClass = "Win32_DiskDrivePhysicalMedia"
cResource = cSchema + cNamespace + cClass

oItems = oSession.Enumerate(cResource)

do while oItems.AtEndOfStream = .f.
	cXML = oItems.ReadItem()
	* View output as formatted XML this time.
	messagebox(DisplayOutputXML(cXML))
enddo

procedure DisplayOutputXML(cXML)
	local oXMLFile, oXSLFile
	oXMLFile = createobject("MSXml2.DOMDocument.3.0")
	oXSLFile = createobject("MSXml2.DOMDocument.3.0")
	oXMLFile.loadxml(cXML)
	* wsmpty.xsl outputs formatted XML
	oXSLFile.load("wsmpty.xsl")
	return oXMLFile.TransformNode(oXSLFile)
endproc

WQL queries in WinRM

In WS2003R2, this is as far as enumerate goes - you get all the properties of all the objects. Vista, though, has the capacity to process WQL queries:

local oWsman, oSession, cDialect, cFilter, ;
	oResultSet, cResource, cXML

oWsman = createobject("Wsman.Automation")
oSession = oWsman.CreateSession()

* Wildcard terminates the resource string
cResource = "http://schemas.microsoft.com/wsman/2005/06/wmi/root/cimv2/*"
cDialect = "http://schemas.microsoft.com/wsman/2005/06/WQL"

* Example queries:
* cFilter = [select EventCode from Win32_NTLogEvent where SourceName="WINRM"]
* cFilter = [select Name from Win32_Service where StartType="Disabled"]
cFilter = "select AdapterType,MACAddress from Win32_NetworkAdapter where PhysicalAdapter=True"

oResultSet = oSession.Enumerate(cResource, cFilter, cDialect)

do while not oResultSet.AtEndOfStream
	cXML = oResultSet.ReadItem
	DisplayProperties(cXML)
enddo

* Parse the XML manually this time
procedure DisplayProperties

	lparameters cXML
	local oParser, oNodes, cProperty, cValue, oItem

	oParser = createobject("MSXml2.DOMDocument.3.0")
	oParser.loadxml(cXML)
	oNodes = oParser.firstChild.firstChild.ChildNodes

	for each oItem in oNodes
		cProperty = oItem.basename
		cValue = oItem.nodetypedvalue
		? cProperty + ": " + cValue
	next

endproc

Calling methods

Methods - static and non-static - are called using the session object's Invoke method: input parameters and output parameters must be serialized as XML. This particular method - Win32_Process.Create - doesn't work in WinRM/Vista build 5308.

local oWSMan, oSession, cClass, cSchema, cNamespace, cResource, ;
	cMethod, cInputParameters, cOutputParameters

oWSMan = createobject("WSMAN.Automation")
oSession = oWSMan.CreateSession()

cSchema =  "http://schemas.microsoft.com/wsman/2005/06/"
cNamespace = "wmi/root/cimv2/"

* Create is a static method so obtain a generic class instance
* rather than a specific instance.

cClass = "WIN32_Process"
cMethod = "Create"

cResource = cSchema + cNamespace + cClass

* Create Input Parameter XML. 
cInputParameters = "<p:" + cMethod + "_INPUT "
cInputParameters = cInputParameters + 	[xmlns:p="] + cSchema + cNamespace + ["] + ">"

* Multiple parameters can be sent, but not embedded objects 
* (so the WIN32_ProcessStartup object cannot be sent)
cInputParameters = cInputParameters + GetParameterXML("CommandLine", "calc.exe")
cInputParameters = cInputParameters + GetParameterXML("CurrentDirectory", "c:\")

cInputParameters = cInputParameters + "<" + "/p:" + cMethod + "_INPUT" + ">"

cOutputParameters = oSession.Invoke(cMethod, cResource, cInputParameters)

* Extract the values directly from the XML using STREXTRACT (VFP7 or later)
cReturnValue = strextract(cOutputParameters, "<p:ReturnValue>", "</p:ReturnValue>")
cProcessID = strextract(cOutputParameters, "<p:ProcessID>", "</p:ProcessID>")

if cReturnValue = "0"
	cMessage = "Process created with an ID of " + cProcessID
else
	cMessage = "Process creation failed: return value was " + cReturnValue
endif

messagebox(cMessage)

procedure GetParameterXML
	lparameters cParameterName, cParameterValue
	cXML = "<p:" + cParameterName + ">" + cParameterValue + ;
		"</p:" + cParameterName + ">"
	return cXML
endproc

In part2 I will show how to make remote connections and to configure WinRM to allow connections over HTTP.

WMI part 4 - Implementing a temporary WMI Event consumer in VFP

stuartd — Fri, 16 Sep 2005 05:21:00 GMT

All the WMI queries so far in this series have been looking at static data, but WMI has a mechanism for checking for changes to local or remote computers and reacting to them: WMI events. Applications can register themselves as event consumers, and receive notifications of these changes. This article shows how, in VFP6 or later.

Extrinsic Events and Semi-Synchronous Queries

There are two main types of WMI events. The simpler ones are the extrinsic event classes. These report on events outside WMI's domain, and consequently have to have an event provider, which alerts WMI when the event takes place. Windows XP and 2003 introduce lots of fun new classes and event providers but only those available in Windows 2000 are used in this article (many are also available in Win 9x and/or NT). The power management event provider (2000+) and the registry event provider are the two main extrinsic event classes available across the spectrum of Windows versions.

Using a method of the WMI service object - ExecNotificationQuery - WMI is instructed to go away and wait for something to happen with our selected event class, and to come back and tell us when it does.

WMI event sample code usually uses this semi-synchronous method for event queries: the obvious attraction is that the syntax is compellingly simple. The downside (in a single-threaded environment like Foxpro at least) is that it blocks the calling application until the event is received, the call reaches it's (optional) timeout, or the application is forcibly terminated: whichever is the earliest. Running the following code sample completely blocks Foxpro for as many milliseconds are specified as the timeout, unless a power management event occurs in that time (you will need a laptop running Windows 2000 or later to generate an actual power management event.)

** Example of semi-synchronously querying an extrinsic event
** If you can't generate a power event, you need to wait for the timeout.

oWMILocator = createobject("WbemScripting.SWbemLocator")
oWMI = oWMILocator.ConnectServer(".", "root\cimv2")

cQuery = "select * from WIN32_PowerManagementEvent"
oResults = oWMI.ExecNotificationQuery(cQuery)
* Timeout in milliseconds...
nTimeout = 10000
oEvent = oResults.NextEvent(nTimeout)
* ... 12289 Error results if no event occurs within the timeout.
do case
	case oEvent.EventType = 4
		? "Entering Suspend"
	case oEvent.EventType = 7
		? "Resume from Suspend"
	case oEvent.EventType = 10
		? "Power Status Change" && mains <-> battery
	case oEvent.EventType = 11
		?  "OEM Event"
	case oEvent.EventType = 18
		? "Resume Automatic"
endcase

Asynchronous Queries and Sink Objects

Blocking behaviour like this effectively useless, so it's just as well that there is another way - as long as we are querying our local computer, we can use asynchronous queries instead. Asynchronous calls to other computers are strongly discouraged due to security considerations and may fail because of them. There is a workaround for semi-synchronous queries, unsurprisingly involving worker threads, which I will come to later.

The ExecNotificationQueryAsync method is used for asynchronous event queries. There are two required parameters: a notification query to execute, and a WMI sink object to receive the event notification from WMI. WMI provides the sink class, all we need to do from VFP is create a VFP sink object and bind it to the WMI sink's events. In VFP7 and later, the intrinsic VFP EventHandler function can be used, but for VFP6 the VFPCom utility is required. The latest version of VFPCom works with VFP6: you'll see in the code later that the sink class syntax differs slightly when using VFPCOM to bind the two objects together.

The WMI sink's OnObjectReady event fires when the notification query finds a hit, and receives the class we are monitoring. OnComplete fires when the query ends, or is cancelled (the WMI sink object has a Cancel method which is used to cancel all asynchronous queries bound to it).

Intrinsic Events

The second type of WMI events, intrinsic events, allow monitoring any of the WMI classes (representing hardware, Windows components, programs, etc) and raise an event as required when an instance of the target class is 'created', 'modified', or 'deleted' - the precise nature of the actual event that generates this instance depends on the class context. The query syntax is a bit more complex for this type of events.

As an example, a simple query would monitor for a new process (i.e. program) being started on the computer. In the query, we need to request instances of a WMI system class, in this case __InstanceCreationEvent, to generate the event when a new instance of the process class is created by a program being started. We also need to specify a polling interval for the WITHIN clause, which is mandatory for event queries which don't have an event provider (an error is raised if it's omitted). The interval is the maximum amount of time in seconds that can elapse before notification of an event must be delivered: the right value to use depends on what you are monitoring. Higher values will receive notifications less frequently, low values (less than 1) affect system and application performance and may eventually generate an error.

Intrinsic event queries must have a WHERE clause: at the least, the event class's TargetInstance property must be the target class name as specified by the ISA operator (instances of all subclasses of the specified class are monitored). A more specific where clause will result in better performance: it must follow the "property operator value" syntax throughout though. Note that the where clause cannot reference any array properties the class may have.

Put these pieces together and this valid query is the result: it checks every three seconds for a new process being started.

select * from __InstanceCreationEvent within 3 where TargetInstance ISA 'Win32_process'

Now we can call the ExecNotificationQueryAsync with the WMI sink object and query. Whan a new process is created, the sink object's OnObjectReady event fires, the instance creation object is received, and has a reference to the new object in it's TargetInstance property. Note that WMI will create a process of it's own - unsecapp.exe - to handle the callback from the asynchronous method call.

Event catching class

If either sink variable goes out of scope, they are automatically unbound, so it's useful to encapsulate them in a class. This sample code uses a general event catching class to watch for new processes being started. There are two versions, one suitable for use in VFP7 or later and one for use in VFP6 or (possibly) earlier which requires the VFPCom utility from Microsoft. Subsequent examples will only show the newer sink syntax.

** Demo query: when a new process is started, echo it's WMI path to the screen.
* RELEASE oEventCatcher in the command window when you tire of receiving events.

public oEventCatcher
* Change class to eventcatcher6 for VFP6 version
oEventCatcher = createobject("eventcatcher")

cQuery = [select * from __InstanceCreationEvent within 3 where TargetInstance ISA 'Win32_process']
oEventCatcher.CatchEvents(cQuery)

return

**
** Event catching class
**

* VFP7+ version

define class eventcatcher as relation

	oSink = .null.
	oWbemSink = .null.
	oWMI = .null.

	procedure init

		this.oWMI = getobject("winmgmts:")
		* Create the sink objects and bind them
		this.oWbemSink = createobject("wbemscripting.swbemsink")
		this.oSink = createobject("vfpsink")
		eventhandler(this.oWbemSink, this.oSink)

	endproc

	procedure destroy

		if vartype(this.oWbemSink) = "O"
			this.oWbemSink.Cancel()
		endif

	endproc

	procedure CatchEvents
		lparameters cQuery
		* Send the WMI sink not the VFP one.
		this.oWMI.ExecNotificationQueryAsync(this.oWbemSink, cQuery)
	endproc

enddefine

** The sink class is easier to manage when decoupled from the eventcatcher class

define class vfpsink as relation

	implements ISWbemSinkEvents in "WbemScripting.SWbemSink"

	procedure ISWbemSinkEvents_OnObjectReady(oObject, oAsyncContext)
		* Assign the TargetInstance object reference to a property at this point.
		? oObject.TargetInstance.Path_.Path
	endproc

	procedure ISWbemSinkEvents_OnCompleted(nResult, oErrorObject, oAsyncContext)
	procedure ISWbemSinkEvents_OnProgress(nUpperBound, nCurrent, cMessage, oAsyncContext)
	procedure ISWbemSinkEvents_OnObjectPut(oObjectPath, oAsyncContext)

enddefine

** VFP6- version

define class eventcatcher6 as relation

	oSink = null
	oWbemSink = null
	oWMI = null
	oVFPCom = null

	procedure init

		oWMILocator = createobject("WbemScripting.SWbemLocator")
		this.oWMI = oWMILocator.ConnectServer(".", "root\cimv2")
		* Create the sink objects and bind them
		this.oWbemSink = createobject("wbemscripting.swbemsink")
		this.oSink = createobject("vfpsink6")
		this.oVFPCom = createobject("vfpcom.comutil")
		this.oVFPCom.BindEvents(this.oWbemSink, this.oSink)

	endproc

	procedure destroy

		if vartype(this.oWbemSink) = "O"
			this.oWbemSink.Cancel()
		endif

	endproc

	procedure CatchEvents
		lparameters cQuery
		this.oWMI.ExecNotificationQueryAsync(this.oWbemSink, cQuery)
	endproc
enddefine


define class vfpsink6 as relation

	procedure OnObjectReady
		lparameters oObject, oAsyncContext
		? oObject.TargetInstance.Path_.Path
	endproc

	procedure OnCompleted
		lparameters nResult, oErrorObject, oAsyncContext
	procedure OnProgress
		lparameters nUpperBound, nCurrent, cMessage, oAsyncContext
	procedure OnObjectPut
		lparameters oObjectPath, oAsyncContext

enddefine

Extending the event catcher

One scenario an application might have to deal with is starting a process, and waiting for it to terminate. We can do this using the __InstanceDeletionEvent class. This still receives a TargetInstance reference (it is to a copy of the deleted object.)

public oEventCatcher
oWMILocator = createobject("WbemScripting.SWbemLocator")
oWMI = oWMILocator.ConnectServer(".", "root\cimv2")
oEventCatcher = createobject("eventcatcher")
oProcessClass = oWMI.Get("Win32_Process")

* Can't just call the static Create method as we won't get a reference 
* to the new process: another approach is needed:
* use the OutParameters object's Process ID property 

* First create the InParameters object:
oInParameters = oProcessClass.Methods_("Create").InParameters.SpawnInstance_

* Set the required command line property for the process to be monitored:
oInParameters.CommandLine = "notepad.exe"

* Now call the method using ExecMethod which returns the OutParameters object:
oOutParameters = oWMI.ExecMethod("WIN32_process", "Create", oInParameters)

* Now we can construct the event query which will fire when this
* specific process ends... no idea what's with Windows 9x here,
* but the (-ve) process ID needs tweaking, at least under Virtual PC.

cQuery = "select * from __InstanceDeletionEvent within 1 "
cQuery = cQuery + " where TargetInstance ISA 'Win32_Process' and TargetInstance.ProcessID="
if os() = "Windows 4"
	nProcessID = 4294967296 + oOutParameters.processID
else
	nProcessID = oOutParameters.processID 
endif

cQuery = cQuery + str(nProcessID)
? cQuery

* Execute the query.
oEventCatcher.CatchEvents(cQuery)

There is one more intrinsic event class, __InstanceModificationEvent: this adds a PreviousInstance property, which has a reference to the object before it was modified. This is very useful for detecting specific changes: the where clause must still follows the property-operator-value syntax though: a query containing "where TargetInstance.Property <> PreviousInstance.Property" will result in an Unparsable Query error.

This query watches for a disk being inserted into a CD drive:

select * from __InstanceModificationEvent within 1 where TargetInstance ISA 'Win32_CDROMDrive' 
and TargetInstance.MediaLoaded = True and PreviousInstance.MediaLoaded = False

Another example watches installed printers for a change of orientation:

select * from __InstanceModificationEvent within 1 where TargetInstance ISA 'Win32_PrinterConfiguration' 
and (TargetInstance.Orientation = 1 and PreviousInstance.Orientation = 2
or TargetInstance.Orientation = 2 and PreviousInstance.Orientation = 1)

What you look for with a WMI event query depends on your application's needs: the extrinsic power management query we used at the beginning of the article will work asynchronously (the receiving sink class would have to change as it will receive the Win32_PowerManagementEvent class instead of one of the intrinsic event classes, so would not then need to reference TargetInstance.) An application could augment that by directly monitoring a laptop's power status by looking at the BatteryStatus property of the Win32_PortableBattery class.. This is probably achievable using BindEvent in VFP9, but not at all easy to achieve otherwise in earlier versions of VFP.

All the notification classes derive from __InstanceOperationEvent - in order to query more than one type of operation we can request instances of this class. The query will raise events for all three subclasses, and the sink can determine which is which by the object's Path_.Class property. There's an example of this later on.

Using the event catcher to catch Event Log events

It's easy to use this technique to monitor for specific events in the Windows Event Log:

* See all events:
select * from __InstanceCreationEvent where TargetInstance ISA 'Win32_NTLogEvent'

* Catch only specific events: 4202 is a network transport failure
select * from __InstanceCreationEvent where TargetInstance ISA 'Win32_NTLogEvent'
and TargetInstance.EventCode=4202

* Catch only events from a specific source: in this case WMI itself.
select * from __InstanceCreationEvent where TargetInstance ISA 'Win32_NTLogEvent'
and TargetInstance.SourceName='WinMgmt'

This will raise an error on a local query if the query results include a log event from the Security Event Log. Access to the Security log requires a WMI privilege to be added to the connection: this should be done at the time of the call in Windows 2000+ but must be requested as part of the original connection in Windows 95/NT. See my WMI connection class for how to do that.

define class logeventcatcher as eventcatcher

	procedure CatchEvents
		lparameters cQuery
		* Required to access the Security log
		this.oWMI.Security_.Privileges.AddAsString("SeSecurityPrivilege")
		dodefault(cQuery)
	endproc

enddefine

If you look at the properties of a Log Event, you'll see that several use the WMI time format - e.g. 20050905151317.000000+060. In order to easily transform these into VFP datetime values you can use this format code:

cWMIDate = oEvent.TimeGenerated
tDateTime = ctot(transform(cWMIDate, '@R 9999-99-99T99:99:9999'))

The final component of the WMI datetime (+060 in the example above) indicates the offset in minutes from GMT. (There's a scripting object which works with WMI dates but it's only available in Windows XP/2003.)

Incidentally, the upper case "T" in the format mask is used to tell CTOT() that it should internally switch to YMD format for the date conversion regardless of what the SET DATE settings are currently.

Querying Association Class Events

Association classes are the glue classes that tie the WMI class hierarchy together. An association class represents a relationship between objects - Win32_UserDesktop relates users and their desktop settings: if you have one, you can determine the other. Other association classes represent the relationship between a single entity and a group - an instance of one of these classes has a property for the "owner" object and a collection representing the "owned" objects. CIM_ProcessExecutable links processes and the files they have open, for example.

This sample association class query watches a specific directory - in this case c:\temp - for files being created, changed, or deleted. The query includes both single and double quotes, and note the amount of escaping required on the backslashes. This will work for mapped network drives but not UNC paths.

select * from __InstanceOperationEvent within 3 where 
TargetInstance ISA 'CIM_DirectoryContainsFile' and
TargetInstance.GroupComponent='WIN32_Directory.name="c:\\\\temp"'

We need to change the sink class for this query as the TargetInstance is an association class: association classes have a number of ways to refer to their components: in this case, GroupComponent and PartComponent are the association properties, but other property pairs used include Antecedent/Dependent, and Element/Setting. The difference from our point of view here is that we don't receive a reference to an instance of the class in the association class, we instead get the full WMI path. If the object still exists, then the WMI Get() method can be used to get an object reference, but that's not the case for __InstanceDeletion as is shown here:

procedure ISWbemSinkEvents_OnObjectReady(oObject, oAsyncContext)

	* Scratch WMI object
	oWMILocator = createobject("WbemScripting.SWbemLocator")
	oWMI = oWMILocator.ConnectServer(".", "root\cimv2")

	do case
		case oObject.Path_.class = "__InstanceCreationEvent"
			oFile = oWMI.get(oObject.TargetInstance.PartComponent)
			? "File " + oFile.name + " was created with filesize " + oFile.FileSize

		case oObject.Path_.class = "__InstanceModificationEvent"
			* This never fires for file modifications. Renaming a file produces a
			* deletion event and a creation event instead.
			? "This never fires for files"

		case oObject.Path_.class = "__InstanceDeletionEvent"
			* Can't "get" an object that's been deleted.
			? oObject.TargetInstance.PartComponent + " was deleted"
	endcase

endproc

A solution for remote semi-synchronous queries

We started this by looking at the semi-synchronous event query ExecNotificationQuery, which blocked Foxpro while waiting for the event. Asynchronous queries are a solution for local queries, but are strongly discouraged for use with remote queries. We can use semi-synchronous remote queries if we can create a worker thread for each, though: fortunately, there is a 3rd party COM component that enables VFP applications to launch background tasks in separate threads, and is free to use and distribute according to the accompanying license (it requires MSVCP70.DLL too).

To see it in action, create a project and compile a MTDLL with this program as the main: save it as wmimtdll.dll (if you prefer to use another name the name will have to be changed in the call below)

define class eventcatcher as session olepublic

	procedure init
	procedure destroy

	procedure CatchEvents
		lparameters cQuery, cServer, cNamespace && cUsername, cPassword etc
		oLocator = createobject("wbemscripting.swbemlocator")
		* See http://weblogs.foxite.com/stuartdunkeld/archive/2005/09/14/910.aspx
		* for username syntax or use the WMI Connection class.
		oWMI = oLocator.ConnectServer(cServer, cNamespace, "", "", "", "", 128)
		oResults = oWMI.ExecNotificationQuery(cQuery)
		oEvent = oResults.NextEvent()
		return oEvent
	endproc

	procedure error(nError, cMethod, nLine)
		comreturnerror("MTEventCatcher", "Error " + transform(nError) + " at line " + transform(nLine) + " of " + cMethod)
	endproc

enddefine

We still need a sink to receive the event: we make our own this time. There's a version for VFP6 too.

define class mtsink as relation

	implements _IWorkerEvents in "vfpmtapp.worker"

	procedure _IWorkerEvents_OnTerminate
		lparameters vResult
		? vResult.TargetInstance.Name
	endproc

enddefine

define class mtsink6 as relation

	procedure OnTerminate
		lparameters vResult
		? vResult.TargetInstance.Name
	endproc

enddefine

It won't come as a blinding surprise that now we create the various objects and bind them together. Note we pass the thread factory an array containing the parameters to be passed to the VFP object method call. This will only work in the command window unless the variables are kept in scope.

* This is the 3rd party component
oThreadFactory = createobject("vfpmtapp.worker.1")

* VFP7: create the sink and bind it.
oSink = createobject("mtsink")
eventhandler(oThreadFactory, oSink)

* VFP6
* oSink = createobject("mtsink6")
* oVFPCom = createobject("vfpcom.comutil")
* oVFPCom.BindEvents(oThreadFactory, oSink)

cQuery = "select * from __InstanceCreationEvent within 1 where TargetInstance ISA 'WIN32_Process'" 
cServer = "remote_computer" && this will still work locally.

dimension aParameters[3]
aParameters[1] = cQuery
aParameters[2] = cServer
aParameters[3] = "root\CIMV2"
* Change this call if you chose another name for the DLL:
oThreadFactory.Run("wmimtdll.eventcatcher", "CatchEvents", @aParameters)

There are limitations to using this control: as the author states "If you return an object ... do not cache a reference to it, the object will be destroyed after the the last notification is executed, because the working thread that hosts this object will end". This means that when the sink's OnTerminate method finishes, the object reference disappears so all the object processing needs to take place in the sink (which can call other methods). Another issue (with WMI more than with the control) is that after NextEvent has returned an event, the thread ends and the query has to be reinvoked.

Providing worker threads sounds like something Sedna could do: until then, this will do, especially in a scenario where one computer is querying many remote computers and there are no distribution issues to worry about.

Temporary and Permanent event consumers

Thus far we have looked at the events that applications or their users might be interested in: the techniques used only allow events to be caught while an application or script is running. There are numerous events that it would be very useful to monitor all the time, whether an application is running or not, and especially on a server: checking for free diskspace of less than 10% on any disk, or CPU usage stuck at 100%, memory usage going through the roof, unknown processes or services, UPS status - WMI has an inbuilt mechanism for this kind of event query. If you create a Permanent Event Consumer (a COM object implementing the IWbemUnboundObjectSink interface) linked to an EventFilter query, then when the event fires, WMI will instantiate the object and pass it the event data.

Edit: this isn't possible in VFP, whose implementation of IMPLEMENTS is lacking the capability of returning the interface when requested via CoGetClassObject. The error hresult is 0x80040154, CLASS_NOT_REGISTERED.

WMI part 3 - Remote Queries

stuartd — Wed, 14 Sep 2005 21:49:00 GMT

One of the principles of WMI is that everything that can be queried or set locally should be able to be done remotely.

WMI makes no distinction between local and remote access ... The difference between a local and a remote connection is that users can specify a user name and password in a remote connection, replacing the current user name and password. With a local connection, users cannot override the current name and password."
Connecting to WMI on a remote computer

With the odd exception this is true: any WMI query can be run remotely, including event notification queries.

To initiate a remote WMI connection (assuming all required services are correctly configured) you need to have administrative rights on the local computer. Also, you have to be using (or be able to specify the credentials of) an account with the rights to connect to the target computer and which has have the Remote Enable access permission on the WMI namespace you want to connect to. (For computers not in a domain, the account should have the same username and password on each computer). This access right is given by default to the Administrators group only, so effectively administrative rights are needed on the target computer. This makes the security model for remote access very simple - if you can initiate a connection, you get access to everything you would normally have access to, and as you're an admin that's everything anyway.

This sample class illustrates local and remote connections. It should work in VFP6 or later. Leave username, domain and password blank to connect with the current user context: from a security point of view, this is preferable as ConnectServer sends the password across the network as plain text unless your network uses Kerberos authentication.

WMI connection class

** Example usage: query a remote PC for the startup commands buried in the registry
oWMIConnection = createobject("WMIConnect")
oWMIConnection.cDomain = "domain"
oWMIConnection.cUsername = "remoteadmin"
* Computer can be specified by IP address or DNS name.
oWMIConnection.cComputer = "target" 
oWMIConnection.cPassword = "itsasecret"
oWMI = oWMIConnection.GetConnection()
if vartype(oWMI) = "O"
	oCommands = oWMI.ExecQuery("Select * from WIN32_StartupCommand")
	? transform(oCommands.Count) + " startup commands found"
endif

** WMI connection class

define class WMIConnect as relation

	** User/domain settings
	cDomain = ""
	cUserName = ""
	cPassword = ""

	** Target computer. 
	cComputer = "" 

	** WMI settings
	cNameSpace = "root/cimv2"

	* Without this flag, a connection attempt would wait indefinitely.
	* nFlags = 128 && XP or better only..
	nFlags = 0

	* Find your Locale ID here: 
	* http://www.microsoft.com/globaldev/reference/win2k/setup/lcid.mspx
	cLocale = "MS_409" && EN-US

	** Security settings.
	nImpersonationLevel = 3 && wbemImpersonationLevelImpersonate
	nAuthenticationLevel = 0 && wbemAuthenticationLevelDefault

	* If .T., load all privileges before connection.
	lLoadPrivileges = .f.

	procedure GetConnection

		local cUserName, cPassword, lRemote, oWMILocator, ;
			oPrivileges, oWMIServices, nPrivilegeID

		if empty(this.cComputer)
			* Use "." for a local connection
			this.cComputer = "."
		endif

		if this.cComputer = "."
			* Cannot use credentials to connect locally
			* even if they are the ones currently in use.
			cUserName = ""
			cPassword = ""
			lRemote = .f.
		else
			cUserName = iif(not empty(this.cDomain), this.cDomain + "\", "") + this.cUserName
			cPassword = this.cPassword
			lRemote = .t.
		endif

		oWMILocator = createobject("WbemScripting.SWbemLocator")

		if lRemote
			* Apply settings for DCOM:
			oWMILocator.Security_.ImpersonationLevel = this.nImpersonationLevel
			oWMILocator.Security_.AuthenticationLevel = this.nAuthenticationLevel
		else
			* Privileges only need to be applied for on local system
			* but must be requested *before* connection on Windows 9x/NT
			if this.lLoadPrivileges
				for nPrivilegeID = 1 to 27
					oWMILocator.Security_.Privileges.add(nPrivilegeID)
				next
			endif
		endif

		cAuthority = "" && for kerberos, see PSDK

		* Connect as specified...
		oWMIServices = oWMILocator.ConnectServer ;
			(this.cComputer, this.cNameSpace, cUserName, cPassword, ;
			this.cLocale, cAuthority, this.nFlags)

		* ... and return the WMI service object.
		return oWMIServices

	endproc

	procedure error(nError, cMethod, nLine)

		* Sample error code
		* This needs to be tested across versions to make sure 
		* same errors are raised.
		local arrErr[1]
		aerror(arrErr)
		display memory like arrErr

		if nError = 1429 or nError = 1427
			nError = arrErr(7)
		else
			messagebox("Error " + transform(nError) + " has occurred")
			* Oops..
		endif

		do case		
			case nError = 4110
				? "Invalid namespace"
			case nError = 4099
				? "Valid credentials, but not allowed to connect"
			case nError = 5
				? "Invalid credentials"
			case nError = 1722
				? "Remote computer not found" 
		endcase
	endproc

enddefine

Impersonation and Authentication

The Impersonation Level specifies whether your security credentials are available to WMI. Of the four options, the documentation says of two that "calls to WMI may fail with this impersonation level" and the fourth "may constitute an unnecessary security risk." This leaves the value "impersonate", and this is the default in Windows 2000 or later - or, to be completely accurate, the value in the registry key 'HKLM\Software\Microsoft\wbem\Scripting\Default Impersonation Level' is the default. This is why impersonationLevel is set to impersonate in all WMI scripts designed for potential remote use.

The Authentication Level determines how secure the connection is. This is constrained by the target operating system: Windows XP won't accept a connection less than 'packet', Windows 9x can't accept connections greater than 'connect'. Fortunately, using the default setting (wbemAuthenticationLevelDefault) allows DCOM to negotiate the appropriate security level.

There are a number of complications when connecting between different versions of Windows, and sometimes specific impersonation and authentication levels need to be set - see this document for the details. Generally, going downstream - from newer to older - is easier than upstream; crossing two or more generations of Windows either way can be problematic and is sometimes impossible.

Optimising the performance of remote queries

Add the WBEM_FLAG_FORWARD_ONLY flag to get one-time forward-enumeration objects: the returned collection object does not populate it's Count property (or support the Clone_ method) and is released as soon as it has been enumerated.

If practical, specify a specific field list rather than * in the SELECT statement.

Don't use moniker syntax even if you are connecting with the current user account.

Use as specific a WHERE clause as possible.

Setting WMI security with the Windows WMI Control

The WMI access permissions are set via the WMI control, which is hidden in the Services and Applications section of Windows 2000/XP Computer Management [or via start/run/wmimgmt.msc]. To access it, right-click on "WMI Control" and choose Properties. Here you can check the default WMI namespace, activate some very verbose logging, and back up the WMI repository. On the security tab is a familiar Windows Access Control Entries (ACE) dialog which enables allowing or denying specific permissions to each namespace on your computer. Here you can disable remote access to WMI namespaces, if you're paranoid but don't want to stop the WMI service altogether.

Alternatively, in some circumstances you could here give an account permission to make a remote connection (and perform some actions) without giving it administrative rights as such, on the general principle it's best to initiate connections with as few rights as possible in order to accomplish the task at hand. (The account will also need DCOM remote connect rights, in Windows 2000/XP these are set with the other DCOM settings in the Component Services manager which can be started from the Administrative Tools menu: right click on the "My Computer" entry in the "Computers" tree and choose "Properties" to access them. Use dcomcnfg.exe for NT and Windows 9x.

Troubleshooting

Notes / command snippets

netsh firewall set service type=remoteadmin mode=enable scope=all profile=all

COM+ scripting

stuartd — Wed, 24 Aug 2005 21:53:00 GMT

This is extracted from a COM+ admin class I wrote for a work project: it illustrates how to view the properties of a COM+ application and it's associated components. It needs Windows 2000 or XP to work, and will report on the system helper applications that are installed by default with COM+ if you don't have a COM+ application as such.

* Admin Catalog interface:
* oAdminCatalog as COMAdmin.COMAdminCatalog

* Collection interfaces (oApplications, oComponents, oApplicationProperties)
* oApplications as COMAdmin.COMAdminCatalogCollection

* Object interface - oApp, oComponent, oProperty
* oApp as COMAdmin.COMAdminCatalogObjectb

clear

* cServer = "complus_server"
* use empty string for local computer
cServer = ""

* Root COM+ admin object
oAdminCatalog = .null.

* COM+ Applications objects
oApplications = .null.
oApp = .null.

* Component objects:
oComponents = .null.
oComponent = .null.

* Property objects
oApplicationProperties = .null.
oComponentProperties = .null.

* Go!
oAdminCatalog = createobject("COMAdmin.COMAdminCatalog")
oAdminCatalog.connect(cServer)

oApplications = oAdminCatalog.GetCollection("Applications")
oApplications.Populate()

for each oApp in oApplications

	* To ask the application collection what properties it supports
	* we need to send a key - zero will do.
	oApplicationProperties = oApplications.GetCollection("PropertyInfo", 0)
	oApplicationProperties.Populate()

	* Send the app's CLSID to get the components collection:
	oComponents = oApplications.GetCollection("Components", oApp.key)

	* Ask the components collection what properties it supports
	oComponentProperties = oComponents.GetCollection("PropertyInfo", 0)
	oComponentProperties.Populate()

	* Only need to do this once.
	exit
next

for each oApp in oApplications

	? "Application: " + oApp.name
	? "--------------------------------------"
	GetApplicationProperties(oApp)
	?

	oComponents = oApplications.GetCollection("Components", oApp.key)
	oComponents.Populate()

	for each oComponent in oComponents
		GetComponentProperties(oComponent)
		* One component per listing
		exit
	next
	
	* One application per listing
	exit
next

return

procedure GetApplicationProperties (oApp)

	local oProperty, cValue

	for each oProperty in oApplicationProperties

		? oProperty.name + ": "
		* Properties - e.g. 'Password' - can be write only.
		if oApp.IsPropertyWriteOnly(oProperty.name) = .f.
			cValue = transform(nvl(oApp.value(oProperty.name), ""))
		else
			cValue = "[Write only]"
		endif
		?? cValue
	next

endproc

procedure GetComponentProperties(oComponent)

	local oProperty, cValue

	? "Component: " + oComponent.name
	? "--------------------------------------"

	for each oProperty in oComponentProperties

		? oProperty.name + ": "

		* Properties - e.g. 'Password' - can be write only.
		if oComponent.IsPropertyWriteOnly(oProperty.name) = .f.
			cValue = transform(nvl(oComponent.value(oProperty.name), ""))
		else
			cValue = "[Write only]"
		endif
		?? cValue
	next

endproc

Accessing user information from Foxpro with ADSI

stuartd — Fri, 05 Aug 2005 18:49:00 GMT

There are a number of ways by which an application can gather information about the current user, whether this is a local computer account, a domain account, or an Active Directory account. Workstations using Windows NT or 9x need to have the Active Directory client installed - download from here.

There are two protocols available for accessing directory information:

WinNT:// is required to access users on NT domains or for Active Directory queries from a PC which isn't a member workstation in the Active Directory.
LDAP:// gives full access to the Active Directory.

[Test LDAP:// with local accounts on winxp, 2k etc]

This code illustrates how to enumerate the Property collections of ADSI objects to show what is available and how to access the values (each property type has an associated method to return the value). It can use the WinNT or LDAP. Useful references are the Active Directory user class, the list of properties not supported by WinNT: and the extra properties added. - the latter list is a lot shorter than the former. Schema extensions such as Microsoft Exchange can be accessed via LDAP which can drastically increase the amount of information available.. Each schema has a helper object - WinNTSystemInfo and ADSystemInfo - to provide the information required to access user information.

The code in this article illustrates how to access the local user information (and, if connected to a domain, workstation information) using WinNT and LDAP. It shows how to extract the individual properties from the UserAccountControl property (UserFlags in WinNT), and how to access property values via the Properties collection. It also illustrates how to calculate the password expiry date under each protocol.

clear

local oWinNTSystemInfo, cDomain, cUserName, cComputer, ;
	oDomain, oUser, oComputer, oADSystemInfo, lLDAP, ;
	nUserFlags, tExpiryDateTime, oGroup

* Use WinNT:// by default - this should work on any system with the AD client.
oWinNTSystemInfo = createobject("WinNTSystemInfo")

cDomain = oWinNTSystemInfo.DomainName
cUserName = oWinNTSystemInfo.UserName
cComputer = oWinNTSystemInfo.ComputerName

* If WinNTSystemInfo doesn't work as expected in all environments
*	 cDomain = "." && local machine
*	 cUserName = alltrim(substr(sys(0), at("#", sys(0)) + 1))
*	 cComputer = alltrim(left(sys(0), at("#", sys(0)) - 1))

* NOTE: these monikers are case-sensitive:
* Winnt: and WINNT: and ldap: and Ldap: won't work

oDomain = getobject("WinNT://" + cDomain)
oUser = getobject("WinNT://" + cDomain + "/" + cUserName + ",user")

try && error if not connected to domain
	oComputer = getobject("WinNT://" + cDomain + "/" + cComputer + ",computer")
catch
endtry

* Try to use LDAP://
oADSystemInfo = createobject("ADSystemInfo")

try
	* PCs not connected to a domain will error as soon as any property is accessed
	cDomain = oADSystemInfo.DomainShortName
	cUserName = oADSystemInfo.UserName
	cComputer = oADSystemInfo.ComputerName

	oDomain = getobject("LDAP://" + cDomain)
	oUser = getobject("LDAP://" + cUserName)
	oComputer = getobject("LDAP://" + cComputer)

	lLDAP = .t.
catch
	lLDAP = .f.
endtry

* The rest of the code works whether using LDAP or WinNT.

* The AccountDisabled property doesn't appear in the property list
* but it's available without calling GetInfo which would save
* resources when enumerating a list of users.

* Test local guest user is disabled with
* oUser = getobject("WinNT://./Guest,user")

if oUser.AccountDisabled
	? "Account is disabled"
	return
endif

? "User flags"
? "--------------"
if lLDAP
	nUserFlags = oUser.UserAccountControl
else
	nUserFlags = oUser.UserFlags
endif
GetUserFlags(nUserFlags)

?
? "User properties"
? "---------------------"

* Populate the properties (the data may be there but the propertycount
* isn't until this has been called)
oUser.GetInfo()
* Pass True as second parameter to see all the properties and values
ShowProperties(oUser, .f.)

* Groups, workstation
?
? "Group memberships"
? "---------------------"

for each oGroup in oUser.Groups
	? oGroup.name
next

?
? "First group's properties"
? "---------------------"
for each oGroup in oUser.Groups
	oGroup.GetInfo()
	ShowProperties(oGroup, .f.)
	exit
next


?
? "Workstation properties"
? "---------------------"

if vartype(oComputer) = "O"
	oComputer.GetInfo()
	ShowProperties(oComputer, .f.)
else
	? "Not available"
endif

?
? "Password expiry"
? "---------------------"

if lLDAP
	tExpiryDateTime = GetPasswordExpiryLDAP(oDomain, oUser)
else
	tExpiryDateTime = GetPasswordExpiryWinNT(oDomain, oUser)
endif

if not empty(tExpiryDateTime)
	? "Password expires " + ttoc(tExpiryDateTime)
endif

procedure GetPasswordExpiryLDAP

	lparameters oDomain, oUser
	* Firstly determine the password policy:
	local oMaxPwdAge, dExpiryDate, nNumDays

	oMaxPwdAge = oDomain.get("maxPwdAge")
	if oMaxPwdAge.LowPart = 0
		* Domain policy doesn't expire passwords
		dExpiryDate = {--}
	else
		* Number of 100 nanosecond intervals since 1.1.1601!
		nNumDays =  ((oMaxPwdAge.HighPart * 2 ^ 32) + ;
			oMaxPwdAge.LowPart) / -864000000000
		* Convert the policy to seconds to match PasswordLastChanged
		* and calculate expiry date and time.
		dExpiryDate = oUser.PasswordLastChanged + (nNumDays * 24 * 60 * 60)
	endif


	return dExpiryDate

endproc

procedure GetPasswordExpiryWinNT

	lparameters oDomain, oUser

	* Firstly determine the password policy:
	local nMaxPasswordAge, nActualPasswordAge, tExpiry
	try
		* Errors for local accounts which don't have MaxPasswordAge set
		nMaxPasswordAge = oDomain.MaxPasswordAge && in seconds
		nActualPasswordAge = oUser.PasswordAge && in seconds
		* Calculate expiry date and time.
		tExpiry = datetime() + nMaxPasswordAge - nActualPasswordAge
	catch
		tExpiry = {--::}
	endtry

	return  tExpiry

endproc

procedure ShowProperties

	lparameters oObject, lVerbose
	local oProperty, nCount, oValue

	if lVerbose
		for nCount = 0 to oObject.PropertyCount - 1

			* Access the properties collection by item
			oProperty = oObject.item[nCount]

			if not isnull(oProperty.values)
				for each oValue in oProperty.values
					? oProperty.name + " : " + transform(GetPropertyValue(oValue))
				next
			else
				? oProperty.name + " is null"
			endif
		next
	else
		? "Object has " + ltrim(str(oObject.PropertyCount)) + " properties"
	endif

endproc

procedure GetPropertyValue

	lparameters oValue

	local nType
	nType = oValue.ADSType

	* Each type has it's own method to return the value..?
	* See below for the full list.

	do case
		case nType = 1
			return oValue.DNString()

		case nType = 2
			return oValue.CaseExactString()

		case nType = 3
			return oValue.CaseIgnoreString()

		case nType = 4
			return oValue.PrintableString()

		case nType = 5
			return oValue.NumericString()

		case nType = 6
			return oValue.Boolean()

		case nType = 7
			* Reserved word
			return oValue.integer()

		case nType = 8
			return oValue.OctetString()

		case nType = 9
			return oValue.UTCTime()

		case nType = 10
			return oValue.LargeInteger()

		case nType = 25
			return oValue.SecurityDescriptor()

		otherwise
			* Other types can't be obtained through this interface.
			return .null.

	endcase

endproc

procedure GetUserFlags

	lparameters nFlags

	if bittest(nFlags, 0) && ADS_UF_SCRIPT, 1
		? "The logon script is executed."
	endif

	if bittest(nFlags, 1) && ADS_UF_ACCOUNTDISABLE, 2
		? "This user account is disabled."
	endif

	if bittest(nFlags, 3) && ADS_UF_HOMEDIR_REQUIRED, 8
		? "The home directory is required."
	endif

	if bittest(nFlags, 4) && ADS_UF_LOCKOUT, 16
		? "This account is currently locked out."
	endif

	if bittest(nFlags, 5) && ADS_UF_PASSWD_NOTREQD, 32
		? "No password is required for this account."
	endif

	if bittest(nFlags, 6) && ADS_UF_PASSWD_CANT_CHANGE, 64
		? "This user cannot change their password."
	endif

	if bittest(nFlags, 7) && ADS_UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED, 128
		? "This user can send an encrypted password."
	endif

	if bittest(nFlags, 8) && ADS_UF_TEMP_DUPLICATE_ACCOUNT, 256
		? "This is an account for users whose primary account is in another domain."
	endif

	if bittest(nFlags, 9) && ADS_UF_NORMAL_ACCOUNT, 512
		? "This is a default account type that represents a normal user."
	endif

	if bittest(nFlags, 16) && ADS_UF_DONT_EXPIRE_PASSWD, 65536
		? "The password will not expire on this account."
	endif

	if bittest(nFlags, 23) && ADS_UF_PASSWORD_EXPIRED, 8388608
		? "This user's password has expired."
	endif

	* Full list of flags at
	* http://msdn.microsoft.com/library/en-us/adsi/adsi/ads_user_flag_enum.asp

endproc


* Property type constants

#define ADSTYPE_INVALID			0	&&	The data type is invalid.
#define ADSTYPE_DN_STRING		1	&&	the string is a Distinguished Name (path) of a directory service object.
#define ADSTYPE_CASE_EXACT_STRING	2	&&	the string is the case-sensitive type.
#define ADSTYPE_CASE_IGNORE_STRING	3	&&	the string is the case-insensitive type.
#define ADSTYPE_PRINTABLE_STRING	4	&&	The string is displayable on screen or in print.
#define ADSTYPE_NUMERIC_STRING		5	&&	the string is a numeral to be interpreted as text.
#define ADSTYPE_BOOLEAN			6	&&	the data is a Boolean value.
#define ADSTYPE_INTEGER			7	&&	the data is an integer value.
#define ADSTYPE_OCTET_STRING		8	&&	the string is a byte array.
#define ADSTYPE_UTC_TIME		9	&&	the data is the universal time as expressed in Universal Time Coordinate (UTC).
#define ADSTYPE_LARGE_INTEGER		10	&&	the data is a long integer value.
#define ADSTYPE_PROV_SPECIFIC		11	&&	the string is a provider-specific string.
#define ADSTYPE_OBJECT_CLASS		12	&&	Not used.
#define ADSTYPE_CASEIGNORE_LIST		13	&& 	the data is a list of case insensitive strings.
#define ADSTYPE_OCTET_LIST		14	&&	the data is a list of octet strings.
#define ADSTYPE_PATH			15	&&	the string is a directory path.
#define ADSTYPE_POSTALADDRESS		16	&& 	the string is the postal address type.
#define ADSTYPE_TIMESTAMP		17	&&	the data is a time stamp in seconds.
#define ADSTYPE_BACKLINK		18	&&	the string is a back link.
#define ADSTYPE_TYPEDNAME		19	&&	the string is a typed name.
#define ADSTYPE_HOLD			20	&&	the data is the Hold data structure.
#define ADSTYPE_NETADDRESS		21	&&	the string is a net address.
#define ADSTYPE_REPLICAPOINTER		22	&& 	the data is a replica pointer.
#define ADSTYPE_FAXNUMBER		23	&&	the string is a fax number.
#define ADSTYPE_EMAIL			24	&&	the data is an e-mail message.
#define ADSTYPE_NT_SECURITY_DESCRIPTOR	25	&&	the data is Windows NT/Windows 2000 security descriptor as represented by a byte array.
#define ADSTYPE_UNKNOWN			26	&&	the data is an undefined type.
#define ADSTYPE_DN_WITH_BINARY		27	&&	The data is used for mapping a distinguished name to a non varying GUID.
#define ADSTYPE_DN_WITH_STRING		28	&&	The data is used for mapping a distinguished name to a non-varying string value.

* ADS Name types
#define ADS_NAME_TYPE_1779	    		1
#define ADS_NAME_TYPE_CANONICAL			2
#define ADS_NAME_TYPE_NT4	     		3
#define ADS_NAME_TYPE_DISPLAY	     		4
#define ADS_NAME_TYPE_DOMAIN_SIMPLE		5
#define ADS_NAME_TYPE_ENTERPRISE_SIMPLE		6
#define ADS_NAME_TYPE_GUID	     		7
#define ADS_NAME_TYPE_UNKNOWN	     		8
#define ADS_NAME_TYPE_USER_PRINCIPAL_NAME	9
#define ADS_NAME_TYPE_CANONICAL_EX	     	10
#define ADS_NAME_TYPE_SERVICE_PRINCIPAL_NAME	11
#define ADS_NAME_TYPE_SID_OR_SID_HISTORY_NAME	12

A WMI wrapper class

stuartd — Fri, 15 Jul 2005 21:00:00 GMT

This VFP class will return a populated VFP object reflecting an instance of the specified WMI class: if you're using VFP9 you benefit from the correct capitalisation when using intellisense, as it creates _memberdata for all the class properties. The code could easily return a specific - i.e. keyed - instance. Usage:

define class WMIWrapper as relation

	cClass = "WIN32_OperatingSystem"
	oClass = .null.
	cMemberData = ""

	procedure generate (cClass as string) as object

		local cName as string, oProperty as object, oItem as object, vValue

		if not empty(cClass)
			this.cClass = cClass
		endif

		this.GetClass()
		

		this.cMemberData = "<VFPData>"

		oItem = createobject("empty")

		for each oProperty in this.oClass.Properties_

			cName = oProperty.name

			if oProperty.IsArray
				vValue = "[Array]"
			else
				vValue = oProperty.value
			endif

			addproperty(oItem, cName, vValue)

			this.cMemberData = this.cMemberData + ;
				[<] + [memberdata ] +  ;
				[name="] + lower(cName) + ["] + ;
				[ type="property" display="] + cName + ["/] + [>]
				
		next

		this.cMemberData = this.cMemberData + "</VFPData>"

		if version(5) => 900
			addproperty(oItem, "_memberdata", this.cMemberData)
		endif

		return oItem

	endproc

	procedure GetClass

		local oWMI, oItems, oItem

		oWMI = getobject("winmgmts:")
		oItems = oWMI.ExecQuery("select * from " + this.cClass)

		for each oItem in oItems
			this.oClass = oItem
			exit
		next

	endproc

enddefine

fox weblog

Automating Visual Studio from VFP

Slipstreaming VFP

Tone

foxkb - foxpro kb article archive

Determining Active Directory group membership

Calling Vista's TaskDialog API

Connecting to WinRM with Windows Vista

Command-line VFP

Remote connections to Windows Server 2003 using WinRM

Configuring client and server (Windows Server 2003)

Server configuration

Client configuration

Creating a Listener

Establishing the remote connection to WMI

Windows Remote Management (WinRM) part 1

Accessing resources

Configuration GETs

Simple enumerations

WQL queries in WinRM

Calling methods

WMI part 4 - Implementing a temporary WMI Event consumer in VFP

Extrinsic Events and Semi-Synchronous Queries

Asynchronous Queries and Sink Objects

Intrinsic Events

Event catching class

Extending the event catcher

Using the event catcher to catch Event Log events

Querying Association Class Events

A solution for remote semi-synchronous queries

Temporary and Permanent event consumers

WMI part 3 - Remote Queries

WMI connection class

Impersonation and Authentication

Optimising the performance of remote queries

Setting WMI security with the Windows WMI Control

Troubleshooting

Links

Notes / command snippets

COM+ scripting

Accessing user information from Foxpro with ADSI

A WMI wrapper class