RSS

Category Archives: Exchange Server

User could not send from another email address belong to himself

post from vpn. reason: can not access wordpress.com from China.
When user mailbox have multi email addresses, for example a@corp1.com and a@corp2.com, primary email address is a@corp1.com. And he wants to send a mail with mail from a@corp2.com. Then he will get a NDR that he does not have permission to send as a@corp2.com.
This is by designed. Do not try to change the behaved.

To help user get what he want, here is a workaround.

1 create a new public mailbox for him.
2 assign full access and send as privilege on the public mailbox for him
3 change primary email address on the public mailbox to a@corp2.com at the meanwhile change his email address to a1@corp2.com
4 ask helpdesk engineer to add the public mailbox opened in his mailbox account from outlook account settings.

Advertisements
 
Leave a comment

Posted by on January 28, 2012 in Exchange Server

 

Bug: if delete a mail request receipt without read, the sender will get a automatic unread receipt by exchange server

if delete a mail request receipt without read, the sender will get a automatic unread receipt by exchange server.

this behave is not expected and shown after apply exchange 2010 sp1 Rollup 3 and this is confirmed by MS CSS team.

This is plan to be fix in Exchange server 2010 sp1 rollup 4. But rollup 4 is recalled recently by Microsoft exchange team.  Now rollup 4 V2 is released at http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26910

recently exchange server 2010 sp1 rollup is not good quality because of the recall rollup 3 and 4. Please do not recall rollup 5 this month. Do you think it will be recalled in SEP 2010? Hope this is only a joke.

more information:http://blogs.technet.com/b/exchange/archive/2011/07/27/an-update-on-exchange-server-2010-sp1-rollup-update-4.aspx

 
 

User could not send from another email address belong to himself

When user mailbox have multi email addresses, for example a@corp1.com and a@corp2.com, primary email address is a@corp1.com. And he wants to send a mail with mail address from a@corp2.com. Then he will get a NDR that he does not have permission to send as a@corp2.com.

This is by designed. Do not try to change the behaved.

To help user get what he want, here is a workaround.

1 create a new mailbox for him.

2 assign full access and send as privilege on the new mailbox for him

3 change primary email address on the new mailbox to a@corp2.com at the meanwhile change his own email address to a1@corp2.com

4 ask helpdesk engineer to add the new mailbox opened in his mailbox account from outlook account settings.

 
 

all meeting request will automatically forward to another mailbox.

as this behave is not expected. And only meeting  request be effected. So I suspend it as an Stale rule issue. it could use mfcmapi to edit.

Download MFCMAPI from http://mfcmapi.codeplex.com/releases/view/66930

1.) Run MFCMAPI and hit ‘OK’ to clear the ‘About MFCMAPI’ information dialog.

2.) Select Session from the dropdown menu and click “Logon and DisplayStore Table”.

clip_image001

3.) Choose the Outlook Profile needed if set to prompt otherwise if there is only one profile it will load that one by default.

4.) Double-click the Default Store for the user’s mailbox which is tagged as True

clip_image002

5.) Expand the ‘Root – Mailbox’ item. Highlight Inbox

clip_image003

6.) Select Actions from the dropdown menu and click “Display rules table”.

image

7.) Check the Stale Rule by compare the rule shows in outlook and MFCMAPI.

clip_image005

clip_image006

8.) Select the Schedule + EMS Interface (Delegate Rule) and delete it.

this state will be at column PR_RULE_PROVIDER which will only exist in a Mailbox on the Server and NOT in a PST file

Remember, if there are multiple delegates assigned this will remove them all and the currently expected Delegate must be re-configured.

9.) Close windows to the main MFCMapi Screen and select Session dropdown menu and hit Logoff.

More information http://technet.microsoft.com/en-us/library/bb508857(EXCHG.65).aspx

 
 

Disabling LDAP Encryption and Signing for Netmon on an Exchange server

thanks for Ben Winzenz Sharing.

There may be times when in order to further troubleshoot a problem, you need to capture a Network Monitor trace.  Netmon is very helpful in finding delays, and LDAP errors.  However, there is one major hurdle.  Virtually all LDAP traffic is signed and sealed, and encrypted.  This unfortunately makes viewing the queries and responses impossible by default.  You would see something similar to the following.

Protocol Name Description
LDAP LDAP: GSS-API Encrypted Payload

 

And that is all you will see.  Of course, this makes troubleshooting much harder, because you can’t see what queries are being issued, or what the Domain Controller is responding with.  Fortunately, there are ways to turn off LDAP encryption.  I have gathered together the following list of things that need to be done in order to ensure that all forms of LDAP encryption are disabled.  Some steps are only for Exchange 2003, and others are only for Exchange 2007.  Where specific to a version, I have included which version it applies to.

Here are the steps to turn off LDAP encryption.  There are a few different places we have to do this in order to catch everything.

These steps apply to both Exchange 2003 and Exchange 2007

1. Modify the Local Security Policy.

Under Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options.  Find the policy setting “Network Security: LDAP client signing requirements”.  Note that the default is set to “Negotiate signing”.  On the Domain Controller side, it is actually set to None by default, but since the client requests to negotiate, it will always be signed if supported.  Set this to None on the “client” (the Exchange server is the client in this case).  You should also check the Default Domain Controller group policy, as if the LDAP signing policy is set to Negotiate, or Require, you will need to modify the Domain Controller policy as well.

2. Set the following registry key and value on the Exchange server.  If the AdminDebug key is not present, add it.  This registry value disables Encrypted LDAP Bind’s.  Normally, once a Bind request is issued, all LDAP traffic sent after that will be encrypted.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\AdminDebug

New DWORD value: ADsOpenObjectFlags

Data Value: 0x3

Per KB 325465, the following values correspond with the following actions.  As you can see, by setting the value to 0x3, we disable both Signing and Encryption.

Value Data (Hexadecimal)  Disables 
1  Signing 
2  Encryption 
3  Encryption and Signing

This step is for Exchange 2007 only

3. Add the following registry key to disable LDAP encryption for the Exchange 2007 DSAccess process

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange ADAccess

New DWORD value: Disable LDAP Encryption

Data Value: 0x1

This step is for Exchange 2003 only

4. Per KB818479, to disable signing and encryption for traffic created by Exchange 2003 Admin tools, add the following value

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange

New DWORD value: DebugLDAP

Data Value: 0x1

Once you have set all of these options, you should be good to go.  Get another Netmon trace, and you should now be able to view the contents of every LDAP frame.  On rare occasions, you may need to reboot to get all of these settings to be correctly read.  Also, don’t forget to undo any changes that are made once you are done.  Signing and Encryption of LDAP traffic is a good thing to have in place for security reasons, so only leave this disabled as long as you need to.

 
Leave a comment

Posted by on February 22, 2011 in Exchange Server

 

dirty shutdown not always indicate the DB is in that way

when using exeutil /mh those DB like Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), Standby Continuous Replication (SCR), of the Database Availability Group (DAG)  passive database copies appear in a dirty shutdown state. this is by design. Do not fear that.

the reason is dirty shutdown database indicates that the database requires additional transaction logs to be committed in order for the database to stand on its own. Those Lagged passive databases always get the log from active node a little later. And after get enough log the replay process will start. So it means those database will always in dirty shutdown status.  So this is by design, right?

 
Leave a comment

Posted by on February 17, 2011 in Exchange Server

 

UAG publish OWA should use basic authentication method.

this is a good idea that UAG hardcode UAG publish OWA using basic authentication method.

 
 
 
%d bloggers like this: