O R G A N I C / F E R T I L I Z E R: 05.06

May 31, 2006

mom: why do agents still send alerts in maintenance mode?

the mom product team was kind enough to (finally) remove all mystery in this blog post regarding why agents continue to send alerts even after you’ve flagged it for maintenance. In summary:

  • management server and database updated immediately
  • server-side responses stop
  • suspended agent initiates configuration update cycle
  • agent receives update that it is in maintenance mode

same process is true when an agent is taken out of maintenance mode.

May 24, 2006

mom: that book is finally on the shelf...

if you missed it, the book professional mom 2005, sms and wsus is finally on the shelf. i'm still waiting on my complimentary copy so i'm not sure whether or not my name is actually on it. i don't think they put my picture on it. i can only guess that it would have made the other authors look terrible in contrast. just kidding... i don't know why and am not going to speculate (doubt that'll stop you though). i contributed about four chapters to it. if you happen to read it, take a guess at which are mine... i'd be curious to know if there's a visible difference in writing style from author to author or if the editors really are gods. by the way, pete, one of the guys at momresources.org, was kind enough to write up a book review.

May 16, 2006

mom: monitoring dns synthetically...

update: this script has been rewritten.  please refer to this post.


background. let me start off by posing a question. have you looked at the dns mp? look closely. there are no synthetic tests. why is it that management packs like these are service-centric?

my dns service hums right along... yet problems exist.  i'm not going to expatiate on the necessity of needing transaction-based monitoring. there are whole companies built around this philosophy. it does seem troubling to me though that the cornerstone of active directory is a healthy dns... yet the dns mp contains no such necessary rule. anyway, enough about that.

foreground. i wrote a script to monitor dns. it doesn't monitor the health or catch events. you've already got all that. it simply runs a nslookup command for a list of hostnames and returns errors, if there are any. it lacks any elegance or sophistication (not that you're used to that in my scripts). maybe you noticed. maybe you didn't.

i stated above that it issues nslookup commands. you may be thinking, why nslookup when you could query records through wmi? well, simple... that'd be too easy. seriously, the reason is that there was a time in the past where the dns service hung (no, mom didn't catch that either). i couldn't query anything with nslookup. however, issuing commands against wmi still continued to work. hmmmm. i guess for that reason i'm a little leery about using wmi. besides, using nslookup seems like it more closely resembles what someone might be doing. i would prefer dig, but nslookup seems quite ubiquitous in the windows world. the script has two parameters you'll need to setup:

  • HostNames - accepts a comma-delimited list of hosts to query
  • LogSuccessEvent - boolean value to log on success
should be self-explanatory. "DNS Synthetic Script" is the source. these are the event id values to pick up in any cooresponding alert rule:
  • 41000 - no hostnames defined
  • 41001 - lookup failed for
  • 41002 - successfully looked up
get the script here: i've posted the script at the other two locations. sooner or later they'll post them.

May 11, 2006

ds: how to setup mail forwarding without a contact object

hmmm, you say... never saw that before. neither had i. every reference i could locate about this topic directed me to setup a contact object to forward to. however, the talented messaging guys i work with came up with a different process. i thought i'd share it for the good of humanity. alright, so let's say you find yourself in a situation where someone leaves the company and wants [his/her] mail forwarded. here's the process you would take to make this work:
  1. gather these fields. take down this information. step 2 will blow it away.
    • mail
    • mailNickname
    • proxyAddresses primary)
  2. disconnect [his/her] mailbox.
  3. put these fields back in for the user object.
    • mail
    • mailNickname
    • proxyAddresses (primary from step 1)
    • proxyAddresses (secondary - the email address to forward to)
    • targetAddress (the email address to forward to)
whenever an email comes in for [him/her], the email will forward to the new address. to elaborate a little on the above steps, the primary address has a capitalized "SMTP:" where as all secondaries has a lowercase "smtp:". if the user is Ima Seeyanya and their old address is ima.seeyanya@olddomain.com and their new address is ima_seeyanya@forwarding.com, the values would fill in as such:
  • proxyAddresses: SMTP:ima.seeyanya@olddomain.com
  • proxyAddresses: smtp:ima.seeyanya@forwarding.com
  • targetAddress: SMTP:ima.seeyanya@forwarding.com
things to note: retaining mailNickname will let users continue to resolve the email address with this method. this method does not remove the user from any distribution lists [he/she] belongs to.

misc: multi-valued attributes and setinfo

it's a great moment when you come to understand something. understanding that you understand something at the wrong moment, however, is a point for debate. while i'm happy for the understanding, i wish it had come sooner. wrong moment by my logic is anytime you're knee-deep in a production change and "understand". :-] understanding how setinfo works with multi-valued attributes is really pretty simple. i'll blame it on "inadequate testing". to pontificate on this tidbit, if you're adding multiple email addresses, say to proxyAddresses, you can't queue up the changes and write them with one setinfo command. instead, you have to write one, commit, append another, commit, etc.

May 3, 2006

mom: resolveguid is a such a task!

isn't it though? none of the agents come configured with resolveguid set. all of this has to be done post installation, post agent rollout. there's no command-line tool or built-in task to simplify this process. at the request of one of the management mvps, i wrote a script to use as a mom task.

the background: by default, when security events are picked up, the sids/guids are not resolved. if you're into resolving them manually, you're set (or manic or crazy or [insert favorite word for getting institutionalized]). otherwise, using the resolveguid registry key will automatically resolve the sids/guids. microsoft published an article about it. if you want the more (frenetic) information with a canadian sense of humor, rory has blogged ad nauseum on this topic.

the foreground: i've linked to the script at the end of this blog. all you need to do is go to one of them, copy the contents into the clipboard and create a new script in mom. i used these parameters for the mom script properties:

  • name: [clever, easily identifiable name]
  • description: adds resolveguid registry key to mom agent
  • language: vbscript
  • script: [paste script here]
  • parameters: none
alright, now the first part is done. navigate to the tasks section. i created a new task under microsoft operations manager because this seemed to make the most sense. the script doesn't stop/start the mom agent after the key is added (even though its required in order to take effect). i figured they're probably things that should happen separately, at the discretion of some type of maintenance window. at any rate, the other tasks are located here for stop/start. anyway, wherever you feel comfortable...
  • run location: agent-managed computer
  • task type: script
  • target role: mom agent
  • script to run: [clever, easily identifiable name of your script above]
  • parameter default values: [none]
now to execute, open the operator console (or console refresh), the task will be available under microsoft operations manager. you can select multiple agents at once (up to 50) and run it. i've posted the script on a few of my favorite resources (momresources.org and myitforum.com) if you want to grab it. comments, rewrites, markups, whatever... always welcome. i'm no scripting guru.

May 1, 2006

rod trent at mms

poor guy didn't get to enjoy mms like most everyone else did. in one of his blog posts from mms, apparently rod suffered from extremely high blood pressure. he's a fixture of the systems management community and has been an advocate for products like SMS for longer than i've been working with this technology. (remember swynk?) if you have an opportunity, check in to see how he's doing and encourage him to get better! :)