Downloads

Disclaimer: Any code or scripts linked on this page (or this blog) are provided as-is, with no warranty of support or function.  Be sure to test thoroughly in a non-production environment before deploying.   I do make all reasonable attempts to test prior to posting code, and as time permits, I will attempt to provide some support if problems are found.  

Downloads

  1. LocalPortMonitor.zip – A vbs script (as a .txt file) for use in a SCOM unit monitor to locally check the status of a listening TCP port.  Described here.
  2. WSHCheck.zip – A vbs script (as a .txt file) for use in a SCOM unit monitor to check the WSH version on 32-bit Windows agents.  Described here.
  3. PutNodeInPatchMaint.zip - A powershell script to put nodes (and clusters, if applicable) in maintenance mode.  Described here.
  4. DocumentMPs.zip – A powershell script to document unsealed management packs by outputting MP entities to a formatted html file.  Described here.
  5. ListUsers2.zip – A powershell script to recursively list the members of a specified group to the defined recursion depth.  Initially descriped here.  Updates described here.
  6. WebMon.zip – A SCOM 2007 R2 management pack for monitoring of multiple websites controlled by a configuration file.   Described here.
  7. EventLogSearch.zip – A simple Windows Forms application for searching events in a local or remote eventlog, including search by description.  Described here.
  8. CiscoSNMP_R2_v1.0.2.7.zip - Version 1.0.2 of the Cisco Managment Pack for OpsMgr 2007 R2.  Described here and here.  (This has been replaced by the xSNMP Management Packs).
  9. Net-SNMP_v1.01.zip – Version 1.0.1 of the Net-SNMP UNIX/Linx Management Packs.  Described here.
  10. CiscoSNMP_SP1_v1.0.2.7.zip - Version 1.0.2 of the Cisco Managment Pack for OpsMgr 2007 SP1.  Described here.
  11. WSSBackup.zip – A VBS script for automating WSS 3.0 backups and an OpsMgr 2007 Management Pack to schedule and monitor the script.  Described here.
  12. xSNMP Management Pack Suite – Version 1.0.8 (Beta) of the xSNMP Management Pack Suite, introduced here.
  13. UNIX.Custom MP - Example SCOM 2007 R2 management pack for monitoring Defunct/Zombie processes on UNIX/Linux systems.  Described here.

22 Responses

  1. Script_newb, on September 16th, 2009 at 4:53 pm Said:

    When running the listUsers PS script, I do not get enumeration of any nested groups of the group I’m running the script against.

    The output lists all the user accounts in the group, but no nested groups.

    Any help is appreciated.

    Thanks.

    Reply
    • Kristopher Bash, on September 16th, 2009 at 7:52 pm Said:

      Just to be sure, what are you inputting as the MaxDepth parameter when you run the script?
      The intended command line usage is: powershell.exe c:\scripts\listusers.ps1 \
      Where is the number of nested levels to recurse.

      Reply
  2. Script_newb, on September 17th, 2009 at 12:50 pm Said:

    I fire up PS, change to the directory where I have the script.
    I then run the following command.

    ./listusers.ps1 domain\group name 3 (substitute domain\group with the actual domain and group name) then add the number 3 to recurse down 3 levels of nested groups.

    It does not matter what number I have as the MaxDepth parameter. The end result is that I only get the user accounts that are in the group listed, no nested groups or their members.

    If I run the script against a group that contains only nested groups, I get no recursion at all and the output is empty aside form the date/ time and target group name.

    Thanks again for the help.

    Reply
  3. Script_newb, on September 18th, 2009 at 12:11 pm Said:

    Update.

    After more digging around I have found that the script executes correctly and recurse through all nested groups if the target group is located in the default
    AD Users Container.

    If however the group is in another OU, lets say and OU for a site office, the enumeration of the nested groups does not occur. In this case, only the members of the group are listed and the nested groups are not.

    I’m not sure if this has to do with the way that the script calls the path to search in AD.

    I see the script is using and ADSI call. I’m not sure if making an LDAP call would resolve this problem as I am no scripting guru.

    Reply
  4. Script_newb, on September 23rd, 2009 at 12:30 pm Said:

    Hi Kristopher

    Any update on a possible fix?

    Thanks.

    Reply
    • Kristopher Bash, on September 23rd, 2009 at 6:38 pm Said:

      Yes, I’ve pretty much got it worked out, but I need to finalize and clean up the script. To pull both local and domain group members (in non-default OU’s), I had to use both WinNT:// and LDAP:// ADSI queries.

      Reply
  5. Script_newb, on September 24th, 2009 at 8:56 am Said:

    Awesome.

    I look forward to the revised version.

    Reply
    • Kristopher Bash, on September 25th, 2009 at 12:49 pm Said:

      Want to give this version a try? http://cid-7fd733e2738cc589.skydrive.live.com/self.aspx/.Public/files/Testing/listusers.zip

      This version implements ADSI searching to suport groups that are in OU’s outside of the default locations. A few things to note:
      1) The syntax is the same: powershell C:\\listusers.ps1 DOMAIN_or_Machine\GroupName MaxDepth. If the group name has spaces in it, the Domain\Group string should be wrapped in quotes.
      2) If the script returns no users for a group, it is probably because the current user doesn’t have rights to
      access the group properties. This is likely to happen with the forest enterprise admins group if a forest root domain model is used
      3) If a domain group is specified as the starting point, the script should be run on a machine in that domain 4) Traversing trusting domains should work, as long as the current user context has the appropriate rights. However, if the starting point is a local group and the local group contains domain groups from multiple domains, only the groups in the current domain context will be found with ADSI queries and use the LDAP:// provider. The groups from the other domain(s) will use the WinNT:// provider and be limited to only groups within the default location. The reason for this is that the local group is enumerated with the WinNT:// provider, and the member objects can’t be easily mapped to an LDAP ADS path. This doesn’t apply once the script gets to the domain group level, because it should be using LDAP:// queries and be able to lookup the proper LDAP path to the trusting domain group.

      Reply
  13. Jesse, on October 14th, 2009 at 5:56 pm Said:

    hey man, I just downloaded the CISCO SNMP SP1 MP for SCOM…. great work! This is exactly what I’ve been looking for to monitor the plethora of switches I have here.

    Keep up the great work!

    Reply
  15. Will, on December 4th, 2009 at 12:11 pm Said:

    Just tried to import the Webmon manage pack to Scom 2007 SP1 and get this error:

    [Line: 1728, Position: 8]
    The element ‘Overrides’ has invalid child element ‘SecureReferenceOverride’.

    Webmon looks like it will be useful for larger volumes of URL checks so if any ideas on that error that would be appreciated. (I imported the SP1 XML file not the R2 one – as we don’t have R2 yet).

    Reply

Leave a Reply