Scripting SMS: Connections Extra Credit
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.
Next up: some simple but useful queries, looking at systems (PCs), packages, collections, advertisements, and more. But first...First Up: Active Server Pages
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 "<%" and "%>" 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:
<% Function Connect(server, site, user, password) ' Create the object to make the WMI connection Set locator = CreateObject("WbemScripting.SWbemLocator") ' Is a site code specified? If not, find one If site = "" then ' Connect to the specified (or default) server Set sms = locator.ConnectServer(server, "root\sms") ' Select the primary site Set results = sms.ExecQuery("SELECT * From SMS_ProviderLocation WHERE ProviderForLocalSite = true") ' Process the results For each r in results site = r.SiteCode ' Get the 3-character site code Next ' Disconnect Set sms = Nothing End if ' Now, connect to the specified site, returning the SWbemServices object to the caller Set Connect = locator.ConnectServer(server, "root\sms\site_" & site, user, password) End Function %>
So let's create a web page that uses the file. Here's the basic web page:
<!--#include virtual="SMS_Connect.inc"--> <html> <head><title>Connect to SMS</title></head> <body> <% Set sms = Connect("","","","") %> Successfully connected to SMS. </body> </html>
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 figure.
Second, Active Server Pages normally run under the context of a local machine account named something like "IUSR_<machine>" 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_<machine>" 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.
IT Solutions Builder TOP IT RESOURCES TO MOVE YOUR BUSINESS FORWARD
Which topic are you interested in?
What is your company size?
What is your job title?
What is your job function?
Searching our resource database to find your matches...