Category Archives: Exchange 2007

Exchange Database is in Dirty Shutdown State Error – Learn to Fix

In this article, we are going to discuss exchange database is in dirty shutdown state. We will also discuss the solution to recover exchange from dirty shutdown which would be applicable for Exchange 2016, 2013, 2010 & 2007. As you might know that Exchange Server database is completely based on JET engine where log files are responsible for maintaining the track of input as well as output operations in the database file. It utilizes the concept of database cache mailbox to decrease the count of input and output operation. When the operation is loaded the cache memory then, it is not committed the information storage, the JET engine marks it as DIRTY. Until all the pending transactions are committed to the database then, it is not measured as updated. Moreover, until the time all the dirty pages are there in the database that is considered as inconsistent. Until the transaction is completed, if the machine shuts down accidentally then, database stay attached to the log file because of which “Exchange Database is in Dirty Shutdown State” error is received on screen. Continue reading Exchange Database is in Dirty Shutdown State Error – Learn to Fix

Heartbleed Vulnerability and Exchange Server

A member of a group on LinkedIn posted about a vulnerability in OpenSSL. Some more details are about the bug are documented here very well Critical crypto bug in OpenSSL opens two-thirds of the Web to eavesdropping

When you read OpenSSL, most of you might think it is not something applicable to my exchange environment since Microsoft Exchange doesn’t use OpenSSL anywhere. That may be not be 100% true. Although neither exchange nor windows natively use OpenSSL, this vulnerability still matters to you and needs you to look at if you are running any sort of hardware load balancer, reverse proxy appliance or a virtual appliance to publish exchange over internet or within corporate network.

A lot of load balancing appliances run on Linux based operating systems and do use OpenSSL stack extensively. You should do a double check on all the appliances that use Linux or Unix based operating systems on them.

How to detect Heartbleed

This vulnerability only applies to OpenSSL versions 1.0.1-1.0.1f. Other SSL libraries, such as PolarSSL, are not vulnerable. OpenVPN-NL, which is depending on PolarSSL, is not affected.

To detect whether you are affected by heartbleed you can use either of below tools

  • http://filippo.io/Heartbleed/ : a web based tool to test and identify the vulnerability. Just enter the name of the website you want to test, in exchange server’s case; it would be OWA/ EAS/EWS /OAB, etc URLs published on internet.
  • http://s3.jspenguin.org/ssltest.py : a python script to test for the vulnerability from the command line. If you want to scan multiple sites you can use a modified version with easily parseable output.
  • If you use Chrome you can install the Chromebleed checker that alerts you when visiting a vulnerable site.
  • To see whether your load balancing or reverse proxy appliance uses a vulnerable version of OpenSSL login to the appliance with and run openssl version if the version

Fix

OpenSSL has provided an updated version (1.0.1g) of OpenSSL at https://www.openssl.org/source/. It is recommended to consult your appliance manufacturer to find out the update procedure and implications of update before simply going ahead and applying the fix.

Exchange Type attribute

I have a habit of spending a lot of time to understand how exchange uses AD, Windows Registry, WMI, Crypto and all related stuff. One of my favorite things to do with any new version of exchange server is to look for the AD changes it makes. When Exchange 2010 was released I was trying to see through a lot of attributes and the way their values are constructed. All other attributes could be explained with the help of MSDN documentation or spending some time to create a logical link between the attributes, schema classes, etc. but the “type attribute on the exchange server object.

image

Value of “type” attribute looks something really weird. Initially I thought it was Chinese or Japanese but it is not. 😛

So what is this “Type” attribute on the exchange server object in active directory?

This attribute and the value of this attribute contains the licensing information of the server edition that you have chosen to install. When you install an Exchange Server 2010 role only Standard Edition of exchange gets installed automatically. Edition and licensing information is stored in type attribute in an encrypted form. Based on what key you have entered during the activation, exchange edition is determined and the value of this attribute also changes accordingly. Since it is in encrypted form, there is no specific pattern in the change that can be noted but you can still observe the change in the value of type attribute.

Well, that was just a geeky finding. Nothing useful anywhere in production although.

Listing Exchange ActiveSync Users and Device Details

As an IT administrator you must have come across a requirement from information security teams that they want to review the number of users who use emails on their mobile phones. Some companies require this data so that they can allow access only for selected users. Although listing users is not a big deal when you can use Get-CASMailbox -ResultSize Unlimited | ? {$_.HasActiveSyncDevicePartnerShip = $True} it is a bit of challenge for a novice powershell user to find out their device information too.

Below scriptlet is quite handy when it comes to finding EAS users and their handheld device details.

$ResultArr =@()
$CASMailboxes = Get-CASMailbox -ResultSize Unlimited | ? {$_.HasActiveSyncDevicePartnership -eq $true}
foreach ($CASMailbox in $CASMailboxes)
{

$ResultArr += Get-ActiveSyncDeviceStatistics -Mailbox $CASMailbox.Identity | Select @{Name=”User”;Expression={($CASMailbox.Name).ToString()}},DeviceType,DeviceModel,FirstSyncTime,LastSuccessSync,IsRemoteWipeSupported
}

$ResultArr | Export-Csv C:\Reports\EASDeviceStats.csv -NoTypeInformation

If you are lazy like me then you may want to send this information directly to someone using a bit of automation

Send-MailMessage -From “Support@company.com” -To “security@company.com” -Subject “ActiveSync User Stats” -Attachments C:\Reports\EASDeviceStats.csv ” -Body ” This is an autogenerated Email. Please do not respond to this email” -SmtpServer “ServerName”

I hope you find this useful!

 

Changing From Display Name of Full Mailbox Notifications

I am sure almost everyone of us have seen this at least once in the lifetime 🙂

One of our old days techies had this requirement of changing the From display name that is used by agents sending notifications about your mailbox size when it reaches the quota. Although you cannot edit the sender email address in this case you can indeed change the Display Name of this notification sender.

CAUTION: Steps involved in this post include using ADSIEDIT, wrong modifications to attributes can cause service stoppage. You should also check Microsoft’s supportability for this change.

Changing this includes changing the display name of the object in your transport configuration.

  1. Open ADSIEDIT
  2.  Navigate to CN=Transport Settings,CN=<Org Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=int
  3. In the right hand side pane locate the object named CN=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e
  4. Right click on the object and select properties.
  5. In properties dialog box of MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e locate the attribute displayName
  6. Select displayName, click Edit button and enter the Display Name of your wish in the Edit Dialog box.

That is all you need to do. Users will see the name that you entered in the dialog box after you modify this and the AD replication completes.

You cannot edit a transport rule if one or more of the recipient addresses are disabled or removed in an Exchange Server 2007 server

Been through such thing before? Well, it was a brain teaser for me for a while. One of my team mates contacted saying they are unable to edit a transport rule configured to BCC emails marked to a particular mailbox.

The situation was like this. Customer has a transport rule which adds 4 recipients as BCC recipients into emails sent to a mailbox named Application Support (application.support@exchange.local). Now, One of these intended BCC recipients resigned and his mailbox was deleted immediately. As a result, emails sent to application.support@exchange.local started bouncing to the senders with an NDR stating the email was not delivered to a user named U Gardner (u.garnder@exchange.local). Indeed, it was annoying for everyone to receive NDRs on each email sent to Application Support mailbox.

Off course, customer contacted our support team to fix this problem. We faced a new issue to be fixed before the NDR could be.

After locating the transport rule they found that they were not able to edit it so that they could simply remove the problem user from the actions page of the transport rule wizard. When right clicked on the rule they never got an option to edit the rule.

Microsoft confirmed this as a problem with Exchange 2007 SP2 systems and it is fixed in RU2 for Exchange Server 2007 SP2 here http://support.microsoft.com/kb/976195

Customer is on Exchange 2007 SP2 currently so it was impractical for us to install RU2 just to resolve this problem. So, we took a little way around 😉

Below are the steps:

  1. Open ADSIEDIT and connect to your configuration partition.
  2. Browse to CN=Transport,CN=Rules,CN=Transport Settings,CN=<Org Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local
  3. Locate the transport rule in the result pane of ADSIEDIT that has a problem
  4. Right click the transport rule and go to properties.
  5. Locate the attribute msExchTransportRuleXml in properties of the transport rule.
  6. Click on edit button.

XML of the rule in AD looks like below:

<rule name="Application Support Forwarding" comments="Application Support Forwarding">
                <fork>
                                <recipient address=application.support@exchange.local />
                </fork>
                <condition>
                                <and>
                                                <true />
                                </and>
                </condition>
                <action name="AddEnvelopeRecipient">
                                <argument value=om.k@exchange.local />
                </action>
                <action name="AddEnvelopeRecipient">
                                <argument value=ra.rai@exchange.local />
                </action>
                <action name="AddEnvelopeRecipient">
                                <argument value=
u.garnder@exchange.local />
                </action>
                <action name="AddEnvelopeRecipient">
                                <argument value=Ven.C@exchange.local />
                </action>
</rule>

If you look at the XML carefully, you will observe that the deleted user email address still lies there in the XML. This deleted mailbox causes a problem and would not let you edit the rule by any known method.

Now, to fix this problem you just have to locate the below part in the Transport Rule XML and delete it from the attribute value.

                <action name="AddEnvelopeRecipient">
                                <argument value=
u.garnder@exchange.local />
                </action>

Once you have deleted this portion of XML and made sure that AD replication has completed, disable the rule in question and enable it back.

Bingo! Problem resolved!!

MX Records: Are they really needed?

Sound a weird question? Yes, it shocked me too. One of my customers run Symantech BrightMail Gateway for their inbound email handling. This appliance has multiple accepted domain names configured. We were amazed to see some domain names not having an associated MX records yet they were receiving emails from internet. I though of digging down more into this just because it was interesting 🙂

For most of us the equation is extremely simple, No MX no email. But I learned something extremely interesting today. RFC 2821 says you can receive emails even if you do not have a MX record for your domain name.

Below text comes from  RFC 2821

5. Address Resolution and Mail Handling Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup MUST be performed to resolve the domain name [22]. The names are expected to be fully-qualified domain names (FQDNs): mechanisms for inferring FQDNs from partial names or local aliases are outside of this specification and, due to a history of problems, are generally discouraged. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name. If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error.

This clearly means if the IP address associated with your exchange server is the same that resolves to  your domain name’s IP address and you do not have any MX records configured in your DNS, you can still receive emails from the sending server compliant to RFC 2821.

Exchange Server 2007 and Exchange Server 2010 both applications are compliant to the mentioned RFC. Although I did not test this scenario yet this information might help you resolving your questions if you faced similar issue like I did.

Mail flow stops with 430 4.2.0 STOREDRV; mailbox logon failure

This is one of the most annoying error that you may probably face with your HT servers and they stop sending emails to MBX servers. There are multiple things that you need to go through to fix this problem. This post is just provide some common troubleshooting steps that can be performed if you face this problem. I faced this one toady in one of my customer’s Exchange 2007 SP2 environment.

This error is most likely generated by permissions issue in active directory. The best bet to find out these problems is using ExBPA. In this particular case the permissions were messed up at the server object level in active directory. Inherited permissions from parent objects got removed due to some reasons.

Here are few things that you should try in this case:

  • First off, make sure your active directory replication is not experiencing any problems.
  • All domain controllers, global catalogs have the correct time and synchronized with your designated NTP server.
  • You can use net time /set \ntpservername if you find any issue discrepancies in the time.
  • Make sure your HT and MBX server’s records are correctly registered in DNS and name resolution works perfectly fine. In some cases, you might want to add PTR records for all of your MBX, DS and HT Servers
  • Make sure your Default Domain Controller Policy had Exchange Server group added in Manage auditing and security log located at
  • Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment of your default domain controller policies.

  • One more things in basic troubleshooting is to check the logon account used for Microsoft Exchange Mail Submission service on mailbox server. It should be set to Local System and Transport Service on Hub transport server should be set to run as Network Service
  • image

    Once you have made sure all these things are in place the permissions are something that we need to concentrate on.

    • Use EXBPA to ensure that none of the Exchange Server objects have permissions inheritance blocked on them. If you have you should see something similar to below:

    image

    • If you really see something like above then the inheritance of permissions to these objects must be allowed. To do this follow below steps:
    • Open ADSIEDIT.MSC and browse to the location CN=<Exchange Server Name>,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange Geek Inc,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=local
    • Right click on the server object that was found not inheriting permissions from parent, Select properties, select Security Tab, Click Advanced button and check the check box “

    image 

    • We are not done yet. There are few more permissions we should check even after allowing inheritance on this object. Follow the previous step to get to security tab of the properties window of Exchange Server object

    image

    • As you see in above screenshot below permissions should be assigned to the Exchange Server security group:
    • Store Constrained Delegation – Allow
    • Store read and write access – Allow
    • Store read only access – Allow
    • Store transport access – Allow
  • These permissions should be checked on all HT servers and MBX servers using ADSIEDIT and they must be as shown above.
  • Force the replication across the site and make sure that all permissions are replicated to all the global catalogs in that site at least.
  • Hope that helps!

    How to add Employee Numbers in ADUC and Exchange GAL

    Some companies need to use AD to store their Employee Numbers or Employee IDs but due to limitations in ADUC MMC most of the people don’t tend to do this.

    I am not very sure how frequently some company needs this but one of my friend needed it for sure. 🙂 I did this in my labs few months ago and worked on at least 3 production environments too. I thought I can share this with everyone who reads at my blog. However, the steps I am going to show in this blog post will only apply to Exchange 2007 and Exchange 2010 GAL. Also, the templates editor tool that we are going to use does not show Employee ID field in the bindings page.

    There are few steps involved in doing this:

    1. A simple VB script stored at some location on network.
    2. Schema Admin group membership to the user account you are going to carry out this operation with.
    3. Exchange Organization Administrator group membership.

    Using the Visual Basic Script

    • Copy and Paste the below text in a notepad file and save it as .vbs

    On Error Resume Next
    Dim objemployeeID
    Dim objUser
    Dim ObjTemp
    Set objemployeeID = Wscript.Arguments
    Set objUser = GetObject(objemployeeID(0))
    objTemp = InputBox("Current Employee ID: "& objUser.employeeNumber & "If you would like to enter a new number of modify the exisitng number, enter the new number in the textbox below")
    if objTemp <> "" then objUser.Put"employeeNumber",objTemp
    objuser.SetInfo
    If Err.Number = "-2147024891" Then
    MsgBox "Your current account does not have permissions to modify the Employee-ID attribute. Please log on with an account with appropriate permissions.",16,"Permission Denied"
    End If
    Set ObjUser = Nothing
    Set objemployeeID = Nothing
    Set objTemp = Nothing
    WSscript.Quit

    • Rename this file to .vbs and store at some network share e.g. \servernameADScriptsEmpID.vbs . The only idea behind storing this script on a network location is to keep this available even the ADUC is used from client computers.

    Editing Schema and User Display Configurations in AD configuration partition:

    Warning: It is highly recommended that you back up your Active Directory before modifying anything in schema. Incorrect changes in schema can cause undesired behavior of Active Directory Services.

    • Logon to any domain controller with Schema Admin privileges.
    • Click Start –> Run and type regsvr32 schmmgmt.dll and hit enter.
    • Click OK on the information dialog that appears on the screen
    • Click Start –> Run and type MMC and press enter.
    • In MMC click File menu and select Add/Remove Snap-In.
    • Click on Add button on Add/Remove Snap-in page.
    • Select Active Directory Schema from the list that appears on the screen.
    • Click Add and click Close and click Close.
    • Expand Classes in Active Directory Schema Snap-in and locate class person.
    • Right click on class person, select Properties and click on Attributes tab.

    image

    • Click on Add button and select employeeID

    image

    • Repeat above step to add employeeNumber as well.
    • Now open ADSIEDIT.MSC and locate CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=domain,DC=com
    • Right click on CN=user-Display and select Properties.
    • Locate the attribute adminContextMenu on Attribute Editor page and click Edit button.
    • Type ,&Employee-ID,\adpun3AD ScriptsEmpID.vbs exactly as shown in figure below and click Add button. (I recommend copy and paste the text in red color)

    image

    • Click OK button and exit the ADSIEDIT.msc
    • Now open Active Directory Users and Computers and locate the user account you want to modify the Employee ID for. You will see an additional context menu item in when you right click on the desired user object.

    image

    • A new pop up appears when you click the above context menu. You can enter or modify the Employee ID for the select user account using the the pop up.

    image

    Adding Employee ID field in Exchange 2007 Global Address List

    • Now to make this Employee ID field visible in Exchange 2007 Global Address list you can use Details Templates Editor tool from Exchange 2007 EMC.
    • Logon to your Exchange 2007 Server with Organization Administrator and open Exchange Management Console.
    • Locate and Open Details Templates Editor Tool from Toolbox node in EMC.
    • Locate the template for User type and Language English (United States) and click Edit from Actions pane. Refer below figure.

    image

    • A new Editor Opens on the screen. Select a Label and a Edit controls from Tools pane in the opened Editor window and place them at your desired location.

    image

    • Add details to the Label control using property editor pane in the editor tool. To do this, select The Label control that you just dragged and dropped on the template and add the text in properties pane.

    image

    • Add details to Edit control and bind it to specific attribute in AD. To do this, select the Listbox control and select Employee ID attribute from Properties pane.

    image

    • Save the edited template by selecting File Menu and Save.
    • Exchange GAL will show the details as shown below. If you are using outlook in cached mode then you will have to wait till the OAB is generated.

    image

    I hope you find this useful and can use when you require this. Do let me know if you have any comments on the post.

    The client operation failed. Error is [0x80004005-0x0004b9-0x000501]

    Our server engineering team was investigating an issue on a bounce back a user got and the whole team spent a lot of time researching on below message.

    From: System Administrator
    Sent: Tuesday, April 20, 2010 4:53 PM
    Cc: Recipient Name
    Subject: Undeliverable: Trainings

    Your message did not reach some or all of the intended recipients.

    Subject: RE: Trainings

    Sent: 4/20/2010 4:45 PM

    The following recipient(s) cannot be reached:

    Recipient on 4/20/2010 4:53 PM

    This message could not be sent. Try sending the message again later, or contact your network administrator. The client operation failed. Error is [0x80004005-0x0004b9-0x000501].

    At the first glance it seems like a problem with permissions on recipient mailbox. However,the error "0x80004005-0x0004b9-0x000501" comes from trying to submit a message on the Exchange transport. The code 0x0004b9 is an ecNullObject from Store, indicating that the failure occurred because an object referenced was null. This implies that this user was having some intermittent networking issue that happened to hit at the time the message was submitted.

    This behavior is by design and the error is expected when network failures occur. If your computer is connected via wireless or a WAN link, then random failures on the network can be common, and that would explain the behavior. Even on a local area network, RPC failures are not uncommon.

    In general, this problem is likely caused by intermittent network connectivity issues, or possibly out-of-resource problem on the client machine.

    I suggest getting back to the user and requesting them to re-submit the message if similar kind of problem occurs in future as well.