filtering out the noise in scom

I’ve decided to tackle SCOM 2012 at my new employer.  It was installed by a previous SysAdmin but basically left out of the box with ALL alerts on EVERYTHING constantly spamming the inboxes of the rest of the team.  I am very sick of these emails.

SCOM is interesting in that by default you really do get alerts for everything.  Even stupid crap you don’t care about like an occasional spike in CPU usage or some service configured with the SYSTEM account or disk latency warnings in the middle of the night during backups.  I have zero experience with SCOM but I can already tell you this is going to be one hell of a love/hate relationship.  I found one article that has already GREATLY helped in reducing the amount of notifications.

SCOM has three severity levels for the alerts included in Management Packs: Information, Warning, and Critical.  It also has three priority levels:  Low, Medium, and High.  Each alert is assigned a priority level and most alerts, unless they are REALLY bad, are assigned medium out of the box in MP’s.  Stuff like a system down though will have be a Critical/High alert by default.  What you can do is create a subscription for only High priority Critical alerts and this will right away reduce the noise from SCOM.  You can then use the SCOM console to see all alerts and tweak individual alerts by adding an override to change the priority to High if it’s something you want to be notified on.  More to come as I play around with SCOM more but make sure you check out the article by Kevin Holman to get started.

rhel6 installing bind-chroot

Oh Red Hat, sometimes I don’t get you.  So it seems the “recommended” way of installing BIND on RHEL6 is now to just install normally (e.g. “yum install bind”) and let SELinux handle the security.  My beef with this is how frustrating SELinux can be.  Honestly every time I have to troubleshoot an issue with it I’m down at least two hours of my time and it just isn’t worth it to me.  Maybe I’m SELinux retarded but this has always been my experience with it so I usually just end up disabling.

RHEL6 still includes a package in the repository for bind-chroot thankfully.  However, it seems that now when you start named Red Hat does some voodoo by mounting all the normal bind directories and files on the chroot jail directories and files.  Very weird, here’s what I mean:

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

/etc/named on /var/named/chroot/etc/named type none (rw,bind)

/var/named on /var/named/chroot/var/named type none (rw,bind)

/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind)

/etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind)

/etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind)

/usr/lib64/bind on /var/named/chroot/usr/lib64/bind type none (rw,bind)

/etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind)

/etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind)

I’m guessing that it was too confusing for people having the symlinks and not knowing which files to edit?  At any rate it was definitely different.  So in RHEL6 just remember to edit /etc/named.conf now and then when you start/restart named your new config will actually be in the jail (e.g. /var/named/chroot/etc/named.conf).

The main issue I ran into bind-chroot on RHEL6.2 is that it was sorted of a busted install.  During install the rndc.key file was not generated even though the documentation says it should be.  So if after running yum install bind-chroot and you do not have /etc/rndc.key you need to create it manually:

rndc-confgen -a

chown root:named /etc/rndc.key

chmod 640 /etc/rndc.key

Despite Red Hat’s documentation, the key file actually needs 640 with named as the group or named will not start due to a permissions error.

Also if you are using bind-chroot make sure you disable SELinux by editing /etc/sysconfig/selinux and then rebooting.

error registering for password reset in fim

If you are just getting password reset implemented with FIM 2010 and your client gets ”An error was encountered.  Please call helpdesk or your system administrator for further assistance.” try the following:

  1. Download the PSTools bundle from http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
  2. Extract PsExec.exe to your C:\ drive
  3. Open a command prompt as administrator and enter “cd c:"
  4. Now enter “psexec.exe -s -d -i cmd.exe”
  5. A new command prompt window should open.  Now enter “mmc.exe”.
  6. Go to File -> Add/Remove Snap-ins
  7. Select Certificates on the left and click the “Add >” button in the middle
  8. Select “Computer Account” from the window that pops up, then Next, and then select “Local computer” and hit Finish
  9. Hit Ok and you should be taken to the MMC window
  10. Expand Certificates on the left, then expand Personal, and finally click on Certificates under Personal
  11. Right click on the “ForefrontIdentityManager” certificate and choose “All tasks” then “Manage Private Keys…”
  12. Click add and enter the name of the account running as the service account for the FIM Service
  13. Make sure “Read” is checked under Allow and hit OK

This apparently is a known bug with build 4.0.2592.0 (current version as of this writing).  Supposedly it will be fixed in Update 1 which does not have a street date just yet.