SMSPerfGuy's WebLog

Same Product, New Role.

SMSPerfGuy — Tue, 13 Sep 2005 01:14:00 GMT

Well it's been a while and I'm finally back from testing SCRM and have just accepted/started in a new role as the SMS Performance and Manageability Program Manager.

What does this mean, it means I now manage the product development of :

The performance/scale and stress-ability of all aspects of the SMS product.
The managability of the SMS Product ( the key deliverable of this being the SMS Management Pack).

This is a whole new world for me, but will allow me to focus on designing and improving the product in the areas for which I'm passionate about. So if you have any ideas on how we can improve the next version of th eproduct in these areas, drop me a line.

It will also allow me to focus sometime to contribute more to this blog. I know, I know i've been a real slacker in the last 6-8 months. My only excuse is that SCRM has taken a good deal of my time, that I haven't been able to focus on anything related to SMS.

This career change also leads me into informing you of a Test position within the SMS Product Group. In fact it is one I have intimate knowledge of. Namely as a Scale and Performance tester for SMS.

If you want to help improve the scalability and performance of the SMS product, have the chance to shape the next release of the SMS product and play with really nice hardware this is the position for you. You will also have an unique position within the product group to test all aspects/features of the product.

You will be responsible for finding and isolating performance/scalability bottlenecks in the product, and driving for and verifying fixes for the ones that block us from meeting the product goals.
Here's the offical job posting: http://members.microsoft.com/careers/search/details.aspx?JobID=fa446350-7aef-4939-bc84-dde9d052eb60

Well that's all for now, i'd better go off and work out what this PM thing is all about :)

Cheers

Craig

Wanted - Program Managers, Developers and Testers

SMSPerfGuy — Tue, 31 May 2005 21:56:00 GMT

With the incredible success of SMS as a product, as well as MS's enterprise management strategy all-up, we (the SMS team) are growing in leaps and bounds! We have openings across the board for program managers, developers, and testers to help support the current SMS product, as well as design and develop the next generations of SMS to come.

If you want to be a part of the team that builds the most used systems management product on the market - send a copy of your resume to SMSJobs@microsoft.com. NOTE - these positions are all based at corporate campus in GORGEOUS Redmond (Seattle), WA. So, a preference for the color “green“ is a plus! :-)

For further information check out the following link to careers at microsoft with SMS.

With thanks to Bill Anderson for text :)

It's been a while

SMSPerfGuy — Tue, 31 May 2005 19:40:00 GMT

Hi All,

It's been nearly 6 months since my last post. As some of you know i've been working on System Center Reporting Manager for the last 9 months or so. I even got to meet some of you and present at this years MMS 2005 conference on SCRM ("Implementing and Customizing System Center Reporting Manager ").

Because I've been working on SCRM 2005 for so long I've had little chance to test and post findings related to SMS 2003.

That said a post by Eileen Brown peaked my interest. It related to the number of secondary sites supported by a single Primary Site. I've replyed to this blog with just some of my observations. This area has generally recieved little converage. To some extent that this is because "supportability" depends on so many factors no one is really willing to "sign in blood".

What i can say is that in a well managed environment the sweet stop for large scale deployments of secondary sites appears to be between 200-500 secondaries per primary site. Please see Eileen's blog for more details.

On another matter, it's nice to have another Kiwi and Auckland University Alumni at Microsoft.

Microsoft Names Chris Liddell as New Chief Financial Officer

See ya.

Craig

SMS 2003 Solution Accelerators

SMSPerfGuy — Tue, 21 Dec 2004 22:13:00 GMT

Systems Management Server (SMS) 2003 Solution Accelerators deliver additional benefits for Windows Server System environments by delivering Microsoft Operations Framework (MOF) and IT Infrastructure Library–based best practices and prescriptive guidance for handling patch management and software update processes. The solution accelerators focus on assessing, identifying, planning, and deploying patches to the Microsoft platform using SMS 2003/SMS 2003 SP1. In addition, the solution accelerators align with the Changing Quadrant as explained in the MOF Executive Overview.

http://www.microsoft.com/smserver/evaluation/solutions.asp

There are currently 2 Solution Accelerators available:

20 Questions for SMS 2003 Planning and Design.

SMSPerfGuy — Thu, 02 Dec 2004 22:03:00 GMT

Not sure if this is of interest to anyone (I’d love to get feedback), but whenever I get asked to design a scalable hierarchy for a customer I run through these 20 or so questions with the consultant/customer to help me design a SMS2003 architecture based on a customer's needs/requirements. With this information I can then start to understand constraints on such items as time, environment (both physical and geopolitical) etc.

I thought I’d post these to get people thinking about the planning phase of a SMS2003 deployment.

SMS Feature Requirements:

· What are expected SLA's for:

· SINV, HINV, Patch Mgt scan, SWMetering reporting at central site from the time the client initiates the scan, from a reporting pint of view.

· SWD SLAs and sizes of:

· Patch/emergency SWD.

· Regular SWD.

· Large SWD (office, SP etc).

· What is the expected SINV size and configuration of files to scan (will it be *.exe or a more focused scan (hint, hint)?

· And at what frequency?

· What is the expected HINV size and configuration (will they want to change the default def.mof)?

· And at what frequency?

· What is the expected SWMetering size and configuration (how many products/files etc)?

· And at what frequency?

· How many SWD advertisements will be created at the central site? In total and per week?

· How many SWD packages will be created at the central site? In total and per week?

· How many collections (and what size, dynamic or static) will be created at the central site? In total and per week?

· How many advertisements per week/month per client will be initiated?

· What’s the average number of clients expected to be targeted by a weekly or monthly SWD advertisement?

· Will the customer be expected to report on SWD to client progress from the central site?

· How many child sites (a basic typology would really help at this point). Include # of clients, WAN links etc.

· What's the AD environment?

· What discovery/client deployment methods they wish to use? And how often?

· What's the backup strategy for this environment. What's the downtime SLA?

Standard Environment Details Needed:

· Number of physical locations within the company.

· Network links (both link speed and available speed).

· Number of users/machines at each location.

· Any geopolitical or legal limitations of design.

· Define any reporting hierarchies. HQ reports data from 4 regional locations, who report for each of the locally based branches etc.

Basically a very detailed Visio document is worth a thousand words.

System Center Reporting Server 2005

SMSPerfGuy — Mon, 29 Nov 2004 21:51:00 GMT

Hi All,

It’s been awhile, as some of you have so clearly pointed out.

Since my last post ( Mid September, has it really been that long?!!), I’ve been heads down working on the design and testing of System Center Reporting Server 2005 (try saying that 5 times fast). Since one of the requirements of a Microsoft employee blog is to not discuss pre-released products, I’m kinda unable able to discuss what I’ve been up to for the last 2-3 months.

So what can I tell you about System Center Reporting Server?

1. I can tell you that those of you running SMS and/or MOM and are looking to deploy System Center Reporting Server 2005 when it’s released, better brush up on your SQL DBA skills. Especially in the area of DTS job monitoring and troubleshooting, along with spending some time getting comfortable with SQL reporting services.

2. From a planning perspective, I’d like to set the record straight that System Center Reporting Server is a data warehouse not a reporting server like SQL reporting services.

In researching (briefly) the definition of a data warehouse I can upon this very good definition from the Minnesota Historical Society.

“Data warehouses are computer based information systems that are home for "secondhand" data that originated from either another application or from an external system or source. Warehouses optimize database query and reporting tools because of their ability to analyze data, often from disparate databases and in interesting ways. They are a way for managers and decision makers to extract information quickly and easily in order to answer questions about their business. In other words, data warehouses are read-only, integrated databases designed to answer comparative and "what if" questions. Unlike operational databases that are set up to handle transactions and that are kept up to date as of the last transaction, data warehouses are analytical, subject-oriented and are structured to aggregate transactions as a snapshot in time.”

What this means is that I suggest you start designing a hardware platform for this server based on data warehouse methodology not SMS or MOM server sizings. J

3. A lot of people are under the impression that this Reporting Server will be a replacement for the SMS Reporting Point. This is definitely not the case. In fact most companies are more than likely to have both implemented, since they target two distinct groups of consumers. SMS reporting server consumers will be predominately Local SMS administrators, helpdesk personnel and IT managers. System Center Reporting Server consumers on the other hand will be personnel such as Asset Management analysts, IT Managers, CIO/Board of Directors reporting staff and IT capacity planners etc.

From the System Center Datasheet:

System Center 2005 introduces System Center Reporting Server 2005, which consolidates event and performance information from Microsoft Operations Manager (MOM) 2005 and change and configuration information from Systems Management Server (SMS) 2003. This combined information can be utilized for data mining and analysis, and can be exposed through rich, robust, and extensible reporting via SQL Server^TM Reporting Services. This integrated reporting capability provides easy access to the data that you need to manage your enterprise. With better insight into your environment, you can make more informed decisions, and clearly demonstrate the value IT brings to the business.

The System Center Reporting Server is designed to assist decision makers with “What if?” and point in time questions (based on different analysis dimensions, like time, resource ID etc) such as:

“What does my server environment look like today?
How are my Webservers performing today, since I applied patches XYZ?
What security patches have I applied to machine X?”

And not daily operational questions such as:

· “How is my advertisement of XYZ doing at this moment?”

· Which machines have sent hardware inventory in the last 7 days?”

SMS 2003 SP1 Ships

SMSPerfGuy — Fri, 10 Sep 2004 23:58:00 GMT

After much blood, sweat and beer it ships.

http://www.microsoft.com/downloads/details.aspx?familyid=0ddfeb0a-86fd-4681-b65f-dfa67629932e&displaylang=en

Microsoft Systems Management Server (SMS) 2003 Service Pack 1 (SP1) is primarily a rollup of a number of fixes for SMS 2003, but also introduces some changes to the supported configurations and broadens the configurations allowed.

Configuration Changes

§ To enhance security, the SMS Legacy Client will be supported on Windows 98 and Windows NT 4.0 SP6a operating systems only. Note that SMS 2.0 clients and Legacy Clients running on Windows 2000, Windows XP, and Windows Server 2003 will not upgrade to SMS 2003 SP1.

§ Reduced requirement for WINS in SMS. If DNS is configured to enable SMS clients and servers to resolve each other’s NetBIOS names then SMS 2003 SP1 does not require WINS.

§ Product keys are required to install SMS 2003 SP1 and can be found on the SMS 2003 product CD case or through Volume Licensing

Broadened Configurations

§ Workgroups

§ Advanced Client support for Virtual Server 2005 and Virtual PC 2004

§ Advanced Client and Distribution Point support for Windows Storage Servers

§ Support for English site server installation on localized operating systems

SMS 2003 SP1 also includes incremental improvements to usability, security, and performance.

Usability

§ Categorize queries, packages, advertisements, reports, and software metering rules easily - with the addition of folders in the Administrator console

§ Over 100 accessibility changes to meet the needs of government and private industry.

Security

§ Authorize critical updates immediately without waiting for inventory scans

§ Track the status of updates with more granular reporting

§ Tightened data privacy for client inventory information provided through encryption of inventory data

§ Enhanced security through the ability to configure the server and Advanced Client ports used for communication

§ Apply signed security at the time the client is provisioned to operate at a higher level of security

§ SMS 2003 had server authentication only. SP1 now has client authentication to protect servers from client spoofing

Performance

§ Improve inventory performance by excluding the Windows Directory during software inventory scans

§ Control bandwidth utilization by specifying the size of the data packages and by using pulse mode to define the time between packages when sending data between sites

§ Improved client inventory performance to minimize user interruption during software inventory scans through enhancements for Windows Management Instrumentation (WMI)-based inventory

§ Reduced time for package distribution and support for a greater number of distributions points per site

§ Improved software distribution and less network impact in 3-tier hierarchies by allowing the sending site to send content directly to the recipient sites without having to send multiple copies through a middle site

Proxy Management Points: Part 2

SMSPerfGuy — Thu, 09 Sep 2004 04:13:00 GMT

This is a follow up to the previous posting on the topic of Management Points.

A number of you have asked some clarification questions which I’ll seek to answer here.

Firstly there were a number of questions around when a client initiates a particular request:

Policy Assignment requests: These are executed as per the Software Distribution Client Agent polling period. By default this is every 60 mins. However what is not clearly known is that the client will actually issue 2 policy assignment requests every polling cycle.

One for all advertisements assigned to the machine.
One for all advertisements assigned to the user and the usergroups the user belongs to.

These requests may or may not happen at the same time and are 2 distinct requests.

Policy Body Requests: These occur only when a new advertisement has been received via a policy assignment request. These specify the configuration of the advertisement; such as when it should run, how it should run etc.
Location Requests: These only occur when a mandatory advertisement needs to execute or the user has chosen to run an optional advertisement. This request then seeks to identify what DPs have the source files necessary for this advertisement.

In summary, only the policy assignment requests are scheduled, the other two only occur “as needed” and are determined by the software distribution frequency.

Another question I get on a regular basis is “How much traffic is generated by SQL replication?”

This is a tough question to answer, since SQL replication is almost a product unto itself. It has a number of methods of configuration.

In the worse case we could assume that a snap shop replication occurs daily. This equates to approximately 50 bytes per resource at the Primary Site times the average number of advertisements per resource.

50 bytes X (# of resources X average number of active advertisements per resource)

However we recommend that transactional replication being used. This is where things get tricky since you can configure transactional replication to occur immediately or on a scheduled basis. This could be smaller or larger than snap shot replication since this will replicate the transactions that occur against the tables we replicate. These are then “replayed” against the replicated DB. At this point in time we still need to perform in-depth analysis on this process before we can provide guidance/sizing of this process.

This is where lab testing will be beneficial to simulate a production environment prior to deployment.

I think the next set of articles I write might focus on testing processes and guidelines for pre-production deployment of SMS 2003.

Proxy Management Point: Benefits and Otherwise.

SMSPerfGuy — Thu, 12 Aug 2004 03:31:00 GMT

One of the most confusing concepts in SMS 2003 is the use and application of a Proxy MP (PMP). I’ll try to explain firstly what the PMP does and doesn’t do, and secondly address when you could consider implementing a PMP.

Firstly the key benefit of deploying a PMP (on a secondary site) is in the network traffic and network scheduling capabilities that the secondary site provides when sending inventory data files up the hierarchy (when I refer to inventory I really mean DDRs, software inventory, hardware inventory, status messages and software metering files).

Without a PMP at a location the advanced client will send all its inventory data over the WAN (be it, somewhat compressed, but not nearly as compressed as the same data being transferred by a secondary site. The client has a compression configuration optimized for speed; the secondary site has one optimized for file size)to a MP over the WAN, based on the client inventory schedule.

With a PMP at the location, the client will send inventory files. Once received the PMP will convert them from XML to native SMS file formats and “forward” them to the secondary site. The secondary site will then compress these files and forward them, via the sender (and using the sender scheduling and bandwidth controls) to its parent primary site server. The secondary site will also send these files in batches (saving even more space) on a per file type basis, if there are multiple inventory files of the same type.

For locations with small numbers of clients the difference between having a PMP and not is very small (particularly because the secondary site sender header adds additional network traffic, and could be even costlier than not having a secondary site/PMP). However as the number of clients at that location grows, so too does the network savings. To get an idea of whether or not your locations will benefit from a PMP/secondary site use the SMS 2003 Capacity Planner to illustrate the various site server options you have.

The PMP does also offers some network traffic and potential fault tolerance benefits related to software distribution, this however has been misrepresented as the primary reason for deploying a PMP.

As a bit of a background the Advanced Client (AC) issues 3 software distribution requests:

Policy Request for a machine or user: This is check to see if there are any advertisements for the machine or user/usergroup. These occur by default every 60 mins (admin configurable). Policy requests are ~10-12Kb per client per hour. These are unique for each machine or user/usergroup. Therefore cannot be cached locally by the PMP.
Policy Body: This is the details of a particular advertisement and as such is unique only to the advertisement and therefore can be cached.
Location Request: This provides the location of the available DPs with the advertisement package. This is based on location (IP subnet etc) and thus is kinda unique to the client machine. Location requests are ~6-8kb per client per advertisement executed. These are not cached.

As you can see the only software distribution data cached on the PMP is the policy body, these are typically <50Kb. The other 2 transactions are smaller, however they are per client. Therefore as the client count increases, so to does the network traffic associated with software distribution functions.

The only way to reduce this software distribution traffic from traveling over the WAN (since the PMP makes these requests on behalf of the client to its Primary Site SQL Data) is to deploy a replicated SQL database at the PMP/secondary location and then replicate the SMS database tables & stored procedures needed. These can be found by executing:

Select * from replicatedobjects where sitesystemtype = ‘MP’

With this design the PMP will not travel across the WAN, but will instead make queries against the local database replica. Note this does require additional configuration in SQL Enterprise manager AND in the SMS Admin UI to “point” the PMP at the replicated SQL DB. An will result in more SQL network traffic, as the replication of transactions etc occurs (SQL replication can be configured in a number of ways, which affect the nature and volume of replicated data).

Depending on the number of clients at the primary site, this SQL replication may generate more or less traffic that having the PMP use the primary sites’ local DB. I’ll discuss SQL replication and its implications in a future article.

Hopefully this illustrates the reasons for PMP placement and clears up some of the misunderstanding surrounding PMP usage/benefits.

When to consider deploying a PMP

Basically this comes down to inventory file volume. When the volume of inventory generated by the ACs at the location exceeds the overhead of deploying a secondary site (and PMP) then a secondary site/PMP should be deployed. I don’t have a rule of thumb as to when this might be, since it depends on number of clients, WAN link speeds, inventory configurations etc.

The best advice I can give you is to download the SMS2003 capacity planner and enter in your environments’ appropriate data and review the various site server options (including appropriate traffic volumes). This analysis will illustrate the expected WAN utilization for a location if you were to place; no SMS server, a DP, a Secondary site, a Secondary site/PMP, a Secondary site/PMP/Replicated SQL or a Primary site.

It's Official!

SMSPerfGuy — Sun, 25 Jul 2004 11:22:00 GMT

The SMS 2003 Capacity Planner Tool and Guide has gone live!

Its available from the Microsoft Download center as well as via the following link from the SMS 2003 Deployment website.

This has been many weeks and months in the making from both Muki and myself.

A big thank you to the MCS/PSS personnel, the Myitforum Advisory Council, Microsoft TAP customers and SMS MVPs who tested various alpha/beta versions (plus anyone else i failed to mention, like my fellow employees on the SMS product team!).

Since this is version 1, I expect to develop and update the tool on a periodic basis or as the SMS product itself changes.

The primary method of posing questions etc regarding the tool or it's output will be the Microsoft Communities SMS Tools newsgroup. However for comments and feedback on future versions/features please feel free to post comments to this blog.

Thanks, Craig.

Reminder: Webcast on SMS 2003 Capacity Planner Tool will take place tomorrow morning

SMSPerfGuy — Fri, 16 Jul 2004 02:42:00 GMT

TechNet Webcast: SMS2003 Hierarchy Planning and Design with the SMS2003 Hierarchy Capacity Planning and Hardware Sizing Tool - Level 300

Date: Friday, July 16, 2004
Time: 9:30 AM-11:00 AM Pacific Time (GMT-7, US & Canada)

The SMS2003 Capacity Planner tool (new shorter name!) is also scheduled to go live tomorrow on the SMS download website

See ya there.

Craig.

The Defmof

SMSPerfGuy — Fri, 09 Jul 2004 19:00:00 GMT

As I alluded to in a previous posting on SQL DB sizing, carefully defining changes to the defmof can play a large part in determining the performance of hardware inventory processing at a primary site. Often I have seen the performance of hardware inventory drop dramatically because of poorly implemented changes to the defmof.

How SMS Primary Site uses the Defmof:

The defmof is composed of multiple object classes that themselves are composed of multiple properties. Each object class result in a separate table being created by the Primary Site once it receives an inventory file (.mif) from a client with the compiled defmof.

This can result in poor performance from two areas:

Inventorying of properties that are dynamic in nature and thus constantly changing.
Defining too broad an object class, leading to large tables of dissimilar data.

Let’s explore these two issues:

Inventory of Dynamic proprieties

One of the major reasons hardware inventory can suffer is the frequent inventorying of properties that are very dynamic in their nature. For example; in prior versions of SMS we used to inventory machine properties such as; freespace, free physical memory, free virtual memory. Now these were often important, especially in the past when disk space wasn’t as cheap as it is these days, in today’s environment these are less important.

The problem with these proprieties is that since these constantly change, every inventory cycle, they result in a large history table being maintained for these object classes. When new inventory is received the old data is moved from the data table to the history table. The larger the history table, the longer it takes to move the data.

Now consider the problem if in addition to the default machine properties you also add additional objects/properties that also change each inventory cycle.

Some examples that some customers turn on are:

Win32_Process
Win32_NTEventLogfile

Both of these are extremely dynamic and will change almost every cycle.

While it’s important to capture the data you need to manage your environment, it’s important to perform a cost/benefit analysis on the speed at which you change the ability of the server to process inventory vs. knowing what Win32 processes you have running.

Defining too broad an Object Class

O this is perhaps the more likely defmof change that affects many customers. Once you define a class object the tendency is to use this object class to capture large volumes of data about your specific environment. It’s the usual story, the object class is already created to capture some company specific data so what’s a few more proprieties?

Sound familiar?

Well the problem with this is that SMS uses a single stored procedure to insert all proprieties in a class into a single database table…see where this is going?

Firstly you have this stored procedure that will take a relatively long time (multiple seconds) to execute into a table that is constantly growing, resulting in even longer execution times for the stored procedure.

The best advice I can give you is to:

Plan carefully the changes you intend to make to the defmof. Test and retest in a lab with production class and configured machines.
Try to create discrete object classes for each additional group of information you wish to collect. So that you create multiple tables (data and hist table pairs) for each class.
Add one object class at a time and test these defmof changes in a lab environment and review the table changes that occur.
Try to minimize the number of classes/proprieties you collect that have regularly changing values.
Do not use one class as a catch all for all custom properties you gather from your environment.
Think about how the data you capture will be used. If its there “just in case” someone needs it, perhaps it’s not really necessary. Or perhaps there’s a better way to use software distribution to distribute an application that can collect this one-time use data. Even if it’s used every six months, why collect the data every week or worse daily.
Remember changes to the defmof will kick off resyncs on the standard client. They will NOT kick off resyncs on the advanced client.

Webcast: SMS2003 Hierarchy Planning and Design with the SMS2003 Hierarchy Capacity Planning and Hardware Sizing Tool

SMSPerfGuy — Thu, 17 Jun 2004 23:30:00 GMT

TechNet Webcast: SMS2003 Hierarchy Planning and Design with the SMS2003 Hierarchy Capacity Planning and Hardware Sizing Tool - Level 300

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032254379&Culture=en-US

Shameless self promotion. :)

Date: Friday, July 16, 2004
Time: 9:30 AM-11:00 AM Pacific Time (GMT-7, US & Canada)

Description: If you are planning of an SMS2003 deployment you need to collect data about your IT infrastructure first. This webcast shows how to get that information and put it to best use. Guided by the “Scenarios and Procedures for Systems Management Server 2003” document (available from the Microsoft® website), this presentation shows how the data gathered helps you develop an Enterprise SMS hierarchy architecture. Then we show how to use the collected data as input for the SMS2003 Hierarchy Capacity Planning and Hardware Sizing Tool. The webcast includes demonstrations of the document worksheets and the capacity planning tool.

Presenter: Craig Morris, Software Test Engineer and Steve Kaczmarek, Technical Writer, Microsoft Corporation

Microsoft TechNet Subscription Giveaway

This webcast is eligible for the TechNet Plus Subscription giveaway. By attending this live webcast you can enter to win a one year TechNet Plus subscription. One winner will be selected from each TechNet webcast. See the official rules for details.

Find out about other TechNet webcasts

SQL and DB Sizing for SMS 2003

SMSPerfGuy — Sun, 06 Jun 2004 07:53:00 GMT

The sizing of SQL DBs for SMS has always be a much debated topic for many years. In SMS1.2 and 2.0 days we generally recommended 1-200kb per client plus 50 Mb for a database size.

DB Sizing changes for SMS 2003.

Considerations:

1. One problem with these recommendations is that today with the new feature sets of SMS 2003 we have to consider no only SMS but also its feature packs such as Patch Management and the upcoming OS Deployment and Device Management. Device management has the potential to double the number of “managed” machines in some organizations.

2. New features such as file path reporting for software inventory, a more useable Software Metering feature and the use of the DB to store client software distribution have changed the landscape considerably.

3. Customer extensions to hardware def.mofs greatly exceeded our expectations.

During the SMS2003 development cycle we closing monitored Microsoft’s own deployment as well as that of our beta enterprise customers.

The conclusion of which is that most customers can utilize a sizing estimate of 1 Mb per client for the SMS DB for most standard deployments of SMS 2003. For customers who feel they will really push one of the features above, a conservative estimate would be to use 2Mb per client.

Detailed Analysis of DB Usage.

In the databases I have examined, software inventory and statue messages are the biggest DB users. For SMS 2003 we introduced the tracking for file path for each executable we report. This is fine for most environments. However when there is more than one location of a client for a particular file, instead of reporting this as two instances counts for the same row in the software inventory table, we now report it as 2 separate rows. This is clearly going to make a big difference from SMS2.0.

In theory status messages for SMS2003 should be more performant from SMS2.0 as we eliminated a number of “less than useful” (PC statement) status messages. However on the flip side, software distribution and client reliability percentages have greatly increased, result in more status messages being delivered.

In SMS2003, as in SMS2.0, customer expansion of the hardware inventory definition file (def.mof) can also play a defining role in DB sizing. Many customers of SMS2.0 extended the def.mof to gather any number of company specific and non-company specific items.

However the mistake many made was in not considering the storage needs of these new items and designing the extensions to utilize multiple tables and indexes. By failing to do this, the performance of hardware inventory processing suffered at the hands of trying to update the same single DB table for multiple classes/categories. The larger the table the slower adds/deletes and especially inserts can be.

Tempdb and SMS Log DBs.

The tempdb is used by SMS on a regular basis. The area that normally causes problems are when a Query or Collection (using a query) is badly formed, resulting in the need to create a very large temp table to produce the results. In some cases I have seen these temp tables/DBs group to over 100% of the associated SMS DB (sometimes over 36Gb). Be very careful with queries.

The tempdb is also critical during upgrades. Temporarily increasing the size of the temp DB to over 50% of the SMS DB is sometimes necessary under these conditions. Please ensure you run setup.exe with the /testdbupgrade switch at least once before any upgrades take place.

The SMS transaction log is used to record all transactions that are written to the SMS DB. By default SMS’s backup regime is set to “simple” (see SLQ documentation for further information). Essentially what this means is that the SMS log DB is not going to be used for restores. If the machine crashes you will be able to restore the site server to the last SMS backup (you will lose all processing since then). This means that SQL will clear parts of the SMS log DB as required.

Generally, the common recommendation configuring the SMS log DB and Tempdb to be 20% of the SMS DB size is probably a very good place to start.

The exception to this is when SQL replication is used for MPs. With SQL Replication being configured on the SMS site server the SMS Log DB will not be cleared until replication is successful. Careful monitoring of replication is therefore required (through SQL Enterprise mgr) to ensure you don’t cause the SMS log DB to run out of space. If this occurs, data loss is possible.

Suggestions

For both SMS DBs I generally like to have “autogrow” enabled and set to grow by a percentage instead of a fixed amount of MB.

Your own experiences and careful monitoring (mainly using SQL Enterprise Manager and SQL Profiler) will allow you to determine what the best configuration is for your environment. During deployment watch the size of the DBs grow as the number of clients installed increases.

Disk Configurations

As far as disk configurations the greater the separate of these DBs from each other the better. Three separate disk arrays is obviously the best, but not always possible. If you expect large volumes of processing to occur, separation of the SMS DB and the SMS log DB will yield good results. However if a large amount of reporting is likely to occur, then separation of the tempdb from other DBs might be important. Once again it all depends. My preference would be to maximize the separation of the SMS DBs, especially is SQL replication is enabled.

With disk hardware being as cheap as it is these days, there really is no excuse not to over spec the size of the drives. As far as which RAID configuration to use, well that depends so much on the environment, in most cases RAID 10 is preferred, then RAID 1 (assuming using 2 channels) or RAID 5. But this also depends on SCSI channels available and card memory, as well as the enterprise environment (size etc) and requirements. I am not going to recommend any solutions here, as the range of options are numerous and always hotly debated.

For example separate RAID 10 array’s for each DB is very, very expensive and probably overkill. I would however consider it a very good solution for the SMS DB and possibly use RAID 1 for the SMS log db and tempdb.

New SMS 2003 Training courses available.

SMSPerfGuy — Wed, 26 May 2004 23:23:00 GMT

Managing Microsoft Systems Management Server 2003

http://www.microsoft.com/traincert/syllabi/2596afinal.asp

This five-day instructor-led course provides students with the knowledge and skills to manage Microsoft Systems Management Server (SMS). Students will learn how to configure SMS components and how to manage the ongoing operations of an SMS infrastructure.

This is a beta version of the book but is available now. While currently still in beta, some training centers already have these on their schedule (on the right there’s a search you can run based on location).

Planning and Deploying Microsoft Systems Management Server 2003

http://www.microsoft.com/traincert/syllabi/2597afinal.asp.

This three-day instructor-led intensive course provides the knowledge and skills necessary for SMS specialists to plan and deploy Microsoft Systems Management Server 2003 into large enterprise environments.

2597A (also a beta version of the course) should be available to order really soon, I think this week.

The B versions (final versions of the book) will be available in July. Those versions will incorporate feedback from the beta teaches of the courses.