http://www.microsoft.com/TechNet/boes/bo/sms/technote/sm203.htm (PC Press Internet CD, 03/1996)
| Updated: March 15,1996 |  Go To TechNet Home Page |
Executive Summary
Project Objectives
Network Architectural Review
Techology Architecture
Pilot Plan
Logistics Plan
Conclusion
Many elements must be considered when deploying complex products such as System Management Server. This document will provide a solid framework for Systems Management Server architectural planning and design. Since good designs come from through structured analysis, so this document is a discussion of the appropriate topics in a structured fashion. The technology issues in this document are discussed within the context of a Systems Management Server design and implementation project. When a project follows the flow outlined in this document and addresses the issues at each section the outcome should be a successful production implementation of Systems Management Server that meets the business needs.
The project described is based on an approach defined in the Microsoft® Solutions Framework (MSF). MSF calls for an overall enterprise architecture consisting of four key elements for strategic planning. The Business Architecture identifies business services independent of application-specific invocation of those services. The Application Architecture provides an architectural framework for each application's development project so that solutions are defined and designed using a model with a consistent set of terminology and services. The Technology Architecture defines the base technology for the enterprise applications development. The Data Architecture helps to track access and usage patterns as the basis for making data distribution, replication, and partitioning decisions. This project will utilize two of those elements, the Business Architecture and the Technology Architecture.
MSF also defines a Solutions Development Discipline (SDD) that defines three other key elements to be used on this project. First the SDD defines three models: the Application, Team, and Process to be used in applications development. This project will rely on the Process and Team models. The Team model simply describes a project is best organized as a small team of peers that approach the project as they are to deliver a product. The Process model calls for a cyclical development cycle that utilizes a risk-driven approach.
Utilizing the MSF concepts the overall Systems Management Server project will accomplish the following:
· Organize a small team of participants.
· Define the requirements for an Systems Management Server implementation
via a Business and Technology Architecture.
· Define the risks of the project resulting from the requirements.
· Review the current Technology Architecture.
· Design the new Technology Architecture.
· Redefine the risks based on the initial assessment and changes
resulting from the new Architecture.
· Develop a pilot plan to provide proof of concept.
· Define the risks associated with the pilot.
· Run the pilot.
· Define the logistics plan for a complete rollout.
The benefits of developing in a client-server environment, namely intuitive interfaces and rapid turnaround times, often cause projects to get started without adequate planning. Twenty years ago starting a project without a plan was unheard of. While we don't want to return to the days of planning paralysis, we do need to consider a change. Client-server technology is becoming increasingly complex. Attempts to implement such technology without an understanding of why we are doing it, what we expect to gain, and how it is going to change our operations, is guaranteed to fail. We need to start with a sound vision, a solid documented approach, and a clear path to the future.
The idea of defining the project goals is simple.
· Define the problems.
· Visualize the business goals.
· Document the tools needed to implement a solution.
· Identify the necessary skills and people to carry out the plan.
· Document the risks.
Completing this stage of the project will provide a solid foundation for the technical work to come. Technology often fails because no one understands the problem being solved. Even the best product can't solve a problem if you don't know what the problem is. The requirements of a Systems Management Server project can be grouped into two key areas answered by the following questions. What business needs will systems management provide? What current technologies will Systems Management Server need to integrate with and which will it replace? The former defines the Business Architecture and the latter the Technology Architecture.
Within MSF an Enterprise Business Architecture:
· Drives the strategic decisions in the Technology Architecture.
· Identifies business services independent of application-specific
invocation of those services.
· Understands how and what data are strategic to the enterprise.
· Provides the basis for strategic application of information
technology.
Simply put, the Business Architecture defines all business services necessary to provide systems management and the characteristics of each. System management needs are unique to each corporation, but several common threads seem to exist. Even though a common need seems to exist, the justification behind the need varies greatly. When documenting the Business Architecture, creating a table of the business services and the matching reason for each is a powerful communication technique. The Business Architecture should be defined in measurable terms; this way at the completion of the design it can be determined if the business needs are being meet. If the business needs haven't been met by the design, simply make changes to the design until they are. The design process should be a cyclical process that results in Systems Management Server meeting the necessary Business and Technology Architecture objectives.
Example of a Business Architecture Table
Business Service Business Need
Workstation Ability to proactively plan for hardware
Inventory and software upgrades and replacement of
obsolete equipment.
Maintain knowledge of commercial software
licenses owned. This information is used
to stay legal and provide leverage in
future purchase negotiations.
Software Automated delivery of strategic internally
Distribution developed client-server applications to
the desktop.
Rollout and upgrade of large numbers of
commercial software applications.
Within MSF an Enterprise Technology Architecture:
· Provides open, vendor, and private standards for selecting technologies
and APIs.
· Defines the base technology for enterprise applications development.
· Outlines a technology migration strategy consistent with enterprise
business goals.
· Provides a context for identifying skills acquisition and training
needs.
· Provides a context for establishing strategic vendor relationships.
The goal of setting the objectives for the Technology Architecture is an aggressive concept to many. We have all seen the industry change rapidly in the last ten years. Keeping up with changing technology, let alone projecting our path along that curve, probably seems like an impossible task. The idea of planning for our technology needs is not new, but within the area of systems management it becomes key. Why is systems management any different than planning for a server platform like Microsoft Windows NT™ Server network operating system? The answer is really quite simple-complexity! The whole area of systems management has produced products that are really more a series of related products in one package than they are a singular entity.
How these separate products interact with the user, current technology, future technology, and even each other needs to be defined. Systems Management Server provides a wealth of functionality with components like hardware inventory, software inventory, software distribution, application sharing, diagnostic utilities, and network monitoring. These tools interoperate within a maze of client and server operating systems options. It is important to define our goals for integrating Systems Management Server into those environments. Systems Management Server projects frequently are going to be integrated with changing standards in desktop and server operating systems. Explicitly define that migration path when producing the Technology Architecture.
The team members gathered to implement Systems Management Server is important to the success of the project. Having a team member with Systems Management Server experience would be great, but consider several other skill levels when filling the team roles. Utilizing the MSF team concept, several roles are defined that help an Systems Management Server project. Key to each role is that the role defines a team need This does not imply that each role must be handled by a different team member.
Team Roles and Responsibilities
Team Role Responsibility
Product User liaison, provides project resources in
Manager terms of funding and people.
Program Owner of Business Architecture and Technology
Manager Architecture documentation. Tracks project
schedule and related tasks.
Development Responsible for providing technical
implementation of the Systems Management
Server design. Knowledgeable in server
architectures, capacity issues, and
enterprise deployment.
User Understands user training issues.
Education
Logistics Helps to define the rollout, upgrade, and
maintenance plans for Systems Management
Server. Knowledgeable on enterprise support
issues.
A key component of the MSF is to approach the project from a risk-driven perspective. Let the applicable risks within a project help drive each phase. Exactly how does risk drive a project? The idea is to define all risks that could cause failure and then use that knowledge to assure success.
When defining the initial project, the objectives are the most logical place to start working on the project risks. Clearly identify elements that may create problems for the project, while documenting keys to keeping those risks under control.
Now that the project objects have been established, it's time to look at the current Technology Architecture. The goal of this analysis is to make sure that we have documented the current environment. From the Technology Architecture objects of the requirements phase it will be easy to identify which components are focal points of the Systems Management Server project. If quality documentation about the current state of the environment exists, this phase will be short. The server environments of most companies have evolved over time without proper documentation; therefore this phase will provide an added benefit.
Normal areas that will need documenting:
Physical network
Server hardware and operating system
Workstation hardware and operating system
Protocols
The physical network stands the greatest chance of having current documentation. The network engineer understands the concept of enterprise management; Systems Management Server will bring this to the PC support groups. The elements of importance to Systems Management Server are network segmentation, line speeds between segments, network redundancy, etc. The physical network topography is important when designing the Systems Management Server hierarchy. The section on the Systems Management Server hierarchy will go into more detail, but the main idea is that network speeds will play a role in planning where sites should go. The network segmentation also helps to define logical points in the hierarchy for sites to be located. A network diagram is the best vehicle for communication of this information.
Example Network Diagram
Current server analysis needs to be added to the physical network information. Along with documenting server placement relative to the physical network layout, the server operating systems should also be included. Current server usage (print/file sharing, SQL, Mail, etc.), client capacity, and hardware characteristics round out the needed information. The current server environment will provide many pieces of information important in designing the Systems Management Server hierarchy. Use of existing servers needs to be considered when designing the Systems Management Server hierarchy. All of the elements mentioned earlier-server usage, capacity, operating system type, and hardware characteristics-help to determine which servers can participate in Systems Management Server.
Example of Adding Server Information to Network Diagram
Like the previous data from the current environment, workstation and protocol information will play a key role in defining how Systems Management Server is designed. Knowing the workstation layout can influence the placement of sites. Knowing which protocols are used at workstations and servers helps to make sure any Systems Management Server site servers will have all the necessary protocols installed to provide proper communications.
Creating the Technology Architecture becomes the major milestone of the Systems Management Server project. The information from this phase is needed for the pilot project and the logistics plan. Several factors will be considered to provide a successful completion of the Technology Architecture phase. Some of those factors are from the objectives phase, others from the current Technology Architecture, and lastly characteristics of the Systems Management Server product itself. Each will play a role in creating a quality Systems Management Server design. One thing to remember is that no one design is perfect or fits all implementations. In fact the only bad design is one that provides no ability to change as needs change, and further, one that ignores all elements of the current Technology Architecture.
The new Technology Architecture is more than just the Systems Management Server hierarchy design. The physical network infrastructure is also an important component. Does this mean that an Systems Management Server design requires a change to the physical network? Most designs will not result in a change to the network. In fact most companies would probably desire a system workaround to making any physical network change. Systems Management Server was developed to work within any network topography. The point to remember is that the physical network is a part of any client-server environment and sometimes a change to the physical network is a valid, cost effective-method to meet the business objective.
Exactly what elements of a design warrant consideration of physical network changes? The circumstances will most likely surround upgrading line speeds for remote sites. Take the case of a remote site with a 256 KB link servicing 100 local users. There has been a plan to upgrade the line speed to T1 for sometime, but it just hasn't occurred. Part of implementing Systems Management Server will call for distributing Microsoft Office to those 100 users. Now is the time to consider that infrastructure change. With the upgraded line speed you will have several options in site server placement. Look at the total cost of line upgrade versus additional hardware and extra administration support costs to determine if the upgrade makes sense.
Again, Systems Management Server won't necessitate physical network changes because the flexibility of site configuration and the architecture compensate for various network topographies, but let it help justify changes that are already needed.
The whole idea behind the creation of the Systems Management Server hierarchy is to produce a system that represents the company as it makes sense to the business. The building blocks that Systems Management Server provides are primary site, secondary site, and domains. While creating a hierarchy is accomplished by taking these building blocks and interconnecting them into a meaningful network, it isn't quite a simple as working with LEGOS.
Most Systems Management Server design approaches can be broken down into two different types.
In the "logical" approach the hierarchy design is based on the business operations. This approach breaks the business into components that match operational units, either at a very high level or at a departmental level. The following illustrates that concept.
Classic Company
Finance Department Site
Finance department server
JP's machine
Malcom's machine
Research Department Site
Research department server
Albert's machine
Ben's machine
The hierarchy for the "logical" approach is easy to identify because people understand the operational aspects of the business. Producing a business breakdown as shown above usually takes very little time. This approach usually produces a very usable Systems Management Server system. Since most business operating units have the same operating needs it is easy to administer an Systems Management Server system broken down this way. Again, in the above example, some of the finance and research departments' needs will be similar; some will be different. Administration can be done either separately at each site or at the parent site. Different inventory strategies can be used at each site letting each department choose what fits them best. The downside to this approach is that it totally ignores the physical layout of the network. What if the finance department is not all located in one building or even one floor? It is not uncommon for groups to be spread throughout many buildings and network topographies. Another problem comes when determining how far to break the logical group down. Does it stop at the finance department or should it be cost centers within the finance department? Should it be functions within the finance department such as finance accounts, finance secretaries, and the like?
In the "physical" approach the hierarchy design is based on the business locations. This approach breaks the business into components that match physical aspects such as buildings or cities. The following illustrates that concept.
Classic Company
Building 200 Site
Building 200 server
Ben's machine
Malcom's machine
Building 300 Site
Building 300 server
Albert's machine
JP's machine
Again the hierarchy for the "physical" approach is easy to identify. Like the "logical" approach it can sometimes be a problem determining where to draw the line buildings, cities, states, etc. A key advantage to this approach is that businesses usually have their physical network architected in the same way. This makes the network issues relative to Systems Management Server limited. Conversely, this approach usually doesn't produce the desired effect for administering the sites. Functional groups with different inventory strategies and software distribution requirements will often be intermixed in sites.
One key to determining where primary sites will go in a hierarchy is the administration duties. Primary sites provide the capability of administering a point in the hierarchy and every site below it. This makes some decisions very easy. If a business unit wants or needs local control of their site then a primary site will be required. This administrative control can mean the ability to distribute software, control inventory strategy, or control Systems Management Server components available at the user's desktop. If any of these elements need to differ from other parts of the business then a primary site will be required to configure the system correctly.
The ability to provide multiple administration points to the system in a secure fashion is a strong selling point, but also has a down side. Remember that for every administration point you introduce you also introduce a communications point that must be administered, both from a systems and personnel perspective. Administrators will need to communicate between each other to make sure that one doesn't duplicate work of the other.
The entire system can be administered from one point in the hierarchy if necessary so try to minimize control points to make life easier. Find good business reasons to influence business units to allow central organizations to administer the system for them.
Systems Management Server provides great flexibility when it comes to adjusting the hierarchy relative to any given environment. This will create the urge to add a new site anytime some conditions such as slow LAN speeds, local administration needs, segregating inventory, and many others exist. All of these problems can be solved by adding a new site and sometimes that's the correct answer. The down side to this problem is the solution-add a new site.
This is why a good Business and Technology Architecture analysis can help in Systems Management Server design. Knowing what the real business goal is may keep the hierarchy under control. If a business goal of maximizing central control and a technology goal of minimizing servers exists, then adding new sites is not necessarily the correct answer to the problem.
In most designs minimizing the number of sites is best. Look seriously at using domain groupings within sites to maintain inventory separation. Question the need for one group to collect inventory every day while another does it every three days. Try to keep administration points to a minimum. If a group of workstations over a slow link is low, say 10 or less, it would be reasonable not to install a site. Looking closely at these issues can keep the number of sites to a manageable number. Remember it is easy to add a site when it is discovered one is needed.
What does a site server look like from a hardware perspective? How many users can be in a site? All these are interesting issues and probably some of the first that will be asked. The best numbers will result from "real world" experiences over time. Capacity considerations are defined by how you look at Systems Management Server. The issues boil down to a few key points, all surrounding the type of usage at the server.
Primary sites require a Microsoft SQL Server™ database and secondary sites do not. Therefore, primary sites have a heavier load. The server with the faster CPU and more RAM will make the better primary site server. When looking at CPU utilization and disk space requirements at a distribution server in relation to Systems Management Server functionality, the following order defines resource loading.
1. Shared applications
2. Software distribution
3. Inventory
Shared applications will have the heaviest potential loading because the workstation and server will be continually exchanging data. Software distribution is more of a one-time copy exchange between the workstation and server so it should be slightly easier on the server. Inventory starts by doing its collection at the workstation and only transfers a relatively small file to the server. Network Monitor and remote control would be heavy users as well, but they typically run at an Administrator workstation and not the Systems Management Server servers.
With little hard data available on the capacity of Systems Management Server the following information is extrapolation data based on smaller projects. With a Pentium class machine and 64MB of RAM on a primary-site server it would not be unthinkable to support inventory from workstations in the thousands. Secondary sites can get by with slightly less memory and depending on the size of the site, potentially a 486 class machine. If you have the site also taking care of software distribution to the workstation or application sharing at the workstation, then the number should be cut by 60 percent. A machine of the same class serving as a distribution server should be able to handle between 300 and 600 users. The same capacity guidelines for NTS as a file and print server should be applied to distribution servers because in essence that is what a distribution server becomes.
The actual key to capacity and Systems Management Server is disk space. With the software distribution process requiring two and a half times the size of the original package to distribute software care must be taken to make sure sufficient disk space exists on site servers. Again this issue is similar to NTS under file and print usage, disk space is always the leading indicator.
How does the shared application functionality enter into Systems Management Server design? The issue is how shared applications select the server from where the code will run. Shared applications work by distributing the application to one or more distribution servers. Users are given access to the application by creating a program group that grants access to global groups. This sets up a scenario where an application can be distributed to multiple distribution servers and access being granted to certain global groups. When a user runs the program group control application, it gathers a list of available application servers from the logon server. From this list a random selection produces a server from which the program group control application will use for the shared application. Now the key to all this is the random selection of the server.
Consider the case where the global group used covers the entire population of users, say domain users. The distribution servers used when distributing the application cover the entire hierarchy, which crosses several slow network line speeds. A user could end up reaching across a slow link to get to a server when one is sitting on the same segment as the user.
One can quickly see that when implementing shared applications the actual environment needs to be known, otherwise the desired effect may not be obtained. The keys are how the NTS domain is set up, physical network layout, distribution servers used and global group assignment to shared applications.
Setting up the workstations with the Systems Management Server client code should be part of the Systems Management Server design planning. Just how should the workstation configuration be accomplished? Systems Management Server provides methods for very automated setup, but also variations can also be utilized.
1. Logon servers can be automatically detected and logon scripts automatically be set up to run the client setup and inventory modules.
2. The same code setup automatically by Systems Management Server can be placed on a central server that each user then executes.
3. Logon servers can also be linked to manually and then have the setup code executed from the logon server.
The best methods in workstation configuration are maximizing automation and minimizing administration. Most existing environments will prohibit the use of option 1 where Systems Management Server does all of the work. This is due to the use of Master Account Domain models and keeping certain existing servers within the domain from becoming Systems Management Server servers. Option 3 provides the least amount of automation. Option 2 provides the best of both worlds. Chapter 3 of the Systems Management Server Administrators Guide contains the components needed to provide client setup.
After selecting an automated setup method to deliver the client code to a workstation the use of the SMSLS.INI file should be considered. This file is used to map a workstation to an Systems Management Server logon server. Again, Chapter 3 of the Systems Management Server Administrators Guide documents the use of this file. The SETLS program will use this file to determine on which logon server the inventory gets mapped. Planning the SMSLS.INI file is essential in order to map the inventory to the proper place in the hierarchy.
The idea is that for a certain grouping such as workgroup, domain, machine name, other domain, or WIN.INI entry a machine can then be mapped to an Systems Management Server logon server. The main method is to provide a mapping of domain=SMSdomain as in the following example, where all workstations in the workgroup JIM will be mapped to a logon server in the DOIT domain.[workgroup]JIM=DOIT
In this instance an Systems Management Server logon server in the DOIT domain will be selected via domain enumeration APIs. These APIs being broadcast in nature will sometimes be more flexible than needed. An undocumented trick to keep in mind is that by placing a server name on the right side of the equals sign, you can direct the workstation to a specific logon server bypassing the use of the enumerate API calls. The following example directs workgroup JIM to a logon server NOW.[workgroup]JIM=\\NOW
When a site contains only one server in a domain or you want a group of workstations to select a specific logon server, this is a powerful technique.
A final point about the SMSLS.INI file is the way that SMSLS.EXE parses the file. The search is linear though the file trying each match as it is found until successfully connecting to a logon server. This gives the ability to provide redundant paths for workstation mapping. The following example takes workstations in the workgroup JIM and tries to map to a logon server in the GOIT domain. If no logon server is found then it tries the logon server NOW. If that is not found it then searches for a logon server in the domain OK.[workgroup]JIM=DOITJIM=\\NOWJIM=OK
The central site is nothing more than the highest primary site in the hierarchy, but the central site can serve special functions in larger environments. When smaller Systems Management Server systems are developed it will be common for the central site to also have workstations mapped to domains within that site. Large Systems Management Server systems, where the number of servers being used for Systems Management Server sites is less important, it is good to keep the central site clean of domains that contain workstation inventory. This site can then become a trap point for workstations that are having problems being mapped to their logon server.
Taking the concept of multiple redundant logon server paths described in the use of the SMSLS.INI file previously, create a mapping for all workstations at the bottom of the file that will direct all workstation to the central site domain. Then if workstations start showing up in the central site domain you know a problem exists and can troubleshoot the problem.
Each primary site requires an SQL Server to be able to house the site database. SQL Server does not need to be housed on the site server itself. This means that one SQL Server can contain the database for several site servers. This is a concept that should be closely analyzed when designing an Systems Management Server system.
Several factors can make using a central SQL Server for multiple sites a good choice.
· Existing SQL Servers with capacity.
· Centrally managed SQL Servers.
· Site server capacity.
· Use of existing servers that are heavily loaded for site servers.
· Off-loading stress from the site server.
· Central backup and recovery capability.
At this point in the Systems Management Server project the need to readdress risk is necessary. The initial risks have been documented and it's time to check and see if we have eliminated any of those with the design as well as document any new risks that have surfaced. If the project is progressing well two things within the area of risk have probably occurred. First, the risks defined as part of the objectives phase have probably been solved. Second, the Systems Management Server design has produced a few unknowns which translate into potential risks.
The new risks will usually center around one of the functional technology areas of Systems Management Server more than any other. For instance, the hierarchy design may attempt to service a small number of workstations over a slow link without a local site. These workstations will be utilizing software distribution to move software to the desktop. This provides a risk around software distribution stressing the link and risking failures or untimely distributions. The risks that are now defined will help to drive the actual pilot in the next phase of the project.
A good planning stage will make the pilot phase and ultimate production rollout smooth, but the entire project concept is based on a risk-driven cyclical approach. Keeping in mind that the project is cyclical, if the pilot phase shows that some aspect of the design needs to change then re-enter this phase and make changes. The following table helps to consolidate some of the key points to address in the Systems Management Server design.
Issue Description
Physical network Sometimes a line speed upgrade is more
cost effective than an Systems
Management Server workaround.
Hierarchy approach Usually a combination of the logical
and physical approach works better than
a pure approach of one method over the
other. Lean toward the logical when
business unit administration is
necessary. Lean toward the physical
when centrally administered.
Local Separate sites are required to support
administration this in a secure environment.
Site servers Usually the fewer the better. Look
closely at the use of domains instead
of sites.
Capacity Utilize distributions servers in sites
to minimize site server requirements.
Shared applications Random selection of distribution server
a definite issue over WAN environments.
Workstation Utilize the SMSLS.INI file.
configuration
Central site In larger Systems Management Server
systems keep the site free from
inventory domains if possible.
SQL Server Utilize a central database server for
multiple sites where possible.
At this point in the project enough information to implement an Systems Management Server system is known. The only thing keeping the design from being turned into a production system is common sense. Every good design usually needs some tweak; training considerations usually haven't been completely addressed, and there could still be risks. Now is the time to work out the last issues and provide hands-on training for the support staff before going production.
A small controlled pilot project should provide the final checkpoint needed. The concept of a pilot project on new technology is an accepted method used for several years. The one key change that should be looked at with Systems Management Server is scope. Often pilots try to validate every aspect of the technology to be implemented. With Systems Management Server, this becomes problematic at best. The breadth of Systems Management Server functionality is intense. Piloting all aspects will probably cause one of two problems.
· Stretch the pilot much longer than necessary
· Require too much support staff
Limit the scope of the Systems Management Server pilot by selecting one key technology: software distribution, application sharing, HelpDesk, or network monitoring. Don't worry about inventory when selecting a functionality to pilot, inventory is a freebie. Several factors will make this easy to accomplish. Seldom does a business need all functionality simultaneously. There will usually be one compelling reason for Systems Management Server in the beginning with an intent to gradually utilize the rest of the functionality. Say, the need to distribute an internal client-server application to all desktops or setting up a HelpDesk capability.
When selecting the proper technology to pilot several elements built into this approach will be helpful.
· Business Architecture objectives
· Technology Architecture objectives
· Remaining risks from the design phase
Pay special attention to the remaining risks when deciding what to pilot, remember this is a risk-driven approach.
A client base for the pilot must also be selected. The key here again is risk, so select a group that provides a good view of what will happen in production. Choosing a "safe" group just to make the pilot easy doesn't provide the desired results. Three elements should be considered.
· The group selected has a high degree of need for the piloted
functionality.
· The group will be one of the first production adopters.
· This group is a high-risk factor.
An alternative to selecting the functionality first and client group second is to invert this selection process letting the group drive the functionality being piloted. This should only be done if the elements of risk remaining in the project justify this approach.
If two good client bases exist that have different functional requirements of Systems Management Server and the proper level of support exists then a pilot with multiple Systems Management Server functionality can be done. If this is done each group should contain their use of the system to just their one functional area.
Outside of validating the Systems Management Server design and working out remaining risk issues, another element of this pilot is training. This is a safe point for hands-on training of the support staff. Three main elements should be addressed as it pertains to training.
· The support staff is working through the issues of setting up the Systems Management Server hierarchy.
Issues relating to site creation, site communication, workstation installation, and troubleshooting those elements are being investigated. At the end of the pilot there should be few, if any, remaining unknowns about how to create and support the hierarchy.
· Supporting the Systems Management Server system from a people perspective should be addressed.
The support staff should utilize this opportunity to test communication mechanisms between themselves and the client base of the pilot. Many items should be investigated such as understanding how to properly gather requests for service from the client, identifying user problems, etc. The staff should be paying attention to areas that need enhanced user training materials.
· Analyze all Systems Management Server functionality and understand how it works in a hands-on fashion.
Even though the pilot is limited to one functional area, the support staff should test and utilize all Systems Management Server functions while this "safe" environment is in place.
Coming out of the pilot, risk should now be at an all-time low. If everything went perfectly the risk table should now be clean with no remaining issues. Well, we know it never works that way, so what will have developed are very manageable risks. At this point the remaining risks are documented to either drive a cyclical pass through the design phase again to hammer out the remaining issues, or to be used in the logistics planning phase.
If at this point the risks remaining don't seem manageable by small design changes, then something is wrong. It is time to step back and get more experienced Systems Management Server consultation.
The final stage of the Systems Management Server project is to define how to create a smooth transition from pilot to production. Success of the project will be judged more by the production rollout than any other element. The design can be great, the support staff can understand all aspects of the product, but if the rollout is a flop it will be the only thing management remembers.
The first key to logistics planning is back to defining the team participants for this roll. It is essential that whoever provides the rollout plan be very aware of logistics and support issues within the corporation. Success will only be enhanced if the logistics planners have done production conversions of this magnitude before. Remember, this is a key element of the enterprise. One point that should be made about the production rollout-don't try to do it all at once. Systems Management Server projects are most successful when converting from pilot to production in phases.
What characteristics of an Systems Management Server production rollout are important?
Identify the user community to receive the Systems Management Server services and where within the phased production implementation they fall. This knowledge will help in determining how the Systems Management Server hierarchy is implemented. Sites can be built and put into production as they are needed. The support staff will be aware of the level of support needed as the service is turned on. Less technical users will typically need more help than power users as the system is implemented.
Make sure that all technologies to be implemented (inventory, software distribution, remote control, etc.) have been identified within their scope.
· Hardware inventory is being implemented across the board.
· Software inventory is targeted at the engineering group upon
conversion.
· Software inventory will be collected on secretary workstations
two months after rollout.
· Microsoft Office Suite will be rolled out to the first 200 users
upon conversion.
After looking at the examples above it is easy to see how to breakdown key elements of the technology implementation. Depending on how this information is documented, it can also become an easy-to-use checklist of the conversion process. Again, knowing which Systems Management Server technology is to be utilized at what point in the production rollout will help in being able to provide the proper level of support personnel.
Get systems up and running in an inventory only capacity early. Inventory is the easiest aspect of Systems Management Server, but provides many infrastructure keys. Getting everyone up on inventory forces the hierarchy to get implemented and tested. Some problems will be found before progressing on to the more complex functionality. The issues surrounding workstation installation and mapping will also get worked out.
Phased rollout of the more complex functionality works best. Don't tackle functionality before the support staff is ready to handle it. Plan for proper training.
As computers have been put to use in more and more situations within large enterprises, the installation and management of hardware and software has become an increasingly complex task. Systems Management Server is a complex system with a wealth of functionality which provides the basis for managing that complex task. Proper planning is critical for the success of any enterprise systems management product and Systems Management Server is no exception.
This paper provided the following goals for a successful Systems Management Server project.
· Conduct the project through a risk-driven cyclical approach.
· Set project objectives.
· Establish a team with proper skills.
· Design based on project objectives and risk utilizing a few
key architectural guides.
· Pilot the design.
· Provide logistics planning.
· Move to production with a phased approach.
When searching for more information on Systems Management Server planning don't forget the Systems Management Server Administrators manual. Three sections are very helpful in understanding the concepts needed for providing an overall design.
· Chapter 2: Concepts and Planning
· Appendix B: Systems Management Server Client Reference
· Appendix C: Systems Management Server System Flow
© 1995 Microsoft Corporation.
THESE MATERIALS ARE PROVIDED "AS-IS," FOR INFORMATIONAL
PURPOSES ONLY.
NEITHER MICROSOFT NOR ITS SUPPLIERS MAKES ANY WARRANTY, EXPRESS
OR IMPLIED WITH RESPECT TO THE CONTENT OF THESE MATERIALS OR THE
ACCURACY OF ANY INFORMATION CONTAINED HEREIN, INCLUDING, WITHOUT
LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. BECAUSE SOME STATES/JURISDICTIONS DO
NOT ALLOW EXCLUSIONS OF IMPLIED WARRANTIES, THE ABOVE LIMITATION
MAY NOT APPLY TO YOU.
NEITHER MICROSOFT NOR ITS SUPPLIERS SHALL HAVE ANY LIABILITY FOR
ANY DAMAGES WHATSOEVER INCLUDING CONSEQUENTIAL INCIDENTAL, DIRECT,
INDIRECT, SPECIAL, AND LOSS PROFITS. BECAUSE SOME STATES/JURISDICTIONS
DO NOT ALLOW THE EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES
THE ABOVE LIMITATION MAY NOT APPLY TO YOU. IN ANY EVENT, MICROSOFT'S
AND ITS SUPPLIERS' ENTIRE LIABILITY IN ANY MANNER ARISING OUT
OF THESE MATERIALS, WHETHER BY TORT, CONTRACT, OR OTHERWISE SHALL
NOT EXCEED THE SUGGESTED RETAIL PRICE OF THESE MATERIALS.
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |