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: https://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

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

https://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

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.

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.

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:

1. 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.
2. Policy Body: This is the details of a particular advertisement and as such is unique only to the advertisement and therefore can be cached.
3. 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).

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.

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.