Just another Foxite.COM Community Weblog site
Remote connections to Windows Server 2003 using WinRM
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)
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.
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.… Continue reading
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
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… Continue reading
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… Continue reading
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, which is handy. Not so good for previous versions, but I don't know enough about intellisense scripting know whether it can be done via that route. Or about how to use the resulting object in a method window, which would make it much more useful.
define class WMIWrapper as relation cClass = "WIN32_OperatingSystem" oClass = .null. cMemberData = "" procedure generate… Continue reading
If you haven't heard of WMI, you might want to skim my previous article on the subject (it's been updated since it was first posted).
The Registry Provider is WMI's mechanism for accessing the system registry. This is what it can do:
- Create and delete registry keys and values with full support for binary [REG_BINARY], expanded string [REG_EXPAND_SZ] and multiple string [REG_MULTI_SZ] data types as well as the usual string [REG_SZ] and DWORD [REG_DWORD] types
- Enumerate registry keys and values
- Query access permissions on registry keys and values
Typical of WMI, you can do a lot in a couple… Continue reading
Introduction To WMI
WMI - Windows Management Instrumentation - is Microsoft's implementation of the WBEM [Web-Based Enterprise Management] standard, and a very powerful tool for administering computers. It was introduced with Windows 2000, but was partially implemented for Windows 95/98/NT. If you are using one of those operating systems you would need to install the WMI core, if it isn't already installed. There are two versions, one for 95/98 and NT and one specifically for 95/98.
WMI is analagous to a database of objects relating to you computer - programs, for example, or hardware - which Windows maintains internally.… Continue reading
Using BindEvent to tie the DblClick method of a grid's controls to the grid itself is a lot easier than swapping in a replacement textbox. It took me a while to come up with generic code that uses CurrentControl but I figured it out in the end:
local oColumn as Column, oGrid as Grid oGrid = thisform.grdExampleGrid for each oColumn in oGrid.Columns bindevent(evaluate("oColumn." + oColumn.CurrentControl), "DblClick", oGrid, "DblClick") next
I was in another grid today, where the control source for a column is a memo field and there's an editbox bound to the contents of the memo. To force… Continue reading