Search This Blog

Tuesday, August 18, 2015

Finding a DNS Zone Creation Date

Not SCOM related, but this is pretty much the only place I dump things I need to remember, and maybe you'll find it useful.

Was in my Windows Server DNS console this morning and I noticed some odd domains listed. I don't remember seeing them before and wanted to see when they were created, to make sure folks weren't randomly adding new zones.

  • Fire up adsiedit.msc on a domain controller.
  • Choose Connect to
  • Under Connection Point, choose Select or type a Distinguished Name or Naming Context
  • Enter DC=DomainDnsZones,DC=<second level DNS>,DC=<top level DNS>
    • E.G. dc=DomainDnsZones,DC=contoso,DC=corp
  • Next, select CN=MicrosoftDNS
  • In the right hand pane, look for the zone in question, reverse or forward
  • Right-click on the folder and select Properties
  • Browse to the whenCreated properties to find out when the zone was added to the system

Thursday, July 30, 2015

SCOM - Check for and alert on low space on mount points - Part 1

I have a number of sites still running Exchange 2010 and because of the buggy management pack there is often not a way to alert on the drive space of an exchange server mount point because sites have removed the management pack.

In searching for a solution, I came across a nice article that helped get me started here:

I took that script and added some additional information so that I could generate both an error condition on low drive space as well as a recovery alert so SCOM knew when to close the alert itself.

In order for this script to run cleanly, you first need to run the following powershell command on any server you want to run mout-point checks on:

new-eventlog -LogName System -Source OpsHealthScript

Next, schedule the following script to run periodically on your server via task scheduler or whatever program you might use to run scripts on a recurring basis.

$TotalGB = @{Name="Capacity(GB)";expression={[math]::round(($_.Capacity/ 1073741824),2)}}
$FreeGB = @{Name="FreeSpace(GB)";expression={[math]::round(($_.FreeSpace / 1073741824),2)}}
$FreePerc =    @{Name="Free(%)";expression={[math]::round(((($_.FreeSpace / 1073741824)/($_.Capacity / 1073741824)) * 100),0)}}
$Check = @{Name="Failed";expression={[math]::round(((($_.FreeSpace / 1073741824)/($_.Capacity / 1073741824)) * 100),0) -lt 10}}

 function get-mountpoints {
 $global:volumes = Get-WmiObject -computer $server win32_volume | Where-object {$_.DriveLetter -eq $null}
 $global:volumes | Select SystemName, Label, Capacity, FreeSpace, $Check | Format-Table -AutoSize

$servers = [system.environment]::MachineName
foreach ($server in $servers){

$Flag = $global:volumes | Select $Check
If ($Flag -match "True") {
Write-EventLog -logname System -source OpsHealthScript -eventID 500 -Entrytype Error -message 'One or more Exchange mount points are below 10% free space.'

Else {
Write-EventLog -logname System -source OpsHealthScript -eventID 800 -Entrytype Information -message 'Exchange mount points are healthy.'

You can access the file here: mount-point-space.ps1

Once this is scheduled, you can setup alerting in a couple of ways, one is a simple alert detection within SCOM to detect Error 500 in the system event log, the other is a correlated alert detection so that each alert generated by the script does not create a new alert within SCOM. I'll go over that in additional detail.

Friday, March 27, 2015

Exchange Inventory Powershell Script

Not SCOM related, but I cobbled together a powershell script that gives useful information for your exchange inventory. In particular, I was looking to re-balance my exchange databases and wanted to get the particulars of all my user mailboxes. I find that using using the alias when running some of the move commands is easier. The script will provide you with the following information:
  • Users's display name
  • Total size of the user's mailbox
  • The primary SMTP address for the user
  • The user's alias
  • The database on which the mailbox is located
By tweaking fields in the PSObject section, you can display or remove additional information, so long as that information is part of one of the other calls, like get-recipient or get-mailboxstatistics. As an example, the original script I found did not pull the database information, so I added that field in.

$(Foreach ($mailbox in Get-recipient -ResultSize Unlimited -RecipientType UserMailbox){
$Stat = $mailbox | Get-MailboxStatistics | Select TotalItemSize,ItemCount
                New-Object PSObject -Property @{
                DisplayName = $mailbox.DisplayName
                TotalItemSize = $Stat.TotalItemSize
                PrimarySmtpAddress = $mailbox.PrimarySmtpAddress
                Alias = $mailbox.Alias
                Database = $mailbox.Database}
}) | Select DisplayName,TotalItemSize,PrimarySmtpAddress,Alias,Database

Thursday, January 8, 2015

System Center Custom Application Monitoring

Sometimes, a problem can seem really hard, but turn out to be rather simple if approached from a different perspective. The application team I support has a poorly written application running on a server. This should sound familiar to most system admins out there.

The application crashed the other day, but none of the windows services actually stopped, nor were there any event log errors to really go off of either. How do we monitor that service then? One option might be the TCP port but nobody seemed to know what that was. Digging into the application, it had a small scripting engine, which allowed us to run some basic scripts.

The first thought the application team had was, we'll write an event log saying everything is ok, and when that doesn't appear, we want an alert. Well, we can monitor for missing alerts in SCOM, but that seemed like it would be destined for error.

What we settled on instead was to have the program simply drop a file in the temp directory. It would put the file there every 30 minutes, with the same name. So now what? I created a small and simple batch file that would check for the file, then delete it if it was there. Otherwise, report the file missing and the service stopped.

IF EXIST C:\TEMP\running.log GOTO Good
EVENTCREATE /T ERROR /ID 333 /L application /d "Custom Application Failed"
DEL C:\TEMP\running.log /q

I then set a schedule task to run every 30 minutes to run this batch file. When the file went missing, it would write the error to the event log. From there, just setup an event monitor in System Center to catch and alert on the event.

Operations Manager Performance Trending with Excel - No SQL Required

A powerful tool for administrators is to trend data to troubleshoot performance problems and forecast future resource needs. In the past, I've run SQL queries but needed a way to instruct support staff on a basic means to accomplish the same tasks right from the console. Thankfully, Operations Manager and Excel allow just that.

Let's get started.

Fire up the Operations Manager Console to the Monitoring section, then open the Windows Computers view (or any section where you access the computer health view, such as SQL)

Find a server you're interested in or simply select one from the list.

After selecting the system, select the Performance View under the Navigation pane of the task panel on the right side of the management console.
Once the Performance View window comes up, in the Performance Actions pane on the right side of the console, change your time frame via Select Time Range, selecting a meaningful period, such as two weeks or longer.
Now at the bottom of the performance monitor screen, select a counter you're interested. I'll use Percent Memory Used for this example.

When selected, a graph should display such as the following:
Going back to the Performance Actions pane, select Copy Data to Clipboard

Open up notepad and past the contents, which should look similar to the following:

Save the file with an xml extension
Now open Excel, select the Data tab and select From Other Sources -> From XML Data Import

Select the XML file created earlier; accept the import defaults when prompted

This should populate the Excel spreadsheet with an X and Y column. The first column is the date/time stamp and the Y column is the performance data.
Select all of the Y data and with it highlighted, select the Insert tab -> Line -> 2-D Line to generate a graph.

This should yield a graph in Excel such as the following:

Right-click on the graph line and select Add Trendline

Generally, accepting the default will paint a trendline  that is helpful for finding issues such as a memory leak or consistent data usage on a hard drive. However, you can play around with the trend to perform longer-term forecasts. I added 50 periods to the end of my trend line to see how memory might look in the future after my data set.
Graph results with the trendline:
The line extends a bit beyond the graph data and shows an overall flat trend on memory utilization. If the server had a memory leak, as an example, the graph might trend steadily upwards like this:

There you have it, a simple but powerful tool for analyzing data recorded in SCOM without a lot of effort.