Virus-scanning software. Virus-scanning and -detection software is a crucial application on today's computers, but depending on the way you deploy it, virus software can affect SMS-client installation. When SMS inventories the software on the computer, it thoroughly reads the binary header information of specified files to obtain the product name, product version, and manufacturer name. This comprehensive scanning process can cause computer slowdowns if you've installed and configured virus software to provide deep and aggressive protection. You can modify both SMS and virus applications to alleviate the problem, but you must include this step in your overall deployment plan.
Component Considerations
Determining which SMS components are most crucial to your company will affect how you deploy SMS. During the planning stage, you should sit down with everyone involved and verify the objectives for implementing a systems-management product. SMS provides every aspect of systems management, and some aspects will be more important to your company than others. Pinpoint the most crucial systems-management need, then list the other components in order of importance. Obviously, you should be most concerned about successfully implementing the components your company thinks are most important.
For example, if your company is implementing SMS primarily because of its hardware and software inventory component, then much of your testing in the pilot phase should be to identify any problems with the SMS inventory services. As I mentioned earlier, the SMS software inventory process is intensive and can cause aggressive virus-scanning software to severely degrade the client computer's processing speed. A few changes to the virus scanner can alleviate the problem, but realizing up front that the inventory component must withstand rigorous testing could change how you roll out SMS.
When remote control is the key SMS component, you must address certain LAN and WAN considerations (such as slow links) and employee privacy and security concerns. If creating detailed reports about software usage and valid application licenses is the most crucial aspect, then you need to restructure the site by adding a top-level SMS reporting server. You might need to change the location of distribution points, client access points, and logon points and change the types of servers that you deploy at the other ends of WAN links to make SMS more reliable, easier to manage, and easier on network bandwidth.
Site and Network Considerations
When you begin working with SMS, you realize that it's dependent on a hierarchical structure that differs greatly from one company to another depending on the company's size, number of locations, network link speeds, and number of employees in each location. You must carefully consider how to organize your SMS structure.
SMS and SQL Server must reside on a Win2K or Windows NT server. SMS 2.0 works with Novell NetWare servers, but key components such as client logon and server inventory can have problems if NetWare servers are present. The next version of SMS, which is code-named Topaz and due in second quarter 2002, won't support NetWare at all. If you have NetWare servers in your network, identify the potential problems and plan for them. You might want to migrate from NetWare to Windows before deploying SMS.
You should also factor into your SMS deployment plans any planned Windows server OS upgrades. For example, many companies are opting to install a Win2K Active Directory (AD) forest parallel to an existing NT 4.0 domain structure so that they can slowly migrate resources to Win2K. In such a scenario, implementing SMS only in the Win2K forest and installing the SMS client software on computers as you migrate users to the new forest might make sense. This method would help provide for a controlled SMS deployment and, if planned properly, could help track users as you migrate them to AD.
Company Politics
Believe it or not, company politics can seriously affect the overall design and deployment of SMS. A design based on politics might not be the most efficient, but it can lead to greater acceptance of SMS.
For example, if your company has several sites, one site might require that it handle all software distributions locally instead of a central location distributing software. To meet this requirement, you'd need SMS expertise and a larger server in that location. Or one location might require that before your Help desk uses remote control to manage a remote computer, SMS requests the user's permission, whereas other sites don't require this additional security measure. To provide this feature, you need a separate component server at the location that wants the feature. (You can assign an existing server the responsibility for providing SMS component services—you don't necessarily need a separate server.)
Company politics can lead you to consider a unique SMS design. Consultants don't know your company's internal workings and might neglect to ask you about them, so you need to think about them on your own.
Ongoing Support
If many of your staff are unfamiliar with SMS, you must plan to find the best training possible. Deployment and post-deployment support services are a staple of any consulting contract, but training is harder to come by. If you locate a consulting company that offers this added benefit, latch on to it and add it to the front of your Rolodex. If not, look for a training course that offers hands-on classes by trainers who have actually worked with SMS in some type of company setting. The majority of training courses follow the approved Microsoft course material to the letter but offer no real-world experience.
You can't train everyone. Some selected IT employees will receive SMS training; others will learn SMS through experience over time. But administrators do require expertise to run SMS. When a site in the SMS hierarchy loses an employee who's trained or experienced with the product, the site and the whole SMS structure are affected.
thanks
Dave November 20, 2001