HomeBrainDump Microsoft`s Strategy to Centralize and Man...
Microsoft's Strategy to Centralize and Manage Automated Installations: SMS 2003
This article mainly focuses on introducing the concept of System Management Server 2003 (SMS) and how it helps organizations to automate installations (including of operating systems) throughout their networks, regardless of geographical locations. We will also see how this helps companies achieve a good ROI.
As you know, every wing of information technology is changing day by day and integrating with each other very tightly. Drastic changes are occurring in such a way as to fulfill most (or even all) of a customer's demands. One of these (sometimes desperate) demands would be managing and installing an operating system, applications, Service Packs, Patches, software, upgrades etc. for all (or at least some) of the clients within a network (either locally or even remotely). Actually this demand most often comes from administrators or system administrators, but not from programmers in general.
Microsoft started to implement a strategy to meet the above requirements a long ago. The company started with a simple strategy called Microsoft's desktop deployment strategy. This has been implemented using Microsoft Remote Installation Services (RIS). RIS basically helped in full installations of an OS just by using the network. No technician actually needed to sit at every computer (or client in this scenario) with a CD-ROM in his hands and install software everywhere. But the process needs a special network adapter (NIC) which can boot remotely. Even though the process could solve many requirements, it lacks the concept of "disk imaging" or installation based on images.
Microsoft then came up with another solution, along with support for imaging technology called Automated Deployment Services (ADS). However, you can use the ADS technology only with server builds, and it requires that you run Windows Server 2000/2003 Server Editions. To be frank, it could not meet all the scenarios for low level legacy machines.
Finally, Microsoft thought of designing and implementing a new and complete infrastructure, just for deploying, integrating, centralizing, diagnosing, and managing installations (and doing a lot more besides!) in a scalable, efficient and secure manner, either locally or remotely. The product which Microsoft finally created is System Management Server (SMS). SMS 2.0 was a tremendous success. Within the same line, the latest is version SMS 2003.
Systems Management Server (SMS) delivers cost-effective, scalable change and configuration management for Microsoft Windows-based desktop and server systems.
With SMS, system administrators can feel comfortable with certain other features like user maintenance (for tightening security), monitoring server performance, Query based reports, and so on. System administrators will also be able to gather information about hardware and software configurations of every workstation within the network (including remote workstations). System administrators can even track and restrict the software usage of different users working at different workstations.
Where does such a huge amount of information about configurations get stored at SMS? SMS is primarily for management and not for storage. As everybody knows, Microsoft wants all of its software components to be able to integrate with each other. It finally accomplished this with SQL Server database. SMS needs to maintain (of course it automatically manages by itself) at least one SQL Server database to store all if its own configuration information, along with all clients (or workstations) as well. This in turn helps the programmer to query that information and provide it to the web!
The next question in general would be, is it necessary to have Active Directory Services deployed on the network? To which the answer is "No," but there are advantages to using Active Directory with Microsoft Systems Management Server (SMS) 2003. The advanced security mode of SMS 2003 requires Active Directory and provides easier account management. If you have Active Directory, you can use the Active Directory site boundaries as the SMS site boundaries. And of course, it is quite secure for remote activities, once SMS gets installed over Active Directory Services.
There exists a small drawback to using SMS, which may be big from a system administrator's point of view. It cannot yet support "clustering" natively. Windows Cluster service is not supported for any SMS site systems, including the SMS site database server. But this can still be achieved in some alternate (in-direct) ways, which I will not be able to discuss as they are out of the scope of this article.
There are several buzz words, such as SMS Site System, SMS Site Server, SMS Site, SMS Client, and so on. Now let us focus on each of them one by one.
Any computer which is being managed by SMS 2003 could be called an SMS Client. In general, it would be client to a domain (or even a workstation as well). If we maintain secondary servers within the site, even a server becomes an SMS Client. But this is a bit of an advanced level of configuration. Some of the clients (or workstations) with old Microsoft OSes like Windows 95, Windows 98, Windows NT 4.0 Workstation, Windows NT Terminal Server, and so on are considered legacy clients.
All the rest of the clients, which boast the latest Microsoft OS such as Windows 2000 Professional, Windows 2000 Server Editions, Windows XP Professional, Windows Server 2003 editions all come under the heading of advanced clients. Note that some Microsoft OSes like Windows ME, Windows XP Home edition, Windows Small Business Server and so on are not supported by SMS. For complete information on the products supported, I suggest you consult Microsoft's website at www.microsoft.com.
A set of computers, users, groups and several other resources, together within a boundary, being managed by SMS can be called as SMS Site. We can define an SMS site with an Active Directory site boundary or with our own IP subnet boundary. It would automatically discover all types of resources like computers, printers, users (or accounts), groups, roles, and so on once we set up an SMS Site. Later all these resources could be categorized into several collections (with our own specific queries) and we would be able to apply bulk operations (or installations) on each collection individually (or even all at once) in a flexible manner. The operation or process which is meant for installation at a client is generally termed an SMS package. To be more general, an SMS site consists of an SMS site server, SMS site systems, and SMS clients and resources.
The Windows server on which SMS 2003 has been installed and that manages the SMS site with all its component attributes and services can be called the SMS Site Server. An SMS site system is a Windows Server (either 2000 or 2003) which can perform several SMS roles for an SMS site.
The answer is "YES." We can develop any desktop based (or even web based) solution which can directly interact with SMS server using SMS SDK (freely downloadable from Microsoft's website). If you could implement a web solution (together with both SMS SDK and SMS Data Store), then the total enterprise could be managed from any client throughout the world very easily with a few clicks.
The core part of SMS has been completely implemented using WMI (Windows Management Instrumentation). I don't think WMI is a new technology for any administrator. It has already been in existence for years. Eighty percent of SMS development is based on WMI. With the help of WMI, we will able to connect to any client (or workstation), find information, transfer information, exchange information, send information, receive information and do several other network tasks.
Another wonder is that SMS itself can be managed with our own customizable WMI scripts. We can even develop applications in other technologies like .NET using WMI as a core interface to SMS activities (apart from direct SMS SDK and SMS data store).
Let us see how we can connect SMS server. Consider the following statement:
Set locator = CreateObject("WbemScripting.SWbemLocator")
The above statement tries to create one object to work with WMI using VBScript. The WBEM stands for Web Based Enterprise Management. You can rewrite the same in JavaScript using the following statement, which may be useful when you want to connect from client-side JavaScript:
var locator = new ActiveXObject ("WbemScripting.SWbemLocator");
Once we create the above object, we need to connect to an existing SMS server. Let us go through the following statement:
Set smsserver = locator.ConnectServer("SERVERNAME", "rootsms")
The above statement tries to connect an existing SMS Server based on the namespace "rootsms." This namespace gets automatically installed once you install SMS Server. If you try to log onto the primary SMS server site (with administrative privileges), the script for connecting that could be as simple as the following:
Set smsserver = locator.ConnectServer("", "rootsmssitename", "", "")
The above statement simply connects to the current server with the current user's (who logged on) credentials. To work with a sample script, proceed to the next section.
As this is an introductory article, I simply wanted to demonstrate how you connect and retrieve SMS information using VBScript together with WMI.
Set locator = CreateObject("WbemScripting.SWbemLocator")
Set smsserver = locator.ConnectServer("servername", "rootsms")
Set info = smsserver.ExecQuery("SELECT * From SMS_ProviderLocation")
For each i in info
sitecode = i.SiteCode
Wscript.Echo sitecode
Next
Set smsserver = Nothing
The above would simply list all the sms site codes. Let me explain the code part by part. I hope by now you can already understand the first two statements. The third statement is as follows:
Set info = smsserver.ExecQuery("SELECT * From SMS_ProviderLocation")
The above code uses WQL (WMI Query Language). The serverobject (smsserver) supports a method "ExecQuery" to execute any SELECT statement (conforming to the semantics of WMI Query Language) which can return a handful of information (either in the form of a table or objects or properties). Once we receive information, we need to go through all those objects and display them on the screen. The following code fragment does the same.
For each i in info
sitecode = i.SiteCode
Wscript.Echo sitecode
Next
It is always a good practice to release memory resources, once we complete our work. That means the connection to the SMS server that we established in the beginning is no longer necessary. The following statement would release all such memory resources:
Set smsserver = Nothing
Let us extend the above a bit. The beauty of the above code is that we can directly use it in ASP for web development as follows:
<html>
<body>
<%
Set locator = CreateObject("WbemScripting.SWbemLocator")
Set smsserver = locator.ConnectServer("servername", "rootsms")
Set info = smsserver.ExecQuery("SELECT * From SMS_ProviderLocation")
For each i in info
sitecode = i.SiteCode
<%= sitecode %>
Next
Set smsserver = Nothing
%>
</body>
</html>
It is that easy. You can simply imagine that any VBScript script can be converted to ASP with a very few basics.
Microsoft has recently released a special pack to ease the OS installations called SMS OS Deployment Feature Pack. The SMS OS Deployment Feature Pack is an image-based solution that lets you deploy Windows Server 2003, Windows XP, and Windows 2000 Server from your SMS infrastructure.
The most important issue to consider before working with this special pack is that we need to apply SMS 2003 service pack 1 to the site server and also to the entire site (all workstations, clients, secondary sites, and so on). The OS Deployment Feature Pack uses Windows Imaging Format, which is going to be a standard Microsoft imaging technology from now on. You can download the OS Deployment Feature Pack at http://www.microsoft.com/smserver/downloads/2003/osdfp.asp.
The following links will be helpful to you in learning more about installing and configuring SMS site server.
BrainDump 
Implement Gzip and Deflate Compression in ASP.Net
