Troubleshooting Archive Attender with ixSearch

When a customer lets me know that a member of their user base is unable to retrieve a message via the link in the stub due to the original message not being found, there are a few things to check.

The first thing to check is that the message is actually in the archive location. To do this, first we must determine the GUID associated with the user in question. Open Archive Attender, Click Groups, and navigate to your user.

Right click the user and click 'Edit User Settings..'

























You will then want to browse the windows file system and navigate to the user's archive, and then the folder that the message exists in the user's mailbox. Please note that if the stub was moved after the archiving action took place, then you will have to check the folder that it was originally archived from.

















If we can verify that the message is where it is supposed to be, then we need to check the map index to verify that Archive Attender knows where to find it when you click the link in the stub. We can accomplish this with the ixSearch tool.

For Index Path, we choose the _Map folder under the Archive to which the user belongs. For the query, we enter the guid of the message in question. The guid can be taken from the link in the stub. We then click the 'Search' button. If nothing pops up, that means that the map index cannot find this message in the specified archive's map index.



















If it does in fact find an entry, as shown above, then we double click the result. It will pop up the following window in which we can see the location that Archive Attender believes the message to reside.



















In the case above, it is in the correct place. If this was incorrect from the real location, or it didn't exist in the map index at all, we'd have to run a task to rebuild the map index. Right click the archive in AACONSOLE.exe, click 'Archive Tasks', and then click 'Rebuild Map Index.'

















This will reestablish the link between stub, index, and archived message. I have seen two cases where the folder structure somehow got an extra space in one of the names, and the map index did not pick up on this. The fix is to be careful about reading the ixsearch.exe output, and verify that it is exact. If there is a space character issue, you can browse the folder structure and remove the space from the folder name manually to fix the indexing issue.

Azaleos is hiring!

If you are looking for an incredible employment opportunity, Azaleos is currently hiring for the following roles:

Senior Messaging Engineer

Network Operations Technician I

Network Operations Technician II

Azaleos employment opportunities have worthwhile career paths, great training resources, and access to knowledgeable professionals. Besides..who in the tech industry doesn't want to work for a cutting edge, fast growing, family of dedicated coworkers?

SherpaSoftware's Archive Attender - HTML MSG Format Issues on x64 Platform

In my experience with SherpaSoftware's Archive Attender, we found a small issue with the ability to download and display messages in HTML format when retrieving them.

*Before I go on, I would like to stress that SherpaSoftware does not support installing on the x64 platform, and never has. That being said..

My test lab was designed to run on x64 in order to run along side my Exchange server (which meant using the MAPI CDO rather than Outlook MAPI..and Outlook MAPI is what Sherpa uses). The issue is found when attempting to retrieve a message in HTML format from the archive as seen below:
























The issue comes when the user decides hit the 'Cancel' button and pull the message down as an HTML. This is beneficial for numerous reasons. First and foremost, you can then view the message on mobile devices, as well as from a computer that does not have a viewer for .msg files. When a user attempts this on an 64-bit Archiving server, they will get the following error:











Azaleos has worked closely with SherpaSoftware to come up with a possible solution to this, and Sherpa has continued to provide excellent service in this regard. As usual, they continually adapt their product to meet the needs of their customer base, even if that base is using an unsupported platform.

More to come on this front..

Quick Powershell Templates vol1

GET MAILBOXES WITH X ACTIVESYNC POLICY

Get-CASMailbox -resultsize unlimited | Where {$_.ActiveSyncMailboxPolicy -eq "Policy Name "} | export-csv C:\outputDefault.csv

You could also replace “| export-csv C:\outputDefault.csv” with “>> file.txt” or “| Out-File c:\file.txt”

Script for identifying and pulling event logs

Param (

[string] $ID

)

Get-Eventlog Application | where {$_.EventID -eq $ID}

ALLOW SHAREPOINT / DISALLOW UNC or File shares

Set-ActiveSyncMailboxPolicy -Identity ContosoMobo -UNCAccessEnabled $false -WSSAccessEnabled $true

Pull Mailbox size and sort

Get-Mailbox -Database <mbdb> | Get-MailboxStatistics | select DisplayName,TotalItemSize | sort TotalItemSize

Change OWA time out

set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\MSExchangeOWA’ -name TrustedClientTimeout -value 1440 -type dword

RAISED RULES QUOTA

Get-Mailbox | Where {$_.RulesQuota -ne "64KB"} | Select Name, RulesQuota

FIND USERS ANTISPAM BYPASS SET

Get-Mailbox | Where {$_.AntispamBypassEnabled -eq $True} | Select Name, AntispamBypassEnabled

FIND USERS WITH SEND ON BEHALF OF VALUE

Get-Mailbox | Where {$_.GrantSendOnBehalfTo -ne $null} | Select Name, GrantSendOnBehalfTo

FIND PEOPLE WHO’S ITEM RETENTION NOT DEFAULT

Get-Mailbox | Where {$_.UseDatabaseRetentionDefaults -eq $False} | Select Name, UseDatabaseRetentionDefaults

FIND PEOPLE HIDDEN FROM GAL

Get-Mailbox | Where {$_.HiddenFromAddressListsEnabled -eq $True} | Select Name, HiddenFromAddressListsEnabled

FIND EXCEPTIONS TO SIZE RESTRICTIONS

Get-Mailbox | Where {$_.UseDatabaseQuotaDefaults -eq $false} | Select Name, IssueWarningQuota, ProhibitSendQuota, ProhibitSendReceiveQuota

PULL MAILBOX STATS FOR USERS

Get-Mailbox -Filter { (Name -eq "Name1") -or (Name -eq "Name2") -or (Name -eq "Name3") } | Get-MailboxStatistics | Format-Table

BLOCK EXTENSIONS AND DELETE WITH NO NDR

Add- AttachmentFilterEntry -Name *. ext -type FileName

Set- AttachmentFilterListConfig -Action SilentDelete

Restore RSGMAILBOX TO:

Restore-Mailbox -Identity "Name2" -RSGDatabase MyRSGDatabase -RSGMailbox "Name1" -TargetFolder Extraction -SubjectKeywords "Meeting"

Places a copy of all items where the subject contains the word "Meeting" from Name1 recovered mailbox into Name2’s mailbox under the folder named Extraction.

REMOTE MOBILE WIPE

Clear-ActiveSyncDevice -Identity WINMOBILE

RESTORE AFTER RSG LOADED

Restore-Mailbox -Identity "Name1" -RSGDatabase Alpha -RSGMailbox "Name2" -TargetFolder NameRecovery

ENABLE OUTLOOK ANYWHERE

Enable-OutlookAnywhere -Server:ExchCas1 -ExternalHostName:mail.domain.com -SSLOffLoading:$false -ExternalAuthenticationMethod:Basic

(After RPC/HTTP is installed as well as cert)

SEND AS/ RECEIVE AS

$server = Get-MailboxServer SERVERNAME

Add-ADPermission -Identity $server.Identity -User "domain\user" -ExtendedRights ("Send As", "Receive As")

OR

Get-mailboxserver <servername> | add-adpermission –user <service account> -accessrights GenericAll -extendedrights Send-As, Receive-As, ms-Exch-Store-Admin

PULL Mailbox size and sort

Get-Mailbox -Database <mbdb> | Get-MailboxStatistics | select DisplayName,TotalItemSize | sort TotalItemSize

RECOVERCMS

Stop-ClusteredMailboxServer

setup.com /RecoverCMS /CMSName:servername /CMSIPAddress:ipaddress

Setup.com /ClearLocalCMS /CMSName:servername

Enable-StorageGroupCopy servername\SG1 -StandbyMachine standbyservername

Outlook 2003 GAL Displays EX type / Creating Detail Templates

The issue has been raised on occasion of Outlook 2003 not providing a good way to retrieve a user’s email address in the GAL. The ‘Email Address’ field in the GAL is of EX type, and displays as the LegacyExchangeDN, and there is no ability to copy the email address from the contact properties.

When looking in Outlook 2003’s GAL, you probably see something like this:

In Outlook 2007 you see the following:

The reason for this is that Outlook 2003 uses the EX type for the Email Address column and Outlook 2007 uses the SMTP type. The EX type is an internal type that exchange uses, and returns a value equal to the LegacyExchangeDN. Unfortunately, Microsoft has hardcoded the GAL view from being modified. A great way to work around this is to use the Details Template Editor under the Exchange 2007 Toolbox (or in Exchange 2003’s ESM, under Recipients), and create a field for email address in the property template. Performing this action is actually good to do anyways for both 2003 AND 2007 clients given the fact that it displays the user or contact’s email address in a field that can be copied if needed.

Exchange 2003 – ESM

Exchange 2007 – EMC

The following example will detail specifically for Exchange 2007, though it can be more or less applied to 2003 with modifications.

Choose the General tab, and either highlight a field to change, or drag out a new one. I chose to change the Alias field to Email Address in this example as it was the least needed field given the circumstances, and it would cut down on clutter. You can change which ever field you want, or create a new one by dragging boxes from the left hand column. To do this, we select Alias, and change the label field on the right to &Email Address. We then click the text field, and select Email Address from the drop down menu.

We now have a field in the properties of users for the SMTP Email Address to be displayed in a copy friendly fashion! This procedure can be repeated for contacts, etc.

Lingering Inter-Domain GC Objects

Recently, a customer experienced a very strange issue pertaining to inbound mail getting bounced from external sources intermittently with the error:

The following recipient(s) cannot be reached:
User on 6/11/2008 2:45 PM
A configuration error in the recipient's e-mail system prevented delivery of this message. Two recipients are configured with the same e-mail address. Contact your administrator.
<[Server] #5.1.4>

The Azaleos monitoring pulled the following from the event logs as well:

Alert: Event 9514 Sent By MSExchangeIS
Property: SourceName (MSExchangeIS)
Instance: Computer(MAILNODE1)
Two objects in the Directory have the same proxy - /DC=com/DC=Domain/DC=childdomain/OU=loc/OU=Departments/OU=dept1/CN=Last,First and /DC=com/DC=Domain/DC=childdomain/OU=loc/OU=Users/CN=Last,First.

At first glance this simply appears to be an issue with two legitimate users having the same email address, caused by replication issues, or creations / deletions at the same time. I searched AD on most of their Domain Controllers (DCs) for the SMTP address, and only turned up the one entry.

I decided to try to trick the system by removing that SMTP address from her account, and then sending the address email to find out where it went. When I did this I received:

First.Last@domain.com
The recipient's e-mail address was not found in the recipient's e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this -message, or provide the following diagnostic text to your system administrator.

The intermittent portion of this issue tells me that it could very well only be a phantom object on a select number of DCs. I decided to run some scans using LDP, LDIFDE, and ADUC. The only difference this time would be to scan using port 3268, which is the Global Catalog (GC) port, rather than the LDAP 389 port.

I ran the following command to derive output against the various GCs in their domain:

ldifde -f C:\output.txt -t 3268 –s GC.domain.com -j C:\ -r "(ProxyAddresses=SMTP: First.Last@domain.com)"

Just the one user showed up again. At this point I remembered that in beginning, I was told that the user had moved between child companies of the parent not long ago. I ran the same scan against the other child domain, but still found nothing.

I ran message tracking to verify mail flow, and that mail always entered the organization the same way. The messages always come directly to the user’s new child domain as expected, and then get rejected. This tells me that it has to be a DC/GC on the new host site of the user (We will call this site A, and their original domain of employment a site B). I connected each DC/GC in site A via ADUC (Active Directory Users and Computers) on the GC port, to the site B domain to poll its records. A single GC had a duplicate record of the user!

Now that the problem has been found, how do we solve it? There are actually two problems. The first is that records viewed over the 3268 port are read only, and if you view the same thing over LDAP (389), you can’t see the record to delete it. Well Microsoft gives us a handy tool called repadmin that usually clears lingering objects like this up.

I ran “repadmin /showrepl” in order to display this server’s replication partners. After pulling a GUID of the DC/GC that I wanted to reference. After pulling the GUID, I inserted it into the following command:

repadmin /removelingeringobjects Problemserver.domain.com a130f9a9-42c5-4499-93d1-530f07fbbec7 DC=company,DC=domain,DC=com /ADVISORY_MODE

but I got the following error..

DsReplicaVerifyObjectsW() failed with status 50 (0x32):
The request is not supported.

This leads us to the second problem. The error occurred due to the problematic server being Windows Server 2000. This problem was unforeseen as every other DC in the organization is 2003. This specific case was resolved by the customers decommissioning the server as a GC because they had been intending to get rid of it for some time anyways. If they did not want to get rid of this server as a GC, however, we could have removed the lingering objects by following the instructions here:

http://support.microsoft.com/?kbid=910205