Paul Thomsen at myITforum.com

Summary: Friday has to be the most emotional day of the conference. It's subdued because a lot of people are sleeping in or have left, but the die-hards have a last chance to get some more and to say good-bye. There are good sessions to be attended, and it's unfortunate that too many people miss out on the goodness.

I'm writing this entry after the fact, back at home. It was a wonderful week, as always. I had a great number of conversations with MMS newbies, including guys from various parts of the world, small organizations, and huge organizations. I had even more conversations with MMS veterans, product team guys, and (occasionally) my own team members (of which we had 6 this year - a record by far). I come back with the strength of the community, which is awesome. I do not lack for motivation or inspiration.

On the other hand, it's great to be back to my family (including my puppy, for those that saw the Thursday keynote) and my technology. Family, non-techie friends, HDTV, great sound, great tunes, my bed, etc. cannot be reproduced on the road, so it is good to be home.

I finally got brave enough to look at my main session's review score, and it turns out it came in number 11! That's out of 126 sessions, so quite good. The next time I do this presentation I'll have more technical content to add, and a hierarchy diagram. The Ask The Expert's session (which I just helped with) seemed to go really well (as evidenced by the hands up to ask questions towards the end) but got more average scores. I'm sure Rod Trent and I (pthomsen@microsoft.com) would be very pleased to hear more ideas on how we can improve that one. We've got ideas, but it's not clear what the ideal approach would be.

I'll see you next year!

 

Summary: good sessions, good conversations, good times. What more could a techie ask for? I was especially inspired by the SMS SDK session.

Today's keynote didn't do much for me, but I haven't surveyed others for opinions. It featured 4 customer CIO's answering standard questions. They gave the politically correct answers that top executives must give in public and everyone agreed that System Center is wonderful (which we knew already). But to get it all started there was a quick mini-presentation on the wonderfulness of puppies. That had us rolling in the aisles (and made me homesick for my 2.1 year old Golden Retriever) 

I attended the SMS SDK update session and that gave me lots of ideas. For example, console extensions seem very flexible, and fairly easy, so I'll do a bunch of those in my spare time... There's a new managed provider interface that sites on top of the SMS Provider for some key but tricky operations (like running queries). Apparently we shouldn't use the MMC SDK when making console modifications - we should just stick to the SMS SDK approach. I'm thinking about how we can use the MP API's to do another level of MP smoke testing. We can add task sequence functions, if we like (such as checking or modifying .INI files). SUM can be fully scripted, so that if you build enough logic into your script then you could do all your Patch Tuesday patch authorizations by double clicking the script. That would reduce a function that was 1.5 hours for us with SMS 2003, and should be about 10 minutes with SCCM 2007, to about 3 seconds. I hope the MSIT patch mgmt administrators don't read my blog - their job is in jeopardy! (I do kid here - I was the patch mgmt lead for a year or so and I know very well that patch authorization is just 1% of the patch mgmt work in a larger enterprise, so eliminating that 1% won't make much difference).

So apparently the SCCM Beta 2 SDK shipped recently, and the RC version of it will come near SCCM RTM. The beta 2 version is about half complete (but does have the console details), and the RC version will be complete.

I was invited to be on the Ask the Experts panel this year, and was the token Microsoft representative. The audience was shy at first and so we took our time with the first few questions, but as the session went on everyone got a lot more enthusiastic. Hands were flying up everywhere. So I'm afraid we only got to about 1/4 of the questions. We're considering how to make it more efficient next year. That probably means I should be a little less politically correct myself - explaining the Microsoft perspective on some issues can be time consuming.

I caught the tail end of the Internet Based Computer Management / SCCM Security session, and apparently there are 3 white papers coming for how to use PKI with SCCM! That was really good to hear. I've heard the message several times this week that all kinds of SMS guys are nervous about how they're going to make PKI work (though they understand the need for it), so that kind of help will be crucial.

I caught most of Greg Ramsey's session on using PowerShell with SMS, and he's done a great job of putting all the pieces together to do most of the common things one would want to do with SMS from the command line. But PowerShell itself still seems too awkward to me. It looks more like a programming language than a scripting language to me (well, I suppose it looks like a UNIX scripting language), and the output is always klunky. But I'm keeping an open mind, and I'm sure we'll get to the level where those issues are addressed.

The big event party was nice enough. It was very close to the hotels, which was a nice change. They opened a bunch of restraurants, and had a good band or two. But the food service shut down around 8:30, and they switched to cash bars at 10:00, which scared most of the attendees away. I got carried away with talking, so missed most of the food and only got to chat with a few people that I was hoping to catch up with. Most people got away to other locations and continued the party, but I was pleased to get an extra hour or two of sleep after a busy week. Some people liked it more than last year's big party, and some less. But there was agreement it wouldn't have been worth the spouse fee ($75 to let your spouse come to the party). 

(I'm down about 4 pounds this week - I'm going to write a diet book (they always sell well): The Conventioneer Diet. You lose weight by attending conventions (though maybe it only works if you're a speaker)).

 

Summary: another wonderfully exhausting day, including doing my presentation. Service Desk and 1e were highlights for me, and the great conversations continued.

The keynote was well received. A fair bit of the presentation was about Service Desk, which will be an important new part of the System Center family. We heard about it last year, but now can see the vision more clearly. Everyone seemed quite impressed and anxious to get this new family member. The integration with the other members, like SCCM and SCOM, will address some key business issues. But the 2008 release date means we have to temper our excitement.

I took in the 1e two hour sales pitch, which is always well done.

I hung out at the Ask The Experts area during the time when speakers are supposed to be there, and we had a great multi-way conversation on a variety of SMS topics for about 1.5 hours. This may be one of the best kept secrets at MMS. It's a great chance to have casual but technical conversations with experts and peers. People were asking questions, discussing problems, offering solutions, telling war stories, and so forth. Everyone got quite a lot ouf ot it, I believe. Beer and food were available, but few people were bothering with that. For SMS we only had about 20 people, so a lot of people missed out.

1e hosted their always fabulous party. There was good representation from myITforum and the Microsoft SMS product team. In past years I haven't connected a lot with the product team at any of the parties because they're usually busy at dinners and similar more focused events with customers. So it was good to see they had a little time for the 1e event this year.

Summary: the real activities began on Tuesday. It was another great day at MMS 2007 for me, but I also learned a few things, got inspired in various ways, and observed that our computer management industry is still maturing. What will MMS 2012 or 2017 be like?? 

The keynote was good. A lot of the usual DSI focus, and Operations Manager 2007, since it's released now. I really got the impression (both at the keynote and from the conference generally) that System Center is really something now - it's not just a marketing spin on SMS and MOM. There are plenty of products in the family and they really do complement each other to some degree. Together they make a compelling story. While chatting with several people, they said much the same thing.

It's confirmed that MMS 2008 will be at the Venetian. Will the Blue Man Group be the Thursday night entertainment? (no, I haven't heard anything)

SMS is selling well, and the support issues are way down. In particular, usage is about double from when SMS 2003 was released, to about 50,000 customers, according to Bill Anderson. All SMS features are being used more than ever, and yet the CSS (formerly PSS) call volumes are half of what they were when SMS 2003 was released (and that volume wasn't bad). Chatting with various consultants at the show, they agree SMS business is better than ever.

Note to self: plan to deploy SMS 2003 SP3! (hopefully in April, but we are busy.) The asset management reports (based on the technology from the Asset Metrix acquisition) look great! My team didn't have the time available to dogfood SP3, so that was left to external customers, so we haven't seen SP3 much.

So what can I say, there's lots of TechSexy stuff here at the conference, and in the software I've gotta use more when I get back to the office.

Microsoft added a party to the usual MMS cast of a thousand parties - at least in part to promote TechSexy. It was very nice, though a little cold due to unseasonable weather. I'm getting the impression that the conference party bar is rising, and being openly acknowledged as an important part of the business of MMS. A few other people I chatted with have had similar observations. And because the parties are restricted (each vendor can only afford to entertain so many people), there is an element of them being an 'insiders' opportunity. They're a good chance to informally meet with people that one might not normally get much chance to talk to. Fortunately there are so many parties, each with a different focus, that almost all attendees can be an insider of one sort or another (depending on which products you use, community participation, interests, etc.).

BTW, if you find yourself more out of the party loop than you would like, then try to develop a party radar. If you hear the word "party" listen closely. Quickly follow the instructions or rumors to get an invitation. Talk to your favorite vendors (especially if you're a customer or really might be one for them). Don't be too shy. Ask the people you chat with about what they're heard. One way or another you can get to some more events.

And yes, parties have free beverages, some food, and some kind of entertainment, so they might sound like all fun. And yes, some people will imbibe too much and decrease their conference productivity. But with a little moderation and effort, the parties actually add greatly to the conference experience. The conversation isn't always work related, but it often is (how inventive can computer geeks be when it comes to conversation topics? 

 

Summary: Getting settled. Meeting and greeting. Booth work at the Microsoft booth. It is always wonderful to see so many old friends and faces. Overall it was a great day for me but most of it was not especially blog-worthy. But I've got a few points to blog.

Steve Thompson had a couple of the only breakout sessions today, and they were on SQL queries. He started at the basics and soon got into fairly advanced topics. Good stuff, but what particularly impressed me was that there was a very large turnout to the sessions. Most of the people described themselves as novices. So it shows that there is still a lot of SQL learning that needs to be done in the community. I've been considering blogging on SQL topics some more, so now I've got some more ideas on how to approach that.

Another point is by way of a universal, partially pre-emptive apology to conference attendees. Actually, maybe it's an apology from all attendees to other attendees. In 'civilized' circumstances there is an art form and etiquette to social conversations. For example, at a cocktail party. We all know to try to be engaging conversationalists, but if the other person is not so interested, to let them transition away. We should try to be inclusive of other people in the area. When transitioning from talking with one person or group to talking with another, a nice segue is ideal, but at least there should be 'sign-off' (e.g.: "it's been good to talk with you again..."). But I find that at the conference these niceties often don't happen. The crowd is so large and the excitement so high that there are constant interruptions. So I often find myself turning back to the first person I was talking to only to find they've moved on. That's cool, but I hope they're not offended that our conversation got interrupted. If so, I am sorry.

And, I'm advised that some online resources that will help provide context around MMS activities are available. Microsoft has started to post podcast conversations and videos with Microsoft executives, customers and partners about the news and happenings of the event including updates with DSI, System Center and Infrastructure Optimization. This content will be refreshed all week here: http://www.microsoft.com/systemcenter/about/summit.aspx

 

Summary: I'm here at the conference and have registered. So here's a quick summary of the attendee swag bag, and other trivia. Spoiler alert: I go into a bit more detail than another rambling SMS engineer ;-)

So I'm here in San Diego, at the Omni. The trip was smooth, I've chatted with a few folks (mainly product team guys), gotten settled, and even registered (only speakers and staff can do so today). So the answer to the all important question ("is the swag bag worthy") is Yes. I think people will like it. It has wheels and an extendible drag-along handle. It might be a tad smaller than 2003 bag, but it's more briefcase oriented. There's a discrete Intel logo on the front side, and an almost equally discrete MMS 2007 logo on the back side. I've uploaded the first picture at the MMS swag bag wiki.

Inside there's a lot of inserts. My favorite is the System Center insert, which is quite substantial and reinforces the size of the suite. And another advertised myITforum, for those who have missed it so far. Otherwise, there's a good MOM (ok, SCOM) notepad, an Intel t-shirt, a System Center / MMS water bottle, and a bunch of demo CD's. Pretty good.

One of the inserts proudly announces MMS 2008 is in Vegas, which we knew. But did we know it would be April 28th to May 2nd? We do now.

The badge holder is a little simpler than most years, but I prefer that - it's less obtrusive.The pen that comes with it is small and designed to hang from a belt loop - different but could be handy.

So that's the exciting news from the first day.The even more exciting event for the day was the SMS Expert get together. The turnout was great (100 people?) and the provision of beverages and snacks was very generous. Most (or at least a large fraction) of the the old-timers were there (including Ed with a little red purse), and many new people. MANY great conversations occurred - lots of reminiscing, even more serious conversations, and some of the usual chatting. Well done SMS Expert!

Summary: we'll soon be at MMS 2007. Here's my advice for how to make the most of the event.

A recent good thread on the SMS mailing list at myITforum.com was entitled "MMS bound" and contained various bits of good advice.I was tempted to jump in, but decided to give it a bit more thought and make a blog of it.

There's lots that could be said, but these are my key points:

1. Know your goals for the week. What do you want to learn? What problems do you need help with? Do you want to look for jobs (sooner or later, via networking)? Do you want to increase your standing in the community? Do you need details on vendor solutions? What does the future hold? Or do you just want to socialize and have fun (nothing wrong with that)? Have a purpose, and pursue it.
   
2. Don't be shy. Sure we may be computer nerds, but we're all computer nerds, so you're amongst friends. So chat up everything that moves - you never know where it will lead. You might make a friend, you might get to share some wisdom, or the contact may lead to other conversations. That includes at meals, around the coffee dispensers, prior to or after sessions, etc. Don't worry if they're Microsoft guys or senior blah-blah-blah's. Say Hi, ask questions, share complaints, etc. See where it goes.
   
3. Remember that those that answer questions learn as much as those that ask them (if they're smart). So again, don't be shy. The speakers and other experts learn where the real pain points are by hearing your questions. They get inspired by different ways of thinking. Similarly, if you have an answer, and the opportunity is right, share it.
   
4. On the other hand, be courteous - read the body language, and use common sense. If the person is making moves like he has to go somewhere else, let him. Tempting as it may be, don't corner him in the washroom at 2 AM with your most challenging technical problems (that's happened to me twice over the years...).
   
5. Make the most of the days: show up to breakfast early, and stay until the late hours. It's all good. Even after the official activities, hang around a bit in the lobbies or other common areas (if you haven't already made arrangements) and see what's happening. With any luck you'll spot an acquintance, get an invitation to dinner or something, and get yet more opportunities to share.
   
6. Of course early mornings and late evenings may be contradictory, but that's where pacing comes in. Know your limits and your energy level, and act accordingly. I may not be the best example on this point, but I seriously don't think I've ever missed a minute of MMS that I shouldn't have missed.
   
7. Unless you really have to, don't bring the family or plan tourist events during the week. If you apply yourself, you won't have time for either.
   
8. Pack light and dress well. Convention areas are large wherever they are, so don't expect to make it back to your hotel room much. By packing light you keep yourself comfortable. By dressing well you're ready to go to a nice restaurant (hopefully at the invitation of a vendor, or with some well-paid consultants), or to make a good impression on some future employer (even if you're not looking now).
   
9. Come loaded with questions, and make notes. The opportunities are there to ask good questions, but they can be fleeting. And good ideas may come when you least expect them.
   
10. In San Diego, bring ear plugs! The trains run regularly through the downtown core all day, and so get a good night's sleep by tuning them out.
    
11. Show up early enough that you can get organized. Monday is a great chance to feel out the convention center, the town, your room, and the people. I always get in on Sunday afternoon.
    
12. When sharing business cards, write on the back what you want, or what you were asked for. You'll get a lot of them in the week, and that way you can follow-up properly.
    
13. Avoid your friends. This is a bit contradictory to some of the above, but's it's true - if you spend the whole week with your co-workers or old friends, how much will you learn? How much will your circle increase? Keep their cel number handy in case you run out of other options, but otherwise do your best to avoid them. OK, reality is that you should make a compromise between hanging out with old friends and new friends, but you know what I mean. And it's good for the community - we want newbies to feel equally welcome.
    
14. Grab good swag when you can. I've gotta do a post on swag, but think of it as gamer points. And there's never much of the good stuff. But be civilized about it.
    
15. Eat well. That's true for traveling generally, but some of us don't travel to much other than conventions. Keep well hydrated and eat as much fruits and vegetables as you can. By the end of the week you'll feel the difference.
    
16. Wear good shoes and use a good pack. You'll travel a lot of distance in a day - a lot more than your usual days in front of a monitor. So take care of your body.
    
17. Have fun! You've earned it with all your hard work, and you'll make the best contacts when 'showing a bit of personality'.

 

Summary: combining SQL Server query results and vbscript is a powerful tool, and well documented. But what if you want SQL Server error messages returned to your vbscript? For example, if you want to automate your DBCC CHECKDB tasks.

One of the joys of my job is that I learn something new pretty much every day. As I've mentioned in previous blog postings, I do a lot of SQL scripts these days, but I still find that I need vbscript on a regular basis, and often that means combining the two. By using vbscript to process the results of my SQL scripts, I can have the best of both worlds - the speed of SQL scripts, but the logic and formatting of vbscript. Today I needed to do that, but rather than getting the usual column and row data from my SQL Server queries into vbscript, I needed the error messages.

In particular I wanted to run DBCC CHECKDB on a bunch of servers. CHECKDB produces a lot of output even when everything is good, so I wanted to direct that output to the vbscript and let the script tell me the 'interesting bits'. The vbscript makes it easy (even if time consuming) to do the CHECKDB on lots of servers, and the logic in the script means I don't have wade through LOTS of output - the script does that work. And why do I want to check lots of servers? Well, as I've often said in various forums, when I see a problem, I almost always ask myself whether I don't have the same problem elsewhere, or whether I won't have it again in the future. A script makes it easy to check both (many servers, any time). (And of course we do have other teams within my IT department who do CHECKDB checks on a regular basis (pretty much daily), and they do a great job of that, but there are times when I like to see the results for myself).

Before we get to the trick for returning SQL Server error messages, maybe I should explain how I normally return SQL Server query results (data) to vbscript. I encourage you to do your favorite Internet search for full details (which means live.com, of course). I use what works for me, but I don't guarantee that my way is necessarily the best way. To start with, I connect to the SQL Server:

Const adOpenStatic = 3
Const adUseClient = 3
Set objConn = WScript.CreateObject("ADODB.Connection")
Set objRS = WScript.CreateObject("ADODB.Recordset")
objConn.CommandTimeout =300
strConn = "Provider=SQLOLEDB.1;Trusted_Connection=yes;Initial Catalog=SMS_" & sitecode & ";Data Source=" & siteserver
objConn.Open strConn    
objRS.CursorLocation = adUseClient 
objRS.ActiveConnection = objConn  
objRS.CursorType = adOpenStatic 

That part is pretty much the same in all my scripts. Then we need to run the query and return the results:

query = "Select SiteCode from v_Site"
objRS.Source = query
objRS.Open
if objRS.RecordCount>0 then
    For iRow = objRS.AbsolutePosition to objRS.RecordCount
         wscript.echo "site: " & objRS.Fields(0).value
         objRS.MoveNext
    Next
end if

That part is going to have a different query each time, of course, may return multiple columns (Fields), and will have some logic to do something with the data (beyond wscript.echo). And I might add more error handling if I fear my servers may be down, etc.

I finish it off by closing the objects:

objRS.Close
objConn.Close

That's not too tricky. I could accomplish much the same thing in fewer lines using WMI, and sometimes I do that. But WMI will be significantly slower for large data sets.

Ok, so how do we return the SQL Server error messages, instead of data? Well, it turns out the core of the trick is this line:

set SQLerrors = objConn.errors

So:

query = "dbcc checkdb"
objRS.Source = query
objRS.Open
set SQLerrors = objConn.errors
for each SQLerror in SQLerrors
     wscript.echo SQLerror
next

Not really tricky at all, except that it is not nearly as commonly documented on the web. You'll want to add your own logic for formatting or parsing the errors, but otherwise it's as simple as that.

p.s. As always, when doing a large read-only query, be sure to prevent locking. I do that by preceding my queries with: set transaction isolation level read uncommitted. In vbscript, I'll append that with a "vbCRLF" and then add my main query to it.
 

Summary: how do you know if your computer management operations are as good as they should be? There are plenty of options, but I have one that I want to advocate.

Does everyone know the mine in the canary story? The idea is that in mines one of the big hazzards is noxious gases of various sorts. Small birds are particularly susceptible to the bad gases, so if the small bird (canary) falls off its perch, then it's time to get out of the mine. Do you have a similar early warning system for computer management?

We hired a new senior operations manager recently (not surprising, since Microsoft, like many other companies, reorganizes about every 6 months or so). He was kind enough to listen to my 'hidden agendas', and so I was thinking about how I would articulate my perspective. I shared various points, but a key one was that he should ask about our security. Nothing complicated -  just simple questions: where's the latest security report? who has access to what? who are those people? Who is responsible for security reviews? What is their opinion of the latest security options? Stuff like that.

We have answers to those questions, and I won't go into those here. They're not entirely bad answers, but are they as good as they should be? More to the point, how readily are the questions answered? My suggestion is that if your organization is well run then the answers to those questions will be very 'matter of fact'. Of course the reports are at URL X. Of course we know who those people are. Should security be tighter? - to me that's the next level of security review.

Similar questions could be asked of similar operational issues - monitoring, SLA reprorting, operational reports, backup/recovery readiness, etc.But security is less immediate - everyone cares about it above all else when something goes wrong, but most of the time securty is not an issue. So it's easy to push it off to tomorrow. That's OK if it's litterally tomorrow, but if you find that a year later tomorrow is still imminent then you have to ask whether your operations are as good as they should be.

So if your latest list of who has access to what in your computer manangement system is 6 months old, then maybe your canary is dead.

BTW - for the hackers amongst my innumerable readers (yeah, right), I don't want to encourage you - Microsoft IT is very thorough about perimeter security, operating system level security, patching, SQL Server level security, etc. So it's not as if the SMS servers are a playground for hackers. But that doesn't mean we don't need improvements.

p.s. While we're chatting, I'll mention that I upgraded my nearly 3 year old Media Center Vista machine to Vista Ultimate today. In those 3 years I upgraded the video card and memory a bit but basically it's what it was back then. Much to my surprise (as an old techie) this upgrade went VERY smoothly. I expected to be struggling with device driver issues, etc. but much to my pleasant surprise (despite working at Microsoft), it is performing wonderfully tonight. So I've got Vista coolness and security at minimal effort. I know that's the way it's supposed to be, but I've done enough upgrades over the years that I know that upgrading older machines with lots of apps is asking for problems. Of course YMMV. And I'm not hear to sell you Vista. But I find it's the negative stories that most often get reported, so when I have a positive one I think it's fair to share it.

Summary: if you're using SMS on a substantial scale or with slower servers, you'll eventually need to do SMS performance analysis. How do you use PerfMon to understand SMS component performance?

Today I had a performance problem on a site server and I suspected that SMS was at the root of the issue. Hopefully you don't have that problem very often (I was working with v4 Beta 2 with 25,000 clients on that site (how many people have that pleasure?...), and we try really hard to eliminate such problems before the product gets to you).But sooner or later you may have such problems, if only because you've misconfigured things (hardware inventory every hour for 3000 clients could do it), or the server is a little dated, or something really did get by us (including the very professional testers in the SMS product group) - hey, it happens.

SMS performance analysis can involve many elements, which I should probably blog about sometime. SQL Server performance is obvious enough. Workload, as represented by your inbox backlogs. General operating system performance or hardware performance. But let's assume you've done all that and things look good and so you assume SMS has to be at the root of the problem.

So you do some Performance Monitor analysis and see that SMS Executive is working VERY hard. But what part of SMS is causing the pain? It's easy enough to to add all the threads for the SMS Executive into your PerfMon analysis. And we know that the threads correspond to SMS "components" (data loader, replication manager, collection evaluator, the senders, etc., etc.). There's easily 50 of them. But PerfMon gives you instance IDs, not component names. So you see one thread going nuts, but you have no clue as to which component it is.

My first little trick is to use an old tool called QSlice.exe. it will show you all process's CPU consumption in a graphical manner. You can double-click on any of them and then see the same thing in a seperate window for all the threads of the process (meaning for the SMS components!). That's a lot easier to watch than PerfMon. And you get both the instance number and the thread ID (in hex format).If you're not used to using QSlice, you're probably asking where you can get it. And Richard Threlkeld of 1E has the answer: it’s part of the Win2K Resource Kit:http://www.microsoft.com/downloads/details.aspx?familyid=6247BB76-13C5-4E0E-B800-53DC1B84A94C&displaylang=en. Thanks Richard!

What I'm really getting at today is that we need a means to translate thread instance numbers, and/or thread IDs, into SMS component names. How's that for SMS trivia? Well, if you've played around with the SMS performance counters, you will have seen that there's a counter for the SMS Executive thread states. It gives you the states (which is mostly "running") but more importantly it gives you the component names and instance numbers for each of the thread instances. Exactly what we need.

So how do we do this from script, so we don't have to be grawking through obscure corners of perfmon output? Well, just connect to WMI on the site server, get the thread states, as so: 

Set Threads = GetObject("winmgmts:{impersonationLevel=impersonate}!root/perfmon").InstancesOf( "SMSThreadStates" )

and then enumerate through them, parsing the ThreadIDName. But before you do that, you'll have to define the "SMSThreadStates" WMI class, which is done by MOFcomping the following:

#pragma namespace("\\\\.\\root")
instance of __Namespace
{
  Name = "perfmon";
};

#pragma namespace("//./root/perfmon")
instance of __Win32Provider as $PMPInst
{
  Name = "PerfProv";
  ClsId = "{f00b4404-f8f1-11ce-a5b6-00aa00680c3f}";
}; 

instance of __InstanceProviderRegistration
{
  Provider = "__Win32Provider.Name=\"PerfProv\"";
  SupportsPut = FALSE;
  SupportsGet = TRUE;
  SupportsDelete = FALSE;
  SupportsEnumeration = TRUE;
};
 
[dynamic, provider("PerfProv"), ClassContext("local|SMS Executive Thread States")]
class SMSThreadStates
{
  [key]
    String ThreadIDnName;
  [PropertyContext("Running Thread Count")]
    uint32 RunningThreads;
};

For bonus points, you can translate thread instance numbers into thread IDs (including in hex) by using the Threads perfmon class.

Clear as mud? OK, maybe this blog is not as 'user-friendly' as it could be. Post comments if you want more details. I'll have to check on the rules for posting full .MOF's and scripts. And from my tech writing days I do know how to write a good procedure. But in blog format I didn't really have space for all of that, so I hope you'll forgive this medium-level approach.