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 :)

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:

1. Patch Management Solution Accelerator
   
2. Business Desktop Deployment Solution Accelerator

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?”

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.

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.

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:

1. Inventorying of properties that are dynamic in nature and thus constantly changing.
2. 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.

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.