Archive for August, 2014

Exchange Message Tracking using EMS

Sometimes I just love linux even more. Message tracking and just plain logging in Exchange is just unbearable. I love the way it is so simple to get right to the problem a linux system.

Determining what has happened to message in Exchange is just a nightmare. It seems even worse in Exchange 2013, but I know there is a lot of information there. It would just be nice to see a simple standards based SMTP type of log. I have yet to stumble on it in the mountain of logging options in EMS.

First, you have to set the event log level. At least, I believe you do. Regardless, it is something to note here, because it could useful for troubleshooting other kind of issues.

To check the current event log levels:

[PS] C:\>Get-EventLogLevel

I highly recommend piping this out to more, because there are a lot of them. By default, almost all of the log levels are set to Lowest.

To change a log level:

[PS] C:\>Set-EventLogLevel -Identity identityname -Level newlevel

For example:

[PS] C:\>Set-EventLogLevel -Identity MSExchangeTransport\SmtpReceive -Level High

[PS] C:\>get-messagetrackinglog -start “6/6/2014 10:00:00” -end “6/17/2014 23:59” -recipient “recipientemailaddress” -sender “senderemailaddress” | format-list | more

If you get a log of output, you may need to use ResultSize to increase the number of items listed. Also, you can use Select to selectively choose your display columns:

[PS] C:\>get-messagetrackinglog -start “6/6/2014 10:00:00” -end “6/17/2014 23:59” -EventID RECEIVE -ResultSize 10000 -recipient “recipientemailaddress” -sender “senderemailaddress” | Select Recipients,Sender,MessageSubject,TimeStamp

Replication – Event ID: 13568

I was getting the following error in the “File Replication Service” event log in a Windows 2003 ADS environment, and replication was not working at all.

The File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR.

WARNING: It is possible that you can lose some data (policies and scripts). This assumes that the PDC is the machine from where all changes are made, and contains the master copies from which everything will be replicated.

I am not exactly sure this was the correct way to resolve this issue, but I do know that the Event ID 13568 and others have stopped and my policies and scripts are now replicating fine.

This is what I did to resolve the issue:

Stop the “File Replication Service” on the server that is holding your FSMO roles (PDC) and that is your master from which all of your changes are made.

Modify this following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup:

Change the value of “BurFlags” to D2 (non-authoritative restore).

Start the “File Replication Service”

Restart Netlogon

On each of the DCs:

Stop the “File Replication Service”

Modify this following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup:

Change the value of “BurFlags” to D4 (authoritative restore).

Start the “File Replication Service”

Restart Netlogon

Here is a good link for more information from Microsoft, and for how to handle other such event IDs:

S.M.A.R.T. status for VMware.

I wanted to try to find out the health of my hard drives on a server running VMware ESXi 5. Not even thinking, I used the smartctl command in one of my linux guests.

# smartctl –all /dev/sda
smartctl 5.43 2012-06-30 r3573 [x86_64-linux-2.6.32-431.17.1.el6.x86_64] (local build)
Copyright (C) 2002-12 by Bruce Allen,

Vendor: VMware
Product: Virtual disk
Revision: 1.0
User Capacity: 107,374,182,400 bytes [107 GB]
Logical block size: 512 bytes
Device type: disk
Local Time is: Mon Aug 18 11:18:29 2014 PDT
Device does not support SMART

Error Counter logging not supported
Device does not support Self Test logging

When I saw the output above, I was hoping for something I could run from the guest to get the information. Unfortunately, it looks like this something that has to be done from the host OS. You need to use the esxcli command to get the information. First, you need to identify the disks:

~ # esxcli storage core device list
Display Name: Local ATA Disk (t10.ATA_____ST32000542AS________________________________________5XW25D4F)
Has Settable Display Name: true
Size: 1907729
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/t10.ATA_____ST32000542AS________________________________________5XW25D4F
Vendor: ATA
Model: ST32000542AS
Revision: CC34
SCSI Level: 5
Is Pseudo: false
Status: on
Is RDM Capable: false
Is Local: true
Is Removable: false
Is SSD: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: unknown
Attached Filters:
VAAI Status: unknown
Other UIDs: vml.01000000002020202020202020202020203558573235443446535433323030
Is Local SAS Device: false
Is Boot USB Device: false

As you can see, this provides a lot interesting information about the drive. However, if you have a lot of drives, it can be more information than you need. I used grep to filtered out the unneeded information:

~ # esxcli storage core device list | egrep “^t10”

That way, I can identify all the drives in my system in a neat list.

Then, to view the S.M.A.R.T. information:

~ # esxcli storage core device smart get -d t10.ATA_____ST32000542AS________________________________________5XW25D4F
Parameter Value Threshold Worst
—————————- —– ——— —–
Health Status OK N/A N/A
Media Wearout Indicator N/A N/A N/A
Write Error Count N/A N/A N/A
Read Error Count 111 6 99
Power-on Hours 66 0 66
Power Cycle Count 100 20 100
Reallocated Sector Count 100 36 100
Raw Read Error Rate 111 6 99
Drive Temperature 42 0 46
Driver Rated Max Temperature 58 45 54
Write Sectors TOT Count 200 0 200
Read Sectors TOT Count N/A N/A N/A
Initial Bad Block Count 100 99 100

Return top