Exchange Geek's Weblog

I'm a Geek!

Archive for the ‘Exchange 2007’ Category

Changing From Display Name of Full Mailbox Notifications

Posted by Milind Naphade on 29/11/2011

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.

Advertisements

Posted in Exchange 2007, Exchange 2010 | 2 Comments »

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

Posted by Milind Naphade on 24/06/2011

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!!

Posted in Exchange 2007, Transport | Comments Off on You cannot edit a transport rule if one or more of the recipient addresses are disabled or removed in an Exchange Server 2007 server

MX Records: Are they really needed?

Posted by Milind Naphade on 18/05/2011

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.

Posted in Exchange 2007, Exchange 2010, Transport | 5 Comments »

Mail flow stops with 430 4.2.0 STOREDRV; mailbox logon failure

Posted by Milind Naphade on 06/05/2011

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 Configuration\Windows Settings\Security Settings\Local Policies\User 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!

    Posted in Exchange 2007, Exchange 2010 | 3 Comments »