Troubleshooting Link State Issues Caused by a Missing “Send As” Permission
Link State is the routing algorithm that Exchange 2003 uses to determine the best route to deliver a message. I won’t go into great detail about Link State since it has been described in detail in so many other places:
https://msexchangeteam.com/archive/2004/03/10/87622.aspx
https://support.microsoft.com/?kbid=842026
The following link shows a very comprehensive guide to troubleshooting Link State:
https://technet.microsoft.com/en-us/library/aa996974(EXCHG.65).aspx
However, one of the most common reasons we see Routing Group Propagation failures is because of a “Deny” being set on a group in AD. The guide above gives a quick blurb:
“If the routing group master or any routing group members are missing the SendAs permission, WinRoute will show the server as Am I connected to the Master?: NO. Verify that this server or the groups it belongs to are not explicitly denied the SendAs permission on the routing group master.”
But this doesn’t give you an effective way to see if this is your problem which is the purpose of this blog.
The easiest way to determine if you are dealing with a permissions issue is to:
1. Take a Winroute.exe snapshot of the Routing Group Master and verify that it can’t connect to itself.
2. Get a quick Regtrace.exe to verify it is a permissions issue.
3. Walk the permissions tree until you find the problem.
Step 1
If the Routing Group Master can’t connect to itself it’s a pretty good bet you’re dealing with a permissions issue. It’s possible that another application has grabbed port 691 and you can test that by stopping the Routing Engine and running Netstat –an. If you see something listening on port 691 then you know you’re dealing with a port conflict. If not, its probably permissions.
Otherwise you will expect to see something similar to the following:
Step 2 – Take a Quick Regtrace
Regtrace is built into Windows 2003 and simply needs to be configured to gather the correct information. This process takes about 2 minutes and can help you save hours of troubleshooting time.
Add the following registry key to enable Regtrace:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MosTrace\CurrentVersion\DebugAsyncTrace]
"AsyncThreadPriority"=dword:00000000
"AsyncTraceFlag"=dword:00000000
"EnabledTraces"=dword:00000044
"MaxTraceFileSize"=dword:0c800000
"OutputTraceType"=dword:00000001
"TraceFile"="c:\\1.atf"
"Modules"=hex(7):52,00,45,00,53,00,56,00,43,00,00,00,00,00
This will create the c:\1.atf file which is tracing the Routing Engine and has a max size of 200mb. It generally won't get over a few hundred k. You can copy the above data into notepad and save it as an *.reg file if you would like to simply import it that way.
Now, restart the Routing Engine Service to gather startup information. The “Send As” check is made on startup.
Next you want to disable tracing setting EnabledTraces and OutputTraceType keys to zero in the registry. Then remove the Modules key.
You always want to disable regtrace when you're done with it because it does cause a performance hit.
Open the 1.atf in notepad and you will see a whole lot of gibberish. Generally, these files need to be “fixed” and viewed with a Microsoft internal application, but for the purposes of testing “Send As” you simply need to do a search in that file for “Other side does not have full authorization”
If you find that string, you are dealing with a deny on “Send As.”
Step 3 – Walking the Permissions Tree
“Other side does not have full authorization” tells you that the Routing Group Master does not have “Send As” permission on its own Server object in Active Directory. By default, it should inherit this permission from the Organization object. Most often, people will add an account to the “Exchange Domain Servers” group to give it full access to all mailboxes. However, once a user or group is added to a built in Exchange group, that group will now carry all of the permissions associated with that account. Permissions are cumulative. This can make identifying permissions issues difficult and ExBPA does not identify this issue.
To walk the tree you will use a combination of ADSIEdit and Active Directory Users and Computers.
Start by getting the permissions on the server object of the RG Master.
If you’re lucky, you’ll find either an explicit or inherited deny on “Send As” for either the Exchange Domain Servers or ServerNameC$ account.
If you find it there, simply remove it, restart the Routing Engine and wait. If that doesn’t allow the master to connect you need to continue walking the tree.
If the permission isn’t obvious, I generally start by pulling group membership starting with the server in Active Directory Users and Computers.
The server should only be a member of Domain Computers and Exchange Domain Servers. In this example there is an Exchange 2007 environment so it is also a member of ExchangeLegacyInterop.
Next, double click on Exchange Domain Servers and check its members. You should ONLY see Exchange 2003 servers here. Exchange Domain Servers should only be a member of Exchange Enterprise Servers and Pre-Windows 2000 Compatible Access. Exchange Enterprise Servers should only have Domain Servers as a member and shouldn’t belong to anything. This is the most common place that permissions get misconfigured. If there are other users or groups here, that is most likely the problem.
You can verify this is the problem by going back to permissions on the server object in ADSIEdit. Find the group or user that was added and see if it has “Send As” permission. If it’s a user, you should see it immediately. If it’s a group, often you have to check membership of that group and look up each one.
I will often just highlight the top listing in the security box, scrolling the bottom box down to the “Send As” right and then checking each user/group.
If “Send As” is an inherited Deny you can use the Advanced Tab to see where it is inherited from:
In this example you can see it is inheriting the deny from the “First Administrative Group” level.
Hope this helps!