Now that we’ve created the “better connection” script for connecting to
SMS from VBScript, the next step is to convert this function to be used with
other tools. In this article, we’ll cover three examples:
- Active Server Pages.
This one will be very similar to the VBScript version, which makes
sense since Active Server Pages use VBScript. But there are some
“opportunities” that will be discussed.
- Visual Basic for Applications.
In this example, which will use Microsoft Excel, we’ll see that VBA offers
features that VBScript does not.
- Visual Basic.
First, we’ll take the modified function from the VBA
example above to show that it will work unchanged. But then, we’ll use
some of the object-oriented features of Visual Basic to create something
that we can build on.
Now that we’ve created the ‘better connection’ script for connecting to SMS from VBScript, the next step is to convert this function to be used with other tools. In this article, we’ll cover three examples.
Next up: some simple but useful queries, looking at systems (PCs), packages,
collections, advertisements, and more. But first…
So what does it take to modify the VBScript function presented in the previous
article to be used in an Active Server Page? Simple: absolutely nothing – it can
be used as-is. Take the source from the last time,
strip out everything except the function itself. Surround the code with “” to indicate that this is VBScript, then save it into a file
(e.g. “SMS_Connect.inc”) that can be included into each Active Server Page
that needs to talk to SMS. The result should look like:
So let’s create a web page that uses the file. Here’s the basic web page:
Connect to SMSSuccessfully connected to SMS.
Save this as a file (e.g. “SMS_Connect.asp”) and execute it from a web browser.
The page doesn’t do much, but if it can be loaded, everything is working. (If any
errors are encountered, the page will stop loading before the “Successfully connected”
message is sent, so all you’ll see is the error information.)
So what if it doesn’t work? There are three possible problems:
- Typos. You’ve checked those already, right?
- Parameters. Unless you are running IIS and this Active Server Page on
an SMS site server, you’ll need to update the parameters passed to the
“Connect” function to include at minimum a server name.
- Security. The account used to run the Active Server Page needs to
be able to connect successfully to SMS via the WMI Scripting API.
The first two items should be fairly obvious, but the third requires further
explanation. First, if you are running this script on a Windows NT 4.0 server,
you need to make a registry change in order to access WMI via an Active Server
Page. This is documented in the
Platform SDK. For some reason, this is not an issue with Windows 2000. Go
Second, Active Server Pages normally run under the context of a local machine
account named something like “IUSR_” which is only a member of the
machine’s (or domain’s, if this is a domain controller) “Guests” group, giving
it little security. This security normally does not include the ability to
connect to SMS. Some ways to fix this:
- Give the “IUSR_” security. The only way this is possible
is for the SMS server and IIS to be on the same machine, or alternatively for
both machines to be domain controllers in the same domain. In either of these
cases, you can add the account into the SMS Server’s “SMS Admins” group, then
give the account the appropriate access within SMS via the SMS Administrator.
While this could work, I would not recommend it.
- Run the web page using a different account. The easiest way to do this:
save the web pages into their own directory, then disable anonymous access to
this directory via the Internet Service Manager. Then each client accessing
the page needs to have the appropriate SMS security.
- Hard-code a user ID and password in the “Connect” function call. Not the
most secure, but it would work.
IIS security is an art form. There are usually several ways to do it, but the
way you choose to implement is a matter of personal preference. I’m sure there
are other ways to achieve the same result – use whatever works for you.
Next time when working with queries we’ll create a web page that does something
a little more useful.