Finding the Error Type for Use with Trap and Try/Catch

I've read tons of web pages over last few years looking at error handling in PowerShell. Many of the blogs and examples assume that you already know the error type that you are looking for. Finally today I found an example of viewing the error type so that you can identify it and use it with Try/Catch or Trap.

To view the error type, first generate the error. This stores the error in the variable $error[0]. To view the error type use the following:

$error[0].exception.gettype().fullname

You can use this with Try/Catch to catch different error messages and perform different actions based on the specific error type.

Try {
     code to try
}
Catch [fullnameOfErrorType] {
     stuff to do for that error type
}
Catch {
     stuff to do for a non-defined error type
}

Passing Pipeline Objects byPropertyName Fails

In class this week, the text had the following example of a Powershell command that should work:

Get-ADComputer -Filter * | Select-Object @{name='ComputerName';expression={$_.name}} | Get-Service

The text claimed this would work and I initially thought it would. Here was my theory.....

Get-ADComputer retrieves the computer objects from Active Directory. Those computer objects have a property 'Name' that we can convert to a property named 'ComputerName'. Then the list of ComputerName property values is passed to Get-Service which has a ComputerName parameter that accepts pipeline input by property name.

However, like all good students, my class wanted to see it work. So, we tried it out, and it didn't work.

It failed with the following error:

Get-Service : Cannot find any service with service name '@{ComputerName=VAN-DC1}'

Further in there was a clue:

ObjectNotFound: (@{ComputerName=VAN-DC1}:String)

The problem relates to how parameters are passed through the pipeline. The preferred choice by PowerShell is to pass byValue. This means that values are matched to parameters based on the type of object that is being passed. Note that PowerShell will also convert data types to match a parameter that accepts pipeline data byValue if it can. Only if all options for binding based on value fail will it kick over and attempt to match byPropertyName.

In this case, the ComputerName property that we added (technically a PropertyNote) was being converted to a string. The Get-Service cmdlet accepts strings as input for the -Name parameter which expects the value to be a service name.

So, the end result is that it was a poorly constructed way to get the list of services from all computers. This example is perhaps easier and works. However, it doesn't showcase passing values along the pipeline.

Get-ADComputer -Filter * | Foreach {Get-Service -ComputerName $_.Name}

EventID 5139 and Kerbauth.dll Error

I recently reinstalled Exchange on a computer that has been installed into the incorrect domain. To do this Exchange 2010 was uninstalled, the computer joined to the other domain, and Exchange 2010 reinstalled.

During the installation process, all appeared good. However, the  Exchange Management Console and Exchange Management Shell were unable to connect locally on the new server. They tried to connect locally, timed out, and then connected to another Exchange 2010 server.

The following errors were in the event logs:

Event ID 5139
A listener channel for protocol 'http' in worker process '1028' serving application pool 'MSExchangePowerShellAppPool' reported a listener channel failure. The data field contains the error number.

Event ID 2280
The Module DLL D:\Microsoft\Exchange Server\V14\Bin\kerbauth.dll failed to load. The data is the error.

The source of this error turned out to be a line in the Windows\System32\inetsrv\config\applicationHost.config file. This line contains the path D:\Microsoft\Exchange Server\V14\Bin\kerbauth.dll when in fact is should have been C:\Microsoft\Exchange Server\V14\Bin\kerbauth.dll. After further investigation, it appeared that the original install of Exchange was done to the D: drive rather than the C: drive and that the change on the second install cause the error.

The line that needed to be modified was:

<add name="kerbauth" image="D:\Exchange Server\V14\Bin\kerbauth.dll" />

After the change to the C: path, all was good.

Dust Protection for Server

We have a client with two physical locations in the same town. To provide offsite backup, we create a system that replicates virtual machines to the second site. The second site is a machine shop that is quite dusty.

Plan A was to locate the server in a large utility room. However, it turns out that in the summertime, that utility room hovers at about 30C (86F). This is much warmer than I'm comfortable with. So, on to Plan B which is the air conditioned office area which is still dusty, but much cooler.

To host the server in the office area, we need some kind of box to house it in that can filter out dust. In my research, I found that the standard for this rating is IP 54 or NEMA 12. Those are two different standards that say the case makes the computer safe from dust and light splashing.

I did some research and here are the best options I found.

1. APC NetShelter CX. This is a nice looking cabinet that is sound proof and comes in various sizes. The smallest of these is an 18U box that is about $3800CDN retail. The dust filtering option is and extra $100 or so. I think this would be my choice in a standard office environment because of the looks and the soundproofing.
2. Tripplite SR42UBEIS. This is a 42U rack that looks like a server rack. It's large and not pretty but gets the job done for dust protection. However, there is no sound proofing. So, this one seems best suited to a dusty utility area than within an office. You're looking at about $2300CDN retail.
3. Dust Free PC. This company has a wide range of dust enclosures for computers and servers. The most basic enclosure for tower servers is about $600 plus shipping. Versions for rack mounting start at about $1500 for a 10U rack. These are not as pretty or sound proofed as the APC NetShelter CX, but they look very functional.

At this point, because it's for a shop, we're not that concerned about noise suppression or pretty. So, I think we're going to go with the Dust Free PC unit. A machine on their shop floor already uses a Dust Free PC enclosure for a PC and they've been happy with it.

Exchange Without a DMZ or Reverse Proxy?

For many years I've been implementing Exchange server in SMB environments without using a DMZ or reverse proxy to control access to Exchange services. At least since Exchange 2010 came out, I've been arguing that they don't really add much security value and that none of my customers  (nor any others I've heard of) had any issues with doing this.

Large companies have fairly rigid security policies. One of these policies is typically that no network traffic is passed directly to the LAN from the Internet. There needs to be some sort of reverse proxy in a DMZ (perimeter network in MS speak). In classes where I teach Exchange, the students from larger organizations typically believe strongly in these policies. They are risk adverse and this is the way it's always been. And many times, they have no control over this policy.

Well, a beautifully written article from Greg Taylor on the Exchange Team lays it all out for you to consider. From my perspective, it solidifies what I've thought for some time. It may give you some new ideas to consider.

Check out Greg's article here:

• http://blogs.technet.com/b/exchange/archive/2013/07/17/life-in-a-post-tmg-world-is-it-as-scary-as-you-think.aspx

Exchange 2013 Corrupted Health Mailboxes

While in the process of removing a database from an Exchange 2013 server, I got the following error:

Failed to remove monitoring mailbox object of database "DBname". Exception: Active directory operation failed on Servername. This error is not retriable. Additional information: Access is denied. Active directory response: 000000005: SecErr: DSID-031520B2, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0.

The database was removed, but there seemed to be some sort of Active Directory error when deleting the monitoring mailboxes associated with the database.

Next I tried to view the monitoring mailboxes by using:

Get-Mailbox -Monitoring

This showed me mailboxes with the following error:

WARNING: The object domainname/Microsoft Exchange System Objects/Monitoring Mailboxes/HealthMailboxbiglongGUID has been corrupted, and it's in an inconsistent state. The following validation errors happened: WARNING: Database is mandatory or UserMailbox.

After doing some searching, this problem is a result of Exchange 2013 not having sufficient permissions to the domainname/Microsoft Exchange System Objects/Monitoring Mailboxes OU. The database attribute is blank because the database it referenced no longer exists.

The simple fix is to manually delete the objects referenced by the errors from that OU by using Active Directory Users and Computers. After removing the object, the error is gone. You cannot use the Remove-Mailbox cmdlet to remove the accounts because Exchange does not have the necessary permissions.

It may be possible to resolve this error by giving Exchange Trusted Subsystem additional permissions to this OU, but I'll leave that for the Exchange team in the next cumulative update.

Note: Exchange 2013 RTM created the user accounts for these mailboxes in the Users folder. Exchange 2013 CU1 creates them in this new location. This may account for the changed behaviour causing the errors.

Deleting the health mailboxes is low risk because they should be recreated by the Microsoft Exchange Health Manager service on the Exchange 2013 server when that service is restarted.

Update: If the health monitoring mailboxes are not being recreated after you delete them, verify that the domainname/Microsoft Exchange System Objects/Monitoring Mailboxes OU exists. One commenter below was having issues and running ADPrep again created the container which allowed the health mailboxes to be recreated.

Exchange 2013 Hidden Mailboxes

In the graphical/web-based interface for Exchange 2013, the list of recipients does not include utility mailboxes such as:

• discovery search mailbox
• arbitration mailboxes

I recently had an issue at a client where rather than trying to fix an Exchange server having issues, we just replaced it and moved the mailboxes. However, before I could actually uninstall Exchange 2013 from the old server, I needed to move the mailboxes that did not appear in the graphical interface.

In the Exchange Management Shell (EMS), the discovery search mailbox is retrieved by the Get-Mailbox cmdlet. So, you can use the following to move the discovery search mailbox:

Get-Mailbox -Server RetiringServer | New-MoveRequest -TargetDatabase DBonNewServer

To get a list of the arbitration mailboxes, you need to use the -Arbitration switch with the Get-Mailbox cmdlet as shown in the screenshot below:

We had not implemented these, but other things that might trip you up are:

• archive mailboxes (use the -Archive switch)
• public folder mailboxes (use the -PublicFolder switch)

After you have removed all mailboxes from a database, then you can remove the database and finally, uninstall Exchange 2013. Uninstalling Exchange 2013 is the proper way to remove the server from the Exchange organization.

If you have not removed all mailboxes from a database before attempting to delete it, you will get the following error:

The mailbox database contains one or more mailboxes, mailbox plans, archive mailboxes, public folder mailboxes, or arbitration mailboxes.

Tool for SMART Status

I have an inexpensive test server that includes Intel's built in RAID functionality on the motherboard (Intel Rapid Storage Technology enterprise). This is a simple RAID controller that allows me to run RAID 10 on the server and have a bunch of virtual machines. However, it has a tendency every few months or so, to drop a drive from the array.

When a drive drops, I want to see the SMART status of the drive. This allows me to see the physical status of the drive and determine whether the drive is failing. However, the Intel management tool for the controller does not show the SMART status for the individual drives. Kind of a big oversight in my mind. Also, many tools that you can download to view SMART status don't work when RAID is enabled.

Today I found a nice open source utility for Windows to view the SMART status that works with this RAID controller. It is hddguardian. You can get it here:

• http://code.google.com/p/hddguardian/

Here is a screenshot: