Have you tried Googling for some of this info? Or do you want someone here
to do it for you?
"Bee" <B...@discussions.microsoft.com> wrote in message
news:37F39B6C-F47C-42B5...@microsoft.com...
I'm sure others will come along with better and/or more complete answers,
but I'll provide what I know.
1. As best as I know, the major downside to using WMI is that it might not
exist or be enabled, which means you can't use it. WMI is a Windows
service, and that service can be stopped or disabled. SysAdmins might do
this to lock down workstations.
2. I'm not sure about this, but I don't think it's available in any
redistributable form. It's a part of the Windows OS.
3. I believe you already got an answer to this in another thread. Or at
least a pointer in the right direction.
4. What's wrong with error trapping? Runtime errors are nothing more than
information for your app to use. You don't need to user a wrapper. Just
*temporarily* change your normal error handling to On Error Resume Next, try
to create the object, and then check if your object variable is Nothing.
That's by far the easiest way (and this goes for *any* object for which
there's a chance you might not be able to create that object).
--
Mike
Slow. Clunky. Poorly designed with tedious,
non-intuitive SQL syntax required. May not
be running/installed.
The SQL-like design provides ways to build
all sorts of different query variations, which is
interesting. But that same flexibility make WMI
very difficult to learn.
> (2)Can I distribute the MS WMICORE or just suggest a user download WMI for
> Win not having WMI like Win98 etc?
Yes. It's pre-installed starting with either 2000
or ME. I'm not certain 200 has it, but I know ME
does. On NT it runs as a service. On 9x it's set
to run at startup. On NT I've also found that it
requires DCOM Process Launcher service. So it's
the sort of thing that's likely to be up and running on
a corporate intranet but really *should* be disabled
on a stand-alone system where it's unlikely to be
used. Nevertheless, both services run by default,
so it should be commonly available.
I've used it a fair amount with scripting. It's mainly
useful as a scripting tool to supplement the WSH.
But I don't find it to be very useful except for getting
system info. (I actually disable it when I'm not using
it. I figure there's no sense leaving it running when there
could be a slight chance of security risk.)
The WMI Registry functions are a joke. The WMI software
product functions are just a partial, superfluous wrapper
around WindowsInstaller, which has a better COM interface
available directly.
It's mostly used by network admins who want to
manage a lot of machines with script.
> I would like to use some WMI calls in my VB6 App. Specifically to get
> Serial Port information.
> (3) If not WMI, then what APIs will give me Serial Port info?
I don't know about that, but it must be available. If it were
me I'd avoid WMI if at all possible.
> (4)How do I check for WMI other that error trapping in a wrapper?
>
Usually one uses GetObject. Something like:
Set WMI = GetObject("WinMgmts:")
It's easy enough to test whether that failed. (I think there's
also an early-bound interface and some sort of API version
of the functions, but I've never used those. As noted above,
WMI is mainly something handy to scripters who have a paucity
of other tools at their disposal.)
I't works well for automating IIS. Creation of websites, etc.
--
Tom Shelton
How 'bout automating the creation of multiple websites on multiple machines?
I don't know of an api other then the IIS wmi interfaces for that.
--
Tom Shelton
Creation of websites? I don't pay much attention
to the in and outs of Windows as a server, so I guess
I wouldn't have come across that. But I still don't
find anything in the CHM file, other than a brief mention
that WMI can be used from as ASP page. I also don't
find IIS in the index of my only WMI book. (Though that
book is not much good, anyway. It's mostly a recipe
book of pre-written scripts specifically for admins.)
I don't understand where WMI comes into "creation
of websites" on a Windows server. The functionality I've
seen is aimed at administration of PCs/workstations.
Do you mean like database access or server-side includes?
Isn't that all in ASP?
WMI is not a single technology in the sense of being an independent
free-standing tool, but facilitates working with a variety of management
tools. ie, from a 40k foot view - it is a "front-end" for whatever supplies
a provider. <g>
Take a look at this:
http://en.wikipedia.org/wiki/Windows_Management_Instrumentation
While incomplete it gives a good overview of the possible.
-ralph
http://msdn.microsoft.com/en-us/library/ms525309.aspx
Starting with IIS6 MS introduced WMI interfaces to configuring IIS. So, for
instance, I have an automated deployment tool that pushes a code package to a
server, then reads an xml configuration file and configures the IIS6 Metabase
accordingly. This way the site can be pushed to mutliple servers and setup
without having to log on to each one and configure IIS manually.
--
Tom Shelton
By the way - yes, I wrote the tool.
--
Tom Shelton
That sounds like it comes under network admin.
to me, but I actually don't know enough about
running servers to understand exactly what you're
talking about or how useful it is. (Or why you'd
need to copy the same site/configuration to multiple
servers, for that matter. You lost me on that one.)
I work in an enterprise environment... Along with my coding duties, I also am
in charge of source control mangment and deployment.
We have several servers that represent different stages of the deployment process.
We have a dev server, a qc server, a stage server, and a production server. We need
to push the same code package through each of these environments until
production (I should also each of these environments can and do have more then one
server). So, we work in dev. When were ready for qc, qc signs off and we push the
current code package to the qc server(s). Once the qc has signed off, we push the
package to stage where it undergoes user acceptance testing. This environment
is an exact mirror of production. When, it is signed off by UAT it gets
pushed to production. Each of these pushes is an almost completely automated
process. The only human intervention is select environment, push button. For
production, there is an additional step - an approver must also push a button,
but once done the code is pushed, unpacked, and the IIS website is created if
necessary and all settings updated to mirror what was done in stageing.
The fact is besides being an awful pain in the butt to have to do this on each
and every server manually - it is not allowed by law. I work for a publicly
traded company and to be sox compliant our production pushes have to be
automated and repeatable. And we have to deploy to stage before prod and we
have to deploy to stage in the same manner as prod.
The other envrionements don't have the same strict requirments as stage and
prod - but, it's dang convinent to just push a couple of buttons and have the
code build, packaged, and pushed without doing a bunch of manual work :)
I guess you can put this under network admin, but it's really a code
deployment tool. It's really the same process that current VS will use to
setup and configure a new website when you publish code.
--
Tom Shelton
Yes, but in general it's aimed at providing a
consistent style/wrapper for tools used with
network admin. In my experience that seems to
be mostly how it's used - by network admins
managing machines. The term is "Windows
Management", after all. And it's Microsoft's
version of "Web-Based Enterprise Management".
That's all I was getting at -- that it's for
network admin and not very useful in most cases
for software. I don't even find it very useful in
scripting.
When Tom referred to "creating websites" it
sounded like he was talking about something
on the level of web design. But from the sound
of his explanation he doesn't seem to be contradicting
my description; just adding a footnote.
That's an interesting explanation. Thanks. I have
no experience with enterprise (or even people
who use words like "enterprise") so your description
is a peek into a new environment.
The stages of QC and UAT -- the complexity of the
whole operation -- seems obvious when you
explain it, but I wasn't aware those steps went
into corporate websites. (For me QC and UAT are both
subsumed under the act of one last quick read to
check for typos before I fire up my FTP program and
upload the latest edit. :)
Well, I know I've used it for retrieving the CPU-ID in two different
projects (the first of which was VB6 based) and also needed it for some
distributed processing work (it was useful to query machines in a network,
their hardware capabilities, and their current workload). I'm not sure of
any existing API's that could've acheived the same result. I do agree
however that it's most often used for administration in a scripting
capacity, I'm just pointing out that it has other uses :-)
This C++ code purports to get the CPU_ID:
UINT64 get_cpuid(void)
{
DWORD dwStandard = 0;
DWORD dwFeature = 0;
_asm {
mov eax, 1
cpuid
mov dwStandard, eax
mov dwFeature, edx
}
return( ((UINT64)(dwFeature) << 32) | ((UINT64)(dwStandard)));
}
Delphi Pascal (I don't have C++ compiler to check if the results of Delphi
is the same as C++):
function GetCPU_ID() : UINT64; StdCall;
var
dwStandard : DWORD;
dwFeature : DWORD;
begin
asm
mov eax, 1
cpuid
mov dwStandard, eax
mov dwFeature, edx
end;
Result := ( (UINT64(dwFeature) SHL 32) OR ( UINT64(dwStandard)) );
end;
"Alex Clark" <qua...@noemail.noemail> wrote in message
news:uxhdK2Ej...@TK2MSFTNGP06.phx.gbl...
"Alex Clark" <qua...@noemail.noemail> wrote in message
news:uxhdK2Ej...@TK2MSFTNGP06.phx.gbl...
But AFAIK there is no API in Windows that will return that value - your
example is a pinch of inline ASM in C++. Also, for the distrib-proc app I
was working on, I had to query machines' hardware capabilities from across
the network, and having a single unified API (WMI) on hand to do all of that
was extremely useful. For querying obscure hardware properties, there are
some things the Windows API can do - for everything else, there's WMI ;-)
Thing is, unless MS specifically added some functions in the core of WMI to
produce things like CPUID, it is likely there exists undocumented stubs in
the OS for these features.
>
>
I suspect they did just that. WMI has a lot of
hardware info. functions, many of which are new.
(In fact many are generally useless because they're
not even implemented with most hardware.) Since
those methods (like motherboard ID, for instance,
or "system enclosure part number") exist even in the
first versions of WMI I suspect that MS probably
wrote drivers specifically for WMI.
I think he's talking about actually *creating* websites. <G> That is,
defining where on the hard disk it will live, what host headers it will
respond to, what users have what rights to it, how it will be indexed
and logged, and so on and so on. It's actually a very intriguing
suggestion, as I've always done this manually and it can get rather
tedious.
--
.NET: It's About Trust!
http://vfred.mvps.org
You got it. That's exactly what I was refering to.
I define all of this in an xml file once and then my deployment tool goes out
to each server and makes it so.
--
Tom Shelton
Just a thought, Karl - I had to do my stuff in C# do to insfrastructure
requirements, so, I know it's of know interest to you. But, when I first
started toying with the idea, I was goign to do it with PowerShell - accessing
wmi stuff is pretty easy in ps. But, I couldn't go installing PS on all of
the servers - which because of the way the internal standardized deployment
system works, I would have had to.
Anyway, there is a good PS project for you :)
--
Tom Shelton
no - not know... lame.
--
Tom Shelton
<chuckle>
> But, when I first
> started toying with the idea, I was goign to do it with PowerShell -
> accessing wmi stuff is pretty easy in ps. But, I couldn't go installing PS
> on all of the servers - which because of the way the internal standardized
> deployment system works, I would have had to.
>
> Anyway, there is a good PS project for you :)
Always the evangelist, eh? <bg> It's a thought!
No, I thought you had an interest in PS. It was just a thought of a good way
to get your feet wet :)
--
Tom Shelton
I do actually, which is why I only kidded you about evangelizing,
rather than flaming you for it. ;-)
It's just another thing on my long list of TODO tasks. Onnathesedays!