this article, will present to you common deployment planning considerations, which will include some further requirements information. The purpose of this article is not to learn exactly how to deploy SMS into a huge infrastructure, though. Rather, the purpose is to introduce concepts related to SMS, and learn some of the considerations that must be made in order to install and support this complex product.
SMS terms, concepts, and features
SMS is a fairly complex program and provides a huge amount of functionality, but requires that you learn some new terms and concepts. Before you get into actually planning, let's go over some of these terms and concepts as they will make the job of planning an appropriate installation much easier. Table A explains some of the things you should know.
Table A
There are other terms and more advanced concepts that are useful for particularly large SMS organizations that help to define how management points are assigned to roaming devices, and how roaming devices are supported by software distribution. For this series of articles, these concepts are out-of-scope, however. In these articles, I will be working with a single SMS site, although I will, in the next part of this series, provide an example of child site installation and administration.
SMS deployment planning
Before you undertake an SMS deployment, particularly for anything larger than a small, single-server SMS deployment, you should take some time to plan the deployment in order to avoid problems with your initial experience. I always recommend that you deploy the product to a single server in a lab environment before you deploy into production, particularly since SMS affects your Active Directory schema, and is fairly complex.
I'm assuming that you've already taken the step of identifying the organizational challenges that you're attempting to correct, that you've adequately documented your environment, and that you're at least basically familiar with the terms and concepts discussed in this article and the previous article in this series.
For a complete enterprise-wide rollout of SMS, you should consider the following steps as a part of your deployment plan:
1. Understand SMS basics and deploy the product into a test environment similar enough to the real environment to be able to get a sense of how the product will perform and whether it will meet your organizational needs.
2. Perform preplanning steps that analyze your current environment and management tools, and determine opportunities for integration (i.e. integration with a help desk product such as FootPrints)
3. Create the SMS hierarchy.
4. Installation planning.
5. Deploy SMS, taking into consideration security and recovery needs.
6. Deploy clients.
7. Assess.
For this article series, I will be skipping steps 1 and 6; step 5 will be included, but will be limited to deploying SMS. The SMS 2003 Concepts, Planning, and Deployment guide will provide you with a complete breakdown of Microsoft's usual recommendations for enterprise software deployments.
SMS hierarchy design
One of the more important planning steps in your SMS deployment is the hierarchical design, including site type and placement, role setting, and more. For small environments that plan to run from a single server with a single site, this step is not critical, but if you have a need to support multiple locations, or you're a large, distributed organization, this step is critical as it can mean the difference between the success and failure of your project.
Planning for this step consists, among other things, of making sure you have an appropriate design diagram of your entire network infrastructure, broken down by IP subnet. Your diagram should include all of your various geographic locations as well, in order to be able to more adequately determine which sites should be primary and which should be secondary, and which other roles are needed to support your overall SMS infrastructure.
Don't forget to include bandwidth calculations between major locations as bandwidth needs will help you to determine where you need to deploy distribution servers. As a part of your bandwidth calculations, also try to ascertain at what times of day you have peak loads on your interconnections. Further, your diagram should indicate how many clients exist in each location and on each subnet, as well as information regarding your Active Directory hierarchy. Bear in mind that SMS can be deployed in such a way that it uses your Active Directory site structure, so this information is important.
On the client side of the equation, make sure you document where you have clients not directly supported by Microsoft, such as Macintosh and Linux systems. While not directly supported by Microsoft, there are third party clients available that do extend SMS' management capabilities to non-Microsoft systems. Visit http://www.vintela.com/products/vmx/ for more information about a well-supported third party client. Also on the client side, make sure you have the ability and rights to push the SMS client out to each desktop. Finally, bear in mind that the SMS Advanced Client only runs on newer desktops, such as those running Windows 2000 or better. Other machines need to use the legacy client, which has an impact on how you need to deploy distribution servers.
Also on the client side, make sure that all clients you want to manage are members of a domain. SMS does not support the management of non-domain systems.
At the end of the SMS hierarchy design discussion, you should have a list of sites, have indicated which site will be the central primary site, which sites will be primary, which sites will be secondary, and how each site will interrelate with all other sites. Further, if you are in a particularly large or distributed environment, you should have identified the locations for various distribution points, management points, server locator points and client access points. Some of these roles are necessary only if you have older clients that require use of the legacy client. Finally, your hierarchy design should provide three-letter SMS site names for your entire SMS rollout. Remember that SMS site names cannot be changed!
The Microsoft document SMS 2003 Concepts Planning Deployment Guide provides an exhaustive, yet comprehensive, overview of additional steps you should take for very large installations of tens of thousands of SMS clients spread across dozens of locations. Chapter 9 in that document also provides an outstanding overview of sizing considerations for SMS servers, which, again, is particularly important for larger deployments. For an article-length feature, it's impossible to replicate the contents of this 676-page document!
Installation planning
The SMS installation process itself should also undergo at least some planning before you deploy into production. For example, you need to make decisions regarding whether or not to extend the Active Directory schema, whether to install SQL Server right on the SMS server or to use a separate SQL Server system, if/how to introduce SQL Server replication for your SMS infrastructure, backup and recovery, whether to use an Express or a Custom installation, and whether to use Advanced or Standard security.
When it comes to making a decision as to whether or not to extend the Active Directory schema, keep a couple of things in mind. First, SMS will work without extending the schema, but some features will not. In particular, you will be unable to publish SMS objects into Active Directory, and client features including global roaming and automatic site assignment for a client can be hindered. Further, you will need to provide appropriate entries in a WINS server for servers running certain SMS roles, such as server locator points and management points. Unless you have a really good reason not to, I highly recommend that you do extend the Active Directory schema for SMS. An option to perform this extension is provided during the installation, which you will see later in this article. If you want to extend the Active Directory schema before you install SMS, you can use the ExtADSch tool to do so.
Like most other database applications, SMS supports both local and remote SQL Server databases for its data warehousing needs. For performance reasons, Microsoft recommends that you install SQL Server right onto the SMS server. In my environment, we have fairly recently deployed SMS, but did not install SQL Server on the SMS server. Rather, we pointed SMS at our central SQL Server 2000 cluster. However, we are not a large environment. We are supporting only a few hundred clients on our SMS server, and all of our servers are interconnected with gigabit links all connected to the same switch fabric. As such, we are also not doing any kind of database replication. If you are in a larger environment, database replication may be desirable. Do note that Microsoft does not recommend that you share a single SQL Server database for multiple SMS sites.
When it comes to installation type--Custom or Express--Microsoft does not recommend the use of the Express option for production sites. The Express option, on a primary site, installs the SMS server, the SMS administrative console, remote tools, and some scripts. The custom option, in contrast, makes the remote tools and scripts optional components. In reality, the express setup option is fine for smaller SMS rollouts. However, do note that the Express option also enables just about every possible role on the SMS server, including the client access, management point, and distribution point roles. If you don't need these roles, use the custom installation method to gain more granular installation control.
The final deployment topic that I will discuss in this article is the security mode--Standard or Advanced--that you plan to use for your SMS infrastructure. Before I get started, I want to point out that, if you opt for advanced security, you can't change it back to standard, so make sure you're able to meet all of your needs before you choose the advanced option. You can change from Standard to Advanced any time.
Because of the tasks it performs, advanced security requires the use of Active Directory in order to function. Whereas standard security uses user accounts to handle SMS tasks, advanced security uses the Local System Account. Further, advanced security uses computer accounts rather than user accounts to access clients. Advanced security is not available if any of your site systems are running NT, or if you're still using an NT domain. Specifically, all of your site systems need to be at Windows 2000 SP2 or better in order to use advanced security.
On the security front, Microsoft also recommends that you install the fewest possible SMS servers and management points that you can and still provide the services you need to your infrastructure. If you're running a large environment, Microsoft has produced the document Scenarios and Procedures for Microsoft Systems Management Server 2003: Security. It's 182 pages of information dedicated to securing SMS. While I take security seriously, my goal in this article series is to help you use SMS, so I won't be discussing securing your sites very much.
No comments:
Post a Comment