sms: sms 2003 sp2 schema extension

so you ran the schema extension you say, and it ran so fast that you didn't notice it had finished? if you're upgrading from SMS 2003 to SP2, the included schema "extension" doesn't do very much at all. in fact, from a practical standpoint, nothing is extended. an existing attribute is linked to an existing class. if you're a sms administrator and can't convince your ad administrators to run it, just show them this. here's a log of a proper run:

<03-30-2006> Modifying Active Directory Schema - with SMS extensions.
<03-30-2006> DS Root:CN=Schema,CN=Configuration,DC=bladerunner,DC=int
<03-30-2006> Attribute cn=MS-SMS-Site-Code already exists.
<03-30-2006> Attribute cn=mS-SMS-Assignment-Site-Code already exists.
<03-30-2006> Attribute cn=MS-SMS-Site-Boundaries already exists.
<03-30-2006> Attribute cn=MS-SMS-Roaming-Boundaries already exists.
<03-30-2006> Attribute cn=MS-SMS-Default-MP already exists.
<03-30-2006> Attribute cn=mS-SMS-Device-Management-Point already exists.
<03-30-2006> Attribute cn=MS-SMS-MP-Name already exists.
<03-30-2006> Attribute cn=MS-SMS-MP-Address already exists.
<03-30-2006> Attribute cn=MS-SMS-Ranged-IP-Low already exists.
<03-30-2006> Attribute cn=MS-SMS-Ranged-IP-High already exists.
<03-30-2006> Class cn=MS-SMS-Management-Point already exists.
<03-30-2006> Located LDAP://cn=MS-SMS-Management-Point,CN=Schema,CN=Configuration,DC=bladerunner,DC=int.
<03-30-2006> Successfully updated class LDAP://cn=MS-SMS-Management-Point,CN=Schema,CN=Configuration,DC=bladerunner,DC=int.
<03-30-2006> Class cn=MS-SMS-Server-Locator-Point already exists.
<03-30-2006> Class cn=MS-SMS-Site already exists.
<03-30-2006> Class cn=MS-SMS-Roaming-Boundary-Range already exists.
<03-30-2006> Successfully extended the Active Directory schema.

i've marked the relevant lines you need to look for in your schema log. you can check this manually too with the active directory schema snap in (schmmgmt.msc). under classes, locate mSSMSManagementPoint. take a look at the optional attributes. you should see dNSHostName now.

mom: graphing performance in the operator console

well, i've had more than a few requests on how to do this. i thought it'd be helpful to share and have a convenient link to send for anyone else that doesn't know how to do it. everyone knows that you can graph performance data in the mom 2005 operator console, but how do you do it longer than the default of two hours (or whatever is specified)? let's take a look at the performance data view "free megabytes". it's located under microsoft windows server base os/performance/logical disk. this is all you have to do.

1. on free megabytes (left pane), right-click and choose properties.
2. the first tab of this window is "criteria". click the measured in specified time period.
3. click the link in the lower window and specify the time frame for the graph you want.
4. click ok.
5. choose the items you want to include.
6. select draw graph.

now you have a graph of data in a longer time range.

mom: heartbeat management

steve wrote up a good article on the entire heartbeat procedure. if you have questions on how this works, make sure to give this a read... :)

mom: useless exchange rule

remember this rule? exchange availability report is dependent on the script generating 9980 events. well, i finally shut it off. i have 500,000 events in my production database right now. i figured if my database is grooming at 4 days, then the calculations would stand to this reason:

1. 4 days = 500,000 events; therefore, the production database is storing 125,000 of these a day.
2. 125,000 * 60 = 7,500,000 since the mom warehouse stores 60 days (61 actually... but who's counting?)

now, assuming all has been going well, the corollary philosophy here is that i am not actually losing any data for availability. why? well, first of all, the exchange availability report that comes from the exchange mp was a monster to run. clearly, you can see why. second, the availibility report that comes from the availability reporting mp doesn't even use 9980. it uses 1001 (and some other stuff, but 1001 for the purpose of exchange). with availability reporting and sla scorecard in place, i'm not going to worry about losing 9980s.

mom: manual agent installations and command-line switches...

if you're looking for the command-line switches for the mom agent installation, look here. oh, by the way, if you're looking for the updated agent, it's in this path: (on the mom server) c:\Program Files\Microsoft Operations Manager 2005\x86. all you should need is the momagent.msi.

mom: monitoring organizationalUnit changes...

i've lost a lot of hair today. why? mom is finicky and aggravating. i'll get to that later. here's how to setup rules to pickup event id 566. it's comprised of two rules: collection and event. first of all, why create a collection event? it's simple. if you only create an event to pick up the alert, you don't necessarily hold all the parameters that you want. if you want to go look for this later, it may be challenging if you're scavenging alerts faster than events. set it up like this:

• source: security
• event id: 566
• type: success audit
• description: contains substring organizationalUnit
• parameters: 3,4,9,12

i'm not going to advocate collecting all the event parameters. it's probably safe with the description filter but saw some come in with some wild parameter counts (in the mid 100's). now, you will pick up events that you probably didn't mean to, like user accounts getting created/deleted under an OU. anyway, the parameters i chose, map to these fields:

• parameter 3: object type
• parameter 4: object name
• parameter 9: user name
• parameter 12: access

alright, now create an event rule with these criterion:

• source: security
• event id: 566
• type: success audit
• description: contains substring organizationalUnit

on the alert tab, modify the description to look like this:

Directory Service change occurred for: Object: $Parameter 3$ User : $Parameter 9$ Action: $Parameter 12$ Change: $Parameter 4$

why? if you let the description field come in to the alert, it's just ugly. no one wants to read it like that. by the way, the parameters won't mean much to you without making this modification to configure the mom agent to resolve the guids it collects in events to friendly names. obviously, you're picking up these events on your domain controllers. yes... that means making this registry change on all of them. this thing took about 4 hours to figure out. many thanks to those i frequently communicate with on msmom@lists.listleague.com. anyway, here's the thing... even though you're picking up the parameters, for some reason, mom will not filter the parameter field (in this case, i was filtering for parameter 3 contains substring organizationalUnit). i don't know why this is. another one of those irritating quirks... anyway, description finally picked it up as it was supposed to happen.

ds: dsacls is driving me crazy!

here's a little background. i'm trying to delegate permissions for create/delete computer objects on a given ou. i get back this nonsensical response on a command i know i've issued before but can't seem to make it work! seen this before? here's the command: dsacls "OU=Computers,OU=General,DC=Company,DC=com" /G "Company\SupportGuy:CCDC;Computer" this is the response:

No GUID Found for Computer The parameter is incorrect. The command failed to complete successfully.

apparently case does matter in some cases (intended). capitalizing Computer causes the output to fail. why? i guess dsacls is case sensitive. it's looking for an object called Computer. switching it to lowercase computer works just fine.

mom: upgrading to sql 2005

have you upgraded to sql 2005? why not? alright, i haven't either but do have a legitimate excuse. i was waiting on three hotfixes to be published. mom 2005 sp1 is not compatible with sql 2005 (operations and reporting database) without these three hotfixes. kb913812, unable to discover computers in ad after upgrading to .net framework 2.0 kb915785, errors can occur when data collected by mom 2005 sp1 is queried with sql server 2005 reporting services kb913801, deadlocks may occur on sql 2005 (some of these are not yet accessible.)

mom: availability reporting doesn't generate reports

in case you missed it, justin harter posted a fix on his blog for the availability management pack which, out of the box, does not generate any reports. click the link above to check it out.

os: wmidiag tool finally posted!

what was once a trivial thing to understand has become an edifice for systems management in the windows space. back when i started learning sms, wmi was completely foreign. it was used primarily to hold configuration data here and there, acting as a mini-database and largely untapped by most software vendors at the time. since its popularity has grown, so has the usage. this is largely ostensible without spinning up wbemtest, opening cim studio, or constructing a single wmi query. if your repository corrupts, there is absolutely no recommendations at this point to remove all items from the wbem repository directory and allow wmi to recover. the ubiquitous usage almost guarantees something will break. i suppose for that reason, wmidiag was born. download it and get to know it. while you're at it, attend the webcast if you can. alain lissoir himself is presenting... content should be great.

sms: addressing wmi corruption...

i picked up this tidbit from jeff gilbert on the sms mailing list. anyway, there are a few ways to address this if the os of the affect client is windows xp or windows 2003 or greater. here's what he had to say on the matter:

There is help for XP SP1-SP2 and Server 2003, SP1 systems to diagnose and repair WMI corruption: To check the WMI repository for errors on a Server 2003 SP1 system, run the following command from command prompt:

• rundll32 wbemupgd, CheckWMISetup

Once you've run that command, check the setup.log file located at: %windir%\System32\Wbem\Logs\Setup.log. Check for entries from today's date. If you find none, then WMI is probably OK and you should continue troubleshooting somewhere else. If however, you see an error message from today saying that it can't find a namespace then yes, your WMI repository does have issues and you should do the below:

• rundll32 wbemupgd, RepairWMISetup

This will re-create your WMI repository minus any custom .mof additions that were implemented without the -autorecover switch. For Windows XP SP2, use the following command to check for corruption, and repair if necessary:

• rundll32 wbemgupgd, UpgradeRepository

For Windows XP SP1, the check and repair commands are below and function just like the Windows Server 2003, SP1 commands:

• rundll32 wbemupgd, CheckWMISetup
• rundll32 wbemupgd, RepairWMISetup

These are the commands I personally use to try to troubleshoot WMI corruptions. Hopefully they can help you too. Remember to always check that setup.log (%windir%\System32\Wbem\Logs\Setup.log) to see what is going on, and remember that any mof additions compiled without the -autorecover switch will be lost whenever you rebuild your WMI repository!

just keep in mind... the commands above do have a space after the comma. it IS required.