SMS & Windows 2000
(How they work together and how they don't)

By ServerWatch Staff (Send Email)
Posted Sep 13, 1999

by Mike Lubanski

Author's Note:  Due to the changing nature of both Windows 2000 and SMS 2.0, Microsoft refused to comment on the validity of this document.  However, since Windows 2000 is in a "release candidate" stage, no new functionality will be added to the product until its release later this year.  Microsoft has also publicly stated that SMS 2.0 will be patched or upgraded to be Win2K-aware approximately 90 days after the release of Windows 2000.  Therefore, it is safe to assume that this document is accurate for at least the remainder of 1999.

Due to the changing nature of both Windows 2000 and SMS 2.0, Microsoft refused to comment on the validity of this document.  However, since Windows 2000 is in a 'release candidate' stage, no new functionality will be added to the product until its release later this year.  Microsoft has also publicly stated that SMS 2.0 will be patched or upgraded to be Win2K-aware approximately 90 days after the release of Windows 2000.  Therefore, it is safe to assume that this document is accurate for at least the remainder of 1999.


The purpose of this document is to give an overview of how SMS 2.0 will work as a part of the Windows 2000 platform.  This includes: 

  • Evaluate and document the proposed use of SMS 2.0 within the Intellimirror concept.  (Note: Intellimirror is not a product, but rather a concept that contains multiple products to form a solution for software management).  Evaluate and document the proposed interaction between SMS 2.0 and the group policy of Windows 2000 and closely examine the overlap and complements of each.
  • Evaluate and document the proposed role of the SMS Installer in the preparation of MSI (Windows Installer) packages.
  • Evaluate and document the proposed role of SMS 2.0 and the Microsoft Implementation of Active Directory.
  • Evaluate the proposed use of SMS 2.0 to upgrade existing Windows NT 4.0 Servers and Workstations as part of the Windows 2000 migration process.  This includes the proposed interaction and overlap with the Remote Install Service built into Windows 2000.


The following section gives an overview of the integration testing among SMS and other Microsoft technologies that will accompany Windows 2000 development.  As per the introduction section, these tests were performed to determine exactly how SMS integrated with these new technologies to aid in the decision of its use in the enterprise as well as where a relationship was lacking to determine what needs to be built or improved.

The following picture will give an overview of how SMS and Windows 2000 technologies overlap:

Sites, Domains and Organization Units

The concept of the "site boundary" is consistent throughout Windows 2000, SMS 2.0 and Exchange 6.0.  Within Windows 2000, a "site" is defined as a set or a range of TCP/IP addresses (or subnets).  SMS site boundaries are defined in the same manner.  Therefore, when designing an SMS 2.0 site, it will most likely contain the same boundaries as the Windows 2000 site.

An SMS site can be based within a single domain or span multiple domains.  SMS cannot yet recognize Fully Qualified Domain Names and therefore cannot be used with nested domains without the use of the ordinary name.  For example, SMS cannot recognize Win2k.microsoft.com, but can only recognize Win2k.  Therefore, Sales.Win2k.microsoft.com must still be represented as the Sales domain in order for SMS to recognize it.  This also means that SMS cannot be used in a native Windows 2000 domain.

A Windows 2000 Organization Unit is conceptually the same as an SMS collection.  An organizational unit will contain users, groups or objects with a common thread that links them together.  An SMS collection is a dynamic grouping of objects (users, groups or machine) that are linked with a common thread that is based on the inventory that SMS collects.  Currently, there is no interaction between an OU and a collection.  It is desirable for future versions of SMS to be able to create a collection that is based on the contents of an organizational unit and be synchronized when it changes.

Integration with the Intellimirror Concepts and Group Policy Technologies

The Intellimirror concept consists of three major areas:

  • User Data Management
  • User Configuration Management
  • Software Installation and Maintenance


SMS plays no role in the management of user data (such as My Documents) or configuration (such as Internet Explorer favorites).  These are managed solely by the Active Directory.  To use the Software Installation and Maintenance function, applications must be installed and configured on each distribution server.  They cannot be distributed easily for an enterprise without additional enterprise deployment tools, such as SMS. Furthermore, full Software Installation and Maintenance (SIM) functionality will only be available for PCs running Windows 2000 Professional and for applications written to support Windows Installer. Windows Installer (formerly MSI) is intended to help streamline the installation process and manage DLL conflicts by assisting in configuration lock-down and ensuring the consistency of application installation.  Microsoft will probably require applications to use Windows Installer to be compliant with the Win2K Application Specification and thus be awarded a Win2K logo.  Microsoft is working to gain commitment from ISVs to use Windows Installer, but existing applications and home-grown applications will not support Windows Installer unless developers or administrators add that support or use alternative packaging and deployment techniques Microsoft is providing to support legacy applications and desktops.  I.T. organizations may opt to use add-on products that provide consistent deployment mechanisms across heterogeneous applications and desktops instead of SIM. [1]

Therefore, the role of SMS in the Intellimirror solution is limited to the population and maintenance of the distribution points from which Intellimirror will look for the packages.  However, there are several features lacking in Intellimirror that SMS provides that may be valuable.

  • SMS provides the functionality of a scheduled deployment.  Deployment of packages can be scheduled to occur at any time, whether or not a user is logged on and use elevated administrative privileges if needed.  Software packages assigned to machines or users using Intellimirror need a reboot or relogon to be activated.  Intellimirror has no concept of scheduling or forcing software to a machine or user at a specified time or recurring interval.
  • SMS provides detailed status of software package distribution and installation.  This includes success and failure reports of software package creation, delivery to distribution points, distribution to clients and installation.  These status reports can be summarized, reported or queried against.  SMS also provides the functionality of inventory to check whether software has been installed.  Intellimirror has no concept of tracking or status reports to view the distribution or installation status.  Intellimirror will report successes and failures to the Windows NT Event Log.  Microsoft is working with ISVs to develop more sophisticated Intellimirror monitoring tools.
  • SMS is designed to deploy software packages across a WAN using site compression and a sender manager (for bandwidth control).  This enables the administrator to use the most efficient method of transferring software over a WAN link.  Intellimirror has no such capability.  SMS can be used to populate distribution points across the enterprise, and then have local administrators using Intellimirror functionality to advertise and assign the software from that point.  This allows a centralized SMS team to maintain the packages, but still allows local administrators to distribute them.
  • SMS is designed to work with Windows NT 4.0, Windows 95, Windows 98 and Windows 2000.  Intellimirror is a Windows 2000-only solution that requires both Win2K Server and Win2K Professional.
  • SMS distributes software to a collection.  This collection can be built using any information that is collected as part of the hardware or software inventory.  This includes users and user groups.  Intellimirror can distribute software users, user groups or machines as listed in the Active Directory.  These objects are usually grouped in an OU (organizational unit) based on some sort of pre-selected criteria.  These OUs are not dynamic and cannot fluctuate with inventory like the concept of the SMS collection.
  • Both SMS and Intellimirror have equal capabilities as it relates to upgrading or removing software.  However, it is important to note that SMS has the ability to schedule the upgrade or removal, while Intellimirror relies on a user logon or a machine reboot.

Overall, Microsoft is seeking to position SMS and Intellimirror as complementary solutions.  SMS is being positioned as more of an "enterprise-friendly" solution that can work in large enterprise, across WAN links, etc.  Intellimirror is being positioned as more of a "local" solution for local administrators to control the software that is deployed within their departments.  In general, one would want to use SMS to manage distribution points, especially those across a WAN, schedule software deployment for a specific time interval and take software inventory of all software that is installed for reporting and status checks. One would use SMS 2.0 to assign and advertise software to Windows NT 4.0, 95 and 98 machines.  One would use Intellimirror to advertise and assign software to Windows 2000 machines. 

Integration of MSI (Windows Installer Service)

The Microsoft Installer Service is a new installation service that is aimed at replacing the old "setup.exe" programs that have become the norm in software installation.  MSI is a new installation database format.  It contains instructions on how to install and remove app as provided by a software developer or ISV.  MSI also provides the ability to repair an application on the fly as it is executed.  It uses the Local System Account to install software.  This is in comparison to SMS using a pre-specified account to install when the user is not doing the installation.  There is little interaction between SMS and an MSI package.  SMS can deploy an MSI package much like any other software package (setup.exe, install.bat, etc.)  SMS can also retrieve and read the MSI Status MIF and integrate it into the distribution status to give a more complete view of the distribution and installation status.  Once the MIF information is inside the SMS status engine, there are robust reports, alerting, etc. available to query the status of the installation.

SMS Installer

In its current iteration, the SMS Installer can be used to produce software installation packages using the traditional methods.  Traditional methods are defined as the snapshot of a before and after image of an installed software package, then the creation of a setup.exe program which installs the package.  SMS Installer does not yet have the ability to create MSI packages.  There will be a forthcoming utility that will transform traditional SMS Installer packages into MSI-based software packages.  There have been no announcements of a version of SMS Installer that will create MSI packages from scratch.

Integration with Active Directory

At the present time, there is no interaction or integration between an SMS site and the Active Directory of that site.  Microsoft is seeking feedback on what type of integration the customer base seeks.

Role of SMS in the migration process of NT 4.0 to Windows 2000

SMS 2.0 is being position as THE tool to deploy Windows 2000 to upgrade existing NT 4.0 servers and workstations.  There are many roles that SMS can play in the deployment process:

  • SMS plays an important role in the deployment planning.  The hardware inventory can be used to determine how many systems do not meet the Win2K hardware requirements. The software inventory can be used to determine how many systems have applications that are not Win2K compatible.  An SMS package can be used to remotely execute "winnt32 /CheckUpgradeOnly" then collect upgrade.txt for analysis (or for it to report to a share point).  The features of the SMS Network discovery will help to better plan upgrade rollouts.  It will help answer the questions: What is the capacity of my network? and How many machines can I deploy Windows 2000 to at the same time?
  • SMS can be used to deploy pre-upgrade tasks (packages) such as disk cleanups, old application deinstall, changing environment variables, etc.
  • SMS can be used for centralized deployment of Windows 2000.  This will allow for fewer (if any) desktop visits to upgrade the Windows NT 4.0 operating system.  Operating system upgrades can occur whether or not a user is logged on and whether or not he has the necessary local admin privileges to install an operating system.  Deployment of Windows 2000 through SMS can also be targeted at users and user groups.
  • The Software metering tools within SMS can control inappropriate or incompatible application use.  If an application is known to be incompatible for Windows 2000, software metering can be used to prevent the usage of that software until it is fixed.  This also includes preventing the use or installation of software that is known to be non-Y2K-compliant.
  • Post deployment and installation diagnosis can be performed by SMS.  This includes tools such as remote control and remote reboot, a network monitor with real time and post-capture experts to analyze network conditions and performance, and a tool that can track critical performance information on the Windows 2000 Server operating system.  The reporting and status tools of SMS will give an accurate picture of the success rate of the deployment.  Finally, software inventory can be used to report on the number of machines and Win2K applications that have been successfully deployed and any other information you may need on those packages.

Integration of SMS with the Windows 2000 Remote Install Service

Since Remote Install Service (R.I.S.) begins its installation before the target machine has an operating system, there is no comparison or overlap with the SMS client.  Since the SMS client requires an operating system to be present to be installed, it is not possible to use SMS to perform R.I.S. functionality.

A new installation of Windows 2000 Professional using R.I.S. can spawn the installation of an SMS client as its final step.  This will ensure that the new machine contains the SMS client and can immediately participate in collections and begin receiving additional software that has been assigned to it.  This can happen in one of two ways:

  1. If time is of no concern, you can simply wait until the next SMS discovery is scheduled to occur.  If the SMS site in configured for network discovery and remote NT client installation, the SMS site will "discover" the newly installed machine and "push" the SMS client down to it.  Once the SMS client installation is complete, the machine can participate in collections to receive its software.  This step is contingent upon the discovery schedule of SMS.  If, for example, the network discovery is scheduled for every 4 hours, then you may need to wait up to 4 hours for the machine to be discovered and installed with an SMS client.
  2. If time is of concern and you prefer a faster method, you will need to include the SMS client installation commands (such as SMSMAN) at the end of the R.I.S. Image that you are using to deploy to machines.  Using the unattend.sif file that R.I.S. generates, you will need to add the installation command for the SMS client at the end of the file.  This will ensure the SMS client installation begins as soon as the operating system image has been applied to the new machine.

Based on the membership of the machine in the pre-defined collections, it will begin receiving software packages based on its role.  This will occur at the next interval of the collection membership update or can be setup to occur immediately via a custom program.


Through careful study, testing and experience, it has been determined that SMS will continue to be a benefit to systems administrators through the Windows 2000 space.  SMS will prove to be the most valuable tool during the deployment of the Windows 2000 operating systems across your systems.  SMS will play critical roles in the planning, deployment and configuration of Windows 2000 machines.  (SMS will continue to play that role for all NT 4.0, Win95 and 98 machines).  Only after all of the machines have been upgraded to Windows 2000, an Active Directory is setup and Group Policies have been setup and activated, will SMS begin to play a reduced role in software management.  At that point, SMS will continue to play valuable roles in diagnose of system problems, inventory collection and evaluation and the management of software distribution points.  Overall, SMS will continue to play a strong role in the management of software in the Windows 2000 space.


[1] Courtesy, Gartner Group

Page 1 of 1

Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date